Camel in action(第一章譯文)

1 First steps

1. Camel 介紹
2. Camel路由

First    steps

Apache camel 是 一個開源的一體化框架，其目的是使一體化系統更容易。本書的第一章節咱們將介紹camel及展現它適合大企事業單位的軟件。你將會學習到關於camel的概念及一些專業術語。

第二章將介紹camel其中一個最重要的一部分：消息路由。Camel主要有兩種方式的路由規則：基於java領域的指定語言（DSL）和基於spring的xml文件的配置。這些路由技術的添加，將向你展現怎麼設計及實現路由，來解決企業系統間的集成問題。

Camel介紹

   

本章要點

• Camel介紹
• Camel主要特色
• 你的第一個camel試駕
• Camel的體系結構及內容

   

打造一個複雜的一體化系統是一個很是昂貴的實驗，而且這個實驗室幾乎不可能成功的。一個有效的而且下降風險的方式是用通過驗證的組件以拼圖的方式組裝一個一體化系統。咱們平時就依賴此一體的系統，咱們就能夠用電話交流發生的一塊兒，例如財務交易、有益於身心健康的旅行計劃或者娛樂活動。

你還不能完成一個拼圖遊戲，直到咱們有了這些能夠自由組合、無縫鏈接的集合塊。有了這樣的系統就能夠更多的關係本身的業務，不須要在考慮系統之間的鏈接及系統內部之間的工做。一個好的一體化的框架提供了簡單的，易管理的系統。

Camel就是這樣的一個框架，在本書中，咱們將幫助你理解camel是什麼，如何去使用它及爲何它是一個最好的一體化框架。

這一章就開始介紹camel框架及它核心最精彩的部分。咱們接下來將要介紹camel的分佈及解釋在本書中能夠運行起來的例子。咱們將會全面的介紹camel的最核心最精彩的部分，是你可以理解camle的體系架構。

   

