开源业务流程管理的数字化演进（下）

开源业务流程管理的数字化演进（下）

第四代

再过一段时间后，jBPM 4.0于2009年发布了alpha版本。主要的技术发展是现在位于引擎核心的Process Virtual Machine（PVM）。业务发展是对新兴的BPMN标准的支持，以及已经支持的jPDL和BPEL。但是，从未发布最终版本，因为团队离开了开始Activiti。下一个版本jBPM 5.0基于通用的Drools规则引擎，对BPM采用了完全不同的方法。

与第三代相比，进行了重大的体系结构更改。由于以前的版本用于如此广泛的不同行业，因此引发了许多改进的想法。

可能最大的区别是切换到了无状态服务API，这些API仍然是当今Flowable的基础。另一个主要变化是运行时间和历史数据的分离，此数据在此之前已经混合在一起。通过保持运行时持久性的小而快，对此进行拆分可以干净地解决一些扩展问题。

尽管JBoss平台上提供了版本4和3，但是许多开发人员一直在Spring环境中使用它。到这个时候，Spring在开发人员心态上的份额与Java EE相似。

第五代

2010年，Activiti的第一个版本是从前4代的课程中构建的全新代码库。当时，jBPM的LGPL许可证规定，这并不是一次微不足道的迁移，因为架构和API有所更改，但是概念模型是一个演变。转换为Apache许可意味着这对于任何后代来说都不会成为问题。Activiti专注于仅支持BPMN，并增强了PVM的性能和规模。在此时间的中间，一个叉从Activiti的带到创建Camunda（目前版本7中，虽然仍然是基于5个生成处理引擎）。随后的一些小变化增加了工艺参数的动态变化。持久性和工作优化；和多租户。

第四代的无状态服务API和第二代的POJO方法得到了充分的解决。开发人员仍然可以在EE环境中使用流程引擎，但是与在其他环境（例如Spring）中运行该流程引擎之间不再存在根本区别。

值得注意的是，在那个时期，用于“完整应用程序开发”的Java框架有所增加。那时是Grails，Dropwizard和Play框架以及我们遗忘的许多其他框架的时代。Spring Boot成为主要选择之一（至今仍是撰写本文时）。第五代BPM体系结构着重于轻量级，具有简单的API并易于集成到其他框架中，因此自然而然。

第六代

Flowable 6.0于2017年初发布。发生了许多重大的体系结构更改，但其本质是从PVM方法转变为BPMN本机方法。从真正的动态流程执行到复杂的流程迁移，这为多篇博客文章带来了差异和潜力。也许违反直觉，它还可以实现更高的性能。另一个重大变化是完全抽象的数据源，这开启了使用NoSQL数据库（例如MongoDB）的可能性。最后，添加了一个基于CMMN的新案例管理引擎，从而添加了一个复杂的工具来从不同的角度对自动化进行建模。它也应该增加一些职位来描述它如何增强和丰富智能自动化。所有这些都是在对API和架构进行最小改动的情况下完成的：它甚至包括嵌入式5第Gen微型引擎可让飞行中的过程像偏执狂一样继续进行。只需最少的努力，就可以采用核心BPM执行中的革命性变化。

我们在第一代的部分中提到了JVM。在整个过程中，JVM通过添加强大的功能和部署选项不断发展，而又不失去向后兼容性。当然，这是一项令人印象深刻的工程壮举。JVM继续被证明可适应不断发展的技术环境。它是许多云技术巨头服务的基础，并且已显示出超过数十年前我们认为可行的规模。考虑一下最近出现的GraalVM，诸如Quarkus（及其他）之类的框架和无服务器运动。Flowable体系结构已经能够从这些更改中受益：例如，请参阅我们关于将Flowable作为无服务器功能运行的博客。

第七代

我们不打算或任何时候，只要有仍有大量基于6个可能的进展的期待另一代次代架构。我们既不打算通过在不同的体系结构上创建全新产品，又失去在现实世界中超过15年的发展而来之不易的所有好处来进行革命。我们正在计划进行改进，以使其更易于开发新技术环境，因此我们不会停滞不前。技术趋势通常看起来像是服装时尚–不同的发型和顶部的一些新层使您很酷–这并不意味着您可以做得更好。