專利名稱：用于使用uddi來調(diào)解web服務的方法和設備的制作方法
技術領域：
本發(fā)明涉及用于對Web (網(wǎng)絡)服務進行支持的方法和設備，尤 其涉及Web服務的動態(tài)服務質(zhì)量(QoS)的管理。
背景技術：
萬維網(wǎng)聯(lián)盟(W3 C )已經(jīng)將Web服務定義為被設計為支持網(wǎng)絡上 可協(xié)同操作的機器到機器的交互的軟件系統(tǒng)。Web服務通常僅是在能 夠通過諸如因特網(wǎng)之類的網(wǎng)絡被訪問并且能夠在宿主(host)所請求 服務的遠程系統(tǒng)上執(zhí)行的應用編程接口 (API)。例如，Web服務的 示例包括由旅行社通過因特網(wǎng)所提供的機票預訂服務、用于建立3G 運營商所提供的HSDPA (高速下行鏈路分組接入)連接的呼叫建立 服務、以及用于在兩個終端用戶之間建立多媒體會話的服務。
已經(jīng)研發(fā)了多種不同的協(xié)議和格式來管理Web服務。
UDDI (統(tǒng)一描述、發(fā)現(xiàn)和集成協(xié)議)是為用于發(fā)布和發(fā)現(xiàn)關于 Web服務的元數(shù)據(jù)的協(xié)議。UDDI服務器擔當Web服務的服務代理 (service broker)。服務提供者能夠在UDDI服務器中注冊(register) 與其服務相關的信息，并且服務請求者能夠聯(lián)系UDDI服務器以便根 據(jù)在UDDI服務器中所存儲的信息來尋找適當?shù)姆铡?br> WSDL (Web服務描述語言)是用于描述待提供的Web服務的 XML (可擴展標記語言)格式。例如，服務請求者可以從UDDI服務 器或從服務提供者接收WSDL文件作為服務請求的結果。WSDL文件 將對服務請求者需要了解以便使用Web服務的細節(jié)進行解釋。
SOAP (簡單對象訪問協(xié)議)是能夠被用于例如服務提供者與服 務請求者之間的通信的基于XML的消息封裝格式。
UDDI服^器上的服務相關的信息。、這意味著關于服務的信P息被存;者 在UDDI服務器中并且能夠在服務請求者在對所期望的服務進行搜索 中聯(lián)系UDDI服務器時被搜索。如果在UDDI服務器接收到服務請求 時找到一個或數(shù)個適當服務，則其能夠例如通過向服務請求者發(fā)送每個適當服務的服務提供者的地址或與每個服務相關聯(lián)的WSDL文件 或URL (統(tǒng)一資源定位符)來進行響應。
在UDDI服務器中所存儲的關于服務的信息通常將包括如下數(shù) 據(jù)例如提供服務的公司名稱、服務類型以及連接到所述服務所需的 信息(例如，URL)。所述信息還可以包括QoS信息，例如Web服 務容量(即，能夠支持的同時請求的數(shù)目)、關于Web服務的魯棒性 的信息以及與Web服務的性能相關的信息。W3C的文獻"QoS for Web Services: Requirements and Possible Approaches ，， http:〃www.w3c.or.kr/kr-office/TR/2003/ws畫qos/描述了對于web服務的 QoS要求。
美國專利申請US2005/0235053公開了 一種用于搜索Web服務的 方法和機制，其使得服務請求者可以連同有關每個服務的服務歷史的 信息一起接收可能服務的列表。服務請求者接著能夠根據(jù)所接收的信 息從所述列表中選擇服務。出于該目的，服務提供者將收集有關過去 所遞送的服務質(zhì)量的信息，即，所述服務的實際操作所產(chǎn)生的服務歷 史，并將該信息提供給UDDI站點。
然而，從服務請求者的角度來看，現(xiàn)有技術的用于搜索Web服務 的機制具有缺陷，原因在于它們沒有特別關注服務請求者的興趣和需 求。服務請求者可能對特定服務具有特別的QoS要求。但是利用當今 可用的Web服務解決方案，服務請求者難以找到滿足他/她的要求的 Web服務。例如，服務請求者可能希望使用Web服務來建立兩個終 端用戶之間的多媒體會話。請求者對于會話具有特定的QoS要求，如 傳輸速率、分組丟失、傳輸延遲和抖動延遲。利用以上所提到的W3C 文獻和美國專利申請中所描述的Web服務解決方案，服務請求者通常 能夠接收到與web服務的容量相關的某些信息或者與服務在過去所能 夠提供的QoS相關的信息，但是這將不會為請求者給出任何關于請求 者針對他/她的會話將接收到的QoS的信息。Web服務容量根據(jù)當前 進行中的會話的數(shù)量及其QoS要求而動態(tài)變化。歷史上已經(jīng)提供了最 佳QoS的服務可能在請求者希望建立多媒體會話的時候由于那時大 量進行中的會話而并非是他/她的最佳選擇。如果存在若干服務提供 者，則服務請求者希望從能夠最佳滿足他/她的QoS要求的服務提供 者那里獲得服務。服務請求者將可能不會對諸如所能夠支持的同時請求數(shù)量之類的一般QoS要求感興趣。他/她主要會對現(xiàn)在他/她能夠從 服務提供者獲得的最佳服務質(zhì)量是什么感興趣。

