企业服务总线（Enterprise Service Bus，ESB）体系结构模式支持在面向服务的体系结构 (SOA) 中虚拟化服务交互并对其进行管理。它使得交互可以在服务提供者和服务请求者之间进行，并且可以使用各种中间件技术和编程模型加以实现。它对本系列的前一篇文章中介绍的 SOA 编程模型进行了扩展。

　　引言

　　SOA 提供了一种灵活的、可扩展且可组合的方法来重用和扩展现有应用程序以及构造新的应用程序。服务声明它们实现的或期望其他服务实现的接口，并且声明控制潜在伙伴交互的策略，从而公布各种功能（包括提供的和请求的）。Web 服务描述语言（Web Services Description Language，WSDL）和其他 Web 服务标准（如 WS-Policy）提供了用于这些声明的词汇。（请参阅参考资料，以获得指向 WSDL Version 2.0 Part 0: Primer 的链接。）

　　业务功能的虚拟化（SOA 的一个主要目标）是通过将服务的定义和使用与服务的实现分离开来而实现的。我们可以使用各种技术实现服务，这些技术包括 IBM WebSphere? MQ、IBM CICS? 或 IBM IMS?、Java? 2 Platform Enterprise Edition (J2EE) Enterprise JavaBeans (EJB)、Java 类、IBM DB2? 查询、Java 消息服务 (JMS) 或 Microsoft? .NET。服务请求者将请求发送到提供其所需功能的服务提供者，而不必考虑它如何实现。

　　ESB 是一种体系结构模式，支持虚拟化通信参与方之间的服务交互并对其进行管理。它提供服务提供者和请求者之间的连接，即使它们并非完全匹配，也能够使它们进行交互。此模式可以使用各种中间件技术和编程模型实现。

　　本文将定义 ESB 模式和它在 SOA 内的角色。后续文章将详细描述其使用场景、使用目前的技术实现 ESB 模式的方法，以及 ESB 技术未来的发展方向。

　　什么是 ESB？

　　在 ESB 模式中，服务交互的参与方并不直接交互，而是通过一个总线交互，该总线提供虚拟化和管理功能来实现和扩展 SOA 的核心定义。IBM ESB 模式提供以下几方面的虚拟化：

　　位置和标识：参与方不需要知道其他参与方的位置或标识。例如，请求者不需要知道请求是否可以由某个提供者提供服务。您可以随意添加或删除服务提供者，而不会带来任何干扰。

　　交互协议：参与方不需要采用相同的通信协议或交互方式。表达为 SOAP/HTTP 的请求可能由仅理解 Java 远程方法调用 (RMI) 的提供者提供服务。

　　接口：请求者和提供者不需要就公共接口达成协议。ESB 可以通过将请求消息转换为提供者所期望的格式来处理此类差异。

　　（交互）服务质量 (QoS)：参与方声明其 QoS 要求，包括性能和可靠性、请求的授权、消息内容的加密/解密、服务交互的自动审核以及如何对请求进行路由（如根据工作负载分布标准将请求路由到可用的实现）。描述请求者和提供者的 QoS 要求和功能的策略可以由服务自己实现或者由进行不匹配补偿的 ESB 实现。

　　因此 ESB 模式使请求者不用了解服务提供者的物理实现——从应用程序开发人员和部署人员的角度来看均是如此。总线负责将请求交付给提供所需功能和 QoS 的服务提供者。提供者接收他们要响应的请求，而不知道消息的来源。ESB 本身对使用它的服务请求者和提供者均不可见。应用程序逻辑可以使用各种编程模型和技术调用或交付服务，而无需考虑是直接连接还是通过 ESB 传递的。连接到 ESB 是部署决策；应用程序源代码不会受到影响。

　　ESB 支持许多交互类型，包括单向、请求/响应、异步、同步和发布/订阅。它还支持复杂事件处理（在复杂事件处理中，可能会观测到一系列事件），以产生一个事件作为该系列中的关系的结果。

