ESB并不是那样 人们往往片面地看待ESB本身

作为构建SOA项目的基础架构，ESB正在受到各大厂商的追捧。但是人们往往片面地看待ESB本身，以及它在SOA项目中的作用，其实ESB并不是那样。

集成技术和SOA的结合

谈到ESB，人们会自然想到两个关键词:集成和SOA。是的，ESB正是集成技术和SOA思想结合的产物。 

分布式时代的集成技术

从集成技术的发展历史来看，最早是简单地点对点集成，两个应用通过各自的接口来实现通信。这种接口固化在应用当中的紧密耦合方式，使得系统毫无灵活性可言，应用本身的每次变化都会要求其相应接口的重新定制。

于是发展出基于消息的中间件，接口被消息代理所取代，应用与应用之间不再是通过其本身的接口互联，而是通过独立的消息代理来通信，这使得应用与应用之间耦合更松，应用的变化影响的只是消息代理，而不需要其他应用改变。但是它仍然是点对点集成的一种方式，路由逻辑和业务逻辑没有分离，系统基本没有扩展性，部署上还是网状结构。

这种点对点的集成方式应付少量应用的整合还差强人意，对于大规模的集成，在EAI时代，逐渐发展出“集线器”模式。通过把所有的系统都连接到中央交换中心，这种模式巧妙地把集成逻辑和业务逻辑分离开来，大大增加了系统弹性。但是这种中央控制的方式使得管理相当复杂，同时中央又往往成为集成的瓶颈所在。

分布式时代的到来对于集成的方式提出了巨大的挑战，这时候ESB就应运而生。通过采用轻量级的分布式体系，ESB将更多的处理逻辑分配到多个的端点上，中央服务器不复存在，业务逻辑处理能力及系统压力可灵活调配。

“总线对于Hub进行了拓展，拓扑的模式还是那样，但是这个单一的物理中心被虚拟化，分散到了整个网络上，负载和灵活性都大大增加了。”IBM的毛新生这样解释ESB，他认为ESB真正实现了系统间的松耦合，从而能够应对大规模的集成。

“ESB就是EAI在SOA时代下的一种形态。”金蝶中间件ESB产品项目经理倪晓兵说，“区别于传统的EAI技术，ESB不仅支持高度的分布式部署，同时支持异步消息的交互，强调面向的对象是符合标准的服务。”

另外，ESB在集成的过程中，更强调一种“统一消息”的概念。这种“统一消息”的格式，是可以被在ESB中所集成的各个服务都认可的。例如，IBM提出的SDO这样的一种统一的数据格式。

SOA时代下的产物

在SOA时代下，ESB为SOA的实施提供了底层架构的技术支持。SOA从根本上来说就是要解决两个问题:重用和异构，但是作为信息化系统建设永远要面对的两个难题，解决的方法却并不简单，所以SOA的体系庞大而复杂。

另外，SOA从根本上来说是一种软件架构的思想和方法论，它必须有相应的技术来帮助它落地，应用在具体的项目当中，而ESB则提供了实施SOA、简化SOA的技术手段。“ESB的意义在于让SOA有了一个可实现的基础设施。”IONA公司大中国区高级架构师陆飞舟这样说。

对于SOA要解决的两个难题，ESB从底层架构上都进行了技术支持。对于服务的重用，ESB提供了服务仓库和消息的路由，来实现服务之间的彼此调用。一个应用如果需要调用一个服务，它根本不用知道这个服务在什么地方，如何调用等，而只需要发送一个调用的请求，ESB就会帮助它找到那个服务，并进行绑定和消息的路由。“ESB为服务提供者和服务消费者之间的集成提供了一个平台。”倪晓兵说。

更重要的是ESB为分散服务提供了交互、组合和治理的基础架构。有了它，SOA才能释放自己的最大价值。

而对于异构环境的连接，这是ESB天生就具备的能力，因为集成技术一开始就是面向异构环境的。不同的数据、消息遵循不同的协议，采用不同的格式，为了完成它们之间的交互，ESB就必须提供转换的能力。同时作为EAI在SOA下的一种形态，ESB更具开放性，尤其是对Web服务的支持。

