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.guhuozai8.cn/

本文標題：面向服務架構的流程狀態保存與恢復方法

本文網址：http://www.guhuozai8.cn/html/news/1051553506.html