什么是 ESB？ESB 严格来说不是某一个产品，而是一种框架，设计模式。不同的提供商对 ESB 的理解也各有不同。从 IBM 的立场来说，ESB 不仅仅是一个概念，而是一种中间件模式；它不是某个产品，而是一种全新的集成应用，协调资源和操纵信息的框架。

下面来介绍 ESB 或可以称为 ESB 的中间件产品保护一些特征，有些是必须的，有些是可选的：

1. 连接性

   ESB 必须提供一种支持服务交互的桥梁，它必须支持多协议 (protocol) 之间的连接。不仅要提供对消息和面向事件的中间件的支持，还要提供和现有 EAI 技术的连接。连接性是 ESB 不可缺少的特征之一。

2. 服务交互

   服务交互可以理解为 ESB 的一个目的之一，ESB 作为 SOA 架构的核心，必然要支持服务的交互，要在服务的请求者和提供者架起一个坚实的桥梁，让服务的请求者和提供者只需要关心各自的业务逻辑，而不需要在发布和消费服务的环节花很大力气。服务交互也是 ESB 的必备特征。

3. 集成

   集成的概念是对于系统而言的，ESB 不仅要能集成那些很容易封装服务的系统，也要集成不能方便地封装服务的系统，例如 SAP, ERP, CRM, Siebel 等 EAI 系统、遗留系统。集成也是 ESB 的核心特征之一。

4. 消息处理

   在集成的过程中，必须要面对的是消息处理，在不同的应用系统中，消息的描述格式是不一样的。在集成环境中，必须要提供一种统一的格式来处理系统间的交互，从 ASBO(Application Specific Business Object ) 到 GBO(Generic Business Object) 之间的互转是 ESB 的核心特征之一。

5. 管理

   对于一个具有 ESB 特征的产品，管理也是一个重要的方面。例如，当一个服务从一个地址切换到另一个地址，在结构等不发生任何改变的时候，ESB 产品应该提供一个方便的途径适应这种改变。

6. QoS

   对于服务交互来说，QoS 也是一个重要的特征，比如针对不同的服务请求者提供不同质量的服务响应。有些服务的请求需要在事务中完成，有些服务的交互需要保证其可靠性。一个 ESB 产品应该提供给开发者定义 QoS 的接口。

7. 安全

   安全的必要性不言而喻，系统和系统之间的交互必然需要认证，授权，加密，签名等安全性。一个优秀的 ESB 产品应该提供可靠的，可灵活配置的安全支持。

IBM 有三款 ESB 产品：WebSphere ESB (WESB)，WebSphere Message Broker(WMB)，DataPower。这三款 ESB 产品都提供了 ESB 所必备的特征，但是它们各有侧重，WESB 主要构建与 WebSphere Application Server 之上，侧重于对标准协议和消息的支持，更适合于 J2EE，Web-Service 为主要特征的集成环境；WMB 提供了一个高级的 ESB，它构建于 WebSphere Message Queue 之上，提供了百种以上协议的连接和数据格式的转换机制。Datapower 是一款比较新的 ESB 产品，除了提供必备的 ESB 的特性之外，Datapower 更侧重于安全。众所周知，在 XML 的环境中，安全对于性能的影响是巨大的，Datapower 给企业 ESB 提供了强大的安全保障。

下面对这三款 ESB 产品比较：

总结，WESB 适用于 J2EE 环境下，对性能要求不是很高的，标遵循标准协议的 SOA 集成；WMB 应用更复杂的集成环境，表现为数据格式多种，传输协议多样，性能要求很高；而在安全和性能要求都很高的应用场景下，选择 Datapower 无疑是最好的选择。下面的图表再次对文中的描述进行总结。

