1       引言

目前，针对企业或者部门的计算机应用已不仅仅停留在诸如文档处理、公文流转以及信息发布等这些简单的业务层面上。越来越多的企业或部门要求将信息技术的应用扩展到关键业务中。关键业务的普遍特征是：（1）是企业或部门赖以生存的；（2）业务过程往往由许多业务活动组成，业务逻辑和业务规则复杂；（3）业务的完成依赖于其中众多业务活动之间的交互和众多的业务人员的协作参与；（4）涉及到的数据量经常是海量数据；（5）如果能将信息技术恰当地应用到这些关键业务中，不仅仅能够提高工作效率，还可以减少出错的可能性。例如，产品的设计和制造过程，银行的借贷和划账业务，还有商标的申请、审查和注册业务等等，都属于相应企业或部门的关键业务。工作流技术所具有的协调本质决定了其在关键业务的信息化过程中将扮演重要的角色。

正如文献^[1][2]所述，工作流是业务过程的计算模型，即将相应的业务逻辑和业务规则在计算机中以恰当的模型进行表示并对其实施计算。业务过程是若干业务活动的集合，这些业务活动按照一定的规则前后链接在一起，相互协作，以便达到一个共同的目标。业务活动则是能够完成特定的功能的一个实际环节，它在信息系统中通常针对具体的应用逻辑。为了对工作流管理系统的开发起到一个指导作用，工作流管理联盟（WfMC）给出了工作流系统的一个通用框架――工作流参考模型^[2]。在工作流参考模型中，工作流引擎是工作流管理系统的核心。工作流引擎是为工作流管理系统在定义提供支持、同时在运行时提供解释和执行服务的一组数据模型和软件。根据文献^[3]中对工作流引擎体系结构的讨论，我们认为工作流引擎主要包括机构模型、信息模型和控制模型三种模型，前两者合称为工作流引擎的数据模型。

本文以国家智能计算机研究开发中心所承当的一个具体的应用项目――国家商标局的商标注册与管理信息化系统为实例，同时分析了其他不同的企业和部门的关键业务的基本特征，针对关键业务的开发需求，在传统的关系DBMS的基础上，讨论一个基于关系结构的轻量级工作流引擎的具体的设计原理与实现方法。它充分考虑了关键业务开发过程中对工作流功能的需求，利用此工作流引擎，可以使用传统的开发工具构造出具有工作流特征的大型信息系统[1][1]。

本文的第2部分讨论为什么要采用关系结构和轻量级这两个概念来设计工作流引擎，第3部分给出相关的数据模型及其表示，接着，在第4部分中将描述工作流引擎的控制模型，最后还将给出具体的应用实例。

2       与关系结构和轻量级相关的一些讨论

目前，软件开发的一个普遍现象是软件产品的规模和功能越来越向大型化和复杂化的方向发展，而本文所提出的基于关系结构的轻量级工作流引擎却强调其小型化的特征。许多工作流产品从数据存储到运行环境往往都有自己的一整套独特的体系结构，它们除了具备了工作流的基本功能外，还同时宣称可以任意集成第三方的应用，甚至有的还嵌入了程度不等的应用开发的功能。但是，开发人员真正需要的可能并非这些复杂特性。

2.1  工作流的设计中心

所谓工作流的设计中心指的是由谁来定义和开发工作流的应用。那么，工作流的设计中心到底应该在哪里？Patricia Seybold Group的Ronni Marshak曾经对这个问题进行过一些有益的论述：

1) 完全由实际的业务人员来负责工作流应用的定义和开发，一些工作流产品也大力提倡这一点。的确，实际的业务人员对自己的业务规则最为熟悉，但他们对计算机技术了解不多。因此，这只适合简单的工作流应用，一旦业务逻辑比较复杂尤其是面对关键业务时，要他们将业务逻辑转换为工作流并且自己定制相应的应用逻辑，则非常困难。

