專利名稱：面向服務組裝的聲明式事務集成方法和系統(tǒng)的制作方法
技術領域：
本發(fā)明涉及一種面向服務組裝的事務集成方法和系統(tǒng)，尤其涉及一種面向服務組 裝的聲明式事務集成方法和系統(tǒng)，屬于計算機服務組裝技術領域。
背景技術：
近年來，Web服務組裝逐漸成為Internet環(huán)境下的應用程序的主流開發(fā)范式。Web 服務是一個平臺獨立、松耦合、自包含、可編程、并依賴于Web技術的服務。Web服務的描 述、訪問、檢索與發(fā)布基于標準XML技術以及一系列的Web技術標準，這些技術及標準有效 地屏蔽了運行環(huán)境的異構性，使得Web服務可以直接部署和運行于Internet之上。由于單 個Web服務往往無法滿足實際需求，因此需要將多個Web服務協(xié)調(diào)與組織起來構造新的Web 服務(復合服務)，支持某個業(yè)務過程。通常，將多個Web服務組裝起來的復合服務稱為基 于Web服務的系統(tǒng)。目前，面向過程的服務組裝相對成熟，如Business Process Execution Language簡稱為BPEL)是一個支持面向過程、可執(zhí)行的Web服務組裝語言，在學術界和工 業(yè)界受到廣泛重視，并有相應的工具支持?；赪eb服務的系統(tǒng)，可以支持快速的業(yè)務重整與優(yōu)化、較好地解決了應用程序 的集成以及數(shù)據(jù)集成等難題。另一方面，與傳統(tǒng)的應用程序相比，基于Web服務的系統(tǒng)的構 造存在很大的區(qū)別。由于Web服務分布在異構的環(huán)境中和不同的管理域中、從屬于不同的 組織機構、面臨不同的授權和安全保護等，基于Web服務組裝的應用程序通常是一個松耦 合的系統(tǒng)。這樣的系統(tǒng)往往描述的是一些非常重要的業(yè)務過程，如銀行支付系統(tǒng)和供應鏈 系統(tǒng)。因此，如何開發(fā)可靠的Web服務組裝、描述一致性的業(yè)務過程是一個重要問題。事務管理是一種用來實現(xiàn)可靠的業(yè)務過程的重要技術。事務是指一系列的操作， 它們按照一種有序的方式改變業(yè)務過程中對象的狀態(tài)。經(jīng)典的事務概念賦予業(yè)務過程一些 非常重要的基本屬性，如原子性指對一個對象的狀態(tài)的改變要么全部發(fā)生，要么什么也沒 發(fā)生；一致性指在事務發(fā)生前后對象的狀態(tài)變化應該是一致的；隔離指一個事務中的對 象的狀態(tài)變化并不影響其它并發(fā)事務中對象的狀態(tài)變化，或者說一個事務中對象的變化對 外是不可見的；和持久性指事務的結果在事務完成后持續(xù)足夠長的時間。經(jīng)典的事務概 念在數(shù)據(jù)庫系統(tǒng)中得到了廣泛的應用，實現(xiàn)相對容易。但在基于Web服務的應用程序中，由 于Web服務部署和運行于一個更加開放、動態(tài)的環(huán)境中，這要求服務組裝具有足夠的靈活 性。例如，某個Web服務可能因為網(wǎng)絡故障突然從業(yè)務流程中退出，如果這種情況發(fā)生了， 服務組裝過程應能請求服務代理搜索一個提供相似功能的Web服務取代已經(jīng)退出的Web服 務。此外，Web服務的事務可能涉及到多個參與實體、跨越多的組織結構、持續(xù)很長時間。因 此，Web服務組裝中的事務概念及其實現(xiàn)變得非常復雜。近年來，服務計算領域推出了一系列面向Web服務的事務框架與協(xié)議，包 括 WS-Coordination(簡稱為 WS-C)，WS-AtomicTransaction (簡稱為 WS-AT)和 WS-BusinessActivity(簡稱為WS-BA)。WS-C描述了一個可擴展的框架以支持多種事務協(xié) 議，定義了事務上下文的結構、事務協(xié)議注冊及事務的激活等服務。WS-AT和WS-BA是兩個典型的面向Web服務的事務協(xié)議族，前者支持簡單的、短周期的原子事務；后者支持長周期 的、復雜的業(yè)務活動。WS-AT和WS-BA可以在WS-C定義的框架下實現(xiàn)。盡管已經(jīng)存在各種 版本的WS-C，WS-AT和WS-BA的獨立實現(xiàn)，但是不存在一個可行的集成方案將服務組裝語言 及事務管理的協(xié)議有效地集成起來，換言之，BPEL和WS-C，WS-AT and WS-BA是分離的面向 Web服務的組裝語言和事務模型或協(xié)議，因而不能有效地支持可靠的Web服務組裝。針對服務組裝語言與面向Web服務的事務協(xié)議之間的集成問題，已有解決方案包 括(1)直接擴展BPEL構造以支持事務概念，該方法需要重新開發(fā)BPEL引擎，如何實現(xiàn)尚 未有報道；(2)基于擴展的BPEL或特定的框架方法實現(xiàn)事務管理的集成，該方法導致BPEL 版本兼容問題及代碼維護的問題；(3)在BPEL過程中直接地實現(xiàn)事務協(xié)議，該方法導致 BPEL規(guī)格說明不易維護，不能集成已有的Web服務的事務框架和協(xié)議的獨立實現(xiàn)。

