Mule ESB OpenESB ServiceMix 英文原文：Comparing Mule ESB and Open ESB / Glassfish ESB 当你准备使用ESB 做集成的时候，一定要记得ESB是一种体系结构，而非一个产品。为集成体系结构创建一个完全标准化模型本身就是一个复杂的问题，因为具体需求的解决方案是因不同的用例而变化的。 尽管ESB体系结构已经逐渐成熟，可以预计某些功能的实现，但是该模型本身也只是一个模型而已。技术规范可以用来区分不同的ESB产品，但是其他的一些因素也必须要考虑，例如整体的理念，易用性，未来发展的路线以及特定产品和公司文化的适应性 例如，一个公司的所有开发都习惯于用他们自己选择IDE工作，那么强制他们使用其他的工作环境就会引起极大的延误，而这作为集成的关键会对工程项目造成极大的损害 有一个简单方式来获得两个不同ESB产品的主要区别，即从“以需求为基础”的角度来分析理解。这是一个两步走的过程——首先，确定内部需求，一个组织应该确定其内部需求，而这个需求一定要满足成功的系统集成解决方案。其次， 比较需求，找到其设计满足你需求的ESB产品。 当你定义你所属组织的需求的时候，从基本的技术需求开始—与遗留系统的平稳连接，由于兼容性导致已存在 的组件无法被移除等等。这些看起来像是大问题，事实上却很容易解决—你需要做的，就是对你的基础设施做全面认真的审视。

更进一步，对于更困难的需求—努力从战略的角度来描述你的集成需求。记住一个从书面上看起来很好的解决方案但最终证明太困难而无法实施，就不是一个真正的解决方案。例如需要考虑的各种因素，包括已有的开发技能，一类解决方案的开发路线图，成本，可扩展性，时间框架，与在所选平台上开发的难度，等等。

从“需求为基础”的角度审视  Open ESB / Glassfish ESB

开放的ESB是由Sun公司最初支持的一种开源的ESB。Glassfish ESB是该项目被商用支持的一个分支版本，与Sun的Glassfish Java EE服务相集成。开放的ESB与Glassfish ESB的设计都是彻底的严格的遵守JBI标准。JBI，意思是Java业务集成，是一类JCP创建标准，用于规范行业内集成组件体系和发布，通过创建附加容器来管理组件—属于“容器的容器”的一种。

该标准(指JBI标准)的两个最重要的价值就是来自不通过项目的组件能在其他的项目中得到重用，对行业内所有的服务采用单一的框架和集成相关的开发能规范技能组合与最佳实践。然而该标准由大多数供应商（不包括IBM和Oracle）支持并交付,不成熟标准的局限性，导致（供应商）热情的急剧降温，大部分供应商或大大缩减他们对JBI的支持，或彻底移除。JBI2.0解决了其中一部分问题，但却遭遇了相似的命运，（JBI2.0）部分被逐渐流行的OSGi(Open Service Gateway Initiative)标准掩盖。

既然JBI为业务集成寻求创建一个标准框架，当开发集成解决方案和服务的时候，开放的ESB和Glassfish ESB均坚持了该标准所提倡的某些做法。除此之外要求所有组件在JBI容器内能被管理，并遵守如标准化消息（服务）等JBI规范，而不是本地POJO通信，在那些容器中JBI的实施并没有规定，但与WSDL服务描述协议有着紧密的联系。

作为各种各样JBI标准的参考实现，开放的ESB同样与其他JCP创建标准有着紧密的联系，正如BPEL，在开放的ESB和Glassfish上执行业务流程，意味着使用BPEL无需额外的扩展。既然是Sun支持的项目，开放的ESB和Glassfish ESB与Sun的其他开发工具，如Netbeans和Java EE紧耦合也就很正常了。同样，作为Glassfish应用服务项目的子项，Glassfish ESB必须是部署在Glassfish应用服务器上。 本文中的所有译文仅用于学习和交流目的，转载请务必注明文章译者、出处、和本文链接。 2KB翻译工作遵照 CC 协议，如果我们的工作有侵犯到您的权益，请及时联系我们。

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