概念:服务组合和编排
此概念描述可组合服务以产生组合和协作结构从而提供面向业务的更高级新服务的方法。
关系
主要描述

简介

面向服务的体系结构(SOA)的一个重要特点是服务是可编写的,这意味着新服务经常是通过一组现有服务之间的协作编写的。在许多方面,对于现有的基于组件和面向对象的技术是这样操作的,除了用于开发面向服务解决方案的中间件中的特定功能允许通过 Web Service 的业务流程执行语言(BPEL4WS、WS-BPEL 或只是 BPEL)等标准直接执行这些协作。正是该功能编写了服务结构,即定义服务之间使用的依赖关系,并编写构成基于服务的体系结构和吸引众多组织的 IT 策略的服务行为。

越来越多的组织开始意识到需要提高响应业务环境变化的能力和灵活性,不论这种压力是来自全球化、新市场和渠道,还是仅仅来自能更有效地使用技术的新竞争对手。这些组织正期待面向服务的开发和面向服务的解决方案作为组织其 IT 资产满足当前需求的一种方法,并提供了可以复用、重新配置、有效并高效地重新组合来满足将来需求的业务功能基础结构。

能以该方式编写服务的另一特点是它提供了一种灵活的方法,可将现有的 IT 资产以新资产的方式整合到新的解决方案中。例如,现有资产,即使那些为大型机平台和类似平台开发的资产,可以作为一些中间件产品的服务显现,并作为使用 J2EE、IBM WebSphere 或 Microsoft .NET 开发的新服务进行集成。不幸的是,大多数现有的资产往往不是使用符合我们用于新服务的许多原则的接口开发的。因此,有效的做法是创建组合服务,这些组合服务不仅合并现有服务,而且提供不同的、更针对业务的接口,这些接口通过聚集和编排现有的功能来利用它们提供更高级的功能。

服务编排

让我们简单看看术语编排。这个术语用于许多中间件产品,表示受管执行某些脚本,这些脚本表示参与者是服务、任务是消息交换的流程。在一些产品中,使用了配合这个术语。虽然一些业内分析人员和技术人员描述了这两个词含意上的差别和这些术语的标准用法,但大多数用户更感兴趣的是它们的相似之处而不是差异。

按照标准,代表 Web Service 编排的常用方法出现较晚,是在大多数领先的中间件供应商引入专有解决方案之后才出现的。当前业内标准是用于 Web Service 的业务流程执行语言(BPEL4WS 或 BPEL)。关于 BPEL4WS 的更多信息,请参阅 OASIS WSBPEL 站点IBM BPEL 站点

作为组合结构的服务

用递归方式可以很容易地根据其他服务提供的功能来开发服务,如下图所示,其中,服务可以确定它们所依赖的那些服务。在这种情况下,组合服务使用的是订单输入和电子数据交换(EDI)网关服务。当服务功能的一般因素确定可以在多个环境中提供的公共功能时,通常将使用组合服务。 对于某些服务,当角色不仅仅提供基础结构功能(如下面的 EDI 服务)时,这是比较容易确定的。在其他情况下,详细的服务协作将确定是否需要将一个候选服务分为多个实际服务。

文本内容中所述的图。

组合服务的一种重要用法是提供现有(旧)资产实现的功能。在大多数情况下,这样的功能将通过资产本身提供的接口或 API 来访问,并将开发一个通过某种逻辑依赖于这些资产的新服务。另一方面,要允许聚集组件更灵活地演进,并允许现有资产将来由于不同的实施被替换,可以使用另一策略。在这种情况下,每个现有的功能都显现为独立的服务,然后组合服务将使用这些服务,使现有资产和组合服务都能独立演进。

组合服务的另一种用法发生在组合服务利用的实际服务集合事先未知时。例如,在订单管理服务的情况下,我们可能发现需要将订单验证分为一组独立的业务规则服务,以便将来可以添加新的规则。 这与服务协调的主题有关(请参阅指南:服务协调)。

显然,这样的方法有优点也有缺点。如果低级服务只能通过 SOAP/HTTP 之类的因特网协议显现,则与通过本机 API 或接口访问相比,其可靠性和性能可能会较低。这些权衡必须属于作为任何服务设计的一部分所作出和记录的一组通用体系结构决定。

