2023年7月24日发(作者：)

CamundaFlowableActiviti技术发展史

⽬前⽐较出名的开源⼯作流框架⼤概有4个，分别是Activiti/camunda/Flowable/Jbpmn。下⾯我们先抛开Jbpm框架，重点对⽐下Activiti/camunda/Flowable三个框架，因为这三个框架同宗同源，⼏乎都是从Jbpm4之后衍⽣出来的。 随着国内越来越多的企业⼤量的开始使⽤⼯作流框架，⼯作流框架的选型也成为⼀个⾸要并且头痛的事情。因为开源的⼯作流框架实在是太多了，⽤多如⽜⽑形如也不为过。从⽽使好多企业感觉⽆从下⼿去选型。因为从表⾯（API）层⾯看都差不多，但是深⼊内核去研究⼜没有太多的时间和精⼒。在本⽂中我们重点从这⼏个框架（Activiti/camunda/Flowable）的发展史。后续博⽂会介绍⼏个技术的选型。Activiti/camunda/Flowable商业化情况camunda已经推出了商业版和开源版本。Flowable已经推出了商业版和开源版本。Activiti持续开源Activiti/camunda发展史 2012年末，Alfresco的Activiti BPM ⼩组正经历⼀系列的转变：Tom Baeyens——Activiti最初的创建者和开发者(宣布担任Effektif云BPM启动的现任CEO)——将不再领导Activiti⼯ 程，并已决定在任职不到三年后离开Alfresco,。camunda是Activiti最⼤的贡献者之⼀(除Alfresco以外)，同时也是它⼀个主 要的执⾏咨询合作伙伴。camunda表⽰Activiti可能太拘束于Alfresco对以⽂档为中⼼的⼯作流的需求(这个也是BPMN约束使然)，⽽忽视了Activiti起步时 的更为普遍的BPM平台。camunda宣布他们正从Activiti 分裂出⼀个新的开源⼯程，那就是camunda BPM.　这在开源BPM界⽆疑是重磅新闻。BPM界早已存在⼏⼤巨头，⽐如Activiti， BonitaSoft, jBPM和Processmaker, 我们并不清楚是否还有⾜够的开源BPM软件需求以保证新的加⼊者的加盟。同时，两⼤阵营必然会有些⼼⽣不快。在这个⼩社会中，树敌的代价将是你⽆法承受 的，因为你永远不会知道在未来⼏年中你终将要和谁合作。这样的离别被形容为“悲伤”，不管是在camunda他们的公告中还是在Joram Barrez (Activiti5/6版本的核⼼开发者，⽬前已经加⼊Flowable阵营)的邮件中;也把Activiti和camunda置于直接敌对的位置，在现有Activiti⽤户和未来业务上进⾏ 竞争。 Signavio——其流程建模⼈员深度整合camunda BPM——下发了⼀个新闻稿声明camundaBPM的分裂将对Signavio的客户有利，并且Tom Baeyens给出了不错的报价;记住Signavio刚为Baeyens的新启动提供了资⾦。这就像是BPM的《冷暖⼈间》。 camunda BPM,正如Activiti(jBPM,就此⽽⾔)并未声称要做零代码BPM组件——有些⼈可能会辩称即使他们声称是，他们也不是——但BPM引擎和功 能的⽬的是嵌⼊业务线的企业应⽤程序中。他们看到零代码市场在⾮战略性流程中是通⽤⼯具，⽽且很有可能通过外包或云解决⽅案(Effektif，任何⼀ 个?)能同样好甚⾄更好地提供服务;反之，camunda将⽬标定位于：IT占据竞争优势，⽽BPM仅仅是⼀个更⼤的应⽤中的⼀部分功能。这并不意味着这 ⾥对⾮技术性业务分析师毫⽆意义：BPMN作为连接业务与IT的桥梁，camunda则把他们之前专有的BPMN往返能⼒带到新的开源⼯程中去。他们在 Eclipse下的BPMN插件中为业务分析师提供了⼀种易于使⽤的建模器，或与Signavio,Adonis和其他建模⼯具实现往返。早在2012年 6⽉，camunda博客就讨论过如何使⽤camunda BPM整合⼏个不同的BPMN建模器,尽管他们明显更青睐Signavio。　camunda BPM是⼀个在Apache 许可下完全开源的BPM堆栈(Eclipse设计者、开发者UI的框架是使⽤Eclipse公共许可)。社区(开源)版通常是最新的版本，注意：⼀些商业 开源供应商把他们的社区版本归⼊到商业版中以提⾼收益，⽽企业(商业)版在接收进⼀步的测试和集成上总是稍慢⼀步。企业版中唯⼀专有的可⽤功能就是应⽤服 务器(WAS)集成和Cockpit Pro,⼀个监控管理⼯具，虽然社区版中有⼀个Cockpit Light功能。你可以在这⾥看到⼀个社区-企业特征的对⽐和⼀个更为完整的清单。除⾮你从⼀开始就被WAS束缚了或者需要相当多的⽀持，社区版是可能⾜ 以让你开始初期运⾏的，这样从开源到商业版的过渡更为容易。　　然⽽，问题并⾮真的是camunda是否将对Activiti代码基做出巨⼤贡献(他们确实做了)，⽽是他们是否能维持并建⽴⼀个Activiti 的开源叉形指令。他们内部有⼀些好的⼈选提供——负责核⼼流程引擎架构师的Daniel Meyer，技术咨询/产品管理视图的Bernd Rücker,BPM业务⽅⾯的Jakob Freund和⼀个具有Activiti和camunda代码基经验的开发团队。他们在Activiti开源社区和开发中展现出卓越的领导⼒，所以很可能 有能⼒运作⼀个camunda BPM开源社区，但是需要确保他们⽤⾜够的资源来保持它的重要地位。在德国，早已有⼀个camunda社区，但那并不同于开源社区，⽽且那只是在德国，所 以他们还有许多⼯作要做。　　还有就是现有的Activiti和camunda⽤户。现有的camunda客户可能并不会被这次的分裂吓到，因为不管怎样对他们来说重要的贡献都 是camunda做出的，但现有的Activiti⽤户(和潜在顾客)可不会轻易妥协于camunda。他们可能正在附加功能与Activiti背后所意 味着的更⼤的公司，稳定的品牌和现有社区之间权衡利弊。鉴于⼀些新的UI特性从Alfresco团队整合到Activiti，公正地说，Alfresco 将继续引领Activiti，并试图维持他们在开源BPM市场上屹⽴不倒。现有Activiti⽤户如果想转向camunda BPM可能会有⼀个⼩窗⼝：现在，引擎是相同的⽽迁移是微不⾜道的，但是我期待着在6个⽉之内，双⽅都将在他们各⾃的项⽬中做出⾜够的改变，⽽那将是⼀项 更重要的⼯作。换⾔之，如果你现在正使⽤Activiti或camunda且⼜考虑转换，那么现在就⾏动吧。　　camunda可能会得罪⼀些⼈，因为他宣告开源分裂⽽不是仅仅把他们专有的产品整合到Activiti⼯程中;这么做他们可能能成为⼀个更强⼤的 影响者，杜绝任何(感观的)来⾃Alfresco的以⽂档为中⼼的影响。再次声明，我并⾮他们任何⼀家公司的内部员⼯，也不是Activiti开源社区的 ⼀份⼦，所以这些都仅仅是推测。Activiti/Flowable发展史 上⽂也提到过，Activiti5在开发期间，衍⽣了⼀个Camunda框架，并且当时的Tom Baeyens已经离职，开始担任领导并全⾯负责Activiti5的发展，Joram Barrez担任架构师的职位，两位强强联⼿，⼀群好基友引领activiti快速迭代的发展着，⽀持更多的BPMN规范要素以及修复这铺天盖地的bug。全世界的宣扬Activiti各种各样的好，风光⼀时。期间还出版了⼀本Activiti in Action⼀书，此书⾮国⼈咖啡兔写的Activiti实战⼀书。这两本书内容风格还是完全不⼀样，写的Activiti in Action书的封⾯如下： 我在写Activiti权威指南的时候，⼤概是2016年7⽉份左右。给清华⼤学出版社交稿的时候⼤概在2017年3⽉份左右、最终出版是2017年5⽉份左右。 其实在2016.7~2017.5期间activiti团队内部已经产⽣了重⼤的分歧。名义上说是分歧，其实是Activiti这⼏年⽌步不前，开始吃⽼本。⽽这⼏年⼜出了CMMN/DMN两个新规范以及BPMN更多的规范，Camunda框架已经率先响应并⽀持了，⽽Activiti5还是不能⽀持这些规范的，导致流失很多⽤户，很多⽤户转向了Camunda阵营，activiti也开始着急忙慌的想去实现CMMN以及DMN规范，但是在实现DMN规范的过程中，还在重构代码，那就是在⽤户层⾯增加了更多的引擎，包括内容引擎、应⽤引擎等，在内核⽅⾯因为还是使⽤的PVM技术，导致在⽀持流程动态化⽅⾯有些吃⼒，bug层出不穷，前段框架选型失败，后端重构错误等原因。 前段选型失败最⼤的看点就是Activiti6的DMN设计器完全没法去正常使⽤，Flowable6的时候⼜重写了DMN设计器。 后端重构包括XML的解析、PVM的去除。XML部分代码重构之后，导致很多元素的解析被遗漏，bug层出不穷。⽬前Flowable6.4之前的版本还有不少元素没有被解析。PVM被移除看起来简单了，这也意味这没有PVM就不会再去⽀持其他的BPEL语⾔的引擎。这个对于⼤公司的战略布局来看，确实丧失了很多的优势，因此⼀批开发团队已经离职，在activiti6框架基础之上去开发flowable框架了。因为不在兼容其他的的BPEL语⾔的引擎。后续还会说其他的⼯作流引擎。关于新的activiti新团队与原有的团队重要开发⼈员我们罗列⼀下，细节如下：上图是Tijs Rademakers，算是activiti5以及6⽐较核⼼的leader了。现在是flowable框架的leader。Joram Barrez 算是activiti5以及6⽐较核⼼的leader了。⽬前从事flowable框架开发。Salaboy Activiti Cloud BPM leader（Activiti Cloud BPM 也就是⽬前的activiti7框架）Tijs Rademakers以及Salaboy⽬前是两个框架的leader。 特此强调⼀点：activiti5以及activiti6、flowable是Tijs Rademakers团队开发的。Activiti7是 Salaboy团队开发的。activiti6以及activiti5代码⽬前有 Salaboy团队进⾏维护。因为Tijs Rademakers团队去开发flowable框架了，所以activiti6以及activiti5代码已经交接给了 Salaboy团队（可以理解为离职之前⼯作交接）。⽬前的activiti5以及activiti6代码还是原Tijs Rademakers原有团队开发的。Salaboy团队⽬前在开发activiti7框架。对于activiti6以及activiti5的代码官⽅已经宣称暂停维护了。activiti7就是噱头 内核使⽤的还是activiti5。并没有为引擎本⾝注⼊更多的新特性，只是在activiti之外的上层封装了⼀些应⽤。旨在简化流程的开发以及适应敏捷开发模式。 注意：activiti6的很多框架bug在flowable框架中已经修复的差不多了。activiti6就是flowable的rc1版本，flowable的rc1版本与flowable6.4.1版本差距是2年，bug之多可想⽽知，两个框架差距了2年，⽽且⽬前activiti6官⽅也停⽌维护了。Camunda框架为了实现⼯作流⾃动化，许多组织购买了BPMS（也称为“BPM套件”），通常由较⼤的供应商提供。 在许多情况下，这些产品⽆法兑现承诺，更糟糕的是，他们对⽤户施加了以下⼀个或多个问题：重量级系统难以安装和维护。封闭式架构，难以与您的技术堆栈集成。需要他们专有的应⽤程序开发⽅法，不受软件开发⼈员的欢迎，灵活性有限。缺乏对BPMN的⽀持，或缺少功能和⼯具。性能和可伸缩性问题。很难获得合格，实惠的专业服务。

