| leaving activity(composite) 第 6 章 流程剖析 上面我们已经简要的接触了两个主要的流程结构： 活动，转移和活动组合。 这一章研究了流程定义结构的全部可能。 这儿基本有两个流程定义方式：基于图形和组合流程语言。 首先，流程支持这两种情况。 每个基于图形的执行和活动组合可以用来组合一些像UML超级状态的实现。 甚至，自动功能活动可以被实现， 所以它们可以使用转移和活动组合。  图 6.1. 逻辑流程结构的UML类图 下一步我们会显示一系列的实例图形结构， 这可以组成PVM流程模型。  图 6.2. 任意两个活动可以使用一个转移进行连接。  图 6.3. 自连接。  图 6.4. 组合活动是一系列内嵌活动。  图 6.5. 在组合中转移到一个活动。  图 6.6. 从一个组合内部的一个活动转移到组合外部的一个活动。 
图 6.7. 继承的组合活动的转移。活动内部可以选择组合活动的转移。  图 6.8. 一个活动转移到外部组合。  图 6.9. 从一个组合活动转移到内部组合活动。  图 6.10. 在组合活动内部的一个初始活动。 第 7 章 高级图形执行 7.1. 循环 活动可以实现循环，基于转移或活动组合。 循环可以包含等待状态。 为了支持多次自动循环执行，流程虚拟机 把执行的传播从尾部递归转换成while循环。 7.2. 子流程 TODO： 子流程 7.3. 默认执行行为 当一个Activity被用作活动行为， 它可以使用下面的方法从外部控制流程： * waitForSignal()
* take(Transition)
* end(*)
* execute(Activity)
* createExecution(*) 当Activity实现用做活动行为， 没有调用任何下面的流程传播方法，然后 在活动执行时，执行会使用默认执行行为。 默认执行行为定义在下面： * 如果当前活动有一个默认向外转移，选择它。
* 如果当前活动有一个父活动，回退到父活动。
* 否则，结束这个执行。 流程语言可以重写默认执行行为， 通过重写ExecutionImpl中的 proceed方法。 7.4. 功能活动 活动也可以用作事件监听器，被称作功能活动。 自动活动的例子是发送邮件，执行数据库更新， 生成pdf，计算平均数，等等。 所有这些都是自动活动，没有改变执行流向。 这里是这些活动如何实现：
public class FunctionalActivity implements Activity, EventListener {
public void execute(ActivityExecution execution) {
perform(execution);
}
public void notify(EventListenerExecution execution) {
perform(execution);
}
void perform(OpenExecution execution) {
...do functional work...
}
} |
perform方法获得一个OpenExecution， 这是ActivityExecution和 EventListenerExecution的超类。 OpenExecution没有提供任何特定目的的方法， 但是依旧是当前状态，流程定义可以通过变量检验， 这包含了环境信息 对应流程执行。 这些方法其实都不能调用执行传播方法。 所以在perform方法完成后，执行会 执行默认的方式。 7.5. 执行和线程 这一章解释流程虚拟机如何通过客户端的线程， 把一个执行从一个等待状态带到另一个。 当一个客户调用一个执行的一个方法（比如signal方法）。 默认，流程虚拟机会使用线程执行流程 直到它到达一个等待状态。一旦下一个等待状态到达， 这个方法会返回，客户端的线程就会返回。 这是流程虚拟机操作的默认方式。 两个更多的异步执行可以补充默认行为： 异步继续 和异步命令服务。 下一个流程会展示基本理论。 它有三个等待状态和四个自动活动。 有很多顺序自动活动的流程。  图 7.1. 有很多顺序自动活动的流程。 这里是如何构建流程：
ClientProcessDefinition processDefinition = ProcessFactory.build("automatic")
.activity("wait 1").initial().behaviour(new WaitState())
.transition().to("automatic 1")
.activity("automatic 1").behaviour(new Display("one"))
.transition().to("wait 2")
.activity("wait 2").behaviour(new WaitState())
.transition().to("automatic 2")
.activity("automatic 2").behaviour(new Display("two"))
.transition().to("automatic 3")
.activity("automatic 3").behaviour(new Display("three"))
.transition().to("automatic 4")
.activity("automatic 4").behaviour(new Display("four"))
.transition().to("wait 3")
.activity("wait 3").behaviour(new WaitState())
.done(); |
让我们和你一起顺着流程的执行一起走。
| ClientExecution execution = processDefinition.startProcessInstance(); |
启动一个新执行意味着初始活动被执行。 所以如果一个自动活动是初始活动，这意味着第一个未命名的向外转移会被立刻选择。 这些都发生在startProcessInstance调用的内部。 然而在这种情况下，初始活动是一个等待状态。 所以startProcessInstance方法会立刻返回， 执行会定位到初始活动'wait 1'.一个新执行会被定为到'wait 1'.  图 7.2. 一个新执行会被定为到'wait 1'. 然后一个外部触发器会执行signal方法。
像上面解释的介绍WaitState， signal会导致选择默认的转移。 转移会把执行移动到automatic 1活动，并执行它。 automatic 1中的Display活动的execute方法， 向控制台打印一行，它不会 调用execution.waitForSignal（）。 因此，执行会通过选择automatic 1外部的默认转移进行执行。 在这种状态，signal方法一直阻塞着。另一个需要考虑的方式是执行方法， 像signal会使用客户端的线程 来拦截流程定义，直到到达一个等待状态。 然后执行到达wait 2， 执行WaitState活动。那个方法会调用 execution.waitForSignal（），这会导致signal方法返回。 线程会返回到调用signal方法 的客户端。 所以，当signal方法返回时，执行定义到wait 2.一个signal会把执行从'initial'带到'wait 2'.  图 7.3. 一个signal会把执行从'initial'带到'wait 2'. 然后执行会等待一个外部触发器， 像是一个对象（更准确的是一个对象图）在内存中， 直到下一个外部触发器执行signal方法。
第二个调用的signal会直接让执行进入wait 3， 在它返回之前。 第二个signal让执行进入'wait 3'.  图 7.4. 第二个signal让执行进入'wait 3'. 使用这个范例的好处是相同的流程定义可以在 客户执行模式中执行 （在内存内不使用持久化），就像在持久化执行模式， 依赖应用和环境。 当在持久化模式下执行一个流程，你如何绑定 流程执行到数据库的事务上。 持久化模式下的事务超时  图 7.5. 持久化模式下的事务超时 在大多情况下，计算工作是流程需要完成的一部分， 在外部触发器（红色部分）之后的部分，其实很少。 一般来说，处理流程执行和处理UI传递过来的请求 的事务不会超过一秒。 而业务流程中的等待状态可能超过几小时，几天甚至几年。 当等待状态启动后，线索就变得很清晰， 在等待状态启动之前，只有计算工作的完成包含在事务中。 考虑一下这种方式： "当到达审批时，所有的自动流程需要做的是什么， 在流程系统需要等待另一个外部触发器之前？". 除非pdf需要被创建，或大邮件需要被发送， 大部分时候，它消耗的时间都是可以忽略的。 这就是为什么在默认的持久化执行模式下， 流程工作在客户端线程下执行。 这个原因也保证着流程同步路径的情况。 当一个执行的单独路径切分成流程同步路径， 流程花在计算上的时间是可忽略的。 所以为什么分支或切分活动实现是有意义的， 目标持久化模式产生的同步路径在同一个线程中按顺序执行。 基本上它们都只是在同一个事务中的计算工作。 因为分支或切分知道每个执行的同步路径会返回，所以这只能被完成， 当出现一个等待状态的时候。 因为这里有一个困难的概念需要掌握，我会再次使用其他词语来解释它。 从头再看一次在持久化执行模式下被流程执行创建出来的它。 如果在一个事务中，一个执行被给与一个外部触发器， 那导致执行切分成多个执行的同步路径。 然后执行在计算上的部分也可以忽略。 生成SQL的部分也可以忽略。 因为所有在同步分支上完成的功能，必须在同一个事务中完成， 这里一般没有指针在分支或切分实现， 在多个线程中产生执行的同步路径。 为了创建可执行流程，开发者需要确切知道什么是自动活动， 什么是等待状态，哪些线程会被分配给流程执行。 对于画业务流程的业务分析人员，事件就很简单了。 对于他们画的活动，他们通常只要知道这是一个人或是一个系统响应。 但是他们通常不知道如何转换线程和事务。 所以对于开发者，第一个任务是分析什么是流程控制的线程中需要执行的， 什么是外部的。 查找外部触发器是寻找一个流程中的等待状态的很好的开始， 就像动词和名词可以在构建UML类图中的元素的规则。 7.6. 流程同步 为了进行流程同步建模，在执行中这是一个父子树形结构。 这个想法是执行主路径是树的根。 流程的主路径也被称作流程实例。 当在给定流程定义上启动或创建一个新流程实例时， 执行便被创建。 现在，因为执行的主路径和流程实例是相同对象， 这保证了用法的简单， 在没有同步情况的简单流程下。 基本执行结构的UML类图  图 7.6. 基本执行结构的UML类图 为了建立执行的多同步路径，活动实现比如一个分支或切分 创建子执行， 使用ActivityExecution.createExecution方法。 活动实现比如结合或合并可以停止流程的这些同步路径， 通过调用执行同步的stop方法。 只有叶子执行可以激活，非叶子执行应该不是激活的。 这个执行的树形结构没有坚持一个同步或结合行为的特殊类型。 它从事着分支或和切分 和结合或和合并来使用执行树结构， 用任何方式，他们想定义期望的同步行为。 这里我们看一个同步执行的例子。 执行的同步路径  图 7.7. 执行的同步路径 这里有执行的一个付款和一个发货路径。 在这种情况，水平线上的活动展示了分支和结合。这个执行显示了三个执行。 执行的主路径不是激活的（显示成灰色） 执行的付款和发货路径是激活的，分别指向了 bill和ship活动。 从事活动行为的实现，是他们想使用的执行结构。 假设多个任务必须在执行进行之前完成。 活动行为可以为这个产生一系列子执行。 或者可以选择，任务组件可以支持任务组， 分配给单独的执行。在那种情况， 任务组件成为同步任务的响应， 因此把这个责任移动到执行树形结构范围之外。 7.7. 异常处理器 在所有分配到流程的代码中，像 Activity，EventListeners和 Condition，可能分配给异常处理器。 这可以想成是把这些实现的方法实现包含在try-catch块中。 但是为了构建更多可复用的构建块， 为了委派类和异常处理逻辑， 异常处理器可以添加到核心流程模型中。 一个异常处理器可以分配给任何流程元素。 当一个异常发生在一个委派类中，一个匹配的异常处理器就会被找到。 如果找到了一个这样的异常处理器，它会有一个处理这个异常的机会。 如果一个异常处理器处理完成，没有出现问题，然后这个异常会 被认为是处理了，就会在委派代码调用后继续。 比如，一个转移有三个动作，第二个动作抛出一个异常， 这个异常被异常处理器处理，然后 编写自动活动，异常处理器提醒是很容易的。 默认是任意执行。没有方法需要在执行中调用。 所以如果一个自动活动抛出一个异常，被异常处理器处理， 这个执行会在这个执行后继续执行。这对于控制流向活动 就会有一个更大的困难。它们可能需要包含try-finally块 来调用执行中对应的方法，在异常处理器 获得一个机会来处理异常。比如，如果活动是等待状态， 然后发生了一个异常，这里就会有一个风险，线程会跳出 execution.waitForSignal（）的调用， 导致执行在这个活动以后继续执行。 TODO： exceptionhandler.isRethrowMasked TODO： transactional exception handlers TODO： we never catch errors 7.8. 流程修改 TODO： 流程修改 7.9. 锁定和流程状态 一个执行的状态不是激活就是锁定。 一个激活的执行不是执行就是等待外部触发器。 如果一个执行不是STATE_ACTIVE，那么它就是被锁定。 一个锁定的执行是只读的，不能接受任何外部触发器。 当一个新执行被创建时，它是STATE_ACTIVE. 为了把状态修改成锁定状态，使用lock（String）。一些STATE_*常量 被提供了，它们演示了最常用的锁定状态。 但是在图片中的'……'状态展示了任何字符串 都可以作为状态提供给lock方法。 执行的状态  图 7.8. 执行的状态 如果一个执行被锁定，修改执行的方法会 抛出一个PvmException，信息会引用真实的锁定状态。 触发事件，更新变量，更新优先级，添加注释 不会当做是修改执行。 子节点的创建和删除也不会检测， 这意味着那些方法可以被外部API客户和活动行为调用， 即使执行在锁定状态。 确保比较getState（）和STATE_*常量时 使用。equals，不要使用'=='，因为如果执行从持久存储加载。 会创建一个新字符串，而不是使用常量。 一个执行实现会被锁定： * 当它结束
* 当它暂停
* 在异步延续过程中 更多的，锁定可以被活动实现使用， 让执行在等待状态下只读，然后为这个执行传递 的外部实例就像这样： * 一个人员任务
* 一个服务调用
* 一个等待状态当探测器检测一个文件的出现时就结束 在这些情况，策略是外部实例应该获得 执行的完全控制，因为它想要控制什么应该允许，什么不应该。 为了获得那种控制，他们锁定了执行，所以所有内部交互 必须通过外部实例传递。 一个创建外部实例的主要原因是， 它们可以在执行已经执行过还存在。比如， 在服务调用的情况，定时器可以导致执行获得超时转移。 当响应在超时后到达，服务调用实例应该 确认它没有signal这个执行。所以服务调用可以看做 一个活动实例（活动实例） 是对活动每个执行的唯一实例。 外部实例它们自己负责管理执行锁定。 如果定时器和客户端应用结果是选择 外部实例，而不是直接选择执行，然后在理论上是不必要的。 它是从事活动行为实现，无论它希望 执行锁定还是解锁。 第 8 章 软件日志 8.1. 配置 PVM可以使用JDK日志（java.util.logging）或log4j.当第一个信息被记录， PVM日志会根据下面的过程进行选择： 1. 如果一个logging.properties资源被发现在 classpath（使用context classloader）下，然后JDK日志会被使用 这个文件会被用来实现JDK日志。 2. 如果log4j在classpath中找到，然后log4j会被用到。 对log4j的检测会通过检测context classloader中的 org.apache.log4j.LogManager来实现。 3. 如果没找到上面的，会使用JDK日志。 8.2. 目录 PVM类使用它们自己的类名作为日志的目录。 为了对PVM的类在做什么进行基本的激烈， 最好打开debug级别。 trace级别对于这个目的来讲 输出似乎太多了。 8.3. JDK日志 在JDK日志中，debug映射为fine， trace映射为finest. finer级别没有用到。 org.jbpm.pvm.internal.log.LogFormatter是pvm库的一部分， 它可以为日志信息创建一个很好的单行输出。 它也有一个灵活的功能，为每个线程创建一个唯一的标示。 想要配置它，这是一个常用的logging.properties
handlers = java.util.logging.ConsoleHandler
java.util.logging.ConsoleHandler.level = FINEST
java.util.logging.ConsoleHandler.formatter = org.jbpm.pvm.internal.log.LogFormatter
# For example, set the com.xyz.foo logger to only log SEVERE messages:
# com.xyz.foo.level = SEVERE
.level = SEVERE
org.jbpm.level=FINE
org.jbpm.tx.level=FINE
org.jbpm.pvm.internal.wire.level=FINE |
8.4. 调试持久化 在测试持久化时，下面的日志配置是很有价值的。 目录org.hibernate.SQL显示执行的SQL语句， 目录org.hibernate.type显示查询中 设置的参数值。
org.hibernate.SQL.level=FINEST
org.hibernate.type.level=FINEST |
一旦你获得一个失败处理，比如因为一个hibernate异常， 你可能希望把批处理大小设置为0，像这样在hibernate配置里：
| hibernate.jdbc.batch_size = 0 |
也是在hibernate配置中，下面的配置允许记录 hibernate输出的SQL的日志细节：
hibernate.format_sql = true
hibernate.use_sql_comments = true
第 9 章 历史 9.1. 概述 在流程执行过程中都会触发HistoryEvents. 我们在两个级别维护历史信息：流程实例和活动实例。 流程实例启动和流程实例结束生成历史事件 会从实现中直接触发。 ActivityBehaviour实现负责调用historyXxx方法 被ActivityExection中暴露。 所有HistoryEvent被委派给一个HistorySession.默认的HistorySessionImpl 将调用历史事件它们自己的process（）方法。 HistoryEvent是临时事件。在process方法中，它们在历史模型中建立信息。 这是一个HistoryProcessInstance，这里还有一个从HistoryActivityInstance 开始的完全类继承结构。 在HistoryEvent.process方法中，历史事件创建模型实体或者在模型实体中合并信息。 比如，一个ProcessInstanceStart历史事件会创建一个HistoryProcessInstance实例或记录。 ProcessInstanceEnd会设置已存在的HistoryProcessInstance实例或记录的 结束属性。 与活动的模式相同。但是对于自动活动，这里有一个优化 所以只有一个事件被创建，所以信息被存储在一个单独的insert中 （所有这些都发生在一个事务中）。 第 10 章 委派类 10.1. 什么是委派类 委派类是实现了Activity或 Condition的类。 根据流程虚拟机的期待，这里有外部类提供了程序逻辑， 插入到PVM的图形执行中。 外派类可以被流程语言 和最终用户提供。 10.2. 委派类的配置 委派类可以实现配置化。成员变量可以包含配置参数， 所以一个委派类可以在 每次使用的时候进行不同的配置。比如， 在Display活动中， 打印到控制台的信息就是一个 配置参数。 委派类应该是无状态的，这意味着执行接口方法 应该不会改变成员变量的值。在执行阶段改变委派类的成员变量的值 其实似乎在执行阶段改变这个流程。 那是线程不安全的，通常会导致与预期不符的结果。 作为一个异常，getter和setter都可以使用来注入配置， 因为它们在委派类实际使用在流程执行之前 就被调用了。 10.3. 对象引用 TODO 10.4. 设计期间 对 运行期间 TODO： 设计期间的活动行为应该和运行期间的行为相同。 10.5. 用户代码拦截器 TODO： 用户代码拦截器 10.6. 成员变量配置 对 配置 TODO： 记录成员变量配置 对 配置 第 11 章 环境 11.1. 简介 环境组件由连接环境组合是一种控制反转（IoC）容器。 它读取配置信息， 描述对象应该如何实例化，如何配置，如何连接在一起。 环境被用来获得Activity实现 和流程虚拟机所需的资源和服务。 主要目的是让流程虚拟机的多个部分可配置， 这样PVM和运行在顶部的语言可以工作在一个标准Java环境 也可以在一个企业Java环境。 环境被分成一系列环境。 每个环境可以拥有自己的生命周期。比如，流程引擎环境会 覆盖应用的全生命时间。块环境只对try-finally块周期内起作用。 一般一个块环境负责一个数据库事务。 每个环境暴露一个key-value列表。 pairs. 11.2. EnvironmentFactory 为了开始和一个环境进行工作，你需要一个EnvironmentFactory. 一个单独的环境工厂对象可以被用在整个应用的完整生命时间里。 所以一般这会保存在一个静态成员变量中。 EnvironmentFactory自己在流程引擎环境中 一个EnvironmentFactory一般被获得 通过解析一个配置文件，像这样：
static EnvironmentFactory environmentFactory =
EnvironmentFactory.parse(new ResourceStreamSource("pvm.cfg.xml"); |
参考javadocs包org.jbpm.stream，获得流源的更多类型。 这是一个环境工厂中的默认解析器， 会创建DefaultEnvironmentFactory. 这个主意是我们也会支持spring作为Ioc容器，但是这还处于TODO状态。 很欢迎大家在这方面帮助我们：-）。这个解析器可以使用静态setter方法配置 EnvironmentFactory.setParser（Parser）。 11.3. 环境块 一个环境为try-finally块的范围而存在。 这是一个环境块看起来像怎样：
Environment environment = environmentFactory.openEnvironment();
try {
...
} finally {
environment.close();
} |
环境块定义了另一个生命部分：block环境。 一个事务可以一个定义在块环境中的对象的 常用例子。 在这样一个块中，对象可以通过名称或类型在环境中查找到。 如果对象可以从环境中通过environment.get（String name） 或<T> T environment.get（Class<T>） 找到。 当一个环境被创建时，它拥有一个process-engine环境 和一个block 环境。 在默认实现中，process-engine环境和 block环境是WireContext. 一个WireContext包含对象如何创建和 如果绑定到正式的对象图中。 11.4. 实例 为了启动简单实例，我们会需要一个Book：
public class Book {
...
public Book() {}
...
} |
然后让我们创建一个环境工厂，知道如何创建book
static EnvironmentFactory environmentFactory = EnvironmentFactory.parseXmlString(
"<jbpm-configuration>" +
" <process-engine>" +
" <object name='book' class='org.jbpm.examples.ch09.Book' />" +
" </process-engine>" +
"</jbpm-configuration>"
)); |
现在我们会创建一个环境块，使用这个环境工厂， 我们会查找环境中的book. 第一次会使用类型查找，第二次会使用名称查找。
| Environment environment = environmentFactory.openEnvironment();
try { Book book = environment.get(Book.class);
assertNotNull(book); assertSame(book, environment.get("book")); } finally {
environment.close();
} |
为了防止这样，你需要把环境作为一个参数传递给所有方法， 当前的环境被维护在一个threadlocal栈中：
| Environment environment = Environment.getCurrent(); |
11.5. 环境 环境可以动态被添加和删除。 任何东西都可以暴露为一个Context.
| public interface Context { Object get(String key);
<T> T get(Class<T> type);
Set<String> keys(); ...
} |
当在环境中执行一次查找，这里有一个默认的搜索次序 哪些环境会为请求的对象检测。 默认次序与环境添加的顺序相反。 比如，如果一个对象被定义在流程引擎环境和块环境中， 块环境被认为更适用的，会被首先检测。 可选的，一个默认的搜索次序可以被传递给get 作为一个可选的参数。 |
| 
496
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