有关现有资产访问以及候选服务与实际服务之间关系的更多信息,请参阅活动:现有资产分析

服务协作

对组合服务的行为进行建模时,我们在确定和设计阶段使用了工件:服务合同的概念。

  • 活动:现有资产分析期间,我们使用协作作为工具来描述候选服务的角色和职责。 例如,我们可能发现需要将订单验证服务和订单管理服务分离,但是它们如何通信?它们又负责什么信息呢?服务协作被用作工具来描述这种通信,我们能确定结果模型所需的消息交换。
  • 任务:服务规范期间,我们使用协作来定义给定服务的具体行为或对服务的操作。例如,可将以上的订单验证示例具体描述为将一组消息发送到一组验证规则服务。

这样,我们可以看到服务设计任务中的服务协作与 Web service 术语中的编排概念直接相关。它代表可配置、具体化的流程描述,将服务之间的一组消息交换进行排序。在大多数中间件实施编排中,该流程被描述为一种 XML 语言,如 BPEL。该流程本身用 UML 2.0 活动或交互描述时,这类语言可以从工件:服务模型中描述的服务协作中生成。

协作包括一个组合结构,该结构提供协调程序及其连接的视图,以及表示交换的消息及其顺序的行为。显示组合提供者的上图展示了一个组合结构,正如以下的订单验证图所示。

文本内容中所述的图。

如下图所示,这不是验证提供者本身的结构,而是服务协作的结构。

文本内容中所述的图。

指定服务行为

如以上所述,通常使用 UML 2.0 活动或交互(尤其是时序图)来描述协作中各服务之间的消息流。下图为 UML 2.0 活动图,说明订单验证服务的行为。对于给定订单,验证注册服务提供了要调用的实际验证操作的列表。

文本内容中所述的图。

请注意,根据对服务的需求,可为整个服务或为每个操作标识这种行为。在此情况下,协作中的活动与验证操作(通过 UML 2.0 中的指定/方法关联)有关。

指定服务绑定

如上所述,将用于服务间通信的绑定(实际物理协议和消息编码)标识为组合视图中的工件:服务通道的属性。在服务之间使用的实际绑定对诸如性能、可靠性和安全性之类的非功能需求有重要影响。 所以,对可用的选择应该记录在整个系统体系结构中确定的每种选择的后果。例如,工件:服务分区的一种用途可能是代表分区中服务间可允许或必需的绑定 - 常见需求是某个逻辑区域内的服务使用高性能但专有的绑定进行通信,而区域外的服务使用低性能但标准化的绑定进行通信。

常见的问题是:Web 服务性能、可靠性和可伸缩性所要求的功能是否可由基于 HTTP 和 SOAP(一向很慢而不可靠)的体系结构提供。 首先必须定义“慢和不可靠”,然后必须意识到,即使可靠的传输也依赖于不可靠的方法。例如,在使用 SOAP over HTTP 时,总有可能构建应用程序级的协议和交互,这些协议和交互提供消息确认和安全性的其他功能。 但是,如果要考虑某些服务在相同的安全性或应用程序环境中进行通信,我们可能会考虑使用非 HTTP 方法。

很重要的一点是要意识到,即使 Web 服务会展示简单的模型和一套简单、灵活的协议,您也不一定要使用这些选项。 正如 WSDL 已经有针对 SOAP 和 HTTP GET/PUT 的绑定一样,向请求程序提供其他选项也是很重要的。 例如,单个服务可能会使用消息队列绑定和 SOAP 绑定来显示消息,这样请求程序就可以选择使用更合适的绑定。 在这种情况下,供应程序可能还会提供激励因素,例如,如果使用了消息队列但没有对 HTTP 对话保证任何服务,就会提供有保证的服务级别。

通过上述订单验证的示例,我们可以了解绑定如何与构造型工件:服务通道关联并显示在下图中。

文本内容中所述的图。

构建和设计企业级解决方案时,我们必须始终记住功能需求和非功能需求,并确保作出正确的权衡和决策来支持业务目标。