与mule 2.0抵死缠绵了两周，喜忧掺半。但只在2.0之后，mule才算真正站到了esb的起跑线上。
 
  完整的笔记见我的wiki: , 这里主要列一下实际的升级感受。
  •  
  •  
  •  
  •   《open-source esbs in action》作者文章

1. 很spring，很sca的配置文件

  • 全spring又全namespace化的配置文件，简洁而规范，在ide中有良好的提示。
    尤其是transport相关的endpoint的改进明显，原来的uri"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支持增强
     ，支持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，都拖得性能大大下降。
    用一个简单例子测试，mule 1.4 xfire  : mule 1.4 cxf : mule 2.0 cxf 的每秒事务数对比是15000：10000：8000。
  2. 仍然没有自带的 ，负载均衡，流量控制实现。
    不像bea、servicemix都使用jms的底层，mule使用vm queue在单一jvm的节点间流动。
    我们团队主要用 在集群里同步状态数据，流量控制与负载均衡也是自己实现。
  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永远都在增大。
    这说明了，开源项目的质量，最终是靠一个积极使用和反馈的用户群和一个活跃的开发团队，"用"出来的。