盡管jbpm非常強大，是目前最適合商業(yè)化的開源工作流引擎，可以開發(fā)出復(fù)雜的流程，但是特別遺憾的是并不支持并發(fā)子流程（multiple-subprocess）
有一次我需要做一個復(fù)雜的流程，主流程里要求同時啟動多個并發(fā)執(zhí)行的子流程，并且子流程的數(shù)目和啟動的時間都不確定，當(dāng)所有子流程都結(jié)束以后，主流程才繼續(xù)執(zhí)行。我們知道jbpm里有子流程的設(shè)定，有專門的節(jié)點ProcessState來處理，但是后來發(fā)現(xiàn)無論如何也實現(xiàn)不了多子流程并發(fā)執(zhí)行，后來看其源碼知道因為subprocess是作為ProcessState的一個屬性，也就是說ProcessState只能包含一個subprocess的定義，并且最重要的是processInstance.getRootToken()和子流程相關(guān)的只有createSubProcessInstance, getSubProcessInstance, setSubProcessInstance三個方法，這意味著主流程的rootToken只能設(shè)置一個子流程，jbpm并不直接支持多子流程。
那么我們就必須用一個變通的方法來實現(xiàn)，“并發(fā)”很自然的讓我們想到了fork，但是這里的fork不能搭配join來使用，具體原因，將在后面討論。
下面先給出流程圖：

state節(jié)點用來啟動子流程（實際應(yīng)用可以換成Task-Node），state進(jìn)入fork后同時進(jìn)入兩個分支，一條去啟動子流程，另一條回到自己，這樣表面看來state沒有動，而同時你又可以啟動第2個，第3個……子流程，需要注意的是第2條子流程和第1個子流程并不處于同一級上，而比第一個子流程低一級，具體請看后面一張圖就明白了，分解后的：

從圖中我們可以看到后一個子流程的整棵樹是前一個子流程的兄弟，但是在業(yè)務(wù)級上是并發(fā)的效果，已經(jīng)實現(xiàn)我們前面的需求。

現(xiàn)在來說說為什么不能用join而直接用end，因為會產(chǎn)生一個問題，state3和sub process 2都到達(dá)了join以后，state2下面的fork就結(jié)束了，就會立刻越過join到達(dá)end，而sub process 1即使執(zhí)行完畢到達(dá)了join卻仍然在傻傻等待著他的兄弟分支也到達(dá)join（而實際上它已經(jīng)自跑到end去了）一同結(jié)束，這樣sub process 1就會永遠(yuǎn)停在join動彈不得，業(yè)務(wù)無法進(jìn)行。

這是我的一個解決方案，但還有一個問題，雖然全部的子流程都能結(jié)束，主流程也能結(jié)束，但因為沒有join，主流程的rootToken仍然停留在fork節(jié)點上。目前我尚不知如何解決，希望各位大家能提出其他更好的解決辦法。
初學(xué)jbpm，水平有限，有不當(dāng)之處還請高手斧正

最后附上demo代碼供參考：

在某一公司中，部門員工要休假的話需要部門主管的批準(zhǔn)。如果休假天數(shù)大于10天的話，在部門主管的同意后，還必須上級主管批準(zhǔn)。如果是部門主管要休假只要上級主管批準(zhǔn)即可。在休假被批準(zhǔn)之前，申請人可以撤銷休假申請。
每個員工還有多少天休假必須管理起來，在員工提交休假申請時要檢查申請?zhí)鞌?shù)是否超過可用天數(shù)。申請批準(zhǔn)后，要在可用天數(shù)里減去申請?zhí)鞌?shù)。每次休假申請結(jié)束之后，不管通過未通過或是否取消，都必須記錄下來。主管在批復(fù)申請之后，系統(tǒng)要將批復(fù)結(jié)果Email給申請人。對于大于10天的申請，如果部門主管已批準(zhǔn)同意而上級主管還未批準(zhǔn)，這時申請人撤銷申請后，系統(tǒng)應(yīng)發(fā)Email通知部門主管申請已撤銷。 
  processdefinition.xml如下：
