为你的集成需求选择正确的 ESB

英文原文：Choosing
the Right ESB for Your Integration Needs

参与翻译(4人)：

左勤, 等PM, 开源中国驻联合国理事, uranus

翻译文章原网址http://www.oschina.net/translate/esb-integration

公司内部不同的应用程序在不同的公司需要沟通。企业级服务总线（ESB）就是这样被创建作为支持应用程序集成的工具。但是什么是ESB呢？什么时候适合用集成套件呢？还有哪一个产品是最适合下一个项目的呢？这篇文章就解释了为什么没有一种良好的解决方法，还有为什么ESB可能也是一种错误的选择。选择正确的产品是项目成功的关键。

企业级服务总线的定义

来自不同厂商的大量产品都包含了“企业服务总线”名称。不幸地是，这个词汇并没有一个标准的定义。产品因此也提供许多不同的特性。在ESB被使用之前首先应该有个清晰的定义。在下面的内容中，ESB是被定义为一种协助开发者的应用集成软件产品，并且提供必要的基础设施去实现路由，转译和一些其他的集成工具。在集成的复杂路径，ESB通常介于框架和套件作为应用集成的替代，正如以下图片所示：



图片1：替代应用集成

在ESB被定义之后，下一节解释什么时候ESB应该被考虑，并且什么时候集成框架或者集成套件是一个更好的选择。

集成架构

集成架构以标准化的方式集成应用，提供了各种企业集成模式（EIP，Enterprise Integration Patterns）的具体实现，如分离器、基于内容的路由等等。使用标准API来集成产品在显著地降低实施成本的同时，也能够使代码清晰易懂。集成架构十分适合于集成使用不同技术开发、通过各种不同协议进行交互的各类应用，并且能很好地支持用于描述集成逻辑的各类概念，如端点、生产者、消费者和各类企业集成模式等等，这些概念也间接的支持了测试自动化。集成架构包含一系列通用的类库，可适应各类开发环境，即使最普通的文本编辑器也行。

知名的集成架构包括Java方面的 Apache Camel和 Spring
Integration，以及.Net方面的 NServiceBus。

使用这些集成架构后，研发团队将多多少少地为项目的成败担负起更重大的责任，一般这些集成架构没有相应的商业支持，工具支持也不够完备，尤其对于关键的部署工作更是缺乏支持。本文接下来的部分将用于介绍ESB和相关的套件，那将是比集成架构更好的选择。

企业服务总线

就像一个框架一样，ESB用于集成应用程序。ESB是基于某一框架的隐式实现。然而，它是一种更为强大的产品。与框架相比，除了最基本的框架功能之外，ESB为应用程序在发布，管理和在运行时的监控提供了强壮的工具支持。另外，对于各类集成场景的实现提供了图形化编辑。集成逻辑能以“拖放”的方式建模，对应的源代码会自动生成。商业对ESB完全支持。

ESB相比于纯框架的最大优势在于有最好的工具，这些工具将大大降低成本和复杂度。集成问题在一个高度的抽象水平得以解决。

集成套件

套件会提供ESB所有的功能特性，除此之外，还会提供许多另外的功能如业务流程管理（BPM）、业务活动监控（BAM）、主数据管理（MDM）等等，还可以包含一个服务注册库。如果在纯粹的集成需求外还需要此类功能特性，集成套件将会很有用处。使用简单的软件栈可以使得整个集成过程清晰明了。

希望现在已经搞清楚集成架构、ESB和集成套件直接的区别了，接下来将介绍如何正确选择ESB或集成套件。

评估标准

注意，我们并不提供一个评估表并要求所有产品都符合上面列出的各种标准。就笔者的观点，这些产品提供的功能和包含的概念数量众多，之间的差异也同样多，因此几乎不可能提供出一个有效的评估表。还有，在当今的IT界，这些功能列表几乎天天在变。

因此，建议先预先定义好你的需求，然后再来评估哪些产品是最合适的。定制化的解决方案一般都很类似，而最常用的开源软件替代方案也都提供类似的特性。所以，合理的做法是在开始就确定好是使用定制化方案还是采用开源方案。

为做出最终选择，你可以参考以下评估标准：

易用性：安装过程是否复杂？需要使用多少工具软件？开发环境是否直观？
可维护性：系统管理员将如何管理产品的运行？监控服务是否有图形化界面？
社区支持：产品是否有活跃的公共论坛或邮件组？是否有足够数量的文档、教程或视频？是否有多家公司提供售后服务？
商业支持：能提供哪些选择（响应时间，7×24在线支持、邮件支持或现场支持？）所需的服务水平如何得到保障？是否能提供你首选语言的支持？
功能：所需要的功能都能满足么？
灵活性：是否能定制产品功能以符合实际需求？
可扩展性：产品如何进行扩展？其接口是否符合标准协议？
连通性：各类交换技术对应的适配器是否都具备？是否有针对B2B产品的适配器，如SAP或Salesforce？创建自己的适配器是否方便？
成本：使用该产品的总体成本是多少？需包含维护、所需的配套产品、连接器等等
许可：采用何种许可和付费模式？如果发生变化时如何处置（如增加服务器、增加CPU或迁移到虚拟机运行等等）？免费升级么？是否可降级？价格表包含所有可预计成本了么，甚至说价格表清晰可懂么？

