在 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，这是个资源消耗过程。
暂无签名
腾讯云云原生提质增效实践精选集 2024
《2024腾讯云云原生提质增效实践精选集》出炉，5大热门技术领域，13个行业精选标杆案例，痛点到解决方案全...
评论