【activiti】縱觀jBPM：從jBPM3到jBPM5以及Activiti5

對jBPM來講，今年最大的事件莫過於jBPM的建立者Tom Baeyens離開JBoss了。Tom Baeyens離開的具體緣由尚不清楚，但他的離開產生了兩個結果：一是jBPM的下一個版本jBPM5徹底放棄了jBPM4的基礎代碼，基於Drools Flow重頭來過；二是Tom Baeyens加入Alfresco後很快推出了新的基於jBPM4的開源工做流系統Activiti。由此不難推測Tom Baeyens離開的部分緣由：JBoss內部對jBPM將來版本的架構實現產生了嚴重的意見分歧。更加巧合的是12月1日Activiti5剛發佈，緊接着12月2日jBPM5就發佈了第一個候選發佈版本，jBPM與Activiti之間的微妙關係可見通常。

在這篇文章裏，咱們將一塊兒回顧jBPM從jBPM3到jBPM5以及Activiti5的發展歷程，咱們能夠清晰的看見jBPM（包括Activiti）設計所遵循的一致原則：強調流程服務的可嵌入性和可擴展性。同時，從各個版本之間的變化咱們也能看見產品設計思路的變化：更增強調面向業務人員，增長BPMS（業務流程管理系統）特性。

在回顧以前，咱們首先討論一下BPMS應該嵌入仍是獨立部署的問題，由於不論是jBPM仍是Activiti，都強調了流程服務的可嵌入性。此外，咱們還須要討論一下什麼是BPMS的特性，它們所解決的問題是什麼。

 

1、嵌入式仍是獨立部署？

不論是jBPM仍是Activiti，都強調了流程服務的可嵌入性。Tom Baeyens在其我的博客裏稱做爲獨立部署的BPMS已死，緣由有兩個：一是獨立部署的BPMS須要很高的安裝使用成本，須要獨立部署、須要用戶支出大量的培訓成本和維護成本；二是獨立部署的BPMS與外部系統的交互方式是分佈式，這使得不少問題變得複雜，例如分佈式事務。Tom Baeyens表明了至關一部分人特別是開發人員的觀點。

Tom Baeyens沒有徹底理解BPMS。什麼是BPMS？BPMS最重要的目標就是須要打破各個應用系統（CRM、ECM、ERP、SCM）之間的界線，將分散在這些系統中的流程集中管理，這是BPMS的實質。一如流程再造，打破各個部門之間的壁壘，減小浪費，創建流程驅動性的組織。以下圖1所示：

 

圖 1：BPMS打破應用系統之間的界線

BPMS所要解決的問題要求其必然是獨立部署的。Tom Baeyens錯誤的根本緣由在於其將BPMS與工做流系統的定義混爲了一談，他如此定義BPMS：BPMS旨在簡化對組織核心流程進行支撐的軟件建立。也就是BPMS面向的是軟件開發人員，旨在簡化他們的開發，下降他們使用流程的門檻。而這正是工做流系統須要解決的問題。

BPMS面向企業用戶，工做流面向開發社區和系統集成商。

2、BPMS特性

jBPM四、jBPM5和Activiti5都增長了其BPMS特性，那些特性可以稱爲BPMS特性呢？咱們先看一看BPMS須要解決的問題，爲解決這些問題所增長的特性就是BPMS特性。

1. 如何設計流程，在組織中高效地對設計出的流程進行溝通，取得共識？

   • 提供跨越組織的流程標準標記符號與術語（BPMN已經成爲標準）
   • 流程及相關文檔的可視化（流程/內容存儲倉庫）
   • 提供在組織結構內進行不一樣層次之間的流程導航（流程存儲倉庫支持組織模型）
   • 流程定義在各個層次/部門間的一致性，避免業務人員的流程建模轉換到IT系統時受到損耗（流程引擎支持基於圖的建模，支持擴展）

2. 如何更好地執行流程？

   • 業務活動的實時監控，預警與控制（BAM）
   • 流程執行的仿真
   • 流程執行的統計分析與反饋（報表）
3. 如何更好地管理流程？
   • 打破各個應用系統之間的界線，統一管理全部流程（EAI，與ESB的集成）
   • 對業務人員友好的建模工具
4. 如何在執行流程過程當中遵循業內最佳實踐和規則？
   • 面向流程的知識管理
   • 規則引擎

