環球即時看！【企業版】Mule3的新增特點-云連接

What is Mule?

(相關資料圖)

Mule有兩個版本，社區版和企業版。 社區版是免費，企業版是收費的，企業版相比于社區版功能豐富許多，它們的比較如下：

1、相比同類框架而言，提供很多優勢，包含：

Mule近期推出了Mule3，Mule3的新增特點-云連接（Cloud Connect） 提供了可以用簡單安全的方式為企業提供基于云技術的數據和服務。它的核心是IBeans，一個輕量級、可重用的接口，用于Web技術的連接擴展和數據服務。

Mule云包括以下內容 1、 Integration Beans （合成bean）：他們是可重用的云接口，可以注入到組件中，可以接受外部的服務，比如說亞馬遜、推特、Facebook等，并且是一種簡單的接收服務、管理安全機制的方法。請求驗證、數據傳輸、錯誤掛起等也可以通過這種方法來實現。 2、 Rest / JAX-RS：（REST協議：即REST(Representational State Transfer表述性狀態轉移)是一種針對網絡應用的設計和開發方式，可以降低開發的復雜性，提高系統的可伸縮性。） 現在Jersey 已經是Mule核心部署的一部分，提供本地化的對REST和JAX-RS的支持，例如Apache CXF。Jersey現在已經在易配置和高可擴展性方面做的非常優秀。Jersey現在使用一種包含很多Jersey資源的接口實現組件來替代終端類型的實現方式。 3、 AJAX：Mule現在直接融合了Javascript應用。Mule3包括了服務終端和Javascript客戶端允許事件被直接發布到瀏覽器，并且事件可以從瀏覽器進行發布。 4、 Web Service：現在對Web Service的發布的配置將更加容易，其擴展性也進一步加強。 5、 ATOM and RSS：Mule 3 現在能夠較好的支持ATOM了。 6、 JSON Support：Mule3包含對JSON數據綁定和JSON傳輸的支持。 7、 JAXB Support：支持組件XML綁定將自動進行，并且也添加了新的JAXB傳輸。 其他的一些支持： 1、FLOW：配置的流程化。 2、Patterns：配置的模式化，可以極大簡化配置，將不同情況的配置進行模式化劃分。 3、Annotation：改進后新的注釋方法對組件中的注入反轉、transformers的發布、組件方法的Pol有很大作用。 4、Deployment：支持單一服務和組服務的熱部署。同時支持部署模型定義。 結構上的提高： 5、Message Processor API：消息處理API，Mule3其內部處理方式較為靈活，能夠在將來其他模式調整時適應外部服務組件。 6、Message Exchange Patterns：消息交換模式，消息在Mule3中的流轉將更加精確和靈活。 7、Message Property Scoping：消息屬性作用域。較好的實現了屬性的作用范圍。 8、Lifecycle Improvements：生命周期的改進。優化了Mule的開啟和關閉行為，熱部署也在這方面得以展現，并支持JSR-250 生命周期注釋方法。 9、Exception Handing：異常處理，異常處理的兼容性更好，并且有錯誤行為預處理功能。 10、Automatic Transformation：自動轉換，Mule3增強了自動轉換引擎，用于進行數據綁定，例如XML/JAX、JSON，并支持自定義。 11、CXF Now a Module：CXF現在在Mule3中作為一個模塊，在Mule3中對CXF進行了優化，使得CXF的用戶與普通的管道/過濾器元素一樣。 12、REST：Mule的開發團隊十分看好REST，在其文檔中使用了“enjoy”這個單詞來形容REST，可見使用REST協議開發Mule3服務應該是比較合適的。 Mule3其他的一些變化： 1、Message factories：消息工廠，從底層將消息翻譯成MuleMessage格式。所有MuleMessage都是由消息工廠創建的。 2、XQuery Support：對XQuery支持。 3、Dynamic Endpoints：動態終端，Mule中的終端可以動態構造，通過Mule傳輸的消息可以構造終端地址。 4、JBoss jBPM：文檔中說明Mule從很早以前就開始與JBoss jBPM進行整合了，但是在Mule3中，對其進行了改善，并將JBoss jBPM版本升級到了4.4版本。 5、Transaction Enhancements：Transaction被增強，通過配置元素屬性，Mule可獲知在Mule外部Transaction已經開始了。 6、AXIS Code Removed from Mule：AXIS代碼在Mule3中被移除，其將作為一個獨立模塊存在。

