企业服务总线

简介

如今似乎每个人都需要使用企业服务总线 (ESB)，但关于其实际好处以及这一术语所涉及的各种概念还有诸多困惑。下面这些语句透露出这种不确定性：“求助！老板说我们需要一个 ESB”或者“我究竟为什么需要 ESB？我使用 BPEL 或 BPMN 不能实现同样的功能吗？”甚至是“X 语言能满足我们的一切需要。”本文试图用具体示例回答有关该术语的一些最重要的问题，从而阐明被认为是“正确的”ESB 应用领域。

ESB 的定义到底是什么？是一款产品还是一种架构模式？
ESB 有何实际用途？
我需要用 ESB 构建 SOA 平台吗？
我需要满足什么要求？
我可以用哪些标准来选择最符合我需求的 ESB？

定义 ESB

该术语目前还没有一个公认的定义，很可能是因为缺乏行业标准，然而流程引擎和其他组件却存在 BPEL 和 BPMN 2.0 之类的标准。Gartner 于 2002 年创造了术语“企业服务总线”，分析师 Roy Schulte 进一步引入这个术语来描述当时市场上的一类软件产品。10 年后，关于 EBS 到底是什么或者它应该提供什么依然没有达成共识。根据制造商和来源的不同，有很多不同的定义。其中，ESB 的定义包括：

“一种集成架构样式，支持提供者和服务用户之间通过由各种点对点连接构成的公共通信总线进行通信”

“企业用来集成应用程序环境中服务的基础架构。”

“一种架构模式，使用面向服务支持异构环境之间的互操作性。”（图 1）

图 1：ESB 架构模式分成这几个主要系统架构
现在市场上提供的 ESB 在系统架构方面有着本质区别。如上图所示，它们主要基于以下架构：

扩展的面向消息的中间件 (MOM)

这些系统对应于 ESB 的原始定义，通常在整个网络中分布多个节点，使用一个 MOM 基础架构支持节点之间可靠的消息传递和事件驱动处理。尽管 ESB 使用专用协议进行通信，但服务端点不需要知道 MOM。可以使用 WSDL 或其他协议公开服务。

扩展的集成代理

过去 5 年间，传统的集成代理供应商逐渐加大了对 Web 服务的支持，并将其产品重新定位为 EBS。这些系统与之前的系统相比更符合标准，但与大多数 ESB 相比仍然更倾向于专用。它们还倾向于提供高度集中化的解决方案，所有消息均通过一个中心代理进行传递。

扩展的应用服务器

许多 ESB 供应商使用 Java EE 应用服务器作为其 ESB 产品的基础。这些产品在服务创建和组成方面通常比原有集成更强大。尽管它们也支持分布式节点，但它们往往都比较集中。

基于端点的插件通道

有几个 ESB 供应商支持极度分布式模型，该模型在服务端点实现服务调节，使用通道插件架构支持异构通信。

调节代理

尽管这些产品从技术上来说不能算是 ESB，但是因为提供了一个服务平台，据我们所知，目前已有多家供应商将此类产品列为 ESB。调节代理可以是集中式的或分布式的，支持服务调节。也有相关的产品类别可实现部分 ESB 功能，但是制造商不能将其作为 ESB 正式销售 [REF-1]。

XML 网关

XML 网关硬件设备主要支持服务调节，这是 ESB 的主要特性之一。事实上，XML 网关通常支持 ESB 不支持或无法支持的服务调节功能，如转换加速以及 XML 文档加密和解密。但是，XML 网关不提供服务平台，这是一个通常与 ESB 相关联的特性。

面向消息的中间件 (MOM)

面向消息的中间件基于消息的异步发送和接收，在应用程序之间提供更松散的耦合。尽管没有定义消息格式，但实际上 XML 已成为首选格式。MOM 产品通常支持通过消息队列以及发布/订阅进行通信。MOM 中通常不提供消息转换，MOM 的应用程序接口相对比较复杂且不够规范。MOM 可以用作通过 EBS 进行可靠消息转发的基础。

