公司之間的數據交換增加了很多。 必須集成的應用程序數量也增加了。 這些接口使用不同的技術，協議和數據格式。 但是，這些應用程序的集成應以標準化的方式建模，有效實現并由自動測試支持 。

JVM環境中提供了三個可滿足這些要求的集成框架： Spring Integration，Mule ESB和Apache Camel 。 它們實現了眾所周知的企業集成模式（EIP， http://www.eaipatterns.com ），因此提供了標準化的，特定于領域的語言來集成應用程序。

這些集成框架幾乎可以在JVM環境中的每個集成項目中使用，無論使用哪種技術，傳輸協議或數據格式。 所有集成項目都可以以一致的方式實現，而無需冗余的樣板代碼。
本文比較了這三種選擇，并討論了它們的優缺點。 如果您想知道何時使用更強大的企業服務總線（ESB）而不是這些輕量級集成框架之一，那么您應該閱讀以下博客文章： http : //www.kai-waehner.de/blog/2011 / 06/02 / when-to-use-apache-camel / （說明了何時使用Apache Camel，但標題也可能是“何時使用輕量級集成框架”）。

比較標準

可以使用幾個標準來比較這三個集成框架：

• 開源的
• 基本概念/架構
• 可測性
• 部署方式
• 人氣度
• 商業支持
• IDE支持
• 錯誤處理
• 監控方式
• 企業準備
• 領域特定語言（DSL）
• 接口，技術和協議的組件數
• 可擴展性

相似之處

這三個框架都有很多相似之處。 因此，上述許多比較標準都是均勻的！ 所有這些都實現了EIP，并提供了一致的模型和消息傳遞體系結構以集成多種技術 。 無論您必須使用哪種技術，都始終以相同的方式進行操作，即相同的語法，相同的API，相同的自動測試。 唯一的區別是每個端點的配置（例如，JMS需要隊列名稱，而JDBC需要數據庫連接URL）。 IMO，這是最重要的功能。 每個框架使用不同的名稱，但是想法是相同的。 例如，“駱駝路徑”等效于“ M流”，“駱駝組件”在Spring Integration中稱為“適配器”。
此外，還存在其他一些與重量級ESB不同的相似之處。 您只需要在類路徑中添加一些庫即可。 因此，您可以在JVM環境中的任何地方使用每個框架。 無論您的項目是Java SE獨立應用程序，還是要將其部署到Web容器（例如Tomcat），JEE應用程序服務器（例如Glassfish），OSGi容器甚至云中，都可以。 只需添加庫，進行一些簡單的配置，即可完成。 然后，您可以開始實施集成工作（路由，轉換等）。

這三個框架都是開源的，并提供熟悉的公共功能，例如源代碼，論壇，郵件列表，問題跟蹤和對新功能的投票。 好的社區會編寫文檔，博客和教程（IMO Apache Camel擁有最引人注目的社區）。 只有已發行書籍的數量對這三者都可能更好。 可以通過不同的供應商獲得商業支持：

• Spring集成：SpringSource（ http://www.springsource.com ）
• Mule ESB：MuleSoft（ http://www.mulesoft.org ）
• Apache Camel：FuseSource（ http://fusesource.com ）和Talend（ http://www.talend.com ）

IDE的支持非常好，即使視覺設計師也可以使用這三種方法來建模集成問題（并讓他們生成代碼）。 每個框架都適合企業使用，因為所有框架都提供必需的功能，例如錯誤處理，自動測試，事務，多線程，可伸縮性和監視。

差異性

如果您知道這些框架之一，那么由于它們的概念相同和許多其他相似之處，您可以輕松地學習其他框架。 接下來，讓我們討論它們的區別，以便能夠決定何時使用哪一個。 兩個最重要的區別是支持的技術數量和使用的DSL。 因此，下面我將特別關注這兩個標準。 在所有示例中，我將使用代碼片段來實現眾所周知的EIP“基于內容的路由器”。 自己判斷，您更喜歡哪一個。

Spring整合

Spring Integration基于著名的Spring項目，并通過集成支持擴展了編程模型。 您可以像在其他Spring項目中一樣使用Spring功能，例如依賴項注入，事務或安全性。

如果您已經有一個Spring項目并且需要添加一些集成的東西，那么Spring Integration非常棒。 如果您了解Spring本身，那么幾乎不需要學習Spring Integration。 盡管如此，Spring Integration僅對技術提供了非常基本的支持-只是“基本的東西”，例如文件，FTP，JMS，TCP，HTTP或Web服務。 Mule和Apache Camel提供了許多更多的組件！
可以通過編寫許多XML代碼（沒有真正的DSL）來實現集成，如下面的代碼片段所示：

<file:inbound-channel-adapterid=”incomingOrders”directory=”file:incomingOrders”/><payload-type-router input-channel=”incomingOrders”><mapping type=”com.kw.DvdOrder” channel=”dvdOrders” /><mapping type=”com.kw.VideogameOrder”channel=”videogameOrders” /><mapping type=”com.kw.OtherOrder” channel=”otherOrders” /></payload-type-router><file:outbound-channel-adapterid=”dvdOrders”directory=”dvdOrders”/><jms:outbound-channel-adapterid=”videogamesOrders”destination=”videogameOrdersQueue”channel=”videogamesOrders”/><logging-channel-adapter id=”otherOrders” level=”INFO”/>

