【正文】 當(dāng)工作流引擎在處理這樣的擴(kuò)充指令時(shí)，工作流引擎對(duì)模型實(shí)例所做的操作為：為主節(jié)點(diǎn)擴(kuò)充一個(gè)輸出庫(kù)所，并為其設(shè)置 token，創(chuàng)建一個(gè)擴(kuò)充節(jié)點(diǎn)，并將擴(kuò)充的庫(kù)所作為其輸入庫(kù)所，同時(shí)創(chuàng)建外向弧連接擴(kuò)充節(jié)點(diǎn)到主節(jié)點(diǎn)的所有輸入庫(kù)所上。 圖 21：自由擴(kuò)充節(jié)點(diǎn)類型 為了更方便對(duì)這三種類型的自由流程結(jié)點(diǎn)擴(kuò)充進(jìn)行討論，我們分別為它們進(jìn)行命名：（ a）協(xié)辦、（ b）委托、（ c）通知。當(dāng) Ti 節(jié)點(diǎn)被指派的用戶進(jìn)行了相關(guān)操作并提交工作流引擎時(shí)，工作流引擎消耗 Pi 中的token，并為 P1 產(chǎn)生 token，該 token 的產(chǎn)生再次使 T2 進(jìn)入 了就緒態(tài)，對(duì)于節(jié)點(diǎn) T2 來說，這一次的就緒和第一次的就緒已經(jīng)截然不同了，再次就緒時(shí)，實(shí)際上已經(jīng)完成了自由擴(kuò)充流程節(jié)點(diǎn) Ti 的操作。當(dāng) T2 處于就緒態(tài)時(shí)，在 T2 上進(jìn)行操作的用戶如果按照主流程進(jìn) 行簡(jiǎn)單的提交操作，那么工作流引擎將對(duì) T2 進(jìn)行激發(fā)操作，工作流引擎按照主流程的定義開始調(diào)度，將 T3 從常態(tài)遷移到激發(fā)態(tài)。為了說明的方便，圖中分別給出了結(jié)點(diǎn)擴(kuò)充操作在過程定義和過程模型上的變化情況。 圖 20：自由流程中的節(jié)點(diǎn)擴(kuò)充圖示 圖 20 反映的是一個(gè)半自由流程在活動(dòng) T2 結(jié)點(diǎn)處進(jìn)行活動(dòng)結(jié)點(diǎn) Ti 的擴(kuò)充情況。 自由流程與固定流程的 本質(zhì)區(qū)別在于自由流程在被工作流引擎執(zhí)行期間其活動(dòng)結(jié)點(diǎn)可以自由的擴(kuò)充。半自由流程是指那些預(yù)先存在流程模型而在流程模型被工作流引擎執(zhí)行期間工作流引擎可以在某些活動(dòng)結(jié)點(diǎn)上根據(jù)用戶的操作執(zhí)行進(jìn)行相應(yīng)的活動(dòng)結(jié)點(diǎn)擴(kuò)充的流程。 .2 自由流程支持 相對(duì)于固定流程來說，自由流程是指那些在流程模型被工作流引擎執(zhí)行期間流程模型實(shí)例可以變更的流程模型。 圖 19：過程定 義――過程模型 從表現(xiàn)形式來看，過程定義 D 更接近于人的流程設(shè)計(jì)習(xí)慣，因此，過程模型定義服務(wù)讓流程設(shè)計(jì)人員所繪制的是 D；過程模型 M 是標(biāo)準(zhǔn)的 Petri 網(wǎng)流程模型圖，這樣的結(jié)構(gòu)更利于工作流引擎基于 Petri 網(wǎng)的調(diào)度理論對(duì)流程進(jìn)行控制。這個(gè)轉(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)實(shí)現(xiàn)部分詳細(xì)介紹。 我們將過程模型定義服務(wù)軟件實(shí)體即圖形化模型定義工具所設(shè)計(jì)出的流程稱為過程定義，使用 D 表示，而將工作流引擎所執(zhí)行的流程稱為過程模型，使用M 表示。 固定流程是工作流管理系統(tǒng)中的基本流程，也是過程模型定義服務(wù)所支持的最基本的流程模型 。通常固定流程是企業(yè)中相對(duì)穩(wěn)定了的企業(yè)經(jīng)營(yíng)流程，而自定義流程是權(quán)限范圍內(nèi)的用戶靈活設(shè)計(jì)組織的企業(yè)經(jīng)營(yíng)過程。廣義上說，凡是在流程模型被工作流引擎實(shí)例化和執(zhí)行的過程中不會(huì) 發(fā)生變化的流程模型都可以稱為固定流程，而不關(guān)心該流程模型是由系統(tǒng)管理人員或流程模型定義人員預(yù)先設(shè)定好的還是由終端用戶根據(jù)各自需求自行定義的。 .1 固定流程支持 所謂固定流程是指流程模型在被工作流引擎實(shí)例化和執(zhí)行的過程中不會(huì)發(fā)生改變的流程。 模型的支持 工作流引擎對(duì)流程模型的支持決定了工作流引擎對(duì)不同類型的流程模型的調(diào)度能力。假定此時(shí)用戶進(jìn)行了觸發(fā)操作，使得 T4 從就緒態(tài)遷移到了激發(fā)態(tài)（常態(tài)），按照規(guī)則，將會(huì)把其輸入庫(kù)所 P P5 中的 token 消耗掉，同時(shí)為其輸出庫(kù)所 P6 產(chǎn)生 token，模型實(shí)例進(jìn)入圖 18 所示狀態(tài)。只有 T3 的激發(fā)會(huì)引起模型實(shí)例狀態(tài)的改變。 T T3的激發(fā)是沒有時(shí)序限定的，也就是說，既可能是 T2 先被激發(fā)，也可能是 T3 先被激發(fā)，這里我們假定 T2 先被激發(fā)，模型實(shí)例進(jìn)入圖 16 所示狀態(tài)。 圖 14： T1 就緒即刻遷移為激發(fā)態(tài) 圖 14 說明當(dāng)前模型實(shí)例剛剛被工作流引擎實(shí)例化，由工作流引擎在起始庫(kù)所 P1 種生成了第一個(gè) token，該 token 的產(chǎn)生即刻引起了變遷 T1 從常態(tài)遷移到了 就緒態(tài)，當(dāng)前模型實(shí)例的狀態(tài)并非飽和狀態(tài)，因?yàn)樘幱诰途w態(tài)的變遷 T1 處觸發(fā)類型為系統(tǒng)自動(dòng)觸發(fā)，因此，當(dāng)其從常態(tài)遷移到就緒態(tài)時(shí)即刻被調(diào)度執(zhí)行， T1將會(huì)從就緒態(tài)即刻進(jìn)入激發(fā)狀態(tài)（常態(tài)），該變化將會(huì)將 T1 的輸入庫(kù)所 P1 種的token 消耗掉，并為其所有輸出庫(kù)所 P P3 生成新的 token，模型實(shí)例進(jìn)入圖15 所示的飽和狀態(tài)。本節(jié)中各個(gè) Petri 網(wǎng)模型圖中白色矩形代表的是處于常態(tài)和激發(fā)態(tài)的變遷，具有花崗石底紋的矩形代表的是當(dāng)前處于就緒態(tài)的變遷。 這種“桌球碰撞現(xiàn)象”即是 Petri 網(wǎng)調(diào)度算法的核心所在 ，在下節(jié)中我們將根據(jù)一個(gè)實(shí)例來說明 Petri 網(wǎng)的調(diào)度算法。當(dāng)桌球的 球臺(tái)上分布著許多桌球的時(shí)候，如果擊出其中一球，該球在運(yùn)動(dòng)中可能會(huì)碰撞到其它球而引起其它球的運(yùn)動(dòng)，而被引起運(yùn)動(dòng)的球在其運(yùn)動(dòng)過程中又可能會(huì)引起另外的球運(yùn)動(dòng)，這樣的迭代下去，如果某一時(shí)刻球臺(tái)上仍然有在運(yùn)動(dòng)的球，那么我們就說其處于不飽和狀態(tài)，直到所有球都不再運(yùn)行，我們說此時(shí)處于了飽和狀態(tài)或靜止?fàn)顟B(tài)。 當(dāng)一個(gè)流程模型被實(shí)例 化的時(shí)候，工作流引擎會(huì)自動(dòng)為該流程模型實(shí)例的起始庫(kù)所生成一個(gè) token，就是這個(gè)被最初放置在起始庫(kù)所中的 token，觸發(fā)了整個(gè)流程實(shí)例的運(yùn)行。該迭代過程也就是任務(wù)的調(diào)度過程、流程狀態(tài)的改變過程。 從該過程不難看出，變遷從就緒態(tài)遷移到激發(fā)態(tài)的過程實(shí)質(zhì)上是變遷消耗其輸入庫(kù)所中的 token 同時(shí)為其輸出庫(kù)所產(chǎn)生 token 的過程。具體來說，當(dāng)任意一個(gè) token 被創(chuàng)建在某個(gè)庫(kù)所中時(shí)，算法都將查看是否因?yàn)樵搕oken 的產(chǎn)生而使得某些變遷從常態(tài)遷移到就緒態(tài)，根據(jù)第 2 部分的介紹，即是說，是否因?yàn)樵?token 的產(chǎn)生而使得某些變 遷的所有輸入庫(kù)所中都至少具有了一個(gè) token，如果存在滿足該條件的變遷，那么，該變遷就從常態(tài)遷移到了就緒態(tài)，也就是說該變遷當(dāng)前可以被執(zhí)行，但是，什么時(shí)候被執(zhí)行將取決于該變遷的觸發(fā)類型。其中，標(biāo)記是一種流程實(shí)例狀態(tài)信息的載體，標(biāo)記在庫(kù)所中的分布情況反映的是流程實(shí)例的狀態(tài)信息。 .1 Petri 網(wǎng)調(diào)度算法 Petri 網(wǎng)調(diào)度算法的核心思想非常簡(jiǎn)單。 不同的工作流管理系統(tǒng)的任務(wù)調(diào)度策略通常是不一樣的，本文所述及的工作流管理系統(tǒng)的任務(wù)調(diào)度策略采用的是 Petri 網(wǎng)的經(jīng)典調(diào)度算法。通常，工作流引擎應(yīng)該具備如下功能： 過程模型定義的解釋執(zhí)行，形成工作管理系統(tǒng)的工作流控制數(shù)據(jù)； 為過程模型創(chuàng)建過程模型實(shí)例，并對(duì)過程模型實(shí)例進(jìn)行維護(hù)； 依據(jù)過程模型進(jìn)行對(duì)過程模型實(shí)例中的活動(dòng)進(jìn)行調(diào)度； 根據(jù)對(duì)過程模型實(shí)例中活動(dòng)的調(diào)度情況維護(hù)任務(wù)表； 根據(jù)工作流控制數(shù)據(jù)調(diào)用應(yīng)用系統(tǒng)提供的任務(wù)實(shí)體； 同工作流程監(jiān)控服務(wù)進(jìn)行通信； 同其它工作流引擎進(jìn)行通信； 度策略 如果說工作流引擎是工作流管理系統(tǒng)的靈魂，那么，任務(wù)調(diào)度策略就是工作流引擎的靈魂，也就是說任務(wù)調(diào)度策略是工作流管理系統(tǒng)的核心之核心。 統(tǒng)應(yīng)用部件 嚴(yán)格的說，業(yè)務(wù)系統(tǒng)應(yīng)用部件不屬于工作流管理系統(tǒng)的一部分，它位于工作流管理系統(tǒng)的外圍，也是工作流管理系統(tǒng)所調(diào)度執(zhí)行的任務(wù)實(shí) 體系統(tǒng)，通常是希望運(yùn)行在工作流管理系統(tǒng)上的企業(yè)的業(yè)務(wù)系統(tǒng)。 執(zhí)行服務(wù)部件 工作流執(zhí)行服務(wù)部件主要包括構(gòu)成工作流管理系統(tǒng)靈魂的工作流引擎，或稱為工作流機(jī)，以及工作流相關(guān)數(shù)據(jù)和工作流控制數(shù)據(jù)等，這些共同構(gòu)成了工作流執(zhí)行服務(wù)部件，負(fù)責(zé)工作流程的調(diào)度和推進(jìn)。在企業(yè)的具體應(yīng)用中，統(tǒng)一工作平臺(tái)服務(wù)起到的作用是企業(yè)信息系統(tǒng)的集成門戶。 作平臺(tái)服務(wù) 統(tǒng)一工作平臺(tái)服務(wù)對(duì)應(yīng)于 WFMC 工作流管理系統(tǒng)系統(tǒng)架構(gòu)中的用戶界面和任務(wù)表管理器。 能接口服務(wù) 通用功能接口服務(wù)從功能上對(duì)應(yīng)于 WFMC 工作流參考模型的五類接口。 工作流程監(jiān)控服務(wù)的軟件實(shí)體是一個(gè)基于 WEB 技術(shù)的監(jiān)控維護(hù)系統(tǒng)，通過該監(jiān)控維護(hù)系統(tǒng)，監(jiān)控人員可以對(duì)當(dāng)前在工作流管理系統(tǒng)上運(yùn)行的應(yīng)用 系統(tǒng)流程實(shí)例的狀態(tài)進(jìn)行監(jiān)控，并可以人為的干預(yù)應(yīng)用系統(tǒng)流程實(shí)例的運(yùn)行，包括可以停止一個(gè)應(yīng)用系統(tǒng)流程實(shí)例、掛起一個(gè)應(yīng)用系統(tǒng)流程實(shí)例、改變應(yīng)用系統(tǒng)流程實(shí)例狀態(tài)等操作。 本文所述及的工作流管理系統(tǒng)的過程模型定義服務(wù)的軟件實(shí)體是運(yùn)用了VML 技術(shù)而開發(fā)的一種完全基于 WEB 技術(shù)的圖形化建模工具，該圖形化建模工具產(chǎn)生的中間文件編碼為 XML 文檔，不同的是，出于實(shí)際應(yīng)用的角度考慮，該中間文件 XML 文檔的文檔結(jié)構(gòu)是自定義的，沒有考慮使用 XPDL 格式，這主要是考慮到 XPDL 文檔結(jié)構(gòu)的復(fù)雜性，但是，如果將模型定義輸出為 XPDL 格式，對(duì)原有的過程模型定義服務(wù)部分的變更是很容易的。這樣在進(jìn)行工作流程中活動(dòng)定義時(shí)，不僅可以指定某個(gè)特定的人是這個(gè)活動(dòng)的參與者，而且可以將活動(dòng)與組織實(shí)體或角色功能進(jìn)行關(guān)聯(lián)。這些信息包括工作流程的開始和完成條件、構(gòu)成工作流程的活動(dòng)以及活動(dòng)的調(diào)度規(guī)則、用戶所需要完成的任務(wù)以及所有工作流相關(guān)數(shù)據(jù)的定義。這樣的設(shè)計(jì)簡(jiǎn)化的工作流引擎的任務(wù)，同時(shí)使工作流相關(guān)數(shù)據(jù)同流程實(shí)例結(jié)合的更加緊密，方便流程的反查和回退等操作?；诖?，本工作流管理系統(tǒng)取消了組織模型定義，代之以在過程模型定義時(shí)直接引用企業(yè)已有的組織結(jié)構(gòu)數(shù)據(jù)，簡(jiǎn)化了開發(fā)難度和系統(tǒng)數(shù)據(jù)冗余，并且避免了組織模型數(shù) 據(jù)和企業(yè)真實(shí)的組織結(jié)構(gòu)數(shù)據(jù)的不一致性。也就是說工作流相關(guān)數(shù)據(jù)是工作流管理系統(tǒng)和應(yīng)用系統(tǒng)的共享數(shù)據(jù)區(qū)，過程模型定義時(shí)也將引用該共享數(shù)據(jù)區(qū)的數(shù)據(jù)字段作為流程跳轉(zhuǎn)時(shí)的判斷條件。 信息模型定義 WFMC 的過程定義工具里的信息模型定義是對(duì)過程模型定義時(shí)所需要引用的工作流相關(guān)數(shù)據(jù)的建模工具。具體的說，組織模型定義就是為流程建模人員提供的一種在抽象層面上建立流程活動(dòng)參與者的組織結(jié)構(gòu)的定義工具。 型定義服務(wù) 過程模型定義服務(wù)從廣義上對(duì)應(yīng)于 WFMC 工作流管理系統(tǒng)架構(gòu)中的過程定義工具，所不同的是， WFMC 的過程定義工具包括：組織模型定義、信息模型定義、過程 模型定義三個(gè)功能模塊；而本工作流管理系統(tǒng)中的過程模型定義服務(wù)特指 WFMC 中的過程模型定義。本文第 7部分的系統(tǒng)性能將針對(duì)本系統(tǒng)所使用的 SOA系統(tǒng)架構(gòu)思想的設(shè)計(jì)和實(shí)現(xiàn)進(jìn)行詳細(xì)的說明。 系統(tǒng) web 服務(wù)配置 本工作流管理系統(tǒng)所提倡的是一種 SOA 即面向服務(wù)體 系結(jié)構(gòu)的軟件架構(gòu)思想。 系統(tǒng)任務(wù)實(shí)體配置 系統(tǒng)任務(wù)實(shí)體配置是將系統(tǒng)功能頁(yè)面發(fā)布為可以被工作流引擎調(diào)度的任務(wù)實(shí)體的功能入口。 系統(tǒng)功能菜單設(shè)置 工作流管理系統(tǒng)作為業(yè)務(wù)系統(tǒng)的操作系統(tǒng)，為業(yè)務(wù)系統(tǒng)的功能頁(yè)面提供了統(tǒng)一的菜單管理入口，即業(yè)務(wù)系統(tǒng)只需要通過系統(tǒng)功能菜單設(shè)置將本業(yè)務(wù)系統(tǒng)的菜單樹進(jìn)行配置即可實(shí)現(xiàn)菜單在同一工作平臺(tái)上的展示，并且，結(jié)合系統(tǒng)訪問權(quán)限的配置信息，展示給終端用戶的菜單樹將會(huì)根據(jù)用戶的訪問權(quán)限 的不同而不同。 系統(tǒng)訪問權(quán)限設(shè)置 工作流管理系統(tǒng)的業(yè)務(wù)系統(tǒng)注冊(cè)服務(wù)提供了統(tǒng)一管理、控制終端用戶對(duì)業(yè)務(wù)系統(tǒng)的功能訪問權(quán)限。 工作流管理系統(tǒng)架構(gòu) 圖 13：工作流管理系統(tǒng)架構(gòu)圖 統(tǒng)注冊(cè)服務(wù) 工作流管理系統(tǒng)被稱為業(yè)務(wù)系統(tǒng)的操作系統(tǒng)，因此，類比于操作系統(tǒng)，業(yè)務(wù)系統(tǒng)就類似于在操作系統(tǒng)上運(yùn)行的功能軟件，業(yè)務(wù)系統(tǒng)的運(yùn)行環(huán)境就是工作流管理系統(tǒng)，功能軟件要想運(yùn)行需要首先安裝到操作系統(tǒng)上，然后再被操作系統(tǒng)來啟動(dòng)并在操作系統(tǒng)環(huán)境中運(yùn)行，那么， 業(yè)務(wù)系統(tǒng)要想在工作流管理系統(tǒng)上運(yùn)行，同樣需要一個(gè)類似的安裝注冊(cè)過程，在本工作流管理系統(tǒng)的系統(tǒng)架構(gòu)中，將業(yè)務(wù)系統(tǒng)向工作流管理系統(tǒng)注冊(cè)的工作作為工作流管理系統(tǒng)的一種服務(wù)組建存在，即業(yè)務(wù)系統(tǒng)注冊(cè)服務(wù)。 系統(tǒng)對(duì)外服務(wù) 工作流管理系統(tǒng)不是企業(yè)的業(yè)務(wù)系統(tǒng)，它是企業(yè)業(yè)務(wù)系統(tǒng)的底層支撐平臺(tái)，或者稱為業(yè)務(wù)系統(tǒng)的操作系統(tǒng)。 基于 Petri 網(wǎng)技術(shù)，意味著工作流管理系統(tǒng)的流程模型建模是使用 Petri網(wǎng)建模語(yǔ)言描述的，同時(shí)，工作流引擎的調(diào)度策略也是基于經(jīng)典的 Petri 網(wǎng)調(diào)度理論進(jìn)行設(shè)計(jì)實(shí)現(xiàn)的。 從本系統(tǒng)的實(shí)現(xiàn)技術(shù)層面來說，本系統(tǒng)應(yīng)該是一種符合 WFMC 標(biāo)準(zhǔn)的，基于web 技術(shù)、 Petri 網(wǎng)技術(shù)和關(guān)系數(shù)據(jù)庫(kù)技術(shù)的工作流管理系統(tǒng)。基于 web 技術(shù)集中體現(xiàn)在實(shí)現(xiàn)工作流管理系統(tǒng)的各個(gè)環(huán)節(jié)和軟件實(shí)體均是采用 web 技術(shù)實(shí)現(xiàn)的，不同于某些工作流管理系統(tǒng)產(chǎn)品，雖然這些工作流管理系統(tǒng)也稱為基于 web 技術(shù)的，但是，嚴(yán)格來說，只能說是支持 web技術(shù)的， 因?yàn)檫@些軟件產(chǎn)品僅僅是為用戶提供了 web 操作頁(yè)面，核心功能卻是嵌入了 ActiveX 控件。這也本工作流管理系統(tǒng)集中解決的問題，也是區(qū)別于國(guó)內(nèi)現(xiàn)有工作流管理系統(tǒng)的地方，國(guó)內(nèi)現(xiàn)有工作流管理系統(tǒng)大多只針對(duì)以公文流轉(zhuǎn)為核心的 OA 系統(tǒng)。 4 系統(tǒng)描述 本文所述及的工作流管理系統(tǒng)是一種基于 web 技術(shù)的工作流管理系統(tǒng)，該工作流管理系統(tǒng)的開發(fā)目的是為企業(yè)提供各種 b/s 架構(gòu)的軟件系統(tǒng)的底層流程運(yùn)行支撐平臺(tái)，該工作流管理系統(tǒng)所支撐的軟件系統(tǒng)按性質(zhì)分為兩類，分別是以公文流轉(zhuǎn)為核心的 OA 系統(tǒng)和以企業(yè)業(yè)務(wù)活動(dòng)為核心的業(yè)務(wù)系統(tǒng)。第三方面是工作流技術(shù)的應(yīng)用 ，包括工作流失事技術(shù)、在不同應(yīng)用領(lǐng)域的應(yīng)用（如在企業(yè)經(jīng)營(yíng)過程重組、并行工程、敏捷制造）方法、應(yīng)用軟件集成等。第二方面是工作流的實(shí)現(xiàn)技術(shù)，包括工作流的事務(wù)特性、各種先進(jìn)軟件技術(shù)的應(yīng)用、工作流仿真。 上述主要研究問題可以分為三個(gè)方面：第一方面是工作流的理論基礎(chǔ)，包括工作流管理系統(tǒng)的體系、模型與定義語(yǔ)言（工作流建模方法、工作流模型的形式化標(biāo)識(shí)、工作流定義語(yǔ)言）等的研究。目前，在工作流設(shè)計(jì)方法學(xué)、工作流概念模型等方面還沒有形成一套比較成熟的理論和方法。在過去很長(zhǎng)一段時(shí)間里，有關(guān)工作流方面的研究主要是商品化的工作流管理系統(tǒng)