3、完整的工做流實現jBPM3

jBPM3的最新版本是3.2.7，其包括瞭如下組件：基於Eclipse的流程設計器、用於監控案例（流程實例）和處理任務的Web控制檯以及jPDL核心庫。以下圖2所示：

圖 2：jBPM3組件

1. 基於Eclipse的流程設計器

   提供給開發人員繪製jPDL流程圖，由於該設計器基於Eclipse，因此生成的流程文件能夠與開發代碼一塊兒組織管理，很是容易進行單元測試。實現了工做流管理系統參考模型裏的接口1。

2. Web管理控制檯

   主要有兩個功能：一是做爲工做流客戶端應用接口，給用戶提供一種手段，以處理案例運行過程當中須要人工處理的任務；二是對案例的狀態進行監控與管理。實現了工做流管理系統參考模型裏的接口2和5。

3. jPDL核心庫

   jPDL核心庫是一個單獨的JAR包，能夠嵌入到目標應用中執行，它包括了：

   • 流程倉庫：解析jPDL流程定義文件並存儲讀取；
   • 流程引擎：對流程定義進行初始化和調度執行，節點的運行期行爲與jPDL裏定義的節點類型一一綁定；
   • 任務管理：生成任務節點所對應的工做項，管理工做項的生命週期（初始化、分配執行者、執行、掛起、結束、終止）；
   • 事件管理：發佈案例和任務的開始、結束事件，經過監聽者模式調用相應的事件處理器；
   • 異步執行機制：經過線程實現了Job Executor，進行異步工做的處理，這些工做包括了時間處理、異步動做。
   • 身份組件模型：實現了一套簡單的身份組件模型，包括了組、用戶和權限。

   經過調用自定義Java代碼實現了對外部應用的調用，從而實現工做流管理系統參考模型裏的接口3。

jBPM3是一個輕量級的嵌入式工做流系統。它在Java社區的成功得益於兩個方面：一是嵌入式，這下降了使用工做流的門檻；二是對開發人員友好，這表如今易讀的jPDL、流程的可測試性(Eclipse插件)以及節點行爲的可擴展性，咱們能夠很是容易的在流程運行中加入本身定製的行爲（經過事件處理器和Action）。jBPM3面向開發人員，它解決的問題是流程的自動化，它的影響力集中在Java開發社區，是一個完整的工做流系統實現。

4、向BPMS努力的jBPM4

與jBPM3相比，jBPM4最大的變化是引入了流程虛擬機（PVM），同時增長了BPMS的特性。jBPM4再也不知足於工做流系統的定位，開始向BPMS努力。

1. 爲何引入流程虛擬機

   儘管jBPM3在Java社區取得了很大的成功，可是有一件事始終被人們詬病，那就是它不支持流程語言規範，從最開始的XPDL、BPEL到後來的BPMN，它採用了自定義的jPDL。在jBPM3中，節點的運行期行爲與jPDL裏定義的節點類型是一一綁定的，這形成了流程引擎與特定流程語言的綁定，要支持其餘的流程語言變得困難。因而在jBPM4中，jBPM提出了流程虛擬機的概念，即流程引擎與流程語言解耦，經過一套通用的流程模型並配以可定製的節點運行期行爲實現了對多流程語言的支持。

   流程虛擬機帶來的好處是多方面的：第一也是最重要的是jBPM4支持了BPMN。

   第二是實現了基於流程組件的流程引擎，流程圖(語言)與實現解耦，咱們使用通用編程語言實現節點運行期行爲，稱之爲流程組件，經過將流程圖與流程組件掛接，避免了圖的損耗。在這一點上，Tom Baeyens對BPMN到BPEL的轉換提出了一針見血的批評：BPMN和jPDL以及XPDL都是基於圖的，而BPEL是基於塊的，這形成了當將業務人員使用BPMN所創建的流程模型向BPEL執行模型進行轉換時，出現許多的不匹配，最初的流程模型會扭曲變形。而扭曲的後果就是業務人員與開發人員之間的協做困難，這影響了流程從業務到技術的實現。

   第三個好處是咱們能夠定義領域特定語言（DSL），在特定的應用裏，採用DSL約定並隱藏了大部分的技術細節可能作到業務人員對執行流程的直接修改，例如企業文檔管理裏的審批流程。