　　图 1 对基本 ESB 模式进行了描述。消息流过将各个通信参与方相互连接在一起的总线。某些参与方会调用其他参与方提供的服务；而其他参与方则会向感兴趣的使用者发布信息。端点与 ESB 交互的位置称为服务交互点 (SIP)。例如，SIP 可以是 Web 服务端点、WebSphere MQ 队列或 RMI 远程对象的代理。服务注册表将捕获描述以下内容的元数据：SIP 的要求和功能（例如，提供或需要的接口）、它们希望与其他 SIP 的交互方式（例如，同步或异步，通过 HTTP 或 JMS）、它们的 QoS 要求（例如，首选的安全、可靠交互）以及支持与其他 SIP 交互的其他信息（例如，语义注释）。

　　图 1. 基本 ESB 模式
 
　　将总线插入参与方之间，提供了将它们的交互通过称为中介 的构造进行协调的机会。中介对请求者和提供者之间动态传递的消息进行操作。对于复杂的交互，可以按顺序将中介连在一起。中介模式部分讨论了实现这些虚拟化、QoS 和管理概念的常用中介模式。

　　ESB 模式为 SOA 实现提供了灵活且易于管理的方法。总线透明地插入端点之间，可以提高服务质量，可以促进请求者和提供者间的交互（而不受协议、交互模式或服务功能不匹配的影响），还可以支持监视和管理。

　　SOA 用户角色及其任务

　　通过研究创建和管理 SOA 解决方案的用户的角色及任务，可以进一步深入了解 ESB 模式。ESB 工具和运行时将 SOA 解决方案的生命周期划分为四个阶段：

　　发现与描述：对可以在整个 ESB 中进行互连的 SIP 进行标识和描述。这包括创建新的服务、发现现有服务、以及描述其接口、要求和功能。

　　建模与构建：通过新建的或现有的中介进行 SIP 互连，以描述解决方案的端到端交互。

　　配置与部署：针对特定的运行时拓扑配置解决方案的抽象声明，并对其进行部署，同时创建必要的运行时构件。

　　监视与管理：通过 SIP 和中介的行为监视和管理解决方案。此阶段将使用 ESB 运行时中的检测和控制点、以及观测和响应消息流的中介。

　　对于 ESB 中间件，最重要的 SOA 解决方案开发角色是集成开发人员和解决方案管理员，但其中也涉及到业务分析人员、解决方案架构师、实现人员、适配器开发人员和操作人员。（这些角色都是概念性的；一个人可以担任其中的多个角色。）图 2 显示了这些角色交互的方式。

　　业务分析人员确定业务需求，并检查业务流程。他们将概括出解决方案的目标、涉及的业务流程、监视解决方案的运行状况和状态的关键指标，以及 IT 系统需要提供的业务服务的类型。

　　解决方案架构师确定哪些业务需求可以通过对现有 IT 资产进行重用、修改或组合得到满足，哪些需要编写或购买新的 IT 资产。他们定义 IT 资产间的交互，包括消息交换的内容。

　　开发工作在三个角色中分配。实现人员编写新的应用程序代码，这些代码将通过服务接口调用。适配器开发人员构建包装现有或新采购的应用程序和软件包的服务，从而为其他服务提供可访问性。集成开发人员使用 ESB 的相关工具和技术构建逻辑，以控制请求在这些服务间路由的方式。

　　图 2. 用户角色
 
　　解决方案管理员部署新的 IT 资产并将其服务定义导入到服务注册表中，从而使新的 IT 资产可用。当解决方案就绪后，操作人员将监视其执行，根据需要启动和停止 IT 系统，并给解决方案管理员提供建议（后者可能将据此调整解决方案配置）。

　　ESB 模式

　　集成开发人员和解决方案管理员会使用一组模式对 SOA 解决方案进行设计和部署。

　　图 3. 基本 ESB 模式的元素
 
　　基本 ESB 模式将应用程序组件抽象为一个服务集，这些服务通过总线进行交互（而不是通过直接的点到点通信交互）。某个给定的服务既可以是提供者，也可以是请求者，或者同时兼有两个角色。任何 SOA 实现都会支持基本虚拟化，允许在不影响依赖请求者的情况下替换等效提供者实现。ESB 模式通过其对请求者/提供者交互的显式管理提高了此基本 SOA 功能。只要能提供与请求者所需的功能相似的功能，且 ESB 能对其进行协调，任何提供者都可以由另一个提供者替代。

