前言

    從本篇文章我們開始介紹工作流框架activiti的相關知識，不過在介紹activiti的知識之前，我們很有必要對工作流的一些基本概念進行了解。

工作流重要概念

Workflow

    Workflow(工作流)是“業務過程的部分或整體在計算機應用環境下的自動化，是對工作流程及其各操作步驟之間業務規則的抽象、概括描述”，它主要解決的是“使在多個參與者之間按照一種提前定義好的規則流程來傳遞與執行文件、資訊或任務的過程，讓這個過程可以自動進行或者部分自動執行，從而完成預期的業務目標”。

WfMC

    提到工作流就不能不提到工作流管理聯盟(WfMC，WorkflowManagementCoalition)，它是一個由涉及工作流和業務流程管理的推廣學者（adopters）、開發工程師、顧問、分析師、大學和研究團體的全球性組織，它的成立，標誌著工作流技術開始進入相對成熟的階段。該組織建立並完善了工作流管理系統的相關術語、體系結構及應用程式設計介面等方面制定了一系列標準，是唯一的致力於工作流標準的專業組織。

WfMS

    接下來要說的是工作流管理系統(WorkflowManagement System,WfMS)，它完成了工作量的定義和管理，並按照在系統中預先定義好的工作流規則進行工作流例項的執行的軟體系統，這裡要說明一下的是，並不是我們企業自己的系統應用了工作流就是工作流管理系統了，工作流管理系統不是企業的業務系統，而是為企業的業務系統的執行提供了一個軟體的支撐環境。WfMS被用來定義、管理和執行工作流程，它的目標是管理工作的流程以確保工作在正確的時間被期望的人員所執行。同時也可以在自動化進行的業務過程中插入人工的執行和干預。

WfMS與工作流框架

    WfMS我一般習慣於稱它為工作流框架，常見的工作流框Activiti、JBPM、OSWorkflow、ActiveBPEL、YAWL等。

工作流引擎

    個人覺得直接理解工作流引擎概念有點難度，我們可以先通過了解工作流引擎的職責再反過來理解工作流引擎，工作流引擎一般都做兩件事情：

    1.定義流程，也就是給我們提供某種規範來定義規則，以及如何定義一個流程的這種規範，同事我們可以根據工作流引擎提供的相關概念來定義更為複雜的流程，這就是工作流引擎做的第一件事叫做定義流程。

    2.執行流程，也就是工作流引擎需要解釋這個規則，還要負責流程，它相當於流程的排程者，監控每個流程的執行情況，並將流程操作發往下一步，或者根據條件休眠或終止流程的這麼一個過程就叫做執行流程。

    瞭解完工作流引擎的這兩個職責，我相信對於什麼是工作流引擎一定已經有了一定的認識了，我們在用一句稍微有點官方的話來總結一下工作流引擎，

工作流框架與工作流引擎

    上面我們提及了常見了幾個工作流框架，其中現在的Activiti和JBPM5.0之前的版本都是基於ProcessEngine 工作流引擎的工作流框架；JBPM5.0開始是基於DroolsFlow為工作流引擎的工作流框架；其中OSWorkflow是以工作流引擎命名的工作流框架，所以OSWorkflow是基於OSWorkflow工作流引擎的工作流框架；ActiveBPEL是基於工作流BPEL引擎的工作流框架…….

    到這裡關於工作流的相關概念就介紹完了，接下來我們先了解一下我們的主角activiti的前世今生。

Activiti前世今生

    Activiti 的創始人是  Tom Baeyens 說到Tom Baeyens 就不能不提他與jbpm的淵源。TomBaeyens 是 jBPM 的創始人，在 2002年，Tom Baeyens建立了基於狀態機原理的jBPM流程引擎。jBPM經過了JBoss和Redhat公司之後，發展到了 jBPM 4。由於jBPM使用的是 GPL開源協議，並且與JBoss和Redhat公司的其他產品線結合的越來越緊密，對jBPM在更廣泛的範圍使用形成了阻礙。JBoss內部對jBPM未來版本的架構實現產生了嚴重的意見分歧，在2005年 Tom Baeyens離開了JBoss公司加入了Alfresco 公司，建立了使用Apache based-license V2的、獨立於Alfresco產品的開源流程產品Activiti 。Activiti在2010年3月份開始啟動，到了2010年12月份正式釋出第一個版本，新的基於jBPM4的開源工作流系統Activiti 5.0  ！所以說Activiti5是在jBPM 3、jBPM 4的基礎上發展而來的，是原jBPM 的延續。

Activiti 與jBPM 5的比較

    jBPM 5則與之前的jBPM3、jBPM 4沒有太大關聯，且捨棄了備受推崇的PVM（流程虛擬機器）思想，轉而選擇jBoss自身產品DroolsFlow作為流程引擎的核心實現，工作流最為重要的“人機互動”任務（類似於審批活動）則由單獨的一塊“Human Task Service”附加到DroolsFlow上實現，任務的查詢、處理等行為通過Apache Mina非同步通訊機制完成。

    從表格中的比較我們可以看出，Activiti最大的優勢是採用了PVM（流程虛擬機器），支援除了BPMN2.0規範之外的流程格式，與外部服務有良好的整合能力，延續了jBPM3、jBPM4良好的社群支援，服務介面清晰，鏈式API更為優雅；劣勢是持久化層沒有遵循JPA規範。

    jBPM最大的優勢是採用了ApacheMina非同步通訊技術，採用JPA/JTA持久化方面的標準，以功能齊全的Guvnor作為流程倉庫，有RedHat(jBoss.org被紅帽收購)的專業化支援；但其劣勢也很明顯，對自身技術依賴過緊且目前僅支援BPMN2。

    我們對Activiti和jBPM進行比較目的是為了讓我們可以對他們的特性更加的瞭解，只有瞭解了他們的特性以後，這樣當我們遇到具體的專案時就可以根據需要來選用適合的工作流框架。

總結

    我們這篇文章主要介紹了工作流相關的基本概念，同時又瞭解了Activiti的前世今生，最後將Activiti與jBPM進行了比較。