1、“通過建模、自動化、管理和BPM (Business Process Management) 優化流程，打破跨部門跨系統業務過程依賴，提高業務效率和效果”。Workflow “全部或者部分由計算機支持或自動處理的業務過程”（工作流管 理聯盟WfMC組織對工作流概念的經典定義）BPM基本內容是管理既定工作的流程，通過服務編排，統一調控各個業務流 程，以確保工作在正確的時間被正確的人執行，達到優化整體業務過程的目的。 BPM概念的貫徹執行，需要有標準化的流程定義語言來支撐，使用統一的語言 遵循一致的標準描述具體業務過程，這些流程定義描述由專有引擎去驅動執行。 這個引擎就 是工作流引擎，它作為BPM

2、的核心發動機，為各個業務流程定義提 供解釋、執行和編排，驅動流程“動“起來，讓大家的工作“流”起來，為BPM 的應用提供基本、核心的動力來源。現實工作中，不可避免的存在跨系統跨業務的情況，而大部分企業在信息化 建設過程中是分階段或分部門（子系統）按步實施的，后期實施的基礎可能是前 期實施成 果的輸出，在耦合業務實施階段，相同的業務過程可能會在不同的實 施階段重用，在進行流程梳理過程中，不同的實施階段所使用的流程描述語言或 遵循的標準會有 所不同（服務廠商不同），有的使用WfMC的XPDL，還有些使 用BPML、BPEL、WSCI等，這就造成流程管理、業務集成上存在很大的一致性、 局限 性，提高

3、了企業應用集成的成本。BPMN2.0規范的引入。遵循BPMN2.0新規范的工作流產品能很大程度上解決此類問題。BPMN2.0相 對于舊的1.0規范以及XPDL、BPML及BPEL等最大的區別是定 義了規范的執行 語義和格式，利用標準的圖元去描述真實的業務發生過程，保證相同的流程在不 同的流程引擎得到的執行結果一致。BPMN2.0對流程執行語義 定義了三類基本 要素，它們是日常業務流程的“三板斧”：Activities （活動）一一在工作流 中所有具備生命周期狀態的都可以稱之為“活動”，如原子級的任務（Task）、 流向（Sequence Flow），以及子流程（Sub-Process）等Gat

4、eways （網關）一一顧名思義，所謂“網關”就是用來決定流程流轉指向 的，可能會被用作條件分支或聚合，也可以被用作并行執行或基于事件的排它性 條件判斷Events （事件）一一在BPMN2.0執行語義中也是一個非常重要的概念，像啟動、結束、邊界條件以及每個活動的創建、開始、流轉等都是流程事件，利用事 件機制，可以通過事件控制器為系統增加輔助功能，如其它業務系統集成、活動 預警等。這三類執行語義的定義涵蓋了業務流程常用的Sequence Flow （流程 轉向）、Task （任務）、Sub-Process （子流程）、Parallel Gateway （并行執 行網關）、ExclusiveGa

5、teway （排它型網關）、InclusiveGateway （包容型網關） 等常用圖元，如圖圖1： BPMN2.0三類基本執行語義要素現實業務所有的業務環節都離不開Activities、Gateways和Events，無論 是簡單的條件審批還是復雜的父子流程循環處理，在一個流程定 義描述中，所 有的業務環節都離不開 Task、Sequence Flow、Exclusive Gateway、 Inclusive Gateway （如圖1中右側綠色標記所示元素），其中Task是一個極 具威力的元素，它能描述業務過程中所有能發生工時的行為，它包括 User Task、Manual Task、Ser

6、vice Task、Script Task 等，可以被用來描 述人機交互任務、線下操作任務、服務調用、腳本計算任務等常規功能。User Task :生成人機交互任務，主要被用來描述需要人為在軟件系統中進 行諸如任務明細查閱、填寫審批意見等業務行為的操作，流程引擎流轉到此類節 點時，系統會自動生成被動觸發任務，須人工響應后才能繼續向下流轉。常用于 審批任務的定義。Manual Task :線下人為操作任務，常用于為了滿足流程圖對實際業務定義 的完整性而進行的與流程驅動無關的線下任務，即此類任務不參與實際工作流流 轉。常用于諸如物流系統中的裝貨、運輸等任務的描述。Service Task:服務任務