<?xml version="1.0" encoding="UTF-8"?>
<!-- edited with XMLSPY v2004 rel. 3 U (http://www.xmlspy.com) by Keller (zju) -->
<!DOCTYPE process-definition PUBLIC
    "-//jBpm/jBpm Mapping DTD 2.0//EN"
    "http://jbpm.org/dtd/processdefinition-2.0.dtd">
<process-definition  name="RequestLeave">
 <swimlane name="requester">
  <description>申請者</description>
 </swimlane>
 <swimlane name="chief">
  <description>部門主管</description>
  <delegation class="kellerdu.jbpm.delegation.ChiefSwimlane"/>
 </swimlane>
 <swimlane name="boss">
  <description>上級主管</description>
  <delegation class="kellerdu.jbpm.delegation.BossSwimlane"/>
 </swimlane>
 <start-state name="request" swimlane="requester">
  <transition to="Begin Request"/>
 </start-state>
 <fork name="Begin Request">
  <transition to="Requester Cancel"/>
  <transition to="IsChief"/>
 </fork>
 <decision name="IsChief">
  <delegation class="kellerdu.jbpm.delegation.ChiefDecision"/>
  <transition name="Boss Approve"  to="Boss Approve"/>
  <transition name="Chief Approve"  to="Chief Approve"/>
 </decision>
 <state name="Requester Cancel">
  <assignment swimlane="requester"/>
  <transition name="cancel" to="Decided">
   <action>
    <!-- 將請假的狀態(tài)改變?yōu)?/span>“取消”-->
    <delegation class="kellerdu.jbpm.action.RequestCancel"/>
   </action>
  </transition>
 </state>
 <state name="Chief Approve">
  <assignment swimlane="chief"/>
  <transition name="approve" to="NeedBossApprove">
   <action>
    <!-- 將請假的狀態(tài)改變?yōu)?/span>“主管批準(zhǔn)”-->
    <delegation class="kellerdu.jbpm.action.ChiefApprove"/>
   </action>
  </transition>
  <transition name="disapprove" to="Decided">
   <action>
    <!-- 將請假的狀態(tài)改變?yōu)?/span>“主管否決”-->
    <delegation class="kellerdu.jbpm.action.ChiefDisapprove"/>
   </action>
  </transition>
 </state>
 <state name="Boss Approve">
  <assignment swimlane="boss"/>
  <transition name="approve" to="Decided">
   <action>
    <!-- 將請假的狀態(tài)改變?yōu)?/span>“老板批準(zhǔn)”-->
    <delegation class="kellerdu.jbpm.action.BossApprove"/>
   </action>
  </transition>
  <transition name="disapprove" to="Decided">
   <action>
    <!-- 將請假的狀態(tài)改變?yōu)?/span>“老板否決”-->
    <delegation class="kellerdu.jbpm.action.BossDisapprove"/>
   </action>
  </transition>
 </state>
 <decision name="NeedBossApprove">
  <!-- 請假天數(shù)大于10天的要老板批準(zhǔn)  -->
  <delegation class="kellerdu.jbpm.delegation.NeedBossApproveDecision"/>
  <transition name="need" to="Boss Approve"/>
  <transition name="notNeed" to="Decided"/>
 </decision>
 <join name="Decided">
  <description>有一個先到達(dá)即進(jìn)行父Token</description>
  <delegation class="kellerdu.jbpm.delegation.DecidedJoin"/>
  <transition to="Do Something"/>
 </join>
 <decision name="Do Something">
  <description>
    根據(jù)請求的狀態(tài)決定。
    （1）“主管或者老板批準(zhǔn)”－‘approve’：修改員工休假的總天數(shù)，設(shè)定發(fā)給用戶E-Mail的信息。
    （2）“主管或者老板否決”-“disapprove”：設(shè)定發(fā)給用戶E－Mail的信息。
    （3）“撤銷”-"cancel"－設(shè)定發(fā)給用戶E－Mail的信息。如果主管批準(zhǔn)，要發(fā)給主管消息說明已經(jīng)撤銷。
    </description>
  <delegation class="kellerdu.jbpm.delegation.DoSomethingDecision"/>
  <transition name="disapprove" to="Finished">
   <action>
    <delegation class="kellerdu.jbpm.action.Disapprove"/>
   </action>
  </transition>
  <transition name="approve" to="Finished">
   <action>
    <delegation class="kellerdu.jbpm.action.Approve"/>
   </action>
  </transition>
  <transition name="cancel" to="Finished">
   <action>
    <delegation class="kellerdu.jbpm.action.Cancel"/>
   </action>
  </transition>
 </decision>
 <end-state name="Finished"/>
 <action event-type="process-end">
  <!-- 發(fā)送E－Mail消息給申請者，記錄請假日志 -->
  <delegation class="kellerdu.jbpm.action.ProcessEndAction"/>
 </action>
</process-definition>
 

jBPM，全稱是Java Business Process Management，是一種基于J2EE的輕量級工作流管理系統(tǒng)。jBPM是公開源代碼項目，它使用要遵循 Apache License。jBPM在2004年10月18日，發(fā)布了2.0版本，并在同一天加入了JBoss，成為了JBoss企業(yè)中間件平臺的一個組成部分，它的名稱也改成JBoss jBPM。隨著jBPM加入JBoss組織，jBPM也將進(jìn)入一個全新的發(fā)展時代，它的前景是十分光明的。

jBPM最大的特色就是它的商務(wù)邏輯定義沒有采用目前的一些規(guī)范，如WfMC´s XPDL, BPML, ebXML, BPEL4WS等，而是采用了它自己定義的Process defiJBoss jBPM nition language (jPdl)。jPdl認(rèn)為一個商務(wù)流程可以被看作是一個UML狀態(tài)圖。jPdl就是詳細(xì)定義了這個狀態(tài)圖的每個部分，如起始、結(jié)束狀態(tài)，狀態(tài)之間的轉(zhuǎn)換等。

jBPM的另一個特色是它使用Hibernate來管理它的數(shù)據(jù)庫。Hibernate是目前Java領(lǐng)域最好的一種數(shù)據(jù)持久層解決方案。通過Hibernate，jBPM將數(shù)據(jù)的管理職能分離出去，自己專注于商務(wù)邏輯的處理。

1.     JPDL的流程定義元素

1)        第一層：GraphElement

這個容易理解,因為在畫流程定義時,每個拖拉的對象都是一個graph的元素。GraphElement有四個屬性：

(1)processDefine 表示當(dāng)前元素屬于哪個流程定義

(2)events 表示可以接收哪些event

(3)name 名字

(4)exceptionHandlers 異常處理類集合(List)

2)        第二層：node、processDefinition、Transition、Task

它們都繼承自GraphElement

(1)processDefinition表示流程定義(implements NodeCollection),它有下面的屬性:name、version、nodes、startState。nodes表示流程中所有的node，startState用于啟動流程時找到首節(jié)點。

(2)Transition表示轉(zhuǎn)移，它有三個屬性：from(Node)，to(Node)，supportedEventTypes表示支持的event類型

(3)node表示節(jié)點，它有四個屬性：leaving transitions、arriving transitions、action、superState。

(4)Task 定義任務(wù)

3)        第三層：各種不同的node

它們都繼承自node。 Decision、EndState、Fork、Join、Merge、Milestone、 InterleaveEnd、InterleaveStart、ProcessState、State。