基于OA系統(tǒng)的工作流引擎設(shè)計與實現(xiàn).doc

XX大學(xué)本科學(xué)生畢業(yè)設(shè)計 基于OA系統(tǒng)的工作流引擎設(shè)計與實現(xiàn)學(xué) 生： 學(xué) 號：指導(dǎo)教師：專 業(yè)：計算機科學(xué)與技術(shù)XX大學(xué)計算機學(xué)院二OO八年六月摘 要工作流管理系統(tǒng)是一個軟件系統(tǒng)，它用于工作流的定義和管理，并按照在計算機中制定好的工作邏輯推進工作流實例的執(zhí)行，實現(xiàn)自動傳遞文檔、信息或者任務(wù)。工作流引擎在工作流管理系統(tǒng)中處于核心地位，是系統(tǒng)的任務(wù)調(diào)度器和資源分配器。它可以創(chuàng)建新的流程、基于過程模型生成工作項、支持活動的執(zhí)行、分配資源以及記錄工作流的相關(guān)信息。目前，工作流技術(shù)在辦公自動化（Office Automation, OA）系統(tǒng)中的應(yīng)用月來越廣泛，對OA系統(tǒng)中的工作流引擎進行探索具有重要的應(yīng)用價值。 本文結(jié)合一般的辦公室辦公自動化的需求，從軟件生存周期的角度，使用面向?qū)ο蟮脑O(shè)計方法，給出了一個結(jié)構(gòu)清晰、配置簡單的工作流引擎設(shè)計方案。重點介紹來了引擎的設(shè)計與實現(xiàn)。該引擎借鑒了已有的工作流引擎的設(shè)計，在保證實用性的基礎(chǔ)上，在權(quán)限和流程管理方面進行了針對性的取舍。最后給出了重要功能的部分代碼，并進行了詳細(xì)的描述。經(jīng)過測試應(yīng)用，該引擎可以支持靈活的流程定制，配置部署簡單，達到了預(yù)定目標(biāo)。關(guān)鍵詞：JSP, Spring, Hibernate, Ajax , JavaScriptABSTRACTWorkflow Management System is a software system. It is mainly used for the definition and management of workflow. It makes the workflow instance executes fluently with some scheduled rules to achieve the goal that pass documents, information or tasks automanticlly. Workflow engine is the kernel of a workflow management system. It is a distributor of tasks and resources, which can create new processes, create work items based on process models, support executions of activities, and allocate resources and record information of the workflow. Nowadays, as there are more and more workflow applications in office automation, it is very important to do research in workflow fields. From the perspective of the software life cycle，this paper proposes a well-structed, easy-to-deploy workflow engine solution with the general demands for office automation, which was designed in an Object-oriented way. The designment and implementation will be focused on. This engine has referenced other engines and has done some choices on the basis of normal function. At last, an implementation is showed with detailed description of some important part.After testing, this engine is easy-to-use and meets the requirements.Keywords: JSP, Spring, Hibernate, Ajax , JavaScript目錄摘 要IABSTRACT21引言51.1課題的背景與目標(biāo)51.2課題研究內(nèi)容及文本組織62相關(guān)技術(shù)及原理72.1工作流技術(shù)72.1.1工作流引擎核心功能72.1.2兩種現(xiàn)有工作流引擎82.2Spring框架102.2.1Spring 聲明式事務(wù)管理112.2.2Spring Web MVC143工作流引擎需求分析173.1相關(guān)概念介紹173.2總體需求173.2.1基于業(yè)務(wù)的需求分析173.2.2需求描述183.3任務(wù)實時通知183.4多種業(yè)務(wù)流程的文件存儲問題193.5文件權(quán)限問題193.6業(yè)務(wù)流程的基本模式193.7用例闡述203.7.1啟動流程203.7.2 掛起流程203.7.3 激活流程213.7.4 終止流程213.7.4 接收任務(wù)213.7.5 打開工作項223.7.6 保存文件223.7.7 發(fā)送文件223.7.8 掛起工作項223.7.9 恢復(fù)工作項233.7.10 駁回文件233.7.11 跟蹤流程狀態(tài)234設(shè)計254.1時序圖254.1.1執(zhí)行工作項254.1.2提交任務(wù)264.1.3實例化流程274.2數(shù)據(jù)庫設(shè)計284.3流程路由機制334.4流程的控制模型344.4.1流程實例導(dǎo)航344.4.2工作項管理344.4.3業(yè)務(wù)文件管理344.4.4文件權(quán)限管理354.4.5任務(wù)實時通知354.5引擎類365系統(tǒng)實現(xiàn)395.1OAworkflow總體框架395.2重點功能實現(xiàn)395.2.1實例化流程的遍歷算法395.2.2巧用Spring SimpleFormController獲取表單405.2.3JSTL Core taglib和Spring bind處理表單顯示415.2.4流程導(dǎo)航核心426總結(jié)447致謝451 引言1.1 課題的背景與目標(biāo)工作流的概念起源于生產(chǎn)和辦公自動化領(lǐng)域，是針對日常工作中具有固定流程的業(yè)務(wù)活動提出的一個概念。工作流管理聯(lián)盟(WFMC)給出的工作流定義是：工作流是一類能夠完全或者部分自動執(zhí)行的經(jīng)營過程，它根據(jù)一系列過程規(guī)則、文檔、信息或任務(wù)能夠在不同的執(zhí)行者之間進行傳遞與執(zhí)行。該技術(shù)的目的是通過將工作分解成定義良好的任務(wù)、角色，按照一定的規(guī)則和過程來執(zhí)行這些任務(wù)并對它們進行監(jiān)控，達到提高工作效率、降低生產(chǎn)成本、提高企業(yè)生產(chǎn)經(jīng)營管理水平和企業(yè)競爭力的目標(biāo)。工作流管理系統(tǒng)的核心部分是工作流引擎，引擎是驅(qū)動流程流動的主要部件，它負(fù)責(zé)解釋工作流流程定義，創(chuàng)建并初始化流程實例，控制流程流動的路徑，記錄流程運行狀態(tài)，掛起或喚醒流程，終止正在運行的流程，與其他引擎之間通訊等等工作。目前，工作流技術(shù)還處于發(fā)展曲線的初級階段，然而，關(guān)于這方面的研究十分活躍，形成了許多規(guī)范標(biāo)準(zhǔn)。例如主要的有：工作流管理聯(lián)盟（Workflow Management Coalition ，WfMC）在體系結(jié)構(gòu)6、工作流相關(guān)術(shù)語7及應(yīng)用程序接口8、管理控制接口9、過程語言描述10等方面提出的一系列規(guī)范。還有Microsoft, BEA, IBM, SAP等公司聯(lián)合提交發(fā)布的BPEL規(guī)范等等。在實際應(yīng)用中開源產(chǎn)品占據(jù)了重要的地位，如JBoss 項目中的jBPM、由OpenSymphony組織開發(fā)的OSWorkflow、Enhydra組織開發(fā)的Shark。在國內(nèi)，上海交通大學(xué)的基于Petri網(wǎng)點分布是工作流管理的研究，浙江大學(xué)的基于工作流過程定義語言（WPDL）的工作流建模平臺，都取得了良好的研究成果。但是工作流管理技術(shù)很多方面還不成熟，在使用過程中往往會遇到的一個重要問題是系統(tǒng)過于龐大復(fù)雜：一些工作流軟件產(chǎn)品，特別是國外成熟的產(chǎn)品，經(jīng)過多年的發(fā)展，功能強大，配置和接口多樣靈活。對于國內(nèi)大部分初次使用工作流技術(shù)的中小型項目來說，這些工作流軟件的功能特性大大超過了需要，客戶需要承受漫長的學(xué)習(xí)周期、復(fù)雜的安裝配置等帶來的風(fēng)險。鑒于上述的原因，本課題的目標(biāo)在于提出一個配置簡單、使用方便、功能實用的工作流引擎的設(shè)計方案，并完成編碼。該工作流引擎OAworkflow是借鑒了已有的工作流引擎，對某些復(fù)雜功能進行簡化后，重新設(shè)計的。與傳統(tǒng)工作流管理系統(tǒng)相比，本工作流管理系統(tǒng)具有以下優(yōu)點：1) 支持靈活的流程定制該系統(tǒng)能夠針對辦公自動化系統(tǒng)中的典型流程案例對流程進行靈活定制，支持的流程路由包括：順序路由、匯聚路由和分支路由。用戶可以根據(jù)具體的業(yè)務(wù)流程，使用客戶端建模工具定制合適的模型。2) 功能詳細(xì)實用例如該系統(tǒng)支持流程分支跳轉(zhuǎn)的時候，允許用戶手動指定流程的直接后續(xù)步驟；當(dāng)審批不合格時，文檔回退的功能等。3) 文件權(quán)限設(shè)置精確該系統(tǒng)的每個業(yè)務(wù)流程綁定一個公文，處于流程中的各個活動對公文的讀寫權(quán)限看精確到字段。4) 支持可視化建模5) 結(jié)構(gòu)清晰，配置簡單1.2 課題研究內(nèi)容及文本組織本課題的重點研究內(nèi)容有：1) 模型定義。本文分析了辦公自動化項目的功能需求，然后針對項目對流程控制的靈活需求，采用了一種結(jié)構(gòu)清晰、功能完整的過程定義格式，使引擎在支持流程分支跳轉(zhuǎn)的時候，還允許用戶手動指定流程的直接后續(xù)步驟，在借鑒了現(xiàn)有工作流引擎設(shè)計思想的基礎(chǔ)上，給出了一個工作流引擎的設(shè)計方案。2) 工作流引擎的實現(xiàn)。本文分別從流程實例化、流程實例管理、流程導(dǎo)航和維護相關(guān)數(shù)據(jù)等模塊詳細(xì)描述了實現(xiàn)方案，其中關(guān)于系統(tǒng)的關(guān)鍵功能部分給出了具體API語義分析。3) 技術(shù)架構(gòu)。本項目采用了Spring + Hibernate 這種流行的Web應(yīng)用程序設(shè)計框架組合。從而使得該引擎具有架構(gòu)清晰開放的特點，系統(tǒng)有著清晰的分層結(jié)構(gòu)。本文由以下六章和參考文獻組成：第一章 引言，介紹了本課題的背景和意義。第二章 相關(guān)技術(shù)及原理，介紹了Spring 開發(fā)框架、Hibernate 數(shù)據(jù)庫持久層技術(shù)、Ajax 技術(shù)、JavaScript、JSTL第三章 需求分析，給出了用例闡述及用例圖第四章 系統(tǒng)設(shè)計，包括數(shù)據(jù)庫設(shè)計、時序圖等第五章 實現(xiàn)，重點從流程實例化、流程實例管理、流程導(dǎo)航和維護相關(guān)數(shù)據(jù)等模塊描述了實現(xiàn)方案及一些關(guān)鍵API 的分析第六章 總結(jié)2 相關(guān)技術(shù)及原理2.1 工作流技術(shù)工作流的概念起源于生產(chǎn)組織和辦公自動化領(lǐng)域，它是針對日常工作中具有固定程序的活動而提出的一個概念。目的是通過將工作分解成定義良好的任務(wù)、角色，按照一定的規(guī)則和過程來執(zhí)行這些任務(wù)并對它們進行監(jiān)控，達到提高工作效率、降低生產(chǎn)成本、提高企業(yè)生產(chǎn)經(jīng)營管理水平和企業(yè)競爭力的目標(biāo)。2.1.1 工作流引擎核心功能工作流引擎降低了工作流系統(tǒng)應(yīng)用模塊與業(yè)務(wù)流程之間的禍合度，當(dāng)業(yè)務(wù)流程發(fā)生變化時，只需修改流程定義，具體的應(yīng)用程序保持不變，工作流引擎對于用戶來說是透明的。目前，工作流引擎的應(yīng)用可以分為三種方式: 作為一個完整的系統(tǒng)提供給最終用戶，能單獨運行，如IBM的Lotus Domino/Notes系統(tǒng)。 僅僅作為企業(yè)應(yīng)用集成(Enterprise Application Integration EAI)平臺。EAI將進程、軟件、標(biāo)準(zhǔn)和硬件聯(lián)合起來，在兩個或更多的企業(yè)系統(tǒng)之間實現(xiàn)無縫集成，使它們就像一個整體一樣，如B2B形式的電子商務(wù)。 嵌入到企業(yè)應(yīng)用中，只提供工作流引擎服務(wù)，開源領(lǐng)域的OS Workflow引擎即屬于這種情況。從圖2.1.1中可以看出，用戶可以通過系統(tǒng)提供的客戶端(如建模工具、任務(wù)列表等)與工作流引擎進行交互。從應(yīng)用上來說，一個工作流引擎必須具有的核心功能包括：(1)流程實例化及執(zhí)行過程模型:解釋企業(yè)經(jīng)營過程的流程定義，根據(jù)過程執(zhí)行需要的初始條件和執(zhí)行參數(shù)生成過程實例，運行過程實例并管理其運行過程。一個過程模型實際是企業(yè)經(jīng)營過程的一個模板，它可以被執(zhí)行多次，也可以有多個有關(guān)這個過程模型的實例在同時運行。(2)為過程和活動的執(zhí)行進行導(dǎo)航:包括啟動和終止實例，根據(jù)活動定義中的條件決定后續(xù)活動的執(zhí)行順序。(3)與外部資源交互完成業(yè)務(wù)活動:分為用戶應(yīng)用接口和直接調(diào)用應(yīng)用接口兩種情況。用戶應(yīng)用接口是指首先通過任務(wù)列表管理器向用戶提供任務(wù)列表，供用戶選擇相應(yīng)的任務(wù)(必要的時候可以調(diào)用相應(yīng)的工具來完成)，任務(wù)完成后由用 戶修改任務(wù)項的狀態(tài)。直接調(diào)用應(yīng)用接口是指由工作流引擎直接調(diào)用相應(yīng)的應(yīng) 用程序，應(yīng)用將執(zhí)行情況反饋給工作流引擎，如一份流轉(zhuǎn)過程中的學(xué)校公文經(jīng) 過校領(lǐng)導(dǎo)會簽以后，系統(tǒng)進行歸檔并自動發(fā)往各相關(guān)職能部門。(4)維護工作流相關(guān)數(shù)據(jù):工作流在執(zhí)行過程中要維護不同過程和活動實例的內(nèi)部狀態(tài)信息，以及用于協(xié)調(diào)和恢復(fù)的各種檢查數(shù)據(jù)和恢復(fù)/重起信息，向用戶傳遞必要的相關(guān)信息。圖2.1.1工作流引擎應(yīng)用層次圖2.1.2 兩種現(xiàn)有工作流引擎目前，OpenSymphony組織開發(fā)的OS Workflow,和Moss項目中集成的jBPM是應(yīng)用比較廣泛的工作流產(chǎn)品，本節(jié)將對這三種引擎的設(shè)計方案和實現(xiàn)機制進行分析介紹。1. jBPMjBPM結(jié)合了工作流應(yīng)用開發(fā)的便利性和企業(yè)應(yīng)用集成能力，其業(yè)務(wù)流程是通過本身提供的流程定義語言jPDL (jBPM Process Definition Language)進行配置，但由于沒有提供規(guī)范接口，從而不易于與其它工作流引擎進行交互。由于JBPM持久層采用Hibernate技術(shù)來實現(xiàn)，因此具有一定的可擴展性。jBPM中結(jié)合了狀態(tài)圖、活動圖和PetriNet的知識，它采用了Token的概念，用來表示任務(wù)分配給某一個Acto嘆執(zhí)行者，可以是人或應(yīng)用系統(tǒng))的依據(jù)，即只有當(dāng)某個執(zhí)行者獲得了一個Token，才有可能去執(zhí)行任務(wù)，因此，jBPM的流程推進機制實際上表現(xiàn)為Token的轉(zhuǎn)移。引擎在一個流程實例開始的時候產(chǎn)生一個Root-Token，而這個Token對象會隨著流程實例運行而轉(zhuǎn)移，從而來表示任務(wù)的依序執(zhí)行。在此過程中，如果將一項任務(wù)分配給某個執(zhí)行者，該執(zhí)行者就會獲得一個Token對象標(biāo)識。2. OSWorkflowOSWorkflow基于有限狀態(tài)機(Finite State Machine, FSM)的概念，它的每個State是通過StepID和Status聯(lián)合表示，而State的轉(zhuǎn)換是由動作驅(qū)動的。在工作流生命期內(nèi)有至少一個或多個活動的State.OSWorkflow本身自帶了一個可選的用戶組織模型，該模型只提供了用戶和用戶組的存儲，沒有涉及用戶的角色概念，在系統(tǒng)訪問控制和授權(quán)方面不夠完善，因此使用時通常選擇配置使用自己實現(xiàn)的用戶組織模型。OSWorkflow具有一定的靈活性，在流程建模方面不僅支持BeanShell腳本，還支持Java, BSF和EJB等，并且可以采用JDBC, Hibernate, EJB等多種數(shù)據(jù)持久化方式。1 流程建模OS Workflow采用自己的流程定義格式，其流程定義遵守的規(guī)則包括:一個工作流定義由多個步驟(Step)組成，其中每一個步驟由一個或多個動作(Action)組成，一個動作可以由用戶觸發(fā)執(zhí)行，也可能自動運行.每個動作至少有一個Unconditional Results和零個或多個Conditional Results，如果指定了多個Conditional Results，那么第一個符合條件的將會被執(zhí)行，如果沒有符合條件的Conditional Result，那么Unconditional Result將會被執(zhí)行。一個步驟的后續(xù)步驟有可能是其本身、一個新的步驟、一個分支結(jié)構(gòu)(Split)或者一個匯合(Join)結(jié)構(gòu)，當(dāng)然，這些情況下工作流自身的狀態(tài)也有可能發(fā)生改變。如果結(jié)果是一個分支結(jié)構(gòu)，在流程定義時需要設(shè)置一個“split”屬性，其值表示將要執(zhí)行的分支路徑的標(biāo)識。相應(yīng)地，一個分支結(jié)構(gòu)也具有一個或多個Unconditional Results. Unconditional Results的值指向分支結(jié)構(gòu)的各個不同分支。OSWorkflow流程定義文件開始部分包括的initial-actions標(biāo)簽里面定義的是流程的初始化動作，每個步驟(就叩)里面包含一個或多個動作(action);在每個動作里面可以手動設(shè)置pre-functions和post-functions，表示在該action執(zhí)行之前或之后要執(zhí)行的動作;results元素則定義了執(zhí)行完該動作后的結(jié)果流向。2 流程推進機制OS Workflow的流程推進機制與通常所說的流程不同，其驅(qū)動是通過動作 (Action)的執(zhí)行來進行的，其實現(xiàn)是分為兩個步驟，一是具體實施動作，另一個是維護流程狀態(tài)變遷。一個動作的執(zhí)行所造成的狀態(tài)改變，可能使流程從一個Step的某個Status變?yōu)榱硪粋€Status，也可能從一個Step的某一個Status變?yōu)榱硪粋€Step的Status。在狀態(tài)變遷的過程中，會執(zhí)行預(yù)先定義的前置和后置函數(shù)。 OSWorkflow不強調(diào)Step的概念，所有的流程推進都是通過Action的切換來表示。所以在OS Workflow的執(zhí)行引擎類中，只有針對Action的遷移，而沒有針對某一步驟( Step)的轉(zhuǎn)換。對于工作流引擎來說，任何一種狀態(tài)改變都意味著是由某個Action引起的變化結(jié)果。如果設(shè)置Action的結(jié)果為Finished，表示該Action在執(zhí)行完以后的結(jié)果狀態(tài)就是Finished。有限狀態(tài)機的基本原則是，一個Finish狀態(tài)的產(chǎn)生意味著流程實例中該動作的結(jié)束。OSWorkflow的流程運轉(zhuǎn)和調(diào)度的核心理念是，在一個工作流程的生命周期中，總會存在至少一個或多個State;一個State到另一個State的轉(zhuǎn)移 (Transition)，依賴于Action的發(fā)生。OS Workflow實現(xiàn)流程導(dǎo)航功能的算法可以描述為： 首先得到流程實例，判斷其狀態(tài)是否處于活動狀態(tài)。根據(jù)流程定義解 析到的結(jié)果和當(dāng)前步驟的id取得當(dāng)前步驟。 判斷當(dāng)前用戶是否有執(zhí)行該活動的權(quán)限，然后將當(dāng)前用戶從當(dāng)前步驟 的用戶列表中刪除，遍歷此列表，若為空表示該步驟已經(jīng)完成，進入 下一步;否則退出。 將當(dāng)前步驟數(shù)據(jù)作為歷史記錄存入數(shù)據(jù)庫。取得下一步信息，并將其 設(shè)置為當(dāng)前步驟。 重復(fù)上述步驟，直至流程完成。OSWorkflow最大的特點就在于其靈活性，它實質(zhì)上只是向用戶提供了一個引擎核心，它的原則是由開發(fā)人員而不是由用戶來設(shè)置和修改系統(tǒng)工作流程的配置。正是于其輕量級特性，所以可以方便的將它集成到應(yīng)用系統(tǒng)中去。2.2 Spring框架Spring 是一個開源框架，是為了解決企業(yè)應(yīng)用程序開發(fā)復(fù)雜性而創(chuàng)建的?？蚣艿闹饕獌?yōu)勢之一就是其分層架構(gòu)，分層架構(gòu)允許您選擇使用哪一個組件，同時為 J2EE 應(yīng)用程序開發(fā)提供集成的框架。它是一個分層架構(gòu)，由 7 個定義良好的模塊組成。Spring 模塊構(gòu)建在核心容器之上，核心容器定義了創(chuàng)建、配置和管理 bean 的方式，如圖 2.2.1 所示。圖2.2.1 Spring框架概述組成 Spring 框架的每個模塊（或組件）都可以單獨存在，或者與其他一個或多個模塊聯(lián)合實現(xiàn)。每個模塊的功能如下： 核心容器：核心容器提供 Spring 框架的基本功能。核心容器的主要組件是 BeanFactory，它是工廠模式的實現(xiàn)。BeanFactory 使用控制反轉(zhuǎn) （IOC） 模式將應(yīng)用程序的配置和依賴性規(guī)范與實際的應(yīng)用程序代碼分開。 Spring 上下文：Spring 上下文是一個配置文件，向 Spring 框架提供上下文信息。Spring 上下文包括企業(yè)服務(wù)，例如 JNDI、EJB、電子郵件、國際化、校驗和調(diào)度功能。 Spring AOP：通過配置管理特性，Spring AOP 模塊直接將面向方面的編程功能集成到了 Spring 框架中。所以，可以很容易地使 Spring 框架管理的任何對象支持 AOP。Spring AOP 模塊為基于 Spring 的應(yīng)用程序中的對象提供了事務(wù)管理服務(wù)。通過使用 Spring AOP，不用依賴 EJB 組件，就可以將聲明性事務(wù)管理集成到應(yīng)用程序中。 Spring DAO：JDBC DAO 抽象層提供了有意義的異常層次結(jié)構(gòu)，可用該結(jié)構(gòu)來管理異常處理和不同數(shù)據(jù)庫供應(yīng)商拋出的錯誤消息。異常層次結(jié)構(gòu)簡化了錯誤處理，并且極大地降低了需要編寫的異常代碼數(shù)量（例如打開和關(guān)閉連接）。Spring DAO 的面向 JDBC 的異常遵從通用的 DAO 異常層次結(jié)構(gòu)。 Spring ORM：Spring 框架插入了若干個 ORM 框架，從而提供了 ORM 的對象關(guān)系工具，其中包括 JDO、Hibernate 和 iBatis SQL Map。所有這些都遵從 Spring 的通用事務(wù)和 DAO 異常層次結(jié)構(gòu)。 Spring Web 模塊：Web 上下文模塊建立在應(yīng)用程序上下文模塊之上，為基于 Web 的應(yīng)用程序提供了上下文。所以，Spring 框架支持與 Jakarta Struts 的集成。Web 模塊還簡化了處理多部分請求以及將請求參數(shù)綁定到域?qū)ο蟮墓ぷ鳌?Spring MVC 框架：MVC 框架是一個全功能的構(gòu)建 Web 應(yīng)用程序的 MVC 實現(xiàn)。通過策略接口，MVC 框架變成為高度可配置的，MVC 容納了大量視圖技術(shù)，其中包括 JSP、Velocity、Tiles、iText 和 POI。Spring 框架的功能可以用在任何 J2EE 服務(wù)器中，大多數(shù)功能也適用于不受管理的環(huán)境。Spring 的核心要點是：支持不綁定到特定 J2EE 服務(wù)的可重用業(yè)務(wù)和數(shù)據(jù)訪問對象。毫無疑問，這樣的對象可以在不同 J2EE 環(huán)境 （Web 或 EJB）、獨立應(yīng)用程序、測試環(huán)境之間重用。2.2.1 Spring 聲明式事務(wù)管理Spring提供的事務(wù)管理可以分為兩類：編程式的和聲明式的。編程式的，比較靈活，但是代碼量大，存在重復(fù)的代碼比較多；聲明式的比編程式的更靈活方便。大多數(shù)Spring用戶選擇聲明式事務(wù)管理。這是對應(yīng)用代碼影響最小的選擇，因此也最符合非侵入式輕量級容器的理念。這一節(jié)將要介紹Spring 提供的聲明式事務(wù)管理。Spring的聲明式事務(wù)管理是通過Spring AOP實現(xiàn)的，其中的事務(wù)通知由元數(shù)據(jù)（目前基于XML或注解）驅(qū)動。代理對象與事務(wù)元數(shù)據(jù)結(jié)合產(chǎn)生了一個AOP代理，它使用一個PlatformTransactionManager實現(xiàn)品配合TransactionInterceptor，在方法調(diào)用前后實施事務(wù)。 概念上來說，在事務(wù)代理上調(diào)用方法的工作過程如圖2.2.2 所示：圖2.2.2 Spring 事務(wù)代理以DataSource，mysql舉例，介紹聲明式的事務(wù)管理的配置與應(yīng)用：onlyfun.caterpillar.IUserDAOPROPAGATION_REQUIREDTransactionProxyFactoryBean需要一個TransactionManager，由于這里使用的是JDBC，所以使用DataSourceTransactionManager，TransactionProxyFactoryBean是個代理對象，target 屬性指定要代理的對象，事務(wù)管理會自動介入指定的方法前后，這里使用 transactionAttributes 屬性指定，insert* 表示指定方法名稱以insert開頭的都要納入事務(wù)管理，您也可以指定方法全名，如果在方法執(zhí)行過程中發(fā)生錯誤，則所有先前的操作自動撤回，否則正常提交。在insert* 等方法上指定了 PROPAGATION_REQUIRED，表示在目前的事務(wù)中執(zhí)行操作，如果事務(wù)不存在就建立一個新的，相關(guān)的常數(shù)意義都可以在API文件的TransactionDefinition接口中找到。您可以加上多個事務(wù)定義，中間使用逗號 , 區(qū)隔，例如可以加上只讀，或者是指定某個異常發(fā)生時撤回操作：PROPAGATION_REQUIRED,readOnly,-MyCheckedExceptionMyCheckedException前面加上 - 時，表示發(fā)生指定異常時撤消操作，如果前面加上 +，表示發(fā)生異常時立即提交。由于userDAO被userDAOProxy代理了，所以要做的是取得userDAOProxy，而不是userDAO，IUserDAOuserDAO=(IUserDAO)context.getBean(userDAOProxy);userDAO.insert(user);申明式事務(wù)管理一般都是粗粒度的，這里可以看到，整個方法都被納入事務(wù)管理，其實在大部分的業(yè)務(wù)處理中，這樣的做法是可以接受的。2.2.2 Spring Web MVCSpring的web框架是圍繞DispatcherServlet來進行設(shè)計的。DispatcherServlet的作用是將請求分發(fā)到不同的處理器。Spring的web框架包括可配置的處理器（handler）映射、視圖（view）解析、本地化（local）解析、主題（theme）解析以及對上傳文件解析。處理器是對Controller接口的實現(xiàn)，該接口僅僅定義了ModelAndView handleRequest(request, response)方法。你可以通過實現(xiàn)這個接口來生成自己的控制器（也可以稱之為處理器），但是從Spring提供的一系列控制器繼承會更省事，比如AbstractController、AbstractCommandController和SimpleFormController。1. DispatcherServlet和其它web框架一樣，Spring的web框架是一個請求驅(qū)動的web框架，其設(shè)計圍繞一個中心的servlet進行，它能將請求分發(fā)給控制器，并提供其它功能幫助web應(yīng)用開發(fā)。然而，Spring的DispatcherServlet所做的不僅僅是這些，它和Spring的IoC容器完全集成在一起，從而允許你使用Spring的其它功能。下圖展示了DispatcherServlet對請求的處理流程：圖2.2.3 Spring Web MVC處理請求的工作流程2. 命令控制器Spring的CommandController是Spring MVC的重要部分。命令控制器提供了一種和數(shù)據(jù)對象交互的方式，并動態(tài)地將來自HttpServletRequest的參數(shù)綁定到你指定的數(shù)據(jù)對象上。它的功能和Struts中的ActionForm有點像，不過在Spring中，你不需要實現(xiàn)任何接口來實現(xiàn)數(shù)據(jù)綁定。首先，讓我們看一下有哪些可以使用的命令控制器： AbstractCommandController 你可以使用該抽象命令控制器來創(chuàng)建自己的命令控制器，它能夠?qū)⒄埱髤?shù)綁定到你指定的命令對象。這個類并不提供任何表單功能，但是它提供驗證功能，并且讓你在子類中去實現(xiàn)如何處理由請求參數(shù)產(chǎn)生的命令對象。 AbstractFormController一個支持表單提交的抽象控制器類。使用這個控制器，你可以定義表單，并使用從控制器獲取的數(shù)據(jù)對象構(gòu)建表單。當(dāng)用戶輸入表單內(nèi)容，AbstractFormController將用戶輸入的內(nèi)容綁定到命令對象，驗證表單內(nèi)容，并將該對象交給控制器，完成相應(yīng)的操作。它支持的功能有防止重復(fù)提交、表單驗證以及一般的表單處理流程。子類需要實現(xiàn)自己的方法來指定采用哪個視圖來顯示輸入表單，哪個視圖顯示表單正確提交后的結(jié)果。如果你需要表單，但不想在應(yīng)用上下文中指定顯示給用戶的視圖，就使用這個控制器。 SimpleFormController 這是一個form cotnroller，當(dāng)需要根據(jù)命令對象來創(chuàng)建相應(yīng)的form的時候，該類可以提供更多的支持。你可以為其指定一個命令對象，顯示表單的視圖名，當(dāng)表單提交成功后顯示給用戶的視圖名等等。 AbstractWizardFormController 這是一個抽象類，繼承這個類需要實現(xiàn)validatePage()、processFinish() 和processCancel() 方法。你有可能也需要寫一個構(gòu)造器，它至少需要調(diào)用setPages()和setCommandName()方法。setPages()的參數(shù)是一個String數(shù)組，這個數(shù)組包含了組成向?qū)У囊晥D名。setCommandName()的參數(shù)是一個String，該參數(shù)將用來在視圖中調(diào)用你的命令對象。和AbstractFormController的實現(xiàn)一樣, 你需要使用命令對象（其實就是一個JavaBean， 這個bean中包含了表單的信息）。你有兩個選擇：在構(gòu)造函數(shù)中調(diào)用setCommandClass()方法（參數(shù)是命令對象的類名），或者實現(xiàn)formBackingObject()方法。AbstractWizardFormController 有幾個你可以復(fù)寫（override）的方法。最有用的一個是referenceData(.)。這個方法允許你把模型數(shù)據(jù)以Map的格式傳遞給視圖；getTargetPage() 允許你動態(tài)地更改向?qū)У捻撁骓樞?，或者直接跳過某些頁面；onBindAndValidate() 允許你復(fù)寫內(nèi)置的綁定和驗證流程。3 工作流引擎需求分析3.1 相關(guān)概念介紹在進行工作流引擎的需求分析之前，先引入幾個將要使用的重要概念。 流程實例，是指工作流系統(tǒng)處理的業(yè)務(wù)流程，每個流程實例的生命期是有限的，并且都有一個唯一標(biāo)識。案例屬性是一系列同案例相關(guān)的變量，能用來管理案例，它們的值可能隨著案例的進展而發(fā)生變化。 活動，是指流程實例下的各個節(jié)點的描述。每個活動具有唯一標(biāo)識，對應(yīng)流程模型中的一個節(jié)點。它的重要屬性有狀態(tài)及狀態(tài)改變時間。它可以對應(yīng)多個工作項，但是在一個時間內(nèi)只能有一個當(dāng)前的工作項，當(dāng)該工作項被執(zhí)行后，活動狀態(tài)發(fā)生相應(yīng)改變。 工作項，是活動的實際執(zhí)行。只要流程實例狀態(tài)允許，工作項就被創(chuàng)建。我們可以把工作項看作是要被執(zhí)行的實際工作塊。 3.2 總體需求3.2.1 基于業(yè)務(wù)的需求分析該工作流管理系統(tǒng)用戶分為流程設(shè)計員和普通用戶兩種。流程設(shè)計人員主要操作包括：建立流程模型、設(shè)置流程相關(guān)屬性、設(shè)置用戶權(quán)限、刪除流程模型、修改模型、保存模型、添加用戶、刪除用戶。流程設(shè)計人員的功能大多屬于建模部分，不是本課題的范圍，在此不作分析。普通用戶功能基本覆蓋了一個標(biāo)準(zhǔn)工作流引擎的核心功能，將是重點本文的重點闡述部分。普通用戶的操作包括：啟動流程實例、掛起流程實例、激活流程實例、接收任務(wù)、打開工作相、查看辦公文檔、發(fā)送文檔等等（如圖3.3.1所示）。用戶通過驗證登錄后，通過導(dǎo)航菜單進入各個頁面進行相關(guān)的操作。大多數(shù)用戶進行的日常操作主要是與工作項有關(guān)，包括有：接收任務(wù)、打開工作項、查看文件、保存發(fā)送文件、回退文件、跟蹤流程狀態(tài)以及用戶信息管理；對于處于開始節(jié)點的用戶，除了上述的操作外，還可以啟動一個流程實例，并且可以對其啟動的流程進行一些控制管理，如掛起、激活、終止以及查看狀態(tài)。圖3.3.1 普通用戶用例圖3.2.2 需求描述(1) 接收任務(wù)，流程中每個活動指定人員進行辦理，當(dāng)流程執(zhí)行到人員負(fù)責(zé)的活動時，負(fù)責(zé)人可主動查詢未完成任務(wù)。(2) 打開工作項，即選擇未完成任務(wù)，進入文件審批界面，進行批閱。(3) 查看文件，用戶對自己經(jīng)手過的文件進行查閱，不能編輯。(4) 保存發(fā)送文件，用戶完成審批后提交任務(wù)。(5) 回退文件，用戶審批文件時，發(fā)現(xiàn)前一級部門的工作不符合要求，可以把文件打回讓其重新審批。(6) 跟蹤流程狀態(tài)，分為三種：跟蹤用戶自己創(chuàng)建的流程的狀態(tài)、跟蹤用戶辦理過的流程的狀態(tài)和跟蹤用戶將要辦理的流程的狀態(tài)。3.3 任務(wù)實時通知常見的信息通知有兩種驅(qū)動方式：拉和推。拉是指用戶主動向服務(wù)器獲取信息；推是指服務(wù)器自動將信息顯示給用戶。作為一個比較人性化的系統(tǒng)，應(yīng)該具備這兩種機制，尤其是對于實時性要求比較高的系統(tǒng)，“推”機制是一種很好的解決方案。工作流管理系統(tǒng)是對業(yè)務(wù)流程的管理系統(tǒng)，任務(wù)能實現(xiàn)實時通知，有助于提高流程流轉(zhuǎn)速度，提高業(yè)務(wù)執(zhí)行的效率。3.4 多種業(yè)務(wù)流程的文件存儲問題工作流管理系統(tǒng)與一般的MIS系統(tǒng)不同，它不是為特定業(yè)務(wù)設(shè)計的，而是能夠支持多種不同的業(yè)務(wù)。然而，不同業(yè)務(wù)處理的文件之間存在很大的差別。流程設(shè)計者在定制流程的同時，可以選擇已存在數(shù)據(jù)庫的表單，甚至可以添加表單。所以，業(yè)務(wù)文件同樣具有靈活定制的需求，其數(shù)據(jù)存儲結(jié)構(gòu)也是該系統(tǒng)要解決的問題。3.5 文件權(quán)限問題文件權(quán)限問題是指流程執(zhí)行者對流程綁定的文件的各個部分具有不同的讀寫權(quán)限。例如，在一個申請審批流程中，處于流程某個活動的部門只能對審批表中該部門負(fù)責(zé)的部分進行編輯，其他的部分不允許修改。3.6 業(yè)務(wù)流程的基本模式文獻1中歸納了22中常見的工作流模式，經(jīng)過對普通的辦公室辦公自動化需求進行分析，其中5種最基本的模式是一般業(yè)務(wù)流程中必需的：1) 順序流向：一個步驟完成后，無條件地流向固定的下一步驟。如圖3.6.1 所示：活動A活動B 圖3.6.1 順序流向2) 選擇分流:一個步驟完成后，按一定的條件流向不同的下一步驟。這種情況下用戶執(zhí)行當(dāng)前任務(wù)并提交任務(wù)后，OAworkflow尋找后續(xù)步驟，并返回讓用戶進行選擇，以決定后續(xù)步驟。如圖3.6.2 所示: 活動A活動B活動COR 圖3.6.2 選擇分流活動A活動B活動CAND3) 并發(fā)分流:一個步驟完成后，同時激活多個后繼步驟，即多人分工同時工作的情形。當(dāng)活動A完成，并提交任務(wù)后，OAworkflow將文件無條件轉(zhuǎn)向活動B和C。如圖3.6.3 所示：圖3.6.3 并發(fā)分流4) 選擇匯合:若干個步驟完成后，都流向步驟C，而只要這些步驟中有一個或多個完成了，步驟C就可以開始?；顒覥的任一前節(jié)點提交任務(wù)后，引擎將遍歷活動C 的所有前活動實例，判斷其狀態(tài)，當(dāng)且僅當(dāng)完成的活動實例數(shù)等于活動C定義的最少通過數(shù)時，引擎才會產(chǎn)生一個對應(yīng)活動C的工作項。如圖3.6.4 所示:活動A活動B活動COR圖3.6.4選擇匯合活動A活動B活動CAND5) 并發(fā)匯合:若干個步驟完成后，都流向步驟C，只有當(dāng)這些步驟都完成了，步驟C才可以開始。即活動C的任一前節(jié)點提交任務(wù)后，引擎將遍歷活動C 的所有前活動實例，判斷其狀態(tài)，當(dāng)且僅當(dāng)所有這些活動實例都處于完成狀態(tài)時，引擎才會產(chǎn)生一個對應(yīng)活動C的工作項。如圖3.6.5 所示: 圖3.6.5 并發(fā)匯合3.7 用例闡述3.7.1啟動流程參與者：普通用戶前置條件：已經(jīng)登錄，運行服務(wù)中有待運行的流程。后置條件：用戶啟動了一個流程。步驟序列：1) 進入啟動流程界面。2) 用戶選擇想要啟動的流程。3) 系統(tǒng)啟動選中的流程，初始化活動節(jié)點。4) 打開公文編輯頁面3.7.2 掛起流程參與者：普通用戶前置條件：已經(jīng)登錄，運行服務(wù)中有該用戶啟動的流程。后置條件：用戶掛起了一個流程。步驟序列：1) 進入流程控制界面，列出由該用戶啟動并且在運行或掛起狀態(tài)的流程信息，包括序號、流程名稱、當(dāng)前狀態(tài)、啟動時間。2) 用戶選擇想要掛起的流程。3) 系統(tǒng)彈出確認(rèn)框，用戶點擊確認(rèn)掛起流程4) 流程被掛起，相應(yīng)狀態(tài)改成“掛起”。3.7.3 激活流程參與者：普通用戶前置條件：已經(jīng)登錄，運行服務(wù)中有該用戶啟動的流程，并且流程處于掛起狀態(tài)。后置條件：用戶激活了一個流程。步驟序列：1) 進入流程控制界面，列出由該用戶啟動并且在運行或掛起狀態(tài)的流程信息，包括序號、流程名稱、當(dāng)前狀態(tài)、啟動時間。2) 用戶選擇想要激活的處于掛起狀態(tài)的流程。3) 系統(tǒng)彈出確認(rèn)框，用戶點擊確認(rèn)激活流程4) 流程被激活，相應(yīng)狀態(tài)改成“執(zhí)行”。3.7.4 終止流程參與者：普通用戶前置條件：已經(jīng)登錄，運行服務(wù)中有該用戶啟動的流程。后置條件：用戶終止了一個流程。步驟序列：1) 進入流程控制界面，列出由該用戶啟動并且在運行或掛起狀態(tài)的流程信息，包括序號、流程名稱、當(dāng)前狀態(tài)、啟動時間。2) 用戶選擇想要終止的流程。3) 系統(tǒng)彈出確認(rèn)框，用戶點擊確認(rèn)終止流程4) 流程被終止，被終止的流程不再顯示相關(guān)信息。3.7.4 接收任務(wù)參與者：普通用戶前置條件：已經(jīng)登錄。后置條件：進入了任務(wù)列表界面。步驟序列：1) 點擊導(dǎo)航菜單中的“接收任務(wù)”鏈接。2) 進入任務(wù)列表界面，列出由該用戶未處理的工作項信息，包括序號、流程名稱、公文名稱、接收時間。3.7.5 打開工作項參與者：普通用戶前置條件：已經(jīng)登錄，進入任務(wù)列表界面。后置條件：進入公文編輯界面。步驟序列：1) 選擇要執(zhí)行的任務(wù)，點擊“打開”。2) 進入公文編輯界面，用戶只能編輯規(guī)定的字段，其他節(jié)點的編輯的內(nèi)容此時為只讀狀態(tài)。3.7.6 保存文件參與者：普通用戶前置條件：用戶已經(jīng)登錄，進入了公文編輯界面。后置條件：保存了經(jīng)過編輯的公文內(nèi)容。步驟序列：1) 點擊“保存”按鈕。2) 頁面刷新，內(nèi)容被保存。3.7.7 發(fā)送文件參與者：普通用戶前置條件：用戶已經(jīng)登錄，進入了公文編輯界面。后置條件：公文被發(fā)送到后續(xù)節(jié)點。步驟序列：1) 點擊“發(fā)送”按鈕。2) 系統(tǒng)自動保存公文內(nèi)容，并獲取后續(xù)節(jié)點。3) 進入后續(xù)節(jié)點界面，如果當(dāng)前節(jié)點為選擇分支節(jié)點，用戶必須選擇后續(xù)發(fā)送節(jié)點。4) 系統(tǒng)彈出確認(rèn)框，點擊確認(rèn)。5) 相應(yīng)后續(xù)節(jié)點被通知，返回查看公文界面。3.7.8 掛起工