　　ESB 提供了交互点，服务可以在此将消息放到总线上或从总线取走。它会对动态消息应用中介，并保证这些托管交互的 QoS。

　　从 ESB 的角度来看，所有的服务交互端点都是类似的，因为它们都发送或处理请求/事件；它们都要求特定的 QoS；它们可能都需要交互协助。ESB 模式允许集成开发人员以与处理新业务逻辑、流程编排组件或外部 Web 服务同样（面向服务）的方式对待与用户交互的请求者或提供者。

　　用于构建基于 ESB 的解决方案的模式分为以下几类：

　　交互模式：允许服务交互点将消息发送到总线或从总线接收消息。
　　中介模式：允许对消息交换进行操作。
　　部署模式：支持将解决方案部署到联合基础设施中。

　　交互模式

　　ESB 允许端点通过总线以其本机交互模式进行交互。它支持各种端点协议和交互方式。交互模式的例子包括：

　　请求/响应：处理端点间的请求/响应方式的交互。此 ESB 基于消息传递模型，因此由两个相关的单向消息流对请求/响应交互进行处理，一个用于请求，一个用于响应。

　　请求/多响应：上述类型的变体，可以发送多个响应。

　　事件传播：事件可以匿名分发到由 ESB 管理的相关方列表。服务可以将自身添加到该列表中。

　　图 4. 交互模式
 
　　中介模式

　　中介模式处理总线上的动态消息（请求或事件）。由请求者发出的消息会转换为稍微有些不兼容的提供者（从潜在的端点集中选择）能够理解的消息。

　　这些中介操作单向消息而不是请求/响应对，因为 ESB 将交互模式放在中介模式上。

　　图 5. 中介模式
 
　　中介有多种基本模式；更为复杂的模式可以通过组合简单模式构建：

　　协议变换：允许服务请求者使用各种交互协议或 API（如 SOAP/HTTP、JMS 和 MQ Integrator——MQI）发送其消息。将请求代码转换为目标服务提供者的格式。可以应用到交互的请求者端或提供者端，或同时应用到两端或两者之间的任何位置。

　　转换：将消息的有效负载（内容）从请求者的模式转换为提供者的模式。可以包含包封、反包封或加密。

　　充实：通过添加来自外部数据源的信息（如由中介定义的自定义参数或者来自数据库查询的自定义参数）来增加消息的有效负载。

　　路由：更改消息的路由，可从支持请求者的意图的服务提供者中选择。选择标准中可以包含消息内容和上下文、以及目标服务提供者的功能。

　　分发：将消息分发到一组相关方，通常由订阅者的相关概要驱动。

　　监视：在信息通过中介时观测其是否发生改变。可以用于监视服务水平；帮助确定问题或对用户进行后续支付使用的货币单位；或记录企业级事件（如价值超过一定数额的购买行为）。还可以用于将消息记入日志，以供审核和后续数据挖掘之用。

　　相关：从消息或事件流中派生复杂事件。包括模式标识规则和响应模式发现的规则（例如，通过生成派生自触发事件流的内容的复杂事件）。

　　可以在解决方案中显式地配置中介。例如，集成开发人员可以配置一个 enrich 中介来修改消息内容。解决方案管理员可以配置一个 route 中介来允许其将某个服务提供者切换到脱机状态。

　　其他中介由 ESB 设置，以满足服务请求者和服务提供者的 QoS 要求。例如，如果服务提供者的安全策略声明要求使用加密消息，则 ESB 可以自动配置一个 encryption 中介。

　　策略同样也是服务的属性，解决方案管理员可以为交互（或交互集）设置策略。例如，为了将要发送到特定外部提供者或交易值超过 1 百万美元的所有消息记录到日志中。ESB 将通过配置中介（在本例中为monitor 中介）来实现策略。

　　复杂模式

　　图 6. 复杂模式
 
　　中介模式和交互模式可以进行组合，以实现更为复杂的模式。

　　例如，在协议变换后转换格式可以实现规范化适配器 模式，在这种模式中，所有相关方使用的消息和业务对象集都标准化为规范的格式。规范化适配器模式将端点的本机总线附加协议转换为标准协议，实现有效负载规范化，并在交付时进行这些转换的反向转换。

　　另一种常见的复杂中介是转换、记录和路由 模式。

