4.1. APIs

流程虛擬機包含4個集成的API，在不同的執(zhí)行模式下， 覆蓋完整的流程工作。 每個API都有特定的目的， 滿足下面的架構(gòu)。
流程虛擬機中的4個API


圖 4.1. 流程虛擬機中的4個API

服務(wù)接口用在應(yīng)用代碼中，與流程虛擬機進行交互， 它將運行在支持事務(wù)的持久化模式下，后端基于數(shù)據(jù)庫。 這是用戶將PVM作為一個工作流引擎使用的最常用的方式。

如果不想使用持久化方式執(zhí)行流程，可以直接使用客戶端API來處理流程和執(zhí)行對象。 客戶端API對外暴露了核心模型對象的方法。

活動API用來實現(xiàn)活動在運行時的行為。 因此一個活動類型實際上是一個組件，核心是實現(xiàn)了ActivityBehaviour接口。 活動行為實現(xiàn)可以控制執(zhí)行的流程。

事件監(jiān)聽器API用來編寫java代碼，它可以用來處理流程事件。 它比活動API類似， 唯一的差別是事件監(jiān)聽器不能控制執(zhí)行的流程。
4.2. 活動API

活動API允許使用java實現(xiàn)運行時的活動行為。

public interface ActivityBehaviour extends Serializable {
  void execute(ActivityExecution execution) throws Exception;
}

一個活動就是分配給活動的一些行為。 提供的執(zhí)行就是到達這個活動的執(zhí)行。 ActivityExecution接口 暴露了控制執(zhí)行流程的方法。

public interface ActivityExecution extends OpenExecution {

  void waitForSignal();
  void take(String transitionName);
  void execute(String activityName);

  ...

}

4.3. 事件監(jiān)聽API

事件監(jiān)聽API允許使用java開發(fā)監(jiān)聽器， 并在特定的流程事件發(fā)生時調(diào)用，像進入一個活動或離開一個活動。 它與活動API類似， 不同的是不能控制執(zhí)行流程的傳播。 比如，當一個執(zhí)行選擇了一個轉(zhuǎn)移，一個對應(yīng)的監(jiān)聽器會被激活， 但是因為這個轉(zhuǎn)移已經(jīng)被選擇了， 執(zhí)行的流程無法被事件監(jiān)聽器改變。

public interface EventListener extends Serializable {

  void notify(EventListenerExecution execution) throws Exception;

}

4.4. 客戶端API

客戶端API是一套暴露了相關(guān)方法的接口， 它用來直接管理流程定義上的執(zhí)行和執(zhí)行對應(yīng)。

最小的需求，客戶端API和活動API需要使用活動創(chuàng)建 流程定義并執(zhí)行它。
4.5. 環(huán)境

在持久化執(zhí)行環(huán)境下，環(huán)境的第一目的 是讓流程在不同的事務(wù)環(huán)境下執(zhí)行， 比如Java標準版，Java企業(yè)版，SEAM和Spring。

PVM代碼自身只通過自身定義的接口來調(diào)用事務(wù)資源。 比如，PVM自身擁有一些建立在hibernate會話，異步消息會話 和定時任務(wù)會話的接口方法。

環(huán)境允許為其配置真實的實現(xiàn)， 在請求的基礎(chǔ)上實現(xiàn)服務(wù)的延遲加載， 為事務(wù)的持續(xù)獲得服務(wù)對象。

一個環(huán)境工廠是靜態(tài)的，一個環(huán)境工廠 提供應(yīng)用中的所有線程。

EnvironmentFactory environmentFactory = new PvmEnvironmentFactory("environment.cfg.xml");

環(huán)境部分可以像這樣 圍繞在持久化流程操作周圍：

Environment environment = environmentFactory.openEnvironment();
try {

  ... inside the environment block...

} finally {
  environment.close();
}

PVM自身會從環(huán)境中獲得所有事務(wù)資源和配置。 Activity實現(xiàn) 也可以做同樣的事情。

org.jbpm.pvm.internal.cfg.JbpmConfiguration 這個類扮演著Configuration， ProcessEngine和EnvironmentFactory三個角色。
4.6. 命令

命令封裝了將被運行在環(huán)境塊中的操作。 命令的主要目的是獲得邏輯。

public interface Command<T> extends Serializable {

  T execute(Environment environment) throws Exception;

}

4.7. 服務(wù)

這里有三個主要服務(wù)：RepositoryService， ExecutionService和ManagementService。 通常來說，服務(wù)是會話外觀，用來暴露PVM持久化應(yīng)用的方法。 下一部分用例子展示 這些服務(wù)中的基本方法。

RepositoryService管理 流程定義的資源。

public interface RepositoryService {

  Deployment createDeployment();

  ProcessDefinitionQuery createProcessDefinitionQuery();

  ...

}

ExecutionService管理 運行時的執(zhí)行。

public interface ExecutionService {

  ProcessInstance startProcessInstanceById(String processDefinitionId);

  ProcessInstance signalExecutionById(String executionId);

  ...

}

ManagementService包含了所有管理操作 來保持系統(tǒng)啟動運行。

public interface ManagementService {

  JobQuery createJobQuery();

  void executeJob(long jobDbid);

  ...

}

所有這些方法都封裝成Command。 這三個服務(wù)執(zhí)行的方法 都委派給一個CommandService：

public interface CommandService {

  <T> T execute(Command<T> command);

}

CommandService被配置到環(huán)境中。 一個CommandService鏈可以看做環(huán)繞在一個命令周圍的一些攔截器。 這就是如何在不同的環(huán)境下 進行持久化和事務(wù)支持的核心機制。

默認的配置文件jbpm.default.cfg.xml 包含了下面的配置服務(wù)。

<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>

  ...

這些服務(wù)，比如repository-service，execution-service 和management-service將按照類型找到配置好的command-service。 command-service標簽符合默認的命令服務(wù)， 基本上什么也不做， 只是在提供給它的環(huán)境上執(zhí)行命令。

配置的command-service結(jié)果， 在默認的命令執(zhí)行期下面的三個攔截器鏈中。
CommandService攔截器



圖 4.2. CommandService攔截器

retry攔截器是鏈中的第一個，它會被環(huán)境 當做CommandService.class暴露出來。 所以retry攔截器會分別提供給repository-service， execution-service和management-service這些服務(wù)。

retry-interceptor會獲取hiberate的StaleObjectExceptions （因為樂觀鎖失敗）并重新嘗試執(zhí)行命令。

environment-interceptor會把一個環(huán)境塊 放到命令執(zhí)行的周圍。

standard-transaction-interceptor會初始化一個 StandardTransaction。hibernate會話/事務(wù)會被作為 標準事務(wù)的一個資源。

這個攔截器棧的不同配置也可以使用：

    * 把執(zhí)行委派到一個本地ejb命令服務(wù)， 這樣可以啟動一個內(nèi)容管理的事務(wù)。
    * 把執(zhí)行委派到一個遠程ejb命令服務(wù)， 這樣命令實際執(zhí)行在一個不同的JVM上。
    * 把命令打包成一個異步消息， 這樣命令會異步執(zhí)行在一個不同的事務(wù)中。

完整版內(nèi)容http://family168.com/tutorial/jbpm4devguide/html/index.html