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

我不同意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允许其他消息类型，那么我想你会需要更多转换器，但是我猜这些转换器就是绑定组件。

绑定组件应该能以一种大家熟知的和格式良好的方式与NMR进行简单地交互，这样才有可能为每个绑定组件提供被其他组件注入到NMR中的消息。否则，在绑定组件间进行持续通信会非常难。

对于使开源成功的问题领域，Ross Mason认为是“厂商观点”：

这个世界的“厂商观点”是开源取得如此好的成绩的一个主要原因。一般说来，由开发人员书写的开源软件更接近要解决的问题。这些开发人员可以运用他们的领域知识、经验和某些方面的改进需求提交更好的解决问题的方式。这就是Mule的终极目标。假设项目成功了，我认为这个目标是通过告诫事情可以被不断改进来实现的（我们一直都这么做）。

有人可能会说规范是由来自不同厂商的社区领导开发出的，为了开发一个每个厂商都将实现的新标准加入到定义标准的行列中。通常“专家组”成员来自开发者社区，因此在JSR要解决的问题域和一个非标准开源产品之间不应该有很大的分歧。

Ross Mason和James Lorenzen都认为，当遇到流内容进入NMR时，JBI规范有缺点，尤其是任何进入NMR的事物都必须比转换成XML，这是个资源消耗过程。

查看英文原文： Mule Founder: JBI Missing the Mark