面向服务架构的流程状态保存与恢复方法

1 概述

    传统面向服务架构(Service-oriented Architecture，SOA)由服务提供者、服务注册中心、服务请求者3个部分组成，对其可恢复性研究主要集中在注册中心与服务实例。目前，基于SOA的业务系统，在原有框架上集成了业务流程管理(Business Process Management，BPM)模块，应用分散自治的Web服务，借助Web服务业务流程执行语言(Web Services Business Process Execution Language，WS-BPEL)，实现松耦合的应用平台。鉴于BPM在SOA中起到的关键作用，为了提高业务的连续性，流程执行引擎的可恢复性成为SOA应用的研究热点。由于基于服务的流程非常脆弱，容易出现异常，因此业务流程运行过程中的状态保存与恢复方法是本领域有待解决的关键问题。

    本文基于有色Petri网(Colored Petri Nets，CPN)模型，设计一种多输入多输出(Multiple Input Multiple Output，MIMO)的高可靠流程执行结构。在此基础上提出引擎保存流程执行状态与中间结果的方法，并在流程异常中断时，能够根据保存的信息迅速恢复流程上下文，保证业务的连续性。

2 相关工作

    目前，BPEL流程可靠性和容错性领域的研究工作很多，主要集中在如文献中讨论的单个服务失效时替代服务的动态选择问题上，针对流程出错时状态保存与恢复方法的研究较少。

    开源引擎Active BPEL、Apache ODE和商业引擎Oracle BPM是当前3种主流的BPEL流程执行引擎。3种执行引擎都借助数据库的存储能力，应用持久化技术记录了流程执行状态，但是没有针对应用服务获取恢复执行所需的最小状态集，并不适合流程中断时状态的恢复。

    文献指出Petri网具有并行性、不确定性和异步性等特点，适合描述和分析分布式系统。而文献提出CPN的概念，它可以承载具有类型的数据。基于SOA的业务流程由消息触发服务，而CPN的Token通过定义颜色模拟不同种类的消息，因此CPN更适合业务流程的建模。

3 面向服务架构的高可靠流程执行引擎设计

    本节从适合状态保存的角度定义分布式业务流程，并对引擎进行扩展，设计一种支持状态保存与恢复的高可靠流程执行引擎。

    3.1 分布式业务流程定义

    Petri网由位置、变迁、弧和标记4个元素组成。对于BPEL调用的伙伴服务，用变迁表示其执行，用位置表示服务的前提条件和后续状态，用弧表示流程的执行顺序，用标记表示不同类型的消息，通过消息的传递模拟实际系统的动态运行行为。

    定义1元消息)元消息m为五元组(id，name，type，ms，value)，其中，id标识不同的元消息；name表示元消息的名称；type∈Σ指消息的类型；ms∈M表明元消息所属的消息；value是元消息的值。

    定义2(消息)消息M是分布式业务流程执行环境中状态交换的信息单元，其中，M(m₁，m₂，...，m_n)是元消息在域上的笛卡尔积；根据交互双方的不同，消息可以分为代表伙伴服务之间状态传递的内部状态信息Mi和代表与流程执行引擎之间消息传递的外部交互信息M₀。

    定义3(业务流程)业务流程BP为九元组(P，T，F，Σ，M，C，G，E，I)，其中，(P，T，F，C，G，E)是CPN表示流程的基本结构；Σ为有限非空消息类型集合；M是有限消息的集合；I是消息处理函数。负函数I_-(p，t)表示变迁t消耗位置p的消息资源；正函数I₊(t，p)表示变迁t产生位置P的消息资源。

    3.2 高可靠执行引擎设计

    BPEL流程运行过程中出现的错误可以是调用伙伴服务时产生的程序错误，也可以是引擎框架的未预期错误。流程运行时产生的上下文环境，包括执行状态和中间结果，前者记录流程执行的当前位置，后者记录服务问传递的相关信息。在错误发生时，根据同步记录的流程上下文迅速恢复执行环境是保障分布式业务正确完成的一种重要方法。

    支持状态保存与恢复的高可靠流程执行引擎结构如图1所示，BPEL语言定义的业务流程以组合服务的形式登记到注册中心，当客户向执行引擎提交请求时，引擎通过流程需求描述信息在注册中心选择符合需求的业务流程并返回流程标识。执行引擎根据流程模板生成实例并执行。每次服务成功执行后，在将服务执行结果传递给邻接的伙伴服务的同时，服务调用结果作为流程的中间结果，以消息的形式返回执行引擎并持久化到数据库。当整个实例结束后，将执行结果返回给引擎，至此一个流程实例执行完毕。与其他执行引擎相比，该结构主要在2个方面进行高可靠性扩展：

    (1)在Web服务执行成功后将服务调用结果返回给执行引擎，由引擎持久化到数据库；

    (2)根据实例与引擎的交互情况，由引擎记录下流程的执行状态。

