各种ESB产品比较Word下载.docx

上传人:b****1 文档编号:4077610 上传时间:2023-05-02 格式:DOCX 页数:21 大小:412.41KB
下载 相关 举报
各种ESB产品比较Word下载.docx_第1页
第1页 / 共21页
各种ESB产品比较Word下载.docx_第2页
第2页 / 共21页
各种ESB产品比较Word下载.docx_第3页
第3页 / 共21页
各种ESB产品比较Word下载.docx_第4页
第4页 / 共21页
各种ESB产品比较Word下载.docx_第5页
第5页 / 共21页
各种ESB产品比较Word下载.docx_第6页
第6页 / 共21页
各种ESB产品比较Word下载.docx_第7页
第7页 / 共21页
各种ESB产品比较Word下载.docx_第8页
第8页 / 共21页
各种ESB产品比较Word下载.docx_第9页
第9页 / 共21页
各种ESB产品比较Word下载.docx_第10页
第10页 / 共21页
各种ESB产品比较Word下载.docx_第11页
第11页 / 共21页
各种ESB产品比较Word下载.docx_第12页
第12页 / 共21页
各种ESB产品比较Word下载.docx_第13页
第13页 / 共21页
各种ESB产品比较Word下载.docx_第14页
第14页 / 共21页
各种ESB产品比较Word下载.docx_第15页
第15页 / 共21页
各种ESB产品比较Word下载.docx_第16页
第16页 / 共21页
各种ESB产品比较Word下载.docx_第17页
第17页 / 共21页
各种ESB产品比较Word下载.docx_第18页
第18页 / 共21页
各种ESB产品比较Word下载.docx_第19页
第19页 / 共21页
各种ESB产品比较Word下载.docx_第20页
第20页 / 共21页
亲,该文档总共21页,到这儿已超出免费预览范围,如果喜欢就下载吧!
下载资源
资源描述

各种ESB产品比较Word下载.docx

《各种ESB产品比较Word下载.docx》由会员分享,可在线阅读,更多相关《各种ESB产品比较Word下载.docx(21页珍藏版)》请在冰点文库上搜索。

各种ESB产品比较Word下载.docx

WebSphere 

Broker

DataPower

Sonic 

ESB

Progress

ActiveMatrix 

ServiceBus

TIBCO

开源

Mule

MuleSoft

ServiceMix/FUSEESB

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将各种协议〔,WS,JMS…〕接入的消息统一转换为SOAPMessage,再通过XqueryEngine对SOAPMessage进展XML操作。

以下场景其缺点可立即显现:

1.下的大数据包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提供了基于模式的开发,将常用的场景模式化,比如服务穿透场景。

▪开发方式模式化简化开发方式,减低了使用门槛,减少了使用中出现的概率。

▪开发方式的转变由自底向上转变为自上而下。

▪自底向上根据使用场景,逐个一步一步地开发组件,最后进展组装。

▪自上而下根据使用场景选择特定的模式,用户只需要配置参数〔比如队列名称,WSDL地址等〕即可。

▪重量级的架构传统的EAI架构,必须依赖于WMQ。

▪笨重的ESQLESQL是WMB用于处理消息流的一套特有的扩展SQL的语言,功能很丰富,语法比拟多,但学习门槛较高。

相比直接通过java方法操作消息,显得格外笨重。

开源Mule

▪社区活跃度在开源ESB中,活跃程度最高,用户量大,不断推出新版本。

▪易用性“让一切变得更简单〞是Mule的宗旨。

2次重构核心架构、推出接入云应用,消息流,基于模式的配置以与热部署;

MuleIDE3.0,将支持图元拖拽,简化开发。

▪异常处理框架异常策略设置级别:

model和service异常处理方式:

1.将异常路由到指定的目的地2.根据异常类型过滤异常,并路由到指定目的地3.设置重试次数4.当采用了事务时,可以在异常处理策略中设置当发生异常时是继续提交还是回滚事务。

▪管理性推出MuleManagementConsole〔收费〕,管理、部署和监控应用。

▪文档文档非常丰富,降低了使用门槛。

基于模式的配置

基于webserviceproxy模式的webservice的穿透场景的配置〔配置非常简单,3个属性〕<

ws:

proxyname="

muleWsProxy"

inboundAddress="

localhost:

8080"

outboundAddress="

webservice.webxml../WeatherWS.asmx"

/>

▪MuleIDE目前的IDE只提供XML级别的编辑,还不能实现图元的拖拽

▪稳定性开源项目的通病,需要在测试场景下进展验证

ServiceMix

▪无缝集成CXF,ActiveMQ,Camel和ODE因为ServiceMix,ActiveMQ,CXF,Camel都是FUSE的开源产品

▪I的优势组件BC,SE可以在任何I容器〔比限于ServiceMix〕中直接运行,复用性强

▪基于OSGi具备OSGi的优势:

模块化,热部署,易扩展

▪基于Karaf提供了非常丰富的命令,管理、部署和监控ServiceMix

问题:

▪I2.0太复杂且规X开展缓慢IT巨头Oracle,IBM投了反对票,目前只有几家小公司投支持票。

已被主流中间件厂商抛弃,没有受到业界的青睐

▪由于I的复杂性所致,其架构并非轻量级缺少IDE的支持必须手写大量的XML配置文件缺少governor的支持ServiceMix4只是借助Flex的webconsole管理OSGi的bundle学习门槛高用户文档和相关资料比拟少

▪Apache孵化新项目CamelKaraf

▪Synapse开展缓慢开展缓慢,新版本中没有增加比拟有亮点的功能特性

▪WSO2ESB开展迅速对Synapse增加了企业级特征:

1.基于WSO2的Carbon平台〔OSGi框架〕2.支持集群、负载均衡和failoverrouting3.支持流量控制和数据缓存还增加了外围产品:

1.WSO2GovernanceRegistry,服务注册产品2.WSO2ESBmanagementconsole,ESB管理控制台3.WSO2CarbonStudio,开发ESB的studio

▪基于Axis借助于Axis的特性,能非常好的支持ws规X,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非常困难

▪组件比拟凌乱对多种协议〔,WebService,JMS,FTP,EMAIL〕的支持,局部依赖于Axis2,局部依赖于synapse

企业集成对公司管理提出显著转变的需要,致力于一体化的努力通常对业务产生深远的影响,但是如果缺乏标准的集成方案,导致概念和技术学习难度增加。

集成定义:

将不同的计算机系统,公司或个人连接起来,企业集成是使不同的应用程序协同工作,产生一个统一的功能集的任务。

集成类型

▪信息门户

▪数据复制

▪共享业务功能

▪面向服务的体系结构

▪分布式业务流程

▪企业对企业集成

企业集成模式:

▪文件传输

▪共享数据库

▪远程过程调用

▪消息

基于消息的EAI:

消息集成分以下步骤实施:

▪construction消息构建

▪Channels通道

▪Endpoints端点

▪Routing路由

▪Transformation转换

▪Management管理

▪MessagingModels消息模型

▪Transactions事务

  目前有SpringIntegration,MuleESB和ApacheCamel. 

三种开源集成框架,它们都遵循企业集成模式EIP(EIP, 

.eaipatterns.),各有细微的区别。

Construction消息构建

  消息是一个数据单元格式,一个消息由一个头,属性和主体的组成发送方转换数据输出构造消息接收方重新从消息恢复成自己的数据模型。

  

(1).Spring集成的消息模型如下:

特点:

▪一个基于模型的消息中最简单的形式

▪使用泛型规定消息体类型

▪无marshaling或un-marshaling需要

  

(2).I〔Java业务集成〕的模型如下:

支持附件和XML以与安全。

  (3).ApacheCamel的消息模型:

消息交换模式(基于WSDL2.0messageexchangepatternsEXP):

消息被封装到消息交换Exchange中。

Channels消息通道

  信道是用于从发送者发送消息到接收器的网关,发送者和接收者不知道对方,实现最大化松耦合,也可以被称为管pipe

  

(1).SpringIntegration的通道是一个纯POJO模型:

  

(2).JavaBusinessIntegrationI是一个创建消息交换的工厂,支持同步或异步。

Endpoints消息端点

  一个端点是一个消息传递应用程序,它能够发送和接收消息的客户端,消息端点封装了消息系统,并与应用程序别离,也是其一局部,自定义了为特定的应用程序和任务的一般消息处理API

  

(1).SpringIntegration实现:

代码实现如下:

  消息通道最大的问题是:

通道容纳消息总会有一个容量,如果有大量消息发送到,而承受者并没有来得与消费,那么需要很大的容量保存这些消息,这是因为传统通道是一个顺序处理的模型,使用SEDA:

StagedEvent-DrivenArchitecture阶段EDA能够解决这个问题。

通过引入线程池立即响应消息处理。

  事件队列承受传入的事件,事件处理器EventHanlder处理传入的事件,线程池提供了线程功能的事件处理程序,该控制器调节资源分配和调度动态。

Routing消息路由

  消息路由器会从一个消息通道消费消息,并根据一组条件将其重新发布到不同的消息渠道.

Spring集成框架实现路由代码如下:

消息转换Transformation

   消息转换是转换一个数据格式到另一种的过滤器。

在消息处理前可以使用各种过滤器:

系统管理

   如下图中Controlbus控制总线使用由应用程序使用的数据一样的消息传递机制,参考工作流设计,别离不同的管道进展传递消息。

消息模型

   区分为Publish/Subscribe发布者/订阅者或点对点Point-to-PointModel,也就是1:

N或1:

1的模型。

存储消息

  保证一次且仅一次的消息传递,使用透明的消息客户端。

消息的事务性

   生产者将在事务上下文中发送一个或多个消息,生产者提交事务;

消费者收到的所有消息,消费者提交事务。

SOA描述了一系列创建松耦合,基于标准,保持业务一致服务的模式和最优实践,因为在描述实现和绑定之间实现别离关注,SOA提供了更高层次的灵活性。

SOA项目案例源码下载

这个项目由下面技术组成:

▪Groovy

▪Gradle

▪Springframework

▪Camel

▪CXF

该应用的场景是:

一个娱乐提供商要分决定奖励他们最忠诚的客户。

需求故事如下:

显示客户可申请的奖金:

作为客户,我希望看到根据我的频道订阅得到的奖励。

账户部门需要检查客户基于忠诚和计费状态根底上的资格量化状态。

需要提供一个RewardsService。

该服务承受输入客户某某和订阅的组合渠道。

如果客户正确,获奖励RewardsService应该返回一个根据组合的订阅的奖励列表。

下表描述了频道订阅和相关的奖励。

客户状态部门正在开发一个EligibilityService,承受账户,检查客户是否合格eligibility,rewardService和EligibilityService交互顺序图:

下面是EligibiityService 

的预期输出和rewardService的相应结果:

这个系统中主要是两个服务,rewardService和EligibiityService,rewardService的结果依赖于EligibiityService,他们之间的整合关系如如下图:

rewardService通过ApacheCxf作为Restful服务对外对客户端公开,其内部和某某部门的EligibiityService通过ApacheCamel整合。

Camel相当于一个消息系统。

展开阅读全文
相关资源
猜你喜欢
相关搜索
资源标签

当前位置:首页 > 工程科技 > 能源化工

copyright@ 2008-2023 冰点文库 网站版权所有

经营许可证编号:鄂ICP备19020893号-2