分布式任務域工作流系統(tǒng)的設計和實現(xiàn)

申請免費試用、咨詢電話：400-8352-114

在工作流技術的研究中，分布式工作流系統(tǒng)成為研究的熱點。一些分布式工作流系統(tǒng)如通過基于持久消息隊列的Exotica，基于可移動代理的DartFlow等，已經(jīng)在一定程度上解決集中式工作流系統(tǒng)的性能瓶頸，單節(jié)點失敗和擴展性等問題，為工作流系統(tǒng)在企業(yè)的實施提供了基礎。

但是從企業(yè)的需求來看，這些系統(tǒng)在實用性上仍然存在一些問題：完全分布的結構增加了系統(tǒng)應用和維護的復雜性；將流程分散定義造成工作流模型動態(tài)修改時一致性維護的困難；細粒度的流程調(diào)度造成應用過程中流程管理不方便的問題等。從企業(yè)的實際情況看，企業(yè)往往希望工作流系統(tǒng)能夠提供集中的流程管理，動態(tài)分散的任務執(zhí)行，以及支持部門或企業(yè)級別的多工作流協(xié)作執(zhí)行。
　　
基于這些問題的考慮，本文從工作流應用的實際要求出發(fā)，提出了多任務域結構的工作流系統(tǒng)實現(xiàn)方案。該系統(tǒng)通過把企業(yè)劃分成不同的功能領域，將任務動態(tài)分配到相應的領域執(zhí)行。這樣以任務的方式對工作流進行調(diào)度，和企業(yè)業(yè)務的人工調(diào)度過程非常一致，方便的實現(xiàn)企業(yè)環(huán)境中的流程任務的分布執(zhí)行。

企業(yè)功能領域

在工作流的應用過程中，需要首先根據(jù)企業(yè)的特點，利用通用功能視圖模型的基本構件生成對企業(yè)需求分析階段的功能模型。而工作流在企業(yè)中的應用可以看作一個三維模型，它們分別是流程邏輯，組織結構模型和應用資源模型。其中，組織模型和資源模型分別代表了企業(yè)的人力資源和物資資源，兩者結合形成若干相互正交的企業(yè)領域。每個領域都有其目標、功能和領域過程，并擁有實現(xiàn)領域目標的相應的資源。領域的劃分和確定受到企業(yè)經(jīng)營目標和限制條件集合（如企業(yè)資源分配狀況）決定，通常表現(xiàn)在企業(yè)當中就是企業(yè)中不同職責的部門機構。不同的領域之間通過流程進行協(xié)作，這也正是工作流在企業(yè)應用的基本思想：流程邏輯表示企業(yè)的核心商業(yè)規(guī)則，是企業(yè)面向客戶的總體任務目標。它跨越職能與組織邊界,對企業(yè)的各個部門領域進行的協(xié)作，集成分散在企業(yè)部門的各種資源，實現(xiàn)企業(yè)最終的目標。

根據(jù)流程和企業(yè)領域的交互特性，我們將工作流管理系統(tǒng)中的核心組件與企業(yè)的建模過程有機結合，使運行系統(tǒng)能夠與企業(yè)模型緊密集成。從流程的角度看，我們將這些企業(yè)不同的工作域稱為任務域。在建立工作流過程模型的時候，針對最基本的活動單元，將它們與適當?shù)娜蝿沼蛳嚓P聯(lián)。而流程運行時，它的調(diào)度被分為兩個層次，面向企業(yè)業(yè)務的流程層和面向組織功能的任務層。流程實現(xiàn)對企業(yè)的資源集成，而任務則是綁定在不同領域的過程活動的實例，任務在運行時根據(jù)屬性和需要被分配到不同的任務域上，由任務域上的處理單元完成任務的處理工作。這樣，將企業(yè)的任務執(zhí)行分配到相應的領域，體現(xiàn)了企業(yè)部門的職責和劃分邊界，實現(xiàn)了了工作流的分布執(zhí)行能力。

多任務域結構的工作流系統(tǒng)

按照WFMC提出的工作流參考模型，一個工作流系統(tǒng)包括過程定義工具、工作流引擎、工作流管理工具、客戶應用和工作流應用等功能模塊。在該參考模型的基礎上，我們提出了面向企業(yè)的多任務域結構的分布式工作流系統(tǒng)，系統(tǒng)主要由開發(fā)管理平臺，一個中央流程服務器和多個任務服務器組成。

