一个具有自适应的动态工作流系统李栋栋，虎嵩林，熊锦华，李厚富（中国科学院计算技术研究所软件室, 北京 100080）E-mail: lidongdong@摘要:业务过程的不可预见性要求工作流系统能够支持各种异常处理，并能动态地适应不断改变的业务环境，而当前工作流技术的主要缺陷是缺少柔韧性和适应性来支持大部分业务过程的动态特性。
本文提出了一个具有自适应的动态工作流系统的模型，介绍了该模型中各个组成部分的功能。
然后给出了本模型中动态性的实现方法，同时针对工作流处理层的自适应性，提出了几种实现方法。
关键词:工作流管理系统；自适应工作流；异常处理；动态修改1. 前言为了更好的支持企业应用，工作流技术还有很多方面有待研究。
其中最主要的一点就是工作流的动态性和自适应性。
电子商务的兴起使得业务过程由单一组织发展到企业间的交互。
这就使得业务过程变得更加复杂和不确定。
目前的工作流产品大多不能较好的对企业在运转过程中出现的一些变化以及异常提供完善的支持。
这些异常情况包括过程的错误执行、模型与实际情况的脱节以及企业的内部及外部环境变化等。
在这种情况下，“自适应性工作流”的概念被提了出来，“自适应性工作流”的一个主要体现就是在工作流的动态修改上，这种修改不仅包括工作流过程的重新设计，而且还包括一些异常的处理，旨在提供一种内在的发现异常、避免异常以及解决异常的机制，从而提高工作流系统的适应性。
这样，开发更加灵活的工作流系统以支持动态的组织过程就成为当前工作流管理研究的重点。
工作流自适应性有下列几种必要性：企业政策、环境的改变。
企业的业务活动和环境都是不断变化的，这就要求现存的业务处理过程不断地进行重新设计和优化，以期获得更好的功效。
有些流程不能预先定义。
某些情况下，在工作流模型定义阶段，不能预先完整地定义工作流的过程逻辑，如：当流程包含的任务、任务执行的顺序、任务需要的资源不确定时。
不可预见事件。
当工作流执行过程中遇到某些外部刺激、用户干涉、或运行时间超出时…，系统如何进行处理，是工作流系统的一个关键问题。
企业技术改进。
技术改进使得软件系统面临着升级或改动，而且还会引发系统的重新配置，例如：软件组件的替换和升级、增加新的组件、改变组件接口等等。
这样，工作流的定义和修改都必须具备灵活性和柔韧性，能够动态地适应这些改进。
目前，国内大多数工作流系统灵活性、柔韧性差，不能很好实现工作流自适应的动态修改，而且对工作流的修改大都是针对工作流定义时的修改，没有提供设定性（ad-hoc）修改的方法。
本文通过研究国内外该领域的研究应用情况，设计实现了一个具有自适应的动态工作流系统。
该系统对工作流管理联盟提出的工作流参考模型进行了扩充，增加了对工作流自适应和动态修改的处理，从而使业务流程能够自适应于其动态环境的改变。
目前，该系统已经在中科院计算所的所务信息平台以及多家企业信息平台上成功使用。
本文首先介绍了当前国内外对自适应动态工作流的研究现状，然后给出了我们所设计的自适应动态工作流系统结构框架，对系统中各个组成部分进行了解释，并详细介绍了系统的自适应性和动态性实现的方法。
2. 国内外相关研究目前，工作流工作者从各个不同的角度对工作流的自适应性和动态性提出了各自的看法和解决方法。
[1]主要讲述工作流修改的方法。
提出了一个完整的、最小的、一致的原语集合，用于工作流的修改；针对正在执行实例如何灵活地适应工作流修改的问题，作者给出了三种策略：Abort，Flush，Progressive。
在[2]中作者把工作流的自适应分为四个层次：域层、处理层、资源层和结构层。
域层的自适应主要是指对正在修改的业务环境的自适应性；处理层主要是指对工作流模式和任务修改的自适应性；资源层主要是对组织结构和数据结构的自适应性；结构层主要是对技术改进和系统重新配置的自适应性。
作者还提到了实现工作流自适应性的两种方法：开放点(Open-point)法和元模型(Meta-model)法。
在[3]中，作者期望通过人工智能中的Reactive control、Planning和Scheduling技术来提高工作流系统的灵活性及适应性。
作者认为Reactive control技术可以实现自适应的过程处理，尤其适合于动态和不可预料环境下适应性的实现；Planning技术可以实现自适应的流程合成和修复；Scheduling技术可以实现自适应的资源和任务分配，无论是初始的分配还是执行过程中的动态分配，都可以采用这种技术来实现。
Edmond和Tilman曾论述过将反演计算与工作流技术相结合以提高其适应能力的思想。
3. 具有自适应性的动态工作流系统结构1.1 3.1 结构、组成适当的工作流模型和灵活的系统结构对自适应性动态工作流的管理是很重要的，我们提出的系统结构是在工作流管理联盟提出的工作流参考模型基础上改进而来，并对其进行了添加和扩展，从而可以实现工作流的动态性和自适应性。
系统结构见图1。
3.2 各个组成部分的说明工作流定义工具：包括对工作流的建模、对任务的定义、以及定义工作流模型中各个任务之间的依赖关系等功能。
提供了柔性的流程执行路径定义功能，用户可以定义在某个活动失败后流程可以继续执行的其他路径。
定义完毕后，相关数据存入相应的工作流数据库表中。
工作流引擎：是工作流执行服务的核心，负责解释过程定义、创建和执行过程实例、以及和工作流应用及客户进行通信。
与一般工作流引擎不同的是，本系统的工作流引擎中增加了自适应处理功能，使工作流处理具有了自适应性。
工作单处理器和用户接口：实现工作流用户和工作流引擎间的通信，允许用户接受工作流引擎发送的信息，并将处理结果返回给工作流引擎。
管理监控工具：监控正在执行流程实例的状态，决定是否需要加快、挂起、恢复、取消某个实例的执行。
也提供已完成流程实例的统计表单，包括总体性能、任务执行历史、每个执行者的工作量等等。
修改决策分析器：支持工作流管理员（WFA）根据工作流数据库中的日志信息、历史信息等进行分析，做出流程修改、调整等的决策。
动态修改工具：修改主要包括修改工作流的定义、修改后实例的协调、和修改后实例的执行。
修改工作流的定义主要用于设置修改规则、设定规则改变后受影响的实例、设置工作流模型的改变。
动态修改的协调主要是协调受修改影响的实例，保证这些实例在新模型下能够正确执行。
修改的执行主要是对过渡阶段工作流实例的处理，这些实例或者按照旧版本继续执行，或者按新版本执行，或者按调整后的流程路径进行执行。
验证工具：验证工作流定义和修改过程中是否有矛盾的流程、对流程各个任务的授权是否一致、是否存在资源分配的冲突等。
动态修改工具和验证工具可以使用户灵活地进行工作流修改的定义，且随时进行检验，保证修改的正确性、一致性。
实例日志：记录工作流中所有的状态变化、事件以及和控制流相关的数据等信息。
历史信息：记录目前正在运行和已经运行完毕的工作流实例的信息，用于向客户提供一些历史相关的数据信息，用于进行数据挖掘、状态查询和以后的评估等等。
版本信息：为了支持业务流程的动态灵活改进、支持工作流的设定性修改，在工作流定义被长久修改后，还必须存储修改前的工作流定义信息。
这样在数据库中就同时存放了工作流定义的多个版本信息，存放多个版本信息的必要性：(a) 某些情况下，需要恢复工作流定义到旧版本。
比如：当发现新定义的版本执行起来比旧版本效果更差时。
(b) 在同一时间内可能需要多个版本定义同时存在。
如：当某些流程实例需要根据一个版本创建，而另外一些实例则需要根据另一个版本创建。
4. 自适应性动态工作流的实现系统中动态修改和适应性实现的图示见图2。
这里只考虑了处理层的自适应性。
现详细介绍一下相关的实现方法。
4.1 动态性的实现方法我们在系统中采用了元模型和开放点相结合的方法来实现工作流的动态修改。
元模型方法：元模型是描述模型的模型。
可以用来描述工作流模型的内在联系，确定工作流模型的结构、组成元素的类型以及建模操作。
定义了一个原语操作集合，用来完成对工作流模型或任务实例的修改操作，以期实现任务的插入、任务的删除、任务的修改以及流转条件的修改。
元模型主要是对工作流模型结构上的修改，但对于某些设定型（ad-hoc）修改来说，使用元模型的方法不太适合，因为ad-hoc型修改发生的几率比较小，属于一种局部性的调整，不需要对整个工作流模型结构进行修改。
开放点方法：在工作流模型中预置特定的点，当实例执行到这些点时，可以进行修改影响任务间依赖关系的参数、为用户提供多重选择、置换和调整资源以及进行资源的动态连接和用户、角色的动态绑定等操作。
与元模型方法相反，开放点方法在处理流程某些结构上的改变时，有一些困难。
我们采用了这两种方法相结合的方法，既可以对流程结构上进行大的改变，又可以进行某些暂时性的局部调整。
4.2 动态修改语言为了更方便地实现流程的动态修改，我们设计了一种动态修改语言，可是使用这种语言直接对流程进行定义、修改。
这种语言包括了一个完整的最小操作集，能够设定任何一种修改，部分操作定义如下： 定义一个新任务Define Task<taskname> withAppTemp<apptempname>,Users<userIDlist>,Roles<roleIDlist>,Resource<nodename.tablename.fieldname，…>其中，apptempname定义任务所对应的应用模板名称。
UserIDlist定义了可以执行该任务的用户列表，RoleIDlist定义了可以执行该任务的角色列表。
Nodename.tablename.fieldname列出该任务所涉及的资源信息，nodename表示相关资源表所在的数据库节点，tablename表示相关资源表，filedname指出该任务所涉及的数据库表中的字段。
插入一个任务到工作流定义中。
Add Task<taskname1> to WF<workflowname> {BEFORE <taskname2>} {with Conditional_expression} 将一个任务插入到工作流中的一个已定义任务后，缺省表示加入到最后。
Conditional_expression指定从任务taskname2流转到任务taskname1时应满足的条件表达式。
删除工作流定义中一个已存在任务DELETE Task<taskname> from WF<workflowname>修改任务属性（如访问的数据、对应的应用、执行人员等）ALTER Task<taskname> Set{AppTemp<apptempname>,}{Users<userIDlist>,}{Roles<roleIDlist>,}{Resource<nodename.tablename.fieldname，…>}修改任务执行的顺序ChangeOrder in WF<workflowname> Set Task<taskname1>BEFORE Task<taskname2>{with Conditional_expression}1.2 4.3 自适应性本文我们主要给出了处理层的几种自适应性的实现方法：任务修改后，正在运行实例的自适应性修改定义后，系统中可能存在多个工作流定义版本，这样对系统中已经创建、正在执行的流程实例来说，根据哪种版本定义来执行，需要由管理员决定后系统来自动执行。
