引擎内核所关注的是一个非常“抽象”层面的问题,而不同引擎关注的“一套完整的执行环境”。
或者我们可以这么来说,引擎内核的职责是非常“精简”的:确保流程按照既有的定义,从一个
节点运行到另一个节点,并正确执行当前节点。
总的来说,引擎内核主要关注四个方面的问题:
(1) 流程定义问题:不是说如何图形化的定义流程,而是如何用一套定义对象,来诠释所
定义的流程。
(2) 流程调度问题:提供什么的机制,可以确保流程能够处理复杂的“流程图结构”,诸如
串行、并行、分支、聚合等等,并在这复杂结构中确保流程从一个节点运行到另一个节点。
(3) 流程执行问题:当流程运行到某个节点的时候,需要一套机制来解决:是否执行此节
点,并如何执行此节点的问题,并维持节点状态生命周期。
(4) 流程实例对象:需要一整套流程实例对象来描述流程实例运行的状态和结果。
4.1 模型与定义对象
工作流引擎本身就是一种“base on model”的组件,流程实例的执行都是依赖于所定义的
“流程定义”,而工作流引擎则是提供了这样一种环境,来维持流程实例的运行。
所以引擎内核,必须提供一套定义对象来描述“流程定义”,并且这些定义对象必须反映出一
种“模型”。比如 jBpm 的定义对象,是与其所基于的 Activity Diagram 模型相对应的。
4.2 调度机制与算法
引擎内核的另一个重要功能,就是保证流程实例准确的从一个节点运行到另一个节点,而这
则需要依赖于一套调度机制。
引擎的调度机制有很多种实现方法,有的甚至是与“所依赖的模型有关”。但普遍来讲,很多
引擎都受到 Petri Net 的影响,而采用 token 来调度。
jBpm 本身就吸纳的 token 这套机制,当然,与 Petri Net 的调度机制还是有所区别。我
们将在下面的章节详细介绍。
4.3 执行机制与状态
经过引擎的调度,实例运行到某个节点了,此时必须必须提供一套机制,来判断当前节点是
否可执行,如果可执行,那么需要提供一套 runtime envrioment 来执行节点——这就是引
擎的执行机制。
复杂的流程引擎会依赖于“流程实例状态”或“活动实例状态”的约束和变迁来进行处理。之所有
有时候我们会把一个流程引擎也叫做“状态机”,很大程度上也是这个原因。
4.4 实例对象与执行环境