图1 支持状态保存与恢复的高可靠流程执行引擎结构

    Web服务实质上是一个消息处理框架，由消息触发Web服务，并以消息的形式将服务的执行结果传递给邻接的伙伴服务。通过对流程监控，当服务失效时启动备份服务，将存储在引擎数据库的中间结果以SOAP消息的形式发送给服务节点，保证了流程状态的前后一致性。针对执行引擎的失效，根据关联矩阵记录的流程执行状态，由本地或异地引擎解析出流程中断前的执行位置，并通过最小补偿回退的方式继续流程的运行，减少了不必要的补偿操作，且整个过程对用户是透明的。

4 基于MIMO模式的业务流程状态保存与恢复

    常见的BPEL业务流程采用单输入单输出的工作模式，即流程开始时输入请求消息，流程结束时向客户返回应答消息。这样的工作模式将流程运行时的中间信息隐藏起来，不利于流程运行时状态的跟踪。本节基于定义3，使流程支持多输入多输出的工作模式，并采用关联矩阵和变迁状态表记录流程运行时的状态。

    4.1 基于关联矩阵的执行状态保存与恢复

    当BPEL业务流程运行时，伙伴服务间主要包括顺序、并行、选择、循环4种执行顺序。其中，t代表调用Web服务；P代表流程执行时消耗或产生的消息。对于循环结构，采用循环展开方法，将循环分解成选择结构和顺序结构，由于流程模型支持多消息输入结构，变迁序列调用的是同一个Web服务。

    定义4(关联矩阵)BP是一个业务流程网，且P={p₁，p₂，...，P_n}，T={t₁，t₂，...，t_m}，则矩阵C=[c_ij](1≤i≤n，l≤j≤m)是BP的关联矩阵，当且仅当：

    关联矩阵记录了流程中位置和变迁的邻接关系。当cij=-1时，表示消息触发行为；当c_ij=l时，表示行为产生消息。设counter()为计数函数且n≥2，n∈N+，令counter(p_i=1)=a，counter(p_i=-1)=b且counter(t_j=-1)=c，则：(1)当a=0^b=l时，表示P_i为初始状态；(2)当a=1^b=0时，表示P_i为结束状态；(3)当a=l^b=l时，表示顺序执行关系；(4)当a=l^b≥n时，表示并行执行关系，并发度为n；(5)当c≥n时，表示选择执行关系，选择度为n。

    在流程执行过程中，可以通过BPEL提供的错误和事件管理从句以及运行时监控方法对流程进行监控管理。由监控程序得知流程在t_j处出现异常中断，通过最小补偿回退的思想对流程进行恢复。(1)若c=1^b=l，则代表变迁t_j，调用的伙伴服务w，处于顺序执行链路上；(2)若c=l^b≥1，则代表变迁岛调用的伙伴服务w_j处于并行执行链路的一个路径上；(3)若c≥n，则代表变迁t_j调用的伙伴服务w_j处于选择执行链路的一个分支上。

    在恢复了流程执行状态的前提下，提供消息上下文，为备份服务传送中间结果，这是保证流程正确运行的有效方法。

    4.2 基于变迁状态表中阔结果的保存与恢复

    由于BPEL业务流程无论是主动调用，还是被动接收都伴随引擎与服务之间的消息传递，因此消息即是流程的中间结果。

    定义5(变迁状态表)变迁状态表是一个关系数据表，它是变迁t∈T在消息接收域I-和消息产生域，I₊上的笛卡尔积。其中，I_-和I₊域中的元素是服务提供者，或者客户与流程执行引擎之间传递的消息M_o；M_o=M_i+Σm_i，即外部交互信息等于内部状态信息与元消息集的广义和。

    BPEL运行时中间结果的保存与恢复过程如图2所示，执行引擎将从客户端接收到的消息以及I₊中的元素，由decompose()函数分解存储，每个存储单元即是一个元消息。对应Web服务描述语言(WSDL)文档中标签的属性。客户输入的请求信息通常是整个流程运行所需的，并不是每个Web服务都需要的。将消息分解存储，在流程需要时，通过sendms()函数发送元消息到位置p_i处，利用compose()函数与变迁t_j产生的消息组合同时存储到变迁状态表中，避免了消息的冗余传输。BPEL的行为在位置Pi处实现了伙伴服务间的消息传递。当发生流程异常中断时，通过关联矩阵得到出错的变迁岛，在变迁状态表中查找到消耗的消息耽，并利用sendMS()函数触发备份服务的执行，保证流程的继续运行。

 图2 BPEL运行时中间结果的保存与恢复过程

    变迁状态表和元消息表随着流程实例的开始而创建，随着流程实例的结束而销毁。当一个流程模板有多个实例同时运行时，运用实例版本和信息加锁的机制可以很好解决资源竞争的问题。

