從本篇文章我們開始介紹工作流框架activiti的相關知識,不過在介紹activiti的知識之前,我們很有必要對工作流的一些基本概念進行了解。
Workflow(工作流)是“業務過程的部分或整體在計算機應用環境下的自動化,是對工作流程及其各操作步驟之間業務規則的抽象、概括描述”,它主要解決的是“使在多個參與者之間按照一種提前定義好的規則流程來傳遞與執行文檔、信息或任務的過程,讓這個過程可以自動進行或者部分自動執行,從而完成預期的業務目標”。
提到工作流就不能不提到工作流管理聯盟(WfMC,WorkflowManagementCoalition),它是一個由涉及工作流和業務流程管理的推廣學者(adopters)、開發工程師、顧問、分析師、大學和研究團體的全球性組織,它的成立,標志著工作流技術開始進入相對成熟的階段。該組織創建并完善了工作流管理系統的相關術語、體系結構及應用編程接口等方面制定了一系列標準,是唯一的致力于工作流標準的專業組織。
接下來要說的是工作流管理系統(WorkflowManagement System,WfMS),它完成了工作量的定義和管理,并按照在系統中預先定義好的工作流規則進行工作流實例的執行的軟件系統,這里要說明一下的是,并不是我們企業自己的系統應用了工作流就是工作流管理系統了,工作流管理系統不是企業的業務系統,而是為企業的業務系統的運行提供了一個軟件的支撐環境。WfMS被用來定義、管理和執行工作流程,它的目標是管理工作的流程以確保工作在正確的時間被期望的人員所執行。同時也可以在自動化進行的業務過程中插入人工的執行和干預。
WfMS我一般習慣于稱它為工作流框架,常見的工作流框Activiti、JBPM、OSWorkflow、ActiveBPEL、YAWL等。
個人覺得直接理解工作流引擎概念有點難度,我們可以先通過了解工作流引擎的職責再反過來理解工作流引擎,工作流引擎一般都做兩件事情:
1.定義流程,也就是給我們提供某種規范來定義規則,以及如何定義一個流程的這種規范,同事我們可以根據工作流引擎提供的相關概念來定義更為復雜的流程,這就是工作流引擎做的第一件事叫做定義流程。
2.執行流程,也就是工作流引擎需要解釋這個規則,還要負責流程,它相當于流程的調度者,監控每個流程的執行情況,并將流程操作發往下一步,或者根據條件休眠或終止流程的這么一個過程就叫做執行流程。
了解完工作流引擎的這兩個職責,我相信對于什么是工作流引擎一定已經有了一定的認識了,我們在用一句稍微有點官方的話來總結一下工作流引擎,工作流引擎為我們提供相關規則概念的定義,給我們提供了相關的API來調用這個引擎去執行流程。流程的操作實際上就是工作流引擎提供相關的api我們去調用它。
上面我們提及了常見了幾個工作流框架,其中現在的Activiti和JBPM5.0之前的版本都是基于PRocessEngine 工作流引擎的工作流框架;JBPM5.0開始是基于DroolsFlow為工作流引擎的工作流框架;其中OSWorkflow是以工作流引擎命名的工作流框架,所以OSWorkflow是基于OSWorkflow工作流引擎的工作流框架;ActiveBPEL是基于工作流BPEL引擎的工作流框架…….
到這里關于工作流的相關概念就介紹完了,接下來我們先了解一下我們的主角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 的延續。
jBPM 5則與之前的jBPM3、jBPM 4沒有太大關聯,且舍棄了備受推崇的PVM(流程虛擬機)思想,轉而選擇jBoss自身產品DroolsFlow作為流程引擎的核心實現,工作流最為重要的“人機交互”任務(類似于審批活動)則由單獨的一塊“Human Task Service”附加到DroolsFlow上實現,任務的查詢、處理等行為通過Apache Mina異步通信機制完成。
序號 | 技術組成 | Activiti | jBPM5 |
1 | 數據庫持久層ORM | MyBatis3 | Hibernate3 |
2 | 持久化標準 | 無 | JPA規范 |
3 | 事務管理 | MyBatis機制/spring事務控制 | Bitronix,基于JTA事務管理 |
4 | 數據庫連接方式 | Jdbc/DataSource | Jdbc/DataSource |
5 | 支持數據庫 | Oracle、SQL Server、MySQL等多數數據庫 | |
6 | 設計模式 | Command模式、觀察者模式等 | 無 |
7 | 內部服務通訊 | Service間通過API調用 | 基于Apache Mina異步通訊 |
8 | 集成接口 | SOAP、Mule、RESTful | 消息通訊 |
9 | 支持的流程格式 | BPMN2、xPDL、jPDL等 | 目前僅只支持BPMN2 xml |
10 | 引擎核心 | PVM(流程虛擬機) | Drools |
11 | 技術前身 | jBPM3、jBPM4 | Drools Flow |
12 | 所屬公司 | Alfresco | jBoss.org |
從表格中的比較我們可以看出,Activiti最大的優勢是采用了PVM(流程虛擬機),支持除了BPMN2.0規范之外的流程格式,與外部服務有良好的集成能力,延續了jBPM3、jBPM4良好的社區支持,服務接口清晰,鏈式API更為優雅;劣勢是持久化層沒有遵循JPA規范。
jBPM最大的優勢是采用了ApacheMina異步通信技術,采用JPA/JTA持久化方面的標準,以功能齊全的Guvnor作為流程倉庫,有RedHat(jBoss.org被紅帽收購)的專業化支持;但其劣勢也很明顯,對自身技術依賴過緊且目前僅支持BPMN2。
我們對Activiti和jBPM進行比較目的是為了讓我們可以對他們的特性更加的了解,只有了解了他們的特性以后,這樣當我們遇到具體的項目時就可以根據需要來選用適合的工作流框架。
我們這篇文章主要介紹了工作流相關的基本概念,同時又了解了Activiti的前世今生,最后將Activiti與jBPM進行了比較。
http://blog.csdn.net/zwk626542417/article/details/46592471
新聞熱點
疑難解答