從流程服務器和任務服務器的關系來看，流程服務器和多個任務服務器構成了星型拓撲結構模型（如圖2所示），流程服務器位于中心，他們?yōu)榱鞒虒用娴恼{(diào)度提供了支持，任務服務器則分散在企業(yè)的各個部門，它們作為任務調(diào)度的處理單元，為任務層次的處理和調(diào)度提供了的支持。流程服務器采用消息隊列和任務服務器進行通信，它監(jiān)控每個任務服務器，并對它們進行管理；任務服務器則向流程服務器報告自己的狀態(tài)，協(xié)助完成流程的執(zhí)行。從功能上看，流程服務器和任務服務器實現(xiàn)了工作流運行時服務。其中流程服務器負責創(chuàng)建和激活流程實例、對流程進行動態(tài)調(diào)整，維護任務服務器的狀態(tài)信息，以及根據(jù)活動規(guī)則分配任務到不同的任務服務器上執(zhí)行等等。而任務服務器則實現(xiàn)了任務分布處理，它負責任務實例(Task)的生成，應用資源的調(diào)用和工作項（WorkItem）的管理。

開發(fā)管理平臺使用可視化的開發(fā)工具創(chuàng)建工作流的流程模型、組織模型和資源模型。模型的信息保存在中央數(shù)據(jù)庫中，為工作流的分布運行提供共享的庫環(huán)境。并且，在工作流流程投入運行后，由開發(fā)管理平臺的流程監(jiān)控工具來跟蹤流程運行和對流程進行實時監(jiān)測。

在建模的過程中，首先利用開發(fā)管理平臺建立企業(yè)的功能模型，包括企業(yè)的組織模型和應用資源模型。與其它的工作流系統(tǒng)不同的是，我們在建立企業(yè)的功能模型時，要為企業(yè)資源建立任務域信息。通常，任務域按照地理位置或組織結構來劃分，如圖2中，按照企業(yè)的部門將它劃分成不同的任務域，每個任務域擁有任務執(zhí)行過程中需要的相關資源，并且配置一個任務服務器來支持任務項的執(zhí)行和資源的處理工作。不同的任務服務器使用ID進行標識，這些ID在企業(yè)內(nèi)是全局唯一的。對于任務域內(nèi)的應用資源，將它們和某個任務服務器ID進行關聯(lián)，表明資源屬于該任務服務器所對應的任務域。任務服務器擁有對任務域內(nèi)的資源的訪問控制權限。

該資源可以存放任務服務器上，也可能是該任務域內(nèi)的任務服務器可以訪問的其他的設備上，在流程運行時，任務服務器可以使用這些資源完成任務操作。同樣，對于企業(yè)部門的不同角色，他們也通過使用ID與任務服務器相關聯(lián)，劃分企業(yè)的任務域角色集合，幫助實現(xiàn)人工活動的分派工作，以及部門的角色相關權限控制。

在建立好企業(yè)的功能模型后，需要將流程活動映射到任務域上。對于每個活動，它都有任務實例化規(guī)則，規(guī)則描述了流程活動綁定的應用資源和角色信息。值得注意的是，流程活動并不直接綁定到任務域上，它只和邏輯資源名和角色名關聯(lián)，至于資源和角色的任務域信息，在流程運行時，由流程服務器對關聯(lián)規(guī)則解析得到，由此確定相關的任務域，動態(tài)分配任務到不同的任務服務器上執(zhí)行。

有了上面的這些準備，流程就可以開始投入運行了。假設，使用流程開發(fā)工具建立流程P，它包括三個串行活動X，Y，Z。企業(yè)中有三個任務服務器，用來支持流程的運行。在流程運行前，管理員將流程P部署到任務服務器A上，分配啟動權限給用戶。這樣，擁有該權限的用戶可以啟動該流程的執(zhí)行了。圖3給出了流程運行的主要步驟和操作：

1) 首先，任務服務器A，B，C在流程服務器S啟動后，發(fā)送注冊消息給流程服務器，建立系統(tǒng)的結構信息；
2) 由于流程P部署在任務服務器A上，用戶通過任務服務器A的Web客戶端啟動流程，任務服務器則通過消息隊列向流程服務器S發(fā)送流程啟動消息；
3) 流程服務器獲得開始活動，并得到活動的實例化規(guī)則。由于該活動是自動型的活動，根據(jù)活動實例化規(guī)則得到活動綁定的資源在任務域的分配信息，確定任務服務器A為活動執(zhí)行者,流程服務器將活動的啟動消息和上下文數(shù)據(jù)傳遞給任務服務器A；
4) 任務服務器A根據(jù)接收的數(shù)據(jù)，獲取資源內(nèi)容，進行服務激活調(diào)用,并在完成服務激活后向流程服務器發(fā)送任務完成信息；
5) 流程服務器取到后繼活動Y，由于Y是人工型活動，根據(jù)Y綁定的角色所在的域信息，S向任務服務器B發(fā)送活動Y的上下文信息；
6) 由于工作項分配采取用戶主動PULL方式，B生成WORKITEM項，并插入相應的角色的WORKLIST隊列，等待該角色的用戶進行處理；
7) 用戶通過任務服務器的Web客戶端訪問自己的工作項，提交工作項數(shù)據(jù)，并通知流程服務器完成任務項的執(zhí)行；
8) 類似的，流程服務器得到第三個活動的信息，由于該活動的資源是全局共享資源， S將根據(jù)任務服務器管理信息選擇負荷最小的任務服務器C，由C完成服務激活；
9) 流程完成后，流程服務器進行統(tǒng)計分析工作，收集流程執(zhí)行數(shù)據(jù)，供管理分析工具使用。

