工作流参考规范概述

【摘 要】工作流管理系统被称为下一代的企业业务操作系统。人们在普遍重视工作流应用的需求满足度和柔性驱动能力的同时，却很少关注工作流应用的规范及应用过程的本质。本文结合WfMC的规范对工作流参考模型作一概述。

【关键字】 WfMC 活动执行者 流程建模 业务组 动作

§1 工作流管理系统的主要构成

工作流管理系统（Workflow Management System，WfMS）主要由下列部件构成。

（1）过程定义工具

过程定义工具被用来创建计算机可处理的业务过程描述。它可以是形式化的过程定义语言或对象关系模型，也可以是简单地规定用户间信息传输的一组路由命令。

（2）过程定义

过程定义（数据）包含了所有使业务过程能被工作流执行子系统执行的必要信息。这些信息包括起始和终止条件、各个组成活动、活动调度规则、各业务的参与者需要做的工作、相关应用程序和数据的调用信息等。

（3）工作流执行子系统（WES）和工作流引擎

工作流执行子系统也称为（业务）过程执行环境，包括一个或多个工作流引擎。工作流引擎是WfMS的核心软件组元。它的功能包括：解释过程定义；创建过程实例并控制其执行；调度各项活动；为用户工作表添加工作项；通过应用程序接口（API）调用应用程序；提供监督和管理功能等。工作流执行子系统可以包括多个工作流引擎，不同工作流引擎通过协作共同执行工作流。

（4）工作流控制数据

指被WES和工作流引擎管理的系统数据，例如工作流实例的状态信息、每一活动的状态信息等。

（5）工作流相关数据

指与业务过程流相关的数据。WfMS使用这些数据确定工作流实例的状态转移，例如过程调度决策数据、活动间的传输数据等。工作流相关数据既可以被工作流引擎使用，也可以被应用程序调用。

（6）工作表和工作表处理程序

工作表列出了与业务过程的参与者相关的一系列工作项，工作表处理程序则对用户和工作表之间的交互进行管理。工作表处理程序完成的功能有：支持用户在工作表中选取一个工作项，重新分配工作项，通报工作项的完成，在工作项被处理的过程中调用相应的应用程序等。

（7）应用程序和应用数据

应用程序可以直接被WfMS调用或通过应用程序代理被间接调用。通过应用程序调用，WfMS部分或完全自动地完成一个活动，或者对业务参与者的工作提供支持。与工作流控制数据和相关数据不同，应用数据对应用程序来讲是局部数据，对WfMS的其他部件来说是不可见的。

§2 工作流管理系统的参考规范

国际工作流管理联盟（Workflow Management Coalition，WfMC）定义了一套完整的参考规范，主要由5个接口构成。

构建工作流管理系统的过程是一个遵循规范和标准的过程，也是一个不断创新的过程。

§2-1工作流定义交换

一、工作流定义交换模型

模拟和定义工具与工作流管理软件之间的接口被称为过程定义输入／输出接口。接口的本质是一个交换格式和一组API调用，它通过一系列物理或电子的媒介进行处理过程定义的交换。定义交换可以完整的或部分的（如只改变某个定义中的某个活动的属性）。

使用这种标准化的形式有明显的好处：

（1）它在build-Time和runtime之间定义了一个分隔点，使一个工具产生的定义可以用于多个不同的工作流产品，这样，用户可以自由地选择工作流产品。

（2）它可以将一个过程定义用于几个协作的工作流产品，实现分布的工作流服务（交换过程定义只是这种分布服务的一个方面)。

工作流定义交换接口

WfMC在这一领域作了两项工作
（1）引出一个元模型，它用于在一个处理过程定义中表示对象及其关系和属性，也可以形成用于产品之间信息交换格式的基础。
（2）工作流系统之间或工作流系统与定义工具之间的API调用，提供了一个访问工作流过程定义的公共途径，访问方式可以是只读、读写或只写，并且在元模型或一个特定的产品集（如注册产品）中操作标准对象的定义。

二、一个基本的元模型

WfMC开发了一个处理过程定义的元模型，它用来确定一组（简单的处理过程定义中初始水平的交换的）基本的对象模型，其他的对象模型由供应商提供或作进一步的探讨。

工作流元模型

假定下面的类型有这样一些属性：

工作流类型定义

 工作流处理过程名称

 版本号

 处理过程的开始和结束条件

 安全、审计和其他控制数据