5 实例分析与性能评价
   
    本节通过经典SOA应用的商务规划，进一步验证BPEL业务流程运行过程中状态的保存与恢复方式，并对其开销进行分析。

    5.1 实例分析

    流程描述了如下场景，用户提交员工资料和出差信息，通过Web服务检索员工的舱位等级，并发地从多家航空公司查找所能提供的机票信息，从中选择票价较低的航空公司，并将确认信息返回给用户直至发送成功。

    该SOA应用支持服务间的顺序、并行、选择、循环的执行关系，不提供流程状态保存的执行引擎，当流程异常中断时，通常需要整个流程重做，带来了不必要的开销。即使应用BPEL自身的恢复机制，由于过多依靠流程设计人员的经验，因此限制了流程恢复的灵活性和高效性。而提供流程状态保存功能的执行引擎将记录执行过程中的最小状态集合，针对异常情况，向备份单元发送状态信息，保证业务连续性，同时提高流程引擎的可靠性，虽然带来了一定的开销，但是为用户可接受的。

    当模拟流程调用AmericanAirlines服务发生超时，通过关联矩阵(见图3)定位到变迁f3出现调用服务异常，由于counter(t₃=-1)=1^counter(p₃=-1)=2，因此说明变迁t₃处于并行执行链路的一个分支，且并行度为2。根据最小补偿回退的思想，在变迁状态表l中查找到t₃I-={AmericanAirlines,FlightDetails}，说明变迁t₃调用AmericanAirlines服务，服务由消息FlightDetails激活；在元消息表2中查找ms字段为FlightDetails的元消息FlightData，由sendms()函数将其发送给备份服务，保证了业务的连续执行。

图3 关联矩阵

表1 变迁状态

表2 元消息格式

    5.2 性能评价

    综合以上分析，提出的业务流程运行过程中状态的保存与恢复方法具有以下特点和性能：

    (1)为流程执行提供多输入多输出结构。这样的执行结构在提高可靠性的同时带来了一定的开销。假设n个伙伴服务按顺序结构组成业务流程，各服务与引擎交互的时间为t_e，各伙伴服务之间的交互时间为t_s，忽略各变迁调用服务的执行时间，则单输入单输出的业务流程执行时间为2t_e+(n-1)t_s。由于分布式环境下t_e与t_s近似相等，在服务与引擎交互的同时向伙伴服务发送流程信息，则多输入多输出的业务流程执行时间为nt_e+(n-1)t_s。

    (2)为流程恢复提供最小状态集合。流程执行过程中只存储应用级的状态信息，包括执行状态和中间结果；当流程恢复时，通过组合元消息向备份服务发送其所需的最小消息集。

    (3)为流程恢复提供本地策略和异地迁移。利用应用与数据分离的2层工作模式，当流程异常中断时，可以根据持久化的状态信息将流程进行本地恢复或异地迁移。

    (4)较优的恢复点目标(Recovery Point Objective，RPO)支持多步回退。在一般情况下，按照最小补偿回退的思想，只需回退到最近的一步操作。由于记录了流程实例执行过程中全状态信息，因此可以由用户干预，实现多步回退。

    (5)较优的恢复时间目标(Recovery Time Objective，RTO)。矩阵和数据表具有处理高效的特点，在发生异常中断时，可以较快查找到流程执行的上下文环境，只需te时间即可完成恢复。

6 结束语

    对于SOA架构下业务流程状态的保存与恢复，通过本文提出的解决方案将执行状态和中间结果集中到引擎，便于流程的统一管理，对于提高业务的连续性具有重要意义。下一步工作是优化保存和恢复协议，使其更好地应用于业务流程执行引擎的容错和容灾中。
 

核心关注：拓步ERP系统平台是覆盖了众多的业务领域、行业应用，蕴涵了丰富的ERP管理思想，集成了ERP软件业务管理理念，功能涉及供应链、成本、制造、CRM、HR等众多业务领域的管理，全面涵盖了企业关注ERP管理系统的核心领域，是众多中小企业信息化建设首选的ERP管理软件信赖品牌。

转载请注明出处：拓步ERP资讯网http://www.toberp.com/

本文标题：面向服务架构的流程状态保存与恢复方法

本文网址：http://www.toberp.com/html/news/1051553506.html