集成代理 (EAI)

现在，一些传统 EAI 工具开发人员将其产品定位为 EBS。这些产品通常比较复杂并且是专用的，通常基于一个集中星型架构。代理充当中央消息交换器（中央节点），发送者和接收者（远端节点）呈放射状分布。可通过支持所需消息格式的适配器端口连接到代理。

业务流程管理系统 (BPMS)

一些 ESB 开发人员将服务编排和自动化业务流程管理（BPEL、BPMN）看作是 ESB 特征，其他人则认为服务总线是一个独立产品，属于 BPMS 类别。尤其是在用流程模型或“编制引擎”类别表达业务方面时，技术集成流程可以表示成一个以不同顺序调用服务的长流程链。

应用服务器

许多 ESB 平台都提供一个服务平台来构建和托管服务。在这种情况下，ESB 还是一个应用服务器。许多应用服务器提供容器来操作服务，还提供一个受限功能来处理消息和执行策略。应用服务器适配器支持通过 Java EE Connector Architecture (JCA) 之类的技术集成原有系统。大多数情况下，应用服务器仅支持几个协议，很难精确分离 ESB 和应用服务器。许多开发人员需要一个应用服务器作为其 ESB 基础。

API 网关

企业和组织的目标是以一种易于使用的标准化方式、以 API 形式向业务合作伙伴和客户公开部分关键服务的访问。这意味着 API 网关可以解决出现的各种安全性、性能和集成问题。API 网关具备威胁保护功能，可确保服务质量。API 网关不是 ESB，但在功能方面有一定重叠，比如转换和路由。

一般来说需要注意的是，向外界公开服务时，API 网关是一个需要考虑的工具。如果位于内联网外部，通常是在 DMZ 中。它只管理正在与外部通信的服务子集。

ESB 用于服务虚拟化，通常管理更大的服务集且位于内联网内部。

何时使用 ESB？

有没有确定何时应使用 ESB 实现的最佳实践？需要集成三个或更多的应用程序或服务时，可以考虑使用 ESB。连接两个应用程序时，点对点集成非常简单且更经济划算。如果要从企业无法控制的外部服务提供者处获取服务，也可以考虑使用 ESB。然后，可以使用 ESB 监视外部提供者保证的服务级别协议。可进一步将服务合同调整的影响控制到最小，因为 ESB 对消息进行必要更改的同时将继续提供一个稳定的接口。

如果要使用多种不同协议（如 HTTP、SOAP 和 FTP）并将它们标准化成一个协议（如 SOAP），ESB 可以执行必要的协议转换。如果始终需要将服务合并成一个架构才能够接收、处理和生成消息，那么使用 ESB 也比较合适。如果需要访问一组预定义的组件和适配器，ESB 也同样适用，这将支持以标准化方式集成各种协议和原有应用程序。如果需要安全、可靠地处理消息，ESB 可以简化两个异构事务性数据源之间事务性消息流的实现。

如果需要通过总线将大量数据作为大量独立消息进行发送，那么使用 ESB 可能存在一些问题。ESB 绝不应取代传统数据集成，比如 ETC 工具。将数据从一个数据库复制到另一个数据时，使用数据集成可能更高效，因为该操作只会不必要地增加 ESB 的负担。

如果需要实现长期业务流程，ESB 应支持无状态的消息流。长期运行的业务流程是有状态的，最好使用 BPEL 和/或 BPMN 实现。这些流程通常无法通过 ESB 实现，但可以通过业务流程管理系统 (BPMS) 实现。

ESB 蓝图

由于缺乏标准化，ESB 市场相当混乱。很多产品自称是 ESB，但是提供的解决方案却大相径庭，而且基于不同的架构。为了更有效地评估 ESB 产品，我们将分配给 ESB 的各种功能组织成了一个蓝图（图 2）。

