走出ESB误区:揭开ESB的十个神话

原文出自IT168

在诸多的专题研讨会上，企业架构师们探讨着许多问题，比如面向服务架构（SOA）的相关问题、如何让企业服务总线（ESB）作为构建企业SOA框架的主干问题等。其中，许多人质疑ESB的意义所在，从中也体现出当前IT群体普遍对ESB存在一定的误解。下面便是笔者总结人们最关心的10个ESB的问题。

误区1：ESB只是EAI换了个名字

许多IT架构团体在搭建SOA的同时仍然受到一个问题的困扰：“ESB和EAI到底有什么不同？”ESB是一种用于构建企业SOA的基础设施，它比传统的EAI代理的用途更为广泛。根据福里斯特研究所的报告，ESB可以提高连通性、增加灵活性促进发展、并加强对重要资源的控制，从而帮助企业实现SOA的价值。

ESB不仅可以用于处理以往依靠EAI工具进行的集成项目，还可以用于建立企业间的B2B关系。

ESB可以提供EAI所能提供的功能，但其基本架构是不同的：这个架构促进了企业从传统的集成方式转向协调服务交互。EAI通常是采用星形架构以独立应用的形式实现的。

ESB提供的功能与EAI代理相同--连通器、应用适配器、根据规则进行的消息路由和数据转换引擎--但是这些功能是面向SOA的，它们分布于整个服务总线并寄存在可独立部署的服务容器中。这使我们可以有选择性地部署所需的集成代理功能，不会产生冗余。ESB容器模型的这种分布式特性使以事件驱动服务的形式按需添加到SOA中的集成组件具有独立的可扩展性。

为了使集成代理能够从真正意义上支持SOA并成为真正意义上的ESB，我们需要把它的基本功能分散到组成部件中，然后才能将各个组件独立地部署到总线中，并使它们协调运作。

我们来看一个基于XSLT的转换引擎。该引擎可以根据XSLT模式表把一种XML文件转换为另一种XML格式。我可以负责任地告诉你没有什么比分析和处理XML更消耗计算资源的了。如果两个经常互通的应用之间存在XSLT转换，那么这个转换很可能会成为性能与扩展的瓶颈。如果你采用的是独立式的星形集成代理方式，那么为了解决这个瓶颈问题并扩大部署你必须把这个集成代理安装到一个处理能力强大的机器上，或者是安装到多台机器上--而这仅仅是为了解决这个转换的问题。同时，其它的集成代理功能，比如路由规则的处理还在和转换处理抢夺计算资源。

与集成代理的星型架构不同，ESB的基础核心提供了一种分布式的服务架构。这种架构是面向集成的，它可以对集成代理中的各种功能比如消息路由、数据转换、和应用适配器等进行选择性的按需部署，而这些独立的集成服务正是构成SOA的一部分。

可以把XSLT转换以服务的形式部署到ESB服务容器中，然后把这个容器的多个实例根据负载平衡分布到许多机器中。如果这个ESB容器是跨平台实现的，那么你还可以灵活地选择转换服务所跨越的平台--Linux主机、Solaris主机、Windows主机等等。如果你不喜欢这种简单的架构，还可以这样考虑：那些对ESB的定义和产品提出非难的供应商同时也为我们提供了方便：你可以部署任意多的轻量级ESB服务容器而无需支付任何额外费用。

ESB提供的这种集成服务可以与其它服务结合融进基于SOA的处理流程，从而扩大业务范围。ESB中的分布式服务可以结合基于路线（itinerary-based）的路由选择（见误区#7）以实现自定向、面向消息的服务交互，从而使ESB的各个部件能够独立地进行工作，不会对某个集中式的路由引擎产生依赖。

误区2：微软正在利用"Indigo"创建ESB

微软的Indigo结合了Messaging Queuing、Component Object Model COM+、.NET、和Web服务。他们在做的是具有Web服务扩展功能的消息总线。这和企业服务总线是有很大不同的。消息总线暴露了低层消息技术的详细内容，它需要编写代码来定义应用与服务之间的关系。而ESB的意义在于配置而不是编码，因此也不需要手工编写内部互通的的各应用之间的关系。ESB有利于提高以事件驱动的形式暴露于总线上的应用之间的松耦合特性。好消息是Indigo上创建的应用至少也是基于消息的，因此通过ESB进行集成也会比较简单。

也就是说，BizTalk Server中的某些东西与Indigo组合后可能会比较像ESB。不过还有很重要的一点，即BizTalk是星型集成代理，因此它同样受到前面在ESB与EAI中所提到的所有不利方面的影响。你无法在不增加任何费用的前提下把XML转换引擎从BizTalk Server中分离出来并作为负载平衡的服务运行在多台机器上（详见前面EAI与ESB的讨论）。