7、，通常工作流流轉過程中會涉及到與自身系統服務 API調用或與外部服務相互調用的情況，此類任務往往由一個具有特定業務服務 功能的Java類承擔，與User Task不同，流程引擎流經此節點會自動調用Java 類中定義的方法，方法執行完畢自動向下一流程節點流轉。另外，此類任務還可 充當“條件路由”的功能對 流程流轉可選分支進行自動判斷。常用于業務邏輯 API的調用。Script Task:腳本任務，在流程流轉期間以“腳本”的聲明或語法參與流 程變量的計算，目前支持的腳本類型有三種：juel（即JSP EL）、groovy和 javascript。在Activiti5.9中新增了 Shell Tas

8、k，可以處理系統外部定義的 Shell腳本文件，也與Script Task有類似的功能。常用于流程變量的處理。Activiti5支持最新的BPMN2.0規范作為支持最新BPMN2.0規范的開源工作流引擎Activit5,實現了對規范的絕 大多數圖元的定義，能夠滿足企業工作流的各種復雜應用。它是一個無侵 入的、 支持嵌入式和獨立部署的開源工作流引擎，是 Tom Bayen離開jBoss加入 Alfresco公司后的另立山頭之作，共同開發Activit5的除了 Alfresco外還有 SpringSource、 MuleSoft、Salves、FuseSource、Signavio 等公司。從 A

9、ctiviti5.0到當前的5.9 （今年3月份發布），版本更新 迭代速度很快，新 版本功能穩定，性能良好，為開源社區提供了商業工作流之外非常具有競爭力的 選擇。 Activiti5與jBPM5技術組成Activiti5使用Spring進行引擎配置以及各個Bean的管理，綜合使用IoC 和AOP技術，使用CXF作為Web Services實現的基礎，使用MyBatis進行底層 數據庫ORM的管理，預先提供Bundle化包能較容易的與OSGi進行集成，通過與 Mule ESB的集成和對外部服務（Web Service、RESTful等）的接口可以構建 全面的SOA應用；jBPM5使用jBoss.

10、org社區的大多數組件，以Drools Flow 為核心組件作為流程引擎的核心構成，以Hibernate作為數據持久化ORM實現，采用基于JPA/JTA的可插拔的持久化和事務控制規范，使 用Guvnor作為流程 管理倉庫，能夠與Seam、Spring、OSGi等集成。需要指出的是Activiti5是在jBPM3、jBPM4的基礎上發展而來的，是原jBPM 的延續，而jBPM5則與之前的jBPM3、jBPM4沒有 太大關聯，且舍棄了備受推 崇的PVM （流程虛擬機）思想，轉而選擇jBoss自身產品Drools Flow作為流 程引擎的核心實現，工作流最為重要的“人機交互”任務（類似于審批活動）則

11、 由單獨的一塊“Human Task Service”附加到Drools Flow上實現，任務的 查詢、處理等行為通過Apache Mina異步通信機制完成。優劣對比：從技術組成來看，Activiti最大的優勢是采用了 PVM （流程虛擬機），支持 除了 BPMN2.0規范之外的流程格式，與外部服務有良好的集成能力，延續了 jBPM3、jBPM4良好的社區支持，服務接口清晰，鏈式API更為優雅；劣勢是持 久化層沒有遵循JPA規范。jBPM最大的優勢是采用了 Apache Mina異步通信技術，采用JPA/JTA持久 化方面的標準，以功能齊全的Guvnor作為流程倉庫，有RedHat（jBoss

