Camunda/Flowable/Activiti技术发展史

 

目前比较出名的开源工作流框架大概有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——下发了一个新闻稿声明camunda BPM的分裂将对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已经离职，tijsrademakers开始担任领导并全面负责Activiti5的发展，Joram Barrez担任架构师的职位，两位强强联手，一群好基友引领activiti快速迭代的发展着，支持更多的BPMN规范要素以及修复这铺天盖地的bug。全世界的宣扬Activiti各种各样的好，风光一时。期间还出版了一本Activiti in Action一书，此书非国人咖啡兔写的Activiti实战一书。这两本书内容风格还是完全不一样，tijsrademakers写的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语言的引擎。这个对于大公司的战略布局来看，确实丧失了很多的优势，因此tijsrademakers一批开发团队已经离职，在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 BPEL
• Alfresco Activiti
• Appian BPM
• Bonitasoft
• JBoss jBPM
• IBM WPS / IBM BPM / IBM MQ Workflow / IBM Lotus Notes
• Oracle BPM
• Software AG Webmethods
• Pega BPM

关于更多的Activiti6视频地址：https://ke.qq.com/course/package/11402?tuin=84de321b

关于更多的Flowable视频地址：https://ke.qq.com/course/package/11431?tuin=84de321b
关于更多的camunda视频2019年3月份即将上市。