售后服务理解面向服务的体系结
构中企业服务总线场景和解决方
案
理解面向服务的体系结构中企业服务总线场景和解决方案
第 1部分
企业服务总线中的工作角色
RickRobinson（rick_robinson@）
IT架构师,IBM
2004年 7月
本文确定了一组最低功能，可以满足企业服务总线（EnterpriseServiceBus，ESB）与面向服务的体系
结构（service-orientedarchitecture，SOA）的原则保持一致的基本需要。通过确定这些最低功能，
您可以确定利用何种现有技术来实现支持 SOA 的 ESB。通过考虑特定情形下的需求如何确定对额外功
能的需要，您可以选择最适合这种情形的实现技术。
引言
最新的 IT 集成是使用 Web 服务技术实现面向服务的体系结构（SOA），有许多优秀的文章讲述了该技
术的好处和相关的实践（请参见参考资料）。最近，企业服务总线（EnterpriseServiceBus，ESB）的
概念被表述为 SOA基础架构的关键组件（请参见参考资料）。然而，有必要阐明 ESB究竟是一个产品、
技术、标准，还是别的什么。特别是，当前是否可以构建 ESB？如果这样，该如何构建？
本文将 ESB 描述为由中间件技术实现并支持 SOA 的一组基础架构功能。ESB 支持异构环境中的服务、
消息，以及基于事件的交互，并且具有适当的服务级别和可管理性。为了达到此目的，需要将多种功
能集中起来并加以分类。然而，并不是 ESB能够传递值的每一种情形都需要所有的功能。
本文确定了一组最低功能，可以满足 ESB与 SOA的原则保持一致的基本需要。通过确定这些最低功能，
您可以确定利用何种现有技术来实现支持 SOA 的 ESB。通过考虑特定情形下的需求如何确定对额外功
能的需要，您可以选择最适合这种情形的实现技术。
在接下来的文章中，我将在 SOA 中定义一组 ESB 场景，以定义 ESB 或 SOA 实现的共同起点。而解决方
案模式又为选择适当的实现技术提供了指南。
随着 ESB 解决方案的发展和成熟，它所需要的功能也在不断地发展。同样，可见的 ESB 产品的可用性
和功能也日趋完善。因此，在本系列的最后一篇文章中，我将考虑 SOA和 ESB的发展路线，以指导 ESB
功能和技术的最初应用，并且阐述如何选择循序渐进的方法。
ESB在 SOA内的工作角色
虽然我不打算深入讨论 SOA 的定义（请参见参考资料），但是在这里概括一下大部分对 SOA 的描述所
适用的原则是很有用的：
利用显式的与实现无关的接口来定义服务。
利用强调位置透明性和可互操作性的通信协议。
封装可重用业务功能的服务的定义。
图 1 说明了这些原则。注意，虽然 Web 服务技术非常符合这些原则，但它并不是唯一符合这些原则的
技术。
图 1:SOA的原则
为了实现 SOA，应用程序和基础架构都必须支持 SOA 原则。启用 SOA 应用程序涉及到创建服务接口，
服务接口可以直接也可以间接地通过使用适配器用于现有的或新的功能。从最基本的级别来看，启用
该基础架构涉及到规划功能来将服务请求路由和传递给正确的服务提供者。然而，基础架构支持在不
影响服务的客户端的情况下由另一个服务实现替代原有的服务实现也是至关重要的。这不仅需要根据
SOA 原则指定服务接口，而且需要基础架构允许客户端代码以独立于所涉及的服务位置和通信协议的
方式来调用服务。这样的服务路由和替代是 ESB的许多功能中的一部分。
ESB支持这些服务交互功能，并提供集成的通信、消息传递以及事件基础架构来支持这些功能。因此，
它将当今正在使用的主要企业集成模式组合成一个实体。ESB 为 SOA 提供与企业需要保持一致的基础
架构，从而提供合适的服务级别和可管理性、以及异构环境中的操作。
本文剩余部分将讨论 ESB 在 SOA 中的角色，包括它提供的除了基本的路由和传输以外的功能，如下面
的 ESB功能模型部分中所述。
ESB结构
ESB 有时被描述为分布式基础架构，这与其他的解决方案形成了对比，比如消息代理技术一般被描述
为中心辐射型（hub-and-spoke）。然而，这并不是真正的差别。正在研究两个不同的问题：控制的集
中和基础架构的分布。ESB和中心辐射型（hub-and-spoke）解决方案都集中控制配置，比如服务交互
的路由、服务命名等等。同样，这两个解决方案可能部署在简单的集中式基础架构中，也可能采用更
复杂的分布式方式进行部署。图 2展示了这一点。
毫无疑问，不同的技术对它们所支持的物理部署模式有不同的约束——有些可能适合于非常广泛的分
布，以支持在很大的地理范围内进行的集成，而其他的可能更适合于部署在本地群集中，以支持高可
用性和可伸缩性。使物理分布需求与候选技术的功能相匹配是 ESB 设计的一个重要方面。另外的一种
能力也是非常重要的，就是以增量方式扩展最初的部署来反映不断变化的需求、集成附加的系统或扩
展基础架构的物理范围。
图 2:分布式 ESB基础架构的集中控制
我还应该定位在 SOA 基础架构中 ESB 与其他组件之间的关系，特别是与 ServiceDirectory、
BusinessServiceChoreography、以及 Business-to-Business(B2B)Gateway 这些组件之间的关系。由
于上述 SOA 原则对这些组件并没有严格的要求，所以我们可以将它们视为可选组件。图 3 展示的 SOA
说明了这些组件之间的关系。
图 3:SOA中的 ESB角色
ESB 需要某种形式的服务路由目录（serviceroutingdirectory）来路由服务请求。然而，SOA 可能还
有单独的业务服务目录（businessservicedirectory），其最基本的形式可能是设计时服务目录，用
于在组织的整个开发活动中实现服务的重用。Web 服务远景在业务服务目录和服务路由目录的角色中
都放置了一个 UDDI目录，因而使得可以动态发现和调用服务。这样的目录可以视为 ESB的一部分；然
而，在这样的解决方案变得普遍之前，业务服务目录可能与 ESB是分离的。
BusinessServiceChoreographer的作用是通过若干业务服务来组合业务流程；因此，它将通过 ESB调
用 服 务 ， 然 后 再 次 通 过 ESB 将 业 务 流 程 公 开 为 客 户 端 可 用 的 其 他 服 务 。 然 而 ，
BusinessServiceChoreographer 在编排业务流程和服务中所扮演的角色确定了这种业务工作流技术
是一种与基础架构技术 ESB分离的技术。
最后，B2BGateway组件的作用是使两个或多个组织的服务在受控且安全的方式下对彼此可用。这有助
于查看这些连接到 ESB 的组件，但它们并不是 ESB 的一部分。虽然有一些网关技术可以提供适合于实
现 B2BGateway 组件和 ESB 的功能，但是 B2BGateway 组件的用途是将其与 ESB 分离。事实上，这种用
途可能需要附加的功能（如合作伙伴关系管理），这些功能不是 ESB 的一部分，并且不一定受到 ESB
技术的支持。
ESB的功能模型
表 1 对现有文献中确定的一些 ESB 功能进行了总结和分类（请参见参考资料）。虽然有一些功能非常
基础，但是其他的功能（如自动化功能或智能化功能）代表着向按需操作环境转变的重要步骤。重要
的是认识到，当前的大多数场景只需要部分类别中的部分功能。ESB 实现所需的最低功能将在下面支
持 SOA的最低功能的 ESB实现部分中进行探讨。
表 1：在现有的文献中定义的 ESB功能
通信 服务交互
路由
寻址
通信技术、协议和标准（例如
IBM®WebSphere®MQ、HTTP和 HTTPS）
发布/订阅
响应/请求
Fire-and-Forget，事件
同步和异步消息传递
服 务 接 口 定 义 （ 例 如 ， Web 服 务 描 述 语 言
（WebServicesDescriptionLanguage，WSDL））
支持替代服务实现
通信和集成所需的服务消息传递模型（例如 SOAP
或企业应用程序集成(EAI)中间件模型）
服务目录和发现
集成 服务质量
数据库
服务聚合
遗留系统和应用程序适配器
EAI中间件的连接性
事 务 （ 原 子 事 务 、 补 偿 、 Web 服 务 事 务
（WS-Transaction））
各种确定的传递范例（例如 Web服务可靠消息传递
（WS-ReliableMessaging）或对 EAI中间件的支持）
服务映射
协议转换
应用程序服务器环境（例如 J2EE
和.NET）
服务调用的语言接口（例如 Java
和 C/C++/C#）
安全性 服务级别
身份验证
授权
不可抵赖性
机密性
安全标准（例如 Kerberos和 Web
服务安全性（WS-Security））
性能
吞吐量
可用性
其他可以构成契约或协定的持久评估方法
消息处理 管理和自治
编码的逻辑
基于内容的逻辑
消息和数据转换
有效性
中介
对象标识映射
数据压缩
服务预置和注册
记录、测量和监控
发现
系统管理和管理工具的集成
自监控和自管理
建模 基础架构智能
对象建模
通用业务对象建模
数据格式库
B2B集成的公共与私有模型
开发和部署工具
业务规则
策略驱动的行为，特别是对于服务级别、服务功能
的安全和质量（例如 Web服务策略（WS-Policy））
模式识别
上面的许多功能既可以使用专有技术实现，也可以通过利用开放标准实现。然而，使用不同的技术来
实现 ESB 可能会使它们的性能、可伸缩性和可靠性这些特性显著不同，同时 ESB 功能和所支持的开放
标准也会有所不同。由于这些原因，再加上最近制订和正在兴起的一些相关标准，当今实现 ESB 的许
多关键决策都涉及到成熟的专有技术和不成熟的开放标准之间的权衡。
在本系列文章中，我们不打算详细讨论上面的每一个功能类别。相反，我们将集中讨论采用或实现 ESB
的不同方法之间的驱动策略。特别是在下一部分，我们将讨论 ESB 为支持 SOA 所需的最低功能由什么
构成。
支持 SOA的最低功能的 ESB实现
如果在前面确定的功能中只有一部分和大多数 SOA 场景相关，我们可能会问：实现 ESB 所需的一组最
低功能由什么构成？为此，考虑最被普遍认同的 ESB定义的原理：
ESB是一种逻辑体系结构组件，它提供与 SOA的原则保持一致的集成基础架构。
SOA原则需要使用与实现无关的的接口、强调位置透明性和可互操作性的通信协议、相对粗粒
度和封装可重用功能的服务定义。
ESB可以作为分布式的异构基础架构进行实现。
ESB提供了管理服务基础架构的方法和在分布式异构环境中进行操作的功能。
表 2展示了根据这些原则定义的最低 ESB功能
表 2:最低的 ESB功能
通信 集成
提供位置透明性的路由和寻址服务
控制服务寻址和命名的管理功能
至少一种形式的消息传递范型（例如，
请求/响应、发布/订阅等等）
支持至少一种可以广泛使用的传输
协议
支持服务提供的多种集成方式，比如 Java2 连
接器、Web服务、异步通信、适配器等等
服务交互
一个开放且与实现无关的服务消息传递与接口模型，它应该将应用程序代码从路由服务和传输协议中
分离出来，并允许替代服务的实现。
请注意这些最低功能并不需要使用特别的技术，比如 EAI 中间件、Web 服务、J2EE 或 XML。这些技术
的使用非常接近也非常符合需求，但是不必强制要求使用它们。相反，最低功能几乎只需简单地使用
SOAP/HTTP和 WSDL就可以实现（当然不是所有的情况都这样）：
URL 寻址和现有的 HTTP 和 DNS 基础架构提供了一个具有路由服务和位置透明性的“总线
（bus）”。
SOAP/HTTP支持请求-响应（Request-Response）通信规范。
HTTP传输协议被广泛地使用。
SOAP和 WSDL是开放、与实现无关的服务通信和连接模型。
然而，这些 SOAP/HTTP和 WSDL的基本应用只是点到点（point-to-point）的集成，并不能实现一些 ESB
需要的关键功能：
目前还没有用于控制服务寻址和命名的管理功能。服务名称通过每个适配器单独进行控制的，
服务路由控制则分散在由服务客户端调用的地址、HTTP基础架构和分配给适配器的服务名称之间。
虽然这种方法依赖于实现细节，但是它往往并不能使服务实现的替代变得简单；服务请求者
代码（也可能是开发工具生成的）通常通过特定地址的特定协议直接绑定到具体的服务提供者实现。
如果想要用另一个服务实现来替代原来的服务实现，就需要修改应用程序代码并重新部署这些代码。
当然，在许多甚至是大多数情形中往往需要其他的功能，并且这种需要变得越来越常见。特别地，不
管是现在还是以后，下面的需求类型可能会导致更复杂高级的技术的使用：
服务质量和服务级别功能。
高级 SOA概念，例如服务编排、目录、转换等等。
按需操作环境需求，比如管理与自治功能以及基础架构智能功能。
跨越具有不同所有权的多个网络、多个协议以及多个域的真正意义上的异步操作。
影响 ESB的安全问题
我不想在这里直接提出安全需求，不过它们对选择 ESB 的实现技术非常重要。例如，如果服务请求不
需要提供身份验证或授权，实现技术的选择就可以非常的广泛。更有可能的情况是，如果需要一些安
全级别，则评估什么形式的安全是可以接受的就非常重要。例如：
1. 是否可以接受通信基础架构中的安全性，例如，是否在 EAI 中间件服务器之间使用安全套接
字层（SecureSocketLayer，SSL）互相验证，或者是否在使用 HTTPS协议？
2. 是否可以接受在参与系统之间单独的点到点（point-to-point）安全性，或者是否需要端到
端（end-to-end）模型？例如，是否有必要通过类似于代理的中间件系统来把客户端身份传递到服务
实现的最终提供者？
3. 是否可以接受应用层中的安全性，例如，客户端代码是否能够执行带有用户 ID和密码的基本
HTTP身份验证，或者是否能够把这些信息作为应用程序数据传递给服务？
4. 是否需要遵守行业安全标准，例如 Kerberos或 WS-Security？
虽然所有这些都是可能的，但是行业的发展方向是基础架构和中间件支持的符合标准的安全性（例如
Web服务安全性（WS-Security））功能。然而，相比之下，这些安全标准也是最近才提出的，而且对
它们的产品支持仍在发展的过程中，而不是已经确定了，这里尤其需要特别考虑的就是它们的互操作
性。因此，任何 ESB 架构都需要尽可能早地确定安全需求，以便在选择实现技术时可以将它们包括进
来。
结束语
在本文中，我讨论了大多数通用的 SOA 原则，以及它们与 Web 服务技术的关联。基于这些原则，我提
出了需要一个基础架构组件，这个组件可以提供路由功能，以便使服务能够彼此交互，同时还能够支
持使用另一个服务实现来替换原有的服务实现。这些功能都是通过 ESB实现的。
ESB 在维持集中控制的同时提供分布式的基础架构，因而需要一些形式的服务路由目录，并且还可能
需要业务服务目录。BusinessServiceChoreographer从 ESB调用服务，然后通过 ESB把这些流程作为
新的服务公开。
ESB的许多功能包括提供：
通信
服务交互
集成
质量服务
安全
服务级别
消息处理
管理及自治服务
建模
基础架构智能
从这些不同的功能中，我确定了建立 ESB所需的最低功能，包括通信、集成和服务交互。
在这个系列的下一个部分中，我将讨论一些通用的场景，以及与这些场景相关的解决方案模式，同时
指出影响这些场景最一般的问题。
第 2部分
驱动体系结构的 ESB场景和问题
RickRobinson（rick_robinson@）
ITArchitect,IBM
2004年 7月
在关于企业服务总线（EnterpriseServiceBus，ESB）的这个系列的第二部分中，作者描述和分析了实
现 ESB和其他面向服务的体系结构（SOA）的解决方案的一些常见场景。
这个系列的第 1篇文章描述了企业服务总线（EnterpriseServiceBus，ESB）的基本概念和工作角色。
本文侧重于描述为支持面向服务的体系结构（SOA）而进行的 ESB开发的场景和问题。您的组织的 SOA
和 ESB可能需要应用到一个或多个这样的场景。
ESB场景及分析
SOA 中的 ESB 场景部分描述了许多 SOA 和 ESB 实现的起点。每个场景都指出驱动体系结构和设计决策
的问题，而这些决策会影响解决方案模式的选择（将在这个系列的第 3部分中进行介绍）。在驱动 ESB
体系结构和设计决策的问题部分中，您可以阅读关于这些问题的详细描述。这些解决方案模式代表着
从服务技术的基本使用，到简单的 ESB实现，再到复杂的 SOA体系结构的发展过程。
这些 ESB 场景的目的并不在于展示组织对 SOA 或 ESB 的全部需求。例如，虽然某个场景（如两个系统
的基本集成）可能看起来很好地匹配了特定的当前需求，但是随着时间的推移，这种需求可能发展成
更复杂的需求（如支持一个或多个应用程序实现更广泛的连接性场景。另外，还可能有许多对 SOA或
ESB 基础架构的单独需求会出现这样的情况，就其个别而言符合简单场景，但集中在一起则表现得比
较复杂。
我们需要在实现满足非常明确的需求的解决方案、努力预料未来的需求和定义跨企业的一致解决方案
这三者之间作出选择。将组织的需要看作是总体上相对复杂的场景（如实现具有高服务质量和 Web 服
务标准支持的 SOA 基础架构）可能是比较适合的。另外，还可以将个别的情形单独看作是简单场景，
但是定义最后得到的这些解决方案以后发展成通用体系结构的路线。
SOA中的 ESB场景
下面的几个部分描述了这些场景的特征：
两个系统的基本集成
支持一个或多个应用程序实现更广泛的连接性
支持遗留系统实现更广泛的连接性
支持企业应用程序集成（EAI）体系结构实现更广泛的连接性
实现组织之间服务或系统的受控集成
通过编排服务使流程自动化
实现具有高服务质量和 Web服务标准支持的 SOA基础架构
两个系统的基本集成
场景
企业需要提供用不同的技术（如 J2EE、.NET、CICS等等）实现的两个系统之间的集成。Web服务 SOAP
标准或消息传递中间件可能是候选的集成技术。这个场景的一个重要的问题是，将来是否会出现需要
集成其他系统的情况。一开始就使用可扩展解决方案可能会对未来的需要提供支持；但是必须在为构
建这样的解决方案而付出的额外工作与解决简单的问题的最初需要之间保持平衡。
最相关的问题 相关的解决方案模式（请参见下一篇文章）
1,3,4,6,10,13 使用包装器或适配器来实现基本集成—请参见基本适配器。
或者，想要在将来进行扩展，有以下两种方案：
o 添加控制服务网关。
o 或 者 实 现 一 个 复 杂 的 基 础 架 构 —比 如
WebservicesCompliantBroker 或 EAIInfrastructureforSOA。
支持一个或多个应用程序实现更广泛的连接性
场景
现有的已封装或自定义开发的应用程序（例如客户关系管理（CustomerRelationshipManagement，
CRM）、企业资源规划（EnterpriseResourcePlanning，ERP）等等）可能是用 J2EE 平台或其他应用程
序服务器环境实现的，它们提供的可用功能超出了应用程序本身。以服务的形式公开这些功能的价值
在于，既支持应用程序彼此之间的互操作，也提供对新的通道或客户端的访问。使用可互操作或开放
的标准通信和服务协议看来是今后发展的最佳途径。
最相关的问题 相关的解决方案模式（请参见下一篇文章）
1、2、3、4、6、8、9、
10、11、12、13、14
使用包装器或适配器来实现基本集成—请参见基本适配器。
添加控制服务网关。
或者实现一个复杂的基础架构—比如 WebservicesCompliantBroker
或 EAIInfrastructureforSOA。
如 果 还 需 要 流 程 编 排 （ ProcessChoreography ）， 就 实 现
ServiceChoreographer 或者 FullSOAInfrastructure。
支持遗留系统实现更广泛的连接性
场景
组织对遗留技术（比如 CICS、IMS 等等）进行了大量的投资，以支持为他们提供核心业务事务和数据
访问的应用程序。其重要价值在于提供互操作性或开放标准、以及对这些事务进行基于服务的访问（例
如，查询帐户余额的事务、创建订单、日程安排或交付跟踪、查询库存级别等等）。
最相关的问题 相关的解决方案模式（请参见下一篇文章）
1,2,3,4,7,8,9,10,11,13,14 使用包装器或适配器来实现基本集成—请参见基本适配器。
或者，想要在将来进行扩展，有以下两种方案：
o 添加控制服务网关。
o 或 者 实 现 一 个 复 杂 的 基 础 架 构 —比 如
WebservicesCompliantBroker 或 EAIInfrastructureforSOA。
支持企业应用程序集成（EAI）基础架构实现更广泛的连接性
场景
需要对现有的 EAI基础架构（如 IBMWebSphereBusinessIntegration）进行扩展，以对其进行基于可互
操作协议或开放标准的访问。虽然根据 XML业务数据并通过高度可互操作协议（如 HTTP或 WebSphereMQ）
公开服务接口可以在某些场景中提供适当的互操作性级别，但是如果对现有的集成范围的自定义开发
或专有扩展都不是可接受的，则可能需要支持 WSDL和 SOAPWeb标准。
最相关的问题 相关的解决方案模式（请参见下一篇文章）
3、4、5、8、9、11、
13、14
使用开放数据格式及 EAIInfrastructureforSOA 来扩展 EAI 基础架
构。
添加控制服务网关。
或者对带有 WebservicesCompliantBroker 的基础架构增加开放标准
支持。
实现组织之间服务或系统的受控集成
场景
组织希望使其客户、供应商或其他合作伙伴能够直接集成由一个或多个应用程序、遗留系统等等提供
的功能。控制的重点是需要提供从外部各方到这些应用程序的安全且易管理的访问。因为组织不能直
接控制其合作伙伴所使用的技术，因此最好使用开放标准。此场景既可以应用于分散的组织之间，也
可以应用于大型分布式组织的各个单位之间。
最相关的问题 相关的解决方案模式（参见下一篇文章）
1、2、3、4、6、8、9、10、
11、13、14
添加服务网关。
或 者 如 果 需 要 更 多 的 复 杂 功 能 ， 就 实 现
WebServicesCompliantBroker。
通过编排服务使流程自动化
场景（注意：此场景可以看作是支持一个或多个应用程序实现更广泛的连接性场景的发展。它不被当
作一个 ESB 场景，因为服务编排通常是与 ESB 分开实现的，正如本系列的第一篇文章所述。然而，我
之所以把它包括在这里，是因为此场景往往驱动对 ESB和服务编排组件的需求。）
现有的已封装（例如，客户关系管理（CustomerRelationshipManagement，CRM）、企业资源规划
（EnterpriseResourcePlanning，ERP）等等）或自定义开发的应用程序可能是在 J2EE 平台或其他应
用程序服务环境中实现的，它们提供的可用功能超出了应用程序本身。可以使用可互操作或开放通信
和服务协议将这些功能作为服务公开，这样应用程序就可以交互。可以在某些层次上组合这些交互以
构成业务流程。应该使用适当的建模和流程执行技术（可能遵守适当的开放标准）来对这些流程进行
显式建模。
最相关的问题 相关的解决方案模式（请参见下一篇文章）
1、2、3、4、6、10、11、12、
13、14
如 果 服 务 的 直 接 连 接 是 可 能 的 ， 则 实 现
ServiceChoreographer。
如 果 需 要 更 复 杂 的 集 成 或 控 制 ， 则 实 现
FullSOAInfrastructure。
实现具有高服务质量和 Web服务标准支持的 SOA基础架构
场景
此场景是由前面的组成的。它代表了对由多个应用程序、遗留系统等等提供的服务进行普遍的内部或
外部访问的需要。需要各种安全、聚合、转换、路由以及服务编排功能。IT组织以响应所支持的业务
不断增加的需求，从而使得能够在业务系统之间进行更普遍且更灵活的集成。
最相关的问题 相关的解决方案模式（请参见下一篇文章）
全部 实现 FullSOAInfrastructure。
驱动 ESB体系结构和设计决策的问题
为了确定用于 ESB 的合适解决方案模式和实现技术，需要对特定的 ESB 功能需求进行详细的分析。下
面的问题旨在帮助进行这一过程，而前面的部分指出了与每个场景相关的特定问题。
1. 现有功能及其数据接口是否与您想要提供的服务相匹配？您是否能够修改或聚合应用程序？
o 如果不可以，则转换或聚合功能就需要由适配器或 ESB体系结构来提供，或者不得不
由服务客户端来完成。
2. 服务是否可以以一些通用业务数据模型的形式公开？如果可以，则实现这些服务的系统是否
已经支持该模型？或者说可以使它们这样做？
o 如果服务不可以，则转换或聚合功能就需要由适配器或 ESB体系结构来提供。
3. 是否需要开放标准？或者是否可以通过 EAI 中间件来实现适当的互操作性？如果需要开放标
准的话，则哪些开放标准是适合的？
o 虽然使用开放标准是实现互操作性的一种途径，但专有的 EAI中间件也具有高度的互
操作性，并且往往要成熟得多。另外，许多组织还拥有广泛的现有基础架构，在一些场景中，它们可
能会使得开放标准的作用几近于无。
o 在需要开放标准的场景中，Web服务也许是这些情况下最明显的选择。不过，您也可
以应用 JavaMessagingService(JMS)、JDBC、基本 XML或者一些其他的技术（比如 EDI或业界通用的 XML
格式。
o 在实践中，不能总是假定相同标准的不同实现之间具有互操作性，特别是对于近来出
现 或 刚 刚 兴 起 的 标 准 。 对 于 Web 服 务 ， Web 服 务 互 操 作 性 组 织
（WebServicesInteroperabilityOrganization）发布了使用 SOAP和 WSDL的互操作性的基本概要，其
他更高级的标准（例如 Web 服务安全性（WS-Security）、Web 服务事务（WS-Transaction）等等）的
概要随后也将发布。在产品全面、稳定且广泛地支持这些概要之前，开放标准的使用还没有得到保证，
并且可能并不总是促进互操作性。
4. 是否需要支持基本通信协议及标准（例如 WebSphereMQ、SOAP、WSDL）？或者需要更高级的功
能（例如 Web服务安全性（WS-Security）、Web服务事务（WS-Transaction）等等）？
o 对支持更复杂标准的需求将对实现技术的选择加以更严格的约束，并且可能意味着使
用还不成熟的技术。
5. 当果考虑更改现有的基础架构使用的消息格式和协议（包括可能采用开放标准）时，需要在
整个现有的基础架构中进行这些更改吗？或者很快就要应用新的消息格式和协议吗？如果正在使用或
考虑使用 EAI技术，该技术是否有自己的内部格式？或者它能够将开放标准处理为内部格式吗？
o 开放标准的任何应用都是受扩展访问的需求驱动的，因此它们对现有基础架构的接口
的可用性比在内部使用的这样的标准更重要。
o 如果需要在内部使用特定的格式、技术或标准，这会给实现技术的选择带来限制。
6. 将作为服务公开的系统实现功能支持所需的技术或开放标准（比如 SOAP、JMS或 XML）吗？
o 如果不支持，ESB基础架构或适配器将需要在所需的开放标准和服务提供者支持的格
式之间进行转换的功能。
7. 在需要访问遗留系统的情况下，通过使用更新的基于 XML 的技术，可以直接支持（例如
CICSSOAP支持）遗留系统的可用性吗？是否需要单独的适配器？遗留平台是否支持 XML处理？如果支
持，这种处理是否可以灵活地使用平台功能？
o 如果因为这其中的任何原因而导致所需的 SOAP或 XML功能对遗留平台不可用，则需
要在适配器（比如 sJ2CConnectorArchitecture(JCA)或 WebSphereBusinessIntegrationAdaptors）、
集成层或 ESB基础架构中使用适当的转换功能。
8. 如果 EAI 技术已经可用，它是否使用适当的功能或接口粒度将服务作为消息流实现？它支持
哪 些 连 接 性 协 议 （ 例 如 JCA 、 SOAP 、 WebSphereMQ 以 及 Java 远 程 方 法 调 用
（JavaRemoteMethodInvocation））？
o 如果现有消息流不提供所需要的服务，则需要另外的流程来执行转换。如果 EAI技术
不直接支持所需的标准，就需要添加一个网关组件。
9. 应该从服务客户端通道以工作负荷缓冲、安全、登录等形式提供给服务提供者系统什么保护
措施？
o 这种缓冲通常是 ESB基础架构的一个角色，并且定义它所需要一些功能。如果特定的
服务提供者系统（例如遗留事务系统（legacytransactionalsystems））需要额外的保护，则可以使用
专用集成层。
10. 应该实现多少服务？实现的什么方面应该在这些服务中保持一致？如何实施一致性（可能在
多个平台上和多个应用程序中）？
o 如果只需要非常少的服务，简单的点到点（point-to-point）集成模型可能比较适合。
然而，如果需要更多的服务或者过一段时间以后可能还是如此，则添加控制点（比如由 ESB 提供的）
就变得愈加有益。
11. 服务交互包含在组织内部，还是有一些交互在组织外部？
o 这常常是不同于在单个组织中实现的 ESB基础架构的一种情况，因为对安全和服务路
由的需求可能与外部可用的服务不同。
12. 是否需要服务编排？服务编排是否涉及短期（short-lived）或长期（long-lived）（换句话
说就是有状态的）流程，还是两者都涉及？它们是否包含人工活动？
o 在这些需求构成业务功能的情况下，应该在与 ESB 分离的 ServiceChoreographer 组
件中实现编排。关于是支持长期有状态流程还是支持人工活动的需求将对实现技术的选择产生限制。
13. 基础架构应该支持什么样的服务级需求（例如，服务响应时间、吞吐量、可用性等等）？随
着时间的推移，需要如何对其进行扩展？
o 一些候选的 ESB实现技术相对较新，并且可能仅仅在有限的服务级进行过测试。同样，
由于相关的开放标准不是最近制订就是正在兴起的，所以在更多的既定产品和技术中对它们的支持也
是新出现的。
o 在可以预见的未来，关键的体系结构决策将专注于特定开放标准优点的平衡，针对服
务级需求的新兴或成熟的产品技术支持这些开放标准。制订这些即时决策需要考虑到有些标准和支持
它们的产品是相对成熟的（例如 XML、SOAP等等），有些（例如 Web服务安全（WS-Security））比较新，
还有一些（例如 Web服务事务）是正在兴起的。
o 标准的优点之间的权衡和经过验证的服务级特征往往驱动一个结合了 ESB 与 SOA 体
系结构中适应标准的、专有的或自定义技术的混合方法。
14. 是否需要点到点（point-to-point）或端到端（end-to-end）安全模型（例如，ESB是否可以
简单的对服务请求授权，还是需要将请求者的身份或其他凭证传递给服务提供者）？是否需要使用应
用程序或遗留安全系统来集成服务安全模型？
o 如果点到点安全性是可接受的，则许多现有解决方案（例如 SSL、对数据库访问的 J2EE
安全性、适配器安全模型等等）就能够得到应用。如果需要端到端安全性，则 Web 服务安全标准就成
为可能，提供所有相关的系统来支持它。换句话说，您可以使用带有客户端消息头的客户端模型，或
者传送像应用程序数据这样的安全信息。
结束语
本文确定了一些 ESB 实现中最常见的场景，以及对相应的解决方案直接产生影响的问题。虽然没有完
全涵盖所有的隐藏问题，但这些是其中最常遇到的。
我们概述了从两个系统的基本集成到实现支持高质量服务和 Web服务标准的 SOA体系结构的常见场景。
并描述了需要重视的十四个不同的问题：
现有数据接口
业务数据模型
开放标准的使用
对基本或高级通信协议的支持
通过现有系统对数据传递格式的修改
通过新技术公开现有服务
对遗留系统的访问
现有 EAI技术
需要的保护措施
需要提供多少服务和需要的一致性程度
公司内部以及与其他公司之间的互操作
对服务编排的需求
服务级需求的基础架构级支持
点到点（point-to-point）或端到端（end-to-end）安全模型的使用
理解这些基本场景和问题为您开发可能的解决方案打下了牢固的基础。在本系列的第 3 部分，我将讨
论本文中提到的实际解决方案。如下：
基本适配器
服务网关
WebservicesCompliantBroker
ServiceChoreographer
用于 SOA的 EAI体系结构
完整的 SOA体系结构
最后，我将讨论组织考虑如何使用受控和增量的方式发展它们的体系结构时可用的选择。也将说明能
够指导您开发自己的 ESB路线的一些问题。
理解面向服务的体系结构中企业服务总线场
景和解决方案，第 3部分
ESB场景的解决方案
级别 :初
级
RickRobinson（rick_robinson@）
ITArchitect,IBM
2004年 7月
这个系列文章的第 3部分介绍了实现企业服务总线（EnterpriseServiceBus，ESB）的场景和解决方案，
在此作者分析了第 2 部分概述的多个场景可能的解决方案。在第 1 部分中说明的总线工作角色提供了
这些场景的基础。
下面继续这个系列来构建面向服务体系结构（Service-OrientedArchitecture，SOA）的企业服务总线，
现在我们来看一看第 2部分（请参阅参考资料）中所描述场景的多种显而易见的解决方案模式。
以下的每个部分都描述了一种 ESB实现方式的解决方案模式，除了基本适配器（BasicAdaptors）模式
以外，其他的都是简单的点到点（P2P）解决方案。每个模式都提出了不同的使用现行技术的实现选择，
同时也做出了正反两方面以及移植方面的考虑。
请注意每个解决方案模式的图示，它认为服务客户端与提供服务的系统是分离的。当然，在许多情况
下，相同的系统或应用程序既可以是服务客户端也可以是服务提供者。图示并非是要排除系统作为单
独的客户端和提供者的可能性，而是承认了相同的系统在不同的互操作中可以有两种不同的工作角色。
在决定系统是作为客户端角色来选择、确认和调用服务，还是作为提供者角色来接收、处理和响应服
务请求时，这个区别通常很重要。
本部分的解决方案模式有：
基本适配器（BasicAdaptors）
服务网关
Web服务兼容的代理（WebService-compliantBroker）
面向服务体系结构的企业应用集成基础架构（EAIInfrastructureforSOA）
服务编排（ServiceChoreographer）
完整的面向服务体系结构的基础架构（FullSOAInfrastructure）
基本适配器解决方案模式
这种解决方案通过封装器或适配器技术来实现简单的点到点（P2P）服务集成，而不是真正的 ESB。这
种技术通过 WSDL 定义的 SOAP 访问或者其他可互操作的产品技术（比如 IBMWebSphere®MQ（MQ））来
实现集成。如果这些技术没有为服务接口定义（比如 WSDL）提供本地模型，那么将需要使用自定义模
型来实现 SOA规范。
虽然设计比较简单，但是从该模式中可以获得的好处却不可低估。例如，通过 MQ或 SOAP/HTTP进行的
直接集成仍然可以是松散耦合式的，尤其是互操作的特征是使用接口来声明时。在将来的某个时候，
对于支持最初使用的集成技术的 ESB 基础架构，我们可以通过它来中断集成。还可以在进程级别的服
务命名和寻址之上实现控制级别。
现在已经有各种各样的适配器可用，而且也可以通过开发工具或运行时技术来创建新的适配器。并能
使其提供对 Web服务规范和企业应用集成（EnterpriseApplicationIntegration，EAI）中间件的支持。
它也可以提供给多种不同类型的系统，包含最新的分布式应用服务器（J2EE服务器（如 WebSphere），
或者微软的.NET系统）、企业遗留系统（比如 CICS®）以及 CommercialOff-the-Shelf软件包（比如 SAP
或 Siebel）。
图 1说明了一般的基本适配器解决方案，包含了使用现有的 HTTP和 EAI中间件基础架构来支持新的集
成。虽然本图描绘的是内部集成场景，但如果用 HTTP 来作为通信协议，或者使用某些 Internet 兼容
的 EAI技术（比如 MQinternetpass-thru），那么该解决方案同样可以应用于外部场景。
图 1.基本适配器解决方案模式将现有 HTTP 和未修改的 EAI 基础架构描述为支持服务总线功能的某些
方面
选择基本适配器的实现技术
以下是实现基本适配器的一些选择：
使用遗留系统或应用程序直接提供的 SOAP或 EAI功能。例如，IBMCICS目前直接提供对 SOAP
的支持，以及许多系统和应用程序包能够支持 MQ或 SOAP接口。
如果用于提供访问的应用程序是用户自己开发的应用程序且运行于应用服务器环境，或者只
要应用服务器运行时环境和应用开发环境能够用来给应用程序添加封装器。例如，
WebSphereStudioApplicationDeveloper 能 够 用 来 给 部 署 于 WebSphereApplicationServer
（ApplicationServer）的 J2EE应用程序添加 XML、SOAP或 MQ支持。
如果这种支持不可用或不合适（例如，如果 XML转换不适合用来处理现有平台上的资源），那
么可能需要其他的体系结构层，如图 2 所示。这可能是托管了与应用程序或遗留系统集成的适配器的
应用服务器层。例如， ApplicationDeveloperIntegrationEdition 提供了 Java2 连接器架构
（Java2ConnectorArchitecture，JCA）连接器技术来访问遗留系统（比如 CICS），并通过 WebSphere
运行时环境为其提供了 J2EE和 Web服务接口。
图 2.执行 XML转换处理的其他体系结构层
如果使用开发工具来创建自己的封装器，那么您可以增强工具提供的功能：通过创建一个框
架或一组实用工具类来执行通用任务，比如安全性、日志纪录等等。然而，这种方法可能引起范围蠕
变（scopecreep），并最终导致该框架实际上变成了用户开发的服务网关或 Web服务兼容代理。当定义
框架提议的功能时，需要注意验证开发和维护的成本是否合适，以及转换为更复杂的模式是更不合适
的。
请参阅参考资料以获取更多有关实现此模式的详细信息。
基本适配器剖析
从正面来说，这种解决方案模式对新的基本架构的需求最低或是根本不需要，并且使用的都是广泛支
持的各种规范和技术。从反面来说，像安全、管理等功能都交给了应用程序或单个封装器的实现来处
理。
由于该模式基于使用协同操作技术和开放式标准，因此将该模式移植到更复杂的体系结构也就相对比
较简单。
模式替换
如果以上均不能满足集成的需求，或者存在一些附加功能或服务质量需求，那么封装器方式就可能满
足不了需求。如果是这样，从逻辑上说下一步应该是服务网关。如果需要更高级 ESB 功能，则 Web 服
务兼容代理或 EAIInfrastructureforSOA模式会比较适合。
服务网关解决方案模式
这种模式代表了一种基本的 ESB 实现，接近于在第 1 部分中描述的“最低功能的 ESB 实现”。服务网
关一般通过 SOAP/HTTP、MQ、Java消息服务（JavaMessageService，JMS）等来支持客户端连接，但是
也可以通过诸如 JCA或 WebSphere业务集成适配器（WebSphereBusinessIntegrationAdaptors，WBIA）
来对服务提供者支持更广泛的集成。网关组件为服务路由、协议转换以及安全担当着中央控制点的角
色。
网关能够用来向客户端提供一致的服务命名空间（例如，以 URL 的形式为 SOAP/HTTP 服务提供命名空
间），并可以向服务提供授权模型，实际上这些服务是由完全不同的系统通过多种协议来提供的。当
需要向外部合作伙伴（比如客户端或供应方）公开服务时，网关所提供的这些功能便成为一个明显的
需求。然而当需要对从应用程序到用多种系统和技术实现的功能的访问进行简化时，这些功能在单个
企业内部也很有用。
一个关键的网关功能是将客户端支持的服务协议转换为提供方支持的服务协议。这些协议可以包括
SOAP/HTTP、MQ 或 SOAP/JMS、JCA、RMI/IIOP 等。候选实现技术的能力需要针对所需要的客户端和提
供方协议来进行评价。
图 3描述了服务网关解决方案模式
图 3.使用服务网关模式实现 ESB
选择服务网关的实现技术
服务网关解决方案模式可以用以下的方式来实现：
使 用 打 包 好 的 网 关 技 术 ， 比 如 WebSphereApplicationServerNetworkDeployment 或
WebSphereBusinessIntegrationConnection提供的 WebServicesGateway。许多网关技术支持某些形式
的中间件过滤器或处理器程序设计模型，以实现自定义增强功能。WebServicesGateway提供了一些可
配 置 的 中 间 件 功 能 。 它 也 支 持 基 于 XML 的 远 程 过 程 调 用 JavaAPIs
（JavaAPIsforXML-basedRemoteProcedureCall，JAX-RPC）规范中定义的 Web服务请求/响应处理程序。
使用应用程序开发和最新应用服务器技术的运行时功能来实现自定义网关。这可能包含与前
面基本适配器解决方案模式中所描述的相同类型的适配器。
如 果 需 要 更 高 级 的 功 能 ， 就 应 该 考 虑 更 复 杂 高 级 的 EAI 中 间 件 ， 比 如
WebSphereBusinessIntegrationMessageBroker。
这种模式的许多实现存在于遗留技术中，这些遗留技术通常没有使用 Web 服务技术。例如，
许多组织构建了路由器事务，它对多种遗留事务提供了使用类似文本的（text-like）数据模型的简单
接口。这种系统使用具有一些 XML的可移植优点的自定义数据格式，从而有效地实现了网关模式。
服务网关剖析
从正面来说，尽管一些网关技术必须在有适当弹性的方式下部署，但这种解决方案仍然能够包含最低
功能基础架构。对互操作协议和开放标准的重视也使基础架构所涉及的方面得以简化。大多数网关技
术与许多其他接口类型（比如 RMI/IIOP和 JCA）进行协同操作的能力，也应该能够减少其他连接性技
术的部署。
然而，网关技术往往限制了对请求/响应和发布/订阅服务的简单一对一映射的服务处理。更复杂高级
的功能，比如消息转换、消息相关性、消息聚集等都可能超出了网关技术所能提供的功能之外，或需
要在自定义场景中进行网关技术之外的开发工作。
大多数 ESB 技术认可网关模式及其相关功能。有了这一点，互操作协议和开放标准的使用、网关功能
的简化等任何移植到更高级的 ESB基础架构的问题都不会太困难。
服务网关的替换模式
最显而易见的替换模式是 Web 服务兼容代理或 EAIInfrastructureforSOA。当需求超出了网关所能提
供的功能之外，或者超出了已打包的网关技术范围时，这些模式会比较适合。另一方面，如果实际涉
及的服务非常少，那么简单的基本适配器解决方案可能比较合适。
Web服务兼容代理解决方案模式
这种解决方案代表了高级复杂的 ESB 实现，它提供了一个功能完整的 EAI 解决方案的所有功能，并且
使用开放标准模型。通过特定场合的明确需求来定义需要什么级别的 EAI 功能，从而确定适合使用哪
种 EAI技术。图 4说明了使用 Web服务兼容代理的 ESB实现。
图 4.使用 Web服务兼容代理的特性丰富的 ESB实现
选择 Web服务兼容代理的实现技术
Web服务兼容代理可以使用的实现技术选择如下：
最可能用于这种解决方案的实现技术是能提供合适的 Web 服务支持的 EAI 中间件，比如
WebSphereBusinessIntegrationServer。
如果 Web 服务支持主要是为了外部集成需要，则 EAI 中间件的专有特性可以在内部使用，并
结合服务网关组件的使用来添加 Web服务支持。
请参阅参考资料以获取更多有关实现此模式的详细信息。
Web服务兼容代理剖析
这种实现方式的优点是在开放标准模型内提供了丰富的功能。然而，虽然 EAI 中间件技术是成熟的，
但是该解决方案支持的开放标准，尤其是更高级的 Web 服务标准，比如 Web 服务策略（WS-Policy）
和 Web 服务事务（WS-Transaction）还不够成熟。因此该场景最主要的缺点仅仅是不能简单地对所有
情况都适用。
Web服务兼容代理的替换模式
如 果 不 能 提 供 适 当 的 Web 服 务 支 持 ， 则 服 务 总 线 （ ServiceBus ） 的 需 求 可 以 通 过
EAIInfrastructureforSOA 模式用更加专有或定制的方式来实现，也许要与服务网关组件相结合以添
加 Web 服务接口。另外，如果开放标准是最关键的需求，而且一些 EAI 功能（比如转换和聚集）能够
在别处完成（也许是在应用程序或适配器内），则服务网关模式可能更合适。
EAIInfrastructureforSOA
出于本文一直讨论的原因，采用 Web 服务规范并不总是适合的。但是 SOA 原则却仍然可以应用于各种
解决方案，这些解决方案既可以是专有的或自定义的技术，也可以是开放标准。
一个显而易见的方法已经被许多成功的实现所证实。就是使用 EAI技术（但不排除其他技术）并结合
XML来构建自定义的 SOA基础架构。只要服务接口已经明确定义并有合适的粒度，EAI中间件就能确保
满足 SOA的互操作性和位置无关性原则。
这种方式潜在的好处也意义重大，因为成熟的 EAI 技术全部的功能和性能都应用于 SOA 的灵活性上。
这个优点既可以应用于为 SOA 实现新的且坚固稳定的基础架构，也可以应用于在现有基础架构上的实
现符合 SOA原则的应用程序。
用这种方法实现的 ESB 可以使用这些重要的开放式的，而且也是事实上的标准，并且从它们中获得好
处。事实上，这确实是一种可以把这些标准广泛应用到现有 IT基础架构中的方法，并且为将来更远的
发展提供一定的基础：
许多 EAI 技术的应用非常广泛，尤其是在单独的组织中，以至于 EAI 技术和开放标准一样具
有互操作性上的优点。
如果合适的话，可以使用 XML 数据和消息格式以帮助实现互操作性和平台无关性，就像 XML
在 Web服务规范中帮助实现了这些优点一样。
EAI将很有可能支持一些形式的 Web服务，因此可以在适合的场合提供开放标准接口，尤其是
对于使用 document/literalSOAP模型来公开所使用的 XML格式的场合。另外，可以通过添加服务网关
到该解决方案来提供这种访问。
有些时候，可以利用 Java 的平台无关性来提供客户端 API 包，这不但对于 J2EE 环境来说很
有用，而且对于单独 Java环境、支持 Java的数据库环境以及其他很多场合也是如此。
EAI中间件可以支持其他的开放标准（比如 JavaMessagingService），这些标准也许不像 Web
服务那样广泛适用，但仍然有很多技术支持它们。
该方法是向完全开放标准的 SOA 基础架构发展的一个重要步骤。虽然从某种意义上说，至少应该考虑
将其移植到 Web 服务标准，但这种方法是向完全开放标准的 SOA 基础架构发展的一个重要步骤。EAI
和 XML 技术的过渡使用至少提供了处理问题（比如接口粒度、公共数据模型与格式等）的方法，所有
这些都是向前发展的重要步骤。
最后，再次强调这种方法的好处。成熟的 EAI 技术通过已被证实的性能、可用性以及可伸缩性等特点
提供了极其丰富的 ESB 功能（流程和数据模型、转换、基于内容的路由、服务聚集和编排等等）。由
于这些功能是最重要的需求，因此不借助 Web 服务技术而只使用 EAI 技术来实现 ESB，这从解决方案
的核心上看是完全符合要求的，尤其是因为如果需要使用 Web 服务，可以在许多方面添加 Web 服务支
持。
图 5说明了这种解决方案模式包含的组件。
图 5.使用 EAI中间件实现功能丰富的服务总线
选择 EAI中间件模式的实现技术
EAI 中 间 件 的 选 择 取 决 于 特 定 情 况 下 所 需 的 ESB 功 能 与 各 种 不 同 EAI 产 品 （ 比 如
WebSphereBusinessIntegration家族）的特性。
设计活动的关键之处在于服务接口定义模型。为了遵循 SOA 原则，应使用直接的接口来定义服务。虽
然有些 EAI 技术可能提供了这样的模型，但在其他的情况下，需要自定义解决方案。在实践中，这经
常通过使用 XML 模式并结合服务身份确认、寻址以及业务数据来实现。然而，也有不使用 XML 的解决
方案，比如某些服务网关模式的遗留系统的实现所使用的文本解决方案。
与数据模型无关的接口模型方面的功能，用于声明性地定义应该如何使用 EAI 基础架构的特性来调度
服务请求和响应。应用程序需要一些机制以解释接口定义及适当的调用 EAI 基础架构。还有，这些机
制可以通过 EAI技术提供，可供选择的技术包括设计与开发规范的实施，或者框架 API的使用。
框架 API 的开发和维护显然代价不菲，但是它比实施跨越多个应用程序规范要更有效。如果至少大多
数连接到服务总线的应用程序都支持同一种编程语言（比如 Java）的情况下，这样的方法是最有效的。
业务数据模型的采用也同样需要选择，是采用基于 XML 的、专有的还是自定义的。由于存在很多普通
的和具体于特定行业的 XML 数据模型，采用这些模型中的一种可能会有好处。然而，许多这种模型正
处于向 Web 服务规范移植的过程中，如果考虑使用这种解决方案模式的原因是由于可用的 Web 服务技
术出于某些原因而不适合使用，那么就不可以选择那些规范。最后，如果 Web 服务或其他基于规范的
某些形式的访问需要使用这种自定义模式实现的服务，那么就既可以选择使用 EAI 技术提供的 Web 服
务支持，也可以添加一个显式服务网关组件（如果它能够更好的匹配需求的话）。
EAI中间件模式剖析
由于这种解决方案模式代表了重要的开发、实现和维护工作，所以需要慎重考虑。该模式的优点是它
与 SOA 原则完全一致，这被反复证明对交付业务有益，并能够用成熟的技术实现，使之具备企业级的
功能、弹性和性能。
该解决方案的成本主要有两方面。首先在于解决方案的最初实现和随后进行的维护，其次，在于移植
工作，随着 Web服务技术的成熟并日益引人注目，最终很可能需要采用开放标准的解决方案。
这种模式的采用是一个即时的决策，这个决策依赖于近期或中期的利益来证明是否值得进行必要的投
入。投入的多少依赖于所使用 EAI 的现有级别，也依赖于附加定制开发的工作量多少。近期或中期的
定义依赖于单个组织认为新兴的 Web 服务规范何时会足够的成熟，以满足他们功能性或非功能性的需
求。
EAI中间件的替换模式
Web服务兼容代理模式是与 EAI中间件模式相似的使用开放标准技术的实现方式。
服务编排解决方案模式
这种模式由专用服务编排组件的实现组成。这种组件不是真正的 ESB，但是它通过多种协议（比如
SOAP/HTTP 或 MQ）支持对服务的连接性，这需要或隐含着 ESB 的存在。在有些场景中，这种支持足以
对服务提供方和服务器请求方进行直接连接。但如果情况并非如此，ESB 可以通过本文描述的任何其
他解决方案模式来提供。这就构成了完整 SOA基础架构解决方案模式。
图 6说明了服务编排的实现。
图 6.服务编排的实现
选择服务编排的实现技术
这种解决方案模式中要做的最重要的选择是，它所需开放标准的级别。有以下三个场景：
对服务接口和流程建模大规模地采用 Web服务规范。
对服务接口采用 Web服务规范，并结合使用专有的流程建模技术。
使用专有的接口和流程建模技术。
因 为 与 流 程 建 模 相 关 的 Web 服 务 标 准 （ 首 先 是 Web 服 务 业 务 流 程 执 行 语 言
（BusinessProcessExecutionLanguageforWebServices，BPEL4WS）是最近出现的，为此支持它们的产
品还不够成熟，因此这些问题与该解决方案模式特别相关。大多数服务编排技术的提供商都将提供专
用的及基于标准的混合技术。例如，这样的技术包括：
WebSphereEnterpriseProcessChoreographer技术提供了对 Web服务接口和流程定义的支持。
MQWorkflow 提供了对更成熟但更专有的服务编排技术的支持，该技术既有 Web 服务接口也有
专有接口。
如果采用专有技术，也许为了解决可伸缩性或弹性需求，可以添加服务网关组件以提供 Web 服务连接
性。如果选择服务编排技术不能为服务提供方（例如，遗留系统或应用服务器）提供充分的集成，那
么就需要一个遵守其中一个其他解决方案中的 ESB。
服务编排剖析
这种解决方案模式很大程度上依赖于基于规范的或专有的解决方案是否实现。基于规范的解决方案目
前还不太成熟，但它最终将能够提供更好的互操作性。专有解决方案将可能在较为熟悉的模型中提供
可伸缩性和弹性，还可以充分利用高互操作性的通信技术（比如 MQ）。但是，随着开放标准技术的成
熟和蔓延，这种方案可能最终还是需要一些移植工作。
完整 SOA基础架构解决方案模式
这种模式代表了服务编排组件与服务总线实现的结合。因为这两方面在本文的其他部分已有描述，在
这里就不更多的描述了，只是说完整的实现显然是可能的。一端采用完全专有解决方案，它使用 ESB
和专有服务编排技术的 EAIInfrastructureforSOA 模式，另一端采用完全开放标准的解决方案，它使
用 ESB以及适应开放标准的服务编排技术的 Web服务兼容代理模式。
采用 SOA和 ESB的主要阶段
本文描述的模式都涉及到从即时需求构建 ESB，这仅仅是朝更复杂的 SOA 实现前进的第一步。这一部
分讨论一些有用的选择，用于组织考虑如何以受控和渐进的方式发展。我不建议所有的组织都采用一
种路线，相反，我想讨论一些在设计 SOA或 ESB路线中应该考虑的问题。
确定所涉及的直接范围
简单说来，实现综合性的 SOA 主要存在两个方面：全功能、有弹性的基础架构的实现和所有相关功能
以服务的形式跨业务地公开。虽然还不是完全独立，但两个方面之间存在一定程度的松散耦合，这使
组织可以比较灵活的选择如何实现它们。
在某些方面，第一个决策就是是验证 ESB 技术，还是验证功能性体系结构的 SOA 原则？这个问题引出
了两个极端的方法：
丰富的基础架构，受限的功能--在这里，主要涉及的是验证这些技术的功能。基础架构很可
能包含复杂的 ESB功能（开放标准的或专有的），并可能构成完整 SOA基础架构解决方案模式。但是这
种技术上方案含有高风险性，并可能含有相对不成熟的技术。因此，不要用它去实现关键的业务项目
或功能。功能以服务的形式公开既具有低危险性，又主要通过可选通路保持传递。随着基础架构功能
的验证和成熟，服务以后将移植到基础架构。
基本的基础架构，丰富的功能--在这里，主要涉及的是业务功能以服务的形式公开，这样就
可以用新的方式访问或组合这些功能以传递业务价值。在这种情况下，预计的业务利益或其他因素驱
动的改变往往变得非常重要，以降低技术风险。因此，基础架构的实现或者仅使用最基础最成熟的 Web
服务规范，或者使用更确定的 EAI 技术。一旦基础架构适当且支持服务互操作性，它的功能今后可以
随着 ESB技术的成熟而升级或移植。
当然，还有两个其他的极端方式--什么都不做，或者马上着手做每件事，但这些可能对路线的观点不
感兴趣。
另外一个的方法在无形地使用。那就是单个部门、项目或工程渐进地采用 SOA 和 ESB 原则、技术和基
础架构。许多组织在 ESB 或 SOA 的进程中，可能使用的是这种方式而不是直接了当的方式。这种局部
采用专门技术或实践的方式可以对其提供更成功的检验，这比大爆炸（big-bang）方式要好得多。这
与丰富的架构，受限的功能方式比较相似，但它由许多基本的架构组成，而不是单个丰富的架构。
实现 SOA 的方法有两个方面应该在早期确定：对服务的内部或外部访问的提供，和一个解决服务粒度
的方法。
支持内部或外部访问的决策将驱动一些因素，包括需要什么级别的服务安全性（请参阅影响 ESB 的安
全问题），以及是否需要显式服务网关组件以控制外部访问。正如 EAIInfrastructureforSOA 解决方
案模式中所讨论的，外部访问也驱动了 Web 服务规范的使用。然而内部访问可能更具灵活性，比如
MQ、RMI/IIOP、或专有 XML。
服务粒度问题已经在业界被广泛地讨论（请参阅参考资料）。综合性的 SOA可能包含多种粒度的服务，
从技术操作性的功能（比如登录、记账等），通过业务功能（比如查询账目结算），到业务处理（比
如处理库存订单）。
每个粒度级别的服务都由更低粒度级别的服务或其他功能组成。因此，需要考虑一些不同等级的服务
聚集或编排，它可能适合不止一种实现技术。在任何特定情况下都可以处理该问题的一个实用方法就
是，确认、特征化以及对可用的不同服务粒度级别进行命名。然后就可以在两个不同粒度级别之间定
义聚集或编排需求，并选择适当的实现技术。
本部分的最后，值得注意服务实现的自上而下（top-down）和自下而上（bottom-up）模型之间联系。
自下而上方法专注于以服务的形式实现应用程序和遗留系统的功能。在一般情况下，这涉及使用适配
器和开发环境来提供合适的接口，并导致相对细粒度业务功能的启用。
自上而下方法则更多涉及到解析业务系统和组件以确认流程和服务的体系结构处理。这个趋向于确定
了粗粒度的服务，而这些粗粒度服务可能是由更多的细粒度服务组成的。
许多组织可能会将这两种方法都加以运用以进行服务确认和启用，某种中间汇合点需要来合并他们。
如果这种汇合点在约定的地方明确地对多种粒度级别的确认和分类，那么它对于技术人员来说可能更
加简单。
SOA的重要阶段
无论选择那种方法来实现完整的 SOA，都必须经过许多阶段。这个部分指出和讨论了其中的一些重要
阶段。由于它们在很大程度上独立，并且它们实现的次序依赖于影响单个组织的很多因素，因此并没
有对它们排序：
基于标准的安全模型--虽然简化的或专有的模型可能在短期内可以满足需要，但综合性的 SOA
必须具备全面且开放标准的安全模型。理解哪些支持 Web 服务安全规范的产品能够满足组织的需求，
这是整个实现计划的关键部分。
启用服务遗留系统和应用程序--现代应用服务器（例如，J2EE服务器比如 ApplicationServer）
的发展让组织能够使用 SQL 和 JDBC 或 ODBC 接口来访问数据库。同样，SOA 的发展将驱动组织能够对
遗留事务和应用程序功能进行基于服务的访问。因此组织可以计划定义和实现用最适当形式的服务来
启用每个系统。可以选择利用 XML 或 Web 服务支持、使用适配器（比如 JCA 适配器）或者使用 EAI 网
关技术提供遗留系统连接性。
实现高质量服务基础架构--到目前为止，可利用的最成熟的 Web 服务支持对不可靠的通信协
议（SOAP/HTTP 规范提供了更高质量的服务，比如 Web 服务可靠消息传递（WS-ReliableMessaging）
或 Web服务事务（WS-Transaction））还没有广泛的支持。目前需要使用 EAI技术来为 SOA提供更高质
量的服务。从长远来看，组织应该在对新兴规范的支持和对符合 Web 服务规范的 EAI 技术的加强这两
方面保持平行发展。
确定的服务粒度级别--如上面确定所涉及的直接范围部分强调的那样，确定与 SOA 相关的粒
度级别以及各级别间的聚集和编排是非常关键的。每个粒度级别（例如，技术性功能、业务功能、业
务流程等）的实现和相关的编排也构成了一个关键的里程碑。
SOA实现步骤
以下问题在前面两部分已经讨论过，您现在可以构成 SOA和服务总线实现的一般路线：
1. 决定 SOA技术或 SOA功能的哪些元素应该优先实现（请参阅确定所涉及的直接范围）。
2. 指定或定义合适的项目来实现第一个解决方案，这既可以是技术试验、业务试验，也可以是
存在可接受风险的真实业务项目。
3. 指定 SOA 中那一个 ESB 场景可以用于项目。更多关于驱动 ESB 体系结构和设计决策的问题和
ESB 功能模型的需求分析。然后基于这些分析选择一种解决方案。基于更多的分析以及安全和非功能
性需求（请参阅影响 ESB的安全问题），最后选择一种合适的实现技术。
4. 与这个工作并行的是，开始规发从第一个实现到完全综合性的 SOA 发展的路线。这项工作依
赖于最初试验的重点，并包含基础架构技术性功能的多个方面，或启用其他功能性服务来利用最初的
试验。在这两种情况下，路线都应该包含在上面指出的 SOA重要阶段。
在最初项目范围之外，还可以计划在其他几个方向上的发展：
发展和提高跨组织的数据模型和流程。
实现应用程序阶段服务，并将其纳入基础架构。
发展 SOA基础架构的技术性能力。
本系列到此结束。在这个系列中，说明了如何从体系结构的观点上最好地使用 ESB。将来，随着 SOA
之后的技术的发展，您将看到 ESB的使用和解决方案得到更深入的研究。
