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允許其他消息類型，那么我想你會需要更多轉換器，但是我猜這些轉換器就是綁定組件。