公司内外的不同应用间需要进行相互通信。企业服务总线（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或套件。