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

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

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

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

　　集成框架会帮助实现企业集成模式（Enterprise Integration Patterns，EIP），如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：专有和开源产品的优势与劣势

接下来我们讲会谈一下ESB产品