Java開源工作流對比

任務

泛指各種事務上所必需執行的流程性工作

循序或平行工作

工作的流動性是一個人接著一個人執行，或同時由多個人分開執行，或是上述兩類工作合并之后的混合型工作

多人

若是單人就可以完成的工作，則不能歸類為流程工作；凡是一件工作必須由兩個人或更多人來協力完成的工作才能稱之為流程工作；

共同目的

多人參與的流程性工作，必須是以完成共同目的為前提；如果一群人是分別針對不同的專案來執行個別的工作，并不算構成一個工作流程；

工作流描述語言

XPDL：WFMC制定的描述業務流程控制流的XML格式規范，格式復雜，與具體語言無關，不靈活

1、XML：流程定義格式簡單，使用靈活

2、基于有限狀態機模型

1、JPdl：JBoss jBPM Processdefinition language，一個商務流程被看作是一個UML狀態圖。

2、基于UML的狀態圖和活動圖來定義流程，已加入JBOSS大家庭，市場前景看好。

是否開源，開源協議

一個可擴展的工作流引擎框架。現在不再開源，用于商業用途

開源的嵌入式工作流引擎 ，它的使用遵循 Apache License

一種基于J2EE的輕量級工作流管理系統，它的使用遵循 Apache License

相關開源項目

Jawe

Osworkflow for .net

支持是否全面

流程定制工具JAWE

1、帶有一個簡陋的流程定制工具，但十分簡陋且常有錯誤 

2、需要專業技術用戶使用

1、Jbpm3的圖形化流程定義嵌入到jbosseclipse IDE

2、流程定制方式更接近用戶的理解

拓展性

體系和功能最為復雜，秉承“模塊化”的思想，比較容易擴展

有良好的擴展性，絕對的靈活（同時也增加了開發者的工作量，需要自己寫一些必要的函數）

最適宜擴展（Jbpm的過程模式支持是比較固定的，但是其對任務的中action擴展是很的靈活）最適宜被商業化應用

持久化

Shark的持久層采用DODS來實現

1、它提供的持久化API：EJB,Hibernate,JDBC等 

2、Osworkflow 可以與Spring集成。

利用hibernate持久化

小結

      Shark是體系和功能最為復雜的代表。它是一款遵循WfMC的XPDL標準開源工作流引擎，并且同時遵循OMG組織的WorkflowManagement Facility規范。XPDL的兩個最重要的概念是Process和Activity。XPDL中的Activity是基于UML1.x中的活動圖的概念。活動圖天生的適于工作流程建模，它相對于狀態圖的一個最大的優點是容易做并發線程的分叉控制，這些并發線程可以同時執行也可以順序執行；它還有一個優點是有泳道的概念，可以控制工作流引擎中的任務的產生。

    在所有開源工作流引擎中，Shark的體系最為完備和復雜。其一直秉承著“模塊化”的思想，所以比較容易擴展。但是自從被Together公司收購后，Shark的商業化色彩已經越來越濃，改稱為Together Workflow Server，并僅以Community Edition的形式提供了部分開源代碼供參考。

     OSWorkflow是最輕量型的代表，也是一款非常靈活和低級別定位的工作流引擎的實現框架。低級別定位的意思是說，它不是定位在解決流程模型對象和運轉場景，而是提供一套可維護調度的機制，供開發人員自主擴展。這個維護流程調度機制OSWorkflow選擇的是基于行為（Action）的FSM理論，所以OSWorkflow更像是一個復雜而靈活的有限狀態調度機。

    Osworkflow有個重要概念是State，State是由step和status聯合表達的，一個State就是一個step中的某個status；而state的轉換由action來驅動，類似狀態圖中的event,因為一個event對應一個action

    OSWorkflow在國內項目應用得較多，很多國內的簡易審批流程項目都是基于其引擎二次開發而來。這主要是由于OSWorkflow是基于Action驅動的，而國內的客戶也很容易接受這樣的操作習慣。但OSWorkflow所依賴的FSM模型對于分支、聚合、子流程的支持度很低，這一點在實施過程中需要注意。

     Jbpm結合應用了狀態圖+活動圖+PetriNet的知識，而且這里的活動圖還是UML2.0版的。UML2.0的活動圖中，節點不叫活動（Activity）而叫動作(action)，活動成了一個高層次的概念，它包含一個動作序列。一個活動圖展現一系列的動作，這些動作組成了活動。Jbpm把action也改名了，稱為state。Jbpm使用的狀態圖的概念有transition/event等。Jbpm來內部實現中還采用了PetriNet的概念，如token,signal等，jBpm對Token的應用很有特色，巧妙地利用Parent-Child Token的機制處理分支、父子流程等復雜應用場景。

    jBpm是最適合擴展的代表，是在所有開源引擎中最適宜被商業化應用的一款。首先其流程建模模型是基于Activity Diagram（活動圖）的，并在引擎構建上融入了FSM和PetriNet思想，所以其內核和根基比較牢固扎實。其次，自從被JBoss收購后，其3.x系列的結構更加趨于微內核，Plug-in思想也更加深入。其同時還提供了對BPEL擴展，存儲支持JBossHibernate實現，集成了JBoss seam，規則引擎準備采用JBossrules，并準備集成JBoss Messaging。這樣，不論從內核和外圍應用，jBpm都具有了強勁的動力。

