内容


SOA 中的紧密耦合 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 开发项目中的测试时间、缺陷跟踪时间以及测试实验室成本,从而提高效率。


相关主题

static.content.url=http://www.ibm.com/developerworks/js/artrating/
SITE_ID=10
Zone=SOA and web services
ArticleID=294807
ArticleTitle=SOA 中的紧密耦合 Web Services
publish-date=03132008