2) 业务人员和专业技术人员相结合。工作流产品提供图形化的界面供业务人员（或者结合专业人员）定义业务逻辑和规则，具体的应用逻辑则由专业开发人员完成。应用的开发可以利用工作流所提供的集成开发工具，也可以利用第三方的开发工具。可能存在的问题是如果使用工作流产品所集成的开发工具的话，则其所提供的开发应用的功能是否足够；另一方面，如果使用第三方的开发工具的话，又该如何实现工作流机制的集成。

3) 还有一种观点认为，要建立真正复杂、灵活而且可扩展的应用系统，必须将工作流的开发融合到信息系统的开发过程中，从整个信息系统的角度来定义工作流中的业务规则、任务流转以及相关角色。甚至更有一种极端的观点认为应该把业务规则硬编码到具体的应用中，如果业务规则比较稳定的话，这种方法可以得到非常紧凑的应用系统，其缺点是系统的重构和复用非常困难。

我们认为，对于关键业务，第(2)或者是第(3)种模式是可行的，但必须有一个恰当的工作流引擎的支持，否则会显著地增加实际开发的难度和工作量。

2.2  为什么要基于关系结构

所谓基于关系的工作流引擎指的是工作流引擎中的数据模型（即机构模型和信息模型）全部通过关系结构来表达；控制工作流引擎运作的各种程序逻辑（即控制模型）也是通过常规关系数据库管理系统中所提供的存储过程、包以及触发器等机制来实现；同时，事务的并发控制也通过数据库系统所提供的机制来实现。

从技术角度来说，使用关系结构来表达工作流引擎中的数据模型可以降低工作流引擎开发过程中的技术难度和工作量。具体表现在：（1）与工作流引擎相关的各种控制数据（包括业务活动的状态数据）可以存储在数据库系统中；（2）与此相关的数据的完整性可以由数据库管理系统来维护；（3）利用关系结构可以方便地定义工作流引擎中的各种数据格式和数据结构；（4）可以方便地利用数据库管理系统提供的各种DML语句来操纵工作流引擎所需的各种数据。

从开发应用系统的角度来看，在同一数据库环境下为开发者提供一个基于关系结构的工作流引擎，并且如果这个工作流引擎所提供的功能可以方便地嵌入到应用的开发环境中，则可以降低开发应用的难度。这是因为：（1）针对关键业务的应用系统通常会采用一个常规的关系数据库系统作为后台的支撑；（2）应用系统的开发者往往会采用一种他们所熟悉的并且适合此数据库系统的前端开发工具来开发具体应用，这些前端开发工具一个显著特征是开发功能强大，但一般不具备工作流机制。因此，采用基于关系结构的工作流引擎很容易与应用的开发环境做到无缝的集成。

2.3  为什么要采用轻量级

轻量级的工作流引擎指的是从够用、灵活和低成本的设计原则出发，不追求工作流引擎的功能的完备和复杂，只是实现其中必不可少的功能和特征。在设计工作流引擎时主要考虑对其数据模型的定义和解释、活动之间的协调以及任务的分配和控制等功能提供支持，而不支持诸如提供内建（built-in）的应用开发工具、对应用数据的定义和完整性维护、完善的异常处理以及长事务控制等功能。

我们之所以采用“轻量级”这一特征来刻画工作流引擎主要出于如下考虑：

1）许多现有的工作流产品都在不同程度上提供了对外部工具的集成功能，部分产品还提供了基于表单的应用逻辑的定制和开发环境。但是，外部工具的多样性和复杂性决定了对外部工具的集成难以做到无缝；而工作流产品内建的开发工具除了与流行的开发工具不兼容外，其开发功能往往都比较简单。因此，对于简单的应用（例如公文流转、订单的审批等），这些产品是合适的。但是，如果是开发关键业务的应用系统（特别是行业应用系统），现有工作流产品所能提供的开发功能是远远不够的。

2）许多针对DBMS的开发工具提供了极强的应用开发手段，但是这些开发工具往往不具备对工作流的机制的支持，而现有的工作流产品由于其出发点不同，很难与其他开发环境有机地融合在一起。因此开发人员往往苦于找不到一套合适的工作流支撑系统来开发具有工作流特征应用。

