【IT168 技术文章】

    通过用例和模拟对象简化 SOA 开发——特别在您的项目涉及多个团队时——并提高 SOA 应用程序质量。借助于可重用服务和需要很少的新代码的应用程序(因为可以依赖这些可重用服务)，面向服务的体系结构 (SOA) 可以大幅度提高应用程序开发的速度。

    但是 SOA 还可能大大增加应用程序开发的复杂性，因为团队需要同时进行应用程序的不同部分的工作，而且要在最后成功地将各个部分组合起来。

    SOA 开发问题

    使用 SOA 开发应用程序可提供更多的应用程序部署选项，但也使得开发工作变得越发困难。这是因为 SOA 将应用程序开发拆分为两个截然不同的部分:

    1.SOA 服务提供程序(SOA Service Provider，SOA-SP) ——该层的代码实现服务。它具有服务 API，以对服务进行声明和为客户机提供调用服务的方法。

    2.SOA 服务协调程序(SOA Service Coordinator，SOA-SC)——该层的代码通过一个或多个 SOA-SP 中的服务提供用户功能。它可能具有 UI 或 GUI，以便同传统应用程序一样与 SOA-SC 进行交互。

    例如，某个金融应用程序的 SOA 可能如图 1 中所示。

    通常由独立的团队分别负责同时开发这两个独立的部分。一个团队负责开发 SOA-SC——对用户而言的应用程序。另一个团队负责开发 SOA-SP，或许存在多个负责此项任务的团队，而每个团队负责开发若干服务。虽然可能已经实现了一些提供程序，但可能仍然需要专门为此应用程序实现其他的提供程序。

    而这给我们提出了第一个问题:如果某些提供程序尚未实现，协调程序开发团队如何开发其负责的应用程序部分呢?

    这两个团队——开发服务的团队和开发协调程序的团队——需要使其活动同步。他们必须就服务 API 达成一致;服务 API 可以是简单的 Java? 接口或 Java Message Service (JMS) 消息格式和队列名称，但必须就此达成一致。但仅就接口达成一致是不够的;服务具有行为，因此团队必须就服务的行为达成一致。服务并不会始终成功地工作，因此团队还必须就错误情况和相应的响应达成一致。

    在理想的情况下，多个团队可以非常容易地协调工作，最初的决策可以稍后进行修改，而所造成的影响却非常小，并且评估工作非常灵活，此外还会不断地进行改进。在现实世界中，团队之间经常存在协作问题，往往较早地(甚至不成熟地)做出不可更改的决策，而且评估方法是固定的。

    这样就带来了第二个问题:协调程序和提供程序团队如何较早而可靠地就服务如何工作达成一致?

    经常通过多个提供程序来实现服务冗余。这样就可以在提供程序之间提供负载平衡和故障转移功能，从而使得协调程序的服务体验更为一致和可靠。冗余可以通过多次部署同一服务实现来实现。不过，当不同的供应商部署了不同的提供程序时，服务几乎肯定具有不同的实现。尽管如此，对于协调程序，所有提供程序的全部实现的工作方式都必须一致，以便协调程序可以采用可交换的方式来调用提供程序。服务的不同实现(特别是来自不同供应商的不同实现)是由不同的团队开发的，而这些团队必须加以协调，以确保开发的是相同的服务。

    因此，第三个问题就是:多个提供程序团队如何实现相同的服务，以确保他们的实现具有兼容性?

    以上是使用 SOA 进行开发的主要问题。必须实现尚未开发的服务来开发协调程序，协调程序团队和提供程序团队必须就服务如何工作达成一致，而且，多个提供程序团队也必须就服务如何工作达成一致。如果没有良好的流程，这就会导致一片混乱，如果不对其进行检查，将会导致 SOA 项目失败。