可支持多语言的工作流动态演进

邱培呸呸呸

摘  要  本文主要讨论如何实现不同定义语言的兼容性，同时设计一个组件为特定的工作流管理系统提供演进支持。对于不同的元模型（定义语言），此组件具有较好的适应性和可重用性。
    关键词  工作流；定义语言兼容性；动态演进；工作流管理系统


1  引言
    所谓工作流，就是工作任务在多个人或多个单位之间的流转，在计算机网络环境下，这种流转表现为信息或数据在多个人之间的传送。工作流管理系统（Workflow Management System，WFMS）就是通过管理一系列的工作活动以及相关人员、资源、信息技术资料来提供业务处理程序上的自动控制，其最大优点就是实现具体应用逻辑和过程逻辑的分离，实现在不修改具体功能的情况下，通过修改业务流程模板来改变系统的功能，完成对组织生产经营过程的部分业务或全部业务的集成管理，有效地把人力资源、物质资源和信息组织在一起，发挥最大的效能。
    对业务过程的强大支持是企业获得成功的一个关键因素，工作流管理系统正是用来调整业务流程及实现业务过程自动化的软件系统。工作流管理系统并不是企业的业务系统，其本身并不执行任何业务逻辑，它只为业务系统提供一个运行环境。工作流系统可分为业务过程定义和业务过程执行两部分，定义部分称为流原型（WFT），执行单元称为工作流实例（WFI），一组工作流原型称为工作流元模型（workflow meta-mode），可以通过工作流元模型来描述工作流模型。元模型用抽象的语义描述了WFT所需的上层实体，并定义了如何表示WFT，其中一种元模型可以看作是一种工作流定义语言。定义语言、WFT、WFI的概念比较难以理解，可分别同C语言、C程序、C程序进程进行类比。
    业务流程是企业应用中最活跃的部分，很难在设计阶段就提供完美的WFT以适应各种情况，因此工作流管理系统必须具备演进的能力。也就是说，即使实例已经在运行当中，也可以修改其定义，但任何修改都要保证模型与实例的正确性。一般情况下，如果没有正在运行的实例，那么对WFT的改动将不会带来什么问题。但如果一个正在被其他WFT所引用的WFT被删除时，整个工作流模型便失效了；如果WFT的改变与正在执行实例发生冲突的话，实例也就无效了。在实际生产生活中，工作流实例经常有一个较长的运行周期，因此工作流管理系统必须支持运行实例的修改，也就是在运行期间动态演进WFT。
    关于工作流的动态演进问题，目前提出的解决方案有工作原型版本化（WFT versioning）以及工作流实例迁移（migration of WFT）。一个版本代表了演进实体的一个状态，当流程发生改变时不是直接修改WFT，而是给出该WFT的一个新版本，通过运用一系列定义良好的修改操作，使新版本继承自源版本，然后通过迁移算法使正在执行中的实例依据WFT的新版本继续执行。这种方法虽然解决了动态演进问题，但修改操作及迁移算法都绑定于特定的工作流定义语言，这意味着一旦定义语言改变，则修改操作及迁移算法都不得不重新实现，因此工作流管理系统应具备处理不同定义语言的能力。
    本文将首先讨论如何实现工作流管理系统的定义语言无关性，在此基础上提出了一个WFT动态演进的方案，并设计了一个组件，它为特定的工作流管理系统提供演进支持，同时可兼容于不同的元模型（定义语言）。
2  实现工作流管理系统的定义语言无关性
    工作流是由工作流定义语言进行描述的，目前存在许多定义语言，各种语言对工作流中相同的语义有着不同的描述。由于缺乏统一的标准，很难使WFT在不同的WFMS之间移植。每种定义语言都有一套自己的概念和结构，由WFMS解释这些概念和结构，一旦改变定义语言，则WFMS的相当一部分都要重写。由于各种语言都有自己的特长，倚重或偏废任何一个都不利于技术的整体发展，因此作为独立的工作流管理系统必须具备处理各种定义语言的能力。
    可以采用“加一层”的办法来解决这个问题。在工作流定义与工作流执行引擎之间加一层所谓的“后台定义”，这样一来，由各种定义语言所描述的WFT就成了“前台定义”。如此划分可以减小不同定义语言所带来的影响，以便在工作流执行引擎的级别上保持相同的数据结构，下面通过微型工作流（micro-workflow）体系结构，来解释前、后台定义及其转换。
