与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永远都在增大。
    这说明了,开源项目的质量,最终是靠一个积极使用和反馈的用户群和一个活跃的开发团队,"用"出来的。