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

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

     为了处理工作流模型，必须有一套定义良好的操作。所谓“定义良好”是指达到两个基本条件：完备性和正确性。完备性是指可以创建或移除WFT模型上的所有元素，正确性是指当完成一系列修改操作后可以保持WFT模型及实例的正确性。为了达到这两个条件，必须设置某些操作的先决条件，如果先决条件不满足，那么操作就不能执行。修改操作有两类：

    (1)CLASS 1——创建和移除WFT以及控制版本的操作。这一类操作完全独立于前台定义语言。

    (2)CLASS 2——修改WFT版本内容的操作，这些操作依赖于前台定义语言。因此当前台定义语言改变时，这些操作必须重新实现。

    WFI的迁移是一个WFI绑定到一个新版本WFT的过程。当一个工作流实例w从版本wt[x]迁移到wt[y]时，它便依据wt[y]开始执行。必须保证迁移操作不会产生无效的WFI，只有当w迁移到wt[y]后仍然保持有效状态，才允许进行迁移操作。

    要判断工作流实例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）。迁移算法工作在后台定义的层次上，不需要任何前台定义的知识。

    由于修改操作直接依赖于前台定义语言并且要生成不同的迁移条件，因此采用不同的前台语言必然导致修改操作重新实现，而迁移条件按后台定义设置，迁移算法可独立于前台定义语言得到重用。

    如上所述，工作流实例迁移依赖于对一组迁移条件的评估，对不满足迁移条件的实例，可采用以下三种方式：

    (1)Abort——放弃此工作流实例的执行。

    (2)Complete——依据老的WFT定义完成此实例的执行。

    (3)Rollback——回滚实例直到可以进行迁移操作的执行点。

    前两种动作很简单，但都有缺点。Abort将浪费大量已完成的工作，而Complete要求实例运行在一个已过时的WFT上，一般是不能接受的，Rollback策略则克服了前两种方法带来的问题。Rollback动作由单步的undo操作组成，先分析实例的执行历史，然后针对每个活动执行undo操作，通过不断的undo操作来更新执行历史，直到所有的迁移条件都满足。

和迁移算法一样，Rollback算法也工作在后台定义上，因此它可以独立于前台定义语言而获得重用。

    依照上述原理，本文设计了一个工作流演进组件，此组件对工作流管理系统提供三个支持：WFT版本化管理、实例迁移管理、定义语言无关支持，以此来实现支持多语言的工作流动态演进策略。图4是该组件的体系结构图，其在逻辑上可分为三个模块：版本管理器、迁移管理器、内容管理器，如此划分可提供良好的复用性。版本管理器对WFT版本进行管理，要提供3.2中所描述的第一类操作。迁移管理器提供迁移算法、演进策略并且对迁移条件进行检测。这两个模块都工作在后台定义上，可以得到完全复用。通过前面讨论可知，要支持不同的工作流定义语言，与前台定义语言相关的修改操作是不可复用的，内容管理器正是来完成这一工作，它能提供3.2中所描述的第二类操作，将不同定义语言带来的影响限制在一个模块内。