可支持多語言的工作流動態(tài)演進(jìn) 4800字

可支持多語言的工作流動態(tài)演進(jìn)4800字工作流管理系統(tǒng)(WorkflowManagementSystem，WFMS)就是通過管理一系列的工作活動以及相關(guān)人員、資源、信息技術(shù)資料來提供業(yè)務(wù)處理程序上的自動控制，其最大優(yōu)點就是實現(xiàn)具體應(yīng)用邏輯和過程邏輯的別離，實現(xiàn)在不修改具體功能的情況下，通過修改業(yè)務(wù)流程模板來改變系統(tǒng)的功能，完成對組織生產(chǎn)經(jīng)營過程的局部業(yè)務(wù)或全部業(yè)務(wù)的集成管理，有效地把人力資源、物質(zhì)資源和信息組織在一起，發(fā)揮最大的效能。對業(yè)務(wù)過程的強大支持是企業(yè)獲得成功的一個關(guān)鍵因素，工作流管理系統(tǒng)正是用來調(diào)整業(yè)務(wù)流程及實現(xiàn)業(yè)務(wù)過程自動化的軟件系統(tǒng)。工作流管理系統(tǒng)并不是企業(yè)的業(yè)務(wù)系統(tǒng)，其本身并不執(zhí)行任何業(yè)務(wù)邏輯，它只為業(yè)務(wù)系統(tǒng)提供一個運行環(huán)境。

1.工作流系統(tǒng)可分為業(yè)務(wù)過程定義和業(yè)務(wù)過程執(zhí)行兩局部，定義局部稱為流原型(WFT)，執(zhí)行單元稱為工作流實例(WFI)，一組工作流原型稱為工作流元模型(workflowmeta-mode)，可以通過工作流元模型來描述工作流模型。元模型用抽象的語義描述了WFT所需的上層實體，并定義了如何表示W(wǎng)FT，其中一種元模型可以看作是一種工作流定義語言。定義語言、WFT、WFI的概念比擬難以理解，可分別同C語言、C程序、C程序進(jìn)程進(jìn)行類比。業(yè)務(wù)流程是企業(yè)應(yīng)用中最活潑的局部，很難在設(shè)計階段就提供完美的WFT以適應(yīng)各種情況，因此工作流管理系統(tǒng)必須具備演進(jìn)的能力。也就是說，即使實例已經(jīng)在運行當(dāng)中，也可以修改其定義，但任何修改都要保證模型與實例的正確性。一般情況下，如果沒有正在運行的實例，則對WFT的改動將不會帶來什么問題。

但如果一個正在被其他WFT所引用的WFT被刪除時，整個工作流模型便失效了;如果WFT的改變與正在執(zhí)行實例發(fā)生沖突的話，實例也就無效了。在實際生產(chǎn)生活中，工作流實例經(jīng)常有一個較長的運行周期，因此工作流管理系統(tǒng)必須支持運行實例的修改，也就是在運行期間動態(tài)演進(jìn)WFT。關(guān)于工作流的動態(tài)演進(jìn)問題，目前提出的解決計劃有工作原型版本化(WFTversioning)以及工作流實例遷移(migrationofWFT)。一個版本代表了演進(jìn)實體的一個狀態(tài)，當(dāng)流程發(fā)生改變時不是直接修改WFT，而是給出該WFT的一個新版本，通過運用一系列定義良好的修改操作，使新版本繼承自源版本，然后通過遷移算法使正在執(zhí)行中的實例依據(jù)WFT的新版本繼續(xù)執(zhí)行。這種辦法雖然解決了動態(tài)演進(jìn)問題，但修改操作及遷移算法都綁定于特定的工作流定義語言，這意味著一旦定義語言改變，那么修改操作及遷移算法都不得不重新實現(xiàn)，因此工作流管理系統(tǒng)應(yīng)具備處理不同定義語言的能力。本文將首先討論如何實現(xiàn)工作流管理系統(tǒng)的定義語言無關(guān)性，在此根底上提出了一個WFT動態(tài)演進(jìn)的計劃，并設(shè)計了一個組件，它為特定的工作流管理系統(tǒng)提供演進(jìn)支持，同時可兼容于不同的元模型(定義語言)。

2實現(xiàn)工作流