误区3：WS-Rliability和WS-Reliable Messaging等WS-*标准终将解除对ESB的需求

在设计ESB的时候就应该考虑使其能根据这些不断发展并逐渐获得商业应用价值的标准做出调整。WS-*标准的发展使应用终端能更好地通过ESB进行交互。

由于各种平行进行的工作，WS-*标准作为不断发展的Web服务标准的一部分自然也存在许多不确定因素。即使这些标准最终发展健全并且得到了广泛的应用，它们仍然需要一个能够为其提供支持的平台。ESB可以在与底层协作标准无关的层面上为企业提供一个构建、编排和管理SOA的统一模型。

WS-Reliability标准的实施需要有可靠的消息持久性和存储转发处理器的支持。企业消息层是ESB的基础组件，它通过消息持久性、存储转发、消息验证等消息协议和与外部XA-compliant事务处理器的接口保证数据传输的服务质量。ESB的部署还可能使复杂网络布局的消息路由透明化，并通过容错的消息服务器架构实现消息设施的持续可用性。在当前高压的企业环境下，要实现所有这些设计还需要许多人的多年劳动。

也就是说，现在部署具有专有消息层的ESB时还应该同时采用一种或更多的WS-Rel*作为补充协议以为将来作准备。但是，这并不是一种可以解决所有问题的方案，我们仍然需要对多种消息和协议的组合提供支持。

误区4：模式还是产品？

企业服务总线（ESB）这个术语实际上并不属于产品的范畴；它只是一个可以实现应用服务器与集成中间件的耦合关系的抽象概念。

ESB是一个用于构建企业SOA的高度分布化的主干总线。企业要构建面向服务的架构，而ESB则是这个架构的基础总线。由于ESB的产生对集成市场带来不少冲击，某些集成供应商便放出烟雾弹称ESB只是一个可以用于组合当前的中间件与应用服务设施的抽象的模式。实际上，ESB确确实实地是一种硬件设施，而且几年前就已经可以从各供应商处购买到了。目前为止，制造业、金融业、电信和零售等各产业之间已经部署了许多ESB。

ESB的定义应该包含以下基本要素：

· 一个分布式的服务架构，包括一个用于寄存集成组件作为远程服务的轻量级容器模型

· 一个可以为各应用与服务提供可靠的消息传输的企业消息主干总线

· XML Data转换

· 服务编排和根据消息内容进行处理的智能路由

· 一个灵活的安全架构

· 可以配置、部署、监控以及管理远程服务的管理设施

由于ESB的分布式服务架构，我们可以通过全球任何位置上的虚拟终端访问服务。这个分布式服务架构是建立在一个由可以通过远程服务进行配置、部署、管理和监控的轻量级服务容器构成的互联系统上的。这些服务容器通过一个实现了可扩展性、持续可用性、低延时处理、安全一致和服务质量（QoS）的标准化的消息主干总线组合到一起。

误区5：ESB与J2EE应用服务产品之间存在竞争

ESB与J2EE app服务器是高度互补性质的。通过使用JMS、MDB、JCA或Web服务等标准接口连接到ESB，即使是在非J2EE环境下J2EE app服务器也可以与其它应用服务器很好地集成。

大部分ESB用户同时也是应用服务器技术的用户。这些用户利用应用服务器和ESB作为他们的集成环境的最优组件--使用应用服务器寄存业务逻辑并以门户的形式提供网站服务，同时使用ESB来集成应用服务器与企业中的各种后端应用和数据源。

误区6：只要使用Web service call即可把门户网站连接到后端系统上

虽然理论上Web服务调用可以把门户连接到后端目标系统上，可是这种方式无法扩展到多个后端系统上。通过使用ESB，可以让门户服务器通过唯一的接口连接到总线，而总线则成为门户服务器可能调用到的所有后端系统上的各种连接属性、协议、安全和数据格式的媒介。

使用了ESB作为门户服务器和可能与门户服务器产生交互的各种后端应用的中间层相当于为ESB用户提供了一个更为灵活、扩展性能更好的SOA，因此当项目更成功、根据业务需求需要发生变化时，他们也能自由地处理各种各样的集成作业。

误区7：当BPEL获得广泛应用的时候ESB就会退出舞台

ESB可以支持多种事件驱动的服务调用的编排方式。BPEL只是其中的一种。ESB还有基于路线的路由，可以为消息指定一系列的路由指令。消息因被服务调用而经过总线的时候，这些代表业务过程定义的路由指令始终是和消息绑定的。然后由远程ESB服务容器决定将消息发送到哪里。

