在 Mule宣告发布2.0版本几周后，Mule(“一个轻量级和高可伸缩性ESB”)的奠基人Ross Mason将Java业务集成(JBI)和Mule架构进行了比较。
Ross说，使他决心实现自己的架构而不是JBI架构的原因是，在JBI 1.0规范中缺失了某些东西。在他的观点中，过于依赖XML，缺乏可重用性的JBI部件(绑定组件，服务引擎)，重型API最引人注目。
Ross Mason认为JBI目标范围太广是降低JBI部件可重用性的原因之一：
按他们的天性，厂商为了竞争会使他们彼此不同。因为JBI试图定义每件事情应该工作的方式，厂商就不得不内置规范之外的特性和替代方法来使他们的服务容器各具特色。这就破坏了可重用性。因为，一个可在某个容器正常工作的JBI绑定组件并不一定能在另一个容器中以同样方式工作。
JBI社区中的厂商试图使自己产品与竞争对手有所不同，厂商总是这么干，但是每个厂商的实现部件都会在性能、可靠性和工业范围标准的支持级别上下工夫。JBI 1.0是第一个试图为集成需求提供答案的规范，不免有些缺点，它们有望在JBI 2.0中得到解决。
同样，Ross一再表示JBI的API过重，开发者如果想要开发JBI部件的话，需要了解的JBI规范知识比他们本应需要了解的要多：
要实现服务，你需要实现相当多的API。这意味着书写服务的伙计对JBI的理解比必须的要多。Mule总是认为服务可以是任何东西，如一个POJO、EJB会话Bean或另一个组件的代理……
埃森哲的高级顾问James Lorenzen，这样回答Ross的关于JBI的重型API的观点：
我不同意JBI使用者必须了解的JBI知识比必须的要多，不过话说回来，扮演那样的人对我来说很难，因为我也是一个组件开发者……
以及
另外，我不会花太多时间给非JBI使用者讲JBI。但是我会忽略规范，直接向他示范可以如何使用JBI。
Ross的博客中另一个重要观点就是，规范化消息路由器(Normalized Message Router，NMR)的以XML为中心的天性：
XML消息被用来四处移动数据。这适合某些系统，但是对于大多数遗留系统则不然。构建它们的时候XML还不存在。它们使用不同的消息类型，如Cobol CopyBook、CSV、二进制记录、自定义扁平文件等。
James Lorenzen解释了NMR如何受益于这个以XML为中心的天性：
由于任何事物都被转换成XML在NMR上传送，唯一需要的转换就是XML。那么你说的是对的，但是对于JBI使用者，我认为它不是问题。另一方面，我认为，如果NMR允许其他消息类型，那么我想你会需要更多转换器，但是我猜这些转换器就是绑定组件。
文章来源于领测软件测试网 https://www.ltesting.net/
