随着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 所示）、管理，以及确保服务生态系统内重组的灵活性所需的模式。

　　关于作者

　　Ali Arsanjani博士是一名高级技术人员，担任IBM Global Services的SOA and Web Services Center of Excellence的首席架构师。他有21年IT行业经验，致力于为大型系统设计和交付分布式软件体系结构。他的研究兴趣和写作领域包括软件设计模式、软件体系结构、基于组件和面向服务的体系结构，以及面向语法的对象设计。他专长于构建可重新动态配置的软件系统。