與Mule 2.0抵死纏綿了兩周，喜憂摻半。但只在2.0之后，Mule才算真正站到了ESB的起跑線上。
 
  完整的筆記見我的Wiki: http://wiki.springside.org.cn/display/calvin/Mule , 這里主要列一下實際的升級感受。

1. 很Spring，很SCA的配置文件

  • 全Spring又全nameSpace化的配置文件，簡潔而規范，在IDE中有良好的提示。
    尤其是transport相關的endpoint的改進明顯，原來的URI<endpoint address="pop3://bob:secret@localhost: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支持增強
    Mule RESTPack ，支持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. 工具增強
    Mule Galaxy  SOA治理工具(開源)， Mule Saturn  消息流監控工具，Mule HQ  底層監控工具。
    不過還沒試用不知道實際效果如何。

3. 遺憾的地方：

  1. 性能下降
    無論是代替XFire的CXF還是Mule 2.0，都拖得性能大大下降。
    用一個簡單例子測試，Mule 1.4+XFire  : Mule 1.4 + CXF : Mule 2.0 + CXF 的每秒事務數對比是15000：10000：8000。
  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類里，居然有內存泄漏，原因是用沒有重載Object的equals()函數的StringBuffer作為HashMap的key，結果map永遠都在增大。
    這說明了，開源項目的質量，最終是靠一個積極使用和反饋的用戶群和一個活躍的開發團隊，"用"出來的。