縱觀 jBPM：從 jBPM3 到 jBPM5 以及 Activiti5

https://www.infoq.cn/article/rh-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。

關於做者

榮浩，ThoughtWorks 諮詢師，關注敏捷和企業流程改進過程，目前正與辛鵬合著《Head First Process- 深刻淺出 IT 流程》一書。博客地址http://ronghao.javaeye.com。