了解紧密耦合与松散耦合Web Services的优缺点以及紧密耦合带来的规模上的变化。本文提供了用于在测试过程中测定紧密耦合Web Services的性能的标准的示例。

　　引言

　　我的developerworks系列文章Use SLAs in a Web services context讨论了如何消除漏洞带来的风险以及如何将Web Services集成到具有服务水平协议（Service Level Agreement，SLA）保证的企业应用程序集成（Enterprise Application Integration，EAI）结构中。我的另一个developerworks系列Work with Web services in enterprise-wide SOAs讨论了负载平衡Web Services以及如何将射频识别（Radio Frequency Identification，RFID）Web Services集成到EAI应用程序中。本系列还讨论了如何开发风险管理Web Services 、将遗留服务组件迁移为可发现的Web Services以及如何使用IBM WebSphere? MQ开发Web Services来将SAP与IBM? DB2?及Oracle进行集成。

　　在上面的每篇文章中，我都在尝试说明面向服务的体系结构（Service-Oriented Architectures，SOA）如何与Web Services及其他交互软件代理间的松散耦合关系。通常，如果资源由于规模的变化而显得不足，而执行速度又至关重要时，我认为您可能需要对某些Web Services进行紧密耦合。

　　应用程序、系统和网络通常比其给定的资源容量（其中包括Web Services可用的消息队列）的发展速度更快。这带来了安全性和性能问题，任何时间任何操作超过了最大容量都可能导致基于消息的Web Services的系统过载。

　　在本文中，我们将了解：

　　·紧密耦合与松散耦合的对比。
　　·为何需要紧密耦合Web Services 。
　　·同步业务功能如何以异步的松散耦合Web Services的形式进行处理。
　　·Web Services的耦合情况如何能从松散耦合切换为紧密耦合。
　　·应该使用何种标准来测定性能。
　　·对测定有何约束。

　　紧密耦合与松散耦合的对比

　　大部分大型的复杂系统都作为大型子系统的小型集合构建，而不是采用小型独立子系统的大型集合的方式形成。这是因为在将系统分解为相对独立的小型组成部分时，可能无法提高性能、安全性、经济效益或无法获得其他主要的特征。大型系统的紧密耦合特征通常是通过优化总体设计和尽可能减少系统组件间的冗余和低效情况来实现的。这会导致系统的组件间的耦合更为紧密以及大量重要的相互依赖关系。

　　系统的组件间紧密耦合的一个缺点是，单个组件内的故障可能会导致整个系统无法使用。松散耦合的Web Services可以视为更好的替换方法；只要提供了备用的故障转移Web Services ，某个Web Services的故障就不会让整个系统无法使用。

　　您可以更改松散Web Services中的细节，只要更改不会影响所调用的Web Services的功能即可。紧密耦合系统可能很难维护，因为一个系统子组件中的更改通常需要立即对其他子组件进行调整。

　　与客户机与服务之间采用紧密耦合的情况（会尽可能减少冗余）不同，松散耦合Web Services需要大量的冗余。侦听Web Services和请求Web Services可能彼此不信任。这意味着必须添加安全和信任标准来让侦听方和请求方彼此信任。另一方面，紧密耦合的调用和被调用系统会假定双方都已经拥有了让对方信任所需要的事项。

　　为什么对Web Services使用紧密耦合？

　　无论资源是否稀缺，Web Services都通常采用基于消息的松散耦合方式；在进行进一步操作（如果有）之前，它们会通过消息队列等待回覆，并将此作为下一步操作的依据。其优势在于，采用传递消息的方式，而不是进行方法调用，从而提供了发送和接收Web Services之间一定程度的独立性。

　　如果大量的Web Services集体超过消息队列系统的资源容量而且在构建或重用具有新功能的Web Services的规划阶段未考虑处理峰值负载，则会导致系统过载。此时就该开始考虑让有些Web Services进行紧密耦合。

　　异步与同步的对比

　　松散耦合的Web Services应用程序可以采取异步或同步方式进行通信。只要应用程序支持相同的基于消息的标准接口，而且使用标准的可互操作语言（例如SOAP），异步Web Services就能彼此进行通信。可以通过异步处理和错误恢复机制保证得到应答。同步Web Services要求具有兼容性才能进行通信。

　　异步的松散耦合Web Services需要花时间来等待响应。同步的松散耦合Web Services并不会等待响应，而会锁定程序直到得到响应为止。同步调用可以通过编程来实现，但带有超时设置，如果调用在一定的时间内未返回，调用Web Services可能取消锁定，从而从系统退出。

