以 ESB 为导向建立 SOA 是有害的

Bobby Woolf 是《Enterprise Application Integration Patterns》的合作者，也在 IBM 任职 WebSphere SOA 与 J2EE 顾问，他写了一篇文章来质疑把 ESB 当作 SOA 的实现基础是否正当（参阅文后注释 *）。

客户常常希望单纯构建 ESB，因为这样可以避开难搞的业务需求，专心解决技术上的挑战。单纯构建 ESB 是 IT 人员的梦想，这样他们可以先建立 ESB，然后指望以后会有 SOA 跟上来利用它。这种以 ESB 为导向的架构丢掉了 SOA 的优势。这种架构没有产生业务价值。实际上，花费了成本却没有收获直接的利益。

Bobby 的文章写得很风趣。但引发的争论是严肃的，而且自 Dave Chappell 发明出“连接优先（Connectivity-First）”这个新词组，争论就愈演愈烈。跟契约优先（Contract-First）这个词组类似，部署 ESB 就像以“连接优先”的方式开始你的 SOA。Bobby 认为以 ESB 为导向的架构方式

……有其固有的缺陷，它建立的连接性可能根本就没有人打算去用……只有当你实际需要一样东西，才去实现它，决不要仅仅因为你预见到未来的需要。

OASIS 的《 SOA Reference Model 》并没有确切提到“连接性（connectivity）”，但它提出了通讯基础设施的概念：

通讯基础设施的主要任务是促进信息以及意图的交换……特别是当交换的发生跨越了所有权边界的情况下，对数据的解释是一个关键问题。对数据的解释必须在服务交互的参与者当中保持一致。

习惯上 SOA 架构参考，包括来自 IBM 的参考在内，总是把 ESB 放在一个显著的地位上。Dave Chappell解释了 ESB 在本质上是一个服务容器，附带有专门的通讯基础设施，用来连接同处在一个容器内的服务。

服务容器是抽象的服务端点（endpoint）的具体表现，它实现了服务接口。服务容器是一个能让服务组件寄宿其中的远程进程。从这个角度来说，它跟应用服务器容器有几分相似，只不过它的专门目的是寄宿集成的服务。

别让 Bobby 的幽默掩盖了他的观点。Bobby 不同意 Joe McKendrick 和 Dave Linthicum 把他的观点解读成 ESB完全无用。而我自己多年前也写过一系列文章，题为《跳下公共汽车（总线），打辆的》，我在其中质疑了对通用的通讯机制的需要。不过，带有专门的通讯基础设施（如Dave Chappell 所描述）的服务容器仍然是非常有用的，JBI 规范的领导 Ron Ten-Hove 解释说：

• 服务容器常常把各种 IT 资产连接到 ESB 上，

而 ESB：

• 具有可靠的消息系统，以供服务容器交互。
• 提供消息转换服务。
• 提供消息路由服务。
• 为控制对服务的访问提供安全功能。
• 可被集中管理，虽然它是一个分布式系统。
• 允许对服务的渐进式改变，而不需要停机或者其他对系统可用性的干扰。

这些功能（以及其他更多功能）对于很多类型的服务来说都是基本的要求。CBDIForum 的 D. Sprott 就列举了一系列模式，如果没有ESB 将很难实现它们。比如用ESB 的路由机制来实现服务版本化（Service Versioning）的策略。

当然，随着WS-* 标准集逐渐完整（WS-TX 已经完成，可靠消息通讯也接近完成**），会抢掉通讯基础设施的一点点风头，但一个高效的服务容器仍然是成功的企业级SOA 的关键。如果厂商们开始大谈他们的“服务容器”而非“总线”，我也不会感到奇怪。毫无疑问，你会开始把各种功能装进服务容器。

Bobby 的文章幽默地表达了作为顾问的失落，当面对着一些对 SOA 一知半解的 IT 组织，为了跟上荒唐的进度要求，在压力驱使下试图表现出任何形式的进步。毫无疑问，最终完成的一堆毫无业务价值的东西，会被怪罪到顾问身上。我觉得 Bobby 给我们提了个醒，我总结如下：“不顾情况，一味使用 ESB 可能是有害的”。这句话可能对任何技术都成立。

*Bobby 对他的文章作了一些澄清：“ESB 是好的；单纯的 ESB 项目是坏的。让架构围绕服务，而非总线。这样说够清楚了吧？！:-)”

** 如同 pascal 所指出，随着 WS Reliable Messaging 在 2007 年 6 月作为 OASIS 标准发布，全套标准已经完整。

查看英文原文： ESB-Oriented Architectures considered harmful