首页 > 大数据 > 数据分析 > 基于WEB技术的工作流管理系统设计与实现
1 绪论
1.1 工作流的起源
计算机尚未普及，网络技术水平还很低以及理论基础匮乏，这项新技术并未取得
成功。1983 年至1985 年间，在图像处理领域和电子邮件领域出现了早期的含有
工作流特征的商用系统。
建设的日益完善，使得工作流技术的研究与开发进入了一个新的热潮。1993 年8
月,第一个工作流技术标准化的工业组织——工作流管理联盟（Workflow
Management
布了用于工作流管理系统之间互操作的工作流参考模型，并相继制定了一系列工
业标准。与此同时，关于工作流技术的学术研究也十分活跃，许多原型系统在实
验室里开发出来。进入二十一世纪以来，工作流技术已被越来越多的人认可，与
之相关的标准规范、工作流引擎及商业产品不胜枚举。人们在开发推广工作流产
品的同时，更加注重工作流的理论研究，以推动该项技术走向成熟。
1.2 本文结构安排
流管理系统的概念、模型等信息和Petri 网相关基础知识进行解释；第三部分相关
工作章节简述了工作流的发展现状以及工作流的研究领域等；第四章是本文所涉
及的工作流管理系统的系统功能描述，意在从系统需求的角度在功能层上介绍本
工作流管理系统；第五部分以本工作流管理系统的系统架构为核心，分别从不同
的角度对本工作流管理系统的系统设计思想作了详细的说明；在第五部分的系统
设计基础之上，第六部分内容对本工作流管理系统的各个主要功能部件进行了关
于实现技术上的详细介绍并对作为工作流管理系统灵魂的工作流引擎的部分核心
代码进行了说明。
2 基本理论
2.1 工作流
中，“工作流”这三个字也是远远比不上DBMS 这样的术语为人熟悉和使用的程
度，这并不是说工作流技术不及DBMS
DBMS
workflow，犹如大多数计算机领域的术语一样，也是个合成词，是英文单词work
和英文单词flow 的组合。Work 翻译为任务、工作等，flow 则翻译为流程、流动
等。Flow 反映的是一种事物的动态属性或变化过程，例如水的流动被称为水流，
空气的流动被称为气流，还有物料流、资金流等，在抽象领域还有信息流、控制
流等，因此，使用任务、活动以及活动之间的变化过程表示业务流程就被称为工
作流。
念要抽象一些，但是工作流从更高的层次上提供了实现物料流、资金流、信息流
及其涉及的相关过程与应用的集成机制，从而使得企业能够实现业务过程继承、
业务过程自动化与业务过程的管理。在工作流概念下实现业务过程集成与业务过
程自动化的继承机制是通过定义不同任务之间相互关系的工作流模型（也称为过
程模型）来实现的。在工作流模型中，无论是具体的物料转移动作、实际物理装
置的操作动作、还是抽象的信息处理动作与决策过程，都可以用工作流的基本组
成元素——任务（也称为活动）来统一地描述。同样，反映不同任务之间的关系，
无论是具体的车间中零件加工顺序关系、办公自动化中的文件批转、还是抽象的
决策流之间的关系都可以用工作流的基本组成元素——连接弧来统一地进行描
述。连接弧反映了对企业业务经营过程的一种控制逻辑，它定义了活动之间的连
接关系和执行顺序。
出了各自的定义：
程规则，文档、信息或任务能够在不同的执行者之间进行传递与执行。
定义2：工作流是将一组任务组织起来完成某个经营过程。在工作流中定义了任
务的触发顺序和触发条件。每个任务可以由一个或多个软件系统完成，也可以由
一个或一组人完成，还可以是由一个或多个人与软件系统协作完成。任务的触发
顺序和触发条件用来定义并实现任务的触发、任务的同步和信息流（数据流）的
传递。
定义3：工作流是一个用来实施经营过程实践的机制。
定义4：工作流是经营过程的一种计算机化的表示模型，定义了完成整个过程所
需要的各种参数。这些参数包括对过程中每一个步骤的定义、步骤间的执行顺序、
条件以及数据流的建立、每一步骤由谁负责以及每个活动所需要的应用程序。
样一个问题，即工作流是经营过程的一个计算机实现。使用工作流作为经营过程
的实现技术首先要求工作流系统能够反映经营过程的如下几个方面问题：
2.2 工作流参考模型
这些工作流产品都有自己的特点，也有自己的协议和接口标准，它们在不同的应
用领域进行了应用。但是由于工作流管理技术与产品缺乏统一的标准，这些不同
的工作流产品从术语的定义和使用、系统结构的设计到与应用之间的接口规范上
都存在较大的差异，导致这些产品之间、产品与其它应用之间的集成十分困难。
按照对系统开放性的要求，这些工作流系统和产品的规范化程度和开放性不够，
导致它们之间不能够实现互操作。工作流管理系统互操作是指两个或多个工作流
机之间通讯和协作工作的能力，具有通讯和协作的能力就称为可以互操作，否则
就称为不能互操作。不同工作流管理系统之间不能互操作这种情况给开发商和用
户都带来了很大的不方便，也在一定程度上阻碍了工作流管理系统的推广和发展。
势，需要建立工作流管理系统的相关标准，从系统结构、术语使用、接口实施方
面提供标准化与规范化的定义，并以此为基础实现不同工作流产品之间的互操作，
方便于其它应用系统的集成。在建立工作流的相关规范和标准方面，WFMC 就是
这样的一个国际组织。它提出了有关工作流管理系统的一些规范，定义了工作流
管理系统的结构及其与应用、管理工具和其它工作流管理系统之间的应用编程接
口，其主要目的是为了实现工作流技术的标准化和开发性，从而支持异构工作流
管理系统与产品之间的互操作，并且使得其它的应用可以使用该结构和定义好的
通用API（应用编程接口）访问不同的工作流管理系统提供的服务，实现与其它
应用的快速有效集成。
个工作流参考模型（Workflow
工作流程序结构的分析，确定结构中的接口，这些接口可以使不同产品在不同的
结构层次上协同工作。所有工作流系统都包含一系列的公共组件，组件间采用一
套被定义好的方法进行协作；不同的产品在这些公共的组件中，会表现出不同的
处理能力。为了实现不同工作流产品间的协同工作，需要在这些组件间制定一套
标准的接口和数据交换格式。通过实现这些标准接口，可以达到产品间的协同工
作。
过程定义工具：以计算机能处理的形式进行过程定义，现在的大多数过程定义工
具采用了图形方式，过程设计者通过绘图方式来创建过程模型，最后输出一个
XPDL 文件，有的过程定义工具还有分析、检测功能，帮助设计者设计出良好的
过程模型。
工作流执行服务：由一个或多个工作流引擎组成，提供过程实例的执行，为活动
进行导航，与外界资源交互完成各项活动，维护控制数据和相关数据等功能。
工作流客户端应用：提供用户操作工作流管理系统分配来的任务，由工作流任务
表管理器和任务操作共同完成。工作流任务表管理器是一个软件模块，负责管理
工作流的任务表，并完成与工作流参与者的交互操作。
工作流引擎直接调用应用：在工作流任务执行过程中，一些不需要人员参与的活
动会直接调用一些应用。在简单的情况下，工作流引擎使用过程模型中定义的活
动信息、应用程序所需要的数据来激活外部应用程序；在复杂的情况下采用工具
代理的方式。工具代理与工作流引擎之间通过专用集成接口来完成数据交换和消
息传递。
系统管理和监控工具：对工作流在整个组织内的流程情况进行监控，并提供一系
列管理功能，实现安全性、过程控制、授权等操作。典型的功能范围包括用户管
理、角色管理、监控管理、资源管理、过程监控管理。具体如：过程模型的实例
化，启动、挂起、恢复、终止过程实例；管理正在执行的过程实例等。
工作流定义转换（接口1）：在建模或定义工具与运行时期工作流管理软件间的接
口。
工作流客户端应用程序接口（接口2）：客户端工作流应用程序与工作流机之间的
通信API。
应用程序调用接口（接口3）：工作流机直接调用应用程序或应用程序代理的API，
是工作流系统同应用系统通信的主要接口之一。
WAPI 协作功能接口（接口4）：工作流机同工作流机之间的通信接口，是构成分
布式工作流管理系统的主要功能接口之一。
管理和监控接口（接口5）：提供对工作流机状态以及工作流运行实例的监控和管
理的接口。
2.3 工作流管理系统
管理技术与工作流管理系统得到广泛重视的一个重要原因是它能够在信息技术的
支持下实现基于人工和计算机活动组成的业务过程的自动化，它可以实现不同自
动化程度（人工操作、半自动化、自动化过程）的规范化业务管理功能，具有良
好的适应性。因此，虽然工作流管理最早是在办公自动化领域开始进行应用的，
它在工业领域的应用同样取得了显著的成果，尤其是在制造领域得到了广泛的应
用。
定义基础上，具有如下定义。
在计算机中预先定义好的工作流逻辑推进工作流实例的执行。
定义2：工作流管理系统是支持企业经营过程高效执行并监控其执行过程的计算
机软件系统。
流管理系统为企业的业务系统运行提供了一个软件支撑环境，非常类似于在单个
计算机上的操作系统。只不过工作流管理系统支撑的范围比较大、环境比较复杂
而以，所以也有人称工作流管理系统是业务操作系统。
面操作，才能够良好地完成对企业经营过程运行的支持。所以，工作流管理系统
在一个企业或部门的经营过程中的应用过程是一个业务应用软件系统的集成与实
施过程。
企业、企业间）、不同时间跨度（分钟、小时、天、月）的经营过程。这完全取决
于实际应用背景的需求。按照经营过程以及组成活动的复杂程度的不同，工作流
管理系统可以采取许多种实施方式，在不同的实施方式中，所应用的信息技术、
通信技术和支撑系统结构会有很大的差别。工作流管理系统的实际运行环境可以
是在一个工作组内部或者在全企业的所有业务部门。
2.4.1 工作流管理系统组成部分
作流管理系统的功能组成部件和接口，它能够满足工作流管理系统和产品应该具
有的主要功能，可为实现工作流产品之间的互操作提供公共的基础。从图中可以
看出，工作流管理系统主要由三部分组成：
软件构件：完成工作流管理系统不同组成部分功能的实现，包括过程建模工具，
工作流引擎，任务表管理器和用户界面；
系统控制数据：工作流管理系统中的一个或多个软件构件使用的数据，包括过程
定义，组织/角色模型数据，工作流控制数据，工作流相关数据，任务表；
应用与应用数据：对于工作流管理系统来说，它们不是工作流管理系统的组成部
分，而是属于外部系统和数据，它们被工作流管理系统调用来完成整个或部分工
作流管理的功能，如被工作流管理系统调用的外部应用以及这些应用操作的数据。
2.4.2 工作流管理系统组件说明
过程建模工具：过程建模工具被用来创建计算机可处理的业务过程描述。它可以
是形式化的过程定义语言或对象关系模型，也可以是简单地规定用户间信息传输
的一组路由命令。
组织/角色模型：包含了组织结构和组织中角色的信息。这些信息往往与流程定义
信息紧密相关。
工作流执行系统和工作流引擎：工作流执行系统也称为过程执行环境，包括一个
或多个工作流引擎。工作流引擎是WFMS 的核心软件。它的功能包括：解释过程
定义；创建过程实例并控制其执行；调度各项活动；为用户工作表添加工作项；
通过应用程序接口（API）调用应用程序；提供监督和管理功能等。工作流执行
子系统可以包括多个工作流引擎，不同工作流引擎通过协作共同执行工作流。
工作流控制数据：被工作流执行系统和工作流引擎管理的系统数据，如工作流实
例的状态信息、每一活动的状态信息等。
工作流相关数据：指与业务过程流程相关的数据。WFMS 使用这些数据确定工作
流实例的状态转移，例如过程调度决策数据、活动间的传输数据等。工作流相关 数据既可以被工作流引擎使用，也可以被应用程序调用。是一段工作流引擎和应
用系统共享的数据区。
工作列表：流程执行中，当需要用户的交互时，工作流引擎便将工作项放置到由
任务表管理器管理的工作列表中，通过任务表管理器实现与用户的交互。
应用程序和应用数据：应用程序可以直接被WFMS
间接调用。通过应用程序调用，WFMS 部分或完全自动地完成一个活动，或者对
业务参与者的工作提供支持。与工作流控制数据和相关数据不同，应用数据对应
用程序来讲是局部数据，对WFMS 的其它部件来说是不可见的。
2.5 Petri 网
工作流过程，另一方面可以通过形式化的分析技术检查工作流模型的正确与否，
甚至对其进行性能分析。
2.5.1 Petri 网的基本元素
网模型都是由如下四种基本图元组合形成的。这四种基本图元是：
2.5.1.1 库所
地点、位置，大多数中文文献中都将place
place 和库所，它们代表同样的图元。在后继的文章中，也会使用P 来表示库所，
使用Pi（i=1，2，3…）表示在一个Petri 网模型中的某个具体的库所。
终止库所、中间库所。
网模型的唯一入口，模型实例将从该点开始并进行流程推进。起始库所的特征是，
没有指向该库所的外向弧，但可以有一个或多个从该库所指向变迁的内向弧。
网模型的唯一出口，模型实例将在该点结束流程。终止库所的特征是，没有从该
库所指向变迁的内向弧，但可以有一个或多个从变迁指向该库所得外向弧。
它是除去起始库所和终止库所外的第三类库所，通常，中间库所起到的作用是连
接变迁与变迁，中间库所根据其相对于变迁的位置的不同又可以分为输入库所和
输出库所两种。当存在一条内向弧P->T 时，我们称P 是T 的输入库所。当存在
一条外向弧T->P 时，我们称P 是T 的输出库所。
2.5.1.2 变迁
为转换、转变，大多数中文文献中都将transition 翻译为变迁是比较形象、合理的，
本文后继部分将使用变迁一词来代表transition，为了文章说明的方便，也会交替
使用transition 和变迁，它们代表同样的图元。在后继的文章中，也会使用T 来表
示变迁，使用Ti（i=1，2，3…）表示在一个Petri 网模型中的某个具体变迁。
例中可能存在的状态。一个变迁在模型实例中可能存在三种状态，分别是：常态、
就绪态和激发态。
件的变迁。
度的条件是指该变迁的所有输入库所中都至少获得了一个token，这将在工作流引
擎调度策略章节详细分析。
执行后的变迁的状态。严格来说，激发态并不是变迁的一种静态状态，而是指处
于就绪态的变迁所对应的任务被实际执行时刻的动态状态，这样来说，一个就绪
态的变迁所对应的任务实体被实际执行后变迁将处于激发态，激发态只是个瞬间
状态，进入激发态的变迁即刻处于常态，即进入新的等待调度条件的状态。图5
说明了变迁状态的变更。
2.5.1.3 弧
到的作用是连接库所和变迁，因为有弧的存在，一个Petri 网的模型最终形成了一
个有向图。根据弧的方向是从库所指向变迁还是从变迁指向库所，弧可以分为两
类：内向弧和外向弧。
文。内向弧通常使用P->T 来表示，即从place 指向transition
的弧。
文。外向弧通常使用T->P 来表示，即从transition 指向place
的弧。
角度来说明弧的方向的，因为transition 在Petri 网模型中是主要的元素，transition
也将是工作流调度引擎进行调度的主体，这将在后继的文章中说明。
2.5.1.4 标记
在大多数中文文献中都没有给出比较合适的翻译，通常选择了直接使用token 一
词，应该说在Petri 网中token 所起到的作用很难选择一个合适的中文来描述。标
记不是Petri 网静态模型的元素，而是Petri 网模型实例运行时的存在的元素。具
体来说，在Petri 网模型建模期间是不存在标记的，只有当该模型被工作流执行引
擎实例化并开始调度时存在的。标记始终是存在于库所中的，如果把库所理解为
一种容器，那么，库所的作用就是用来装标记的。Petri 网模型实例中标记在所有
库所中的分布状态就反映了一个Petri 网模型实例的运行状态。因此，token 在Petri
网中是一种运行时模型实例状态信息的载体和标记，这也是本文将token 翻译为
标记的直接原因。从这个角度来说，有些参考文献引用网络中的术语将Petri 网中
的token 翻译为令牌是不恰当的，至少是不够准确的，Petri 网中的token 从功能
上来说是一种反映模型实例运行状态的静态实体，网络中的令牌是一种处于移动
中的动态实体。Petri 网中的token 的生存期只是在某个特定的place 中从创建到消
耗的过程，并不会出现token 在不同的place 中移动的情况。这一点在后文将由具
体的解释。
2.5.2 Petri 网的触发器
变迁处于激发态的时刻是不同的。能够引起一个处于就绪态的变迁向激发态迁移
的事件被称为一个“触发器”。存在四种不同类型的触发器。
a)
b)
c)
2.5.3 Petri 网的路由
顺序路由
并行路由
条件路由
本的发散和汇聚单元：
与发散
序进行。用图表示为具有一个输入库所、两个或多个输出库所的变迁。这样，当
该变迁被激发后将为所有的输出库所产生token。
与汇聚
样，变迁只有当其所有的输入库所中都拥有了可用的token 后才能够从常态迁移
到就绪态，既是说，输入库所前并行的流程必须全部执行完，才汇聚到当前变迁，
任何一个输入库所没有可用的token，变迁都处于同步等待状态。
显示或发散
是尽可能早的确定（as early as possible）。用图表示为在变迁的输出弧上附加了条
件判断，即是说，当变迁被激发后，并不是为其所有输出库所产生token，而是要
根据输出弧上的条件，通常条件是一种bool 型的表达式，以决定是否为弧所连接
的输出库所产生token。
隐式或发散
征是尽可能晚的确定（as
发指向不同的变迁，这样，当输入库所获得token 后，哪个变迁先激发就会获得
这个token。一旦某个变迁消耗了该token，那么，另外的变迁将不再具备就绪的
条件了，也就无法被激发了。
或汇聚
的变迁中任何一个的激发都会使得其输出库所后继的变迁的状态的迁移。
3 相关工作
3.1 工作流发展现状
分解成定义良好的任务、角色，按照一定的规则和过程来执行这些任务并对它们
进行监控，达到提高工作效率、降低生产成本、提高企业生产经营管理水平和企
业竞争力的目标。
Intranet、Extranet、Internet、政府上网工程、企业上网工程、电子政府、电子商
务、电子管理、政府内部网、企业网、数字神经系统和数字化办公等一系列新概
念，这些新概念的提出背后都或多或少的存在着工作流的思想，只不过有些概念
体现的工作流思想少些，而有些概念的核心思想就是工作流的思想，如办公自动
化等。随着企业信息化步伐的加快，工作流的思想已经越来越多地进入了企业应
用系统领域。现代化企业为了增强工作效率、缩短信息传播周期、固化业务模式、
增加核心竞争力，已经将企业经营过程的各个领域各个环节均纳入了企业信息化
的部分。众多的企业应用系统按照功能从大的范围来划分，无非两种，一种是以
公文流转、日常办公为主体的办公自动化系统，另一种则是以企业经营过程的业
务流程为主要辅助对象的具体业务系统。无论是办公自动化系统还是具体业务系
统，都是为企业提供软件服务的，都是本着服务于企业需求为目标的，然而，现
实世界中的各个企业的经营过程是无时无刻不在变化和调整中的，以便适应瞬息
万变的市场。这种变更带给信息化系统软件的最大的问题在于企业经营过程的调
整往往使得原有的信息化系统软件要推倒重新设计开发，使开发成本非常的高，
寻找到一种能够相对灵活的架构和管理方式以使得信息化系统能够快速的适应企
业经营过程的变更成为了为企业构造信息化系统的软件设计人员的头等课题。工
作流及工作流管理系统之所以能为企业信息化系统所使用究其原因也在于此。虽
然工作流技术已经开始在企业应用中拥有了一片天空，然而，同已经应用于企业
的其他技术相比，工作流技术仍然处于其技术发展的初期。
趋势的曲线图上标示了工作流技术同RDBMS 技术当前发展阶段的对比。从图中
不难看出，工作流技术才刚刚处于技术的提出和初期的发展阶段，距离其发展的
高峰期还有很长的一段路。特别是当把工作流技术同已经处于稳定阶段的产品化
了的RDBMS 相比时，工作流技术发展的落后是非常明显的，然而，任何一种技
术的发展客观上都是遵循这一技术发展曲线的，都是要有个过程的，RDBMS
术能够达到今天的程度也是从其提出之初一点点地发展起来的，因此，工作流技
术尽管仍然处于其技术提出阶段，但市场对技术的需求必将加快工作流技术的发
展，加快其产品化的步伐。
已有的工作流产品大部分属于办公自动化系统，例如协同、通达、浪潮等产品。
然后，能够作为企业业务系统支撑平台的工作流产品几乎没有，企业业务系统仍
是大量的专业系统各自独立的构成的，相互集成协作的能力基本上靠传统的手工
方式人为的来操作，失去了信息化的高效性和自动性。工作流为企业业务系统提
供支撑平台的需求同当前工作流技术的发展形成了鲜明的对比，当然，需求拉动
市场，市场促进科研，随着工作流技术的成熟，最终将会进入到企业业务系统并
为其服务的。本文所设计实现的工作流管理系统主要目的也在于此。
3.2 工作流研究领域
发展，随着它在实际应用中取得的良好效果而得到了充分的重视，并且得到了迅
速的发展。相对于工作流产品市场的繁荣，工作流相关理论研究则显得有些滞后。
在过去很长一段时间里，有关工作流方面的研究主要是商品化的工作流管理系统
的开发商所领导。本着把工作流产品推向市场的目的，这些开发商大多把研究的
注意力放在了工作流管理系统的开发实施方面。目前，在工作流设计方法学、工
作流概念模型等方面还没有形成一套比较成熟的理论和方法。
系结构的研究；2 工作流模型与工作流定义语言研究；3 工作流的事务特性：研究
如何实现高级事务处理技术与工作流管理技术的结合，用定义良好的模型语义与
恢复机制来提高工作流系统的正确性与可靠性，从而能够更好地支持企业复杂的
业务过程；4
化用户界面、消息通讯、数据库、WWW 等在内的与工作流系统的设计实现有关
的各项技术及方法；5 工作流的仿真与分析方法；6 基于工作流的应用集成与互操
作技术：研究异构应用系统的集成以及不同工作流系统之间的互操作问题；7
作流与经营过程重组：研究如何通过工作流管理系统的实施来支持企业快速高效
地实现经营过程重组；8
的领域进行应用，包括在CIMS 中的应用。
工作流管理系统的体系、模型与定义语言（工作流建模方法、工作流模型的形式
化标识、工作流定义语言）等的研究。这一部分工作目前相对来说比较薄弱，还
有许多问题需要进一步研究。第二方面是工作流的实现技术，包括工作流的事务
特性、各种先进软件技术的应用、工作流仿真。这方面研究工作的主要目的是提
高工作流管理系统的性能，尤其是提高工作流管理系统的可靠性及其在处理大规
模复杂的且具有并行业务的流程方面的能力。第三方面是工作流技术的应用，包
括工作流失事技术、在不同应用领域的应用（如在企业经营过程重组、并行工程、
敏捷制造）方法、应用软件集成等。这方面研究的目的是发挥工作流管理系统的
优势，为解决具体应用领域内的问题提供有效实现手段。
4 系统描述
作流管理系统的开发目的是为企业提供各种b/s 架构的软件系统的底层流程运行
支撑平台，该工作流管理系统所支撑的软件系统按性质分为两类，分别是以公文
流转为核心的OA 系统和以企业业务活动为核心的业务系统。
4.1 系统功能描述
流程调度需求截然不同的系统。这也本工作流管理系统集中解决的问题，也是区
别于国内现有工作流管理系统的地方，国内现有工作流管理系统大多只针对以公
文流转为核心的OA 系统。
本系统的特征。基于web 技术集中体现在实现工作流管理系统的各个环节和软件
实体均是采用web 技术实现的，不同于某些工作流管理系统产品，虽然这些工作
流管理系统也称为基于web 技术的，但是，严格来说，只能说是支持web 技术的，
因为这些软件产品仅仅是为用户提供了web
ActiveX 控件。基于web 技术的另一层含义是，被工作流引擎调度的任务执行实
体也是web 方式提供的，这点对于现代企业的应用集成是非常重要的，当软件系
统逐步从原来的桌面C/S 模式转型为基于浏览器的B/S 模型后，企业中的大部分
应用系统均是B/S 架构的，如何将这些B/S 模式下运行的企业应用系统集成进工
作流管理系统，并由工作流管理系统进行集中管理和调度同样是当前工作流管理
系统软件所要挑战的课题。
于web 技术、Petri 网技术和关系数据库技术的工作流管理系统。
WFMC 的参考模型标准的，或者说系统的设计初衷是定位于一种开放性的、可扩
展的工作流管理系统。
模语言描述的，同时，工作流引擎的调度策略也是基于经典的Petri 网调度理论进
行设计实现的。
据库中并通过对关系数据库的维护来实现对业务系统流程的控制。
4.2 系统对外服务
或者称为业务系统的操作系统。本工作流管理系统作为业务系统的操作系统将对
外提供如下服务：
u
u
u
u
u
5 系统设计
结合实际的应用需求提出的一种符合WFMC
构。
5.1
5.1.1 业务系统注册服务
系统就类似于在操作系统上运行的功能软件，业务系统的运行环境就是工作流管
理系统，功能软件要想运行需要首先安装到操作系统上，然后再被操作系统来启
动并在操作系统环境中运行，那么，业务系统要想在工作流管理系统上运行，同
样需要一个类似的安装注册过程，在本工作流管理系统的系统架构中，将业务系
统向工作流管理系统注册的工作作为工作流管理系统的一种服务组建存在，即业
务系统注册服务。
能菜单设置、系统任务实体配置、系统web 服务配置等。
系统访问权限设置
系统的功能访问权限。系统访问权限的验证机制采用基于角色的访问权限控制理
论，并在该理论上有所扩充，在工作流管理系统这一底层支撑平台上提取、抽象
并接管了原本由业务系统需要处理的访问权限功能，减轻了业务系统的开发任务，
并易于统一配置和维护，关于本工作流管理系统提出并使用的基于角色的访问权
限控制的思想和实现将在第7 部分的系统性能章节详细说明。
系统功能菜单设置
一的菜单管理入口，即业务系统只需要通过系统功能菜单设置将本业务系统的菜
单树进行配置即可实现菜单在同一工作平台上的展示，并且，结合系统访问权限
的配置信息，展示给终端用户的菜单树将会根据用户的访问权限的不同而不同。
工作流管理系统提供系统功能菜单设置的功能同样简化了业务系统的开发任务，
是业务系统开发人员集中精力于业务逻辑的开发上。
系统任务实体配置
体的功能入口。具体的说，通过系统任务实体配置功能注册的任务实体将会被过
程模型定义服务在进行过程模型定义时引用，即这里注册的任务将最终被指定到
工作流模型中的transition 即变迁，作为该变迁被激发时的真正的调度运行实体。
系统web 服务配置
想。SOA 的灵活性和可扩展性是不容置疑的，它是以服务的思想为核心，以服务
提供者、服务使用者和服务注册中心为基本组成元素的新型软件架构思想。本文
第7 部分的系统性能将针对本系统所使用的SOA 系统架构思想的设计和实现进
行详细的说明。业务系统注册服务的系统web 服务配置就是为业务系统进行集中
配置系统提供的那些原始web 服务功能模块的入口。
5.1.2 过程模型定义服务
义工具，所不同的是，WFMC 的过程定义工具包括：组织模型定义、信息模型定
义、过程模型定义三个功能模块；而本工作流管理系统中的过程模型定义服务特
指WFMC 中的过程模型定义。
组织模型定义
的参与者信息的建模工具。具体的说，组织模型定义就是为流程建模人员提供的
一种在抽象层面上建立流程活动参与者的组织结构的定义工具。流程建模人员在
定义好组织结构模型后，就可以在过程模型定义时为过程中的活动指定具体的参 与者，这里的参与者就是组织模型定义时所创建的，它并不特指某个具体的操作
人员，过程模型定义期间为活动指派的参与者将在过程模型实例运行期由工作流
引擎根据组织模型定义时给出的相关信息映射到具体的操作人员上。
信息模型定义
的工作流相关数据的建模工具。工作流相关数据是由信息模型定义产生的，并由
工作流引擎和应用系统共同访问维护的数据。也就是说工作流相关数据是工作流
管理系统和应用系统的共享数据区，过程模型定义时也将引用该共享数据区的数
据字段作为流程跳转时的判断条件。
设计中进行了形式上的转变，这些转变具体为：
映射工作，这并不是说本工作流管理系统的工作流引擎在运行时无法向具体的操
作人员指派任务，之所以取消了组织模型定义，主要是基于企业原有的组织结构
数据已经非常健全，并且本工作流管理系统只针对一家企业服务，因此如果在工
作流管理系统中再增加一层组织模型的定义就显得有些冗余，并且增加了工作流
引擎的映射任务。基于此，本工作流管理系统取消了组织模型定义，代之以在过
程模型定义时直接引用企业已有的组织结构数据，简化了开发难度和系统数据冗
余，并且避免了组织模型数据和企业真实的组织结构数据的不一致性。
来由工作流引擎和应用系统共同维护，并由工作流引擎在应用系统活动之间进行
传递。这样的设计简化的工作流引擎的任务，同时使工作流相关数据同流程实例
结合的更加紧密，方便流程的反查和回退等操作。
过程模型定义
程所需要的所有信息。这些信息包括工作流程的开始和完成条件、构成工作流程
的活动以及活动的调度规则、用户所需要完成的任务以及所有工作流相关数据的
定义。过程模型定义可能引用组织模型中关于组织结构、组织中的角色等信息（具
体到本工作流管理系统的过程模型定义，就是直接引用企业已有的组织结构数据
中的信息，在后文中我们同样用组织模型来说明）。这样在进行工作流程中活动定
义时，不仅可以指定某个特定的人是这个活动的参与者，而且可以将活动与组织
实体或角色功能进行关联。
XPDL 文件，XPDL 是WFMC 提出的一种可扩展流程定义语言，本身是一种良构
的XML 文档，WFMC 提出XPDL 的目的在于统一流程定义的标准语言，以使得
不同厂商开发的流程建模工具所产生的模型文件能够互访，一旦形成了该标准模
型定义语言后，流程建模工具开发厂商和流程模型解释工具开发厂商就可以基于
相同的接口标准各自独立的开发相应的工具，很好地体现了开放性思想。
VML 技术而开发的一种完全基于WEB 技术的图形化建模工具，该图形化建模工
具产生的中间文件编码为XML 文档，不同的是，出于实际应用的角度考虑，该
中间文件XML 文档的文档结构是自定义的，没有考虑使用XPDL 格式，这主要
是考虑到XPDL 文档结构的复杂性，但是，如果将模型定义输出为XPDL 格式，
对原有的过程模型定义服务部分的变更是很容易的。
5.1.3 工作流程监控服务
要功能是对工作流管理系统上运行的应用系统流程实例进行监控、管理和性能统
计等。
该监控维护系统，监控人员可以对当前在工作流管理系统上运行的应用系统流程
实例的状态进行监控，并可以人为的干预应用系统流程实例的运行，包括可以停
止一个应用系统流程实例、挂起一个应用系统流程实例、改变应用系统流程实例
状态等操作。在企业的具体应用中，企业相关人员可以通过对当前运行的企业应
用系统流程实例的状态的监控和分析来掌控企业经营状态和对企业经营状态的全
局分析的目的。
5.1.4 通用功能接口服务
功能接口服务的软件实体是一组功能中间件，分别为以下功能部件间的通信提供
标准的通信接口：
接口；接口6 是本工作流管理系统的业务系统注册服务同在工作流管理系统上运
行的应用系统之间通信的接口，主要是应用系统对通过业务系统注册服务进行配
置了的访问权限、web 服务、菜单配置等信息的访问。
5.1.5 统一工作平台服务
任务表管理器。如果将工作流管理系统类比于计算机操作系统，那么，统一工作
平台服务软件实体的功能就类似于操作系统的桌面，它承载了终端用户登录、应
用系统菜单加载、任务列表展示、应用系统任务实体的调度和加载、访问权限控
制等功能。在企业的具体应用中，统一工作平台服务起到的作用是企业信息系统
的集成门户。
5.2 部件功能解析
分为三类部件，分别是：工作流执行服务部件、工作流功能服务部件和业务系统
应用部件。
5.2.1 工作流执行服务部件
为工作流机，以及工作流相关数据和工作流控制数据等，这些共同构成了工作流
执行服务部件，负责工作流程的调度和推进。
5.2.2 工作流功能服务部件
行服务同外部部件，包括人、应用系统等，的交互和通信功能。
5.2.3 业务系统应用部件
流管理系统的外围，也是工作流管理系统所调度执行的任务实体系统，通常是希
望运行在工作流管理系统上的企业的业务系统。
5.3 工作流引擎详解
ÿ
ÿ
ÿ
ÿ
ÿ
ÿ
ÿ
5.3.1 任务调度策略
流引擎的灵魂，也就是说任务调度策略是工作流管理系统的核心之核心。工作流
引擎的任务调度策略的性能的优劣以及调度策略能否很好的进行扩展将直接关系
到工作流管理系统的功能是否强大。
流管理系统的任务调度策略采用的是Petri
Petri 网的基本调度算法，然后结合实例说明任务是如何依据Petri 网调度算法被调
度的。
5.3.1.1 Petri 网调度算法
种基本图元：库所、变迁、弧、标记。其中，标记是一种流程实例状态信息的载 体，标记在库所中的分布情况反映的是流程实例的状态信息。Petri 网的调度算法
或者说Petri 网流程的推进过程实质上是token 的创建和消耗的过程。具体来说，
当任意一个token 被创建在某个库所中时，算法都将查看是否因为该token 的产生
而使得某些变迁从常态迁移到就绪态，根据第2 部分的介绍，即是说，是否因为
该token 的产生而使得某些变迁的所有输入库所中都至少具有了一个token，如果
存在满足该条件的变迁，那么，该变迁就从常态迁移到了就绪态，也就是说该变
迁当前可以被执行，但是，什么时候被执行将取决于该变迁的触发类型。当一个
处于就绪态的变迁被触发前，其状态一直保持为就绪态，并且会将其所有输入库
所中的一个token 进行锁定，直到该变迁被触发时，变迁才从就绪态迁移到激发
态，具体来说，一个处于就绪态的变迁被触发的过程包含如下步骤：
从该过程不难看出，变迁从就绪态迁移到激发态的过程实质上是变迁消耗其输入
库所中的token 同时为其输出库所产生token 的过程。一个token 的创建可能引起
了变迁状态的迁移，变迁状态的迁移消耗了输入库所中的token 并为其输出库所
生成新的token，新生成的token 又会重复该过程，形成了迭代。该迭代过程也就
是任务的调度过程、流程状态的改变过程。因此，前文提到过token 在库所中的
分布情况反映的是流程实例的状态信息。
始库所生成一个token，就是这个被最初放置在起始库所中的token，触发了整个
流程实例的运行。当任意时刻我们观察一个流程实例的时候，如果该时刻没有新
的token 生成时，我们称流程模型处于饱和状态，或静止状态；如果因为一个token
的产生引起了新的token 的产生并且这样的过程在瞬间迭代下去，那么，在该时 刻所观察到的流程实例将是不稳定状态，或不饱和状态，这样的状态最终将会趋
于饱和状态，也就是说流程实例将最终进入静止状态，我们称这种现象为“桌球
碰撞现象”。当桌球的球台上分布着许多桌球的时候，如果击出其中一球，该球在
运动中可能会碰撞到其它球而引起其它球的运动，而被引起运动的球在其运动过
程中又可能会引起另外的球运动，这样的迭代下去，如果某一时刻球台上仍然有
在运动的球，那么我们就说其处于不饱和状态，直到所有球都不再运行，我们说
此时处于了饱和状态或静止状态。于是，某个变迁从就绪态迁移到激发态的动作
过程所产生的新token 就好像是被击出的桌球一样，这些token 的产生很可能会引
起新的token 的生成，直到处于饱和为止。
据一个实例来说明Petri 网的调度算法。
5.3.1.2 调度实例说明
各个Petri 网模型图中白色矩形代表的是处于常态和激发态的变迁，具有花岗石底
纹的矩形代表的是当前处于就绪态的变迁。Petri 网模型图中的小黑点代表的是当
前token 的分布。
图14 说明当前模型实例刚刚被工作流引擎实例化，由工作流引擎在起始库所P1
种生成了第一个token，该token 的产生即刻引起了变迁T1 从常态迁移到了就绪
态，当前模型实例的状态并非饱和状态，因为处于就绪态的变迁T1
就绪态即刻进入激发状态（常态），该变化将会将T1
消耗掉，并为其所有输出库所P2、P3 生成新的token，模型实例进入图15 所示
的饱和状态。
图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 所示状态。
图16 所示的状态是T2 被激发后的状态，T2 的激发使得P2 中的token 被消耗，
同时为T2 的输出库所P4 产生了token，调度算法此时会尝试找到因为P4 中token
的产生而可能会成为就绪态的变迁，但是，却没有这样的变迁，因为对于变迁T4
来说，虽然其输入库所P4 拥有了token，但是，T4 的另外一个输入库所P5 中却
没有token，因此，T4 不满足从常态迁移到就绪态的条件，因此，当前模型实例
处于稳定状态。只有T3 的激发会引起模型实例状态的改变。假定此时T3 被激发
了，按照规则，将会把P3 中的token 消耗掉，同时为P5 产生新的token，状态如
图17
图17 所示的是T3 被激发后的状态，当P5 中产生token 时，调度算法尝试找到因
为P5 中token 的产生而可能会成为就绪的变迁，于是，找到了T4，T4 的状态就
从常态迁移到了就绪态，T4 的触发类型为手工触发，T4 被调度等待用户进行触
发。假定此时用户进行了触发操作，使得T4 从就绪态迁移到了激发态（常态），
按照规则，将会把其输入库所P4、P5 中的token 消耗掉，同时为其输出库所P6
产生token，模型实例进入图18 所示状态。
图18 所示状态为T4 被激发后的状态，P6 中产生了token，因为P6 是终止库所，
因此，满足了流程结束的条件，该流程实例结束。
5.3.2 对流程模型的支持
度能力。流程模型根据其创建的时机、流程中活动的性质、流程中活动的创建时
机的不同可以分为多种类型的流程模型：固定流程、自定义流程、自由流程、嵌
套流程等。
5.3.2.1 固定流程支持
改变的流程。狭义上说，固定流程特指那些由系统管理人员或流程模型定义人员
预先定义好的、在流程模型实例化和执行过程中不会发生变化的流程。广义上说，
凡是在流程模型被工作流引擎实例化和执行的过程中不会发生变化的流程模型都
可以称为固定流程，而不关心该流程模型是由系统管理人员或流程模型定义人员
预先设定好的还是由终端用户根据各自需求自行定义的。我们将那些由终端用户
根据各自需求自行定义的流程称为自定义流程。通常固定流程是企业中相对稳定
了的企业经营流程，而自定义流程是权限范围内的用户灵活设计组织的企业经营
过程。自定义流程实质上是一种特殊的固定流程，因此，后文的讨论中，出现的
固定流程是广义上包含了固定流程和自定义流程的流程模型概念。
最基本的流程模型。为了后文讨论的方便，这里简单介绍一下过程定义和过程模
型的区别和相互转换关系。
为过程定义，使用D 表示，而将工作流引擎所执行的流程称为过程模型，使用M
表示。D 是过程模型定义服务的输出文件，D 经过转换器的翻译最终形成可被工
作流引擎执行的M。这个转换器依据其功能被称为DM 转换器，反向的转换器被
称为MD 转换器，两种转换器都依据特定的转换规则进行转换操作，具体的转换规则将在系统实现部分详细介绍。图19
说明了两种模型在表现形式上的不同。
从表现形式来看，过程定义D 更接近于人的流程设计习惯，因此，过程模型定义
服务让流程设计人员所绘制的是D；过程模型M 是标准的Petri 网流程模型图，
这样的结构更利于工作流引擎基于Petri 网的调度理论对流程进行控制。这样，就
需要在过程定义D 和过程模型M 之间进行转换，这种转换是双向的，是通过工
作流管理系统所提供的DM 转换器和MD 转换器来完成的。
5.3.2.2 自由流程支持
流程模型实例可以变更的流程模型。自由流程根据其自由度的不同又可分为全自
由流程和半自由流程，全自由流程是指那些预先不存在流程模型而由终端用户的
操作发起并根据终端用户的操作进行后继活动结点的扩充的流程。半自由流程是 指那些预先存在流程模型而在流程模型被工作流引擎执行期间工作流引擎可以在
某些活动结点上根据用户的操作执行进行相应的活动结点扩充的流程。半自由流
程不同于全自由流程的是，半自由流程的活动结点的扩充是在一个预定义的主流
程的某些结点上进行的扩充，其自由度是受主流程的限制的，而全自由流程预先
不存在主流程，所有的节点都是根据终端用户的操作指令进行动态扩充的。
动结点可以自由的扩充。自由流程中活动结点的扩充在过程定义和过程模型中表
现为如下形式的变更，图20 所示。
图20 反映的是一个半自由流程在活动T2 结点处进行活动结点Ti 的扩充情况。前
文提到过，自由流程活动结点扩充的实质是工作流引擎根据用户的操作指令对原
流程模型实例进行结点扩充的操作。为了说明的方便，图中分别给出了结点扩充
操作在过程定义和过程模型上的变化情况。对该情况说明如下。当T2
流引擎将对T2 进行激发操作，工作流引擎按照主流程的定义开始调度，将T3 从
常态迁移到激发态。但是，如果在T2 上的操作用户向工作流引擎发送了扩充Ti
活动结点的操作指令，那么，工作流引擎将在原流程模型实例上在T2
行结点的扩充，反映在图的过程模型图中就是增加了库所Pi、变迁Ti 和虚线所标
示的3 条弧，并即刻将扩充后的Ti 从常态迁移到就绪态。当Ti 节点被指派的用
户进行了相关操作并提交工作流引擎时，工作流引擎消耗Pi 中的token，并为P1
产生token，该token 的产生再次使T2 进入了就绪态，对于节点T2 来说，这一次
的就绪和第一次的就绪已经截然不同了，再次就绪时，实际上已经完成了自由扩
充流程节点Ti 的操作。
毕后如何返回主流程等信息，可以汇总出如下情况。
行命名：（a）协办、（b）委托、（c）通知。
在创建了自由扩充活动节点（后面简称扩充节点）的同时要求扩充节点在执行完
成时必须返回主节点。当工作流引擎在处理这样的扩充指令时，工作流引擎对模
型实例所做的操作为：为主节点扩充一个输出库所，并为其设置token，创建一个
扩充节点，并将扩充的库所作为其输入库所，同时创建外向弧连接扩充节点到主
节点的所有输入库所上。这样，在主节点创建了扩充节点并使其就绪后，主节点
将从原来的就绪态退转为常态，等待扩充节点的返回操作再次使能自己。从该过
程的描述中可以看出，该过程非常类似现实生活中本来应该由主节点这个人独立
处理的事情，主节点却希望临时请求扩充节点这个人来协同完成，主节点希望基
于扩充节点所做出的操作进一步决定自己如何来处理这件事情，因此，我们将这
种节点扩充模式形象的称为协办，即请求协同办理的意思。
B 委托
时返回主节点在主流程中的后继节点。当工作流引擎在处理这样的扩充指令时，
工作流引擎对模型实例所做的操作为：为主节点扩充一个输出库所，并为其设置
token，创建一个扩充节点，并将扩充的库所作为其输入库所，同时创建外向弧连
接扩充节点到主节点的所有输出库所上。同a 协办模式不同的是扩充节点的外向
弧连接的不是主节点的输入库所而是主节点的所有输出库所。这样，在主节点创
建了扩充节点并使其就绪后，主节点将从原来的就绪态退转为常态，主节点已经
不再需要等待扩充节点返回了。从该过程的描述中可以看出，该过程非常类似现
实生活中本来应该由主节点这个人处理的事情，主节点却托付给了扩充节点这个
人来完成，当扩充节点完成该事情返回主流程时，对主流的推进效果等价于该任
务由主节点处理并推进流程的效果，因此，我们将这种节点扩充模式形象的称为
委托，即委托他人代办的意思。
C 通知
充节点返回主流程。当工作流引擎在处理这样的扩充指令时，工作流引擎对模型
实例所做的操作为：为主节点扩充一个输出库所，并为其设置token，创建一个扩
充节点，并将扩充的库所作为其输入库所。同a 协办、b 委托不同，在通知模式
下，工作流引擎并不为扩充节点创建外向弧。这样，在主节点创建了扩充节点并
使其就绪后，主节点消耗其输入库所的token，状态从就绪态迁移到激发态，为其
所有输出库所产生token。从该过程的描述中可以看出，该过程非常类似现实生活
中档主节点这个人在处理一件事情后向扩充节点这个人发个通知的动作，目的在
于告知扩充节点。因此，我们将这种节点扩充模式形象的称为通知。
5.3.2.3 嵌套流程支持
些独立的流程，这些独立的流程在流程模型定义的时候被父流程所引用并作为父
流程的一部分，同父流程中其他活动结点共同构成完整的流程模型，被引用的流
程模型相对引用它的流程模型来说是子流程，引用了子流程作为流程模型一部分
的流程模型就被称为嵌套流程。嵌套流程是一种高级的流程模型，也是大多数企
业经营流程建模所使用最多的流程模型类型。
的企业经营流程建模过程进行层次化的划分，可以采用自顶向下、或自底向上的
方式进行复杂流程的建模，当将一个复杂的流程层层分解为一个个相对简单的可
实施的子流程时，对复杂的企业经营流程的建模就只需要引用这些已经定义好的
子流程就可以了。同时，嵌套流程的支持还增加了对企业已有流程模型的复用性，
减轻流程建模的工作量。另外，嵌套流程的支持也为企业对其经营过程进行分析
和企业流程重组以达到最优配置提供了很好的操作平台。
希望为企业的业务系统提供业务工作流程管理的系统来说，能够实现嵌套流程的
支持是尤其重要的。嵌套流程的重要性也带来了其技术实现上的高难度，因此，目前的工作流管理系统软件中，能够很好的支持嵌套流程的非常有限。本工作流
管理系统从设计时考虑了对嵌套流程的支持，并从理论和实现技术上进行了探索，
在本节后面论述中将作详细的说明。
迁、6
在模型定义时并不像其他的变迁那样被关联到某个具体的任务实体上，而是被指
定为某个已有的子流程模型的引用，我们称T3
的，称T1、T2、T4 这样的变迁为任务实体变迁。子流程变迁同任务实体变迁一
样具有变迁的基本的3 种状态，所不同的是，子流程变迁在其状态迁移时工作流
引擎所执行的动作和任务实体变迁状态迁移时工作流引擎所执行的动作是不同
的。具体来说，当子流程变迁T3
引擎会将T3 的输入库所中的token 锁定，当工作流引擎进一步判定出T3 为一个
子流程变迁时，工作流引擎将根据模型定义时为T3
该子流程的模型定义数据并进行实例化该子流程的操作。实例化该子流程的同时，
工作流引擎会将父流程的标示以及引用该子流程的变迁T3
实例的上下文，以便子流程实例执行完成时返回。工作流引擎实例化子流程的操
作将会在该子流程实例的起始库所中放置token，于是，该子流程实例的调度运行
将依据正常的流程实例被工作流引擎所管理。与此同时，父流程中变迁T3
态一直保持就绪态，直到因其而实例化的子流程被调度执行完毕，当工作流引擎
判断出子流程已经执行完毕时，工作流引擎从子流程实例的上下文中获得该子流
程的父流程标示以及引用该子流程的变迁的标示，工作流引擎此时就可以根据获
得的父流程以及子流程变迁的标示，对子流程变迁T3 进行状态的迁移，即将T3
的状态从就绪态迁移到激发态，消耗其输入库所中锁定的token，为其输出库所产
生token，推进流程的执行。至此，T3 所引用的子流程就被工作流引擎成功调度
并执行返回推进了父流程的执行。
5.3.3 任务表管理器
单。任务表是工作流引擎同应用系统使用人员之间进行交互的窗口，如图23。
态迁移到就绪态时，就意味着工作流引擎会根据过程模型定义时为改变前设置的
组织人员、任务实体等信息决策出应该为那些人员生成什么样的任务实体工作项，
工作流引擎决策出来的这些任务项将被工作流引擎放置到任务表中，等待对应的
组织人员来获取。组织人员或称为应用系统操作人员通过登陆工作平台来从任务
表中取得指派给自己处理的任务项，并依据过程模型定义时设置的任务实体来具 体的执行该任务实体操作，对任务实体的操作具体来说可能是在某个功能叶面上
对某份产品订单作处理，也可能是对某个公文作审批处理。当操作人员完成了指
派给他的任务实体后会将该任务提交给任务表，通知工作流引擎，工作流引擎会
改变任务表中对应工作项的状态，并试图对整个过程模型实例进行推进。
6 系统实现
6.1 数据库设计
型定义数据、模型引用数据、实例静态数据、实例动态数据。
6.1.1 模型定义数据
图形建模工具，流程建模人员使用图形建模工具创建了过程定义后，经过DM 转
换器将过程定义信息转换并存储为模型定义数据形成工作流引擎可以解释执行的
Petri网语言描述的过程模型。模型定义数据包含四个表，分别是：Model_workflow、
Model_place、Model_transition、Model_arc。
Model_workflow
建时间、生效时间等。工作流模型表是流程模型的标示。
Model_place
称、库所描述、库所所属工作流模型标示等信息。
Model_transition
名称、变迁描述、变迁所属工作流模型标示、变迁所引用的角色人员、变迁所引
用的应用系统任务实体、变迁的触发类型等信息。
Model_arc
库所、弧所连接的变迁、弧的方向等信息。
化和后继调度操作提供模型数据。这四个表将作为过程模型转换器中的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 所在的place 标示，token 的状态等。
Instance_workitem
该表是工作流引擎对变迁进行调度的最终输出信息的存储区，具体说，当模型实
例中的一个变迁被工作流引擎从常态迁移为就绪态时，工作流引擎会依据过程定
义时未改变前设置的组织人员、任务实体等引用信息来决定将当前变迁所对应的 任务实体分派给哪个人或哪些人去执行，并在Instance_workitem 表中为其增加任
务项。因此，该表所存储的信息与Instance_transition 存储的信息的主要不同在于
任务实体已经被确定的指派到了某个具体的组织人员上。Instance_workitem 表的
信息将由任务表管理器进行维护。
的运行时信息。
6.2 图形建模工具
来的模型，工作流管理系统就没有执行和调度的实体。因此，一个功能强大的、
便捷的、界面友好的过程建模工具对于工作流管理系统来说尤其的重要。常见的
过程模型定义工具有两种，一种是基于传统的表单式操作的建模工具，一种是可
视化的图形建模工具。从实现的技术上来说，表单式的建模工具实现起来非常简
单，但是，对于建模人员来说，无法随时从流程的全局考虑，特别是对于功能复
杂的流程来说，使用表单式的建模工具来创建模型是一件非常痛苦的事情。图形
化建模工具就是为了方便建模人员的操作而开发的可视化的建模工具，即建模人
员就像在纸上画图一样，来使用系统提供的相关图元和界面来进行模型的创建。
当然，图形化建模工具的实现技术也是比较复杂的，通常，图形化建模工具都是
以桌面应用程序提供给建模人员的，这些桌面应用程序通常是使用vc 等开发语言
开发的，这样的图形建模工具不是基于web 技术的，即使有些图形化建模工具也
为建模人员提供浏览器操作方式，但其本质是将原来的桌面应用程序制作成
AcitveX
完全基于web技术的图形建模工具是应该让建模人员在浏览器上绘制流程的一种
工具，因此，从实现技术上来说，主要是采用某种技术来实现矢量图形的绘制功
能。在当今矢量图技术领域，最为突出的也是功能最为强大的两种技术要数VML
和SVG 了。
VML(Vector Markup Language)
提供支持。使用VML 可以在IE 中绘制矢量图形，所以有人认为VML 就是在IE
中实现了画笔的功能。下面介绍一下VML 的优点：
基于XML 标准
势，它的表示方法简单，易于扩展等等。
支持高质量的矢量图形显示
在VML 中使用两个基本的元素：shape 和group。这两个元素定义了VML 的全
部结构；shape 描述一个矢量图形元素，而group 用来将这些图形结合起来，这样
它们可以作为一个整体进行处理。
由文本构成的图像，并可集成到HTML
复杂的图像。VML 与HTML 兼容，通过在HTML 中声明VML 命名空间并声明
处理函数，就可以和其他HTML 元素一样使用VML 元素，在客户端浏览器显示
图像。VML 标记里面可以定义DHTML 大部分属性和事件，比如说id, name,
title,
onmouseover
SVG(Scalable Vector Graphics)
兼容的文档，SVG
些指令，把SVG 图像在指定设备上显示出来。使用SVG 可以在网页上显示出各 种各样的高质量的矢量图形，支持很多您想象得出的功能：几何图形、动画、渐
变色、滤镜效果等。最关键的是，它也是完全用普通文本来描述的！也就是说，
这是一种专门为网络而设计的基于文本的图像格式。
点，例如：基于XML 标准、高质量的矢量图像、由文本构成的图像。然而，SVG
却需要专门的阅读器插件才能解析，当前IE 浏览器在不安装插件的前提下是无法
解析SVG 的。
甚至在某些扩展方面SVG 要优于VML，但是，考虑到IE 对VML 的支持，在开
发本工作流管理系统的图形建模工具时选择了VML 技术。
6.2.2 输出文件格式说明
设计的时候，所有数据均保存在客户端内存中，在建模人员进行模型保存的时候
再将这些数据从客户端内存中提取出来，传送到服务器端进行保存。保存在客户
端内存中的与流程模型相关的数据根据其数据性质分为两类：绘图区图形数据和
数据岛属性数据。
绘图区图形数据
用的是VML 标记语言，因此，绘图区图形数据实质上就是建模人员创建的模型
图所对应的VML 数据。绘图区图形数据对于生成工作流引擎能够执行的过程模
型是没有任何价值的，之所以保存绘图区图形数据，目的在于建模人员再次打开
其曾经保存过的模型的时候在其主绘图区再现其最近一次保存模型时的图形信
息。如图25，VML 绘图区数据在建模人员进行模型保存操作的时候会在服务器
端被保存为一个扩展名为.vml 的文件。
数据岛属性数据
的属性信息。数据岛属性数据才是创建工作流引擎能够执行的过程模型时真正需
要的数据。数据岛属性数据是一种使用了xml 数据岛技术而缓存在客户端IE 浏览
器中的记录了建模人员所设置的模型图元属性的数据。数据岛属性数据的结构是
良构的XML 格式数据，有其自身的标记定义。
6.3 过程模型转换器
具设计绘制的更接近于人的流程模型信息，具体说就是图形建模工具输出文件中
的数据岛属性数据xml 文件。过程模型是工作流引擎能够执行的Petri 网语言描述
的流程模型信息，具体说就是存储于模型定义数据表中的数据。过程定义最终需
要转换为过程模型才能被工作流引擎执行；过程模型同样需要转换为过程定义才
能更好的为人所理解和察看。
6.3.1 DM 转换器
器的输入和输出。
DM 转换器将依据如下算法进行转换操作：
的输入和输出。
程定义的中间文件。MD 转换器并不是DM 转换器的简单的逆向操作，从MD 转
换器的输出来看，MD 转换器除了从过程模型中提取出图元属性信息生成数据岛
属性数据xml 文件外，更重要的、也是难度比较大的在于从毫无位置坐标信息的
过程模型数据中构造出具有合理布局的vml 绘图数据的vml 文件的过程。并非所
有的模型定义数据都需要MD 转换器进行转换才能得到过程定义中间文件的，对
于那些原本就是从过程定义通过DM 转换器转换得到的过程模型来说，其所对应
的过程定义中间文件在服务器上是已经存在了的，就不需要MD 转换器的反向转
换了。只有那些通过其他途径，比如表单定义、第三方工具导入等，形成的过程
模型，为了能够使用图形建模工具对其进行察看或变更时，MD 转换器的功能才
得以发挥。
本工作管理系统当前的过程模型都是通过图形建模工具创建并经过DM 转换器转换得到的，本工作流管理系统当前版本并没有提供MD 转换器的功能，将作为后
继开发工作。
6.4 工作流引擎核心代码分析
开发环境下使用C#编写的，由于篇幅原因，出于说明的方便，部分代码会结合使
用C#语句和伪码，并在某些代码上做了简化。
6.4.1 FindTransitionsCanBeEnab
所谓直接变迁是指那些以该token 所在库所为输入库所的变迁。引用桌球碰撞理
论来说明，那么，函数所查找的就是当一个桌球被击出时，因为与该球碰撞而开
始运动的那些球。
///
///
///
///
/// 创建的token
的id
///
private static ArrayList FindTransitionsCanBeEnab
{
}
该查找过程将依据如下步骤进行：
操作准备元数据。
6.4.2 EnableATransition
private static string EnableATransition( string transitionId,string
caseId,string newContext )
{