Mule奠基人：JBI偏离了靶子

在 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的观点：