管理系統(tǒng)的定義語言無關(guān)性工作流是由工作流定義語言進(jìn)行描述的，目前存在許多定義語言，各種語言對工作流中相同的語義有著不同的描述。由于不足統(tǒng)一的規(guī)范，很難使WFT在不同的WFMS之間移植。每種定義語言都有一套自己的概念和結(jié)構(gòu)，由WFMS解釋這些概念和結(jié)構(gòu)，一旦改變定義語言，那么WFMS的相當(dāng)一局部都要重寫。由于各種語言都有自己的特長，倚重或偏廢任何一個都不利于技術(shù)的整體開展，因此作為獨立的工作流管理系統(tǒng)必須具備處理各種定義語言的能力。可以采用“加一層〞的方法來解決這個問題。在工作流定義與工作流執(zhí)行引擎之間加一層所謂的“后臺定義〞，這樣一來，由各種定義語言所描述的WFT就成了“前臺定義〞。如此劃分可以減小不同定義語言所帶來的影響，以便在工作流執(zhí)行引擎的級別上保持相同的數(shù)據(jù)結(jié)構(gòu)，下面通過微型工作流(micro-workflow)體系結(jié)構(gòu)，來解釋前、后臺定義及其轉(zhuǎn)換。

2.1前臺定義Micro-workflow有自己的定義語言，即本文所稱的前臺定義，它的關(guān)鍵抽象是過程(Procedure)，一顆由過程組成的層次樹便定義了一個工作流程。(1)簡單過程(SimpleProcedure)——這些過程表示樹(指定義樹，非元模型)中的葉子節(jié)點，它既可以是一個代表軟件效勞的過程，也可以是一個代表用戶必須完成的工作過程。(2)復(fù)合過程(CompositeProcedure)——復(fù)合過程用于表示對控制流(序列、條件等)的管理結(jié)構(gòu)，是樹中的非葉子節(jié)點。

2.2后臺定義采用根底數(shù)據(jù)結(jié)構(gòu)中的有向圖來進(jìn)行后臺定義，其中節(jié)點代表活動步驟，節(jié)點之間的連接代表流(數(shù)據(jù)流或控制流)?？刂屏鹘⒘斯?jié)點的執(zhí)行順序，數(shù)據(jù)流定義了從一個活動傳遞到另一個活動的數(shù)據(jù)，任何圖都有一個開始節(jié)點和終止節(jié)點。

2.3前臺定義到后臺定義的翻譯要完成從前臺到后臺的翻譯，前臺定義模型與后臺定義模型之間必須有一個完備的映射。前臺定義模型提供編譯規(guī)那么從而生成后臺定義，micro-workflow中的編譯是按照自頂向下的方式完成的，它從前臺定義的根部開始，遞歸進(jìn)行，每個復(fù)合過程編譯它的子節(jié)點作為其相應(yīng)后臺定義圖中的表示。每個簡單過程編譯成圖中的一個節(jié)點，而復(fù)合過程中的信息那么成節(jié)點之間的連接，生成的結(jié)果圖就是工作流引擎可任意處理的后臺定義，定義編譯算法時要考慮所有存在的規(guī)那么，如控制流、數(shù)據(jù)流以及發(fā)送給各個節(jié)點的消息類型等。圖2大體描述了一個前臺到后臺的映射。

3工作原型

修改一個靈活的工作流管理系統(tǒng)應(yīng)該具備WFT的修改功能，即便是已經(jīng)有實例運行在WFT上，它也可以被修改，下面將解決這個問題。首先介紹WFT版本化的概念并給出圖1的擴(kuò)展，然后介紹修改操作(modificationoperation)的概念。

3.1WFT版本化WFT版本化的主要思想是創(chuàng)立WFT的新版本而不是直接修改原有的WFT。WFT的行為信息保存在它的各個版本中，圖3是圖1元模型的擴(kuò)展，提供了WFT版本化支持。一個WFT由一個或多個版本組成，并且某一版本只唯一隸屬于一個WFT，也就說一個版本可以有多個子孫，但只能有一個父親，每個版本都有一個版本號作為唯一標(biāo)識。當(dāng)一個新的WFT參加到工作流模型中時，便建立了此WFT的根版本。如果要施加任何修改操作，那么先創(chuàng)立此版本的一個子孫版本，然后在新版本上進(jìn)行修改操作。一個版本可處于三種狀態(tài)中：臨時狀態(tài)、發(fā)布狀態(tài)及過時狀態(tài)。一個版本一旦創(chuàng)立便置于臨時狀態(tài)中，處于臨時狀態(tài)的版本可以進(jìn)行修改或移除，但不能進(jìn)行實例化也不能產(chǎn)生子孫版本;一旦修改操作完成那么變?yōu)榘l(fā)布狀態(tài)，處于此狀態(tài)的版本不能修改或移除，但可產(chǎn)生新版本;最后，當(dāng)發(fā)布狀態(tài)的版本變失效時，它的狀態(tài)被置為過時。

