市场主流ESB的产品比较较全.docx
《市场主流ESB的产品比较较全.docx》由会员分享，可在线阅读，更多相关《市场主流ESB的产品比较较全.docx（11页珍藏版）》请在冰点文库上搜索。
市场主流ESB的产品比较较全
综述
介绍了主流商业和开源ESB的发展趋势、可借鉴的地方和其缺点：
ESB产品一览表包括商业和开源：
类型
产品
公司
商业
OracleServiceBus（OSB）
Oracle
OracleEnterpriseServiceBus（ESB）
WebSphereEnterpriseServiceBus
IBM
WebSphere?
Message?
Broker
WebSphere?
DataPower
Sonic?
ESB
Progress
ActiveMatrix?
ServiceBus
TIBCO
开源
Mule
MuleSoft
ServiceMix/FUSEESB
Progress
Synapse/WSO2ESB
WSO2
甲骨文的OSB
OracleServiceBus（OSB）的架构图:
主要逻辑层：
底层消息服务总线的安全，消息Broker，服务管理。
优点：
▪易用性
▪开发工具从WebConsole迁移到Eclipse，支持图形化拖拽和便于调试
▪在studio上直接集成测试功能，比如studio能提供直接发送和接收SOAP,JMS消息的功能，无需借助第三方工具，如SoapUI和编写JMS客户端代码。
▪性能提升
▪嵌入OracleCoherence（企业级的内存数据网格）产品，在特定场景下为服务调用提供缓存，性能提升80%。
▪Cache机制为静态响应信息提升性能。
静态响应信息是指在一段时间内不会发生变化的信息，如天气预报，手机套餐，人民币汇率等，这些数据变化的周期通常是1天，1月。
▪实现手段：
采用比较成熟的开源Memcached或者轻量级的JCACHE
▪管控能力增强
▪采用自动化的生命周期服务治理，从服务设计、开发、部署和运行期的整个服务生命周期内和EnterpriseRepository产品进行自动同步，无需人工干预。
缺点：
▪依赖于Weblogic
▪重量级的统一消息格式：
▪通过反编译OSB的源码，可以看出OSB将各种协议（HTTP,WS,JMS…）接入的消息统一转换为SOAPMessage，再通过XqueryEngine对SOAPMessage进行XML操作。
▪以下场景其缺点可立即显现：
▪1.HTTP下的大数据包
▪2.JMSObject类型的大数据包（最新版本OSB才支持JMSObject类型，之前只支持JMSText类型
▪依据：
▪对大数据包进行XML操作比较耗CPU
▪将大的Object转换为XML是个繁重的操作
IBM的WMB
WebSphereMessageBroker（WMB）的优点和趋势：
?
简化开发/部署架构
?
去掉configurationmanager，开发工具/应用可以直接和broker交互。
?
易管理
?
为管理员提供专用的管理工具--WebSphereMessageBrokerExplorer，可以管理本地和远程的broker和queuemanager，同时提供了监控broker性能和消息流的功能。
?
简化开发流程
?
?
将常用的消息流场景进行了模板化，推出了基于模式的开发方式，用户只需要配置相关参数即可。
提供的模式分为两类：
内置（built-in）和自定义（user-defined）。
WMB7.0架构：
WMB开发/部署架构的变迁:
▪去掉configurationmanager，开发工具/应用可以直接和broker交互。
▪Broker的配置信息保存在File中，可以不依赖于DB。
▪统一安全机制，queuemanagersandbrokers均采用MQqueue的授权机制。
V6中采用的安全机制是由ConfigurationManager提供的AccessControlLists（ACLs）来管理授权的。
▪统一publish/subscribe机制，MessageBrokerV7直接采用WebSphereMQV7的publish/subscribe机制，因此去掉了以前版本中使用publish/subscribe时所需的UserNameServer。
WMB提供了基于模式的开发，将常用的场景模式化，比如服务穿透场景。
不使用基于模式开发一个服务穿透的场景所需步骤：
1.创建并配置业务服务
2.创建并配置代理服务
3.在代理服务中关联业务服务
如果采用模式开发，其步骤：
1.创建服务穿透模式并配置业务服务和代理服务
优点：
▪开发方式模式化
▪简化开发方式，减低了使用门槛，减少了使用中出现的概率。
▪开发方式的转变
▪由自底向上转变为自上而下。
▪自底向上
▪根据使用场景，逐个一步一步地开发组件，最后进行组装。
▪自上而下
▪根据使用场景选择特定的模式，用户只需要配置参数（比如队列名称，WSDL地址等）即可。
缺点：
▪重量级的架构
▪传统的EAI架构，必须依赖于WMQ。
▪笨重的ESQL
▪ESQL是WMB用于处理消息流的一套特有的扩展SQL的语言，功能很丰富，语法比较多，但学习门槛较高。
▪相比直接通过java方法操作消息，显得格外笨重。
开源Mule
优点：
▪社区活跃度
▪在开源ESB中，活跃程度最高，用户量大，不断推出新版本。
▪易用性
▪“让一切变得更简单”是Mule的宗旨。
2次重构核心架构、推出接入云应用，消息流，基于模式的配置以及热部署；MuleIDE3.0，将支持图元拖拽，简化开发。
▪扩展性
▪增加一个新协议非常简单，只需实现5个接口类即可。
▪
▪
▪
▪
▪
▪异常处理框架
▪异常策略设置级别:
▪model和service
▪异常处理方式：
▪1.将异常路由到指定的目的地
▪2.根据异常类型过滤异常，并路由到指定目的地
▪3.设置重试次数
▪4.当采用了事务时，可以在异常处理策略中设置当发生异常时是继续提交还是回滚事务。
▪管理性
▪推出MuleManagementConsole（收费），管理、部署和监控应用。
▪文档
▪文档非常丰富，降低了使用门槛。
基于模式的配置
基于webserviceproxy模式的webservice的穿透场景的配置（配置非常简单，3个属性）
proxyname="muleWsProxy"?
inboundAddress
缺点：
▪集群非常弱
▪1.只能配置一个主实例和一个从实例
▪2.不支持flow和基于模式的配置
▪3.某些路由会丢失或者获得重复的消息
▪MuleIDE
▪目前的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的webconsole管理OSGi的bundle
▪学习门槛高
▪用户文档和相关资料比较少
▪ServiceMix迁移到OSGi
▪JBI2.0中增加了对OSGi的支持；
▪ServiceMix4.x完全基于OSGi，
▪ServiceMix3.x继续前行
▪Apache孵化新项目
▪Camel
▪Karaf
Synapse/WSO2ESB
▪Synapse发展缓慢
▪发展缓慢，新版本中没有增加比较有亮点的功能特性
▪WSO2ESB发展迅速
▪对Synapse增加了企业级特征：
▪1.基于WSO2的Carbon平台（OSGi框架）
▪2.支持集群、负载均衡和failoverrouting
▪3.支持流量控制和数据缓存
▪还增加了外围产品：
▪1.WSO2GovernanceRegistry，服务注册产品
▪2.WSO2ESBmanagementconsole，ESB管理控制台
▪3.WSO2CarbonStudio，开发ESB的studio
▪基于Axis
▪借助于Axis的特性，能非常好的支持ws规范，ws-*。
因此非常适合WebService的场景。
▪基于WSO2的Carbon平台
▪Carbon是WSO2的基础平台，它是一个OSGi框架，几乎WSO2的都基于它。
▪支持集群
▪集群中节点间的通信框架基于ApacheTribes（组通信框架）
▪相关信息持久化在内嵌的Derby中
▪支持一个主节点和多个从节点failoverrouting
▪在集群环境中，所有的请求只能被主节点接收，从节点只能作为备份节点。
▪支持流量控制
▪在单个ESB实例或者集群中，可以在服务级别配置流量控制。
当请求数超过阀值时，ESB将被拒绝访问。
实现机制：
借助组件ThrottlingMediator
▪支持数据缓存
▪集群中的各个ESB实例共享缓存的数据。
▪当一个请求被ESB实例1处理完后返回响应信息，当再次向ESB实例1或者集群中其他的ESB实例发送该请求时，直接从缓存中取出原来的响应信息。
▪实现机制：
借助组件CachingMediator
▪WSO2GovernanceRegistry
▪开源中最优秀的服务注册项目
▪WSO2ESBmanagementconsole
▪创建和管理各组件（接入层、中介层和接出层）；
▪图形化地方式统计系统资源（CPU,内存）；
▪图像化统计ESB中各组件（接入层、中介层和接出层）接收发送消息的大小以及响应时间；
▪记录系统日志、SOAP日志；图形化显示消息的流向
▪文档丰富
▪WSO2提供了非常丰富的文档：
▪安装手册
▪开发手册
▪管理员手册
▪部署手册
▪…
▪大量的使用实例
缺点：
▪架构不够清晰
▪显得有点臃肿、不简洁、不够优雅
▪扩展性差
▪新增一个协议/transport非常困难
▪组件比较凌乱
▪对多种协议（HTTP,WebService，JMS,FTP,EMAIL）的支持，部分依赖于Axis2,部分依赖于synapse
普元ESB
国内非常成熟的ESB产品，在电信、金融领域大量应用，性能卓越。
真正意义上实现了服务从开发、部署、执行、监控、优化的全周期管理！
•可靠的总线架构，可快速部署并支撑业务系统。
•业务化的服务注册与管理，并可实时监控接口服务调用情况。
•强大的环境融合与协议适配能力。
优点：
高性能：
根据具体业务，可实现个性化的流量控制、IP拦截、报文校验等特性。
在中国电信OIP集成平台中，支撑了以CRM、BOSS为核心的50多个应用系统。
在上海移动ESB集成平台中，目前日均交易量9000万笔，峰值TPS达到了6000。
高扩展：
开放的API接口，使得ESB产品更加容易和企业内部现有的系统有机的融合在一起，譬如：
与现有安全系统的融合、与现有IT网管系统的融合
业务化：
丰富的QoS质量指标，完备的日志信息和方便的进程管理机制，同时还可以依托服务运行的轨迹信息形成跨部门的业务流程的监控。
高可靠：
采用取了SEDA、NIO等业界先进的技术以及松散的集群部署方式来保障ESB整体基础设施以及关键服务的可靠性，从而提高了ESB的容错性
缺点：
对复杂报文处理的支持不佳。
采用SEDA支持高性能配置，但性能调优比较复杂，需要掌握专业的技能
采用Studio的服务开发、调优、部署方式，不能支持web浏览器
升级会员 