IBM WebSphere Developer 技术期刊: WebSphere Business Integration Server Foundation Process Choreographer 中的建模补偿

文档选项 未显示需要 JavaScript 的文档选项

级别： 初级

Susan Herrmann (herrmans@de.ibm.com), 流程编排器开发人员, IBM 德国

2005 年 1 月 01 日

本文描述了什么是补偿以及怎样在几个流程场景下利用 WebSphere® Studio Application Developer Integration Edition 对补偿进行建模。这些信息帮助业务流程建模者在流程中引入补偿。

引言

WebSphere Business Integration Server Foundation V5.1 (以下简称为 Server Foundation) 的流程编排器（Process Choreographer）组件提供了利用业务流程编排企业内部以及企业间的服务的能力，企业间的服务包括人力和 IT 资源。流程编排器支持在 J2EE™ 环境中运行业务流程执行语言（BPEL）进程，并允许你将业务流程技术和由 J2EE 架构提供的并从 Server Foundation 获取的其它服务进行组合。

流程编排器中的业务流程由多个所谓的“活动”互相连接。活动可以有多种类型。一个非常重要的活动类型是调用活动，用于调用 Web 服务，Web 服务可以被实现为 EJB 组件或其它流程。

业务流程可能需要几天、几月甚至几年来完成，因此，有可能单个活动在整个进程结束前完成（根据已提交的事务控制）。如果某个事件或错误发生而导致流程取消，已经完成的活动需要被复原。这里就需要补偿支持来完成这一任务。

本文描述了什么是补偿以及怎样在几个流程场景中利用 WebSphere® Studio Application Developer Integration Edition 对它进行建模。这些信息将帮助业务流程建模者在流程中引入补偿。可以在 WebSphere Studio 信息中心找到关于在 WebSphere Studio Application Developer Integration Edition（后面简称为 Integration Edition）内业务流程建模以及在 Server Foundation 上运行业务流程的基本信息。 (参见 参考资料。)

(Server Foundation 的补偿功能并不是 BPEL 补偿规范的实现，尽管它实现的是这个功能。)

回页首

流程编排器中的补偿

利用 Integration Edition BPEL 流程编辑器，业务流程建模者可将多个活动组合为一个业务流程。通过编辑流程和活动的属性，建模者控制了流程的补偿行为。

补偿用来还原已经完成的活动。一旦补偿被触发，整个流程都被补偿。即，一旦进行补偿，它就要补偿流程中已经运行完成的所有活动。

哪一个行为需要补偿由活动来定义：调用活动通过一个服务来定义在活动的 forwards 进程中将调用哪个进程。为实现补偿，这些服务被称为活动的 “forward” 服务或 “do” 服务。活动同时还有一个服务用来定义流程的补偿中将调用哪个服务。“补偿”服务负责还原 forward 执行的行为。

补偿服务和其它服务一样，它是个 Web 服务，需要一个输入消息。补偿服务需要一个操作来还原调用活动的 forward 服务所做的改变。

带有补偿服务定义的调用活动的 forward 服务和补偿服务本身必须与 Web 服务调用框架（WSIF）绑定同步。即，服务被请求/响应操作调用，服务的结果通过操作马上返回到调用者。这种调用的发生不需要回复机制。 EJB 操作的调用是同步的，JMS 绑定的操作是异步的，因为请求被放入一个队列并且回复流程通过发送消息到另一个队列来触发。

补偿服务的输入消息是特定变量数据在相应的 forward 服务成功完成时刻的快照。您可以明确定义补偿服务的输入消息。如果你不打算这么做，流程编排引擎将利用 forward 服务的输入和输出消息的不服那作为补偿服务的输入。（参见 参考资料。）

补偿服务的返回消息、流程的输出消息不会对流程产生任何影响，因此被流程编排引擎丢弃。由于补偿服务在运行时有一个相关的、不变的输出消息，它的输出消息可能从来不被使用，如作为其它补偿服务的输入。

让我们看一下包含如下服务的旅行预定流程：

• 预定旅馆。
• 租赁汽车。
• 预定飞机。
• 发送确认函。

假设流程中的旅馆和汽车租赁已经成功完成，并且这些结果已经提交。假设飞机预定失败，你需要复原成功完成的预定使得系统回到它的初始状态。这就可以通过添加补偿服务来实现。

