支持動態(tài)調(diào)度的工作流Ｄ—Ｆｌｏｗ Ｅｎｇｉｎｅ的設(shè)計(jì)與實(shí)現(xiàn)

摘 要：基于流程與活動兩個(gè)級別考慮，提出支持動態(tài)調(diào)度的工作流D—Flow Engine；從動態(tài)路由和流程多版本方面分析了其動態(tài)調(diào)度特性。通過在流程建模階段擴(kuò)展工作流管理聯(lián)盟的工作流元模型相關(guān)定義，重點(diǎn)分析了動態(tài)路由和多版本流程遷移在流程運(yùn)行階段的調(diào)度實(shí)現(xiàn)。實(shí)踐表明，D—Flow Engine提高了工作流的適應(yīng)性，滿足了企業(yè)對工作流動態(tài)性的需求。

關(guān)鍵詞：工作流； 動態(tài)性； 元模型； 路由

中圖分類號：TP391文獻(xiàn)標(biāo)志碼：A

文章編號：1001—3695(2007)03—0173—04

隨著工作流技術(shù)的快速發(fā)展以及在實(shí)際應(yīng)用中的不斷深入，人們對工作流系統(tǒng)提出了更多的功能要求，其中一個(gè)主要問題是工作流系統(tǒng)的靈活性和動態(tài)性。傳統(tǒng)工作流的工作過程分為建模階段和運(yùn)行階段。建模階段是對一個(gè)工作流程進(jìn)行模型定義；運(yùn)行階段是工作流執(zhí)行服務(wù)對工作流定義進(jìn)行解釋執(zhí)行。由于現(xiàn)實(shí)的工作流系統(tǒng)可能無法事先確定所有過程，并且過程之間的關(guān)系在執(zhí)行期間并不是一成不變的，工作流系統(tǒng)缺乏柔性和動態(tài)性。如何使工作流系統(tǒng)具有靈活的動態(tài)性和自適應(yīng)能力，已經(jīng)成為目前工作流管理系統(tǒng)研究的一個(gè)熱點(diǎn)。

在可適應(yīng)動態(tài)工作流方面，研究者們進(jìn)行了廣泛的探索研究。文獻(xiàn)[1]討論了工作流實(shí)際運(yùn)行中可能出現(xiàn)的各種異常；根據(jù)其影響大小進(jìn)行分類，分析了如何預(yù)防、檢測和恢復(fù)異常，并應(yīng)用在工作流系統(tǒng)Endeavors中。文獻(xiàn)[2]描述了一個(gè)具有動態(tài)路由和操作控制機(jī)制的工作流實(shí)現(xiàn)框架，提出了其構(gòu)成三要素，即工作流控制表、約束序列和基于事件的管理規(guī)則。文獻(xiàn)[3]利用繼承思想提出了工作流繼承保留轉(zhuǎn)換規(guī)則，以此來解決流程動態(tài)遷移帶來的一系列問題。文獻(xiàn)[4]采用一個(gè)正確性評價(jià)來確保流程運(yùn)行時(shí)能夠在流程定義規(guī)則改變的情況下順利地進(jìn)行動態(tài)遷移。文獻(xiàn)[5]介紹了一個(gè)有改善性能的工作流路由調(diào)度算法。文獻(xiàn)[6]中的Reflection 方法采用工作流執(zhí)行過程中人機(jī)不斷交互來完成一個(gè)具有動態(tài)執(zhí)行的工作流程。

以上各種研究方法從適應(yīng)性、動態(tài)性等角度出發(fā)，采用各種具體方法試圖使工作流系統(tǒng)具備動態(tài)柔性特征。但另一方面，工作流的基本特征就是業(yè)務(wù)邏輯與應(yīng)用相分離，可以從模型方面出發(fā)改善其動態(tài)適應(yīng)能力。本文設(shè)計(jì)并實(shí)現(xiàn)了一個(gè)支持動態(tài)調(diào)度的工作流引擎D—Flow Engine，給出了其工作流元模型，重點(diǎn)研究了工作流的流程動態(tài)調(diào)度服務(wù)，最后結(jié)合應(yīng)用實(shí)例進(jìn)行了研究并給出結(jié)論。

1 D—Flow Engine工作流元模型

