Mule是什么？（What is Mule?）
??? Mule 框架是高度可擴展的，允許你以很小的規模開始，隨著時間的推移，連接更多的應用系統。 Mule管理應用系統和組件之間的交互，不管它們是否在同一個VM(Visual Machine-虛擬機，即JVM-Java虛擬機)或在Internet上，不管底層使用的傳輸協議。


?? Mule相比同類框架而言，提供很多優勢，包含：Mule ESB是基于Java的輕量級消息框架，它允許你簡單 快速的連接應用系統，使得他們（應用系統）可以交換數據。Mule使用SOA(Service-Oriented Architecture-面向服務架構)，使得簡單集成已存應用系統成為可能。不管應用系統使用的是哪些不同的技術，包括：JMS Web Services JDBC HTTP 等，Mule可以無縫的在他們之間進行處理交互動作。??
??? Mule基于Enterprise Service Bus(ESB)架構思想。ESB的主要特性是通過扮演一個中轉系統的角色，允許不同的應用系統交互，中轉系統在內網或Internet上的應用系統間搬運數據。 目前市場上有一些商業的ESB實現。盡管如此，大部分提供有限的功能，或在已存應用服務器／消息服務器之上構建，將你鎖定在特定的供應商（將你固定的ESB廠商）。Mule是供應商中立的，因此不同廠商的實現可以插入進來。當你使用Mule時，永遠不會鎖定的特定的供應商。
??? Mule相比同類框架而言，提供很多優勢，包含：
? Mule 組件可以是任何你想要的類型。你可以簡單的集成任何東西, 從POJO到其他框架的組件。
? Mule 和 ESB 模型使得重大的組件重用。不象其他的框架，Mule允許你在不做任何變化的情況下使用已存組件。組件不強制要求有Mule特性的代碼，就可以在Mule中運行，沒有程序式的API強制要求。業務邏輯和消息邏輯完全分離。
? 消息（Messages）可以是任何格式，從SOAP到二進制圖片文件（binary image files）。Mule沒有強制任何架構上的設計約束，例如XML消息或 WSDL服務約束。
? 可以一些拓撲結構上部署Mule，不僅僅是ESB。因為它是輕量級 和 嵌入式的，Mule能降低上線時間，提高生產力，為工程提供安全 可伸縮的應用系統，它適應變化，在需要時提高或降低系統規模。
??? MuleSoft也提供管理工具，允許你管理你的部署(Mule HQ)，并控制你得基礎結構(Mule Galaxy)。

理解消息框架
??? 將你的應用系統聯網的優勢是一個應用系統可以向另一個應用系統發送數據。然而，很多應用系統沒有讀取和處理從其他系統發送過來的數據的能力。 Mule ESB通過提供一個消息框架讀取、轉換、并以消息的形式在應用間發送數據。消息僅僅就是一個數據包，它在應用間的一個特定的通道（渠道）上可以被處理和發送。


?? 在最簡單的情況， 當你的系統連接到Mule時， Mule從一個源系統讀取數據，需要時Mule轉換數據到目標系統可以讀取的格式上, 然后發送數據到目標系統。這允許你幾成所有類型的應用系統，甚至那些沒有內置集成的。

??? Mule是一個基于企業服務總線(Enterprise Service Bus(ESB))思想的消息框架。ESB的關鍵優勢是通過扮演一個在內網或公網應用系統間搬運數據的傳輸系統，使得不同的應用系統可以交互。Mule的核心是消息總線(Message Bus), 它在應用系統間路由消息。
Mule和傳統ESB的不同點之一在于Mule只在需要時才轉換數據。典型的ESB, 你必須為每個你連接到總線(Bus)上的應用系統創建一個適配器(Adapter), 適配器轉換應用的數據到一個公共的消息格式上。這些Adapter的開發和處理每個消息所需的時間，需要干的時間和努力。
??? Mule剔除了單個消息格式的需要。信息被發送到任何溝通通道(如：HTTP或JMS), 并只在通道上需要時才進行轉換。因此，Mule相比于傳統ESB, 提高性能并減少開發時間。
??? Mule架構和術語使用Gregor Hohpe和Bobby Woolf寫的< Enterprise Integration Patterns: Designing, Building, and Deploying Messaging Solutions >一書中的描述原理。這本書對于任何工作中涉及到企業消息解決方案的人，強烈建議閱讀<譯者注：隨后會進行本書的翻譯工作>。

