最近想学习了解下ESB 就从网上转载了下:各种ESB产品比较
ESB产品一览表包括商业和开源:
类型 | 产品 | 公司 |
商业 | Oracle Service Bus (OSB) | Oracle |
Oracle Enterprise Service Bus (ESB) | ||
WebSphere Enterprise Service Bus | IBM | |
WebSphere Message Broker | ||
WebSphere DataPower | ||
Sonic ESB | Progress | |
ActiveMatrix Service Bus | TIBCO | |
开源 | Mule | MuleSoft |
ServiceMix/FUSE ESB | Progress | |
Synapse/WSO2 ESB | WSO2 |
甲骨文的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)的优点和趋势:
ß简化开发/部署架构
去掉configuration manager,开发工具/应用可以直接和broker交互。
ß易管理
为管理员提供专用的管理工具--WebSphere Message Broker Explorer,可以管理本地和远程的broker和queue manager,同时提供了监控broker性能和消息流的功能。
ß简化开发流程
将常用的消息流场景进行了模板化,推出了基于模式的开发方式,用户只需要配置相关参数即可。提供的模式分为两类:内置(built-in)和自定义(user-defined)。
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提供了非常丰富的文档:
安装手册
开发手册
管理员手册
部署手册
…
大量的使用实例
缺点:
- 架构不够清晰
显得有点臃肿、不简洁、不够优雅 - 扩展性差
新增一个协议/transport非常困难 -
组件比较凌乱
对多种协议(HTTP,WebService,JMS,FTP,EMAIL)的支持,部分依赖于Axis2,部分依赖于synapse
相关推荐
mule esb mule esb 开发工具
文档列举了三个国产ESB的介绍:金蝶ApusicESB、锐易特软件、合众企业服务总线,希望可以对后来者提供一些建议
wso2 esb installation part 5
WEBSERVICE调试工具-ESB消息统一推送接口调用说明,内附调试工具,开发webservice接口的同学可以下载
Mule ESB 是一个轻量级的基于java的企业服务总线和集成平台, 使得开发人员可以快速,简单的连接多个应用, 使得它们可以交换数据。 Mule ESB 容易集成现有异构系统,包括:JMS, Web Services, JDBC, HTTP, 等. ESB...
Mule ESB开发工具以及相匹配的英文手册和中文手册(翻译狗充值翻译),过几天发布一些研究成果和样例
Primeton ESB®是普元基于多年对大型企业的IT建设及分布式计算和集成能力的认识和技术积累而推出的服务整合产品,是部署和实现SOA的理想工具。主要用于企业内及企业间的服务整合,通过总线形式有效改善现有系统之间...
包含ESB的总体功能说明,已经工具中的开发DEMO,有不足的地方请大家补上,
NULL 博文链接:https://huangjiateng.iteye.com/blog/2280242
金蝶中间件(ESB)采用SOA架构实现,通过灵活的配置,可实现数据的采集、加工、转换、交换等,是系统整合或共享数据中心解决方案应用较好的工具之一,值得推荐!
MQ测试工具,很好的测试工具,开发JMS,WEB SERVICE,配置消息流后可通过该工具测试!
如何使用ESB进行企业应用集成,ppt文档,描述有关于camel等ESB工具的使用。后期上传更多关于mule等的资源。
这次演练的目的是向您介绍Mule Studio(基于eclipse的集成开发工具),并帮助您轻松地创建自己的应用。 本教程本教程将引导您如何使用 Mu
NULL 博文链接:https://deadcow.iteye.com/blog/713113
NULL 博文链接:https://siye1982.iteye.com/blog/592400
文件上传功能的代码 博文链接:https://blueskylan.iteye.com/blog/250403
NULL 博文链接:https://fkueje001.iteye.com/blog/2164592
MindManager源文件 博文链接:https://lj6684.iteye.com/blog/728502