在旅行预定流程中，需要定义如下 forward 服务和补偿服务：

表 1. 旅行预定流程中的 forward 服务和补偿服务

图 4 显示了 BookHotel 调用活动中定义的 forward 服务。

图 5 显示了 BookHotel 活动的补偿属性面板中定义的补偿服务。

定义补偿服务并不能够确保在某个失败发生的时候触发补偿。在实际开始补偿的时候必须得到一个 "Compensation Sphere"，它由一个名为 Compensation Sphere 的进程属性来控制。在进程执行期间，补偿服务注册到 Compensation Sphere 。Compensation Sphere 负责当补偿被触发的时候调用注册的补偿服务。

Compensation Sphere 被定义在流程级别 (图 7)。

有多种方法来设置 Compensation Sphere 选项。在图 7 中，我们为了确保得到 Compensation Sphere ，因此选中 Requires New 选项，通知服务器为此流程创建新的 Compensation Sphere。（如果是 Not Supported，流程将在没有任何 Compensation Sphere 下运行，即补偿永远不会进行，即使补偿服务被定义。）

当运行旅行预定流程，与成功执行的 forward 服务相关联的补偿服务以及补偿服务的输入消息被注册到 Compensation Sphere 。因此，这就确保了当需要补偿时，只有已经完成的 forward 服务的补偿服务被执行。

如果业务流程成功完成，则不需要补偿，所有注册的补偿服务将被删除。

如果补偿被触发，补偿服务被调用的顺序与它们在 Compensation Sphere 注册的顺序相反。当所有注册的补偿服务被成功执行，则补偿完成。

如果在补偿服务的调用过程中发生失败，流程的补偿进程将被停止，并需要人工交互来重新启动。这一任务通过业务流程 Web 客户的修复控制台来实现。在后面还要深入讨论 修复控制台。

回页首

业务流程中的与补偿相关属性

在流程建模期间就要对决定应用到流程及其活动的补偿行为进行设置。在这一节，我们将总结控制补偿行为的流程和活动属性。

Integration Edition BPEL 流程编辑器中的以下属性将影响补偿：

• 执行模式（Execution Mode） (流程属性)
• 自治（Autonomy） (流程属性)
• 补偿范围（Compensation Sphere） (流程属性)
• 活动参与事务（Activity Takes Part in Transaction） (活动属性).

执行模式

流程的执行模式可以是长期运行或微流。执行模式并不是一个特定于补偿的属性，但它却对补偿行为具有影响。以一个长期运行的流程为例，为在 Integration Edition BPEL 的流程编辑器中设置执行模式，在流程的服务器属性面板中选择 Process is long-running 选项（如图 9 所示）。

长期运行的过程意味着可以被中断，这一点可以通过持久化流程状态和在多个事务下组成流程活动来实现。一个长期运行的流程，也就是一组连接的导航事务。导航事务被流程编排引擎用来执行诸如变量更新等任务。另外，导航事务可能将调用服务的操作分开，但它不得不这么做。调用服务同样也可以在它自身的事务控制下运行，在这种情况下，如果通过事务行为来调用 EJB 操作来设置 它的发布描述符中的 RequiresNew。如果补偿被触发，它将跨越此刻并未参与运行的导航事务的 forward 服务或者已经提交的 forward 服务。

微流流程执行模式指的是整个流程运行在一个事务中。微流是一个短期运行的操作，它不允许被中断且不保持任何流程状态。如果在微流处理中发生失败，则将会导致导航事务的回滚，在此导航事务下的所有 forward 服务都将回滚。补偿仅需要处理那些没有参加导航服务的 forward 服务，或者只有非事务的工作才需要补偿。

自治

流程可以嵌套，即一个流程在执行过程中可以控制其它流程。在流程建模期间，即将定义这一被调用的流程运行在哪一自治下。有两种类型的自治：peer 和 child 。流程的自治规范与补偿无关，但它对补偿产生影响。

一个 peer 自治的流程完全独立运行，即调用流程并不会将上下文或生命周期操作如终止或删除传播给 peer 流程。以 peer 的方式调用，流程需要自己负责补偿，即它必须拥有自己的补偿范围。

