| 标题 | 基于SOA的工作流补偿机制研究 |
| 范文 | 孔钦 摘要：工作流管理系统通过集成企业内部各种复杂的业务流程，实现流程自动执行，在传统的无纸化办公环境中发挥了很大作用。随着面向服务架构SOA（ServiceOriented Architecture）、网格等概念的提出，工作流管理系统中各个活动节点不再局限于本地的应用程序，而是逐步扩展到网络上的各种个性化服务。工作流节点利用SOA架构发现和匹配相适应的服务资源来完成相关任务。研究了面向服务的工作流异常处理机制，在对现有补偿方法进行总结的基础上，提出了层次性协调框架以应对面向服务的工作流异常情况，保证补偿活动快速准确地并行执行。 关键词：SOA；事务工作流；补偿活动；协调框架 DOIDOI：10.11907/rjdk.151355 中图分类号：TP301 文献标识码：A 文章编号文章编号：16727800（2015）008005203 0 引言 事务概念开始来源于数据库研究领域，提出的目的是为解决数据的出错恢复和并发访问问题。工作流中的活动节点对应的业务过程可部分或完全自动完成。某些特定的应用领域要求节点在执行过程中作为一个整体，要么正确提交、要么回滚退出。针对某些工作流的特定事务特性，人们基于现有的数据库事务模型，提出了各种适合工作流的事务模型，比如多层事务模型、嵌套事务模型、柔性事务模型和分支/汇合事务模型等。 Amit Sheth率先基于高级事务模型概念提出了事务工作流（ Transactional Workflow）[1]概念。事务工作流结合了普通工作流和事务两者特性，既支持业务流程的自动执行，又满足应用程序的事务属性。在事务工作流里，活动节点存在两种事务类型：①适合生命周期短的活动，叫做原子事务类型，节点的执行满足原子性。这类事务执行的特征是allornothing，参与的活动节点或者全部成功执行，或者未执行任何操作；②适合生命周期长的活动，叫做业务事务类型，通过引入调和、补偿等故障处理机制，结合预先设立好的协议，既满足业务流程的事务性要求，也便于其他用户尽快访问活动节点执行时占用的资源。 结合SOA（services oriented architecture）面向服务架构的工作流，重新赋予工作流各个活动节点新的实现形式。传统工作流的活动节点，局限于本地的某个特定的应用程序，系统耦合度高，移植性差。而SOA的引入，则意味着可以选择网络提供的各种服务来实现工作流中活动节点的执行。一旦构建了基于SOA架构的工作流管理系统，不同的功能模块以服务（service）方式呈现出来，服务间使用统一和标准的方式进行通信，具备良好的通信契约和统一的访问接口定义[2]，这种实现方式完全独立于某个硬件平台、操作系统和编程语言，系统耦合度低、实现方式灵活、移植性好。 基于SOA的工作流因为其特有的灵活、多变的流程实现方式，而展现出网状的任务匹配和执行模式：①设定工作流每个活动节点的任务是最顶层任务，基于不同的粒度，可以将各个顶层任务逐步分解成一级、二级等多级子任务，形成结构化的任务分解架构；②最底层的子任务通过各种各样的动态发现和匹配算法，选择最合适的服务资源。不同服务因为相同的接口定义和通信契约，相互之间可以合成、嵌套；③服务提供的运算结果经由结构化的层次返回给工作流节点，保证其快速顺畅进行。 面向服务的工作流体系结构如图1所示。 面向服务的工作流同样必须满足事务性要求，但是它面临的情况却比传统的工作流复杂很多，因为一方面它结合了SOA的松耦合，实现了中立和弹性配置等特性，另一方面还具有更复杂的操作、更广的分布性以及更多的异构性[3]。因此对于长时间运行的工作流，必须充分保证业务过程的事务性，尽量避免回滚和补偿过程。而一旦某个分支活动出现故障时，必须有选择地补偿部分节点以降低整个流程的补偿代价，保证流程快速有效地进行。对于面向服务的工作流而言，补偿会出现各种各样的情况，如何完成某个服务节点的补偿任务已经引起业界的关注。 图1 面向服务的工作流体系结构 本文主要研究面向服务工作流的事务补偿机制，提出了层次性协调框架来保证业务活动的事务性，同时一旦需要执行补偿的时候，快速准确地执行相应的补偿任务。 1 工作流活动节点补偿机制 工作流的某个活动节点有可能出现异常，而在此前已执行结束的活动节点已经对系统产生了一些影响。为此，必须通过执行补偿策略，消除已执行行为产生的影响，才能确保整体流程沿着执行路径继续下去或正常停止。 补偿模式根据补偿节点的多少分为完全补偿和部分补偿两种，如图2所示。图2（a） 回滚所有的节点至工作流的起始点，属于完全补偿。这种补偿模式涉及全部已执行的活动节点，回滚代价大，因为一旦某个节点出现异常，所有节点都必须回滚至原始状态。基于这种模式下处理逻辑比较简单，所以很多节点少、流程简单的工作流会采用这种补偿模式。图2（b） 则描述了部分补偿执行流程。不需要回滚或者补偿所有节点，而是通过设置回滚、补偿点，在故障点和安全点之间建立补偿路径，形成部分补偿。通过有选择地进行部分节点的回滚和补偿，处理突发的异常情况。这种补偿实现起来代价较小，特别适合业务过程中节点没必要进行补偿或者部分已实现的执行结果需要保留等异常情况。但随之而来的是它的处理逻辑必然较完全补偿复杂许多。图2（b）中，在逆向补偿中，结点c2的补偿活动被忽略，直接由结点c3′跳至结点c1′。 针对这两种补偿方法，众多文献对补偿路径执行效率的提高提出了不同解决方法。文献[4]认为对于执行无影响的任务节点和执行结果幂等的任务节点，在补偿图中可以过滤掉这些补偿，进而提高补偿效率。文献[5]提出了“机会补偿”概念，通过将执行和补偿之间的依赖关系显式地明确标识在工作流描述语言中，为补偿过程提供了更多弹性。文献[6]在多层次的事务模型基础上提出了相应的补偿机制，重点强调了嵌套结构下补偿的范围，以上这几种机制通常将工作流看成平坦流图。文献[7]提出了面向复杂事务工作流的层次式失效恢复算法HFR（Hierarchical Failure Recovery）。基于工作流多个层次间具有基于应用语义的依赖关系，很多时候较低层次出现的失效需要传播到较高层次。HFR通过预先配置好子过程的恢复模式，动态确定补偿终止点，为具有不同的子过程及活动提供不同的灵活处理机制，将失效尽可能限制在低层block中，大大提高了补偿执行效率。 图2 Compensate策略 基于SOA的事务工作流由于服务的松耦合性和动态变化性，其补偿模型的建立和补偿过程的执行变得相当复杂。补偿的主要目标就是构建一个正确且代价最小的补偿模型。本文针对这个目标，结合Web service中事务处理的规范，将协调者的角色加入到面向服务的工作流中，通过协调者的中间作用协调事务完成，尽量避免回滚和补偿的执行。当服务节点出现各种各样突发异常情况时，各层的协调者还能利用层次性的框架完成补偿过程。 2 面向服务工作流的协调框架 2.1 协调器结构 协调器主要由4个元素组成：激活服务（Activation Service）、注册服务（Registration Service）、协调服务（Coordination Service）、补偿服务（Compensation Service）。创建和注册服务的机制，涵盖了事务性回滚和补偿问题的解决方法。工作流中各个任务活动节点与底层服务的协调和通信基于这4个服务的通力合作。 协调器兼顾了目前流行的两种协调模型（原子事务协调模型、业务事务协调模型），容许各系统、各平台以事务方式进行互操作。协调器最核心的协调服务模块，既可以用一个结构性的功能程序来实现，也可以以层次性Agent的形式来处理工作流的任务或活动。协调器组织结构见图3。 如图3所示，任务节点和服务节点都由激活、注册、协调和补偿4部分组成。激活服务利用create消息通知协调器即将开始一个新的工作流节点的任务活动，根据该活动的事务要求设置协调协议。激活服务可以为新创建的活动和现有活动的关系建立嵌套关系或上下级关系，以应对一些复杂工作流的嵌套事务性要求。注册服务通过登记（enrollment）和选择（selection），提供任务活动和服务资源注册。对于可补偿或可替代的活动，其对应的补偿或替代服务也被注册到协调器中。协调服务是协调器结构中最核心最重要的功能模块。协调服务主要由两部分组成：①两阶段提交协议的执行：第一阶段通知各服务节点作准备，如果收到所有节点的反馈，进入第二阶段。如果部分服务节点无反馈，则选择其它可替换的等价服务节点。一旦找不到可替换的服务，协调器最后通知任务节点，任务无法完成；第二阶段：当收到所有服务节点都准备好的消息后，协调器通知服务节点执行任务，服务节点执行完成后返回是否执行成功的消息给协调器；②协调补偿服务完成：在服务节点执行出现异常时，协调器执行恢复操作，尽可能撤消其它相关节点已经产生的影响。补偿服务和其它3个服务相辅相成，当某个服务节点无法返回正确结果出现异常情况时，补偿服务负责根据该服务节点生成动态补偿图，并将补偿服务节点地址通知协调器，由协调器来完成补偿。协调过程见图4。 图3 协调器组织结构 图4 协调序列 2.2 层次性协调补偿架构 传统的补偿模式和实现方法不能完全适用于面向服务的工作流。利用层次性的协调模型来协调事务活动和后续补偿活动可以很好地应对松耦合，以及结构复杂的SOA事务工作流中出现的各种突发情况。设计如图5所示的层次性协调架构，包括顶层协调器、子协调器和底层协调器。通过对同一粒度层的服务设置一个相应层次的协调器，使得补偿代价最小、效率最高。 当某一层次的服务节点发生故障无法顺利完成任务时，协调器通过查找该服务节点有无补偿服务节点，动态地确定补偿图。如果没有相应的补偿服务节点，则异常信息和动态补偿图向上一层父协调器传播。父协调器通过查找同一层的服务有无相应的补偿服务节点，决定下一步的操作序列。通过自底向上一直重复这个过程，直至找到可以处理补偿的协调器。最终确定的协调器根据异常信息和得到的动态补偿结构图向部分补偿服务资源发出执行命令，接着选择合适的替代路径保证工作流的继续执行。所有参与补偿服务资源执行后将结果反馈给协调器，协调器将执行结果经由协调树向上反馈给工作流的任务节点，最终完成整个补偿过程。 图5 层次性补偿协调架构（S：SERVICE C：COORDINATOR） 这种层次性的协调架构预先设置好服务的恢复模式和恢复策略，利用自底向上层层传递找到合适的协调器，通过补偿模块动态产生补偿图，确定补偿活动的终止点来完成补偿活动。一旦服务可补偿或者可替换，异常信息就不再向上传播。补偿域尽可能限制在低层的服务中，由底层的协调器处理补偿过程，减少不必要的补偿，提高失效恢复的效率。 3 结语 本文在研究Web service事务处理规范和工作流事务补偿的基础上，提出了针对面向服务工作流体系结构的层次性协调框架，以保证事务补偿活动快速准确地执行。层次性协调框架作为工作流和服务资源的中间件，对活动和资源有效地协调管理，提高了工作流执行效率。 参考文献： [1] A SHETH，M RUSINKIEWICZ.On transactional workflows[J].IEEE Data Engineering Bulletin，1993，16（2）： 3740. [2] M P SINGH， M N HUHNS.Serviceoriented computing：semantics，processes，agents[M].John Wiley & Sons，2005. [3] REN YI，WU QUANYUAN，JIA YAN，et al.A survey of transaction processing technology[J].Journal of Computer Research and Development，2005，42（10）： 17791784 . [4] Global transaction support for workflow management systems：from formal specification to practical implementation[EB/OL].http：//www.docin.com/p973353998.html. [5] M KAMATH，K RAMAMRITHAM.Failure handling and coordinated execution of concurrent workflows[J].Procs.14th Int.Conf.on Data Engineering，Orlando，Florida，USA，1998：334341. [6] P KRYCHNIAK.Bounding the effects of compensation under relaxed multilevel serializability[J].Distributed and Parallel Databases，Kluwer Academic，1996，4（4）： 355374 [7] 任怡，吴泉源，贾焰. 一种层次式的事务工作流失效恢复算法[J].电子学报，2005 （2）：317320. （责任编辑：杜能钢） |
| 随便看 |
|
科学优质学术资源、百科知识分享平台，免费提供知识科普、生活经验分享、中外学术论文、各类范文、学术文献、教学资料、学术期刊、会议、报纸、杂志、工具书等各类资源检索、在线阅读和软件app下载服务。