优秀的工作流管理模型设计方案

工作流管理联盟（WFMC）在定义工作流的基础上，给出了工作流管理的定义，他认为，工作流管理（Workflow Management，WFM）是指人与电脑共同工作的自动化协调、控制和通信，在电脑化的业务过程上，通过在网络上运行软件，使所有命令的执行都处于受控状态。从中可以看出，工作流管理通常是结合电脑等自动化工具而进行的业务流程的管理和控制。而不同的信息工具所构建的模块或使用的方法也不尽相同，这样就给使用不同软件的用户的业务继承和互操作带来了困难。WFMC 通过分析工作流产品间的相似性，采用了模块化方式定义了一系列的标准和规范，力求实现异构工作流产品间、工作流产品与其他操作系统间的互操作。

1）工作流管理的基本模型

工作流管理模型来源于对普通工作流程序结构的分析，从中确定结构中的接口，而这些接口可以使不同产品在不同的结构层次上协同工作。所有工作流系统都包括一系列的公共组件，组件间采用一套被定义的方法进行协作；不同的产品在这些公共的组件中会表现出不同的处理能力。为实现不同工作流产品之间的协同工作，需要在这些组件之间制订一套标准的接口和数据交换格式。通过实现这些标准接口，可以达到产品的协同工作。WFMC 自1993 年成立以来，发布了包括《WFMC—TC—1003 工作流参考模型》等几十个标准和规范。本节以WFMC发布的参考模型为实例，论述工作流管理模型的基本知识和形式。

规范TC—1003 通过对工作流管理系统功能的模块化划分及定义各个模块间的接口，给出了工作流的参考模型（Workflow Reference Model），实现了WFMS 间各个层次上的互操作性，如图8.1所示，工作流模型中包括了多种组件。

图8.1　工作流参考模型

图中所示工作流执行服务周围的接口是WAPI（Workflow APIS），通过这些接口可以访问工作流系统，这些接口还控制工作流控制软件和其他系统组件间的交互。图中列出了5个接口，在这5 个接口中的许多功能，都是被两个或更多接口所同时拥有的，因此WAPI 接口可以看作统一的服务接口，可以交叉使用这5 个接口来支持工作流管理功能，而不是单独使用其中某个接口。

这5 个接口分别具有不同的功能作用：

接口1，实现不同工作流定义工具与不同工作流执行服务间的互操作性。

接口2，实现不同工作流客户端应用与不同工作流执行服务间的互操作性。

接口3，实现不同激活应用与不同工作流执行服务间的互操作性。

接口4，实现不同工作流执行服务间的互操作性。

接口5，实现不同管理与监控工具与不同工作流执行服务间的互操作性。

这5 个接口中包括了工作流客户端的应用，也就是将客户的管理纳入了工作流管理的过程中，因此，使工作流管理的模型有了客户应用的基础，也增强了企业内部管理与外部客户管理的联系，从而增加了工作流管理模型的开放性，使其实践应用的价值得到进一步的提升。

2）工作流参考模型中各个组件的含义

工作流参考模型中各个组件有不同的含义和作用。

（1）流程定义工具（Process Definition Tools）

所谓流程定义（Process Definition）是指业务流程的形式化描述。主体用于支持系统建模和运行过程自动化的实现。一个流程可分解为一系列子流程和活动，其定义的内容主要包括描述流程起始、终止的活动关系网络，以及一些关于个体行为的信息，如组织成员、与IT相关的应用和数据等。而流程定义工具（Process Definition Tools）是指提供工作流定义服务的应用工具，包括各种分析、描述和保存商业流程，它输出可以被工作流执行服务所识别的流程定义。许多工作流产品都提供了自己的流程定义工具，因此流程定义一般是保存在工作流产品范围内的，但可能不支持读/写信息的编程接口访问。

（2）工作流引擎（Workflow Engine）

工作流引擎是指为流程/活动实例的运行提供执行环境的软件服务，提供按照流程定义来执行流程的功能。一个或多个工作流引擎构成了一个工作流域。一个工作流引擎负责工作流执行服务中的部分或全部的运行控制环境。它能够处理以下几方面内容：(www.xing528.com)

·解释流程定义。

·控制过程实例——创建、激活、挂起、终止等。

·为流程的活动导航，可能包含顺序和平行的操作、最后时间期限、对工作流相关数据进行解释等。

·工作流参与者的签名和退出。

·确定任务目标，实现用户意图；提供接口，支持用户交互。

·维护工作流控制数据和工作流相关数据，在用户程序间和用户间传递工作流相关数据。

·提供调用外部程序的接口，连接所有工作流相关数据。

·提供控制、管理和审查功能。

（3）工作流执行服务（Workflow Enactment Service）

工作流执行服务由一个或多个同构或异构的工作流引擎组成，用来创建、执行和管理工作流实例，应用程序可能会通过WAPI 来和这个服务项目交互。它使用一个或多个工作流引擎，为过程实例和活动提供运行环境，负责解释和激活流程定义，与过程所需的外部资源进行交互。

在分布式工作流执行服务中，通常由几个工作流引擎分别控制一部分的流程执行服务，并且同该流程的子用户以及与流程中的活动相关的应用工具进行交互。各个工作流引擎之间使用了特定的协议和交换格式，以此来使操作、交换流程、活动控制信息达到同步。与工作流相关的数据也可以在工作流引擎之间传递，但在一个单一同构的工作流执行服务中，这些操作是由销售商制订的。

在一个由多个工作流引擎组成的工作流执行服务中，流程执行时可根据引擎的不同进行分割，分割机制可以由流程类型决定，通过使用一个特定的引擎控制一个特殊的流程类型；或者由功能作用的分布决定，通过使用一个特定的引擎机制在其本身控制范围内需要用户或者资源分配的流程。工作流执行服务可以被认为是一个状态转变机构，在这个机构中流程或活动实例通过改变状态来适应外部事件（如活动的开始和完成）。

（4）工作流客户端功能

在工作流模型中，通过客户端应用程序与工作流引擎间的定义良好的接口进行交互。在这个接口中包含工作列表——由工作流引擎分配给用户的任务序列，最简单的情况是：工作流引擎访问工作列表，把任务分配给用户；工作列表处理器访问工作列表，向工作列表中添加任务项，有许多不同的产品来实现工作列表的交互。

（5）激活应用

一个业务流程的执行通常需要和各类外部应用系统交互，完成某项任务。这类应用系统又分为两类：一类称为服务端激活应用，这种应用往往无须用户的参与而由工作流引擎负责和应用系统交互（如从MIS 系统中提取各类数据）；另一类称为客户端激活应用，这种应用往往需要用户的参与而由用户通过工作列表处理器和应用系统交互（如文字处理和电子表单）。

在一般情况下，本地工作流引擎通过使用流程定义中用于确定活动性质、调用的应用系统类型、所要求的数据等信息来激活应用系统。激活应用相对于工作流引擎可以是本地的也可以和工作流引擎在同一平台下，或者在一个独立的通过网络可以访问到的平台。但是流程定义必须包含足够的应用系统类型和地址信息来激活应用系统。在这种情况下，应用系统的命名和定位是在流程定义和工作流引擎的本地进行的。

该模型中，要求两个工作流执行服务都支持用于通信的公用API组，而且两个工作流执行服务都可以解释公用流程定义，这些公用流程可以是从一个公用流程产生处产生输入到两个工作流域的，也可以是运行阶段中在两个工作流域之间互动传递的。不同的异构工作流引擎之间也要传输工作流相关数据和应用数据。