活动

 活动名称

 活动类型（子流、自动流等等）

 活动的开始和结束条件

 其他时序的约束

转换条件

 流或执行条件

工作流相关数据

 数据名称和路径

 数据类型

角色

 角色名称和组织实体

调用的应用程序

 应用程序类型和名称

 参数

 位置或访问路径

在分布的服务中，工作流引擎中的活动的分配要在处理过程定义中指定（作为活动的一个属性）。处理过程的定义涉及到安全和管理，如过程中受特权控制和超级用户管理的活动，同时也要考虑其他方面。

在定义交换格式中，假定可以将一个模糊的符号命名方案映射到runtime核心服务的真实名称和地址。这可能需要动态地址机制来处理（如通过目录服务），或通过其他处理过程定义之外的机制处理。有其他的工业组织正在从事这方面的工作，如处理的模拟和CASE交换工具；WfMC的方案是同其他组织共同努力下产生的。

三、访问处理过程定义的API

WAPI中的一组API是用来访问处理过程定义数据的。期望这些规范能覆盖下面的普通类型。操作一个列表、单独的对象或属性的命令没有提供。

会话的建立

 在参与的系统之间建立/断开会话

工作流定义操作

 从一个仓库或其他资源列表中获取工作流处理过程定义的名称的清单

 从提供给会话处理的处理过程定义清单中，选择/排除一个定义

 读写最高层的工作流处理过程定义对象

工作流定义对象操作

 在工作流定义中创建、获取和删除对象

 获取、设置和删除对象的属性

工作流客户端功能

工作队列处理程序直接同系统的使用者打交道，它可能会作为一个工作流产品一部分来提供，或由用户自己编写，也可能与办公室服务一起集成在一个桌面环境中，如邮件和work-in-progress文件夹，以提供一个任务管理系统。因此，在工作流核心服务与工作流客户端应用程序之间需要一个灵活的通讯机制，以支持由不同操作系统构成的工作流系统。

在工作流模型中，客户端应用程序于工作流引擎之间通过一个接口进行交互操作，这个接口使用了工作队列的概念。

有工作流引擎赋给特定用户的工作单元的队列。最简单的情况下，工作队列可以被工作流引擎访问，以便赋给用户待处理的工作单元并获取用户处理的结果。工作队列的交互也有其他不同的产品实现途径。

从工作队列中激活一个工作单元可能在工作流客户端应用程序或用户的控制之下进行。在工作流客户端应用程序和工作流核心服务之间定义了一组过程，可以用来向队列中添加工作单元、从队列中移走完成的工作单元或挂起正在活动的工作单元等等。

工作队列处理程序也处理应用程序的调用，这些处理或是直接进行或是在用户参与下进行。由工作队列处理程序直接调用的应用程序最好放在本地环境中，虽然没有强制性的约束。

工作队列中，一部分活动的相关数据可以帮助工作队列处理程序调用应用程序。如果一个应用程序的数据类型非常固定，工作队列中就会存储一个关联。其他情况下，工作队列处理程序与工作流引擎之间需要完整的（应用程序名称和路径的）交换，这时，工作流客户端应用程序可以通过应用程序调用接口（接口3）实现一些功能，以获取必要的信息。

一个工作队列中可能包含了多个不同的活动实例，这些实例可能来自不同的处理过程。（根据不同的产品实现途径，每种类型的处理过程使用单独的物理工作队列，或者由工作队列处理程序将不同的工作队列的单元以统一的形式表达给用户。）

因此，客户端工作流应用程序与工作流引擎之间的接口必须在以下方面具有足够的灵活性：

 处理过程和活动的标识符

 资源的名称和位置

 数据的引用和数据结构

 可选的通讯机制

§2-2工作流客户端应用程序接口

满足上面要求的途径包含多个标准的API集（WAPI），这些API以统一的方式被应用程序、工作流引擎和工作队列访问，而不管实际的产品是如何实现的。

这些API及其参数将映射到不同的通讯机制以适应不同的工作流实现机制。（在基于电子邮件的通讯中，工作队列处理程序可以通过如何本地邮箱访问接口直接访问收件箱，而不是通过WAPI调用。这种情况下，工作队列处理程序将负责过滤所有非工作单元的邮件，并作适当的处理。同样，对工作流引擎的命令或响应可以直接放到发件箱中。这样，通过邮件交换格式实现了一个简单的交互，而没有完全使用WAPI。）