如圖1所示，D—Flow Engine工作流元模型有兩個(gè)層次，即核心模型和支撐模型。核心模型是以流程、活動等過程模型為中心，另外還包含數(shù)據(jù)模型和應(yīng)用模型；支撐模型主要包括組織模型、資源模型、權(quán)限模型和時(shí)間模型。

圖1 D—Flow Engine工作流元模型

支撐模型是任何一個(gè)工作流模型所必需的，但同時(shí)它們又經(jīng)常與企業(yè)中其他應(yīng)用系統(tǒng)有所關(guān)聯(lián)，為了實(shí)現(xiàn)工作流系統(tǒng)的集成性和柔性，有必要將它們分為獨(dú)立的一類。

D—Flow Engine的動態(tài)性主要體現(xiàn)在兩個(gè)方面：①流程的適應(yīng)性，即一個(gè)流程定義能夠根據(jù)用戶的不同需求而實(shí)例化出滿足不同需求的流程實(shí)例；②活動任務(wù)的分配，即每次活動激活分配任務(wù)時(shí)能夠根據(jù)當(dāng)時(shí)的實(shí)際需要來分配合適的任務(wù)執(zhí)行人。文獻(xiàn)[7]中詳細(xì)討論了活動任務(wù)的動態(tài)分配，不在本文論述之列。D—Flow Engine在流程動態(tài)調(diào)度方面支持動態(tài)路由和多版本流程，可以根據(jù)時(shí)間分為兩個(gè)方面，即建模階段和運(yùn)行階段。建模階段的動態(tài)性是指工作流定義時(shí)能夠定義一個(gè)流程的動態(tài)特性；運(yùn)行階段的動態(tài)性是指工作流程實(shí)例能夠修改預(yù)先定義的流程或一些不可預(yù)測的變化。

2 流程動態(tài)調(diào)度

2.1 工作流建模階段對動態(tài)調(diào)度的支持

一個(gè)工作流程由活動（Activity）和遷移（Transition）組成，根據(jù)兩者之間的關(guān)系，傳統(tǒng)工作流系統(tǒng)提供了串行、分叉、合并、循環(huán)等基本路由調(diào)度。但企業(yè)的實(shí)際應(yīng)用往往比較復(fù)雜，用戶在結(jié)束一個(gè)活動任務(wù)后，有可能需要跳過某個(gè)（些）活動節(jié)點(diǎn)繼續(xù)執(zhí)行；或者用戶認(rèn)為目前任務(wù)狀態(tài)沒有滿足需求，需要重新反饋到前面某個(gè)活動節(jié)點(diǎn)重復(fù)執(zhí)行。由于人為等不確定因素的存在，在流程建模定義時(shí)很難對這些動態(tài)路由直接用遷移清晰地表明出來。D—Flow Engine在提供了串行等基本路由的基礎(chǔ)上還支持跳躍和反饋路由。

定義1 跳躍路由：某活動A的活動實(shí)例執(zhí)行完成后不激活后續(xù)活動而跳躍激活后面某個(gè)活動B使流程繼續(xù)執(zhí)行，而在A、B之間不存在直接遷移，則活動A到B的路由為跳躍路由。

定義2 反饋路由：某活動A的活動實(shí)例執(zhí)行完成后，在不存在遷移的情況下，激活其前面一個(gè)活動節(jié)點(diǎn)B，則活動A到B的路由為反饋路由。

D—Flow Engine通過擴(kuò)充活動的屬性定義來支持動態(tài)路由。WfMC雖然對一般活動屬性進(jìn)行了基本的定義，如ID、Name等，但要支持動態(tài)調(diào)度，就有必要對其進(jìn)行擴(kuò)充。在傳統(tǒng)工作流中，一個(gè)活動出現(xiàn)在一個(gè)流程中意味著當(dāng)流程到達(dá)該活動時(shí)活動就要執(zhí)行，活動之間分不出哪些是關(guān)鍵的，哪些是可以變通的。為了使整個(gè)流程具有靈活性，將活動分成以下幾個(gè)類別：必須執(zhí)行、可被跳過執(zhí)行、可反饋執(zhí)行、需要人工干預(yù)，每類活動分別對應(yīng)執(zhí)行的不同行為。

