ServiceMix vs Mule ESB
Chris Hane发表一篇博文:ServiceMix vs Mule ESB,从自己的体会对ServiceMix和Mule进行了使用上比较。
作者Chris Hane需求目标是实现一个简单的服务:接受一个文件的提交POST,然后做一些简单转换后保存在文件系统中。就这一个简单的事情,作者使用ServiceMix花费了一天班时间,又是读源码,又是google搜索,都没有搞定,
作者认为:ServiceMix网站上很多文档对于新用户来说还有待改进。
而Mule ESB文档是完善的,按照指示,在10分钟内运行案例,然后花了很多时间阅读案例和教程,4个小时后作者能够创建了自己第一个服务,当然他认为他可以做得更快,但是花了很多时间搞清楚其原理。
Mule提供IDE插件,这样能够在Eclipse中调试运行Mule应用,非常方便。
该作者是没有Spring背景经验,所以对基于Spring整合的ServiceMix无从下手,有人在其博客留言,说:90%场合Spring整合比Mule更干净更简单,只有10%场合适合Mule,我不仅有疑问,象博客作者这样毫无Spring背景的人,那就不是简单容易了,所以,这里有一个背景前提条件。
博客作者认为:Spring整合更适合在一个应用内部的消息整合,而Mule则侧重于不同系统之间以接口整合。
有人认为,对于作者这么一个简单需求,使用Apache Camel,定义一个Apache Camel route的XML,然后直接部署到ServiceMix 4容器中就可以。我个人比较惊叹,这么一个简单的服务,动用Apache两个开源项目,是Apache开源太专业了,还是现在用户太笨了呢?
有人建议使用JBoss ESB,不管是作者简单应用和复杂应用都适合,JBoss ESB都提供Eclipse插件,JBoss ESB把服务组合成一个职责链模式chain of responsibilities pattern ,这带来一个out-of-the-box解决方案,当然该建议者是JBoss ESB架构师,不过我对职责链模式一直有一个性能上担心,不知JBoss ESB如何克服的?
还有人提出基于JMX的jmx-agent和mx4j implementation来实现作者的要求,这也是一个思路吧。
总结:从以上大家提议来看,SOA/ESB与软件快速开发之间还存在距离,现在的ESB解决方案都是基于已有的软件架构,如果你想从零开始就使用ESB,那么可能会不是很方便。