爱华网1 绪论
1.1 工作流的起源
工作流技术起源于二十世纪七十年代中期办公自动化领域的研究，由于当时
计算机尚未普及，网络技术水平还很低以及理论基础匮乏，这项新技术并未取得
成功。1983 年至1985 年间，在图像处理领域和电子邮件领域出现了早期的含有
工作流特征的商用系统。
进入九十年代以后，随着个人计算机、网络技术的普及和推广，以及信息化
建设的日益完善，使得工作流技术的研究与开发进入了一个新的热潮。1993 年8
月,第一个工作流技术标准化的工业组织——工作流管理联盟（Workflow
Management Coalition，简称WFMC，下同）成立。1994年，工作流管理联盟发
布了用于工作流管理系统之间互操作的工作流参考模型，并相继制定了一系列工
业标准。与此同时，关于工作流技术的学术研究也十分活跃，许多原型系统在实
验室里开发出来。进入二十一世纪以来，工作流技术已被越来越多的人认可，与
之相关的标准规范、工作流引擎及商业产品不胜枚举。人们在开发推广工作流产
品的同时，更加注重工作流的理论研究，以推动该项技术走向成熟。
1.2 本文结构安排
本文后面内容将按如下章节编排：第二部分基础理论部分将对工作流及工作
流管理系统的概念、模型等信息和Petri 网相关基础知识进行解释；第三部分相关
工作章节简述了工作流的发展现状以及工作流的研究领域等；第四章是本文所涉
及的工作流管理系统的系统功能描述，意在从系统需求的角度在功能层上介绍本
工作流管理系统；第五部分以本工作流管理系统的系统架构为核心，分别从不同
的角度对本工作流管理系统的系统设计思想作了详细的说明；在第五部分的系统
设计基础之上，第六部分内容对本工作流管理系统的各个主要功能部件进行了关
于实现技术上的详细介绍并对作为工作流管理系统灵魂的工作流引擎的部分核心
代码进行了说明。
2 基本理论
2.1 工作流
“工作流”这个概念并不为大多数人所了解，即使是在专业的软件开发人员
中，“工作流”这三个字也是远远比不上DBMS 这样的术语为人熟悉和使用的程
度，这并不是说工作流技术不及DBMS 等技术，只是说明了工作流技术相对于
DBMS等成熟、稳定的技术来说，还处于发展的初期。工作流的英文单词是
workflow，犹如大多数计算机领域的术语一样，也是个合成词，是英文单词work
和英文单词flow 的组合。Work 翻译为任务、工作等，flow 则翻译为流程、流动
等。Flow 反映的是一种事物的动态属性或变化过程，例如水的流动被称为水流，
空气的流动被称为气流，还有物料流、资金流等，在抽象领域还有信息流、控制
流等，因此，使用任务、活动以及活动之间的变化过程表示业务流程就被称为工
作流。
在企业实际应用中，虽然工作流的概念相对于物料流、资金流、信息流等概
念要抽象一些，但是工作流从更高的层次上提供了实现物料流、资金流、信息流
及其涉及的相关过程与应用的集成机制，从而使得企业能够实现业务过程继承、
业务过程自动化与业务过程的管理。在工作流概念下实现业务过程集成与业务过
程自动化的继承机制是通过定义不同任务之间相互关系的工作流模型（也称为过
程模型）来实现的。在工作流模型中，无论是具体的物料转移动作、实际物理装
置的操作动作、还是抽象的信息处理动作与决策过程，都可以用工作流的基本组
成元素——任务（也称为活动）来统一地描述。同样，反映不同任务之间的关系，
无论是具体的车间中零件加工顺序关系、办公自动化中的文件批转、还是抽象的
决策流之间的关系都可以用工作流的基本组成元素——连接弧来统一地进行描
述。连接弧反映了对企业业务经营过程的一种控制逻辑，它定义了活动之间的连
接关系和执行顺序。
工作流尚没有一个统一的、明确的定义，不同的组织和研究人员对工作流给
出了各自的定义：定义1：工作流是一类能够完全或者部分自动执行的经营过程，它根据一系列过
程规则，文档、信息或任务能够在不同的执行者之间进行传递与执行。
定义2：工作流是将一组任务组织起来完成某个经营过程。在工作流中定义了任
务的触发顺序和触发条件。每个任务可以由一个或多个软件系统完成，也可以由
一个或一组人完成，还可以是由一个或多个人与软件系统协作完成。任务的触发
顺序和触发条件用来定义并实现任务的触发、任务的同步和信息流（数据流）的
传递。
定义3：工作流是一个用来实施经营过程实践的机制。
定义4：工作流是经营过程的一种计算机化的表示模型，定义了完成整个过程所
需要的各种参数。这些参数包括对过程中每一个步骤的定义、步骤间的执行顺序、
条件以及数据流的建立、每一步骤由谁负责以及每个活动所需要的应用程序。
以上这些工作流的定义，虽然在表述方式上有所不同，但是基本上说明了这
样一个问题，即工作流是经营过程的一个计算机实现。使用工作流作为经营过程
的实现技术首先要求工作流系统能够反映经营过程的如下几个方面问题：
1.经营过程是什么，即由哪些活动、任务组成，也就是结构上的定义；
2. 怎么做，即活动间的执行条件、规则以及所交互的信息，也就是控制流
与信息流的定义；
3.由谁来做，即人或者计算机应用程序，也就是组织角色的定义；
4.做得怎样，即通过工作流管理系统对执行过程进行监控。
2.2 工作流参考模型
随着对工作流产品需求的不断扩大，许多公司纷纷推出了不同的工作流产品。
这些工作流产品都有自己的特点，也有自己的协议和接口标准，它们在不同的应
用领域进行了应用。但是由于工作流管理技术与产品缺乏统一的标准，这些不同
的工作流产品从术语的定义和使用、系统结构的设计到与应用之间的接口规范上
都存在较大的差异，导致这些产品之间、产品与其它应用之间的集成十分困难。
按照对系统开放性的要求，这些工作流系统和产品的规范化程度和开放性不够，
导致它们之间不能够实现互操作。工作流管理系统互操作是指两个或多个工作流
机之间通讯和协作工作的能力，具有通讯和协作的能力就称为可以互操作，否则
就称为不能互操作。不同工作流管理系统之间不能互操作这种情况给开发商和用
户都带来了很大的不方便，也在一定程度上阻碍了工作流管理系统的推广和发展。
为了能够更好的支持企业经营建模、分析和实施，适应世界市场的多元化趋
势，需要建立工作流管理系统的相关标准，从系统结构、术语使用、接口实施方
面提供标准化与规范化的定义，并以此为基础实现不同工作流产品之间的互操作，
方便于其它应用系统的集成。在建立工作流的相关规范和标准方面，WFMC 就是
这样的一个国际组织。它提出了有关工作流管理系统的一些规范，定义了工作流
管理系统的结构及其与应用、管理工具和其它工作流管理系统之间的应用编程接
口，其主要目的是为了实现工作流技术的标准化和开发性，从而支持异构工作流
管理系统与产品之间的互操作，并且使得其它的应用可以使用该结构和定义好的
通用API（应用编程接口）访问不同的工作流管理系统提供的服务，实现与其它
应用的快速有效集成。
WFMC 在工作流的相关规范和标准方面做出的主要贡献之一就是提出了一
个工作流参考模型（Workflow ReferenceModel）。工作流参考模型来源于对普通
工作流程序结构的分析，确定结构中的接口，这些接口可以使不同产品在不同的
结构层次上协同工作。所有工作流系统都包含一系列的公共组件，组件间采用一
套被定义好的方法进行协作；不同的产品在这些公共的组件中，会表现出不同的
处理能力。为了实现不同工作流产品间的协同工作，需要在这些组件间制定一套
标准的接口和数据交换格式。通过实现这些标准接口，可以达到产品间的协同工
作。
图1描述了WFMC 提出的工作流参考模型的主要组件和接口。
图1：WFMC 工作流参考模型——组件与接口
过程定义工具：以计算机能处理的形式进行过程定义，现在的大多数过程定义工
具采用了图形方式，过程设计者通过绘图方式来创建过程模型，最后输出一个
XPDL 文件，有的过程定义工具还有分析、检测功能，帮助设计者设计出良好的
过程模型。
工作流执行服务：由一个或多个工作流引擎组成，提供过程实例的执行，为活动
进行导航，与外界资源交互完成各项活动，维护控制数据和相关数据等功能。
工作流客户端应用：提供用户操作工作流管理系统分配来的任务，由工作流任务
表管理器和任务操作共同完成。工作流任务表管理器是一个软件模块，负责管理
工作流的任务表，并完成与工作流参与者的交互操作。
工作流引擎直接调用应用：在工作流任务执行过程中，一些不需要人员参与的活
动会直接调用一些应用。在简单的情况下，工作流引擎使用过程模型中定义的活
动信息、应用程序所需要的数据来激活外部应用程序；在复杂的情况下采用工具
代理的方式。工具代理与工作流引擎之间通过专用集成接口来完成数据交换和消
息传递。
系统管理和监控工具：对工作流在整个组织内的流程情况进行监控，并提供一系
列管理功能，实现安全性、过程控制、授权等操作。典型的功能范围包括用户管
理、角色管理、监控管理、资源管理、过程监控管理。具体如：过程模型的实例
化，启动、挂起、恢复、终止过程实例；管理正在执行的过程实例等。
工作流定义转换（接口1）：在建模或定义工具与运行时期工作流管理软件间的接
口。
工作流客户端应用程序接口（接口2）：客户端工作流应用程序与工作流机之间的
通信API。
应用程序调用接口（接口3）：工作流机直接调用应用程序或应用程序代理的API，
是工作流系统同应用系统通信的主要接口之一。
WAPI 协作功能接口（接口4）：工作流机同工作流机之间的通信接口，是构成分
布式工作流管理系统的主要功能接口之一。
管理和监控接口（接口5）：提供对工作流机状态以及工作流运行实例的监控和管
理的接口。
2.3 工作流管理系统
工作流管理是在迅速发展的技术，它在不同的行业已经得到了应用。工作流
管理技术与工作流管理系统得到广泛重视的一个重要原因是它能够在信息技术的
支持下实现基于人工和计算机活动组成的业务过程的自动化，它可以实现不同自
动化程度（人工操作、半自动化、自动化过程）的规范化业务管理功能，具有良
好的适应性。因此，虽然工作流管理最早是在办公自动化领域开始进行应用的，
它在工业领域的应用同样取得了显著的成果，尤其是在制造领域得到了广泛的应
用。
工作流管理系统——Workflow Management System（简称WFMS），在工作流
定义基础上，具有如下定义。定义1：工作流管理系统是一个软件系统，它完成工作流的定义和管理，并按照
在计算机中预先定义好的工作流逻辑推进工作流实例的执行。
定义2：工作流管理系统是支持企业经营过程高效执行并监控其执行过程的计算
机软件系统。
根据工作流管理系统的定义，一个工作流管理系统应该提供如下的功能：
1. 定义、实现和管理工作流的运行；
2. 与工作流执行者，即人或应用系统，进行交互；
3. 推进工作流实例的执行；
4. 监控工作流的运行状态。
需要指出的是，工作流管理系统不是企业的业务系统。在很大程度上，工作
流管理系统为企业的业务系统运行提供了一个软件支撑环境，非常类似于在单个
计算机上的操作系统。只不过工作流管理系统支撑的范围比较大、环境比较复杂
而以，所以也有人称工作流管理系统是业务操作系统。
在工作流管理系统的支撑下，通过集成具体的业务应用软件和操作人员的界
面操作，才能够良好地完成对企业经营过程运行的支持。所以，工作流管理系统
在一个企业或部门的经营过程中的应用过程是一个业务应用软件系统的集成与实
施过程。
工作流管理系统可以用来定义与执行不同覆盖范围（单个工作者、部门、全
企业、企业间）、不同时间跨度（分钟、小时、天、月）的经营过程。这完全取决
于实际应用背景的需求。按照经营过程以及组成活动的复杂程度的不同，工作流
管理系统可以采取许多种实施方式，在不同的实施方式中，所应用的信息技术、
通信技术和支撑系统结构会有很大的差别。工作流管理系统的实际运行环境可以
是在一个工作组内部或者在全企业的所有业务部门。 2.4工作流管理系统架构
图2：WFMC 提出的通用工作流管理系统产品架构
2.4.1 工作流管理系统组成部分
图2 为WFMC 提出的工作流管理系统产品架构。这个架构给出了抽象的工
作流管理系统的功能组成部件和接口，它能够满足工作流管理系统和产品应该具
有的主要功能，可为实现工作流产品之间的互操作提供公共的基础。从图中可以
看出，工作流管理系统主要由三部分组成：
软件构件：完成工作流管理系统不同组成部分功能的实现，包括过程建模工具，
工作流引擎，任务表管理器和用户界面；
系统控制数据：工作流管理系统中的一个或多个软件构件使用的数据，包括过程
定义，组织/角色模型数据，工作流控制数据，工作流相关数据，任务表；
应用与应用数据：对于工作流管理系统来说，它们不是工作流管理系统的组成部
分，而是属于外部系统和数据，它们被工作流管理系统调用来完成整个或部分工
作流管理的功能，如被工作流管理系统调用的外部应用以及这些应用操作的数据。
2.4.2 工作流管理系统组件说明
过程建模工具：过程建模工具被用来创建计算机可处理的业务过程描述。它可以
是形式化的过程定义语言或对象关系模型，也可以是简单地规定用户间信息传输
的一组路由命令。
组织/角色模型：包含了组织结构和组织中角色的信息。这些信息往往与流程定义
信息紧密相关。
工作流执行系统和工作流引擎：工作流执行系统也称为过程执行环境，包括一个
或多个工作流引擎。工作流引擎是WFMS 的核心软件。它的功能包括：解释过程
定义；创建过程实例并控制其执行；调度各项活动；为用户工作表添加工作项；
通过应用程序接口（API）调用应用程序；提供监督和管理功能等。工作流执行
子系统可以包括多个工作流引擎，不同工作流引擎通过协作共同执行工作流。
工作流控制数据：被工作流执行系统和工作流引擎管理的系统数据，如工作流实
例的状态信息、每一活动的状态信息等。
工作流相关数据：指与业务过程流程相关的数据。WFMS 使用这些数据确定工作
流实例的状态转移，例如过程调度决策数据、活动间的传输数据等。工作流相关数据既可以被工作流引擎使用，也可以被应用程序调用。是一段工作流引擎和应
用系统共享的数据区。
工作列表：流程执行中，当需要用户的交互时，工作流引擎便将工作项放置到由
任务表管理器管理的工作列表中，通过任务表管理器实现与用户的交互。
应用程序和应用数据：应用程序可以直接被WFMS 调用或通过应用程序代理被
间接调用。通过应用程序调用，WFMS 部分或完全自动地完成一个活动，或者对
业务参与者的工作提供支持。与工作流控制数据和相关数据不同，应用数据对应
用程序来讲是局部数据，对WFMS 的其它部件来说是不可见的。
2.5 Petri 网
Petri 网是一个图形化的数学建模工具。一方面可以利用图形化的方式来描述
工作流过程，另一方面可以通过形式化的分析技术检查工作流模型的正确与否，
甚至对其进行性能分析。
Petri网定义成三元组，PN=(P,T,F)，其中：
P={p ,p,p …p }是库所的有限非空集；
1 2 3 m
T={t ,t,t …t }是变迁的有限非空集；
1 2 3 n
F=P×T∪T×P是有向弧的集合，P 和T 还满足P∩T=ø 且P∪T≠ø;
图3：一个Petri 网模型实例
2.5.1 Petri 网的基本元素
Petri 网作为一个图形化的建模工具，具有四种基本的图元，任何一个Petri
网模型都是由如下四种基本图元组合形成的。这四种基本图元是：
（1）库所（2）变迁
（3）弧（4）标记
图4：Petri 网基本图元标示
2.5.1.1 库所
库所使用圆圈表示。库所是英文place 的中文译文，在英文中place 意为空间、
地点、位置，大多数中文文献中都将place 翻译为库所是比较形象、合理的，本文后继部分将使用库所一词来代表place，为了文章说明的方便，也会交替使用
place 和库所，它们代表同样的图元。在后继的文章中，也会使用P 来表示库所，
使用Pi（i=1，2，3…）表示在一个Petri 网模型中的某个具体的库所。
在Petri网中，库所因其所处的位置的不同被划分为三类，分别是：起始库所、
终止库所、中间库所。
起始库所，即start place，在标准Petri网模型中有且仅有一个，它表示Petri
网模型的唯一入口，模型实例将从该点开始并进行流程推进。起始库所的特征是，
没有指向该库所的外向弧，但可以有一个或多个从该库所指向变迁的内向弧。
终止库所，即end place，在标准Petri 网模型中有且仅有一个，它表示Petri
网模型的唯一出口，模型实例将在该点结束流程。终止库所的特征是，没有从该
库所指向变迁的内向弧，但可以有一个或多个从变迁指向该库所得外向弧。
中间库所，即intermediate place，在标准Petri 网模型中可以有0个或多个，
它是除去起始库所和终止库所外的第三类库所，通常，中间库所起到的作用是连
接变迁与变迁，中间库所根据其相对于变迁的位置的不同又可以分为输入库所和
输出库所两种。当存在一条内向弧P->T 时，我们称P 是T 的输入库所。当存在
一条外向弧T->P 时，我们称P 是T 的输出库所。
2.5.1.2 变迁
变迁使用矩形表示。变迁是英文transition 的中文译文，在英文中transition 意
为转换、转变，大多数中文文献中都将transition 翻译为变迁是比较形象、合理的，
本文后继部分将使用变迁一词来代表transition，为了文章说明的方便，也会交替
使用transition 和变迁，它们代表同样的图元。在后继的文章中，也会使用T 来表
示变迁，使用Ti（i=1，2，3…）表示在一个Petri 网模型中的某个具体变迁。
为了后文讨论工作流引擎调度策略的方便，这里简单介绍一下变迁在模型实
例中可能存在的状态。一个变迁在模型实例中可能存在三种状态，分别是：常态、就绪态和激发态。
常态，或者说是未就绪态，处于该状态的变迁是指那些尚不满足被调度的条
件的变迁。
就绪态，就绪态的变迁是指那些已具备了被调度的条件的变迁，这里的被调
度的条件是指该变迁的所有输入库所中都至少获得了一个token，这将在工作流引
擎调度策略章节详细分析。
激发态，激发态的变迁是指那些成为就绪态的变迁所对应的任务实体被实际
执行后的变迁的状态。严格来说，激发态并不是变迁的一种静态状态，而是指处
于就绪态的变迁所对应的任务被实际执行时刻的动态状态，这样来说，一个就绪
态的变迁所对应的任务实体被实际执行后变迁将处于激发态，激发态只是个瞬间
状态，进入激发态的变迁即刻处于常态，即进入新的等待调度条件的状态。图5
说明了变迁状态的变更。
激发并消耗调度条件
激发态
常态
等待调度条件就绪态
等待激发
图5：变迁的运行时状态迁移图
2.5.1.3 弧
弧使用一条有向线段表示。弧是英文arc 的中文译文，弧在Petri 网模型中起
到的作用是连接库所和变迁，因为有弧的存在，一个Petri 网的模型最终形成了一
个有向图。根据弧的方向是从库所指向变迁还是从变迁指向库所，弧可以分为两
类：内向弧和外向弧。
内向弧是指从库所指向变迁的弧，如图。内向弧是英文inward arc 的中文译
文。内向弧通常使用P->T 来表示，即从place 指向transition的弧。
外向弧是指从变迁指向库所的弧，如图。外向弧是英文outward arc 的中文译
文。外向弧通常使用T->P 来表示，即从transition 指向place的弧。
这里需要说明的是，当我们说外向和内向时，我们是站在变迁即transition 的
角度来说明弧的方向的，因为transition 在Petri 网模型中是主要的元素，transition
也将是工作流调度引擎进行调度的主体，这将在后继的文章中说明。
2.5.1.4 标记
标记在Petri网模型中使用小黑点来表示，标记一词是本文对token 的翻译，
在大多数中文文献中都没有给出比较合适的翻译，通常选择了直接使用token 一
词，应该说在Petri 网中token 所起到的作用很难选择一个合适的中文来描述。标
记不是Petri 网静态模型的元素，而是Petri 网模型实例运行时的存在的元素。具
体来说，在Petri 网模型建模期间是不存在标记的，只有当该模型被工作流执行引
擎实例化并开始调度时存在的。标记始终是存在于库所中的，如果把库所理解为
一种容器，那么，库所的作用就是用来装标记的。Petri 网模型实例中标记在所有
库所中的分布状态就反映了一个Petri 网模型实例的运行状态。因此，token 在Petri
网中是一种运行时模型实例状态信息的载体和标记，这也是本文将token 翻译为
标记的直接原因。从这个角度来说，有些参考文献引用网络中的术语将Petri 网中
的token 翻译为令牌是不恰当的，至少是不够准确的，Petri 网中的token 从功能
上来说是一种反映模型实例运行状态的静态实体，网络中的令牌是一种处于移动
中的动态实体。Petri 网中的token 的生存期只是在某个特定的place 中从创建到消
耗的过程，并不会出现token 在不同的place 中移动的情况。这一点在后文将由具体的解释。
2.5.2 Petri 网的触发器
从上文所阐述的变迁运行期状态迁移中可以看出，变迁处于就绪态的时刻和
变迁处于激发态的时刻是不同的。能够引起一个处于就绪态的变迁向激发态迁移
的事件被称为一个“触发器”。存在四种不同类型的触发器。
ab
cd
图6：petri 网中变迁的四种触发类型表示图
a) 自动触发：任务一旦从常态迁移到了就绪态就马上可以被激发。这种类型的
触发应用于那些不需要人来交互的而是被应用程序来执行的任务。
b) 用户触发：任务由人来触发，例如，用户选择一个处于就绪态的任务来执行。
在一个工作流管理系统中每个用户都有一个任务输入箱，这个输入箱所包含
的就是那些已经就绪的可以被用户执行的任务实例，任务实例也称为工作项
（workitem）。用户选择并完成一个工作项的操作就是相关的任务实例的触
发，同时工作流实例也将进入流程的下一阶段。
c) 时间触发：处于就绪态的任务由一个时钟来触发。例如，任务项在一个预定
的时刻被执行。 )消息触发：一个外部事件触发一个处于就绪态的任务实例。消息可能是电子
邮件、传真、电话或EDI 消息。每个这样的外部事件都对应应用任务的某个
活动，这样工作流系统才能知道事件的发生。
2.5.3 Petri 网的路由
从工作流程的起始库所到中止库所的路由形式有多种，如下：
顺序路由
图7：顺序路由示意图
并行路由
图8：并行路由示意图
条件路由 2.5.4 Petri 网的发散和汇聚
为了能够实现Petri 网的路由方法，需要使用发散和汇聚，Petri 网具有如下基
本的发散和汇聚单元：
与发散显式或发散隐式或发散
与汇聚或汇聚
图11：petri 网的发散和汇聚标示
与发散
与发散标示的是一种并行路由，即多个任务可以并行地或以某种不确定的次
序进行。用图表示为具有一个输入库所、两个或多个输出库所的变迁。这样，当
该变迁被激发后将为所有的输出库所产生token。
与汇聚
与汇聚用图表示为一个具有两个或多个输入库所和一个输出库所的变迁。这
样，变迁只有当其所有的输入库所中都拥有了可用的token 后才能够从常态迁移
到就绪态，既是说，输入库所前并行的流程必须全部执行完，才汇聚到当前变迁，
任何一个输入库所没有可用的token，变迁都处于同步等待状态。
显示或发散
显示或发散是条件路由的一种具体实例，它在流程的推进中表现出来的特征
是尽可能早的确定（as early as possible）。用图表示为在变迁的输出弧上附加了条
件判断，即是说，当变迁被激发后，并不是为其所有输出库所产生token，而是要
根据输出弧上的条件，通常条件是一种bool 型的表达式，以决定是否为弧所连接
的输出库所产生token。
隐式或发散
隐式或发散也是条件路由的一种具体实例，它在流程的推进中表现出来的特
征是尽可能晚的确定（as lateas possible）。用图表示为存在两条弧从同一库所出
发指向不同的变迁，这样，当输入库所获得token 后，哪个变迁先激发就会获得
这个token。一旦某个变迁消耗了该token，那么，另外的变迁将不再具备就绪的
条件了，也就无法被激发了。
或汇聚
或汇聚用图表示为两个不同的变迁拥有同一个输出库所，这样，这两个不同
的变迁中任何一个的激发都会使得其输出库所后继的变迁的状态的迁移。
3 相关工作
3.1 工作流发展现状
工作流的概念起源于生产组织和办公自动化领域，提出的目的是通过将工作
分解成定义良好的任务、角色，按照一定的规则和过程来执行这些任务并对它们
进行监控，达到提高工作效率、降低生产成本、提高企业生产经营管理水平和企
业竞争力的目标。
自20 世纪90年代中期至今，互联网技术在我国迅速发展和普及，引出了
Intranet、Extranet、Internet、政府上网工程、企业上网工程、电子政府、电子商
务、电子管理、政府内部网、企业网、数字神经系统和数字化办公等一系列新概
念，这些新概念的提出背后都或多或少的存在着工作流的思想，只不过有些概念
体现的工作流思想少些，而有些概念的核心思想就是工作流的思想，如办公自动
化等。随着企业信息化步伐的加快，工作流的思想已经越来越多地进入了企业应
用系统领域。现代化企业为了增强工作效率、缩短信息传播周期、固化业务模式、
增加核心竞争力，已经将企业经营过程的各个领域各个环节均纳入了企业信息化
的部分。众多的企业应用系统按照功能从大的范围来划分，无非两种，一种是以
公文流转、日常办公为主体的办公自动化系统，另一种则是以企业经营过程的业
务流程为主要辅助对象的具体业务系统。无论是办公自动化系统还是具体业务系
统，都是为企业提供软件服务的，都是本着服务于企业需求为目标的，然而，现
实世界中的各个企业的经营过程是无时无刻不在变化和调整中的，以便适应瞬息
万变的市场。这种变更带给信息化系统软件的最大的问题在于企业经营过程的调
整往往使得原有的信息化系统软件要推倒重新设计开发，使开发成本非常的高，
寻找到一种能够相对灵活的架构和管理方式以使得信息化系统能够快速的适应企
业经营过程的变更成为了为企业构造信息化系统的软件设计人员的头等课题。工
作流及工作流管理系统之所以能为企业信息化系统所使用究其原因也在于此。虽
然工作流技术已经开始在企业应用中拥有了一片天空，然而，同已经应用于企业
的其他技术相比，工作流技术仍然处于其技术发展的初期。
图12：工作流技术同关系数据库管理系统技术发展曲线图
图12是在stevesmith 提出的用来反映一种技术从其提出到最终产品化的发展
趋势的曲线图上标示了工作流技术同RDBMS 技术当前发展阶段的对比。从图中
不难看出，工作流技术才刚刚处于技术的提出和初期的发展阶段，距离其发展的
高峰期还有很长的一段路。特别是当把工作流技术同已经处于稳定阶段的产品化
了的RDBMS 相比时，工作流技术发展的落后是非常明显的，然而，任何一种技
术的发展客观上都是遵循这一技术发展曲线的，都是要有个过程的，RDBMS 技
术能够达到今天的程度也是从其提出之初一点点地发展起来的，因此，工作流技
术尽管仍然处于其技术提出阶段，但市场对技术的需求必将加快工作流技术的发
展，加快其产品化的步伐。
从国内目前工作流技术应用来看，工作流进入企业应用的还非常有限，并且，
已有的工作流产品大部分属于办公自动化系统，例如协同、通达、浪潮等产品。
然后，能够作为企业业务系统支撑平台的工作流产品几乎没有，企业业务系统仍
是大量的专业系统各自独立的构成的，相互集成协作的能力基本上靠传统的手工
方式人为的来操作，失去了信息化的高效性和自动性。工作流为企业业务系统提
供支撑平台的需求同当前工作流技术的发展形成了鲜明的对比，当然，需求拉动
市场，市场促进科研，随着工作流技术的成熟，最终将会进入到企业业务系统并
为其服务的。本文所设计实现的工作流管理系统主要目的也在于此。
3.2 工作流研究领域
工作流管理技术，在其发展的初期主要是由工作流产品开发的公司推动着其
发展，随着它在实际应用中取得的良好效果而得到了充分的重视，并且得到了迅
速的发展。相对于工作流产品市场的繁荣，工作流相关理论研究则显得有些滞后。
在过去很长一段时间里，有关工作流方面的研究主要是商品化的工作流管理系统
的开发商所领导。本着把工作流产品推向市场的目的，这些开发商大多把研究的
注意力放在了工作流管理系统的开发实施方面。目前，在工作流设计方法学、工
作流概念模型等方面还没有形成一套比较成熟的理论和方法。
在工作流理论与实施技术方面，研究的主要内容包括：1 工作流管理系统体
系结构的研究；2 工作流模型与工作流定义语言研究；3 工作流的事务特性：研究
如何实现高级事务处理技术与工作流管理技术的结合，用定义良好的模型语义与
恢复机制来提高工作流系统的正确性与可靠性，从而能够更好地支持企业复杂的
业务过程；4 工作流实现技术：包括面向对象技术、异构分布式计算技术、图形
化用户界面、消息通讯、数据库、WWW 等在内的与工作流系统的设计实现有关
的各项技术及方法；5 工作流的仿真与分析方法；6 基于工作流的应用集成与互操
作技术：研究异构应用系统的集成以及不同工作流系统之间的互操作问题；7 工
作流与经营过程重组：研究如何通过工作流管理系统的实施来支持企业快速高效
地实现经营过程重组；8 工作流技术的其它应用：研究如何将工作流技术在不同
的领域进行应用，包括在CIMS 中的应用。
上述主要研究问题可以分为三个方面：第一方面是工作流的理论基础，包括
工作流管理系统的体系、模型与定义语言（工作流建模方法、工作流模型的形式
化标识、工作流定义语言）等的研究。这一部分工作目前相对来说比较薄弱，还
有许多问题需要进一步研究。第二方面是工作流的实现技术，包括工作流的事务
特性、各种先进软件技术的应用、工作流仿真。这方面研究工作的主要目的是提
高工作流管理系统的性能，尤其是提高工作流管理系统的可靠性及其在处理大规
模复杂的且具有并行业务的流程方面的能力。第三方面是工作流技术的应用，包
括工作流失事技术、在不同应用领域的应用（如在企业经营过程重组、并行工程、
敏捷制造）方法、应用软件集成等。这方面研究的目的是发挥工作流管理系统的
优势，为解决具体应用领域内的问题提供有效实现手段。
4 系统描述
本文所述及的工作流管理系统是一种基于web 技术的工作流管理系统，该工
作流管理系统的开发目的是为企业提供各种b/s 架构的软件系统的底层流程运行
支撑平台，该工作流管理系统所支撑的软件系统按性质分为两类，分别是以公文
流转为核心的OA 系统和以企业业务活动为核心的业务系统。
4.1 系统功能描述
本工作流管理系统的设计定位于同时支撑oa 系统和企业业务系统这两种对
流程调度需求截然不同的系统。这也本工作流管理系统集中解决的问题，也是区
别于国内现有工作流管理系统的地方，国内现有工作流管理系统大多只针对以公
文流转为核心的OA 系统。
本工作流管理系统是一种基于web 技术的工作流管理系统，基于web 技术是
本系统的特征。基于web 技术集中体现在实现工作流管理系统的各个环节和软件
实体均是采用web 技术实现的，不同于某些工作流管理系统产品，虽然这些工作
流管理系统也称为基于web 技术的，但是，严格来说，只能说是支持web 技术的，
因为这些软件产品仅仅是为用户提供了web 操作页面，核心功能却是嵌入了
ActiveX 控件。基于web 技术的另一层含义是，被工作流引擎调度的任务执行实
体也是web 方式提供的，这点对于现代企业的应用集成是非常重要的，当软件系
统逐步从原来的桌面C/S 模式转型为基于浏览器的B/S 模型后，企业中的大部分
应用系统均是B/S 架构的，如何将这些B/S 模式下运行的企业应用系统集成进工
作流管理系统，并由工作流管理系统进行集中管理和调度同样是当前工作流管理
系统软件所要挑战的课题。
从本系统的实现技术层面来说，本系统应该是一种符合WFMC 标准的，基
于web 技术、Petri 网技术和关系数据库技术的工作流管理系统。
符合WFMC 标准，意味着本工作流管理系统的系统架构设计是完全基于
WFMC 的参考模型标准的，或者说系统的设计初衷是定位于一种开放性的、可扩
展的工作流管理系统。
基于Petri网技术，意味着工作流管理系统的流程模型建模是使用Petri 网建
模语言描述的，同时，工作流引擎的调度策略也是基于经典的Petri 网调度理论进
行设计实现的。
基于关系数据库技术，意味着业务系统流程的描述信息将最终存储在关系数
据库中并通过对关系数据库的维护来实现对业务系统流程的控制。
4.2 系统对外服务
工作流管理系统不是企业的业务系统，它是企业业务系统的底层支撑平台，
或者称为业务系统的操作系统。本工作流管理系统作为业务系统的操作系统将对
外提供如下服务：
u业务系统注册服务
° 业务注册中心任务注册中心
°菜单注册中心
°权限注册中心
°服务注册中心
u过程模型定义服务
°图形化过程定义工具
°表单式过程定义工具
u工作流程监控服务
°日志管理功能
°过程管理功能
°过程状态功能
u通用功能接口服务
°权限验证工具类
°服务调用工具类
°日志维护工具类
°应用接口工具类
u统一工作平台服务
°权限验证模块
°菜单控制模块 任务列表模块
° 任务展示模块
5 系统设计
本工作流管理系统的系统架构是依据WFMC 提出的工作流管理系统架构并
结合实际的应用需求提出的一种符合WFMC 参考模型标准的工作流管理系统架
构。
5.1 工作流管理系统架构
图13：工作流管理系统架构图
5.1.1 业务系统注册服务
工作流管理系统被称为业务系统的操作系统，因此，类比于操作系统，业务
系统就类似于在操作系统上运行的功能软件，业务系统的运行环境就是工作流管
理系统，功能软件要想运行需要首先安装到操作系统上，然后再被操作系统来启
动并在操作系统环境中运行，那么，业务系统要想在工作流管理系统上运行，同
样需要一个类似的安装注册过程，在本工作流管理系统的系统架构中，将业务系
统向工作流管理系统注册的工作作为工作流管理系统的一种服务组建存在，即业
务系统注册服务。
业务系统注册服务下设若干功能模块，分别是：系统访问权限设置、系统功
能菜单设置、系统任务实体配置、系统web 服务配置等。
系统访问权限设置
工作流管理系统的业务系统注册服务提供了统一管理、控制终端用户对业务
系统的功能访问权限。系统访问权限的验证机制采用基于角色的访问权限控制理
论，并在该理论上有所扩充，在工作流管理系统这一底层支撑平台上提取、抽象
并接管了原本由业务系统需要处理的访问权限功能，减轻了业务系统的开发任务，
并易于统一配置和维护，关于本工作流管理系统提出并使用的基于角色的访问权
限控制的思想和实现将在第7 部分的系统性能章节详细说明。
系统功能菜单设置
工作流管理系统作为业务系统的操作系统，为业务系统的功能页面提供了统
一的菜单管理入口，即业务系统只需要通过系统功能菜单设置将本业务系统的菜
单树进行配置即可实现菜单在同一工作平台上的展示，并且，结合系统访问权限
的配置信息，展示给终端用户的菜单树将会根据用户的访问权限的不同而不同。
工作流管理系统提供系统功能菜单设置的功能同样简化了业务系统的开发任务，
是业务系统开发人员集中精力于业务逻辑的开发上。
系统任务实体配置
系统任务实体配置是将系统功能页面发布为可以被工作流引擎调度的任务实
体的功能入口。具体的说，通过系统任务实体配置功能注册的任务实体将会被过
程模型定义服务在进行过程模型定义时引用，即这里注册的任务将最终被指定到
工作流模型中的transition 即变迁，作为该变迁被激发时的真正的调度运行实体。
系统web 服务配置
本工作流管理系统所提倡的是一种SOA 即面向服务体系结构的软件架构思
想。SOA 的灵活性和可扩展性是不容置疑的，它是以服务的思想为核心，以服务
提供者、服务使用者和服务注册中心为基本组成元素的新型软件架构思想。本文
第7 部分的系统性能将针对本系统所使用的SOA 系统架构思想的设计和实现进
行详细的说明。业务系统注册服务的系统web 服务配置就是为业务系统进行集中
配置系统提供的那些原始web 服务功能模块的入口。
5.1.2 过程模型定义服务
过程模型定义服务从广义上对应于WFMC 工作流管理系统架构中的过程定
义工具，所不同的是，WFMC 的过程定义工具包括：组织模型定义、信息模型定
义、过程模型定义三个功能模块；而本工作流管理系统中的过程模型定义服务特
指WFMC 中的过程模型定义。
组织模型定义
WFMC 的过程定义工具里的组织模型定义是对过程模型定义时所需要引用
的参与者信息的建模工具。具体的说，组织模型定义就是为流程建模人员提供的
一种在抽象层面上建立流程活动参与者的组织结构的定义工具。流程建模人员在
定义好组织结构模型后，就可以在过程模型定义时为过程中的活动指定具体的参与者，这里的参与者就是组织模型定义时所创建的，它并不特指某个具体的操作
人员，过程模型定义期间为活动指派的参与者将在过程模型实例运行期由工作流
引擎根据组织模型定义时给出的相关信息映射到具体的操作人员上。
信息模型定义
WFMC 的过程定义工具里的信息模型定义是对过程模型定义时所需要引用
的工作流相关数据的建模工具。工作流相关数据是由信息模型定义产生的，并由
工作流引擎和应用系统共同访问维护的数据。也就是说工作流相关数据是工作流
管理系统和应用系统的共享数据区，过程模型定义时也将引用该共享数据区的数
据字段作为流程跳转时的判断条件。
上面提到的WFMC 的组织模型定义和信息模型定义在本工作流管理系统的
设计中进行了形式上的转变，这些转变具体为：
取消了组织模型定义，主要目的是为了简化工作流引擎在运行期的组织模型
映射工作，这并不是说本工作流管理系统的工作流引擎在运行时无法向具体的操
作人员指派任务，之所以取消了组织模型定义，主要是基于企业原有的组织结构
数据已经非常健全，并且本工作流管理系统只针对一家企业服务，因此如果在工
作流管理系统中再增加一层组织模型的定义就显得有些冗余，并且增加了工作流
引擎的映射任务。基于此，本工作流管理系统取消了组织模型定义，代之以在过
程模型定义时直接引用企业已有的组织结构数据，简化了开发难度和系统数据冗
余，并且避免了组织模型数据和企业真实的组织结构数据的不一致性。
取消了信息模型定义，代之以将工作流相关数据作为流程实例的上下文数据
来由工作流引擎和应用系统共同维护，并由工作流引擎在应用系统活动之间进行
传递。这样的设计简化的工作流引擎的任务，同时使工作流相关数据同流程实例
结合的更加紧密，方便流程的反查和回退等操作。
过程模型定义 一个完整的工作流模型包含了描述一个能够被工作流引擎调度执行的工作流
程所需要的所有信息。这些信息包括工作流程的开始和完成条件、构成工作流程
的活动以及活动的调度规则、用户所需要完成的任务以及所有工作流相关数据的
定义。过程模型定义可能引用组织模型中关于组织结构、组织中的角色等信息（具
体到本工作流管理系统的过程模型定义，就是直接引用企业已有的组织结构数据
中的信息，在后文中我们同样用组织模型来说明）。这样在进行工作流程中活动定
义时，不仅可以指定某个特定的人是这个活动的参与者，而且可以将活动与组织
实体或角色功能进行关联。
WFMC 中的过程模型定义服务的输出数据是包含了工作流模型所有信息的
XPDL 文件，XPDL 是WFMC 提出的一种可扩展流程定义语言，本身是一种良构
的XML 文档，WFMC 提出XPDL 的目的在于统一流程定义的标准语言，以使得
不同厂商开发的流程建模工具所产生的模型文件能够互访，一旦形成了该标准模
型定义语言后，流程建模工具开发厂商和流程模型解释工具开发厂商就可以基于
相同的接口标准各自独立的开发相应的工具，很好地体现了开放性思想。
本文所述及的工作流管理系统的过程模型定义服务的软件实体是运用了
VML 技术而开发的一种完全基于WEB 技术的图形化建模工具，该图形化建模工
具产生的中间文件编码为XML 文档，不同的是，出于实际应用的角度考虑，该
中间文件XML 文档的文档结构是自定义的，没有考虑使用XPDL 格式，这主要
是考虑到XPDL 文档结构的复杂性，但是，如果将模型定义输出为XPDL 格式，
对原有的过程模型定义服务部分的变更是很容易的。
5.1.3 工作流程监控服务
工作流程监控服务对应于WFMC 工作流管理系统系统架构中的模型监控，主
要功能是对工作流管理系统上运行的应用系统流程实例进行监控、管理和性能统
计等。
工作流程监控服务的软件实体是一个基于WEB 技术的监控维护系统，通过
该监控维护系统，监控人员可以对当前在工作流管理系统上运行的应用系统流程
实例的状态进行监控，并可以人为的干预应用系统流程实例的运行，包括可以停
止一个应用系统流程实例、挂起一个应用系统流程实例、改变应用系统流程实例
状态等操作。在企业的具体应用中，企业相关人员可以通过对当前运行的企业应
用系统流程实例的状态的监控和分析来掌控企业经营状态和对企业经营状态的全
局分析的目的。
5.1.4 通用功能接口服务
通用功能接口服务从功能上对应于WFMC 工作流参考模型的五类接口。通用
功能接口服务的软件实体是一组功能中间件，分别为以下功能部件间的通信提供
标准的通信接口：
1.过程模型定义服务同工作流引擎之间的通信（接口1）；
2.统一工作平台服务同工作流引擎之间的通信（接口2）；
3.应用系统同工作流引擎之间的通信（接口3）；
4.工作流程监控服务同工作流引擎之间的通信（接口5）；
5.工作流引擎同其它工作流引擎之间的通信（接口4）；
6.业务系统注册服务同应用系统之间的通信（功能扩展接口）
其中通信接口1——通信接口5 分别对应了WFMC 工作流参考模型的五类功
接口；接口6 是本工作流管理系统的业务系统注册服务同在工作流管理系统上运
行的应用系统之间通信的接口，主要是应用系统对通过业务系统注册服务进行配
置了的访问权限、web 服务、菜单配置等信息的访问。
5.1.5 统一工作平台服务
统一工作平台服务对应于WFMC 工作流管理系统系统架构中的用户界面和
任务表管理器。如果将工作流管理系统类比于计算机操作系统，那么，统一工作
平台服务软件实体的功能就类似于操作系统的桌面，它承载了终端用户登录、应
用系统菜单加载、任务列表展示、应用系统任务实体的调度和加载、访问权限控
制等功能。在企业的具体应用中，统一工作平台服务起到的作用是企业信息系统
的集成门户。
5.2 部件功能解析
根据工作流管理系统架构图，将系统中各种部件依据其功能范围可以大致划
分为三类部件，分别是：工作流执行服务部件、工作流功能服务部件和业务系统
应用部件。
5.2.1 工作流执行服务部件
工作流执行服务部件主要包括构成工作流管理系统灵魂的工作流引擎，或称
为工作流机，以及工作流相关数据和工作流控制数据等，这些共同构成了工作流
执行服务部件，负责工作流程的调度和推进。
5.2.2 工作流功能服务部件
工作流功能服务部件位于工作流执行服务部件的外围，直接担负着工作流执
行服务同外部部件，包括人、应用系统等，的交互和通信功能。
5.2.3 业务系统应用部件
严格的说，业务系统应用部件不属于工作流管理系统的一部分，它位于工作
流管理系统的外围，也是工作流管理系统所调度执行的任务实体系统，通常是希
望运行在工作流管理系统上的企业的业务系统。
5.3 工作流引擎详解
工作流引擎即workflow engine，是整个工作流管理系统的核心部分，是工作流管理系统的灵魂。通常，工作流引擎应该具备如下功能：
ÿ过程模型定义的解释执行，形成工作管理系统的工作流控制数据；
ÿ为过程模型创建过程模型实例，并对过程模型实例进行维护；
ÿ依据过程模型进行对过程模型实例中的活动进行调度；
ÿ根据对过程模型实例中活动的调度情况维护任务表；
ÿ根据工作流控制数据调用应用系统提供的任务实体；
ÿ同工作流程监控服务进行通信；
ÿ同其它工作流引擎进行通信；
5.3.1 任务调度策略
如果说工作流引擎是工作流管理系统的灵魂，那么，任务调度策略就是工作
流引擎的灵魂，也就是说任务调度策略是工作流管理系统的核心之核心。工作流
引擎的任务调度策略的性能的优劣以及调度策略能否很好的进行扩展将直接关系
到工作流管理系统的功能是否强大。
不同的工作流管理系统的任务调度策略通常是不一样的，本文所述及的工作
流管理系统的任务调度策略采用的是Petri 网的经典调度算法。下面将首先介绍
Petri 网的基本调度算法，然后结合实例说明任务是如何依据Petri 网调度算法被调
度的。
5.3.1.1 Petri 网调度算法
Petri网调度算法的核心思想非常简单。在本文第2 部分曾介绍过Petri 网的四
种基本图元：库所、变迁、弧、标记。其中，标记是一种流程实例状态信息的载体，标记在库所中的分布情况反映的是流程实例的状态信息。Petri 网的调度算法
或者说Petri 网流程的推进过程实质上是token 的创建和消耗的过程。具体来说，
当任意一个token 被创建在某个库所中时，算法都将查看是否因为该token 的产生
而使得某些变迁从常态迁移到就绪态，根据第2 部分的介绍，即是说，是否因为
该token 的产生而使得某些变迁的所有输入库所中都至少具有了一个token，如果
存在满足该条件的变迁，那么，该变迁就从常态迁移到了就绪态，也就是说该变
迁当前可以被执行，但是，什么时候被执行将取决于该变迁的触发类型。当一个
处于就绪态的变迁被触发前，其状态一直保持为就绪态，并且会将其所有输入库
所中的一个token 进行锁定，直到该变迁被触发时，变迁才从就绪态迁移到激发
态，具体来说，一个处于就绪态的变迁被触发的过程包含如下步骤：
1. 变迁所对应的任务实体被实际执行；
2.变迁从其所有输入库所中消耗掉在该变迁成为就绪态时锁定的token；
3. 变迁为其所有输出库所生成新的token；
4. 变迁从就绪态迁移到激发态并瞬间变回常态。
从该过程不难看出，变迁从就绪态迁移到激发态的过程实质上是变迁消耗其输入
库所中的token 同时为其输出库所产生token 的过程。一个token 的创建可能引起
了变迁状态的迁移，变迁状态的迁移消耗了输入库所中的token 并为其输出库所
生成新的token，新生成的token 又会重复该过程，形成了迭代。该迭代过程也就
是任务的调度过程、流程状态的改变过程。因此，前文提到过token 在库所中的
分布情况反映的是流程实例的状态信息。
当一个流程模型被实例化的时候，工作流引擎会自动为该流程模型实例的起
始库所生成一个token，就是这个被最初放置在起始库所中的token，触发了整个
流程实例的运行。当任意时刻我们观察一个流程实例的时候，如果该时刻没有新
的token 生成时，我们称流程模型处于饱和状态，或静止状态；如果因为一个token
的产生引起了新的token 的产生并且这样的过程在瞬间迭代下去，那么，在该时刻所观察到的流程实例将是不稳定状态，或不饱和状态，这样的状态最终将会趋
于饱和状态，也就是说流程实例将最终进入静止状态，我们称这种现象为“桌球
碰撞现象”。当桌球的球台上分布着许多桌球的时候，如果击出其中一球，该球在
运动中可能会碰撞到其它球而引起其它球的运动，而被引起运动的球在其运动过
程中又可能会引起另外的球运动，这样的迭代下去，如果某一时刻球台上仍然有
在运动的球，那么我们就说其处于不饱和状态，直到所有球都不再运行，我们说
此时处于了饱和状态或静止状态。于是，某个变迁从就绪态迁移到激发态的动作
过程所产生的新token 就好像是被击出的桌球一样，这些token 的产生很可能会引
起新的token 的生成，直到处于饱和为止。
这种“桌球碰撞现象”即是Petri 网调度算法的核心所在，在下节中我们将根
据一个实例来说明Petri 网的调度算法。
5.3.1.2 调度实例说明
本节内容将结合一个简单的Petri 网模型来说明Petri 网的调度算法。本节中
各个Petri 网模型图中白色矩形代表的是处于常态和激发态的变迁，具有花岗石底
纹的矩形代表的是当前处于就绪态的变迁。Petri 网模型图中的小黑点代表的是当
前token 的分布。
P2P4
T2
P1T1T4P6
P3P5
T3
图14：T1 就绪即刻迁移为激发态
图14 说明当前模型实例刚刚被工作流引擎实例化，由工作流引擎在起始库所P1
种生成了第一个token，该token 的产生即刻引起了变迁T1 从常态迁移到了就绪
态，当前模型实例的状态并非饱和状态，因为处于就绪态的变迁T1 处触发类型为系统自动触发，因此，当其从常态迁移到就绪态时即刻被调度执行，T1 将会从
就绪态即刻进入激发状态（常态），该变化将会将T1 的输入库所P1 种的token
消耗掉，并为其所有输出库所P2、P3 生成新的token，模型实例进入图15 所示
的饱和状态。
P2P4
T2
P1T1T4P6
P3P5
T3
图15：T2 和T3 处于就绪态
图15 所示的模型实例处于了一种饱和状态，即P2 中产生的token 使得变迁T2
从常态迁移到了就绪态；P3 种产生的token 使得变迁T3 从常态迁移到了就绪态，
但是，因为T2、T3 与T1 的触发类型不同，T2、T3 都是手工触发的变迁，因此，
T2、T3 迁移到就绪态时会将其各自输入库所及P2、P3 中的token 锁定，T2、T3
何时被激发将取决于用户何时来执行T2、T3 所对应的任务实体。T2、T3 的激发
是没有时序限定的，也就是说，既可能是T2 先被激发，也可能是T3 先被激发，
这里我们假定T2 先被激发，模型实例进入图16 所示状态。
P2P4
T2
P1T1T4P6
P3P5
T3
图16：T2 激发，T3 仍处于就绪态
图16 所示的状态是T2 被激发后的状态，T2 的激发使得P2 中的token 被消耗，
同时为T2 的输出库所P4 产生了token，调度算法此时会尝试找到因为P4 中token
的产生而可能会成为就绪态的变迁，但是，却没有这样的变迁，因为对于变迁T4
来说，虽然其输入库所P4 拥有了token，但是，T4 的另外一个输入库所P5 中却
没有token，因此，T4 不满足从常态迁移到就绪态的条件，因此，当前模型实例
处于稳定状态。只有T3 的激发会引起模型实例状态的改变。假定此时T3 被激发
了，按照规则，将会把P3 中的token 消耗掉，同时为P5 产生新的token，状态如
图17
P2P4
T2
P1T1T4P6
P3P5
T3
图17：T3 激发，T4 处于就绪态
图17 所示的是T3 被激发后的状态，当P5 中产生token 时，调度算法尝试找到因
为P5 中token 的产生而可能会成为就绪的变迁，于是，找到了T4，T4 的状态就
从常态迁移到了就绪态，T4 的触发类型为手工触发，T4 被调度等待用户进行触
发。假定此时用户进行了触发操作，使得T4 从就绪态迁移到了激发态（常态），
按照规则，将会把其输入库所P4、P5 中的token 消耗掉，同时为其输出库所P6
产生token，模型实例进入图18 所示状态。
P2P4
T2
P1T1T4P6
P3P5
T3
图18：T4 激发
图18 所示状态为T4 被激发后的状态，P6 中产生了token，因为P6 是终止库所，因此，满足了流程结束的条件，该流程实例结束。
5.3.2 对流程模型的支持
工作流引擎对流程模型的支持决定了工作流引擎对不同类型的流程模型的调
度能力。流程模型根据其创建的时机、流程中活动的性质、流程中活动的创建时
机的不同可以分为多种类型的流程模型：固定流程、自定义流程、自由流程、嵌
套流程等。
5.3.2.1 固定流程支持
所谓固定流程是指流程模型在被工作流引擎实例化和执行的过程中不会发生
改变的流程。狭义上说，固定流程特指那些由系统管理人员或流程模型定义人员
预先定义好的、在流程模型实例化和执行过程中不会发生变化的流程。广义上说，
凡是在流程模型被工作流引擎实例化和执行的过程中不会发生变化的流程模型都
可以称为固定流程，而不关心该流程模型是由系统管理人员或流程模型定义人员
预先设定好的还是由终端用户根据各自需求自行定义的。我们将那些由终端用户
根据各自需求自行定义的流程称为自定义流程。通常固定流程是企业中相对稳定
了的企业经营流程，而自定义流程是权限范围内的用户灵活设计组织的企业经营
过程。自定义流程实质上是一种特殊的固定流程，因此，后文的讨论中，出现的
固定流程是广义上包含了固定流程和自定义流程的流程模型概念。
固定流程是工作流管理系统中的基本流程，也是过程模型定义服务所支持的
最基本的流程模型。为了后文讨论的方便，这里简单介绍一下过程定义和过程模
型的区别和相互转换关系。
我们将过程模型定义服务软件实体即图形化模型定义工具所设计出的流程称
为过程定义，使用D 表示，而将工作流引擎所执行的流程称为过程模型，使用M
表示。D 是过程模型定义服务的输出文件，D 经过转换器的翻译最终形成可被工
作流引擎执行的M。这个转换器依据其功能被称为DM 转换器，反向的转换器被
称为MD 转换器，两种转换器都依据特定的转换规则进行转换操作，具体的转换规则将在系统实现部分详细介绍。图19说明了两种模型在表现形式上的不同。
DM 转换器
MD 转换器
D：过程定义M：过程模型
图19：过程定义——过程模型
从表现形式来看，过程定义D 更接近于人的流程设计习惯，因此，过程模型定义
服务让流程设计人员所绘制的是D；过程模型M 是标准的Petri 网流程模型图，
这样的结构更利于工作流引擎基于Petri 网的调度理论对流程进行控制。这样，就
需要在过程定义D 和过程模型M 之间进行转换，这种转换是双向的，是通过工
作流管理系统所提供的DM 转换器和MD 转换器来完成的。
5.3.2.2 自由流程支持
相对于固定流程来说，自由流程是指那些在流程模型被工作流引擎执行期间
流程模型实例可以变更的流程模型。自由流程根据其自由度的不同又可分为全自
由流程和半自由流程，全自由流程是指那些预先不存在流程模型而由终端用户的
操作发起并根据终端用户的操作进行后继活动结点的扩充的流程。半自由流程是指那些预先存在流程模型而在流程模型被工作流引擎执行期间工作流引擎可以在
某些活动结点上根据用户的操作执行进行相应的活动结点扩充的流程。半自由流
程不同于全自由流程的是，半自由流程的活动结点的扩充是在一个预定义的主流
程的某些结点上进行的扩充，其自由度是受主流程的限制的，而全自由流程预先
不存在主流程，所有的节点都是根据终端用户的操作指令进行动态扩充的。
自由流程与固定流程的本质区别在于自由流程在被工作流引擎执行期间其活
动结点可以自由的扩充。自由流程中活动结点的扩充在过程定义和过程模型中表
现为如下形式的变更，图20 所示。
P0
T1
T1
P1
T2
T2
PiTi
TiP2
T3T3
P3
图20：自由流程中的节点扩充图示
图20 反映的是一个半自由流程在活动T2 结点处进行活动结点Ti 的扩充情况。前
文提到过，自由流程活动结点扩充的实质是工作流引擎根据用户的操作指令对原
流程模型实例进行结点扩充的操作。为了说明的方便，图中分别给出了结点扩充
操作在过程定义和过程模型上的变化情况。对该情况说明如下。当T2 处于就绪态时，在T2 上进行操作的用户如果按照主流程进行简单的提交操作，那么工作
流引擎将对T2 进行激发操作，工作流引擎按照主流程的定义开始调度，将T3 从
常态迁移到激发态。但是，如果在T2 上的操作用户向工作流引擎发送了扩充Ti
活动结点的操作指令，那么，工作流引擎将在原流程模型实例上在T2 节点出进
行结点的扩充，反映在图的过程模型图中就是增加了库所Pi、变迁Ti 和虚线所标
示的3 条弧，并即刻将扩充后的Ti 从常态迁移到就绪态。当Ti 节点被指派的用
户进行了相关操作并提交工作流引擎时，工作流引擎消耗Pi 中的token，并为P1
产生token，该token 的产生再次使T2 进入了就绪态，对于节点T2 来说，这一次
的就绪和第一次的就绪已经截然不同了，再次就绪时，实际上已经完成了自由扩
充流程节点Ti 的操作。
根据自由扩充的活动结点是否需要返回主流程、自由扩充的活动结点执行完
毕后如何返回主流程等信息，可以汇总出如下情况。
(a)(b)
(c)
图21：自由扩充节点类型
为了更方便对这三种类型的自由流程结点扩充进行讨论，我们分别为它们进
行命名：（a）协办、（b）委托、（c）通知。 A协办
在该扩充模式下，主流程中发起自由流程扩充的节点（后面简称为主节点）
在创建了自由扩充活动节点（后面简称扩充节点）的同时要求扩充节点在执行完
成时必须返回主节点。当工作流引擎在处理这样的扩充指令时，工作流引擎对模
型实例所做的操作为：为主节点扩充一个输出库所，并为其设置token，创建一个
扩充节点，并将扩充的库所作为其输入库所，同时创建外向弧连接扩充节点到主
节点的所有输入库所上。这样，在主节点创建了扩充节点并使其就绪后，主节点
将从原来的就绪态退转为常态，等待扩充节点的返回操作再次使能自己。从该过
程的描述中可以看出，该过程非常类似现实生活中本来应该由主节点这个人独立
处理的事情，主节点却希望临时请求扩充节点这个人来协同完成，主节点希望基
于扩充节点所做出的操作进一步决定自己如何来处理这件事情，因此，我们将这
种节点扩充模式形象的称为协办，即请求协同办理的意思。
B 委托
在该扩充模式下，主节点在创建了扩充节点的同时告知扩充节点在执行完成
时返回主节点在主流程中的后继节点。当工作流引擎在处理这样的扩充指令时，
工作流引擎对模型实例所做的操作为：为主节点扩充一个输出库所，并为其设置
token，创建一个扩充节点，并将扩充的库所作为其输入库所，同时创建外向弧连
接扩充节点到主节点的所有输出库所上。同a 协办模式不同的是扩充节点的外向
弧连接的不是主节点的输入库所而是主节点的所有输出库所。这样，在主节点创
建了扩充节点并使其就绪后，主节点将从原来的就绪态退转为常态，主节点已经
不再需要等待扩充节点返回了。从该过程的描述中可以看出，该过程非常类似现
实生活中本来应该由主节点这个人处理的事情，主节点却托付给了扩充节点这个
人来完成，当扩充节点完成该事情返回主流程时，对主流的推进效果等价于该任
务由主节点处理并推进流程的效果，因此，我们将这种节点扩充模式形象的称为
委托，即委托他人代办的意思。
C 通知
在该扩充模式下，主节点在创建了扩充节点并对其进行使能操作时不要求扩
充节点返回主流程。当工作流引擎在处理这样的扩充指令时，工作流引擎对模型
实例所做的操作为：为主节点扩充一个输出库所，并为其设置token，创建一个扩
充节点，并将扩充的库所作为其输入库所。同a 协办、b 委托不同，在通知模式
下，工作流引擎并不为扩充节点创建外向弧。这样，在主节点创建了扩充节点并
使其就绪后，主节点消耗其输入库所的token，状态从就绪态迁移到激发态，为其
所有输出库所产生token。从该过程的描述中可以看出，该过程非常类似现实生活
中档主节点这个人在处理一件事情后向扩充节点这个人发个通知的动作，目的在
于告知扩充节点。因此，我们将这种节点扩充模式形象的称为通知。
5.3.2.3 嵌套流程支持
嵌套流程或称为子流程支持，是指流程模型中的若干活动结点所对应的是一
些独立的流程，这些独立的流程在流程模型定义的时候被父流程所引用并作为父
流程的一部分，同父流程中其他活动结点共同构成完整的流程模型，被引用的流
程模型相对引用它的流程模型来说是子流程，引用了子流程作为流程模型一部分
的流程模型就被称为嵌套流程。嵌套流程是一种高级的流程模型，也是大多数企
业经营流程建模所使用最多的流程模型类型。
嵌套流程的应用具有很多优点，例如，因为嵌套流程的存在，可以使对复杂
的企业经营流程建模过程进行层次化的划分，可以采用自顶向下、或自底向上的
方式进行复杂流程的建模，当将一个复杂的流程层层分解为一个个相对简单的可
实施的子流程时，对复杂的企业经营流程的建模就只需要引用这些已经定义好的
子流程就可以了。同时，嵌套流程的支持还增加了对企业已有流程模型的复用性，
减轻流程建模的工作量。另外，嵌套流程的支持也为企业对其经营过程进行分析
和企业流程重组以达到最优配置提供了很好的操作平台。
嵌套流程的支持始终是一些产品化的工作流管理系统所追求的目标，特别是
希望为企业的业务系统提供业务工作流程管理的系统来说，能够实现嵌套流程的
支持是尤其重要的。嵌套流程的重要性也带来了其技术实现上的高难度，因此，目前的工作流管理系统软件中，能够很好的支持嵌套流程的非常有限。本工作流
管理系统从设计时考虑了对嵌套流程的支持，并从理论和实现技术上进行了探索，
在本节后面论述中将作详细的说明。
T2父流程模型
T1T4
T3
子流程模型
图22：嵌套流程图解
图22展示的是嵌套流程的逻辑模型图解，处于顶层的父流程模型是由4 个变
迁、6 个库所组成的。其中，变迁T3 是个特殊的变迁，和其他的变迁不同，T3
在模型定义时并不像其他的变迁那样被关联到某个具体的任务实体上，而是被指
定为某个已有的子流程模型的引用，我们称T3 这样的变迁为子流程变迁，相对
的，称T1、T2、T4 这样的变迁为任务实体变迁。子流程变迁同任务实体变迁一
样具有变迁的基本的3 种状态，所不同的是，子流程变迁在其状态迁移时工作流
引擎所执行的动作和任务实体变迁状态迁移时工作流引擎所执行的动作是不同
的。具体来说，当子流程变迁T3 满足了从常态向就绪态迁移的条件时，工作流
引擎会将T3 的输入库所中的token 锁定，当工作流引擎进一步判定出T3 为一个
子流程变迁时，工作流引擎将根据模型定义时为T3 所指定的子流程的引用找到
该子流程的模型定义数据并进行实例化该子流程的操作。实例化该子流程的同时，
工作流引擎会将父流程的标示以及引用该子流程的变迁T3 的标示传递给子流程
实例的上下文，以便子流程实例执行完成时返回。工作流引擎实例化子流程的操
作将会在该子流程实例的起始库所中放置token，于是，该子流程实例的调度运行
将依据正常的流程实例被工作流引擎所管理。与此同时，父流程中变迁T3 的状
态一直保持就绪态，直到因其而实例化的子流程被调度执行完毕，当工作流引擎
判断出子流程已经执行完毕时，工作流引擎从子流程实例的上下文中获得该子流
程的父流程标示以及引用该子流程的变迁的标示，工作流引擎此时就可以根据获
得的父流程以及子流程变迁的标示，对子流程变迁T3 进行状态的迁移，即将T3
的状态从就绪态迁移到激发态，消耗其输入库所中锁定的token，为其输出库所产
生token，推进流程的执行。至此，T3 所引用的子流程就被工作流引擎成功调度
并执行返回推进了父流程的执行。
5.3.3 任务表管理器
任务表在工作流管理系统中处于一个非常重要的位置，虽然它的结构比较简
单。任务表是工作流引擎同应用系统使用人员之间进行交互的窗口，如图23。
放置任务取得任务
工作
工作流任务表平台
引擎
通知引擎提交任务操作人员
图23：任务表的位置示意图
工作流引擎在对过程模型实例进行执行调度时，当一个用户触发的变迁从常
态迁移到就绪态时，就意味着工作流引擎会根据过程模型定义时为改变前设置的
组织人员、任务实体等信息决策出应该为那些人员生成什么样的任务实体工作项，
工作流引擎决策出来的这些任务项将被工作流引擎放置到任务表中，等待对应的
组织人员来获取。组织人员或称为应用系统操作人员通过登陆工作平台来从任务
表中取得指派给自己处理的任务项，并依据过程模型定义时设置的任务实体来具体的执行该任务实体操作，对任务实体的操作具体来说可能是在某个功能叶面上
对某份产品订单作处理，也可能是对某个公文作审批处理。当操作人员完成了指
派给他的任务实体后会将该任务提交给任务表，通知工作流引擎，工作流引擎会
改变任务表中对应工作项的状态，并试图对整个过程模型实例进行推进。
6 系统实现
6.1 数据库设计
Model _workflow
Model _placeModel _ transition
Model _arc
Role,UserApplication _task
Instance_tokenInstance _arc
Instance _placeInstance _ transition
Instance _workflow
Instance _workitem
模型定义数据模型引用数据
实例静态数据实例动态数据
根据这些数据表所存放的数据的性质可以将它们划分为四类表，分别是：模
型定义数据、模型引用数据、实例静态数据、实例动态数据。
6.1.1 模型定义数据
模型定义数据是用来存储过程模型信息的一组数据表，这些过程模型来自于
图形建模工具，流程建模人员使用图形建模工具创建了过程定义后，经过DM 转
换器将过程定义信息转换并存储为模型定义数据形成工作流引擎可以解释执行的
Petri网语言描述的过程模型。模型定义数据包含四个表，分别是：Model_workflow、
Model_place、Model_transition、Model_arc。
Model_workflow
工作流模型表，存储工作流模型的基本信息，包括流程名称、流程描述、创
建时间、生效时间等。工作流模型表是流程模型的标示。
Model_place
模型库所表，存储工作流模型Petri 网图中的所有place 的信息，包括库所名
称、库所描述、库所所属工作流模型标示等信息。
Model_transition
模型变迁表，存储工作流模型Petri 网图中的所有transition 的信息，包括变迁
名称、变迁描述、变迁所属工作流模型标示、变迁所引用的角色人员、变迁所引
用的应用系统任务实体、变迁的触发类型等信息。
Model_arc
模型弧表，存储工作流模型Petri 网图中的所有arc 的信息，包括弧所连接的
库所、弧所连接的变迁、弧的方向等信息。
四个表共同存储了流程模型的Petri 网描述信息，为工作流引擎对其进行实例
化和后继调度操作提供模型数据。这四个表将作为过程模型转换器中的DM 转换
器的输出数据存储区。
6.1.2 模型引用数据
模型引用数据是用来存储组织结构模型数据以及应用系统任务实体信息的数
据表。这些数据表的数据将为模型定义中库所的角色人员、任务实体等引用属性
提供数据来源。模型引用数据包括：Role,User、Application_task。
Role, User
组织模型表，存放工作流的参与者信息，这里的组织模型表不是特指单个表，
而是指代与组织模型数据相关的一系列表，这一系列表共同存储组织结构数据。
在本工作流管理系统中，由于取消了组织模型定义模块，因此，组织模型表实质
上就是企业已有的人员组织数据表。
Application_task
应用系统任务实体表，存储过程模型定义时需要引用的活动任务实体信息。
任务实体就是过程模型的变迁所对应的实际执行实体，是由应用系统提供的软件
实体。根据变迁的触发类型的不同，任务实体也具有相应的类型分类，不同类型
的任务实体会关联到应用系统中不同的软件实体上的。而这样的关联是由流程建
模人员通过任务注册功能进行操作的。
6.1.3 实例静态数据
实例静态数据是用来存储过程模型的单一实例信息的表。与模型定义数据相
对应，实例静态数据由4 个表组成，分别是：Instance_workfow、Instance_place、
Instance_transition、Instance_arc。实例静态数据是工作流引擎对过程模型进行实
例化操作时创建的，具体来说，当工作流引擎接收到实例化某个过程模型的指令
时，工作流引擎会从模型定义数据中找到该过程模型的模型数据并将模型定义数
据中与该过程模型相关的所有信息复制到实例静态数据中，形成该过程模型的一
个完整实例数据，即将所有Model_*表中与实例化过程模型相关的数据复制到对
应的Instance_*表中。从这个角度来说，实例静态数据实际上就是模型定义数据
的一个初始副本，工作流引擎在实例化一个过程模型的时候挥拳拷贝模型定义数
据到实例静态数据中，即实例静态数据同样反映了该过程模型的Petri 网图的信
息，之后工作流引擎对该实例的执行操作将完全在实例静态数据上进行，不再访
问模型定义数据。之所以在过程模型实例化时将模型定义数据全拷贝到实例静态
数据，目的在于避免流程建模人员对模型定义数据的变更操作影响已经创建过的
该模型的实例。另外，当工作流引擎进行自由流程扩充的时候，所有对Petri 网图
进行的扩充都将作用在实例静态数据上，而不会变更模型定义数据。这样做的好
处是，自由流程扩充反映的是某个具体的模型实例在运行期间的状态，而不是公
共的模型定义数据的属性，所有对模型实例的扩充操作记录在了实例静态数据上，
便于对实例的监控和反查等操作，使得模型的各个实例可以各自独立的自由扩充
其流程而不会相互影响。
6.1.4 实例动态数据
实例动态数据是用来存储过程模型实例在被工作流引擎执行过程中的动态信
息的表，包括：Instance_token、Instance_workitem。
Instance_token
实例标记表，存储过程模型实例在被工作流引擎调度的过程产生的token 的
信息，这些信息包括：token 所在的place 标示，token 的状态等。
Instance_workitem
实例工作项表，存储的是由工作流引擎调度并指派给组织人员的工作项信息。
该表是工作流引擎对变迁进行调度的最终输出信息的存储区，具体说，当模型实
例中的一个变迁被工作流引擎从常态迁移为就绪态时，工作流引擎会依据过程定
义时未改变前设置的组织人员、任务实体等引用信息来决定将当前变迁所对应的任务实体分派给哪个人或哪些人去执行，并在Instance_workitem 表中为其增加任
务项。因此，该表所存储的信息与Instance_transition 存储的信息的主要不同在于
任务实体已经被确定的指派到了某个具体的组织人员上。Instance_workitem 表的
信息将由任务表管理器进行维护。
实例动态数据是相对于实例静态数据而言的，它们共同构成了过程模型实例
的运行时信息。
6.2 图形建模工具
过程模型定义始终位于工作流管理系统的最前端，没有过程模型定义创建出
来的模型，工作流管理系统就没有执行和调度的实体。因此，一个功能强大的、
便捷的、界面友好的过程建模工具对于工作流管理系统来说尤其的重要。常见的
过程模型定义工具有两种，一种是基于传统的表单式操作的建模工具，一种是可
视化的图形建模工具。从实现的技术上来说，表单式的建模工具实现起来非常简
单，但是，对于建模人员来说，无法随时从流程的全局考虑，特别是对于功能复
杂的流程来说，使用表单式的建模工具来创建模型是一件非常痛苦的事情。图形
化建模工具就是为了方便建模人员的操作而开发的可视化的建模工具，即建模人
员就像在纸上画图一样，来使用系统提供的相关图元和界面来进行模型的创建。
当然，图形化建模工具的实现技术也是比较复杂的，通常，图形化建模工具都是
以桌面应用程序提供给建模人员的，这些桌面应用程序通常是使用vc 等开发语言
开发的，这样的图形建模工具不是基于web 技术的，即使有些图形化建模工具也
为建模人员提供浏览器操作方式，但其本质是将原来的桌面应用程序制作成
AcitveX 等插件嵌入到浏览器中实现的，从实现技术上说仍然是桌面应用程序。
完全基于web技术的图形建模工具是应该让建模人员在浏览器上绘制流程的一种
工具，因此，从实现技术上来说，主要是采用某种技术来实现矢量图形的绘制功
能。在当今矢量图技术领域，最为突出的也是功能最为强大的两种技术要数VML
和SVG 了。 6.2.1 VML 和SVG的比较
VML(Vector Markup Language)
是一个最初由Microsoft 开发的XML词表，现在也只有IE5.0以上版本对VML
提供支持。使用VML 可以在IE 中绘制矢量图形，所以有人认为VML 就是在IE
中实现了画笔的功能。下面介绍一下VML 的优点：
基于XML 标准
XML 是公认拥有无穷生命力的下一代网络标记语言，VML 具有先天的优
势，它的表示方法简单，易于扩展等等。
支持高质量的矢量图形显示
VML支持广泛的矢量图形特征，它们基于由相连接的直线和曲线描述路径。
在VML 中使用两个基本的元素：shape 和group。这两个元素定义了VML 的全
部结构；shape 描述一个矢量图形元素，而group 用来将这些图形结合起来，这样
它们可以作为一个整体进行处理。
由文本构成的图像，并可集成到HTML
由于VML 使用简单的文本来表示图像，这样就可用很少的字节来表示比较
复杂的图像。VML 与HTML 兼容，通过在HTML 中声明VML 命名空间并声明
处理函数，就可以和其他HTML 元素一样使用VML 元素，在客户端浏览器显示
图像。VML 标记里面可以定义DHTML 大部分属性和事件，比如说id, name,title,
onmouseover 等等。
SVG(Scalable Vector Graphics)
SVG是一种基于XML 的开放的矢量图形描述语言。SVG 图像是与XML1.0
兼容的文档，SVG 元素是指示如何绘制图像的一些指令，阅读器(Viewer)解释这
些指令，把SVG 图像在指定设备上显示出来。使用SVG 可以在网页上显示出各种各样的高质量的矢量图形，支持很多您想象得出的功能：几何图形、动画、渐
变色、滤镜效果等。最关键的是，它也是完全用普通文本来描述的！也就是说，
这是一种专门为网络而设计的基于文本的图像格式。
SVG是对PGML 和VML 的一种综合,所以VML 的优点也就成为SVG 的优
点，例如：基于XML 标准、高质量的矢量图像、由文本构成的图像。然而，SVG
却需要专门的阅读器插件才能解析，当前IE 浏览器在不安装插件的前提下是无法
解析SVG 的。
因此，虽然从功能上说，VML 和SVG 都可以成为图形建模工具的支撑技术，
甚至在某些扩展方面SVG 要优于VML，但是，考虑到IE 对VML 的支持，在开
发本工作流管理系统的图形建模工具时选择了VML 技术。
6.2.2 输出文件格式说明
图形建模工具是一种完全基于WEB 技术的建模工具。建模人员在进行模型
设计的时候，所有数据均保存在客户端内存中，在建模人员进行模型保存的时候
再将这些数据从客户端内存中提取出来，传送到服务器端进行保存。保存在客户
端内存中的与流程模型相关的数据根据其数据性质分为两类：绘图区图形数据和
数据岛属性数据。
VML绘图区数据FileName.vml
XML 数据岛数据
FileName.xml
图25：输出文件示意图
绘图区图形数据 绘图区图形数据是建模人员创建的模型图的图元数据，由于图形建模工具使
用的是VML 标记语言，因此，绘图区图形数据实质上就是建模人员创建的模型
图所对应的VML 数据。绘图区图形数据对于生成工作流引擎能够执行的过程模
型是没有任何价值的，之所以保存绘图区图形数据，目的在于建模人员再次打开
其曾经保存过的模型的时候在其主绘图区再现其最近一次保存模型时的图形信
息。如图25，VML 绘图区数据在建模人员进行模型保存操作的时候会在服务器
端被保存为一个扩展名为.vml 的文件。
数据岛属性数据
数据岛属性数据是建模人员创建的流程的属性信息以及流程中变迁、库所上
的属性信息。数据岛属性数据才是创建工作流引擎能够执行的过程模型时真正需
要的数据。数据岛属性数据是一种使用了xml 数据岛技术而缓存在客户端IE 浏览
器中的记录了建模人员所设置的模型图元属性的数据。数据岛属性数据的结构是
良构的XML 格式数据，有其自身的标记定义。
<workflow>
<wfproperties>
<sysid></sysid>
<name></name>
<desc></desc>
</wfproperties>
<arcs>
<arc>
<arcid></arcid>
<srctransition></srctransition>
<objtransition></objtransition>
<arctype></arctype>
<precondition></precondition>
</arc>
</arcs>
<transitions>
<transition>
<transitionid></transitionid>
<transitionname></transitionname>
<transitiondesc></transitiondesc>
<transitiontrigger></transitiontrigger>
<transitiontask></transitiontask>
<rolelist></rolelist>
<userlist></userlist>
<apptype></apptype>
<wsassignuser></wsassignuser>
<wsruntimelocation>-</wruntimelocation>
<wsuserdefinefirerule></wsuserdefinefirerule>
</transition>
</transitions>
</workflow>
6.3 过程模型转换器
前面简单介绍了过程定义和过程模型的区别。过程定义实质通过图形建模工
具设计绘制的更接近于人的流程模型信息，具体说就是图形建模工具输出文件中
的数据岛属性数据xml 文件。过程模型是工作流引擎能够执行的Petri 网语言描述
的流程模型信息，具体说就是存储于模型定义数据表中的数据。过程定义最终需
要转换为过程模型才能被工作流引擎执行；过程模型同样需要转换为过程定义才
能更好的为人所理解和察看。
6.3.1 DM 转换器
过程定义向过程模型的转换是通过DM 转换器来完成的。图说明了DM 装换
器的输入和输出。
DM转换器模型定义数据
FileName.xml
图26：DM 转换器功能示意图
DM 转换器将图形建模工具创建的数据岛属性数据xml 文件作为输入数据，经过转换器的映射，最终输出为数据库中模型定义数据表中的Petri 网描述模型。
DM 转换器将依据如下算法进行转换操作：
1.使用xml文件中<wfproperties>节点的信息在Model_workflow表中创建记
录；
2. 对 xml文件中所有<transition>节点进行遍历，并使用节点的信息在
Model_transition 表中生成记录，每生成一个记录都将其在
Model_transition表中的主键码值记录在当前处理的<transition>节点上用
来创建弧时使用。
3. 对xml文件中所有<arc>节点进行遍历，获取当前<arc>节点的子节点
<srctransition>和<objtransition>的节点值，如果srctransition等于start，说
明该弧在过程定义中连接了开始图元，据此，转换器在Model_place 中创
建起始库所，根据objtransition 值在xml 文件中找到对应transition 在第一
步中记录下来的主键码值，在Model_arc 中创建一内向弧，连接起始库所
到主键码为获得的主键码所标示的变迁；如果srctransition 不等于start，
objtransition 不等于end，转换器将在Model_place 中创建中间库所，根据
srctransition 和objtransition 在xml 文件中找到对应transition 在第一步中
记录下来的主键码，分别记作srcT 和objT，在Model_arc 中创建一外向
弧，连接srcT 所标示的变迁到先前创建的中间库所，在Model_arc 中创
建一内向弧，连接先前创建的中间库所到objT所标示的变迁；如果
objtransition 等于end，说明该弧在过程定义中连接到了结束图元，据此，
转换器在Model_palce 中创建终止库所，根据srctransition 值在xml 文件
中找到对应transition 在第一步中记录下来的主键码值，在Model_arc 中
创建一外向弧，连接主键码所标示的变迁到前线创建的终止库所。
对一个数据岛属性数据xml 文件进行如上三步操作后，就完成了从过程定义
到过程模型的转换。 6.3.2 MD 转换器
过程模型向过程定义的转换是由MD 转换器来完成的。图说明了MD 转换器
的输入和输出。
FileName.xml
模型定义数据MD 转换器
FileName.vml
图27：MD 转换器功能示意图
MD 转换器的功能是从模型定义数据中反向生成能被图形建模工具打开的过
程定义的中间文件。MD 转换器并不是DM 转换器的简单的逆向操作，从MD 转
换器的输出来看，MD 转换器除了从过程模型中提取出图元属性信息生成数据岛
属性数据xml 文件外，更重要的、也是难度比较大的在于从毫无位置坐标信息的
过程模型数据中构造出具有合理布局的vml 绘图数据的vml 文件的过程。并非所
有的模型定义数据都需要MD 转换器进行转换才能得到过程定义中间文件的，对
于那些原本就是从过程定义通过DM 转换器转换得到的过程模型来说，其所对应
的过程定义中间文件在服务器上是已经存在了的，就不需要MD 转换器的反向转
换了。只有那些通过其他途径，比如表单定义、第三方工具导入等，形成的过程
模型，为了能够使用图形建模工具对其进行察看或变更时，MD 转换器的功能才
得以发挥。
一个功能健全的工作流管理系统是应该提供一个良好的MD 转换器的，基于
本工作管理系统当前的过程模型都是通过图形建模工具创建并经过DM 转换器转换得到的，本工作流管理系统当前版本并没有提供MD转换器的功能，将作为后
继开发工作。
6.4 工作流引擎核心代码分析
本节内容将对工作流引擎的核心代码进行分析，本节出现的代码是在VS.NET
开发环境下使用C#编写的，由于篇幅原因，出于说明的方便，部分代码会结合使
用C#语句和伪码，并在某些代码上做了简化。
6.4.1 FindTransitionsCanBeEnabled
功能：查找某个被创建的token 可能引起的从常态迁移到就绪态的直接变迁，
所谓直接变迁是指那些以该token 所在库所为输入库所的变迁。引用桌球碰撞理
论来说明，那么，函数所查找的就是当一个桌球被击出时，因为与该球碰撞而开
始运动的那些球。
/// <summary>
/// 查找当tokenId 代表的token被创建时可能引起的直接就绪变迁的函数
///对于可以就绪的变迁，立即锁定其输入库所的token
///</summary>
/// <param name="tokenId">创建的token的id</param>
/// <returns>由tokenId 代表的token的创建引起的直接就绪变迁的集合</returns>
private static ArrayList FindTransitionsCanBeEnabled( stringtokenId )
{
ArrayList transitionsCanBeEnabled = newArrayList();
transitionsCanBeEnabled = COAEngineDatabase.FindTransitions(tokenId );
return transitionsCanBeEnabled;
}
该查找过程将依据如下步骤进行：
1. 获得tokenId 标示的token所在的库所标示，记为placeId；
2. 查询Instance_arc 表检索出以placeId所标示的库所作为输入库所的所有
变迁，即满足存在一条内向弧从placeId 标示的库所到变迁的那些变迁的
集合，记入transitionArray；
3.对transitionArray 中的变迁进行遍历，如果transitionArray[i]所标示的变迁
的所有输入库所中均具有可用的token，那么，将transitionArray[i]添加进
enableTranArray ，即enableTranArray.Add(transitionArray[i] ) ；如果
transitionArray[i]不满足上述条件，则遍历向下进行；
4.返回enableTranArray。
FindTransitionsCanBeEnabled函数从功能上来说是在为后继即将进行的迭代
操作准备元数据。
6.4.2 EnableATransition
功能：将满足就绪条件的变迁从常态迁移到就绪态。
private static string EnableATransition( string transitionId,stringcaseId,string newContext )
{
string newWorkitemId = "";
switch(GetTransitionTrigger( transitionId))
{
case COATransitionTrigger.User://手工触发
{
//使用接口IAssignTask 判断将变迁对应的任务指派给哪些具体的用户
ArrayList userIds = IAssignTask( transitionId,caseId,newContext);
//使用接口IGetTaskRuntimeLocation获得变迁对应任务运行时的位置url
string runtimeTaskLocation =IGetTaskRuntimeLocation(
transitionId,caseId,newContext);
//使用函数PushAnEnabledTransitionToWorkitem产生任务项等待用户提取触发
for(inti=0;i<userIds.Count;i++)
newWorkitemId =PushAnEnabledTransitionToWorkitem(
transitionId,caseId,userIds[i].ToString(),runtimeTaskLocation);
break;
}
case COATransitionTrigger.Auto://自动触发
{
//生成workitem 记录
newWorkitemId =PushAnEnabledTransitionToWorkitem(transitionId,caseId,"-1",newContext);
//自动触发相关的任务
IAutoTrigerATask(
newWorkitemId,newContext,ref nextContext,ref finishWorkitem);
//如果目前采用的是同步方式调用的话可以考虑增加任务提交功能
ICommitAWorkitem(newWorkitemId,nextContext,finishWorkitem);
break; returnnewWorkitemId;
}
该函数将依据如下步骤进行：
1.获得即将从常态迁移为就绪态的变迁的触发类型依据触发类型作不同的
处理；
2. 如果触发类型为手工触发，调用IAssignTask获取该变迁被指派给那些组
织用户列表，调用IGetTaskRuntimeLocation 获取该变迁所对应的任务实
体的运行时位置信息，调用PushAnEnabledTransitionToWorkitem 为获得
组织用户列表中的用户分别产生工作项记录；
3.如果触发类型为自动触发，调用PushAnEnabledTransitionToWorkitem 为
该自动触发的变迁在任务表中产生工作项记录，调用IAutoTrigerATask
执行该自动触发变迁所对应的任务实体，通常是web 服务，调用返回后，
调用ICommitAWorkitem 显示的将先前产生的工作项作提交处理。
EnableATransition 的功能在于使能一个满足了就绪条件的变迁，根据变迁的触
发方式进行不同的处理，如果变迁是手工触发，则为相应的人员创建工作项，完
成本次使能动作，如果变迁是自动触发，则主动触发任务实体，令其自动执行并
返回，返回后通知工作流引擎变迁激发完成，引擎将进入迭代过程试图推进流程。
6.4.3 FireAnEnabledTransition
功能：将一个处于就绪态的变迁迁移为激发态，即对就绪的变迁作激发处理。
privatestaticArrayListFireAnEnabledTransition(stringtransitionId,stringcaseId,stringnewContext,refstring
parentW )
{
ArrayList tokensProducedByTheTransition = newArrayList();
//获得该变迁的所有输出弧的信息
DataSet ds = COAEngineDatabase.GetTransitonOutwardArc( transitionId);
string placesToBePutInToken = ""; foreach(DataRowdr in ds.Tables[0].Rows)
{
string placeId =dr["it_place_serialno"].ToString();
string conditionId =dr["arc_condition"].ToString();
if( conditionId == "-1" ||COAEngineInnerInterface.IJudgeArcCondition(conditionId,newContext) )
placesToBePutInToken += placeId + ",";
}
placesToBePutInToken =placesToBePutInToken.Substring(0,placesToBePutInToken.Length-1);
//处理该已完成的变迁
tokensProducedByTheTransition =COAEngineDatabase.HandleAFiredTransition(
transitionId,caseId,newContext,placesToBePutInToken,refparentW);
return tokensProducedByTheTransition;
}
该函数将依据如下步骤进行：
1.调用GetTransitonOutwardArc 获得正在被处理的变迁的所有输出弧信息
记入arcArray；
2. 对arcArray进行遍历，如果arcArray[i].condition 等于“-1”即弧上没有判
定条件，则 palcesToBePutInToken.Add(arcArray[i].placeId ) ，如果
arcArray[i].condition 不等于“-1”，则调用IJudgeArcCondition 判断在当
前上下文中判定条件是否成立，如果条件成立，
palcesToBePutInToken.Add( arcArray[i].placeId )，如果条件不成立，则继
续进行后即遍历；
3. 调用HandleAFiredTransition将变迁从就绪态迁移到激发态，返回为
palcesToBePutInToken 中place 创建的token。
6.4.4 PushAnEnabledTransitionToWorkitem
功能：为一个已成为就绪态的变迁创建任务项。
private static stringPushAnEnabledTransitionToWorkitem(
string transitionId,string caseId,stringuserToBeAssignedTheTask,string taskRuntimeLocation)
{
string workitemId = "";
workitemId =COAEngineDatabase.CreateAWorkitem(
caseId,transitionId,taskRuntimeLocation,userToBeAssignedTheTask);
return workitemId;
}
PushAnEnabledTransitionToWorkitem所创建的任务项将被放置在
Instance_workitem 中，所创建的任务项对于不同触发类型的变迁来说是没有差别
的，既是说，不管变迁是自动触发的还是手工触发的，
PushAnEnabledTransitionToWorkitem是不做区别对待的，所不同的是，如果变迁
是手工触发的，那么，创建的任务项被指派到了组织人员上，等待组织人员来获
取并提交该任务项，如果变迁是自动触发的，那么，创建的任务项将被后继程序
中的代码自动提交。
6.4.5 InstantiateAWorkflow
功能：为一个工作流模型创建一个新的实例。函数将根据所实例化的是一个
固定流程还是一个全自由流程进行不同的处理。在5.3.2 对流程模型的支持一节中
曾提到过，固定流程和全自由流程的区别在于固定流程是在创建实例前已经存在
了模型数据，而全自由流程是没有模型数据的。
private static bool IInstantiateAWorkflow( string taskId,stringnewContext,bool isFixed,
COAEngineKernel.COATransitionTriggertransitionTrigger,
string transitionName,string transitionDesc,stringtransitionTask,ArrayListtransitionUserList,
string wsAssignUser,stringwsRuntimeLocation,
COAEngineKernel.COATransitionFireRule transitionFireRule,stringwsUserDefineFireRule,string parentT)
{
if( isFixed )
{
//实例化的是一个固定流程
string caseId = "";
string tokenProduced =COAEngineDatabase.InstantiateFixedWorkflow(
taskId,newContext,parentT,ref caseId);
//对单个token 搜索因其成为就绪的变迁
ArrayList transitionsCanBeEnabled =FindTransitionsCanBeEnabled(
tokenProduced);
//遍历所有可能成为就绪的变迁试图对其进行相应处理
for(intj=0;j<transitionsCanBeEnabled.Count;j++)
{
//对单个transition 进行处理
string startWorkitemId =EnableATransition(transitionsCanBeEnabled[j].ToString(),caseId,newContext);
COAEngineCommonInterface.ICommitAWorkitem(startWorkitemId,newContext,true);
}
}
else
{
//实例化的是一个全自由流程
string caseId = "";
string tokenProduced =COAEngineDatabase.InstantiateFreeWorkfow(
taskId,newContext,transitionName,transitionDesc,transitionTask,
transitionTrigger.GetHashCode().ToString(),transitionFireRule.GetHashCode().ToString(),transitionUserList,
wsAssignUser,wsRuntimeLocation,wsUserDefineFireRule,refcaseId);
//对单个token 搜索因其成为就绪的变迁
ArrayList transitionsCanBeEnabled =FindTransitionsCanBeEnabled(
tokenProduced);
//遍历所有可能成为就绪的变迁试图对其进行相应处理
for(intj=0;j<transitionsCanBeEnabled.Count;j++)
{
//对单个transition 进行处理
string startWorkitemId =
EnableATransition(transitionsCanBeEnabled[j].ToString(),caseId,newContext);
COAEngineCommonInterface.ICommitAWorkitem(startWorkitemId,newContext,true);
}
}
return true;
}
实例化一个固定流程的步骤：
1.调用InstantiateFixedWorkflow根据起始任务的id确定需要实例化的模型，
将模型定义数据即Model_*各表中的数据拷贝进实例静态数据即相对应
的Instance_*各表中，形成模型实例数据，并随即为流程的起始库所在
Instance_token 中创建token；
2. 对创建的token调用FindTransitionsCanBeEnabled 获得因其而能够迁移为
就绪态的直接变迁；
3.对第二步中获得的变迁调用EnableATransition 进行使能操作，进入迭代。
4.调用ICommitAWorkitem 将引起该流程实例化的起始任务所对应的工作
项作提交处理，实例化操作完成。实例化一个全自由流程的步骤：
1. 调用 InstantiateFreeWorkfow，根据其输入参数在实例静态数据即
Instance_*各表中创建实例数据，所创建的数据包括：起始任务所对应的
变迁、起始任务要求自由扩展的节点所对应的变迁、起始库所、终止库
所、一个中间库所、连接起始库所到起始任务对应变迁的内向弧、连接
起始任务对应变迁到中间库所的外向弧、连接中间库所到起始任务要有
扩充的节点所对应变迁的内向弧、连接起始任务要求扩充的节点所对应
变迁到终止库所的外向弧。为起始库所创建token；
2. 对创建的token调用FindTransitionsCanBeEnabled 获得因其而能够迁移为
就绪态的直接变迁；
3.对第二步中获得的变迁调用EnableATransition 进行使能操作，进入迭代。
4.调用ICommitAWorkitem 将引起该流程实例化的起始任务所对应的工作
项作提交处理，实例化操作完成。
6.4.6 CommitATransition
功能：对变迁作激发处理，是对FireAnEnabledTransition 的顶层封装，也是工
作流引擎依据Petri 网调度算法的集中体现。
private static bool ICommitATransition( string transitionId,stringcaseId,string newContext,ref string parentW)
{
//成功提交workitem,对当前变迁作激发处理
ArrayList tokensProducedByTheTransition =FireAnEnabledTransition(
transitionId,caseId,newContext,refparentW);
//遍历所有新生成的token 试图推进流程状态
for(inti=0;i<tokensProducedByTheTransition.Count;i++)
{
//对单个token 搜索因其成为就绪的变迁
ArrayList transitionsCanBeEnabled =FindTransitionsCanBeEnabled(
tokensProducedByTheTransition[i].ToString())
//遍历所有可能成为就绪的变迁试图对其进行相应处理
for(intj=0;j<transitionsCanBeEnabled.Count;j++)
{
//对单个transition 进行处理
EnableATransition(transitionsCanBeEnabled[j].ToString(),caseId,newContext);
}
}
return true;
}
该函数将按如下步骤进行：
调用FireAnEnabledTransition 将一个就绪的变迁迁移到激发态，即消耗该变迁所
有输入库所中先前所定的token，为其所有输出库所创建token；
对新创建的token 列表进行遍历，调用FindTransitionsCanBeEnabled 查找当前新创
建的token 可能引起的就绪的变迁列表；
对上一部获得的能够成为就绪态的变迁进行遍历，调用EnableATransition 对当前
变迁进行使能操作，进入迭代；
6.4.7 GetWorkitemFromEngine
功能：从工作流引擎中获取指定组织人员的指定状态的任务项。
public static DataSet IGetWorkitemFromEngine( string role,stringuserId,COAWorkitemStatusworkitemStatus,string
systemId )
{
……
}
函数执行比较简单，只需要从Instance_workitem 中检索出满足条件的数据信息即
可。
6.4.8 CommitAWorkitem
功能：提交一个任务项，该函数是应用程序将任务项提交回工作流引擎的接口。 private static boolICommitAWorkitem( string workitemId,string newContext,boolisFinish,bool hasFreeTask,
COAEngineKernel.COAFreeTaskModefreeTaskMode,
COAEngineKernel.COATransitionTriggertransitionTrigger,
string transitionName,string transitionDesc,stringtransitionTask,ArrayListtransitionUserList,
string wsAssignUser,stringwsRuntimeLocation,
COAEngineKernel.COATransitionFireRuletransitionFireRule,
string wsUserDefineFireRule,boolisSubWorkflow)
{
//根据isFinish 参数判断是否设置工作项为完成状态
if( isFinish )
{
//设置工作项为finished 状态
int ret =COAEngineDatabase.FinishAWorkitem(……);
//如果自由扩充的任务模式不是是用户定义模式
if( freeTaskMode != COAFreeTaskMode.UserDefine)
{
bool canFire = false;
//根据激发原则进行相应的处理
switch((COATransitionFireRule)Enum.Parse(typeof(COATransitionFireRule),fireRule,true))
{
case COATransitionFireRule.Null:
canFire = true;
break;
caseCOATransitionFireRule.FiredWhenFirstCommit:
if( u2.Length == 1 )
canFire = true;
break;
caseCOATransitionFireRule.FiredWhenLastCommit:
if( u2.Length == u1.Length )
canFire = true;
break;
case COATransitionFireRule.UserDefine:
canFire =COAEngineInnerInterface.IUserDefineFireRule(……);
break;
}
if( canFire )
{
//激发变迁
ICommitATransition( transitionId,caseId,newContext,ref workitemId);
//如果激发变迁后使得流程实例结束并且该实例存在父流程实例时,激发对应工作项
if( workitemId != "-1" )
ICommitAWorkitem( …… );
}
}
}
else
{
//设置工作项为in progress 状态
COAEngineDatabase.InProgressAWorkitem( workitemId);
}
//根据hasFressTask 参数判断是否需要进行自由流程扩充
if( hasFreeTask ){
//对当前提交的工作项所对应的变迁进行自由流程的扩充操作
//如果为子流程扩充,改变任务id 为指定的创建子流程实例的任务id
string startTask = transitionTask;
if( isSubWorkflow )
transitionTask = initSubWorkflowTaskId;
string tokenProduced =COAEngineDatabase.FreeWorkflowExtend(……);
//用获得的新token 使能扩充得到的新变迁
//对token 搜索因其成为就绪的变迁
ArrayList transitionsCanBeEnabled =FindTransitionsCanBeEnabled(
tokenProduced);
//遍历所有可能成为就绪的变迁试图对其进行相应处理
for(intj=0;j<transitionsCanBeEnabled.Count;j++)
{
if( isSubWorkflow )
newContext = "……";
//对单个transition 进行处理
EnableATransition(transitionsCanBeEnabled[j].ToString(),caseId,newContext);
}
}
return true;
}
该函数将根据输入参数中所制定的是否将工作项设置为完成状态、是否在该工作
项对应变迁上进行自由节点扩充进行不同的处理。
不需要将任务项设置为完成状态时，即isFinish 为false，工作流引擎只需要调用
InProgressAWorkitem 将该任务项的状态设置为in progress即可；
当isFinish 为true 时，工作流引擎会调用FinishAWorkitem 将任务项设置为完成状
态，同时试图推进流程的进行。首先，工作流引擎会依据是否需要进行自由节点
的扩充以及当前任务相对应节点的激发规则来却是是否对当前任务相对应的变迁
从就绪态迁移到激发态。如果需要状态迁移，则调用ICommitATransition 对变迁
做激发处理。
工作流引擎当hasFreeTask 为true 时，工作流引擎被告知需要在当前处理的任务
相对应的变迁上进行自由节点扩充。 7 结束语
本文论述的是一种基于WEB 技术的工作流管理系统的设计与实现。基于
WFMC 提出的工作流模型，结合企业的具体应用需求设计并提出了一种通用的工
作流管理系统架构，并实现了各组成部件。本文详细阐述了本工作流管理系统的
工作流引擎的核心调度算法及实现代码，可以说是对经典的Petri 网调度理论的很
好的应用和实现，实践证明，对于企业应用中一般的业务流程模型来说，使用Petri
网进行建模并采用经典Petri 网调度理论作为工作流引擎调度算法依据都是可以
满足流程需求的，但是，对于某些特殊的流程，仅仅使用经典Petri 网调度理论就
显得无能为力了，这时，就需要对Petri 进行扩展，也就是通常所说的高级Petri
网。高级Petri 网对经典Petri 网作了很多扩展，这些扩展包括：可以为流程增加
时间属性；可以为token 进行着色处理；支持复杂的嵌套模型定义；支持多入口
多出口等。无疑，这些扩展属性的应用必将为工作流引擎的功能带来更大的扩充。
由于开发周期的限制，本文所述及的工作流管理系统所实现的部分是作为工
作流管理系统最核心的部分的模型定义工具和工作流引擎，对于一个完整的工作
流管理系统来说，仅仅具有这两部分的功能还不足以满足应用要求，企业之所以
采用工作流管理系统来实现对企业业务流程的管理，其主要原因在于工作流管理
系统能够使企业的业务流程规范化以及对企业业务流程的统一集中管理，其中，
对业务流程的统一集中管理是一个企业应用工作流管理系统时最为关注的功能。
为了满足这种要求，工作流管理系统的另一个重要功能就是提供对在其上面运行
的工作流模型实例的监控功能，也就是说工作流管理系统的监控功能。通过工作
流管理系统的监控功能，监控人员可以全局的掌控所有流程的运行实例的状态，
并能加以干预，真正起到控制流程运转的目的。工作流管理系统的监控功能将作
为本工作流管理系统的后继开发工作来实现。
由于本工作流管理系统在涉及之初，出于满足企业应用需求的目的，对工作
流管理系统中的若干环节进行了简化和改造，这些简化和改造的环节集中体现在
取消了组织模型，代之以企业的实际组织结构数据；取消了信息模型，代之以在流程变迁节点间传递上下文。这两部分的简化和改造虽然能够很好的满足企业的
应用需求，但是，作为一个通用的工作流管理系统来说，这两部分的功能是需要
完善的，以便能满足于更加通用的功能要求，这两部分的功能将作为本工作流管
理系统的后继开发工作来实现。