定義3 活動Activity:={AID，Name，T，Data，State，Attribute，Condition}。其中AID為活動的標(biāo)志信息，包括活動標(biāo)志號和版本號，構(gòu)成二維變量唯一地確定一個(gè)活動；Name為活動名稱；T是一個(gè)謂詞邏輯表達(dá)式，T∷=f(O)表示該活動要完成具體的一個(gè)動作或功能， f是一個(gè)邏輯謂詞，O是f操作的對象，如WriteDoc(a.doc)表示書寫名為a.doc的文檔；State是當(dāng)前活動的狀態(tài)；Attribute描述了該活動在執(zhí)行時(shí)的行為屬性，包括可被跳過執(zhí)行、可反饋執(zhí)行、必須執(zhí)行、需要人工干預(yù)等，其中可反饋有發(fā)出（Out）和接收（In）兩種類型；Condition代表活動的激活條件和完成條件，其中有活動的合并方式（AND，OR）和分裂方式（AND，OR）。

工作流D—Flow Engine建模階段對動態(tài)調(diào)度支持另一個(gè)方面的表現(xiàn)是流程的多版本。工作流是企業(yè)經(jīng)營過程重組的一個(gè)重要使能方式。在企業(yè)過程重組和結(jié)構(gòu)優(yōu)化中，一個(gè)工作流程往往需要不斷更新，從而造成新舊版本流程共存。D—Flow Engine支持新舊多個(gè)版本的流程，采用與面向?qū)ο笳Z言類似的單根繼承體系，分別實(shí)現(xiàn)流程定義間與活動間的繼承關(guān)系。在流程定義間的繼承關(guān)系中將活動、遷移和流程相關(guān)數(shù)據(jù)作為流程定義的可繼承屬性；在活動中就是相關(guān)數(shù)據(jù)作為可繼承屬性。工作流模型繼承體系中提供了虛流程定義的概念。

定義4 虛流程定義：不具有完整信息集合、不能直接被實(shí)例化的流程定義。例如可以不具有開始、結(jié)束活動，可以有單個(gè)孤立活動節(jié)點(diǎn)等可實(shí)例化流程定義不能出現(xiàn)的情況。

D—Flow Engine模型繼承關(guān)系中支持以下兩種繼承特性：

（1）公用（Public）——父流程定義中某個(gè)可繼承屬性的繼承特性為Public，則任何繼承該父流程定義的子流程定義都可以擁有該屬性。

（2）私有（Private）——父流程定義中某個(gè)可繼承屬性的繼承特性為Private，則任何繼承該父流程定義的子流程定義都不能看見該屬性，即不擁有該屬性。同時(shí)由于工作流模型屬性的關(guān)聯(lián)性，如活動A是私有的，則所有與其關(guān)聯(lián)的遷移都必須是私有的。

定義5 流程標(biāo)志W(wǎng)FID:={ID，Versiton，Valid，PID，PVersion}。其中，ID是父子系列流程定義的標(biāo)志；Version表示此流程定義的版本序列號，與ID構(gòu)成一個(gè)具體流程定義的唯一標(biāo)志；Valid有效性標(biāo)志表示該版本流程是否還可以實(shí)例化執(zhí)行，是一個(gè)布爾型值；PID是父流程的ID，沒有父流程則為空；PVersion是父流程的版本序列號，沒有父流程則為空。

定義6 流程ProcessDefinition:={WFID，D_r，A_o，T_o，M_A，M_A，Rules}。其中，WFID為流程標(biāo)志；D_r是流程的數(shù)據(jù)信息；A_o、T_o是流程自定義的所有活動集合和所有遷移集合；M_A、M_T分別是父子流程中活動和遷移的替代映射關(guān)系；Rules是流程定義的一組規(guī)則和策略，如任務(wù)分配的方式（推式和拉式）、路由分支的選擇策略、流程新舊版本遷移策略等。

2.2 工作流運(yùn)行階段對動態(tài)調(diào)度的處理

工作流運(yùn)行階段對動態(tài)調(diào)度的處理可以分為三類：①處理在建模階段預(yù)先定義的有動態(tài)調(diào)度行為的活動或流程；②修改原來定義的流程實(shí)例，并根據(jù)新的流程實(shí)例形成新的流程定義；③只修改運(yùn)行的流程實(shí)例而不改變流程定義（適合臨時(shí)改變流程實(shí)例的情況下），這個(gè)流程實(shí)例運(yùn)行完成后不影響原來的流程定義。

