在诸多的专题研讨会上，企业架构师们探讨着许多问题，比如面向服务架构（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来集成应用服务器与企业中的各种后端应用和数据源。