《（BPM业务流程管理)jbpm和shark工作流引擎对比》由会员分享，可在线阅读，更多相关《（BPM业务流程管理)jbpm和shark工作流引擎对比（8页珍藏版）》请在金锄头文库上搜索。
1、基于现状各方面情况，我们讨论到下一版本平台的工作子系统在shark和jbpm中做一个选择，前面我花时间学习了shark各方面的资料，现就Jbpm和Shark工作流各自特点列出比较（欢迎各位提出自己的见解和完善意见）：Xpdl:xml process definition language.Bpel:Business Process execution language.Jpdl:JBoss Jpbm Process definition language.考察角度：稳定性，易用性，灵活性，可监管，扩展性，可维护性，发展趋势。SharkJbpm持久层Shark自己的一个ORM的方案DODS，基本
2、上没有什么人来使用DODS，也没有人了解它，表现也非常一般.可以配置jdbc连接.支持当前大多数流行的数据库.可以访问LDAP用户定义数据.Jbpm3种使用的是开源框架Hibernate3, Hibernate是目前Java领域最好的一种数据持久层解决方案，Jbpm将数据的管理职能分离出去，自己专注于商务逻辑的处理。可以配置jdbc连接参数.可以配置使用web容器的连接池.支持当前大多数流行的数据库.安装部署可以独立部署.可以和其他应用集成.自带web管理工具.可以独立部署.可以和其他应用集成.自带web管理工具.针对不同数据库有一个对应的初始化脚本文件.流程设计器使用的Xpdl语言定义流程.
3、有一个Jawe来图形化定义流程.Jawe功能图形化功能相对较强.可以编辑活动变量，流程逻辑控制属性.需要改造设计器和平台的权限模型结合.已有一个Flash版web设计器,感觉不是很直观好用.引入UML泳道使流程用户模型更加清晰，但对于同一用户在多阶段都参与的流程难得画好.使用Jpdl流程定义语言.有一个Eclipse流程定义插件.插件图形化功能较弱，只能绘制流程流转的基本元素.对活动属性和流程逻辑控制需要手工编辑Jpdl文件.没有设计插件的源代码，要和当前平台权限模型结合需要手工编辑Jpdl文件.初步思路是自己来开发一个web设计器.有泳道概念，但泳道用于工作任务的处理者属性，不体现在流程图绘
4、制，流程图结构不会受到用户泳道的约束.定义语言遵循WfMC规范.内容结构是按元素类型组织的.Xpdl：制定的描述业务流程控制流的XML格式规范, 格式复杂.与具体语言无关，不灵活.可以嵌入脚本控制语言.宣传称也遵守WfMC规范.内容结构和设计图流转顺序更加一致。Jpdl：直观易懂，可以手工修改.内容按结构保存在数据库中.方便扩展自己的逻辑控制内容.可嵌入一个简单自定义的脚本控制语言.表单定制通过活动的变量来定制处理表单.可以通过变量来定制处理表单.异构系统交互Shark可以开CORBA的服务.需要借助java的其他远程访问框架.支持EJB.可改造性体系和功能最为复杂.秉承“模块化”的思想，比较
5、容易扩展.Xpdl文件保存在大字段中，难于分析扩展.活动事件模型非常容易扩展自己的控制逻辑.Jpdl文件被分析好结构化地存储在各个数据表中，容易根据需求扩展出特定的活动模型，如多人会签活动，超时自动处理活动，多人选择处理活动.很方便进行二次开发扩展升级.支持文档公司积累文档丰富.积累文档丰富.网上具有大量的共享技术资源.Jpdl流程定义说明文档很好用.运行稳定性比较稳定.比较稳定.可维护性公司对shark有很多的积累.熟悉的人员有露明，明华等.引擎开源.设计器代码开源.DODS开源吗，熟悉它的人非常少.熟悉的人员有宏伟，文力.对3.2版本流程定义和控制模型幽闭叫深入的研究.比较容易维护满足业务
6、需求.引擎开源.设计器插件不开源.Hibernat开源，熟悉的技术人员多.使用简单，易上手，源代码也易读.可配置性各模块按接口调用，可以替换模块的实现，非常灵活.可以配置数据库连接和日志输出等.没有那么灵活.SharkJbpm体系结构结构清晰，参见附图1.Activity-Assignment-User.工作列表产生于Activity- Assignment.结构清晰，参加附图2.Node-Task-User.工作列表产生于Node-Task.活动和流转模型流程包.活动（定义任务和处理页面）.块活动.子流程活动.工具活动（自动执行一些后台功能）.路由结点.转移.条件转移.否则转移.例外转移.（
7、根据活动或转移里定义的条件选择路径流转）没有包概念.任务结点（可以定义多个任务，每个任务有自己的处理页面和处理人员）=TaskNode.状态结点（执行会中断，直到外部触发一个信号signal，方便实现分布式系统）=State.自动结点(执行不会中断，自动继续流转）=Node.决策结点（自动）=Decision.超结点（相当于块结点）=SuperNode.子流程结点=ProcessNode.分支和汇聚结点=ForkNode和JoinNode.转移（每个转移有一个名字，引擎的Token根据名字控制转移路径，路径命名使流程图的业务逻辑更加直观）=Transition.可用控制机制包，流程，活动可以定
8、义属性控制变量.流程实例挂起，恢复，终止，放弃.活动实例的接收，完成，挂起，恢复，终止，放弃，改派.改造后实现工作的回退，收回?流程，结点，任务可以定义属性控制变量.变量分为流程级别和任务级别，具备不同可见性范围.Action,Handle等也可以控制变量.每个结点可以定义事件（进入，退出，异常，超时等）处理逻辑(Event-Action模型).转移发生时也可以定义事件的处理逻辑.工作任务生成可以定义自己的控制逻辑.超时事件.流程实例挂起，恢复，终止，放弃.任务实例的接收，完成，挂起，恢复，终止，放弃，改派.改造实现任务的回退，收回(需要研究确认).如果不改造，特定环节的回退可以通过流程设计来
9、实现.可监控管内容流程定义的加载，删除.流程实例的创建，删除.可以实现任务执行情况查询和催办.可以查询到相关环节日志记录.流程定义的创建，删除.流程实例的创建，删除.可以实现任务执行情况查询和催办.可以对流程流转，任务操作，变量操作等多类日志进行查询分析.发展趋势IBM早期支持（收购FileNet）.早期中国也有一批公司支持.早期好评较多（20032005），活跃了1年半左右时间.靠山是Enhydra.思想保守，不思进取，排除异己.版本更新比较慢，代码的更新也没有按照开源的方式来完成.Shark2.0后，有很多组件不开源了，而且都是只有Demo，如果要用，需要付费.仍有为数不少基于Shark开
10、发的系统在运行维护.发展已进入暮年.IBM/Oracle现在是支持BPEL的老大.BEA支持BPEL（收购uego）.是近年java&j2ee界极力推荐的开源选型（2005到现在）.靠山是jboss,jboss用户群非常庞大.RedHat收购了Jboss，以后RedHat系统可能会内嵌Jbpm.Jbpm组织当前仍保持非常活跃状态.Eclipse在组织BPEL的开源设计器.越来越多的软件厂商采用JBpm做为自己产品中的工作流子系统.网上对Jbpm的正面评价比较多.今年出现Jbpm原创人员离开组织现象.未来发展仍存在一定的不确定性.附图1(shark类结构图)：流程图附图2（jbpm类结构图）：定
11、义部分运行部分流程图Fork和join范例（这也是和shark区别较大的一个地方）:引擎数据表说明（可以知道jbpm大概包括哪些内容）：JBPM_ACTION action记录表 JBPM_DECISIONCONDITIONS 结果条件表 JBPM_DELEGATION 委托表 JBPM_EVENT 事件表 处理进入或者离开事件 JBPM_EXCEPTIONHANDLER 异常处理表 JBPM_ID_GROUP 用户组表 JBPM_ID_MEMBERSHIP 用户成员表 表现用户和组之间的多对多关系 JBPM_ID_PERMISSIONS 用户权限表 JBPM_ID_USER 用户表 JBPM
12、_MODULEDEFINITION 模块定义表 JBPM_MODULEINSTANCE 模块实例表 JBPM_NODE 流程节点表 JBPM_POOLEDACTOR 汇集参与着表 JBPM_PROCESSDEFINITION 流程定义表 JBPM_PROCESSFILE 流程文件表 JBPM_PROCESSFILEBLOCK 流程文件块表 JBPM_PROCESSINSTANCE 流程实例表 JBPM_RUNTIMEACTION 运行中行为表 JBPM_SCRIPTVARIABLES 脚本变量表 JBPM_SWIMLANE 泳道表 JBPM_SWIMLANEINSTANCE 泳道实例表 JBP
13、M_TASK 任务表 JBPM_TASKACTORPOOL 用户行为汇总 JBPM_TASKINSTANCE 任务实例 JBPM_TIMER 计时表 JBPM_TOKEN 令牌表 JBPM_TOKENVARIABLEMAP 令牌变量影射表 JBPM_TRANSITION 转换表 JBPM_VARIABLEINSTANCE 变量实例表 JBPM_VARIABLEINSTANCEBLOCK 变量实例块表 JBPM_VARIABLEMAPPING 变量影射表摘录Xpdl和Bpel对比：WFMC认为BPEL才是“执行语言”，而认为XPDL主要用来“建模”。XPDL领域主要还是利用了活动图，状态图和FS
14、M等元素；这些元素的结合很容易用来表达一个流程的建模模型；但是，我们的平常的做法，就是直接拿这个建模模型来作为了执行语言。我们这样做有什么缺点呢？首先，我们用XPDL表达了流程的建模模型，但是我们为了让它可执行，加入了太多的业务人员不能理解的元素，导致业务人员不能直接使用它；其次，我们用XPDL表达了可执行的元素，为了容易“建模”，加入了很多“活动”等“建模”元素，这些元素一般会需要去配置很多的属性，而这些属性是干扰和影响“执行”的。XPDL就是一个建模和执行的混合体，是一个分析和实现的混合体。实现模型还是要靠BPEL。摘录Petia whohedPatterns-based Evaluati
15、on of Open Source BPM Systems:The Cases of jBPM, OpenWFE, and Enhydra Shark（分析角度控制流、数据和资源）研究报告的总结： 总的来说，可以概括为开源系统与开发人员（相对于业务分析师）结合得更加紧密。如果有人对Java很熟悉，jBPM或许是一个好的选择，否则不建议使用jBPM；类似地，虽然从工作流模式的角度看，OpenWFE拥有一种针对工作流标准的强大语言，我们却可以推断出它对于非程序员来说很难懂；最后，Endydra Shark对工作流模式的简单支持可能要求特殊复杂的解决方式才能满足重要的商业场景。个人初步保留意见：我们已经有一个可以用