3）具有工作流特征的应用的形态千变万化，要想在工作流系统中对不同的应用（包括应用数据）进行统一的表示往往不遂人意。利用这种所谓灵活的工作流系统开发出来的应用在实际运作过程中反而表现不灵活。因此，另外一种相反趋势是，应用的逻辑仍旧由专用的应用开发工具去完成，工作流引擎只管理相关的控制数据，对应用数据只提供必要的关联手段将其与控制数据联结在一起。

4）目前已经有许多中间件产品（各种应用服务器、TP等）提供了对应用事务包括长事务的控制能力，对事务控制有特殊需求的应用系统可以使用这些产品。

新西兰Massey大学的Tagg^[4]等学者对工作流引擎的描述曾经使用过“轻量级”这一术语，但其侧重点在于如何构造一个“瘦客户端”。我们的侧重点则是设计一个充分支持工作流特征的小型内核，它可以无缝地嵌入到传统的应用开发环境中。

综上所述，基于关系的轻量级工作流引擎是这样一种产品：它可以在传统的关系数据库基础之上定义工作流数据模型；它利用DBMS内嵌的编程语言来实现工作流引擎的控制逻辑；它提供了一系列比较完备的APIs，应用的开发者可以将这些APIs嵌入到自己的应用系统中从而实现具有工作流性质的信息系统。基于关系的轻量级工作流引擎的适用对象并非应用系统的最终用户，而是利用专用开发工具构造相应应用系统的专业开发人员。它为开发人员提供了驱动工作流的机制的支持，从而构造出各种灵活的具有工作流特征的应用系统。其具体表现形式为：一套表结构、一组建模工具和一系列供实际应用调用的APIs。

3       数据模型

基于关系结构的轻量级工作流引擎的数据模型包括机构模型和信息模型两部分。机构模型描述的是企业或者部门的组织机构关系，信息模型则定义工作流引擎中所用到的各种控制数据。通过数据模型，可以方便地描述关键业务的业务规则、活动的依赖关系以及任务的指派等特征。它们都通过统一的关系结构来定义。图1给出了基于关系结构的轻量级工作流引擎的数据模型的ER图（限于篇幅只给出核心表结构）。

3.1  机构模型

与机构模型相关的表主要有STAFF、DEPARTMENT、TEAM、STAFF_TEAM、ROLE和STAFF_IN_ROLE，表之间的关系已经在图中通过不同含义的连线标出。下面将有重点地对其中的一些含义作出一些解释。

DEPARTMENT和TEAM分别表示部门和团队，部门通常表示纵向的行政隶属关系，而团队通常表示横向的合作关系。DEPARTMENT和TEAM分别通过相应的SUPER_DEPT_ID和SUPER_TEAM_ID关联使得在部门之间和团队之间分别形成树状的上下级关系

STAFF记录与人员相关的个体信息，其中的LOGGING_ON指示相应的人员目前是否已经登录到系统，ON_LEAVE表示该人员是否正处于休假期，这两种信息在工作流引擎中将被作为任务分配的指示信息。STAFF中的外码DEPT_ID指明该人员所隶属的部门。关系STAFF_TEAM指定了人员与团队之间的隶属关系。

机构模型中的部门、团队、人员以及相互间的关系为大型企业尤其是从事技术工作的企业的机构建模提供了有力的支持，同时也为现代企业流行的管理模式――“矩阵管理”提供了支持。当然，对于小型机构而言，完全可以考虑只定义DEPARTMENT或者TEAM其中之一。由于DEPARTMENT和TEAM之间在ER图中并无联系，因此缺其一并不会破坏机构模型的完整性。

ROLE进一步扩展了机构模型的建模能力，关系STAFF_IN_ROLE在STAFF和ROLE之间建立起来关联。在机构模型中引入角色这一概念主要是为了增强任务指派的能力，在本文的后续内容中将对角色中的有关概念作进一步的解释。

