工作流引擎发展脉络整理

起源 
jBPM3是一个完整的工作流系统实现,面向开发人员,目的在于简化对组织核心流程进行支撑的软件创建,不支持标准。

发展
jBPM4引入PVM,使其拥有更强大的扩展性,同时增加BPMS特性,这些特性包括了对BPMN的支持、面向业务人员的Web建模器和简单统计分析功能的加入。

分裂

  1. JBPM的主创人员Tom Baeyens与合作伙伴在JBPM的未来架构上产生了重大分歧,于是Tom离开了Jboss并加入了Alfresco公司,沿用jBPM4代码,创立了Activiti5。
    Activiti5基于jBPM4的开源工作流系统,与Alfresco的集成增加了其流程可视化与管理能力,同时通过创新的Activiti Cycle协作组件支持流程相关人员之间的协调,最后,它加强了集成能力。
  2. Jboss公司完全抛弃了JBPM4的架构,基于Drools Flow进行彻底重构,推出了JBPM5。支持BPMN,通过与Drools的合并支持BAM,通过内容仓库增加对流程可视化的支持。由于放弃了jBPM4的PVM,引擎的可扩展性受到损害,并且不再支持jPDL。
    尽管JBPM5和Acitiviti5都支持BPMN2.0规范,但是由于JBPM5完全推翻了JBPM4的架构,这无异于将已经在使用JBPM4和之前版本的用户推向了Activiti5。因此几年下来,Acitiviti大有取代JBPM之势。当然,JBoss旗下有众多优秀的产品,JBPM5作为Jboss的亲生子,自然与这些产品进行整合具有先天的优势,因此选择Activiti5或JBPM5还需要认真权衡利弊。

裂变

  1. 除Alfresco以外,Activiti最大的贡献者之一的公司Camunda表示Activiti可能太拘束于Alfresco对以文档为中心的工作流的需求(这个也是BPMN约束使然),而忽视了Activiti起步时的更为普遍的BPM平台。camunda宣布他们正从Activiti 分裂出一个新的开源工程,那就是camunda BPM.
  2. 当年JBMP的主创Tom已经离开Alfresco多年,后辈们也开始步前人后尘。Tijs Rademakers、Joram Barrez等Activiti的原班核心人马,由于与Alfresco公司在项目的未来发展方向上出现分歧,于是选择集体出走,创建了Flowable,并且将第一个版本定义为5.22,而且在两周前发布了6.0版本。
  3. activiti自身发展缓慢,Activiti这几年止步不前,开始吃老本。而这几年又出了CMMN/DMN两个新规范以及BPMN更多的规范,Camunda框架已经率先响应并支持了,而Activiti5还是不能支持这些规范的,导致流失很多用户,很多用户转向了Camunda阵营,activiti也开始着急忙慌的想去实现CMMN以及DMN规范,但是在实现DMN规范的过程中,还在重构代码,那就是在用户层面增加了更多的引擎,包括内容引擎、应用引擎等,在内核方面因为还是使用的PVM技术,导致在支持流程动态化方面有些吃力,bug层出不穷,前段框架选型失败,后端重构错误等原因。activiti6以及activiti5的代码官方已经宣称暂停维护了。activiti7就是噱头 内核使用的还是activiti6,并没有为引擎注入更多的新特性,只是在activiti之外的上层封装了一些应用,往云方向发展。6.0版本据说留了大量框架级bug,而在flowable中进行了修复。

从各方面收集的资料来看
activiti优于jbpm,jbpm首先出局
flowable优于activiti,即activiti也不再考虑
flowable与camunda之间,能查到资料是camunda更好一些,但缺乏多资料交叉印证。

资料1:
从多个维度对比,camunda优于flowable
https://blog.csdn.net/qq_30739519/article/details/86682931

资料2:
flowable以6.4.1版本为分水岭,大力发展其商业版产品。开源版本维护不及时。部分功能已经不再开源版发布,比如表单生成器(表单引擎)、历史数据同步至其他数据源、es等等。dmn目前是个半成品,没有camunda稳定和好用,对于dmn规范支持薄弱。部分商业版的组件被商业化,因此开源版不再维护。Mongdb目前也放到商业产品中了,开源版的几乎不能用。(来源:https://blog.csdn.net/qq_30739519/article/details/82493456

上一篇:Unity3D学习-相机跟踪


下一篇:maven命令总结