分类：
2009-07-07 17:38:44
4.1. APIs
流程虚拟机包含4个集成的API，在不同的执行模式下， 覆盖完整的流程工作。 每个API都有特定的目的， 满足下面的架构。
图 4.1. 流程虚拟机中的4个API
服务接口用在应用代码中，与流程虚拟机进行交互， 它将运行在支持事务的持久化模式下，后端基于数据库。 这是用户将PVM作为一个工作流引擎使用的最常用的方式。
如果不想使用持久化方式执行流程，可以直接使用客户端API来处理流程和执行对象。 客户端API对外暴露了核心模型对象的方法。
活动API用来实现活动在运行时的行为。 因此一个活动类型实际上是一个组件，核心是实现了ActivityBehaviour接口。 活动行为实现可以控制执行的流程。
事件监听器API用来编写Java代码，它可以用来处理流程事件。 它比活动API类似， 唯一的差别是事件监听器不能控制执行的流程。
4.2. 活动API
活动API允许使用java实现运行时的活动行为。
public ActivityBehaviour extends Serializable { void execute(ActivityExecution execution) throws Exception; } |
一个活动就是分配给活动的一些行为。 提供的执行时到达这个活动的执行。 ActivityExecution接口 暴露了控制执行流程的方法。
public interface ActivityExecution extends OpenExecution { void waitForSignal(); void take( transitionName); void execute(String activityName); ... } |
事件监听API允许使用Java开发监听器， 并在特定的流程事件发生时调用，像进入一个活动或离开一个活动。 它与活动API类似， 不同的是不能控制执行流程的传播。 比如，当一个执行选择了一个转移，一个对应的监听器会被激活， 但是因为这个转移已经被选择了， 执行的流程无法被事件监听器改变。
public 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 extends Serializable { T execute(Environment environment) throws Exception; } |
这里有三个主要服务：RepositoryService， ExecutionService和ManagementService. 通常来说，服务是会话门面，用来暴露PVM持久化应用的方法。 下一部分用例子展示 这些服务中的基本方法。
RepositoryService管理 流程定义的资源。
public RepositoryService { createDeployment(); ProcessDefinitionQuery createProcessDefinitionQuery(); ... } |
ExecutionService管理 运行时的执行。
public interface ExecutionService { ProcessInstance startProcessInstanceById( processDefinitionId); ProcessInstance signalExecutionById(String executionId); ... } |
ManagementService包含了所有管理操作 来保持系统启动运行。
public interface ManagementService { JobQuery createJobQuery(); void executeJob(long jobDbid); ... } |
所有这些方法都封装成command. 这三个服务执行的方法 都委派给一个CommandService：
public interface CommandService { T execute(Command command); } |
CommandService被配置到环境中。 一个CommandService链可以看做环绕在一个命令周围的一些拦截器。 这就是如何在不同的环境下 进行持久化和事务支持的核心机制。
默认的配置文件jbpm.default.cfg.XML 包含了下面的配置服务。
|
And the file jbpm.tx.Hibernate.cfg.xml contains the following command service configuration：
|
这些服务，比如repository-service，execution-service 和management-service将按照类型找到配置好的command-service. command-service标签符合默认的命令服务， 基本上什么也不做， 只是在提供给它的环境上执行命令。
配置的command-service结果， 在默认的命令执行期下面的三个拦截器链中。
图 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上。
● 把命令打包成一个异步消息， 这样命令会异步执行在一个不同的事务中。