　　异步的松散耦合Web Services的一个问题是，对于某些业务功能，可能会超出消息队列服务器或系统的资源容量。

　　业务功能

　　由于可靠性和可伸缩性的原因，业务通常是异步的，有些业务功能需要同步事务，如对目录、计划更改、信用卡事务批准和拒绝等的一些查询。接下来让我们讨论一个在线图书Web Services场景，其中松散耦合同步业务功能看起来似乎处于异步模式（虽然不是）。

　　异步模式

　　接下来让我们看一个在线书店示例，了解进行交易的流程。首先您进行选择，然后将其放入购物车。或许您会删除或添加一些图书。不过，购物车Web Services最终会以异步模式等待您完成购物。完成后，您要选择信用卡支付选项来进行购买。

　　然后，系统将通过外部源进行检查，以验证卡信息。如果您看到要求您花数分钟等待响应的消息，则系统就处于异步模式。另一方面，如果系统不断地验证和批准您的信用信息，则其处于同步模式。

　　同步模式

　　同步模式会在等待快速响应的同时锁定Web Services应用程序。如果应用程序将超时设置为数秒钟，则会在给定时间内退出，取消锁定应用程序，然后要求您稍后返回以完成事务。如果获得响应，您就知道了您的信用卡信息是否得到了批准。在得到批准信息后，将会看到感谢消息，然后将以异步方式等待图书送达。

　　缺少切换模式

　　问题在于，此Web Services中的有些异步功能没有在响应事件警报机制（指示系统规模的变化超过了系统的资源容量）的情况下从松散耦合模式切换到紧密耦合模式的功能。
　
　　规模变化

　　可以在应用程序运行时在后台将资源的容量在高低之间调整。从理论上讲，在容量高时，松散耦合Web Services将等待消息队列服务器的响应。实际上，在Web Services等待发送或接收消息时，消息队列资源要么稀缺要么不稀缺。

　　耦合切换

　　为了让特定Web Services响应规模的变化，请考虑能够在事件警报机制触发时（其对应资源达到了特定的级别）从松散耦合切换到紧密耦合的Web Services 。在进行切换时，资源可以在Web Services需要时动态分配，在不需要时将其收回。

　　WS-Addressing

　　当Web Services紧密耦合时，应该在关闭WS-Context的情况下通过ReferenceProperties打开WS-Addressing EndpointReference。WS-Addressing会话模型提供了Web Services端点信息和会话数据间的耦合，这与分布式对象系统中的对象引用类似。

　　WS-Context

　　当Web Services从松散耦合模式进行切换时，应该打开WS-Context并关闭WS-Addressing。WS-Context提供了一个会话模型，此模型是HTTP服务器和事务系统中的会话模型的进化模型，允许服务客户机更为自然地将关系动态、临时地绑定到服务。

　　测定性能

　　无论您是否计划对某些Web Services进行紧密耦合或重新设计某些现有Web Services，以便能够进行耦合切换，则应该设定一个性能测定目标。为了设置目标，请考虑在网络和应用程序级别要使用的性能标准以及哪些约束可能会影响性能。

　　以下是在设置性能标准时要考虑的一些事项：

　　·每个Web Services接收消息之前等待的最大时间
　　·给定时间内出现的最大时间范围是多长和出现的频率是多少
　　·进行模式切换的时间长度和完成切换过程的时间长度
　　·最大时间范围的频率（例如，晚饭后和周末期间）
　　·Web Services部署后第一个月中的峰值时间
　　·规模变化对SLA中所保证的可用性的影响
　　·在测试过程中和生产中所保证达到的服务可用性的范围

　　所有这些建议都受到各种约束的影响，如SLA、安全处理、测试过程、公司政策和政府法律法规。

　　结束语

　　要考虑Web Services的紧密耦合，您需要一个由开发人员、测试人员、系统管理员组成的团队。您必需事先考虑开发、测试和部署紧密耦合Web Services以及能够切换到紧密耦合模式（以避免稀缺资源系统过载）的松散耦合Web Services的问题。解决这些问题可以帮助完成紧密耦合Web Services的设计、开发和部署工作。您可以使用IBM Rational?ClearQuest?和IBM Rational Functional Tester来减少在企业SOA开发项目中的测试时间、缺陷跟踪时间以及测试实验室成本，从而提高效率。

　　关于作者

　　Judith M. Myerson是一位系统架构师兼工程师。她感兴趣的领域包括中间件技术、企业级系统、数据库技术、应用程序开发、网络管理、安全性以及项目管理。您可以通过jmyerson@bellatlantic.net与Judith联系。