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

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

ORAM BARREZ和PAUL HOLMES-HIGGIN

尽管我们已经看到了一些令人震惊的随机代码，但我们不打算建议软件通过随机突变的方式像生物学一样进化。我们要建议的是，开源与开发软件的进化方法的结合可以产生强大，适应性强和寿命长的产品。

使用开放源代码时，您可以将想法放在代码中，然后随着开发人员在广泛的用途和环境中进行尝试，将其适应和调整为现实世界：开放源代码是获得如此广泛和大量反馈的唯一方法。对于所有软件，随着适应的积累，您会发现“ cruft”，因此有必要进行调整，甚至可能会违背某些最初的想法。通常，此时会根据先前版本的学习内容来创建新的体系结构版本。通常，这是一个抛弃历史包的机会，而且常常是革命而不是进化（我们当中许多人还记得从AngularJS 1升级到2的痛苦……）。可以将主要体系结构版本的这些周期视为软件生命周期的几代人。理想的目标是，每一代都带来强大的增强功能，而又不要求对其进行重大更改。

您还将注意到的是，随着新概念及其体系结构需要改变以满足早期反馈（特别是在开放源代码中），初始代的循环非常快。随着软件产品的成熟，主要架构更改的发生频率越来越低（在专有软件中通常仅发生一次）。然后，您会看到较小的进化变化，其中一些可以带来显着的改进，否则稳定性和一致性是关键。但是，您仍然可以使用代码规范来解决那些与体系结构的概念优雅性不相称的问题。在某个时候，产品的选择是继续积累“修复”还是以某种方式管理革命性的发展。

这种革命性的演变是建筑师在Flowable的最新迭代中采用的方法。在6.x版中，它代表了开源Java BPM演进的第六代。开源Java BPM的故事实际上始于jBPM，接着是Activiti，然后是Flowable（尽管版本号并不总是反映所有变体的产生）。

第一代

早在2003年，jBPM 1.0就发布了。它仅在J2EE环境中运行，并使用了自己的流程定义语言jPDL。它基于Wil van der Aalst教授的工作思想。作为第一代产品，这是革命性的开始，早期版本迅速迭代。

2003年的技术前景与今天截然不同。回顾我们自己的记忆，当时我们正在做的项目包括applet，具有在EJB中实现的重量级服务器逻辑的Swing桌面应用程序。Spring刚刚诞生（Rod Johnson撰写的“专家一对一J2EE设计和开发”书于2002年问世，其思想演变为Spring将会变成什么样）。

从那时起，这些技术已经衰落或消失，但当时处于Sun Microsystems旗下的Java / JVM平台除外。尽管自JVM诞生以来已经宣布了许多迫在眉睫的JVM，但今天它仍然是占主导地位的平台选择。令人印象深刻的壮举，稍后再讲。

当时，每个BPM供应商都拥有自己的流程语言和工具，而jBPM也不例外，其轻量级jPDL语言也是如此。这确实是一个荒野的西部。历史的旁注：可能很多人都不知道，实际上在实现JVM上的业务流程API标准化方面取得了很大进步。该JSR-207：对Java流程定义是由一组厂商试图达成共识的是什么意思“关于JVM进程”。

第二代

2004年，jBPM在2.0版中加入了JBoss。此版本允许BPM引擎在任何Java环境中运行，并且显着的发展是将流程运行时作为POJO。现在，所有Java开发人员都可以使用BPM的功能。

有趣的是，版本1.x和2.x的工件仍然可以在线下载（开放源代码的另一个优点）。遍历代码使游览非常有趣。从第一代到第二代，最具影响力的变化是切换到仅在JVM上运行而没有应用程序服务器的流程引擎。在当前版本的Flowable中，这仍然是至关重要的。

今天，一些概念（例如能够对测试过程进行单元化的明确目标）继续存在。与目前的服务API相比，少数服务API看起来有些陌生。但是，那个时代的应用服务器主导地位在第二代的许多地方仍然闪耀。鉴于该项目在JBoss的保护下，因此不要感到惊讶。

第三代

在2005年之后不久，jBPM 3.0引入了对BPEL（BPM的Betamax）的支持，从而推动了引擎向“流程虚拟机”概念的发展。这一代被广泛使用，以至于开源反馈确保在核心实现周围增加了功能和优势。

从体系结构的角度来看，版本2和版本3之间的差异很大。在功能方面，引擎支持的操作方式有了飞跃。它不再只是将Java中的状态机用于BPM，还不仅仅是成为众多建模语言的基础框架。

持久性是由Hibernate完成的，它具有“会话对象”的概念。这个想法也被纳入3.0设计中，这意味着与引擎的所有相关交互都需要放在上下文块中。该块为后来的命令和命令拦截器奠定了基础。