• WESB 的优势是提供了和流程服务器 WPS 以及 J2EE 服务器 WAS 良好的整合。WESB 适合使用于对性能要求不是很高，且遵循标准协议的 SOA 整合环境中。
• WMB支持几乎大部分常用的数据格式和协议。并且提供了良好的扩展功能，开发人员可以在 WMB 基础上开发自己的数据格式解析的节点。处理性能较高。适合于信息传输量较大，信息交互频繁的场景中。
• Datapower 使用硬件的 XML 解析和加速器，在性能上有了很大的提高。在安全和性能要求都比较高的环境中，Datapower 是一首选 ESB。

WebSphere ESB 与 SIBus 的比较:
1.WAS v6中的服务集成总线 (SIBus) 技术可以创建ESB。
2.ESB 的基本功能回顾
  总的来说，ESB 通过一组丰富的功能(包括智能路由、协议中介和其他转化机制)集成服务，实现对应用程序之间交互的管理和监视，从而提供了在企业内部和企业之间连接新的和现有软件应用程序的功能。ESB 支持服务可视化，从而在服务请求者和服务提供者之间提供了多方面的分离。
  以下是比较关键的ESB 功能
  1).首先，ESB 能够通过各种方式与服务请求者和服务提供者交互：可以通过持久性消息中枢（特别是 MQ）发送和接收消息，并能够通过 HTTP 和 JMS发送和接收 Web 服务请求和响应消息。
  2).其次，能够在不同消息和传输协议之间转换，如将 HTTP 上的 SOAP 转换为 JMS 上的 SOAP。
  3).然后，能够使用流行的转换语言 XSLT 转换 XML 消息。
  4).能够应用消息中介（如日志记录）。提供高级功能包括消息的监视、在服务注册中心中查询端点和异步请求/响应。
3.ESB 的现有功能：
  1).ESB 非常重视标准，可以对 XML 和 SOAP 提供一流的支持。
  2).ESB 的核心是中介流组件，它是特定类型的 SCA 组件，支持SCA/SDO 编程模型。可以使ESB与WPS组件轻松集成。
  3).ESB 需要SDO 的扩展——服务消息对象（Service Message Objects，SMO）——它使我们能够访问所需的消息上下文和内容。
  4).ESB 需要XSLT转换语言转换 XML 消息。
  5).需要连接不支持现成的 SOAP 或 XML 的现有系统时，WebSphere Adapters 可以为我们节省许多开发时间，因为可以将它们用作能够“连接”到 WebSphere ESB 中介的另一个 SCA 组件类型。
4.ESB 与 SIBus 的比较
  1).ESB 和 WID 提供了 SIBus 没有的功能,SIBus配置过程可能非常麻烦;ESB 可以通过WID进行可视化中介流组件的开发。ESB 支持不同的交互模式与请求和响应消息的自动关联。SIBus只能通过代码实现，开发速度无法比；
  2).ESB的缺省 JMS 提供程序即SIBus的JMS 提供程序，ESB基于WAS，ESB安装也自动含有SIBus功能。
  3).SIBus 中介和 ESB 中介之间的差异,二者的中介框架实现、API、包装和管理模型是不同的。SIBus 和 ESB 将 SDO 用作通过总线的消息流的表现机制。但ESB使用称为 Service Message Objects (SMO) 的 SDO 扩展。
  4).将 SIBus MQLink 与 WebSphere ESB 一起使用,SIBus 通过其 MQLink 功能提供到 MQ 的连接,ESB 也可以使用MQ SCA 本地绑定连接MQ。
  5).SIBus 和 WebSphere ESB 基础结构的共存和集成,ESB 和 SIBus 可以共存，并且可以互相迁移。

面向 ESB 的体系结构：一种错误的采用 SOA 的方式
  面向 ESB 的体系结构并不带来业务价值。基于面向 ESB 的体系结构的项目需要成为基于 SOA 的项目，才能帮助确保成功地提供业务价值。
  SOA 的主要目标是在业务领域与 IT 领域之间保持一致，从而同时提高二者的效率。SOA 基于业务需求。SOA 可保持 IT 与业务的一致性，所以SOA还要有很复杂的分析，而ESB并不需要业务需求来实现服务总线。ESB是在真正需要的时候实现所需的内容，而不要在预计会使用时进行实现。