本文介绍了流程同步的建模方法，包括如何通过父子树形结构实现多路径同步，并讨论了异常处理器在流程中的作用，以及如何处理流程中的异常。
7.6. 流程同步
为了进行流程同步建模，在执行中这是一个父子树形结构。 这个想法是执行主路径是树的根。 流程的主路径也被称作流程实例。 当在给定流程定义上启动或创建一个新流程实例时， 执行便被创建。
现在，因为执行的主路径和流程实例是相同对象， 这保证了用法的简单， 在没有同步情况的简单流程下。
基本执行结构的UML类图
[img]/upload/attachment/119389/8ae6df63-cff8-3b4c-b18f-1cb8a464ce0a.png[/img]
图 7.6. 基本执行结构的UML类图
为了建立执行的多同步路径，活动实现比如一个分支或切分 创建子执行， 使用ActivityExecution.createExecution方法。 活动实现比如结合或合并可以停止流程的这些同步路径， 通过调用执行同步的stop方法。
只有叶子执行可以激活，非叶子执行应该不是激活的。 这个执行的树形结构没有坚持一个同步或结合行为的特殊类型。 它从事着分支或和切分 和结合或和合并来使用执行树结构， 用任何方式，他们想定义期望的同步行为。 这里我们看一个同步执行的例子。
执行的同步路径
[img]/upload/attachment/119391/babd6c5c-bed5-3faa-abd4-036e3aa22b0b.png[/img]
图 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方法。
执行的状态
[img]/upload/attachment/119393/e1b2a8f0-bd10-35e7-bb62-564793ccfc9f.png[/img]
图 7.8. 执行的状态
如果一个执行被锁定，修改执行的方法会 抛出一个PvmException，信息会引用真实的锁定状态。 触发事件，更新变量，更新优先级，添加注释 不会当做是修改执行。 子节点的创建和删除也不会检测， 这意味着那些方法可以被外部API客户和活动行为调用， 即使执行在锁定状态。
确保比较getState()和STATE_*常量时 使用.equals，不要使用'=='，因为如果执行从持久存储加载。 会创建一个新字符串，而不是使用常量。
一个执行实现会被锁定：
* 当它结束
* 当它暂停
* 在异步延续过程中
更多的，锁定可以被活动实现使用， 让执行在等待状态下只读，然后为这个执行传递 的外部实例就像这样：
* 一个人员任务
* 一个服务调用
* 一个等待状态当探测器检测一个文件的出现时就结束
在这些情况，策略是外部实例应该获得 执行的完全控制，因为它想要控制什么应该允许，什么不应该。 为了获得那种控制，他们锁定了执行，所以所有内部交互 必须通过外部实例传递。
一个创建外部实例的主要原因是， 它们可以在执行已经执行过还存在。比如， 在服务调用的情况，定时器可以导致执行获得超时转移。 当响应在超时后到达，服务调用实例应该 确认它没有signal这个执行。所以服务调用可以看做 一个活动实例（活动实例） 是对活动每个执行的唯一实例。
外部实例它们自己负责管理执行锁定。 如果定时器和客户端应用结果是选择 外部实例，而不是直接选择执行，然后在理论上是不必要的。 它是从事活动行为实现，无论它希望 执行锁定还是解锁。
为了进行流程同步建模，在执行中这是一个父子树形结构。 这个想法是执行主路径是树的根。 流程的主路径也被称作流程实例。 当在给定流程定义上启动或创建一个新流程实例时， 执行便被创建。
现在，因为执行的主路径和流程实例是相同对象， 这保证了用法的简单， 在没有同步情况的简单流程下。
基本执行结构的UML类图
[img]/upload/attachment/119389/8ae6df63-cff8-3b4c-b18f-1cb8a464ce0a.png[/img]
图 7.6. 基本执行结构的UML类图
为了建立执行的多同步路径，活动实现比如一个分支或切分 创建子执行， 使用ActivityExecution.createExecution方法。 活动实现比如结合或合并可以停止流程的这些同步路径， 通过调用执行同步的stop方法。
只有叶子执行可以激活，非叶子执行应该不是激活的。 这个执行的树形结构没有坚持一个同步或结合行为的特殊类型。 它从事着分支或和切分 和结合或和合并来使用执行树结构， 用任何方式，他们想定义期望的同步行为。 这里我们看一个同步执行的例子。
执行的同步路径
[img]/upload/attachment/119391/babd6c5c-bed5-3faa-abd4-036e3aa22b0b.png[/img]
图 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方法。
执行的状态
[img]/upload/attachment/119393/e1b2a8f0-bd10-35e7-bb62-564793ccfc9f.png[/img]
图 7.8. 执行的状态
如果一个执行被锁定，修改执行的方法会 抛出一个PvmException，信息会引用真实的锁定状态。 触发事件，更新变量，更新优先级，添加注释 不会当做是修改执行。 子节点的创建和删除也不会检测， 这意味着那些方法可以被外部API客户和活动行为调用， 即使执行在锁定状态。
确保比较getState()和STATE_*常量时 使用.equals，不要使用'=='，因为如果执行从持久存储加载。 会创建一个新字符串，而不是使用常量。
一个执行实现会被锁定：
* 当它结束
* 当它暂停
* 在异步延续过程中
更多的，锁定可以被活动实现使用， 让执行在等待状态下只读，然后为这个执行传递 的外部实例就像这样：
* 一个人员任务
* 一个服务调用
* 一个等待状态当探测器检测一个文件的出现时就结束
在这些情况，策略是外部实例应该获得 执行的完全控制，因为它想要控制什么应该允许，什么不应该。 为了获得那种控制，他们锁定了执行，所以所有内部交互 必须通过外部实例传递。
一个创建外部实例的主要原因是， 它们可以在执行已经执行过还存在。比如， 在服务调用的情况，定时器可以导致执行获得超时转移。 当响应在超时后到达，服务调用实例应该 确认它没有signal这个执行。所以服务调用可以看做 一个活动实例（活动实例） 是对活动每个执行的唯一实例。
外部实例它们自己负责管理执行锁定。 如果定时器和客户端应用结果是选择 外部实例，而不是直接选择执行，然后在理论上是不必要的。 它是从事活动行为实现，无论它希望 执行锁定还是解锁。
扫一扫
6451
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