图1  数据模型ER图

3.2  信息模型

信息模型的核心是业务活动表（简称活动）ACTIVITY，其他相关的表结构主要有业务过程PROCESS、业务规则（活动流转规则）ROUTING_RULE、活动前依赖规则PRE_RULE、任务指派规则ASSGN_RULE、任务列表TO_DO_TASK_LIST以及已完成的任务列表HAVE_DONE_TASKS。从图中可以看出，ACTIVITY与其他表之间都存在联系。

3.2.1              活动类型

每个业务过程由若干业务活动组成，不同的业务活动通过各不相同的ACT_ID来唯一标识，ACT_TYPE则指明相应活动的类型。同一个业务活动在工作流运行时可能具有多个实例（instance）。我们将活动的实例称为任务[2][2]，将属于同一业务过程的任务称为属于同一批次的任务。有的业务活动可能针对具体的业务环节，即在前台（后台）对应实际的应用逻辑；有的业务活动则不针对具体的业务环节。活动类型可以进行如下分类：

l  INITIAL，初始化活动，业务过程的第一个活动，不针对具体业务环节。

l  INTERACTION，常规交互活动，INTERACTION活动对应实际的业务环节，在前台对应实际的应用逻辑，完成此活动需要实际人员的参与。在所有活动类型中，只有INTERACTION活动才需要与实际人员交互。

l  AUTOMATION，常规自动活动，同样对应实际的业务环节，但是实际的应用逻辑位于后台，由工作流引擎自动调用完成。AUTO_EXECUTIVE指明相应应用逻辑的执行体。

l  AND_BRANCH，与分支活动，不针对具体业务环节，此活动将同时派生出若干后继活动。

l  AND_MERGE，与汇聚活动，是一同步活动，不针对具体业务环节，流经此处的任务将进行与汇聚同步。此活动将进行活动的前依赖规则检查，只有所有的前依赖规则均被满足，才可流向后继活动。

l  OR_MERGE，或汇聚活动，是一同步活动，不针对具体业务环节，流经此处的任务将进行或汇聚同步。它同样将进行活动的前依赖规则检查，但是在前依赖规则只要存在一条满足指定条件的，就可以流向后继活动。OR_MERGE_FLAG用于指定或汇聚条件。

l   VOTE_MERGE，投票汇聚活动，是一同步活动，不针对具体业务环节，同一批次的任务只有达到NUM_VOTES_NEEDED所指定的票数才可流向后继活动。

l   DUMMY，哑活动，不针对具体业务环节，它可以作为某些活动的虚拟后继活动，还可以使用它来构造更为复杂的业务规则。若哑活动有后继活动，则可以立即流向后继活动。

l   COMPLETION，终结活动，表明相应业务过程的终结，不针对具体业务环节。

3.2.2             业务规则的表示

在工作流引擎中，业务规则可以分解成活动的前依赖规则和活动的后转发规则。活动的前依赖规则指明相应活动的启动条件，启动条件是通过相应活动的直接前趋活动以及相应的状态标志来表示的，前依赖规则包含顺序、与汇聚、或汇聚和投票汇聚四种规则。活动的后转发规则指的是当前活动所对应的任务结束后该启动哪些后继活动，后转发规则包含顺序、或分支和与分支三种规则。图1中的PRE_RULE表、ROUTING_RULE表以及ACTIVITY表中的ACT_TYPE和RULE_APPLIED等字段联合表示活动的前依赖规则和后转发规则。

