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

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

  • 全Spring又全nameSpace化的配置文件，簡(jiǎn)潔而規(guī)范，在IDE中有良好的提示。
    尤其是transport相關(guān)的endpoint的改進(jìn)明顯，原來(lái)的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中清晰顯示了可選的配置項(xiàng)。

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


  • SCA的Service/Component概念。
    Service/Component代替了原來(lái)注定要被遺忘的MuleDescriptor，其中Component定義業(yè)務(wù)邏輯的POJO，Service定義如何以服務(wù)的方式管理組件的配置。
    在POJO中調(diào)用遠(yuǎn)程服務(wù)的Nested Router也改為了很SCA的Binding。
    Component也有Component 與 PooledComponent的選項(xiàng)。完整的例子如下：
<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，并將一個(gè)遠(yuǎn)程的CXF Endpoint binding到POJO的CreditAgencyService變量中，可直接調(diào)用；

  • 可視化拖拽的Eclipse 插件Mule IDE。
    雖然還非常原始，但總算有個(gè)盼頭。

2. 架構(gòu)的更改

  1. Web Service支持增強(qiáng)
    隨著CXF作者的加入，Web Service這事實(shí)上SOA里最重要的Transport得到了加強(qiáng)，WSDL終于可以通過(guò)annotation準(zhǔn)確配置。
    雖然無(wú)奈，就沖這個(gè)理由就應(yīng)該升級(jí)到2.0了。不是2.0太好，而是1.4太差了。 
  2. REST支持增強(qiáng)
    Mule RESTPack ，支持apache abdera(Atom Publish協(xié)議實(shí)現(xiàn))，Jersey(JSR131 RESTful WebService實(shí)現(xiàn))和Restlet 三種Transport。
  3. 代碼結(jié)構(gòu)的合理化
    抽象出相對(duì)穩(wěn)定的org.mule.api接口包，代替原來(lái)的org.mule.umo包。
    開發(fā)團(tuán)隊(duì)還檢查調(diào)整了Mule中所有對(duì)象的定義，使其更加準(zhǔn)確。
  4. 各個(gè)模塊的升級(jí)
    如核心MuleManager大對(duì)象拆成MuleContext and Registry，運(yùn)行時(shí)Reistry支持動(dòng)態(tài)加載Service，支持向OSGI進(jìn)軍；
    如以流的方式轉(zhuǎn)換處理消息。
    如SEDA模型定義的細(xì)化，見(jiàn)后。
  5. 工具增強(qiáng)
    Mule Galaxy  SOA治理工具(開源)， Mule Saturn  消息流監(jiān)控工具，Mule HQ  底層監(jiān)控工具。
    不過(guò)還沒(méi)試用不知道實(shí)際效果如何。

3. 遺憾的地方：

  1. 性能下降
    無(wú)論是代替XFire的CXF還是Mule 2.0，都拖得性能大大下降。
    用一個(gè)簡(jiǎn)單例子測(cè)試，Mule 1.4+XFire  : Mule 1.4 + CXF : Mule 2.0 + CXF 的每秒事務(wù)數(shù)對(duì)比是15000：10000：8000。
  2. 仍然沒(méi)有自帶的集群 ，負(fù)載均衡，流量控制實(shí)現(xiàn)。
    不像BEA、ServiceMix都使用JMS的底層，Mule使用vm queue在單一JVM的節(jié)點(diǎn)間流動(dòng)。
    我們團(tuán)隊(duì)主要用TerraCotta 在集群里同步狀態(tài)數(shù)據(jù)，流量控制與負(fù)載均衡也是自己實(shí)現(xiàn)。
  3. CXF transport 仍然使用Mule自己實(shí)現(xiàn)的Http Connector。
    CXF Standlone也是用Jetty的，看tomcat們努力的勁頭，相信誰(shuí)都能隨便實(shí)現(xiàn)一個(gè)不錯(cuò)的Http Connector。
  4. 從1.4升到2.0非常的花時(shí)間。
    估計(jì)團(tuán)隊(duì)重構(gòu)的太興奮了，從代碼到配置文件再到XFire to CXF，一些代碼級(jí)修改還沒(méi)文檔詳述。
  5. 文檔從1.4版更新到2.0版的進(jìn)度太慢，而且文檔仍然簡(jiǎn)略。
  6. 質(zhì)量仍然需要在使用中檢驗(yàn)。
    文檔說(shuō)2.0版本的比1.x版本增加了30%的單元測(cè)試用例，按理來(lái)說(shuō)項(xiàng)目質(zhì)量應(yīng)該提高了。
    但還是被我發(fā)現(xiàn)了在很重要的AbstractEntryPointResolver類里，居然有內(nèi)存泄漏，原因是用沒(méi)有重載Object的equals()函數(shù)的StringBuffer作為HashMap的key，結(jié)果map永遠(yuǎn)都在增大。
    這說(shuō)明了，開源項(xiàng)目的質(zhì)量，最終是靠一個(gè)積極使用和反饋的用戶群和一個(gè)活躍的開發(fā)團(tuán)隊(duì)，"用"出來(lái)的。