4.1. APIs
流程虛擬機包含4個集成的API,在不同的執行模式下, 覆蓋完整的流程工作。 每個API都有特定的目的, 滿足下面的架構。
流程虛擬機中的4個API
圖 4.1. 流程虛擬機中的4個API
服務接口用在應用代碼中,與流程虛擬機進行交互, 它將運行在支持事務的持久化模式下,後端基於數據庫。 這是用戶將PVM作為一個工作流引擎使用的最常用的方式。
如果不想使用持久化方式執行流程,可以直接使用客戶端API來處理流程和執行對象。 客戶端API對外暴露了核心模型對象的方法。
活動API用來實現活動在運行時的行為。 因此一個活動類型實際上是一個組件,核心是實現了ActivityBehaviour接口。 活動行為實現可以控制執行的流程。
事件監聽器API用來編寫Java代碼,它可以用來處理流程事件。 它比活動API類似, 唯一的差別是事件監聽器不能控制執行的流程。
4.2. 活動API
活動API允許使用Java實現運行時的活動行為。
- public interface ActivityBehaviour extends Serializable {
- void execute(ActivityExecution execution) throws Exception;
- }
一個活動就是分配給活動的一些行為。 提供的執行就是到達這個活動的執行。 ActivityExecution接口 暴露了控制執行流程的方法。
- public interface ActivityExecution extends OpenExecution {
- void waitForSignal();
- void take(String transitionName);
- void execute(String activityName);
- ...
- }
4.3. 事件監聽API
事件監聽API允許使用Java開發監聽器, 並在特定的流程事件發生時調用,像進入一個活動或離開一個活動。 它與活動API類似, 不同的是不能控制執行流程的傳播。 比如,當一個執行選擇了一個轉移,一個對應的監聽器會被激活, 但是因為這個轉移已經被選擇了, 執行的流程無法被事件監聽器改變。
- public interface EventListener extends Serializable {
- void notify(EventListenerExecution execution) throws Exception;
- }
4.4. 客戶端API
客戶端API是一套暴露了相關方法的接口, 它用來直接管理流程定義上的執行和執行對應。
最小的需求,客戶端API和活動API需要使用活動創建 流程定義並執行它。
4.5. 環境
在持久化執行環境下,環境的第一目的 是讓流程在不同的事務環境下執行, 比如Java標准版,Java企業版,SEAM和Spring。
PVM代碼自身只通過自身定義的接口來調用事務資源。 比如,PVM自身擁有一些建立在hibernate會話,異步消息會話 和定時任務會話的接口方法。
環境允許為其配置真實的實現, 在請求的基礎上實現服務的延遲加載, 為事務的持續獲得服務對象。
一個環境工廠是靜態的,一個環境工廠 提供應用中的所有線程。
- EnvironmentFactory environmentFactory = new PvmEnvironmentFactory("environment.cfg.XML");
環境部分可以像這樣 圍繞在持久化流程操作周圍:
- Environment environment = environmentFactory.openEnvironment();
- try {
- ... inside the environment block...
- } finally {
- environment.close();
- }
PVM自身會從環境中獲得所有事務資源和配置。 Activity實現 也可以做同樣的事情。
org.jbpm.pvm.internal.cfg.JbpmConfiguration 這個類扮演著Configuration, ProcessEngine和EnvironmentFactory三個角色。
4.6. 命令
命令封裝了將被運行在環境塊中的操作。 命令的主要目的是獲得邏輯。
- public interface Command< T> extends Serializable {
- T execute(Environment environment) throws Exception;
- }
4.7. 服務
這裡有三個主要服務:RepositoryService, ExecutionService和ManagementService。 通常來說,服務是會話外觀,用來暴露PVM持久化應用的方法。 下一部分用例子展示 這些服務中的基本方法。
RepositoryService管理 流程定義的資源。
- public interface RepositoryService {
- Deployment createDeployment();
- ProcessDefinitionQuery createProcessDefinitionQuery();
- ...
- }
- ExecutionService管理 運行時的執行。
- public interface ExecutionService {
- ProcessInstance startProcessInstanceById(String processDefinitionId);
- ProcessInstance signalExecutionById(String executionId);
- ...
- }
- ManagementService包含了所有管理操作 來保持系統啟動運行。
- public interface ManagementService {
- JobQuery createJobQuery();
- void executeJob(long jobDbid);
- ...
- }
所有這些方法都封裝成Command。 這三個服務執行的方法 都委派給一個CommandService:
- public interface CommandService {
- < T> T execute(Command< T> command);
- }
CommandService被配置到環境中。 一個CommandService鏈可以看做環繞在一個命令周圍的一些攔截器。 這就是如何在不同的環境下 進行持久化和事務支持的核心機制。
默認的配置文件jbpm.default.cfg.XML 包含了下面的配置服務。
- < jbpm-configuration>
- < process-engine>
- < repository-service />
- < repository-cache />
- < execution-service />
- < history-service />
- < management-service />
- < identity-service />
- < task-service />
文件 jbpm.tx.hibernate.cfg.XML包含了 下面的command service配置:
- < jbpm-configuration>
- < process-engine-context>
- < command-service>
- < retry-interceptor />
- < environment-interceptor />
- < standard-transaction-interceptor />
- < /command-service>
- < /process-engine-context>
- ...
這些服務,比如repository-service,execution-service 和management-service將按照類型找到配置好的command-service。 command-service標簽符合默認的命令服務, 基本上什麼也不做, 只是在提供給它的環境上執行命令。
配置的command-service結果, 在默認的命令執行期下面的三個攔截器鏈中。
CommandService攔截器
圖 4.2. CommandService攔截器
retry攔截器是鏈中的第一個,它會被環境 當做CommandService.class暴露出來。 所以retry攔截器會分別提供給repository-service, execution-service和management-service這些服務。
retry-interceptor會獲取hiberate的StaleObjectExceptions (因為樂觀鎖失敗)並重新嘗試執行命令。
environment-interceptor會把一個環境塊 放到命令執行的周圍。
standard-transaction-interceptor會初始化一個 StandardTransaction。hibernate會話/事務會被作為 標准事務的一個資源。
這個攔截器棧的不同配置也可以使用:
◆把執行委派到一個本地ejb命令服務, 這樣可以啟動一個內容管理的事務。
◆把執行委派到一個遠程ejb命令服務, 這樣命令實際執行在一個不同的JVM上。
◆把命令打包成一個異步消息, 這樣命令會異步執行在一個不同的事務中。