發(fā)明內(nèi)容
本發(fā)明要解決的技術問題是提供一種集成已有的Web服務的事務框架和協(xié)議的 面向服務組裝的聲明式事務集成方法和系統(tǒng)。為解決上述技術問題，本發(fā)明采用如下技術方案本發(fā)明提供的面向服務組裝的聲明式事務集成方法，包括如下步驟，(1)、對基于服務組裝語言BPEL的服務組裝規(guī)格說明進行預處理，識別并消除不 同活動之間存在的事務依賴；(2)、對預處理后的所述服務組裝規(guī)格說明進行事務策略的說 明和注解，借助ECA定義所述事務處理的規(guī)則，對服務組裝中指定的活動聲明預期的事務 策略，確保被注解的活動遵循一定的事務協(xié)議規(guī)范，預處理后的所述服務組裝規(guī)格說明和 所述事務策略的注解文件形成含事務注解的服務組裝規(guī)格說明；(3)、解釋和執(zhí)行所述含事 務注解的服務組裝規(guī)格說明，完成預定業(yè)務的Web服務組裝。本發(fā)明提供的的面向服務組裝的聲明式事務集成系統(tǒng)，其特征在于包括，服務組 裝規(guī)格說明模塊，為預處理后的基于服務組裝語言BPEL的服務組裝規(guī)格說明，包括活動名 稱、活動運行時信息、事務信息、事務標識號、事務協(xié)議類型、根事務標識號；預處理后的所 述服務組裝規(guī)格說明使得不同活動之間不存在事務依賴；事務策略注釋模塊，為一組以活 動為基本單位的ECA規(guī)則，所述ECA規(guī)則包括事件、條件和動作過程三部分；所述事件為執(zhí) 行BPEL過程時需要捕獲的一些低層事件；所述條件為相關事件觸發(fā)后執(zhí)行事務處理過程 時必須滿足的條件，所述動作為具體的處理步驟；服務組裝引擎模塊，讀取并解釋所述服務 組裝規(guī)格說明；事務管理模塊，偵聽所述服務組裝引擎模塊執(zhí)行中與所述事務處理相關的 事件；在被注解活動執(zhí)行時，讀取所述事務策略注解文件。本發(fā)明提供的面向服務組裝的聲明式事務集成方法和系統(tǒng)，利用現(xiàn)有的服務組裝 引擎和面向Web服務的事務協(xié)議的實現(xiàn)，部分支持服務組裝中自動化的事務設計與執(zhí)行， 增強Web服務組裝的可靠性。一方面，由于事務策略的注解使用聲明式語言，不僅易于應 用，而且支持在BPEL描述的業(yè)務過程中實施增量式的事務集成。另一方面，由于事務協(xié)議 一次實現(xiàn)多次使用、事務策略的修改簡單，實現(xiàn)了高效的事務管理。根據(jù)所述面向服務組裝的聲明式事務集成方法的一種優(yōu)選實施方式，其中，所述 步驟(1)中預處理通過構造BPEL過程的抽象模型實現(xiàn)，基于所述抽象模型識別和消除活動 之間的依賴沖突。
根據(jù)所述面向服務組裝的聲明式事務集成方法的一種優(yōu)選實施方式，其中，所述 BPEL過程的抽象模型記載活動之間至少包括活動名稱、操作、輸入變量、輸出變量、源連接 與目標連接的交互關系。根據(jù)所述面向服務組裝的聲明式事務集成方法的一種優(yōu)選實施方式，其中，所述 步驟(2)中，所述指定的活動為BPEL過程中與遠程Web服務交互的特定類型的活動。根據(jù)所述面向服務組裝的聲明式事務集成方法的一種優(yōu)選實施方式，其中，所述 事務策略的注解由依據(jù)BPEL過程的抽象模型，遵循一種事務策略聲明模板實現(xiàn)；其中，所 述事務策略聲明模板包括活動名稱、活動運行時信息、事務信息、事務標識號、事務協(xié)議類 型、根事務標識號。根據(jù)所述面向服務組裝的聲明式事務集成方法的一種優(yōu)選實施方式，其中，所述 事務策略聲明模板的表示采用XML語法格式；所述事務協(xié)議類型為WS-C或者WS-AT或者 WS-BA0根據(jù)所述面向服務組裝的聲明式事務集成方法的一種優(yōu)選實施方式，其中，所述 步驟(3)中通過定義事務處理規(guī)則的表示結構，解析與執(zhí)行不同的事務策略的處理過程。根據(jù)所述面向服務組裝的聲明式事務集成方法的一種優(yōu)選實施方式，其中，所述 事務處理規(guī)則的表示結構包括事件、條件和動作過程三部分；所述事件指明執(zhí)行BPEL過程 時需要捕獲的一些低層事件，所述條件指明相關事件觸發(fā)后執(zhí)行事務處理過程時必須滿足 的條件，所述動作指明具體的處理步驟。根據(jù)所述面向服務組裝的聲明式事務集成方法的一種優(yōu)選實施方式，其中，采用 BPEL引擎解釋服務組裝規(guī)格說明；采用事務管理模塊管理事務的生命周期；調(diào)用相應地事 務協(xié)議實現(xiàn)聲明的所述事務協(xié)議類型的執(zhí)行。