由于我们将各种汇聚活动单独抽取出来，因此可以用很简洁的关系结构来表达活动的前依赖和后转发规则。首先ACTIVITY表中的RULE_APPLIED字段指示相应活动应该采用何种规则判断准则，它可以有四种取值：DEFAULT、USER_DEFINED_PRE_RULE、USER_DEFINED_POST_ROUTING_RULE和USER_DEFINED_BOTH_RULE。DEFAULT表示由工作流引擎自动根据PRE_RULE表和ROUTING_RULE表来进行规则检查。考虑到业务规则的多样性，本文提供了自定义方式来表达那些无法用缺省规则表示的特殊业务规则，ACTIVITY表中的EX_PRE_RULE_FUNC和EX_POST_RULE_FUNC分别指定了前依赖和后转发规则的自定义调用接口。自定义业务规则的行为完全由相应的程序确定。一般情况下，大多数业务规则都可以直接通过DEFAULT方式表达。接下来将讨论在DEFAULT方式下前依赖规则和后转发规则的表示。

活动的后转发规则主要通过表ROUTING_RULE表示，后转发规则可以用如下四元组来表达：

Post_Routing_Rule = (PRE_ACT_ID, CURR_ACT_ID, COMPLETION_FLAG, NEXT_ACT_ID_LIST)

其含义是：在当前活动的ACT_ID为CURR_ACT_ID的情况下，如果当前活动的前趋活动的ACT_ID为PRE_ACT_ID并且当前活动的结束标记为COMPLETION_FLAG的话，工作流将流向由NEXT_ACT_ID_LIST所指明的后继活动。

前依赖规则则需联合PRE_RULE、ROUTING_RULE和ACTIVITY共同表示，前依赖规则可以用一个三元组来表达，即：

Pre_Dependency_Rule = (PRE_ACT_ID, CURR_ACT_ID, PRE_DEPNT_SET)

PRE_DEPNT_SET为前依赖活动集，其中的每一个元素又可以用另外一个三元组来表示：

Element_Pre_Depnt_Set = (DEPNT_ID, DEPNT_ACT_ID, DEPNT_ACT_STATUS)

Pre_Dependency_Rule的含义是：由前趋活动PRE_ACT_ID流转过来的当前活动CURR_ACT_ID能否启动取决于前依赖活动集PRE_DEPNT_SET中所包含的那些活动是否已经到达各自应该到达的结束状态DEPNT_ACT_STATUS。可以看出，只有在前依赖活动集中出现的那些前趋活动才可以联合构成对当前活动的约束关系，如果某个前依赖规则三元组中的PRE_DEPNT_SET为空集，则表明由此前趋活动流到当前活动的流转过程跟其他前趋活动没有任何关系，与此相应的当前活动可以立即启动。

3.2.3             任务队列和已完成任务队列

一个活动可以同时具有多个实例，即任务，这些实例可以是属于同一批次的，也可能属于不同的批次，流水号SERIAL_NO用来标识任务所属的批次，所有属于同一批次的任务具有相同的流水号；不同的任务之间则通过唯一的TASK_ID进行标识。

本文所讨论的轻量级工作流引擎并不涉及对具体的应用逻辑和应用数据的管理，但是，在工作流引擎中必须提供一种手段将任务与应用实体有机地关联起来，否则，单独的任务将不具有任何实际意义。实体标识ENTITY_ID便起到了这种桥梁作用，其取值的真实含义完全取决于应用逻辑的自身解释，例如它可以是某个编号，也可以是某个文件的名字。ENTITY_ID在业务初始化的时候设置，其值也可以在业务流转过程中被随时改变。

任务队列TO_DO_TASK_LIST用于记录那些已经创建但尚未完成的任务，位于任务队列中的任务具有四种状态：（1）PENDING，任务正处于“与汇聚”同步状态，即正在等待其他相关的前趋任务的结束；（2）WAITING，任务已经就绪，处于“等待处理”的状态；（3）PROCESSING，任务处于“正在处理”的状态；（4）PAUSING，任务处于“暂停”的状态。

已完成任务队列HAVE_DONE_TASKS用于记录那些已经正常结束的任务，COMPLETION_FLAG表示相应任务的结束标记。

STAFF_ID表示执行此任务的实际人员，GRANTOR_ID若不为空，则表示此次任务的执行过程是经过授权的，GRANTOR_ID指明相应的授权人员。

3.3  任务指派

