公司内外的不同应用间需要进行相互通信。企业服务总线（Enterprise Service Bus，ESB）已经被视为支持应用集成的工具。但是ESB是什么呢？什么时候使用集成套件（integration suite）更为合适呢？下一个项目最合适的产品是什么？本文将会讲述为什么没有银弹（silver bullet）以及为何有时ESB可能也是错误的选择。对于项目的成功来讲，选择合适的产品是至关重要的。

术语“企业服务总线”的定义

众多来自不同供应商的产品都包含了“企业服务总线”的名字。令人遗憾的是，这个术语并没有标准的定义。因此，这些产品提供了很多不同的特性。在使用之前，ESB这个术语应该进行清晰地定义。在后文中，ESB可以定义为帮助开发人员进行应用集成的软件产品，因此它会提供必要的基础设施来实现路由、转换以及其他的集成设施。按照集成的复杂性路径，ESB通常会位于框架和套件之间，会作为应用集成的可选方案，如下图所示：

图1：应用集成的可选方案

在定义完ESB这个术语后，下一小节将会讨论什么时候要考虑ESB，以及在何时集成框架或集成套件是更好的选择。

集成框架

框架会帮助实现企业集成模式（Enterprise Integration Patterns，EIP, http://www.eaipatterns.com），如Splitter或基于内容的路由（Content Based Router）,从而能够以标准的方式进行应用集成。使用标准的API来集成产品可以明显地减少实现所付出的努力并且源码能够更容易被其他开发人员理解。框架可以很好地基于不同的协议和技术来集成不同的应用，像端点（endpoint）、生产者（producer）、消费者（consumer）以及EIP这样的理念可以用来创建集成逻辑。即便背后的支持性测试也使用了相同的理念。

框架包含了一些通用的库因此可以与任何开发环境兼容，即便是传统的文本编辑器也是可以的。

在Java环境中知名的框架样例是Apache Camel以及Spring Integration，在.NET中则是NServiceBus。

使用框架的话，开发团队要或多或少全权负责项目的成功。通常不会有商业上的支持。工具一般也只会部分可用，并且不一定适合“关键任务”（mission-critical）的部署。因此本文剩余的内容将会关注ESB以及对应的套件，通常来说它们是比框架更好的选择。

企业服务总线

类似于框架，ESB也用来集成应用。ESB在幕后会基于框架。但是，它是更为强大的产品。相对于框架来讲，除了应用集成的基本功能以外，ESB还提供了强大的工具来支持部署、管理以及运行时的监控。另外，图形化的编辑器可以用于实现各种集成场景。集成逻辑可以使用“拖拽操作”来建模，对应的代码将会自动生成。ESB会包含商业化的支持。

相对于单纯地使用框架，ESB的巨大优势在于更好的工具，它会明显地降低成本和复杂性。可以在更高的抽象等级解决集成的问题。

集成套件

套件提供了ESB的所有特性。另外，还会包含很多其他的功能，如业务流程管理（Business Process Management，BPM）、业务活动监控（Business Activity Monitoring）、主数据管理（Master Data Management）或仓库（Repository）。如果除了单纯的集成还需要某些附加的特性，那么建议使用套件。借助一个软件栈（software stack）就能实现全部的集成。

希望你现在已经明白了框架、ESB以及套件的区别。接下来会介绍如何选择合适的ESB或套件。

对比指标

注意：我们不会提供按照各种标准比较所有产品的矩阵。以笔者看来，创建一个良好且有用的矩阵几乎是不可能的，因为这些产品提供了如此之多的（通常还是不同的）功能和理念。除此之外，在IT世界中，所列的特性实际上每天都在发生着变化。

因此，建议你预先定义自己的需求，然后评估哪一个产品是最合适的。专有的解决方案通常是类似的，而最经常使用的开源竞争对手也提供了类似的特征。因此，在开始的时候，要考虑专有的还是开源的解决方案中，哪一个是更好的选择。

为了做出决策，你应该使用以下的指标：

• 可用性：安装的复杂性如何？需要多少工具？开发环境是否直观？
• 可维护性：如何管理产品？是否有管理服务的GUI？
• 社区：是否有活跃的公共论坛或邮件列表？是否可以获取众多的文章、教程以及视频？是否有众多的公司支持该产品？
• 企业级支持：提供了什么样的支持选项（“营业时间”、“24/7”热线、Email以及在线支持等）？需要的服务级别协议是否有保证？是否提供了你所首选语言的支持？
• 功能性：你所需要的所有功能是否都提供了？
• 灵活性：为了满足我的需求，是否能够自定义功能？
• 可扩展性：是否可以对产品进行扩展？产品及其接口是否基于标准构建的？
• 连接器（Connector）：对所有需要的技术，是否有适配器？对B2B产品，如SAP或Salesforce，是否有适配器？构建自定义适配器的便利性如何？
• 成本：产品的全部成本（拥有的总成本）是什么——包括维护、所有需要的辅助产品以及连接器等？
• 许可证：所使用的许可证或定制收费模式是什么？当需求发生变化（更多的电脑、更多的CPU以及转移到虚拟机等等）时会怎样？升级免费吗？或者可以降级吗？成本是“可预期的”吗，甚至价格清单易于理解吗？