这个过程中没有集中的路由规则引擎，因此基于路线的路由也是ESB分布式的特性一大体现。像星型EAI代理所用的这种集中的消息路由规则引擎则可能会成为系统的瓶颈，并且如果这一部分出现故障将导致整个系统的瘫痪。仅仅使用消息路线、消息和过程定义其实就足够了，这样还能允许ESB的各个不同部分独立地进行工作。

消息路线可以有效地处理那些包含有限步骤并且无需很长的处理时间即可结束的无状态随机过程。甘特称这种过程定义为"微流（microflows）"。根据基于内容的路由服务的使用情况，路线中可能会产生简单的分支。

如果需要更复杂的过程定义，还可以在ESB中加入一个流程编排引擎作为补充服务。这个过程编排可以支持可能存在很长时间的状态过程。它还可以支持带分支的平行执行路径，并根据联接条件或转换条件支持消息流执行路径的融合。这样的过程可以支持BPEL和其它的过程定义语法，比如ebXML BPSS。还可以将成熟的过程编排与非状态的基于路线的路由结合，建立一个可以解决复杂的集成问题的SOA。

误区8：ESB技术和其它技术一样正在经历一个典型的技术发展曲线：凭空产生，迅速发展，然后马上进入“幻灭”阶段。

ESB这个概念是制造、电子商务、电信、金融服务和零售等多个产业的先导者共同努力产生的结果。其产生是由于需求，是以当时已经比较成功的分布式计算模型和EAI技术为基础建立的新方式。这些IT先导者的最终结果是一致的："我们的分布式消息基础结构是成功的，所以我们希望能以此为基础建立一个用于集成的基于标准的事件驱动的SOA。我们希望它能包含Web服务、XML数据转换、基于内容的路由和面向分布式过程的服务调用模型。"因此，ESB中所体现的这些概念都是成熟的，是有健全的基础的。也正因为如此，ESB技术正在发挥着它应有的作用。现在已经有数百条ESB在各行业服役，比如供应链、物流自动化、金融服务中的全球直通处理、电信的实时服务、以及零售业的远程店面管理。

误区9：ESB只是一个推动器，但它并没有提供成熟的工具，比如设计业务流用的图形编辑器。

现在有一种新的IDE（或Gartner集团所称的ISE）可以让你设计、配置、测试、调试你在建立应用ESB的SOA时开发的集成服务。其使用的是图形界面，集成设计师可以用UML表示法来描述过程定义。你还可以使用ISE图形化地创建不同数据之间的转换方式并建立和调试XSLT模式表。

误区10：可以使用EJB容器实现ESB容器

ESB结构中的一个关键组成部分就是一个高度分布式的、轻量级的服务容器。这个服务容器能以事件驱动服务的形式寄存集成组件，比如一个在XML消息中添加XPath表达式来决定路由的基于内容的路由服务。它还能寄存定制的服务或用于接入打包的应用的专门适配器。

这和它们的远房亲戚应用服务器容器及集成代理可不一样，ESB服务容器可以让你随时在任何地方有选择性地按需部署集成服务，不多也不会少。而另一方面即使只需要添加一点集成功能都需要在所有地方安装完整的应用服务器堆栈。这样就产生了所谓的"到处都是应用服务器"的问题。同时还会产生数目不小的许可证、安装、和随后相关的各种费用。

而ESB的精髓在于"配置取代编码"。如果是以应用服务器为主的集成方式，你通常要编写代码来描述服务之间的依存关系。EJB模型使用的是client/server的集成模式，服务之间的接口是紧耦合的关系，而这些都要写进代码并编译到类文件中，这样，每次需要改动的时候都要对这些文件进行修改和重新部署。

在ESB中，服务是以与输入和输出通道有关的信息进行配置的。这些通道发送和接收基于内容的请求和响应模式以及单向事件通知，然后通过其它的调用框架进行处理，而不是服务本身。

可以对ESB服务进行配置和部署，这只需要从配置仓库里读取XSL模式表、XPath表达式、脚本和参数等信息。一旦部署完成，其性能便是高度灵活的。

总结

总的来说，对ESB的理解包含以下方面：

· ESB是建立企业SOA集成环境的主干总线。

· WS-*标准的发展将使ESB的交互性能更为完善。今天采用ESB可以让你做好应付未来的准备，并且当WS-*标准具有真正的商业价值的时候你也能做出适当的调整。

· ESB并不仅仅是一个抽象的模式。它属于产品的范畴，有清晰的定义，也有许多供应商可以选择。

· ESB与应用服务器的互补性很强。

· ESB提供了灵活的连接器和可扩展的设施，有利于将门户服务器集成到后端系统。

· ESB为协调服务之间的交互提供了许多选择。

· ESB技术是以实际为基础的，并已在许多行业得到应用。