【正文】 步驟(就叩)里面包含一個或多個動作(action)。如果結(jié)果是一個分支結(jié)構(gòu)，在流程定義時需要設(shè)置一個“split”屬性，其值表示將要執(zhí)行的分支路徑的標(biāo)識。[1] 流程建模OS Workflow采用自己的流程定義格式，其流程定義遵守的規(guī)則包括:一個工作流定義由多個步驟(Step)組成，其中每一個步驟由一個或多個動作(Action)組成，一個動作可以由用戶觸發(fā)執(zhí)行， Results和零個或多個Conditional Results，如果指定了多個Conditional Results，那么第一個符合條件的將會被執(zhí)行，如果沒有符合條件的Conditional Result，那么Unconditional Result將會被執(zhí)行。在工作流生命期內(nèi)有至少一個或多個活動的State.OSWorkflow本身自帶了一個可選的用戶組織模型，該模型只提供了用戶和用戶組的存儲，沒有涉及用戶的角色概念，在系統(tǒng)訪問控制和授權(quán)方面不夠完善，因此使用時通常選擇配置使用自己實現(xiàn)的用戶組織模型。在此過程中，如果將一項任務(wù)分配給某個執(zhí)行者，該執(zhí)行者就會獲得一個Token對象標(biāo)識。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)移。1. jBPMjBPM結(jié)合了工作流應(yīng)用開發(fā)的便利性和企業(yè)應(yīng)用集成能力，其業(yè)務(wù)流程是通過本身提供的流程定義語言jPDL (jBPM Process Definition Language)進行配置，但由于沒有提供規(guī)范接口，從而不易于與其它工作流引擎進行交互。(4)維護工作流相關(guān)數(shù)據(jù):工作流在執(zhí)行過程中要維護不同過程和活動實例的內(nèi)部狀態(tài)信息，以及用于協(xié)調(diào)和恢復(fù)的各種檢查數(shù)據(jù)和恢復(fù)/重起信息，向用戶傳遞必要的相關(guān)信息。用戶應(yīng)用接口是指首先通過任務(wù)列表管理器向用戶提供任務(wù)列表，供用戶選擇相應(yīng)的任務(wù)(必要的時候可以調(diào)用相應(yīng)的工具來完成)，任務(wù)完成后由用 戶修改任務(wù)項的狀態(tài)。(2)為過程和活動的執(zhí)行進行導(dǎo)航:包括啟動和終止實例，根據(jù)活動定義中的條件決定后續(xù)活動的執(zhí)行順序。從應(yīng)用上來說，一個工作流引擎必須具有的核心功能包括：(1)流程實例化及執(zhí)行過程模型:解釋企業(yè)經(jīng)營過程的流程定義，根據(jù)過程執(zhí)行需要的初始條件和執(zhí)行參數(shù)生成過程實例，運行過程實例并管理其運行過程。 嵌入到企業(yè)應(yīng)用中，只提供工作流引擎服務(wù)，開源領(lǐng)域的OS Workflow引擎即屬于這種情況。EAI將進程、軟件、標(biāo)準(zhǔn)和硬件聯(lián)合起來，在兩個或更多的企業(yè)系統(tǒng)之間實現(xiàn)無縫集成，使它們就像一個整體一樣，如B2B形式的電子商務(wù)。 216。目前，工作流引擎的應(yīng)用可以分為三種方式:216。目的是通過將工作分解成定義良好的任務(wù)、角色，按照一定的規(guī)則和過程來執(zhí)行這些任務(wù)并對它們進行監(jiān)控，達(dá)到提高工作效率、降低生產(chǎn)成本、提高企業(yè)生產(chǎn)經(jīng)營管理水平和企業(yè)競爭力的目標(biāo)。本文由以下六章和參考文獻組成：第一章 引言，介紹了本課題的背景和意義。本項目采用了Spring + Hibernate 這種流行的Web應(yīng)用程序設(shè)計框架組合。本文分別從流程實例化、流程實例管理、流程導(dǎo)航和維護相關(guān)數(shù)據(jù)等模塊詳細(xì)描述了實現(xiàn)方案，其中關(guān)于系統(tǒng)的關(guān)鍵功能部分給出了具體API語義分析。本文分析了辦公自動化項目的功能需求，然后針對項目對流程控制的靈活需求，采用了一種結(jié)構(gòu)清晰、功能完整的過程定義格式，使引擎在支持流程分支跳轉(zhuǎn)的時候，還允許用戶手動指定流程的直接后續(xù)步驟，在借鑒了現(xiàn)有工作流引擎設(shè)計思想的基礎(chǔ)上，給出了一個工作流引擎的設(shè)計方案。3) 文件權(quán)限設(shè)置精確該系統(tǒng)的每個業(yè)務(wù)流程綁定一個公文，處于流程中的各個活動對公文的讀寫權(quán)限看精確到字段。用戶可以根據(jù)具體的業(yè)務(wù)流程，使用客戶端建模工具定制合適的模型。該工作流引擎——OAworkflow是借鑒了已有的工作流引擎，對某些復(fù)雜功能進行簡化后，重新設(shè)計的。對于國內(nèi)大部分初次使用工作流技術(shù)的中小型項目來說，這些工作流軟件的功能特性大大超過了需要，客戶需要承受漫長的學(xué)習(xí)周期、復(fù)雜的安裝配置等帶來的風(fēng)險。在國內(nèi)，上海交通大學(xué)的基于Petri網(wǎng)點分布是工作流管理的研究，浙江大學(xué)的基于工作流過程定義語言（WPDL）的工作流建模平臺，都取得了良好的研究成果。還有Microsoft, BEA, IBM, SAP等公司聯(lián)合提交發(fā)布的BPEL規(guī)范等等。目前，工作流技術(shù)還處于發(fā)展曲線的初級階段，然而，關(guān)于這方面的研究十分活躍，形成了許多規(guī)范標(biāo)準(zhǔn)。該技術(shù)的目的是通過將工作分解成定義良好的任務(wù)、角色，按照一定的規(guī)則和過程來執(zhí)行這些任務(wù)并對它們進行監(jiān)控，達(dá)到提高工作效率、降低生產(chǎn)成本、提高企業(yè)生產(chǎn)經(jīng)營管理水平和企業(yè)競爭力的目標(biāo)。 基于OA系統(tǒng)的工作流引擎設(shè)計方案11 引言 課題的背景與目標(biāo)工作流的概念起源于生產(chǎn)和辦公自動化領(lǐng)域，是針對日常工作中具有固定流程的業(yè)務(wù)活動提出的一個概念。工作流管理聯(lián)盟(WFMC)給出的工作流定義是：工作流是一類能夠完全或者部分自動執(zhí)行的經(jīng)營過程，它根據(jù)一系列過程規(guī)則、文檔、信息或任務(wù)能夠在不同的執(zhí)行者之間進行傳遞與執(zhí)行。工作流管理系統(tǒng)的核心部分是工作流引擎，引擎是驅(qū)動流程流動的主要部件，它負(fù)責(zé)解釋工作流流程定義，創(chuàng)建并初始化流程實例，控制流程流動的路徑，記錄流程運行狀態(tài)，掛起或喚醒流程，終止正在運行的流程，與其他引擎之間通訊等等工作。例如主要的有：工作流管理聯(lián)盟（Workflow Management Coalition ，WfMC）在體系結(jié)構(gòu)[6]、工作流相關(guān)術(shù)語[7]及應(yīng)用程序接口[8]、管理控制接口[9]、過程語言描述[10]等方面提出的一系列規(guī)范。在實際應(yīng)用中開源產(chǎn)品占據(jù)了重要的地位，如JBoss 項目中的jBPM、由OpenSymphony組織開發(fā)的OSWorkflow、Enhydra組織開發(fā)的Shark。但是工作流管理技術(shù)很多方面還不成熟，在使用過程中往往會遇到的一個重要問題是系統(tǒng)過于龐大復(fù)雜：一些工作流軟件產(chǎn)品，特別是國外成熟的產(chǎn)品，經(jīng)過多年的發(fā)展，功能強大，配置和接口多樣靈活。鑒于上述的原因，本課題的目標(biāo)在于提出一個配置簡單、使用方便、功能實用的工作流引擎的設(shè)計方案，并完成編碼。與傳統(tǒng)工作流管理系統(tǒng)相比，本工作流管理系統(tǒng)具有以下優(yōu)點：1) 支持靈活的流程定制該系統(tǒng)能夠針對辦公自動化系統(tǒng)中的典型流程案例對流程進行靈活定制，支持的流程路由包括：順序路由、匯聚路由和分支路由。2) 功能詳細(xì)實用例如該系統(tǒng)支持流程分支跳轉(zhuǎn)的時候，允許用戶手動指定流程的直接后續(xù)步驟；當(dāng)審批不合格時，文檔回退的功能等。4) 支持可視化建模5) 結(jié)構(gòu)清晰，配置簡單 課題研究內(nèi)容及文本組織本課題的重點研究內(nèi)容有：1) 模型定義。2) 工作流引擎的實現(xiàn)。3) 技術(shù)架構(gòu)。從而使得該引擎具有架構(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é)442 相關(guān)技術(shù)及原理 工作流技術(shù)工作流的概念起源于生產(chǎn)組織和辦公自動化領(lǐng)域，它是針對日常工作中具有固定程序的活動而提出的一個概念。 工作流引擎核心功能工作流引擎降低了工作流系統(tǒng)應(yīng)用模塊與業(yè)務(wù)流程之間的禍合度，當(dāng)業(yè)務(wù)流程發(fā)生變化時，只需修改流程定義，具體的應(yīng)用程序保持不變，工作流引擎對于用戶來說是透明的。 作為一個完整的系統(tǒng)提供給最終用戶，能單獨運行，如IBM的Lotus Domino/Notes系統(tǒng)。 僅僅作為企業(yè)應(yīng)用集成(Enterprise Application Integration EAI)平臺。216。，用戶可以通過系統(tǒng)提供的客戶端(如建模工具、任務(wù)列表等)與工作流引擎進行交互。一個過程模型實際是企業(yè)經(jīng)營過程的一個模板，它可以被執(zhí)行多次，也可以有多個有關(guān)這個過程模型的實例在同時運行。(3)與外部資源交互完成業(yè)務(wù)活動:分為用戶應(yīng)用接口和直接調(diào)用應(yīng)用接口兩種情況。直接調(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)職能部門。 兩種現(xiàn)有工作流引擎目前，OpenSymphony組織開發(fā)的OS Workflow,和Moss項目中集成的jBPM是應(yīng)用比較廣泛的工作流產(chǎn)品，本節(jié)將對這三種引擎的設(shè)計方案和實現(xiàn)機制進行分析介紹。由于JBPM持久層采用Hibernate技術(shù)來實現(xiàn)，因此具有一定的可擴展性。引擎在一個流程實例開始的時候產(chǎn)生一個RootToken，而這個Token對象會隨著流程實例運行而轉(zhuǎn)移，從而來表示任務(wù)的依序執(zhí)行。2. OSWorkflowOSWorkflow基于有限狀態(tài)機(Finite State Machine, FSM)的概念，它的每個State是通過StepID和Status聯(lián)合表示，而State的轉(zhuǎn)換是由動作驅(qū)動的。OSWorkflow具有一定的靈活性，在流程建模方面不僅支持BeanShell腳本，還支持Java, BSF和EJB等，并且可以采用JDBC, Hibernate, EJB等多種數(shù)據(jù)持久化方式。一個步驟的后續(xù)步驟有可能是其本身、一個新的步驟、一個分支結(jié)構(gòu)(Split)或者一個匯合(Join)結(jié)構(gòu)，當(dāng)然，這些情況下工作流自身的狀態(tài)也有可能發(fā)生改變。相應(yīng)地，一個分支結(jié)構(gòu)也具有一個或多個Unconditional Results. Unconditional Results的值指向分支結(jié)構(gòu)的各個不同分支。在每個動作里面可以手動設(shè)置prefunctions和postfunctions，表示在該action執(zhí)行之前或之后要執(zhí)行的動作。[2] 流程推進機制OS Workflow的流程推進機制與通常所說的流程不同，其驅(qū)動是通過動作 (Action)的執(zhí)行來進行的，其實現(xiàn)是分為兩個步驟，一是具體實施動作，另一個是維護流程狀態(tài)變遷。在狀態(tài)變遷的過程中，會執(zhí)行預(yù)先定義的前置和后置函數(shù)。所以在OS Workflow的執(zhí)行引擎類中，只有針對Action的遷移，而沒有針對某一步驟( Step)的轉(zhuǎn)換。如果設(shè)置Action的結(jié)果為Finished，表示該Action在執(zhí)行完以后的結(jié)果狀態(tài)就是Finished。OSWorkflow的流程運轉(zhuǎn)和調(diào)度的核心理念是，在一個工作流程的生命周期中，總會存在至少一個或多個State。OS Workflow實現(xiàn)流程導(dǎo)航功能的算法可以描述為：216。根據(jù)流程定義解 析到的結(jié)果和當(dāng)前步驟的id取得當(dāng)前步驟。 判斷當(dāng)前用戶是否有執(zhí)行該活動的權(quán)限，然后將當(dāng)前用戶從當(dāng)前步驟 的用戶列表中刪除，遍歷此列表，若為空表示該步驟已經(jīng)完成，進入 下一步。216。取得下一步信息，并將其 設(shè)置為當(dāng)前步驟。 重復(fù)上述步驟，直至流程完成。正是于其輕量級特性，所以可以方便的將它集成到應(yīng)用系統(tǒng)中去。框架的主要優(yōu)勢之一就是其分層架構(gòu)，分層架構(gòu)允許您選擇使用哪一個組件，同時為 J2EE 應(yīng)用程序開發(fā)提供集成的框架。Spring 模塊構(gòu)建在核心容器之上，核心容器定義了創(chuàng)建、配置和管理 bean 的方式，如圖 所示。每個模塊的功能如下：216。核心容器的主要組件是 BeanFactory，它是工廠模式的實現(xiàn)。216。Spring 上下文包括企業(yè)服務(wù)，例如 JNDI、EJB、電子郵件、國際化、校驗和調(diào)度功能。 Spring AOP：通過配置管理特性，Spring AOP 模塊直接將面向方面的編程功能集成到了 Spring 框架中。Spring AOP 模塊為基于 Spring 的應(yīng)用程序中的對象提供了事務(wù)管理服務(wù)。216。異常層次結(jié)構(gòu)簡化了錯誤處理，并且極大地降低了需要編寫的異常代碼數(shù)量（例如打開和關(guān)閉連接）。216。所有這些都遵從 Spring 的通用事務(wù)和 DAO 異常層次結(jié)構(gòu)。 Spring Web 模塊：Web 上下文模塊建立在應(yīng)用程序上下文模塊之上，為基于 Web 的應(yīng)用程序提供了上下文。Web 模塊還簡化了處理多部分請求以及將請求參數(shù)綁定到域?qū)ο蟮墓ぷ鳌?Spring MVC 框架：MVC 框架是一個全功能的構(gòu)建 Web 應(yīng)用程序的 MVC 實現(xiàn)。Spring 框架的功能可以用在任何 J2EE 服務(wù)器中，大多數(shù)功能也適用于不受管理的環(huán)境。毫無疑問，這樣的對象可以在不同 J2EE 環(huán)境 （Web 或 EJB）、獨立應(yīng)用程序、測試環(huán)境之間重用。編程式的，比較靈活，但是代碼量大，存在重復(fù)的代碼比較多；聲明式的比編程式的更