12、.org被紅 帽收購）的專業化支持；但其劣勢也很明顯，對自身技術依賴過緊且目前僅支持 BPMN2。 Activiti5 設計模式命令模式能將命令的發出與執行分開，委派給不同的對象，每一個命令都代 表一個指令，其最大的好處是提供了一個公共接口，使得用戶可以用同一種方式 調用所有的事務，同時也易于添加新事務以擴展系統。Activiti5大量采用了命令模式，在流程運行期間，所有的指令執行（比如 流程部署、流程流轉、獲取任務等）都使用此模式實現，其中涉及到四個重要 的概念：Command:Activiti5的命令定義接口，僅有一個execute方法，所有運行期 要執行的指令都要實現該接口，定義要執行的

13、具體行為。CommandContext:命令執行的上下文環境，每個Command的執行都依賴其上 下文環境，CommandContext創建了命令執行期間的 引擎會話與數據庫會話， 每個CommandContext都是一個單獨的ThreadLocal，執行期間不會受其它線程 干預，是線程安全的。CommandExecutor:命令執行器，負責執行所有的運行時Command。引擎中各 項指令的執行(即命令的產生者可能來源于多種對象)都托CommandExecutor 處理，僅有一個接口方法：execute(Command command) o ActivityBehavior: 活動行為定義，用

14、于定義BPMN2.0執行語義層的各圖元在流程引擎的行為，或稱 之為所具備的圖元特征。與Command的概念類似，僅僅描述“待執行”的指令 是什么，會發生什么樣的行為，但真正要執行時則由引擎負責驅動。人機交互任務是業務流程應用中最常用的業務類型，以BPMN2.0中定義的 “Task”這個典型元素說明一下命令模式在Activiti5中的應用：Activiti5 針對 BPMN2.0 的 Task Element 定義了 Task 接口，并依據 Semantic.xsd執行語義定義了相關任務元素所具有的行為特性，此行為特性通 過 setActivityBehavior方法進行行為與元素的綁定，這些B

15、ehavior在流程 引擎驅動流轉到活動節點時將被觸發，通 過 execute(ActivityExecution execution)執行 ActivityBehavior 中指定 的操作；每個活動有若干 個Command與之對應，比如ClaimTaskCmd、CompleteTaskCmd、 DelegateTaskCmd、 SaveTaskCmd、 DeleteTaskCmd 等，分 別表示任務的領取、完成、轉交、保存、刪除等，這些操作指令的執行結果通過 命令執行上下文 (CommandContext)得到DAO層的TaskManager將任務對象的 變更持久化到數據庫中；引擎不關心要執

16、行什么，凡是實現了 Command接口的類都可以通過 CommandExecutor執行，除了引擎提供的這些原生的任務指令外，如果業務 系 統有額外的特性化操作，也可以自定義一組Command，在Command.execute()中 自由調用外部服務、發送手機短信、附加任務屬性、調用DAO操作數據庫等， 封裝完畢后交由引擎去執行，即可得到希望的結果。同樣，如果在業務系統中需 要自定義BPMN元素或屬性，僅需同步增加ActivityBehavior接口的實現，在 解析流程定義文件時將自定義的行為實現與元素(屬性)幫定，并緩存之，待引 擎驅動到達節點時自動執行。在 ActivityBehavior

17、. execute()中依然可以調 用各種各樣的API已實現特定的業務目的。此處需要注意的是，Activiti5的CommandContext是包含事務處理的，在每 次關閉上下文環境時，會執行事務的提交，但在實際業務系統 中，業務事務、 引擎事務以及數據庫事務應該是被統一到一個事務中去管理，這就需要將 Activiti5的事務與業務系統的事務合并。Activiti5通 過Spring注入提供了 該方式的可行性，引擎內部的事務控制可以委托給業務層去處理，在初始化引擎 配置時，將業務系統中定義的DataSource和 TransactionManager傳遞給流程 配置的 dataSource、t