表1比较了专有的和开源的ESB以及套件之间的优势和劣势（绿色=良好，红色=居中，红色=较差）。考虑到差异，所得到的结论如下：专有的解决方案通常提供了更多的特性以及“强大”的支持。但是，存在的问题在于，“它们是真的是需要的吗？”要记住的是，它们所要付出的努力、复杂性以及成本都会随之增高。开源产品会在使用便利性、更强的灵活性、易于扩展以及低成本方面得分。

表1：专有和开源产品的优势与劣势

可选的产品

在描述完专有产品和开源产品的主要不同之后，下面介绍一些相关的产品。因此，我将会给出各种可行方案的概要介绍以及简短实用的分析。

几乎每家专有集成产品的厂商都提供了包含所有功能的解决方案，如IBM和Oracle。至于开源的可选方案，尤其值得一提的是Talend的统一平台（Unified Platform）以及WSO2平台，它们也提供了完备的套件。除此之外，还有一些可选方案只专注于ESB，这方面可能最重要的开源提供者是Mule ESB以及Fuse ESB。

Oracle服务总线/Fusion中间件

Oracle服务总线是Oracle目前的ESB。它是Oracle Fusion中间件（Oracle Fusion Middleware，OFM）软件栈的一个组件，它符合本文中对集成套件的定义。其中还包含了很多其他的产品，如SOA套件（SOA Suite）、Coherence、复杂事件处理（Complex Event Processing）、BPEL处理管理器（BPEL Process Manager）、企业信息服务（Enterprise Messaging Service）、服务注册中心（Service Registry）等等。

很难找到Oracle套件所没有提供的功能。工具非常强大和稳定。对于大多数的产品都有图形化编辑器。对于能够想到的服务等级协议都能得到服务支持。如果这些强大的功能和SLA真的是你需要的，那么你可以选择Oracle。这种强大当然也是要付出一定成本的。不应低估产品的高度复杂性。另外，你还要注意许可证和支持的高昂成本以及不透明的定价模式。

OFM是基于标准的，如Java EE、BPEL、SOAP以及SCA。产品是专有的，它们来源于Oracle在过去的多次收购。因此，使用了不同的代码基，不同的产品通常会使用不同的开发工具。下载的总量能够迅速到达20Gb。安装是非常耗时的，偶尔会需要几天的时间——即便只是在笔记本上的简单安装也可能如此。产品是相当重量级的。运行时的资源要求也很高。

另外，你可以将“Oracle”替换为“IBM”并将“Fusion中间件”替换为“WebSphere”，本节所讨论的内容依然成立——值得一提的是，IBM在其产品组合中有三个不同的ESB：Message Broker、ESB以及DataPower SOA Appliances。Tobco、Microsoft以及SAP在专有ESB和集成套件市场上也扮演着重要的角色。

因此，这一部分的结论可以这样说，专有的集成套件几乎可以提供所有需要的功能并涵盖所有的SLA。但是，在大多数的项目中，很多功能和SLA并不是必需的。在这种情况下，一定也要评估一下开源的替代方案。它们中最重要的产品在接下来的小节中进行了描述。

Mule ESB

Mule ESB是最早成功的开源ESB之一。它具备前面所提到的开源ESB的很多通用特征。这包括非常简单（“一键点击”）的安装以及直观的、基于Eclipse的工具。通常，开源的ESB是非常轻量级和可扩展的解决方案。除了开源的免费版本，还有商用的企业级版本。这会为产品提供额外的功能和支持。

对于那些还没有了解的人来说，需要提及的一点是“开源”并不意味着“免费”。开源软件的厂商必须要挣钱，因此不能免费地开发软件和提供支持。但是，对顾客来说价格会友好得多，同时也不会像专有产品那样基于晦涩难懂的价格列表。不过，开源版本可以用在任何环境（甚至是生产环境）下，并没有许可证的成本。但通常，开源版本只是用来了解的，并为稍后升级到企业级版本提供可行的证明，企业级版本会有额外的特性和支持。

正如其名字所示，Mule ESB是纯粹的ESB。相对于Apache Camel和Spring Integration这样的框架，其重要的优势在于能够高效实现集成场景的图形化编辑器，以及为SAP或Salesforce这样的B2B产品所提供的连接器。但是，在Mule ESB中会缺少套件的功能。为了应对这样的使用场景，ESB必须要与其他厂商的产品联合使用。Mule ESB的不利因素在于较小的社区、限制性的许可证模型并且可获取的源码有限。它的竞争对手在这方面有明显的优势。

Fuse ESB

Fuse ESB类似于Mule ESB也是一个纯粹的ESB，而不是套件。它基于集成环境中的事实标准如Apache CXF以及Apache Camel。这样它一开始就拥有了强大的社区。它的开发环境是基于Eclipse的，并且非常直观。

