【導(dǎo)讀】程規(guī)則，文檔、信息或任務(wù)能夠在不同的執(zhí)行者之間進(jìn)行傳遞與執(zhí)行。一個完整的工作流管理系統(tǒng)是由工作。流執(zhí)行部件、工作流功能部件和外部應(yīng)用系統(tǒng)構(gòu)成的。流引擎，是工作流管理系統(tǒng)的核心。工作流引擎負(fù)責(zé)解釋過程定義、創(chuàng)建模型實。例、調(diào)度模型實例任務(wù)、推進(jìn)流程等功能。一個過程模型就是企業(yè)經(jīng)營過程中業(yè)。型，例如：固定流程、自由流程以及嵌套流程等。種常見的流程模型的支持。

　　

【正文】 統(tǒng)的外圍，也是工作流管理系統(tǒng)所調(diào)度執(zhí)行的任務(wù)實 體系統(tǒng)，通常是希望運行在工作流管理系統(tǒng)上的企業(yè)的業(yè)務(wù)系統(tǒng)。 工作流引擎詳解 工作流引擎即 workflow engine，是整個工作流管理系統(tǒng)的核心部分，是工作流管理系統(tǒng)的靈魂。通常，工作流引擎應(yīng)該具備如下功能： 過程模型定義的解釋執(zhí)行，形成工作管理系統(tǒng)的工作流控制數(shù)據(jù)； 為過程模型創(chuàng)建過程模型實例，并對過程模型實例進(jìn)行維護(hù)； 依據(jù)過程模型進(jìn)行對過程模型實例中的活動進(jìn)行調(diào)度； 根據(jù)對過程模型實例中活動的調(diào)度情況維護(hù)任務(wù)表； 根據(jù)工作流控制數(shù)據(jù)調(diào)用應(yīng)用系統(tǒng)提供的任務(wù)實體； 同工作流程監(jiān)控服務(wù)進(jìn)行通信； 同其它工作流引擎進(jìn)行通信； 度策略 如果說工作流引擎是工作流管理系統(tǒng)的靈魂，那么，任務(wù)調(diào)度策略就是工作流引擎的靈魂，也就是說任務(wù)調(diào)度策略是工作流管理系統(tǒng)的核心之核心。工作流引擎的任務(wù)調(diào)度策略的性能的優(yōu)劣以及調(diào)度策略能否很好的進(jìn)行擴(kuò)展將直接關(guān)系到工作流管理系統(tǒng)的功能是否強(qiáng)大。 不同的工作流管理系統(tǒng)的任務(wù)調(diào)度策略通常是不一樣的，本文所述及的工作流管理系統(tǒng)的任務(wù)調(diào)度策略采用的是 Petri 網(wǎng)的經(jīng)典調(diào)度算法。下面將首先介紹 Petri 網(wǎng)的基本調(diào)度算法，然后結(jié)合實例說明任務(wù)是如何依據(jù) Petri 網(wǎng)調(diào)度算法被調(diào)度的。 .1 Petri 網(wǎng)調(diào)度算法 Petri 網(wǎng)調(diào)度算法的核心思想非常簡單。在本文第 2 部分曾介紹過 Petri網(wǎng)的四種基本圖元：庫所、變遷、弧、標(biāo)記。其中，標(biāo)記是一種流程實例狀態(tài)信息的載體，標(biāo)記在庫所中的分布情況反映的是流程實例的狀態(tài)信息。 Petri 網(wǎng)的調(diào)度算法或者說 Petri 網(wǎng)流程的推進(jìn)過程實質(zhì)上是 token 的創(chuàng)建和消耗的過程。具體來說，當(dāng)任意一個 token 被創(chuàng)建在某個庫所中時，算法都將查看是否因為該token 的產(chǎn)生而使得某些變遷從常態(tài)遷移到就緒態(tài)，根據(jù)第 2 部分的介紹，即是說，是否因為該 token 的產(chǎn)生而使得某些變 遷的所有輸入庫所中都至少具有了一個 token，如果存在滿足該條件的變遷，那么，該變遷就從常態(tài)遷移到了就緒態(tài)，也就是說該變遷當(dāng)前可以被執(zhí)行，但是，什么時候被執(zhí)行將取決于該變遷的觸發(fā)類型。當(dāng)一個處于就緒態(tài)的變遷被觸發(fā)前，其狀態(tài)一直保持為就緒態(tài)，并且會將其所有輸入庫所中的一個 token 進(jìn)行鎖定，直到該變遷被觸發(fā)時，變遷才從就緒態(tài)遷移到激發(fā)態(tài)，具體來說，一個處于就緒態(tài)的變遷被觸發(fā)的過程包含如下步驟： 變遷所對應(yīng)的任務(wù)實體被實際執(zhí)行； 變遷從其所有輸入庫所中消耗掉在該變遷成為就緒態(tài)時鎖定的 token； 變遷為其所有輸 出庫所生成新的 token； 變遷從就緒態(tài)遷移到激發(fā)態(tài)并瞬間變回常態(tài)。 從該過程不難看出，變遷從就緒態(tài)遷移到激發(fā)態(tài)的過程實質(zhì)上是變遷消耗其輸入庫所中的 token 同時為其輸出庫所產(chǎn)生 token 的過程。一個 token 的創(chuàng)建可能引起了變遷狀態(tài)的遷移，變遷狀態(tài)的遷移消耗了輸入庫所中的 token 并為其輸出庫所生成新的 token，新生成的 token 又會重復(fù)該過程，形成了迭代。該迭代過程也就是任務(wù)的調(diào)度過程、流程狀態(tài)的改變過程。因此，前文提到過 token在庫所中的分布情況反映的是流程實例的狀態(tài)信息。 當(dāng)一個流程模型被實例 化的時候，工作流引擎會自動為該流程模型實例的起始庫所生成一個 token，就是這個被最初放置在起始庫所中的 token，觸發(fā)了整個流程實例的運行。當(dāng)任意時刻我們觀察一個流程實例的時候，如果該時刻沒有新的 token 生成時，我們稱流程模型處于飽和狀態(tài)，或靜止?fàn)顟B(tài)；如果因為一個 token 的產(chǎn)生引起了新的 token 的產(chǎn)生并且這樣的過程在瞬間迭代下去，那么，在該時刻所觀察到的流程實例將是不穩(wěn)定狀態(tài)，或不飽和狀態(tài)，這樣的狀態(tài)最終將會趨于飽和狀態(tài)，也就是說流程實例將最終進(jìn)入靜止?fàn)顟B(tài)，我們稱這種現(xiàn)象為“桌球碰撞現(xiàn)象”。當(dāng)桌球的 球臺上分布著許多桌球的時候，如果擊出其中一球，該球在運動中可能會碰撞到其它球而引起其它球的運動，而被引起運動的球在其運動過程中又可能會引起另外的球運動，這樣的迭代下去，如果某一時刻球臺上仍然有在運動的球，那么我們就說其處于不飽和狀態(tài)，直到所有球都不再運行，我們說此時處于了飽和狀態(tài)或靜止?fàn)顟B(tài)。于是，某個變遷從就緒態(tài)遷移到激發(fā)態(tài)的動作過程所產(chǎn)生的新 token 就好像是被擊出的桌球一樣，這些 token的產(chǎn)生很可能會引起新的 token 的生成，直到處于飽和為止。 這種“桌球碰撞現(xiàn)象”即是 Petri 網(wǎng)調(diào)度算法的核心所在 ，在下節(jié)中我們將根據(jù)一個實例來說明 Petri 網(wǎng)的調(diào)度算法。 .2 調(diào)度實例說明 本節(jié)內(nèi)容將結(jié)合一個簡單的 Petri 網(wǎng)模型來說明 Petri 網(wǎng)的調(diào)度算法。本節(jié)中各個 Petri 網(wǎng)模型圖中白色矩形代表的是處于常態(tài)和激發(fā)態(tài)的變遷，具有花崗石底紋的矩形代表的是當(dāng)前處于就緒態(tài)的變遷。 Petri 網(wǎng)模型圖中的小黑點代表的是當(dāng)前 token 的分布。 圖 14： T1 就緒即刻遷移為激發(fā)態(tài) 圖 14 說明當(dāng)前模型實例剛剛被工作流引擎實例化，由工作流引擎在起始庫所 P1 種生成了第一個 token，該 token 的產(chǎn)生即刻引起了變遷 T1 從常態(tài)遷移到了 就緒態(tài)，當(dāng)前模型實例的狀態(tài)并非飽和狀態(tài)，因為處于就緒態(tài)的變遷 T1 處觸發(fā)類型為系統(tǒng)自動觸發(fā)，因此，當(dāng)其從常態(tài)遷移到就緒態(tài)時即刻被調(diào)度執(zhí)行， T1將會從就緒態(tài)即刻進(jìn)入激發(fā)狀態(tài)（常態(tài)），該變化將會將 T1 的輸入庫所 P1 種的token 消耗掉，并為其所有輸出庫所 P P3 生成新的 token，模型實例進(jìn)入圖15 所示的飽和狀態(tài)。 圖 15： T2 和 T3 處于就緒態(tài) 圖 15 所示的模型實例處于了一種飽和狀態(tài)，即 P2 中產(chǎn)生的 token 使得變遷T2 從常態(tài)遷移到了就緒態(tài)； P3 種產(chǎn)生的 token 使得變遷 T3 從常態(tài)遷移到了就緒態(tài)，但是，因為 T T3 與 T1 的觸發(fā)類型不同， T T3 都是手工觸發(fā)的變遷，因此， T T3 遷移到就緒態(tài)時會將其各自輸入庫所及 P P3 中的 token 鎖定，T T3 何時被激發(fā)將取決于用戶何時來執(zhí)行 T T3 所對應(yīng)的任務(wù)實體。 T T3的激發(fā)是沒有時序限定的，也就是說，既可能是 T2 先被激發(fā)，也可能是 T3 先被激發(fā)，這里我們假定 T2 先被激發(fā)，模型實例進(jìn)入圖 16 所示狀態(tài)。 圖 16： T2 激發(fā)， T3 仍處于就緒態(tài) 圖 16 所示的狀態(tài)是 T2 被激發(fā)后的狀態(tài)， T2 的激發(fā)使得 P2 中的 token 被消耗，同時為 T2 的輸出庫所 P4 產(chǎn)生了 token，調(diào)度 算法此時會嘗試找到因為 P4中 token 的產(chǎn)生而可能會成為就緒態(tài)的變遷，但是，卻沒有這樣的變遷，因為對于變遷 T4 來說，雖然其輸入庫所 P4 擁有了 token，但是， T4 的另外一個輸入庫所 P5 中卻沒有 token，因此， T4 不滿足從常態(tài)遷移到就緒態(tài)的條件，因此，當(dāng)前模型實例處于穩(wěn)定狀態(tài)。只有 T3 的激發(fā)會引起模型實例狀態(tài)的改變。假定此時 T3 被激發(fā)了，按照規(guī)則，將會把 P3 中的 token 消耗掉，同時為 P5 產(chǎn)生新的token，狀態(tài)如圖 17 圖 17： T3 激發(fā)， T4 處于就緒態(tài) 圖 17 所示的是 T3 被激發(fā)后的狀態(tài)，當(dāng) P5 中產(chǎn)生 token 時，調(diào)度算法嘗試找到因為 P5 中 token 的產(chǎn)生而可能會成為就緒的變遷，于是，找到了 T4， T4的狀態(tài)就從常態(tài)遷移到了就緒態(tài)， T4 的觸發(fā)類型為手工觸發(fā)， T4 被調(diào)度等待用戶進(jìn)行觸發(fā)。假定此時用戶進(jìn)行了觸發(fā)操作，使得 T4 從就緒態(tài)遷移到了激發(fā)態(tài)（常態(tài)），按照規(guī)則，將會把其輸入庫所 P P5 中的 token 消耗掉，同時為其輸出庫所 P6 產(chǎn)生 token，模型實例進(jìn)入圖 18 所示狀態(tài)。 圖 18： T4 激發(fā) 圖 18 所示狀態(tài)為 T4 被激發(fā)后的狀態(tài)， P6 中產(chǎn)生了 token，因為 P6 是終止庫所，因此，滿足了流程結(jié)束的條件，該流程實例結(jié)束 。 模型的支持 工作流引擎對流程模型的支持決定了工作流引擎對不同類型的流程模型的調(diào)度能力。流程模型根據(jù)其創(chuàng)建的時機(jī)、流程中活動的性質(zhì)、流程中活動的創(chuàng)建時機(jī)的不同可以分為多種類型的流程模型：固定流程、自定義流程、自由流程、嵌套流程等。 .1 固定流程支持 所謂固定流程是指流程模型在被工作流引擎實例化和執(zhí)行的過程中不會發(fā)生改變的流程。狹義上說，固定流程特指那些由系統(tǒng)管理人員或流程模型定義人員預(yù)先定義好的、在流程模型實例化和執(zhí)行過程中不會發(fā)生變化的流程。廣義上說，凡是在流程模型被工作流引擎實例化和執(zhí)行的過程中不會 發(fā)生變化的流程模型都可以稱為固定流程，而不關(guān)心該流程模型是由系統(tǒng)管理人員或流程模型定義人員預(yù)先設(shè)定好的還是由終端用戶根據(jù)各自需求自行定義的。我們將那些由終端用戶根據(jù)各自需求自行定義的流程稱為自定義流程。通常固定流程是企業(yè)中相對穩(wěn)定了的企業(yè)經(jīng)營流程，而自定義流程是權(quán)限范圍內(nèi)的用戶靈活設(shè)計組織的企業(yè)經(jīng)營過程。自定義流程實質(zhì)上是一種特殊的固定流程，因此，后文的討論中，出現(xiàn)的固定流程是廣義上包含了固定流程和自定義流程的流程模型概念。 固定流程是工作流管理系統(tǒng)中的基本流程，也是過程模型定義服務(wù)所支持的最基本的流程模型 。為了后文討論的方便，這里簡單介紹一下過程定義和過程模型的區(qū)別和相互轉(zhuǎn)換關(guān)系。 我們將過程模型定義服務(wù)軟件實體即圖形化模型定義工具所設(shè)計出的流程稱為過程定義，使用 D 表示，而將工作流引擎所執(zhí)行的流程稱為過程模型，使用M 表示。 D 是過程模型定義服務(wù)的輸出文件， D 經(jīng)過轉(zhuǎn)換器的翻譯最終形成可被工作流引擎執(zhí)行的 M。這個轉(zhuǎn)換器依據(jù)其功能被稱為 DM 轉(zhuǎn)換器，反向的轉(zhuǎn)換器被稱為 MD 轉(zhuǎn)換器，兩種轉(zhuǎn)換器都依據(jù)特定的轉(zhuǎn)換規(guī)則進(jìn)行轉(zhuǎn)換操作，具體的轉(zhuǎn)換規(guī)則將在系統(tǒng)實現(xiàn)部分詳細(xì)介紹。圖 19 說明了兩種模型在表現(xiàn)形式上的不同。 圖 19：過程定 義――過程模型 從表現(xiàn)形式來看，過程定義 D 更接近于人的流程設(shè)計習(xí)慣，因此，過程模型定義服務(wù)讓流程設(shè)計人員所繪制的是 D；過程模型 M 是標(biāo)準(zhǔn)的 Petri 網(wǎng)流程模型圖，這樣的結(jié)構(gòu)更利于工作流引擎基于 Petri 網(wǎng)的調(diào)度理論對流程進(jìn)行控制。這樣，就需要在過程定義 D 和過程模型 M 之間進(jìn)行轉(zhuǎn)換，這種轉(zhuǎn)換是雙向的，是通過工作流管理系統(tǒng)所提供的 DM 轉(zhuǎn)換器和 MD 轉(zhuǎn)換器來完成的。 .2 自由流程支持 相對于固定流程來說，自由流程是指那些在流程模型被工作流引擎執(zhí)行期間流程模型實例可以變更的流程模型。自由流程根據(jù)其自由度的不同又可分為全 自由流程和半自由流程，全自由流程是指那些預(yù)先不存在流程模型而由終端用戶的操作發(fā)起并根據(jù)終端用戶的操作進(jìn)行后繼活動結(jié)點的擴(kuò)充的流程。半自由流程是指那些預(yù)先存在流程模型而在流程模型被工作流引擎執(zhí)行期間工作流引擎可以在某些活動結(jié)點上根據(jù)用戶的操作執(zhí)行進(jìn)行相應(yīng)的活動結(jié)點擴(kuò)充的流程。半自由流程不同于全自由流程的是，半自由流程的活動結(jié)點的擴(kuò)充是在一個預(yù)定義的主流程的某些結(jié)點上進(jìn)行的擴(kuò)充，其自由度是受主流程的限制的，而全自由流程預(yù)先不存在主流程，所有的節(jié)點都是根據(jù)終端用戶的操作指令進(jìn)行動態(tài)擴(kuò)充的。 自由流程與固定流程的 本質(zhì)區(qū)別在于自由流程在被工作流引擎執(zhí)行期間其活動結(jié)點可以自由的擴(kuò)充。自由流程中活動結(jié)點的擴(kuò)充在過程定義和過程模型中表現(xiàn)為如下形式的變更，圖 20 所示。 圖 20：自由流程中的節(jié)點擴(kuò)充圖示 圖 20 反映的是一個半自由流程在活動 T2 結(jié)點處進(jìn)行活動結(jié)點 Ti 的擴(kuò)充情況。前文提到過，自由流程活動結(jié)點擴(kuò)充的實質(zhì)是工作流引擎根據(jù)用戶的操作指令對原流程模型實例進(jìn)行結(jié)點擴(kuò)充的操作。為了說明的方便，圖中分別給出了結(jié)點擴(kuò)充操作在過程定義和過程模型上的變化情況。對該情況說明如下。當(dāng) T2 處于就緒態(tài)時，在 T2 上進(jìn)行操作的用戶如果按照主流程進(jìn) 行簡單的提交操作，那么工作流引擎將對 T2 進(jìn)行激發(fā)操作，工作流引擎按照主流程的定義開始調(diào)度，將 T3 從常態(tài)遷移到激發(fā)態(tài)。但是，如果在 T2 上的操作用戶向工作流引擎發(fā)送了擴(kuò)充 Ti 活動結(jié)點的操作指令，那么，工作流引擎將在原流程模型實例上在 T2節(jié)點出進(jìn)行結(jié)點的擴(kuò)充，反映在圖的過程模型圖中就是增加了庫所 Pi、變遷 Ti和虛線所標(biāo)示的 3 條弧，并即刻將擴(kuò)充后的 Ti 從常態(tài)遷移到就緒態(tài)。當(dāng) Ti 節(jié)點被指派的用戶進(jìn)行了相關(guān)操作并提交工作流引擎時，工作流引擎消耗 Pi 中的token，并為 P1 產(chǎn)生 token，該 token 的產(chǎn)生再次使 T2 進(jìn)入 了就緒態(tài)，對于節(jié)點 T2 來說，這一次的就緒和第一次的就緒已經(jīng)截然不同了，再次就緒時，實際上已經(jīng)完成了自由擴(kuò)充流程節(jié)點 Ti 的操作。 根據(jù)自由擴(kuò)充的活動結(jié)點是否需要返回主流程、自由擴(kuò)充的活動結(jié)點執(zhí)行完畢后如何返回主流程等信息，可以匯總出如下情況。 圖 21：自由擴(kuò)充節(jié)點類型 為了更方便對這三種類型的自由流程結(jié)點擴(kuò)充進(jìn)行討論，我們分別為它們進(jìn)行命名：（ a）協(xié)辦、（ b）委托、（ c）通知。 A 協(xié)辦 在該擴(kuò)充模式下，主流程中發(fā)起自由流程擴(kuò)充的節(jié)點（后面簡稱為主節(jié)點）在創(chuàng)建了自由擴(kuò)充活動節(jié)點（后面簡稱擴(kuò)充節(jié)點）的同時要 求擴(kuò)充節(jié)點在執(zhí)行完成時必須返回主節(jié)點。當(dāng)工作流引擎在處理這樣的擴(kuò)充指令時，工作流引擎對模型實例所做的操作為：為主節(jié)點擴(kuò)充一個輸出庫所，并為其設(shè)置 token，創(chuàng)建一個擴(kuò)充節(jié)點，并將擴(kuò)充的庫所作為其輸入庫所，同時創(chuàng)建外向弧連接擴(kuò)充節(jié)點到主節(jié)點的所有輸入庫所上。這樣