开源ESB mule esb 社区版都有哪些强大的地方

要上ESB+工作流,给推荐个开源吧!
[问题点数:100分]
要上ESB+工作流,给推荐个开源吧!
[问题点数:100分]
不显示删除回复
显示所有回复
显示星级回复
显示得分回复
只显示楼主
2010年2月 Java大版内专家分月排行榜第二
2011年7月 Java大版内专家分月排行榜第三2010年1月 Java大版内专家分月排行榜第三2009年12月 Java大版内专家分月排行榜第三
2010年5月 Java大版内专家分月排行榜第一2010年2月 Java大版内专家分月排行榜第一2010年1月 Java大版内专家分月排行榜第一2010年1月 Oracle大版内专家分月排行榜第一2009年12月 Java大版内专家分月排行榜第一2009年12月 Oracle大版内专家分月排行榜第一
2010年2月 Oracle大版内专家分月排行榜第三
2011年12月 扩充话题大版内专家分排名第三
本帖子已过去太久远了,不再提供回复功能。新浪广告共享计划>
广告共享计划
开源ESB对比分析
Mule是一个基于Java的轻量级企业服务总线和集成平台。Mule通过Transports/Connectors与外围的异构系统连接,提供Routing(路由)、Transaction
Management(事务管理)、Transformation(转换)、Message
Broker(消息代理)、Transportation
Management(传输管理)、Security(安全)等核心模块。Mule可以单独使用,也可以架设在常用的应用服务器上。
外围系统的服务请求通过Mule
ESB的Transport接入,Mule通过Transformer进行数据的格式转换,然后经过Inbound
Router进行消息过滤(内部通过配置filter实现)后交给Mule的Component进行业务逻辑处理,处理后的结果通过Outbound
Router确定传递给哪个接收方,然后通过Transformer进行数据格式转换,通过Transport连接至接收方,传递信息。
基于J2EE1.4的企业消息总线(ESB)和消息代理(broker);
可插入的连接性,支持20多种传输协议,比如:jms、jdbc、tcp、udp、multicast、http、servlet、smtp、pop3、file、xmpp等;
支持任何传输之上的异步,同步和请求响应事件处理机制;
支持Axis或者Glue的Web Service;
灵活的部署结构,包括Client/Server, P2P, ESB 和Enterprise Service
与Spring 框架集成:可用作ESB 容器,也可以很容易的嵌入到Spring应用中;
使用基于SEDA处理模型的高度可伸缩的企业服务器;
强大的基于EIP模式的事件路由机制等。
在开源ESB中,活跃程度最高,用户量大,不断推出新版本。
基于模式的配置以及热部署;Mule IDE3.0,将支持图元拖拽,简化开发。
扩展性:增加一个新协议非常简单,只需实现5个接口类。
管理性:推出Console(收费),管理、部署和监控应用。
文档:文档非常丰富,降低了使用门槛。
集群非常弱,只能配置一个主实例和一个从实例,不支持flow和基于模式的配置
目前的IDE只提供XML级别的编辑,还不能实现图元的拖拽
稳定性:开源项目的通病,需要在测试场景下进行验证
Apache ServiceMix
ServiceMix是Apache基金会下的一个ESB总线,同时也是一个独立的JBI容器(也就是说它支持完整的JBI规范)。说它是一个独立的JBI容器,是因为它拥有自己独立的运行环境,能像应用服务器一样启动,并支持动态的热部署等,这一点则区别于CXF。
ServiceMix的容器运行环境采用内核的架构,并以Geronimo关于J2EE方面的实现为基础(当然也就支持J2EE的各方面规范,例如
安全性方面的JAAS等),所以在性能上还是较为出色的。在通信上,整合了ActiveMQ,也支持多种的通信协议,例如HTTP和JMS。同时在管理组
件上采用了JMX的管理架构,从而能够对部署在总线上的各种组件进行动态的配置和管理,或通过Web的形式,或通过JMX远程访问均可。
ServiceMix内核能够整合到所处的操作系统中,从而作为OS的对外提供的服务。区别与其他总线的是,ServiceMix还提供了自己的脚本命令
控制台,并通过一些简单命令来管理应用组件以及ServiceMix内核实例。
主要优点:
JBI的优势:组件BC,SE可以在任何JBI容器(比限于ServiceMix)中直接运行,复用性强
基于OSGi:具备OSGi的优势:模块化,热部署,易扩展
基于Karaf:提供了非常丰富的命令,管理、部署和监控ServiceMix
主要缺点:
JBI规范太复杂,已被主流中间件厂商抛弃,没有受到业界的青睐
架构复杂,由于JBI的复杂性所致,其架构并非轻量级
缺少IDE的支持,必须手写大量的XML配置文件
学习门槛高,用户文档和相关资料比较少
Apache Synapse/WSO2
由Axis构成底层支持的Web Service总线,WSO2基于Synapse。
主要优点:
借助于Axiss的特性,能非常好的支持WS及WS-*。因此非常适合Web Service的场景
支持集群,集群中节点间的通信框架基于Apache Tribes(组通信框架)
支持一个主节点和多个从节点,支持Failover Routing
在集群环境中,所有的请求只能被主节点接收,从节点只能作为备份节点。
支持流量控制,在单个ESB实例或者集群中,可以在服务级别配置流量控制。
持数据缓存,集群中的各个ESB实例共享缓存的数据。
主要缺点:
架构不够清晰,显得有点臃肿、不简洁、不够优雅
扩展性差,新增一个协议/transport非常困难
组件比较凌乱,对多种协议(HTTP,WebService,JMS,FTP,EMAIL)的支持,部分依赖于Axis2,部分依赖于synapse
ESB是JBoss社区为面向SOA而提出的一个EAI系统平台。它提供了很多EAI本身所应具有的功能,例如业务流程监控、集成开发环境、工作流用户接口、业务流程管理、分布式计算架构以及作为应用容器的功能等。可以说JBossESB在功能上是较为强大的。但相对于上面的总线而言,它的技术架构方案是最独立的。因为它除了支持J2EE标准外,对于JBI规范压根就不沾边。当然也就不存在JBI规范中的规范化消息路由、服务引擎和绑定组件了。JBossESB除了支持
Service外,还支持多种的远程调用协议,例如JMS。只是相对于ServiceMix和CXF而言,如果要对JBossESB进行扩展,可能要花费较大的时间和精力。
JBossESB相对上述的开源项目而言,一个很大的优势在于文档资料是最为丰富和完备的。所以在开发和扩展上减小了不小的阻力。它并且依托于成熟的JBoss社区,周围齐全的开源项目支持,为后期的平台扩展提供了丰富的选择空间。
UltraESB 是一个开源的企业服务总线 ESB
项目,特点是高性能和易用。提供一个强大而具备良好伸缩性的架构,在性能方面表现优异,根据性能测试数据可以看到,其性能优于常见Mule和WSO2,对于TPS数据可以达到3000TPS以上。而且轻量级,易于使用和管理。
支持传输层:
&&& HTTP/S
(POP3/IMAP/SMTP)
File/SFTP/FTP/FTPS/Samba
(Scheduled Job)
&&& MLLP/S
支持协议:
FastInfoset
&&& Protocol
OpenESB是Sun公司提出来的开源ESB项目,所以对JBI规范的支持程度就不用多说了。而GlassFish
ESB则是将OpenESB的核心运行环境与GlassFish应用服务器以及NetBean的集成开发环境整合在一起的有一个ESB项目,当然其中还包含了一些OpenESB中已有的组件(子集)。
在OpenESB中提供了能够支持WS-BPEL2.0的引擎。但是现在这个组件支持WSDL1.1,暂不支持WSDL2.0。而且这个引擎要依托与NetBean集成开发平台,起码只能得到基于NetBean的相应开发包和组件包。但是这个组件对BPEL提供了强大的支持,其中包括支持端点状态的监控、支持多线程执行、业务流程的调试、系统错误的可靠性恢复中各个业务流程实例的数据库持久化以及负载均衡等。
已投稿到:
以上网友发言只代表其个人观点,不代表新浪网的观点或立场。各种ESB产品比较 -解道Jdon
& & & &&& & &
  介绍了主流商业和开源ESB的发展趋势、可借鉴的地方和其缺点:
