表 1：在现有的文献中定义的 ESB 功能

通信	服务交互
路由 寻址 通信技术、协议和标准（例如 IBM® WebSphere® MQ、HTTP 和 HTTPS） 发布/订阅 响应/请求 Fire-and-Forget，事件 同步和异步消息传递	服务接口定义（例如，Web 服务描述语言（Web Services Description Language，WSDL）） 支持替代服务实现 通信和集成所需的服务消息传递模型（例如 SOAP 或企业应用程序集成 (EAI) 中间件模型） 服务目录和发现
集成	服务质量
数据库 服务聚合 遗留系统和应用程序适配器 EAI 中间件的连接性 服务映射 协议转换 应用程序服务器环境（例如 J2EE 和 .NET） 服务调用的语言接口（例如 Java 和 C/C++/C#）	事务（原子事务、补偿、Web 服务事务（WS-Transaction）） 各种确定的传递范例（例如 Web 服务可靠消息传递（WS-ReliableMessaging）或对 EAI 中间件的支持）
安全性	服务级别
身份验证 授权 不可抵赖性 机密性 安全标准（例如 Kerberos 和 Web 服务安全性（WS-Security））	性能 吞吐量 可用性 其他可以构成契约或协定的持久评估方法
消息处理	管理和自治
编码的逻辑 基于内容的逻辑 消息和数据转换 有效性 中介 对象标识映射 数据压缩	服务预置和注册 记录、测量和监控 发现 系统管理和管理工具的集成 自监控和自管理
建模	基础架构智能
对象建模 通用业务对象建模 数据格式库 B2B 集成的公共与私有模型 开发和部署工具	业务规则 策略驱动的行为，特别是对于服务级别、服务功能的安全和质量（例如 Web 服务策略（WS-Policy）） 模式识别

    上面的许多功能既可以使用专有技术实现，也可以通过利用开放标准实现。然而，使用不同的技术来实现 ESB 可能会使它们的性能、可伸缩性和可靠性这些特性显著不同，同时 ESB 功能和所支持的开放标准也会有所不同。由于这些原因，再加上最近制订和正在兴起的一些相关标准，当今实现 ESB 的许多关键决策都涉及到成熟的专有技术和不成熟的开放标准之间的权衡。

    在本系列文章中，我们不打算详细讨论上面的每一个功能类别。相反，我们将集中讨论采用或实现 ESB 的不同方法之间的驱动策略。特别是在下一部分，我们将讨论 ESB 为支持 SOA 所需的最低功能由什么构成。

    支持 SOA 的最低功能的 ESB 实现

    如果在前面确定的功能中只有一部分和大多数 SOA 场景相关，我们可能会问：实现 ESB 所需的一组最低功能由什么构成？为此，考虑最被普遍认同的 ESB 定义的原理：

    1.ESB 是一种逻辑体系结构组件，它提供与 SOA 的原则保持一致的集成基础架构。
    2.SOA 原则需要使用与实现无关的的接口、强调位置透明性和可互操作性的通信协议、相对粗粒度和封装可重用功能的服务定义。
    3.ESB 可以作为分布式的异构基础架构进行实现。
    4.ESB 提供了管理服务基础架构的方法和在分布式异构环境中进行操作的功能。

    表 2展示了根据这些原则定义的最低 ESB 功能

    表 2: 最低的 ESB 功能

