2020年(BPM业务流程管理)jbpm和shark工作流引擎对比

（BPM业务流程管理)jbpm和shark工作流
引擎对比
基于现状各方面情况，我们讨论到下一版本平台的工作子系统在shark和jbpm中做一个选择，前面我花时间学习了shark各方面的资料，现就Jbpm和Shark工作流各自特点列出比较（欢迎各位提出自己的见解和完善意见）：
Xpdl:xmlprocessdefinitionlanguage.
Bpel:BusinessProcessexecutionlanguage.
Jpdl:JBossJpbmProcessdefinitionlanguage.
考察角度：稳定性，易用性，灵活性，可监管，扩展性，可维护性，发展趋势。

附图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技术可行也会具有相当价值。