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

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