ESB 蓝图不包括“编排”或“流程编排”组件，因为这被视作 BPMS 类别的一部分。它们为长期运行的、有状态的业务流程提供专用的运行时环境，这些流程为此进行了优化，支持 BPMN 或 BPEL 之类的语言。ESB 应该是无状态的，并且应配置为尽可能高效地处理消息。

操作和管理模块

该模块中的以下功能组件支持可靠的企业服务总线操作和管理。统计信息与状态 提供服务的 ESB 统计信息，如错误数量、最小和最大响应时间以及处理的消息数。警报 提供一个发送警报消息的机制，可通过各种通道发送，因此也可以集成到现有监视环境中。SLA 规则 是在统计信息与状态 功能组件的信息基础上定义的规则。支持度量和监视 SLA。可以使用警报 组件通知任何 SLA 侵权。

消息跟踪 可以在 ESB 中轻松跟踪消息，应在需要时激活，以便将相关开销降至最低。消息重新传递 确保在预定义时间后自动重新发送未及时处理的消息。可以配置尝试次数以及它们之间的时间间隔。该组件主要适用于仅持续一段时间的技术错误，如临时网络中断。端点故障切换 可以指定一个备用服务提供者，在主服务提供者不可用时自动调用。

负载平衡 可以列出一个逻辑服务提供者端点的几个服务端点。它使用冗余服务实现，根据定义的策略交替调用每个请求，可以循环调用，也可根据消息优先级和负载依赖关系进行调用。

消息限制 可以定义应被发送到服务提供者的服务端点的每单元时间内的最大消息数。它通过缓冲 ESB 队列中超过阈值范围的消息来防止服务提供者在高峰时段重载。消息限制 还支持消息优先级，这样可以确保始终先处理高优先级的消息。记录与报告 支持记录消息，方便以后显示。它还提供功能审计。

配置管理 支持在操作系统上安全地调整 ESB 配置，同时始终维护配置的完整性。可在操作过程中调整和替换构件和属性。还可以保存变更历史记录，这样 ESB 服务可以随时回滚到早期状态。服务注册表 可以在 ESB 上注册和管理服务。高可用性 确保 ESB 提供的服务是故障安全的，与运行这些服务的服务器的状态无关。

错误医院 是那些经过多次重新传递尝试仍无法处理的消息的目的地，可以在这里查看、更正（如果需要的话）以及重新处理这些消息。部署 可在 ESB 上自动安装服务。特定于环境的参数（如端点 URI）通常是由该组件重写的。服务使用情况 支持记录服务使用情况并向用户收取费用。

调节模块

调节模块包含用于实现 ESB 服务消息流的功能组件。消息路由 支持根据消息的内容将消息其转发至特定服务端点。如果使用的协议或消息格式支持与消息正文无关的消息头区域，转发标准可能源于消息正文或消息头。

根据消息头进行路由可能是一个极具吸引力的选择，可提高服务性能和可扩展性，因为直接访问消息头比解析来自消息正文的路由信息更高效。这对于大型消息来说尤其重要。

消息转换 支持从一种消息格式转换为另一种适用于文本和二进制消息的格式以及 XML 格式。此外，还可以从文本（如 CSV 格式）转换为 XML，或者从 XML 转换为文本（如 CSV 格式）。XML 转换使用著名的 XSLT 标准，XSLT 支持对转换进行声明性描述，并且拥有带拖放功能的图形资源以实现创建目的。

XSLT 转换的主要缺点是，如果处理大型文档，内存使用量过高，这可能会限制解决方案的可扩展性。如果 ESB 提供支持 XML 流转换的选项（比如，通过 XQuery），那就更好了。

服务调出 可以在 ESB 中访问消息流中的其他服务，比如增强一条消息。服务可能是一个 Web 服务，但 ESB 可以如您所愿地支持直接调用 ESB 中本地安装的程序代码（如 Java 类方法）。可靠的消息传递 支持使用队列或 WS* 标准（如 WS-ReliableMessaging）可靠地传递消息。