客户端应用接口

客户端应用程序API的全部的实现途径如图。

API的规范出版在另一个WfMC文档中；下面只提供一个关于客户端应用程序使用的API的概要。一起提供的还有操作处理过程或活动实例以及操作工作队列的命令。

会话的建立
在参与的系统之间建立/断开会话

工作流定义操作
获取或查询工作流处理过程定义的名称或属性

处理过程的控制功能
创建/启动/终止一个处理过程实例
挂起/唤醒一个处理过程实例
在一个处理过程实例或活动实例内部强制状态的转换
修改或查询一个处理过程实例或活动实例的属性（如优先级）

处理过程状态功能
打开/关闭一个处理过程或活动实例的查询，设置过滤标准
获取处理过程或活动实例的详细资料，并按指定的条件过滤
获取指定的处理过程或活动实例的详细资料

工作队列/工作单元处理功能
打开/关闭一个工作队列查询，设置过滤标准
获取工作队列单元，，并按指定的条件过滤
选择/重赋值/完成一个工作单元的通知
修改或查询工作单元的属性

处理过程的超级用户功能
下面的功能面向所有的处理过程或活动实例，并且是在超级用户的特权下才能获得的，或许需要特定的应用程序和用户登录。）
改变正在运行的工作流处理过程定义及其实例
改变所有指定类型的处理过程或活动实例的状态
改变所有指定类型的处理过程或活动实例的属性
终止所有过程实例

数据处理功能
获取或返回工作流相关数据或应用程序数据

管理功能
可以通过某种客户端应用程序实现由WAPI支持的附加的管理功能。

应用程序调用
通过工作队列处理程序的功能（如提供对处理过程／活动／工作单元属性和工作流相关数据的访问）实现了基本的应用程序调用支持。其中一些应用程序调用功能与客户端应用程序环境有关。

然而，许多工作流系统限制了它们能处理的应用程序的范围，这些应用程序的数据必须是强类型的而且必须能够直接访问（如通过目录），例如字处理或电子表格程序。其它情况下，可以通过标准的金矿机制来调用应用程序，如OSI TP协议或X.400。有些系统的实现中使用了“应用程序代理”的概念，它将应用程序的调用方法同工作流核心服务隔开。也可以通过使用标准API开发工作流应用程序工具于工作流核心服务通讯（接收应用程序数据、发出或接收活动事件等）。这些API可能直接被应用程序工具或应用程序代理使用，作为没有工作流知识的开发者的一个前端。

一些可以用于应用程序调用的接口类型

接口类型	工作流相关数据访问	参考标准
本地处理过程调用	本地文件	没有
Shell脚本	本地文件	XML/XPDL？
ORB调用	通过引用（调用参数）	有
远程执行调用	通过引用（调用参数）	有
消息传送	内置或通过引用	有
交易	内置或通过引用	有

进一步讨论将要涉及应用程序调用的所有可能的范围了。WfMC初始的工作着重考虑开发一组接口类型和一些将来用于工作流专用应用程序的API。

§2-3应用程序调用接口

下图显示了接口的框架，适用于应用程序代理和工作流应用程序。
在简单的情况下，应用程序调用都在本地发生，并且使用处理程序定义中的信息（应用程序类型和相关数据）。调用的应用程序可能在本地，也可能在网络上能访问到的其他位置。处理过程定义中包含了足够的应用程序类型和位置信息（工作流引擎需要的）。此时，应用程序命名和地址对处理过程定义和工作流引擎来说是本地的。

应用程序调用API的语法将由WfMC研究并作为规范收入文档。操作将通过几个接口进行（包括上表中的），有些是同步的、有些是异步的。下面提供了应用程序调用可能会用到的命令集。

应用程序调用接口

会话的建立
建立/断开应用程序（或应用程序代理）会话

活动管理功能
（工作流引擎到应用程序）
启动活动（工作流引擎到应用程序）
挂起/唤醒/终止活动（用于异步应用程序接口）
（应用程序到工作流引擎）
活动完成通知
产生事件（如同步）
查询活动属性

数据处理功能
给出工作流相关数据（应用程序的前驱和后继活动）
给出应用程序数据或数据地址

在更复杂的情况下，包括在不同类型的工作流引擎之间的交互操作，可能需要在工作流引擎之间传诵应用程序调用信息，或者是在运行时通过交换获得，或者是在导入过程定义时获得。