自治规范仅应用与长期运行的流程。自治在服务器属性面板来定义。（如图 9 所示）。

如果一个被调用的流程有自治的 child，child 将加入父流程的补偿范围。微流被看作一个独立的 child。带有单向操作接口的长期流行的流程必须是一个 peer 流程。

不被其它流程调用的流程称为顶级流程。通过 child 自治来调用其它流程的流程被称作被调用流程的父流程。

补偿范围

补偿范围负责调用注册的补偿服务，这些服务通过补偿范围属性来定义。例如，补偿范围将负责进程内以及它调用的进程的所有补偿服务。补偿范围可以被禁止，因此不管补偿服务是否被定义，都不会发生补偿。

对于特定的流程，在Integration Edition 的服务器属性面板（如图 9 ）中可以为 Compensation Sphere 设置 4 个值。 这些值与执行模式和自治属性密切相关，如表 2 所示。

表 2. Compensation Sphere 属性值

参与事务的活动

活动的事务参与属性指示流程编排引擎活动对应的 forward 服务是否需要加入流程编排引擎的导航事务。

补偿需要知道 forward 服务是否已经加入导航事务，因为如果服务已在导航事务内被回滚的话，它就绝不能够再进行补偿。因此。活动的事务参与属性对于补偿行为具有影响，只要导航事务没有提交。如果导航事务已经提交，但业务流程在后期失败，同非事务性的服务一样，事务性的 forward 服务的补偿服务必须被调用。（所有补偿服务注册到 Compensation Sphere）。

如果 forward 服务在流程的导航事务内运行的话，设置活动事务参与属性。例如，调用一个微流（或 EJB 操作）就是一个需要检查标志的例子，在操作的部署描述符中有个设置为 Required 的事务属性。对于部署描述符中的事务属性设置为 RequiresNew 的 EJB 操作或非事务性活动就不需要检查此标志。（参阅 参考资料来了解更多活动事务参与属性的信息。）

在我们的示例中，BookHotel 调用活动的 forward 服务是一个事务属性设置为 Required 的EJB 操作，并且在活动的补偿属性面板中选中 Activity Takes Part in Transaction 属性。

SendConfirmation 调用活动的 forward 服务发送一个确认 email 。这一操作在流程的导航服务内不能够被回滚，因此， Activity Takes Part in Transaction 属性不能选中，如图 17 所示。

回页首

在 BPEL 流程中运行补偿的前提

流程的补偿被以下几个条件触发：

• 在一个长期运行的流程中，当发生下列情况，则进行补偿：
  • 错误传递到流程级的错误处理，或没有明确定义错误处理。
  • 通用流程编排 API 提供一个方法来中止流程实例。您可以定义中止时是否需要补偿：terminate(String PIID, boolean doCompenation)。
• 在一个微流流程中，补偿在以下条件下运行：
  • 事务中的微流进行回滚。不在事务中运行的服务必须进行补偿。

补偿中的流程状态

对于长期运行的流程，你可以使用业务流程 Web 客户端来查看流程的这些状态：

• Compensating
  当补偿在长期运行的流程中触发时。补偿正在进行中。
  
  
• Compensated
  补偿已经完成
  
  
• Indoubt
  如果在补偿过程中发生失败。补偿过程需要使用业务流程 Web 客户端修复控制台来手工修复(参见 修复控制台 。)

微流流程和它们的状态是不保持的，因此，你在业务流程的 Web 客户端将看不到正在运行或已经完成的微流流程。然而，如果在微流补偿过程发生失败，你可以利用业务流程 Web 客户修理控制台来手工完成补偿流程。

回页首

几个流程场景中的补偿

在本节，我们将展示几个流程场景并描述如何对每个补偿进行建模，重点描述 Compensation Sphere 的定义，补偿服务、自治和活动事务参与标志。

高级长期运行的流程的补偿

高级流程的自治标志的值与补偿无关。为在高层设置补偿，长期运行过程需要设置以下值：

• Compensation Sphere
  通过设置 Compensation Sphere 属性值为 Requires New 或 Requires 来允许补偿；通过设置 Compensation Sphere 属性值为 Not Supported 或 Supports 来禁止补偿。
  
  
• 补偿服务
  当长期运行的流程失败，每一个需要重置的 forward 服务需要带有输入消息定义的补偿服务。
  
  
