專利名稱：端到端Web服務(wù)質(zhì)量監(jiān)測系統(tǒng)及方法
技術(shù)領(lǐng)域：
本發(fā)明屬于Web服務(wù)組合領(lǐng)域，特別涉及一種端到端Web服務(wù)質(zhì)量監(jiān)測系統(tǒng)及方法。
背景技術(shù)：
以Web服務(wù)為代表的軟件服務(wù)技術(shù)正在快速發(fā)展，它所具備的松散耦合以及平臺 無關(guān)的優(yōu)良特性非常適合于hternet環(huán)境下異構(gòu)應(yīng)用之間的互操作和集成。隨著功能相 同或相似的Web服務(wù)(以下簡稱服務(wù))日益增多，用戶在使用Web服務(wù)或者創(chuàng)建組合服務(wù)時 通常有多個候選Web服務(wù)可供選擇。在滿足用戶功能需求的基礎(chǔ)上，Web服務(wù)質(zhì)量(Quality of Web Services, QoffS)成為評價候選Web服務(wù)的標準，也成為牽動Web服務(wù)發(fā)展的重要 因素。服務(wù)提供者所提供的是具有一定質(zhì)量保障的服務(wù)，服務(wù)使用者所請求的是具有一定 質(zhì)量約束的服務(wù)。服務(wù)監(jiān)測是指對服務(wù)質(zhì)量的監(jiān)視和測量。服務(wù)質(zhì)量監(jiān)視是指由特定監(jiān)視實體對服 務(wù)質(zhì)量進行周期性的測量；服務(wù)質(zhì)量測量是指對QoWS模型所定義的屬性值的獲取。服務(wù)監(jiān) 測建立在特定QoWS模型基礎(chǔ)上，不同的QoWS模型往往需要不同的服務(wù)監(jiān)測方法。對Web服務(wù)質(zhì)量進行建?？梢詮姆?wù)提供者的視角和服務(wù)使用者的視角進行。 QoffS屬性主要包括可用性、可訪問性、可靠性、規(guī)范性、安全性、響應(yīng)時間、吞吐率、延遲、價 格、網(wǎng)絡(luò)帶寬和信譽度等?？蓪oWS屬性分成兩類一類是與Web服務(wù)所處的服務(wù)環(huán)境無 關(guān)，而與Web服務(wù)自身的實現(xiàn)相關(guān)的內(nèi)部屬性，另一類則是與Web服務(wù)所處的服務(wù)環(huán)境存在 聯(lián)系的外部屬性。也可從另一個角度將QoWS屬性分成三類不經(jīng)常發(fā)生變化的靜態(tài)指標 (如Web服務(wù)的規(guī)范性和安全性)、隨著特定環(huán)境的變化而變化的動態(tài)指標(如服務(wù)可用 性、網(wǎng)絡(luò)可用性和執(zhí)行時間)、根據(jù)統(tǒng)計數(shù)據(jù)計算得到的統(tǒng)計指標(如服務(wù)可靠性，網(wǎng)絡(luò)可 靠性，執(zhí)行可靠性和信譽度)。盡管以上QoWS模型的提出能夠在某種程度上支持服務(wù)監(jiān)測 與服務(wù)評價，然而，現(xiàn)有QoWS模型是單維度的，即沒有貫穿在面向服務(wù)體系結(jié)構(gòu)的整個流 程(服務(wù)發(fā)布、服務(wù)發(fā)現(xiàn)、服務(wù)選取、服務(wù)執(zhí)行)中，無法代表客觀的、綜合的服務(wù)質(zhì)量。例 如，以服務(wù)的響應(yīng)時間為例，該QoWS屬性應(yīng)具有不同維度交付響應(yīng)時間、傳輸響應(yīng)時間、 感知響應(yīng)時間、約定響應(yīng)時間、(指定時間段的)平均響應(yīng)時間和用戶所期望的響應(yīng)時間。傳統(tǒng)面向服務(wù)體系結(jié)構(gòu)不支持服務(wù)度量和服務(wù)監(jiān)視。當前典型的服務(wù)度量技術(shù) 有對底層網(wǎng)絡(luò)數(shù)據(jù)包進行度量、基于代理、對SOAP引擎庫進行修改以及應(yīng)用響應(yīng)度量等 方法。當前典型的服務(wù)監(jiān)視方法包括1)擴展UDDI增加了一種新的數(shù)據(jù)結(jié)構(gòu)，用于描述 Web服務(wù)的QoWS屬性，還定義了一種QoWS證明者角色，用于對服務(wù)提供者所宣稱的服務(wù)質(zhì) 量進行驗證；2)傳統(tǒng)SOA結(jié)構(gòu)中增加了一個面向服務(wù)中間件(SOM)，所有Web服務(wù)提供者內(nèi) 部增加一個QoWS收集器，定時向SOM提供實時的Web服務(wù)QoWS量化值；幻通過中間件平 臺來對Web服務(wù)的服務(wù)質(zhì)量進行監(jiān)控，它向服務(wù)用戶提供用戶端代理，由代理來截獲傳輸 的SOAP消息，從而收集與服務(wù)質(zhì)量有關(guān)的數(shù)據(jù)；4)在SOA模型外引入了可信任的第三QoWS認證中心，負責對QoWS量化，并根據(jù)用戶反饋來評估Web服務(wù)。現(xiàn)有服務(wù)監(jiān)測方法要么只 度量和監(jiān)視服務(wù)端的交付質(zhì)量，要么只度量和監(jiān)視用戶端的感知質(zhì)量，無法客觀的、真實的 反應(yīng)服務(wù)質(zhì)量。由于網(wǎng)絡(luò)性能、端系統(tǒng)性能等外部環(huán)境的影響，Web服務(wù)在服務(wù)提供者端的表現(xiàn)和 服務(wù)使用者所感知到的結(jié)果不盡相同。監(jiān)測Web服務(wù)在服務(wù)提供者端所表現(xiàn)的質(zhì)量能夠 反映服務(wù)實際交付的質(zhì)量，但不能反映使用者實際感知到的質(zhì)量；同樣，監(jiān)測服務(wù)在使用者 端所表現(xiàn)的質(zhì)量能夠反映客戶實際感知到的質(zhì)量，但無法客觀反映服務(wù)提供者所交付的質(zhì) 量。然而現(xiàn)有Web服務(wù)質(zhì)量監(jiān)測系統(tǒng)要么以服務(wù)提供者的交付質(zhì)量作為監(jiān)測標準，要么以 服務(wù)使用者的感知質(zhì)量作為監(jiān)測標準，缺乏真實的、客觀的、綜合的監(jiān)測機制。