編寫流程描述文件方式

      BPM是通過圖形化的編輯工具（JBPM自帶的Eclipse插件）來編寫業務流程如開始狀態，結束狀態，以及狀態之間的轉換，之后會自動生成XML文件，但具體每一步相關的細節操作還是要手工配置（如該節點是屬于什么類型節點，相關的函數，要不要較驗）。

      OSWorkFlow則要通過手工寫XML文件來定義流程文件，而且它涉及的標簽元素比較多，其用戶手冊上也建議實施人員不要去修改流程，否則流程很容易破壞。

工作流信息保存方式

      JBPM是將流程信息直接保存到數據庫，可以用任何方式對數據庫的操作，這樣就要引入保存工作流信息的相關表。

      OSWorkFlow是既可以保存在XML文件里，也可以保存在數據庫中，保存在數據庫中時需要配置propertySet.xml文件，比較復雜，而且它不是完全支持hibernate（如引入osuser來作權限分析時），此時要自定義操作數據庫的方式。

與系統集成

      JBPM集成比較容易，加入Spring支持包spring-modules-jbpm31.jar,該包加入了Spring對JBPM的包裝，所有的集成都是在此包基礎之上。之后還要配置sessionFactoryForJbpm ,jbpmConfiguration,jbpmTemplate, jbpmDao。

      OSWorkFlow跟Spring集成須要如下所需組件：

    1)SpringHibernateWorkflowStore，讓工作流程實例(如果需要的話)分享當前事務。      2) SpringTypeResolver，允許 OSWorkflow 從 Spring ApplicationContext中獲得業務邏輯組件(conditions, functions等等)。      3)SpringConfiguration， 這是一個 Workflow Configuration 接口的實現類， 它包含指向 store和 factory的引用，這樣可以在 spring 中注射或者連接。      4) SpringWorkflowFactory，這是一個 XMLWorkflowFactory 封裝包，它可以允許從容器中注入 configuration，從而不再從其它的 XML 配置文件中讀取它們。

    如果OSWorkFlow引入osuser.xml來設置權限，則不支持Hibernate3，因為osuser是比較獨立的模塊，目前還沒有支持hibernate3，所以跟Spring集成時要修改配置文件applicationContext-hibernate3.xml

重點難點

      JPDL語言的學習，主要是用來編寫流程文件；理解3個接口:動作處理接口(提供影響流程執行的方法，在event和action元素中被回調)，判定處理接口（用在decision判定節點中，提供方法來判定節點的轉向），委派處理接口（用在task的委派子元素assignment中，用來指定將任務分配給指定的人員或角色）。

      工作流文件定義的元素，主要用來編寫工作流；OSWorkFlow.xml及propertySet.xml文件的配置；InputMap接口、Workflow 接口及WorkflowDescriptor接口。

開發步驟

      通過圖形編輯工具編寫業務流程――>生成xml流程文件――>修改流程文件（判斷節點是任務節點、普通節點還是判定節點,之后作相應修改）――>導入保存流程信息的數據庫表――>部署流程定義文件（將流程文件中的內容放到數據庫中）――>創建流程實例――>調用JBPM提供的signal方法執行流程流轉

      手工編寫工作流文件——>配置OSWorkflow.xml――>配置WorkStore——>配置propertySet.xml,osUser.xml文件（如果需要用戶權限）――>調用AbatractWorkflow類加載OSWorkflow.xml(它會自動加載工作流文件及數據庫配置文件)――>調用WorkFlow接口方法(initial()方法,transitionWorkflow（）方法，doAction（）方法)