與[2，3]不同的是，它們實現(xiàn)了流程的全分布運行。但是，它們是通過將流程進行切片，分布到不同的執(zhí)行機上，在運行時，執(zhí)行機從本地直接得到活動副本并執(zhí)行，實現(xiàn)了一種全分布的體系結構。然而，這種結構的系統(tǒng)在流程重組和動態(tài)修改時容易引起流程的不一致，造成修改上的不便。并且，流程的切片和分布發(fā)生在流程運行前，使得流程與系統(tǒng)結構關系過于緊密。而在我們的系統(tǒng)中，通過對流程進行集中的控制，方便了流程相關的管理；流程活動通過規(guī)則的資源屬性關聯(lián)到不同的任務域上，在運行時通過對規(guī)則解析動態(tài)分配任務執(zhí)行，實現(xiàn)流程執(zhí)行的動態(tài)性；而且根據(jù)企業(yè)的人員和資源分配情況，就近獲取資源，利用角色部門劃分方便對任務的控制，提高了流程的執(zhí)行效率。

基于J2EE工作流系統(tǒng)的實現(xiàn)

在實際應用中，工作流系統(tǒng)往往在不同的硬件平臺、操作系統(tǒng)、網(wǎng)絡協(xié)議和數(shù)據(jù)庫的異構環(huán)境下運行，這對系統(tǒng)的不同模塊的通訊和協(xié)作提出了很高的要求。而J2EE平臺為分布式應用提供一整套的企業(yè)服務，包括事務處理、數(shù)據(jù)庫訪問、消息收發(fā)等。使它成為企業(yè)級別分布式軟件開發(fā)領域的重要技術，為系統(tǒng)的實現(xiàn)提供了強大的軟件平臺。

消息隊列為用戶提供基于消息傳遞方式的工作流系統(tǒng)通信平臺。在[2]中實現(xiàn)了基于持久消息隊列的全分布式工作流系統(tǒng)。通過使用消息隊列可以將消息分布到不同的節(jié)點處理，并且隊列的事務特性保證消息處理的可靠性，同時消息隊列的異步調(diào)用方式實現(xiàn)了系統(tǒng)單元之間的松散耦合。

在系統(tǒng)中，流程服務器和任務服務器的通訊采用消息隊列方式。并采用JMS(Java Message Service)服務實現(xiàn)消息傳遞功能。JMS定義了在Java環(huán)境中訪問消息中間件的接口，并且J2EE平臺提供了消息驅(qū)動bean(MDB)進一步方便了對異步消息的處理。流程服務器和任務服務器的通信采取JMS的Peer to Peer的方式，每個任務服務器都有一個消息接收隊列和一個消息發(fā)送隊列，流程將消息發(fā)送到目標隊列后可以繼續(xù)執(zhí)行其它的工作，任務服務器通過MDB完成消息的獲取和解析工作，這樣降低兩者的耦合程度，有利于提高系統(tǒng)的擴展性。并且消息隊列實現(xiàn)流程之間的并行處理和流程內(nèi)部的并發(fā)活動處理，成為平緩工作流系統(tǒng)負載的一個有效途徑。