發(fā)明內(nèi)容
如以上所提到的，從服務請求者的角度來看，當今可用的Web 服務解決方案并未關注QoS支持。因此，本發(fā)明的目的是提供用于支 持Web服務中的動態(tài)QoS要求的方法和設備。
借助于根據(jù)本發(fā)明的UDDI服務器和UDDI服務器中的方法來實 現(xiàn)上述目的。
本發(fā)明的第一實施例提供了一種用于對由多個服務提供者向多 個服務請求者提供的Web服務進行調(diào)解(mediate)的UDDI服務器。 UDDI服務器包括用于存儲與Web服務相關聯(lián)的信息的Web服務寄存 器。Web服務寄存器包括用于存儲分別與每個Web服務相關聯(lián)的QoS 狀態(tài)信息的數(shù)據(jù)集合。QoS狀態(tài)信息是關于相關聯(lián)的Web服務能夠為 服務請求者提供的當前QoS的信息。UDDI服務器還包括用于根椐從 服務提供者接收的動態(tài)服務狀態(tài)信息對存儲在所述數(shù)據(jù)集合中的QoS 狀態(tài)信息進行周期性地更新的裝置。
本發(fā)明的第二實施例提供了一種在用于對由多個服務提供者向 多個服務請求者提供的Web服務進行調(diào)解的UDDI服務器中的方法。 所述方法包括在UDDI服務器中注冊至少一個Web服務的步驟。該注 冊步驟包括存儲與每個Web服務相關聯(lián)的信息，所述信息包括與每個 Web服務相關聯(lián)的QoS狀態(tài)信息。QoS狀態(tài)信息是關于相關聯(lián)的Web 服務能夠向服務請求者提供的當前QoS的信息。此外，所述方法包括 根據(jù)分別從每個Web服務的服務提供者接收的動態(tài)服務狀態(tài)信息對 所存儲的QoS狀態(tài)信息進行周期性地更新的步驟。
本發(fā)明進一步的實施例提供了 一種用于響應于服務請求而選擇 滿足服務請求者的QoS要求的Web服務的方法和UDDI服務器。
本發(fā)明的優(yōu)勢在于允許將動態(tài)QoS納入考慮的Web服務調(diào)解 (mediation)。本發(fā)明提供了對QoS供應的支持，這使得UDDI服務 器可以通過將服務提供者與滿足服務請求者要求的Web服務進行匹 配而為服務請求者提供更好的服務。
本發(fā)明的另 一個優(yōu)勢在于其提供了對服務提供者的資源進行更好的資源管理的工具。根據(jù)本發(fā)明，由于可以考慮到不同服務提供者 的容量，所以服務請求可以更好地在不同服務提供者之間分布。因此， 可以避免因服務請求而使不具有可用容量的服務提供者過載，而是作 為替代將服務請求導向具有可用容量的服務提供者。這可能對各方都 會更為有利的，原因在于向服務請求者提供質(zhì)量很差的服務或者根本 不提供服務會損害服務提供者的聲譽。
本發(fā)明實施例進一步的優(yōu)勢在于它可以提供對Web "良務的更快 遞送，原因在于可以避免對Web服務的不必要的請求。由于根據(jù)本發(fā) 明實施例的UDDI服務器能夠給出與滿足服務請求者的QoS要求的 Web服務相關的信息，所以這是可能的。因此，服務請求者可以避免 向無法支持該服務請求者的要求的Web服務做出請求。
本發(fā)明實施例又另一優(yōu)勢在于可能提供通過偏好(preference)寄 存器來定制(customize)對Web服務的請求。
通過閱讀以下結合附圖所進行的詳細描述，本發(fā)明實施例的更多 優(yōu)勢和特征將變得顯而易見。


