基于動態代理的ＢＰＥＬ恢復機制
2009-01-01 00:00:00周如民陳平鮑亮胡圣明康春農
計算機應用研究 2009年5期
(西安電子科技大學 軟件工程研究所 西安 710071）
摘 要：提出了一種基于動態代理的方法來提高流程的可靠性。該方法使用面向方面技術擴展BPEL引擎來攔截調用伙伴服務，并由動態代理與伙伴服務交互。如果伙伴服務失敗，則動態代理動態地發現并調用等價服務。動態等價服務發現結合了傳統的基于關鍵字的服務發現和基于本體的服務發現兩種技術。采用消息轉換機制來解決失敗服務與替換服務之間接口不匹配的問題。此外，還提供了基于瀏覽器的管理界面來幫助設計人員管理替換服務和消息轉換規則。最后，通過實驗分析表明該方法是一種可行的方案。
關鍵詞：Web服務業務流程執行語言； 動態代理； 面向方面編程； 服務發現； 消息格式轉換
中圖分類號：TP311文獻標志碼：A
文章編號：1001-3695(2009)05-1770-04
Dynamic proxybased recovery mechanism for BPEL
ZHOU Rumin CHEN Ping BAO Liang HU Shengming KANG Chunnong
（Software Engineering Institute Xidian University Xi’an 710071 China）
Abstract:This paper proposed a dynamic proxybased approach to enhance the reliability of BPEL process extended the functions of BPEL engines available through AOP to intercept the invocation of partner services and made the dynamic proxy control the interaction with partner services. If a partner service failed the dynamic proxy would dynamically discover and invoke its equivalent service. The implementation of alternate service discovery combined the traditional service discovery based on keywords with the service discovery based on ontology. Developed message transformation mechanism to deal with possible interface mismatches. Additionally provided a browserbased administration interface that allowed designers to manage alternate services and message transformation rules. Finally used experiments to demonstrate that the approach proposed is feasible.
Key words：WSBPEL; dynamic proxy; aspectoriented programming(AOP); service discovery; message transformation
0 引言
面向服務計算是一種新的分布式計算范型，能夠通過組合網絡上的服務以快速、低成本地構建分布式組合應用。服務是自描述的和與平臺無關的計算單元。Web服務是目前實現服務廣泛采用的技術，它采用開放的標準協議，包括SOAP(simple object access protocol)、WSDL(Web services description language)和UDDI(universal description、discovery and integration)等。WSBPEL[1，2]已經成為當前Web服務組合的事實標準，可以將相關的Web服務組合成大粒度和更有價值的服務。這個組合的服務稱為BPEL流程，被組合的服務稱為伙伴服務。BPEL提供了變量、順序、分支、循環、異步消息、流程關聯集、事件處理、補償處理和異常處理機制等。BPEL規范由BEA、微軟和IBM共同發起制定，于2003年開始由OASIS組織發布標準。
BPEL流程通常組合很多Web服務，通過Internet與這些服務進行通信。Web服務是分布的、異構的和自治的，并由不同組織進行開發和維護，這些特點使得基于服務的流程非常脆弱，很容易出現異常。在這種情況下，需要動態地發現失敗服務的等價服務(等價是指兩個服務實現相同的功能，但它們的接口可以不一致)，并用其來代替失敗服務執行。隨著SOA技術的廣泛應用，Internet中的具有等價功能的Web服務數量迅速增加，而Web服務本身具有動態性和易變性的特點，這就使得在設計流程時不可能將伙伴服務的等價服務全部羅列出來。為了解決這些問題，本文提出了一種基于動態代理的方法，能夠動態地發現和調用等價服務。如圖1所示，當調用服務容器SC1中的服務S1發生異常時，動態代理使用服務容器SC2中的服務S1來代替其執行。
Ezenwoye等人提出了用代理服務代替失敗服務執行的RobustBPEL[3]和RobustBPEL2[4]。Baresi等人提出了一種BPEL自愈的解決方案Dynamo[5]，為用戶提供了領域規范語言WSReL(Web service recovery language)定義服務異常恢復規則。當伙伴服務失敗時，RobustBPEL和Dynamo是通過硬編碼的形式將替換服務寫入配置文件，不能在流程運行時修改，而RobustBPEL2可以動態地發現等價服務，但要求伙伴服務與替換服務具有相同的接口。如果兩者接口不匹配，則需要預先為替換服務提供一個包裝接口，這種方式使得新發現的具有等價功能而與伙伴服務接口和包裝接口不同的服務不能作為替換服務。陳今梁等人提出了一個WSBPEL流程的運行時監控方法[6]，該方法采用AOP技術擴展BPEL引擎，實現監控功能，從而能夠靈活監控WSBPEL流程的執行，但該方法不具有恢復能力。
本文提出的基于動態代理的方法是通過AOP技術擴展ActiveBPEL[7]的功能，使之具有動態恢復的能力。動態代理能夠進行動態服務發現、服務相似性搜索、等價服務選擇和服務管理等。本文的主要工作包括以下幾個方面：a)采用AOP技術擴展BPEL引擎的功能，可以不修改BPEL引擎源代碼就具有動態恢復機制；b)采用基于關鍵字的服務發現和基于本體語義的服務發現相結合的方法，提高服務發現的準確率；c）提出一種基于消息格式轉換的機制來解決服務接口不匹配的問題；d)提供基于瀏覽器的管理界面來管理替換服務和消息轉換規則。
1 動態代理
BPEL規范提供了錯誤處理器、補償處理器和事件處理器用于設計異常處理和恢復策略。流程設計人員在編寫流程時需要考慮所有可能的錯誤并設計相應的處理策略。通過這種方式，如果流程在運行時發生錯誤就可以根據事先設計好的策略進行恢復處理。流程的異常處理策略完全由設計人員來設計會存在一些問題：a）流程設計人員往往不會把所有錯誤狀態都考慮到，如調用伙伴服務時，出現一個網絡通信異常，而這個異常又沒有被〈catch〉捕獲，這就可能導致整個流程運行失敗；b）如果所有的異常處理都放到BPEL流程中會導致流程的設計非常困難，也使得流程過于復雜和難以維護;c）BPEL規范的三種處理器的功能非常基礎，不能為設計人員直接提供更高級的恢復策略，如服務替換策略、設計人員設計異常處理和恢復策略完全依賴于個人經驗和掌握BPEL規范的程度。
通過兩種不同的策略可以解決上述問題：a)擴展BPEL規范，通過增加新的BPEL構建器或擴充已有構建器的屬性來增強其處理能力。這種方式的缺點是必須修改BPEL引擎的源代碼，由于該方式改變了 BPEL元素的層次結構。目前幾乎所有的BPEL引擎對層次結構的遍歷都是采用visitor模式[8]，這會導致BPEL引擎需要修改的代碼量是難以估計的。b)擴展BPEL引擎，通過為引擎增加新的模塊自動地執行恢復策略。這種方式也需要改變BPEL引擎，但通過AOP技術可以將新代碼直接植入到BPEL引擎中，而不需要修改原有的源代碼。針對不同的BPEL引擎，只需要定義不同的aspect，然后將代碼植入到引擎中就可以使之具有異常處理和恢復的能力。
本文提出的動態代理采用了第二種解決方案，通過AOP技術為BPEL引擎提供動態恢復的能力。
1.1 體系結構
動態代理體系結構如圖2所示。通過AOP技術對BPEL引擎進行擴展，攔截對伙伴服務的調用請求，由動態服務代理來控制與伙伴服務的交互。動態代理在結構上分為兩層，即運行時層和核心層。運行時層主要負責與伙伴服務交互，當伙伴服務失敗時，從核心層獲取并執行失敗服務的等價服務。為了方便敘述，將BPEL流程中調用的伙伴服務稱為標準服務，與標準服務等價的服務稱為替換服務。核心層主要負責動態地發現標準服務的替換服務、管理標準服務與替換服務的消息轉換規則和按照某種策略返回替換服務。核心層可以獨立于運行時層運行，其目的是將發現服務階段與使用服務階段分離。核心層可以在流程未運行或運行過程中，在UDDI注冊中心動態地發現標準服務的替換服務。當標準服務失敗時，動態服務代理使用已經搜索的替換服務執行。這樣可以大大縮短獲取替換服務的時間，從而減少流程的執行時間，提高運行性能。
運行時層包括動態服務代理組件、服務調用組件、異常分析組件和消息格式轉換組件。動態服務代理組件將服務請求交給服務調用組件以獲取服務的運行結果。當調用服務出現異常時，動態服務代理組件首先通過異常分析組件獲得異常類型，通過服務選擇組件獲得替換服務和消息轉換規則，然后再通過服務調用組件執行替換服務。
核心層包括動態服務發現組件、服務管理組件和服務選擇組件。動態服務發現組件首先從BPEL描述文件中找出所有的標準服務，然后以標準服務為參考從UDDI注冊中心搜索與之相似的服務。服務管理組件負責管理由動態服務發現組件搜索到的服務，并負責管理標準服務與替換服務之間的消息轉換規則。服務選擇組件首先根據動態服務代理組件提供的服務標志信息，通過服務管理組件找到對應的替換服務，然后根據選擇策略返回相應的服務。
1.2 服務調用攔截
通過AOP技術可以在不改變BPEL引擎源代碼的情況下，通過植入代碼增強其功能。本文采用的BPEL引擎是ActiveBPEL，通過AspectJ將服務調用攔截作為橫切關注點引入到引擎中。ActiveBPEL為活動定義兩個類層次結構：一個是以AeActivityDef類為基類的層次結構，該結構與BPEL規范定義的活動一一對應，流程部署就是將BPEL文件轉換成該內存結構；另一個是以AeActivityImpl類為基類的層次結構，該結構是運行時使用的結構，當執行流程時引擎首先將AeActivityDef層次結構轉換成AeActivityImpl層次結構，然后采用visitor模式遍歷。AeActivityImpl類為活動的執行定義了一個通用的接口。其中包含execute方法，各個子類重置該方法的實現來定義自己的具體操作，如scope活動為內部定義的變量分配存儲空間，invoke活動執行外部服務調用。
本文僅考慮流程與伙伴服務交互時出現的異常，所以只需要在流程執行invoke活動進行攔截。為此對AeActivityInvokeImpl類的execute方法設置around類型的切入點，以便于最大程度地控制活動的執行。一旦ActiveBPEL引擎執行invoke活動，正常執行被攔截，控制權交給動態服務代理。該組件負責與伙伴服務進行交互，當出現異常時進行相應處理。
1.3 異常分析
根據BPEL流程中異常的來源不同，將異常分成三類：a)流程異常。由于BPEL流程設計時的疏忽而導致的語法錯誤，如使用了未定義的變量或者BPEL構建器的名字不正確等錯誤。b)邏輯異常。伙伴服務的接口描述文件中對操作定義的異常，這些異常通常是由服務提供者為了區分不同的錯誤情況而有意拋出的異常。c)系統異常。調用伙伴服務時出現的除了邏輯異常以外的異常，這些異常包括非人為異常和人為異常。其中非人為異常一般是由于網絡故障、服務所在機器的操作系統錯誤、數據庫出錯或機器出現硬件故障等引發的異常。人為異常是指服務提供者在維護服務的過程中，撤銷了原來的服務或為了服務功能的需要修改了服務的接口信息等引起的異常。這幾類異常都會導致流程不能夠正常運行。
對于不同的異常類型采用的處理方法也不相同。a)流程異常是由于流程有語法錯誤導致的，可以采用錯誤預防的方法。目前有很多BPEL流程設計工具，包括ActiveBPEL設計器、Eclipse BPEL設計器和OracleBPEL設計器，這些工具都提供了對BPEL流程的基本語法檢查，能夠很好地排除流程的語法錯誤。b)邏輯錯誤是由服務提供者有意拋出的，如銀行的取款服務，當客戶取款的金額大于賬戶余額時會拋出InsufficientException。這類異常的處理往往與業務規則有關，其屬于流程設計的一部分，所以由流程設計人員通過BPEL規范提供的異常處理器設計處理策略。c)系統異常是由于Web服務本身的特點決定的，筆者采用容錯的方法來解決。此類異常只表示當前調用的服務不能訪問，并不意味著其他與之等價的服務也不能訪問，所以可以使用等價服務來代替失敗服務來提高流程的可靠性。本文提出的動態代理用于處理系統異常，能夠動態地發現和調用失敗服務的等價服務。
異常分析組件的功能是分析當前出現異常的類型，即邏輯異常或系統異常。首先采用WSDL解析器分析失敗服務的WSDL文件，獲得該服務定義的邏輯異常，然后判斷當前的異常是否屬于邏輯異常，如果是則返回邏輯異常類型，否則返回系統異常類型。
1.4 動態服務代理
動態服務代理是動態代理框架的外觀控制器[9]，服務調用攔截模塊只需要與該模塊進行交互。其主要職責是整合其他各模塊的功能，實現流程的自動恢復。動態服務代理的工作方式為：動態服務代理得到控制權后，通過服務調用模塊與伙伴服務進行交互。如果服務執行成功，則動態代理什么也不做。當調用服務出現異常時，動態服務代理組件首先通過異常分析組件獲得異常類型，如果異常為邏輯異常，由于該類異常的處理屬于業務流程的一部分，并且流程設計人員已經在流程中設計了相應的恢復策略，動態代理不處理該異常，而是由BPEL流程中的異常處理器進行處理。如果異常為系統異常，則需要找到該失敗服務的一個替換服務來執行。動態服務代理首先通過服務選擇組件獲取當前失敗服務的替換服務和相應的消息轉換規則；然后調用消息格式轉換組件將失敗服務的輸入消息轉換成替換服務的輸入消息，通過服務調用組件調用替換服務；最后在服務調用組件返回服務執行結果后，動態服務代理組件將替換服務的返回消息再轉換成失敗服務的輸出消息格式。這樣，動態服務代理通過與其他模塊相互配合實現了在調用伙伴服務失敗時的自動恢復處理。
1.5 動態服務發現
傳統的Web服務發現手段是基于UDDI系統，但UDDI提供的Web服務查詢只是簡單地基于關鍵字的語法匹配，缺乏語義信息，所以得到的服務可能不是用戶想要的。
語義以本體(ontology[10])技術為基礎，從具體的應用領域中抽取出共用的概念和術語，建立它們之間的關系，從而為該領域提供可被共享和復用的領域知識和詞匯，使得領域內對領域知識形成一致的理解。
本文提出了將傳統服務發現與本體語義相結合的方法，如圖3所示。該方法將服務發現分成兩個階段：a)采用基于關鍵字的搜索從UDDI得到一系列Web服務；b)以標準服務為參考，采用基于語義的方法，從a)得到的Web服務中搜索相似的服務。本文的語義搜索方法是一種輕量級的基于本體詞匯相似度量方法，使用服務的描述信息、名稱、輸入參數和輸出參數的相似性來判斷服務相似性。
圖3中的服務提取模塊根據BPEL文件找出所有的標準服務，通過WSDL文件得到標準服務的服務描述、名稱、輸入和輸出參數；然后通過服務預處理模塊進行必要的預處理，以提高信息的有效性；最后通過數據庫訪問框架將標準服務的信息存儲到本地的服務倉庫中，為服務發現做好準備。
服務預處理模塊從WSDL中提取服務的描述、名稱、輸入參數和輸出參數信息，并對這些信息進行處理。主要包括拆分句子和合成詞、統一詞的形式、替換縮寫詞、去掉沒有意義的詞和根據本體庫將詞替換成標準的語義詞匯等。
服務檢索模塊實現a)的服務搜索，根據標準服務的信息用關鍵字匹配的方法從UDDI注冊中心獲取到一組滿足條件的服務的WSDL文件，交給服務相似性搜索模塊進行b)搜索。
服務相似性搜索模塊實現b)的服務搜索，以標準服務為參考，從服務檢索模塊提供的WSDL文件中搜索與之相似的服務，并將相似服務通過數據庫訪問框架存儲到本地服務倉庫中建立標準服務與其的關聯關系。
數據庫訪問框架用于簡化編寫操作數據庫的代碼，提高數據庫操作的運行效率。本文采用了目前被廣泛采用的Hibernate框架。筆者將一個Web服務抽象成由描述、名稱、輸入和輸出參數組成的實體，可以定義如下：
定義1 一個Web服務可以表示為
WSi=(Di，Ni，Ii，Oi)(1)
其中：Di表示服務的描述集合；Ni表示服務名稱的集合；Ii表示輸入參數的集合；Oi表示輸出參數的集合。
對于兩個服務WSi和WSj的相似度，根據所包含元素的相似度進行計算，給出下面的定義。
定義2WSi和WSj相似度定義如下：
simws(WSi，WSj)=w1#8226;simD(Di，Dj)+w2#8226;simN(Ni，Nj)+
w3#8226;simI(Ii，Ij)+w4#8226;simO(Oi，Oj)(2)
其中:∑4i=1 wi=1，wi表示權重；simD(Di，Dj)、simN(Ni，Nj)、simI(Ii，Ij)和simO(Oi，Oj)分別表示服務描述、名稱、輸入參數和輸出參數的相似度，本文采用文獻[11]的方法對它們進行計算。設定一個閾值，當兩個服務的相似度大于該閾值時，認為這兩個服務為相似服務。
1.6 服務管理
通過動態服務發現組件找到標準服務的相似服務可能有多個，而且兩個服務相似并不能保證它們的功能相同，即使兩個服務語義等價也不能保證它們的功能一定相同。例如用于查詢本地賓館信息的服務，假設有兩個服務提供者，一個是本地的旅行社，另一個是體育協會。旅行社的查詢服務是根據查詢條件返回本地所有滿足條件的賓館信息；而體育協會的查詢服務是根據查詢條件從它規定的本地賓館中查找所有滿足條件的賓館信息。在這種情況下，即使這兩個服務完全相似，也不能用一個服務去替換另一個服務。因此，相似服務是否能夠作為替換服務還需要由服務管理組件來最終確定。
鑒于以上分析，本文采用半自動化的方法來確定標準服務的替換服務。首先采用完全自動化的動態服務發現組件找到標準服務的相似服務，然后由管理員確定哪些相似服務可以作為標準服務的替換服務。服務管理組件包括：
a)服務管理模塊。它負責管理標準服務的替換服務，可以通過兩種方式來添加標準服務的替換服務；（a)當明確知道標準服務的替換服務時，可以直接導入替換服務的WSDL文件來添加替換服務；（b)利用動態服務發現組件找到的相似服務，經過確認的相似服務成為替換服務，同時也可以刪除不正確的相似服務或不再可用的替換服務。針對一個標準服務存在多個替換服務時，可以設置各個服務的優先級。
b)服務緩沖模塊。它用于緩存標準服務和替換服務的信息以提高服務查詢的速度，減少性能開銷。當服務管理模塊對替換服務更新時，此模塊的信息也要進行相應的更新。
c)服務查詢模塊。它負責根據給定的標準服務信息獲得其相應的替換服務列表和相應的消息轉換規則。首先在服務緩沖中查詢，如果信息已經在緩沖區中就直接返回，否則需要查詢數據庫獲得信息。
d)消息轉換規則管理。它用于建立和維護標準服務和替換服務的消息轉換規則。
1.7 消息格式轉換
消息格式轉換組件是一個適配器組件，它使用消息轉換規則來協調標準服務與替換服務接口不一致的情況，對輸入消息和輸出消息進行格式轉換。由于BPEL流程中的invoke活動設置的輸入和輸出變量都是按照標準服務的消息類型定義的，需要將標準服務的輸入消息格式轉換成替換服務的輸入消息格式和將替換服務的輸出消息格式轉換成標準服務的輸出消息格式。Web服務接口描述是基于XML格式的WSDL文件，因此采用XSLT進行消息格式轉換。消息格式轉換包括兩個部分，即制定消息轉換規則和消息轉換。圖4顯示了基于瀏覽器的設計界面，用戶可以通過簡單地建立數據間的映射關系來設計源消息格式與目標消息格式之間的轉換規則，系統會根據建立的映射關系自動生成XSLT轉換規則，從而使得設計人員不需要熟悉XSLT技術就可以建立消息轉換規則。
消息轉換組件負責根據轉換規則將消息格式轉換為目標格式。本文采用適配器模式將目前應用最廣泛的XSLT引擎(Xalan、Saxon和XT)集成到系統中，用戶可以通過配置選擇使用的引擎，如圖5所示。
2 實驗分析
本文提出的動態代理將搜索替換服務與流程運行分成兩個獨立的階段。搜索替換服務階段負責搜索標準服務的等價服務，要求獲得等價服務的準確性盡可能高。在流程運行階段如果調用伙伴服務失敗，則動態代理使用搜索階段獲得的等價服務替換失敗服務執行，要求動態代理對性能的影響盡可能小。鑒于上述原因，本章通過兩個實驗分別對搜索等價服務的準確性和動態代理對性能的影響進行分析。
XMethods[12]發布了大量的Web服務的WSDL文件，從這些服務中選擇了四類服務用于評估搜索服務的準確性，分別為郵編搜索服務(10個)、天氣查詢服務(7個)、短信服務(16個)和email驗證服務(7個)。這四類服務的搜索結果統計如圖6所示。準確率是指針對一個搜索請求提供了正確搜索結果的比例。其定義為：搜索結果中正確的服務個數/搜索結果的服務總數×100%。召回率是指針對某個搜索請求實際產生的正確搜索結果數與應該產生的正確結果的總數的比例。其定義為：搜索結果中正確的服務個數/應該獲得的服務總數×100%。例如，搜索短信服務時，搜索的服務總數為20個。其中包括所有的短信服務(16個)，所以正確率為16/20×100%=80%，召回率為16/16×100%=100%。
申請貸款流程是一個常見的BPEL業務流程的例子[1，2]。申請貸款流程組合了風險評估服務(riskAssessmentService)和貸款評估服務(loanApprovalService)兩個服務。申請貸款流程通過這兩個服務來評估是否批準客戶的貸款申請。具體處理過程為：客戶提出貸款申請，申請信息包括個人信息和貸款金額。通過風險評估服務可知貸款申請的風險度，如果為低風險且貸款金額小于100 000元，則批準貸款申請；否則由貸款評估服務來決定貸款是否批準。風險評估服務和它的替換服務分別簡稱為RAS和AltRAS。假設RAS出現系統異常，則動態代理使用AltRAS代替RAS執行，各組件的交互關系如圖7所示。流程的運行環境是Intel雙核1.80 GHz、512 MB內存和Windows XP操作系統。BPEL流程服務部署在本地，兩個評估服務及其替換服務部署在遠程的計算機上。
運行結果性能比較如8所示，不帶監控表示流程在沒有擴展的ActiveBPEL引擎上運行的統計數據；動態監控表示流程在已經擴展了的具有動態代理功能的ActiveBPEL引擎中運行，并假設風險評估服務和貸款評估服務總是在有一個服務失敗的情況下統計數據。從圖8中可以看出
