Mule ESB ServiceMix 英文原文：Comparing Mule ESB and Servicemix / Fuse ESB ESB（ Enterprise Service Bus 企业服务总线）并非一个产品，而是一种架构。如果两种集成解决方案都称自己为ESB，那么实际上他们为达到同一目的而采用的方法或许完全不同（在某些情况下，他们甚至对于如何定位目标都存在不同看法）。
正因为这个原因，在选择ESB解决方案时，重要的是不要太纠结方案的名称，而要多关注不同方法的架构所能解决的具体需求。 在讨论集成需求的时候，对特定的消息格式或模式的支持等技术问题会立刻浮现我们脑海中。然而，其他的一些因素也属于集成需求范畴，比如支出、解决方案的路线图、项目时间表与易用性、具体的业务需求等因素。

换句话说，当在两种集成方案进行决策的时候，对一定数量的特性进行列表对比同样必要，它是更加有用的，对于创建高优先级的，提供的解决方案必须满足的大图片列表式的需求，并与该列表的竞争者进行对比。

从需求导向来考察SerivceMix和Fuse ESB

ServiceMix是一个Apache的开源ESB项目，Fuse ESB则是其对应的商业版本。与其他大多数ESB产品类似，ServiceMix和Fuse ESB都采用了以标准为基础的集成方式。然而，ServiceMix和Fuse ESB与其他ESB产品一个重要差别在于其更注重支持JBI标准，这一差别也能反映它们（指SerivceMix/Fuse ESB）在其设计之初所要达到的目的。

JBI（Java业务集成），属于JCP创建标准，该标准确定了对特定网络的所有组件都具有统一的消息格式和部署模式。然而（JBI）最早来源于大规模供应商的支持，设计用于提供在Java平台上模块化和便携式的编写集成代码的统一方法，可JBI很快丧失了（其上升的）势头，由于大多数组织无法承担中途放弃而转向一种严格的（但）无法满足大量（标准之外）的复杂需求的新“标准”。最终，大部分供应商（创建JBI标准的）放弃了该标准（JBI）并移除或降低他们产品对JBI的支持。因此，目前JBI仅在一小部分集成项目中被使用，包括 ServiceMix/Fuse。

有一种思考方式是将JBI看做“容器的容器”，一种抽象的附加层和基于为了进行通信而必须将网络中的每一个元素进行封装的组件。JBI通过要求运用一种被“标准化”的组件来创建每一条消息—在（该消息）被其他组件接受之前，从它原来的格式转换成XML格式。该标准（JBI）的其他特点同样适用于严格的模式—配置必需用WSDL（Web Services Description Language WEB服务描述语言）格式来编写，而不是任何其他格式，更多的是倾向于BPEL（Business Process Execution Language 业务流程执行语言）。

作为委员会创建的一类标准，JBI一度遭遇到了很多外部的问题，除了它自身功能的限制。首要的问题是很少被采用。大多数成功的JSRs(Java Specification Requests Java规范请求)，被开发用来解决一些存在的没有满足的需求，基于事实的（满足需求）的驱动，代表了一类量身定制的解决方案。

相对来说，JSR规范中的JBI标准很特别，它（JBI）试图说服众多供应商复杂的环境，完全不同的集成需求和哲学的组织，以及已投入使用的昂贵的构架，采用一种单一的新的标准，而这种理解本身就不成熟。采用JBI作为一种普适标准，阻碍了更进一步即它（JBI）主要的价值在于对不同供应商组件之间的互协性，而很少被采用则具有一定的争议性。 如同 ServiceMix / Fuse 基于他们对标准的支持，几乎对JBI的完全支持，他们满足的原始的“需求”与对该标准严格的支持有很大的联系。因此，组织可能会选择ServiceMix / Fuse，如果他们当前的开发人员先前有过（实践）JBI的经历。 本文中的所有译文仅用于学习和交流目的，转载请务必注明文章译者、出处、和本文链接。 2KB翻译工作遵照 CC 协议，如果我们的工作有侵犯到您的权益，请及时联系我们。

2KB项目（www.2kb.com，源码交易平台）,提供担保交易、源码交易、虚拟商品、在家创业、在线创业、任务交易、网站设计、软件设计、网络兼职、站长交易、域名交易、链接买卖、网站交易、广告买卖、站长培训、建站美工等服务