任务指派指的是依照何种准则将任务分配给具体人员来执行。只有常规交互活动才涉及到任务指派的问题；其他活动要么在前台不具备实际的应用逻辑，要么由工作流引擎自动调用，因此与任务指派没有关系。

在前文中已经提到了机构模型和信息模型中的许多表和字段将联合用于工作流引擎的任务指派，其核心表结构为ASSGN_RULE，每一个常规交互活动在ASSGN_RULE表都对应一条记录。BASED_ON指明任务指派的基准，它可以取如下四值之一：（1）DEPT_BASED，基于部门进行任务指派，DEPT_ID用于指定执行此活动的部门；（2）TEAM_BASED，基于团队进行任务指派，TEAM_ID用于指定执行此活动的团队；（3）ROLE_BASED，基于角色进行任务指派，ROLE_ID用于指定执行此活动的角色；（4）USER_DEFINED，基于自定义的方式进行任务指派，EX_FUNC指明相应的自定义执行程序。

任务指派的基准确定了可以执行相应任务的群体，具体指派到哪些实际人员还取决于任务指派方法METHOD，METHOD可以取如下值：

l   ALL，任务将分配给由BASED_ON指定的群体中的所有人员。

l   LEAST WORKING LIST，任务将分配给指定群体中的工作量最少的人员，工作量的多少可以通过TO_DO_TASK_LIST的统计数据得到。

l   FCFA，先来先分配（First Coming First Assigning），即将任务队列中最早创建的任务分配给相应群体中最先提出执行任务请求的个体，任务的创建时间由DATE_CREATED指示。

l   PRIORITY，基于优先数分配，只适合于ROLE_BASED任务指派基准。在表STAFF_IN_ROLE中有个字段PRIORITY_NUM用于指定相应人员的优先数，此方法将把任务分配给优先数最大的人员。

l   ROUND ROBIN，轮转法，只适合于ROLE_BASED任务指派基准。ROUND_ROBIN_TOKEN为轮转令牌，任务将分配给携有轮转令牌的人员。

4       工作流引擎的控制模型

控制模型将机构模型和信息模型有机地结合在一起，它根据其中定义的业务规则对业务过程中的各项业务活动的流转以及任务指派等工作进行控制和协调。控制模型是工作流引擎的控制中心。

4.1  应用框架

图2给出了使用本文所提出的工作流引擎的应用系统的框架结构。

可视化 建模工具

流程 逻辑

应用 逻辑

流程 逻辑

应用 逻辑

流程 逻辑

应用 逻辑

数据库接口（数据库通信协议）

D B M S

机构 模型

信息 模型

日志 信息

应用 数据

引擎 控制器

C/C++接口

Java接口

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

图2  应用框架

如图2所示，“可视化建模工具”即采用一套恰当的图示化的工具来对对业务过程进行描述，然后将其转换成如机构模型和信息模型中所述及的关系结构，从而建立起工作流引擎的数据模型。因此，“可视化建模工具”是工作流引擎在构造时的定义中心，而“引擎控制器”则是工作流引擎在运行时的控制中心，它负责工作流引擎在运行时的协调、调度和控制功能。根据具体应用的开发环境的不同，工作流引擎在应用框架中为不同类型的应用提供了不同的接口，例如C/C++接口、Java接口以及直接基于数据库通信协议的接口，从而为不同类型的应用与工作流引擎的交互提供了方便。应用框架中的“应用数据”则由具体的应用逻辑自行管理，工作流引擎并不关心这部分的数据格式。

任务 队列

已完成 任务队列

日志 信息

调度 中心

任务管理

任务指派

转发控制

依赖检查

启动控制

信息 模型

机构 模型

外部接口

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

图3  引擎控制器结构图

4.2  引擎控制器

引擎控制器是工作流引擎在运行时的控制中心，图3给出了引擎控制器的控制结构图。

l       调度中心