18、ransactionManager 屬性后，Activiti5 內部會使 用 Spring 提供的 TransactionAwareDataSourceProxy 來封裝傳進來的 DataSource， 并利用外部的事務管理來接管Activiti5的事務控制，確保了從該DataSource 獲取的數據庫連接與Spring定義的事務能夠完美地結合，從而實現業務系統 與引擎系統事務的集成。Activiti5對BPMN2.0執行語義的解析Activiti5通過BpmnParse使用SAX方式進行BPMN2.0 XML流程定義文件的 解析，是解析的核心類，從根節點開始解析，依次對Definitions

19、Attributes、 Imports、 ItemDefinitions、Messages、Interfaces、和 Errors 以及 ProcessDefinitions各個元素進行解析（以上均是標準的BPMN2.0元素），最后解析負責流程可視化定義的DiagramInterchangeElements元素。每解析一 個元素都會判 斷元素類型，如果是“活動“類型（包括Task、Gateway等）， 則會為活動設置相應的ActivityBehavior，同時如果流程定義文件中定 義了 額外屬性，Activiti5會自行利用反射機制注入到ActivityBehavior。除了 Command和

20、ActivityBehavior外，Activiti5還大量引入了監聽機制（攔 截器的概念），目前引擎主要包含四類監聽：BPMN解析監聽BpmnParseListener，負責對BPMN2.0規范的流程定義文 件進行解析控制；任務監聽TaskListener，負責對各類任務的狀態以及任務創建、指派責任人、完成任務三類事件進行響應；執行監聽 ExecutionListener，對執行過程添加輔助管控功能，對引擎 中發生的啟動、流轉、結束事件進行響應；事務監聽TransactionListener，負責事務控制監聽。PVM流程虛擬機中包含三類事件：Start、End、Take，分別表示流程的啟動、

21、 流轉和結束，流程啟動后，流引擎會從Start事件開始執行，通過Take事件， 驅動流程流向下一個環節，該“流向”的動作會被PVM運行時的AtomicOperationTransitionNotifyListenerTake 監聽，該監聽會將附加到 該流向的所有執行監聽依次執行。任務有 也有三類事件可以被監聽：Create、 Assignment、Complete,如果希望在任務被創建或指定了相關責任人或任務完成 后增加些額外的輔助功能，可以創建TaskListener接口的實現類，并將其定 義到執行定義元素中，Activiti5會處理這一切。這些監聽本質上都算是活動的 附加代理，在現有操作的

22、基礎上額外增加一個管理控制手段以達到特殊的目 的，ActivityBehavior從另一個角度來看也是一種代理，都是 由DelegateInvocation負責調用執行，它主要用來提供用戶代碼調用的上下 文環境并負責控制實際調用，Activiti5為其提供了五個實 現： ActivityBehaviorInvocation、ExecutionListenerInvocation 、 ExpressionInvocation 、 JavaDelegateInvocation、 TaskListenerInvocation。Activiti5 提供的 Command、ActivityBehavio

23、r、Listener 等接口為引擎的 功能擴展提供了方便，如果業務系統的功能不 能滿足時可以實現這些接口，以 無侵入的方式擴展Activiti5，利用這些擴展接口，可以在其執行方法中完成很 多業務邏輯，如權限校驗、與業務系統的交 互、與外部系統集成調用，甚至替 換原有功能偷梁換柱暗度陳倉。Activiti5 API 應用ProcessEngine是Activiti系統的核心接口，七類基礎服務接口通過 ProcessEngine獲取，均采用鏈式API方式，直觀明了，易于使 用：RepositoryService：流程資源服務的接口，主要用于對流程定義的部署、查 詢和刪除操。新流程的部署使用createDeployment().addResourceXXX().deploy()方法；已部署流程的查詢 使用createDeploymentQuery()附加查詢條件的方式獲取；另外可以使用 deleteDeployment和 deleteDeploymentCascade方法進行流程的刪除或級聯 刪除。TaskService:任務服務接口，該接口暴露了管理人機交互任務的操作，如 任務領取(claiming)、任務完成(completing)和任務指派(assigning)， 還包括對任務的創建