Fuse ESB是FuseSource的一部分。但是，FuseSource最近被Red Hat收购了，现在它属于JBoss部门。Fuse ESB包含在当前的Roadmap之中并将会得到持续的支持。它将会集成到JBoss企业级SOA平台（JBoss Enterprise SOA Platform）之中——就像它收购的BPM解决方案Polymita一样。到形成统一的套件还有很长的路要走，因为集成FuseSource和Polymita依然需要几个月的时间，并且JBoss ESB、Switchyard和Fuse ESB这三个ESB产品要合并为一个。在这方面，其他的厂商已经获得了更好的效果。

Talend ESB/统一平台（Unified Platform）

Talend ESB是Talend套件的一部分。Talend ESB可以独立使用，也可以与Talend统一平台的其他组件联合使用。所有的组件都是开源的并且可以免费得到。企业级的版本提供了更多的功能和支持。与专有产品的不同之处在于，所有的组成组件都是基于相同的代码基而且同一个工具可以用在各个地方。在不同领域如ESB、BPM、ETL、MDM，都可以很顺畅地完成——它本身不是单独的集成项目。

Talend套件的所有工具都是基于Eclipse的。使用Eclipse的类似“外观和体验”以及直观性依然得到了保存。Talend为所有的产品提供了一个可视化的设计器，并使用“零编码”（zero-coding）的方式。这样就能高效地实现集成的场景。当然，你依然可以编写和集成自定义的逻辑到项目之中，例如通过Java类（POJO）或不同的脚本语言。

类似于Fuse ESB，Talend ESB也基于多个集成环境中的事实标准，如Apache Camel、Apache CXF、Apache Karaf以及Apache Zookeeper。除了能够使用Apache Camel为JMS、HTTP以及FTP这些技术所提供的连接器以外，还有很多的B2B适配器是可用的，如为Alfresco、Jasper、SAP、Salesforce以及主机系统所提供的适配器。默认会包含所有的500个以上的连接器。这样所造成的结果就是Talend的IDE比其竞争对手有更高的硬件需求。你不能在太差的笔记本上安装Talend。另外一个不足是缺失SOA管理功能（SOA governance feature）。这计划在下一版中进行添加。

WSO2 ESB/Platform

相对来说，WSO2是一个不太知名的厂商。但是WSO2提供了完整的套件组件，包括业务流程服务器（Business Process Server）、业务规则服务器（Business Rules Server）、业务活动监控（Business Activity Monitor）以及注册表管理（Governance Registry）。完整的WSO2平台可以很容易地进行安装，它并且提供了轻量级的、基于Eclipse的开发studio。类似于Talend和FuseSource，WSO2也将主要的开源项目纳为组件，如Apache Synapse（轻量级ESB）、Axis（Web Service实现）以及ODE（业务流程引擎）。

除了Talend以外，WSO2是唯一一个所提供的套件基于单一代码基和单一开发环境的厂商。因此，没有什么会阻碍迭代式的开发过程，例如开始的时候只有几个小的特性，然后一步步添加更多的功能。弱点在于图形化的工具。它能够支持平台上的所有组件，但是不像其竞争对手的工具那样直观。

“自己动手做”（Do it yourself）集成套件？

警告性的结论：如果联合使用多个框架和产品来构建自己的自定义集成套件，通常会遇到不必要的高昂成本并会遇到很多额外的陷阱。鉴于已经有多种方案，所以强烈不建议通过各种拼凑来创建自己的方案。如果这样做的话，需要编写“粘合代码”（glue code）、进行测试和缺陷修正，同时一旦遇到问题时，没有明确的协议。供应商通常会归咎于另一方，例如，如果你想将ESB与其他厂商的BPM方案结合在一起，当遇到问题的时候，你该找谁呢？所以，你为什么要去关注那些别人已经关注过的问题呢，而且现在已经可以获取完整的产品栈（同时也有开源的

结论

解决集成的问题方面并没有银弹。首先，必须要做出决策框架的功能是否足够。要注意的是，使用框架大多数的源码要自己编写，同时工具和支持都很有限。否则的话，ESB就是更好的选择。但是，如果稍后会用到套件中的额外功能，那么最好在开始的时候就使用集成套件中的ESB。这可以保证持续性，不会遇到联合使用多个产品的问题和额外成本。

如果要使用ESB或集成套件，必要要决定专有产品还是开源产品更合适。专有的解决方案提供了所有可能的特性以及强大的支持。但是，这也会导致更高的成本和更高的复杂性。与此相对的是，开源解决方案会有更低的成本、便于使用且具备灵活性。一旦这个问题解决了，就可以创建一个候选列表来详细地评估备选方案。强烈建议在做出最终决策前做出证明。确保你的团队实现了原型（从第一次安装到最终部署和监控），而不是只听从于厂商的顾问所言。将来你的团队将会独自安装产品并解决集成的问题，此时可能并没有可咨询的顾问。