摘要：針對當(dāng)前企業(yè)和政府對分布式工作流應(yīng)用的需求趨勢，給出了一個(gè)基于JMX（Java Management Extensions）－Java管理擴(kuò)展框架和Observer觀察者模式的可自管理的分布式工作流引擎（Self-Management Distributed Workflow Engine）的設(shè)計(jì)與實(shí)現(xiàn)。在該實(shí)現(xiàn)中以觀察者模式作為主控引擎與各個(gè)執(zhí)行引擎進(jìn)行分布式協(xié)作的實(shí)現(xiàn)機(jī)制。利用JMX Notification Model（JMX通知模型）和JMX Timer Service(JMX時(shí)間服務(wù))實(shí)現(xiàn)觀察者模式的異步特性。主控引擎充當(dāng)目標(biāo)對象,所有的執(zhí)行引擎充當(dāng)觀察者并關(guān)注主控引擎的狀態(tài)改變。主控引擎的調(diào)度機(jī)采用輪轉(zhuǎn)法為所有的實(shí)例活動(dòng)動(dòng)態(tài)分配執(zhí)行引擎。執(zhí)行引擎通過在啟動(dòng)時(shí)自動(dòng)注冊到主控引擎，關(guān)閉時(shí)自動(dòng)從主控引擎注銷，實(shí)現(xiàn)了整個(gè)系統(tǒng)的可自管理性，而以工作流命名空間（WorkflowNameSpace）的形式對工作流相關(guān)數(shù)據(jù)的封裝和EJB容器提供的良好的事務(wù)特性，保證了整個(gè)系統(tǒng)的可靠性。
關(guān)鍵詞：java管理擴(kuò)展框架；觀察者模式；分布式工作流引擎 文獻(xiàn)標(biāo)識(shí)碼：A 中圖分類號(hào)：TP391
1 引言
工作流技術(shù)是實(shí)現(xiàn)企業(yè)業(yè)務(wù)過程建模、業(yè)務(wù)過程仿真分析、業(yè)務(wù)過程優(yōu)化、業(yè)務(wù)過程管理與集成，從而最終實(shí)現(xiàn)業(yè)務(wù)過程自動(dòng)化的核心技術(shù)[1]。早期的工作流應(yīng)用系統(tǒng)都是集中式的，即由一個(gè)工作流引擎去完成整個(gè)流程實(shí)例的執(zhí)行。隨著計(jì)算機(jī)和網(wǎng)絡(luò)技術(shù)的發(fā)展更加迅速和成熟，特別是Internet 應(yīng)用日益普及的情況下，現(xiàn)代企業(yè)和政府的信息資源越來越表現(xiàn)出一種異構(gòu)、分布、松散耦合的特點(diǎn)，信息共享、資源整合、協(xié)同辦公已成為當(dāng)前眾多企業(yè)和政府的共同需求，而隨著EJB、RMI、Web Service等分布式技術(shù)的日益成熟，分布式工作流的研究已成為當(dāng)前眾多組織和廠商的共同方向。
1.1 分布式工作流引擎概述
“分布式工作流引擎”的概念是相對于早期的集中式工作流引擎而言的，即整個(gè)工作流管理系統(tǒng)只有一個(gè)核心引擎，這個(gè)核心引擎負(fù)責(zé)解析工作流的流程定義，將工作流定義加載為運(yùn)行時(shí)定義，然后調(diào)度和監(jiān)控流程中每個(gè)活動(dòng)的執(zhí)行。對于人工活動(dòng)結(jié)點(diǎn)，負(fù)責(zé)為參與者生成相關(guān)的工作項(xiàng)，對于自動(dòng)活動(dòng)結(jié)點(diǎn)，負(fù)責(zé)調(diào)用外部的具體應(yīng)用（如企業(yè)中的HR、CRM等應(yīng)用，或者是執(zhí)行某項(xiàng)操作的一個(gè)JavaBean）[2]，這種集中式的工作流管理系統(tǒng)由于主要的負(fù)荷全集中在一個(gè)工作流引擎上，因此在可擴(kuò)展性、健壯性以及吞吐量等方面都不能滿足企業(yè)執(zhí)行大規(guī)模復(fù)雜應(yīng)用的需求，尤其是當(dāng)基于此集中式的工作流引擎的應(yīng)用同時(shí)被大量用戶訪問時(shí)，將有可能導(dǎo)致工作流服務(wù)器的過載而癱瘓[3]。
所謂分布式工作流引擎是指采用一組分布在不同節(jié)點(diǎn)上的工作流引擎來共同協(xié)作完成整個(gè)工作流實(shí)例的執(zhí)行。每個(gè)工作流引擎負(fù)責(zé)完成其中一部分活動(dòng)實(shí)例的執(zhí)行，不同的工作流引擎之間通過可靠的通信機(jī)制實(shí)現(xiàn)協(xié)作[4]。通過分布在不同網(wǎng)絡(luò)節(jié)點(diǎn)上的多個(gè)工作流引擎的協(xié)作來運(yùn)行工作流流程，可以明顯改善集中式工作流引擎的性能瓶頸問題。
1.2 研究現(xiàn)狀
在分布式工作流的研究領(lǐng)域，以IBM公司的基于“持久消息隊(duì)列”、瑞士蘇黎士大學(xué)的基于“事件驅(qū)動(dòng)”和美國達(dá)特茅斯大學(xué)的基于“可移動(dòng)代理”的分布式工作流系統(tǒng)較具典型性和可行性[1]。
基于“持久消息隊(duì)列”的分布式工作流―Exotica/FMQM(FlowMark on Message Queue Manager)，以“消息傳送”為實(shí)現(xiàn)機(jī)制。執(zhí)行節(jié)點(diǎn)接收到消息后，執(zhí)行當(dāng)前活動(dòng)，執(zhí)行完當(dāng)前活動(dòng)后，根據(jù)當(dāng)前活動(dòng)的輸出連接弧向其它節(jié)點(diǎn)發(fā)送消息，從而推動(dòng)整個(gè)過程實(shí)例的進(jìn)程。
基于“事件驅(qū)動(dòng)”的分布式工作流―EVE（Event Engine－事件引擎），主要由事件引擎服務(wù)器和Broker（代理）組成。事件引擎服務(wù)器負(fù)責(zé)接收來自本地代理及遠(yuǎn)程事件引擎服務(wù)器的事件，并根據(jù)ECA（Event Condition Action）規(guī)則定義，把事件發(fā)送給“感興趣”的代理，當(dāng)代理接到相應(yīng)的事件后，就開始執(zhí)行一個(gè)工作流實(shí)例的某一個(gè)活動(dòng)，在這期間，代理還會(huì)產(chǎn)生新的事件。這些事件被通知到事件引擎服務(wù)器后，服務(wù)器將繼續(xù)以事件的方式推動(dòng)整個(gè)過程實(shí)例的進(jìn)程。
基于“可移動(dòng)代理”的分布式工作流―DartFlow，由可移動(dòng)的代理將代碼與數(shù)據(jù)傳遞到另外的網(wǎng)絡(luò)節(jié)點(diǎn)上去執(zhí)行，從而實(shí)現(xiàn)工作流過程的分布式執(zhí)行。
Yan等人采用Petri網(wǎng)來對分布式工作流系統(tǒng)進(jìn)行建模，進(jìn)而提出標(biāo)準(zhǔn)的工作流結(jié)構(gòu)和工作流塊的概念，
以此支持復(fù)雜的分布式工作流管理系統(tǒng)的實(shí)現(xiàn)[5],Alonso等人考慮了分布式工作流引擎中的數(shù)據(jù)管理問題[6]，Pallec等人采用MOF(Meta-Object Facility)來達(dá)到工作流管理系統(tǒng)中的互操作性[7]。這些方法或多或少都能達(dá)到分布式工作流管理系統(tǒng)的目的，但在系統(tǒng)的自管理性、可擴(kuò)展性方面并不令人滿意。本文針對當(dāng)前企業(yè)和政府對分布式工作流管理系統(tǒng)應(yīng)用的這種需求趨勢，提出了一種分布式工作流引擎的實(shí)現(xiàn)方案，即使用JMX（Java Management Extensions）－Java管理擴(kuò)展框架和Observer（觀察者）模式，實(shí)現(xiàn)可高效自管理的分布式工作流引擎，同時(shí)利用觀察者模式所具有的異步調(diào)用的特點(diǎn)，實(shí)現(xiàn)了整個(gè)工作流引擎的高效性和低耦合性。
2 可自管理的分布式工作流引擎(SMDWE--Self-Management Distributed Workflow Engine)的設(shè)計(jì)
2.1 SMDWE設(shè)計(jì)原理
SMDWE的設(shè)計(jì)分為二個(gè)部分，即數(shù)據(jù)存儲(chǔ)的設(shè)計(jì)和邏輯控制的設(shè)計(jì)。
2.1.1 數(shù)據(jù)存儲(chǔ)的設(shè)計(jì)
基于關(guān)系數(shù)據(jù)庫的多表結(jié)構(gòu)，以EJB的CMP（Container-Managed Persistence容器管理的持久性）作為持久化策略統(tǒng)一以實(shí)體Bean的形式存儲(chǔ)工作流模型定義的相關(guān)數(shù)據(jù)及運(yùn)行實(shí)例數(shù)據(jù)。運(yùn)行時(shí)采用一組實(shí)體Bean將靜態(tài)定義加載為運(yùn)行時(shí)定義。同時(shí)，該CMP也就是運(yùn)行時(shí)實(shí)例。將運(yùn)行時(shí)工作流的定義劃分為小的對象，即如下的核心實(shí)例：流程（InstProcess）、活動(dòng)（InstActivity）、工作項(xiàng)（Workitem）、轉(zhuǎn)移（InstTransition）、其它相關(guān)數(shù)據(jù)。將運(yùn)行時(shí)工作流的定義劃分為小的對象，減少了資源沖突的可能，既提高了效率，又保證了線程安全性。同時(shí)可以將這些對象序列化之后方便地在執(zhí)行引擎之間進(jìn)行傳遞。
2.1.2 邏輯控制的設(shè)計(jì)
Observer(觀察者)模式，是一種典型的設(shè)計(jì)模式，我們通常采用它來減少互相通信的組件之間的耦合從而實(shí)現(xiàn)異步調(diào)用。傳統(tǒng)的觀察者設(shè)計(jì)模式有兩個(gè)主要的參與者：一個(gè) subject（目標(biāo)）和一個(gè) observer（觀察者），其中觀察者關(guān)注目標(biāo)的狀態(tài)改變。
JMX是具有高度可伸縮性的管理框架，是 Java 應(yīng)用程序的管理規(guī)范，目前已成為新的J2EE規(guī)范中一部分。JMX可以實(shí)現(xiàn)應(yīng)用程序組件的熱插拔、熱配置和熱管理。另外，JMX 的功能不僅僅是對組件進(jìn)行管理，對那些基于組件進(jìn)行開發(fā)的應(yīng)用程序，JMX也提供了一個(gè)統(tǒng)一的、可配置的管理框架[8]。JMX管理框架中的MBean通知模型類似于Java中的事件監(jiān)聽器模型。MBean或管理應(yīng)用程序可以作為MBean事件的監(jiān)聽器注冊。在本實(shí)現(xiàn)中，我們將實(shí)現(xiàn)了NotificationListener接口的主控狀態(tài)機(jī)（MainEngineObservable）作為MBean事件的監(jiān)聽器注冊到MBeanServer上，用來接收由JMX框架提供的時(shí)間服務(wù)Timer所循環(huán)發(fā)出的通知。
SMDWE由一個(gè)主控引擎和分布在網(wǎng)絡(luò)中的多個(gè)執(zhí)行引擎構(gòu)成。執(zhí)行引擎作為觀察者注冊到主控引擎上，主控引擎和執(zhí)行引擎分別作為目標(biāo)對象和觀察者。主控引擎由一個(gè)分布式引擎管理器充當(dāng)具體的目標(biāo)對象與執(zhí)行引擎的觀察代理器進(jìn)行通信。主控引擎負(fù)責(zé)執(zhí)行流程的初始活動(dòng)和動(dòng)態(tài)調(diào)度執(zhí)行引擎去執(zhí)行流程中的其它后續(xù)活動(dòng)。當(dāng)初始活動(dòng)執(zhí)行完畢時(shí)，目標(biāo)對象（主控引擎）的狀態(tài)發(fā)生改變，然后主控引擎調(diào)用動(dòng)態(tài)調(diào)度機(jī)根據(jù)動(dòng)態(tài)調(diào)度算法決定后續(xù)活動(dòng)的執(zhí)行者，同時(shí)觀察者（執(zhí)行引擎）得到一個(gè)狀態(tài)變更通知（此通知中包括當(dāng)前活動(dòng)及其轉(zhuǎn)移的相關(guān)數(shù)據(jù)和執(zhí)行此活動(dòng)的執(zhí)行引擎的名稱），然后目標(biāo)對象（主控引擎）回調(diào)每個(gè)執(zhí)行引擎的觀察代理器的update()方法，如果執(zhí)行引擎的名稱與通知中的名稱一致，則此執(zhí)行引擎的觀察代理器調(diào)用活動(dòng)處理器執(zhí)行相關(guān)的動(dòng)作（執(zhí)行流程的第二個(gè)活動(dòng)），依次類推，此執(zhí)行引擎在執(zhí)行完自己的任務(wù)后，將回調(diào)主控引擎的addNotification()方法重新設(shè)置主控引擎的狀態(tài)，此時(shí)其他的觀察者（執(zhí)行引擎）再次得到主控引擎的狀態(tài)變更通知，然后符合條件的觀察者（執(zhí)行引擎）繼續(xù)執(zhí)行自己的動(dòng)作，從而推動(dòng)整個(gè)工作流流程的前進(jìn)。
3 系統(tǒng)結(jié)構(gòu)
根據(jù)對SMDWE的設(shè)計(jì)原理的分析，下面給出其整體結(jié)構(gòu)圖：
1
圖1 SMDWE系統(tǒng)結(jié)構(gòu)圖
定義態(tài)系統(tǒng)主要包括可視化的過程建模定義工具，用戶根據(jù)實(shí)際的業(yè)務(wù)流程進(jìn)行建模，然后建模定義調(diào)用過程定義存儲(chǔ)服務(wù)將業(yè)務(wù)模型存入數(shù)據(jù)庫。
運(yùn)行態(tài)系統(tǒng)是由部署在網(wǎng)絡(luò)上的一個(gè)主控引擎和多個(gè)執(zhí)行引擎共同組成。主控引擎和執(zhí)行引擎之間通過EJB遠(yuǎn)程調(diào)用進(jìn)行通信。SMDWE由工作表管理器、活動(dòng)執(zhí)行處理器（主控引擎、執(zhí)行引擎）、過程實(shí)例加載器、過程定義解釋器、分布式引擎管理器、動(dòng)態(tài)調(diào)度機(jī)、主控狀態(tài)機(jī)、觀察代理器、觀察器、應(yīng)用程序代理器、工作表生成器等組成。下面對各部分做簡單的說明：
工作表管理器：負(fù)責(zé)與流程參與者交互，為其生成相關(guān)的工作項(xiàng)，供辦理人拾取、提交工作項(xiàng)；
活動(dòng)執(zhí)行處理器（主控引擎、執(zhí)行引擎）：負(fù)責(zé)執(zhí)行具體的活動(dòng)，對于人工活動(dòng)負(fù)責(zé)生成相關(guān)的工作項(xiàng)，對于自動(dòng)活動(dòng)負(fù)責(zé)調(diào)用外部的具體應(yīng)用（主控工作流引擎只負(fù)責(zé)執(zhí)行初始活動(dòng)）；
過程實(shí)例加載器：主要負(fù)責(zé)接收用戶的流程啟動(dòng)請求，然后對靜態(tài)的流程定義進(jìn)行加載；
過程定義解釋器：負(fù)責(zé)將xml形式的流程定義與流程對象進(jìn)行互相轉(zhuǎn)換；
分布式引擎管理器：負(fù)責(zé)維護(hù)網(wǎng)絡(luò)上所有的執(zhí)行引擎的URL（Uniform Resource Locator統(tǒng)一資源定位符）及它們各自觀察代理器的JNDI（Java Naming and Directory Interface － Java命名和目錄接口），網(wǎng)絡(luò)上所有的執(zhí)行引擎都首先要注冊到此管理器上，然后再由其注冊到主控狀態(tài)機(jī)上。流程執(zhí)行時(shí)負(fù)責(zé)接收執(zhí)行引擎發(fā)送的已執(zhí)行活動(dòng)的信息，取得其后繼活動(dòng)，調(diào)用JMX的時(shí)間服務(wù)向主控狀態(tài)機(jī)發(fā)送狀態(tài)變更通知。此管理器用EJB實(shí)現(xiàn)，由執(zhí)行引擎的觀察代理器遠(yuǎn)程調(diào)用；
動(dòng)態(tài)調(diào)度機(jī)：主要根據(jù)負(fù)載均衡原理，利用輪轉(zhuǎn)法，動(dòng)態(tài)調(diào)度各個(gè)執(zhí)行引擎；
主控狀態(tài)機(jī)：作為目標(biāo)對象維護(hù)執(zhí)行引擎的觀察者列表，負(fù)責(zé)記錄每個(gè)流程實(shí)例中執(zhí)行活動(dòng)實(shí)例的狀態(tài)，同時(shí)負(fù)責(zé)監(jiān)聽分布式引擎管理器發(fā)出的狀態(tài)變更通知。狀態(tài)變更時(shí)，負(fù)責(zé)向觀察者（執(zhí)行引擎）發(fā)送通知。最后調(diào)用動(dòng)態(tài)調(diào)度機(jī)，決定下一個(gè)活動(dòng)的執(zhí)行者；
觀察代理器：是執(zhí)行工作流引擎負(fù)責(zé)觀察目標(biāo)對象的觀察器的遠(yuǎn)程代理，由EJB實(shí)現(xiàn)；
觀察器：執(zhí)行引擎的本地觀察者，啟動(dòng)時(shí)負(fù)責(zé)調(diào)用分布式引擎管理器將自身注冊到主控引擎上，執(zhí)行
流程時(shí)負(fù)責(zé)觀察主控工作流引擎的狀態(tài)，并提供update()回調(diào)方法；
應(yīng)用程序代理器：負(fù)責(zé)代理執(zhí)行外部的應(yīng)用程序，如JavaBean、EJB、特定應(yīng)用程序等；
工作表生成器：在執(zhí)行引擎中只負(fù)責(zé)生成工作項(xiàng)；
4 系統(tǒng)實(shí)現(xiàn)方案
4.1 主控引擎的Observable組件模型
圖2 主控引擎的Observable組件模型圖
主控引擎的Observable組件模型如圖2所示，其中MainEngineObservable類繼承java.util.Observable類，作為主控引擎的流程狀態(tài)機(jī)，其作用如下：
1） 實(shí)現(xiàn)目標(biāo)對象（Subject）的身份，負(fù)責(zé)維護(hù)所有觀察者（執(zhí)行引擎觀察器）的一個(gè)列表；
2） 實(shí)現(xiàn)javax.management.NotificationListener接口，負(fù)責(zé)監(jiān)聽分布式引擎管理器發(fā)出的狀態(tài)變更通知；
3） 接到通知后，先調(diào)用父類Observable的setChanged()方法改變自身狀態(tài)，然后調(diào)用notifyObservers()方法通知所有的觀察者主控狀態(tài)機(jī)的狀態(tài)發(fā)生改變；
4） notifyObservers()方法分別調(diào)用注冊表中的每個(gè)觀察器的update()方法；
DistributeEngineManagerBean分布式引擎管理器類實(shí)際上是MainEngineObservable的一個(gè)遠(yuǎn)程代理，由SessionBean實(shí)現(xiàn)，遠(yuǎn)程觀察者（執(zhí)行引擎）通過EJB遠(yuǎn)程調(diào)用分布式引擎管理器的方法，將自己注冊到目標(biāo)對象MainEngineObservable上。DistributeEngineManagerBean主要完成以下功能：
1） 保存遠(yuǎn)程觀察者的URL；
2） 接受遠(yuǎn)程觀察者的注冊；
3） 調(diào)用MainEngineObservable類的addObserver()方法進(jìn)行真正的注冊；
4） 提供addNotification()方法接收已執(zhí)行活動(dòng)的信息，供主控引擎和執(zhí)行引擎的活動(dòng)處理器調(diào)用；
5） 提供triggerNotification()方法，給主控狀態(tài)機(jī)發(fā)送真正的狀態(tài)變更通知；
4.2 執(zhí)行引擎的Observer組件模型
圖3 執(zhí)行引擎的Observer組件模型圖
執(zhí)行引擎的Observable組件模型如圖3所示，其中ExcuteEngineObserver類充當(dāng)執(zhí)行引擎對主控引擎的觀察者身份，實(shí)現(xiàn)了java.util.Observer接口類，提供一個(gè)update()回調(diào)方法，供主控引擎調(diào)用。在update()方法中實(shí)現(xiàn)對活動(dòng)執(zhí)行處理器的調(diào)用，從而完成工作流活動(dòng)的執(zhí)行。
ExcuteEngineObserverProxyBean類是ExcuteEngineObserver類的一個(gè)遠(yuǎn)程代理，實(shí)現(xiàn)了EJB 2.0的Home接口和Remote接口。主控引擎通過對此代理的遠(yuǎn)程調(diào)用，然后再由此代理通過本地調(diào)用ExcuteEngineObserver類的update()方法，間接實(shí)現(xiàn)對執(zhí)行引擎的活動(dòng)處理器的執(zhí)行調(diào)用。
4.3 SMDWE的調(diào)度算法
為實(shí)現(xiàn)負(fù)載均衡，對執(zhí)行工作流引擎采用輪轉(zhuǎn)法進(jìn)行調(diào)度，其調(diào)度算法如下：
(1) 執(zhí)行引擎注冊：執(zhí)行引擎啟動(dòng)時(shí)，通過EJB遠(yuǎn)程調(diào)用主控引擎的分布式引擎管理器，將自身注冊到主控引擎的主控狀態(tài)機(jī)上；
(2) 過程實(shí)例加載：當(dāng)主控引擎收到客戶啟動(dòng)流程的請求后，引擎調(diào)用過程實(shí)例加載器，將需要啟動(dòng)的流程定義加載到運(yùn)行庫；然后過程實(shí)例加載器調(diào)用過程定義解釋器，將xml流程定義轉(zhuǎn)化為Process流程定義對象；
(3) 初始活動(dòng)執(zhí)行：主控引擎調(diào)用活動(dòng)執(zhí)行處理器執(zhí)行流程的第一個(gè)初始活動(dòng)；
（4）發(fā)送狀態(tài)變更通知：活動(dòng)執(zhí)行處理器執(zhí)行完畢后將此活動(dòng)作為參數(shù)調(diào)用分布式引擎管理器的addNotification()方法發(fā)送已執(zhí)行的通知；
（5）取得后繼活動(dòng)：分布式引擎管理器根據(jù)已執(zhí)行活動(dòng)取得其后繼活動(dòng)及工作流相關(guān)數(shù)據(jù)；
(6) 動(dòng)態(tài)調(diào)度執(zhí)行引擎：分布式引擎管理器取得執(zhí)行引擎的觀察器列表，調(diào)用動(dòng)態(tài)調(diào)度機(jī)采用輪轉(zhuǎn)法確定執(zhí)行引擎的URL，然后將此URL、（5）中的后繼活動(dòng)作為參數(shù)調(diào)用自身的triggerNotification()方法給主控狀態(tài)機(jī)發(fā)送消息；
(7) 主控狀態(tài)機(jī)給執(zhí)行引擎發(fā)送通知：主控狀態(tài)機(jī)監(jiān)聽到消息后，調(diào)用setChanged()方法改變自身狀態(tài)，調(diào)用NotifyObservers()方法通知所有注冊的執(zhí)行引擎的觀察器，回調(diào)每個(gè)執(zhí)行引擎的觀察器的update()方法；
(8) 執(zhí)行引擎執(zhí)行活動(dòng)：如果執(zhí)行引擎的URL與參數(shù)中的URL一致，則執(zhí)行引擎的觀察器調(diào)用自身的活動(dòng)處理器，執(zhí)行當(dāng)前活動(dòng)?；顒?dòng)執(zhí)行完畢，活動(dòng)處理器再調(diào)用分布式引擎管理器的addNotification()方法再次循環(huán)執(zhí)行(4)－(8)直到整個(gè)流程結(jié)束。
(9) 流程結(jié)束。整個(gè)流程執(zhí)行完畢調(diào)用清除器清除相關(guān)的實(shí)例數(shù)據(jù)。
4.4 分布式工作流中的關(guān)鍵問題及解決方法
4.4.1 工作流相關(guān)數(shù)據(jù)和控制數(shù)據(jù)的處理
為保證分布式工作流相關(guān)數(shù)據(jù)的同步，本實(shí)現(xiàn)中將工作流的相關(guān)數(shù)據(jù)以實(shí)例變量的形式，采用實(shí)體Bean進(jìn)行存貯；而在工作流的流程實(shí)例或活動(dòng)實(shí)例中，對工作流的實(shí)例變量采用工作流命名空間二元組（WorkflowNameSpace<InstProcess||InstActivity, variableList>）的形式進(jìn)行封裝，為此我們引入具有面向?qū)ο竽_本語言特性的Java代碼解釋器BeanShell的NameSpace對工作流實(shí)例變量進(jìn)行封裝。然后將WorkflowNameSpace對象的實(shí)例序列化作為流程實(shí)例（InstProcess）或活動(dòng)實(shí)例(InstActivity)的成員變量在執(zhí)行引擎之間進(jìn)行傳遞，從而實(shí)現(xiàn)了工作流相關(guān)數(shù)據(jù)傳遞的可靠傳遞。
工作流的控制數(shù)據(jù)主要包括工作流實(shí)例的一些數(shù)據(jù)，例如流程實(shí)例數(shù)據(jù)、活動(dòng)實(shí)例數(shù)據(jù)、工作項(xiàng)數(shù)據(jù)。在分布式的工作流中主控引擎負(fù)責(zé)以實(shí)體Bean的形式持久化流程實(shí)例數(shù)據(jù)、活動(dòng)實(shí)例數(shù)據(jù)和工作項(xiàng)數(shù)據(jù)，這樣在應(yīng)用層實(shí)現(xiàn)對工作流的監(jiān)控時(shí)，就可以統(tǒng)一調(diào)度工作流的各種實(shí)例數(shù)據(jù)。執(zhí)行引擎通過EJB遠(yuǎn)程調(diào)用的方式對實(shí)體Bean的數(shù)據(jù)進(jìn)行維護(hù)，即各個(gè)執(zhí)行引擎負(fù)責(zé)工作流活動(dòng)實(shí)例數(shù)據(jù)和工作項(xiàng)數(shù)據(jù)的生成。對于人工型的活動(dòng)，執(zhí)行引擎的活動(dòng)處理器先調(diào)用工作流表管理器為此活動(dòng)生成工作項(xiàng)，如果成功則更改活動(dòng)狀態(tài)。對于自動(dòng)型的活動(dòng)，則調(diào)用應(yīng)用程序代理器執(zhí)行外部應(yīng)用。
4.4.2 分布式事務(wù)的處理
工作流中的事務(wù)與僅僅滿足ACID（Atomicity原子性、Consistency一致性、Isolation隔離性、Durability持久性）屬性的經(jīng)典事務(wù)模型是完全不同的：1）經(jīng)典的事務(wù)模型主要是面向數(shù)據(jù)庫的，而工作流中的事務(wù)主要是面向活動(dòng)對象的，需要更復(fù)雜的邏輯控制；2）經(jīng)典的事務(wù)模型活動(dòng)時(shí)間很短，工作流中的事務(wù)活動(dòng)時(shí)間很長，有可能是一天、一個(gè)月或更長；3）經(jīng)典的事務(wù)模型要求一個(gè)事務(wù)如果不全部成功，就全部回滾，而工作流的事務(wù)不能因?yàn)橐粋€(gè)活動(dòng)的失敗，就回滾整個(gè)流程實(shí)例（除非有極特殊的需求）；4）經(jīng)典的事務(wù)模型的恢復(fù)由數(shù)據(jù)庫的事務(wù)控制，而工作流的恢復(fù)需要工作流數(shù)據(jù)和業(yè)務(wù)數(shù)據(jù)同時(shí)進(jìn)行恢復(fù)，這時(shí)可能就會(huì)用到復(fù)雜的補(bǔ)償操作。針對于工作流事務(wù)的以上特點(diǎn)，在本實(shí)現(xiàn)中只采取對某個(gè)工作流的活動(dòng)進(jìn)行事務(wù)控制，只有某一個(gè)活動(dòng)完全執(zhí)行成功后才去更改流程的狀態(tài)，分布式執(zhí)行引擎的活動(dòng)處理器負(fù)責(zé)將當(dāng)前的執(zhí)行活動(dòng)和狀態(tài)兩個(gè)參數(shù)傳回給主控引擎的分布式引擎管理器，例如，當(dāng)執(zhí)行引擎的活動(dòng)處理器執(zhí)行工作流的活動(dòng)時(shí)失敗，活動(dòng)處理器先調(diào)用已經(jīng)根據(jù)實(shí)際的業(yè)務(wù)需求定義的一個(gè)補(bǔ)償操作對業(yè)務(wù)數(shù)據(jù)進(jìn)行恢復(fù)，然后調(diào)用分布式引擎管理器的addNotification()方法時(shí)，將當(dāng)前執(zhí)行的活動(dòng)對象和錯(cuò)誤標(biāo)志傳回主控引擎，分布式引擎管理器判斷如果接收到的是一個(gè)錯(cuò)誤標(biāo)志，則調(diào)用動(dòng)態(tài)調(diào)度機(jī)為此失敗的活動(dòng)重新分配一個(gè)執(zhí)行引擎。
4.5 性能分析
4.5.1 可靠性
分布式工作流由于在引擎協(xié)作的過程中存在很多的遠(yuǎn)程數(shù)據(jù)傳遞，因此保證其數(shù)據(jù)傳遞的可靠性是分布式工作流首先要解決的問題。在本設(shè)計(jì)中傳遞的主要是實(shí)例數(shù)據(jù)，而這些實(shí)例數(shù)據(jù)以實(shí)體Bean的形式持久化到數(shù)據(jù)庫，在數(shù)據(jù)傳遞失敗時(shí)，從EJB容器的實(shí)例池中重新取得實(shí)體Bean的實(shí)例進(jìn)行傳遞，因此有效地解決了數(shù)據(jù)遠(yuǎn)程傳遞失敗時(shí)的恢復(fù)問題。第二種可能的問題是系統(tǒng)中的某個(gè)執(zhí)行引擎在執(zhí)行活動(dòng)的過程中失敗，此時(shí)則采用4.4.2一節(jié)中的方法進(jìn)行恢復(fù)。第三種是數(shù)據(jù)的并發(fā)訪問問題，為了在應(yīng)用層實(shí)現(xiàn)工作流監(jiān)控功能時(shí)對數(shù)據(jù)統(tǒng)一處理，所以在主控引擎中統(tǒng)一持久化實(shí)例數(shù)據(jù)。此時(shí)由于多個(gè)執(zhí)行引擎通過會(huì)話Bean遠(yuǎn)程調(diào)用實(shí)體Bean來生成過程實(shí)例數(shù)據(jù)和工作項(xiàng)數(shù)據(jù)，因此由可能引起并發(fā)訪問的沖突問題，解決辦法是采用主控引擎的EJB容器提供的事務(wù)隔離策略控制實(shí)體Bean的訪問，從而有效地解決了并發(fā)訪問數(shù)據(jù)庫的沖突問題。
4.5.2 可擴(kuò)展性
可擴(kuò)展性包括功能可擴(kuò)展性和結(jié)構(gòu)可擴(kuò)展性。功能擴(kuò)展性，由于本系統(tǒng)采用JMX作為整體的功能管理框架，JMX本身的對應(yīng)用程序組件的熱插拔、熱配置、熱管理的特性決定了本系統(tǒng)具有良好的功能擴(kuò)展性。在結(jié)構(gòu)擴(kuò)展性方面，大多數(shù)的分布式引擎不能滿足企業(yè)的分布式需求，因?yàn)檫@些分布式引擎只是靜態(tài)意義上的分布，即在流程定義期，將過程的活動(dòng)定義與執(zhí)行引擎所在的網(wǎng)絡(luò)節(jié)點(diǎn)進(jìn)行綁定（如基于消息的Exotica），這樣導(dǎo)致了流程定義與執(zhí)行引擎的緊偶合。而SMDWE是基于觀察者模式實(shí)現(xiàn)，因此活動(dòng)的執(zhí)行是在運(yùn)行期通過負(fù)載均衡算法動(dòng)態(tài)決定的，所以是真正意義上的可動(dòng)態(tài)柔性擴(kuò)展的系統(tǒng)。在實(shí)現(xiàn)時(shí)編寫一個(gè)可由容器自動(dòng)啟動(dòng)的Servlet，每個(gè)執(zhí)行引擎啟動(dòng)時(shí)，此Servlet自動(dòng)執(zhí)行，調(diào)用觀察代理器，由觀察代理器遠(yuǎn)程調(diào)用分布式引擎管理器的addObservers()方法將自身注冊到主控引擎上。主控引擎的分布式引擎管理器將每個(gè)注冊過的執(zhí)行引擎的URL存入數(shù)據(jù)庫，動(dòng)態(tài)調(diào)度機(jī)動(dòng)態(tài)調(diào)度執(zhí)行引擎時(shí)首先調(diào)用分布式引擎管理器的getObservers()方法獲得所有注冊成功的執(zhí)行引擎列表，然后根據(jù)輪轉(zhuǎn)法進(jìn)行調(diào)度。系統(tǒng)需要擴(kuò)展時(shí)，在相應(yīng)的網(wǎng)絡(luò)節(jié)點(diǎn)上重新部署一個(gè)執(zhí)行引擎，然后啟動(dòng)執(zhí)行引擎，執(zhí)行引擎按照上面的方法注冊到主控引擎，實(shí)現(xiàn)了動(dòng)態(tài)擴(kuò)展。
4.5.3 容錯(cuò)性
當(dāng)分布式環(huán)境中的某個(gè)分布式工作流引擎出現(xiàn)故障時(shí)，只有那些正在此分布式工作流引擎執(zhí)行的過程實(shí)例會(huì)受到影響，不會(huì)使整個(gè)系統(tǒng)癱瘓。而當(dāng)其他流程實(shí)例請求工作流引擎時(shí)將會(huì)繞過此工作流引擎。
5 應(yīng)用實(shí)例
根據(jù)上面的設(shè)計(jì)與實(shí)現(xiàn)分析，下面給出一個(gè)應(yīng)用實(shí)例來說明怎樣應(yīng)用本文中的方法實(shí)現(xiàn)SMDWE的可自管理性和可靠性，應(yīng)用JMX的時(shí)間通知模型實(shí)現(xiàn)分布式引擎的異步性。
1）執(zhí)行引擎的自動(dòng)擴(kuò)展：執(zhí)行引擎的動(dòng)態(tài)擴(kuò)展是通過分別調(diào)用主控引擎的分布式引擎管理器的注冊
方法addObserver（）和注銷方法deleteObserver（）實(shí)現(xiàn)的。其清單如下DistributeEngineManagerBean.java：
public void addObserver(String excuteEngineURL,String observerJNDIName,String homeInterfaceName) throws WorkflowException {
//向主控引擎注冊一個(gè)觀察者
observerList.add(excuteEngineURL+":"+observerJNDIName+":"+homeInterfaceName);
}
public void deleteObserver(String excuteEngineURL,String observerJNDIName,String homeInterfaceName) throws WorkflowException{
//刪除一個(gè)指定URL的觀察者
observerList.remove(excuteEngineURL+":"+observerJNDIName+":"+homeInterfaceName);
}
addObserver()和deleteObserver()方法是兩個(gè)遠(yuǎn)程方法，執(zhí)行引擎啟動(dòng)時(shí)由觀察器（ExcuteEngineObserver.java）通過EJB遠(yuǎn)程調(diào)用addObserver（）方法，將自身注冊到主控引擎上。如果執(zhí)行引擎關(guān)閉則調(diào)用deleteObserver()方法注銷自己。當(dāng)系統(tǒng)因?yàn)樾阅茉蛐枰獢U(kuò)展時(shí)，就在網(wǎng)絡(luò)上新部署一個(gè)執(zhí)行引擎并啟動(dòng)，則這個(gè)新部署的引擎通過上面的方法注冊到了主控引擎。這樣系統(tǒng)就具備了高度的可自管理性，執(zhí)行引擎可隨時(shí)關(guān)閉或加入到系統(tǒng)中來。
2）活動(dòng)執(zhí)行失敗時(shí)的失敗轉(zhuǎn)發(fā)：執(zhí)行引擎執(zhí)行活動(dòng)完畢后，不管成功與否都調(diào)用分布式引擎管理器
的addNotification()方法，將執(zhí)行完畢的活動(dòng)傳回主控引擎，并返回一個(gè)是否成功的標(biāo)志。清單如下：
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)執(zhí)行成功則取出其后繼活動(dòng)放入待辦列表中，如果執(zhí)行失敗則放入失敗列表errorList中，此時(shí)主控引擎可將此失敗的活動(dòng)繼續(xù)分配給其它的執(zhí)行引擎繼續(xù)執(zhí)行，因此結(jié)合本文中的其它提高可靠性的方法，到達(dá)了系統(tǒng)的可靠性要求。
6 總結(jié)
目前分布式工作流管理系統(tǒng)正朝著自管理的方向發(fā)展，本文提出了一種基于JMX框架和觀察者模式實(shí)現(xiàn)高效自管理的分布式工作流引擎的設(shè)計(jì)與實(shí)現(xiàn)方法。執(zhí)行引擎可以隨時(shí)加入到自管理的分布式工作流管理系統(tǒng)中，加入時(shí)只需在網(wǎng)絡(luò)上新部署一個(gè)工作流引擎即可，真正地實(shí)現(xiàn)了分布式工作流引擎的自管理和自擴(kuò)展，每當(dāng)新增一個(gè)執(zhí)行引擎時(shí)，系統(tǒng)便自動(dòng)擴(kuò)展，同時(shí)具有了更好的處理能力。
參考文獻(xiàn)
[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ù)基礎(chǔ)[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