IBM为ESB定义了四个必备的功能:“路由器”——根据信息内容，在不同应用和服务之间进行信息传输和路由;“转换器”——进行应用之间的通信协议转换;“翻译机”——进行应用之间的消息格式转换;“收发室”——处理来自不同渠道的业务事件（同步传输，异步传输，发布/订阅等方式）。

其中“路由器”和“收发室”都是针对服务的重用而设计的，而“转换器”和“翻译机”则专门用来解决异构的通信问题。

针对重用和异构这两个难题，倪晓兵认为ESB提供了两个核心的功能，服务的管理和数据的转换。

那么ESB到底是什么呢？业内对ESB的定义是:它是由中间件技术实现并支持SOA的一组基础架构，支持异构环境中的服务、消息以及基于事件的交互，并且具有适当的服务级别和可管理性。

ESB是逻辑上与SOA 所遵循的基本原则保持一致的服务集成基础架构，它提供了服务管理的方法和在分布式异构环境中进行服务交互的功能。

ESB不仅仅是连通 

连通是最基础的能力

不管是应对集成还是支持SOA落地，连通性都是ESB要解决的首要问题，数据和消息的传输和转换是SOA实现的基础。作为SOA架构的信息传输龙骨，ESB为SOA提供一种连通性基础架构，用以连接SOA中的服务。

IBM WebSphere软件全球副总裁Sandy Carter女士介绍说，“ESB是SOA中的消息框架，即消息相互交换和通信的方式，是业界标准与客户消息框架的整合。”

“IT系统如果是一个人体的话，血液就是数据，心脏和血管就是ESB，大脑等器官就是应用，这样一个整体就是SOA。”毛新生这样比喻。

ESB要做到还很多

但是ESB的作用绝不仅限于连接。“企业需要不受限制的ESB。这是因为SOA不仅仅需要ESB来解决连通性问题，而且还需要ESB与附加产品的运行环境一起得到扩展，以便形成一个可以充分整合并有效连通的解决方案。”Sandy Carter说。

BEA公司中国区技术经理刘汩春说:“SOA的‘服务’不仅仅是可重用，而且必须是可组装编排;可快速注册发布; 质量可监控;生命周期可管理的。这样SOA才能在整个IT范围内实现服务治理和优化，从而直接推动业务的优化。”

倪晓兵介绍，金蝶中间件推出的Apusic ESB不仅包含了数据连通的功能，还涵盖了智能网络、服务仓库、业务重组和管理工具。

首先，分布式部署和集中控制是ESB的典型特征。ESB服务器在物理上可能相隔很远，但是通过集中管理，这些服务器组成了一个ESB网络，在逻辑上形成完整的企业服务总线。

在Apusic ESB的智能网络中，不要求网络中的各个服务器都必须明确地和其他所有的服务器建立连接关系，只要一个节点不是孤立节点，那么这个节点就可以和Apusic ESB网络中的任意非孤立节点通信。并且，在通信过程中的路径选择上，Apusic ESB 网络会根据网络连接状况的实际情况，作出智能调整，自动选择最优路径。

其次服务的注册、发布和编排也是SOA实现服务重用性的基础。在Apusic ESB的服务仓库中，任何符合标准的服务都可以在其中注册，从而被其他服务调用。而消费服务也无需知道被调用服务的具体特征，只需要发送相应地请求即可找到相应的服务，并进行绑定和数据的传输。

同时为了满足具体的业务需求，不同的服务需要被组装在一起形成新的应用系统。Apusic ESB引入了工作流流程的概念，引入自主实现且基于业界标准的，具有条件分支和合并并行流转功能的BPEL4WS流程引擎，从而实现综合的、复杂的业务逻辑编排。这个流程引擎支持子流程、条件脚本、路由节点等功能。通过灵活的流程定义，按照即时的业务需求，将单个离散服务有机的组合起来，达到服务重组的目的，完成集成的业务需求。

此外，Apusic ESB在引擎级别将BPEL规范的细节进行了包装，对用户来说，只需要关心流程中的一个服务即可，无须再去关心BPEL的具体技术细节。

最后，所有的调用、转换都必须有一个良好的管理工具来帮助实施，并进行监控。Apusic ESB则提供了一体化的管理工具，通过这些工具，您可以非常方便的对Apusic ESB进行集中式管理、可视化的流程设计，以及运行期的实时监控等功能。

