任務(wù)

泛指各種事務(wù)上所必需執(zhí)行的流程性工作

循序或平行工作

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

多人

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

共同目的

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

工作流描述語言

XPDL：WFMC制定的描述業(yè)務(wù)流程控制流的XML格式規(guī)范，格式復(fù)雜，與具體語言無關(guān)，不靈活

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

2、基于有限狀態(tài)機模型

1、JPdl：JBoss jBPM Processdefinition language，一個商務(wù)流程被看作是一個UML狀態(tài)圖。

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

是否開源，開源協(xié)議

一個可擴展的工作流引擎框架?，F(xiàn)在不再開源，用于商業(yè)用途

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

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

相關(guān)開源項目

Jawe

Osworkflow for .net

支持是否全面

流程定制工具JAWE

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

2、需要專業(yè)技術(shù)用戶使用

1、Jbpm3的圖形化流程定義嵌入到j(luò)bosseclipse IDE

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

拓展性

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

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

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

持久化

Shark的持久層采用DODS來實現(xiàn)

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

2、Osworkflow 可以與Spring集成。

利用hibernate持久化

小結(jié)

      Shark是體系和功能最為復(fù)雜的代表。它是一款遵循WfMC的XPDL標(biāo)準(zhǔn)開源工作流引擎，并且同時遵循OMG組織的WorkflowManagement Facility規(guī)范。XPDL的兩個最重要的概念是Process和Activity。XPDL中的Activity是基于UML1.x中的活動圖的概念?；顒訄D天生的適于工作流程建模，它相對于狀態(tài)圖的一個最大的優(yōu)點是容易做并發(fā)線程的分叉控制，這些并發(fā)線程可以同時執(zhí)行也可以順序執(zhí)行；它還有一個優(yōu)點是有泳道的概念，可以控制工作流引擎中的任務(wù)的產(chǎn)生。

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

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

    Osworkflow有個重要概念是State，State是由step和status聯(lián)合表達的，一個State就是一個step中的某個status；而state的轉(zhuǎn)換由action來驅(qū)動，類似狀態(tài)圖中的event,因為一個event對應(yīng)一個action

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

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

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

編寫流程描述文件方式

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

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

工作流信息保存方式

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

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

與系統(tǒng)集成

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

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

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

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

重點難點

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

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

開發(fā)步驟

      通過圖形編輯工具編寫業(yè)務(wù)流程――>生成xml流程文件――>修改流程文件（判斷節(jié)點是任務(wù)節(jié)點、普通節(jié)點還是判定節(jié)點,之后作相應(yīng)修改）――>導(dǎo)入保存流程信息的數(shù)據(jù)庫表――>部署流程定義文件（將流程文件中的內(nèi)容放到數(shù)據(jù)庫中）――>創(chuàng)建流程實例――>調(diào)用JBPM提供的signal方法執(zhí)行流程流轉(zhuǎn)

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

流轉(zhuǎn)方法

      先確定節(jié)點是什么節(jié)點，如果是普通的Node節(jié)點，則是流程執(zhí)行到此節(jié)點不會中斷，繼續(xù)執(zhí)行；如果是state節(jié)點，則流程執(zhí)行到此節(jié)點會中斷，直到系統(tǒng)外的參與者發(fā)會命令才能繼續(xù)執(zhí)行，即調(diào)用signal（）或end（）方法；如果節(jié)點是Task-node，則會根據(jù)task任務(wù)列表的任務(wù)有沒全部執(zhí)行完來決定流轉(zhuǎn)。

      一個工作流包含多個步驟。每一個步驟都有一個當(dāng)前狀態(tài)(例如, Queued, Underway, or Finished)。每一個步驟中都有一個或者多個動作可以被執(zhí)行。每一個動作都可以設(shè)置執(zhí)行條件(condition)，也可以設(shè)置執(zhí)行函數(shù)(pre-function or post-function)。動作產(chǎn)生結(jié)果(result)，導(dǎo)致工作流的狀態(tài)和當(dāng)前步驟發(fā)生改變

流程定義文件主要元素

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

步驟（step）、條件（conditions）、循環(huán)（loops）、分支（spilts）、合并（joins）、角色（roles）、函數(shù)（function）

其他

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

相似之處

1、都是BPMN2過程建模和執(zhí)行環(huán)境。

2、都是BPM系統(tǒng)（符合BPM規(guī)范）。

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

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

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

6、Activiti5和jBPM5唯一的區(qū)別是jBPM5基于WebService - HumanTask標(biāo)準(zhǔn)來描述人工任務(wù)和管理生命周期。 如有興趣了解這方面的標(biāo)準(zhǔn)及其優(yōu)點，可參閱WS - HT規(guī)范介紹 。

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

數(shù)據(jù)庫持久層ORM

MyBatis3

Hibernate3

持久化標(biāo)準(zhǔn)

無

JPA規(guī)范

事務(wù)管理

MyBatis機制/Spring事務(wù)控制

Bitronix，基于JTA事務(wù)管理

數(shù)據(jù)庫連接方式

Jdbc/DataSource

Jdbc/DataSource

支持?jǐn)?shù)據(jù)庫

Oracle、SQL Server、MySQL等多數(shù)數(shù)據(jù)庫

Oracle、SQL Server、MySQL等多數(shù)數(shù)據(jù)庫

設(shè)計模式

Command模式、觀察者模式等

內(nèi)部服務(wù)通訊

Service間通過API調(diào)用

基于Apache Mina異步通訊

集成接口

SOAP、Mule、RESTful

消息通訊

支持的流程格式

BPMN2、xPDL、jPDL等

目前僅只支持BPMN2 xml

引擎核心

PVM（流程虛擬機）

Drools

技術(shù)前身

jBPM3、jBPM4

Drools Flow

所屬公司

Alfresco

jBoss.org

集成

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

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

優(yōu)劣對比

      從技術(shù)組成來看，Activiti最大的優(yōu)勢是采用了PVM（流程虛擬機），支持除了BPMN2.0規(guī)范之外的流程格式，與外部服務(wù)有良好的集成能力，延續(xù)了jBPM3、jBPM4良好的社區(qū)支持，服務(wù)接口清晰，鏈?zhǔn)紸PI更為優(yōu)雅；Activiti上手比較快，界面也比較簡潔、直觀

      劣勢是持久化層沒有遵循JPA規(guī)范。

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

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