流轉方法

      先確定節點是什么節點，如果是普通的Node節點，則是流程執行到此節點不會中斷，繼續執行；如果是state節點，則流程執行到此節點會中斷，直到系統外的參與者發會命令才能繼續執行，即調用signal（）或end（）方法；如果節點是Task-node，則會根據task任務列表的任務有沒全部執行完來決定流轉。

      一個工作流包含多個步驟。每一個步驟都有一個當前狀態(例如, Queued, Underway, or Finished)。每一個步驟中都有一個或者多個動作可以被執行。每一個動作都可以設置執行條件(condition)，也可以設置執行函數(pre-function or post-function)。動作產生結果(result)，導致工作流的狀態和當前步驟發生改變

流程定義文件主要元素

      一個JBPM的流程定義XML文件中包含一個< process-definition>元素，而一個< process-definition>元素又包含零個或一個< description>元素，零個或多個的< swimlane>元素，一個< start-state>元素，零個或多個的< state>元素或< decision>元素或< fork>元素或< join>元素，以及零個或多個的< action>元素，零個或多個<task-node>和<node>元素，一個< end-state>元素等等。此外，< process definition>元素有一個標示符，以“name”屬性來表示，這個屬性必須存在，用來表示該流程的名稱。

步驟（step）、條件（conditions）、循環（loops）、分支（spilts）、合并（joins）、角色（roles）、函數（function）

其他

      JBPM的Scheduler可以實現在JBPM流程中定時觸發某一動作。在流程中JPBM提供了timer節點供我們使用，通過這個節點我們可以實現節點動作的定時觸發。

相似之處

1、都是BPMN2過程建模和執行環境。

2、都是BPM系統（符合BPM規范）。

3、都是開源項目-遵循ASL協議（ Apache的 軟件許可）。

4、都源自JBoss（Activiti5是jBPM4的衍生，jBPM5則基于Drools Flow）。 

5、都很成熟，從無到有，雙方開始約始于2年半前。 都有對人工任務的生命周期管理。 

6、Activiti5和jBPM5唯一的區別是jBPM5基于WebService - HumanTask標準來描述人工任務和管理生命周期。 如有興趣了解這方面的標準及其優點，可參閱WS - HT規范介紹 。

7、 都使用了不同風格的 Oryx 流程編輯器對BPMN2建模。 jBPM5采用的是 Intalio 維護的開源項目分支。 Activiti5則使用了Signavio維護的分支。

數據庫持久層ORM

MyBatis3

Hibernate3

持久化標準

無

JPA規范

事務管理

MyBatis機制/Spring事務控制

Bitronix，基于JTA事務管理

數據庫連接方式

Jdbc/DataSource

Jdbc/DataSource

支持數據庫

Oracle、SQL Server、MySQL等多數數據庫

Oracle、SQL Server、MySQL等多數數據庫

設計模式

Command模式、觀察者模式等

內部服務通訊

Service間通過API調用

基于Apache Mina異步通訊

集成接口

SOAP、Mule、RESTful

消息通訊

支持的流程格式

BPMN2、xPDL、jPDL等

目前僅只支持BPMN2 xml

引擎核心

PVM（流程虛擬機）

Drools

技術前身

jBPM3、jBPM4

Drools Flow

所屬公司

Alfresco

jBoss.org

集成

      Activiti5使用Spring進行引擎配置以及各個Bean的管理，綜合使用IoC和AOP技術，使用CXF作為Web Services實現的基礎，使用MyBatis進行底層數據庫ORM的管理，預先提供Bundle化包能較容易的與OSGi進行集成，通過與Mule ESB的集成和對外部服務（Web Service、RESTful等）的接口可以構建全面的SOA應用；

      jBPM5使用jBoss.org社區的大多數組件，以Drools Flow為核心組件作為流程引擎的核心構成，以Hibernate作為數據持久化ORM實現，采用基于JPA/JTA的可插拔的持久化和事務控制規范，使用Guvnor作為流程管理倉庫，能夠與Seam、Spring、OSGi等集成。

優劣對比

      從技術組成來看，Activiti最大的優勢是采用了PVM（流程虛擬機），支持除了BPMN2.0規范之外的流程格式，與外部服務有良好的集成能力，延續了jBPM3、jBPM4良好的社區支持，服務接口清晰，鏈式API更為優雅；Activiti上手比較快，界面也比較簡潔、直觀

      劣勢是持久化層沒有遵循JPA規范。

      jBPM最大的優勢是采用了Apache Mina異步通信技術，采用JPA/JTA持久化方面的標準，以功能齊全的Guvnor作為流程倉庫，有RedHat(jBoss.org被紅帽收購)的專業化支持；

      但其劣勢也很明顯，對自身技術依賴過緊且目前僅支持BPMN2。