调度中心接受从外部接口发送过来有关流程控制的请求（如业务初始化、获取任务以及结束任务等），然后根据不同的请求类型调用相应的处理模块完成与本次请求相关的操作并将结果返回。由于是在DBMS内部实现工作流引擎的控制模型，因此有关请求的并发处理等问题完全可以交给数据库管理系统来完成，也不需要诸如请求队列等形式的数据结构。因此，事实上可以将调度中心看成一个多线程的并发服务器，它可以对多个外部请求提供并发服务。对外部请求的处理过程中肯定会涉及到对内部数据结构（即工作流引擎的数据模型）中有关数据的读写和更改操作，这些数据的完整性和互斥操作则可以通过DBMS提供的各种加锁机制来实现，从而实现了多个外部请求之间的独立性。

l       任务管理

任务管理主要根据调度中心的指示完成诸如任务创建、任务状态的转换以及相关数据的维护等工作。每次“结束任务”的外部请求将触发调度中心调用“任务管理”为后继活动（如果存在的话）创建新的实例，其状态为“Pending”；同时，其他不同的外部请求也将触发“任务管理”实施任务状态的切换。任务状态转换图如图4所示。

初态

Pending

Waiting

Processing

Pausing

终态

创建任务

同步完成

获取任务

结束任务

挂起

复位

汇聚同步

 

 

 

 

 

 

 

图4 任务状态转换图

l       任务指派

任务指派处理只是针对常规交互活动，通常情况下，在任务状态由“Pending”切换到“Waiting”过程中完成任务的指派工作，即处于就绪状态的任务在通常情况下都确定了其执行者（FCFA除外）。任务指派过程首先根据任务指派基准确定可以执行此任务的群体人员，通常情况下这是一个包含多个人员的集合；然后根据任务指派方法确定由这个群体中的哪些个体来执行任务，执行任务的个体标识记录在相应任务记录的STAFF_ID字段中。在3．4节中已经对任务指派方法进行了解释，这里有两点需要特别强调：

1）如果任务指派方法是“ALL”的话，将对当前的任务记录进行拷贝，即保证每一执行任务的个体在TO_DO_TASK_LIST中都有一条对应的记录；

2）如果任务指派方法是“FCFA”的话，事实上在任务指派阶段不不作任何工作，即相应任务记录的STAFF_ID字段为空。此时任务指派工作自动隐含在获取任务的请求中，即谁先发出获取任务的请求，就自动将此类型的任务分配给谁。

l       依赖检查

依赖检查指的是活动的前依赖规则的检查，调度中心在将任务切换到就绪状态之前将进行相关的前依赖规则检查，只有满足检查条件的任务才可以进行状态的切换。前文已经描述了前依赖规则在数据模型中的表示方法，这里主要讨论在控制模型中是如何对各种前依赖规则进行处理的。

对于顺序前依赖规则，很显然，从前趋活动流转到当前活动跟其他前趋活动没有关系，PRE_DEPNT_SET为空集，当前活动的启动没有其他约束条件，相应任务可以立即由“Pending”状态转换到“Waiting”状态。

对于与汇聚前依赖规则，PRE_DEPNT_SET中指明所有参与与汇聚的其他前趋活动，只有所有相关的前趋活动均到达各自指定的结束状态DEPNT_ACT_STATUS，当前活动方可启动。

对于或汇聚前依赖规则，PRE_DEPNT_SET为空集，此规则的检查将涉及到ACTIVITY表中的OR_MERGE_FLAG，OR_MERGE_FLAG的取值可以是所有相关的前趋活动的结束标记之一或者是一个特殊的标记“ANY”。如果OR_MERGE_FLAG的值不是“ANY”，则将检查相应前趋活动的结束标记COMPLETION_FLAG是否与OR_MERGE_FLAG相同，若相同，则启动当前活动，若不相同，则不作任何处理；否则，如果OR_MERGE_FLAG的值为“ANY”，则首先结束的前趋活动将启动当前活动，后结束的活动将被丢弃。

