Mule3用户手册：Mule ESB 3使用要点
Mule是一個靈活的消息處理和集成框架。你使用Mule的方式取決于你要嘗試解決的問題。Mule3提供了多種配置構建方法，這些方法可以根據需要被混合和裝配，來實現你的方案。
l? 理解Mule配置
l? 在流、模式或服務之間進行選擇
l? 消息源和消息處理器
l? 配置組件
l? 使用傳輸器做連接
l? 配置端點
l? 使用過濾器
l? 使用轉換器
l? 使用Mule云連接來連接SaaS，社交媒體和電子商務
l? Mule查詢語言
l? 使用表達式
l? 消息屬性域
l? 事務管理
l? 配置安全
l? 錯誤處理
l? 使用Web Services
理解Mule配置
理解Mule配置
[XML配置相關] [Schema參考] [默認值] [枚舉值] [強類型語言的優點][Spring配置相關] [Spring Beans] [Spring屬性] [屬性占位符] [Mule配置相關] [全局元素] [流] [配置模式] [服務] [自定義元素] [系統級配置] [管理器] [代理]
XML配置相關
Mule使用XML配置來定義每個應用，它完整的描述了運行應用需要的組成部分。一個基本的Mule應用可以使用非常簡單的配置，例如：
下面我們將仔細查看這一配置的所有片段的細節。目前，盡管它很簡單，卻是一個完整的應用，并且非常易讀：甚至對Mule只有短時間了解的人也能夠解釋清楚，它是在從標準輸入向標準輸出拷貝消息。
?
Schema參考
Mule配置的語法是由一組XMLschema文件定義的。每一個配置列出了它用到的schema，并給出了它們的URL地址。它們中的大部分是你正在使用的Mule版本所對應的Mule schema，但是另外也可能有一些第三方的schema，例如：
l? Spring schema，定義了用到的所有Spring標簽元素（比如Spring beans）的語法
l? CXF schema，用于Mule CXF模塊所處理的Web Services的配置
一個配置文件中引用到的每個schema都由兩部分數據定義：
l? 名字空間，這是一個URI
l? 位置，這是一個URL
?
配置文件既定義了schema的名字空間URI作為XML名字空間，同時又關聯了schema的名字空間和位置。像我們從上面的配置文件中看到的一樣，這是由頂級元素mule標簽來完成的：
這里將mule core的schema名字空間被定義為配置文件的默認名字空間。它是這里默認名字空間的最佳選擇，因為有這么多配置的元素是屬于核心名字空間的。
Mule stdio傳輸器允許使用標準I/O進行通信的，它的名字空間使用“stdio”作為前綴。Mule模塊或者傳輸器里的約定是使用它們的名字作為名字空間的前綴。
Xsi:schema屬性關聯名字空間到它們的位置，這里它提供了stdio schema和mule core schema的位置。
????????
Mule配置中包含這些部分是必須的，因為它們保證了schema能夠被查找到，這樣配置文件才能使用它們進行檢驗。
默認值
除定義了元素和屬性的語法外，schema還可以給它們定義默認值。眾所周知，這是對于讓你的配置可讀是極其有用的，因為它們不會因為不必要的信息變得雜亂。默認值可以通過schema本身來查找，或者在Mule的模塊和傳輸器的該當中也定義了這些值。例如，用于重復地向端口輪詢的<poll>元素，它的定義包含了以下的屬性定義：
只有當要覆蓋默認的1s的值時，才需要指定這一屬性。
枚舉值
許多Mule的屬性只可以接受一個限定的集合內的值。它們在schema中被定義為枚舉值，來保證只有這些值才能被指定。這里是一個stdio傳輸器的例子：
這強制指定了只接受有IN、OUT和ERR，它們分別代表標準輸入、輸出和錯誤。
強類型語言的優點
要引用到所有schema的需求好像非常的笨重，但是它有兩個遠超出所付出的精力的優勢。
第一，它幫助你一次就能創建出有效的配置。主流的集成開發環境都提供了schema感知的XML編輯器。因此，當你創建和編輯你的配置時，IDE會提示你在每個點上可以接受的元素和屬性，在你只輸入了幾個字符后實例它們的名字，以及高亮指示出需要修改的輸入錯誤。同樣的，它提供了對枚舉值的填充的相同的幫助功能。
第二，它允許Mule在應用啟動時驗證你的配置。不像一些其他的基于配置的系統那樣，只是無聲的忽略它們不認識的元素和屬性，Mule會捕獲這些錯誤，這樣你就可以修正它們。例如，假設在上面的配置文件中，我們拼寫錯誤了“outbound-endpoint”，一旦應用嘗試啟動，結果立即就會出現錯誤：
它直接指出了需要修正的那一行。這遠比只是簡單的忽略問題，讓你困擾為什么沒有任何輸出要有用得多。
?
Spring配置相關
Mule解析配置的方便是嵌入于Spring中的，因此除了定義Mule相關的構造方法，Mule配置中可以做到Spring配置能做的所有事情：創建SprignBean，配置list和map，定義屬性占位符等等。我們將在下面的章節中進行詳細的研究。注意，一如往常，引用合適的schema是必不可少的。
Spring Beans
Mule配置中對Spring最簡單的使用就是配置Springbean。這些bean會和Mule相關的對象一起被放到Mule注冊中心里，你可以通過名字查找到任意自定義的Java對象，例如，自定義組件，你可以使用所有Spring的功能來創建它們，例如：
Spring配置
在Mule配置中，有很多地方都可以使用自定義的Java對象：自定義的轉換器、過濾器、消息處理器等等。所有情況下，都可能要指定一個要實例化的類，和一組Spring屬性用于配置這個實例。再說一次，你可以在屬性中使用Spring語法的全集，包括list、map等等。
這里是一個例子：
為了在創建Java對象上允許更多的控制，創建自定義組件的語法稍有不同。例如，創建一個單例：
屬性占位符
Mule配置可以包含對屬性占位符的引用，來保證能夠引用到配置文件之外的值。這特性的一個重要的使用場景就是用戶名和密碼，它們應該使用一種更安全的方式來指定。屬性占位符的語法就是簡單的：${name}，這里的name就是一個Java屬性文件里的一個屬性。
這里是一個使用了屬性占位符，以及它引用到的屬性的例子：
配置文件：
屬性文件：
注意這里給出的文件路徑是基于classpath路徑，另一種選擇是使用URL，例如file:///etc/mule/conf/my-mule-app-override.properties。如上所示，也可以指定一組屬性文件，它們中間使用逗號分隔。
Mule配置相關
全局配置
許多Mule元素可以在頂級進行指定，也就是說，作為最外層的mule元素的直接子元素。這些全局元素都有名稱，這樣才能被使用的地方被引用。注意對全局元素，Mule配置中使用了單一的，扁平的名字空間。任意兩個全局元素不能共享同樣的名稱，即使它們是全然不同類型的東西，比如端點和過濾器。
我們來看一下最常見的全局元素：
連接器
連接器是Mule傳輸器的具體實例，它的屬性描述了傳輸器是怎樣使用的。所有Mule端點使用的連接器都一個繼承了連接器屬性的相同的傳輸器。
???????? 這里是連接器的例子：
Vm連接器指定了它所有的端點都使用持久隊列。文件連接器指定了它的每個端點一秒輪詢一次，同時還指定了一旦執行處理，這些文件會被移動到的目錄。
注意屬性可能被屬性指定，也可能被子元素指定。你可以通過查看連接器對應的傳輸器的參考文檔來確定怎么來配置連接器的屬性。
端點和它的連接器的關系其實是相當靈活的：
l? 如果端點使用名字指定了連接器，它就會使用這個連接器。當然，如果端點和連接器使用了不同傳輸器，就會出錯。
l? 如果端點上沒有指定連接器，而它的傳輸器有一個連接器，那端點就使用這個連接器。
l? 如果端點上沒有指定連接器，并且它的傳輸器也沒有連接器，Mule會為這個傳輸器的所有端點創建一個默認的連接器供它們使用。
l? 如果端點上沒有指定連接器，同時它的傳輸器上有多于一個的連接器，就會出錯。
?
關于連接器和端點的傳輸器相關的信息，可以參考MULE3USER:Available Transports.
端點
Mule端點是一個消息讀出（入站）和寫入（出站）的對象，它上面指定了一些屬性，定義了這個過程是怎么完成的。端點可以使用兩種方式指定：
l? 作為全局元素配置的端點稱為全局端點。流或者服務中配置的入站或者出站端點，可以使用ref屬性引用一個全局端點。
l? 流或者服務中配置的入站或者出站端點，可以不引用全局端點，直接進行配置。
全局端點指定了一組屬性，包括它的位置。引用了這個全局端點的入站和出站端點都會繼承它的屬性。這里是幾個全局端點的例子：
Vm端點指定了它的位置，并引用了上面的連接器。它使用了一個通用的address屬性指定它的位置。Http端點使用了默認的http連接器。因為它被明確的配置為http端點，因此它可以使用http相關的屬性host、port和path來指定它的位置。File端點指定了它讀出（或寫入）的目錄，它會使用默認的文件連接器。因為它被配置為通用的端點，因此它必須使用address來指定位置。
注意每個端點都會使用一種特定的傳輸器，但它可以通過兩種不同的方式指定：
l? 如果元素有前綴，它可以使用前綴對應的傳輸器，
l? 如果沒有前綴，前綴就會通過address屬性來確定。
?
前綴風格的更值得推薦，尤其是位置配置會比較復雜時，比較一下
和
端點上面一個最重要的屬性是它的消息交換方式（簡稱MEP），也就是說，消息是不是單向的或者請求返回響應的。這個可以在多個層次上指定：
l? 一些傳輸器只支持一種MEP。例如，imap是單向的，因為當它讀了一封email時，沒有任何響應會被發送出去。另一種，servlet，總是請求-響應類型的。
l? 每種傳輸器有一種默認的MEP。JMS默認是單向的，因為JMS消息通常不會和響應關聯起來。http默認是請求-響應的，因為HTTP協議天生的對每個請求都有一個響應。
l? 端點上可以定義MEP，盡管，只有MRP對它們的傳輸器合法，才能被接受。
轉換器
轉換器是一個傳輸當前Mule消息的對象。Mule核心定義了轉換器的基本集合，許多模塊和傳輸器中定義了更多的轉換器，例如JSON模塊定義了的能夠在對象和JSON間相互轉換的轉換器，而Email傳輸器定義了在二進行數組和MIME消息間轉換的轉換器。每種類型的轉換器都通過定義XML配置定義了它們的屬性。這里是一個轉換器的例子：
上面的轉換器轉換消息到JSON，指定了特定的處理過程來處理對org.mule.tck.testmodels. fruit.Orange類的轉換。下面的轉換器負責添加一個invocation-scoped屬性到當前的消息上。
像端點一樣，轉換器可以被配置成全局元素，被使用到的地方引用，或者也可以在使用點上進行直接配置。
更多Mule轉換器的內容，參考UsingTransformers。
過濾器
過濾器是確定消息是不是應該被處理的對象。和轉換器一樣，Mule核心定義了過濾器的基本集合，許多模塊和傳輸器定義了更豐富的過濾器。這里是過濾器的一些例子：
上面的過濾器保證了只有當前消息匹配指定的模式時，才能被繼續處理。下面的的過濾器只有當消息是XML文檔時，才會繼續處理。
?
還有幾個搞定了其他的過濾器功能的特別的過濾器，第一個是message-filter：
如上所示，只有匹配指定的模式時，當前消息才會被繼續處理。但是現在所有沒有匹配的消息，不是被丟棄，而是被發送到dead letter隊列來繼續處理。在這里，只有當消息是XML文檔，才會被處理，否則拋出異常。
其他特殊的過濾器是and-filter、or-filter和not-filter，它們可以讓你將過濾器組合成邏輯表達式：
當消息是優先級1，或者消息是優先級2，并且來自加拿大以外的國家時，才會被處理。
?
過濾器可以被配置成全局元素，被使用到的地方引用，或者也可以在使用點上進行直接配置。更多Mule過濾器的內容，參考Using Filters。
表達式
Mule有強大的表達式功能，允許基于系統不同部分的信息來影響消息的處理。因為Mule的許多不同部分可以判定表達式，指定一個表達式需要兩個部分：
l? 計算器，用來計算表達式。Mule提供了很多的計算器，同時你也可以添加你自己的。
l? 表達式，用于被計算。表達式的語法是和計算器相關的。
根據表達式使用的位置不同，有兩種方式指定表達式。常用的，基于表達式的元素，例如表達式轉換器、表達式過濾器，基于表達式的路由器，例如表達式消息切分器，它們都有特定的表達式屬性，計算器和自定義計算器。例如：
當使用string值替代表達式時，你要使用語法#[evaluator.expression]，例如：
?
這一表達式調用：首先xpath表達式被使用了兩次從當前消息中抽取數據，然后調用string計算器，通過這些數據和連字符來構建出一個string。
表達式和屬性占位符可能看起來很像，但是它們是完全不同的。屬性占位符會在配置期會替換，用來構建靜態的信息。表達式在運行時被替換，因此所有使用到它們的都是動態的。看一下下面的例子：
第一個是好的——它在配置期確定端點的位置。（當然，vm.path屬性必須要設置）。
第二個是不合法的。入站端點的地址在配置期必須要設置，在配置被構建前，表達式是沒有辦法計算的。
第三個和第一個是很像的。
第四個是一個新的配置——動態端點。端點要發消息到的地點是在消息的處理過程中才確定的，可能每次都會不同。當然，沒有配置vm.path屬性的消息會導致出錯。更多Mule表達式的內容，參考Using Expressions。
名字和引用
正如我們看到的，許多Mule對象可以被全局定義。這樣的好處是通過在都要好好的 地方引用它們，可以做到在整個應用中復用。對于這種使用，有一個通用的模式：
l? 全局對象使用name屬性來標識它的名字
l? 它可能使用ref屬性被引用
對每種類型的對象，都有一種泛型的元素用來引用它。
l? 所有全局轉換器都用transformer元素引用
l? 所有全局的消息處理器都用processor元素進行引用
l? 所有全局端點都用inbound-endpoint和outbound-endpoint進行引用
l? 所有全局過濾器都用filter元素進行引用
例如：
另外，也有一些情況下，全局對象的名字是作為屬性值來使用的，例如：
流
流是Mule處理的基本單元。一個流從一個入站端點開始，從其中讀取消息后，繼續經常一系列的消息處理器，然后可選的終止于出站端點，從這里整個被處理后的消息被發送出去。我們已經見過一些消息處理器了：轉換器和過濾器。其他類型的包括使用像Java或Groovy語言處理消息的組件，調用云服務的云連接器，和按需要選擇消息流的路由器。下面是簡單的流，我們將參考它來了解所有部分。
正如其名，這一個流是用來接收和處理訂單的。當我們瀏覽時，記一下流的配置是怎么映射到它描述的邏輯上的：
消息從HTTP端口中被讀取出來。
消息被轉換成String。
將String用作Key來從數據庫中查找訂單列表。
訂單被轉換為XML格式。
如果訂單沒有準備好要被處理，跳過它。
列表可以選擇被記錄日志，以用于調試。
列表中的每一個訂單被切分成單獨的消息。
消息放大器在消息上添加一些信息
調用Authorize.net來授權訂單。
訂單上的郵箱地址保存備用。
調用Java組件處理訂單。
調用另一個叫做processOrder的流處理訂單。
processOrder的確認郵件發送訂單的地址。
?
如果處理訂單中導致了異常，異常處理策略就會被調用：
所有鏈上的消息處理器都被調用處理異常。
首先，消息被轉換成字符器
最后，字符串被放入到錯誤隊列中，等待人工處理。
?
這一個流中的任一步都在下面會被詳細描述，通過構造進行組織。
?
端點
之前，我們研究了全局端點的聲明。現在我們看一下流里面的端點，它們是用于接收（入站）和發送（出站）消息的。入站端點只在流的開始出現，在這個位置它們供給了要被處理的消息。出站端點在后面的任意位置都可以出現。穿過流的消息的路徑取決于它的端點的MEP：
l? 如果入站端點是請求-響應方式，流就會在它中止時，返回當前消息給它的調用者。
l? 如果入站端點是單向的，流就會在它中止時，直接退出。
l? 當流到達了一個請求-響應類型的出站端點時，它會將當前消息發送給這一端點，然后等待響應，并將響應作為當前消息。
l? 當流到達一個單向的出站端點時，它會將當前消息發送給這一端點，然后繼續處理當前消息。
這里的例子中通過HTTP連接接收消息。消息負載被設置到接收到的字符數組中，HTTP頭變成了入站消息屬性。因為這個端點是請求-響應（HTTP默認）式的，在流的最后，當前消息會被返回給調用者。
接下來用消息作為參數調用了一個JDBC查詢，使用查詢結果替換掉當前消息。因為這一端點是請求-響應式的，查詢結果會變成當前消息。
從分支流中返回的訂單完成確認被郵寄出去。注意我們使用了之前被保存到了消息屬性中的郵件地址。因為這一端點是單向的（郵件傳輸器的惟一MEP），當前消息不會被修改。
所有沒有被正確處理的訂單都會被放入JMS隊列中等待人工檢查。因為這一端點是單向的（JMS默認），當前消息不會被修改。
結果，在成功的情況下，最后發送回調用者的消息將會是確認消息。否則失敗時，相同的字符串會被發送到JMS錯誤隊列。
轉換器
如前面所述，轉換器會修改當前消息。這里有幾個例子。注意它們是在被使用的位置定義的。然后同樣可以全局定義，然后在使用的位置進行引用。
上例中，字節數組被轉換為字符串，來保證可以作為key進行數據庫查詢。
從數據庫中讀取的訂單會轉換成XML文檔。
郵件地址被存到消息屬性中。注意，不同于大部分轉換器，消息屬性轉換器不會影響到消息負載，只是修改了它的屬性。
導致了異常的消息被轉換成字符串。注意由于使用相同的策略處理所有異常，所以我們不知道消息在這個位置會是哪種對象。它可能是字節數組，字符串，或者XML文檔。轉換所有這些消息成字符串，保證接收者知道需要什么。
消息放大器
消息放大器使用enricher元素進行配置。不同于能夠修改消息負載的消息轉換器，放大器向消息添加額外的屬性。這允許流逐步積聚起一批用于后續處理的信息。更多放大器的信息參見Message Enricher。
例子中，放大器調用云連接器來獲得了信息，并存到消息屬性內。因為云連接器在放大器內被調用，因此，它的返回被放大器處理，而不是變成消息。
日志記錄器
Logger元素允許從流中輸出調用信息。更多logger的信息參見Logger Element for Flows。
???????? 例子中，每個從數據庫中取出的訂被輸出出來，但僅在DEBUG模式啟用時。這意味著這個流通常是不輸出信息的，但在需要時可以很容易地啟用調用。
過濾器
???????? 過濾器確定了消息是否被處理。
???????? 例子中，如果取出的文檔的狀態不是“ready”，處理就會跳過。
路由器
???????? 路由器修改了消息的流。在其他可能的情況下，它可能在多處消息處理器中選擇，切分一條消息成多條，合并多條消息到一條。更多路由器的信息參考Routing Message Processors。
???????? 例子中，將從數據庫中讀取的文檔在order元素處分切成多個訂單。結果是零或多個訂單，其中每個都會經常流的其余部分處理。也就是說，對接收到的每個HTTP消息，經過splitter的處理的單向的。而余下的部分可能被處理零次，一次或者多次，這取決于文檔中包含了多少訂單。
組件
組件是使用Java、Groovy或者其他語言編寫的消息處理器。Mule通過查找與消息類型最佳的匹配，來決定調用組件的哪個方法。例如，如果消息是一個InputStream，它會尋找接收一個InputStream類型（或者Stream，或者Object）的公開方法。為了訂制這種搜索，Mule使用一種叫做入口解決器的對象，它們是配置在組件上的。這里是一些例子：
這個例子讓preProcessXMLOrder和preProcessTextOrder變成了候選者。Mule使用消息的類型，執行反射進行選擇。
調用消息屬性中名字為methodToCall的方法。
即使它沒有參數，也會調用generate方法。
?
入口解決器是高級使用方式。幾乎任何情況下，Mule都可以在沒有任何特別引導下找到正確的方法來調用。
這是一個Java組件，它通過類名進行指定，在處理當前消息時進行調用。在這個例子中，它會預處理消息。更多入口解決器的信息，參考Entry Point Resolver Configuration Reference。
云連接器
一個云連接器會調用一個云服務。
上例中，它調用authorize.net來授權信用卡購買，這是通過從消息中發送給它信息實現的。更多云連接器的信息，參考Integrating with Cloud Connect。
處理器鏈
處理器鏈是一組消息處理器，它們將會按順序被執行。它允許你在一個配置中使用多于一個的處理器，不然就只允許一個。就像是把多條Java語句放到大括號里面。
例子中，它用于執行異常策略的兩步。首先轉換消息，然后郵件發送。
分支流
分支流是一種能夠被另一個流調用的流。它表示了一個可重用的處理步驟。調用它非常像調用Java方法，將當前消息傳入分支流，當它返回時，調用的流恢復處理這個由分支流返回的消息。
例子中，調用它用來處理已經被處理過的訂單，產生一條確認消息。
異常策略
當異常產生在異常策略的作用域內時，會被調用，就非常像Java的異常處理器。它可以定義對任何待定的事務做什么處理，以及異常對流是不是致命，而且還包括處理異常的邏輯。
例子中，它將導致異常的消息寫入JMS隊列，隊列會被檢查。更多關于異常策略的信息，參考MULE3USER:Exception Handling。
配置模式
流有強大和靈活的優勢。Mule可以做的任何事情都可以被放入流。Mule還可以使用配置模式，它們就是設計用于簡化Mule的常用配置的。熟悉這些模式，并在可能的情況下使用它們，是非常有價值的。這和你應該使用一個類庫，而不是從頭寫相同的功能是一樣的道理。現在Mule支持四種配置模式：
l? Pattern:bridge 建立了入站端點和出站端點之間的橋梁。
l? Pattern:simple-service 是從一個入站端點到組件之間的簡單流。
l? Pattern:validator 它像單身的bridge，不過它會在發送消息到出站端點前進行驗證消息。
l? Pattern:web-service-proxy 是一個Web Service代理。
從Mule 3.1.1開始，如上所示它們都在pattern名字空間里。在Mule 3早一些的版本中，它們是在core名字空間中的，除了web-service-proxy，那時是ws:proxy。這些老的名字在Mule3.1.x的版本中將繼續可用，不過之后會刪除掉。
通用特性
為了靈活性，所有這些模式都允許端口通過多種方式進行指定：
l? 本地端點可以作為子元素聲明，就像在流里面一樣。
l? 對全局端點的引用可以作為子元素聲明，就像在流里面一樣。
l? 對全局端點的引用可以作為屬性inboundEndpoint-ref和outboundEndpoint-ref的值聲明。
l? 端點的地址可以使用屬性inboundAddress和outboundAddress的值指定。
所有配置模式都可以指定異常策略，就像流上一樣。
橋
該模式允許你除入站和出站端點之外，還可以配置，
l? 一組應用于請求上的轉換器
l? 一組應用于響應上的轉換器
l? 是不是在一個事務里處理消息
這里是一些例子：
???????? 上例中，Mule使用事務從JMS隊列拷貝消息到JMS主題。從一個vm入站端點讀取字節數組，將它們轉換為字符串，然后寫到vm出站端點中。響應是字符串的，它們會被轉換成字節數組，然后被寫到出站端點中。
簡單服務
該模式允許你除入站端點外，還可以配置：
l? 一組應用于請求上的轉換器
l? 一組應用于響應上的轉換器
l? 一個組件
l? 一個組件類型，讓你可以使用Jersey和CXF組件
這里是一些例子：
這里是一個顯示請求的簡單服務。它使用了一個CXF組件。注意創建這個組件只需要如此少的配置。
校驗器
該模式允許你除入站和出站端點外，還可以配置：
l? 一組應用于請求上的轉換器
l? 一組應用于響應上的轉換器
l? 一個執行校驗的過濾器
l? 創建響應的表達式，用于表明驗證成功或失敗
這里是一個例子：
上例中在調用其他服務前，驗證消息負載是不是正確的類型。
Web Service代理
該模式會創建一個Web Service代理。它通過修改已經發布的WSDL，來包含代理的URL。
可以讓你除入站和出站端點外，還可以配置：
l? 一組應用于請求上的轉換器
l? 一組應用于響應上的轉換器
l? 服務WSDL的位置，用URL或者文件名
這里是一個例子：
上例創建了位于server1上的天氣預報服務的代理。
更多配置模式相關的信息，參考UsingMule Configuration Patterns。
服務
服務是Mule很老的特性。它們既不像流一個靈活，也不能像配置模式一樣友好。盡管服務仍然是完全支持的，但我們推薦新的開發使用流和模式來完成。前面已經提到，服務使用了許多和流相同的理念，并且不難使用和構建。
一個服務分為三個部分：
l? 入站。這包含了一個入站端點，加上服務允許的單一組件的任意前置處理過程。它可以由入站路由器、轉換器、過濾器和其他消息處理器組成。
l? 組件。這個和流中出現的組件相同。它是可選的。
l? 出站。這是所有組件之后的處理過程。它由一組出站路由器組成。這里最簡單的是pass-through路由器，它只是簡單的把消息傳遞給出站端點。
服務，像流和模式一樣，可以定義異常策略。
?
服務是放置在一個叫做模型的構件內的。構件負責聚合服務，并讓它們共享一些配置：
l? 異常策略
l? 組件的入口解決器
把這里所有的組合起來，我們可以比較一下，使用流、配置模式和服務來創建一個拷貝標準輸出流的簡單應用。
橋模式是最簡單的，流也沒有太落后。服務方式不難讀懂，但是它明顯的又長又復雜。更多服務的信息，參考Service Configuration Reference。
自定義元素
Mule是可擴展的，這意味著你可以創建你自己的對象（通常是通過擴展Mule的類）。在你完成了這個以后，可以通過標準的方式將它們放置到配置文件中。假設，例如你創建了com.mycompany.HTMLCreater，它負責轉換很多種文檔到HTML。它是一個Springbean：
l? 有一個默認的構造器
l? 它通過設置bean屬性進行定制
現在你可以通過使用custom-transformer元素將它放到你的配置中：
注意標準的轉換器的Mule屬性是通過通常的方式指定的。惟一不同的是對象是通過類名和Spring屬性來創建的，而不是通過基于schema的元和屬性。每種類型的Mule對象都有一個用于自定義擴展的元素：
l? 用于連接器的custom-connector
l? 用于入口解決器的custom-entry-point-resolver
l? 用于異常策略的custom-exception-strategy
l? 用于過濾器的custom-filter
l? 用于消息處理器的custom-processor
l? 用于路由器的custom-router
l? 用于轉換器的custom-transformer
系統級配置
配置包含了多個全局配置，這會影響到整個的mule應用。所有都是mule頂級子元素configuration元素的子元素。它們都屬于兩個組內：線程監測和超時。
線程監測
線程監測確定了Mule怎樣管理線程池。在大部分場景下，默認設置會運行良好，但如果你確信，例如，你的端點正在接收非常大的流量，以至于它們需要額外的線程來處理，你就可以通過修改默認設置來調整它。這可以是選擇的端點，也可以是對所有端點。可以被調整的設置所對應的元素如下：
l? 所有線程池default-threading-profile
l? 對所有轉發消息的線程池default-dispatcher-threading-profile
l? 對所有接收消息的線程池default-receiver-threading-profile
l? 所有處理服務的線程池default-service-threading-profile
超時
同樣，默認超時時間通常工作良好，但是如果你想調整它們，你可以針對每個或者全局調整。可以被調整的超時所對應的屬性如下：
l? 對同步響應等待多長時間，以毫秒計，默認是10s，defaultResponseTimeout
l? 對事務完成等待多長時間，以毫秒計，默認是30s，defaultTransactionTimeout
l? 對Mule優雅地關閉要等待多長時間，以毫秒計，默認是5s，shutdownTimeout
管理器
Mule有多個全局對象，用于管理系統級設施。它們將在下面進行討論。
事務管理器
Mule使用JTA來管理 XA事務。因此，要使用XA 事務，必須要有一個JTA事務管理器，并在配置中指定。Mule對其中的許多有顯式的配置，同樣，也允許你使用自定義的管理器。用于配置事務管理器的元素是mule的直接子元素。
l? WebSphere事務管理器：websphere-transaction-manager
l? JBoss事務管理器：jboss-transaction-manager
l? WebLogic事務管理器：*weblogic-transaction-manager
l? JRun事務管理器：jrun-transaction-manager
l? Resin事務管理器：resin-transaction-manager
l? 在JNDI中查找事務管理器：*jndi-transaction-manager
l? 自定義查找事務管理器：*custom-transaction-manager
加*的事務管理器，在執行查找前允許你配置JNDI環境。更多關于事務管理器的信息，參考Transaction Management。
安全管理器
Mule安全管理器可以使用一個或多個加密策略進行配置，然后可以用于加密轉換器、安全過濾器或者像SSL或HTTPS這樣的安全傳輸器中。這些加密策略可以大大減化安全管理器的配置，因為它們可以在組件間共享。安全管理器使用全局security-manager元素進行設置，它是mule的直接子元素。
例如，這里是一個基于密碼的加密策略（PBE），它提供了使用JCE的密碼加密。用戶必須要指定密碼，并且還可以選擇一個salt和迭代次數。默認的算法是使用MD5和DES的PBE，但用戶可以指定任意被JCE支持的算法。
這個加密策略可以在系統中被其他組件引用，比如過濾器或轉換器。
更多Mule安全的信息，參考ConfiguringSecurity。
通知管理器
Mule可以在消息發送，接收或者處理時發送通知。你必須要注冊一些對象來接收它們，這樣通知才能真正被創建和發送。這是通過全局的notifications元素來未完成的，這是一個mule的直接子元素。它允許你指定一個對象來接收通知，也可能指定哪一個通知器來發送它。注意一個對象只能接收它實現了對應的接口的通知（這些接口定義在org.mule.api.context. notification.package）。這里是一個例子：
假設ComponentMessageNotificationLogger實現了ComponentMessageNotificationListener接口， EndpointMessageNotificationLogger實現了EndpointMessageNotificationListener。
Mule創建了監聽器bean，并且給兩個組件和端口通知都注冊了這兩個bean。但因為ComponentMessageNotificationLogger只實現了組件通知的接口，只有這種才是它能接收到的（相同，另一個EndpointMessageNotificationLogger也一樣）。
更多通知相關的信息，參考NotificationsConfiguration Reference。
代理
Mule允許你定義代理來擴展Mule的功能。Mule會管理代理的生命周期（初始化它們，在啟動時啟動它們，在關閉時停止和銷毀它們）。這些代理可以做任何事情，惟一要求是它們要實現org.mule.api.agent.Agent，這保證Mule能管理它們。更多Mule代理的信息，參考MuleAgents。
自定義代理
簡單的聲明全局的custom-agent元素，就可以創建自定義代理，它是mule的直接子元素。代理是Sprign bean，所以一樣它需要類名和一組Spring屬性來完成配置。另外，它需要一個名字，Mule用它在日志輸出中標識代理。這里是一個例子：
上例創建了一個代理，進行每30s一次的心跳。由于Mule會啟動和停止它，心跳會在Mule服務器運行過程中準確的進行。
管理代理
Mule在管理名字空間中實現了多種管理代理。
l? Management:jmx-server創建JMX服務器，允許對Mule的JMX bean進行本地和遠程訪問
l? Management:jmx-mx4j-adapter創建一個服務，允許對JMX bean使用HTTP訪問
l? Management:rmi-server 創建一個服務，允許對JMX bean使用RMI訪問
l? Management:jmx-notifications創建一個代理，發送Mule通知到JMX
l? Management:jmx-log4j允許JMX管理Mule對Log4J的使用
l? Management:jmx-default-config保證同時創建以上的部分
l? Management:log4j-notifications創建一個代理，發送Mule通知到Log4J
l? Management:chainsaw-notifications創建一個代理，發送Mule通知到Chainsaw
l? Management:publish-notifications創建一個代理，發布Mule通知到Mule出站端點
l? Management:yourkit-profiler創建一個代理，暴露YourKit監測信息到JMX
總結
以上是生活随笔為你收集整理的Mule3用户手册：Mule ESB 3使用要点的全部內容，希望文章能夠幫你解決所遇到的問題。
- 上一篇： 投行是什么
- 下一篇： 新华欣保险公司是一个什么样的公司