下表对比了商业的和开源的ESB产品及套件的长处和不足（绿色表示好，***表示一般，红色表示差）。总体来说商业产品和开源产品之间的差异在于：商业产品提供更多的功能和“强有力”的售后支持。然而，问题是“这些真的是必须的么？”必须记住的是所需的付出、系统的复杂性以及费用都会相应变得更高。开源产品在易用性、灵活性、扩展性和费用方面都更有竞争力。

标准	商业产品	开源产品
易用性	安装过程相当复杂(需要厂商的顾问来安装!?)，"工具的地域"	一键安装 (有时在Mac上也能实现)，安装后几分钟即可使用，统一的操作平台
运维和监控	强大的工具支持（如运行管理和监控），无需关心源码，可通过图形界面进行定制	工具支持较弱（如运行管理、监控、和其他厂商的产品进行集成），无需关心源码，可通过图形界面进行定制
社区支持	购买服务，有论坛（但不是能获得帮助的真正的社区）	开源项目有对应社区，同时产品也有自身的社区
商业支持	7×24商业支持，SLA任你选择， 无数的服务商	7×24商业支持，但选择面更小，需要去寻找本地的顾问和支持
功能性	集成功能再加上很多其他的功能（BAM, CEP, EDA,等等等等等）	集成功能在加上少许其他功能
灵活性	提交变更申请、再等上很久、然后等来一个付款要求，或者，付上一大笔钱、然后马上就给你搞定	开源、想做啥都行
扩展性	自己做（很难很难）或付钱购买服务	扩展基于标准，或事实标准
连通性	提供各类技术和商业产品的连接适配器	提供各类技术和商业产品的连接适配器
费用	高（十分高）	较少
许可	复杂的价格条款，什么东西都要付费（升级、迁移到虚拟机、随便其他什么。。。）	订阅付费模式、可免费升级、成本可预见、可降级

候选产品

解释完商业产品和开源产品之间的主要差异，接下来将特别介绍几个产品，将分别对这些候选产品做一个概览，包括少许实用性方面的意见。

几乎所有的商业集成产品厂商，如IBM和Oracle，提供的解决方案都包含应有尽有的功能。在开源软件方面，特别值得一提的是拓蓝统一平台和WSO2平台，因为这两家开源厂商同样提供完整的套件。此外，还有一些仅提供ESB产品，其中最终于的莫过于Mule
ESB和Fuse ESB。

Oracle Service Bus / Fusion Middleware

Oracle
Service Bus是Oracle目前的ESB产品，它是Oracle Fusion中间件系列（就是本文定义的套件）的一个组成部分，Fusion中间件套件还包含很多其他产品，例如，SOA套件、Coherence（分布式缓存）、CEP（复杂事件处理）、BPEL过程管理、企业消息服务（MQ）、服务注册管理等等。

几乎没什么功能是Oracle的套件无法提供的，各类工具都很强大而稳定，绝大多数产品都有图形化的编辑界面，各种可想像到的商业服务等级应有尽有。如果这些都是你真正需要的，那么选择Oracle绝对没错。但这些强大的套件代价不菲，并且也不要低估这些产品带来的复杂性，此外，你还必须注意不那么透明的定价模式下高级许可和支持的花费。

OFM基于Java EE、BPEL、SOAP和SCA等标准，这些产品是Oracle自行开发或不断收购来的，因此，这些产品也基于不同的代码库，并且往往需要使用不同的开发工具。下载这些产品和工具的总量会很快会超过20G。安装过程相当繁琐，往往要搞上几天，哪怕你只是将在你的笔记本上简单装下也是如此。这些产品都相当重，运行会需要相当高的资源配置。

顺便说下，你只要把Oracle替换成IBM、把Fusion中间件替换成WebSphere，以上一切仍然成立，仅有的区别是IBM官方提供3个ESB产品：Message Broker、WebSphere ESB和DataPower SOA设备（一个盒子）。同样，Tibco、微软和SAP在商业ESB和集成套件市场上也扮演着重要的角色。

总的来说，商业集成套件能够提供应有尽有的功能和服务等级，然而，很多功能和服务等级在多数项目里并用不上。在此种情况下，有必要评估下开源产品，接下来将介绍几个最重要的产品。

Mule ESB

Mule ESB是第一个成功地开源ESB。它与之前提及到的开源ESB产品有很多共同的特性。包括非常简单的一键安装("one click")和直观的基于Eclipse的工具。通常，开源ESB是非常轻量级的和可扩展的解决方案。除了免费的开源版本和紫外，商业的企业版本是可获得的。这将就对产品提供了额外的功能和支持。

对于这些仍然不清楚的，应该知道“开源”并不意味着“免费”。即使是开原供应商也必须赚钱，免费的话将无法开发产品和提供支持。然而，对于客户的价格是非常优惠的，也没有像私有产品供应商那样，建立在一张模糊的价格单上。虽然开源产品版本能在没有授权成本的情况下使用(即使在产品中)。然而，时常开源版本只用于做实验或做一个概念证明，以后升级到企业版额外的功能和支持。

