《可支持多语言的工作流动态演进》由会员分享，可在线阅读，更多相关《可支持多语言的工作流动态演进（5页珍藏版）》请在金锄头文库上搜索。
1、1可支持多语言的工作流动态演进摘 要 本文主要讨论如何实现不同定义语言的兼容性，同时设计一个组件为特定的工作流管理系统提供演进支持。对于不同的元模型（定义语言），此组件具有较好的适应性和可重用性。 关键词 工作流；定义语言兼容性；动态演进；工作流管理系统1 引言所谓工作流，就是工作任务在多个人或多个单位之间的流转，在计算机网络环境下，这种流转表现为信息或数据在多个人之间的传送。工作流管理系统（Workflow Management System，WFMS）就是通过管理一系列的工作活动以及相关人员、资源、信息技术资料来提供业务处理程序上的自动控制，其最大优点就是实现具体应用逻辑和过程逻辑的分离，
2、实现在不修改具体功能的情况下，通过修改业务流程模板来改变系统的功能，完成对组织生产经营过程的部分业务或全部业务的集成管理，有效地把人力资源、物质资源和信息组织在一起，发挥最大的效能。对业务过程的强大支持是企业获得成功的一个关键因素，工作流管理系统正是用来调整业务流程及实现业务过程自动化的软件系统。工作流管理系统并不是企业的业务系统，其本身并不执行任何业务逻辑，它只为业务系统提供一个运行环境。工作流系统可分为业务过程定义和业务过程执行两部分，定义部分称为流原型（WFT），执行单元称为工作流实例（WFI），一组工作流原型称为工作流元模型（workflow meta-mode），可以通过工作流元模型
3、来描述工作流模型。元模型用抽象的语义描述了 WFT 所需的上层实体，并定义了如何表示 WFT，其中一种元模型可以看作是一种工作流定义语言。定义语言、WFT、WFI 的概念比较难以理解，可2分别同 C 语言、C 程序、C 程序进程进行类比。业务流程是企业应用中最活跃的部分，很难在设计阶段就提供完美的 WFT 以适应各种情况，因此工作流管理系统必须具备演进的能力。也就是说，即使实例已经在运行当中，也可以修改其定义，但任何修改都要保证模型与实例的正确性。一般情况下，如果没有正在运行的实例，那么对 WFT 的改动将不会带来什么问题。但如果一个正在被其他 WFT 所引用的 WFT 被删除时，整个工作流模
4、型便失效了；如果 WFT 的改变与正在执行实例发生冲突的话，实例也就无效了。在实际生产生活中，工作流实例经常有一个较长的运行周期，因此工作流管理系统必须支持运行实例的修改，也就是在运行期间动态演进 WFT。关于工作流的动态演进问题，目前提出的解决方案有工作原型版本化（WFT versioning）以及工作流实例迁移（migration of WFT）。一个版本代表了演进实体的一个状态，当流程发生改变时不是直接修改 WFT，而是给出该 WFT 的一个新版本，通过运用一系列定义良好的修改操作，使新版本继承自源版本，然后通过迁移算法使正在执行中的实例依据 WFT 的新版本继续执行。这种方法虽然解决了
5、动态演进问题，但修改操作及迁移算法都绑定于特定的工作流定义语言，这意味着一旦定义语言改变，则修改操作及迁移算法都不得不重新实现，因此工作流管理系统应具备处理不同定义语言的能力。本文将首先讨论如何实现工作流管理系统的定义语言无关性，在此基础上提出了一个 WFT 动态演进的方案，并设计了一个组件，它为特定的工作流管理系统提供演进支持，同时可兼容于不同的元模型（定义语言）。2 实现工作流管理系统的定义语言无关性工作流是由工作流定义语言进行描述的，目前存在许多定义语言，各种语言对工3作流中相同的语义有着不同的描述。由于缺乏统一的标准，很难使 WFT 在不同的 WFMS 之间移植。每种定义语言都有一套自
6、己的概念和结构，由 WFMS 解释这些概念和结构，一旦改变定义语言，则 WFMS 的相当一部分都要重写。由于各种语言都有自己的特长，倚重或偏废任何一个都不利于技术的整体发展，因此作为独立的工作流管理系统必须具备处理各种定义语言的能力。可以采用“加一层”的办法来解决这个问题。在工作流定义与工作流执行引擎之间加一层所谓的“后台定义”，这样一来，由各种定义语言所描述的 WFT 就成了“前台定义”。如此划分可以减小不同定义语言所带来的影响，以便在工作流执行引擎的级别上保持相同的数据结构，下面通过微型工作流（micro-workflow）体系结构，来解释前、后台定义及其转换。2.1 前台定义Micro-
7、workflow 有自己的定义语言，即本文所称的前台定义，它的关键抽象是过程（Procedure），一颗由过程组成的层次树便定义了一个工作流程。图 1 就是定义树的元模型，这里主要有两种类型的过程：图 1 micro-workflow 前台定义元模型(1)简单过程（Simple Procedure）这些过程表示树（指定义树，非元模型）中的叶子节点，它既可以是一个代表软件服务的过程，也可以是一个代表用户必须完成的工作过程。(2)复合过程（Composite Procedure）复合过程用于表示对控制流（序列、条件等）的管理结构，是树中的非叶子节点。2.2 后台定义4采用基础数据结构中的有向图来进
8、行后台定义，其中节点代表活动步骤，节点之间的连接代表流（数据流或控制流）。控制流建立了节点的执行顺序，数据流定义了从一个活动传递到另一个活动的数据，任何图都有一个开始节点和终止节点。2.3 前台定义到后台定义的翻译要完成从前台到后台的翻译，前台定义模型与后台定义模型之间必须有一个完备的映射。前台定义模型提供编译规则从而生成后台定义，micro-workflow 中的编译是按照自顶向下的方式完成的，它从前台定义的根部开始，递归进行，每个复合过程编译它的子节点作为其相应后台定义图中的表示。每个简单过程编译成图中的一个节点，而复合过程中的信息则成节点之间的连接，生成的结果图就是工作流引擎可任意处理的
9、后台定义，定义编译算法时要考虑所有存在的规则，如控制流、数据流以及发送给各个节点的消息类型等。图 2 大体描述了一个前台到后台的映射。图 2 micro-workflow 的前台/后台定义3 工作原型修改一个灵活的工作流管理系统应该具备 WFT 的修改功能，即便是已经有实例运行在 WFT 上，它也可以被修改，下面将解决这个问题。首先介绍 WFT 版本化的概念并给出图 1 的扩展，然后介绍修改操作（modification operation）的概念。3.1 WFT 版本化WFT 版本化的主要思想是创建 WFT 的新版本而不是直接修改原有的WFT。WFT 的行为信息保留在它的各个版本中，图 3
10、是图 1 元模型的扩展，提供了 WFT 版本化支持。一个 WFT 由一个或多个版本组成，并且某一版本只唯一隶属于一个 WFT，也就说一个版本可以有多个子孙，但只能有一个父亲，每个版本都有一个版本号作为5唯一标识。当一个新的 WFT 加入到工作流模型中时，便建立了此 WFT 的根版本。如果要施加任何修改操作，则先创建此版本的一个子孙版本，然后在新版本上进行修改操作。一个版本可处于三种状态中：临时状态、发布状态及过时状态。一个版本一旦创建便置于临时状态中，处于临时状态的版本可以进行修改或移除，但不能进行实例化也不能产生子孙版本；一旦修改操作完成则变为发布状态，处于此状态的版本不能修改或移除，但可产
11、生新版本；最后，当发布状态的版本变失效时，它的状态被置为过时。图 3 支持版本化的工作流定义元模型3.2 修改操作为了处理工作流模型，必须有一套定义良好的操作。所谓“定义良好”是指达到两个基本条件：完备性和正确性。完备性是指可以创建或移除 WFT 模型上的所有元素，正确性是指当完成一系列修改操作后可以保持 WFT 模型及实例的正确性。为了达到这两个条件，必须设置某些操作的先决条件，如果先决条件不满足，那么操作就不能执行。修改操作有两类：(1)CLASS 1创建和移除 WFT 以及控制版本的操作。这一类操作完全独立于前台定义语言。(2)CLASS 2修改 WFT 版本内容的操作，这些操作依赖于前
12、台定义语言。因此当前台定义语言改变时，这些操作必须重新实现。4 工作流实例迁移WFI 的迁移是一个 WFI 绑定到一个新版本 WFT 的过程。当一个工作流实例 w从版本 wtx迁移到 wty时，它便依据 wty开始执行。必须保证迁移操作不会产6生无效的 WFI，只有当 w 迁移到 wty后仍然保持有效状态，才允许进行迁移操作。 4.1 迁移条件要判断工作流实例 w 在 t 时刻是否可以迁移到 wty，一个简单的方法是分析以往 w 在 t 时刻所包含的事件，看其是否与 wty兼容，也就是说必须检验 t 时刻的每一个事件，看迁移到 wty后是否会导致无效的 WFI。很明显这种方法的效率不高，可以采
13、用产生新版本 WFI 的修改操作（CLASS 2，参见 3.2）。为了决定是否可以迁移，必须考虑每个修改操作的先决条件，修改操作 OP 的先决条件保证 wty在经过继承自 wtx的修改操作 OP 后，实例 w 的正确性。因此如果 w 在时刻 t 可以满足所有修改操作的先决条件，则 w 可以在时刻 t 从 wtx迁移到 wty，于是迁移条件便可由修改操作导出。需要注意的是，修改操作只与前台定义相关，而迁移条件必须依据后台定义设置，这意味着实现一个修改操作必须了解后台定义模型以便生成正确的迁移条件。迁移算法在检查迁移条件后执行实例迁移，只要有一个迁移条件不满足，演进策略就将被激活（参见 4.2）。
14、迁移算法工作在后台定义的层次上，不需要任何前台定义的知识。由于修改操作直接依赖于前台定义语言并且要生成不同的迁移条件，因此采用不同的前言必然导致修改操作重新实现，而迁移条件按后台定义设置，迁移算法可独立于前台定义语言得到重用。4.2 演进策略如上所述，工作流实例迁移依赖于对一组迁移条件的评估，对不满足迁移条件的实例，可采用以下三种方式：(1)Abort放弃此工作流实例的执行。(2)Complete依据老的 WFT 定义完成此实例的执行。7(3)Rollback回滚实例直到可以进行迁移操作的执行点。前两种动作很简单，但都有缺点。Abort 将浪费大量已完成的工作，而 Complete要求实例运行
15、在一个已过时的 WFT 上，一般是不能接受的，Rollback 策略则克服了前两种方法带来的问题。Rollback 动作由单步的 undo 操作组成，先分析实例的执行历史，然后针对每个活动执行 undo 操作，通过不断的 undo 操作来更新执行历史，直到所有的迁移条件都满足。和迁移算法一样，Rollback 算法也工作在后台定义上，因此它可以独立于前台定义语言而获得重用。5 演进组件体系结构依照上述原理，本文设计了一个工作流演进组件，此组件对工作流管理系统提供三个支持：WFT 版本化管理、实例迁移管理、定义语言无关支持，以此来实现支持多语言的工作流动态演进策略。图 4 是该组件的体系结构图，
16、其在逻辑上可分为三个模块：版本管理器、迁移管理器、内容管理器，如此划分可提供良好的复用性。版本管理器对 WFT 版本进行管理，要提供 3.2 中所描述的第一类操作。迁移管理器提供迁移算法、演进策略并且对迁移条件进行检测。这两个模块都工作在后台定义上，可以得到完全复用。通过前面讨论可知，要支持不同的工作流定义语言，与前台定义语言相关的修改操作是不可复用的，内容管理器正是来完成这一工作，它能提供 3.2 中所描述的第二类操作，将不同定义语言带来的影响限制在一个模块内。图 4 组件体系结构6 结束语 从目前的形势来看，对工作流技术的研究正在向深层次进行，目的有两个：一是8为工作流技术发展解决理论上的问题，探讨工作流模型和语义的形式化表示方法等；二是从工作流实现技术的角度，探讨利用先进的技术提高工作流管理系统的性能和可靠性。本文研究的问题涉及到了这两个方面，提出了一种支持多语言的工作流动态演进策略，上述组件正是在深入研究工作流管理联盟提供的工作流管理系统模型和各大主流工作流管理系统的基础上设计出来的。参考文献 1W