通信	集成
提供位置透明性的路由和寻址服务 控制服务寻址和命名的管理功能 至少一种形式的消息传递范型（例如，请求/响应、发布/订阅等等） 支持至少一种可以广泛使用的传输协议	支持服务提供的多种集成方式，比如 Java 2 连接器、Web 服务、异步通信、适配器等等
服务交互
一个开放且与实现无关的服务消息传递与接口模型，它应该将应用程序代码从路由服务和传输协议中分离出来，并允许替代服务的实现。

    请注意这些最低功能并不需要使用特别的技术，比如 EAI 中间件、Web 服务、J2EE 或 XML。这些技术的使用非常接近也非常符合需求，但是不必强制要求使用它们。相反，最低功能几乎只需简单地使用 SOAP/HTTP 和 WSDL 就可以实现（当然不是所有的情况都这样）：

    1.URL 寻址和现有的 HTTP 和 DNS 基础架构提供了一个具有路由服务和位置透明性的“总线（bus）”。
    2.SOAP/HTTP 支持请求-响应（Request-Response）通信规范。
    3.HTTP 传输协议被广泛地使用。
    4.SOAP 和 WSDL 是开放、与实现无关的服务通信和连接模型。

    然而，这些 SOAP/HTTP 和 WSDL 的基本应用只是点到点（point-to-point）的集成，并不能实现一些 ESB 需要的关键功能：

    1.目前还没有用于控制服务寻址和命名的管理功能。服务名称通过每个适配器单独进行控制的，服务路由控制则分散在由服务客户端调用的地址、HTTP 基础架构和分配给适配器的服务名称之间。
    2.虽然这种方法依赖于实现细节，但是它往往并不能使服务实现的替代变得简单；服务请求者代码（也可能是开发工具生成的）通常通过特定地址的特定协议直接绑定到具体的服务提供者实现。如果想要用另一个服务实现来替代原来的服务实现，就需要修改应用程序代码并重新部署这些代码。

    当然，在许多甚至是大多数情形中往往需要其他的功能，并且这种需要变得越来越常见。特别地，不管是现在还是以后，下面的需求类型可能会导致更复杂高级的技术的使用：

    1.服务质量和服务级别功能。
    2.高级 SOA 概念，例如服务编排、目录、转换等等。
    3.按需操作环境需求，比如管理与自治功能以及基础架构智能功能。
    4.跨越具有不同所有权的多个网络、多个协议以及多个域的真正意义上的异步操作。 

    影响 ESB 的安全问题

    我不想在这里直接提出安全需求，不过它们对选择 ESB 的实现技术非常重要。例如，如果服务请求不需要提供身份验证或授权，实现技术的选择就可以非常的广泛。更有可能的情况是，如果需要一些安全级别，则评估什么形式的安全是可以接受的就非常重要。例如：

    1.是否可以接受通信基础架构中的安全性，例如，是否在 EAI 中间件服务器之间使用安全套接字层（Secure Socket Layer，SSL）互相验证，或者是否在使用 HTTPS 协议？
    2.是否可以接受在参与系统之间单独的点到点（point-to-point）安全性，或者是否需要端到端（end-to-end）模型？例如，是否有必要通过类似于代理的中间件系统来把客户端身份传递到服务实现的最终提供者？
    3.是否可以接受应用层中的安全性，例如，客户端代码是否能够执行带有用户 ID 和密码的基本 HTTP 身份验证，或者是否能够把这些信息作为应用程序数据传递给服务？
    4.是否需要遵守行业安全标准，例如 Kerberos 或 WS-Security？
   
    虽然所有这些都是可能的，但是行业的发展方向是基础架构和中间件支持的符合标准的安全性（例如 Web 服务安全性（WS-Security））功能。然而，相比之下，这些安全标准也是最近才提出的，而且对它们的产品支持仍在发展的过程中，而不是已经确定了，这里尤其需要特别考虑的就是它们的互操作性。因此，任何 ESB 架构都需要尽可能早地确定安全需求，以便在选择实现技术时可以将它们包括进来。

    结束语

    在本文中，我讨论了大多数通用的 SOA 原则，以及它们与 Web 服务技术的关联。基于这些原则，我提出了需要一个基础架构组件，这个组件可以提供路由功能，以便使服务能够彼此交互，同时还能够支持使用另一个服务实现来替换原有的服务实现。这些功能都是通过 ESB 实现的。

    ESB 在维持集中控制的同时提供分布式的基础架构，因而需要一些形式的服务路由目录，并且还可能需要业务服务目录。Business Service Choreographer 从 ESB 调用服务，然后通过 ESB 把这些流程作为新的服务公开。

    ESB 的许多功能包括提供：

    1.通信
    2.服务交互
    3集成
    4.质量服务
    5.安全
    6.服务级别
    7.消息处理
    8.管理及自治服务
    9.建模
    10.基础架构智能

    从这些不同的功能中，我确定了建立 ESB 所需的最低功能，包括通信、集成和服务交互。

    在这个系列的下一个部分中，我将讨论一些通用的场景，以及与这些场景相关的解决方案模式，同时指出影响这些场景最一般的问题。