总体拥有成本（TCO）过⾼，部分原因是维护费⽤⾼昂。因此，许多组织决定摆脱这些遗留系统，并⽤Camunda BPM取代他们的BPMS。

Camunda BPM轻巧且开发⼈员友好Camunda从⼀开始就是为开发⼈员设计的：Camunda BPM既可以⽤作独⽴的流程引擎服务器，也可以⽤在⾃定义Java应⽤程序中。Camunda BPM还提供REST API，以便⾮Java开发⼈员可以构建连接到远程流程引擎的应⽤程序。为了实现⾼可⽤性和可伸缩性，Camunda可以依赖于⼀个共享数据库在分布式集群上运⾏。Camunda也照顾业务⽤户，Camunda BPM为⾮开发⼈员提供了⼴泛的⼯具：Camunda使⽤ISO标准BPMN 2.0定义⼯作流程，为技术和⾮技术⽤户提供通⽤语⾔。Camunda Modeler使业务分析师可以直观地定义⼯作流，并与开发⼈员⼀起协作实际部署。Camunda Optimize为业务利益相关者提供实时监控和报告，因此不会对流程提出任何疑问。Camunda还包括决策模型和表⽰法（DMN）决策引擎，以便业务⽤户可以定义和维护直接与⼯作流引擎集成的可执⾏业务规则。Camunda BPM是Apache 2.0许可下的开源软件，这意味着您可以直接访问源代码和最⼩的供应商锁定。流程迁移是直截了当的，我们在这⾥提供帮助从传统的BPMS迁移到Camunda BPM并⾮⼀蹴⽽就，但它仍然是⼀个简单的过程。Camunda BPM多次取代以下产品：Active BPELAlfresco ActivitiAppian BPMBonitasoftJBoss jBPMIBM WPS / IBM BPM / IBM MQ Workflow / IBM Lotus NotesOracle BPMSoftware AG WebmethodsPega BPM