2. BPMS特性的加入

   這表如今如下三個方面：第一是支持了BPMN，BPMN已經成爲業務人員的流程建模標準；第二是引入了Signavio做爲面向業務人員的Web建模器；第三是在已有的Web管理控制檯加入了對案例和任務的統計功能。jBPM4的組件以下圖3所示：

   圖3：jBPM4組件

   和jBPM3同樣，jBPM4依然是輕量級的、可嵌入的工做流系統。相比jBPM3，它將業務人員做爲最終用戶之一，增長了部分BPMS特性，同時PVM的引入使得它的可擴展性獲得了極大的加強，咱們甚至能夠定義本身的DSL。

   在BPMS特性裏咱們提到了應該避免業務人員的流程建模轉換到IT系統時受到損耗，最理想的狀況是業務人員與開發人員共用一個流程模型，業務人員可以直接對流程進行調整（在特定應用中，經過DSL是能夠作到的）；其次是經過BPMS將業務人員的模型與實際執行的技術模型關聯起來（不少商業產品已經作到了這一點，在Activiti5中咱們也會看到這一點），業務人員、開發人員以及運營團隊之間可以作到很好的協調；最差是業務人員與開發人員各自爲政，獨立維護各自的流程模型，而且模型之間存在極大的不匹配，此時流程的迅速變化基本上是奢望。

5、鳩佔鵲巢的Drools Flow與jBPM5

目前jBPM5剛剛發佈了第一個候選發佈版本，jBPM5基本上徹底拋棄了jBPM4的代碼，全部代碼所有來自原先的Drools Flow。Drools Flow最初被用來解決規則執行順序的問題。其實從Drools Flow開始支持BPMN時起，咱們已經預感到它與jBPM的競爭關係。

jBPM5依舊定位爲輕量級的可嵌入的工做流系統。在jBPM5的特性裏，有這麼兩條引人關注：一是引入了Guvnor做爲流程倉庫，這解決了流程的可視化問題，流程定義做爲資源被管理，咱們能夠對流程定義進行可視化管理以及全文檢索（Guvnor使用了Jackrabbit做爲了其存儲實現，但咱們的經驗代表Jackrabbit在大數據量狀況下性能存在嚴重問題）；第二是規則引擎(Drools Expert)、事件處理引擎(Drools Fusion)與流程引擎的合三爲一，這是jBPM5最讓人期待的地方。jBPM5的組件以下圖4所示：

圖 4：jBPM5組件

規則引擎在流程中的應用已經很是普遍了，咱們這裏說說事件處理引擎。

事件處理引擎是業務活動監控（BAM）的基礎，BAM的功能及執行過程，以下：

• 捕獲：BAM捕獲各類事件（經過消息監聽器、適配器、代理等）。這些事件來自應用、系統軟件、外部交易夥伴。消息是BAM的核心——它們反應底層業務流程的情況。
• 過濾：BAM過濾掉沒有直接後果的事件，在不少狀況下由支持事件流處理（Event Stream Processing，簡稱ESP）或復瑣事件處理（Complex Event Processing，簡稱CEP）引擎來進行過濾。
• 分析：BAM根據分析模型和規則將相關事件聯繫起來。
• 警告：BAM向用戶提出警告，以便用戶在必要時進行控制。

如上所示，BAM的執行過程包含四個步驟，而前三個步驟都是對事件進行相關的處理（捕獲事件、過濾事件、分析事件、關聯事件），所以在大多數BAM的技術實現方案中，都基於CEP和ESP的引擎來實現BAM的功能。

與jBPM4相比，jBPM5對PVM的放棄也帶來了幾個不小的問題：第一是對開發人員來講只支持BPMN，再也不支持jPDL（固然提供了遷移工具）；第二是流程執行的可擴展性回到了jBPM3的年代，僅僅支持自定義動做（至關於jBPM3裏的Action）。此外，Web建模器由Signavio替換爲了Oryx Designer。

總而言之，jBPM5經過引入流程倉庫和BAM繼續向BPMS邁進（目前的進展是與流程倉庫的集成還未完成，BAM基於日誌進行分析），同時，因爲再也不支持PVM和jPDL，帶來了流程擴展性的下降和社區開發人員的將來流失。

6、Activiti5的反擊