圖1是圖示用于實現(xiàn)Web服務的一般系統(tǒng)體系結構的示意性框圖。
圖2是圖示根據(jù)本發(fā)明實施例的用于實現(xiàn)Web服務的系統(tǒng)體系結 構的示意性框圖。
圖3a是圖示根據(jù)本發(fā)明實施例的QoS模型的第一示例的示意性 框圖。
圖3b是圖示根據(jù)本發(fā)明實施例的QoS模型的第二示例的示意性 框圖。
圖4是圖示根據(jù)本發(fā)明的UDDI服務器中的方法實施例的流程圖。
圖5是圖示根據(jù)本發(fā)明的可替換實施例的用于實現(xiàn)Web服務的系 統(tǒng)體系結構的示意性框圖。
圖6是圖示根據(jù)本發(fā)明實施例的UDDI服務器(如圖5所示的 UDDI服務器)中的方法的流程圖。
圖7是圖示根據(jù)本發(fā)明實施例的UDDI服務器中用于管理請求隊 列的方法的流程圖。
具體實施例方式
現(xiàn)在將參考其中示出了本發(fā)明優(yōu)選實施例的附圖對本發(fā)明進行 更為全面的描述。然而，本發(fā)明可以以許多不同形式來實現(xiàn)，并且不
應被理解為局限于這里所闡釋的實施例；相反，對于本領域技術人員 而言，提供這些實施例以使得本公開內(nèi)容全面和完整并且將全面?zhèn)鬟_ 本發(fā)明的范圍。在附圖中，相同的附圖標記表示相同部件。
圖1示意性圖示了用于實現(xiàn)Web服務的一般體系結構。服務提供 者11已經(jīng)實施了供其他人經(jīng)由諸如因特網(wǎng)之類的網(wǎng)絡開放使用的 Web服務lla。為了推廣Web服務，服務提供者向擔當Web服務代 理的UDDI服務器12注冊Web服務lla。注冊步驟13可以包括月良 務提供者傳送諸如服務提供者名稱、服務類型和訪問服務所需信息之 類的信息。服務提供者還可以向UDDI服務器傳送描述Web服務的 WSDL文件。UDDI服務器12存儲從服務提供者12所接收的關于Web 服務lla的信息以及與Web服務器寄存器14中由其他服務提供者所 提供的其他Web服務相關的信息。希望使用特定類型的Web服務的 服務請求者15可以通過向UDDI服務器12發(fā)送搜索請求16來尋找 適當?shù)姆?。例如，假設服務請求者可能想要在線預訂機票，Web服 務lla為旅行預訂服務并且服務提供者12例如是旅行社。搜索請求 16于是將指示服務請求者想要搜索旅行預訂服務。UDDI服務器12 將針對旅行預訂服務檢查Web服務寄存器14并在搜索響應17中返回 與所注冊的任何旅行預訂服務相關的信息。在這種情況下，UDDI服 務器12將在搜索響應17中發(fā)送關于Web服務lla并且可能還與向 UDDI服務器注冊的其他旅行預訂服務相關的信息。根據(jù)UDDI服務 器對特定Web服務所存儲的信息類型，搜索響應例如可以包括諸如服 務提供者名稱、用于訪問服務或WSDL文件的URL之類的信息。搜 索響應17后面可以是，服務請求者15連接18到服務提供者11以請 求使用Web服務lla。服務提供者11接著可以通過向服務請求者15 發(fā)送WSDL文件來進行響應，所述WSDL文件向服務請求者提供了 使用所述服務所需的所有信息。在這種情況下，WSDL文件例如可以 指定諸如期望起飛時間、目的地和航線之類的參數(shù)，服務提供者應當 在使用Web服務lla時發(fā)送這些參數(shù)。根據(jù)WSDL文件中的信息，可以在服務請求者15處建立Web服務客戶端20。在服務請求者已經(jīng) 從UDDI服務器12接收到描述服務的WSDL文件的情況下，服務請 求者能夠接著開始直接使用Web服務而無需首先聯(lián)系服務提供者以 接收WSDL文件。
應當注意的是，有許多不同方式來實現(xiàn)Web服務并且圖1和以上 描述僅構成一個示例。
如以上所提到的，從服務請求者的角度來看，當今可用的Web 服務解決方案沒有關注QoS支持。然而，本發(fā)明的實施提供了用于支 持Web服務中的動態(tài)QoS要求的方法和UDDI服務器。
圖2是圖示根據(jù)本發(fā)明實施例的UDDI服務器21的示意性框圖。 所述UDDI服務器包括Web服務寄存器22，其中存儲與由不同服務 提供者24所提供的Web服務23相關的信息。Web服務寄存器對于 向UDDI服務器所注冊的每個Web服務而言具有一個記錄25。每個 記錄25包括服務規(guī)范26,其是包含與服務相關的諸如服務類型、月良 務提供者名稱、到服務的URL等之類的完全靜態(tài)的數(shù)據(jù)的數(shù)據(jù)集合。 根據(jù)本發(fā)明的該實施例的Web服務寄存器中的記錄還將包括含有與 相關聯(lián)的Web服務能夠向服務請求者提供的當前QoS相關的QoS狀 態(tài)信息的服務狀態(tài)數(shù)據(jù)集合27。與在服務規(guī)范26中存儲的數(shù)據(jù)相比， 在服務狀態(tài)數(shù)據(jù)集合27中存儲的數(shù)據(jù)通常是高度動態(tài)的。對于用于 HSDPA連接的呼叫建立的Web服務而言，服務狀態(tài)數(shù)據(jù)集合例如可 以包括諸如Web服務所能夠提供的當前傳輸速率之類的數(shù)據(jù)。該傳輸 速率依賴于同時進行的會話數(shù)量并且由此將隨Web服務負載的變化 而變4匕。
根據(jù)從不同服務提供者所接收的更新信息對存儲在服務狀態(tài)數(shù) 據(jù)集合中的QoS狀態(tài)信息進行周期性地更新。例如，這些更新可以響 應于從服務提供者接收到周期性地自動推送(push)消息而發(fā)生，或 者借助于UDDI服務器所進行的周期性地主動拉取(pull)來進行。 向UDDI服務器傳輸經(jīng)更新的動態(tài)QoS狀態(tài)信息的模式可以取決于 Web服務。例如，可以使用推送來更新經(jīng)常被i青求的流行Web服務 的QoS狀態(tài)信息，而拉取則被用于更新QoS狀態(tài)更新并非那么關4建 的不常被請求的服務。但是許多用于向UDDI服務器傳輸更新的不同 方案也是可能的，并且所實施的方案是選擇的問題。QoS狀態(tài)信息例如可以被承載于不同服務提供者與UDDI服務器之間的SOAP消息中。
UDDI服務器21任選地還可以包括QoS模型寄存器28。 QoS模型寄存器包括多個預定義QoS模型29。 QoS模型均指定多個QoS參數(shù)字段并且表示W(wǎng)eb服務的QoS簡檔(profile) 。 QoS模型可以作為服務狀態(tài)數(shù)據(jù)集合27的模板。使用具有預定義QoS模型集合的QoS模型寄存器將簡化服務狀態(tài)數(shù)據(jù)集合27的處理。
如所提到的，QoS模型寄存器28中的每個條目(即，每個QoS模型)具有表示W(wǎng)eb服務的QoS簡檔的多個字段。圖3a和3b圖示了 QoS模型的兩個示例。圖3a圖示了尤其適于描述用于建立數(shù)據(jù)連接的服務的QoS簡檔的QoS模型31。 QoS模型31包括用于存儲傳輸速率、分組丟失、傳輸延遲、峰值速率和平均速率的字段32、 33、 34、34a和34b。圖3b圖示了尤其適于描述用于建立多媒體會話的服務的QoS簡檔的QoS模型35。 QoS模型35包括用于存儲傳輸速率、分組丟失、傳輸延遲和抖動延遲的字段36、 37、 38和39。所^使用的QoS參數(shù)由此將取決于Web服務的類型。可能相關的一些其他QoS參數(shù)示例為最大速率、平均速率、最小速率、分辨率、采樣速率等，或者與音頻、視頻和數(shù)據(jù)的質(zhì)量相關的參數(shù)。
許多不同服務使用相同的QoS模型是可能的。使用相同的QoS模型將使得更容易對相同類型的Web服務進行比較。如果Web服務對應于若千不同類型的服務的組合，則Web服務與若干QoS模型相關聯(lián)也是可能的。
如果使用QoS模型寄存器28，則優(yōu)選地，當新的服務在UDDI服務器12處被注冊時，其必須與至少一個QoS模型29相關聯(lián)。如果沒有一個QoS模型與所述服務相符(fit)，則能夠創(chuàng)建新的QoS模型并將其存儲在QoS模型寄存器28中。優(yōu)選地，這應當由UDDI服務器以受控的方式來進行。
不保證QoS要求的服務23可以與QoS模型寄存器28中的NULL(空)條目相關聯(lián)。
一旦注冊了服務并選擇了 QoS模型，UDDI服務器就將使用所選擇的QoS模型作為模板來創(chuàng)建用于QoS監(jiān)視的服務狀態(tài)數(shù)據(jù)集合27。服務狀態(tài)數(shù)據(jù)集合27被鏈接(link)到所注冊的服務。如以上所提到的，服務狀態(tài)數(shù)據(jù)集合27的內(nèi)容將根據(jù)從Web服務的提供者周期性地接收的或在請求時所接收的信息而被動態(tài)更新。服務狀態(tài)數(shù)據(jù)集合的內(nèi)容將指示相關聯(lián)的Web服務當前所能夠支持的最高QoS要求。
當使用QoS模型時，服務請求者40的設備可適于將QoS要求的集合直接包括在服務請求41中?？商鎿Q地，服務請求者可以針對沒有QoS要求的特定類型的服務向UDDI服務器發(fā)送服務請求，并且UDDI服務器可以通過向服務請求者發(fā)送包括與所請求服務類型相對應的QoS模型的消息42來對服務請求進行響應，以便指示服務請求者可以在QoS要求的集合中指定什么QoS參數(shù)。服務請求者將接著通過在響應消息43中指定期望的QoS要求來進行響應，并且UDDI服務器21在已經(jīng)從服務請求者40接收到期望的QoS要求之后將開始查找適當?shù)姆铡?br> 根據(jù)以上描述，對于本領域技術人員而言將會很明顯的是，本發(fā)明的實施方式需要對根據(jù)現(xiàn)有技術的UDDI服務器進行一些適配。自然選擇是通過向UDDI服務器提供新的軟件來實施本發(fā)明，不過以固件、硬件或其組合的實施方式也是可行的。例如，UDDI服務器21將必須被適配成使得Web服務寄存器被安排為存儲QoS狀態(tài)信息。UDDI服務器還將必須被配備以用于與服務提供者進行通信以接收和更新QoS狀態(tài)信息的裝置。這樣的更新裝置在圖2中示意性圖示并且由附圖標記44來表示。所述更新裝置通常以軟件來實施，并且優(yōu)選地被安排為使用已有的用于與服務提供者進行通信的接口 。
除UDDI服務器中的適配之外，還要求服務提供者的設備的一些適配，原因在于服務提供者應當能夠向UDDI服務器提供服務狀態(tài)信息，并且周期性地向UDDI服務器發(fā)送該信息的更新。此外，服務提供者還應當具有必要裝置以便例如在其當前可用容量方面跟蹤(keeptrackof)其自己的QoS狀態(tài)。還有必要對服務請求者的設備進行一定的適配。根據(jù)本發(fā)明的實施例，服務請求者應當具有用于向UDDI服務器傳送QoS要求的裝置。如果使用QoS模型，則服務請求者例如應當能夠獲得QoS模型并且將QoS要求表示成與適當QoS模型相對應。對本領域技術人員很明顯的是，這樣的適配通常在軟件中進行。
圖4是圖示根據(jù)本發(fā)明的UDDI服務器中的方法實施例的流程圖。在步驟401,開始在Web服務寄存器中注冊新的Web服務。這可以通過UDDI從服務提供者接收注冊請求而被發(fā)起。根據(jù)該實施例，所
述方法接著在步驟402繼續(xù)，其中搜索QoS模型寄存器，以查明是否存在與待注冊的Web服務相符的預定義QoS模型。如果沒有找到相符的QoS模型，則創(chuàng)建相符的QoS模型并將其存儲在QoS模型寄存器中，步驟403。在步驟404中選擇相符的QoS模型與所述Web服務相關聯(lián)。在步驟405中，根據(jù)所選擇的QoS模型為所述Web服務創(chuàng)建服務狀態(tài)數(shù)據(jù)集合。接著，將從服務提供者所提供的QoS狀態(tài)信息存儲在服務狀態(tài)數(shù)據(jù)集合中，步驟406。此后，完成Web服務的注冊，除其他之外，這尤其可以包括在Web服務寄存器中存儲以上所提到的Web服務的服務規(guī)范，步驟407。當注冊完成時，所述方法將繼續(xù)以更新步驟408,其中根據(jù)通過UDDI服務器所發(fā)起的主動拉取或服務
信息，對所存儲的服務的QoS狀態(tài)信息進行周期性地更新。
以上所提到的對UDDI進行適配以存儲和監(jiān)視與Web服務能夠提供給服務請求者的當前QoS相關的信息將使得UDDI可以向服務請求者提供更好的服務請求響應。然而，如果如圖5所示以及以下將要描述的那樣在UDDI服務器中實施多個附加特征，貝'J UDDI能夠向服務請求者提供甚至更好的服務。
圖5是根據(jù)本發(fā)明的可替換實施例的UDDI服務器50的示意性框圖。UDDI服務器50包括Web服務寄存器22,其列出不同Web服務提供者24-1， ...， 24-N所提供的多個Web服務。多個服務請求者40-1, ...， 40-M可以聯(lián)系UDDI以便尋找期望的Web服務。Web月良務寄存器22包括每個所注冊Web服務的記錄25,其中每個記錄25包括服務規(guī)范26和服務狀態(tài)數(shù)據(jù)集合27，所述服務狀態(tài)數(shù)據(jù)集合27具有如上所述的被動態(tài)更新的內(nèi)容。根據(jù)本發(fā)明的該實施例，UDDI服務器50還包括決策制訂功能(decision making function DMF ) 51。DMF 51被安排成使用在服務狀態(tài)數(shù)據(jù)集合27中所存儲的QoS狀態(tài)信息和服務請求者所提供的QoS要求來為服務請求者選擇Web服務。
當UDDI從例如服務請求者40-1接收到對于期望服務類型的服務請求Rl以及QoS要求集合時，DMF 51將處理所述服務請求并從Web服務寄存器中所注冊的期望類型的Web服務中選擇Web服務，以使得如相關聯(lián)的服務狀態(tài)數(shù)據(jù)集合27中所存儲的QoS狀態(tài)信息所指示的，所選擇的Web服務能夠提供的當前QoS滿足所述QoS要求集合。UDDI接著將在服務請求響應消息中向服務請求者發(fā)送與所選擇的Web服務相關的信息。由此，服務請求者將接收與已知滿足服務請求者的QoS要求的單個Web服務相關的信息，而不是從UDDI接收的可能的Web服務的列表。從服務請求者的角度來看，與現(xiàn)有技術的解決方案相比，這被認為是非常有吸引力的，原因在于其為服務請求者省去了可能必須在多個Web服務之間進行選擇的麻煩。根據(jù)現(xiàn)有技術的解決方案，服務請求者甚至不了解UDDI已經(jīng)發(fā)送了與其相關的信息的Web服務是否合適，原因在于根據(jù)現(xiàn)有技術沒有提供與滿足服務請求者的QoS要求的Web服務能力相關的信息。
圖5所示的UDDI服務器50還可選地包括偏好寄存器52。在偏好寄存器52中可以存儲與服務請求者40-1,…，40-M和/或服務提供者24-l， ...， 24-N相關的更多靜態(tài)偏好信息。在偏好寄存器中所存儲的偏好信息通常并非是服務請求特定的。其可以是來自他人的評價(rating)，優(yōu)選的收費方案、優(yōu)選的服務提供者/請求者、QoS參數(shù)的權重(weight)等。并不排除還可以在偏好寄存器中存儲實際的QoS要求，例如，如果服務請求者總是請求具有相同QoS要求的相同服務的話。但QoS要求通常并不存儲在偏好寄存器中。服務請求者例如能夠根據(jù)定價策略、先前接收的服務等來不斷地更新偏好寄存器。
如果使用了偏好寄存器52,如以下將進一步詳細解釋的，DMF
應當適于在選擇Web服務時考慮存儲在偏好寄存器中的相關偏好信自
可選地，UDDI服務器50此外可以包括一個或數(shù)個請求隊列53。可以為在UDDI中注冊的每個Web服務類型提供 一 個請求隊列。如果對于所注冊的Web服務而言當前沒有可用容量，則針對特定類型的Web服務的服務請求可以被放入與所述特定類型的Web服務相關聯(lián)的請求隊列中，以使得與所述服務請求相關聯(lián)的偏好和/或QoS要求能夠得以滿足。所述服務請求被放入請求隊列中以等待可用容量。
UDDI服務器50的DMF優(yōu)選地被安排為使其對Web力良務的選擇不僅基于QoS要求和所請求Web服務的QoS狀態(tài)信息，而且還基于所存儲的與服務請求者和/或服務提供者相關的任何存儲的偏好信息以及請求隊列狀態(tài)。DMF并不限于任何特定類型的決策制訂或選擇算法。可以使用許多不同的算法。當存在多個適合的Web服務可供選4奪時，例如可以使用選擇具有最大容量的算法、隨機選擇算法和循環(huán)機制。
圖6是圖示根據(jù)本發(fā)明實施例的諸如UDDI服務器50之類的UDDI服務器中的方法示例的流程圖。圖6圖示了如何為服務請求選擇適當?shù)腤eb服務。在步驟501中，接收服務請求。即使請求隊列不為空，也立即處理所述請求，這是因為有許多將服務請求存儲在隊列中的理由。首先應當檢查新的服務請求。在步驟502中，UDDI服務器的DMF將找出不同服務提供者所提供的、能夠提供所請求類型的服務的所有Web服務。在步驟502中所找到的Web服務在這里被稱作第一 Web服務集合。在步驟503中，由DMF使用偏好寄存器52中的信息對第一 Web服務集合進行第一過濾。例如，該步驟將移除服務提供者所提供的、偏好寄存器的偏好信息指出無論Web服務的狀態(tài)如何也永遠不被用于當前服務請求者的那些Web服務。剩余Web服務的集合在這里被稱作第二 Web服務集合并且被臨時保存用于所述服務請求。在步驟504中，由DMF獲取與第二 Web服務集合相關聯(lián)的、并被存儲在Web服務寄存器中的QoS狀態(tài)信息。在步驟505中，使用來自服務請求者的QoS要求再次對第二集合進行過濾以得到第三Web服務集合，其包括根據(jù)其相關聯(lián)的QoS狀態(tài)信息而滿足所述QoS要求的那些Web服務。如果在步驟506a中發(fā)現(xiàn)第三集合為空，則在步驟506b中將服務請求存儲在請求隊列53中。否則，根據(jù)該實施例，將在步驟507中使用偏好寄存器52中的偏好信息對Web服務進行排序(rank)。排序中所使用的參數(shù)可以是定價、可信度、請求者與提供者之間的關系、QoS參數(shù)的權重等。如果若干Web服務具有相同的最高排名(ranking)，則能夠使用許多算法來進行選擇。非常簡單的 一種算法為隨機選擇。將隨機選出具有最高排名的Web服務之一。也可以使用循環(huán)方法，即依次選擇Web服務。略為先進的算法將考慮Web服務的當前可用容量。可以選擇具有最高可用容量的Web服務，以使得能夠在所有Web服務上均勻分布負載。甚至能夠在決策制訂時使用與請求隊列53中的當前請求相關的信息。如果存在等待特定Web服務獲得足夠容量的請求，則如果存在具有相同排名的其他可用Web服務，就避免該特定Web服務用于其他服務請求。在DMF中能夠使用多種算法。然而，在步驟508中，DMF根據(jù)某一決策制訂算法來選擇Web服務。在步驟509中，向服務請求者發(fā)送具有關于所選擇的Web服務的信息的服務請求響應。
如果使用一個或數(shù)個請求隊列，則存在若干不同的對請求隊列中的請求進行管理的方式。例如，可以以預定間隔進行新的檢查來查明請求隊列中的任何服務請求是否可以得到滿足。 一種可選方式是在針對與請求隊列相關聯(lián)的Web服務類型更新QoS狀態(tài)信息時執(zhí)行檢查。圖7是圖示這種實施例的流程圖。圖7圖示了 DMF51如何在更新與Web服務相關的QoS狀態(tài)信息時管理請求隊列53的示例。在步驟601中，更新Web服務的QoS狀態(tài)信息。(假設容量增加，但是存在若干QoS參數(shù)， 一些可能增加而其他可能減少。根據(jù)該實施例，針對每個服務狀態(tài)更新進行檢查)。在步驟602中，檢查與針對其進行了更新的服務類型相關聯(lián)的請求隊列53。如果請求隊列為空，則將沒有動作發(fā)生，步驟608。否則，在步驟603中，取出請求隊列中的第一服務請求以供處理。在步驟604中，當如以上結合圖6的步驟503所描述的那樣，在接收到請求時，DMF檢查Web服務是否處于以上所提到的所創(chuàng)建的第二 Web服務集合中。如果不處于第二集合中，則沒有動作發(fā)生，步驟608。否則，該過程進行至步驟605，在那里對照所更新的QoS狀態(tài)信息來檢查QoS要求。如果Web服務能夠滿足QoS要求，則在步驟606中選擇Web服務并且將服務請求響應發(fā)送回請求者。否則，該過程將繼續(xù)在步驟607中取得隊列中的下一個請求，并且接著將在步驟604開始過程步驟的重復。如果服務請求為請求隊列53中的最后請求，則沒有動作發(fā)生，步驟608。
根據(jù)本發(fā)明以上所描述的實施例，提供具有大容量的Web服務的服務提供者很可能被分配給服務請求者。本發(fā)明還向UDDI服務器的提供者提供了新的商業(yè)機會的可能性。UDDI服務器的提供者例如可以提供服務級別方案，其中服務提供者可以向UDDI服務器提供者支付費用以使其服務被排在UDDI服務器中的高質(zhì)量(premium)級別的服務中。如果存在若干可從中進行選擇的、能夠滿足QoS要求的Web服務，則UDDI可以被安排成總是比在服務級別方案中具有較低級別的任意其他Web服務更為優(yōu)先地選擇高質(zhì)量級別的服務。
如以上所提到的，現(xiàn)有技術的UDDI服務器僅提供了服務查找服務而并不支持QoS供應。另一方面，本發(fā)明的實施例提供了對QoS 供應的這種支持并且還提供了用于高效資源管理的工具。由于UDDI 服務器擔當Web服務的代理，所以希望所迷代理為服務提供者和服務 請求者這二者提供最佳可能服務。服務請求者想要得到能夠滿足其 QoS要求的服務。服務提供者的目標是使其系統(tǒng)資源最大化并且為盡 可能多的滿意用戶提供服務。這可以通過本發(fā)明的實施例來實現(xiàn)。
本領域技術人員根據(jù)以上描述將會意識到，為了實施所描述的本 發(fā)明的不同實施例，對軟件、固件和/或硬件進行修改是必要和/或適 當?shù)摹?br> 然采用了特定術語，、但是它們僅以 一般和說^性的含2來使用而并非 用于限制，本發(fā)明的范圍在以下權利要求中給出。
權利要求
1.一種用于對由多個服務提供者(24)向多個服務請求者(40)提供的Web服務(23)進行調(diào)解的UDDI服務器(21，50)，所述UDDI服務器包括用于存儲與所述Web服務相關聯(lián)的信息的Web服務寄存器(22)，其中所述Web服務寄存器包括用于存儲分別與每個Web服務相關聯(lián)的QoS狀態(tài)信息的數(shù)據(jù)集合(27)，所述QoS狀態(tài)信息是關于相關聯(lián)的Web服務能夠向服務請求者提供的當前QoS的信息，用于根據(jù)從所述多個服務提供者接收的動態(tài)服務狀態(tài)信息，對存儲在所述數(shù)據(jù)集合(27)中的所述QoS狀態(tài)信息進行周期性地更新的裝置(44)。
2. 如權利要求1所述的UDDI服務器(21 )，進一步包括QoS 模型寄存器(28)，其包括多個預定義QoS模型(29, 31， 35 ),每 個預定義QoS模型指定多個QoS參數(shù)字段(32， 33, 34， 36， 37， 38， 39),其中每個QoS模型表示W(wǎng)eb服務的QoS簡檔并且可以用 作為用于多個所述數(shù)據(jù)集合(27)的模板。
3. 如權利要求2所述的UDDI服務器(21),其中所述多個QoS 參數(shù)字段包括用于以下QoS參數(shù)中至少一個的字段傳輸速率、分組 丟失、傳輸延遲、抖動延遲、最大速率、最小速率、平均速率、分辨 率或采樣速率。
4. 如權利要求2或3所述的UDDI服務器(21 )，其中Web服 務寄存器(22 )被安排成將待注冊的第一 Web服務與至少一個預定義 QoS模型(29 )相關聯(lián)以創(chuàng)建與第一 Web服務相關聯(lián)的第 一數(shù)據(jù)集合， 其包含由所述至少一個預定義QoS模型所指定的多個QoS參數(shù)字段。
5. 如權利要求2-4中任一項所述的UDDI服務器(21),其中 QoS模型寄存器(28 )被安排成在沒有一個現(xiàn)有的預定義QoS模型(29 ) 與將要在Web服務寄存器中注冊的第二 Web服務相符的情況下注冊 新的QoS模型，并且其中Web服務寄存器被安排成將第二 Web服務 與新的QoS模型相關聯(lián)以創(chuàng)建與第二 Web服務相關聯(lián)的第二數(shù)據(jù)集 合(27 )。
6. 如權利要求1-5中任一項所述的UDDI服務器(21),其中 用于更新所述QoS狀態(tài)信息的所述裝置(44 )被安排成在UDDI服務器接收到與來自與數(shù)據(jù)集合相關聯(lián)的Web服務的服務提供者(24 )的 推送消息中的數(shù)據(jù)集合相關的動態(tài)服務狀態(tài)信息時對所述數(shù)據(jù)集合 (27)之一的QoS狀態(tài)信息進行更新。
7. 如權利要求1-5中任一項所述的UDDI服務器(21)，其中 用于更新所述QoS狀態(tài)信息的所述裝置(44 )被安排成周期性地拉取 所述Web服務之一的服務提供者(24)以便請求與所述Web服務相 關的動態(tài)服務狀態(tài)信息并且根據(jù)所接收的動態(tài)服務狀態(tài)信息，對與 Web服務相關聯(lián)的數(shù)據(jù)集合(27)中存儲的QoS狀態(tài)信息進行更新。
8. 如權利要求1 - 5中任一項所述的UDDI服務器(21)，其中 用于更新所述QoS狀態(tài)信息的所述裝置(44 )被安排成根據(jù)作為推送 信息或者作為由UDDI服務器周期性地拉取的信息而從與數(shù)據(jù)集合相 關聯(lián)的Web服務的服務提供者遞送的服務狀態(tài)信息來對所述數(shù)據(jù)集 合(27)之一的QoS狀態(tài)信息進行更新，并且其中UDDI服務器被安 排成根據(jù)Web服務類型對服務狀態(tài)信息的遞送模式進行適配。
9. 如權利要求1-8中任一項所述的UDDI服務器(50),其中 UDDI服務器進一步包括決策制定功能(51),其被安排成處理來自所述服務請求者的服務請求，所述服務請求者均與QoS 要求集合相關聯(lián)；并且分別為每個服務請求從在所述Web服務寄存器(22)中注冊的所 述Web服務中選擇Web服務，以使得在與Web服務相關聯(lián)的數(shù)據(jù)集 合(27)中存儲的QoS狀態(tài)信息所指示的、Web服務所能夠提供的當 前QoS滿足與服務請求相關聯(lián)的QoS要求集合。
10. 如權利要求9所述的UDDI服務器(50)，其中UDDI服務 器進一步包括偏好寄存器(52)，其中可以在偏好寄存器(52)中存 儲關于所述服務請求者(40)或服務提供者(24)的偏好的偏好信息， 并且其中決策制定功能(51 )進一步被安排成選擇Web服務以使得其 還與在所述偏好寄存器中存儲的服務請求者和/或服務提供者的偏好 信息相匹配。
11. 如權利要求IO所述的UDDI服務器(50),其中所述偏好信 息包括以下信息類型中的一個或數(shù)個關于Web服務評價的信息、優(yōu) 選收費方案、優(yōu)選服務提供者或請求者、不接受的服務提供者或請求 者、或QoS要求的權重或QoS要求。
12. 如權利要求9所述的UDDI服務器(50)，其中UDDI服務 器進一步包括至少一個請求隊列(53)，如果不存在滿足與服務請求 相關聯(lián)的QoS要求的可用Web服務，則能夠?qū)⑺龇照埱蟠鎯υ?所述請求隊列中。
13. 如權利要求10或11所述的UDDI服務器(50),其中所述 UDDI服務器進一步包括至少一個請求隊列(53),如果不存在滿足 與服務請求相關聯(lián)的QoS要求的、并且還與存儲在所述偏好寄存器(52 )中的服務請求者和/或服務提供者的偏好信息相匹配的可用Web 服務，則能夠?qū)⑺龇照埱蟠鎯υ谒稣埱箨犃兄小?br> 14. 如權利要求13所述的UDDI服務器(50),其中所述決策制 定功能(51 )進一步被安排成在選擇Web服務之前檢查所述請求隊列(53 )的狀態(tài)并且選擇Web服務以使得所述請求隊列中所存儲的服務 請求盡可能多地得到滿足。
15. 如權利要求9-13中任一項所述的UDDI服務器(50),其 中所述決策制定功能(51 )被安排成在存在若干可能選擇的Web服務 時根據(jù)決策算法來選擇Web服務。
16. —種在用于對由多個服務提供者(24 )向多個服務請求者(40 ) 提供的Web服務進行調(diào)解的UDDI服務器(21, 50)中的方法，所述 方法包括以下步驟在UDDI服務器中注冊(401-407)至少一個Web服務(23)， 所述注冊步驟包括存儲與每個Web服務相關聯(lián)的信息，所述信息包括 與每個Web服務相關聯(lián)的QoS狀態(tài)信息，所述QoS狀態(tài)信息是關于 相關聯(lián)的Web服務能夠向服務請求者提供的當前QoS的信息；以及根據(jù)分別從每個Web服務的服務提供者接收的動態(tài)服務狀態(tài)信 息，對所述存儲的QoS狀態(tài)信息進行周期性地更新(408 )。
17. 如權利要求16所述的方法，其中所述注冊步驟進一步包括 從QoS模型寄存器(28)中選擇(404)將與每個Web服務相關聯(lián)的 QoS模型(29)，所述QoS模型寄存器(28)包括多個預定義QoS 模型，每個預定義QoS模型指定多個QoS參數(shù)字段(32， 33， 34， 36, 37， 38， 39)，利用所選擇的QoS模型作為模板為每個Web服 務創(chuàng)建數(shù)據(jù)集合(27 )并且將所述QoS狀態(tài)信息映射到所述數(shù)據(jù)集合 中。
18. 如權利要求16所述的方法，其中所述注冊步驟進一步包括 在QoS模型寄存器(28)中搜索(402)分別與每個Web服務的類型相符的QoS模型(29),所述QoS模型寄存器(28)包括多個預定義QoS模型，每個預定義QoS模型指定多個QoS參數(shù)字段， 如果找到用于第一 Web服務的相符的QoS模型，貝'J選擇(404)所述相符的QoS模型以與第一 Web服務相關聯(lián)； 利用所選擇的相符的QoS模型作為模板為第一 Web服務創(chuàng)建(405 )數(shù)據(jù)集合(27);并且將與第一 Web服務相關聯(lián)的所述QoS狀態(tài)信息映射(406 )到所述數(shù)據(jù)集合中，如果沒有找到用于第一 Web服務的相符的QoS模型，則定義(403)與第一 Web服務的類型相符的新的QoS模型； 在QoS模型寄存器中注冊新的QoS模型； 選擇(404)所述新的QoS模型以與第一 Web服務相關聯(lián)； 利用所選擇的新的QoS模型作為模板為第一 Web服務創(chuàng)建 (405 )數(shù)據(jù)集合(27);并且將與第一 Web服務相關聯(lián)的所述QoS狀態(tài)信息映射(406 )到所述數(shù)據(jù)集合中。
19. 如權利要求16- 18中任一項所述的方法，其中更新所述QoS 狀態(tài)信息的所述步驟(408 )包括周期性地接收來自Web服務的服務 提供者的推送消息中的動態(tài)服務狀態(tài)信息。
20. 如權利要求16- 18中任一項所述的方法，其中更新所述QoS 狀態(tài)信息的所述步驟(408 )包括周期性地從Web服務的服務提供者 拉取動態(tài)服務狀態(tài)信息。
21. 如權利要求16-20中任一項所述的方法，進一步包括步驟 從所述服務請求者之一接收(501)服務請求，所述服務請求與QoS要求集合相關聯(lián)；以及選擇(502-508 ) UDDI服務器中所注冊的所述至少一個Web服務 之一，所述選擇步驟包括將所述QoS要求集合與UDDI中所存儲的 QoS狀態(tài)信息進行比較并且選擇一個Web服務以使得如與所述一個 Web服務相關聯(lián)的QoS狀態(tài)信息所指示的、所述一個Web服務所能 夠提供的當前QoS滿足與服務請求相關聯(lián)的QoS要求集合，在響應消息中向從其接收到服務請求的服務請求者發(fā)送(509 ) 關于所選擇的一個Web服務的信息。
22. 如權利要求21所述的方法，其中所述選擇步驟進一步包括 搜索(502 )在UDDI中注冊的所述至少一個Web服務以尋找與服務請求中所請求的Web服務的類型相對應的第一 Web服務集合， 以及使用偏好信息對所述第一 Web服務集合進行過濾(503 ),以便 得到遵照所述偏好信息的第二 Web服務集合，所述偏好信息是已經(jīng)在 UDDI服務器中預存儲的與從其接收到服務請求的服務請求者的偏好 相關的信息，其中從所述第二 Web服務集合中選擇一個Web服務。
23. 如權利要求22所述的方法，其中所述選擇步驟進一步包括 通過將所述QoS要求集合與UDDI中所存儲的QoS狀態(tài)信息進行比 較來過濾(505 )所述第二 Web服務集合以得到第三Web服務集合， 其均與指示每個web服務將分別滿足所述QoS要求集合的QoS狀態(tài) 信息相關聯(lián)，其中從所述第三Web服務集合中選擇一個Web服務。
24. 如權利要求21-23中任一項所述的方法，其中如果沒有在 所述選擇步驟中找到適合的Web服務，則將服務請求存儲(506b)在 請求隊列中。
全文摘要
本發(fā)明涉及用于對由多個服務提供者(24)向多個服務請求者(40)提供的Web服務(23)進行調(diào)解的UDDI服務器(50)以及UDDI服務器(50)中的方法。根據(jù)本發(fā)明的UDDI服務器適于提供對于在Web服務調(diào)解中考慮動態(tài)服務質(zhì)量的支持。UDDI服務器包括Web服務寄存器(22)，其包括用于存儲QoS狀態(tài)信息的數(shù)據(jù)集合(27)。QoS狀態(tài)信息是關于相關聯(lián)的Web服務能夠向服務請求者提供的當前QoS的信息。根據(jù)從服務提供者接收的動態(tài)服務狀態(tài)信息，對存儲在數(shù)據(jù)集合(27)中的QoS狀態(tài)信息進行周期性地更新。UDDI服務器可選地包括決策制定功能(51)，其用于選擇滿足服務請求者的QoS要求集合的Web服務。
文檔編號H04L29/08GK101637006SQ200780052164
公開日2010年1月27日 申請日期2007年3月14日 優(yōu)先權日2007年3月14日
發(fā)明者威 黃 申請人:艾利森電話股份有限公司