摘要：針對當前企業(yè)和政府對分布式工作流應用的需求趨勢，給出了一個(gè)基于JMX（Java Management Extensions）－Java管理擴展框架和Observer觀(guān)察者模式的可自管理的分布式工作流引擎（Self-Management Distributed Workflow Engine）的設計與實(shí)現。在該實(shí)現中以觀(guān)察者模式作為主控引擎與各個(gè)執行引擎進(jìn)行分布式協(xié)作的實(shí)現機制。利用JMX Notification Model（JMX通知模型）和JMX Timer Service(JMX時(shí)間服務(wù))實(shí)現觀(guān)察者模式的異步特性。主控引擎充當目標對象,所有的執行引擎充當觀(guān)察者并關(guān)注主控引擎的狀態(tài)改變。主控引擎的調度機采用輪轉法為所有的實(shí)例活動(dòng)動(dòng)態(tài)分配執行引擎。執行引擎通過(guò)在啟動(dòng)時(shí)自動(dòng)注冊到主控引擎，關(guān)閉時(shí)自動(dòng)從主控引擎注銷(xiāo)，實(shí)現了整個(gè)系統的可自管理性，而以工作流命名空間（WorkflowNameSpace）的形式對工作流相關(guān)數據的封裝和EJB容器提供的良好的事務(wù)特性，保證了整個(gè)系統的可靠性。
關(guān)鍵詞：java管理擴展框架；觀(guān)察者模式；分布式工作流引擎 文獻標識碼：A 中圖分類(lèi)號：TP391
1 引言
工作流技術(shù)是實(shí)現企業(yè)業(yè)務(wù)過(guò)程建模、業(yè)務(wù)過(guò)程仿真分析、業(yè)務(wù)過(guò)程優(yōu)化、業(yè)務(wù)過(guò)程管理與集成，從而最終實(shí)現業(yè)務(wù)過(guò)程自動(dòng)化的核心技術(shù)[1]。早期的工作流應用系統都是集中式的，即由一個(gè)工作流引擎去完成整個(gè)流程實(shí)例的執行。隨著(zhù)計算機和網(wǎng)絡(luò )技術(shù)的發(fā)展更加迅速和成熟，特別是Internet 應用日益普及的情況下，現代企業(yè)和政府的信息資源越來(lái)越表現出一種異構、分布、松散耦合的特點(diǎn)，信息共享、資源整合、協(xié)同辦公已成為當前眾多企業(yè)和政府的共同需求，而隨著(zhù)EJB、RMI、Web Service等分布式技術(shù)的日益成熟，分布式工作流的研究已成為當前眾多組織和廠(chǎng)商的共同方向。
1.1 分布式工作流引擎概述
“分布式工作流引擎”的概念是相對于早期的集中式工作流引擎而言的，即整個(gè)工作流管理系統只有一個(gè)核心引擎，這個(gè)核心引擎負責解析工作流的流程定義，將工作流定義加載為運行時(shí)定義，然后調度和監控流程中每個(gè)活動(dòng)的執行。對于人工活動(dòng)結點(diǎn)，負責為參與者生成相關(guān)的工作項，對于自動(dòng)活動(dòng)結點(diǎn)，負責調用外部的具體應用（如企業(yè)中的HR、CRM等應用，或者是執行某項操作的一個(gè)JavaBean）[2]，這種集中式的工作流管理系統由于主要的負荷全集中在一個(gè)工作流引擎上，因此在可擴展性、健壯性以及吞吐量等方面都不能滿(mǎn)足企業(yè)執行大規模復雜應用的需求，尤其是當基于此集中式的工作流引擎的應用同時(shí)被大量用戶(hù)訪(fǎng)問(wèn)時(shí)，將有可能導致工作流服務(wù)器的過(guò)載而癱瘓[3]。
所謂分布式工作流引擎是指采用一組分布在不同節點(diǎn)上的工作流引擎來(lái)共同協(xié)作完成整個(gè)工作流實(shí)例的執行。每個(gè)工作流引擎負責完成其中一部分活動(dòng)實(shí)例的執行，不同的工作流引擎之間通過(guò)可靠的通信機制實(shí)現協(xié)作[4]。通過(guò)分布在不同網(wǎng)絡(luò )節點(diǎn)上的多個(gè)工作流引擎的協(xié)作來(lái)運行工作流流程，可以明顯改善集中式工作流引擎的性能瓶頸問(wèn)題。
1.2 研究現狀
在分布式工作流的研究領(lǐng)域，以IBM公司的基于“持久消息隊列”、瑞士蘇黎士大學(xué)的基于“事件驅動(dòng)”和美國達特茅斯大學(xué)的基于“可移動(dòng)代理”的分布式工作流系統較具典型性和可行性[1]。
基于“持久消息隊列”的分布式工作流―Exotica/FMQM(FlowMark on Message Queue Manager)，以“消息傳送”為實(shí)現機制。執行節點(diǎn)接收到消息后，執行當前活動(dòng)，執行完當前活動(dòng)后，根據當前活動(dòng)的輸出連接弧向其它節點(diǎn)發(fā)送消息，從而推動(dòng)整個(gè)過(guò)程實(shí)例的進(jìn)程。
基于“事件驅動(dòng)”的分布式工作流―EVE（Event Engine－事件引擎），主要由事件引擎服務(wù)器和Broker（代理）組成。事件引擎服務(wù)器負責接收來(lái)自本地代理及遠程事件引擎服務(wù)器的事件，并根據ECA（Event Condition Action）規則定義，把事件發(fā)送給“感興趣”的代理，當代理接到相應的事件后，就開(kāi)始執行一個(gè)工作流實(shí)例的某一個(gè)活動(dòng)，在這期間，代理還會(huì )產(chǎn)生新的事件。這些事件被通知到事件引擎服務(wù)器后，服務(wù)器將繼續以事件的方式推動(dòng)整個(gè)過(guò)程實(shí)例的進(jìn)程。
基于“可移動(dòng)代理”的分布式工作流―DartFlow，由可移動(dòng)的代理將代碼與數據傳遞到另外的網(wǎng)絡(luò )節點(diǎn)上去執行，從而實(shí)現工作流過(guò)程的分布式執行。
Yan等人采用Petri網(wǎng)來(lái)對分布式工作流系統進(jìn)行建模，進(jìn)而提出標準的工作流結構和工作流塊的概念，
以此支持復雜的分布式工作流管理系統的實(shí)現[5],Alonso等人考慮了分布式工作流引擎中的數據管理問(wèn)題[6]，Pallec等人采用MOF(Meta-Object Facility)來(lái)達到工作流管理系統中的互操作性[7]。這些方法或多或少都能達到分布式工作流管理系統的目的，但在系統的自管理性、可擴展性方面并不令人滿(mǎn)意。本文針對當前企業(yè)和政府對分布式工作流管理系統應用的這種需求趨勢，提出了一種分布式工作流引擎的實(shí)現方案，即使用JMX（Java Management Extensions）－Java管理擴展框架和Observer（觀(guān)察者）模式，實(shí)現可高效自管理的分布式工作流引擎，同時(shí)利用觀(guān)察者模式所具有的異步調用的特點(diǎn)，實(shí)現了整個(gè)工作流引擎的高效性和低耦合性。
2 可自管理的分布式工作流引擎(SMDWE--Self-Management Distributed Workflow Engine)的設計
2.1 SMDWE設計原理
SMDWE的設計分為二個(gè)部分，即數據存儲的設計和邏輯控制的設計。
2.1.1 數據存儲的設計
基于關(guān)系數據庫的多表結構，以EJB的CMP（Container-Managed Persistence容器管理的持久性）作為持久化策略統一以實(shí)體Bean的形式存儲工作流模型定義的相關(guān)數據及運行實(shí)例數據。運行時(shí)采用一組實(shí)體Bean將靜態(tài)定義加載為運行時(shí)定義。同時(shí)，該CMP也就是運行時(shí)實(shí)例。將運行時(shí)工作流的定義劃分為小的對象，即如下的核心實(shí)例：流程（InstProcess）、活動(dòng)（InstActivity）、工作項（Workitem）、轉移（InstTransition）、其它相關(guān)數據。將運行時(shí)工作流的定義劃分為小的對象，減少了資源沖突的可能，既提高了效率，又保證了線(xiàn)程安全性。同時(shí)可以將這些對象序列化之后方便地在執行引擎之間進(jìn)行傳遞。
2.1.2 邏輯控制的設計
Observer(觀(guān)察者)模式，是一種典型的設計模式，我們通常采用它來(lái)減少互相通信的組件之間的耦合從而實(shí)現異步調用。傳統的觀(guān)察者設計模式有兩個(gè)主要的參與者：一個(gè) subject（目標）和一個(gè) observer（觀(guān)察者），其中觀(guān)察者關(guān)注目標的狀態(tài)改變。
JMX是具有高度可伸縮性的管理框架，是 Java 應用程序的管理規范，目前已成為新的J2EE規范中一部分。JMX可以實(shí)現應用程序組件的熱插拔、熱配置和熱管理。另外，JMX 的功能不僅僅是對組件進(jìn)行管理，對那些基于組件進(jìn)行開(kāi)發(fā)的應用程序，JMX也提供了一個(gè)統一的、可配置的管理框架[8]。JMX管理框架中的MBean通知模型類(lèi)似于Java中的事件監聽(tīng)器模型。MBean或管理應用程序可以作為MBean事件的監聽(tīng)器注冊。在本實(shí)現中，我們將實(shí)現了NotificationListener接口的主控狀態(tài)機（MainEngineObservable）作為MBean事件的監聽(tīng)器注冊到MBeanServer上，用來(lái)接收由JMX框架提供的時(shí)間服務(wù)Timer所循環(huán)發(fā)出的通知。
SMDWE由一個(gè)主控引擎和分布在網(wǎng)絡(luò )中的多個(gè)執行引擎構成。執行引擎作為觀(guān)察者注冊到主控引擎上，主控引擎和執行引擎分別作為目標對象和觀(guān)察者。主控引擎由一個(gè)分布式引擎管理器充當具體的目標對象與執行引擎的觀(guān)察代理器進(jìn)行通信。主控引擎負責執行流程的初始活動(dòng)和動(dòng)態(tài)調度執行引擎去執行流程中的其它后續活動(dòng)。當初始活動(dòng)執行完畢時(shí)，目標對象（主控引擎）的狀態(tài)發(fā)生改變，然后主控引擎調用動(dòng)態(tài)調度機根據動(dòng)態(tài)調度算法決定后續活動(dòng)的執行者，同時(shí)觀(guān)察者（執行引擎）得到一個(gè)狀態(tài)變更通知（此通知中包括當前活動(dòng)及其轉移的相關(guān)數據和執行此活動(dòng)的執行引擎的名稱(chēng)），然后目標對象（主控引擎）回調每個(gè)執行引擎的觀(guān)察代理器的update()方法，如果執行引擎的名稱(chēng)與通知中的名稱(chēng)一致，則此執行引擎的觀(guān)察代理器調用活動(dòng)處理器執行相關(guān)的動(dòng)作（執行流程的第二個(gè)活動(dòng)），依次類(lèi)推，此執行引擎在執行完自己的任務(wù)后，將回調主控引擎的addNotification()方法重新設置主控引擎的狀態(tài)，此時(shí)其他的觀(guān)察者（執行引擎）再次得到主控引擎的狀態(tài)變更通知，然后符合條件的觀(guān)察者（執行引擎）繼續執行自己的動(dòng)作，從而推動(dòng)整個(gè)工作流流程的前進(jìn)。
3 系統結構
根據對SMDWE的設計原理的分析，下面給出其整體結構圖：
1
圖1 SMDWE系統結構圖
定義態(tài)系統主要包括可視化的過(guò)程建模定義工具，用戶(hù)根據實(shí)際的業(yè)務(wù)流程進(jìn)行建模，然后建模定義調用過(guò)程定義存儲服務(wù)將業(yè)務(wù)模型存入數據庫。
運行態(tài)系統是由部署在網(wǎng)絡(luò )上的一個(gè)主控引擎和多個(gè)執行引擎共同組成。主控引擎和執行引擎之間通過(guò)EJB遠程調用進(jìn)行通信。SMDWE由工作表管理器、活動(dòng)執行處理器（主控引擎、執行引擎）、過(guò)程實(shí)例加載器、過(guò)程定義解釋器、分布式引擎管理器、動(dòng)態(tài)調度機、主控狀態(tài)機、觀(guān)察代理器、觀(guān)察器、應用程序代理器、工作表生成器等組成。下面對各部分做簡(jiǎn)單的說(shuō)明：
工作表管理器：負責與流程參與者交互，為其生成相關(guān)的工作項，供辦理人拾取、提交工作項；
活動(dòng)執行處理器（主控引擎、執行引擎）：負責執行具體的活動(dòng)，對于人工活動(dòng)負責生成相關(guān)的工作項，對于自動(dòng)活動(dòng)負責調用外部的具體應用（主控工作流引擎只負責執行初始活動(dòng)）；
過(guò)程實(shí)例加載器：主要負責接收用戶(hù)的流程啟動(dòng)請求，然后對靜態(tài)的流程定義進(jìn)行加載；
過(guò)程定義解釋器：負責將xml形式的流程定義與流程對象進(jìn)行互相轉換；
分布式引擎管理器：負責維護網(wǎng)絡(luò )上所有的執行引擎的URL（Uniform Resource Locator統一資源定位符）及它們各自觀(guān)察代理器的JNDI（Java Naming and Directory Interface － Java命名和目錄接口），網(wǎng)絡(luò )上所有的執行引擎都首先要注冊到此管理器上，然后再由其注冊到主控狀態(tài)機上。流程執行時(shí)負責接收執行引擎發(fā)送的已執行活動(dòng)的信息，取得其后繼活動(dòng)，調用JMX的時(shí)間服務(wù)向主控狀態(tài)機發(fā)送狀態(tài)變更通知。此管理器用EJB實(shí)現，由執行引擎的觀(guān)察代理器遠程調用；
動(dòng)態(tài)調度機：主要根據負載均衡原理，利用輪轉法，動(dòng)態(tài)調度各個(gè)執行引擎；
主控狀態(tài)機：作為目標對象維護執行引擎的觀(guān)察者列表，負責記錄每個(gè)流程實(shí)例中執行活動(dòng)實(shí)例的狀態(tài)，同時(shí)負責監聽(tīng)分布式引擎管理器發(fā)出的狀態(tài)變更通知。狀態(tài)變更時(shí)，負責向觀(guān)察者（執行引擎）發(fā)送通知。最后調用動(dòng)態(tài)調度機，決定下一個(gè)活動(dòng)的執行者；
觀(guān)察代理器：是執行工作流引擎負責觀(guān)察目標對象的觀(guān)察器的遠程代理，由EJB實(shí)現；
觀(guān)察器：執行引擎的本地觀(guān)察者，啟動(dòng)時(shí)負責調用分布式引擎管理器將自身注冊到主控引擎上，執行
流程時(shí)負責觀(guān)察主控工作流引擎的狀態(tài)，并提供update()回調方法；
應用程序代理器：負責代理執行外部的應用程序，如JavaBean、EJB、特定應用程序等；
工作表生成器：在執行引擎中只負責生成工作項；
4 系統實(shí)現方案
4.1 主控引擎的Observable組件模型
圖2 主控引擎的Observable組件模型圖
主控引擎的Observable組件模型如圖2所示，其中MainEngineObservable類(lèi)繼承java.util.Observable類(lèi)，作為主控引擎的流程狀態(tài)機，其作用如下：
1） 實(shí)現目標對象（Subject）的身份，負責維護所有觀(guān)察者（執行引擎觀(guān)察器）的一個(gè)列表；
2） 實(shí)現javax.management.NotificationListener接口，負責監聽(tīng)分布式引擎管理器發(fā)出的狀態(tài)變更通知；
3） 接到通知后，先調用父類(lèi)Observable的setChanged()方法改變自身狀態(tài)，然后調用notifyObservers()方法通知所有的觀(guān)察者主控狀態(tài)機的狀態(tài)發(fā)生改變；
4） notifyObservers()方法分別調用注冊表中的每個(gè)觀(guān)察器的update()方法；
DistributeEngineManagerBean分布式引擎管理器類(lèi)實(shí)際上是MainEngineObservable的一個(gè)遠程代理，由SessionBean實(shí)現，遠程觀(guān)察者（執行引擎）通過(guò)EJB遠程調用分布式引擎管理器的方法，將自己注冊到目標對象MainEngineObservable上。DistributeEngineManagerBean主要完成以下功能：
1） 保存遠程觀(guān)察者的URL；
2） 接受遠程觀(guān)察者的注冊；
3） 調用MainEngineObservable類(lèi)的addObserver()方法進(jìn)行真正的注冊；
4） 提供addNotification()方法接收已執行活動(dòng)的信息，供主控引擎和執行引擎的活動(dòng)處理器調用；
5） 提供triggerNotification()方法，給主控狀態(tài)機發(fā)送真正的狀態(tài)變更通知；
4.2 執行引擎的Observer組件模型
圖3 執行引擎的Observer組件模型圖
執行引擎的Observable組件模型如圖3所示，其中ExcuteEngineObserver類(lèi)充當執行引擎對主控引擎的觀(guān)察者身份，實(shí)現了java.util.Observer接口類(lèi)，提供一個(gè)update()回調方法，供主控引擎調用。在update()方法中實(shí)現對活動(dòng)執行處理器的調用，從而完成工作流活動(dòng)的執行。
ExcuteEngineObserverProxyBean類(lèi)是ExcuteEngineObserver類(lèi)的一個(gè)遠程代理，實(shí)現了EJB 2.0的Home接口和Remote接口。主控引擎通過(guò)對此代理的遠程調用，然后再由此代理通過(guò)本地調用ExcuteEngineObserver類(lèi)的update()方法，間接實(shí)現對執行引擎的活動(dòng)處理器的執行調用。
4.3 SMDWE的調度算法
為實(shí)現負載均衡，對執行工作流引擎采用輪轉法進(jìn)行調度，其調度算法如下：
(1) 執行引擎注冊：執行引擎啟動(dòng)時(shí)，通過(guò)EJB遠程調用主控引擎的分布式引擎管理器，將自身注冊到主控引擎的主控狀態(tài)機上；
(2) 過(guò)程實(shí)例加載：當主控引擎收到客戶(hù)啟動(dòng)流程的請求后，引擎調用過(guò)程實(shí)例加載器，將需要啟動(dòng)的流程定義加載到運行庫；然后過(guò)程實(shí)例加載器調用過(guò)程定義解釋器，將xml流程定義轉化為Process流程定義對象；
(3) 初始活動(dòng)執行：主控引擎調用活動(dòng)執行處理器執行流程的第一個(gè)初始活動(dòng)；
（4）發(fā)送狀態(tài)變更通知：活動(dòng)執行處理器執行完畢后將此活動(dòng)作為參數調用分布式引擎管理器的addNotification()方法發(fā)送已執行的通知；
（5）取得后繼活動(dòng)：分布式引擎管理器根據已執行活動(dòng)取得其后繼活動(dòng)及工作流相關(guān)數據；
(6) 動(dòng)態(tài)調度執行引擎：分布式引擎管理器取得執行引擎的觀(guān)察器列表，調用動(dòng)態(tài)調度機采用輪轉法確定執行引擎的URL，然后將此URL、（5）中的后繼活動(dòng)作為參數調用自身的triggerNotification()方法給主控狀態(tài)機發(fā)送消息；
(7) 主控狀態(tài)機給執行引擎發(fā)送通知：主控狀態(tài)機監聽(tīng)到消息后，調用setChanged()方法改變自身狀態(tài)，調用NotifyObservers()方法通知所有注冊的執行引擎的觀(guān)察器，回調每個(gè)執行引擎的觀(guān)察器的update()方法；
(8) 執行引擎執行活動(dòng)：如果執行引擎的URL與參數中的URL一致，則執行引擎的觀(guān)察器調用自身的活動(dòng)處理器，執行當前活動(dòng)?；顒?dòng)執行完畢，活動(dòng)處理器再調用分布式引擎管理器的addNotification()方法再次循環(huán)執行(4)－(8)直到整個(gè)流程結束。
(9) 流程結束。整個(gè)流程執行完畢調用清除器清除相關(guān)的實(shí)例數據。
4.4 分布式工作流中的關(guān)鍵問(wèn)題及解決方法
4.4.1 工作流相關(guān)數據和控制數據的處理
為保證分布式工作流相關(guān)數據的同步，本實(shí)現中將工作流的相關(guān)數據以實(shí)例變量的形式，采用實(shí)體Bean進(jìn)行存貯；而在工作流的流程實(shí)例或活動(dòng)實(shí)例中，對工作流的實(shí)例變量采用工作流命名空間二元組（WorkflowNameSpace<InstProcess||InstActivity, variableList>）的形式進(jìn)行封裝，為此我們引入具有面向對象腳本語(yǔ)言特性的Java代碼解釋器BeanShell的NameSpace對工作流實(shí)例變量進(jìn)行封裝。然后將WorkflowNameSpace對象的實(shí)例序列化作為流程實(shí)例（InstProcess）或活動(dòng)實(shí)例(InstActivity)的成員變量在執行引擎之間進(jìn)行傳遞，從而實(shí)現了工作流相關(guān)數據傳遞的可靠傳遞。
工作流的控制數據主要包括工作流實(shí)例的一些數據，例如流程實(shí)例數據、活動(dòng)實(shí)例數據、工作項數據。在分布式的工作流中主控引擎負責以實(shí)體Bean的形式持久化流程實(shí)例數據、活動(dòng)實(shí)例數據和工作項數據，這樣在應用層實(shí)現對工作流的監控時(shí)，就可以統一調度工作流的各種實(shí)例數據。執行引擎通過(guò)EJB遠程調用的方式對實(shí)體Bean的數據進(jìn)行維護，即各個(gè)執行引擎負責工作流活動(dòng)實(shí)例數據和工作項數據的生成。對于人工型的活動(dòng)，執行引擎的活動(dòng)處理器先調用工作流表管理器為此活動(dòng)生成工作項，如果成功則更改活動(dòng)狀態(tài)。對于自動(dòng)型的活動(dòng)，則調用應用程序代理器執行外部應用。
4.4.2 分布式事務(wù)的處理
工作流中的事務(wù)與僅僅滿(mǎn)足ACID（Atomicity原子性、Consistency一致性、Isolation隔離性、Durability持久性）屬性的經(jīng)典事務(wù)模型是完全不同的：1）經(jīng)典的事務(wù)模型主要是面向數據庫的，而工作流中的事務(wù)主要是面向活動(dòng)對象的，需要更復雜的邏輯控制；2）經(jīng)典的事務(wù)模型活動(dòng)時(shí)間很短，工作流中的事務(wù)活動(dòng)時(shí)間很長(cháng)，有可能是一天、一個(gè)月或更長(cháng)；3）經(jīng)典的事務(wù)模型要求一個(gè)事務(wù)如果不全部成功，就全部回滾，而工作流的事務(wù)不能因為一個(gè)活動(dòng)的失敗，就回滾整個(gè)流程實(shí)例（除非有極特殊的需求）；4）經(jīng)典的事務(wù)模型的恢復由數據庫的事務(wù)控制，而工作流的恢復需要工作流數據和業(yè)務(wù)數據同時(shí)進(jìn)行恢復，這時(shí)可能就會(huì )用到復雜的補償操作。針對于工作流事務(wù)的以上特點(diǎn)，在本實(shí)現中只采取對某個(gè)工作流的活動(dòng)進(jìn)行事務(wù)控制，只有某一個(gè)活動(dòng)完全執行成功后才去更改流程的狀態(tài)，分布式執行引擎的活動(dòng)處理器負責將當前的執行活動(dòng)和狀態(tài)兩個(gè)參數傳回給主控引擎的分布式引擎管理器，例如，當執行引擎的活動(dòng)處理器執行工作流的活動(dòng)時(shí)失敗，活動(dòng)處理器先調用已經(jīng)根據實(shí)際的業(yè)務(wù)需求定義的一個(gè)補償操作對業(yè)務(wù)數據進(jìn)行恢復，然后調用分布式引擎管理器的addNotification()方法時(shí)，將當前執行的活動(dòng)對象和錯誤標志傳回主控引擎，分布式引擎管理器判斷如果接收到的是一個(gè)錯誤標志，則調用動(dòng)態(tài)調度機為此失敗的活動(dòng)重新分配一個(gè)執行引擎。
4.5 性能分析
4.5.1 可靠性
分布式工作流由于在引擎協(xié)作的過(guò)程中存在很多的遠程數據傳遞，因此保證其數據傳遞的可靠性是分布式工作流首先要解決的問(wèn)題。在本設計中傳遞的主要是實(shí)例數據，而這些實(shí)例數據以實(shí)體Bean的形式持久化到數據庫，在數據傳遞失敗時(shí)，從EJB容器的實(shí)例池中重新取得實(shí)體Bean的實(shí)例進(jìn)行傳遞，因此有效地解決了數據遠程傳遞失敗時(shí)的恢復問(wèn)題。第二種可能的問(wèn)題是系統中的某個(gè)執行引擎在執行活動(dòng)的過(guò)程中失敗，此時(shí)則采用4.4.2一節中的方法進(jìn)行恢復。第三種是數據的并發(fā)訪(fǎng)問(wèn)問(wèn)題，為了在應用層實(shí)現工作流監控功能時(shí)對數據統一處理，所以在主控引擎中統一持久化實(shí)例數據。此時(shí)由于多個(gè)執行引擎通過(guò)會(huì )話(huà)Bean遠程調用實(shí)體Bean來(lái)生成過(guò)程實(shí)例數據和工作項數據，因此由可能引起并發(fā)訪(fǎng)問(wèn)的沖突問(wèn)題，解決辦法是采用主控引擎的EJB容器提供的事務(wù)隔離策略控制實(shí)體Bean的訪(fǎng)問(wèn)，從而有效地解決了并發(fā)訪(fǎng)問(wèn)數據庫的沖突問(wèn)題。
4.5.2 可擴展性
可擴展性包括功能可擴展性和結構可擴展性。功能擴展性，由于本系統采用JMX作為整體的功能管理框架，JMX本身的對應用程序組件的熱插拔、熱配置、熱管理的特性決定了本系統具有良好的功能擴展性。在結構擴展性方面，大多數的分布式引擎不能滿(mǎn)足企業(yè)的分布式需求，因為這些分布式引擎只是靜態(tài)意義上的分布，即在流程定義期，將過(guò)程的活動(dòng)定義與執行引擎所在的網(wǎng)絡(luò )節點(diǎn)進(jìn)行綁定（如基于消息的Exotica），這樣導致了流程定義與執行引擎的緊偶合。而SMDWE是基于觀(guān)察者模式實(shí)現，因此活動(dòng)的執行是在運行期通過(guò)負載均衡算法動(dòng)態(tài)決定的，所以是真正意義上的可動(dòng)態(tài)柔性擴展的系統。在實(shí)現時(shí)編寫(xiě)一個(gè)可由容器自動(dòng)啟動(dòng)的Servlet，每個(gè)執行引擎啟動(dòng)時(shí)，此Servlet自動(dòng)執行，調用觀(guān)察代理器，由觀(guān)察代理器遠程調用分布式引擎管理器的addObservers()方法將自身注冊到主控引擎上。主控引擎的分布式引擎管理器將每個(gè)注冊過(guò)的執行引擎的URL存入數據庫，動(dòng)態(tài)調度機動(dòng)態(tài)調度執行引擎時(shí)首先調用分布式引擎管理器的getObservers()方法獲得所有注冊成功的執行引擎列表，然后根據輪轉法進(jìn)行調度。系統需要擴展時(shí)，在相應的網(wǎng)絡(luò )節點(diǎn)上重新部署一個(gè)執行引擎，然后啟動(dòng)執行引擎，執行引擎按照上面的方法注冊到主控引擎，實(shí)現了動(dòng)態(tài)擴展。
4.5.3 容錯性
當分布式環(huán)境中的某個(gè)分布式工作流引擎出現故障時(shí)，只有那些正在此分布式工作流引擎執行的過(guò)程實(shí)例會(huì )受到影響，不會(huì )使整個(gè)系統癱瘓。而當其他流程實(shí)例請求工作流引擎時(shí)將會(huì )繞過(guò)此工作流引擎。
5 應用實(shí)例
根據上面的設計與實(shí)現分析，下面給出一個(gè)應用實(shí)例來(lái)說(shuō)明怎樣應用本文中的方法實(shí)現SMDWE的可自管理性和可靠性，應用JMX的時(shí)間通知模型實(shí)現分布式引擎的異步性。
1）執行引擎的自動(dòng)擴展：執行引擎的動(dòng)態(tài)擴展是通過(guò)分別調用主控引擎的分布式引擎管理器的注冊
方法addObserver（）和注銷(xiāo)方法deleteObserver（）實(shí)現的。其清單如下DistributeEngineManagerBean.java：
public void addObserver(String excuteEngineURL,String observerJNDIName,String homeInterfaceName) throws WorkflowException {
//向主控引擎注冊一個(gè)觀(guān)察者
observerList.add(excuteEngineURL+":"+observerJNDIName+":"+homeInterfaceName);
}
public void deleteObserver(String excuteEngineURL,String observerJNDIName,String homeInterfaceName) throws WorkflowException{
//刪除一個(gè)指定URL的觀(guān)察者
observerList.remove(excuteEngineURL+":"+observerJNDIName+":"+homeInterfaceName);
}
addObserver()和deleteObserver()方法是兩個(gè)遠程方法，執行引擎啟動(dòng)時(shí)由觀(guān)察器（ExcuteEngineObserver.java）通過(guò)EJB遠程調用addObserver（）方法，將自身注冊到主控引擎上。如果執行引擎關(guān)閉則調用deleteObserver()方法注銷(xiāo)自己。當系統因為性能原因需要擴展時(shí)，就在網(wǎng)絡(luò )上新部署一個(gè)執行引擎并啟動(dòng)，則這個(gè)新部署的引擎通過(guò)上面的方法注冊到了主控引擎。這樣系統就具備了高度的可自管理性，執行引擎可隨時(shí)關(guān)閉或加入到系統中來(lái)。
2）活動(dòng)執行失敗時(shí)的失敗轉發(fā)：執行引擎執行活動(dòng)完畢后，不管成功與否都調用分布式引擎管理器
的addNotification()方法，將執行完畢的活動(dòng)傳回主控引擎，并返回一個(gè)是否成功的標志。清單如下：
public synchronized void addNotification(InstActivity activity, boolean isSucess) throws WorkflowException {
this.isSucess = isSucess;
if (this.isSucess) {
if (errorList.contains(activity)) {
errorList.remove(activity);
}
List lstNextActivities = getNextActivities(activity);
Iterator it = lstNextActivities.iterator();
while (it.hasNext()) {
InstActivity nextActivity = (InstActivity) it.next();
nextActivity.setExcuteEngineURL(getDynamicExcuteEngineURL());
toDoList.add(nextActivity);
}
} else {
errorList.add(activity);
}
}
從清單中可以看出，如果活動(dòng)執行成功則取出其后繼活動(dòng)放入待辦列表中，如果執行失敗則放入失敗列表errorList中，此時(shí)主控引擎可將此失敗的活動(dòng)繼續分配給其它的執行引擎繼續執行，因此結合本文中的其它提高可靠性的方法，到達了系統的可靠性要求。
6 總結
目前分布式工作流管理系統正朝著(zhù)自管理的方向發(fā)展，本文提出了一種基于JMX框架和觀(guān)察者模式實(shí)現高效自管理的分布式工作流引擎的設計與實(shí)現方法。執行引擎可以隨時(shí)加入到自管理的分布式工作流管理系統中，加入時(shí)只需在網(wǎng)絡(luò )上新部署一個(gè)工作流引擎即可，真正地實(shí)現了分布式工作流引擎的自管理和自擴展，每當新增一個(gè)執行引擎時(shí)，系統便自動(dòng)擴展，同時(shí)具有了更好的處理能力。
參考文獻
[1] FAN Yu-shun, LUO Hai-bin, LIN Hui-ping, et al. Fundamentals of Workflow Management Technology[M]. Beijing: Tsinghua University Press, 2001. p.211-220. (in Chinese) [范玉順，羅海濱，林慧萍，等.工作流管理技術(shù)基礎[M]. 北京：清華大學(xué)出版社，2001: 211-220]
[2] Workflow Management Coalition. WFMC-TC-1003. The Workflow Reference Model, Document Status - Issue 1.1, http://www.wfmc.org/standards/docs/tc003v11.pdf
[3] Thomas Bauer, Peter Dadam University of Ulm, Dept. of Databases and Information Systems, Efficient Distributed Workflow Management Based on Variable Server Assignments. http://www.informatik.uni-ulm.de/dbis/01/dbis/downloads/BaDa00.pdf
[4] Workflow Management Coalition. WFMC-TC-1023. Workflow Standard –Interoperability Wf-XML Binding - Issue 1.1, http://www.wfmc.org/standards/docs/Wf-XML-11.pdf
[5] Yan Y, Bejan, A. Modeling workflow within distributed systems[C]. in: The Sixth International Conference on Computer Supported Cooperative Work in Design. July 2001 :433 – 439
[6] Alonso G, et al. Distributed data management in workflow environments[C]. in: Proceedings of Seventh International Workshop on Research Issues in Data Engineering, April 1997: 82 - 90
[7] Le Pallec X, Vantroys T. A cooperative workflow management system with the Meta-Object Facility[C]. in: Proceedings of Fifth IEEE International Enterprise Distributed Object Computing Conference (EDOC ‘01). Sept. 2001: 273 – 280
[8] Java? Management Extensions Instrumentation and Agent Specification, v1.2 http://jcp.org/aboutJava/communityprocess/final/jsr003/index3.html
Design and implementation of Self-Managed Distributed Workflow Engine
XIN Peng1 WANG Shao-feng2
(1．School of Software, Tsinghua University, Beijing 100084；
2．School of Software, Tsinghua University, Beijing 100084)
Abstract：On the basis of requirement for distributed workflow engine in the enterprise and government, a design and implementation of Self-Managed Distributed Workflow Engine which based JMX (Java Management Extensions) and Observer pattern was presented. The central engine communicates with the execute engine as the Observer pattern works. Implements the asynchronous characteristic by using JMX Notification Model and JMX Timer Service. The central engine acts as the subject, and all the execute engines act as the observers and observe the state changes of the central engine. Adopting the Round-Robin algorithm, the scheduler assigns an execute engine for each activity. The execute engine registers with the central engine during the start time, and logout from the central engine during the close time, so the Self-Managed workflow system was implemented. The encapsulation of workflow relevant data by the WorkflowNameSpace object and the well transaction provided by the EJB container ensures the reliability of the workflow system.
Keywords: JMX; Observer pattern; distributed workflow engine
