servicemix / mule /open esb /Jboss esb 比较

请您先登录，才能继续操作

netfly 2008-07-31

servicemix/mule/open esb/xbus/openAdapter比较

老实说，这些东西我都研究过。

项目选型前，比较是第一步，呵呵。

servicemix太大了，下载下了，编译其源代码，足足用了一个上午，而servicemix涉及到的jar包，也是超级恐怖的，居然连RFID都搞进来了，我顿时倒吸了一口凉气，从头到脚，一身冰凉！

原先想servicemix基于JBI实现，集群起来也非常方便，但是看着这个超变态的庞然大物，我完全没有信心去掌控它。

一看mule源代码，小巧玲珑而不失强悍，以四两拨千斤，这才是我想要的。在MULE里面，存在UMO（universal message object），它是Mule的一个关键的组件，这个特性我也非常喜欢，以后的动态消息就好做了。

可喜的是，mule还有配置界面、管理界面，太兴奋了，给客户演示的时候，总不能演示一行行的命令吧？得有花花绿绿的的界面才行。

open esb有管理界面，也是比较庞大的东西。

Jboss esb功能是非常完备的，但是源代码就有200M，呵呵，比较头痛。

xbus是一个非常精致的esb，就是功能比较弱。

openAdapter是一个非常精致Adapter，已经在很多开源项目中使用。

kencool 2008-09-04

请问楼主，选型确定了吗？

netfly 2009-01-16

servicemix/mule/open esb/xbus/openAdapter的例子都是一堆又一堆代码，不成熟。

大概是由于开源吧，上面所有的esb的界面没什么可用性，非常不方便，而且真正做esb的话，还是选择自己开发比较好，真正的商业产品是拖拖拉拉就全搞定了。

alloyer 2009-03-13

呵呵，我们选择的也是Mule，因为我们的项目以研究为主。
如果有兴趣可以加QQ：175583318一起讨论！

yihaijunyxr 2010-07-09

我研究mule一个星期了，就一个UMO树,你觉得需一个ESB这么重量级的东西吗？不如自己写几行代码加配置来实现，mule的transport很垃圾呀！我们公司多年以来一直用的就是我写了一个封装所有常见通信协议的jar包加配置文件,现在要用mule了。不可能要很多开发人员都去研究mule吧，我以前提供一个名为call的API方法，大家填一下配置文件最多最重载个什么消息处理类，多简单！