&&&&& 主要介绍:
&&&&& Oracle Service Bus
&&&&& WebSphere Message Broker
&&&&& Mule
&&&&& ServiceMix/FUSE ESB
&&&&& Synapse/WSO2 ESB
ESB产品一览表包括商业和开源:
Oracle Service Bus (OSB)
Oracle Enterprise Service Bus (ESB)
WebSphere Enterprise Service Bus
WebSphere Message Broker
WebSphere DataPower
ActiveMatrix& Service Bus
ServiceMix/FUSE ESB
Synapse/WSO2 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是个繁重的操作
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方法操作消息,显得格外笨重。
社区活跃度
在开源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=&.cn/WeatherWS.asmx&/&
集群非常弱
1.只能配置一个主实例和一个从实例
2.不支持flow和基于模式的配置
3.某些路由会丢失或者获得重复的消息
目前的IDE只提供XML级别的编辑,还不能实现图元的拖拽
开源项目的通病,需要在测试场景下进行验证
ServiceMix
无缝集成CXF,ActiveMQ,Camel和ODE
因为ServiceMix,ActiveMQ,CXF,Camel都是FUSE的开源产品
组件BC,SE可以在任何JBI容器(比限于ServiceMix)中直接运行,复用性强
具备OSGi的优势:模块化,热部署,易扩展
提供了非常丰富的命令,管理、部署和监控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孵化新项目
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的特性,能非常好的支持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
| 网站地图 | 设为首页当前访客身份:游客 [
当前位置:
&& ESB企业服务总线
共有21款 ESB企业服务总线开源软件,第1页
ESB全称为Enterprise Service Bus,即企业服务总线。它是传统中间件技术与XML、Web服务等技术结合的产物。ESB提供了网络中最基本的连接中枢,是构筑企业神经系统的必要元素。ESB的出现改变了传统的软件架构,可以提供比传统中间件产品更为廉价的解决方案,同时它还可以消除不同应用之间的技术差异,让不同的应用服务器协调运作,实现了不同服务之间的通信和整合。从功能上看,ESB提供了事件驱动和文档导向的处理模式,以及分布式的运行管理机制,它支持基于内容的路由和过滤,具备了复杂数据的传输能力,并可以提供一系列的标准接口。
软件过滤:
所有编程语言
Objective-C
JavaScript
TypeScript
ActionScript
Delphi/Pascal
Sliverlight
所有操作系统
iPhone/iPad/iPod
Windows Phone/Mobile
Firefox OS
ZBUS = MQ + RPC + PROXY
支持消息队列, 发布订阅, RPC, 代理(TCP/HTTP/DMZ) 亿级消息堆积能力、支持HA高可用 超轻量级,单个Jar包无依赖 ~250K
丰富的API--JAVA/C/C++/C#/Python/Node.JS多语言接入 目前zbus总线在国信证券、前海股权交易中心...
最近更新:
发布于 6个月前
Jet 是一个用于 Web 的轻量级和实时的消息总线。支持浏览器和 Node.js node-jet,提供 Lua 版本 lua-jet 和基于 Arduino 的版本 Arduino-Jet。 示例代码: var jet = require('node-jet');
var peer = new jet.Peer({
url: 'ws://jet.nodejit...
最近更新:
发布于 10个月前
Zato 是一个用 Python 编写的开源 ESB 和应用服务器。按照设计,它用于构建后端应用程序(即仅是API)和在SOA 中整合系统。 Zato 的目标用户是使用 Python 或者 Ruby 和 PHP 等其它动态语言的开发人员,或者是那些考虑在工作中尝试动态语言的技术团队,后者...
Mule是一个企业服务总线(ESB)消息框架.它的主要特性包括: 1.基于J2EE1.4的企业消息总线(ESB)和消息代理(broker). 2.可插入的连接性:比如Jms,jdbc,tcp,udp,multicast,http,servlet,smtp,pop3, file,xmpp等. 3.支持任何传输之上的异步,同步和请求响应事件处...
最近更新:
发布于 1年前
ESB是SOA基础架构的一部分,而SOA并不是一种简单的技术或产品。它是一种设计风格,包含无关于实际技术的多个方面。JBossESB能够把抽象的 SOA设计映射成具体实现。它特性包括:支持大部分通知框架,Transport支持包括JMS (JBossMQ,JBoss Messaging,Oracl...
最近更新:
发布于 9个月前
OpenESB (NetBeans ESB)项目实现了一个运行期企业服务总线(Enterprise Service Bus:ESB)使用JBI(Java业务集成)作为核心基础。OpenESB可以让你集成企业应用与Web Service松散地连 接成复合的应用程序。这使得你可以无缝地组合与拆解该复合应用程序,并认识到...
最近更新:
发布于 7年前
UltraESB 是一个开源的企业服务总线 ESB 项目,特点是高性能和易用。提供一个强大而具备良好伸缩性的架构,在性能方面表现优异,而且轻量级,易于使用和管理。 支持传输层: HTTP/S JMS Email (POP3/IMAP/SMTP) AMQP File/SFTP/FTP/FTPS/Samba Timer (Sch...
最近更新:
发布于 3年前
WSO2 ESB是一套轻量级,以XML和Web service为核心的ESB(Enterprise Service Bus)。基于Apache Synapse和Apache Axis2项目构建。它支持connectivity,transformation,mediation和Web service交互管理。...
最近更新:
发布于 3年前
Fuse ESB (现已改名 JBoss Fuse)核心是一个ESB产品,你可以把开发使用OSGi Bundle封装后的WebService或OSGi作为服务直接部署到ESB,但更多的应用模式是纯粹将其作为一个总线,对其它系统所曝露出的服务进行 绑定集成(binding component)。应用系统之间...
最近更新:
发布于 3年前
MassTransit 是一个 .NET 的分布式应用开发框架。
ServiceMix是一个建立在JBI (JSR 208)语法规则和APIs上的开源ESB(Enterprise Service Bus:企业服务总线)。它包括一个完整的JBI容器,其主要是由标准化信息服务和路由器,JBI管理MBeans,JBI配置单元和Ant任务(安装组 件和管理容器)组成。新版本中集成了B...
Apache Synapse一个易于使用、轻量级的XML与Web Services管理和集成中间件。可用于搭建SOA和ESB的基础平台。Apache Synapse支持多种标准包括:XML、XSLT、XQuery、XPath、SOAP、POX/REST、HTTP/S、JMS、、FTP、 SFTP、WS-RM、WS-Addressing、SMTP等Synapse...
Shuttle(飞梭)服务总线是国外的一个免费的.NET开源软件项目,它为开发面向消息的事件驱动架构(EDA)系统提供了一种新方法。尽管它仍处于起步阶段,不过它已被应用于生产系统之中。 相关要点如下: 用C#(基于.NET 3.5)开发而成 核心功能不依赖于任何第...
ChainBuilder ESB是一个新的Java业务集成( JBI )兼容的开源解决方案,用于面向服务的架构( SOA )的环境。 ChainBuilder ESB的组成部分是用Java编写的,并轻松配置,通过图形用户界面插入流行的Eclipse开发平台。 ChainBuilder的ESB的图形组件流编辑器创...
SwitchYard 是一个轻量级的服务交付框架,提供完整的开发、发布和管理面向服务应用程序的全生命周期。 没错 SwtichYard 有点像 ESB 企业服务总线,是 ESB 的一种。 主要特性有: 通过 CDI 的 Bean 服务 集成工作流 声明转换 Drools 实现的决策服务 集成 Ap...
最近更新:
发布于 10个月前
Petals ESB是一个开源的ESB平台,适用于大型SOA架构。设计运行在多台分布式服务器之上并完全兼容主要工业标准包括:JBI、SCA、BPEL和WSDL 等。支持多种连接器:WSDL、SOAP、REST、POP、SMTP、IMAP、EJB、JDBC等。易于使用集成Eclipse开发环境 (Petals St...
最近更新:
发布于 5年前
JFinal极简zbus插件, 该插件具有以下特点: 1)简化设计,去掉了异步发送,仅支持同步发送。
2)信息发送/接收支持泛型,类型安全。 3)可直接发送/接收JFinal中特有的Model对象和Record对象。 导入dist目录下的jfinal-zbus-3.1.0.jar 同时还需要导入...
最近更新:
发布于 7个月前
Celtix提供了一个运行期Java企业服务总线和一组可扩展的API.通过使用一个基于标准的,面向服务的体系来简化商业与技术组件的构建,集成和灵活重复使用。
AEAI ESB 应用集成平台为数通畅联的核心产品,本着分享传递的理念,数通畅联将ESB管理控制台项目开源,目的在于满足客户与伙伴的OEM需求,以及为广大IT爱好者的集成工具提供多一种选择,多一种便利。希望通过开源中国,分享该产品,在交流学习中,使更多的...
最近更新:
发布于 5个月前
Petals Service Platform 是ObjectWeb的项目,致力于提供一个Java (商标)业务集成( JBI )的平台,提供轻巧,包装一体化解决方案的基础上,符合JSR - 208规范,具有高度集中的分布和集群。花瓣利用若干ObjectWeb的项目,如分形和JORAM ,以提供一个灵活...现在有哪些比较好的开源ESB产品?BPM怎么同ESB产品集成?
好像Bonita Open Solution还没有做和某个ESB产品集成的connector. BPM与ESB集成,有哪些典型应用场景?
按投票排序
开源ESB比较出名的有mule和servicemix(内部是支持EIP的camel),还有SpringIntegration。几个东西的比较有很多人在做,比如:mule目前可以与开源BPM引擎activiti进行连接,印象里也有与JBPM和bonita的connector,可以去mule网站上去找一下。activiti现在支持与mule和camel的集成。通过与这两个ESB的集成,扩大了BPM的使用范围,可以把流程中的task集成到各种外部应用上。集成的主要方式是:1、流程调用外部应用,一般是把流程数据发送到ESB提供给BPM的接口上,比如使用mule task发送到vm connector上。&sendTask id="processOrderAndTweet" activiti:type="mule"&
&extensionElements&
&activiti:field name="endpointUrl"&
&activiti:string&vm://tweetFromActiviti&/activiti:string&
&/activiti:field&
&activiti:field name="language"&
&activiti:string&juel&/activiti:string&
&/activiti:field&
&activiti:field name="payloadExpression"&
&activiti:string&I have just purchased a #{productName} &/activiti:string&
&/activiti:field&
&activiti:field name="resultVariable"&
&activiti:string&theVariable&/activiti:string&
&/activiti:field&
&/extensionElements&
&/sendTask&
2、外部应用处理完后调用流程,现在activiti是采用设置流程variable并signal的方式。&flow name="approve-flow"&
&jms:inbound-endpoint queue="approveQueue" /&
&activiti:set-variable executionIdExpression="#[groovy:payload.id]"
variableExpression="#[string:approvedBy]" valueExpression="#[header:INBOUND:username]" /&
&activiti:signal executionIdExpression="#[groovy:payload.id]" /&
参见:更多例子:activiti与camel集成的相关链接:不过,感觉现在流程与外部集成的方式不怎么便捷,也不怎么优雅。至少在开源产品上如此,商业产品如何不太清楚。ESB与BPM的集成,其实主要是两种场景:一是BPM需要将流程用各种异构系统来实现,也就是说由系统来实现各种activity或者叫task。这样就需要集成中间件来实现流程引擎与信息系统的连接,比如目前activiti使用mule就是这个用意。另外一种是从集成角度考虑:对于一些复杂的集成场景,单纯的用集成配置中的一些模式已经不够用,特别是在存在并行操作或等待状态的持久化的情况下,David Chapell在他的ESB一书中的第七章对itinerary-based integration与orchestration-based integration进行过对比来说明哪些情况下适合使用流程orchestration。BPEL4WS就是用流程编排的方式来实现web service之间的集成。目前很多BPM也支持BPEL4WS。再进一步的,orchestration关注的是对于进入一个channel的消息的处理方法。而在实际的集成过程中,集成场景未必是简单的request-reply,可能涉及复杂的会话(conversation)。此时,需要在宏观上对conversation进行描述。这个过程在SOA中称为choreography。在实现层面上,一些global的集成约束,比如消息之间的时间间隔或者顺序关系,需要相应的实现在ESB的配置中。这个方面似乎还没有充分的被探索关于conversation,EAI patterns的作者Hohpe认为是EAI的下一个环节。他把enterprise中的集成分为messaging、conversation、process和event processing:
mule和servicemix前面已经有人介绍。最近我想研究的是JBoss ESB,还有就是eBay开源SOA平台Turmeric。对于BPM和ESB集成,建议了解下最新的BPMN2.0规范,可以讲靠谱的还是BPEL和ESB集成,ESB提供原子服务,BPEL对服务进行编排和组合。
ESB产品本身的最主要产品是集成连接,可以根据技术型的方式,如HTTP,WS,JDBC,MQ,JMS等等。BPM所编排的服务若来自于某个现有系统,而该系统又无法和BPM产品直接整合时,或直接整合在技术上需要做许多事情时,就可以使用ESB在中间搭建连接的桥梁。Bonita Open Solution若只是上面列举的任何技术形式的连接,就可以和ESB产品集成。
Apache ServiceMix
ESB目前选择mule,BPM选择activiti
在ESB中集成workflow还是有一些不错的用例场景的,比如数据的validation, 当出现无效数据时,可以发给工作流,交给特定人员去fix, 又或者由MQ生成tasklist 然后触发工作流来消费这些message
ESB选择mule
如果已经有了bpm,esb一般只作为服务注册以消除点对点集成,对用户甚至是bpm都可以是透明的,大家只要知道有个web服务即可,至于这个web服务是直接暴露在业务系统的进程中,还是统一注册在esb上,那都是架构管理上的事儿,一般不必过于关注。 而实际上,现在大部分的esb包含了部分的bpm功能(人工活动除外),甚至对于要求不太高的信息系统,基于esb做一些包装,即可满足bpm的大部分功能。 开源的esb拿来玩玩还行,不建议真的在实际项目中使用,改造工作太大,还不如自己开发一个,或者买个商业的。
已有帐号?
社交帐号登录
无法登录?
社交帐号登录

我要回帖

更多关于 mule esb 社区版下载 的文章

 

随机推荐