因此，可以將運(yùn)行階段工作流的動態(tài)調(diào)度分為兩種：①可預(yù)測的處理（如前面提到的建模階段中動態(tài)路由和多版本流程的處理），即工作流引擎從流程定義中已知流程和活動的意義是什么，只是具體的操作要由人工干預(yù)或由不同規(guī)則來處理；②不可預(yù)測的操作（如一個(gè)活動正在執(zhí)行時(shí)或已執(zhí)行完畢，因?yàn)槠渌顒有薷幕驁?zhí)行失敗導(dǎo)致該活動的重新執(zhí)行或撤銷等；人工干預(yù)在何時(shí)進(jìn)行操作原語，何時(shí)提交給工作流引擎也是不可預(yù)測的）。

2.2.1 流程實(shí)例的動態(tài)路由

流程實(shí)例執(zhí)行的過程中，路由的動態(tài)調(diào)度實(shí)質(zhì)上可以看成是由一個(gè)活動節(jié)點(diǎn)定向路由到另一個(gè)活動節(jié)點(diǎn)，而不用去關(guān)心間隔的活動節(jié)點(diǎn)。下面是跳躍路由的運(yùn)行步驟：

（1）完成活動實(shí)例A后，判斷其后續(xù)活動是否有可被跳過行為屬性。沒有，則不發(fā)生跳躍路由直接激活后續(xù)活動，返回；有則轉(zhuǎn)（2）。

（2）詢問用戶是否需要進(jìn)行跳躍路由。不需要則不發(fā)生跳躍路由，返回；需要則轉(zhuǎn)（3）。

（3）尋找流程定義的規(guī)則策略集Rules中是否存在從活動A開始的跳躍規(guī)則。有則自動根據(jù)規(guī)則進(jìn)行跳躍路由，返回；無則轉(zhuǎn)（4）。

（4）列出從活動A開始可跳躍路由到的所有活動節(jié)點(diǎn)集合，讓用戶選擇一個(gè)活動節(jié)點(diǎn)進(jìn)行跳躍路由。

（5）詢問用戶是否需要將此跳躍規(guī)則添加到流程定義的規(guī)則策略集中以實(shí)現(xiàn)自動跳躍路由。不需要則完成跳躍路由；需要則添加跳躍規(guī)則并完成路由。

反饋路由與此類似，只是在步驟（1）中判斷的是活動A是否具有可發(fā)出反饋的行為屬性。無論是跳躍還是反饋，在路由過程中都需要越過某些活動。而這些被越過的活動與其他活動必然存在著一定的關(guān)系，動態(tài)路由的執(zhí)行將會影響到活動任務(wù)存在的環(huán)境。因此，在執(zhí)行動態(tài)路由時(shí)需要避免或消除路由操作帶來的不利影響。這種影響主要來源于活動之間的依賴關(guān)系，可將其分為以下兩種：

（1）數(shù)據(jù)依賴。流程定義中各個(gè)活動之間可能存在數(shù)據(jù)的相互依賴，依賴活動的數(shù)據(jù)值需要被依賴活動的數(shù)值。在這種依賴關(guān)系下，進(jìn)行動態(tài)路由必須解決路由中跳過的活動間的數(shù)據(jù)依賴性。如圖2所示，從活動“送審1”定向路由到活動“送審6”，活動“送審6”對活動“送審2”和活動“送審4”有數(shù)據(jù)依賴，則定向路由成功的必要條件是活動“送審6”的依賴數(shù)據(jù)可以通過取缺省值或人工賦值等方式代替數(shù)據(jù)依賴。

（2）路由依賴。如果不考慮路由依賴關(guān)系，通過動態(tài)路由可能會導(dǎo)致兩種不希望的后果。假設(shè)活動“送審1”和“送審2”的分裂為“AND”，活動“送審6”的合并也為“AND”，則：

①遷移實(shí)例無限等待。例如活動“送審6”反饋路由到活動“送審3”，則最后結(jié)果由于活動“送審5”和活動“送審4”無法到達(dá)，造成從活動“送審3”到活動“送審6”的遷移實(shí)例無限等待而無法激活“送審6”。

②活動實(shí)例無限等待。例如活動“送審4”反饋路由到活動“送審1”，由于“送審1”的分裂是“AND”，此時(shí)如果“送審2”活動實(shí)例仍處于激活狀態(tài)，則將造成“送審2”活動實(shí)例處于無限等待狀態(tài)。

圖2 流程定義示例圖

