工作流与Petri net的关系

　　工作流的发展过程

　　以前，信息系统是设计来支持单个任务的执行。今天的信息系统需要支持业务流程，其不只局限于仅仅关心任务，还关注控制、监控且支持一个业务流程的逻辑方面。这里以历史发展的视图给出工作流管理系统的进化路线图。

　　图1  工作流管理系统的出现

　　20世纪60年代应用软件直接构建于OS之上，负责所有纷繁复杂的事物，甚至于要应用软件自身维护数据文件的操作。后来，随着SQL标准出台，DBMS（数据库管理系统）出现，将应用从数据文件维护的泥潭中解脱出来，但应用软件仍然要维护复杂的UI界面，这是出现了UIMS（用户界面管理系统），C/S模式出现了象delphi这么优秀的RAD开发工具，抽取整理出了大量实用易用的用户交互控件，B/S出现了象Strust专门解决用户展现层问题的优秀框架。然而，经过一段时间的业务以及技术的沉淀，人们发现要在各个分布得象梅花桩一般的企业应用上“打出组合拳”，也就是应用集成实在太难了，同时随着网络分布式技术成熟，人们产生了将WFMS（工作流管理系统）单独提出来应变复杂而多变的业务流程驱动的业务解决方案。

　　比起技术方面的成熟程度，流程管理理念方面似乎更早熟一些，在早于技术发展的步伐人们就提出了BPR（业务流程重组）和CPI（持续流程优化）。企业开始关注流程，以及流程管理。人们开始了解以部门为导向的系统观把部门间的联系割裂开来，必须靠流程将部门联系在一起。正如哈默所说：“为顾客创造价值的是流程，而不是哪个部门”。个人体会是关注流程的目的就是要要以流程为主线更好地理解公司整体经营管理，从而更好地实现整合，实现整体最优化，更有效地支持企业战略。

　　工作流基本概念梳理

　　工作流管理系统从原理上和实现上来讲可以认为是一个BOS（业务操作系统），它管理的是业务的流程，负责对业务流程进行静态的定义，则可以类比看做为OS（操作系统）里的静态的可执行程序的代码。基于静态流程规则的定义，业务流程又具有动态性，就是我们常说的流程实例。OS负责多进程的创建、调度、执行，保存进程的上下文信息等操作，同时需要人为操作时，等待人工执行，目的是让多个进程可以有条不絮地完全执行完毕。工作流管理系统的功能也类似，管理业务流程实例的创建、调度、执行，并保存各自流程实例的执行上下文信息，同时提供人工任务接口，以便让各个业务流程实例走完走好，好的管理系统还会给出相应的执行报告和监控接口。

　　以上只是从原理类比上做了个比喻，其实工作流发展至今，因为建模语言标准的过多与复杂，各自都有一套自己描述工作流相关的技术术语。这里进行一个简单的输理，以便可以进一步理解本文后面会使用到的术语。”case”这个词，中文直译可能就是案例的意思，但这里理解为流程实例，一个流程定义可以对应多个流程实例，如同一个类可以对应多个该类的对象一样。工作流管理系统要做的就是尽可能地有效并高效处理”case”。而通过按照某特定的次序执行”task”来处理”case”。这里”task”是任务的意思，工作流流程定义指定哪个任务要执行，且以什么次序执行。那么以什么次序执行则为”condition”（条件），满足什么条件就可以执行，执行完后会满足什么条件。对于特定的”case”要执行的”task”则叫做”work item”。而术语”resource”（资源）在这里既可以是人也可以是机器，是执行任务的主体。而某个case下由相应的执行者”resource”执行的”task”（任务）就可以确定一个”activity”（活动）。

　　如下图为工作流的三维图

　　这里给出的工作流的三维图，我们只关心”process”和”case”这两个轴，因为这里讨论的是工作流与petri net的关系。

　　Petri net理论基础介绍

　　Petri net分经典petri net理论和高级petri net理论。是对离散并行系统的数学表示。Petri网是1960年代由卡尔·A·佩特里发明的，适合于描述异步的、并发的计算机系统模型。Petri网既有严格的数学表述方式，也有直观的图形表达方式，既有丰富的系统描述手段和系统行为分析技术，又为计算机科学提供坚实的概念基础。研究领域趋向认为Petri网是所有流程定义语言之母。本文所提到的petri net未特别说明，均表示经典petri net。

　　Petri网是简单的过程模型，由两种节点：库所和变迁，有向弧，以及令牌等元素组成的。

　　Petri网的结构

　　(1) Petri网的元素：

　　库所（Place）圆形节点
　　变迁（Transition）方形节点
　　有向弧（Connection）是库所和变迁之间的有向弧
　　令牌（Token）是库所中的动态对象，可以从一个库所移动到另一个库所。

　　(2) Petri网的规则是：

