apache camel

首先，為全面披露信息，在過去的1.5年中， 我一直擔任 FuseSource（現為Red Hat） 的顧問，為零售，運輸，銀行/金融等不同行業的大型和小型公司提供SOA和集成項目支持。我的專長是使用該領域的一些最佳開源項目來設計具有高可伸縮性和吞吐量要求的解決方案： Apache ActiveMQ ， Apache Camel ， Apache ServiceMix ， Apache CXF等。

我是Apache Camel的DZone Refcardz的作者之一，題為“ Apache Camel Essential Components” ，也是同一標題的網絡廣播的發言人。 我還是Packt Publishing即將出版的有關Apache Camel的書的技術審稿人，我希望很快能公開發布該書。

不用說，我已經使用Apache Camel做過一些工作，對此我做出了貢獻，并鼓勵人們進行檢查。

但是在開始使用FuseSource之前，我曾與其他中間件集成項目打過交道-一些開源，一些商業，但是我第一次嘗試輕量級開源集成項目并不是使用Apache Camel。

我在2009年偶然發現了Spring Integration ，非常喜歡它。

我寫了有關Spring Integration的博客 ，對用戶論壇做出了貢獻，對bug修復和示例做出了貢獻等，在社區中保持了一些活躍。 我非常尊重Mark，Oleg，Gary，Gunnar等。 等 在Spring Integration上所做的出色工作。

我喜歡它如何擴展Spring以及它如何緊密實施由Gregor Hohpe和Bobby Wolf分類的Enterprise Integration Pattens 。 那時我在幾個項目上使用過它，我堅信除非您將它用于實際項目上以解決實際問題，否則您對項目沒有真正的感覺。 但是，由于我有機會足夠深入地使用了這兩個項目，因此我想為Blogo貢獻我的觀察和見解

首先，有很多文章比較了兩個項目。 有些關注統計數據，例如社區活動或組件數量。 盡管在某種程度上相關，但我想更深入一點。 因此，以下博客文章是我對Apache Camel和Spring Integration的想法 ，以及（破壞者警報！）為什么我會選擇Camel作為集成項目。

抽象，抽象，抽象

這兩個項目旨在滿足類似的需求：輕量級的集成庫，具有EIP的完整實現，用于中介和路由，以及在常用技術之上提供抽象以與外部系統接口。 一些常見的技術包括Web服務（SOAP / REST），JMS或異步消息傳遞，基于文件的批處理系統，TCP套接字，FTP / SFTP，RDBMS等。 基本上，只要兩個異構系統需要同步或異步進行交互并交換數據，輕型集成庫就可以為您提供極大的幫助。 對于那些問“不是ESB做什么的人？” ..恩……有點……但是我可以再寫一次。

對于我們這些集成系統的人來說，我們很快就發現了有關集成的兩件事。 ＃1不性感，＃2很難。
了解系統在技術和語義上的差異以及如何將其用于實現業務功能至關重要。 您最終編寫的代碼應專注于這些業務問題，并應盡可能利用現有的商品組件。 編寫代碼以與文件系統交互或將消息發送到隊列絕對被認為是商品代碼，只是增加了必須維護的代碼庫。 如果您手動/滾動自己編寫代碼，那么您還承擔將錯誤引入對業務邏輯或業務語義不是至關重要的區域的風險。 以我的拙見，這是不必要的風險。

這樣便可以使用Apache Camel或Spring Integration。它們通過提供對社區審核過的商品組件的訪問以及實現常見的EIP（如轉換，路由，過濾，拆分/聚合等）來幫助簡化集成項目。再次..由社區審查。 如果您手動編寫這些代碼，祝您好運。 當然可以做到，人們一直都在這樣做，但這對大多數項目來說都是不必要的風險。

我在哪里

是的，因此您可以將這兩個項目中的任何一個視為特定技術之上的“抽象”。 這個抽象概念使您可以專注于“集成應該做什么”。 為了解決這個問題，我相信Apache Camel很有意思。

領域特定語言

集成要比編寫的要經常讀得多..與代碼相同。 因此，就像您渴望編寫帶有短函數，描述性變量，適當級別的數據隱藏等的精美代碼一樣，集成項目的編碼也是如此，但將其帶入了一個新的高度。 您想要對其進行編碼，以便您可以閱讀并理解它。 盡管使用了集成代碼，即使您的代碼編寫得井井有條，“正在集成的內容”的全部含義和意圖最終仍會丟失在成堆的代碼中。 您可以利用集成抽象庫，但是就上述目的而言，它們與它們一樣好，但您想要的是清楚地回答“正在集成什么”。

Apache Camel提出了一種領域特定語言 ，我相信這是兩個項目之間的重要區別。 使用DSL，即使面對中等到復雜的集成，其他項目也開始不清楚，您可以非常簡潔地表達“正在集成的內容”。 Apache Camel 以Java（我最喜歡的），Spring XML，Scala，Blueprint-OSGI，Groovy ..以及其價值（甚至是Kotlin）提供DSL。

使用DSL，您可以使用“ from”，“ split”，“ choice”和“ to”之類的結構來構建集成“ Routes”。 這些使您可以用通用語言指定“集成正在做什么”。

