圖五是在 jbpm4 中啟動一個流程實例的執(zhí)行序列圖，圖六是節(jié)點推進(jìn)的執(zhí)行序列圖，從上面兩個圖中我們可以看到核心的調(diào)度是依據(jù) Execution 的轉(zhuǎn)移來實現(xiàn)的（ ExecutionImpl 可以是 ActivityExecution 、 ClientProcessInstance 、 EventListenerExecution 的實例）， Execution 實際上就是取代了 Jbpm3 中的 Token ， Execution 的轉(zhuǎn)移實際上就是根據(jù)狀態(tài)機(jī)的變遷（ ActivityExecution 、 ClientProcessInstance 、 EventListenerExecution 實例之間的切換）加上調(diào)用相應(yīng)的原子操作： ExecuteNode 、 MoveToChildNode 、 MoveToParentNode 、 ProceedToDesitination 、 Signal 、 TakeTransition （詳見 pvm/internal/model/op 包下的相關(guān)類）來實現(xiàn)的。所以 Execution 實例的集合及有向圖實際上就是運行期的路徑。

3、  Event-Action 機(jī)制的變化

在 jbpm3 中是基于 Event-Action 機(jī)制來實現(xiàn)事件與動作的觸發(fā)的，但是在 jbpm4 中則采用觀察者模式來觸發(fā)事件的。所有用戶自己定義的動作，全部要實現(xiàn) EventListener 接口，這些動作作為監(jiān)聽者（就是事件 Event 的觀察者 Observer ）注冊到相應(yīng)的流程定義對象上（ ProcessElement 或者 Node ），而事件 Event 則作為被觀察的對象（實際上就是 Observerable ），實際上在 jbpm4 中專門定義出了一個對象 ObservableElementImpl ，流程定義中的 NodeImpl 、 TransitionImpl 、 ProcessDefinitionImpl 均繼承自此對象，因此這些元素本身就可以作為 Observerable 而被觀察者來監(jiān)控。

4、  客戶端接口的變化

在jbpm4中對客戶端的接口統(tǒng)一為7個服務(wù)接口：ProcessService、ExecutionService、CommandService 、TaskService 、ManagementService、HistoryService、IdentityService，這7個接口可以從ProcessEngine接口中獲得，jbpm4在啟動的過程中由JbpmConfiguration負(fù)責(zé)構(gòu)建引擎。

Ø ProcessService-流程定義的服務(wù)接口，包括對流程定義的部署、查詢、刪除操作；

Ø ExecutionService-執(zhí)行服務(wù)接口，包括啟動流程、實例推進(jìn)、設(shè)置變量等操作；

Ø CommandService-Command模式的服務(wù)接口，實際上就是將客戶端的請求全部封裝在一個調(diào)用接口中，然后由這個接口去調(diào)用Command接口的眾多實現(xiàn)（StartExecutionCmd、SignalCmd、SetVariablesCmd、GetTimersCmd、DeployCmd、NewTaskCmd、SubmitTask、ExecuteJobCmd等等，具體可參加pvm/internal/cmd，task/internal/cmd包及其它包下實現(xiàn)Command接口的類），這是典型的Command模式的應(yīng)用，感興趣的讀者可以去了解設(shè)計模式中的Command模式；

Ø TaskService-人工活動的服務(wù)接口，包括對任務(wù)的創(chuàng)建、提交、查詢、保存、刪除等操作；

Ø ManagementService-web管理控制臺的服務(wù)接口，目前只有獲得消息及計時器的接口實現(xiàn)；

Ø HistoryService-目前有對歷史庫中的流程實例、活動實例進(jìn)行查詢、某個流程定義中的所有活動的平均持續(xù)時間、某個流程定義中的某個活動實例的轉(zhuǎn)移的執(zhí)行次數(shù)

Ø IdentityService-用戶、組、成員關(guān)系的相關(guān)操作方法

5、歷史庫的加入

jBPM3中數(shù)據(jù)庫設(shè)計一直是我比較詬病的地方，尤其是其實例數(shù)據(jù)庫沒有設(shè)計歷史庫的概念并按照辦結(jié)狀態(tài)將運行結(jié)束的實例數(shù)據(jù)歸入歷史庫，在這種情況下它的實例數(shù)據(jù)庫就會隨著時間而無限膨脹，這就阻礙了它的真實應(yīng)用，而在jBPM4的最新代碼中（注意Alpha1還沒有出現(xiàn)），歷史庫的相關(guān)功能代碼竟然出現(xiàn)了！詳見ExecutionImpl最新代碼中的fireHistoryEvent方法及一系列的historyXXX方法。在ActivityBehaviour的execute方法中加入了historyTaskStart方法的調(diào)用、signal方法中加入了historyTaskEnd方法的調(diào)用，而以上2個方法在ExecutionImpl中都是以歷史事件（HistoryEvent有4個實現(xiàn)子類ProcessInstanceStart、ProcessInstanceEnd、ActivityStart、ActivityEnd分別用作流程實例的創(chuàng)建結(jié)束期、活動實例的創(chuàng)建結(jié)束期的歷史數(shù)據(jù)處理）的觸發(fā)機(jī)制來實現(xiàn)的，也就是在整個流程實例執(zhí)行的過程中，都加入了對將運行數(shù)據(jù)存入歷史庫的歷史事件（HistoryEvent）的觸發(fā)。這樣實例列表的查詢可以只查詢歷史庫。不過這里很遺憾的是，這個事件沒有同時清除運行庫的數(shù)據(jù)，這樣還是會造成運行庫的無限膨脹問題。