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

　　

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