引言

　　我们会经常遇到越来越多的客户要求完成根本不使用SOA的项目，而仅仅在其中实现企业服务总线(Enterprise Service Bus，ESB)体系结构。此类面向 ESB 的体系结构并不困难，但是其成功与否却难下定论。要求进行此类项目的客户并不了解这一点：面向ESB的体系结构并不带来业务价值。基于面向ESB的体系结构的项目需要成为基于SOA的项目，才能帮助确保成功地提供业务价值。

　　仅使用ESB体系结构

　　SOA基于业务需求。SOA可保持IT与业务的一致性，使IT系统按照业务系统的方式工作，帮助确保IT产生业务价值。有关更多细节，请参见IBM白皮书“IBM SOA Foundation: An architectural introduction and overview”

　　SOA的主要目标是在业务领域与IT领域之间保持一致，从而同时提高二者的效率。

　　使用 IBM 产品和服务构建IT系统的IT部门可能对其业务需求了解并不够。对于习惯于精确计划系统将如何工作的工程师，业务工作的方式可能会让人觉得没有计划，是随机的。说明内容看起来不一致，不可行，业务用户的需求似乎不现实，而且总在变。业务需求成了“都市神话”，似乎存在于组织中，但仔细分析却又找不到。

　　从这个角度而言，将 IT 与业务保持一致是不现实的。业务部门似乎不知道自己需要什么。其流程对自动化构成了挑战。实现流程自动化的工作没有效果，而且站不住脚。

　　工程师所了解的是技术。技术并不需要想像的需求列表，仅仅需要代码而已。代码不会抱怨不好用，编译器也不会每天改变自己的需求。代码要么运行，要么不运行。如果今天代码在运行，那么明天它也会运行。

　　技术对于工程师来说更容易掌握，也让他们觉得比较满意。这也碰巧成为了大多数企业软件公司销售的主要内容。ESB 是技术，用于连接到其他技术。

　　SOA 非常复杂，而与此不同，ESB 理解起来较为容易。ESB 并不需要任何这样的业务需求，仅仅需要技术需求。ESB 非常精确，以各项标准为基础：数据格式、连接协议、XML、IP、HTTP、SOAP、JMS、JAX-RPC、JAX-WS 等等。SOA 可能会永远都处在分析停滞状态，而构建 ESB 可以实际完成一些看得见的工作。

　　这经常被称为连接一切 的项目。客户有很多部分——应用程序、计算机系统、数据中心、部门、子公司、外派机构、合作伙伴和客户——这些部分彼此并不通信。各个部分对其他部分所进行的工作毫不知情。一个部分拥有另一个部分需要的数据，因此这两个部分需要协同工作。只有所有的部分连接到一起，才能够都正常工作。与尝试了解业务需求的无效果相比，连接一切是一个能够解决的问题，因为其解决方案是技术。如果将 IT 部门比作锤子，则 ESB 就是 SOA 的钉子。

　　他们的想法经常是，“我们不知道还需要别的什么，因此目前我们将仅仅构建 ESB。”但这与“您开始编写代码，我们将了解他们需要什么”方法有什么实际的区别么?

　　ESB“梦话之地”介绍

　　读者经常通过单个属于来对连接一切的想法进行总结：企业服务总线(ESB)。那么，他们在说需要 ESB 的时候到底是希望什么呢?他们的 ESB 指的是什么呢?是否真的有必要将其称为 ESB?

　　客户经常喜欢将 ESB 中的第一个词替换掉。他们不使用企业，而使用其它的组织单位，如公司、部门或政府。有时候还会使用其用途进行描述，如采购或工资单。或者描述其将传递的内容，如产品或订单。即使客户所需的是公司产品采购服务总线，也不要被服务总线 之前的词语所迷惑。这些客户需要的是 ESB。他们有时候甚至会这样描述需求“一个 ESB，但……”。

　　客户的重点实际上在最后一部分：总线。在包括总线的技术拓扑中，所有对象都连接到总线，因此，也使用总线连接到所有其他对象。总线是各个部分间通信的主干道。应用程序间的通信(甚至网络上计算机之间的通信)通常都使用消息(即一系列不同的信息数据包)完成。Enterprise Integration Patterns 一书对此进行了很好的概述，其中将此类连接称为消息总线。