Mule簡介

    筆者一直在研究和開發ESB相關項目，最近一周學習了Mule項目，對Mule開源ESB項目有了一定的認識。本文寫一些mule的簡介。在下一篇文章中介紹了Mule的安裝部署和使用例程。

    Mule是什麼？

    Mule是一個輕量級的基于Java的ESB消息架構，它允許使用者快捷地連接配接多個應用并且在這些應用之間交換資料。Mule使用了SOA的體系結構思想，可以友善的內建已有的應用。它是可更新的、高分布式的對象代理，可以通過異步傳輸消息技術來無縫的處理服務與應用之間的互動。

    Mule架構提供了一個可更新的環境，可以把自己的業務元件部署在裡面。Mule管理所有元件之間的互動，不管它們是在同一個虛拟機中還是在internet上，也不管底層使用的傳輸方式。

    Mule圍繞着企業服務總線（ESB）架構進行設計，保證了不同的元件或者應用可以通過公共的消息總線進行互動，公共的消息總線一般是由JMS或者其他消息伺服器來實作。

    在應用中會使用不同的技術，包括JMS,Web Services，JDBC，HTTP等等，Mule可以很好地處理他們之間的互動。

    Mule有以下的優點：

    (1)Mule元件可以是你需要的任何類型。你可以很容易地內建一切從一個"plain old Java object"（POJO）到另一個架構的元件。

    (2)Mule和ESB模型允許元件重用。不像其他的架構，mule允許你使用一個已有的元件而不需要改變。元件不需要任何特定的mule代碼，并且沒有要求的API。業務邏輯和消息邏輯保持完全分離。

    (3)消息可以是任何格式，從SOAP到二進制圖像檔案。mule對體系結構不強制任何設計限制，比如XML消息或者WSDL服務。

    (4)你可以以多種拓撲結構開發mule，不僅僅是ESB。因為它是輕量級的和可嵌入的，mule可以有效地減少到市場的時間，并且增強項目參評，比如安全性，可擴充性。

    mulesorce提供了管理工具運作管理你的開發(Mule HQ)和基礎設施(Mule Galaxy)。

    了解消息架構

    應用網絡化的好處是使得一個應用能夠發送資料到另一個應用。但是許多應用不能夠讀取和處理另一個應用的資料。Mule通過在應用之間提供一個消息架構以消息的方式讀取、轉換和發送資料來解決這個問題。一個消息是一個資料包，它可以在一個特定的管道(channel，也成為一個queue)中處理和發送。如下圖所示：

    了解Mule體系結構

    該部分讨論了Mule體系結構的不同部分和他們如何處理消息和資料。這裡使用了一個例子：一個公司需要為客戶訂單(order)産生發票(invoice)，對這些發票執行一些處理後，把它們發送到運輸部門以滿足訂單。

    處理過程：

    把業務邏輯和消息分離

    Mule的一個優點是它能處理通過一系列協定發送的消息。例如，一個發票(invoice)可能是XML格式的，但是它可能通過HTTP到達，也可能是作為一個JMS消息，這取決于哪個應用建立了這個發票(invoice)。如果服務元件僅僅處理業務邏輯和資料，而不是消息本身，它是如何讀取各種格式的消息的呢？

    答案是：服務元件不知道如何讀取消息，因為預設地，服務元件和消息格式是屏蔽的。取而代之，一個transport單獨攜帶消息，transformer在router傳遞這個消息到服務元件之前改變消息的負載(比如剛才的invoice)，它按照需要格式化使得這個服務元件可以讀取。例如，如果一個XML invoice通過HTTP被發送，HTTP transport攜帶這個消息，router指導這個消息到達每一個服務元件以處理它，并且transformer按需要沿路改變這個invoice(比如從XML到一個Java對象)。所有的這些transporting,transforming和routing對于消息元件是透明的。

    把所有的組織起來

    Endpoint是配置的元素，是把所有服務組織起來的關鍵。你在inbound和outbound routers指定endpoint來告訴Mule使用哪個transport，把消息發送到哪裡和服務元件需要接收哪個消息。一個endpoint的主要部分是位址(address)，表達成URI，表示了使用的transport、位址和任意額外的參數。

    下面說明上圖所示的邏輯資料流：

    (1)使用者放一個order到公司網站，并且一個invoice被建立成一個XML格式并且送出到http://myfirm.com/orders。

    (2)HTTP transport接收這個XML invoice并且把它包裝成一個Mule message。這個使用者資料服務的inbound endpoint設定成http://myfirm.com/orders，并且它的inbound router指定這個消息必須包含一個Java對象，是以HTTP transport準備轉換這個XMLinvoice并且分發這個消息到這個服務。

    (3)XML到對象 transformer把XML invoice轉換成一個Java對象。

    (4)這個transport把這個消息傳給使用者資料服務。

    (5)使用者資料服務元件查詢master customer database（資料庫）以擷取關于永和的額外資料，并且更新invoice的資料。

    (6)HTTP transport使用outbound router配置來決定它必須分發消息到http://myfirm.com/verify。

    (7)HTTP transport使用Inventory Verification服務的inbound router配置來擷取消息并且把它傳輸到服務元件。

    (8)服務元件更新invoice，有那個warehoused的一個ID code，這個倉庫有所有的現在庫存的invoice。

    (9)outbound endpoint 指定一個JMS位址，所有這個JMS transport分發這個消息到order fulfillment application，這個應用挑選訂單。

    Mule中的幾個名次解釋：

    1. Connectors ：就是支援不同協定的連接配接器。例如：Http,FTP,Mail,Soap,JMS和MW等等.通常連接配接器有三種類型：隻用于接收，隻用于發送和兩者皆可。

    2. EndPoints Address：終端位址，類似于jms://topic:myTopic這樣的東西。前面的ｊｍｓ就是連接配接器的類型。後面是各個連接配接器能識别的位址。這 個位址可以是接收器識别的位址，例如：jms://topic:myTopic表示對myTopic這個隊列進行監聽。也可以是發送器識别的位址。例如 pop3://user:[email protected]将某一個消息發送到遠端郵箱裡面。

    注意這裡的位址是你自己命名的，通常不同的應用有不同的位址，例如某個應用是jms://topic:myTopic。另一個是jms://topic:myTopic2

    3. UMO Components ：可以想象成這是ESB總線上的一個個晶片，控制器。在Mule裡面，他們是一些POJO，負責接收消息，然後進行處理，在發送出去。例如，一個UMO它 的作用是監聽jms://topic:myTopic裡面的消息，如果有，加以處理後發送到pop3: //user:[email protected]這個郵箱裡面。

     顯而易見，UMO通過簡單的調用EndPoints Address來接收消息和轉發消息。它不需要知道自己按照什麼協定接收和發送消息。這就是ESB的作用所在，即提供統一的總線接口。

    在下一篇文章中介紹了Mule的安裝部署和使用例程。

     本文轉自panpan3210 51CTO部落格，原文連結：http://blog.51cto.com/panpan/132100，如需轉載請自行聯系原作者