1. 介紹camel

   Camel是一個整合框架，其目的是使你的全部的項目更高效有趣。Camel項目最先開始於2007年。可是它還很年輕，camel已經是一個成熟的開源項目了。在apache 2 的許可證是有效的，它有一個強大的交流社區。

   Camel 關注在簡易集成。咱們相信你到目前爲止已經完成了前面的閱讀。接下來你將會領略到camel的魅力，添加它到你的工具清單中。

   Camel項目之因此被命名爲簡單的"Camel"是 由於這個名字簡短易記。傳言camel的名字是有一個發現者抽的是駱駝牌香菸。在camel website輸入(http://camel.apache.org/why-the-name-camel.html)，camel名字清單。

   1. Camel是什麼

      Camel框架的核心是一個路由引擎，它容許你定義本身的路由規則，決定接受哪些消息，作出決定如何處理，發送這些消息給其餘目標。Camel用這種集成語言容許你定義複雜的路由規則。

      Camel的基本原則之一是不會假設任何你須要處理的數據，這是很重要的一點，由於它給大家開發者一個集成任何系統的一個機會，不須要轉換你的數據爲另外的一種公認格式。

      Camel 提供了高水平的抽象，它容許你根據相同的api協議或者系統的數據類型集成各類各樣的系統。Camel的組件提供了特殊實現的接口api，其目的是給不一樣的協議和數據類型服務。Camel打破了傳統模式，它支持80多種不一樣的協議和數據類型，它的擴展性和模塊性容許你實現你本身專有協議的無縫插件。這些體系結構的選擇淘汰沒有必要的轉換，從而使camel更加的高效，易學。結果證實，camel是適合嵌入到其餘項目中的，由於它提供了充足的處理能力。其餘開源的項目，例如Apache ServiceMix和ActiveMQ已經使用camel做爲企業集成的一種處理方式。

      咱們應該提問camel不是什麼，camel不是ESB，有些人稱camel是個輕量級的ESB，由於它支持路由、事務、監控、編制等。Camel 沒有一個容器或者一個可靠的消息總線，可是它能夠依賴例如開源的ESB或者前面提到的ServiceMix，因爲以上緣由，咱們更喜歡把camel稱做超越一個ESB的集成框架。

      理解camel是什麼，這樣可以更能好的看到它的主要功能點。讓咱們來看一下它的主要功能點。

   

1. 爲何使用Camel

Camel爲整合領域介紹了一些新奇的觀點，這就是爲何它的做者們決定在第一領域建立camel，代替正在使用已經存在的框架。咱們將經過本書介紹富有camel全部的功能點。這些功能點以下：

• 路由和斡旋引擎
• 企業集成模式
• Domain-speclfic language（DSL）
• 可拓展組件庫
• 有效負載路由
• 模塊化、組件式體系結構
• POJO模型
• 容易配置
• 數據類型自動轉換
• 輕量核心
• 測試裝備
• 充滿活力的社團

   

路由和斡旋引擎

路由和斡旋引擎是camel的核心功能。路由引擎基於路由配置有選擇的對消息進行路由。在camel的實例中，路由配置隊列是以企業集成模式和DSL。以上兩種咱們將在下面介紹。

企業集成模式（EIPS）

儘管集成的問題多中國多樣，Gregor Hohpe 和Bobby Woolf 發現了不少問題。接着大家很容易的把問題解決掉了。他們編寫一本《Enterprise Integration Patterns》書，這本書對那些專業集成的人來講是必讀的書。接下來，它將幫助你理解又快又容易地理解camel。

企業集成模式或者EIPS對咱們是有幫助的，由於它不只給咱們提供了問題的解決方案，而且也幫咱們定義了咱們所交流問題的自己。有了模式問題交流起來更容易。使用模式語言比描述須要解決的問題容易的多，就好像學習漢語比學習甲骨文要容易的多。

Camel基於EIPs是沉重的。儘管EIPs描述了集成問題的解決方案，同時也提供了通用的詞彙列表，但這些詞彙列表沒有造成書面語言。Camel就避免了這個問題，它提供了一種集成描述性語言。在EIPs和camel的DSL語言之間幾乎有一種一對一的關係。

   

Domain-specific language（DSL camel本身的描述性語言）

Camel的domain-specific language（DSL） 對集成領域來講是一個主要的貢獻。有一些相似於DSL（容許你用XML去描述路由規則）特徵的集成框架。並不像camel，他們的DSLs是基於特定語言。Camel提供了多種DSLs。例如程序語言 java、Scala，Groovy，它還容許以XML特定方式的路由規則。

DSL的目的是讓開發者關注集成問題而不是程序開發工具。儘管Camel大部分是用java開發的。可是它支持多種程序語言。每一種語言都有屬於它治的健壯性，你可能想用不一樣的語言完成的不一樣的任務。你有這樣的自由創建本身的解決方案。

這有一些使用不一樣程序語言DSL 例子。

• Java DSL

From("file:data/inbox").to("jms:queue:order");

• Pring DSL

  <route>

      <from uri="file:data/inbox"/>

      <to uri="jms:queuq:order"/>

  </route>

• Scala DSL

from "file:data/inbox"->"jms:queue:order"

   

這些例子都是真實代碼，展現了路由一個或者多個文件從一個文件夾到JMS隊列是很容易的。由於這是真正的底層程序語言，你能夠用已經存在的工具支持，例如代碼實現，代碼編譯錯誤的檢查。例如：

你剛纔看見的是Eclipse IDE的自動完成列表清單，供咱們選擇。

額外的組件庫（大量的組件庫）

Camle提供了超過80個組件的拓展庫。這些組件使camel用APIs鏈接傳送和理解數據的格式。

有效的負載路由

Camle可以提供任何一種有效的負載路由。你不能限制XML負載。這種自由的意思是你沒有必要轉換你本身的負載爲權威的容易路由格式

模塊化和組件式體系結構

Camel 有一個模塊化體系結構，它容許任何組件加載到camel中，當組件船上出現不受歡迎的組件時，那就是來自第三方或者你本身定製的組件。

POJO模型

Beans（POJO）在camel是一等公民，它致力於讓你在任何地方任什麼時候間使用beans。這也就意味着不少地方你能夠繼承camel內建功能編寫本身風格的代碼。在第四章已經討論了在camel中bean的使用。

配置簡單

配置的慣例是儘可能減小配置的要求，是爲了在路由中配置終點。Camel使用更簡單更直接的URL配置。

例如你可能配置一個文件夾下面的a.txt文件，以下：

from("file:data/inbox?recursive-true&include-*.txt")…

類型自動轉換

Camel已經嵌入了150多種自動轉換的機制。你不在須要配置類型轉換規則，例如把byte arrays 轉換爲 Strings。若是你須要一種camel沒有的轉換類型，你能夠本身去建立屬於本身的Converter。最關鍵的部分工做在引擎中，so你能夠不用擔憂it。

Camel的組件有槓桿的特色。他們能夠接受各類各樣的數據類型，把這些類型轉換爲其餘類型。他們有這個能力。在camel社區裏面這是個最受歡迎的特性。你甚至可能開始想問爲何在java自己不提供這樣的功能呢？在第三章將介紹多種類型轉換。

輕量級的核心

Camel核心被認爲是輕量級的，總共自由包加起來大約也就1.6MB，它只依賴Apache Commons Logging，資源的通用管理。這樣使camel更容易在你喜歡的任何地方嵌入或者部署。例如在標準的應用、web應用、spring應用、J2EE應用、JBI容器、OSGI bundle、java web start或者Google Appengine。Camel沒有被設計成一個server或者ESB，取而代之的是能夠嵌入到你選擇的任何平臺中。

測試工具箱

Camel提供了測試工具箱，使測試你本身的camel應用更容易。這些測試工具在測試camel自己中普遍應用。例如他們能夠幫助你虛擬真正的endpoints。它提供了安裝進度條的功能。Camel能夠根據它來判定服務是正常啓動或者啓動失敗。在第六章cover了Camel的testing。

活躍的社團

Camel有一個活躍的社團。若是在你的項目中想使用任何開源的項目，加入的該社團中是必須得。不活躍的項目幾乎沒有社團的支持，出了問題那就是你本身的問題。使用camel，若是你有任何問題，熱心的使用者和開發者會迅速處理幫助你。

到目前爲止你已經看到了camel的主要組成的功能。咱們有很少的人手在觀察camel的使用範圍和試用的例子。

   

   

1.2快速開始

咱們將介紹怎麼獲得Camel的幫助文檔，解釋camel裏面包括什麼。怎麼用Maven運行例子。After this，你將學會運行從本書源碼中的任何例子。手續看一下camel的分佈。

1.2.1 Getting camel

在官方Apache Camel上能夠看到Camel的下載地址（http://camel.apache.org/download.html）。

打開網址你將會看見你將會看見不一樣版本的camel下載列表,固然也會有最新版本的下載。

咱們將使用camel2.5.0。去下載這個版本，點擊camel 2.5.0 版本的連接。幾乎在本頁的底部你會找到兩個二進制的發佈包：爲windows用戶zip發佈包，和爲Unix/Linux/Cygwin 用戶提供的tar.gz發佈包。把下載好的包解壓開。

1.2.2 你的第一個camel例子

本書的中的例子都使用了Apche的Maven。那就意味着Camel倉庫將會自動爲你下載。本書的源碼地址：http://manning.com/ibsen或者http://code.google/p/camelinaction

    第一個例子咱們會用傳統的"hello world"：路由文件。假如你須要讀一個目錄（data/inbox）下面的文件，而後用必定的方式進行處理，而後把結果寫到另一個文件目錄（data/outbox）。很簡單，你將會跳過處理過程，你的輸出僅僅是一份原來文件的copy。圖Figure 1.2 畫出了這個過程。

看起來很是簡單是否是。如下代碼是用純java來實現的。

以上十分簡單的用例，可是用java實現仍舊須要34行代碼。你不得不使用低級的文件API，確保數據流已經關閉，這樣的程序很容易出錯。

用camel來實現以下：

但你使用Camel時大部分相似於java這樣的代碼都顯得有點樣板了。每個Camel應用使用CamelContext 中的方法進行啓動或者中止。你也能夠添加一個sleep method爲你copy文件準備時間。見listing 1.2.

Camel路由是以邊讀邊流動的方式來定義的。上面那個路由是以這樣的方式來讀的：消費者的消息來自位置爲data/inbox（設置noop選項）文件夾下面的文件，接着把文件路由到位置data/outbox中。noop 選項告訴Camel離開（保留）資源文件。如有你不使用noop選項，這個文件會被刪除掉。從沒有見過Camel的人們可以理解camel的路由作了些什麼。你可能也想關注這一點。出去掉樣板代碼，你建立一個路由文件替換上面的java code。

運行這個例子。你須要去下載and實例一個apache的maven(http://maven.apche.org/download.html)。

Note 本書上的代碼用的是Maven 2.2.1。最新版本可能出現意想不到的錯誤。

POM展示以下：

Maven自己是個複雜的話題。咱們在這不作更多的細節介紹。咱們將給你足夠的信息介紹本書中的全部例子。推薦讀 Maven by Example 和 The Complete Reference。咱們也用Maven部署應用。（沒有用過Maven的同窗，能夠去學習一下，很不錯 比ant好用）

1.3 camel消息模型

在camel中有兩個消息模型的抽象概念。下面的section咱們將會涉及到。以下：

• Org.apache.camel.Message----這個基礎的實體包含須要在camel中路由的數據。
• Org.apache.camel.Exchange----消息交換是camel的抽象概念。消息交換有個"in"消息做爲回覆，還有一個"out"消息。

咱們開始經過查看消息來理解數據是怎樣在Camel中被塑造和運輸的。咱們將看到在Camel中"conversation"是怎樣被塑造的。

1.3.1 消息

系統之間通信的時候Messages是做爲獨立實體來用的。消息從發送者的方向到消息的接受者，插入以下：

消息有一個體，頭信息及一些附加配置，以下圖：

   

消息有定義標識，標識的type是java.lang.String。消息建立的時候，其惟一標識是被迫必須被建立的。消息是依賴協議的，它沒有強制的格式。這些協議沒有定義一種消息的惟一標識庫。Camel一般用它本身的UID。

頭信息和附加配置

頭信息裏面放的是消息之間的關係，例如發送者的UID、內容編碼的跡象、認證消息等等。

頭信信息是name-value對；name是惟一的。強轉換爲String類型，由於name的類型是java.lang.Object類型的。這就意味着Camel在header類型上強加約束。頭是以Map的形式來存儲信息。一個消息可能也會有選項附加配置，例如一般被web service和email 組件使用。

消息體（Body）

消息體是java.lang.Object類型。這就意味着能夠存儲任何類型的消息。由應用設計者來決定消息接收者能夠理解的消息內容。當消息的接收者和發送者使用不一樣的body 類型。Camel提供了一些轉換能夠接收格式的數據機制。

失敗標誌（FAULT FLAG）

消息也有一個失敗標誌。

   

1.3.2 交換

Camel的交換是在路由過程當中發生在消息容器中。一種交換同時提供了系統之間不一樣類型的集成，例如衆所周知的MEPs（Message exchange patterns）。MEPs between事件消息（one-way） and request-response 以不一樣的消息風格被使用。Camel的exchange有一種屬性模式供選擇。

InOnly ---事件消息（ A one-way message）。例如，JMS消息常常就以時間消息來使用。

InOut---請求響應消息（request-response message）。例如，HTTP。一個客戶端請求一個須要返回的web頁面，等待server回覆。Canel交換都包括哪些內容以下插圖：

讓咱們來看一下Figure1.5每一個元素的細節。

• Exchage ID---用來交換的惟一標識。Camel會提供一個默認的惟一ID
• MEP-A-- 指定的樣式。你是否正在使用Inonly或者InOut消息結構樣式。當只是InOnly樣式時，The change只包含一種in消息。如果InOut模式，out消息也包含一個回覆消息給請求者。
• Exception（異常）---若是在路由的過程當中任什麼時候間發生異常，則這個異常被放到異常空間。
• 屬性---類似的消息頭，他們持續在整個交換過程當中。屬性包含有被使用global-leve信息。反之消息頭對哪些特有的消息來講是特別的。Camel在路由期間它本身將添加各類屬性。你做爲一個開發者能夠在交換的生命週期內的任何point保留或者恢復這些屬性。
• In 消息—這是一種被強制的輸入消息。這In 消息包含請求消息。
• Out 消息---這是一種宣泄消息。它僅存在MEP中。這Out消息包含恢復消息。

咱們想在講camel體系結構前討論一下camel的消息模型。咱們想你對camel的消息已經有了必定的理解。畢竟camel大部分重要的方面都是路由消息。你如今已經具有了更多的去學習關於camel和他的體系結構。

1.4 camel體系結構
咱們如今把注意力轉到camel的體系架構上來。咱們將首先看一下高水平的體系架構，接着深刻的研究一下這些內容。你讀過本章段後，你應該懂得了集成的術語，在第二章爲你準備了。咱們將深刻研究camel的路由能力。

1.4．1 camel體系機構

咱們製做了高水平的camle體系架構視圖，以下插圖：

路由引擎有消息路由的詳細說明。路由做爲DSLs語言被定義使用。在路由期間消息會被處理成各類類型的消息。在消息在路由期間實現了因此的EIP。在camel中這些組件時做爲鏈接其餘系統的拓展點。

1.4.2 camel的概念

Camel有不少新的概念，所以讓咱們花一些時間一個一個理解它。咱們從CamelContext開始，它是camel的運行環境。很重要喲。

CamelContext

你可能已經猜到CamelContext是一個有類別容器，從figure1.6的插圖你可能認爲它是camel的運行環境系統。Figure1.7展現了大部分值得注意的服務。這些服務都是camel保留下來的。以下插圖：

The details of each of these services will be discussed throughout the book. Let's

now take a look at routes and Camel's routing engine.

    這些服務將會貫穿本書。如今咱們先看一下ROUTES和ROUTING ENGINE 。

上圖部分翻譯：

Components：包含用到的組件。Camel 可以經過自動載入類路徑或者自動激活OSGI容器等方式來運行。第七章中討論。

Endpoints：包含已建立的endpoints。

Routes：包含被添加的路由。會在第二章中講解。

Type converters：包括已經載入的類轉換。Camel擁有能夠手動或自動轉換類的機制。第三章中詳細描述。

Registry：包含能夠查閱beans的註冊表。默認狀況下，它是JNDI registry。若是基於Spring，它是Spring ApplicationContext ，若是使用OSGI容器，它是OSGI registry。第四章講。

Languages：包含載入的語言。Camel容許使用不一樣的語言建立表達式。你會看到在講解DSL的時候使用的Xpath 語言。徹底參考camel本身的簡約的表達式語言能夠參考 附錄A。

   

路由引擎

Camel的路由引擎其實就是作消息移動。    引擎不會暴露給開發者。可是你應該意識到它的存在，它作了因此的重活，確保消息可以根據屬性準確路由。

路由

路由是camel的一個核心抽象概念。最簡單的方式是定義一個路由做爲處理鏈。在消息 應用中使用路由有不少種緣由。解耦的客戶端和服務器端，生產者和消費者，路由能夠

• 動態的決定一個客戶端將會被那個服務調用。
• 提供了一種處理額外流程的靈活方式
• 運行服務器端和客戶端獨立開發。
• 加強一些系統的功能。

     

   

Camel中的每個路由都有一個惟一的標識。這些標識爲logging，debuging，監控，路由的啓動中止服務的。路由也有一個精確的輸入消息資。

Each route in Camel has a unique identifier that's used for logging, debugging, monitoring, and starting and stopping routes. Routes also have exactly one input source for

messages, so they're effectively tied to an input endpoint.

Camel中每個路由都有一個惟一的標識，用於日誌、調試、監控、和啓動中止路由。路由有完整的輸入資源，因此他能夠有效的和input endpoint 聯繫。

下面定義一個使用DSL語言的路由。

DSL：

定義一個路由。

DSL（Domain-Specific Language）

在camel中，DSL也就是常用的java API（給EIP提供的方法名稱）。考慮一下下面的例子：

from("file:data/inbox").filter().xpath("/order[not(@test)]).to("jms:queue:order")

在這一句java語句中，你定義了路由。From 一個文件，這個文件路由到EIP，這個消息是不是測試的目的 或者不是。若是一個消息經過了測試，它將會被轉發到JMS結束點。失敗消息過濾器將會放棄執行。

Canmel提供了多種DSL語言，你能夠用spring定義一樣的路由。Like this：

   

建立應用的時候DSL爲Camel用戶提供了一個抽象的概念。路由真正構成了處理過程。讓咱們來看一下處理過程是什麼。

PROCESSOR

處理過程是camel的一個核心概念。表明了一個有處理能力節點的使用，建立，或者修改交換輸入。在路由期間交換會從一個處理流到下一個處理；例如你能夠想象一個畫面，每一個節點都有指定的處理方式。一個處理的輸出到一個處理的輸入連成一個隊。怎麼作交換的輸入輸出處理畫面呢？咱們須要看一下components和endpoints

Component

在camel中組件是主要的繼承點。時至今日，已經有超過80個組件體系，應用範圍有數據轉換函數，DSL，數據格式，等等。你甚至能夠建立本身的組件。在第11章討論。

從程序的視角來看，組件是十分簡單扼。他們的名字會用在URL中產生關聯關係，他們扮演着終點工廠。例如一個 FileComponent 會關聯URI中的一個文件，而後建立一個FileEndpoints。EndPoint多是一個很是基本的事件概念。

EndPoint

Endpoint是camel的抽象概念。信道末端模型。系統能夠利用信道收發消息。以下圖：

在camel中，你須要在URL中配置endpoint。例如file:data/inbox?delay=5000,你也用這種法師涉及到了endpoints。在運行的時候，camel將會用URL標記的方式查找endpoint。

以下圖：展現了它是怎麼工做的

Scheme 標識endpoint的類型。在這個例子中，文件模式（scheme of file）選擇文件組件（FileComponent）。這個FileComponent做爲建立FileEndpoint 的工廠。這個Context path 是data/inbox 告送FileComponent文件夾的路徑。這個Option 屬性 delay=5000表示此文件應該被推遲5秒鐘。

Figure 1.10 展現了endpoint和producer、exchange、consumer之間如何工做的。

先看一眼figure1.10可能有點暈，在幾分鐘後你就會領會的。Endpoint做爲建立consumer和producer的工廠。

Producer

Producer是camel的一個抽象概念。它是用來建立消息給endpoint

+++++++++++++++++++++++++++++++++++++++++++

Producer：

A producer is the Camel abstraction that refers to an entity capable of creating and

sending a message to an endpoint. Figure 1.10 illustrates where the producer fits in with other Camel concepts.

When a message needs to be sent to an endpoint, the producer will create an exchange and populate it with data compatible with that particular endpoint. For example, a FileProducer will write the message body to a file. A JmsProducer, on the other hand, will map the Camel message to a javax.jms.Messagebefore sending it to a JMS destination. This is an important feature in Camel, because it hides the complexity of interacting with particular transports. All you need to do is route a message to an endpoint, and the producer does the heavy lifting.

生產者：

Producer是一個camel的抽象類，實體可以建立併發送消息到endpoint。圖1.10一方面也說明了這個概念。當一個消息須要被髮送到一個endpoint時，生產者將建立一個exchange並填充兼容個別項目的endpoint數據。例如：FileProducer會將消息body寫入到一個文件。還有JmsProducer會把Camel消息映射到正在發送消息到JMS目標上的javax.jms.Messagebefore中。在camel中，這是很重要的功能，由於它隱藏了與特有的transports的相互做用的複雜性。你要作的是將一個消息路由到endpoint，而後producer會作重活。

CONSUMER：

A consumer is the service that receives messages produced by a producer, wraps them

in an exchange, and sends them to be processed. Consumers are the source of the

exchanges being routed in Camel.

Looking back at figure 1.10, we can see where the consumer fits in with other

Camel concepts. To create a new exchange, a consumer will use the endpoint that wraps the payload being consumed. A processor is then used to initiate the routing of the exchange in Camel using the routing engine.

In Camel there are two kinds of consumers: event-driven consumers and polling consumers. The differences between these consumers are important, because they

help solve different problems.

消費者：

消費者是接收生產者生產的消息的服務。把他們封裝到exchange中而且發送他們去處理。消費者是camel中被路由的exchanges的源頭。

    回頭看圖1.10，咱們看到消費者與其餘camel概念的交互。建立一個新exchange，消費者將使用endpoint封裝被消費的有效載荷。Processor而後使用路由引擎發起exchange的路由。在camel中有兩種消費者：事件驅動的消費者 和 輪詢的消費者。它們的區別很重要，由於它們有助於解決問題。

事件驅動的消費者（EVENT-DRIVEN CONSUMER）：

大可能是事件驅動的消費者，如圖1.11

    這種消費者和客戶-服務結構webservice。同時在EIP中也表示爲異步的接收者。消費者監聽指定的消息通道，一般使用TCP/IP端口或JMS隊列，等待客戶端發送消息給它。當消息到達的時候，消費者喚醒而且將消息進行處理。

輪詢的消費者（POLLING CONSUMER）

    另外一種是輪詢消費者如圖1.12 。

    相比事件驅動消費者，輪詢消費者主動從指定源獲取消息，例如FTP服務。輪詢消費者在EIP術語中也是 同步的接受者，由於它不會獲取更多消息，直到他完成當前消息的處理。一般輪詢消費者是定時輪詢消費者，經過指定間隔。File，FTP和Email傳輸一般用定時輪詢消費者。

    

1.5 在回頭看第一個camel示例

    回頭看1.2.2的camel示例，你應該能夠更加透徹的理解了。

    再來看一個例子。

    

    示例中，在camel運行時會首先建立一個camelContext，經過RouteBuilder和java DSL來添加路由邏輯。經過DSL，能夠一目瞭然的讓camel組件，endpoints，消費者，生產者等實例化。你要關注的是定義路由爲你的集成項目。底層中，camel是訪問FileComponent而且用它做爲一個工廠建立endpoint和它的生產者。同時也建立消費者。

1.6    總結

    略