思考：
1.ESB的定义到底是什么？是一款产品还是一种架构模式？
2.ESB有何实际用处？
定义ESB
对于企业服务总线（Enterprise Service Bus），目前还没有公认的定义，根据供应商和来源的不同，有很多种不同的定义，其中包含如下定义：
一种集成架构样式，支持提供者和服务用户之间通过由各种点对点连接构成的公共通信总线进行通信”
“企业用来集成应用程序环境中服务的基础架构。”
“一种架构模式，使用面向服务支持异构环境之间的互操作性。”（图 1）
图 1：ESB 架构模式分成这几个主要系统架构
ESB 用于服务虚拟化，通常管理更大的服务集且位于内联网内部。
何时使用ESB？
有没有确定何时应使用ESB实现的最佳实践，需要集成三个或更多的应用程序或服务时，可以考虑使用ESB。连接两个应用程序时，点对点集成非常简单而且更经济划算。如果要从企业无法控制的外部服务提供者获取服务，也可以考虑使用ESB。然后，可以使用ESB监视外部提供者保证的服务级别协议。可进一步将服务合同调整的影响控制到最小，因为ESB对消息进行必要更改的同时将继续提供一个稳定的接口。
如果使用多种不同协议（如果：http、SQAP和FTP）并将它们标准化成一个协议（如SOAP），ESB可以执行必要的协议转换。如果始终需要将服务合并成一个架构才能接收、处理和生成消息，那么使用ESB也比较合适。如果需要访问一组预定义的组件和适配器，ESB也同样使用，这将支持以标准化方式集成各种协议和原有应用程序。如果需要安全、可靠地处理消息，ESB可以简化两个异构事务性数据源之间事务性消息流的实现。
如果需要通过总线将大量数据作为大量独立消息进行发送，那么使用 ESB 可能存在一些问题。ESB 绝不应取代传统数据集成，比如 ETC 工具。将数据从一个数据库复制到另一个数据时，使用数据集成可能更高效，因为该操作只会不必要地增加 ESB 的负担。
如果需要实现长期业务流程，ESB 应支持无状态的消息流。长期运行的业务流程是有状态的，最好使用 BPEL 和/或 BPMN 实现。这些流程通常无法通过 ESB 实现，但可以通过业务流程管理系统 (BPMS) 实现。
ESB 蓝图
由于缺乏标准化，ESB 市场相当混乱。很多产品自称是 ESB，但是提供的解决方案却大相径庭，而且基于不同的架构。为了更有效地评估 ESB 产品，我们将分配给 ESB 的各种功能组织成了一个蓝图（图 2）。
图 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 来执行批处理时应小心谨慎，因为可能会对性能产生负面影响。
参考资料
[REF-1] http://www.oracle.com/technetwork/cn/articles/soa/ind-soa-esb-1967705-zhs.html