作为相同的建议，Mule ESB是纯ESB。相对于像Apache Camel或Spring 集成框架，对于集成场景提供了优秀的图形化编辑实现，如SAP或Salesforce的B2B产品提供可用的连接。然而，套件的功能在Mule ESB中却丢失了。对于这种情况，ESB必须和其他供应商的产品相结合。Mule ESB的短板是开发社区小，严格的licensing 模型和悠闲的源代码。在这一点，其竞争对手有明显的优势。

Fuse ESB

Fuse ESB就像Mule ESB一样，是没有套件的纯ESB。它是基于如 Apache CXF和Apache Camel这样的集成环境中的实际的标准。因此，一个伟大的社区，由此从小到大的建立起来。开发环境是基于Eclipse，并且非常直观。

Fuse ESB是FuseSource的一部分。然而，FuseSource最近被Red Hat收购，属于JBoss的一部分了。 Fuse ESB当前被列在路线图中，并会继续得到支持。它将会被集成到JBoss企业版SOA平台-就像还收购了BPM解决方案Polymita。要成为一套统一的套件还有很长的路要走，因此 FuseSource和Polymita的集成还需要一段时间，JBoss ESB, Switchyard 和Fuse ESB等现在又三种ESB产品需要合并到一起。到这里，其余的开源供应商已经得到最好的结果。

Talend ESB/统一平台

Talend ESB是Talend套件的一部分。Talend ESB可以被独立使用，或者与Talend统一平台的其他组件组合使用。所有组件均免费且开源。其企业版提供额外的功能和技术支持。与之前提到的产品不同的是，Talend所有的组件都基于相同的基础代码之上开发，使用相同的工具。
因而可以有机地结合成为一个整体项目，无缝地应用到不同领域，如ESB，BPM，ETL，MDM等。

Talend套件的所有工具都基于Eclipse构建，并保留了Eclipse中熟悉的外观和使用习惯。Talend使用“零编码”方式，为所有的产品部件提供了可视化设计器。 从而在各种集成场景中可以更有效地进行实现。当然，你依然可以自己编写业务逻辑代码来自定义地集成你的项目，比如通过Java(POJOs)或者其他的脚本语言。

像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对硬件有更高的要求，不应该安装到一台性能不太强的笔记本上。另外一个不足就是缺少了SOA治理功能。这一功能会在以后的发布版本中添加。

WSO2 ESB / Platform

WSO2是一个相对陌生的供应商。然而，WSO2提供了一套组件所包括的整个范围，包括Business Process Server，Business Rules
Server, Business Activity Monitor或者Governance Registry。完整地WSO2平台非常容易安装，提供了一个轻量级的，基于Eclipse的开发工具。像Talend和FuseSource，WSO2同样将一些开源项目，如Apache Synapse（轻量级ESB），Axis（Web服务实现）或者 ODE（业务处理引擎）加入到它的组件中。

除了Talend之外，WSO2是唯一一个供应商，提供了一组完整套件，该套件基于单一代码和单一开发环境。因此，在迭代开发过程中没有什么表示，刚开始一个小功能，后来一步步的增加更多的功能。它的弱点是图形化工具不足。它支持平台的所有组件，但它在使用上，没有它的竞争对手表现的那样直观。

DIY自己的集成套件？

严重警告不要自行用集成框架和产品来构建自己的集成套件，这往往代价高昂，并会遇到数不尽的坑。既然已有成熟的解决方案，我们不建议自己在创建一个。你会需要写很多胶水代码来组合这些产品，需要测试并修复缺陷，在遇到问题时也找不到帮助。比如你想把不同厂商的ESB和BPM产品整合在一起，那出问题的时候你去找那个厂商获取支持呢？产品厂商往往会说是其他厂商的产品有问题。因此，既然已经有人仔细的考虑过如何将框架和产品集成为套件之类的问题，并且提供出了完整的解决方案（也包括开源的），你为何还要自己再去研究一般同样的问题呢？

总结

没有解决集成问题的银弹。

首先，需要评估下是否集成框架就足够解决问题了。需要注意的是选择了集成框架，大部分代码都要自己写了，工具和支持也都是没有的。如果不是，那么ESB就是更好的选择。而且，如果后续将使用某个套件中的产品，那么最好一开始就使用这个套件中的ESB产品。这可以保证在组合这些产品时避免发生问题或产生费用。

如果要使用ESB或集成套件，那边必须考虑是用商业产品还是开源产品。商业解决方案可提供所有可能的功能特性，并有强大的售后支持，然而同时也会带来更高的开销，同时也会导致系统的高复杂性。与之相对的是，开源产品一般花费较小，同时更加易用和灵活。一旦确定后就可以列出一个备选列表并进行细节方面的评估。强烈建议在确定最终方案前做个POC，并确保是由你的团队而不是厂商的顾问来实现原型，因为你的团队将来需要在厂商顾问无法到位的情况下独自安装产品和解决问题。