• 活动事务参与属性
  就像前面提到的，如果 forward 服务在流程的导航服务内运行，则选择此属性。

高级微流流程中的补偿

正如前面提到的，自治标志与补偿无关。对于微流，它仅支持 2 个 Compensation Sphere 属性。应用下面的值来设置补偿：

• Compensation Sphere
  通过设置 Compensation Sphere 属性值为 Requires 来允许补偿；通过设置 Compensation Sphere 属性值为 Supports 来禁止补偿。
  
  
• Compensation Service
  微流总是运行在导航事务中。如果事务回滚，事务内所有 forward 服务执行所造成的改变都将回滚。只有不在导航服务内执行的 forward 服务才需要一个定义了输入消息的补偿服务。
  
  
• 活动参与事务
  正如前面提到的，如果 forward 服务在流程的导航服务内运行，则选择此属性。对于高级微流，仅对导航事务控制外的服务定义补偿服务。为实现这一点， 活动参与事务 应该不被选中，对于每一个定义的补偿服务。

调用 peer 自治流程中的补偿

本节描述在设置为 peer自治 的流程中的补偿是如何工作的。

微流总是调用依赖 child 。因此，调用 peer 自治流程的总是 长期运行的流程。

• Compensation Sphere
  通过设置 Compensation Sphere 属性值为 Requires New 来允许补偿；通过设置 Compensation Sphere 属性值为 Not Supported 来禁止补偿。如果补偿被允许，这一自治 peer 流程将打开自身的 Compensation Sphere 。即父流程相对于 peer 流程运行在一个运行在一个不同的独立的 Compensation Sphere 。当父流程开始补偿，peer 流程的补偿服务将不会被调用。
  
  
• 补偿服务
  当长期运行的过程失败需要一个定义了输入消息的补偿服务时，每一个 forward 服务都需要复原。
  
  
• 活动参与事务正如前面提到的，如果 forward 服务在流程的导航服务内运行，则选择此属性。

被调用的长期运行子流程的补偿

下面是长期运行流程的补偿设置，它被 child 自治的其它流程调用。

首先，必须了解在 peer 自治下每次通过异步（单向）接口来调用长期运行过程，即使在流程建模中定义为 child 自治。这种一个常见的例子便是从微流中调用长期运行过程。由于微流只能够异步地调用长期运行过程，这些调用过程总是 peer 。这中流程的补偿行为前面已经描述。

下面这些值只用在长期运行的子过程，它们通过异步接口被长期运行的流程调用。

• Compensation Sphere
  子流程加入到它父亲的 Compensation Sphere 。Compensation Sphere 在这种情况下被用来通知流程编排引擎是否子流程必须支持补偿（意思是，是否拥有 Compensation Sphere），或它能够在没有补偿的条件下处理。如果子流程被设计为它必须有一个 Compensation Sphere，Compensation Sphere 属性被设置为 Requires。如果父流程在这种情况下不能够提供 Compensation Sphere，将抛出一个错误告诉子流程没有 Compensation Sphere 就不能够运行。如果子流程设计为不管它的父流程是否有 Compensation Sphere，Compensation Sphere 属性将被设置为 Supports。
  
  
• 补偿服务
  当长期运行的过程失败需要一个定义了输入消息的补偿服务时，每一个 forward 服务都需要复原。
  
  
• 活动参与事务
  如果 forward 服务在流程的导航服务内运行，则选择此属性。

被调用的微流子流程中的补偿

被调用的微流流程总是以 child 自治的方式运行。为实现补偿：

• Compensation Sphere
  子流程加入到它父亲的 Compensation Sphere 。Compensation Sphere 在这种情况下被用来通知流程编排引擎是否子流程必须支持补偿（意思是，是否拥有 Compensation Sphere），或它能够在没有补偿的条件下处理。
  • 如果子流程被设计为它必须有一个 Compensation Sphere，Compensation Sphere 属性被设置为 Requires。如果父流程在这种情况下不能够提供 Compensation Sphere，将抛出一个错误告诉子流程没有 Compensation Sphere 就不能够运行。
  • 如果子流程设计为不管它的父流程是否有 Compensation Sphere，Compensation Sphere 属性将被设置为 Supports 。
