ESB 综述 1：定义 ESB

Accenture 首席技术官 Don Rippert 的近期访谈的主题是：激活 SOA 的全部潜力还需五年。但是，访谈中隐藏着一个简单的论断，即使用企业服务总线（Enterprise Service Bus，ESB）是实现 ESB 全部潜力 4 步中的第三步。Don Rippert 模型中的步骤如下：

1. 使用 XML，以更标准的方式使用应用程序接口。
2. 捕获一些业务过程，并将它们转化成为 Web 服务。
3. 引入并全面使用企业服务总线。
4. 产生业务过程执行语言（Business Process Execution Language，BPEL），它可由业务过程建模工具完成。BPEL 可以改变应用程序的行为，而无需修改软件。

Rippert 先生在采访中表示，尽管很多组织拥有 ESB，但是它并没有被完全利用。他进一步的表示，大多数公司仍处于阶段 1。与这个 ESB 所处位置的论断相对比的是， Burton Group 的分析师 Anne Thomas Manes 的叙述，其发表于近期面向服务架构 Yahoo Group 的讨论中。Anne 说：

…如果缺少我推荐启动 SOA 的“基本组件”，ESB 将不会列在我的清单中。事实上，我并不鼓励人们由 ESB 开始。ESB 并不会鼓励好的 SOA 行为。ESB 本质上是集成系统，而非 SOA 系统。SOA 是用于拆卸应用竖井（application silos），而集成系统则是修补这些竖井。

引用她的书，她接着提及的基本组件包括：

• 一个或多个服务平台（如，.NET，Java EE 应用服务器等）
• SOA 管理解决方案
• 注册表
• 如果服务要被暴露在防火墙之外，那么需要 XML 网关

引用组员早期的帖子，她说道：

“…ESB 特别适合桥接传统应用，因此，在服务基础设施中，它是一个有用的组件。很多 ESB 也支持可靠消息传递、异步消息传递和发布 / 订阅交换模式。这些能力都非常有用，但是，在 SOA 项目的初始阶段可能不会发挥多大的用途。（每个组织有很多不选用这些能力的项目。）在 SOA 项目的后期，你还可能需要一个编制（orchestration）引擎，并且大多数的 ESB 都会提供一个。即便如此，ESB 也绝对不是组织启动 SOA 的起点。所有这些能力你一开始并不需要。因此，ESB 应该在后期购买。”

这似乎符合 Rippert 先生的观点，即尽管很多组织拥有 ESB，但是它并没有被完全利用。Manes 女士的评论同样有助于定义 ESB 的范围，通过暗示许多 ESB 支持的特性，它确定了一组适当的能力。

根据维基百科的 ESB 定义，ESB 有如下特性：

1. 它是面向服务架构的实现。
2. 它通常是操作系统和编程语言无关的；它应能在 Java 和.Net 应用程序之间工作。
3. 它使用 XML（可扩展标识语言）作为标准通信语言。
4. 它支持 Web 服务标准。
5. 它支持消息传递（同步、异步、点对点、发布 - 订阅）。
6. 它包含基于标准的适配器（如 J2C/JCA），用于集成传统系统。
7. 它包含对服务编制（orchestration）和编排（choreography）的支持。
8. 它包含智能、基于内容的路由服务（itenerary 路由）。
9. 它包含标准安全模型，用于 ESB 的认证、授权和审计。
10. 它包含转换服务（通常是使用 XSLT），在发送应用和接收应用之间转换格式，简化数据格式和值的转换。
11. 它包含基于模式（schema）的验证，用于发送和接收消息。
12. 它可以统一应用业务规则，充实其它来源的消息，分拆和组合多个消息，以及处理异常。
13. 它可以条件路由，或基于非集中策略的消息转换，即不需要集中规则引擎。
14. 它可监视不同 SLA（服务级别合约）的消息响应门限，以及在 SLA 中定义的其它特性。
15. 它（常常）简化“服务类别”，向更高或更低优先级用户做出适当的响应。
16. 它支持队列，在应用临时不可用时用来保存消息。
17. 它由（地理）分布式环境中的选择性部署应用适配器组成。

维基百科的定义容许“ESB 精确定义的变种”。

Manes 女士和 Rippert 先生似乎都同意 ESB 是有用的，并代表项目后期用于部署 SOA 的功能集合。维基百科的定义可以作为讨论的起点，主题是关于如何定义这一有用技术。

在随后的讨论中，请关注 ESB 的定义，而非本文中引证的业界专家的观点。

查看英文原文： ESB Roundup Part One: Defining the ESB