mule2.1.2 初步認識 釋出cxf 和axis服務                    

一、總述  

      Mule的運作能力也許是它在開源ESB中最大的優勢：商業的支援公司，給大家貢獻程式碼的，年度大會MuleConf，還挖來了CXF的作者與SaleForces的CXO......

二、示例

三、Mule的功能

1.  重溫ESB的功能

• 解耦中介：客戶對實際服務提供者的身份、物理位置、傳輸協議和介面定義都是不知道也不關心的，互動整合程式碼提取到了業務邏輯之外，由ESB平臺進行中央的宣告式定義。
                ESB平臺實現協議轉換
  (WebService，Http，JMS...)，訊息轉換(轉換、充實、過濾)，訊息路由(同步/非同步、釋出/訂閱、基於內容路由、分支與聚合...)。
• 服務中介：ESB平臺作為中介提供服務互動中的基礎服務。
                ESB平臺實現SLA(可靠性保證，負載均衡，流量控制，快取，事務控制，加密傳輸)，服務管理監控(異常處理，服務呼叫及訊息資料記錄，系統及服務的狀態監控，ESB配置管理)，統一安全管理(這個有點理想主義)。
• 服務編排：多個服務進行編排形成新的服務。
                ESB支援一個直觀的形式定義新組合服務的流程(工作流、BPEL 或 程式碼級編排)。

2. Mule的解耦中介

    Pluggable的傳輸層，路由器，轉換器是所有ESB必然支援的核心功能，作為《Enterprise Intergration Patterns》的遵循者提供如下：

• ：WebService、JMS等常用的協議都已滿足，IBM MQ在企業版中提供，只缺Weblogic Tuxedo了。
• /:提供EIP中描述的路由
  1.基於內容路由，Fillter提供訊息型別、訊息屬性、JXPath和OGNL表示式的基礎過濾能力。另有去除重複訊息的Router。
  2.接收表基類，由使用者自行實現。
  3.分拆聚合重排路由。
  4.流程編排路由見後。
• ：提供基礎層次上的的協議型別轉換、XML<->Java轉換、編碼、壓縮、加密轉換。業務級轉換由使用者實現。

      不過，1.4版中的Transport的實現質量很一般，而Router、Filter、Transformer都實現得較簡單和基礎，

      最後，Mule額外提供了POJO的程式設計模型，而不是痛苦的XQuery Base的XML訊息。

3. Mule的服務中介

     提供較基本的中介服務：

• 事務(支援XA的JDBC,JMS,VM queue)
• 異常處理(支援異常控制策略與Dead Letter Channel)
• 安全 (用Acegi意思了一下，弱)

    其他的能力如流量控制、負載均衡，可基於Mule的機制自行實現。

4. 服務編排

• ChainRouter簡單實現Pipeline模式
• JBPM Router(見loanbroker example)。
• 在1.4版中還有  和Apache PXE BPEL Router。

5. Service Container

   這是個額外的Bonus。Mule的身份並不純粹。如果Component是什麼都不幹的Bridge Component，它就是真正純排程外部服務的ESB。
   如果Component是業務POJO，在Mule中執行業務邏輯，Mule就成為一個Service Container，類似於SCA Domain。
   這時候它本身就是Spring+CXF的，額外有多通訊協議支援，有SEDA(Staged Event-Driven Architecture)，有非同步程式設計模式，有服務中介基礎設施，作為後臺服務容器也是個不錯的選擇。
   日後自己可能會越來越多使用Mule 2.0+Terracotta作為自己的服務容器方案。

四、Mule2.0 印象

    與Mule 2.0抵死纏綿了兩週，喜憂摻半。但只在2.0之後，Mule才算真正站到了ESB的起跑線上。

1. 很Spring，很SCA的配置檔案

• 全Spring又全nameSpace化的配置檔案，簡潔而規範，在IDE中有良好的提示。
  尤其是transport相關的endpoint的改進明顯，原來的URI<endpoint address="pop3://bob:[email protected]:62002"> 或如下的connector

<connector name="SystemStreamConnector" className="org.mule.providers.stream.SystemStreamConnector">
    <properties>
        <property name="promptMessage" value="Please enter something: "/>
        <property name="messageDelayTime" value="1000"/>
    </properties>
</connector>

            改為transport特定的namespace後，IDE中清晰顯示了可選的配置項。

<stdio:connector name="SystemStreamConnector" promptMessage="Please enter something: "messageDelayTime="1000"/>

• SCA的Service/Component概念。
  Service/Component代替了原來註定要被遺忘的MuleDescriptor，其中Component定義業務邏輯的POJO，Service定義如何以服務的方式管理元件的配置。
  在POJO中呼叫遠端服務的Nested Router也改為了很SCA的Binding。
  Component也有Component 與 PooledComponent的選項。完整的例子如下：

<pooled-component>
  <spring-object bean="mySpringPojo"/>
    <binding interface="org.mule.example.loanbroker.credit.CreditAgencyService">
      <outbound-endpoint ref="CreditAgency"/>
    </binding>
    <pooling-profile exhaustedAction="WHEN_EXHAUSTED_FAIL" initialisationPolicy="INITIALISE_ALL"
      maxActive="1" maxIdle="2"maxWait="3"/>