• 补偿服务
  不在导航事务内执行的所有子流程的所有 forward 服务都需要一个带有输入消息定义的补偿服务。如果子微流流程的顶级流程是长期运行的，每一个需要复原的 forward 服务都需要一个带有输入消息定义的补偿服务。因为微流的 child 在长期运行的事务内被执行和提交。如果长期运行的流程需要在后面补偿，调用微流 child 的所有服务都已经提交了，因此，必须被补偿－而不仅仅是那些没有运行在导航事务内的服务。
  
  
• 活动参与事务
  >如果 forward 服务在流程的导航服务内运行，则选择此属性。

回页首

修复控制台

当补偿被触发，Compensation Sphere 以相反的顺序调用注册的所有补偿服务。在成功的完成补偿某服务后，此服务被从 Compensation 移除，下一个补偿服务将被调用。

如果在执行补偿服务的过程中发生错误，Compensation Sphere 停止此流程实例的补偿过程。如果流程是长期运行的，流程实例的状态被设置为 "Indoubt"，对于长期运行的流程和微流，业务流程 Web 客户调用接口来手工修复补偿流程：

• 业务流程 Web 客户的导航面板选择 Undo Actions in Error ，将得到所有失败的补偿服务的列表。你可以找到补偿服务并决定是否尝试重新执行服务，或是忽略它，或者将补偿服务所在的流程实例完全中止。
• 选择 Retry 来再次调用一个失败的补偿服务。如果此服务能够成功完成，所有注册到 Compensation Sphere 的其它 补偿服务将被调用，补偿将继续运行直到完成或另外一个补偿服务发生失败。
• 选择 Skip 将补偿服务从相应的 Compensation Sphere移除。此补偿服务将不会调用，补偿将从注册到Compensation Sphere 的下一个补偿继续执行，补偿将继续运行直到完成或另外一个补偿服务发生失败。
• 选择 Stop 来从相应的 Compensation Sphere移除所有的补偿服务，包括失败的补偿服务。剩余补偿服务的调用将被忽略，因此补偿宣告完成。

假设我们的示例旅行预定流程由于 SendConfirmation 活动中的一个意外而导致失败，活动BookHotel、ReserveCar 和 BookFlight 需要被补偿，因此 Compensation Sphere 调用它们相应的补偿服务。现在假设 ReserveCar 的补偿服务也发生失败，由于旅行预定是长期运行的业务流程 Web 客户中的状态显示为 Indoubt。

要查看失败的补偿服务，可在导航面板（图23）选择 Repair Compensation 按钮或 Error 链接中的的 Undo Actions。

失败补偿服务的活动名将被显示，通过选择一个可用的操作按钮，您可以修复补偿中的问题。

回页首

结束语

本文讲解了如何定义 BPEL 流程的补偿，描述了长期运行流程和微流的补偿行为，并演示了如何修复失败的补偿服务。

参考资料

• 您可以参阅本文在 developerWorks 全球站点上的 英文原文。
  
  
• WebSphere 信息中心
  
  
• Web 服务业务流程执行语言，1.1 版
  
  
• WebSphere Business Integration Server Foundation Process Choreographer
  
  
• 如何组合补偿服务的输入消息？
  
  
• 补偿面板中的 "Activity takes part in transaction" 标志是什么意思？
  
  
• 要了解更多信息，访问 developerWorks WebSphere Application Server zone 和 developerWorks WebSphere Business Integration zone。你将发现大量技术文档、入门教程、教材、下载资料、产品信息和技术支持信息等等。
  
  
• Developer Bookstore。 包含上百种针对开发人员的技术书籍，最高可打 35% 的折扣。
  
  
• WebSphere 论坛。 特定产品的论坛，在那里，你可以提问，并与其它 Websphere 用户交流意见。
  
  
• developerWorks blogs。正在进行，由软件专家自由组成，为您留下了空间 可以添加您的注释。
  

关于作者

		Susan Herrmann 在 Boeblingen 的 IBM 开发实验室的流程编排组工作。她在 Stuttgart 完成信息技术专业的学习并与 2001 年加入 IBM 德国。

对本文的评价

太差！ (1) 需提高 (2) 一般；尚可 (3) 好文章 (4) 真棒！(5) 建议？

回页首