Mule ESB JBoss ESB 英文原文：Comparing Mule ESB and JBoss ESB 对于工期紧张，任务繁重的项目，人们常常作出轻率的决定：要求比较平稳的项目计划，或者提出古灵精怪的整合需求。在 SOA（基于服务的架构）的发展历程中常常可以见到，不统一规划整合方案，往往是对整个架构（以及IT预算）的最大危害之一。 怎样选择一个高效和合理的整合方案呢？其实很简单：先放下项目计划，将精力集中在项目组的整合需求上。为了找到一个合适的整合方案，你需要兼顾项目时间，项目预算，项目后期发展需求，是否适合项目组文化，以及符合技术上的要求。如果一个解决方案不能在项目时间内完成，或者导致项目组出现财政问题，那么这根本不能被称之为解决方案。 因此，为了不受开发商言论的影响，找出整合方案产品之间的差异，最好的方法是：从需求的角度去考察这些产品的特性。也就是说，到底这个产品是为了解决什么问题？怎样把项目组的需求转换成那个产品能解决的问题？

从需求的角度来考察 JBoss ESB

JBoss ESB 是一个来自 JBoss 的 ESB 风格的整合方案产品。这个产品诞生于2006年，JBoss 收购了商业化的 Rosetta 产品并将其开源，这就是JBoss ESB 的前身。当时 JBoss 社区强烈要求一个 ESB 风格的整合方案，用来将 JBoss 的不同产品（JBoss服务器，JEMS等）整合到一起。为了加速 JBoss ESB 的开发，JBoss 收购了 Rosetta。在重用 Rosetta 的组件后，JBoss 社区很快就开发出了 JBoss ESB，可以很容易地应用到 JBoss 产品中。

JBoss ESB 必须部署到 JBoss JEE 服务器，它使JBoss服务器可以更加紧密地与 JEMS 和 JBossMQ 结合起来。由于JBoss ESB 是用来将其他 JBoss产品整合起来的，它的发布周期和这些产品似乎密切相关。 相对于其他整合方案产品，JBoss ESB 的开发路线比较保守。

由于需要与其他 JBoss 产品紧密整合，JBoss ESB 实现了一个 相对宽松的整合架构。这个架构是支持大部分现行标准的，但是与其他 ESB 有很大的不同。从一开始，JBss ESB 就只针对特定的人群（JBoss用户），设计上独树一帜，完全不受 Mule （目的明确，注重现实需求）及其他整合方案产品（严格遵循某个标准，如JBI）的影响。因此，业界普遍认为 JBss ESB 的 学习曲线比其他产品更陡峭。

如果你的整合方案涉及大量 JBoss 组件，那么你应该考虑使用 JBoss ESB。

Mule ESB-针对真实世界里系统整合的需求

Mule ESB以其超过150万的下载量及其2500次上线部署成为了世界上使用最广泛的开源级别的企业级总线服务。Mule ESB具有的简单开发模式和轻量级架构，使得开发人员可以在短时间内掌握，并且很容易用来创建于整合系统应用服务。Mule ESB去掉了整合的繁琐部分，帮助开发人员能够轻易地建立各类型系统与服务之间高性能、并且跨协议的（信息）交互。

Mule ESB与其他诸如JBoss的ESB的区别在于，Mule项目所体现出的建立在满足真实世界里的系统整合的需求。许多整合的方法（严格遵循一个简单准则，协调配合其它供应商的应有职责等等）虽然纸面上看上去很美好，但在（公司、企业）集团尝试在生产环境上实施整合系统时，却会导致很多重大问题。
这些方案失败的原因有很多：为了所谓的“严格 遵循规范”，很多企业设计的架构使用了诸多标准，即使对这些标准不熟悉，开发者也不得不勉强地着手工作；为了降低成本而对整合方案作出了各种不必要的甚至是有害的条条框框；整合方案被过度设计，或者完全不经过抽象设计，使得后期难以整合新技术等。 与此相反，Mule 是 基于现实世界的整合需求而设计实现的。很多项目组选择 Mule 的首要原因是“这个方案能够快速地解决我们目前的整合问题，并且将来也能很容易地进行扩展”。Mule 对现行标准支持得很好，封装良好的跨协议整合，有一个活跃着诸多整合方案专家的开源社区，并且有着不断改进的开发路线图。正是由于这些优点，很多采用开放架构的项目组都选择使用 Mule 来做整合方案。 本文中的所有译文仅用于学习和交流目的，转载请务必注明文章译者、出处、和本文链接。 2KB翻译工作遵照 CC 协议，如果我们的工作有侵犯到您的权益，请及时联系我们。

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