</pooled-component>

      上文按pooling-profile定義的pooled-component，在spring中定義mySpringPojo，並將一個遠端的CXF Endpoint binding到POJO的CreditAgencyService變數中，可直接呼叫；

• 視覺化拖拽的Eclipse 外掛Mule IDE。
  雖然還非常原始，但總算有個盼頭。

2. 架構的更改

1. Web Service支援增強
   隨著CXF作者的加入，Web Service這事實上SOA裡最重要的Transport得到了加強，WSDL終於可以通過annotation準確配置。
   雖然無奈，就衝這個理由就應該升級到2.0了。不是2.0太好，而是1.4太差了。
2. REST支援增強
   ，支援apache abdera(Atom Publish協議實現)，Jersey(JSR131 RESTful WebService實現)和Restlet 三種Transport。
3. 程式碼結構的合理化
   抽象出相對穩定的org.mule.api介面包，代替原來的org.mule.umo包。
   開發團隊還檢查調整了Mule中所有物件的定義，使其更加準確。
4. 各個模組的升級
   如核心MuleManager大物件拆成MuleContext and Registry，執行時Reistry支援動態載入Service，支援向OSGI進軍；
   如以流的方式轉換處理訊息。
   如SEDA模型定義的細化，見後。
5. 工具增強
   SOA治理工具(開源)， 訊息流監控工具， 底層監控工具。
   不過還沒試用不知道實際效果如何。

3. 遺憾的地方：

1. 效能下降
   無論是代替XFire的CXF還是Mule 2.0，都拖得效能大大下降。(但用JDK6的話情況又好一點)
2. 仍然沒有自帶的叢集，負載均衡，流量控制實現。
   不像BEA、ServiceMix都使用JMS的底層，Mule使用vm queue在單一JVM的節點間流動。
   我們團隊主要用TerraCotta在叢集裡同步狀態資料，流量控制與負載均衡也是自己實現。
3. CXF transport 仍然使用Mule自己實現的Http Connector。
   CXF Standlone也是用Jetty的，看tomcat們努力的勁頭，相信誰都能隨便實現一個不錯的Http Connector。
4. 從1.4升到2.0非常的花時間。
   估計團隊重構的太興奮了，從程式碼到配置檔案再到XFire to CXF，一些程式碼級修改還沒文件詳述。
5. 文件從1.4版更新到2.0版的進度太慢，而且文件仍然簡略。
6. 質量仍然在使用中檢驗。
   文件說2.0版本的比1.x版本增加了30%的單元測試用例，按理來說專案質量應該提高了。
   但還是被我發現了在很重要的AbstractEntryPointResolver類裡，居然有記憶體洩漏。()
   原因是用了StringBuffer作為HashMap的key，而SB並沒有過載Object的equals()函式的，結果map永遠都在增大。

這說明了，開源專案的質量，最終是靠一個積極使用和反饋的使用者群和一個活躍的開發團隊，"用"出來的。

五、詭異的訊息流

     不同的inbound-outbound模式下，Mule中的訊息流與互動模式非常詭異，不熟悉的人會很痛苦，詳見，不過好在Mule 2.1進行了清晰化

• 同步模式：如果component有outbound，最終向呼叫者的返回結果就是outbound的返回結果還是component的，取決於outbound裡的synchronous屬性，
                  如果為True，則返回outbound的結果，為false或者不設定，則返回component，並非同步將訊息發給outbound。
                  如果沒有outbound，如果component的函式返回null，則返回NullPayload，如果函式為void，返回請求引數，其餘正常返回。
• 非同步請求應答模式：一個同步Inbound，一個Ountbound（通常有reply-to的配置），一個 async-reply。Component請求，發給outbound，在async等待outbound返回，再返回給呼叫者。

六、詭異的SEDA模型

   Mule 2.0的SEDA模型配置更加細膩，但卻沒有文件描述，以下都是從配置檔案的Schema讀出。

  SEDA的配置項仍然分Thread Pool、Component Pool、Queue三項，但其中Thread Pool又細分Receiver,Dispatcher ,Component 三項。

• <configuration>可設定全域性的Thread Pool，又分default-threading-profile與default-receiver-threading-profile等四項。後面三項如果沒有特別設定，則採用第一項的值。
• <connector>可設自己的dispatcher與receiver threading profile。
• <model>可設自己的queue profile。
• <service>可設自己的component-threading-profile與queue profile
• <pooled-component>可設自己的pooling-profile。

換個角度描述：

• Threading：<configuration>描述全域性預設Threading，<connector>描述dispatcher與receiver，service描述compent-threading
• Compoent Pool:<pooled-component>
• Queue:<model>，<service>

最後結果，配了default-threading-profile為100後，系統開了100條的http.receiver，其他component和vm.receiver都只有1條執行緒。在典型場景的CXF -> component->同步VM Queue ->component的情況下，一個請求的兩個component都在同一個http.receiver執行緒內執行。

相對於1.4的改進：

  Thread Pool的配置細膩了，而且不會去開N條實際用不到的vm.receiver

  Component 不再預設有個物件池，也可以是<component>指向自身或Spring的單例，<pool-component>時才做池化處理。