对于投票汇聚活动，PRE_DEPNT_SET同样为空集，当前活动要等到属于同一批次任务数目达到NUM_VOTES_NEEDED的要求方可启动。属于同一批次的任务数目可以通过对TO_DO_TASK_LIST按照ACT_ID和SERIAL_NO进行统计得到。

l       转发控制

当应用发出“结束任务”的外部请求时，该请求将触发调度中心启动“转发控制”。转发控制的主要依据在工作流数据模型中定义的后转发规则，后转发规则定义了当前活动与其后继活动之间的关系。转发控制的处理过程是根据“结束任务”请求中所携带的“任务结束标记”以及相应前趋活动和当前活动的活动标识匹配ROUTING_RULE表中的记录，从而得到相应的后继活动列表NEXT_ACT_ID_LIST；然后由调度中心根据后继活动列表启动“任务管理”为相应的后继活动新建任务。

对于顺序转发以及或分支转发规则，NEXT_ACT_ID_LIST只包含一个活动；对于与分支转发规则，则NEXT_ACT_ID_LIST中将包含多个活动。

l       启动控制

启动控制负责常规自动活动的所对应的自动执行体的启动并对其活动进行监控。

5       应用实例

本文所讨论的基于关系结构的轻量级工作流引擎已经有一个具体的应用对象，即国家商标局的商标注册与管理信息化系统。这是一个大型的信息系统，总共涉及到商标局各个业务处大约18个商标处理业务，如商标新申请业务、商标变更业务以及商标转让业务等等，所有这些业务都属于商标局的关键业务；同时，这也是一个具有海量数据的信息系统，在实施我们的项目之前，商标局已经有一个早期系统存储所有已经注册的商标的信息，总共有约100万条商标，超过10G字节的历史数据，以后随着商标业务的发展以及其他商标业务的电子化，数据量估计还将增加一个数量级。

在所有的商标业务中，大部分业务过程都比较复杂，例如商标新申请业务，光主要的业务活动就超过15个，这些业务活动发生既有顺序关系，也有并行关系，大部分都包含往复关系，相互间的依赖关系也比较复杂。通过调查，我们发现现有的工作流产品在流程控制、数据处理以及应用开发上都难以满足系统的需求。这迫使我们自己去设计和实现一个如本文所述的工作流引擎。我们采用Oracle公司的Developer/2000开发商标业务的应用逻辑，然后在应用逻辑中嵌入对工作流引擎的调用从而实现流程的控制。目前，该系统已经全部开发完毕和测试工作，马上要投入正式运行。实际的应用实例表明，由于我们有一个基于关系结构的工作流引擎的支持，使得我们可以将注意力集中于应用逻辑的开发。基于关系结构的轻量级工作流引擎在关键业务的开发过程中体现出它的价值。

 

参考文献

 

[1]      Hollingsworth D. Workflow Management Coalition: The Workflow Reference Model. Document Number WFMC-TC00-1003, Brussels, 1994

[2]      WfMC. Workflow Management Coalition Specification: Terminology & Glossary. Document Number WFMC-TC-1011, Brussels, 1996

[3]      Karl R.P.H. Leung et al. The Liaision Workflow Engine Architecture. In: Proc of the 32^nd Hawaii Int’l Conf on System Sciences, Hawaii, Jan. 1999, http://www.computer.org/proceedings/Hiccs2/

[4]      R.Tagg et.al. Preliminary Design of a Lightweight Workflow Server. In: 8^th Australasian Conf on Information Systems, Australia, 1997, http://business.unisa.edu.au/acis97/

 

 

修改稿  编号：991111－1080

 

 

作者简介：

 

何清法，男，1970年生，博士研究生，研究方向为基于内容的信息检索、图形与图象处理以及信息系统与数据库。

 

李国杰，男，1943年生，院士，博士生导师，研究方向为并行处理、人工智能和高性能算法设计。

 

焦丽梅，女，1971年生，硕士，工程师，研究方向为面向对象的数据库、知识库和推理机。

 

刘力力，男，1974年生，硕士研究生，研究方向为信息系统与数据库技术。