协议转换 意味着无需任何编程工作即可从某个通信协议切换到另一个协议，比如，从 TCP/IP 切换到 HTTP。消息验证 确保消息是有效的。在 XML 中，这意味着消息包含规范定义的 XML 并对应于特定的 XML 模式或 WSDL。不过，ESB 还提供了其他验证方法，如 Schematron 或规则引擎。

消息交换模式 (MEP) 支持消息交换模式，如同步和异步请求/应答、单向调用以及发布/订阅。结果缓存 可以在缓存中保存服务调用结果，这样返回同样结果的后续调用可从缓存获得应答，无需再次调用服务。如果数据是静态的或者需要零星或少许的改动，此功能尤为适合。可大大减少像访问原有系统这样的开销可能较大的操作。

事务 支持 ESB 通过消息处理提供事务完整性。ESB 用于支持可靠消息传递 的持久队列通常作为事务数据源，因此可参与异构事务。此外，ESB 还提供了一个分布式事务管理器，可使用两阶段提交协议通过异构数据源协调分布式事务。

消息重新排序 使属于一个整体但顺序不对的消息流可以重新排序。在并行处理消息的面向消息的解决方案中，消息进入 ESB 的顺序可能会丢失。如果顺序对于服务提供者很重要，消息重新排序 可以合并到消息流中。重新排序器包含一个内部缓冲区，缓冲区对消息进行处理，直至排序完成且可发送。

直通式消息传递 可以令 ESB 高效转发 ESB 消息。如果要将 ESB 用于服务虚拟化，并且将消息从服务使用者原样转发至服务提供者，这将非常有用。在这种情况下，如果 ESB 不接触消息，只是简单地按原样传递，该功能非常适用。

安全模块

该模块使用大量组件支持传输级和消息级安全性。当服务使用者访问 ESB 中的服务时，身份验证 验证其身份，并验证针对服务提供者的 ESB 身份验证。授权 为服务提供了一个授权系统，通常可通过 XACML 对这些服务进行配置，以便分配给用户或角色。

安全调节 支持交互，通过将一个域的凭证转换成另一个域的相应凭证在安全域之外进行通信。加密/解密 支持消息内容的加密和解密。

适配器/传输模块

该模块包括的适配器可通过服务托管模块连接 ESB 提供的服务。假设 ESB 从无到有提供一组适配器，客户或第三方开发人员还可以开发其他适配器以满足具体的用户需求。

服务托管模块

该模块支持在 ESB 上直接安装和操作服务，如果 ESB 基于应用服务器，该模块通常是必需的。服务容器 提供一个或多个容器，在其中安装服务和管理生命周期。它提供可访问技术横截面功能（如事务和安全性）的服务。

组件模型 提供了一个抽象的组件模型（如 Java EJB、Java Spring Framework 或 Microsoft COM+），在此基础上创建服务。

ESB 的实际应用场景

图 3 所示的符号用于以图形化方式描述各种场景，无需参考产品或工具。这些符号来自于 [1]，根据 ESB 功能不断添加。

图 3：ESB 符号
场景 1 — 服务虚拟化
服务使用者往往更喜欢硬连接实际服务端点，特别是在 BPEL 流程中，因为使用提供的工具可轻松执行。然而，在运行时对服务器地址的改动绝对不能产生需要在服务客户端进行重新部署的改动。这个问题的一个非常好的解决方案是使用 ESB 虚拟化端点。图 4 展示了这个场景，服务提供者提供的 Web 服务接口不再由服使用者直接使用，而是通过 ESB 来使用。ESB 可以完全按照为潜在的服务使用者提供接口那样提供接口。

图 4：使用额外的监视拦截器虚拟化服务
在 ESB 配置过程中可以轻松实现需要对端点地址进行的任何改动，因此服务使用者可以像以前一样继续运行。然而，ESB 需要能够合并到现有消息流中。服务虚拟化还支持使用扩展到服务统计信息的 ESB 监视功能，以便检查 SLA 合规性，如果不合规的话，则配置适当的操作。如果服务提供者对服务合同进行了更改但不想影响服务使用者，可以执行服务虚拟化。在这种情况下，对交换的消息进行简单的转换即可解决此问题。