Activiti5是Tom Baeyens加入Alfresco後推出的新的基於jBPM4的開源工做流系統，1號剛剛發佈第一個版本。Activiti的開發團隊相比與jBPM強大了許多，有23位核心開發者。固然這也是因爲activiti規劃的功能所致：包括核心引擎、Web的流程建模器、協做工具Activiti Cycle、Activiti Probe、Activiti Explorer、與Spring的集成、與Mule的集成等。

圖 5：Activiti5的組件

如上圖所示，Activiti5由三種類型的組件組成，分別是：專用工具（Dedicated Tools）、內容存儲工具（Stored Content）和協做工具（Collaboration Tool）。

專用工具包括如下：

• Alfresco—Alfresco公司的企業級內容管理產品

Alfresco 是一個開源的、企業級的內容管理系統，功能包括：文檔管理、協做、記錄管理、知識庫管理、Web內容管理等功能。Alfresco與Activiti的深刻集成實現了流程及相關文檔的可視化。更重要的是Alfresco支持組織模型，可以提供在組織結構內進行不一樣層次之間的流程導航。

• Activiti Modeler—建模器

基於開源Signavio Web流程編輯器的一個定製版本，提供了對BPMN2.0圖形化規範的支持，建模後的流程以文件格式進行存儲。

• Activiti Designer—Eclipse插件形式的建模器
• Activiti probe—管理及監控組件

對流程引擎運行期實例提供管理及監控的Web控制檯。包含部署的管理、流程定義的管理、數據庫表的檢視、日誌查看、事務的平均執行時間、失敗屢次的工做等功能。

• Activiti Explorer—任務管理組件

提供任務管理功能和對案例、任務基於歷史數據的統計分析（報表）功能。Web應用程序。

內容存儲工具：包括了文檔倉庫、模型倉庫、SVN倉庫、MVN倉庫和Activiti引擎。其中文檔倉庫、SVN倉庫和MVN倉庫三個組件爲協做工具（Activiti Cycle）提供底層的支撐。Activiti引擎則是之前的PVM。

協做工具：與jBPM4相比，Activiti5最使人矚目的特性就在於它的協做工具組件。

Activiti Cycle徹底是一種新類型的BPM組件。它是一個用來促進業務人員、開發人員和IT運營人員協做的Web應用程序。 在現實的場景中，業務文檔有業務人員所持有，而軟件程序由開發團隊所管理，被部署的軟件應用則被IT管理人員所管理。三者之間不能很好的協做。咱們能夠想象這樣一個場景，業務經理用文檔來維護需求和visio格式的流程圖，開發人員管理可執行的流程和大量的Java源文件而IT維護人員則管理部署在Tomcat中的.war文件和存儲在Activiti數據庫中的流程。

圖 6：Activiti cycle協做組件邏輯示意圖

Activiti Cycle經過BusinessLink將與流程相關的業務人員、開發團隊與IT維護人員關聯起來，實現他們之間的協做。

總而言之，與jBPM4相比，Activiti5目前最重要的加強就是實現了流程的可視化以及創新的Activiti Cycle協做組件，此外，經過與Mule的集成增強了其集成能力。其對PVM的保留使其繼承了jBPM4強大的可擴展能力，對jBPM的老用戶來講，這是向其遷移的重要理由。

7、總結

jBPM3是一個完整的工做流系統實現，面向開發人員，目的在於簡化對組織核心流程進行支撐的軟件建立，不支持標準。

jBPM4引入PVM，使其擁有更強大的擴展性，同時增長BPMS特性，這些特性包括了對BPMN的支持、面向業務人員的Web建模器和簡單統計分析功能的加入。

jBPM5基於原先的Drools Flow，支持BPMN，經過與Drools的合併支持BAM，經過內容倉庫增長對流程可視化的支持。因爲放棄了jBPM4的PVM，引擎的可擴展性受到損害，而且再也不支持jPDL。

Activiti5基於jBPM4，與Alfresco的集成增長了其流程可視化與管理能力，同時經過創新的Activiti Cycle協做組件支持流程相關人員之間的協調，最後，它增強了集成能力。

對於工做流應用或者jBPM三、jBPM4的老用戶，建議轉向Activiti5。

 

原文地址：http://www.infoq.com/cn/articles/rh-jbpm5-activiti5