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