协调程序开发

    此 SOA 开发流程的第五步是由协调程序开发团队实现使用服务的应用程序。在实际服务实现就绪之前，应用程序都将使用服务模拟。

    此时，由于具有大量的服务模拟，因此协调程序团队可以继续进行其相关工作，就像已经实现并提供了服务提供程序一样。而且，协调程序团队不仅具有一组可以使用的服务(也就是模拟)，而且也有了可以演示服务如何工作的和客户机如何使用服务的一组测试。该团队可以将这些测试作为可以如何实现其协调程序的简单原型使用。和提供程序团队一样，尽管尚未实现任何代码，但协调程序开发团队已经早就在进行协调程序的工作了。

    理想情况下，协调程序团队将可以使用达成一致的服务模拟来成功地实现他们的协调程序。不过有时候这样做有些困难。模拟并不提供某些需要的行为或希望的接口。协调程序客户还需要比模拟提供的服务更细粒度的服务。如果服务协调程序需要其他功能，则可以尝试自行实现此功能。如果协调程序需要不同的接口，则可以尝试实现一个适配器，来将其所希望的接口转换为模拟实现的接口。如果协调程序希望更细粒度的功能，则该团队需要对模拟及其测试进行修改。

    这些更改会使得有必要重新与提供程序团队进行同步。让我们假定协调程序团队实现了额外的功能或不同的接口来提高服务的可用性。如果添加的行为不是特定于协调程序，而是会涉及到服务，则添加的行为可以潜在地由其他服务使用者重用。因此应将其内置到提供程序中。提供程序所需的更改可以也应该建模为对模拟及其测试的更改。当协调程序团队必须修改模拟及其测试时——既可能是为了增强其他功能也可能是为了对功能进行进一步细化——必须将这些更改应用到提供程序和其他所有的工作内容。已更改的模拟和测试成为协调程序团队、提供程序团队以及其他协调程序提供团队之间的重新协商点。他们必须针对达成一致的一组新模拟和测试重新进行同步。

    示例协调程序实现

    协调程序开发团队将实现一个委托给 StockQuoteService 的实现的客户端组件。它的行为将与服务测试相似，不同的是，它将使用服务类为 GUI 或客户端应用程序提供真正的功能。协调程序实现只能使用 StockQuoteService 中经服务测试证明可用的功能。Java 编译器将确保协调程序代码只能调用服务接口声明的方法;保持协调程序实现与测试实现的一致可以确保服务按预期的要求工作。

    将流程组合起来

    那么，该流程在实践中是如何工作的呢?

    第一步，开发服务用例。服务用例团队可以包括来自提供程序团队和协调程序团队的代表。或者，这个团队可以仅由那些专门进行需求收集和用例开发的分析人员组成。传统用例开发主要关注人们如何使用应用程序，而这个团队必须将重点放在组件如何集成上。他们不应关心提供程序将如何实现，也不用考虑协调程序可以如何实现。相反，他们应将重点放在服务是什么、它们完成什么工作以及如何对其进行调用上。

    第二步，将服务用例编写为服务测试。用例是人可读的，而服务测试表示相同的需求，但采用的却是计算机可执行的方式。这些测试必须由开发人员实现，而不是由开发用例的分析人员实现。测试开发人员可以是提供程序团队和协调程序团队的成员，也可以是可用且有能力实现测试的人员。在最终确定测试之前，每个团队的代表都必须对其进行认可，从而表示所有团队已就其达成了一致，而不考虑谁开发了哪个测试。

    第三步，开发通过测试的服务模拟。开发测试的团体通常也实现模拟。模拟证明测试可以通过，作为原型供提供程序团队使用，并支持协调程序团队继续进行开发。与测试一样，除非所有团队都认可模拟并表示同意，否则就不能认为已最终确定了模拟。换句话说，任何团队都不能强制别的团队接受一组测试和模拟，大家必须一致认可，否则迟早会出现混乱。

    第四步，提供程序团队部署提供程序，这些提供程序的行为与模拟相似，且均已通过了测试。如果将这些提供程序添加到测试和模拟，尤其是在更改了测试和模拟的情况下，则他们必须分发这些更改，以便其他团队重新进行同步。他们不能强制让其他团队接受这些修改;所有团队必须就此达成一致。

    第五步，协调程序团队必须使用模拟开发可以正常工作的协调程序。如果需要更改模拟，他们还需要对测试进行更新。他们需要随后将其更改分发给其他组，所有的团队必须找到一个大家都认可的点——一组共同的测试和模拟，并据此重新进行同步。

    这些步骤一起的确可以形成一个简单的开发流程。