BPM业务流程管理jbpm和shark工作流引擎对比Word文档下载推荐.docx

BPM业务流程管理jbpm和shark工作流引擎对比Word文档下载推荐.docx

《BPM业务流程管理jbpm和shark工作流引擎对比Word文档下载推荐.docx》由会员分享，可在线阅读，更多相关《BPM业务流程管理jbpm和shark工作流引擎对比Word文档下载推荐.docx（9页珍藏版）》请在冰豆网上搜索。

可以独立部署.

可以和其他应用集成.

自带web管理工具.

针对不同数据库有一个对应的初始化脚本文件.

流程设计器

使用的Xpdl语言定义流程.

有一个Jawe来图形化定义流程.

Jawe功能图形化功能相对较强.

可以编辑活动变量，流程逻辑控制属性.

需要改造设计器和平台的权限模型结合.

已有一个Flash版web设计器,感觉不是很直观好用.

引入UML泳道使流程用户模型更加清晰，但对于同一用户在多阶段都参与的流程难得画好.

使用Jpdl流程定义语言.

有一个Eclipse流程定义插件.

插件图形化功能较弱，只能绘制流程流转的基本元素.

对活动属性和流程逻辑控制需要手工编辑Jpdl文件.

没有设计插件的源代码，要和当前平台权限模型结合需要手工编辑Jpdl文件.

初步思路是自己来开发一个web设计器.

有泳道概念，但泳道用于工作任务的处理者属性，不体现在流程图绘制，流程图结构不会受到用户泳道的约束.

定义语言

遵循WfMC规范.

内容结构是按元素类型组织的.

Xpdl：

制定的描述业务流程控制流的XML格式规范,格式复杂.

与具体语言无关，不灵活.

可以嵌入脚本控制语言.

宣传称也遵守WfMC规范.

内容结构和设计图流转顺序更加一致。

Jpdl：

直观易懂，可以手工修改.

内容按结构保存在数据库中.

方便扩展自己的逻辑控制内容.

可嵌入一个简单自定义的脚本控制语言.

表单定制

通过活动的变量来定制处理表单.

可以通过变量来定制处理表单.

异构系统交互

Shark可以开CORBA的服务.

需要借助java的其他远程访问框架.

支持EJB.

可改造性

体系和功能最为复杂.

秉承“模块化”的思想，比较容易扩展.

Xpdl文件保存在大字段中，难于分析扩展.

活动事件模型非常容易扩展自己的控制逻辑.

Jpdl文件被分析好结构化地存储在各个数据表中，容易根据需求扩展出特定的活动模型，如多人会签活动，超时自动处理活动，多人选择处理活动.

很方便进行二次开发扩展升级.

支持文档

公司积累文档丰富.

积累文档丰富.

网上具有大量的共享技术资源.

Jpdl流程定义说明文档很好用.

运行稳定性

比较稳定.

可维护性

公司对shark有很多的积累.

熟悉的人员有露明，明华等.

引擎开源.

设计器代码开源.

DODS开源吗，熟悉它的人非常少.

熟悉的人员有宏伟，文力.

对3.2版本流程定义和控制模型幽闭叫深入的研究.

比较容易维护满足业务需求.

设计器插件不开源.

Hibernat开源，熟悉的技术人员多.

使用简单，易上手，源代码也易读.

可配置性

各模块按接口调用，可以替换模块的实现，非常灵活.

可以配置数据库连接和日志输出等.

没有那么灵活.

体系结构

结构清晰，参见附图1.

Activity-Assignment-User.

工作列表产生于Activity-Assignment.

结构清晰，参加附图2.

Node-Task-User.

工作列表产生于Node-Task.

活动和流转模型

流程包.

活动（定义任务和处理页面）.

块活动.

子流程活动.

工具活动（自动执行一些后台功能）.

路由结点.

转移.

条件转移.

否则转移.

例外转移.

（根据活动或转移里定义的条件选择路径流转）

没有包概念.

任务结点（可以定义多个任务，每个任务有自己的处理页面和处理人员）=>

TaskNode.

状态结点（执行会中断，直到外部触发一个信号signal，方便实现分布式系统）=>

State.

自动结点（执行不会中断，自动继续流转）=>

Node.

决策结点（自动）=>

Decision.

超结点（相当于块结点）=>

SuperNode.

子流程结点=>

ProcessNode.

分支和汇聚结点=>

ForkNode和JoinNode.

转移（每个转移有一个名字，引擎的Token根据名字控制转移路径，路径命名使流程图的业务逻辑更加直观）=>

Transition.

可用控制机制

包，流程，活动可以定义属性控制变量.

流程实例挂起，恢复，终止，放弃.