场景 2 — 服务支持
当纳入具有功能接口的服务时，通常会出现的情况是，服务使用者和服务提供者在协议级别使用不同的语言。图 5 介绍了两个服务提供者，从技术上来说它们提供的是相同的服务，一个提供的是 SQL 接口，另一个提供的是 FTP 接口。可以将企业服务总线用作协议转换器以保持接口不变，因为它提供的方法可确保使用定义的接口。

图 5：服务支持
与场景 1 类似，如果通信协议将来发生变化，ESB 可确保服务使用者或服务提供者端无需后续更改。

场景 3 — 安全的消息处理
ESB 还能支持传统集成场景，主要目的是将消息从一个系统转发到另一个系统。在图 6 所示的场景中，ESB 使用来自外部队列的消息，使用对一个 Web 服务的服务调出来丰富这些消息，然后通过数据库适配器将消息发送到目标系统。

图 6：安全的消息处理
ESB 中的处理是事务性的，意味着将消息流配置为像其他参与者一样参与分布式 XA 事务。使用队列中的消息时将启动事务，事务还包含数据库适配器执行的数据库操作。如果消息流成功完成，紧接着会提交分布式事务。

场景 4 — 服务版本控制
服务往往随着时间而改变，通常需要引入一个新的不兼容版本。在这些情况下，可以使用 ESB 执行从“旧”接口到“新”接口的转换。在图 7 所示的场景中，服务提供者引入了服务的 2.0 版本，服务使用者 B 立即安装了该版本。服务使用者 A 一直使用接口 1.0，不想切换到 2.0 版本，因为不会给业务带来任何附加值。然而，服务提供者不想让这两个版本并行运行。同时运行两个接口可能比较困难，甚至在技术上不可行，而且会导致不必要的资源消耗。

图 7：服务版本控制
如果 ESB 通过直通式传递（类似于场景 1）直接提供 2.0 版本，情况可能比较简单。同时，在适应现有消息流的同时必须提供接口 1.0 版本，这样将不再从服务提供者处调用 1.0 版本。相反，消息是从 1.0 版本转换到 2.0，然后发送给新服务。这种转换可能相对比较复杂，具体取决于两个版本之间的差异有多大。为了提供调用 2.0 版本所需的所有信息，可能需要额外丰富 1.0 版本消息。

需要维护 ESB 中的转换和接口 1.0，直至没有服务使用者使用旧接口。之所以在 ESB 中执行这种转换而不是在服务提供者中从版本 1.0 映射到 2.0，具体原因如下：

映射是技术问题，与业务相关问题无关
不会影响外部服务提供者。
ESB 使旧接口的使用透明。
当所有服务使用者都改用接口 2.0 后，无需更改服务提供者。
总结
ESB 是一个中间件解决方案，使用面向服务的模型来促进和支持异构环境之间的互操作性。没有规范准确定义了什么是 ESB 或者它应该提供什么功能。虽然 ESB 主要与“调节”和“集成”这类概念相关，但它还适合作为一个平台以类似于应用服务器的方式提供服务。ESB 代表被称作“集成”和“应用服务器”的产品类别的整合。

ESB 的一个关键特性是服务虚拟化。本文提出的 ESB 蓝图提供了各种功能的有序排列，构成了评估 ESB 产品的基础。

要点
企业服务总线应被视为一个架构样式或模式，而不是一款产品。
ESB 没有定义或规范，因此也没有标准。
ESB 可帮助实现系统间的松散耦合。
ESB 上的服务是无状态的。长期运行的流程不属于 ESB，但是在使用 BPEL 和 BPMN 之类语言的 BPM 系统中受支持。
“误用”ESB 来执行批处理时应小心谨慎，因为可能会对性能产生负面影响。

转自
http://www.oracle.com/technetwork/cn/articles/soa/ind-soa-esb-1967705-zhs.html