通过服务模拟来简化SOA开发(3)

　　此 SOA 开发流程的第四步是由提供程序开发团队实现通过服务测试的服务。

　　此时，提供程序团队已经准备好，可以进行服务开发了。既然他们还没有开始实现服务，怎么可能进行服务开发呢?幸运的是，他们已经开发了描述服务应如何工作的服务用例，开发人员就是开发人员，他们已经开始考虑如何实现服务了。开发人员已经创建了服务测试，这些测试可说明服务的 API 是什么，并帮助演示服务的行为。他们已经开发了服务模拟，这些模拟是表示实际服务将如何工作的快速原型。

　　因此，开发人员已经非常明确如何实现服务，只是尚未实现其相关的任何代码而已。

　　这几乎是毫无疑问的，但开发人员实现的服务必须通过服务测试。他们如何知道自己已经完成服务实现工作了呢?当服务通过了所有测试后，服务就已完全实现了。在开发期间，团队的开发活动可能会让他们添加要测试的其他功能。训练有素的团队不会放弃这些想法，而将对其进行捕获并添加到服务的测试集中。服务实现也必须通过这些测试。提供程序团队还应该向其他提供程序团队和协调程序团队通报这些添加的测试，以便所有团队的测试集保持同步。

　　理想的情况下，提供程序团队将可以成功地实现通过测试的服务，而不必修改已达成一致的测试。不过，这经常被证明是不切实际的。当开发人员实现服务时，他们有时会发现需要更改服务的接口或行为。如果服务测试的质量良好，而开发人员更改了服务的工作方式，则测试就不能再通过了。为了使测试仍然有效，开发人员必须修改测试，使其可以验证新的设计。更改测试意味着服务模拟现在将不能通过测试，因此也必须对其进行更改，以实际模拟服务现在的工作方式。

　　如果提供程序开发人员更改了服务测试或服务模拟，他们需要尽快通知协调程序开发人员和该服务的任何其他提供程序的开发人员。任何使用旧测试和模拟的人员都在根据一个现在已经过时的协议进行开发，因此各个团队需要根据新测试和模拟进行同步。如果其他团队拒绝接受新测试和模拟，则重新同步的工作就变成了团队之间的重新协商点。他们仍然有希望就服务用例达成一致，以从此处继续开展工作，从而开发一组一致认可的测试和模拟。

　　示例提供程序实现

　　提供程序开发团队将开发实现 StockQuoteService 的类或组件，其工作方式与 StockQuoteMock 类似，并使股票报价测试能够通过。模拟是一个包含硬编码响应的简单对象，而此提供程序是提供实际行为的组件。该实现应该执行以下操作:

　　﹡　支持所有有效股票代码(至少支持提供程序的股票交易中涉及到的所有股票)。
　　﹡　确保使用包含所支持股票的实时价格的数据库。
　　﹡　将数据库使用的价格格式转换为服务返回的格式。
　　﹡　将数据库针对无效代码的输入结果(如空查询结果)转换为服务希望的错误。
　　﹡　实现服务的协议，如 EJB 远程接口、HTTP Web 服务或 JMS 请求和答复消息。

　　由于模拟和实际提供程序实现相同的接口——在此例中为 Java 接口 StockQuoteService，因此服务测试可以使用两个实现中的任何一个;只要使用要实例化的正确类对测试进行配置即可。为了运行测试，您还需要使用测试期望的股票价格对数据库进行配置。

　　协调程序开发

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

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

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

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

　　示例协调程序实现

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

　　将流程组合起来

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

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

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

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

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

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

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

　　解决 SOA 问题

　　那么，这个流程是否解决了我在本文开始时提出的问题?

　　1. 如果某些提供程序尚未开发，则协调程序团队如何开发其负责的应用程序部分?

　　模拟解决了此问题。模拟可以快速地进行开发。虽然实际提供程序的开发需要更长的时间，但协调程序团队可以使用模拟同步开发协调程序。只要满足了以下条件，此工作就可以顺利地进行:

　　﹡　 模拟的功能全面，即意味着其编写的测试和用例也全面。

　　﹡　没有团队必须更改模拟。只要某个团队必须对模拟进行更改，他们就应该在进一步脱离同步之前尽可能快地重新进行同步。

　　2. 协调程序团队和提供程序团队如何较早而可靠地就服务如何工作达成一致?

　　因为测试和模拟可以快速进行开发，而且它们是真正可以运行的实际代码，所以提供了早期验证，从而可以确保用例有意义，并且团队真的达成了一致。有了经验后，可以在前期投入更多的精力，以确保测试和模拟的全面性，这些构件需要更改的几率越小，剩下的开发过程中需要重新进行同步的几率也就越小。

　　3. 实现相同服务的多个提供程序团队如何能确保他们的实现是兼容的?

　　一组公共测试以及通过这些测试的模拟可以作为公共参考框架使用，以确保独立的提供程序实现始终兼容且可互换。早期的测试越前面，需要更改的几率就越小，从而团队需要重新同步的情况也就越少。

　　这样一来，该流程就解决了多个团队实现 SOA 的不同部分时所面临的主要问题。