發(fā)明內(nèi)容
針對以有技術(shù)的不足，本發(fā)明提出一種端到端Web服務(wù)質(zhì)量監(jiān)測系統(tǒng)及方法，以 實現(xiàn)從服務(wù)提供者和服務(wù)使用者兩端監(jiān)測服務(wù)會話的質(zhì)量信息。本發(fā)明所需服務(wù)器兩臺，其硬件環(huán)境為Intel Pentium M processor 735 (1. 7GHz,400MHz FSB,2MB L2 cache)，1.2GB DDR2 (support dual-channel)RAM, Cent0S5操作系統(tǒng)。通過中國網(wǎng)通ADSL (帶寬2Mbps)或IOOMbps局域網(wǎng)接入hternet。本發(fā)明所提出的六維QoWS模型，其QoWS屬性具有多維性、服務(wù)等級協(xié)議相關(guān)性和 可度量性。多維性是指同一 QoWS屬性具有不同維度的涵義，以滿足服務(wù)質(zhì)量在不同生命周 期階段中所具有的不同含義和需求。服務(wù)等級協(xié)議相關(guān)性是指QoWS屬性包含服務(wù)提供者 在服務(wù)等級協(xié)議中所發(fā)布或服務(wù)雙方所約定的質(zhì)量屬性，以此衡量服務(wù)質(zhì)量的一致性(即 用戶對服務(wù)的滿意程度)?？啥攘啃允侵窺oWS屬性能夠由第三方實體進行客觀的、定量的 度量。在服務(wù)計算環(huán)境中，根據(jù)服務(wù)質(zhì)量在不同階段所具有的不同的含義和表現(xiàn)，將服務(wù)質(zhì) 量劃分為六個維度1.期望質(zhì)量(EQoWQ 是指服務(wù)使用者在服務(wù)選取時所提出的服務(wù)質(zhì)量約束。實 際上，用戶提出的服務(wù)質(zhì)量約束應(yīng)該在某個服務(wù)質(zhì)量模型的規(guī)范下，否則將是盲目的，無法 保證選取的有效性；2.約定質(zhì)量(AQoWQ 是指服務(wù)提供者和服務(wù)使用者在服務(wù)執(zhí)行前對服務(wù)質(zhì)量所 作的約定。服務(wù)提供者按照約定質(zhì)量交付服務(wù)；3.交付質(zhì)量(DQoWQ 是指服務(wù)提供者實際交付的服務(wù)的質(zhì)量。它描述的是服務(wù) 在提供者端所表現(xiàn)出來的質(zhì)量，通過監(jiān)測得到；4.感知質(zhì)量(PQoWS)是指服務(wù)使用者實際感知到的服務(wù)的質(zhì)量。它描述的是服 務(wù)在使用者端所表現(xiàn)出來的質(zhì)量，通過監(jiān)測得到；5.傳輸質(zhì)量(TQoWQ 是指傳輸服務(wù)請求和響應(yīng)消息的網(wǎng)絡(luò)的質(zhì)量，通過監(jiān)測得 到；6.統(tǒng)計質(zhì)量(SQoWS)是指利用統(tǒng)計分析得到的服務(wù)長期性的、平均的性能表現(xiàn)。QoffS監(jiān)測包括三個方面的內(nèi)容服務(wù)會話信息的獲取、服務(wù)會話信息的傳輸以及 QoWS指標的計算。本發(fā)明采用應(yīng)用程序接口鉤子(API Hook)技術(shù)實現(xiàn)服務(wù)會話信息的獲 取，API Hook是操作系統(tǒng)為了能夠靈活方便地添加新功能而提供的擴展機制，通過該技術(shù) 可以對SOAP消息進行攔截和分析，以提取出服務(wù)會話的基本信息。本發(fā)明采用簡單網(wǎng)絡(luò)管理協(xié)議(Simple Network Management Protocol, SNMP)實現(xiàn)服務(wù)會話信息的傳輸，由SNMP 管理者(即服務(wù)監(jiān)測者)從SNMP代理(即服務(wù)提供者和服務(wù)使用者)周期性地讀取服務(wù) 會話信息。對于QoWS指標的計算部分，本發(fā)明的設(shè)計基本覆蓋了當前典型QoWS指標的需 要，即原始的服務(wù)會話信息基本滿足當前典型QoWS指標的計算需要，但QoWS指標的計算不 作為本發(fā)明的內(nèi)容。如

圖1所示，端到端QoWS監(jiān)測模型包括三個實體服務(wù)提供者、服務(wù)使用者和服務(wù) 監(jiān)測者，該模型依賴如下假設(shè)l.QoWS監(jiān)測以約定質(zhì)量為依據(jù)，監(jiān)測服務(wù)質(zhì)量是否達到約定標準以及達到的程度。2.三個實體存在于同一個SNMP管理域中，即它們共同支持同一管理標準，同時服 務(wù)提供者和服務(wù)使用者均向服務(wù)監(jiān)測者開放SNMP管理接口。約定質(zhì)量是由服務(wù)等級協(xié)議(Service Level Agreement, SLA)定義和說明的。服 務(wù)提供者按照服務(wù)等級為服務(wù)使用者提供相應(yīng)服務(wù)及質(zhì)量。服務(wù)等級可以由服務(wù)使用者指 定，也可以由服務(wù)提供者根據(jù)服務(wù)使用者的屬性進行配置。將服務(wù)會話信息歸并到SNMP管理信息庫的iso. org. dod. internet, mgmt. mib-2 結(jié)點下，采用RFCl 155標準將其轉(zhuǎn)化為管理對象。管理對象涵蓋了服務(wù)會話的基本信息，以 供計算QoWS指標的需要，其結(jié)構(gòu)分別如圖2和圖3所示。服務(wù)端管理對象(SQoWS_Group)有兩個表服務(wù)表ServTable和會話表 kssionTable。ServTable將服務(wù)提供者所提供的所有服務(wù)形成一張表，描述它們的基本信 息，其變量說明如下· servNum 服務(wù)提供者所提供的服務(wù)的數(shù)量?！?servEntry 某個服務(wù)的信息條目?！?servlndex 表索引或服務(wù)編號，標識表中的每一條記錄?！?servURL 服務(wù) URL。· capacity 服務(wù)容量，是指該服務(wù)能同時處理請求的最大用戶數(shù)?！?operationSet 服務(wù)提供的所有的操作的集合。包括操作名operation和有效 時間validTime。validTime用來為操作的響應(yīng)時間設(shè)定一個閾值，如某操作在其有效時間 內(nèi)沒有執(zhí)行完畢，則視該操作為失效，其相應(yīng)的服務(wù)會話狀態(tài)為failure。kssionTable描述了服務(wù)提供者所經(jīng)歷的和正在經(jīng)歷的全部服務(wù)會話的信息。其 變量表示如下· sessionNum 全部服務(wù)會話的數(shù)量。· sessionEntry 某個服務(wù)會話的信息條目?！?sessionlndex 服務(wù)會話索引，標識表中的每一條記錄?！?sessionID 會話ID，唯一標識一個服務(wù)會話?！?servURL 服務(wù) URL。· clientAddr 客戶端地址?！?status 月艮務(wù)會話的狀態(tài)。包括 active、delivered、failure 禾口 collected 四 個狀態(tài)。active是指服務(wù)端正在處理來自客戶端的請求，delivered是指服務(wù)操作在有效 時間內(nèi)已交付，failure是指服務(wù)操作在有效時間內(nèi)沒有交付，collected是指服務(wù)監(jiān)測者已收集該會話的信息。· operation 服務(wù)所調(diào)用的操作。· deliveredParameters 交付質(zhì)量參數(shù)。包括接收請求的時刻t (sr)和發(fā)出響 應(yīng)的時刻t (sc)?？蛻舳斯芾韺ο?CQoWS_Group)描述了客戶端的會話表kssionTable，其變量說 明如下· sessionNum 服務(wù)會話的數(shù)量，包括已經(jīng)歷的和正在經(jīng)歷的服務(wù)會話?！?sessionlndex 表索弓|?！?sessionID 會話 ID?！?servURL 服務(wù) URL?！?validTime 會話有效時間，用來為服務(wù)的響應(yīng)時間設(shè)定一個閾值，如某服務(wù)請 求在其有效時間內(nèi)沒有收到響應(yīng)，則視該會話為失效，其相應(yīng)的服務(wù)會話狀態(tài)為failure?！?status 月艮務(wù)會話的狀態(tài)。包括 active、perceived、failure 禾口 collected 四個 狀態(tài)。active是指客戶端正在等待來自服務(wù)端的響應(yīng)，perceived是指服務(wù)請求在會話有 效時間內(nèi)已收到響應(yīng)，failure是指服務(wù)請求在會話有效時間內(nèi)沒有收到響應(yīng)，collected 是指服務(wù)監(jiān)測者已收集該會話的信息?！?operation 所調(diào)用的服務(wù)操作?！?perceivedParameters 感知質(zhì)量參數(shù)。包括發(fā)出請求的時刻t (cs)和接收響 應(yīng)的時刻t(cr)。如圖1所示，該監(jiān)測系統(tǒng)包括以下四個模塊注冊模塊、SNMP代理模塊、監(jiān)測模塊 和評價模塊。注冊模塊用于實現(xiàn)SLA的注冊及約定質(zhì)量的生成；SNMP代理模塊用于服務(wù)會 話信息的獲取和SNMP協(xié)議實現(xiàn)；監(jiān)測模塊作為SNMP管理者與SNMP代理一同實現(xiàn)服務(wù)會話 信息的傳輸；評價模塊用于對約定質(zhì)量達到的程度進行綜合的、長期的評估；所述的注冊模塊實現(xiàn)以下功能(1)服務(wù)提供者把與服務(wù)使用者協(xié)商后的服務(wù)等級協(xié)議向服務(wù)監(jiān)測者進行注冊；(2)注冊模塊將服務(wù)等級協(xié)議中的相關(guān)信息進行提取，生成約定質(zhì)量的各個參數(shù) 及參數(shù)值；(3)注冊模塊將約定質(zhì)量參數(shù)發(fā)送給監(jiān)測模塊，作為所要監(jiān)測的QoWS指標；所述的SNMP代理模塊實現(xiàn)以下功能SNMP代理模塊分別在服務(wù)提供者端和服務(wù)使用者端采用API Hook應(yīng)用程序接口 鉤子技術(shù)獲取服務(wù)會話信息，并采用UCD-SNMP引擎實現(xiàn)SNMP功能；所述的監(jiān)測模塊實現(xiàn)以下功能(1)監(jiān)測模塊作為SNMP管理者周期性的向管理域中的服務(wù)提供者進行輪詢，獲 取服務(wù)會話的管理信息，并且根據(jù)該信息中的線索對相應(yīng)服務(wù)使用者端的管理信息進行讀 ?。?2)監(jiān)測模塊分別對服務(wù)提供者端和服務(wù)使用者端的會話信息進行處理，得到與 約定質(zhì)量參數(shù)所對應(yīng)的交付質(zhì)量參數(shù)值及感知質(zhì)量參數(shù)值；(3)監(jiān)測模塊將交付質(zhì)量參數(shù)值、感知質(zhì)量參數(shù)值和傳輸質(zhì)量參數(shù)值發(fā)送給評價 模塊；
所述的評價模塊實現(xiàn)以下功能評價模塊對該服務(wù)的質(zhì)量信息進行評估和統(tǒng)計。一種端到端Web服務(wù)質(zhì)量監(jiān)測方法，按如下步驟進行步驟A 服務(wù)提供者把其與服務(wù)使用者協(xié)商后的服務(wù)等級協(xié)議向服務(wù)監(jiān)測者進行
注冊；步驟B 服務(wù)監(jiān)測者提取服務(wù)等級協(xié)議中的相關(guān)信息，生成約定質(zhì)量的各個參數(shù) 及參數(shù)值；步驟C 將約定質(zhì)量參數(shù)作為所要監(jiān)測的QoWS指標，分別在服務(wù)提供者端和服務(wù) 使用者端采用API Hook應(yīng)用程序接口鉤子技術(shù)獲取服務(wù)會話信息；步驟D 周期性的向管理域中的服務(wù)提供者(即SNMP代理)進行輪詢，獲取服務(wù) 會話的管理信息，并且根據(jù)該信息中的線索對相應(yīng)服務(wù)使用者端的管理信息進行讀取；步驟E 分別對服務(wù)提供者端和服務(wù)使用者端的會話信息進行處理，得到與約定 質(zhì)量參數(shù)所對應(yīng)的交付質(zhì)量參數(shù)值及感知質(zhì)量參數(shù)值。其生成過程與具體的QoWS指標實 例相關(guān)，由SNMP代理所獲取的原始服務(wù)會話信息計算而成(對于QoWS指標的計算部分，本 發(fā)明的設(shè)計基本覆蓋了當前典型QoWS指標的需要，即原始的服務(wù)會話信息基本滿足當前 典型QoWS指標的計算需要，但QoWS指標的計算為本領(lǐng)域技術(shù)人員公知的常規(guī)技術(shù)，不做說 明)。值得注意的是，有些QoWS參數(shù)在約定質(zhì)量中指定的是交付質(zhì)量，有些則指定的是感知 質(zhì)量，將計算出與之相對應(yīng)的參數(shù)值。同時，還能夠計算該服務(wù)會話所依賴的網(wǎng)絡(luò)的傳輸質(zhì) 量，作為客觀評估約定質(zhì)量達到程度的重要因素。步驟F 根據(jù)交付質(zhì)量參數(shù)值、感知質(zhì)量參數(shù)值和傳輸質(zhì)量參數(shù)值對服務(wù)會話的 質(zhì)量及服務(wù)質(zhì)量進行評估和統(tǒng)計。由此完成了服務(wù)監(jiān)測的整個過程，即以服務(wù)等級協(xié)議的注冊為始，以服務(wù)評價為 終。服務(wù)的統(tǒng)計質(zhì)量可作為服務(wù)選取的標準，與服務(wù)使用者所指定的期望質(zhì)量進行匹配以 選取出最符合用戶需求的服務(wù)。步驟C的分解步驟Cl 分別在服務(wù)提供者端和服務(wù)使用者端攔截HTTP數(shù)據(jù)包；步驟C2 對HTTP數(shù)據(jù)包進行過濾和分析；步驟C3 采用UCD-SNMP引擎將對應(yīng)的服務(wù)端管理信息對象與客戶端管理信息對 象進行賦值。步驟Cl的分解步驟Cl 1 通過重載庫函數(shù)send ()、recv ()來截獲數(shù)據(jù)包；步驟C12 記錄下所截獲的HTTP消息的時間戳，包括HTTP請求報文的發(fā)送時刻 t (cs)、HTTP請求報文的接收時刻t (sr)、HTTP響應(yīng)報文的發(fā)送時刻t (ss)及HTTP響應(yīng)報 文的接收時刻t(cr)；步驟C13 為了獲取服務(wù)會話的端到端信息，服務(wù)端管理對象結(jié)構(gòu)和客戶端管理 對象結(jié)構(gòu)中均設(shè)計了一個服務(wù)會話標識sessionID，用來標識一個端到端服務(wù)會話。由于服 務(wù)會話是從服務(wù)使用者發(fā)起的，所以服務(wù)會話標識是由服務(wù)使用者端的SNMP代理所創(chuàng)建， 在HTTP請求報文的請求行后插上一個首部行，字段名為kssionID，其值為當前時間戳；步驟C14 將服務(wù)會話標識、時間戳及數(shù)據(jù)包大小發(fā)送到管道中。
步驟C2的分解步驟C21 從管道里讀取數(shù)據(jù)；步驟C22 通過對HTTP消息的類型Content-Type和客戶能夠接收的消息類型 Acc印t首部行進行判斷，從而過濾非SOAP (Simple Object Access Protocol，簡單對象訪 問協(xié)議)消息。判斷消息類型Content-type首部行的值是否含有SOAP信息(application/ soap+xml)，如果有則該數(shù)據(jù)包是SOAP數(shù)據(jù)包，否則便認為該數(shù)據(jù)包不是SOAP數(shù)據(jù)包。如 果不存在消息類型Content-Type首部行，則判斷客戶所能接收的消息類型Ac^pt首部行 的值是否含有SOAP信息(application/soap+xml)，如果含有則認為該數(shù)據(jù)包是SOAP數(shù)據(jù) 包；否則便認為該數(shù)據(jù)包不是SOAP數(shù)據(jù)包；步驟C23 通過處理HTTP GET請求和HTTP POST請求來獲取服務(wù)操作operation 參數(shù)值；步驟C3的分解步驟C31 服務(wù)使用者端SNMP代理在分析完所發(fā)送的服務(wù)請求消息后，在客戶端 管理對象組CQoWS_Group中創(chuàng)建一個服務(wù)會話項sessionEntry及相應(yīng)的服務(wù)會話索引 sessionlndex,并將服務(wù)會話標識sessionID、服務(wù)地址servURL、服務(wù)操作operation和服 務(wù)請求消息的發(fā)送時刻t (cs)參數(shù)進行賦值，同時將服務(wù)會話狀態(tài)status賦值為active ；步驟C32 為客戶端管理對象組中的服務(wù)會話有效時間validTime賦值，該有效時 間用來為服務(wù)操作的響應(yīng)時間設(shè)定一個閾值(最大值)，如果服務(wù)使用者在有效時間內(nèi)沒 有接收到服務(wù)響應(yīng)，則視該服務(wù)會話為無效；步驟C33 服務(wù)提供者端SNMP代理在分析完所接收的服務(wù)請求消息后，在服 務(wù)端管理對象組的服務(wù)會話表SQoWS_Group. sessionTable中創(chuàng)建一個服務(wù)會話項 sessionEntry及相應(yīng)的服務(wù)會話索引sessior^ndex，并將服務(wù)會話標識sessionID、客 戶地址clientAddr、服務(wù)地址servURL、服務(wù)操作operation和服務(wù)請求消息的接收時刻 t(sr)參數(shù)進行賦值，同時將服務(wù)會話狀態(tài)status賦值為active ；步驟C34 為服務(wù)端管理對象組中的服務(wù)操作有效時間validTime賦值，該有效時 間用來為服務(wù)的執(zhí)行時間設(shè)定一個閾值(最大值)，如果服務(wù)在有效時間內(nèi)沒有執(zhí)行完畢， 則視該服務(wù)會話為失效；步驟C35 服務(wù)提供者端SNMP代理如果在有效時間validTime內(nèi)攔截到所發(fā)出的 服務(wù)響應(yīng)消息，則status更新為delivered，否則更新為failure ；步驟C36 服務(wù)使用者端SNMP代理如果在有效時間validTime內(nèi)攔截到所接收的 服務(wù)響應(yīng)消息，則status更新為perceived，否則更新為failure。步驟C32的分解步驟C321 服務(wù)使用者端SNMP代理向服務(wù)監(jiān)測者端SNMP管理者發(fā)送一個事件通 知(擴展的陷入消息)；步驟C322 監(jiān)測者端SNMP管理者接收到事件通知后，根據(jù)約定質(zhì)量中所指定的服 務(wù)響應(yīng)時間對validTime參數(shù)進行處理。需要注意的是，約定質(zhì)量中所指定的服務(wù)響應(yīng)時 間是指服務(wù)在提供者端的執(zhí)行時間，而validTime是指從發(fā)出請求到接收響應(yīng)的時間的最 大值。為了簡單化，validTime參數(shù)賦值為服務(wù)響應(yīng)時間的2倍，即validTime = 2X約定 響應(yīng)時間；
步驟C323:而后發(fā)送一條SNMP set指令，將處理后的值賦值給有效時間 validTime。步驟C34的分解步驟C341 服務(wù)提供者端SNMP代理向服務(wù)監(jiān)測者端SNMP管理者發(fā)送一個事件通 知(擴展的陷入消息)；步驟C342 監(jiān)測者端SNMP管理者接收到事件通知后，根據(jù)約定質(zhì)量中所指定的服 務(wù)響應(yīng)時間對validTime參數(shù)進行處理。需要注意的是，約定質(zhì)量中所指定的服務(wù)響應(yīng)時 間是指服務(wù)在提供者端的執(zhí)行時間，而validTime是指服務(wù)執(zhí)行時間的最大值。為了簡單 化，validTime參數(shù)賦值為增加30%的服務(wù)響應(yīng)時間，即validTime = (1+30% ) X約定響 應(yīng)時間；步驟C343:而后發(fā)送一條SNMP set指令，將處理后的值賦值給有效時間 validTime。步驟D的分解步驟Dl 周期性的輪詢服務(wù)端會話表SQoWS_Group. sessionTable,如果發(fā)現(xiàn)了新 交付的服務(wù)會話(服務(wù)會話狀態(tài)status = delivered or failure)，則取出該會話所對應(yīng) 的客戶地址clientAddr和服務(wù)會話標識sessionID，同時將服務(wù)會話狀態(tài)status更新為 collected ；步驟D2 按照客戶地址讀取該客戶的會話表CQ0WS_Gr0Up，按照服務(wù)會話標識 sessionID提取該服務(wù)會話在客戶端的管理信息，并將其服務(wù)會話狀態(tài)status更新為 collected。步驟F的分解步驟Fl 對單次服務(wù)會話的質(zhì)量進行評估；步驟F2 對各個QoWS指標進行長期評估；步驟F3 對服務(wù)質(zhì)量進行長期評估，即對服務(wù)達到約定質(zhì)量的程度進行統(tǒng)計，其 計算方法為
權(quán)利要求
1.一種端到端Web服務(wù)質(zhì)量監(jiān)測系統(tǒng)，其特征在于該監(jiān)測系統(tǒng)包括以下四個模塊注 冊模塊、SNMP代理模塊、監(jiān)測模塊和評價模塊；注冊模塊用于實現(xiàn)SLA的注冊及約定質(zhì)量的 生成；SNMP代理模塊用于服務(wù)會話信息的獲取和SNMP協(xié)議實現(xiàn)；監(jiān)測模塊作為SNMP管理 者與SNMP代理一同實現(xiàn)服務(wù)會話信息的傳輸；評價模塊用于對約定質(zhì)量達到的程度進行 綜合的、長期的評估；所述的注冊模塊實現(xiàn)以下功能(1)服務(wù)提供者把與服務(wù)使用者協(xié)商后的服務(wù)等級協(xié)議向服務(wù)監(jiān)測者進行注冊；(2)注冊模塊將服務(wù)等級協(xié)議中的相關(guān)信息進行提取，生成約定質(zhì)量的各個參數(shù)及參 數(shù)值；(3)注冊模塊將約定質(zhì)量參數(shù)發(fā)送給監(jiān)測模塊，作為所要監(jiān)測的QoWS指標； 所述的SNMP代理模塊實現(xiàn)以下功能SNMP代理模塊分別在服務(wù)提供者端和服務(wù)使用者端采用API Hook應(yīng)用程序接口鉤子 技術(shù)獲取服務(wù)會話信息，并采用UCD-SNMP引擎實現(xiàn)SNMP功能； 所述的監(jiān)測模塊實現(xiàn)以下功能(1)監(jiān)測模塊作為SNMP管理者周期性的向管理域中的服務(wù)提供者進行輪詢，獲取服務(wù) 會話的管理信息，并且根據(jù)該信息中的線索對相應(yīng)服務(wù)使用者端的管理信息進行讀?。?2)監(jiān)測模塊分別對服務(wù)提供者端和服務(wù)使用者端的會話信息進行處理，得到與約定 質(zhì)量參數(shù)所對應(yīng)的交付質(zhì)量參數(shù)值及感知質(zhì)量參數(shù)值；(3)監(jiān)測模塊將交付質(zhì)量參數(shù)值、感知質(zhì)量參數(shù)值和傳輸質(zhì)量參數(shù)值發(fā)送給評價模塊；所述的評價模塊實現(xiàn)以下功能評價模塊對該服務(wù)的質(zhì)量信息進行評估和統(tǒng)計。
2.采用權(quán)利要求1所述的端到端Web服務(wù)質(zhì)量監(jiān)測系統(tǒng)的監(jiān)測方法，其特征在于 按如下步驟進行步驟A 服務(wù)提供者把其與服務(wù)使用者協(xié)商后的服務(wù)等級協(xié)議向服務(wù)監(jiān)測者進行注ππ冊；步驟B 服務(wù)監(jiān)測者提取服務(wù)等級協(xié)議中的相關(guān)信息，生成約定質(zhì)量的各個參數(shù)及參 數(shù)值；步驟C 將約定質(zhì)量參數(shù)作為所要監(jiān)測的QoWS指標，分別在服務(wù)提供者端和服務(wù)使用 者端采用API Hook應(yīng)用程序接口鉤子技術(shù)獲取服務(wù)會話信息；步驟D 周期性的向管理域中的服務(wù)提供者進行輪詢，獲取服務(wù)會話的管理信息，并且 根據(jù)該信息中的線索對相應(yīng)服務(wù)使用者端的管理信息進行讀?。徊襟EE 分別對服務(wù)提供者端和服務(wù)使用者端的會話信息進行處理，得到與約定質(zhì)量 參數(shù)所對應(yīng)的交付質(zhì)量參數(shù)值及感知質(zhì)量參數(shù)值；步驟F 根據(jù)交付質(zhì)量參數(shù)值、感知質(zhì)量參數(shù)值和傳輸質(zhì)量參數(shù)值對服務(wù)會話的質(zhì)量 及服務(wù)質(zhì)量進行評估和統(tǒng)計。
3.按權(quán)利要求2所述的端到端Web服務(wù)質(zhì)量監(jiān)測方法，其特征在于所述的步驟C，按 如下步驟進行步驟Cl 分別在服務(wù)提供者端和服務(wù)使用者端攔截HTTP數(shù)據(jù)包；步驟C2 對HTTP數(shù)據(jù)包進行過濾和分析；步驟C3 采用UCD-SNMP引擎將對應(yīng)的服務(wù)端管理信息對象與客戶端管理信息對象進 行賦值。
4.按權(quán)利要求3所述的端到端Web服務(wù)質(zhì)量監(jiān)測方法，其特征在于所述的步驟Cl，按 如下步驟進行步驟Cii 通過重載庫函數(shù)send()、recv()來截獲數(shù)據(jù)包；步驟C12 記錄下所截獲的HTTP消息的時間戳，包括HTTP請求報文的發(fā)送時刻t (cs)、 HTTP請求報文的接收時刻t (sr)、HTTP響應(yīng)報文的發(fā)送時刻t (ss)及HTTP響應(yīng)報文的接 收時亥Ij t (cr)；步驟C13:在服務(wù)端管理對象結(jié)構(gòu)和客戶端管理對象結(jié)構(gòu)中均設(shè)置服務(wù)會話標識 sessionID ；在HTTP請求報文的請求行后插上一個首部行，字段名為kssionID，其值為當 前時間戳；步驟C14 將服務(wù)會話標識、時間戳及數(shù)據(jù)包大小發(fā)送到管道中；所述的步驟C2，按如下步驟進行步驟C21 從管道里讀取數(shù)據(jù)；步驟C22 通過對HTTP消息的類型Content-Type和客戶能夠接收的消息類型Acapt 首部行進行判斷，過濾非SOAP消息；判斷消息類型Content-type首部行的值是否含有 SOAP信息，如果有則該數(shù)據(jù)包是SOAP數(shù)據(jù)包，否則便認為該數(shù)據(jù)包不是SOAP數(shù)據(jù)包；如果 不存在消息類型Content-Type首部行，則判斷客戶所能接收的消息類型Ac^pt首部行的 值是否含有SOAP信息，如果含有則認為該數(shù)據(jù)包是SOAP數(shù)據(jù)包；否則便認為該數(shù)據(jù)包不是 SOAP數(shù)據(jù)包；步驟C23 通過處理HTTP GET請求和HTTP POST請求來獲取服務(wù)操作operation參數(shù)值；所述的步驟C3，按如下步驟進行步驟C31 服務(wù)使用者端SNMP代理在分析完所發(fā)送的服務(wù)請求消息后，在客戶端管 理對象組CQoWS_Group中創(chuàng)建一個服務(wù)會話項sessionEntry及相應(yīng)的服務(wù)會話索引 sessionlndex,并將服務(wù)會話標識sessionID、服務(wù)地址servURL、服務(wù)操作operation和服 務(wù)請求消息的發(fā)送時刻t (cs)參數(shù)進行賦值，同時將服務(wù)會話狀態(tài)status賦值為active ；步驟C32 為客戶端管理對象組中的服務(wù)會話有效時間validTime賦值，該有效時間用 來為服務(wù)操作的響應(yīng)時間設(shè)定一個閾值即最大值，如果服務(wù)使用者在有效時間內(nèi)沒有接收 到服務(wù)響應(yīng)，則視該服務(wù)會話為無效；步驟C33 服務(wù)提供者端SNMP代理在分析完所接受的服務(wù)請求消息后，在服務(wù)端管理 對象組的服務(wù)會話表SQoWS_Group. sessionTable中創(chuàng)建一個服務(wù)會話項sessionEntry及 相應(yīng)的服務(wù)會話索引sessionhdex，并將服務(wù)會話標識sessionID、客戶地址clientAddr、 服務(wù)地址servURL、服務(wù)操作operation和服務(wù)請求消息的接收時刻t (sr)參數(shù)進行賦值， 同時將服務(wù)會話狀態(tài)status賦值為active ；步驟C34 為服務(wù)端管理對象組中的服務(wù)操作有效時間validTime賦值，該有效時間用 來為服務(wù)的執(zhí)行時間設(shè)定一個閾值即最大值，如果服務(wù)在有效時間內(nèi)沒有執(zhí)行完畢，則視 該服務(wù)會話為失效；步驟C35 服務(wù)提供者端SNMP代理如果在有效時間validTime內(nèi)攔截到所發(fā)出的服務(wù) 響應(yīng)消息，則status更新為delivered，否則更新為failure ；步驟C36 服務(wù)使用者端SNMP代理如果在有效時間validTime內(nèi)攔截到所接收的服務(wù) 響應(yīng)消息，則status更新為perceived，否則更新為failure。
5.按權(quán)利要求4所述的端到端Web服務(wù)質(zhì)量監(jiān)測方法，其特征在于所述的步驟C32， 按如下步驟進行步驟C321 服務(wù)使用者端SNMP代理向服務(wù)監(jiān)測者端SNMP管理者發(fā)送一個事件通知即 擴展的陷入消息；步驟C322 監(jiān)測者端SNMP管理者接收到事件通知后，根據(jù)約定質(zhì)量中所指定的服 務(wù)響應(yīng)時間對validTime參數(shù)進行處理；validTime參數(shù)賦值為服務(wù)響應(yīng)時間的2倍，即 validTime = 2X約定響應(yīng)時間；步驟C323 而后發(fā)送一條SNMP set指令，將處理后的值賦值給有效時間validTime ；所述的步驟C34，按如下步驟進行步驟C341 服務(wù)提供者端SNMP代理向服務(wù)監(jiān)測者端SNMP管理者發(fā)送一個事件通知即 擴展的陷入消息；步驟C342 監(jiān)測者端SNMP管理者接收到事件通知后，根據(jù)約定質(zhì)量中所指定的服務(wù)響 應(yīng)時間對validTime參數(shù)進行處理；validTime參數(shù)賦值為增加30%的服務(wù)響應(yīng)時間，即 validTime = (1+30% ) X 約定響應(yīng)時間；步驟C343 而后發(fā)送一條SNMP set指令，將處理后的值賦值給有效時間validTime。
6.按權(quán)利要求2所述的端到端Web服務(wù)質(zhì)量監(jiān)測方法，其特征在于所述的步驟D，按 如下步驟進行步驟Dl 周期性的輪詢服務(wù)端會話表SQoWS_Group. sessionTable,如果發(fā)現(xiàn)了新交 付的服務(wù)會話，即status = delivered or failure，則取出該會話所對應(yīng)的客戶地址 clientAddr和服務(wù)會話標識sessionID，同時將服務(wù)會話狀態(tài)status更新為collected ；步驟D2 按照客戶地址讀取該客戶的會話表CQ0WS_Gr0Up，按照服務(wù)會話標識 sessionID提取該服務(wù)會話在客戶端的管理信息，并將其服務(wù)會話狀態(tài)status更新為 collected。
7.按權(quán)利要求2所述的端到端Web服務(wù)質(zhì)量監(jiān)測方法，其特征在于所述的步驟F，按 如下步驟進行步驟Fl 對單次服務(wù)會話的質(zhì)量進行評估；步驟F2 對各個QoWS指標進行長期評估；步驟F3 對服務(wù)質(zhì)量進行長期評估，即對服務(wù)達到約定質(zhì)量的程度進行統(tǒng)計，其統(tǒng)計 方法按下式進行
8.按權(quán)利要求7所述的端到端Web服務(wù)質(zhì)量監(jiān)測方法，其特征在于所述的步驟Fl，按 如下步驟進行步驟Fll 對單次服務(wù)會話的各個QoWS指標參數(shù)進行評估，計算方法如下(1).對于在SLA中所約定的交付質(zhì)量參數(shù)的計算方法1)對于正參數(shù)，即參數(shù)值越大所反映的服務(wù)質(zhì)量越好；
全文摘要
一種端到端Web服務(wù)質(zhì)量監(jiān)測系統(tǒng)及方法，該監(jiān)測系統(tǒng)包括以下四個模塊注冊模塊、SNMP代理模塊、監(jiān)測模塊和評價模塊；該監(jiān)測方法按如下步驟進行步驟A注冊；步驟B生成約定質(zhì)量的各個參數(shù)及參數(shù)值；步驟C發(fā)送將約定質(zhì)量參數(shù)；步驟D獲取服務(wù)會話信息，步驟E獲取服務(wù)會話的管理信息；步驟F得到與約定質(zhì)量參數(shù)所對應(yīng)的交付質(zhì)量參數(shù)值及感知質(zhì)量參數(shù)值；步驟G監(jiān)測模塊將交付質(zhì)量參數(shù)值、感知質(zhì)量參數(shù)值和傳輸質(zhì)量參數(shù)值發(fā)送給評價模塊；步驟H評價模塊對該服務(wù)的質(zhì)量信息進行評估和統(tǒng)計。本發(fā)明的優(yōu)點簡單有效且開銷較低，并能夠客觀的、綜合的反映服務(wù)會話質(zhì)量信息，以便為服務(wù)選取提供客觀依據(jù)。
文檔編號H04L12/24GK102123056SQ201010563710
公開日2011年7月13日 申請日期2010年11月29日 優(yōu)先權(quán)日2010年11月29日
發(fā)明者張斌, 那俊, 郭軍, 郭楠, 高巖, 黃利萍 申請人:東北大學