活动实例的接收，完成，挂起，恢复，终止，放弃，改派.

改造后实现工作的回退，收回?

流程，结点，任务可以定义属性控制变量.

变量分为流程级别和任务级别，具备不同可见性范围.

Action,Handle等也可以控制变量.

每个结点可以定义事件（进入，退出，异常，超时等）处理逻辑（Event-Action模型）.

转移发生时也可以定义事件的处理逻辑.

工作任务生成可以定义自己的控制逻辑.

超时事件.

任务实例的接收，完成，挂起，恢复，终止，放弃，改派.

改造实现任务的回退，收回（需要研究确认）.

如果不改造，特定环节的回退可以通过流程设计来实现.

可监控

管内容

流程定义的加载，删除.

流程实例的创建，删除.

可以实现任务执行情况查询和催办.

可以查询到相关环节日志记录.

流程定义的创建，删除.

可以对流程流转，任务操作，变量操作等多类日志进行查询分析.

发展趋势

IBM早期支持（收购FileNet）.

早期中国也有一批公司支持.

早期好评较多（2003—2005），活跃了1年半左右时间.

靠山是Enhydra.

思想保守，不思进取，排除异己.

版本更新比较慢，代码的更新也没有按照开源的方式来完成.

Shark2.0后，有很多组件不开源了，而且都是只有Demo，如果要用，需要付费.

仍有为数不少基于Shark开发的系统在运行维护.

发展已进入暮年.

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类结构图）：

定义部分

运行部分

Fork和join范例（这也是和shark区别较大的一个地方）:

引擎数据表说明（可以知道jbpm大概包括哪些内容）：

JBPM_ACTIONaction记录表

JBPM_DECISIONCONDITIONS结果条件表

JBPM_DELEGATION委托表

JBPM_EVENT事件表处理进入或者离开事件

JBPM_EXCEPTIONHANDLER异常处理表

JBPM_ID_GROUP用户组表

JBPM_ID_MEMBERSHIP用户成员表表现用户和组之间的多对多关系

JBPM_ID_PERMISSIONS用户权限表

JBPM_ID_USER用户表

JBPM_MODULEDEFINITION模块定义表

JBPM_MODULEINSTANCE模块实例表

JBPM_NODE流程节点表

JBPM_POOLEDACTOR汇集参与着表

JBPM_PROCESSDEFINITION流程定义表

JBPM_PROCESSFILE流程文件表

JBPM_PROCESSFILEBLOCK流程文件块表

JBPM_PROCESSINSTANCE流程实例表

JBPM_RUNTIMEACTION运行中行为表

JBPM_SCRIPTVARIABLES脚本变量表

JBPM_SWIMLANE泳道表

JBPM_SWIMLANEINSTANCE泳道实例表

JBPM_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领域主要还是利用了活动图，状态图和FSM等元素；

这些元素的结合很容易用来表达一个流程的建模模型；

但是，我们的平常的做法，就是直接拿这个建模模型来作为了执行语言。

我们这样做有什么缺点呢？

首先，我们用XPDL表达了流程的建模模型，但是我们为了让它可执行，加入了太多的业务人员不能理解的元素，导致业务人员不能直接使用它；

其次，我们用XPDL表达了可执行的元素，为了容易“建模”，加入了很多“活动”等“建模”元素，这些元素一般会需要去配置很多的属性，而这些属性是干扰和影响“执行”的。

XPDL就是一个建模和执行的混合体，是一个分析和实现的混合体。

实现模型还是要靠BPEL。

摘录Petiawhohed《Patterns-basedEvaluationofOpenSourceBPMSystems:

TheCasesofjBPM,OpenWFE,andEnhydraShark》（分析角度控制流、数据和资源）研究报告的总结：

总的来说，可以概括为开源系统与开发人员（相对于业务分析师）结合得更加紧密。

如果有人对Java很熟悉，jBPM或许是一个好的选择，否则不建议使用jBPM；

类似地，虽然从工作流模式的角度看，OpenWFE拥有一种针对工作流标准的强大语言，我们却可以推断出它对于非程序员来说很难懂；

最后，EndydraShark对工作流模式的简单支持可能要求特殊复杂的解决方式才能满足重要的商业场景。

个人初步保留意见：

我们已经有一个可以用的shark平台，公司对shark有比较多的积累，但其中可能还有一些这样那样的小问题，发展本身受到shark技术和多方面原因的限制；

如果部门将提高平台定位高，甚至以后要作成商业产品，还是改用jbpm为好，我们对jbpm也有一些了解和研究，前期需要投入一些人力，如流程设计器的制作，对JBPM内核做更加深入的研究和改造，我们的下一版本平台采用jbpm技术可行也会具有相当价值。