1. 名詞解釋
1.1. BPM
Business Process Management，業務流程管理，“通過建模、自動化、管理和優化流程，打破跨部門跨系統業務過程依賴，提高業務效率和效果”。
1.2. BPMN
Business Process Modeling Notation，業務流程建模與標註，包括這些圖元如何組合成一個業務流程圖（Business Process Diagram）；討論BPMN的各種的用途，包括以何種精度來影響一個流程圖中的模型；BPMN作為一個標準的價值，以及BPMN未來發展的遠景。
1.3. BPEL
Business Process Execution Language，意為業務過程執行語言，是一種基於XML的，用來描寫業務過程的程式語言，被描寫的業務過程的每個單一步驟則由Web服務來實現。
XML Process Definition Language,是由Workflow Management Coalition（簡寫為：WfMC）所提出的一個標準化規格，使用XML檔案讓不同的工作流程軟體能夠交換商業流程定義。XPDL被設計為圖形上和語義上都滿足交換用的商業流程定義，是描述BPMN圖的最佳檔案格式。BPEL也可以描述商業流程。但是XPDL不僅包含流程執行的描述，還包括了元素的圖形資訊，更適於商業流程建模。
1.5. JPDL
JBoss jBPM Process Definition Language，是構建於jBPM框架上的流程語言之一。在jPDL中提供了任務（tasks）、待處理狀態 （wait states）、計時器（timers）、自動處理（automated actions）等術語，並通過圖型化的流程定義，很直觀地描述業務流程。
1.6. PVM
Process Virtual Machine，流程虛擬機器，他的設計初衷是通過實現介面和定製外掛等方式相容多種流程定義語言和流程活動場景，為所有的業務流程定義提供一套通用API平臺。那麼，無論是需要對jBPM 原有流程定義語言進行擴充套件，或者重新實現一套專用的流程定義語言，都可以通過實現 PVM 指定的介面規範完成。
1.7. DMN
Decision Model and Notation，DMN的目的是提供一個模型決策結構，從而使組織的策略可以用圖形清晰的地描繪出來，通過業務分析準確的定義，使其自動化（可選地）。
1.8. CMMN
Case Management Model and Notation，CMMN是一種圖形化的符號，用於捕獲工作方法，這些工作方法基於處理需要各種活動的情況，這些活動可能以不可預測的順序執行，以響應不斷變化的情況。通過使用以事件為中心的方法和案例檔案的概念，CMMN擴充套件了可以用BPMN建模的邊界，包括結構化程度較低的工作和由知識工人驅動的工作。結合使用BPMN和CMMN，使用者可以涵蓋更廣泛的工作方法。
2. 眾多工作流
2.1. JBPM（Java Business Process Management）
由JBoss公司開發，目前最高版本JPBM7，不過從JBPM5開始已經跟之前不是同一個產品了，JBPM5的程式碼基礎不是JBPM4，而是從Drools Flow重新開始。下面要涉及的很多產品都是以JBPM4的程式碼為起點進行開發的。
2.2. Activiti
Alfresco軟體開發，基於JBPM4，後併入OMG，目前最高版本activiti 7。Activiti5版本的時候，核心團隊發生了比較大的變動（離職），activiti6的開發團隊在新版本中去除了PVM，納入了DMN，重構XML解析，BUG較多，目前主要團隊致力於activiti7,5&6已經官宣不維護。
2.3. Osworkflow
完全用java語言編寫的開放原始碼的工作流引擎，具有顯著的靈活性及完全面向有技術背景的使用者的特點。由opensymphony組織維護，其不遵守XPDL等業務規範，完全使用XML編排業務。面向開發人員。
2.4. Shark
靠山是Enhydra。是一個可擴充套件的工作流引擎框架，它包括一個完全基於 WFMC 規範的標準實現，它使用XPDL（沒有任何自己新的擴充套件）作為自身的工作流流程定義格式。其持久層和設計器都是自己公司研發的，持久層實現採用的標準是輕量級的Enhydra DODS O/R mapping 工具，設計器可以用Enhydra JaWE 圖形XPDL編輯器。
2.5. Apache ODE
輕型的、可嵌入的元件，利用元件組裝成一個完整的BPM系統。關鍵模組包括ODE BPEL編譯器、ODE BPEL執行時、ODE資料訪問物件（DAOs）、ODE整合層（ILs）和使用者工具。雖然掛在Apache下面，但已經年久失修。
2.6. Flowable
基於activiti6，最新的開源版本是flowable6，開發團隊是從activiti中分裂出來的，修復了一眾activiti6的bug，並在其基礎上研發了DMN支援，BPEL支援等等。相對開源版，其商業版的功能會更強大。
2.7. Camunda
基於activiti5，所以其保留了PVM，最新版本Camunda7，開發團隊也是從activiti中分裂出來的，發展軌跡與flowable相似，同時也提供了商業版。
2.8. JFlow
前身ccFlow，國產的工作流引擎，由濟南馳騁公司開發維護，主打中國式的業務流程，由於是國產的軟體，中文化程度比較深，業務開發也對使用者比較友好。國產的開源工作流引擎還是挺多的，JFlow是其中功能比較完善的一個，同時對比activiti，流程上更加中國化，支援自定義流程跳轉，加簽等。其他國產工作流就不列舉了。
還有很多工作流，比如ProcessMaker，SWF，oracle，Bonita，openwebflow，snaker
等，不過做BPM的話，相對於上面列舉的產品還是有些缺陷，比如流程過於簡單，資料過少等。
3. 關於工作流標準
BPMN是聽得比較多的工作流標準，但工作流的規範其實不止一種，還有XPDL，BPML等。甚至他們的出現時間比BPMN更早，只是因為一些技術和非技術原因，BPMN2.0被普遍使用了，而非BMPN2.0規範的廠商也逐漸轉移了。
以下的內容是關於規範標準之爭中，BPMN2.0如何從眾多規範中戰勝並被普遍使用的。
3.1. BPMN1.X
在BPMN1.X裡，BPMN是Business Process Modeling Notation的縮寫，即業務流程建模符號，而在BPMN2.0裡，BPMN變成了Business Process Model And Notation的縮寫，即業務流程模型和符號，一個單詞的增加卻標示著BPMN本身發生了巨大的變化。
檢視如下圖1 timeline:
圖1
其中BPMN1.0在2004年5月由BPMI組織正式釋出。這個階段WSFL和BPEL-WS都已經被髮布。這三種規範中，BPMN1.0僅僅作為業務流程建模的一系列符號標準，對業務比較友好。廠商們認為統一的建模標準能夠使他們圍繞核心建模工具提供其他更多的價值，更加願意接受BPMN。
但BPMN1.x只是一些建模符號，不支援元模型，不支援儲存和交換，也不支援執行。2008年，BPMN1.1釋出，但仍然存在這些對開發人員並不友好的缺點，XPDL、BPEL和BPDM圍繞著BPMN1.x的儲存、交換和執行，產生了新的競爭。
XPDL作為WfMC提出的流程定義語言規範，本身就是一個元模型，可以儲存，並且具備執行語義，因此理論上來講，將BPMN轉換為XPDL就可以解決儲存、交換和執行的問題。XPDL2.0於2005年10月釋出，在規範裡，WfMC直接將XPDL的目標定義為BPMN的XML序列化格式。2008年4月23日釋出的XPDL2.1規範，直接支援BPMN1.1到XPDL2.1的轉換。XPDL是面向圖的，BPMN也是面向圖的，因此BPMN到XPDL的轉換有著天然的優勢。如今有超過80個的不同公司的產品使用XPDL來交換流程定義，同時也有一些廠商在自己提供的BPMN工具中使用了XPDL作為交換和儲存格式。
BPEL-WS規範在2003年4月提交給了OASIS（Organizationfor the Advancement of Structured Information Standards，結構化資訊標準促進組織）並更名為WSBPEL（Web Services Business Process Execution Language）規範， 2007年4月釋出WSBPEL2.0版本，除了Microsoft、 BEA、 IBM、 SAP 和Siebel，Sun Microsystems和甲骨文公司也相繼加入了OASIS組織。除去政治因素，BPEL的流行還在於Web正成為分散式系統架構的平臺以及SOA的雄起，SOA強調服務的分解和解耦，而BPEL則對這些WEB服務進行編制，兩者密不可分。但BPMN到BPEL的轉換存在著先天上的缺陷，原因是BPMN是基於圖的，而BPEL是基於塊的，BPEL是一個結構化（塊[Block]）和非結構化（控制鏈和事件）的混合體。這個缺陷導致有些BPMN建模的流程無法對映到BPEL，兩者的雙向工程更是存在問題。這個缺陷成為人們反覆詬病的物件。許多支援BPEL的產品為了解決這一問題，不得不在使用者建模時做出種種限制，讓使用者繪製不出無法轉換的模型。
而BPDM（業務流程定義元模型，Business Process Definition Metamodel）則是OMG組織自己提出來解決BPMN儲存和交換問題的規範。於2007年7月形成初稿，2008年7月被OMG最終採用。BPDM是一個標準的概念定義，用來表達業務流程模型。元模型定義了用來交換的概念，關係和場景，可以使得不同的建模工具所建模出來的流程模型進行交換。BPDM超越了BPMN和BPEL所定義的業務流程建模的要素，它定義了編排和編制。
3.2. BPMN2.0
隨後，BPMN2.0釋出了。看圖2 timeline
圖2
BPMN2.0 beta1版本於2009年8月釋出，BPMN2.0 beta2版本於2010年5月釋出，BPMN2.0正式版本於2011年1月3日釋出。BPMN2.0正式將自己更名為Business Process Model And Notation（業務流程模型和符號），相比BPMN1.x，最重要的變化在於其定義了流程的元模型和執行語義，即它自己解決了儲存、交換和執行的問題，BPMN由單純的業務建模重新迴歸了它的本源，即作為一個對業務人員友好的標準流程執行語言的圖形化前端。BPMN2.0一出手，競爭就結束了，XPDL、BPEL和BPDM各自準備回家釣魚。
BPMN2.0是最被廣泛使用的標準，也是當前熱門產品使用的標準，詳情請看整理的表1：
|
工作流框架 |
遵循規範 |
備註 |
|
Bonita BPM |
XPDL |
流程過於簡單 |
|
Shark |
XPDL |
不維護-2017 |
|
Osworkflow |
自定義XML規範 |
不維護 |
|
JBPM |
BPMN2.0 |
JBPM4.3後新增了對BPMN的支援，持續開源 |
|
Apache ODE |
WS-BPEL、BPEL4WS |
不維護 |
|
Activiti |
BPMN2.0，XPDL，JPDL |
Activiti7維護 |
|
Flowable |
BPMN2.0，XPDL，JPDL |
持續開源 |
|
JFlow |
BPMN2.0，Ccbpm |
2015年後為了與國際接軌，開發支援BPMN |
|
Camunda |
BPMN2.0，XPDL，JPDL |
持續開源 |
表1
這個表格可以對一些工作流產品有一個初步印象。
4. 分表對比
4.1. 對比須知
為了方便檢視彙總表格，有必要再深入展示幾個開篇提到的概念：
PVM
PVM是在JBPM4的時候被納入的，activiti5沿用，activiti團隊在activiti6就已經移除了，ActivitiImpl, ProcessDefinitionImpl, ExecutionImpl, TransitionImpl 都不可用了。所有的流程定義有關的資訊都可以通過BpmnModel來獲得，通過org.activiti.engine.impl.util.ProcessDefinitionUtil來拿到BpmnModel。
工作流中，由於flowable是基於activiti6開發的，所以程式碼中也沒有PVM，Camunda基於activiti5開發的，所以PVM還在，更改這個核心引擎沒有絕對的好壞之分，但是由於我們的程式碼是基於activiti5開發的，所以對我們的程式碼移植是有影響的。
DMN
BPMN是OMG公司釋出的工作流規範，而DMN同樣是OMG公司釋出規範，該規範主要用於定義業務決策的模型和圖形，1.0版本釋出於2015年，目前最新的是1.1版本，釋出於2016年。
BPMN主要用於規範業務流程，業務決策的邏輯由PMML等規範來定義，例如在某些業務流程中，需要由多個決策來決定流程走向，而每個決策都要根據自身的規則來決定，並且每個決策之間可能存在關聯，此時在BPMN與PMML之間出現了空白，DMN規範出現前，決策者無法參與到業務中。為了填補模型上的空白，新增了DMN規範，定義決策的規範以及圖形，DMN規範相當於業務流程模型與決策邏輯模型之間的橋樑。
圖3圖解：
圖3
雖然DMN只作為工作流與決策邏輯的橋樑，但實際上，規範中也包含決策邏輯部分，同時也相容PMML規範所定義的表示式語言。換言之，實現DMN規範的框架，同時也會具有業務規則的處理能力。
CMMN
CMMN具有與BPMN不同的基本範例。 CMMN沒有順序的流程。相反，它以某種狀態對案例建模。根據狀態，視情況而定，有些事情可能會處理，而有些事情可能不會。控制主要由人來執行。 CMMN是宣告性的，該模型說明了要應用的內容，但沒有說明如何實現它。相反，BPMN強制性地規定了流程中某些步驟必須進行的工作。對於大多數人而言，宣告性建模更為複雜且較不直觀。結果，CMMN模型更加難以理解。您不能簡單地用手指追蹤路徑！
CMMN對可能的活動和活動限制進行建模。它對活動何時發生，何時必須發生以及何時不應該發生進行建模。 CMMN同樣限制了流程中人員可以使用的操作範圍。事例模型必須事先經過仔細考慮。重要的是要提出這一點，以應對人們經常誤解的事實，即人們在案件管理方面可以做他們想做的任何事情。
CMMN和BPMN都描述了業務流程中的活動。這些標準之間的主要區別是：
1、BPMN採用繫結方法。 它提供了活動的確切順序。提供自由度比較困難。比如加個節點、任意跳轉就很麻煩。
2、CMMN採用非約束性方法，然後增加了限制。建立排序比較困難。
換句話說，原則上您可以用任何一種表示法表達大多數問題。但是，根據問題的型別，建模將在BPMN或CMMN中更好地工作，並且這些標準之一更可能產生整潔有效的模型。
使用CMMN的指標包括：
1、無需序列：如果序列無關緊要，並且可以按任何順序執行任務，則這將在BPMN中產生過多的連線-臨時建模。也許使用臨時子流程可以避免混亂。
2、活動取決於條件：定義條件是CMMN的強項。可以定義許多工，但是它們只能在某些情況下起作用。例如，這種情況可能是訂單超過一定數量或客戶具有VIP身份；其他已完成的任務也會影響條件。可選因素和資料相關因素的這種組合不能在BPMN中反映出來。
3、專用計劃階段：由於能夠處理任意任務，CMMN可以適應一個計劃階段，在該階段中，一個工人計劃一個案例並啟用任務。 其他工人將不得不遵守計劃。 BPMN不能做任何事情。
包括BPMN標準，這三個標準都是由OMG提出的。多數機構認為DMN和CMMN是工作流發展趨勢。
4.2. 對比表格
經過第二個章節的比較，我從支援的標準和社群活躍度表現比較好的工作流中篩選出幾個選項進行進一步對比，如表2：
|
|
Activiti 7 |
Flowable 6 |
Camunda bpm |
JBPM 7 |
JFLOW(國產的) |
|
功能 |
|||||
|
會籤 |
√ |
√ |
√ |
√ |
√ |
|
回退 |
× |
√ |
√ |
- |
√ |
|
駁回 |
× |
√ |
√ |
√ |
√ |
|
自定義流轉 |
× |
× |
√ |
- |
√ |
|
加簽、減籤 |
× |
√ |
√ |
- |
√ |
|
多例項 |
√ |
√ |
√ |
√ |
√ |
|
事務子流程 |
√ |
√ |
√ |
√ |
√ |
|
版本遷移 |
× |
× |
√ |
× |
× |
|
相容性及二次開發 |
|||||
|
支援的流程格式 |
BPMN2.0、XPDL、PDL |
BPMN2.0、XPDL、XPDL |
BPMN2.0、XPDL、XPDL |
BPMN2.0 |
BPMN2.0 |
|
開源情況 |
開源 |
提供商業和開源版 |
提供商業和開源版 |
開源 |
開源 |
|
開發基礎 |
jBPM4 |
Activiti 5 & 6 |
Activiti 5 |
版本5之後Drools Flow |
自開發 |
|
直接支援的指令碼 |
JUEL、groovy |
JUEL、groovy |
python、ruby、groovy、JUEL |
- |
- |
|
引擎核心（跟程式碼相容有關） |
去除PVM |
去除PVM |
流程虛擬機器（PVM）（遷移上有優勢） |
Drools |
自研 |
|
Spring結合 |
√ |
√ |
√ |
√ |
√ |
|
二次開發難度 |
一般 |
一般 |
一般 |
較難 |
一般 |
|
未來擴充 |
|||||
|
CMMN支援 |
× |
√ |
√ |
× |
× |
|
DMN支援 |
√ |
√（6.4之前不穩定） |
√ |
√ |
× |
|
歷史資料處理（NoSql） |
× |
√ |
√（只提供瞭解決方案） |
- |
× |
|
支援資料庫 |
Oracle、SQL Server、MySQL |
Oracle、SQL Server、MySQL、postgre |
Oracle、SQL Server、MySQL、postgre |
Mysql，postgre |
oracle,sqlserver,mysql |
|
叢集部署 |
√ |
√ |
√ |
√ |
|
|
雲部署 |
√ |
- |
√ |
- |
√ |
|
其他特性 |
|||||
|
持久化框架 |
Mybatis |
JPA二次封裝 |
Hibernate |
JPA |
- |
|
架構 |
spring boot 2 |
spring boot 1.5 |
spring boot 2 |
Kie |
spring boot 2(特別版本) |
|
事務管理 |
MyBatis機制/Spring事務控制 |
hibernate機制/Spring事務控制 |
hibernate機制/Spring事務控制 |
Bitronix，基於JTA事務管理 |
- |
|
分散式事務
|
MyBatis機制/Spring事務控制 |
- |
補償機制，SAGA 模式 |
Bitronix，基於JTA事務管理 |
- |
|
開發手冊 |
https://activiti.gitbook.io/activiti-7-developers-guide/ 部分網頁打不開 |
http://www.shareniu.com/flowable6.5_zh_document/bpm/index.html |
https://docs.jboss.org/jbpm/release/7.40.0.Final/jbpm-docs/html_single/ |
||
|
執行模式 |
獨立執行和內嵌 |
- |
獨立執行和內嵌 |
- |
獨立執行和內嵌 |
|
原始碼活躍度 |
相對活躍 |
相對活躍 |
比較活躍 |
相對活躍 |
一般 |
|
原始碼地址 |
|||||
|
設計器 |
整合idea eclipse，web |
自提供，eclipse |
自提供，eclipse |
Eclipse |
自提供，.net開發 |
|
整合介面 |
SOAP、Mule、RESTful |
SOAP、Mule、RESTful |
SOAP、Mule、RESTful |
訊息通訊 |
SOAP、Mule、RESTful |
|
內部服務通訊 |
Service間通過API呼叫 |
Service間通過API呼叫 |
Service間通過API呼叫 |
基於Apache Mina非同步通訊
|
- |
表2
特別說明：
1. 原始碼活躍度：從分支數，提交數，參與者，最近提交時間等判斷
2. Drools Flow (process/workflow)：該工作流引擎是Drools下的一個專案，JBPM的規則引擎正是Drools，由於activiti開發自JBPM4，所以activiti，flowable以及Camunda都有Drools的影子。
3. 空白處或者小短杆表示的代表的暫時未查證的內容
4. 另外要說明的是，表格中支援的功能需要有不少部分需要認真探討，比如Camunda宣稱支援各種功能，以及Nosql儲存，但實際上，其支援的回退，撤回都是通過一個跳轉實現的，要打折扣，NoSql也只是提供瞭解決方案，要自己實現噢，後面一篇文章會再提及。
5. 效能
關於工作流效能比較的文章比較少（少得可憐），因為沒有直接的資料能夠對比工作流之間的效能，所以獨立出一章介紹，基本情況：
5.1. 概述
以下內容來自：
http://www.bpm-guide.de/2016/06/12/scientific-performance-benchmark-of-open-source-bpmn-engines/ 《Scientific performance benchmark of open source BPMN engines》
據說是16年的一份科學效能報告，可惜效能報告中，除了Camunda外，其他兩種被對比的WFMS產品名稱並沒有寫出來，所以這個報告只能作為參考：
“In general, we may conclude that Camunda performed better and more stable for all metrics when compared with WfMS A and WfMS B.”
“WfMS A and Camunda share many architectural similarities because Camunda was originally a fork of WfMS A.” 暗指WfMS A是activiti。
為了得到更多的效能資料，接下來從各個官網尋找材料。
5.2. Camunda
https://camunda.com/products/performance/
該地址沒有描述具體的效能，但是列舉了一些措施，表示做了效能考慮：
1. 緊湊型表：減少必要的儲存資料，在最好的例子中，修改一個活動只需要更新一條資料
2. 避免死鎖：採用樂觀鎖；使用者思考期間不持有鎖；批量重新整理資料
3. 控制儲存點：在一個事務中儲存多個活動
4. 智慧快取：使用一級快取，減少查詢
5. 並行：並行任務在資料庫中表現為不同行，實現真正並行
6. 叢集：多節點共用資料庫
7. 最小資源佔用：流程引擎無狀態，每個節點只需要分配少於10M的快取，所以支援大批量任務在節點上執行
8. 分庫：歷史庫和執行庫是分開的，原則上，歷史資料可以轉移到任何大資料產品上
5.3. Flowable
https://flowable.com/open-source/docs/bpmn/ch18-Advanced/#async-executor
這裡沒有特別介紹提升效能的設計，但一些角落有提到，對效能是否提升未知：
1.額外寫了UUID id生成器，解決併發的bug，但其實不一定能提升效能；
2.資料庫的批量插入
3.async executor：非同步執行器，能解決背壓，但是對效能的提升程度未知
5.4. JBPM7
https://jbpm.org/learn/jbpmPerformance.html
這裡也沒有介紹效能的具體情況。但提供了檢測效能的方法，指明瞭不跟任何工作流作對比，言辭謹慎。官網給的例子仍然可以作為參考資料，翻譯如下：
客戶端：jmeter
版本：社群版 7.8
硬體：
Macos 10.14.4
Cpu i7 2.3GHZ
Memory 16GB
Db Postgre
測試內容：三個簡單的流程，我做了簡單的表格繼承他的測試結果；（利用執行1000個例項用時得出TPS）
|
單位：TPS |
單執行緒 |
四執行緒 |
八執行緒 |
|
簡單指令碼任務 |
91 |
240 |
361 |
|
簡單使用者任務 |
16 |
52 |
72 |
|
使用者任務+並行指令碼任務 |
11 |
45 |
70 |
5.5. Activiti 7
https://activiti.gitbook.io/activiti-7-developers-guide/
有提到一些提升查詢效能的地方，但是不明確。
5.6. JFlow
未提及效能
6. 總結
大致總結以下調研的總體感受。Activiti7相對於5和6沒有太多功能上的變化，主要致力於一些輔助功能，對接一些基礎技術。比如雲原生，ELK，spring cloud。分散式的應用或許會對效能有一定的提升。
Flowable的NoSql方案和訊息佇列比較特別，同時對DMN和CMMN的研究也比較多，是個不錯的選擇。
JBPM近年來新的文件少一些，應用和二次開發可能會比較吃力。JFlow功能比較齊全，而且中文化的設計器對開發人也和業務人也都比較友好，但是他的材料基本限於官網，後期不會保障。
Camunda BPM支援的功能比較多，對DMN和CMMN的支援也是推出最早的，效能上看起來也做了比較多的應對，雖然商業版的推出減少了開源版的維護，但仍然是幾個競品中綜合看起來比較符合當前需求的，PVM的保留也會使得遷移比較順滑，具體使用情況還需要進一步嘗試，比較推薦。（如果不是舊產品遷移其實需要更多選擇，框架改革的優化是可以考慮在內的，根據需求選擇）
7. 一些參考網址
https://github.com/qiudaoke/flowable-userguide/blob/master/%E6%A1%86%E6%9E%B6bug%E5%88%97%E8%A1%A8/bug.txt 《Flowable 6.5未修復bug列表》
https://flowable.com/blog/2016/09/decision-model-and-notation-dmn-how-to-start-a-project-2/ 《decision-model-and-notation-dmn-how-to-start-a-project-2》
https://blog.camunda.com/post/2016/10/migrate-from-activiti-to-camunda/ 《How to migrate from Activiti 5.21 to Camunda BPM 7.5》
http://www.bpm-guide.de/2015/09/28/why-bpmn-is-not-enough/ 《Why BPMN is not enough》