3.2修改操作為了處理工作流模型，必須有一套定義良好的操作。所謂“定義良好〞是指到達(dá)兩個根本條件：完備性和正確性。完備性是指可以創(chuàng)立或移除WFT模型上的所有元素，正確性是指當(dāng)完成一系列修改操作后可以保持WFT模型及實例的正確性。為了到達(dá)這兩個條件，必須設(shè)置某些操作的先決條件，如果先決條件不滿足，則操作就不能執(zhí)行。修改操作有兩類：(1)CLASS1——創(chuàng)立和移除WFT以及控制版本的操作。這一類操作完全獨立于前臺定義語言。(2)CLASS2——修改WFT版本內(nèi)容的操作，這些操作依賴于前臺定義語言。因此當(dāng)前臺定義語言改變時，這些操作必須重新實現(xiàn)。

4工作流實例遷移

WFI的遷移是一個WFI綁定到一個新版本W(wǎng)FT的過程。當(dāng)一個工作流實例w從版本wt[x]遷移到wt[y]時，它便依據(jù)wt[y]開始執(zhí)行。必須保證遷移操作不會產(chǎn)生無效的WFI，只有當(dāng)w遷移到wt[y]后仍然保持有效狀態(tài)，才允許進(jìn)行遷移操作。

4.1遷移條件要判斷工作流實例w在t時刻是否可以遷移到wt[y]，一個簡單的辦法是分析以往w在t時刻所包含的事件，看其是否與wt[y]兼容，也就是說必須檢驗t時刻的每一個事件，看遷移到wt[y]后是否會導(dǎo)致無效的WFI。很明顯這種辦法的效率不高，可以采用產(chǎn)生新版本W(wǎng)FI的修改操作(CLASS2，參見3.2)。為了決定是否可以遷移，必須考慮每個修改操作的先決條件，修改操作OP的先決條件保證wt[y]在經(jīng)過繼承自wt[x]的修改操作OP后，實例w的正確性。因此如果w在時刻t可以滿足所有修改操作的先決條件，那么w可以在時刻t從wt[x]遷移到wt[y]，于是遷移條件便可由修改操作導(dǎo)出。需要注意的是，修改操作只與前臺定義相關(guān)，而遷移條件必須依據(jù)后臺定義設(shè)置，這意味著實現(xiàn)一個修改操作必須了解后臺定義模型以便生成正確的遷移條件。遷移算法在檢查遷移條件后執(zhí)行實例遷移，只要有一個遷移條件不滿足，演進(jìn)策略就將被激活(參見4.2)。遷移算法工作在后臺定義的層次上，不需要任何前臺定義的知識。由于修改操作直接依賴于前臺定義語言并且要生成不同的遷移條件，因此采用不同的前臺語言必然導(dǎo)致修改操作重新實現(xiàn)，而遷移條件按后臺定義設(shè)置，遷移算法可獨立于前臺定義語言得到重用。

4.2演進(jìn)策略如上所述，工作流實例遷移依賴于對一組遷移條件的評估，對不滿足遷移條件的實例，可采用下列三種方式：(1)Abort——放棄此工作流實例的執(zhí)行。(2)Complete——依據(jù)老的WFT定義完成此實例的執(zhí)行。(3)Rollback——回滾實例直到可以進(jìn)行遷移操作的執(zhí)行點。前兩種動作很簡單，但都有缺點。Abort將浪費大量已完成的工作，而Complete要求實例運行在一個已過時的WFT上，一般是不能接受的，Rollback策略那么克服了前兩種辦法帶來的問題。Rollback動作由單步的undo操作組成，先分析實例的執(zhí)行歷史，然后針對每個活動執(zhí)行undo操作，通過不斷的undo操作來更新執(zhí)行歷史，直到所有的遷移條件都滿足。和遷移算法一樣，Rollback算法也工作在后臺定義上，因此它可以獨立于前臺定義語言而獲得重用。

5演進(jìn)組件體系結(jié)構(gòu)

依照上述原理，本文設(shè)計了一個工作流演進(jìn)組件，此組件對工作流管理系統(tǒng)提供三個支持：WFT版本化管理、實例遷移管理、定義語言無關(guān)支持，以此來實現(xiàn)支持多語言的工作流動態(tài)演進(jìn)策略。圖4是該組件的體系結(jié)構(gòu)圖，其在邏輯上可分為三個模塊：版本管理器、遷移管理器、內(nèi)容管理器，如此劃分可提供良好的復(fù)用性。版本管理器對WFT版本進(jìn)行管理，要提供3.2中所描述的第一類操作。遷移管理器提供遷移算法、演進(jìn)策略并且對遷移條件進(jìn)行檢測。這兩個模塊都工作在后臺定義上，可以得到完全復(fù)用。通過前面討論可知，要支持不同的工作流定義語言，與前臺定義語言相關(guān)的修改操作是不可復(fù)用的，內(nèi)容管理器正是來完成這一工作，它能提供3.2中所描述的第二類操作，將不同