為了更清楚地說明本發(fā)明實施例或現(xiàn)有技術中的技術方案，下面將對實施例或現(xiàn) 有技術描述中所需要使用的附圖作簡單地介紹，顯而易見地，下面描述中的附圖僅僅是本 發(fā)明的一些實施例，對于本領域普通技術人員來講，在不付出創(chuàng)造性勞動性的前提下，還可 以根據(jù)這些附圖獲得其他的附圖。圖1為本發(fā)明一個優(yōu)選實施例的原理圖；圖2為本發(fā)明一個優(yōu)選實施例的含事務注解的服務組裝規(guī)格說明的運行平臺原理圖。
具體實施例方式下面將結合本發(fā)明的附圖，對本發(fā)明的技術方案進行清楚、完整地描述，顯然，所 描述的實施例僅僅是本發(fā)明一部分實施例，而不是全部的實施例?；诒景l(fā)明中的實施例， 本領域普通技術人員在沒有作出創(chuàng)造性勞動前提下所獲得的所有其他實施例，都屬于本發(fā) 明保護的范圍。為了解決現(xiàn)有技術中服務組裝語言與面向Web服務的事務協(xié)議分離造成不能有 效支持可靠的Web服務組裝的問題，本發(fā)明提供一種面向服務的組裝的聲明式事務繼承方 法和系統(tǒng)。
如圖1所示，本發(fā)明提供的一個優(yōu)選實施例的原理圖，本發(fā)明從復用已有的事務 協(xié)議中間件出發(fā)，重點解決如何將事務設計集成到服務組裝中，從而增強服務組裝實現(xiàn)的 業(yè)務過程的可靠性。該方法通過對BPEL描述的服務組裝規(guī)格說明進行注解，對指定的活動 聲明相關的事務策略，在運行時刻通過復用已有的事務協(xié)議的中間件，實現(xiàn)對所聲明的事 務策略的支持與執(zhí)行。該方法并不擴展服務組裝語言BPEL，因而無須修改BPEL引擎。與傳統(tǒng)的應用程序不同，BPEL描述的服務組裝規(guī)格說明包含對遠程Web服務調(diào)用 的原子活動、以及各種活動之間的控制流。參與事務的對象是Web服務，同一 Web服務的不 同活動之間可能存在一定依賴關系。將事務概念引入到服務組裝中，首先要對服務組裝的 規(guī)格說明進行預處理，即針對給定的一組從屬于同一事務內(nèi)的一組活動，判定注解的合理 性。為此，本發(fā)明構造BPEL過程的抽象模型，開發(fā)識別與化解BPEL過程中活動之間事務依 賴的方法。BPEL過程的抽象模型S描述了一組活動A以及活動間的依賴關系L，表示為S = {A，L}。其中，對于任意的活動a e A，a存在類型Ta并具有如下屬性活動名稱Na ；由Web 服務的某個端口實現(xiàn)的操作OPa，操作OPa輸入變量IVa和輸出變量OVa ；源連接SLa (指明 離開該活動的連接)與目標連接TLa(指明進入該活動的連接)。對于任意的連接Ik e L，Ik具有如下屬性連接名稱Nlk ；連接方向Ikd由兩個活 動al e A與a2 e A確定，其中Ik為活動al的源連接，a2的目標連接；連接條件lk。表明 遷移在活動al e A與a2 e A之間發(fā)生的必要條件。在BPEL過程中，人們只能對特定類型的活動請求事務管理。一個事務中的不同活 動之間不應該存在直接的業(yè)務邏輯依賴，為此本發(fā)明開發(fā)了基于抽象模型的活動依賴沖突 的檢測與化解方法。方法的基本思想是在圖上構造可達路徑集合，然后針對可達路徑上任 意兩個活動B111和an，遍歷am到an的所有連接，檢查是否存在這樣的一個連接lk，使得Ik的 連接條件lk。中涉及活動am的輸出變量，如果存在，則表明存在事務依賴。如果所有的可達 路徑中都不找不到上述連接，則S中不存在事務依賴?；诔橄竽Ｐ偷幕顒右蕾嚊_突的化解方法，該方法借助活動依賴沖突的檢測方 法，發(fā)現(xiàn)存在事務依賴的活動對后，在得到服務組裝的設計人員確認后，將這些活動進行合 并處理。運用上述方法處理后，BPEL描述的服務組裝規(guī)格說明中不再存在活動間的事務依賴。經(jīng)過上述預處理后，可以對BPEL描述的某些活動進行事務策略的注解。BPEL描述 的服務組裝規(guī)格說明中活動的類型包括Invoke，Assign，R印Iy和Receive等，其中Invoke 活動描述了業(yè)務過程與遠程Web服務交互；Assign活動描述了變量之間的值傳遞；Receive 活動負責消息的輸入；R印Iy活動負責消息的輸出；其中，Receive與R印Iy必須匹配。對 服務組裝規(guī)格說明進行事務設計時，應對Invoke類型的活動進行事務策略的注解。為此， 本發(fā)明提出了一種采用XMLSchema形式定義的事務策略聲明模板，其中，activityName指 明了注解活動的名稱。<design-time-info>和<run-time-info>分別用來對服務組裝中活 動的設計時和運行時期望的特性進行注解。由于事務特性屬于活動的運行時特性，因此應 在<run-time-info>中定義。<trans_info>定義了事務策略的注解信息，其中<Trans_ID> 定義了事務標識號，為一正整數(shù)；<Trans_Pr0t0C0l>定義了被注解活動應遵循的事務協(xié)議 類型，包括WS-AT和WS-BA ；<Trans_R00t>定義了被注解活動從屬的根事務。如果該活動所 在事務單元不存在根事務，則<Trans_Root>標識為0。
通過定義<TranS_ID>與<TranS_R00t>，上述事務策略聲明模板支持復雜業(yè)務流 程中嵌套事務的聲明。此外，上述事務策略聲明模板中，事務策略可以與被注解活動的其它 設計時或運行時特性一起定義，如服務的動態(tài)綁定，這意味著本發(fā)明提出的面向服務組裝 的聲明式事務集成方法，可以兼容服務組裝的多種擴展特性。運用事務策略聲明模板，對服務組裝中指定的活動聲明期望的事務策略。本發(fā)明 支持增量式的事務聲明方式。換言之，可以增量地對服務組裝中某個活動追加或修改期望 的事務協(xié)議。事務策略注解完成后，生成一個獨立的XML文件。為了便于運行時支持與執(zhí) 行聲明的事務策略，該XML文件應與服務組裝規(guī)格說明BPEL文件存放于同一目錄下。通過上述步驟，完成了在原始的服務組裝規(guī)格說明中實施事務設計。預處理后的 服務組裝規(guī)格說明與事務策略注解文件一起，形成了含事務注解的服務組裝規(guī)格說明。為 了解釋并執(zhí)行所聲明的事務策略，本發(fā)明采用ECA (事件-條件-動作)規(guī)則為每個被注解 的活動明確地定義事務處理規(guī)則，其中，事件為BPEL過程運行過程中需要捕獲事務處理相 關的一些事件，包括 ActivityEnableEvent、ActivityExecStartEvent 等事件類型，其中， “ActivityEnableEvent” 指當前被解釋的活動可以執(zhí)行，"ActivityExecStartEvend^i 前活動執(zhí)行已經(jīng)開始；條件為包括活動執(zhí)行前必須滿足前提條件和活動執(zhí)行后必須滿足的 后置條件；動作為響應事件而執(zhí)行的一系列處理步驟。在服務組裝規(guī)格說明執(zhí)行過程中，為了執(zhí)行上述ECA事務處理規(guī)則，需要開發(fā)一 個執(zhí)行框架，解析與執(zhí)行不同的事務策略的處理過程。該框架擴展服務組裝的引擎，并復用 事務協(xié)議的實現(xiàn)。結合圖2，說明運行時刻如何解釋與執(zhí)行含事務注解的服務組裝規(guī)格說明。服務組 裝引擎讀取并解釋服務組裝規(guī)格說明(即BPEL文件)。服務組裝引擎在解釋執(zhí)行BPEL文 件的過程中會產(chǎn)生各種事件，事務處理管理偵聽與事務處理相關的一些事件。當被注解活 動執(zhí)行時，事務管理模塊讀取事務策略注解文件(即一組以活動為單位的ECA規(guī)則)。在事 務策略注解文件中，以活動名稱為關鍵字查詢是否存在當前活動相關的事務策略規(guī)則。如 果存在、并且滿足ECA規(guī)則中的條件，則執(zhí)行動作定義的各種處理步驟。在執(zhí)行事務處理 的步驟時，事務管理模塊首先創(chuàng)建一個事務對象，執(zhí)行指定的事務處理過程?；顒訉凑?事務協(xié)議的規(guī)范執(zhí)行，事務執(zhí)行完畢后事務協(xié)議實現(xiàn)向事務處理管理發(fā)送事務處理結束消 息，事務處理管理刪除事務對象，并將控制權轉交給服務組裝引擎，服務組裝引擎繼續(xù)執(zhí)行 BPEL過程。如果不存在相關規(guī)則，或者存在相關規(guī)則但條件不滿足，則事務處理管理忽略該 事件，不做任何處理。以下結合圖1，以一種支持面向服務組裝的聲明式事務集成方法的平臺DecTM4B 為例，對本發(fā)明的技術方案進行詳細說明。首先，采用標準BPEL語言定義服務組裝的規(guī)格說明。以Drop-dead Order系統(tǒng) (由分銷商Distributor、供貨方Supplier、運輸方Carrier三方的Web服務組裝構成的 供應鏈系統(tǒng))為例，首先，BPEL過程通過“Request Distribution”操作向分銷商訂購貨 物。如果訂單是有效、而且分銷商能夠提供相關的服務，那么BPEL過程返回一個肯定的回 復；否則，拒絕訂單請求。分銷商接受訂單后，BPEL過程則尋求一個合適的供貨方，通過 “RequestSupply”操作請求供貨。如果請求成功，BPEL過程繼續(xù)尋求一個合適的運輸方，通 過“RequestDelivery”操作請求運輸貨物；否則，BPEL過程返回一個錯誤消息，提示不存在合適的供貨方。相似地，如果發(fā)送給運輸方的請求成功，BPEL過程通過“SupplyProduct”操 作要求供貨方提供貨物、通過“DeliverProduct”操作要求運輸方運輸貨物；如果請求不成 功，BPEL過程返回一個錯誤消息，提示不存在合適的運輸方。當將貨物成功的交付給客戶 后，BPEL過程通過“CompleteDistribution”操作確認供貨成功，返回一個成功的消息。在實施事務策略注解之前，必須對上述服務組裝規(guī)格說明進行預處理。在抽象 BPEL模型基礎上，應用活動依賴沖突的檢測方法，發(fā)現(xiàn)Invoke活動RequestDistribution 與 CompleteDistribution 之間存在事務依賴,類似的 RequestSupply 與 SupplyProduct 之 間、RequestDilivery與DeliverProduct之間也存在事務依賴關系。為此，必須對存在事務 依賴的活動進行合并。具體說來，將RequestDistribution與CompleteDistribution合并 為分銷活動 CompleteDistribution，將 RequestSupply 與 SupplyProduct 合并為供貨活動 SupplyProduct,將 RequestDilivery 與 DeliverProduct 合并為運輸活動 DeliverProduct。然后，對預處理后的服務組裝規(guī)格說明實施事務設計。對于分銷活動 CompleteDistribution 而目， 只有當供貨活動SupplyProduct與運輸活動DeliverProduct 都能在規(guī)定的時間內(nèi)容完成，才能完成一個訂單事務，否則必須拒絕訂單請求，該事務適用 WS-BA。對于供貨活動SupplyProduct而言，要么供貨，要么不供貨，適用WS-AT。類似的， 運輸活動DeliverProduct適用WS-AT。另外，供貨事務和運輸事務從屬于分銷事務。相 應地，遵循事務策略聲明模板對上述三個活動進行注解，其中，CompleteDistribution所 屬的分銷事務的Trans_ID為1，遵循WS-BA。SuppIyProduct所屬的運輸事務的Trans_ ID為2，遵循WS-AT。DeliverProduct所屬的供貨事務的Trans_ID為3，遵循WS-AT。 CompleteDistribution 的 Trans_Root 為 0，表明該事務為根事務，而 SupplyProduct 和 DeliverProduct 白勺 Trans_RootCompleteDistributio 白勺 Trans_ID 才目胃，\MitthK 屬于分銷事務。通過上述過程，得到預處理后的服務組裝規(guī)格說明(BPEL文件)和事務策略注解 文件，二者形成了含事務聲明的服務組裝規(guī)格說明。接下來，采用ECA規(guī)則定義所聲明的事 務策略的處理規(guī)則。以活動SupplyProduct的事務創(chuàng)建為例，符合Drools規(guī)范的ECA規(guī)則 如下所示其中，規(guī)則名稱Name中包含被注解的活動名稱“SupplyProduct”。Parameter 指明該規(guī)則處理的事件為“TransactionCreatedEvent”，該事件與BPEL引擎觸發(fā)的低層 事件“ActivityExecStartEvent”有關。Class指明了處理相關事件的Java程序?qū)崿F(xiàn)。 java condition部分定義了應用該規(guī)則時必須滿足的條件為“當前活動的名稱必須為 SupplyProduct而且聲明的事務協(xié)議為WS-AT”。Java consequence部分定義了一系列的 操作，具體的處理過程與聲明的事務策略與事務上下文環(huán)境有關。最后，在DecTM4B平臺上運行上述含事務聲明的服務組裝規(guī)格說明時，采用 ActiveBPEL引擎(一種BPEL引擎的實現(xiàn)版本)執(zhí)行BPEL規(guī)格說明，事務處理管理模塊偵 聽ActiveBPEL引擎的各種事件。當被注解的活動執(zhí)行時，事務處理管理模塊在事務策略注 解文件中查詢與本活動相關的ECA規(guī)則，采用Drools ( 一種基于Java語言實現(xiàn)的ECA規(guī)則 引擎)解釋ECA規(guī)則。WS-AT與WS-BA協(xié)議實現(xiàn)采用了 JBoss中間件。本發(fā)明將事務設計以一種聲明的方式集成到服務組裝規(guī)格說明中，增強了服務組 裝實現(xiàn)的業(yè)務過程的可靠性。通過本發(fā)明設計可靠的服務組裝時，首先對服務組裝的規(guī)格說明進行預處理，消除活動間存在事務依賴沖突，然后對預處理后的服務組裝規(guī)格說明進 行事務策略的聲明與注解，借助ECA規(guī)則定義事務處理的規(guī)則，最后通過擴展后的服務組 裝引擎解釋與支持聲明的事務策略，保證活動的執(zhí)行遵循相關的事務協(xié)議。本發(fā)明提供了 服務組裝規(guī)格說明的預處理技術、事務策略的注解方法、事務處理的規(guī)則定義、支持平臺， 是一個完整的面向服務組裝的事務集成方案，在服務組裝中實現(xiàn)了簡單、高效的事務管理， 填補了服務組裝語言與面向Web的事務協(xié)議在集成方面的鴻溝，對于基于Web服務組裝實 現(xiàn)可靠的業(yè)務流程具有十分重要的意義。 以上所述，僅為本發(fā)明的具體實施方式
，但本發(fā)明的保護范圍并不局限于此，任何 熟悉本技術領域的技術人員在本發(fā)明揭露的技術范圍內(nèi)，可輕易想到變化或替換，都應涵 蓋在本發(fā)明的保護范圍之內(nèi)。因此，本發(fā)明的保護范圍應所述以權利要求的保護范圍為準。
權利要求
1.一種面向服務組裝的聲明式事務集成方法，其特征在于包括如下步驟，(1)、對基于服務組裝語言BPEL的服務組裝規(guī)格說明進行預處理，識別并消除不同活 動之間存在的事務依賴；O)、對預處理后的所述服務組裝規(guī)格說明進行事務策略的說明和注解，借助ECA定義 所述事務處理的規(guī)則，對服務組裝中指定的活動聲明預期的事務策略，確保被注解的活動 遵循一定的事務協(xié)議規(guī)范，預處理后的所述服務組裝規(guī)格說明和所述事務策略的注解文件 形成含事務注解的服務組裝規(guī)格說明；(3)、解釋和執(zhí)行所述含事務注解的服務組裝規(guī)格說明，完成預定業(yè)務的Web服務組裝。
2.根據(jù)權利要求1所述的方法，其特征在于所述步驟(1)中預處理通過構造BPEL過 程的抽象模型實現(xiàn)，基于所述抽象模型識別和消除活動之間的依賴沖突。
3.根據(jù)權利要求2所述的方法，其特征在于所述BPEL過程的抽象模型記載活動之間 至少包括活動名稱、操作、輸入變量、輸出變量、源連接與目標連接的交互關系。
4.根據(jù)權利要求3所述的方法，其特征在于所述步驟( 中，所述指定的活動為BPEL 過程中與遠程Web服務交互的特定類型的活動。
5.根據(jù)權利要求4所述的方法，其特征在于所述事務策略的注解由依據(jù)BPEL過程的 抽象模型，遵循一種事務策略聲明模板實現(xiàn)；其中，所述事務策略聲明模板包括活動名稱、 活動運行時信息、事務信息、事務標識號、事務協(xié)議類型、根事務標識號。
6.根據(jù)權利要求5所述的方法，其特征在于所述事務策略聲明模板的表示采用XML 語法格式；所述事務協(xié)議類型為WS-C或者WS-AT或者WS-BA。
7.根據(jù)權利要求6所述的方法，其特征在于所述步驟(3)中通過定義事務處理規(guī)則 的表示結構，解析與執(zhí)行不同的事務策略的處理過程。
8.根據(jù)權利要求7所述的方法，其特征在于所述事務處理規(guī)則的表示結構包括事件、 條件和動作過程三部分；所述事件指明執(zhí)行BPEL過程時需要捕獲的一些低層事件，所述條 件指明相關事件觸發(fā)后執(zhí)行事務處理過程時必須滿足的條件，所述動作指明具體的處理步 馬聚ο
9.根據(jù)權利要求8所述的方法，其特征在于采用BPEL引擎解釋服務組裝規(guī)格說明； 采用事務管理模塊管理事務的生命周期；調(diào)用相應地事務協(xié)議實現(xiàn)聲明的所述事務協(xié)議類 型的執(zhí)行。
10.一種實現(xiàn)權利要求1-9任一所述方法的面向服務組裝的聲明式事務集成系統(tǒng)，其 特征在于包括，服務組裝規(guī)格說明模塊，為預處理后的基于服務組裝語言BPEL的服務組裝規(guī)格說明， 包括活動名稱、活動運行時信息、事務信息、事務標識號、事務協(xié)議類型、根事務標識號；預 處理后的所述服務組裝規(guī)格說明使得不同活動之間不存在事務依賴；事務策略注釋模塊，為一組以活動為基本單位的ECA規(guī)則，所述ECA規(guī)則包括事件、條 件和動作過程三部分；所述事件為執(zhí)行BPEL過程時需要捕獲的一些低層事件；所述條件為 相關事件觸發(fā)后執(zhí)行事務處理過程時必須滿足的條件，所述動作為具體的處理步驟；服務組裝引擎模塊，讀取并解釋所述服務組裝規(guī)格說明；事務管理模塊，偵聽所述服務組裝引擎模塊執(zhí)行中與所述事務處理相關的事件；在被注解活動執(zhí)行時，讀取所述事務策略注解文件。
全文摘要
本發(fā)明公開了一種面向服務組裝的聲明式事務集成方法和系統(tǒng)，所述方法包括如下步驟，(1)對基于服務組裝語言BPEL的服務組裝規(guī)格說明進行預處理，識別并消除不同活動之間存在的事務依賴；(2)對預處理后的所述服務組裝規(guī)格說明進行事務策略的說明和注解，確保被注解的活動遵循一定的事務協(xié)議規(guī)范，預處理后的所述服務組裝規(guī)格說明和所述事務策略的注解文件形成含事務注解的服務組裝規(guī)格說明；(3)解釋和執(zhí)行所述含事務注解的服務組裝規(guī)格說明，完成預定業(yè)務的Web服務組裝。通過集成已有的Web服務的事務框架和協(xié)議，利用現(xiàn)有的服務組裝引擎和面向Web服務的事務協(xié)議，部分支持服務組裝中自動化的事務設計與執(zhí)行，增強Web服務組裝的可靠性。
文檔編號G06F9/44GK102073505SQ20111003405
公開日2011年5月25日 申請日期2011年1月31日 優(yōu)先權日2011年1月31日
發(fā)明者孫昌愛 申請人:北京科技大學