工作流數(shù)據(jù)在系統(tǒng)中是集中、持久存儲的，這種存儲方式使得數(shù)據(jù)的一致性得以保證，并且為數(shù)據(jù)的管理和維護帶來了極大的方便。同時，現(xiàn)在的數(shù)據(jù)庫技術非常成熟，使得當數(shù)據(jù)庫服務器發(fā)生異常時，能夠通過日志進行錯誤的恢復，使系統(tǒng)具有很好的可靠性。

同時，為了避免數(shù)據(jù)的集中存儲帶來的負面影響，如數(shù)據(jù)服務器的處理效率和網(wǎng)絡帶寬可能成為系統(tǒng)瓶頸，我們?yōu)閿?shù)據(jù)訪問提供了統(tǒng)一訪問接口(DateBase Access Interface)，通過將數(shù)據(jù)庫訪問服務構建在J2EE平臺上，由應用服務器提供數(shù)據(jù)并發(fā)訪問控制和事務的支持。應用服務器通過配置方式來建立數(shù)據(jù)庫訪問環(huán)境，并通過容器來管理數(shù)據(jù)庫的連接，支持系統(tǒng)對數(shù)據(jù)庫頻繁的訪問。同時，我們在數(shù)據(jù)訪問層提供數(shù)據(jù)的存儲過程訪問和數(shù)據(jù)的緩存方法，減少網(wǎng)絡流量，提高數(shù)據(jù)處理效率，降低了數(shù)據(jù)庫服務器成為系統(tǒng)瓶頸的可能。

集成性是增強工作流系統(tǒng)的可擴展性的一個重要的方面。而Webservice的出現(xiàn)為應用的集成提供了一個統(tǒng)一的解決方案。J2EE作為主流的Webservice開發(fā)平臺之一，實現(xiàn)了開放的Webservice服務的開發(fā)。在企業(yè)中的應用資源往往形式多種多樣。我們都通過任務服務器的服務調(diào)用適配器對應用進行統(tǒng)一的調(diào)用。應用都使用Webservice方式包裝發(fā)布，例如在J2EE平臺上應用一般使用EJB (Enterprise JavaBeanTM) 實現(xiàn)。應用以EJB的方式實現(xiàn)之后，僅需為其編寫描述文件，部署到應用服務器上，并將描述文件發(fā)布到UDDI注冊中心，其他的應用就可以找到這個應用的描述文件，并按照描述文件描述的訪問方式（如SOAP協(xié)議）和接口調(diào)用這個服務。對于企業(yè)現(xiàn)存系統(tǒng)、遺留系統(tǒng)和erp系統(tǒng)等，可以使用Web服務適配器將它們集成到Web服務模型中。Web服務適配器一般是一個包裝成Web服務的Java應用程序，它用J2EE連接器使得遺留應用能被小服務程序（Servlet）和JSP訪問，或者被遠程系統(tǒng)通過SOAP訪問。

通過Web servcie方式，不僅可以將企業(yè)中各種類型的應用進行包裝，作為工作流可調(diào)用的應用(Workflow Based Application)；還可以將整個流程包裝成Web service方式，將流程作為服務的實現(xiàn)者，作為領域的資源提供給外界使用。這樣，實現(xiàn)了企業(yè)中分散的資源的集成功能。

基于Web的工作流系統(tǒng)已經(jīng)成為一種趨勢，許多供應商紛紛開發(fā)新產(chǎn)品或者在原有的產(chǎn)品的基礎上增加對Web的支持[4]。使用Web方式實現(xiàn)工作流的客戶端應用，用戶可以方便的獲取自己的任務列表和工作項，能夠完成任務項的管理功能和任務的執(zhí)行功能，大大提高工作流系統(tǒng)的實用性。在我們系統(tǒng)中，通過任務服務器提供了對Web方式的任務控制的支持。任務服務器在后臺使用EJB實現(xiàn)任務處理邏輯，通過Servlet實現(xiàn)用戶的交互控制。一方面，通過Web客戶端JSP程序與客戶進行交互，完成對流程的部署，啟動和任務隊列的管理等功能；另外一方面，使用預定義的HTML頁面，JSP程序等，實現(xiàn)和客戶的交互過程，完成流程運行時的數(shù)據(jù)獲取等功能，協(xié)助流程的人工活動執(zhí)行。

來源：CCW