您還可以對某些內容使用Java代碼和注釋，但是最后，您需要大量XML。 老實說，我不太喜歡XML聲明。 它適用于配置（例如JMS連接工廠），但不適用于復雜的集成邏輯。 至少，它應該是具有更好可讀性的DSL，但是更復雜的Spring Integration示例確實很難閱讀。
此外，Eclipse的可視化設計器（稱為集成圖）還可以，但不如其競爭者那么直觀好。 因此，如果我已經有一個現有的Spring項目，并且僅添加一些僅需要“基本技術”（例如文件，FTP，JMS或JDBC）的集成邏輯，就只能使用Spring Integration。

ule子ESB

顧名思義，Mule ESB是一個完整的ESB，包括幾個附加功能，而不僅僅是一個集成框架（您可以將其與基于Apache Camel的ESB Apache ServiceMix進行比較）。 盡管如此，Mule也可以用作輕量級的集成框架-只需不添加和使用EIP集成之外的任何其他功能。 作為Spring Integration，Mule僅提供XML DSL。 在我看來，至少它比Spring Integration更容易閱讀。 Mule Studio提供了非常出色且直觀的視覺設計師。 將以下代碼片段與上面的Spring集成代碼進行比較。 它比Spring Integration更像DSL。 如果集成邏輯更復雜，則這很重要。

<flow name=”muleFlow”><file:inbound-endpoint path=”incomingOrders”/><choice><when expression=”payload instanceof com.kw.DvdOrder”evaluator=”groovy”><file:outbound-endpoint path=”incoming/dvdOrders”/></when><when expression=”payload instanceof com.kw.DvdOrder”evaluator=”groovy”><jms:outbound-endpointqueue=”videogameOrdersQueue”/></when><otherwise><logger level=”INFO”/></otherwise></choice>
</flow>

Mule的主要優點是與重要專有接口（例如SAP，Tibco Rendevous，Oracle Siebel CRM，Paypal或IBM的CICS事務網關 ）的一些非常有趣的連接器 。 如果您的集成項目需要其中一些連接器，那么我可能會選擇Mule！

對于某些項目而言，缺點是Mule對OSGi拒絕： http : //blogs.mulesoft.org/osgi-no-thanks/

阿帕奇駱駝

Apache Camel與Mule幾乎相同。 它為您可能想到的幾乎每種技術提供了許多組件（甚至比Mule還要多）。 如果沒有可用的組件，則可以從Maven原型開始很容易地創建自己的組件！ 如果您是Spring的人：Camel也具有很棒的Spring集成。 與其他兩個一樣，它提供了XML DSL：

<route><from uri=”file:incomingOrders”/><choice><when><simple>${in.header.type} is ‘com.kw.DvdOrder’</simple><to uri=”file:incoming/dvdOrders”/></when><when><simple>${in.header.type} is ‘com.kw.VideogameOrder’</simple><to uri=”jms:videogameOrdersQueue”/></when><otherwise><to uri=”log:OtherOrders”/></otherwise></choice></route>

可讀性優于Spring Integration，并且幾乎與Mule相同。 此外，FuseSource還提供了一個很好的（但商業化的）可視化設計器Fuse IDE，它可以生成XML DSL代碼。 盡管如此，無論您使用視覺設計器還是僅使用XML編輯器，它都是很多XML。 我個人不喜歡這樣。

因此，讓我們向您展示另一個很棒的功能： Apache Camel還提供了Java，Groovy和Scala的DSL 。 您不必編寫太多難看的XML。 就個人而言，我更喜歡使用這些流利的DSL之一而不是XML來進行集成邏輯。 我只使用XML做配置工作，例如JMS連接工廠或JDBC屬性。 在這里，您可以看到使用Java DSL代碼段的相同示例：

from(“file:incomingOrders “).choice().when(body().isInstanceOf(com.kw.DvdOrder.class)).to(“file:incoming/dvdOrders”).when(body().isInstanceOf(com.kw.VideogameOrder.class)).to(“jms:videogameOrdersQueue “).otherwise().to(“mock:OtherOrders “);

流利的編程DSL非常易于閱讀（即使在更復雜的示例中也是如此）。 此外，這些編程DSL比XML具有更好的IDE支持（代碼完成，重構等）。 由于這些很棒的流利的DSL，如果我不需要Mule的某些出色的連接器來連接專有產品，我將始終使用Apache Camel。 由于它與Spring的集成非常好，因此在大多數用例中，我甚至更喜歡Apache Camel。

順便說一句：Talend提供了一個可視化設計器來生成Java DSL代碼，但是它會生成大量樣板代碼，并且反之亦然（即您無法編輯生成的代碼）。 這是一個不可行的標準，必須盡快解決（希望如此）！

最終獲勝者是…

…所有這三個集成框架，因為它們都是輕量級的并且易于使用-即使是用于復雜的集成項目。 始終使用相同的語法和概念來集成多種不同的技術真是太棒了–包括非常好的測試支持。

我個人最喜歡的是Apache Camel，這是因為它具有出色的Java，Groovy和Scala DSL ，并結合了許多受支持的技術。 僅當我需要某些專有產品的獨特連接器時，才使用Mule。 如果只需要集成“基本技術”（例如FTP或JMS），則只能在現有的Spring項目中使用Spring Integration。 盡管如此：無論您選擇這些輕量級集成框架中的哪個，都可以通過輕松的工作輕松實現復雜的集成項目，這將帶來很多樂趣。 切記：繁瑣的ESB通常具有太多的功能，因此也有太多不必要的復雜性和工作量。 使用正確的工具完成正確的工作！

參考： 被寵壞的選擇：使用哪種集成框架– Spring Integration，Mule ESB或Apache Camel？ 來自我們的JCG合作伙伴 ? 關于Java EE / SOA /云計算的博客的Kai Wahner。