? Mule 組件可以是任何你想要的類型。你可以簡單的集成任何東西, 從POJO到其他框架的組件。? Mule 和 ESB 模型使得重大的組件重用。不象其他的框架，Mule允許你在不做任何變化的情況下使用已存組件。組件不強制要求有Mule特性的代碼，就可以在Mule中運行，沒有程序式的API強制要求。業務邏輯和消息邏輯完全分離。? 消息（Messages）可以是任何格式，從SOAP到二進制圖片文件（binary image files）。Mule沒有強制任何架構上的設計約束，例如XML消息或 WSDL服務約束。? 可以一些拓撲結構上部署Mule，不僅僅是ESB。因為它是輕量級 和 嵌入式的，Mule能降低上線時間，提高生產力，為工程提供安全 可伸縮的應用系統，它適應變化，在需要時提高或降低系統規模。

Mule ESB是基于Java的輕量級消息框架——允許你簡單 快速的連接應用系統，使得他們（應用系統）可以交換數據。Mule使用SOA(Service-Oriented Architecture-面向服務架構)——使得簡單集成已存應用系統成為可能。

特性

功能強大，易于使用(Easy to learn, powerful to use)

集成、部署非常方便(Integrate with anything, deploy anywhere)： 提供了超過120個用來集成協議、應用的連接器和模板，足夠應對常見的企業級應用集成問題，支持云端。

拖拽式的圖形化界面設計器(Drag-and-drop graphical design)： 使用Anypoint Studio這個圖形化設計的IDE，開發人員可以高效地創建集成流程。

使用常見的工具(Use the tools you know)： Mule ESB使用的是一些主流的開發工具，如Eclipse、Maven, Spring and Ant，開發人員可以很容易上手。

專為開發者而設計，被全球企業所選擇(Designed for developers, chosen by global enterprises)

一個安全的平臺(A secure platform)： 系統會阻止未經授權的訪問，保護敏感的數據，通過Anypoint Enterprise Security的安全管理機制主動防御潛在的攻擊。

可擴展的、可靠的、可用的(Scalable, reliable, available)： 高吞吐量和高度分布式環境的架構。

Mule ESB的內置高可用性集群和數據網格可以確保不會有消息丟失。 內置可見性(Built-in visibility)：提供查看運行性能的界面，監控關鍵的統計數據，并可以設置SLA報警，為診斷和解決性能問題提供極大便利。 封裝性——管理應用系統和組件之間的交互，不管它們是否在同一個VM(Visual Machine-虛擬機，即JVM-Java虛擬機)或在Internet上，不管底層使用的傳輸協議。不管應用系統使用的是哪些不同的技術，包括：JMS Web Services JDBC HTTP 等，Mule可以無縫的在他們之間進行處理交互動作。高度可擴展性——允許你以很小的規模開始，隨著時間的推移，連接更多的應用系統。

2、Mule基于Enterprise Service Bus(ESB)架構思想。

補充：【見ppt即可】

0、軟件開發的演變歷程面向機器語言(Monolithic)的開發模式需要根據不同平臺的機器語言來開發代碼。 面向過程(Procedure)的開發模式使用獨立于機器的程序語言來進行開發，如C、Pascal，用過程來代表一個抽象的代碼集合，包裝重用現成的代碼。 面向對象(Object)的開發模式用更接近現實的對象來表述一個相對完整的事物，面向對象的語言(C++，Java等)，提供了更抽象的封裝和重用模式。面向對象的開發強調從現實世界問題域到軟件程序的直接映射，更接近人類的自然思維方式。 面向組件(Component)的開發模式隨著軟件開發規模的擴大，在涉及分布式、異構等復雜特征的環境中，代碼級別的重用性差，可維護性差，效率低的弱點是不可逾越的，因此人們以架構運行環境(如.Net，J2EE等)來提供完善的支撐平臺，從而把開發者解放出來，更專注于業務核心的開發。而這些業務功能(Business Function) 以組件的形式(DCOM， EJB等)發布運行在架構運行環境中。軟件開發的重用模式也上升到業務組件的級別。 面向服務(Service)的模式

1、面向服務架構SOAService-Oriented Architecture，面向服務的體系結構

一種架構模型，它可以根據需求通過網絡對松散耦合的粗粒度應用組件進行分布式部署、組合和使用。

SOA架構有哪些基本的要求？ SOA在相對較粗的粒度上對應用服務或業務模塊進行封裝與重用 服務間保持松散耦合，基于開放的標準， 服務的接口描述與具體實現無關 靈活的架構 -服務的實現細節，服務的位置乃至服務請求的底層協議都應該透明

2、ESB：圖1：已經按照SOA的思想提煉出了各種業務服務，公布出來，同樣，你發現其他很多人也做了同樣的事情。大家都很振奮，開始踴躍的嘗試，我調用你的一個服務，你調我的一個服務。啊哈！大家都SOA了。且慢，那么這個SOA給你們帶來了什么好處呢？Ok，現在我可以在J2EE環境里調用.Net的組件了，但是原來沒有SOA的時候也可以做到的呀。只要兩個節點之間互相認可對方的方式，即使不存在公開/統一的服務界面也可以實現點到點的互聯。因此我們不得不承認，如果我們只有服務，而服務的請求者和服務的提供者之間仍然需要這種顯式的點到點的調用，那么這就不是一個典型的SOA架構。服務的參與雙方都必須建立1對1 的聯系。