理解Mule 架構
?? 這一部分描述Mule ESB架構的不同部分，以及它如何處理消息和消息的數據。 以下圖解，使用一個公司的例子，要為客戶訂單生成發貨單，在這些發貨單上有一些操作，然后為了完成訂單，發送它們到發貨部門。

這一部分包含如下主題:
? 關于 SOA
? 處理數據
? 服務組件間路由消息
? 從消息中分離業務邏輯
? 將全部融合到一起

關于 SOA

??? Mule ESB 是基于Service-Oriented Architecture(SOA)概念的。使用SOA方法開發，允許IT組織將應用功能組件或服務融合在一起來開發應用系統。服務是不連續的功能集合，彼此完全分離，并能在同一對象上協同工作。例如：如果你需要處理發貨單，你可能有一個服務，它將數據庫的客戶數據合并到發貨單中，另外一個服務檢查存貨數據庫，看看發貨單中的項目是否有存貨。
??? 因為每個服務是獨立的，服務可以被用來構建多個處理的處理塊，而不需要重新創建每種類型的處理或消息。例如：合并客戶數據到發貨單的服務也能用來合并客戶數據到報表、信件或其他的文檔。 這個模塊化的方法允許你一次創建功能，重用多次，流水線式的開發。
使用SOA, 企業可以實現開發成本大大節省，在開發新的應用系統時，可以通過重用和重新配置現有服務，快速的適應業務條件的變化。
??? SOA還可以更好的整合企業IT資源，包括先前孤立的應用系統和遺留系統。 Mule全面支持SOA方式，并使服務間協調的協作, 讓你很容易就將應用系統捆綁在一起。

處理數據

??? 當消息從應用系統被發送時，Mule ESB獲取到消息，發送到使用特定業務邏輯處理它的服務中, 接著將它路由到正確的應用系統。 Mule包含很多獨立的部分，它們處理數據并路由消息。 服務的關鍵部分是服務組件(service component)。Service Component 在消息上執行業務邏輯，例如讀取發貨單對象，從客戶數據庫中添加信息到發貨單對象，然后將它轉交給訂單完成應用系統。



??? Service Component 的重要特性是它不需要有任何Mule特性(如：Mule的某一個接口)的代碼; 它可以簡單到是一個POJO, Spring Bean, Java Bean 或以特定方式處理數據的業務邏輯。Mule管理Service Component，將它和配置設置捆綁并暴露為服務，并確保傳入正確的信息，從Service Component傳出的消息基于你在Mule配置文件中的特定配置。

??? 你可以有很多執行不同業務邏輯的不同Service Component, 例如：一個驗證發貨單中的項目是否有庫存，另一個更新不同的客戶數據庫中的訂單歷史。 發貨單， 被封裝在消息中，可以從一個Service Component流向下一個，知道所有必要的處理完成。

服務組件間路由消息
??? 如前所述，Service Component包含在消息上處理數據的業務邏輯， 它不包含任何關于接受或發送消息的信息。

??? 為了確保該Service Component接收正確的消息，并在處理后妥善路由消息，當你配置Mule ESB的Service Component時可以指定入站路由器(inbound router)和出站路由器(outbound router)。

??? Inbound Router指定這個Service Component將要處理的消息。然后可以過濾進來的消息并聚集它們，然后在路由消息到Service Component之前將他們重新排序。例如，Service Component，如果一個Service Component支持RSS feed, Inbound Router可能過濾那些從那個feed中發來的消息。

??? Service Component處理完消息之后，Outbound Router指定將消息發送到哪里。例如：它可能路由正式地址的發貨單到一個發貨部門，路由所有其他的發貨單到另一個發貨部門。你能定義多個Inbound和Outbound路由器，甚至連接在一起，使Service Component接受和發送消息的要求完全一樣。



從消息中分離業務邏輯

