各种ESB产品比较(转)

介绍了主流商业和开源ESB的发展趋势、可借鉴的地方和其缺点：

ESB产品一览表包括商业和开源：

甲骨文的OSB

Oracle Service Bus (OSB)的架构图:

主要逻辑层：底层消息 服务总线的安全， 消息Broker，服务管理。

优点：

• 易用性
  开发工具从Web Console迁移到Eclipse，支持图形化拖拽和便于调试
  在studio上直接集成测试功能，比如studio能提供直接发送和接收SOAP,JMS消息的功能，无需借助第三方工具，如SoapUI和编写JMS客户端代码。
  
  
• 性能提升
  嵌入Oracle Coherence(企业级的内存数据网格）产品，在特定场景下为服务调用提供缓存，性能提升80%。
  Cache机制为静态响应信息提升性能。静态响应信息是指在一段时间内不会发生变化的信息，如天气预报，手机套餐，人民币汇率等，这些数据变化的周期通常是1天，1月。
  实现手段：采用比较成熟的开源Memcached或者轻量级的JCACHE
  
  
• 管控能力增强
  采用自动化的生命周期服务治理，从服务设计、开发、部署和运行期的整个服务生命周期内和Enterprise Repository产品进行自动同步，无需人工干预。

缺点：

• 依赖于Weblogic
• 重量级的统一消息格式：
  通过反编译OSB的源码，可以看出OSB将各种协议（HTTP,WS,JMS…）接入的消息统一转换为SOAP Message，再通过Xquery Engine对SOAP Message进行XML操作。
  以下场景其缺点可立即显现：
  1.HTTP下的大数据包
  2.JMS Object类型的大数据包（最新版本OSB才支持JMS Object类型，之前只支持JMS Text类型
  依据：
  对大数据包进行XML操作比较耗CPU
  将大的Object转换为XML是个繁重的操作

IBM的WMB

WebSphere Message Broker（WMB）的优点和趋势：

WMB 7.0架构：

WMB开发/部署架构的变迁:

• 去掉configuration manager，开发工具/应用可以直接和broker交互。
• Broker的配置信息保存在File中，可以不依赖于DB。
• 统一安全机制，queue managers and brokers均采用MQ queue的授权机制。V6中采用的安全机制是由Configuration Manager提供的Access Control Lists (ACLs)来管理授权的。
• 统一publish/subscribe机制，Message Broker V7直接采用WebSphere MQ V7的publish/subscribe机制，因此去掉了以前版本中使用publish/subscribe时所需的User Name Server。

WMB提供了基于模式的开发， 将常用的场景模式化，比如服务穿透场景。

不使用基于模式开发一个服务穿透的场景所需步骤：
1.创建并配置业务服务
2.创建并配置代理服务
3.在代理服务中关联业务服务

如果采用模式开发，其步骤：
1.创建服务穿透模式并配置业务服务和代理服务

优点：

• 开发方式模式化
  简化开发方式，减低了使用门槛，减少了使用中出现的概率。
• 开发方式的转变
  由自底向上转变为自上而下。
• 自底向上
  根据使用场景，逐个一步一步地开发组件，最后进行组装。
• 自上而下
  根据使用场景选择特定的模式，用户只需要配置参数（比如队列名称，WSDL地址等）即可。

缺点：

• 重量级的架构
  传统的EAI架构，必须依赖于WMQ。
• 笨重的ESQL
  ESQL是WMB用于处理消息流的一套特有的扩展SQL的语言，功能很丰富，语法比较多，但学习门槛较高。
  相比直接通过java方法操作消息，显得格外笨重。

开源Mule

优点：

• 社区活跃度
  在开源ESB中，活跃程度最高，用户量大，不断推出新版本。
• 易用性
  “让一切变得更简单”是Mule的宗旨。2次重构核心架构、推出接入云应用，消息流，基于模式的配置以及热部署；Mule IDE3.0，将支持图元拖拽，简化开发。
• 扩展性
  增加一个新协议非常简单，只需实现5个接口类即可。
  org.mule.api.transport.Connector
  org.mule.api.transport.MessageReceiver
  org.mule.api.transport.MessageDispatcher
  org.mule.api.transport.MessageDispatcherFactory
  org.mule.api.transport.MuleMessageFactory
  
  
• 异常处理框架
  异常策略设置级别:
  model和service
  异常处理方式：
  1.将异常路由到指定的目的地
  2.根据异常类型过滤异常，并路由到指定目的地
  3.设置重试次数
  4.当采用了事务时，可以在异常处理策略中设置当发生异常时是继续提交还是回滚事务。
  
  
• 管理性
  推出Mule Management Console（收费），管理、部署和监控应用。
• 文档
  文档非常丰富，降低了使用门槛。

基于模式的配置

基于web service proxy模式的web service的穿透场景的配置（配置非常简单，3个属性）
<ws:proxy name="muleWsProxy" 
inboundAddress="http://localhost:8080" 
outboundAddress="http://webservice.webxml.com.cn/WeatherWS.asmx"/>

缺点：

• 集群非常弱
  1.只能配置一个主实例和一个从实例
  2.不支持flow和基于模式的配置
  3.某些路由会丢失或者获得重复的消息
  
  
• Mule IDE
  目前的IDE只提供XML级别的编辑，还不能实现图元的拖拽
  
  
• 稳定性
  开源项目的通病，需要在测试场景下进行验证

ServiceMix

优点：

• 无缝集成CXF,ActiveMQ,Camel和ODE
  因为ServiceMix,ActiveMQ,CXF,Camel都是FUSE的开源产品
• JBI的优势
  组件BC,SE可以在任何JBI容器（比限于ServiceMix）中直接运行，复用性强
• 基于OSGi
  具备OSGi的优势：模块化，热部署，易扩展
• 基于Karaf
  提供了非常丰富的命令，管理、部署和监控ServiceMix

问题：

• JBI2.0太复杂且规范发展缓慢
  IT巨头Oracle,IBM投了反对票，目前只有几家小公司投支持票。已被主流中间件厂商抛弃,没有受到业界的青睐
  
  
• 由于JBI的复杂性所致，其架构并非轻量级
  缺少IDE的支持
  必须手写大量的XML配置文件
  缺少governor的支持
  ServiceMix4只是借助Flex的web console管理OSGi的bundle
  学习门槛高
  用户文档和相关资料比较少
  
  
• ServiceMix迁移到OSGi
  JBI2.0中增加了对OSGi的支持；
  ServiceMix4.x完全基于OSGi，
  ServiceMix3.x继续前行
  
  
• Apache孵化新项目
  Camel
  Karaf

Synapse/WSO2 ESB

• Synapse发展缓慢
  发展缓慢，新版本中没有增加比较有亮点的功能特性
  
  
• WSO2 ESB发展迅速
  对Synapse增加了企业级特征：
  1.基于WSO2的Carbon平台（OSGi框架）
  2.支持集群、负载均衡和failover routing
  3.支持流量控制和数据缓存
  还增加了外围产品：
  1. WSO2 Governance Registry，服务注册产品
  2. WSO2 ESB management console，ESB管理控制台
  3. WSO2 Carbon Studio，开发ESB的studio
  
  
• 基于Axis
  借助于Axis的特性，能非常好的支持ws规范，ws-*。因此非常适合WebService的场景。
• 基于WSO2的Carbon平台
  Carbon是WSO2的基础平台，它是一个OSGi框架，几乎WSO2的都基于它。
  
  
• 支持集群
  集群中节点间的通信框架基于Apache Tribes（组通信框架）
  相关信息持久化在内嵌的Derby中
  支持一个主节点和多个从节点failover routing
  在集群环境中，所有的请求只能被主节点接收，从节点只能作为备份节点。
  
  
• 支持流量控制
  在单个ESB实例或者集群中，可以在服务级别配置流量控制。当请求数超过阀值时，ESB将被拒绝访问。 实现机制：借助组件Throttling Mediator
• 支持数据缓存
  集群中的各个ESB实例共享缓存的数据。
  当一个请求被ESB实例1处理完后返回响应信息，当再次向ESB实例1或者集群中其他的ESB实例发送该请求时，直接从缓存中取出原来的响应信息。
  实现机制：借助组件Caching Mediator
  
  
• WSO2 Governance Registry
  开源中最优秀的服务注册项目
• WSO2 ESB management console
  创建和管理各组件（接入层、中介层和接出层）；
  图形化地方式统计系统资源（CPU,内存）；
  图像化统计ESB中各组件（接入层、中介层和接出层）接收发送消息的大小以及响应时间；
  记录系统日志、SOAP日志；图形化显示消息的流向
  
  
• 文档丰富
  WSO2提供了非常丰富的文档：
  安装手册
  开发手册
  管理员手册
  部署手册
  …
  大量的使用实例http://www.jdon.com/soa/esb.html

缺点：

• 架构不够清晰
  显得有点臃肿、不简洁、不够优雅
• 扩展性差
  新增一个协议/transport非常困难
• 组件比较凌乱
  对多种协议（HTTP,WebService，JMS,FTP,EMAIL）的支持，部分依赖于Axis2,部分依赖于synapse

SOA之企业应用集成EAI

SOA案例项目源码

http://www.jdon.com/soa/esb.html