§2-4协作能力抽象规范

一、简述

这是一个WfMC标准，它提供了一个抽象的规范用以定义要求不同的工作流引擎间的协作能力的功能。WfMC的一个主要目标是制定工作流系统的标准，以使不同的工作流产品之间可以平滑地交换工作单元。

工作流产品的特点是多种多样的。在制定协同能力标准时，WfMC没有要求工作流产品供应商放弃产品特有的功能性去提供交互能力。因此，WfMC致力于开发一系列交互方案，以满足不同层次的交互（从简单的任务传递到过程定义、工作流相关数据的交换以及完整的工作流应用程序交互）。这种情况下，初始的要求是要支持简单的交互，随着情况的复杂化，在作更多的工作。

虽然可以考虑开发非常复杂的交互方案，使不同供应商提供的引擎之间协作，提供统一的核心服务，这在目前似乎还不能实现，因为这要求所有引擎都能解释公共的处理过程定义，并且它们之间要共享工作流控制数据，以维护在不同的工作流控制引擎之间共享的处理过程状态视图。当前比较现实的目标是实现在不同的核心服务之间传送处理过程。

二、一些基本概念

工作流协作能力：两个或更多的工作流引擎之间的通讯和协作能力。其目的是整理执行工作流程实例通过这些引擎。
工作流引擎：一个为工作流程实例提供运行时刻的执行环境的软件服务（引擎）。
一个工作流流程定义实例：一个工作流流程定义的实例（包括其自动化部分在内），它是由工作流管理系统创建和管理的。
一个工作流管理系统：通过软件的执行完整的定义，管理，执行工作流流程。此执行的软件命令是由工作流流程逻辑的一个计算机表示来驱动的。
一个工作流管理系统是由一个或更多的工作流设定服务组成。
一个工作流设定服务是由一个或更多的工作流引擎组成的。

业务组：在业务流转过程中，执行相同业务动作/活动的业务执行者的集合（人/系统）

三、协作能力模型

WfMC定义了大量的协同工作能力的模型，如：
（1）两个或更多的工作流引擎直接协作

工作流引擎协作

（2）两个或更多的工作流引擎在同一个设定服务里的运作

工作流设定服务

（3）在一个工作流管理系统范围内的两个或更多的工作流设定服务的协作

工作流群组设定服务

（4）协作能力的实现

两个软件工具的协作能力一般通过如下几种方式实现：

工具间的直接作用

工具间的直接作用

消息传递

消息传递

此方式在工作协作能力上的应用：

工作流协作的消息传递

中介（bridging） (采用封装，转化及网关等形式)

中介

此方式在工作协作能力上的应用：

工作流协作的中介应用

共享存储数据

工具间的共享数据存储

四、工作流流程在两个协作的引擎里执行的不同方式

链式流程

链式流程

嵌套子流程

嵌套子流程

同步并行

同步并行

交叉执行

交叉执行

§2-5 WfMC审计数据规范

一、概述

WfMC的最终目标是规范一个管理和监视功能的接口标准，通过这个接口，商家的管理应用程序可以同其他的引擎一起工作。这样，几个工作流服务可以在一定范围内共享管理和系统监视功能。此接口试图提供一个全局视图，视图中包括组织内部所有工作流动的完整的状态信息；此接口还包括与管理有关的完整的功能集，包括安全、控制和授权的考虑。

接口实现如图所示。

系统管理和监控接口

二、审计数据

审计数据:从发生在一个工作流设定服务期间的各种事件中捕捉和记录的信息。此信息被称为通用工作流审计数据（CWAD）.
通过定义这种数据的语义规范可使接口5标准化，以达到和不同工作流产品工作的能力。

三、CWAD 命名协定

命名将遵循《WfMC的 WAPI命名协定》中的标准说明。另外，新的关于属性的命名协定提议考虑属性的抽象规范。

四、CWAD 数据信息

CWAD 审计数据由三类信息组成：基础数据，自由数据，私有数据。

基础数据是被记录且对所有的审计功能有效。在这些信息里，有些定义的元素被指定为强制性的或者是可选择的。如果事件被记录，强制性的元素是必须有的。由于工作流商家的产品操作不同，有些审计信息将不适用且将被考虑作为自由数据。除了一些必须信息之外，由私有数据信息组成的是未被定义且对商家和用户的自身需要是有用的，它可以包括复杂的形式。