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,那么可能会不是很方便。

去年10月份的时候,做过一些SOA方面的调研,为公司整个架构体系迁移到SOA架构做可行情评估。

ServiceMix这个东西,文档做得太差了一点,很多东西用起来还是有些复杂。然后,它又不是一个完整的SOA实现, 它自已的定位也只是一个ESB产品。所以, 我觉得它前途不太好。

现在谈SOA这一些东西像是有些过时,不过,SOA中的一些理念还是很不错的,apache下面有一个open source的基于SCA规范实现的产品叫tunscany,其底层是基于spring扩展的,感觉做得不错,上手也比较快。