2.1 前台定义
    Micro-workflow有自己的定义语言，即本文所称的前台定义，它的关键抽象是过程（Procedure），一颗由过程组成的层次树便定义了一个工作流程。图1就是定义树的元模型，这里主要有两种类型的过程：


图1 micro-workflow前台定义元模型


    (1)简单过程（Simple Procedure）——这些过程表示树（指定义树，非元模型）中的叶子节点，它既可以是一个代表软件服务的过程，也可以是一个代表用户必须完成的工作过程。
    (2)复合过程（Composite Procedure）——复合过程用于表示对控制流（序列、条件等）的管理结构，是树中的非叶子节点。
2.2 后台定义
    采用基础数据结构中的有向图来进行后台定义，其中节点代表活动步骤，节点之间的连接代表流（数据流或控制流）。控制流建立了节点的执行顺序，数据流定义了从一个活动传递到另一个活动的数据，任何图都有一个开始节点和终止节点。
2.3 前台定义到后台定义的翻译
    要完成从前台到后台的翻译，前台定义模型与后台定义模型之间必须有一个完备的映射。前台定义模型提供编译规则从而生成后台定义，micro-workflow中的编译是按照自顶向下的方式完成的，它从前台定义的根部开始，递归进行，每个复合过程编译它的子节点作为其相应后台定义图中的表示。每个简单过程编译成图中的一个节点，而复合过程中的信息则成节点之间的连接，生成的结果图就是工作流引擎可任意处理的后台定义，定义编译算法时要考虑所有存在的规则，如控制流、数据流以及发送给各个节点的消息类型等。图2大体描述了一个前台到后台的映射。




图2 micro-workflow的前台/后台定义


3  工作原型修改
    一个灵活的工作流管理系统应该具备WFT的修改功能，即便是已经有实例运行在WFT上，它也可以被修改，下面将解决这个问题。首先介绍WFT版本化的概念并给出图1的扩展，然后介绍修改操作（modification operation）的概念。3.1  WFT版本化
    WFT版本化的主要思想是创建WFT的新版本而不是直接修改原有的WFT。WFT的行为信息保留在它的各个版本中，图3是图1元模型的扩展，提供了WFT版本化支持。
    一个WFT由一个或多个版本组成，并且某一版本只唯一隶属于一个WFT，也就说一个版本可以有多个子孙，但只能有一个父亲，每个版本都有一个版本号作为唯一标识。当一个新的WFT加入到工作流模型中时，便建立了此WFT的根版本。如果要施加任何修改操作，则先创建此版本的一个子孙版本，然后在新版本上进行修改操作。一个版本可处于三种状态中：临时状态、发布状态及过时状态。一个版本一旦创建便置于临时状态中，处于临时状态的版本可以进行修改或移除，但不能进行实例化也不能产生子孙版本；一旦修改操作完成则变为发布状态，处于此状态的版本不能修改或移除，但可产生新版本；最后，当发布状态的版本变失效时，它的状态被置为过时。



图3 支持版本化的工作流定义元模型

3.2  修改操作
     为了处理工作流模型，必须有一套定义良好的操作。所谓“定义良好”是指达到两个基本条件：完备性和正确性。完备性是指可以创建或移除WFT模型上的所有元素，正确性是指当完成一系列修改操作后可以保持WFT模型及实例的正确性。为了达到这两个条件，必须设置某些操作的先决条件，如果先决条件不满足，那么操作就不能执行。修改操作有两类：
    (1)CLASS 1——创建和移除WFT以及控制版本的操作。这一类操作完全独立于前台定义语言。
    (2)CLASS 2——修改WFT版本内容的操作，这些操作依赖于前台定义语言。因此当前台定义语言改变时，这些操作必须重新实现。
4  工作流实例迁移
    WFI的迁移是一个WFI绑定到一个新版本WFT的过程。当一个工作流实例w从版本wt[x]迁移到wt[y]时，它便依据wt[y]开始执行。必须保证迁移操作不会产生无效的WFI，只有当w迁移到wt[y]后仍然保持有效状态，才允许进行迁移操作。
