与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
<!--{cps..0}--><connectorname="SystemStreamConnector"className="org.mule.providers.stream.SystemStreamConnector">
<properties>
<propertyname="promptMessage"value="Pleaseentersomething:"/>
<propertyname="messageDelayTime"value="1000"/>
</properties>
</connector>
改为transport特定的namespace后,IDE中清晰显示了可选的配置项。
<!--{cps..1}--><stdio:connectorname="SystemStreamConnector"promptMessage="Pleaseentersomething:"messageDelayTime="1000"/>
-
SCA的Service/Component概念。
Service/Component代替了原来注定要被遗忘的MuleDescriptor,其中Component定义业务逻辑的POJO,Service定义如何以服务的方式管理组件的配置。
在POJO中调用远程服务的Nested Router也改为了很SCA的Binding。
Component也有Component 与 PooledComponent的选项。完整的例子如下:
<!--{cps..2}--><pooled-component>
<spring-objectbean="mySpringPojo"/>
<bindinginterface="org.mule.example.loanbroker.credit.CreditAgencyService">
<outbound-endpointref="CreditAgency"/>
</binding>
<pooling-profileexhaustedAction="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永远都在增大。
这说明了,开源项目的质量,最终是靠一个积极使用和反馈的用户群和一个活跃的开发团队,"用"出来的。
分享到:
相关推荐
使用Mule_2.0基于模式的开发 使用Mule_2.0基于模式的开发 使用Mule_2.0基于模式的开发
Mule ESB 是一个轻量级的基于java的企业服务总线和集成平台, 使得开发人员可以快速,简单的连接多个应用, 使得它们可以交换数据。 Mule ESB 容易集成现有异构系统,包括:JMS, Web Services, JDBC, HTTP, 等. ESB...
文档主要介绍了Mule ESB的使用方法,并结合具体实例加深对ESB的理解,对新手很有帮助哦!
Mule ESB 项目在Linux中的部署与开发与应用案例
Mule ESB应用部署 Mule ESB应用的目录结构,配置文件说明
ESB原理及Mule ESB实践
mule,mule esb,Mule,ESB
MuleESB3.0 属于轻量级的消息框架和整合平台,mule云
MuleESB集成webservice+restful(sprintboot+mybatis+mysql)+activeMQ+javamail,五天的研究成果,集成了我所关注的点,希望有更多的朋友一起学习进步。
mule esb 项目 例子 入门
mule esb开发手册
mule esb mule esb 开发工具
MuleEsb开源框架简介.pdf
企业服务总线(Mule ESB)的研究与实现
mule esb mule esb打包手册文档
mule esb 的 简单介绍, 以及一些主要特性的介绍
MuleESB_3.0_中文教程
mule esb 3 user guider: 社区成熟,文档丰富的开源esb mule用户手册
Mule ESB实际开发例子,适合初学者。