工作流与PetriNet两种节点的新诠释

         前两天在给一个同事讲解一个基于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这两种抽象节点。