為了避免上述兩種異常情況的出現(xiàn)，D—Flow Engine工作流采用了配對活動方法對動態(tài)路由目標(biāo)進(jìn)行過濾。通過配對活動法過濾后的活動均可作為動態(tài)路由的目標(biāo)活動節(jié)點(diǎn)。

定義7 前驅(qū)（后繼）活動：如果從活動A到活動B存在一條通路（不考慮循環(huán)路由），則稱活動A為活動B的前驅(qū)活動，活動B為活動A的后繼活動。

定義8 配對活動：活動節(jié)點(diǎn)A和活動節(jié)點(diǎn)B符合如下三條規(guī)則，則稱活動A和活動B是配對活動。

（1）活動A和活動B至少存在一條通路（為便于敘述將以下規(guī)則活動B設(shè)為活動A的后繼活動）。

（2）設(shè)Ps為從活動B到開始節(jié)點(diǎn)的所有路由活動節(jié)點(diǎn)集合，則P∈Ps均滿足A∈P。

（3）設(shè)Pe為從活動A到結(jié)束節(jié)點(diǎn)的所有路由活動節(jié)點(diǎn)集合，則P∈Pe均滿足B∈P。

那么，設(shè)從活動A到活動B欲進(jìn)行動態(tài)路由，過濾方法如下：

(1)活動A和活動B之間至少存在一條通路。

(2)如果從活動A到活動B之間存在一條通路，并且活動A和活動B是配對活動，則過濾成功。

(3)如果從活動B到活動A之間存在一條通路，則活動A的合并條件是“OR”；活動A和活動B是配對活動，則過濾成功。

如圖2所示，如果活動節(jié)點(diǎn)“送審6”的合并條件是“AND”，則從活動節(jié)點(diǎn)“送審6”動態(tài)路由到活動節(jié)點(diǎn)“送審1”是合法的；而動態(tài)路由至活動節(jié)點(diǎn)“送審2”或“送審3”則是非法的。

2.2.2 多版本流程的動態(tài)遷移

多版本流程的實(shí)質(zhì)是工作流運(yùn)行過程中對原有流程定義的修改，主要有以下幾個(gè)方面：①流程基本屬性與其相關(guān)數(shù)據(jù)的修改；②活動基本屬性與其相關(guān)數(shù)據(jù)的修改；③遷移基本屬性的修改；④活動和遷移的增加或刪除，以及所造成的路由更改。

與流程動態(tài)路由調(diào)度僅造成流程實(shí)例自身執(zhí)行的修改不同的是，流程定義的修改可能會對屬于該流程定義的所有流程實(shí)例的執(zhí)行造成影響。傳統(tǒng)的處理策略有以下幾種方式：

（1）重起。對屬于該流程定義的所有未完成流程實(shí)例均執(zhí)行重起操作，并通過回滾（Rollback）機(jī)制來處理由已運(yùn)行流程實(shí)例帶來的影響。該策略處理簡單，但不適合無法通過回滾來消除影響的情況。

（2）繼續(xù)。繼續(xù)執(zhí)行該流程定義的未完成流程實(shí)例，新起流程實(shí)例按照更改后的流程定義執(zhí)行。該策略處理簡單，但不能滿足用戶的一些需求。

（3）遷移。通過一定的策略，將該流程定義的未完成流程實(shí)例的執(zhí)行由老流程定義遷移至新流程定義，按照新流程定義執(zhí)行。

D—Flow Engine通過流程定義版本管理實(shí)施的流程定義級更改處理策略，以流程定義有效性為開關(guān)，實(shí)現(xiàn)繼續(xù)和遷移兩種處理策略的動態(tài)選擇。如果舊版本流程定義還有效，則舊版本流程定義的所有未完成流程實(shí)例采用繼續(xù)策略，按照舊版本流程定義執(zhí)行；否則采用遷移的處理策略。與動態(tài)路由調(diào)度一樣，流程間遷移也存在數(shù)據(jù)依賴和路由依賴的問題，所以遷移并不一定成功。一旦發(fā)現(xiàn)遷移失敗，則應(yīng)立即采用重起策略。