當我使用Spring Integration時，他們沒有DSL。 您使用Spring XML直接處理了通道和組件（管道和過濾器），而通道是主要的抽象。 他們當時在Scala DSL上工作，但是盡管我很喜歡Scala，但它仍然沒有得到廣泛使用，因此出于在通用語言或XML集成項目中使用它的目的，沒有太多選擇。 基本上，您將端點（如jms-gateway或http-gateway）與通道連接在一起，并將通道的另一端連接到諸如Splitter或Router的EIP。 但是對于要連接的每個組件，您還必須注意使用哪個Channel的輸入是什么，以及它具有什么輸出。

一旦您的項目開始發展，您就會發現通道對象激增。 最終稀釋了集成的含義。

例如，看一下Cafe Spring Integration Example 。 這個例子并不復雜，但是它說明了我遇到的問題。 想象一下在許多Spring上下文文件中拆分通道和組件，您會看到它如何變得非常混亂。

這是使用Apache Camel實現完全相同的示例的方法：

當然，我不希望人們能夠在不了解或未使用各個庫的情況下準確掌握每個示例的操作，但是毫無疑問，我發現閱讀以駱駝式DSL表示的富有表現力的DSL更容易。與嘗試解釋所有通道的SI路徑/流量。 這使我更接近“此集成的功能”，而不會為細節所困擾。

測試中

編寫集成流程的另一個非常重要的部分是測試。 我不會像往常一樣大聲疾呼，如果不測試代碼，你會是個傻瓜，但是即使不測試集成，也會加倍。 他們所能達到的復雜程度以及所涉及的調解，都需要驗證其是否有效！！

當時，Spring Integration沒有專門用于測試路由的良好實踐。 大概是因為他們已經有一個針對Spring本身的通用測試框架 。 您可以肯定地做到這一點，因為我們都習慣于使用Spring編寫單元測試或集成測試，并使用EasyMock或Mockito模擬合作者 ，對嗎？ 而且，如果您需要任何其他功能，則必須自己構建它們。

但是，有了Apache Camel，就可以立即使用豐富的測試支持，并且可以很容易地使用它來鼓勵測試您的路線。 Camel的測試框架建立在Spring Test的某些功能之上，因此最終成為兩全其美。 例如，您可以模擬會影響實時系統的路由部分，并專注于路由和中介功能。 您可以像使用Mockito一樣設置期望和斷言行為，但是它內置在庫中并添加了其他功能。 我的同事David Valeri擁有出色的測試和調試博客，以及他在CamelOne上的演講

例如，在以下代碼段中，我們可以斷言在5000ms的時間內在模擬端點上收到了兩條消息：

您甚至可以通過應用AOP建議來模擬實時端點，如下所示：

除了模擬組件之外，如果您在執行OSGI時無需部署到容器，您還可以獲得協助測試Blueprint XML的功能，您可以使用DataSet組件進行浸泡測試或壓力測試，以及許多其他復雜的測試場景。

查看這些鏈接以獲取更多信息：

• 端點測試：數據集
• 端點測試：模擬
• 端點測試：測試
• 淘汰實時技術
• 駱駝測試
• 駱駝彈簧測試
• 藍圖測試

社區

最后，但同樣重要的是，我想指出的是，Apache Camel擁有一個充滿活力的多元社區，由來自世界各地的不同公司的不同項目的參與者組成。 在寫到郵件列表或提交JIRA之后，幾分鐘之內就能收到回復并不罕見。 您可能希望在非營利性的核心開源基金會（如Apache Software Foundation ）中找到相同的生態系統，而在其他項目中卻不會完全一樣。

我當然不是說Spring Integration論壇和JIRA并不活躍，但是我認為Apache Camel項目中非項目或公司（VMWare / SpringSource）人員的活動更多。 在我看來，這傾向于培養更多的創造力，更多的外部人做出貢獻并使項目變得更好等，這是開源和開放社區發展的核心。 當然會有更多的爭論，但最終結果是非常積極的。

在有關Spring Integration與Camel的其他一些文章中，作者指出Camel比Spring Integration具有更多的組件。 這里有一個更大的連接選項方面的觀點，但我認為更重要的一點是，其中許多是由非核心的Camel開發人員貢獻的。 另外，您可以嘗試在github上進行快速搜索，您會發現人們編寫的Camel組件甚至還沒有帶到Apache社區，但是您仍然可以利用。

您應該使用哪一個？

因此，我在這里幾乎永無止境的散文中發表了自己的見解。.但我鼓勵您檢查兩個項目并自己決定。 其他人將有不同的經驗和意見，并且在一定程度上將在決定下一個集成項目中使用哪個方面起很大作用。

以上是我的觀點。 但是，如果我遺漏了某些內容或歪曲了某些內容，請發表評論并糾正我！

參考： 輕量級的開源集成：Apache Camel還是Spring集成？ 由我們的JCG合作伙伴 Christian Posta在Christian Posta –軟件博客博客中獲得。

翻譯自: https://www.javacodegeeks.com/2013/10/light-weight-open-source-integration-apache-camel-or-spring-integration.html

apache camel

總結

以上是生活随笔為你收集整理的apache camel_轻量级的开源集成：Apache Camel还是Spring集成？的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。