前两天在给一个同事讲解一个基于Petri Net工作流引擎的时候,如何理解place和transition,着实费了点劲。如果单纯是PN的概念,到也容易,问题是基于PN的工作流引擎,其引申了两种节点:一种是State,一种是Activity:其中state是演化自place,activity则演化自transition。
在往下讲解之前,让我们现在回顾回顾PN的基本知识:Petri Net是对离散并行系统的数学表示,其是1960年代由C.A.佩特里发明的,适合于描述异步的、并发的计算机系统模型。Petri网既有严格的数学表述方式,也有直观的图形表达方式。
在国外很多著名流程相关的文档中,PN的数学表述用的很多,但可惜这些估计只有那些相关专业的研究生、博士生才能看得懂的,俺们一般开发人员,能够领悟图形Notation即可。
经典的PN是简单的过程模型,由两种节点(库所和变迁),及有向弧,以及令牌(Token)组成的。
PN不光抽象了经典的过程模型,并描述了完备的支撑过程调度的算法:如果一个变迁的每个输入库所(input place)都拥有令牌,该变迁即为被允许(enable)。一个变迁被允许时,变迁将发生(fire),输入库所(input place)的令牌被消耗,同时为输出库所(output place)产生令牌。
不过今天不是来讲PN的,只讲过程模型的抽象的两种基本节点:state和activity:一种节点是表述“前置状态”,一种是“过程活动的抽象”。它们分别演化自PN的库所(place)和变迁(transition)。在任何工作流系统中的节点,都是由这两种节点扩展和演化而来的,不同的就是可能有些工作流定义模型中没有state的抽象。
这两种节点在很多工作流定义模型中找到影子:最明显的要数YAWL的Condition和Task节点。在XPDL中,Route节点有些类place的含义,不过不是很明显。
但注意,不要拿这个state与jbpm的state节点,或osworkflow的state概念相匹配。Jbpm的state实际上一种activity节点;而osworkfow的state则是其step+status的联合表述。并且本文的所说的activity也不要仅仅联系到XPDL规范中的activity节点。—— 这里所说的state和activity都是一种最基本节点的抽象描述,分别代表两种Base类型节点。
工作流中有两个很重要的概念:状态与生命周期。对于这两种节点,他们也有各自的生命周期,以及不同生命周期阶段的所反映的状态。
State节点的生命周期状态是:initializtion,running,completed。
Activity节点的生命周期状态是:initializtion,actived,running,completed(有的可能没有running状态)。
但是这两种节点之间是有一些相互约束的,对于State节点来说,其能否从running状态转变为completed,需要依赖于其后续的Activity节点是否能够active;其实,这也就是上面所说的PN的调度算法。
当然,对于很多工作流引擎所依赖的流程定义模型来说,其根本就没有state节点一说。即使我们前面所提到的XPDL的route节点,你说他是activity也可以,很多工作流引擎本身就是作为activity一种处理的。
说道这,可能很多人会疑问了:有的流程定义模型还有forck、join等之类的于处理分支等等情况的节点。实际上,这些节点也依然是activity节点。其不仅是过程活动的抽象,而且其生命周期及约束也是与activity相同的。
文章有些抽象了,不过俺也实在找不到什么更清晰和直白简单的话语,来通俗易懂的解释state和activity这两种抽象节点。