縱觀jBPM：從jBPM3到jBPM5以及Activiti5

      我們将一起回顧jBPM從jBPM3到jBPM5以及Activiti5的發展曆程，我們可以清晰的看見jBPM（包括Activiti）設計所遵循的一緻原則：強調流程服務的可嵌入性和可擴充性。同時，從各個版本之間的變化我們也能看見産品設計思路的變化：更加強調面向業務人員，增加BPMS（業務流程管理系統）特性。

      在回顧之前，我們首先讨論一下BPMS應該嵌入還是獨立部署的問題，因為不管是jBPM還是Activiti，都強調了流程服務的可嵌入性。此外，我們還需要讨論一下什麼是BPMS的特性，它們所解決的問題是什麼。

      不管是jBPM還是Activiti，都強調了流程服務的可嵌入性。Tom Baeyens在其個人部落格裡稱作為獨立部署的BPMS已死，原因有兩個：一是獨立部署的BPMS需要很高的安裝使用成本，需要獨立部署、需要使用者支出大量的教育訓練成本和維護成本；二是獨立部署的BPMS與外部系統的互動方式是分布式，這使得很多問題變得複雜，例如分布式事務。Tom Baeyens代表了相當一部分人特别是開發人員的觀點。

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

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

       BPMS面向企業使用者，工作流面向開發社群和系統內建商。

     jBPM4、jBPM5和Activiti5都增加了其BPMS特性，那些特性能夠稱為BPMS特性呢？我們先看一看BPMS需要解決的問題，為解決這些問題所增加的特性就是BPMS特性。

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

提供跨越組織的流程标準标記符号與術語（BPMN已經成為标準）

流程及相關文檔的可視化（流程/内容存儲倉庫）

提供在組織結構内進行不同層次之間的流程導航（流程存儲倉庫支援組織模型）

流程定義在各個層次/部門間的一緻性，避免業務人員的流程模組化轉換到IT系統時受到損耗（流程引擎支援基于圖的模組化，支援擴充）

如何更好地執行流程？

業務活動的實時監控，預警與控制（BAM）

流程執行的仿真

流程執行的統計分析與回報（報表）

如何更好地管理流程？

打破各個應用系統之間的界線，統一管理所有流程（EAI，與ESB的內建）

對業務人員友好的模組化工具

如何在執行流程過程中遵循業内最佳實踐和規則？

面向流程的知識管理

規則引擎

        jBPM3的最新版本是3.2.7，其包括了以下元件：基于Eclipse的流程設計器、用于監控案例（流程執行個體）和處理任務的Web控制台以及jPDL核心庫。如下圖2所示：

圖 2：jBPM3元件

基于Eclipse的流程設計器提供給開發人員繪制jPDL流程圖，因為該設計器基于Eclipse，是以生成的流程檔案可以與開發代碼一起組織管理，非常容易進行單元測試。實作了工作流管理系統參考模型裡的接口1。

Web管理控制台主要有兩個功能：一是作為工作流用戶端應用接口，給使用者提供一種手段，以處理案例運作過程中需要人工處理的任務；二是對案例的狀态進行監控與管理。實作了工作流管理系統參考模型裡的接口2和5。

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

流程倉庫：解析jPDL流程定義檔案并存儲讀取；

流程引擎：對流程定義進行初始化和排程執行，節點的運作期行為與jPDL裡定義的節點類型一一綁定；

任務管理：生成任務節點所對應的工作項，管理工作項的生命周期（初始化、配置設定執行者、執行、挂起、結束、終止）；

事件管理：釋出案例和任務的開始、結束事件，通過監聽者模式調用相應的事件處理器；

異步執行機制：通過線程實作了Job Executor，進行異步工作的處理，這些工作包括了時間處理、異步動作。

身份元件模型：實作了一套簡單的身份元件模型，包括了組、使用者和權限。

通過調用自定義Java代碼實作了對外部應用的調用，進而實作工作流管理系統參考模型裡的接口3。

jBPM3是一個輕量級的嵌入式工作流系統。它在Java社群的成功得益于兩個方面：一是嵌入式，這降低了使用工作流的門檻；二是對開發人員友好，這表現在易讀的jPDL、流程的可測試性(Eclipse插件)以及節點行為的可擴充性，我們可以非常容易的在流程運作中加入自己定制的行為（通過事件處理器和Action）。jBPM3面向開發人員，它解決的問題是流程的自動化，它的影響力集中在Java開發社群，是一個完整的工作流系統實作。

與jBPM3相比，jBPM4最大的變化是引入了流程虛拟機（PVM），同時增加了BPMS的特性。jBPM4不再滿足于工作流系統的定位，開始向BPMS努力。

為什麼引入流程虛拟機

盡管jBPM3在Java社群取得了很大的成功，但是有一件事始終被人們诟病，那就是它不支援流程語言規範，從最開始的XPDL、BPEL到後來的BPMN，它采用了自定義的jPDL。在jBPM3中，節點的運作期行為與jPDL裡定義的節點類型是一一綁定的，這造成了流程引擎與特定流程語言的綁定，要支援其他的流程語言變得困難。于是在jBPM4中，jBPM提出了流程虛拟機的概念，即流程引擎與流程語言解耦，通過一套通用的流程模型并配以可定制的節點運作期行為實作了對多流程語言的支援。

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

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

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

BPMS特性的加入

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

圖3：jBPM4元件

和jBPM3一樣，jBPM4依然是輕量級的、可嵌入的工作流系統。相比jBPM3，它将業務人員作為最終使用者之一，增加了部分BPMS特性，同時PVM的引入使得它的可擴充性得到了極大的增強，我們甚至可以定義自己的DSL。

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

目前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，帶來了流程擴充性的降低和社群開發人員的未來流失。

      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的老使用者來說，這是向其遷移的重要理由。

jBPM3是一個完整的工作流系統實作，面向開發人員，目的在于簡化對組織核心流程進行支撐的軟體建立，不支援标準。 jBPM4引入PVM，使其擁有更強大的擴充性，同時增加BPMS特性，這些特性包括了對BPMN的支援、面向業務人員的Web模組化器和簡單統計分析功能的加入。 jBPM5基于原先的Drools Flow，支援BPMN，通過與Drools的合并支援BAM，通過内容倉庫增加對流程可視化的支援。由于放棄了jBPM4的PVM，引擎的可擴充性受到損害，并且不再支援jPDL。 Activiti5基于jBPM4，與Alfresco的內建增加了其流程可視化與管理能力，同時通過創新的Activiti Cycle協作元件支援流程相關人員之間的協調，最後，它加強了內建能力。 對于工作流應用或者jBPM3、jBPM4的老使用者，建議轉向Activiti5。