随着 IT 产业日益成熟，我们将目睹越来越多成功的面向服务的体系结构（Service-Oriented Architecture，SOA）的设计和实现的出现。我们同样也将面对以微妙不同的形式重复出现、但从根本上来说却具有相同的基本问题的挑战。我们也倾向于重复使用解决方案的稍有不同的变体。为了达到这一目的，在涉及面向服务的体系结构和面向服务的集成（Service-Oriented Integration，SOI）的项目环境中引出了下面的模式。这些项目专注于面向服务的体系结构的迁移、建模、设计和实现，以及通过服务支持的松耦合集成，这称为面向服务的集成。在这个系列中，我们将分享这些模式以及使用它们的经验。我们将就如何结合使用它们以便帮助解决在 SOA 和 SOI 的迁移、建模、设计和实现过程中通常会遇到的问题提供指导。
引言：SOA 采用和 SOA 方法
单一的 SOA 解决方案很少恰好合适，理解这一点变得日益重要。相反，应该根据组织的方法和成熟度来量身定做 SOA 解决方案，以便确保一条更平坦的采用和成功之路。SOA 的采用分四个层次，正如下面的表 1 中所确定和解释的。
在采用和结合面向服务的体系结构 (SOA) 方面，企业可能处于不同的成熟度。一些企业仅仅是刚刚开始探索 SOA 的世界，使用其技术范例：Web 服务。它们将遗留功能包装起来，再向第三方、客户和业务伙伴公开以供调用。这就把它们带入了这场游戏：逐渐建立起开发团队，开始改变企业文化以便更好地支持 SOA 的流程，并且在探索新技术和可能受到影响的业务能力方面迈出第一步。这是第一个层次。
SOA 采用的第二个层次是在成功地通过 Web 服务的最初测试后，现在这个组织开始使用服务来集成系统和应用程序。这一步超出了企业应用程序集成（Enterprise Application Integration，EAI）。随着专有协议、粘接代码 (glue code)、更加开放的点到点连接、基于标准的协议和基于每个系统外化的服务描述的交互的出现，我们步入了面向服务的集成的领域。在这一领域中，企业服务总线占据最重要的位置：在不必考虑目标服务的提供者的情况下协调、路由和转换服务调用的机制。它有助于克服与点到点连接有关的许多缺点。
表 1. SOA 采用的层次
|
采用层次
|
名称
|
描述
|
| 1 |
实现单独的 Web 服务 |
由新的或现有的应用程序中所包含的任务来创建服务 |
| 2 |
业务功能的面向服务的集成 |
通过跨企业内外的多个应用程序集成服务来实现业务目标 |
| 3 |
整个企业范围的 IT 转换 |
支持跨整个企业的业务功能的集成的体系结构实现 |
| 4 |
随需应变的业务转换 |
现有业务模型的广泛转换或者新的业务模型的部署 |
创建 SOA 的六种方法
据说在驾驶飞机时，起飞和降落是最困难的两件事情。您可以使用各种各样的方法模式在飞机跑道上降落，这取决于由天气、交通密度、风速等等因素决定的空中交通控制指导。成功地创建 SOA 同样也有至少六种方法。
一些客户希望从他们的业务流程开始，然后继续开发支持这些流程所需的服务。而其他一些客户在遗留系统中拥有现有的功能，他们希望将其公开给客户、合作伙伴以及服务生态系统。后一种方法的一个重要的变体是，功能是嵌入式的而不能容易地访问，所以需要完成相当数量的遗留转换和组件化，以便将功能提取出来并将其作为服务公开——而它是否将是一个良好的服务则是另外一回事。我们将在另一篇文章“Service Litmus Test”中解决这个问题，并且提出确定是否确实应该公开某些内容的标准。处理 SOA 的另外一种自顶向下的方法是借助模型驱动的体系结构（Model-driven architecture，MDA）工具，以便定义可以生成代码的模型来构建服务。到目前为止，我们已经考虑了两种自顶向下和两种自底向上的方法。
其他项目需要提供对数据及与该数据相关联的状态的访问。这是 SOA 的信息体系结构或者数据体系结构方法。然而，一些项目试图去集成系统，它们更关心的是如何通过消息传递而不是其他什么方式来集成系统和应用程序；没有崇高的业务驱动的理想和合作伙伴对内部流程的访问，只有通过消息传递进行的系统集成的定义。
表 2. SOA 的六种方法
|
方法
|
描述（典型的项目所有者的特性描述）
|
限制条件
|
| 业务流程驱动 |
我的业务流程需要接进资源，而且每个活动都需要调用 IT 功能；我希望该功能能够以一种灵活的、可替代的方式使用。 |
自顶向下 |
| 基于工具的 MDA |
我希望定义一个模型（业务模型），然后由工具为我生成具体细节。 |
自顶向下 |
| 包装遗留 |
我拥有已经进行了大规模投资的现有系统，但是它们不具有可伸缩性。我想要快速地添加新的功能，但是这些系统是分离的。它们就像个地窖，功能封闭在其中。 |
自底向上 |
| 组件化遗留 |
使用基于编译器的工具将整个庞大的遗留系统分解成模块。 |
自底向上 |
| 数据驱动 |
使用服务来提供对信息的访问，而不必在提供者端公开 Schema 或者实现决策。 |
专注于数据 |
| 消息驱动 |
“仅仅希望这些系统通过标准的、非专有的协议进行集成、通信。” |
应用程序和系统的面向服务的集成 |
模式语言背景
概述
随着一个组织在朝更灵活和健壮的体系结构（伴随着快速变更的业务需求）迈进的道路上逐渐成熟，它将做两件事：a）选择专注于一组核心的差异化计划，这些计划以核心竞争力为中心，b）朝级别越来越高的人员、合作伙伴、流程以及数据的松耦合和可动态重组集成的方向前进。请注意，由现有的服务构建复合应用程序来动态重组是关键。通过这种方法，可以在企业内部和外部以可重用的方式公开服务。
当组织开始转向 SOA 时，采用的主要方法之一或者进入 SOA 世界的入口就是通过面向服务的集成 (SOI)。提议这样做的重要价值之一是利用 IT 系统中现有的投资，而不是重新改写/重新编写新的。实际上，服务集成比企业应用程序集成更进一步，将使用最少的“粘接代码”，通过非专有的协议来定义和利用松耦合的服务集。这种方法的关键在于两点，一是将服务作为关键启动程序进行访问，二是生态系统中多个系统甚至业务伙伴之间的数据和处理的交互。
为了使这种 SOI 方法获得成功，而且为了从 IT 系统方面的实际观点出发并逐渐朝着企业中服务演化的方向前进，我们需要克服一些主要障碍或者说挑战。这些问题的涵盖范围看起来非常广泛，从简单的、几乎琐碎的问题，到日益复杂的问题，随着我们在使用和实现 SOA 并获得相应的业务和 IT 好处方面更加成熟，我们将遇到这些必须解决的问题。这里所概述的模式有助于解决这些挑战；每种挑战一个模式。随着我们的研究逐渐深入，我们发现一种趋势——我们正使用更细粒度的模式来构建日益复杂的解决方案，以便解决更加复杂的问题。例如，不是从第一天就立即拥有 ESB，我们可能发现，从一个服务策略开始，创建一些服务适配器和代理，转到虚拟提供者，接着到服务集成器，然后才是 ESB，这样更明智。这些模式的使用将依赖于对项目的实际考虑，您将在不同的项目中有区别地使用它们，正如 Alexander 所说的，“不要以相同的方式做同一件事两次”。
通常，最初的挑战是具体确定在项目、业务部门或者组织内部提议使用 SOA 的价值。这涉及到在实现服务的实际服务提供者的服务质量下降或者他们不能提供所需要的功能时改变实际服务提供者的灵活性和能力。这种灵活性是 SOA 的首要价值，而这种挑战可以通过了解借助远程服务策略获得灵活性的步骤来克服。我们还将描述另外两种挑战，并使用这里提出的模式加以克服。
这些模式构成了模式语言的核心，当您达到 SOA 采用的成熟度的较高级别时，将涉及各种围绕 SOA 和 SOI 产生的问题（如下面的图 1 所示）。通过增加服务集成度的增量采用来迁移到 SOA 的组织一般从具有专有接口和粘接代码的强耦合系统开始，迁移到部分公开的服务之间的点到点连接，而这些服务通常仅仅包装现有的功能并使其可访问。这两点代表了实现 SOA 全部潜能的过程中的前两个步骤。每个步骤都代表更高的成熟度以及在商业价值和 IT 利益方面相应的增加。例如，为了迅速地支持对现有功能的访问，难以访问的嵌入式功能的点到点公开 (Point-to-Point Exposure) 是迈出硬编码地窖的重要一步。这些地窖包含嵌入式并且通常难以访问的功能。组织常常借助于创建在其他环境中本身难以访问的冗余功能，而不是费力地访问难以访问的嵌入式功能。在通常情况下，应用程序组合（换句话说就是，减少）可以通过确定不同系统中的共同功能，提取、隔离并封装最有希望的功能，然后提供单一访问点 (Single Point of Access) 来实现，以便简化维护、降低成本并支持合并和采购期间的快速合并等。
下面的表 3 中提到的模式是从各种项目中“挖掘”出来的 SOA 和 SOI 模式的一部分：
表 3. 模式及其相应的好处
|
环境
|
模式
|
适用性
|
| 封闭；集中的功能 |
硬编码的（不是模式，而是时间状态的一点） |
时间点；低风险；少变化、高性能系统 |
| 分布式的；多点访问 |
点到点公开 |
迅速公开现有的功能；快速释放价值；访问嵌入式功能 |
| 包装遗留的功能，使其可以通过 Web 服务来访问 |
服务适配器 |
用户需要访问不支持服务的功能（通过服务调用访问遗留系统，例如——Web 服务） |
| 如果您不能直接访问服务提供者的服务描述并且不能直接调用服务，那么使用它的代理来访问服务 |
服务代理 |
向使用者提供 SOA 接口 |
| 提供选择服务提供者的灵活性 |
远程服务策略 |
提供根据服务质量或者功能考虑事项改变服务提供者的灵活性。这使得在合并应用程序组合时加速合并和采购以及灵活地改变提供者成为可能。 |
| 消除冗余的功能；重构和合并或者在某些情况下替换现有的系统 |
单一访问点 |
给功能的许多潜在变体提供一个访问点。一种服务策略通常需要一个单一访问点。 |
| 某一时刻，一个项目或业务部门依赖于其他项目或业务部门的某些尚未作为服务公开的功能 |
虚拟提供者 |
不存在的提供者；提高服务的关键部分 |
| 单一访问点 |
服务集成器 |
路由、转换 |
| 常规企业集成方法 |
企业服务总线 |
中介；路由；转换、策略、规则、事件；在生态系统/价值网中的组织内部或者合作伙伴之间 |
| SOA 的涅磐 (Nirvana of SOA)；通过依赖于业务领域特定的功能的环境识别服务进行动态重新配置 |
集成的服务生态系统 |
向一组语义相关的行业特定的业务合作伙伴提供动态配置功能，这些合作伙伴利用并重组生态系统的功能来给自己以及作为一个整体的生态系统提供更大的价值 |
对于给定的情况，下表中的每个点都可能是合理的或适当的，向图谱的右侧移动并不总是要做的正确事情或者要采用的解决方案。级数表示逐渐增加的成熟度以及需要更多的成熟来处理不断增加的复杂性和克服 IT 所经受的新的、更加令人生畏的业务挑战。
图 1. 迈向集成的服务生态系统的 SOA 和 SOI 的模式图谱上的点
下面的部分将介绍一些构成 SOA/SOI 的模式语言基础的基本模式。“基本的”的意思是指客户往往首先碰到与这些模式有关的问题，需要解决它们，以便在 SOA 的方向上继续前进。SOA 是一个渐进的、小的转换旅程，逐渐将服务描述从由多个服务提供者所提供的服务实现中分离开来。下面的解决方案描述了这些问题是如何循环地解决的，并且可以作为模式用于下一个项目，以助您一臂之力。就像任何其他模式一样，这些模式同样也需要调整以适合环境和形成您个人的问题空间的强制要求：项目的利弊和需要考虑的事项，无论它们是组织上的还是技术上的，都非常重要，而且您可以决定是否需要跳过从一个模式到另一个模式的步骤，或者部分地实现该模式。
模式的讨论和模式的环境
大部分组织都有多种异构后端遗留系统，而只支持投资其中的一些来参与 SOA。通常，组织分为多个业务部门，其中每个业务部门都可能拥有整套系统的一部分，并且不能控制支持单一业务流程的一组水平应用程序。因此，业务流程可能跨越多个业务部门，涉及不同的系统所有者。每个系统将支持（用来更新或者创建）业务流程的一部分。在这个端到端流程中，并不是每个参与者都有机会获得资助，或者同意进行 SOA 迁移，或者适时地这样做。因此，一个组织单位决定将其功能迁移到 SOA 并不意味着其他提供依赖功能的业务部门或合作伙伴同意这样做，注意到这一点非常重要。
因此，在初始阶段，向 SOA 迁移的努力包括组织必须克服的学习和集成曲线。例如，SOI 模式虚拟提供者有助于为此搭桥铺路。企业可以利用、更改或者加强现有的基础设施、系统、管理和策略，以增量的方式迁移到 SOA，从而克服这些问题。服务提供者可能依赖于一组由生态系统中其他业务部门或组织提供的外部服务。这些服务在特定时刻可能并未准备就绪，或者不满足服务质量要求。虚拟提供者模式可以帮助解决这个问题，它允许期望的提供者在服务使用者端创建 SOA 以及在服务提供者端创建服务的虚拟提供者。它所依赖的任何一个系统都有可能还没有准备好就完全地迁移到 SOA。在过渡时期，服务使用者可以使用虚拟提供者来前进、构建 SOA，并且一旦提供者的服务的实际 SOA 实现开始工作，就可以通过服务策略链接到提供者的服务。虚拟提供者就绪后，在 SOA 中创建集成层就变得更加容易了。接着您就可以应用服务集成器来更好地充实这个层次。集成层的完备和好处是伴随企业服务总线的创建而获得的。
[远程]服务策略可以单独使用，也可以与其他两个主要的模式一起使用。这个模式从本质上来说模仿了多态的概念，将其用于服务，并且具体化了策略设计模式（但不是从面向对象的角度）。实际上，它适用于远程调用的面向服务的领域，在这个领域中，需要允许灵活地重新分配和迁移到新的端点，从服务使用者角度来看，这可以以一种更经济、可伸缩、可兼容且一致的方式提供服务。因此，当使用者需要更改非功能性需求时，或者当当前的提供者偏离了想要的交付功能性或非功能性需求的方法时，可以使用服务策略重新分配其他的服务提供者作为服务端点，这种方式对应用程序和基础设施的改变最少。本质上，您从一组更保守的不成熟的 Web 服务转移到一个具有单一访问点的更成熟的 SOA，从而消除了冗余，提供了一致性的注册中心、储存库和代理。请注意，我们并没有选择术语“网关 (Gateway)”，虽然它可能是一个更合适的词，但这里的意思是指在这个领域开发的产品，例如 Web Service Gateway 产品。在这里，我们专注于业务功能的统一访问点的功能性方面。
所以，如果您问，“为了通过服务集成到达 SOA 的最终状态，究竟什么才是基于服务总线增量迁移到立体集成（层）体系结构的跳板呢？”第一种模式从灵活性的角度讨论了 SOA 的价值。第二种模式是关于创建关键部分来启动您的 SOA 并使其在企业中运行。而第三种模式是关于将虚拟提供者带到下一层，作为服务集成器。您迟早都会希望将实现再向前推进一步，即 ESB。
这里我们描述了为了实现这个目标您可能需要采取的步骤。请注意，在某些情况下，如果组织的文化和工具、技术以及中间件都就绪，那么您可能直接就到了 ESB。对于组织中更成熟的部分这可能也是可行的，而应用程序的某些部分则需要您手动操作，通过这里所描述的模式小心翼翼地将其逐步迁移到其他选定的部分。
模式 1：远程服务策略
环境和问题：这是策略设计模式的变体，可以在 SOA 的体系结构环境中应用。它处理与松耦合有关的问题，并在我们希望根据例如输入环境或者不同服务提供者能够提供的服务质量特征灵活地改变服务实现时使用。纯粹的面向对象的策略模式主要依赖于基于继承的多态来创建根据环境交换的可互换算法系列。在 SOA 环境中，我们需要的不是拥有一个对象层次结构，而是能够改变服务提供者，同时将对使用者的服务感知的影响降到最低程度或者根本没有影响，从而改变服务描述的实际实现者。在大部分情况下，实现者可以是内部网或 Internet 上某处的远程功能单元的提供者。因此，例如，可能需要改变 OrderEntry 应用程序中的 VerifyAddress 服务的服务提供者，因为出于更大的交易量或者安全约束的原因，我们的服务质量需求发生了改变。或者，提供者已经决定将我们过去所依赖的同一基本服务的价格提高一倍。现在，我们希望能够在 IT 和业务不受损害的情况下灵活地改变服务提供者，这就意味着将对 IT 系统的改变降到最低程度并且不对业务或者客户的在线购物体验造成影响。
图 2. SOA 提供的灵活性
在许多情况下，服务提供者是远程的，而绑定到实际实现者是通过 Web 服务绑定（WSDL 接口的 SOAP 调用，可能发现或预设为一个给定的 URI）来实现的。
解决方案：不是将访问和通信机制硬编码到服务提供者，而是创建一个服务层将您所需要的服务接口从可能的服务实现者层——例如企业组件层 (Enterprise Component Layer)——分离出来。这就提供了改变实现服务接口的服务提供者的灵活性，同时又不必对 IT 系统的代码做大的改变。“重新配置”，而不是硬编码的自定义，是这个策略的名称：提供灵活性的可动态重新配置的体系结构样式正是提议 SOA 的关键价值之一。
图 3. 显示远程服务的可选策略
结果和变体：实现这个模式有不同的程度。您可以从更高的耦合度开始，然后迁移到较低的耦合度。URI 没有硬编码到现有服务提供者的 WSDL，这就可以通过创建提供者的服务注册中心和动态改变提供者（UDDI 和 LDAP 等等）来获得改变提供者的能力。如果需要更进一步的动态程度，那么发现和协商流程就会出现在注册中心，它并不受您的控制，而是由外部服务代理提供，这个服务代理将为您找到“最合适的”或者“最匹配的”的服务。
请注意，这里需要标准化的语义，以便方便地改变服务提供者。幸运地是，在多个行业的不同业务领域中出现了一套标准，它们可以构成在更复杂的场景中改变提供者所需要的语义的基础。
模式 2：服务适配器
（也称为服务包装器）
环境和问题：服务适配器的目标是提供使非面向服务的系统能够参与到面向服务的体系结构之中的机制
这样的服务通常都是不能提供 SOA 所指定的清晰定义的、大粒度的接口类型的遗留系统或打包的应用程序。这常常是一个反复出现的问题，因为现在许多核心业务流程都是由长期建立的系统来支持的，它们可能使用并不属于 SOA 的主流的技术，并且可能非常复杂，因此不容易改变。所以，虽然它们可能是 SOA 中重用的好的候选者，但是需要做一些工作来向其提供基于服务的访问。在某些情况下，供应商提供服务适配器，这就使工作更容易了（例如，用于 CICS 的 Web 服务）。
为了向遗留系统提供包装器服务，需要某种形式的适配器技术或者“服务适配器”。这项技术的目标是与非 SOA 的系统集成，并应用所需要的任何数据或协议转换来公开表示遗留功能的清晰的服务接口。这个接口是作为“包装器服务”发布的。然后，服务使用者就可以通过该适配器绑定到包装器服务了。
图 4. 服务适配器
随着我们需要从适配器获得更多的智能和功能，我们开始需要这个语言中的其他模式。所以，有时仅仅编写包装器就足够了。而有时就需要更多的变体和智能来将一项功能引入 SOA，这取决于我们是否确实拥有它、它的性能特征是什么，等等。
结果：可以更改应用程序或者遗留代码，以提供清晰的接口。当代码的容器（例如，CICS）支持适当的技术（例如，CICS SOAP 支持或者支持 XML 和消息传递技术）时，这种模式可能特别合适。
应该考虑的其他事项：
- 显式适配器的使用，是定制的还是打包的（例如，Java 2 Connector 或 WebSphere Business Integration Adaptor）。
- 更通用的中间件的使用。例如，EAI 技术，比如代理，可以提供更集中的能力来执行用于多个应用程序或者遗留系统的适配器功能。
- ESB 的使用。如果使用 ESB，并且 ESB 具有类似于 EAI 的集成能力以及协调服务请求的能力，那么它就可以执行用于多个应用程序或者遗留系统的适配器功能。
模式 3：服务代理
环境和问题：使用者并不具备直接支持服务或者使用 WSDL 调用服务的能力。然而，您需要给他们提供使用与某个将来的提供者提供的特定服务相关联的功能和服务质量的机会。请记住，或许现在这个提供者并没有将这项功能作为 Web 服务来提供，而是以遗留的形式提供，并计划将来进行迁移。服务的提供者可能还不具备公开服务的能力。
强制要求：如果候选提供者提供的服务功能还没有充分地准备好，那么您可能仍需要提供服务的句柄，即使实际的 WSDL 和支持 Web 服务的技术还没有就绪。
解决方案：为了对使用者屏蔽使用服务接口访问功能所需要的复杂性，作为跳板，您可以选择向客户机提供服务代理，作为将来支持 SOA 功能的代理。
这个模式可以与服务适配器一起使用来支持虚拟提供者。
模式 4：虚拟提供者
您可能准备好了一个（或多个）服务适配器和服务代理。现在，您可以开始构建您的虚拟提供者了。
环境和问题：您与依赖您提供服务的服务使用者处于一个生态系统中。同样地，您也依赖于服务提供者所提供的服务。然而，在现实世界中，这个生态系统是逐渐发展的——并不是所有您需要的服务都可以作为 Web 服务或者通过服务规范使用。您需要开发服务的关键部分来支持您的业务部门、企业或者生态系统。
图 5. SOA 生态系统
强制要求：您希望以服务而不是 API 调用的方式获得您所依赖的现有提供者的功能；但是它们还不能作为服务公开。您需要与潜在的提供者进行协商，以获得所需要的服务，不只是功能上的，还有必需的服务水平协议或非功能性的需求，所有这些都是基于您所提供的服务规范或描述（另外，或许还有服务策略）。您可能会面临挑战，因为提供者可能没有按照您要求的方式提供服务。最终，您可能要面对这样的问题：a）提供者可能没有及时地提供服务来满足您急切的要求，b）他们提供了与您的粒度不匹配的其他功能，或者 c）他们没有提供您所需要的非功能性需求。
您希望有人向您提供服务，但却还没有人做好准备。
解决方案：通过指定您所需要的服务并假定该服务已被提供的方式来创建虚拟提供者。使用代理与遗留系统通信，同时使用适配器将所使用的协议转换为在服务描述/协定中指定的您所希望/需要/拥有的协议，自己创建服务提供者。将代理和适配器封装在虚包 (facade) 中，因为适配器的数量将根据以后需要转换的新系统和新协议随机增长。因此，可以使用虚包封装这组适配器来与现有的 API 进行通信。
图 6. 虚拟提供者 SOA 模式组合虚包、服务代理、服务适配器和规则对象模式来启用支持使用者的服务中的关键部分，即使在生态系统还没有准备好提供所需要的全部服务时
结果：现在您有了以一种适当的递增方式迁移到 SOA 的方法，即使生态系统还未完全做好准备。一旦提供者的服务得以实际创建、发布和提供，并且能够使用，您就可以直接插入到这些服务。但是您不必编写任何新的代码，只需为源自现有的提供者 API 的新协议准备新的适配器即可。
相关模式：即后面提到的企业服务总线，如果中介、路由、转换和策略的规则对象都添加到虚拟提供者的话。
虚拟提供者包括虚包、代理和一个或多个用于目标系统连接类型的适配器。一旦在虚拟提供者中添加了用于路由和策略管理的规则对象，它就成为了服务总线。
需要准备好一些模式来实现虚拟提供者，这涉及到管理。匹配提供的模式表明，中心组织将公平地在两个组织单位之间分配资金，以便资助它们支持和创建各自所需要的服务，而这些服务又不在它们自己的资金预算之内，因为这“仅仅”使其他业务部门受益。请注意，随着组织内中心访问点变得更加普遍，这些问题就逐渐消失了。
模式 5：服务集成器
环境和问题：您正应用虚拟提供者并可能采用远程服务策略来满足业务需求的需要。然而，通过与冗余的后端功能相集成，封闭的遗留系统（自定义应用程序和打包的应用程序）仍是一个挑战。您需要有一个到后端功能的单一访问点，以便能够在新的组合中重组该功能的各个部分，同时需要监视和管理这些新服务。
我们处于服务提供者的生态系统，其中的现有功能通常是脆弱的和特别开发的：连接常常是“一次性的”。集成是专有的和特别的；没有单一访问点来合成服务。
强制要求：当前的系统没有提供具有合适粒度级别的接口。当没有通过服务粒度与业务目标和 IT 系统一致的机制（例如，在 SOMA 方法[1]中的目标服务建模）进行服务建模和识别时，就会发生这种情况。另一种情况就是，服务没有以合适的方式重构，并且没有以无连接的（无状态的）方式公开。因此，集成保留点到点的状态，实现每个新的改变都将引起粘接代码的膨胀。您需要有一个同样也可以利用虚拟提供者和服务策略的健壮且灵活的单一访问点。
解决方案：因此，可以将一个特定的集成层引入服务集成的体系结构中，并通过服务集成器来管理这一层。服务集成器向其他的冗余服务提供单一访问点。
为了简单起见，在实现端的虚拟提供者的环境中，将变体外化为远程服务策略。按照这种方式开始构建从紧耦合的脆弱体系结构到更加松耦合的、可动态重新配置的体系结构的适当转换的基础。
图 7. 专注于由服务集成器管理的集成层
服务集成器负责管理多个集成层，如图 3 所示（层 6）。在服务计算生态系统中，服务集成器允许生态系统的单点集成、监视和管理。这个生态系统在本质上是分形的：这个组织可以在其体系结构的不同领域找到。它从项目层上的组织内开始，再转到业务部门，并涵盖企业体系结构中跨业务部门的各种现有应用程序。这就允许在生态系统中集成两个或多个企业体系结构进行协作。
为了进一步发展通过应用虚拟提供者和远程服务策略模式“启动”的生态系统，现在我们需要合并来自跨多个后端系统和源的功能和服务，并将它们重组为一组内聚功能的内聚单一访问点，以便减少或裁减我们的应用程序组合。通常，这种合并基于多个业务流程合成（编排）。而很多时候，这种编排可能也不是采用松耦合的、外化的技术（如 BPEL）来实现的，因为非功能性需求的成本可能太高了。为了减轻非功能性（操作）的影响，这种合成甚至可能是硬编码的。由于服务合成通过服务集成器接进多个应用程序源，再合并、重组，然后在表示层作为门户提交，因此减少了模式选择/权衡的影响。
图 8. 服务集成器在使用者和提供者之间进行协调
请注意，如果将虚拟提供者作为服务集成器使用，同时我们又在虚拟提供者（服务集成器）中添加了用于路由和策略管理的规则对象，那么它就变成了服务总线。
图 9. 服务集成器 SOI 模式
结果：现在，无论在企业内部还是在企业外部的生态系统中，您都可以监视、管理和迁移功能和服务。您可以集成和重组接进其他外部服务提供者的应用程序、打包的应用程序和其他遗留功能，并为新的服务组合提供单一访问和合成点，它们可能提交到 SOA 的使用者层（例如，表示层）内的门户。
讨论：那么，这与企业服务总线 (ESB) 有什么不同呢？简单地说，我们正在讨论的是可以支持成功地、渐进地迁移到 ESB 之前的状态的跳板。在那以后，就可以创建和利用 ESB 来提供增强的服务功能了。因此，通常我们会看到客户机从硬连接 (hard-wired) 集成开始，然后转到点到点服务集成。虚拟服务提供者和之后的服务集成器提供了向 ESB 增量转换的图谱中的其他两个步骤。
模式 6：ESB
环境和问题：本文所描述的模式阐释了一些常用的技术，以现实的、可递增实现的方式来实际交付一些由 SOA 带来的灵活性的元素。然而，随着组织越来越多地采用跨应用程序、遗留系统、通道技术等等的面向服务的体系结构，支持服务所需要的中间件以及用于支持它们的服务和技术的管理就成为复杂的问题。管理这种复杂性的解决方案的一个重要部分就是提供一个用于服务通信、协调、转换和集成的基础设施。这个基础设施同样也可以作为控制点，将服务管理、安全、监视和规范应用于面向服务的体系结构。这种公共的基础设施是由企业服务总线描述的。
强制要求：拥有大量服务的组织将日益需要公共管理和操作模型来进行功能控制，以便：
- 以可管理的方式支持大量的服务交互
- 提供对高级交互功能（例如，事务、存储转发、基础设施服务、安全以及服务质量）的支持
- 支持多种交互方式，例如同步请求/响应、消息传递、发布/订阅以及事件
- 提供与 SOA 原则相一致的健壮的、可管理的、分布式集成基础设施
- 支持服务路由和替换、协议转换以及其他的消息处理
- 同时支持 Web 服务及传统的 EAI 通信标准和技术
解决方案：创建企业服务总线来提供整个组织内的中间件功能，以便支持服务交互。ESB 应该支持这些服务所要求的通信、协调、转换和集成技术，并且应该能够使用公共管理模型来支持地理上分布的部署。下面的图 11 摘自 IBM 红皮书“Patterns: Implementing a SOA using an Enterprise Service Bus”，它阐释了 ESB 的关键特性，其中包括：
- 它作为一个或多个“集线器”组件部署。每个集线器都提供本地化的但又可伸缩的功能来执行路由、转换、安全以及其他功能，常称为“中介”功能。
- 它有名称空间目录和管理服务，用于管理它支持访问的服务。在地理上部署的 ESB 中，管理服务跨协同操作的集线器来维护一致的配置。
- 它有许多入站端口。每个入站端口都配置为使用某个特定的协议（例如 SOAP/HTTP 或 WebSphere MQ）来接收一组地址的服务请求
- 它有许多出站端口。每个出站端口都配置为使用某个特定的协议转发服务请求和接收来自一组地址的响应。
这种配置使 ESB 能够以公共的方式支持跨企业的任意数量的服务的虚拟服务提供者模式和远程接收策略。另外，ESB 可以提供服务请求者和提供者之间的各种安全、数据格式或事务模型的转换。这样，ESB 就成为企业环境中不可避免会遇到的复杂性和异构性的控制及封装点。
图 10. ESB 模式
请参考下面的参考资料中列出的 ESB 红皮书，以获得关于 ESB 模式更多信息。
图 11. 可选视图：作为服务代理的服务总线
可以使用各种技术和产品实现 ESB 模式——特定的实现选择依赖于特定组织的需求。参考资料中引用的 IBM 红皮书包括对 ESB 模式更详细的分析以及使用各种 IBM 软件技术进行实现的指导。ESB 的公共实现技术包括 EAI 中间件（例如，WebSphere BI Message Broker）、Web 服务路由器（例如，WebSphere Web Services Gateway）或者更多使用 CORBA 技术或经由 HTTP 协议的基本 XML 的自定义实现。
讨论：请注意，不仅基础设施必须至少处于任何使用者和提供者所要求的最高级别，而且使用者或提供者本身也必须处于所需的级别。例如，安全和其他非功能的需求是将影响 SOA 的服务质量的点到点的概念。ESB 可以帮助管理服务，但是“管理服务”是更复杂的概念，例如，从 Web 服务的角度来看，管理服务可能不仅仅意味着添加或者删除 JAX-RPC 处理程序，而且还意味着启动/停止、管理服务的名称空间（注册中心）等等。
结束语
可以结合使用这些模式来解决迁移到 SOA 的相关问题。同样在许多情况下，客户需要转到面向服务的集成模型，将其作为在他们的组织中实现更大规模的 SOA 的跳板。使用这些模式可以为客户提供以下几方面的帮助：
- 可以在对现有功能进行最小程度的改变的情况下顺利地迁移到 SOA，同时越来越多地获得日益成熟的 SOA 所带来的好处。
- 支持将他们的包装工作合并到新的 SOA 开发中的功能。
- 使用渐进迁移的策略，没有弃用他们当前运行的系统，因此，不会对向业务客户交付价值和处理他们的需求造成影响。
虚拟提供者通过支持创建服务范式的一流构造来帮助创建服务的生态系统（我将就此单独写一篇文章）。项目的粒度非常重要：较小的项目应该使用服务适配器和服务代理来连接遗留的功能或者不支持 SOA 的功能。如果组织中的某个业务部门决定标准化 SOA，那么它应该考虑创建虚拟提供者。或者，如果在企业层有一个项目跨多个业务部门（如付款处理服务或定价服务），那么创建虚拟提供者作为迈向创建服务总线的第一步是恰当的（这包括构建想要的功能的服务适配器，如果您希望作为服务访问该功能，则应该向服务使用者提供服务代理）。如果出于性能或者安全方面的考虑，您希望嵌入访问，那么您只需要一个服务适配器来访问这项功能。实现这项服务的企业组件将需要这样的适配器，以便能够调用这项功能。但是不必将它作为服务向其使用者公开。只有那些不得不向提供者的使用者公开的服务才需要有服务代理或请求处理程序。
随着组织发展到使用和采用 SOA 的更高的成熟度，它们将开始迈出内部系统的边界，超越与少数合作伙伴的点到点零星集成，进入到要求新的功能的服务生态系统。这些功能之一就是我们上面概述的模式，它们帮助使体系结构进入到服务生态系统的领域中。其他的功能包括面向服务的企业体系结构（service-oriented enterprise architecture，SOEA）、面向服务的建模和体系结构方法（service-oriented modeling and architecture method，SOMA)、面向服务的引用模型 (service-oriented reference model)（如图 7 所示）、管理，以及确保服务生态系统内重组的灵活性所需的模式。