(西安電子科技大學(xué) 軟件工程研究所 西安 710071)
摘 要:提出了一種基于動(dòng)態(tài)代理的方法來(lái)提高流程的可靠性。該方法使用面向方面技術(shù)擴(kuò)展BPEL引擎來(lái)攔截調(diào)用伙伴服務(wù),并由動(dòng)態(tài)代理與伙伴服務(wù)交互。如果伙伴服務(wù)失敗,則動(dòng)態(tài)代理動(dòng)態(tài)地發(fā)現(xiàn)并調(diào)用等價(jià)服務(wù)。動(dòng)態(tài)等價(jià)服務(wù)發(fā)現(xiàn)結(jié)合了傳統(tǒng)的基于關(guān)鍵字的服務(wù)發(fā)現(xiàn)和基于本體的服務(wù)發(fā)現(xiàn)兩種技術(shù)。采用消息轉(zhuǎn)換機(jī)制來(lái)解決失敗服務(wù)與替換服務(wù)之間接口不匹配的問(wèn)題。此外,還提供了基于瀏覽器的管理界面來(lái)幫助設(shè)計(jì)人員管理替換服務(wù)和消息轉(zhuǎn)換規(guī)則。最后,通過(guò)實(shí)驗(yàn)分析表明該方法是一種可行的方案。
關(guān)鍵詞:Web服務(wù)業(yè)務(wù)流程執(zhí)行語(yǔ)言; 動(dòng)態(tài)代理; 面向方面編程; 服務(wù)發(fā)現(xiàn); 消息格式轉(zhuǎn)換
中圖分類(lèi)號(hào):TP311文獻(xiàn)標(biāo)志碼:A
文章編號(hào):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 引言
面向服務(wù)計(jì)算是一種新的分布式計(jì)算范型,能夠通過(guò)組合網(wǎng)絡(luò)上的服務(wù)以快速、低成本地構(gòu)建分布式組合應(yīng)用。服務(wù)是自描述的和與平臺(tái)無(wú)關(guān)的計(jì)算單元。Web服務(wù)是目前實(shí)現(xiàn)服務(wù)廣泛采用的技術(shù),它采用開(kāi)放的標(biāo)準(zhǔn)協(xié)議,包括SOAP(simple object access protocol)、WSDL(Web services description language)和UDDI(universal description、discovery and integration)等。WSBPEL[1,2]已經(jīng)成為當(dāng)前Web服務(wù)組合的事實(shí)標(biāo)準(zhǔn),可以將相關(guān)的Web服務(wù)組合成大粒度和更有價(jià)值的服務(wù)。這個(gè)組合的服務(wù)稱(chēng)為BPEL流程,被組合的服務(wù)稱(chēng)為伙伴服務(wù)。BPEL提供了變量、順序、分支、循環(huán)、異步消息、流程關(guān)聯(lián)集、事件處理、補(bǔ)償處理和異常處理機(jī)制等。BPEL規(guī)范由BEA、微軟和IBM共同發(fā)起制定,于2003年開(kāi)始由OASIS組織發(fā)布標(biāo)準(zhǔn)。
BPEL流程通常組合很多Web服務(wù),通過(guò)Internet與這些服務(wù)進(jìn)行通信。Web服務(wù)是分布的、異構(gòu)的和自治的,并由不同組織進(jìn)行開(kāi)發(fā)和維護(hù),這些特點(diǎn)使得基于服務(wù)的流程非常脆弱,很容易出現(xiàn)異常。在這種情況下,需要?jiǎng)討B(tài)地發(fā)現(xiàn)失敗服務(wù)的等價(jià)服務(wù)(等價(jià)是指兩個(gè)服務(wù)實(shí)現(xiàn)相同的功能,但它們的接口可以不一致),并用其來(lái)代替失敗服務(wù)執(zhí)行。隨著SOA技術(shù)的廣泛應(yīng)用,Internet中的具有等價(jià)功能的Web服務(wù)數(shù)量迅速增加,而Web服務(wù)本身具有動(dòng)態(tài)性和易變性的特點(diǎn),這就使得在設(shè)計(jì)流程時(shí)不可能將伙伴服務(wù)的等價(jià)服務(wù)全部羅列出來(lái)。為了解決這些問(wèn)題,本文提出了一種基于動(dòng)態(tài)代理的方法,能夠動(dòng)態(tài)地發(fā)現(xiàn)和調(diào)用等價(jià)服務(wù)。如圖1所示,當(dāng)調(diào)用服務(wù)容器SC1中的服務(wù)S1發(fā)生異常時(shí),動(dòng)態(tài)代理使用服務(wù)容器SC2中的服務(wù)S1來(lái)代替其執(zhí)行。
Ezenwoye等人提出了用代理服務(wù)代替失敗服務(wù)執(zhí)行的RobustBPEL[3]和RobustBPEL2[4]。Baresi等人提出了一種BPEL自愈的解決方案Dynamo[5],為用戶(hù)提供了領(lǐng)域規(guī)范語(yǔ)言WSReL(Web service recovery language)定義服務(wù)異常恢復(fù)規(guī)則。當(dāng)伙伴服務(wù)失敗時(shí),RobustBPEL和Dynamo是通過(guò)硬編碼的形式將替換服務(wù)寫(xiě)入配置文件,不能在流程運(yùn)行時(shí)修改,而RobustBPEL2可以動(dòng)態(tài)地發(fā)現(xiàn)等價(jià)服務(wù),但要求伙伴服務(wù)與替換服務(wù)具有相同的接口。如果兩者接口不匹配,則需要預(yù)先為替換服務(wù)提供一個(gè)包裝接口,這種方式使得新發(fā)現(xiàn)的具有等價(jià)功能而與伙伴服務(wù)接口和包裝接口不同的服務(wù)不能作為替換服務(wù)。陳今梁等人提出了一個(gè)WSBPEL流程的運(yùn)行時(shí)監(jiān)控方法[6],該方法采用AOP技術(shù)擴(kuò)展BPEL引擎,實(shí)現(xiàn)監(jiān)控功能,從而能夠靈活監(jiān)控WSBPEL流程的執(zhí)行,但該方法不具有恢復(fù)能力。
本文提出的基于動(dòng)態(tài)代理的方法是通過(guò)AOP技術(shù)擴(kuò)展ActiveBPEL[7]的功能,使之具有動(dòng)態(tài)恢復(fù)的能力。動(dòng)態(tài)代理能夠進(jìn)行動(dòng)態(tài)服務(wù)發(fā)現(xiàn)、服務(wù)相似性搜索、等價(jià)服務(wù)選擇和服務(wù)管理等。本文的主要工作包括以下幾個(gè)方面:a)采用AOP技術(shù)擴(kuò)展BPEL引擎的功能,可以不修改BPEL引擎源代碼就具有動(dòng)態(tài)恢復(fù)機(jī)制;b)采用基于關(guān)鍵字的服務(wù)發(fā)現(xiàn)和基于本體語(yǔ)義的服務(wù)發(fā)現(xiàn)相結(jié)合的方法,提高服務(wù)發(fā)現(xiàn)的準(zhǔn)確率;c)提出一種基于消息格式轉(zhuǎn)換的機(jī)制來(lái)解決服務(wù)接口不匹配的問(wèn)題;d)提供基于瀏覽器的管理界面來(lái)管理替換服務(wù)和消息轉(zhuǎn)換規(guī)則。
1 動(dòng)態(tài)代理
BPEL規(guī)范提供了錯(cuò)誤處理器、補(bǔ)償處理器和事件處理器用于設(shè)計(jì)異常處理和恢復(fù)策略。流程設(shè)計(jì)人員在編寫(xiě)流程時(shí)需要考慮所有可能的錯(cuò)誤并設(shè)計(jì)相應(yīng)的處理策略。通過(guò)這種方式,如果流程在運(yùn)行時(shí)發(fā)生錯(cuò)誤就可以根據(jù)事先設(shè)計(jì)好的策略進(jìn)行恢復(fù)處理。流程的異常處理策略完全由設(shè)計(jì)人員來(lái)設(shè)計(jì)會(huì)存在一些問(wèn)題:a)流程設(shè)計(jì)人員往往不會(huì)把所有錯(cuò)誤狀態(tài)都考慮到,如調(diào)用伙伴服務(wù)時(shí),出現(xiàn)一個(gè)網(wǎng)絡(luò)通信異常,而這個(gè)異常又沒(méi)有被〈catch〉捕獲,這就可能導(dǎo)致整個(gè)流程運(yùn)行失敗;b)如果所有的異常處理都放到BPEL流程中會(huì)導(dǎo)致流程的設(shè)計(jì)非常困難,也使得流程過(guò)于復(fù)雜和難以維護(hù);c)BPEL規(guī)范的三種處理器的功能非常基礎(chǔ),不能為設(shè)計(jì)人員直接提供更高級(jí)的恢復(fù)策略,如服務(wù)替換策略、設(shè)計(jì)人員設(shè)計(jì)異常處理和恢復(fù)策略完全依賴(lài)于個(gè)人經(jīng)驗(yàn)和掌握BPEL規(guī)范的程度。
通過(guò)兩種不同的策略可以解決上述問(wèn)題:a)擴(kuò)展BPEL規(guī)范,通過(guò)增加新的BPEL構(gòu)建器或擴(kuò)充已有構(gòu)建器的屬性來(lái)增強(qiáng)其處理能力。這種方式的缺點(diǎn)是必須修改BPEL引擎的源代碼,由于該方式改變了 BPEL元素的層次結(jié)構(gòu)。目前幾乎所有的BPEL引擎對(duì)層次結(jié)構(gòu)的遍歷都是采用visitor模式[8],這會(huì)導(dǎo)致BPEL引擎需要修改的代碼量是難以估計(jì)的。b)擴(kuò)展BPEL引擎,通過(guò)為引擎增加新的模塊自動(dòng)地執(zhí)行恢復(fù)策略。這種方式也需要改變BPEL引擎,但通過(guò)AOP技術(shù)可以將新代碼直接植入到BPEL引擎中,而不需要修改原有的源代碼。針對(duì)不同的BPEL引擎,只需要定義不同的aspect,然后將代碼植入到引擎中就可以使之具有異常處理和恢復(fù)的能力。
本文提出的動(dòng)態(tài)代理采用了第二種解決方案,通過(guò)AOP技術(shù)為BPEL引擎提供動(dòng)態(tài)恢復(fù)的能力。
1.1 體系結(jié)構(gòu)
動(dòng)態(tài)代理體系結(jié)構(gòu)如圖2所示。通過(guò)AOP技術(shù)對(duì)BPEL引擎進(jìn)行擴(kuò)展,攔截對(duì)伙伴服務(wù)的調(diào)用請(qǐng)求,由動(dòng)態(tài)服務(wù)代理來(lái)控制與伙伴服務(wù)的交互。動(dòng)態(tài)代理在結(jié)構(gòu)上分為兩層,即運(yùn)行時(shí)層和核心層。運(yùn)行時(shí)層主要負(fù)責(zé)與伙伴服務(wù)交互,當(dāng)伙伴服務(wù)失敗時(shí),從核心層獲取并執(zhí)行失敗服務(wù)的等價(jià)服務(wù)。為了方便敘述,將BPEL流程中調(diào)用的伙伴服務(wù)稱(chēng)為標(biāo)準(zhǔn)服務(wù),與標(biāo)準(zhǔn)服務(wù)等價(jià)的服務(wù)稱(chēng)為替換服務(wù)。核心層主要負(fù)責(zé)動(dòng)態(tài)地發(fā)現(xiàn)標(biāo)準(zhǔn)服務(wù)的替換服務(wù)、管理標(biāo)準(zhǔn)服務(wù)與替換服務(wù)的消息轉(zhuǎn)換規(guī)則和按照某種策略返回替換服務(wù)。核心層可以獨(dú)立于運(yùn)行時(shí)層運(yùn)行,其目的是將發(fā)現(xiàn)服務(wù)階段與使用服務(wù)階段分離。核心層可以在流程未運(yùn)行或運(yùn)行過(guò)程中,在UDDI注冊(cè)中心動(dòng)態(tài)地發(fā)現(xiàn)標(biāo)準(zhǔn)服務(wù)的替換服務(wù)。當(dāng)標(biāo)準(zhǔn)服務(wù)失敗時(shí),動(dòng)態(tài)服務(wù)代理使用已經(jīng)搜索的替換服務(wù)執(zhí)行。這樣可以大大縮短獲取替換服務(wù)的時(shí)間,從而減少流程的執(zhí)行時(shí)間,提高運(yùn)行性能。
運(yùn)行時(shí)層包括動(dòng)態(tài)服務(wù)代理組件、服務(wù)調(diào)用組件、異常分析組件和消息格式轉(zhuǎn)換組件。動(dòng)態(tài)服務(wù)代理組件將服務(wù)請(qǐng)求交給服務(wù)調(diào)用組件以獲取服務(wù)的運(yùn)行結(jié)果。當(dāng)調(diào)用服務(wù)出現(xiàn)異常時(shí),動(dòng)態(tài)服務(wù)代理組件首先通過(guò)異常分析組件獲得異常類(lèi)型,通過(guò)服務(wù)選擇組件獲得替換服務(wù)和消息轉(zhuǎn)換規(guī)則,然后再通過(guò)服務(wù)調(diào)用組件執(zhí)行替換服務(wù)。
核心層包括動(dòng)態(tài)服務(wù)發(fā)現(xiàn)組件、服務(wù)管理組件和服務(wù)選擇組件。動(dòng)態(tài)服務(wù)發(fā)現(xiàn)組件首先從BPEL描述文件中找出所有的標(biāo)準(zhǔn)服務(wù),然后以標(biāo)準(zhǔn)服務(wù)為參考從UDDI注冊(cè)中心搜索與之相似的服務(wù)。服務(wù)管理組件負(fù)責(zé)管理由動(dòng)態(tài)服務(wù)發(fā)現(xiàn)組件搜索到的服務(wù),并負(fù)責(zé)管理標(biāo)準(zhǔn)服務(wù)與替換服務(wù)之間的消息轉(zhuǎn)換規(guī)則。服務(wù)選擇組件首先根據(jù)動(dòng)態(tài)服務(wù)代理組件提供的服務(wù)標(biāo)志信息,通過(guò)服務(wù)管理組件找到對(duì)應(yīng)的替換服務(wù),然后根據(jù)選擇策略返回相應(yīng)的服務(wù)。
1.2 服務(wù)調(diào)用攔截
通過(guò)AOP技術(shù)可以在不改變BPEL引擎源代碼的情況下,通過(guò)植入代碼增強(qiáng)其功能。本文采用的BPEL引擎是ActiveBPEL,通過(guò)AspectJ將服務(wù)調(diào)用攔截作為橫切關(guān)注點(diǎn)引入到引擎中。ActiveBPEL為活動(dòng)定義兩個(gè)類(lèi)層次結(jié)構(gòu):一個(gè)是以AeActivityDef類(lèi)為基類(lèi)的層次結(jié)構(gòu),該結(jié)構(gòu)與BPEL規(guī)范定義的活動(dòng)一一對(duì)應(yīng),流程部署就是將BPEL文件轉(zhuǎn)換成該內(nèi)存結(jié)構(gòu);另一個(gè)是以AeActivityImpl類(lèi)為基類(lèi)的層次結(jié)構(gòu),該結(jié)構(gòu)是運(yùn)行時(shí)使用的結(jié)構(gòu),當(dāng)執(zhí)行流程時(shí)引擎首先將AeActivityDef層次結(jié)構(gòu)轉(zhuǎn)換成AeActivityImpl層次結(jié)構(gòu),然后采用visitor模式遍歷。AeActivityImpl類(lèi)為活動(dòng)的執(zhí)行定義了一個(gè)通用的接口。其中包含execute方法,各個(gè)子類(lèi)重置該方法的實(shí)現(xiàn)來(lái)定義自己的具體操作,如scope活動(dòng)為內(nèi)部定義的變量分配存儲(chǔ)空間,invoke活動(dòng)執(zhí)行外部服務(wù)調(diào)用。
本文僅考慮流程與伙伴服務(wù)交互時(shí)出現(xiàn)的異常,所以只需要在流程執(zhí)行invoke活動(dòng)進(jìn)行攔截。為此對(duì)AeActivityInvokeImpl類(lèi)的execute方法設(shè)置around類(lèi)型的切入點(diǎn),以便于最大程度地控制活動(dòng)的執(zhí)行。一旦ActiveBPEL引擎執(zhí)行invoke活動(dòng),正常執(zhí)行被攔截,控制權(quán)交給動(dòng)態(tài)服務(wù)代理。該組件負(fù)責(zé)與伙伴服務(wù)進(jìn)行交互,當(dāng)出現(xiàn)異常時(shí)進(jìn)行相應(yīng)處理。
1.3 異常分析
根據(jù)BPEL流程中異常的來(lái)源不同,將異常分成三類(lèi):a)流程異常。由于BPEL流程設(shè)計(jì)時(shí)的疏忽而導(dǎo)致的語(yǔ)法錯(cuò)誤,如使用了未定義的變量或者BPEL構(gòu)建器的名字不正確等錯(cuò)誤。b)邏輯異常。伙伴服務(wù)的接口描述文件中對(duì)操作定義的異常,這些異常通常是由服務(wù)提供者為了區(qū)分不同的錯(cuò)誤情況而有意拋出的異常。c)系統(tǒng)異常。調(diào)用伙伴服務(wù)時(shí)出現(xiàn)的除了邏輯異常以外的異常,這些異常包括非人為異常和人為異常。其中非人為異常一般是由于網(wǎng)絡(luò)故障、服務(wù)所在機(jī)器的操作系統(tǒng)錯(cuò)誤、數(shù)據(jù)庫(kù)出錯(cuò)或機(jī)器出現(xiàn)硬件故障等引發(fā)的異常。人為異常是指服務(wù)提供者在維護(hù)服務(wù)的過(guò)程中,撤銷(xiāo)了原來(lái)的服務(wù)或?yàn)榱朔?wù)功能的需要修改了服務(wù)的接口信息等引起的異常。這幾類(lèi)異常都會(huì)導(dǎo)致流程不能夠正常運(yùn)行。
對(duì)于不同的異常類(lèi)型采用的處理方法也不相同。a)流程異常是由于流程有語(yǔ)法錯(cuò)誤導(dǎo)致的,可以采用錯(cuò)誤預(yù)防的方法。目前有很多BPEL流程設(shè)計(jì)工具,包括ActiveBPEL設(shè)計(jì)器、Eclipse BPEL設(shè)計(jì)器和OracleBPEL設(shè)計(jì)器,這些工具都提供了對(duì)BPEL流程的基本語(yǔ)法檢查,能夠很好地排除流程的語(yǔ)法錯(cuò)誤。b)邏輯錯(cuò)誤是由服務(wù)提供者有意拋出的,如銀行的取款服務(wù),當(dāng)客戶(hù)取款的金額大于賬戶(hù)余額時(shí)會(huì)拋出InsufficientException。這類(lèi)異常的處理往往與業(yè)務(wù)規(guī)則有關(guān),其屬于流程設(shè)計(jì)的一部分,所以由流程設(shè)計(jì)人員通過(guò)BPEL規(guī)范提供的異常處理器設(shè)計(jì)處理策略。c)系統(tǒng)異常是由于Web服務(wù)本身的特點(diǎn)決定的,筆者采用容錯(cuò)的方法來(lái)解決。此類(lèi)異常只表示當(dāng)前調(diào)用的服務(wù)不能訪問(wèn),并不意味著其他與之等價(jià)的服務(wù)也不能訪問(wèn),所以可以使用等價(jià)服務(wù)來(lái)代替失敗服務(wù)來(lái)提高流程的可靠性。本文提出的動(dòng)態(tài)代理用于處理系統(tǒng)異常,能夠動(dòng)態(tài)地發(fā)現(xiàn)和調(diào)用失敗服務(wù)的等價(jià)服務(wù)。
異常分析組件的功能是分析當(dāng)前出現(xiàn)異常的類(lèi)型,即邏輯異常或系統(tǒng)異常。首先采用WSDL解析器分析失敗服務(wù)的WSDL文件,獲得該服務(wù)定義的邏輯異常,然后判斷當(dāng)前的異常是否屬于邏輯異常,如果是則返回邏輯異常類(lèi)型,否則返回系統(tǒng)異常類(lèi)型。
1.4 動(dòng)態(tài)服務(wù)代理
動(dòng)態(tài)服務(wù)代理是動(dòng)態(tài)代理框架的外觀控制器[9],服務(wù)調(diào)用攔截模塊只需要與該模塊進(jìn)行交互。其主要職責(zé)是整合其他各模塊的功能,實(shí)現(xiàn)流程的自動(dòng)恢復(fù)。動(dòng)態(tài)服務(wù)代理的工作方式為:動(dòng)態(tài)服務(wù)代理得到控制權(quán)后,通過(guò)服務(wù)調(diào)用模塊與伙伴服務(wù)進(jìn)行交互。如果服務(wù)執(zhí)行成功,則動(dòng)態(tài)代理什么也不做。當(dāng)調(diào)用服務(wù)出現(xiàn)異常時(shí),動(dòng)態(tài)服務(wù)代理組件首先通過(guò)異常分析組件獲得異常類(lèi)型,如果異常為邏輯異常,由于該類(lèi)異常的處理屬于業(yè)務(wù)流程的一部分,并且流程設(shè)計(jì)人員已經(jīng)在流程中設(shè)計(jì)了相應(yīng)的恢復(fù)策略,動(dòng)態(tài)代理不處理該異常,而是由BPEL流程中的異常處理器進(jìn)行處理。如果異常為系統(tǒng)異常,則需要找到該失敗服務(wù)的一個(gè)替換服務(wù)來(lái)執(zhí)行。動(dòng)態(tài)服務(wù)代理首先通過(guò)服務(wù)選擇組件獲取當(dāng)前失敗服務(wù)的替換服務(wù)和相應(yīng)的消息轉(zhuǎn)換規(guī)則;然后調(diào)用消息格式轉(zhuǎn)換組件將失敗服務(wù)的輸入消息轉(zhuǎn)換成替換服務(wù)的輸入消息,通過(guò)服務(wù)調(diào)用組件調(diào)用替換服務(wù);最后在服務(wù)調(diào)用組件返回服務(wù)執(zhí)行結(jié)果后,動(dòng)態(tài)服務(wù)代理組件將替換服務(wù)的返回消息再轉(zhuǎn)換成失敗服務(wù)的輸出消息格式。這樣,動(dòng)態(tài)服務(wù)代理通過(guò)與其他模塊相互配合實(shí)現(xiàn)了在調(diào)用伙伴服務(wù)失敗時(shí)的自動(dòng)恢復(fù)處理。
1.5 動(dòng)態(tài)服務(wù)發(fā)現(xiàn)
傳統(tǒng)的Web服務(wù)發(fā)現(xiàn)手段是基于UDDI系統(tǒng),但UDDI提供的Web服務(wù)查詢(xún)只是簡(jiǎn)單地基于關(guān)鍵字的語(yǔ)法匹配,缺乏語(yǔ)義信息,所以得到的服務(wù)可能不是用戶(hù)想要的。
語(yǔ)義以本體(ontology[10])技術(shù)為基礎(chǔ),從具體的應(yīng)用領(lǐng)域中抽取出共用的概念和術(shù)語(yǔ),建立它們之間的關(guān)系,從而為該領(lǐng)域提供可被共享和復(fù)用的領(lǐng)域知識(shí)和詞匯,使得領(lǐng)域內(nèi)對(duì)領(lǐng)域知識(shí)形成一致的理解。
本文提出了將傳統(tǒng)服務(wù)發(fā)現(xiàn)與本體語(yǔ)義相結(jié)合的方法,如圖3所示。該方法將服務(wù)發(fā)現(xiàn)分成兩個(gè)階段:a)采用基于關(guān)鍵字的搜索從UDDI得到一系列Web服務(wù);b)以標(biāo)準(zhǔn)服務(wù)為參考,采用基于語(yǔ)義的方法,從a)得到的Web服務(wù)中搜索相似的服務(wù)。本文的語(yǔ)義搜索方法是一種輕量級(jí)的基于本體詞匯相似度量方法,使用服務(wù)的描述信息、名稱(chēng)、輸入?yún)?shù)和輸出參數(shù)的相似性來(lái)判斷服務(wù)相似性。
圖3中的服務(wù)提取模塊根據(jù)BPEL文件找出所有的標(biāo)準(zhǔn)服務(wù),通過(guò)WSDL文件得到標(biāo)準(zhǔn)服務(wù)的服務(wù)描述、名稱(chēng)、輸入和輸出參數(shù);然后通過(guò)服務(wù)預(yù)處理模塊進(jìn)行必要的預(yù)處理,以提高信息的有效性;最后通過(guò)數(shù)據(jù)庫(kù)訪問(wèn)框架將標(biāo)準(zhǔn)服務(wù)的信息存儲(chǔ)到本地的服務(wù)倉(cāng)庫(kù)中,為服務(wù)發(fā)現(xiàn)做好準(zhǔn)備。
服務(wù)預(yù)處理模塊從WSDL中提取服務(wù)的描述、名稱(chēng)、輸入?yún)?shù)和輸出參數(shù)信息,并對(duì)這些信息進(jìn)行處理。主要包括拆分句子和合成詞、統(tǒng)一詞的形式、替換縮寫(xiě)詞、去掉沒(méi)有意義的詞和根據(jù)本體庫(kù)將詞替換成標(biāo)準(zhǔn)的語(yǔ)義詞匯等。
服務(wù)檢索模塊實(shí)現(xiàn)a)的服務(wù)搜索,根據(jù)標(biāo)準(zhǔn)服務(wù)的信息用關(guān)鍵字匹配的方法從UDDI注冊(cè)中心獲取到一組滿(mǎn)足條件的服務(wù)的WSDL文件,交給服務(wù)相似性搜索模塊進(jìn)行b)搜索。
服務(wù)相似性搜索模塊實(shí)現(xiàn)b)的服務(wù)搜索,以標(biāo)準(zhǔn)服務(wù)為參考,從服務(wù)檢索模塊提供的WSDL文件中搜索與之相似的服務(wù),并將相似服務(wù)通過(guò)數(shù)據(jù)庫(kù)訪問(wèn)框架存儲(chǔ)到本地服務(wù)倉(cāng)庫(kù)中建立標(biāo)準(zhǔn)服務(wù)與其的關(guān)聯(lián)關(guān)系。
數(shù)據(jù)庫(kù)訪問(wèn)框架用于簡(jiǎn)化編寫(xiě)操作數(shù)據(jù)庫(kù)的代碼,提高數(shù)據(jù)庫(kù)操作的運(yùn)行效率。本文采用了目前被廣泛采用的Hibernate框架。筆者將一個(gè)Web服務(wù)抽象成由描述、名稱(chēng)、輸入和輸出參數(shù)組成的實(shí)體,可以定義如下:
定義1 一個(gè)Web服務(wù)可以表示為
WSi=(Di,Ni,Ii,Oi)(1)
其中:Di表示服務(wù)的描述集合;Ni表示服務(wù)名稱(chēng)的集合;Ii表示輸入?yún)?shù)的集合;Oi表示輸出參數(shù)的集合。
對(duì)于兩個(gè)服務(wù)WSi和WSj的相似度,根據(jù)所包含元素的相似度進(jìn)行計(jì)算,給出下面的定義。
定義2WSi和WSj相似度定義如下:
simws(WSi,WSj)=w1#8226;simD(Di,Dj)+w2#8226;simN(Ni,Nj)+
w3#8226;simI(xiàn)(Ii,Ij)+w4#8226;simO(Oi,Oj)(2)
其中:∑4i=1 wi=1,wi表示權(quán)重;simD(Di,Dj)、simN(Ni,Nj)、simI(Ii,Ij)和simO(Oi,Oj)分別表示服務(wù)描述、名稱(chēng)、輸入?yún)?shù)和輸出參數(shù)的相似度,本文采用文獻(xiàn)[11]的方法對(duì)它們進(jìn)行計(jì)算。設(shè)定一個(gè)閾值,當(dāng)兩個(gè)服務(wù)的相似度大于該閾值時(shí),認(rèn)為這兩個(gè)服務(wù)為相似服務(wù)。
1.6 服務(wù)管理
通過(guò)動(dòng)態(tài)服務(wù)發(fā)現(xiàn)組件找到標(biāo)準(zhǔn)服務(wù)的相似服務(wù)可能有多個(gè),而且兩個(gè)服務(wù)相似并不能保證它們的功能相同,即使兩個(gè)服務(wù)語(yǔ)義等價(jià)也不能保證它們的功能一定相同。例如用于查詢(xún)本地賓館信息的服務(wù),假設(shè)有兩個(gè)服務(wù)提供者,一個(gè)是本地的旅行社,另一個(gè)是體育協(xié)會(huì)。旅行社的查詢(xún)服務(wù)是根據(jù)查詢(xún)條件返回本地所有滿(mǎn)足條件的賓館信息;而體育協(xié)會(huì)的查詢(xún)服務(wù)是根據(jù)查詢(xún)條件從它規(guī)定的本地賓館中查找所有滿(mǎn)足條件的賓館信息。在這種情況下,即使這兩個(gè)服務(wù)完全相似,也不能用一個(gè)服務(wù)去替換另一個(gè)服務(wù)。因此,相似服務(wù)是否能夠作為替換服務(wù)還需要由服務(wù)管理組件來(lái)最終確定。
鑒于以上分析,本文采用半自動(dòng)化的方法來(lái)確定標(biāo)準(zhǔn)服務(wù)的替換服務(wù)。首先采用完全自動(dòng)化的動(dòng)態(tài)服務(wù)發(fā)現(xiàn)組件找到標(biāo)準(zhǔn)服務(wù)的相似服務(wù),然后由管理員確定哪些相似服務(wù)可以作為標(biāo)準(zhǔn)服務(wù)的替換服務(wù)。服務(wù)管理組件包括:
a)服務(wù)管理模塊。它負(fù)責(zé)管理標(biāo)準(zhǔn)服務(wù)的替換服務(wù),可以通過(guò)兩種方式來(lái)添加標(biāo)準(zhǔn)服務(wù)的替換服務(wù);(a)當(dāng)明確知道標(biāo)準(zhǔn)服務(wù)的替換服務(wù)時(shí),可以直接導(dǎo)入替換服務(wù)的WSDL文件來(lái)添加替換服務(wù);(b)利用動(dòng)態(tài)服務(wù)發(fā)現(xiàn)組件找到的相似服務(wù),經(jīng)過(guò)確認(rèn)的相似服務(wù)成為替換服務(wù),同時(shí)也可以刪除不正確的相似服務(wù)或不再可用的替換服務(wù)。針對(duì)一個(gè)標(biāo)準(zhǔn)服務(wù)存在多個(gè)替換服務(wù)時(shí),可以設(shè)置各個(gè)服務(wù)的優(yōu)先級(jí)。
b)服務(wù)緩沖模塊。它用于緩存標(biāo)準(zhǔn)服務(wù)和替換服務(wù)的信息以提高服務(wù)查詢(xún)的速度,減少性能開(kāi)銷(xiāo)。當(dāng)服務(wù)管理模塊對(duì)替換服務(wù)更新時(shí),此模塊的信息也要進(jìn)行相應(yīng)的更新。
c)服務(wù)查詢(xún)模塊。它負(fù)責(zé)根據(jù)給定的標(biāo)準(zhǔn)服務(wù)信息獲得其相應(yīng)的替換服務(wù)列表和相應(yīng)的消息轉(zhuǎn)換規(guī)則。首先在服務(wù)緩沖中查詢(xún),如果信息已經(jīng)在緩沖區(qū)中就直接返回,否則需要查詢(xún)數(shù)據(jù)庫(kù)獲得信息。
d)消息轉(zhuǎn)換規(guī)則管理。它用于建立和維護(hù)標(biāo)準(zhǔn)服務(wù)和替換服務(wù)的消息轉(zhuǎn)換規(guī)則。
1.7 消息格式轉(zhuǎn)換
消息格式轉(zhuǎn)換組件是一個(gè)適配器組件,它使用消息轉(zhuǎn)換規(guī)則來(lái)協(xié)調(diào)標(biāo)準(zhǔn)服務(wù)與替換服務(wù)接口不一致的情況,對(duì)輸入消息和輸出消息進(jìn)行格式轉(zhuǎn)換。由于BPEL流程中的invoke活動(dòng)設(shè)置的輸入和輸出變量都是按照標(biāo)準(zhǔn)服務(wù)的消息類(lèi)型定義的,需要將標(biāo)準(zhǔn)服務(wù)的輸入消息格式轉(zhuǎn)換成替換服務(wù)的輸入消息格式和將替換服務(wù)的輸出消息格式轉(zhuǎn)換成標(biāo)準(zhǔn)服務(wù)的輸出消息格式。Web服務(wù)接口描述是基于XML格式的WSDL文件,因此采用XSLT進(jìn)行消息格式轉(zhuǎn)換。消息格式轉(zhuǎn)換包括兩個(gè)部分,即制定消息轉(zhuǎn)換規(guī)則和消息轉(zhuǎn)換。圖4顯示了基于瀏覽器的設(shè)計(jì)界面,用戶(hù)可以通過(guò)簡(jiǎn)單地建立數(shù)據(jù)間的映射關(guān)系來(lái)設(shè)計(jì)源消息格式與目標(biāo)消息格式之間的轉(zhuǎn)換規(guī)則,系統(tǒng)會(huì)根據(jù)建立的映射關(guān)系自動(dòng)生成XSLT轉(zhuǎn)換規(guī)則,從而使得設(shè)計(jì)人員不需要熟悉XSLT技術(shù)就可以建立消息轉(zhuǎn)換規(guī)則。
消息轉(zhuǎn)換組件負(fù)責(zé)根據(jù)轉(zhuǎn)換規(guī)則將消息格式轉(zhuǎn)換為目標(biāo)格式。本文采用適配器模式將目前應(yīng)用最廣泛的XSLT引擎(Xalan、Saxon和XT)集成到系統(tǒng)中,用戶(hù)可以通過(guò)配置選擇使用的引擎,如圖5所示。
2 實(shí)驗(yàn)分析
本文提出的動(dòng)態(tài)代理將搜索替換服務(wù)與流程運(yùn)行分成兩個(gè)獨(dú)立的階段。搜索替換服務(wù)階段負(fù)責(zé)搜索標(biāo)準(zhǔn)服務(wù)的等價(jià)服務(wù),要求獲得等價(jià)服務(wù)的準(zhǔn)確性盡可能高。在流程運(yùn)行階段如果調(diào)用伙伴服務(wù)失敗,則動(dòng)態(tài)代理使用搜索階段獲得的等價(jià)服務(wù)替換失敗服務(wù)執(zhí)行,要求動(dòng)態(tài)代理對(duì)性能的影響盡可能小。鑒于上述原因,本章通過(guò)兩個(gè)實(shí)驗(yàn)分別對(duì)搜索等價(jià)服務(wù)的準(zhǔn)確性和動(dòng)態(tài)代理對(duì)性能的影響進(jìn)行分析。
XMethods[12]發(fā)布了大量的Web服務(wù)的WSDL文件,從這些服務(wù)中選擇了四類(lèi)服務(wù)用于評(píng)估搜索服務(wù)的準(zhǔn)確性,分別為郵編搜索服務(wù)(10個(gè))、天氣查詢(xún)服務(wù)(7個(gè))、短信服務(wù)(16個(gè))和email驗(yàn)證服務(wù)(7個(gè))。這四類(lèi)服務(wù)的搜索結(jié)果統(tǒng)計(jì)如圖6所示。準(zhǔn)確率是指針對(duì)一個(gè)搜索請(qǐng)求提供了正確搜索結(jié)果的比例。其定義為:搜索結(jié)果中正確的服務(wù)個(gè)數(shù)/搜索結(jié)果的服務(wù)總數(shù)×100%。召回率是指針對(duì)某個(gè)搜索請(qǐng)求實(shí)際產(chǎn)生的正確搜索結(jié)果數(shù)與應(yīng)該產(chǎn)生的正確結(jié)果的總數(shù)的比例。其定義為:搜索結(jié)果中正確的服務(wù)個(gè)數(shù)/應(yīng)該獲得的服務(wù)總數(shù)×100%。例如,搜索短信服務(wù)時(shí),搜索的服務(wù)總數(shù)為20個(gè)。其中包括所有的短信服務(wù)(16個(gè)),所以正確率為16/20×100%=80%,召回率為16/16×100%=100%。
申請(qǐng)貸款流程是一個(gè)常見(jiàn)的BPEL業(yè)務(wù)流程的例子[1,2]。申請(qǐng)貸款流程組合了風(fēng)險(xiǎn)評(píng)估服務(wù)(riskAssessmentService)和貸款評(píng)估服務(wù)(loanApprovalService)兩個(gè)服務(wù)。申請(qǐng)貸款流程通過(guò)這兩個(gè)服務(wù)來(lái)評(píng)估是否批準(zhǔn)客戶(hù)的貸款申請(qǐng)。具體處理過(guò)程為:客戶(hù)提出貸款申請(qǐng),申請(qǐng)信息包括個(gè)人信息和貸款金額。通過(guò)風(fēng)險(xiǎn)評(píng)估服務(wù)可知貸款申請(qǐng)的風(fēng)險(xiǎn)度,如果為低風(fēng)險(xiǎn)且貸款金額小于100 000元,則批準(zhǔn)貸款申請(qǐng);否則由貸款評(píng)估服務(wù)來(lái)決定貸款是否批準(zhǔn)。風(fēng)險(xiǎn)評(píng)估服務(wù)和它的替換服務(wù)分別簡(jiǎn)稱(chēng)為RAS和AltRAS。假設(shè)RAS出現(xiàn)系統(tǒng)異常,則動(dòng)態(tài)代理使用AltRAS代替RAS執(zhí)行,各組件的交互關(guān)系如圖7所示。流程的運(yùn)行環(huán)境是Intel雙核1.80 GHz、512 MB內(nèi)存和Windows XP操作系統(tǒng)。BPEL流程服務(wù)部署在本地,兩個(gè)評(píng)估服務(wù)及其替換服務(wù)部署在遠(yuǎn)程的計(jì)算機(jī)上。
運(yùn)行結(jié)果性能比較如8所示,不帶監(jiān)控表示流程在沒(méi)有擴(kuò)展的ActiveBPEL引擎上運(yùn)行的統(tǒng)計(jì)數(shù)據(jù);動(dòng)態(tài)監(jiān)控表示流程在已經(jīng)擴(kuò)展了的具有動(dòng)態(tài)代理功能的ActiveBPEL引擎中運(yùn)行,并假設(shè)風(fēng)險(xiǎn)評(píng)估服務(wù)和貸款評(píng)估服務(wù)總是在有一個(gè)服務(wù)失敗的情況下統(tǒng)計(jì)數(shù)據(jù)。從圖8中可以看出