ESB其实只是技术

SOA项目不应从ESB开始

ESB在SOA中的重要作用，使得各个SOA厂商纷纷推出自己的ESB产品，并在具体的SOA实施中，利用ESB来作为切入点，并简化SOA的复杂性。

但是这种对ESB的重视正在使SOA的实施进入迷途。因为ESB只是技术手段，而SOA的目标则是业务价值。对技术手段的过分重视往往使人们忽略了SOA的最终目标，陷入在技术的泥潭当中不能自拔。同时ESB的简化掩盖了SOA的复杂性，使大家对SOA的实施过分盲目乐观，忽略了除了技术以外其他很多更重要的因素。

针对这种错误倾向，IBM WebSphere SOA与J2EE顾问Bobby Woolf最近写了一篇文章《以ESB为中心的架构是实施SOA错误的途径》来质疑这种把ESB当作SOA的实现基础的做法。Bobby Woolf在文章中提到，很多客户在开始建设SOA时要求先为他们建立一个ESB，他们抛弃了SOA的理念而只对ESB感兴趣。“这些客户在ESB和SOA之间划了一个等号，或者更准确地说建设SOA就必须建设ESB。”毛新生指出了这种错误的根源所在。

因此以ESB来启动一个SOA项目是有害的，它将陷入技术的怪圈中，而无法产生最大的业务价值。毛新生认为业务才应该是SOA开始的起点和最终的目标。“你首先要在业务上进行服务的分解，然后才把他们映射到技术实现中。”毛新生说。

SOA项目的实施必须从业务需求的分析开始，而不是从构建ESB来开始。倪晓兵对这种观点也表示支持，“SOA框架体系下的软件开发，应该是从业务流程分析开始的，用一些组件化的业务建模方法，对实际的业务场景进行分析。在这个基础上建立业务用例，并根据这些业务用例构造业务流程模型。”

倪晓兵同时强调:“ESB不过工具和技术而已，关键上集成业务如何做？业务逻辑如何编制？如何实施？金蝶不仅提供产品,还能提供一套实施方法论。针对简单集成业务，提供标准知识集，也就是工具包，SI马上就可以用，针对复杂业务，我们提供一套方法论，金蝶的六步实施法，可以加速实施过程”。

引入ESB的最佳时机

我们既然不能从ESB来开始一个SOA项目，那么应该在项目的什么时候引进这个重要的工具呢？Accenture首席技术官Don Rippert认为激活SOA的全部潜力需要通过四个阶段，依次是使用XML，以更标准的方式使用应用程序接口;捕获一些业务过程，并将它们转化成为Web服务;引入并全面使用企业服务总线;产生业务过程执行语言（Business Process Execution Language，BPEL），它可由业务过程建模工具完成。

在这四个阶段，ESB的采用则位于第三阶段中。同时他认为当前大多数的企业还只是处于第一个阶段，因此ESB实际上对于他们来说并不是迫切需要的。

Burton Group的分析师Anne Thomas Manes的观点与Rippert相似，他认为要采用ESB，必须首先实现启动SOA的基本组件，这些组件是一个或多个服务平台（如.NET，Java EE应用服务器等），SOA管理解决方案，注册表，另外如果服务要被暴露在防火墙之外，那么需要XML网关。

她说:“如果缺少我推荐启动SOA的‘基本组件’，ESB将不会列在我的清单中。事实上，我并不鼓励人们由ESB开始。ESB并不会鼓励好的SOA行为。ESB本质上是集成系统，而非SOA系统。”并且她认为ESB应该在后期购买。

毛新生认为，做SOA的事情不要先上来建立一个大而全的ESB，相反是关注你的业务问题，找到用SOA的方法来解决业务上的需求，在解决这个问题的过程当中，你会看到一系列的业务服务。这些业务服务是会产生业务价值的。它可以灵活地组装，动态地解决你变化的业务需求。这是它的价值，只有这样才能使你的业务敏捷起来，随需应变起来。而在服务的组装过程中，你再去考虑利用ESB来把他们连接起来。

需要注意的是，这并不是否认ESB的价值。ESB是好的，单纯的ESB项目是坏的。让架构围绕服务，而非总线。

（转载至http://news.csdn.net/n/20080408/115014.html）