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

可支持多语言的工作流动态演进4800字工作流管理系统(WorkflowManagementSystem，WFMS)就是通过管理一系列的工作活动以及相关人员、资源、信息技术资料来提供业务处理程序上的自动控制，其最大优点就是实现具体应用逻辑和过程逻辑的别离，实现在不修改具体功能的情况下，通过修改业务流程模板来改变系统的功能，完成对组织生产经营过程的局部业务或全部业务的集成管理，有效地把人力资源、物质资源和信息组织在一起，发挥最大的效能。对业务过程的强大支持是企业获得成功的一个关键因素，工作流管理系统正是用来调整业务流程及实现业务过程自动化的软件系统。工作流管理系统并不是企业的业务系统，其本身并不执行任何业务逻辑，它只为业务系统提供一个运行环境。

1.工作流系统可分为业务过程定义和业务过程执行两局部，定义局部称为流原型(WFT)，执行单元称为工作流实例(WFI)，一组工作流原型称为工作流元模型(workflowmeta-mode)，可以通过工作流元模型来描述工作流模型。元模型用抽象的语义描述了WFT所需的上层实体，并定义了如何表示WFT，其中一种元模型可以看作是一种工作流定义语言。定义语言、WFT、WFI的概念比拟难以理解，可分别同C语言、C程序、C程序进程进行类比。业务流程是企业应用中最活泼的局部，很难在设计阶段就提供完美的WFT以适应各种情况，因此工作流管理系统必须具备演进的能力。也就是说，即使实例已经在运行当中，也可以修改其定义，但任何修改都要保证模型与实例的正确性。一般情况下，如果没有正在运行的实例，则对WFT的改动将不会带来什么问题。

但如果一个正在被其他WFT所引用的WFT被删除时，整个工作流模型便失效了;如果WFT的改变与正在执行实例发生冲突的话，实例也就无效了。在实际生产生活中，工作流实例经常有一个较长的运行周期，因此工作流管理系统必须支持运行实例的修改，也就是在运行期间动态演进WFT。关于工作流的动态演进问题，目前提出的解决计划有工作原型版本化(WFTversioning)以及工作流实例迁移(migrationofWFT)。一个版本代表了演进实体的一个状态，当流程发生改变时不是直接修改WFT，而是给出该WFT的一个新版本，通过运用一系列定义良好的修改操作，使新版本继承自源版本，然后通过迁移算法使正在执行中的实例依据WFT的新版本继续执行。这种办法虽然解决了动态演进问题，但修改操作及迁移算法都绑定于特定的工作流定义语言，这意味着一旦定义语言改变，那么修改操作及迁移算法都不得不重新实现，因此工作流管理系统应具备处理不同定义语言的能力。本文将首先讨论如何实现工作流管理系统的定义语言无关性，在此根底上提出了一个WFT动态演进的计划，并设计了一个组件，它为特定的工作流管理系统提供演进支持，同时可兼容于不同的元模型(定义语言)。

2实现工作流

管理系统的定义语言无关性工作流是由工作流定义语言进行描述的，目前存在许多定义语言，各种语言对工作流中相同的语义有着不同的描述。由于不足统一的规范，很难使WFT在不同的WFMS之间移植。每种定义语言都有一套自己的概念和结构，由WFMS解释这些概念和结构，一旦改变定义语言，那么WFMS的相当一局部都要重写。由于各种语言都有自己的特长，倚重或偏废任何一个都不利于技术的整体开展，因此作为独立的工作流管理系统必须具备处理各种定义语言的能力。可以采用“加一层〞的方法来解决这个问题。在工作流定义与工作流执行引擎之间加一层所谓的“后台定义〞，这样一来，由各种定义语言所描述的WFT就成了“前台定义〞。如此划分可以减小不同定义语言所带来的影响，以便在工作流执行引擎的级别上保持相同的数据结构，下面通过微型工作流(micro-workflow)体系结构，来解释前、后台定义及其转换。

2.1前台定义Micro-workflow有自己的定义语言，即本文所称的前台定义，它的关键抽象是过程(Procedure)，一颗由过程组成的层次树便定义了一个工作流程。(1)简单过程(SimpleProcedure)——这些过程表示树(指定义树，非元模型)中的叶子节点，它既可以是一个代表软件效劳的过程，也可以是一个代表用户必须完成的工作过程。(2)复合过程(CompositeProcedure)——复合过程用于表示对控制流(序列、条件等)的管理结构，是树中的非叶子节点。

2.2后台定义采用根底数据结构中的有向图来进行后台定义，其中节点代表活动步骤，节点之间的连接代表流(数据流或控制流)。控制流建立了节点的执行顺序，数据流定义了从一个活动传递到另一个活动的数据，任何图都有一个开始节点和终止节点。

2.3前台定义到后台定义的翻译要完成从前台到后台的翻译，前台定义模型与后台定义模型之间必须有一个完备的映射。前台定义模型提供编译规那么从而生成后台定义，micro-workflow中的编译是按照自顶向下的方式完成的，它从前台定义的根部开始，递归进行，每个复合过程编译它的子节点作为其相应后台定义图中的表示。每个简单过程编译成图中的一个节点，而复合过程中的信息那么成节点之间的连接，生成的结果图就是工作流引擎可任意处理的后台定义，定义编译算法时要考虑所有存在的规那么，如控制流、数据流以及发送给各个节点的消息类型等。图2大体描述了一个前台到后台的映射。

3工作原型

修改一个灵活的工作流管理系统应该具备WFT的修改功能，即便是已经有实例运行在WFT上，它也可以被修改，下面将解决这个问题。首先介绍WFT版本化的概念并给出图1的扩展，然后介绍修改操作(modificationoperation)的概念。

3.1WFT版本化WFT版本化的主要思想是创立WFT的新版本而不是直接修改原有的WFT。WFT的行为信息保存在它的各个版本中，图3是图1元模型的扩展，提供了WFT版本化支持。一个WFT由一个或多个版本组成，并且某一版本只唯一隶属于一个WFT，也就说一个版本可以有多个子孙，但只能有一个父亲，每个版本都有一个版本号作为唯一标识。当一个新的WFT参加到工作流模型中时，便建立了此WFT的根版本。如果要施加任何修改操作，那么先创立此版本的一个子孙版本，然后在新版本上进行修改操作。一个版本可处于三种状态中：临时状态、发布状态及过时状态。一个版本一旦创立便置于临时状态中，处于临时状态的版本可以进行修改或移除，但不能进行实例化也不能产生子孙版本;一旦修改操作完成那么变为发布状态，处于此状态的版本不能修改或移除，但可产生新版本;最后，当发布状态的版本变失效时，它的状态被置为过时。

3.2修改操作为了处理工作流模型，必须有一套定义良好的操作。所谓“定义良好〞是指到达两个根本条件：完备性和正确性。完备性是指可以创立或移除WFT模型上的所有元素，正确性是指当完成一系列修改操作后可以保持WFT模型及实例的正确性。为了到达这两个条件，必须设置某些操作的先决条件，如果先决条件不满足，则操作就不能执行。修改操作有两类：(1)CLASS1——创立和移除WFT以及控制版本的操作。这一类操作完全独立于前台定义语言。(2)CLASS2——修改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的修改操作(CLASS2，参见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中所描述的第二类操作，将不同