　　网关 模式是一个复杂的协议变换变体。它可以合并转换和监视中介，以提供加密、日志记录或审核等功能。它还可以对一对多关系中的消息进行聚合和反聚合。服务门户是此类模式的代表，它为多个服务提供单一联系点，并隐藏内部服务的细节。

　　部署模式

　　解决方案管理可以选择多种 ESB 拓扑。下面是一些常见的例子：

　　全局 ESB：所有服务共享一个名称空间，每个服务提供者对环境（异构、集中管理但分布在多个地理位置）中所有服务请求者均可见。供部门或小型企业使用，其中，所有服务都可能在整个组织中应用。

　　直接连接的 ESB：公共服务注册中心使几个独立的 ESB 安装中的所有服务均可见。用于由业务部门提供和管理服务但整个企业中均可使用这些服务的场合。

　　代理 ESB：桥接服务有选择地将请求者或提供者公开给其他域中的合作伙伴，从而控制多个 ESB 安装（每个安装都管理自己的名称空间）间的共享。ESB 间的服务交互通过实现桥接服务的公共代理进行。供各个部门使用，这些部门开发和管理自己的服务，但共享其中部分服务或者有选择地访问企业提供的服务。

　　联合 ESB：将多个依赖 ESB 联合到其中的主 ESB。服务使用者和提供者连接到主 ESB 或某个依赖 ESB，以访问整个网络中的服务。供希望在一个监管部门的保护下联合有适度自治权的部门的组织使用。

 

　　图 7. ESB 部署模式
 
　　结束语

　　ESB 模式扩展了 SOA 的虚拟化功能。可以由标准功能单元组成中介，然后进行部署，以帮助不匹配的请求者和提供者进行交互。ESB 还提供了用于部署和管理服务的通用模型。ESB 概念允许根据用户角色单独进行考虑，从而减少了单个工作人员的概念上的负担，并改进了体系结构的可用性。ESB 的综合编程模型、组件化工具以及基础设施极大地支持了 SOA 原则的提前实现。

　　作者简介

　　Beth Hutchison 博士是高级技术人员兼 Web 服务架构师，致力于 IBM 的企业服务总线技术的研究。她一直从事尖端技术领域的工作，最初是第一个分布式平台上的 WebSphere MQ 版本的首席开发人员，随后她担任了 IBM 的 Java 虚拟机的性能架构师。现在她又重新回到 MQ 家族，负责整个 ESB 中的系统管理。
 
　　Marc-Thomas Schmidt 是 IBM 的杰出工程师 (Distinguished Engineer)，已从事了十多年 IBM 的业务集成技术方面的工作，涉及到的领域包括从工作流管理系统，到面向消息的高级中间件，再到业务流程管理技术等方面。他目前负责 IBM 的 ESB 技术的技术架构方面的工作。
 
　　Dan Wolfson 是 IBM 的杰出工程师 (Distinguished Engineer)，在 IBM Software Group 担任 Business Integration Software 的首席技术官。他负责 IBM 的集成软件（运行库和工具）的体系结构和技术策略的制定与实施，并同整个 SWG（特别是 IBM Websphere Business Integration 和 Information Integration 产品）的体系结构与开发团队全面协作。Dan 在商业分布式计算技术的研究方面有 20 多年的经验，涉及的领域包括面向事务和对象的系统、编程语言、消息传递和数据库系统。
 
　　Marcia L. Stockton 在北卡罗莱纳州的三角研究工业园 (Research Triangle Park) 工作，居住在加利福尼亚州，她是 IBM Software Group 的高级技术人员和主要发明人。她也是资深的 IEEE 成员。Marcia 是 Software Group Architecture Board 的 Programming Model Workgroup 的主管，推动横向集成的创新并促进跨 Lotus、Rational、WebSphere、DB2? 和 Tivoli? 产品的编程模型简化。她申请的 73 项 U.S. 专利涵盖的范围从网络、Web、安全、保密、多媒体、无线、普遍设备到无线电频率 ID。最近她致力于为身份管理和边缘服务器分布式编程定义体系结构。她在开发了五年网络软件之后于 1988 加入 IBM。她于 1975 年在 Swarthmore College 获得学士学位。您可以通过 mls@us.ibm.com 与 Marcia 联系。