4.1 迁移条件
    要判断工作流实例w在t时刻是否可以迁移到wt[y]，一个简单的方法是分析以往w在t时刻所包含的事件，看其是否与wt[y]兼容，也就是说必须检验t时刻的每一个事件，看迁移到wt[y]后是否会导致无效的WFI。很明显这种方法的效率不高，可以采用产生新版本WFI的修改操作（CLASS 2，参见3.2）。为了决定是否可以迁移，必须考虑每个修改操作的先决条件，修改操作OP的先决条件保证wt[y]在经过继承自wt[x]的修改操作OP后，实例w的正确性。因此如果w在时刻t可以满足所有修改操作的先决条件，则w可以在时刻t从wt[x]迁移到 wt[y]，于是迁移条件便可由修改操作导出。需要注意的是，修改操作只与前台定义相关，而迁移条件必须依据后台定义设置，这意味着实现一个修改操作必须了解后台定义模型以便生成正确的迁移条件。
    迁移算法在检查迁移条件后执行实例迁移，只要有一个迁移条件不满足，演进策略就将被激活（参见4.2）。迁移算法工作在后台定义的层次上，不需要任何前台定义的知识。
    由于修改操作直接依赖于前台定义语言并且要生成不同的迁移条件，因此采用不同的前台语言必然导致修改操作重新实现，而迁移条件按后台定义设置，迁移算法可独立于前台定义语言得到重用。
4.2 演进策略
    如上所述，工作流实例迁移依赖于对一组迁移条件的评估，对不满足迁移条件的实例，可采用以下三种方式：
    (1)Abort——放弃此工作流实例的执行。
    (2)Complete——依据老的WFT定义完成此实例的执行。
    (3)Rollback——回滚实例直到可以进行迁移操作的执行点。
    前两种动作很简单，但都有缺点。Abort将浪费大量已完成的工作，而Complete要求实例运行在一个已过时的WFT上，一般是不能接受的，Rollback策略则克服了前两种方法带来的问题。Rollback动作由单步的undo操作组成，先分析实例的执行历史，然后针对每个活动执行undo操作，通过不断的undo操作来更新执行历史，直到所有的迁移条件都满足。
和迁移算法一样，Rollback算法也工作在后台定义上，因此它可以独立于前台定义语言而获得重用。
5  演进组件体系结构
    依照上述原理，本文设计了一个工作流演进组件，此组件对工作流管理系统提供三个支持：WFT版本化管理、实例迁移管理、定义语言无关支持，以此来实现支持多语言的工作流动态演进策略。图4是该组件的体系结构图，其在逻辑上可分为三个模块：版本管理器、迁移管理器、内容管理器，如此划分可提供良好的复用性。版本管理器对WFT版本进行管理，要提供3.2中所描述的第一类操作。迁移管理器提供迁移算法、演进策略并且对迁移条件进行检测。这两个模块都工作在后台定义上，可以得到完全复用。通过前面讨论可知，要支持不同的工作流定义语言，与前台定义语言相关的修改操作是不可复用的，内容管理器正是来完成这一工作，它能提供3.2中所描述的第二类操作，将不同定义语言带来的影响限制在一个模块内。


图4 组件体系结构


6  结束语
    从目前的形势来看，对工作流技术的研究正在向深层次进行，目的有两个：一是为工作流技术发展解决理论上的问题，探讨工作流模型和语义的形式化表示方法等；二是从工作流实现技术的角度，探讨利用先进的技术提高工作流管理系统的性能和可靠性。本文研究的问题涉及到了这两个方面，提出了一种支持多语言的工作流动态演进策略，上述组件正是在深入研究工作流管理联盟提供的工作流管理系统模型和各大主流工作流管理系统的基础上设计出来的。
参考文献
[1]Workflow Management Coalition. Workflow reference model [DB/OL]. http://www.aiim.org/wfmc//standard//tc003 v11. pdf, 1995
[2] Manolescu D. Micro-workflow: a workflow architecture supporting compositional object-oriented software development [D]. University of Illinois, 2001
[3] Sergio Miguel Fernandess, Joao Cachopo, Antonio Rito Silva. Supporting evolution in workflow definition language. Technical Uniersity of Lisbon. 2003
[4] 范玉顺. 工作流管理技术基础—实现企业经营过程重组与经营过程自动化的核心技术[M] 北京：清华大学出版社，2001