　　有向弧是有方向的
　　两个库所或变迁之间不允许有弧
　　库所可以拥有任意数量的令牌

　　Petri网的行为

　　如果一个变迁的每个输入库所（input place）都拥有令牌，该变迁即为被允许(enable)。一个变迁被允许时，变迁将发生(fire)，输入库所(input place)的令牌被消耗，同时为输出库所(output place)产生令牌。

　　变迁的发生是原子的
　　有两个变迁都被允许的可能，但是一次只能发生一个变迁

　　如果出现一个变迁，其输入库所的个数与输出库所的个数不相等，令牌的个数将发生变化

　　Petri网络是静态的
　　Petri网的状态由令牌在库所的分布决定
　　Petri网的形式化定义

　　一个经典的Petri网由四元组（库所，变迁，输入函数，输出函数）组成。任何图都可以映射到这样一个四元组上，反之亦然。

　　Petri网流程建模

　　一个流程的状态是由在场所中的令牌建模的，状态的变迁是由变迁建模的。令牌表示事物（人，货物，机器），信息，条件，或对象的状态； 库所代表库所，通道或地理位置；变迁代表事件，转化或传输。 一个流程有当前状态，可达状态，不可达状态。

　　经典Petri网的局限性

　　没有测试库所中零令牌的能力
　　模型容易变得很庞大
　　模型不能反映时间方面的内容
　　不支持构造大规模模型，如自顶向下或自底向上

　　工作流与Petri net的关系

　　工作流发展至今，已经不是简单的一种工程实施的科学，它如同数据库一样有坚实的数学理论基础。当然现在流行的开源的工作流如Jbpm以及Osworkflow都是以软件工程设计为主导的实现，里面对工作流petri net理论的引用不多，就算是有也只是部门概念的简单借用而已。现阶段对petri net的研究和实践也有开源的实现，但主要都用于研究和学习领域。前面提到“研究领域趋向认为Petri网是所有流程定义语言之母”，自然petri net就能用于工作流流程建模，但不能是简单地“拿来主义”。在没对这些概念弄清楚之前，笔者也走过不少弯路，简单地认为反正petri net就是作为工作流的建模语言就是，没搞清楚什么情况下才适用，怎样才能让petri net作为工作流建模语言，弄清楚这个对搞清workflow与petri net的关系相当重要。这里谈几点自己的体会，我们普遍所说的petri net本身就很大的范围，如果只是指经典petri net理论就够了，就可以做为工作流流程建模的语言这是大错特错的。上面也列出了基本的经典petri net理论。在这些基本理论中我们可以看出，petri net是一个自己推动的系统，即 只要在满足“变迁”的“库所”处有足够的“托肯”就会发生“变迁”，而不需要等待外界人工或系统的干预或响应。这点是与工作流系统最大的不同，看看WMFC所给出的工作流系统构件与接口图

　　里面的接口2和接口3就是工作流管理系统分别与人和机器打交道的。工作流管理系统受到外界系统的影响，是一个reactive（被动）的系统。而相对与petri net系统，则是相对自封的系统，其主动推进，不涉及人工或系统的干预和响应。为此，著名的工作流专家、教授Wil M.P. van der Aalst在其著名的《The application of Petri nets to workflow management》论文中以经典petri net理论为基础给出了WF-Net（工作流网）作为petri net理论应用于工作流建模语言的成果。WF-Net除了给出了四个基本路由构件表示（顺序、分支、条件、循环），还给出了工作流管理系统建模语言中对外界响应的标记，有四种，自动触发、消息触发机制、用户触发、定时器触发。

　　可见，petri net对于工作流管理系统，并不仅仅只是与工作流路由的模式相关而已，petri net本身是一个开放的理论，任何人都可以基于其发展出自己的“网论”。它是建模语言的基础，是扩展的基线。具体将工作流与petri net的概念相互映射，工作流中的”case”可以用petri net中的”token”（托肯）来建模，”task”可以用”transition”（ 变迁）来建模，”condition”可以用”place”（库所）来建模。当然，正如前面所提到的利用petri net来建模工作流流程定义，自然就会让工作流流程模型变大，因为它将activity（活动）拆分为了“条件”和“变迁”，这样可以更好地描述工作流管理系统除资源因素以外的“条件满足”，以及再加入资源（这里包括人和机器）能动性发挥作用后，进入响应的“变迁”。

　　当然，petri net对于工作流，不仅仅在建模语言方面的贡献，如果我们的目光只是停留在这里，那么就太短浅了。现在研究领域在经典petri net中对模型的分析技术、冲突检测技术等等也有了大幅度的进步。与操作系统类似，业务流程模型中的路由也有可能出现因为资源的竞争产生死锁现象，这也是工作流方面在流程仿真–当然这就涉及到BPM技术了，相关的方面了。

　　原文出处：http://gocom.primeton.com/blog10871_19935.htm