可將流程動態(tài)遷移的過程歸納為五個(gè)步驟：暫停執(zhí)行、流程遷移、遷移后提交、正確性驗(yàn)證、繼續(xù)執(zhí)行。暫停執(zhí)行是當(dāng)一個(gè)流程實(shí)例在運(yùn)行過程中接到一個(gè)流程遷移的工作流內(nèi)部操作消息時(shí)，該流程實(shí)例要保持的一種狀態(tài)。這是流程定義中已明確規(guī)定的，以便系統(tǒng)進(jìn)行處理。流程動態(tài)遷移的基本策略是：若當(dāng)前活動或遷移是Private的，則沿用老版本流程的活動或遷移；當(dāng)前活動或遷移是Public的，則按照新流程定義中的活動遷移替代映射關(guān)系用新版本活動或遷移代替老版本活動或遷移。提交過程是按照修改后的流程定義來執(zhí)行流程實(shí)例的。這時(shí)要考慮兩方面問題：①新流程會不會影響原先的運(yùn)行狀態(tài)，包括撤銷已執(zhí)行的部分活動、回退到先前某個(gè)活動（可能需要補(bǔ)償）、跳到另一個(gè)活動執(zhí)行；②新流程中的活動與原先活動是否存在數(shù)據(jù)關(guān)聯(lián)和路由關(guān)聯(lián)、其相應(yīng)的關(guān)聯(lián)內(nèi)容是什么、活動之間的關(guān)聯(lián)關(guān)系是否會影響該流程與其他流程的關(guān)聯(lián)關(guān)系等。這些必須有相應(yīng)的關(guān)聯(lián)規(guī)則來約束。動態(tài)遷移后的工作流需要對其進(jìn)行驗(yàn)證，驗(yàn)證的內(nèi)容包括在結(jié)構(gòu)和語義上是否正確、是否破壞了數(shù)據(jù)一致性和控制一致性等。這需要通過活動間、遷移間的相應(yīng)關(guān)聯(lián)規(guī)則來解決，從而保證遷移后工作流的正確性。

工作流在執(zhí)行階段進(jìn)行動態(tài)調(diào)度時(shí)，必須有一組規(guī)則和相應(yīng)算法來保證調(diào)度后工作流的正確性。這些規(guī)則包括提交規(guī)則和驗(yàn)證規(guī)則等。

3 應(yīng)用研究

流程在實(shí)際運(yùn)行過程中，當(dāng)結(jié)束“送審1”后可直接跳過“送審2”激活“送審3”，如圖4所示。

圖4 “送審2”被跳過之后

活動“送審3”可以選擇繼續(xù)執(zhí)行下去直到流程結(jié)束；或者選擇反饋，到可接收反饋節(jié)點(diǎn)“送審1”，如圖5所示。由于業(yè)務(wù)流程的調(diào)整，需要從流程一遷移到新版本流程二。由流程一定義可知活動“送審3”及其關(guān)聯(lián)的“遷移3”和“遷移4”都是私有的。新版本流程二的定義如下：

若同時(shí)設(shè)置流程一的有效性WFIDA·Valid=False，在流程運(yùn)行過程中就會實(shí)現(xiàn)動態(tài)遷移。流程定義二會繼承除“送審2”“遷移3”“送審3”和“遷移4”以外定義一的所有其他活動和遷移；同時(shí)“會簽”“遷移3′”“審核”和“遷移4′”分別覆蓋了“送審2”“遷移3”“送審3”和“遷移4”。所有流程實(shí)例都會按照新版本流程定義二來運(yùn)行，如圖6所示。

4 結(jié)束語

本文所提出的支持動態(tài)調(diào)度的工作流D—Flow Engine已經(jīng)得到實(shí)際應(yīng)用，基本滿足了企業(yè)應(yīng)用中調(diào)度分配的動態(tài)性需求。流程級調(diào)度服務(wù)的動態(tài)路由調(diào)度和多版本流程動態(tài)遷移的目的就是在恰當(dāng)?shù)臅r(shí)間激活合適的活動實(shí)例。在按照所執(zhí)行流程實(shí)例的流程模式規(guī)則前提下，提供最大限度的柔性和動態(tài)性，是流程實(shí)例執(zhí)行的關(guān)鍵服務(wù)，也是工作流系統(tǒng)性能和動態(tài)性的關(guān)鍵所在。在融合流程繼承機(jī)制和動態(tài)路由基礎(chǔ)上，D—Flow Engine具備了很高的柔性和動態(tài)性。但是還有很多工作尚未完成，如繼承遷移的事務(wù)性處理、高性能調(diào)度算法等都是有待進(jìn)一步解決的問題。

本文中所涉及到的圖表、注解、公式等內(nèi)容請以PDF格式閱讀原文。