第13章 異步繼續
13.1 概念
jBPM以面向圖的編程（GOP）爲基礎，從基本上來講，GOP指定了一個可以處理當前執行路徑的簡單狀態機。在GOP中指定的執行算法中，所有狀態的轉換在客戶端線程的一個單一操作中完成，如果你不熟悉在“第4章 面向圖的編程”中定義的執行算法，請先閱讀該部分。默認情況下，在客戶端線程中完成狀態轉換是一個不錯的方法，因爲它自然地與服務端的事務保持一致，流程從一個等待狀態到另一個等待狀態的執行在一個事務中完成。
但是在某些情形開發者或許想在流程定義中調整事務劃分。在jPDL中，可以使用屬性async=“true”指定流程執行以異步的方式繼續，可以在任何節點類型和動作類型上指定async=“true”。
13.2 一個實例
通常，節點總是在令牌進入之後被執行，因此，節點在客戶端線程中被執行。我們將通過兩個例子來研究異步執行，第一個例子有三個節點，它是一個流程的部分，節點“a”是一個等待狀態，節點“b”是一個自動化步驟，節點“c”也是一個等待狀態，下面的圖中表現了這個流程不包含任何異步行爲的情形。
第一個框圖中展示了開始情形，令牌指向節點“a”，意味着執行路徑正在等待一個外部的觸發器，觸發器必須通過發送一個信號到令牌引起。當信號到達時，令牌將被從節點“a”通過轉換被傳遞到節點“b”，令牌到達節點“b”之後, 節點“b”被執行。回想一下，因爲節點“b”是一個自動化步驟，它不會作爲一個等待狀態（例如發送一個email），所以第二個框圖只是當節點“b”被執行時的一個快照，因爲節點“b”是流程中的一個自動化步驟，所以節點“b”的執行包含了令牌通過轉換到節點“c”的傳播。節點“c”是一個等待狀態，因此第三個框圖展示了signal方法返回後的情形。
圖 13.1 例1：沒有異步繼續的流程
雖然在jBPM中持久化不是必須的，但是通常情況下信號在一個事務中被調用。讓我們看一下該事務的更新，首先，令牌被更新爲指向節點“c”，這些更新作爲GraphSession.saveProcessInstance的結果被hibernate在一個JDBC連接上發生；其次，如果自動化動作訪問和更新某些相互影響的資源，那些資源的更新會與上述事務組合或作爲事務的一部分。
現在我們看一下第二個例子，第二個例子是第一個例子的變種，在節點“b”引入了一個異步執行，節點“a”和“c”的行爲表現與第一個例子中相同，也就是它們表現爲等待狀態。在jPDL中，一個節點通過設置屬性async=“true”來標識爲異步。
添加async=“true”到節點“b”的結果就是流程的執行將被分裂爲兩部分。一部分將執行流程直到節點“b”被執行；另一部分將會執行節點“b”，並且執行在等待狀態“c”停止。
事務因此也將被分裂爲兩個獨立的事務，每個事務對應於一部分。當在第一個事務中需要一個外部觸發器（Token.signal方法調用）來離開節點“a”時，jBPM將會自動觸發並完成第二個事務。
圖 13.2 例2：有異步繼續的流程
對於動作（action）原理相似，被屬性async=“true”標識的動作在執行流程的線程之外被執行，如果持久化被配置（這是默認的），則動作在一個獨立的事務中被執行。
在jBPM中，異步執行通過使用一個異步通知系統來實現。當流程執行到達需要異步執行的點時，jBPM將掛起執行，產生一個命令消息併發送該命令消息到命令執行器，命令執行器是一個單獨的組件，在收到的消息之上它將在流程掛起的地方恢復流程執行。
jBPM可以被配置爲使用JMS提供者或者它自己內置的異步通知系統，內置的通知系統在功能上是很有限的，但是可以在JMS不能使用的環境中支持異步特性。
13.3 命令執行器
命令執行器是恢復流程異步執行的組件，它通過異步通知系統等待命令消息的到達並執行它們，ExecuteNodeCommand和ExecuteActrionCommand兩個命令被用來異步繼續。
這些命令由流程執行產生，在流程執行過程中，對於每個需要異步執行的節點，一個ExecuteNodeCommand（POJO）將被在MessageInstance（消息實例）中創建，消息實例是ProcessInstance的一個非持久化擴展，它只是用來聚集所有將要發送的消息。
消息將被作爲GraphSession.saveProcessInstance的一部分被髮送，該方法的實現包含一個上下文構建器，構建器作爲saveProcessInstance方法的一個方面（aspect）。實際使用的攔截器可以在jbpm.cfg.xml中配置，SendMessagesInterceptor攔截器被默認配置，用來從MessageInstance中讀取消息並且通過可配置的異步通知系統發送消息。
SendMessagesInterceptor使用接口MessageServiceFactory和MessageService發送消息，這使得異步通知實現是可配置的（也是在jbpm.cfg.xml中）。
13.4 jBPM內置的異步消息
當使用jBPM內置的異步通知時，消息通過持久化到數據庫被髮送，消息的持久化可以與jBPM流程更新一樣在同一個事務、jdbc連接中完成。
命令消息將被存儲在JBPM_MESSAGE表中。
POJO命令執行器（org.jbpm.msg.command.CommandExecutor）將從數據庫表中讀取消息並執行它們，因此POJO命令執行器典型的事務處理如下：1)讀取下一個命令消息2)執行命令消息3)刪除命令消息。
如果命令消息執行失敗，事務將會回滾，然後一個新的事務將被開始用來添加錯誤信息到數據庫的消息，命令執行器過濾掉所有包含異常的消息。
圖 13.3 POJO命令執行器事務
如果由於某些原因添加異常到命令消息的事務失敗了，它也一樣會被回滾，在這種情況下，沒有異常的消息依然被保留在隊列，因此它將在以後被再次嘗試執行。
侷限性：jBPM內置的異步通知系統不支持多個節點同步，因此你不能多次配置POJO命令執行器並且把它們配置爲使用相同數據庫。
13.5 JMS用於異步結構
異步執行特性打開了jBPM所適用場景的一個新局面，典型的被用在業務流程建模時，它可以從一個非常技術的觀點來使用。
設想你有一個擁有很多異步處理的應用，綁定所有的消息生成和消息銷燬軟件在一起是很困難的，如果使用jBPM這將成爲可能。通過創建所有異步結構的視圖，把你的所有代碼放入POJO，並且在流程文件中添加事務劃分，就可以做到了。jBPM考慮到了你無需自己編寫所有JMS或MDB代碼而綁定發送者到接受者。
13.6 JMS用於異步通知
TODO（還未實現）
13.7 未來趨勢
TODO：添加支持多個隊列，因此可以爲每個標識爲異步的節點或動作指定一個隊列，並且將循環爲一組隊列生成消息。因爲所有這些對於JMS和內置的通知系統將是可配置的，所以對於怎樣處理所有這些配置需要一些考慮。流程定義將無需依賴於這兩個可能的實現。