与Mule 2.0抵死缠绵了两周,喜忧掺半。但只在2.0之后,Mule才算真正
站到了ESB的起跑线上。 完整的笔记见我的Wiki:
http://wiki.springside.org.cn/display/calvin/Mule
, 这里主要列一下实际的升级感受。
- InfoQ中文站新闻
- Mule2.0的What's new
- Migrating Mule 1.x to 2.0
- Pattern Based Development with Mule 2.0
《Open-Source ESBs in Action》作者文章
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. 架构的更改
- Web Service支持增强 随着CXF作者的加入,Web Service这事实上SOA里最重要的Transport得到了加强,WSDL终于可以通过annotation准确配置。 虽然无奈,就冲这个理由就应该升级到2.0了。不是2.0太好,而是1.4太差了。
- REST支持增强 Mule RESTPack
,支持apache abdera(Atom Publish协议实现),Jersey(JSR131 RESTful WebService实现)和Restlet 三种Transport。
- 代码结构的合理化 抽象出相对稳定的org.mule.api接口包,代替原来的org.mule.umo包。 开发团队还检查调整了Mule中所有对象的定义,使其更加准确。
- 各个模块的升级 如核心MuleManager大对象拆成MuleContext and Registry,运行时Reistry支持动态加载Service,支持向OSGI进军; 如以流的方式转换处理消息。 如SEDA模型定义的细化,见后。
- 工具增强 Mule Galaxy
SOA治理工具(开源), Mule Saturn
消息流监控工具,Mule HQ
底层监控工具。 不过还没试用不知道实际效果如何。
3. 遗憾的地方:
- 性能下降 无论是代替XFire的CXF还是Mule 2.0,都拖得性能大大下降。 用一个简单例子测试,Mule 1.4+XFire : Mule 1.4 + CXF : Mule 2.0 + CXF 的每秒事务数对比是15000:10000:8000。
- 仍然没有自带的集群
,负载均衡,流量控制实现。 不像BEA、ServiceMix都使用JMS的底层,Mule使用vm queue在单一JVM的节点间流动。 我们团队主要用TerraCotta 在集群里同步状态数据,流量控制与负载均衡也是自己实现。
- CXF transport 仍然使用Mule自己实现的Http Connector。 CXF Standlone也是用Jetty的,看tomcat们努力的劲头,相信谁都能随便实现一个不错的Http Connector。
- 从1.4升到2.0非常的花时间。 估计团队重构的太兴奋了,从代码到配置文件再到XFire to CXF,一些代码级修改还没文档详述。
- 文档从1.4版更新到2.0版的进度太慢,而且文档仍然简略。
- 质量仍然需要在使用中检验。 文档说2.0版本的比1.x版本增加了30%的单元测试用例,按理来说项目质量应该提高了。 但还是被我发现了在很重要的AbstractEntryPointResolver类里,居然有内存泄漏,原因是用没有重载Object的equals()函数的StringBuffer作为HashMap的key,结果map永远都在增大。 这说明了,开源项目的质量,最终是靠一个积极使用和反馈的用户群和一个活跃的开发团队,"用"出来的。