問題：企業應用程序集成（EAI）
由于新產品和新應用，幾乎每個公司都必須進行企業應用程序集成。 集成這些應用程序會產生一些問題。 每十年出現新的范例，例如客戶端/服務器通信，面向服務的體系結構（SOA）或云計算。
此外，出現了不同的接口，協議和技術。 如今（而不是過去（很多年前））將數據存儲在文件中，而不再使用SQL數據庫。 有時，在某些用例中甚至需要NoSQL數據庫。 同步遠程過程調用或異步消息傳遞用于通過多種技術（如RMI，SOAP Web服務，REST或JMS）進行通信。 存在許多軟件孤島。 盡管如此，這幾十年來的所有應用程序和產品都必須相互通信才能完美地協同工作。
企業集成模式（EIP）
當然，您可以徹底解決每個問題，編寫一些意大利面條式代碼，并使應用程序協同工作。 不幸的是，您的管理層將不喜歡該解決方案的長期前景。
企業集成模式（www.eaipatterns.com）幫助分散問題并使用標準化方法集成應用程序。 使用這些，您總是使用相同的概念來轉換和路由消息。 因此，最好在每次遇到問題時都不要重新發明輪子。
集成系統的替代方法
存在用于集成應用程序的三種選擇。 EIP可以在每種解決方案中使用。
解決方案1：自己的自定義解決方案
實施適合您的問題的單獨解決方案，而不必將問題分成幾小部分。 這可行，并且可能是小型用例的最快替代方案。 您必須自己編寫所有代碼。 如果團隊成員更換，維護成本可能會很高。
解決方案2：集成框架
使用有助于使用幾種集成模式以標準化方式集成應用程序的框架。 它大大減少了工作量。 每個開發人員都將很容易理解您的工作（如果他知道所使用的框架）。
解決方案3：企業服務總線（ESB）
使用企業服務總線來集成您的應用程序。 在幕后，ESB還使用了集成框架。 但是還有更多功能，例如業務流程管理，注冊表或業務活動監視。 通常，您可以在圖形用戶界面中配置路由和諸如此類的東西–您必須自己決定是否可以降低復雜性和工作量。 通常，ESB是一個復雜的產品。 學習曲線要??高得多。 但是，您將獲得一個非常強大的工具，該工具應該可以滿足您的所有需求。
什么是Apache Camel？
Apache Camel是一個輕量級的集成框架，可實現所有EIP。 因此，您可以使用所需的模式輕松集成不同的應用程序。 您可以使用Java，Spring XML，Scala或Groovy。 您可以想象到的幾乎每種技術都可以使用，例如HTTP，FTP，JMS，EJB，JPA，RMI，JMS，JMX，LDAP，Netty，以及許多很多其他技術（當然，大多數ESB也提供對它們的支持）。 此外，可以非常輕松地創建自己的自定義組件。
您可以將Apache Camel作為獨立的應用程序部署在Web容器（例如Tomcat或Jetty），JEE應用程序服務器（例如JBoss AS或WebSphere AS），OSGi環境中或與Spring容器結合使用。
如果您需要有關Apache Camel的更多信息，請訪問其網站作為起點： http : //camel.apache.org 。 本文暫無技術介紹J
什么時候使用Apache Camel？
如果要集成具有不同協議和技術的多個應用程序，Apache Camel很棒。 為什么？ 我非常欣賞其中一項功能（除了支持多種技術之外，還支持不同的編程語言）： 每個集成都使用相同的概念！ 無論您使用哪種協議。 無論您使用哪種技術。 無論您使用哪種域特定語言（DSL），它都可以是Java，Scala，Groovy或Spring XML。 您以相同的方式進行操作。 總是！ 有生產者，有消費者，有端點，有EIP，有自定義處理器/ bean（例如用于自定義轉換）和參數（例如用于憑證）。
這是一個包含使用Java DSL的所有這些概念的示例：
from（? activeMQ：orderQueue“）.. transaction（）。log（? processing order“）。to（mock：“ notYetExistingInterface”）
現在讓我們看一下使用Scala DSL的另一個示例：
“ file：incomingOrders？noop = true”過程（新的TransformationProcessor）到“ jdbc：orderDatastore”
如果您是開發人員，那么您應該能夠認識到這些路線的作用，不是嗎？
另外兩個非常重要的功能是對錯誤處理（例如，使用死信隊列）的支持和自動測試。 您可以使用Camel擴展的JUnit輕松測試所有內容！ 同樣，無論您要支持哪種技術，您都始終使用相同的概念。
Apache Camel已經成熟，可以投入生產了。 它提供可伸縮性，事務支持，并發和監視。 FuseSource可提供商業支持： http : //fusesource.com/products/enterprise-camel
什么時候不使用Apache Camel？
好吧，是的，在某些用例中，我不使用Apache Camel。 我已經在下圖中說明了這一點（請記住我上面提到的三種選擇：自己的自定義集成，集成框架，企業服務總線）。
如果您只需要集成一種或兩種技術（例如讀取文件或發送JMS消息），則使用一些眾所周知的庫（例如Apache Commons IO或Spring JmsTemplate）可能會更容易，更快捷。 但是請務必使用這些幫助程序類，純凈的File或JMS與try-catch-error集成非常丑陋！
盡管FuseSource提供了商業支持，但我不會將Apache Camel用于大型集成項目。 在大多數情況下，ESB是完成此任務的正確工具。 它提供了許多其他功能，例如BPM或BAM。 當然，您也可以使用幾個單一的框架或產品并“創建”自己的ESB，但這是浪費時間和金錢（在我看來）。
已經有幾種生產就緒的ESB。 通常，開源解決方案比諸如WebSphere Message Broker之類的商業產品更輕巧（您可能只需要一兩天即可安裝該產品的評估版）！ 著名的開源ESB是Apache ServiceMix，Mule ESB和WSO2 ESB。 順便說一句：您是否知道某些基于Apache Camel框架的ESB（例如Apache Service Mix和Talend ESB）。 因此，如果您喜歡Apache Camel，則也可以使用Apache ServiceMix或基于ServiceMix的商業化Fuse ESB。
結論
Apache Camel是一個很棒的框架，用于將應用程序與不同的技術集成在一起。 最好的事情是您始終使用相同的概念。 此外，對許多技術的支持，良好的錯誤處理和輕松的自動測試使其可用于集成項目。
由于每個公司的應用程序和技術的數量將進一步增加，因此Apache Camel擁有美好的未來。 今天，我們有了應用程序孤島，十年后，我們可能會部署在Goggle App Engine，CloudFoundry，Amazon EC3或任何其他云服務中的云孤島。 因此，我希望Apache Camel也不會為適應云時代做好準備（例如，通過提供易于連接到云框架的組件）。 但這就是未來。如果您必須在JVM / Java環境中集成應用程序，那么現在您真的應該嘗試一下該框架。
順便說一句：我知道我在本文中贊揚Camel，但我既不是Camel的提交者，也不是FuseSource的工作人員。 我只是真的很喜歡這個框架。
最好的祝福，
參考： 何時使用Apache Camel？ 從我們的JCG合作伙伴 Kai Wahner在關于Java EE / SOA /云計算的博客上的博客。
翻譯自: https://www.javacodegeeks.com/2012/07/when-to-use-apache-camel.html