在SOA中，我們還需要這樣一個中間層，能夠幫助實現在SOA架構中不同服務之間的智能化管理。最容易想到的是這樣一個HUB-Spoke結構，在SOA架構中的各服務之間設置一個類似于Hub的中間件，由它充當整個SOA架構的中央管理器的作用。

圖2：現在服務的請求者和提供者之間有了一個智能的中轉站， 服務的請求者不再需要了解服務提供者的細節。 可能會出現哪些問題呢？首先，整個SOA架構的性能，如果每個服務的請求都經過中央Hub的中轉，那么Hub的負擔會很重，速度會隨著參與者的增多而愈來愈慢；其次，這樣的系統會很脆弱，一旦Hub出錯，整個SOA架構都會癱瘓；最后，這樣的架構會破壞SOA的開放性原則，參與者運行在一個相對封閉的環境中，擴展起來十分麻煩。

圖3： MuleESB是一種在松散耦合的服務和應用之間標準的集成方式(即使我們需要一些Hub，那么它們也是以某種服務的形式部署在總線上，相比上面的結構要靈活的多 ) - 比單一Hub的形式更開放，總線結構有無限擴展的可能 - 真正體現了SOA的理念， 一切皆為服務，服務在總線(BUS)中處于平等的地位

ESB可以作用于：

面向服務的架構（分布式的應用由可重用的服務組成）面向消息的架構（應用之間通過ESB發送和接受消息）事件驅動的架構（應用之間異步地產生和接收消息）

//見ppt 首先，在ESB系統中，被集成的對象被明確定義為服務，而不是傳統EAI中各種各樣的中間件平臺，這樣就極大簡化了在集成異構性上的考慮，因為不管有怎樣的應用底層實現，只要是SOA架構中的服務，它就一定是基于標準的。

其次，ESB明確強調消息(Message)處理在集成過程中的作用，這里的消息指的是應用環境中被集成對象之間的溝通。傳統的EAI系統中的消息處理大多是被動的，消息的處理需要各自中間件的私有方式支持，例如API的方式。ESB系統由于集成對象統一到服務，消息在應用服務之間傳遞時格式是標準的，直接面向消息的處理方式成為可能。如果ESB能夠在底層支持現有的各種通訊協議，那么對消息的處理就完全不考慮底層的傳輸細節，而直接通過消息的標準格式定義來進行。這樣，在ESB中，對消息的處理就會成為ESB的核心，因為通過消息處理來集成服務是最簡單可行的方式。這也是ESB中總線(Bus)功能的體現。ESB的概念不僅僅是提供消息交互的通道，更重要的是提供服務的智能化集成基礎架構。

最后，事件驅動成為ESB的重要特征。通常服務之間傳遞的消息有兩種形式，一種是調用(Call)， 即請求/回應方式，這是常見的同步模式。還有一種我們稱之為單路消息(One-way)，它的目的往往是觸發異步的事件， 發送者不需要馬上得到回復?？紤]到有些應用服務是長時間運行的，因此，這種異步服務之間的消息交互也是ESB必須支持的。除此之外，ESB的很多功能都可以利用這種機制來實現，例如，SOA中服務的性能監控等基礎架構功能，需要通過ESB來提供數據，當服務的請求通過ESB中轉的時候，ESB很容易通過事件驅動機制向SOA的基礎架構服務傳遞信息。

3、主要功能

Mule是一個輕量級的集成平臺，Mule不是用來創建多個系統、服務、APIs或者設備之間的點對點集成，而是用來智能管理節點之間的消息路由、數據映射、編排以及使消息可靠地、安全地傳遞。其他系統和應用接入Mule，讓Mule處理所有系統之間的通信，并且可以跟蹤和監控發生的一切。

使用Mule，可以：

4、Mule基礎4.1 Anypoint平臺Anypoint Platform是一個完整的用于SOA、SaaS和APIs的集成平臺，提供了一組功能強大的工具和服務來實現以下集成目標： ? 集成SaaS和本地應用程序； ? 現代化的遺留服務(legacy services)； ? 編排業務流程和服務； ? 為終端用戶、B2B應用和移動端應用設計和發布API； ? 創建API代理使實現脫離業務流的編排(Create API proxies to separate implementation from orchestration)； ? Engage consumers of your API ? 管理API的運行時策略(Govern APIs with runtime policies)

4.2 幾個重要的概念流程和消息(Flows and Messages)