一段关于MessageBroker与ESB区别的引用：“如果具体的把ESB产品和传统EAI里面的消息总线类产品（ActiveMQ？）做个比较，两者差异就很大了，主要有三方面。第一，ESB以SOA面向业务的哲学为基础，所以它主要是通过配置来建立 ，而不是通过编程建立;第二，ESB必须有能力在不同的协议之间建立互通机制，包括传统的消息机制（JMS）和Web服务接口（WS）;第三，除了消息(服务)代理方式外，ESB还必须为SOA服务治理提供服务的生命周期管理，而非简单的过滤、转发、路由”，服务生命周期管理，就是指从服务发布、注册、使用、推广、效益统计、升级等。
关于esb的效率问题：”ESB 采用了轻量级的分布式体系结构。当必须将程序间的每次交互转换为规范格式时，集中式的交换中心才有意义。ESB(如 IONA Artix)可以将更多的处理逻辑分配到端点上。这与大型主机和现代的分布式系统体系结构间的区别相似。从广义的角度而言，ESB最主要的技术与Web服务密不可分，如WSDL(Web服务描述语言)、UDDI(统一发现、描述和集成)、SOAP(简单对象访问协议)，这方面的技术目前处于稳定的发展阶段，而有关WS*的发展正处于一个整合和渗透不稳定过程中。此外，还有一些相关的技术正在活跃起来，比如流程方面BPEL(业务流程执行语言); 安全方面SAML(安全断言标记语言)、XML处理的XQuery;服务组件模型SCA/SDO(服务组件架构/服务数据对象)与JBI(Java Business Integration)等”。
上面这些应该是从老外翻译来的，英语文章尤其是技术类的和汉语语言习惯有着巨大差异，给我们的感觉就是英文技术文章在不必啰嗦的地方莫名其妙的啰嗦，在应该详述的地方一笔带过。
关于camel的参见：http://www.javaeye.com/wiki/interview/1858-apache-camel。jnn在谈到camel比较其他esb优势的时候主要说了两点：一是camel更轻量；二是camel支持java语法方式的Transport配置（比如从jms接收消息处理后转发cxf：from("jms://xxxx").processor(new MyProcessor()).to("cxf://xxxx")）
而对于springIntegration，spring做的事情似乎有点太多了，spring的目标似乎是围绕ioc为开发者提供spring style的更轻量级的另一选择，好比springMVC对比struts、spring持久化对比hibernate。Spring作为一种非侵略性的，轻量级的framework能很好地与SCA相融合，下面这段文字出自SCA白皮书 的原文。
SCA views Spring as a natural partner which can be used as a component implementation technology. The Spring framework can be used to create components and wire them within a module using its dependency injection capabilities. SCA may be used to extend the capabilities of Spring components by publishing Spring beans as entry points to be accessed as services by other modules as well as by providing Spring beans with service references wired to services of other modules.
以此可以看出，SCA和Spring有着密切的关系，可以相互补充。相信未来SCA和Spring会有更紧密的融合，以更大更好地发挥各自的优点。
按照alloyer的看法：Camel算是一款专注于解决消息路由的集成框架，如果你们要开发自己的ESB，可以考虑基于Camel开发。mule的部分传输器里有些bug，也就是说代码质量没有apache的项目高，mule既不支持JBI，也不支持SCA。mule是一款很轻量级的ESB，对代码的侵入可以做到非常小，如果单单从入门和开发效率上，推荐mule。如果是高负载，高标准要求的项目，推荐serviceMix
mule在sourceforge上的esb项目活跃度排名第一、mule应该是出身java四大开源体系之一的opensymphony、现在mule从mulesource改为mulesoft、也推出收费企业版了，也不知道这样和纯开源哪个能强一点。