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