??? Mule ESB 眾多優勢中的一個就是它能處理多種協議發送來的消息。 例如：發貨單可能總是XML的格式，但是他可能通過HTTP發送，或者作為一個JMS消息，這依賴于制作發貨單的應用系統。 如果Service Component僅處理業務邏輯和數據，而不是信息本身，它如何知道怎樣讀取接收到的各種格式的消息？
??? 答案是Service Component不知道如何閱讀消息，因為通常消息格式對于Service Component是完全屏蔽的。 取而代之的是，一個Transport攜帶消息一起，然后在路由器將消息傳遞到Service Component之前， Transformers以Service Component可以讀取的格式改變消息的負載(Payload, 例如發貨單)。
??? 例如：如果XML發貨單通過HTTP發送過來， HTTP Transport攜帶消息一起，直接路將此消息路由到需要處理它的每一個Service Component，然后Transformers在前進的道路上對于每一個Service Component必要的改變發貨單（如：從XML轉換到Java對象）。



?? Transformers是交換數據的關鍵， 因為它允許Mule轉換數據到另外一個組件或應用程序可以理解的格式上。最重要的是， 數據只在必要時做轉換。代替將每個消息轉換到一個公共的消息格式上的是：消息和他們的數據只在該消息的目標組件或應用程序需要時做轉換。
最后你可以使用多種類型的Transports來處理不同的通道（Channels）, 如：在HTTP上發送消息(Mule在HTTP上接收到消息)，經過Customer Data service component的處理，將它作為一個JMS消息轉發。
?? 將業務邏輯與發送和消息轉換的分離，就帶來更大的靈活性，你如何設置你的架構，并使其更加簡單來定制業務邏輯，而不必擔心可能到來的各種消息格式。
如果需要，你的Service Component可以使用消息的原始數據，但不是必須的。

將全部融合到一起
??? Endpoints是將所有的服務融合到一起的關鍵配置元素。你在Inbound和Outbound Router上指定Endpoints, 來告訴Mule ESB, 使用哪一個Transport，發送消息到哪里，哪些消息是Service Component應該接受。 Endpoint的主要部分是地址，表示為一個URI(統一資源標識符, Uniform Resource Indicator (URI)), 它表示要使用的Transport， 位置(一個Transport特性的資源)，以及其他額外的參數。
??? 例如： 如果服務的Inbound Router指定Endpoint [http://myfirm.com/mule], HTTP Transport會將發送到那個URL的所有消息轉發到Service中。如果Inbound Router指定為file://myserver/files/, File Transport將會觀察那個目錄，轉發任何在那個目錄中創建的新文件到Service中。你在Outbound Router中指定的Endpoint標識消息要走的下一步 - 消息會到達有著和前一個Service的Outbound Endpoint相同的Inbound Endpoint的Service, 像如下圖解所示。
???


??? Service可以使用不同的Transports接收消息。對于每種Service將用到的Transport，你必須指定一個或多個分離的Endpoint。例如：如果你想要你的一個Service能夠處理從HTTP和JMS通道過來的消息，你需要在這個Service的Inbound Router上指定至少一個HTTP Endpoint和至少一個JSM Endpoint。
??? Mule在這個Service上注冊這些Endpoints, Transport運行時使用這些注冊信息來配置自身并決定發送和接收消息的位置。Router或Endpoint能包含過濾器(Filters), 這進一步指定發送和接受哪些消息。例如：你可以指定Service Component只接受來自于特定作者的RSS消息。
??? 為你的Services指定Routers和Endpoints，需要簡單編輯一個XML文件。你不需要編寫任何Java代碼。 如前所述，你的Service Components代碼仍然與消息和路由完全分離，你只需要處理Mule配置。
??? 總而言之，Mule提供了一個簡單、輕量級的方式來編寫處理數據的Service Components, 他們不需要擔心數據的發送和接收、數據格式、以及發送或接收數據中使用到的技術。
??? 然而，很多供應商和集成技術提供連接到不同的數據源的能力，但通常都要求額外的編碼信息以達到想要的獲取消息和分發數據的效果。Mule允許你快速開發Service Components，通過簡單的XML配置而不是編寫Java代碼。


原文地址：
[urlhttp://www.mulesoft.org/documentation/display/MULE3INTRO/Understanding+the+Messaging+Framework[/url]

[urlhttp://www.mulesoft.org/documentation/display/MULE3INTRO/Understanding+the+Mule+Architecture[/url]

本文PDF版本下載：

Mule 介紹及架構理解 Getting Started