SOA中的紧密耦合WebServices.PDFVIP

SOA 中的紧密耦合 Web Services Judith Myerson (jmyerson at ) 系统工程师兼架构师 Freelance Developer 2008 年 3 月 13 日 了解紧密耦合与松散耦合 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 的耦合情况如何能从松散耦合切换为紧密耦合。 ?? 应该使用何种标准来测定性能。 ?? 对测定有何约束。 紧密耦合与松散耦合的对比 大部分大型的复杂系统都作为大型子系统的小型集合构建，而不是采用小型独立子系统的大型集合 的方式形成。这是因为在将系统分解为相对独立的小型组成部分时，可能无法提高性能、安全性、 ? 版权所有?IBM 公司?2008 SOA 中的紧密耦合 Web Services 商标 第 1 页，共 6 developerWorks? /developerWorks/cn/ 经济效益或无法获得其他主要的特征。大型系统的紧密耦合特征通常是通过优化总体设计和尽可能 减少系统组件间的冗余和低效情况来实现的。这会导致系统的组件间的耦合更为紧密以及大量重要 的相互依赖关系。 系统的组件间紧密耦合的一个缺点是，单个组件内的故障可能会导致整个系统无法使用。松散耦合 的 Web Services 可以视为更好的替换方法；只要提供了备用的故障转移 Web Services ，某个 Web Services 的故障就不会让整个系统无法使用。 您可以更改松散 Web Services 中的细节，只要更改不会影响所调用的 Web Services 的功能即可。紧 密耦合系统可能很难维护，因为一个系统子组件中的更改通常需要立即对其他子组件进行调整。 与客户机与服务之间采用紧密耦合的情况（会尽可能减少冗余）不同，松散耦合 Web Services 需要 大量的冗余。侦听 Web Services 和请求 Web Services 可能彼此不信任。这意味着必须添加安全和信 任标准来让侦听方和请求方彼此信任。另一方面，紧密耦合的调用和被调用系统会假定双方都已经 拥有了让对方信任所需要的事项。 为什么对 Web Services 使用紧密耦合？ 无论资源是否稀缺，Web Services 都通常采用基于消息的松散耦合方式；在进行进一步操作（如果 有）之前，它们会通过消息队列等待回覆，并将此作为下一步操作的依据。其优势在于，采用传递 消息的方式，而不是进行方法调用，从而提供了发送和接收 Web Services 之间一定程度的独立性。 如果大量