理解Web服務(wù)的服務(wù)質(zhì)量

申請免費(fèi)試用、咨詢電話：400-8352-114

理解Web服務(wù)的服務(wù)質(zhì)量 
 
－－改善Web服務(wù)的性能

Anbazhagan Mani（manbazha@in.ibm.com），軟件工程師，IBM Software Labs，印度

Arun Nagarajan（anagaraj@in.ibm.com），軟件工程師，IBM Global Services，印度

2002 年 1 月

隨著 Web 服務(wù)的廣泛擴(kuò)展，服務(wù)質(zhì)量（quality of service，QoS）將變成一個(gè)判定服務(wù)提供者是否成功的重要因素。QoS 決定服務(wù)的可用性和實(shí)用性，而這兩方面都會(huì)影響到服務(wù)的普及。在本文中，我們將看一看各種 Web 服務(wù) QoS 需求、影響 Web 服務(wù)性能的瓶頸、提高服務(wù)質(zhì)量的方法、事務(wù)性服務(wù)以及一種使用服務(wù)代理測量 Web 服務(wù)響應(yīng)時(shí)間的簡單方法。

動(dòng)態(tài)電子商務(wù)的前景要求在因特網(wǎng)上無縫集成業(yè)務(wù)流程、應(yīng)用程序和 Web 服務(wù)。由于因特網(wǎng)的動(dòng)態(tài)性和不可預(yù)知性，在因特網(wǎng)上提供 QoS 是一個(gè)至關(guān)重要且意義重大的挑戰(zhàn)。特征和需求極其不同的應(yīng)用程序都爭用不足的網(wǎng)絡(luò)資源。通信模式的變化、拒絕服務(wù)攻擊、基礎(chǔ)構(gòu)造失效的影響、Web 協(xié)議的低性能以及 Web 上的安全性問題這些因素產(chǎn)生了對因特網(wǎng) QoS 標(biāo)準(zhǔn)的需求。通常，未解決的 QoS 問題會(huì)導(dǎo)致重要的事務(wù)性應(yīng)用程序遭受無法接受的性能下降。

隨著 SOAP、UDDI 和 WSDL 之類的標(biāo)準(zhǔn)被所有主要的 Web 服務(wù)從事者采用，Web 服務(wù)的整個(gè)領(lǐng)域 — 包括金融服務(wù)、高科技和媒體以及娛樂領(lǐng)域目前都正在開發(fā)。由于大多數(shù) Web 服務(wù)將需要建立并遵守標(biāo)準(zhǔn)，QoS 將變成這些服務(wù)的重要賣點(diǎn)和區(qū)分點(diǎn)。

QoS 涉及到一整套技術(shù)，這些技術(shù)根據(jù)可用的網(wǎng)絡(luò)資源使服務(wù)請求者的需要與服務(wù)提供者的需要達(dá)成一致。談到 QoS，我們指的是 Web 服務(wù)的非功能性屬性，如性能、可靠性、可用性和安全性。

Web 服務(wù)的 QoS 需求

支持 Web 服務(wù)中的 QoS 的主要需求如下：

可用性：可用性是質(zhì)量的一個(gè)方面，指 Web 服務(wù)是否存在或是否已就緒可供立即使用。可用性表示服務(wù)可用的可能性。較大的值表示服務(wù)一直可供使用，而較小的值表示無法預(yù)知在某個(gè)特定時(shí)刻服務(wù)是否可用。與可用性有關(guān)的還有修復(fù)時(shí)間（time-to-repair，TTR）。TTR 表示修復(fù)已經(jīng)失效的服務(wù)要花費(fèi)的時(shí)間。理想情況下，較小的 TTR 值是合乎需要的。

可訪問性：可訪問性是服務(wù)質(zhì)量的一個(gè)方面，表示能夠?yàn)?Web 服務(wù)請求提供服務(wù)的程度。它可以表示為一種可能性尺度，用來表示在某個(gè)時(shí)間點(diǎn)上成功地實(shí)例化服務(wù)的成功率或機(jī)會(huì)。Web 服務(wù)可用但卻無法訪問這種情形是可能存在的?？梢酝ㄟ^構(gòu)建一個(gè)可高度伸縮的系統(tǒng)使 Web 服務(wù)得到很高的可訪問性?？缮炜s性是指不管請求量如何變化，都能夠始終如一地為請求服務(wù)的能力。

完整性：完整性是質(zhì)量的一個(gè)方面，指 Web 服務(wù)如何維護(hù)交互相對于最初情況的正確性。 適當(dāng)?shù)貓?zhí)行 Web 服務(wù)事務(wù)會(huì)實(shí)現(xiàn)正確的交互。一個(gè)事務(wù)是指一系列將被當(dāng)作單個(gè)工作單元的活動(dòng)。要使事務(wù)成功，必須完成所有的活動(dòng)。如果一個(gè)事務(wù)未完成，那么所做的全部更改都被回滾。
性能：性能是 Web 服務(wù)質(zhì)量的一個(gè)方面，可以根據(jù)吞吐量和延遲對其進(jìn)行測量。吞吐量的值較大且延遲的值較小表示 Web 服務(wù)性能良好。吞吐量表示在給定時(shí)間段內(nèi)被服務(wù)的 Web 服務(wù)請求數(shù)。延遲是發(fā)送請求和接收響應(yīng)之間的往返時(shí)間。

可靠性：可靠性是 Web 服務(wù)質(zhì)量的一個(gè)方面，表示能夠維護(hù)服務(wù)和服務(wù)質(zhì)量的程度。每月或每年的失效次數(shù)是衡量 Web 服務(wù)可靠性的尺度。在另一種意義上，可靠性是指服務(wù)請求者和服務(wù)提供者發(fā)送和接收的消息的有保證和有序的傳送。

常規(guī)性: 常規(guī)性是質(zhì)量的一個(gè)方面，指 Web 服務(wù)與規(guī)則、法律一致，遵循標(biāo)準(zhǔn)和已建立的服務(wù)級(jí)別協(xié)議。Web 服務(wù)使用許多標(biāo)準(zhǔn)，例如 SOAP、UDDI 和 WSDL。要正確調(diào)用服務(wù)請求者請求的服務(wù)，就必須嚴(yán)格遵守服務(wù)提供者所提供的正確版本的標(biāo)準(zhǔn)（例如，SOAP 版本 1.2）。
安全性：安全性是 Web 服務(wù)質(zhì)量的一個(gè)方面，通過驗(yàn)證涉及到的各方、對消息加密以及提供訪問控制來提供機(jī)密性和不可抵賴性。由于 Web 服務(wù)調(diào)用是發(fā)生在公共的因特網(wǎng)上，安全性的重要性已經(jīng)有所增加。根據(jù)服務(wù)請求者的不同，服務(wù)提供者可以用不同的方法來提供安全性，所提供的安全性也可以有不同的級(jí)別。

啟用 QoS 的 Web 服務(wù)

接口定義（WSDL）為服務(wù)指定了語法說明，但在語義和非功能性方面沒做任何指定。啟用 QoS 的 Web 服務(wù)需要面向 Web 服務(wù)的一種獨(dú)立的 QoS 語言來回答下列問題：

什么是預(yù)期的延遲？

什么是可接受的往返時(shí)間？

程序員在開發(fā)調(diào)用 Web 服務(wù)的應(yīng)用程序時(shí)要能夠理解 Web 服務(wù)的 QoS 特征。

理想情況下，啟用 QoS 的 Web 服務(wù)平臺(tái)應(yīng)該能夠支持許多種不同類型的應(yīng)用程序：

有不同的 QoS 需求

使用不同類型的通信和計(jì)算資源

在考慮有 QoS 意識(shí)的 Web 服務(wù)時(shí)，我們假設(shè)使用關(guān)于 QoS 的語句擴(kuò)展了接口規(guī)范，這些語句可以被關(guān)聯(lián)到整個(gè)接口，也可關(guān)聯(lián)到個(gè)別操作和屬性。對于服務(wù)請求者來說，這些語句描述了所要求的 QoS，該 QoS 與客戶所要求的服務(wù)有關(guān)，而從服務(wù)提供者的角度來說，這些語句描述了所提供的 QoS，該 QoS 與服務(wù)器對象所提供的服務(wù)有關(guān)。

IBM 設(shè)計(jì)出的 Web 服務(wù)體系結(jié)構(gòu)包含一個(gè)名為“端點(diǎn)描述”的獨(dú)立的層，來向服務(wù)描述添加額外的語義，如 QoS 屬性。

QoS 協(xié)商與綁定的建立

在使用啟用 QoS 的 Web 服務(wù)平臺(tái)建立綁定期間，應(yīng)該執(zhí)行下列步驟：

服務(wù)請求者通過指定對 Web 服務(wù)接口的引用請求建立綁定。該請求還包含所要求的 QoS。

QoS 中介者在 UDDI 中搜索服務(wù)提供者。

QoS 中介者象下面描述的那樣進(jìn)行 QoS 協(xié)商。

Web 服務(wù) QoS 中介者將所提供的 QoS 與所要求的 QoS 進(jìn)行比較并使用其內(nèi)部信息來確定一個(gè)約定的 QoS。這個(gè)過程被稱為 QoS 協(xié)商。
如果 QoS 協(xié)商已經(jīng)成功，則通知服務(wù)請求者和服務(wù)提供者協(xié)商已經(jīng)成功，并且已經(jīng)建立了一個(gè)綁定。從這個(gè)時(shí)刻起，這些對象就可以通過綁定進(jìn)行交互了。

Web 服務(wù)的性能瓶頸

由于底層消息傳遞和傳輸協(xié)議的局限性，Web 服務(wù)會(huì)遇到性能瓶頸。然而，對公眾普遍接受的協(xié)議（例如 HTTP 和 SOAP）的依賴卻使它們成了必須承擔(dān)的永久的負(fù)擔(dān)。因此，理解這些局限性的工作方式就很重要。

HTTP

HTTP 是一種盡力而為的傳輸服務(wù)。它是一個(gè)無狀態(tài)的數(shù)據(jù)轉(zhuǎn)發(fā)機(jī)制，往往會(huì)產(chǎn)生兩個(gè)主要問題：

不保證數(shù)據(jù)包會(huì)被傳輸?shù)侥康牡亍?BR>
不保證數(shù)據(jù)包到達(dá)的順序。

如果無可用的帶寬，那么數(shù)據(jù)包就會(huì)被簡單地廢棄。隨著運(yùn)行在網(wǎng)絡(luò)上的用戶和數(shù)據(jù)量的增加，帶寬顯然是一個(gè)瓶頸。習(xí)慣上，許多應(yīng)用程序都假設(shè)零延遲和無限帶寬。而且，習(xí)慣上應(yīng)用程序使用同步消息傳遞。當(dāng)您在自己的計(jì)算機(jī)上運(yùn)行應(yīng)用程序時(shí)，同步的消息傳遞是沒什么問題的；組件通信的延遲以幾毫秒計(jì)。但是，對于 Web 服務(wù)來說，它們是通過因特網(wǎng)進(jìn)行通信，這意味著延遲要以幾十、幾百甚至幾千微秒計(jì)。

雖然可以使用新設(shè)計(jì)的協(xié)議如“可靠 HTTP”（Reliable HTTP，HTTPR）、“塊可擴(kuò)展交換協(xié)議”（Blocks Extensible Exchange Protocol，BEEP）和“直接因特網(wǎng)消息封裝”（Direct Internet Message Encapsulation，DIME），但這些用于 Web 服務(wù)傳輸?shù)男聟f(xié)議（如 HTTPR 和 BEEP）的廣泛采用還需要一些時(shí)間。因此，使用 Web 服務(wù)的應(yīng)用程序設(shè)計(jì)人員在設(shè)計(jì)他們的系統(tǒng)時(shí)應(yīng)該理解 Web 服務(wù)的性能問題，比如延遲和可用性。下面給出了一些改善 Web 服務(wù)性能的方法。

使用異步消息隊(duì)列

依賴遠(yuǎn)程 Web 服務(wù)的應(yīng)用程序可以使用消息排隊(duì)來改善可靠性，但要以響應(yīng)時(shí)間為代價(jià)。 一個(gè)企業(yè)內(nèi)的應(yīng)用程序和 Web 服務(wù)可以使用消息排隊(duì)如“Java 消息傳遞服務(wù)”（Java Messaging Service，JMS）或 IBM MQSeries 進(jìn)行 Web 服務(wù)調(diào)用。企業(yè)消息傳遞為整個(gè)企業(yè)內(nèi)的關(guān)鍵數(shù)據(jù)異步交換提供可靠、靈活的服務(wù)。 消息隊(duì)列有兩個(gè)主要優(yōu)勢：

它是異步的：一個(gè)消息傳遞服務(wù)提供者可以在消息到達(dá)時(shí)向請求者傳遞消息，請求者不必為接收消息而請求消息。

它是可靠的：消息傳遞服務(wù)可以確保一條消息被傳遞一次，且僅傳遞一次。

將來，因特網(wǎng)上的發(fā)布和訂閱消息傳遞系統(tǒng)如 alphaWorks 上的 Utility Services 包可以用于 Web 服務(wù)調(diào)用（請參閱參考資料）。

專用 WAN 和 Web 服務(wù)網(wǎng)絡(luò)

對于依賴對其任務(wù)關(guān)鍵的 Web 服務(wù)的企業(yè)來說，使用專用 WAN／企業(yè)外部網(wǎng)和 Web 服務(wù)網(wǎng)絡(luò)是一個(gè)合適的選擇。這些專用網(wǎng)提供較短的網(wǎng)絡(luò)延遲、較少的擁塞、可靠傳遞和不可抵賴性。但是，對某些企業(yè)來說，擁有一個(gè)專用網(wǎng)是很昂貴的。

SOAP 和性能

SOAP 是 Web 服務(wù)實(shí)際上的有線協(xié)議。SOAP 性能由于以下原因而降低：

從 SOAP 數(shù)據(jù)包抽取 SOAP 信封（envelope）比較耗時(shí)。

使用 XML 解析器分析 SOAP 信封內(nèi)包含的 XML 信息也很耗時(shí)。

XML 數(shù)據(jù)的優(yōu)化可能性不太大。

SOAP 編碼規(guī)則強(qiáng)制在所有發(fā)送和接收的 SOAP 消息中包含類型指定信息。

以 XML 可接受的格式對二進(jìn)制數(shù)據(jù)進(jìn)行編碼會(huì)導(dǎo)致因編碼而增加的額外字節(jié)的開銷，還有執(zhí)行編碼／解碼的處理器開銷。

必須加載、實(shí)例化 XML 處理器，并為其提供 XML 數(shù)據(jù)。接下來必須發(fā)現(xiàn)方法調(diào)用參數(shù)信息。隨著 XML 處理器為了支持更多的 XML 功能而發(fā)展，這會(huì)包括很多開銷。

SOAP 性能中 XML 解析器的角色

大多數(shù)現(xiàn)有的 XML 解析器從代碼規(guī)模、處理時(shí)間和內(nèi)存占用來說都開銷太大，因?yàn)檫@些解析器必須支持許多功能，如類型檢查和轉(zhuǎn)換、格式良好檢查或者歧義解決。所有這些使得 XML 解析器需要更多的計(jì)算資源。一些應(yīng)用程序可以考慮使用 XML 解析器的精簡版，精簡版的代碼規(guī)模和內(nèi)存占用都比較小。

另外，目前的大多數(shù) SOAP 實(shí)現(xiàn)都是基于“文檔對象模型”（Document Object Model，DOM）的。DOM 解析器分析消息的速度本來就慢。可以使用基于 SAX 的 SOAP 實(shí)現(xiàn)來增加吞吐量、減少內(nèi)存開銷并改善可伸縮性。

壓縮 XML

SOAP 使用 XML 作為它的有效負(fù)載。如果我們考慮到數(shù)千條 SOAP 消息正在 Web 上傳送， 那么網(wǎng)絡(luò)帶寬已經(jīng)達(dá)到了極限。按 XML 的方法顯示數(shù)據(jù)，數(shù)據(jù)大小通常會(huì)比以二進(jìn)制格式顯示相同的數(shù)據(jù)大得多，前者平均是后者的 400%。當(dāng)必須快速傳送消息時(shí)，消息大小的這種增長會(huì)產(chǎn)生一個(gè)很嚴(yán)重的問題，即它會(huì)導(dǎo)致數(shù)據(jù)傳送時(shí)間的顯著增加。一些應(yīng)用程序設(shè)計(jì)應(yīng)該考慮壓縮的和高效的表示法。達(dá)到這一目標(biāo)的其中一個(gè)方法是壓縮 XML — 特別是當(dāng)壓縮所需要的 CPU 開銷小于網(wǎng)絡(luò)延遲時(shí)。

影響 Web 服務(wù)性能的其它因素

還有其它因素會(huì)影響 Web 服務(wù)性能，這些因素是 Web 服務(wù)應(yīng)用程序無法控制的，比如：

Web 服務(wù)器的響應(yīng)時(shí)間和可用性。

應(yīng)用程序的最初執(zhí)行時(shí)間，如 Web 應(yīng)用程序服務(wù)器中 EJB/Servlet 的最初執(zhí)行時(shí) 間。

后端數(shù)據(jù)庫或舊系統(tǒng)的性能。

提供主動(dòng) Web 服務(wù) QoS 的方法

通過使用各種不同的常見方法，如服務(wù)請求的高速緩存和負(fù)載平衡，服務(wù)提供者可以主動(dòng)向服務(wù)請求者提供很高的 QoS。在 Web 服務(wù)器級(jí)別上和 Web 應(yīng)用程序服務(wù)器級(jí)別上都可以完成高速緩存和負(fù)載平衡。負(fù)載平衡區(qū)分各種類型通信的優(yōu)先次序，并確保適當(dāng)?shù)匕凑彰總€(gè)請求所表現(xiàn)出的商業(yè)價(jià)值對待它。

Web 服務(wù)提供者可以執(zhí)行容量建模來創(chuàng)建一個(gè)請求流量、當(dāng)前容量利用和結(jié)果 QoS 的自上而下的模型。服務(wù)提供者還可以根據(jù)通信量、不同應(yīng)用程序服務(wù)類別的通信和來自不同來源的通信對 Web 服務(wù)通信進(jìn)行分類。這將有助于理解為大量服務(wù)需求和將來的計(jì)劃如對 Web 應(yīng)用程序服務(wù)器和／或 Web 服務(wù)器進(jìn)行負(fù)載平衡的容量和類型（例如，建立一個(gè)群集服務(wù)器站所需的服務(wù)器數(shù)目）提供好的 QoS 所需要的容量。

服務(wù)提供者可以通過使用容量模型來確定不同的客戶和服務(wù)類型所需的容量以及通過確保不同應(yīng)用程序和顧客的正確 QoS 級(jí)別來提供區(qū)別服務(wù)。例如，一個(gè)多媒體 Web 服務(wù)可能要求好的吞吐量，但一個(gè)銀行 Web 服務(wù)可能要求安全性和事務(wù)性 QoS。

事務(wù)性 QoS

事務(wù)性 QoS 是指執(zhí)行事務(wù)的可靠性和一致性級(jí)別。事務(wù)性 QoS 對于維護(hù) Web 服務(wù)的完整性至關(guān)重要。事務(wù)對于業(yè)務(wù)流程保證一組相關(guān)的活動(dòng)被當(dāng)作一個(gè)工作單元并完成來說非常重要。如果執(zhí)行事務(wù)時(shí)發(fā)生異常，就必須把事務(wù)恢復(fù)到一個(gè)一致的狀態(tài)。這個(gè)屬性被稱為事務(wù)的“原子性”。除了原子性之外，從更嚴(yán)格的意義上來說，事務(wù)還應(yīng)該滿足一致性、孤立性和持久性等屬性 。所有這四個(gè)屬性被統(tǒng)稱為“ACID”屬性（請參閱旁注）。

事務(wù)的 ACID 屬性

原子性（Atomicity）：一個(gè)事務(wù)是處理過程的一個(gè)原子單元；要么執(zhí)行整個(gè)事務(wù)，要么一點(diǎn)也不執(zhí)行。

一致性（Consistency）：事務(wù)的正確執(zhí)行必須是使系統(tǒng)從一個(gè)一致的狀態(tài)到另一個(gè)一致的狀態(tài)。

孤立性（Isolation）：在事務(wù)被提交之前，它的更新對其它事務(wù)應(yīng)該是不可見的。也就是說，它應(yīng)該自己運(yùn)行，就象沒有其它事務(wù)在運(yùn)行一樣。

持久性（Durability）：一個(gè)事務(wù)一旦提交，所提交的更改必須在任何故障事件下都永不丟失。
 
提供事務(wù)性 QoS 的方法有下面幾種。最流行的方法是“兩階段提交”，這種方法傳統(tǒng)上用在 Web 應(yīng)用程序體系結(jié)構(gòu)中?！皟呻A段提交”提供了一個(gè)事務(wù)協(xié)調(diào)器，它根據(jù)這樣一種思想來控制事務(wù) — 不允許提交任何成分事務(wù)，除非它們能夠全部提交?！癑ava 事務(wù)服務(wù)”（Java Transactional Service，JTS）、CORBA OTS 和大多數(shù)數(shù)據(jù)庫管理系統(tǒng)中都使用這種使用事務(wù)協(xié)調(diào)器來確保原子性的方法。

但在我們考慮涉及到 Web 服務(wù)的事務(wù)時(shí)，還有一些新的復(fù)雜之處。特定的應(yīng)用程序或 Web 服務(wù)所使用的 Web 服務(wù)不僅歸不同的各方所有，還常在 Web 上被遠(yuǎn)程分發(fā)?？紤]到事務(wù)協(xié)調(diào)器不具備對全部資源的完全控制能力，在 Web 服務(wù)環(huán)境中擁有一個(gè)中央事務(wù)協(xié)調(diào)器（它可以指定規(guī)則并執(zhí)行提交和回滾）實(shí)現(xiàn)起來是非常乏味的。另外，“兩階段提交”協(xié)議還包括一種或其它形式的資源鎖定。較長時(shí)間地鎖定資源會(huì)導(dǎo)致嚴(yán)重的可伸縮性問題。因此，即使有可能使用，也要特別注意確保資源未被長時(shí)間鎖定。

OASIS Business Transactions 技術(shù)委員會(huì)已經(jīng)發(fā)布了“業(yè)務(wù)交易協(xié)議”（Business Transaction Protocol，BTP），該協(xié)議擴(kuò)展了“兩階段提交”事務(wù)管理方法以滿足使用 XML 在 Web 上交換數(shù)據(jù)的完全不同的貿(mào)易伙伴的需要。BTP 允許跨越多個(gè)企業(yè)的長期持久事務(wù)是正常 ACID 事務(wù)和非 ACID 事務(wù)（術(shù)語上稱為“聚合”）。

另一種被稱為“補(bǔ)償”的方法是基于這樣一種思想 — 一直允許提交事務(wù)，但在提交后可以取消它的影響和活動(dòng)。例如，預(yù)定一次發(fā)貨，如果還沒開始所要求的發(fā)貨流程，就可以取消這次發(fā)貨。取消發(fā)貨是補(bǔ)償事務(wù)的一個(gè)示例；它補(bǔ)償預(yù)定發(fā)貨的最初事務(wù)。在補(bǔ)償事務(wù)中，每個(gè)“真正的”事務(wù)都有一個(gè)相關(guān)聯(lián)的“補(bǔ)償”事務(wù)。 這個(gè)“補(bǔ)償”事務(wù)元素描述了一種方法，這種方法是還原“真正的”事務(wù)造成的變化并返回到先前一致的狀態(tài)。如果任何事務(wù)異常終止，調(diào)用者都會(huì)為先前提交的所有事務(wù)執(zhí)行相應(yīng)的補(bǔ)償事務(wù)。與補(bǔ)償事務(wù)相關(guān)的兩個(gè)主要問題是：

與兩階段提交不同，補(bǔ)償事務(wù)可能無法總是滿足全部四個(gè)“ACID”屬性 — 這意味著一直有失效的可能。
必須重新設(shè)計(jì)以前設(shè)計(jì)的兩階段提交事務(wù)來提供補(bǔ)償方法。

Web Services ToolKit proxygen

“服務(wù)代理生成器”（Service Proxy Generator）工具可以用于創(chuàng)建可與 Web 服務(wù)交互的客戶機(jī)代理。這個(gè)工具檢查 WSDL 文檔并生成可用于調(diào)用 Web 服務(wù)的 Java 編程語言類。這個(gè)工具是 WSDL 工具箱的一個(gè)部分。可以使用 proxygen 命令運(yùn)行該工具。這個(gè)命令位于 WSTK_HOME/bin 目錄中。這個(gè)命令有一個(gè)必需的輸入?yún)?shù)。這個(gè)參數(shù)是 WSDL 服務(wù)描述文檔的文件名。
 
測量 Web 服務(wù)響應(yīng)時(shí)間的一個(gè)簡單方法

通過在服務(wù)代理中添加一點(diǎn)額外的功能就可以開發(fā)一種測量 Web 服務(wù)性能特征的簡單方法。Web 服務(wù)中的服務(wù)代理與 Java RMI 中的存根相似。它們包含特定于服務(wù)接口中的綁定的代碼，從而對客戶機(jī)隱藏了復(fù)雜的網(wǎng)絡(luò)通信細(xì)節(jié)。例如，如果該綁定是一個(gè) SOAP 綁定，那么服務(wù)代理將包含特定于 SOAP 的代碼，這些代碼可被客戶機(jī)用來調(diào)用服務(wù)。

開發(fā)一個(gè)能夠測量響應(yīng)時(shí)間的代理包括如下步驟：

根據(jù) WSDL 服務(wù)定義文件生成服務(wù)代理。

修改生成的服務(wù)代理，添加計(jì)時(shí)代碼（請參閱清單 2）。

重新編譯修改過的服務(wù)代理。

開發(fā)一個(gè)客戶機(jī)程序來創(chuàng)建一個(gè)服務(wù)代理對象并調(diào)用必需的方法。

第一步：根據(jù)服務(wù)定義生成一個(gè)服務(wù)代理

一般情況下，服務(wù)代理不是由程序員寫的?？梢院苋菀椎馗鶕?jù) WSDL 文件生成服務(wù)代理。Web Service Toolkit（包含 alphaWorks WSTK）提供生成服務(wù)代理的工具（請參閱旁注）。清單 1 中給出了 EchoService 的一個(gè)樣本 WSDL 服務(wù)定義。這是一個(gè)簡單的 Web 服務(wù)，它回顯在末尾附加了一個(gè)“Hello”的原始字符串。

清單 1：一個(gè)簡單 EchoService 的 WSDL 文件

<?xml version="1.0" encoding="UTF-8"?>
<definitions name="EchoService"
  targetNamespace="http://www.echoserviceservice.com/EchoService-interface"
  xmlns="http://schemas.xmlsoap.org/wsdl/"
  xmlns:soap="http://schemas.xmlsoap.org/wsdl/soap/"
  xmlns:tns="http://www.echoserviceservice.com/EchoService"
    xmlns:xsd="http://www.w3.org/1999/XMLSchema">
<message name="InechoRequest">
  <part name="meth1_inType1" type="xsd:string"/>
</message>
<message name="OutechoResponse">
  <part name="meth1_outType" type="xsd:string"/>
</message>
<portType name="EchoService">
  <operation name="echo">
    <input message="InechoRequest"/>
    <output message="OutechoResponse"/>
  </operation>
</portType>
<binding name="EchoServiceBinding" type="EchoService">
  <soap:binding style="rpc" transport="http://schemas.xmlsoap.org/soap/http"/>
  <operation name="echo">
    <soap:operation soapAction="urn:echoservice-service"/>
    <input>
      <soap:body
          encodingStyle="http://schemas.xmlsoap.org/soap/encoding/"
          namespace="urn:echoservice-service"
          use="encoded"/>
    </input>
    <output>
      <soap:body
          encodingStyle="http://schemas.xmlsoap.org/soap/encoding/"
          namespace="urn:echoservice-service" use="encoded"/>
    </output>
  </operation>
</binding>
<service
      name="EchoService">
  <documentation>IBM WSTK 2.0 generated service definition file</documentation>
  <port binding="EchoServiceBinding" name="EchoServicePort">
    <soap:address location="http://localhost:8080/soap/servlet/rpcrouter"/>
  </port>
</service>
</definitions>   

 第 2 步：修改已生成的服務(wù)代理

即使機(jī)器生成的“服務(wù)代理”代碼不應(yīng)編輯，我們也不必太嚴(yán)格服從這個(gè)規(guī)則，可以添加幾行代碼。 這些添加的代碼行實(shí)例化一個(gè) Timer 對象以測量綁定到服務(wù)器和調(diào)用方法的時(shí)間。清單 2 中給出的樣本代碼對此進(jìn)行了演示。

清單 2：修改過的服務(wù)代理（修改過的代碼以紅色顯示）

import java.net.*;
import java.util.*;
import org.apache.soap.*;
import org.apache.soap.encoding.*;
import org.apache.soap.rpc.*;
import org.apache.soap.util.xml.*;
import mytimer.Timer;
public class EchoServiceProxy
{
  private Call call = new Call();
  private URL url = null;
  private String SOAPActionURI = "";
  private SOAPMappingRegistry smr = call.getSOAPMappingRegistry();
  public EchoServiceProxy() throws MalformedURLException
  {
    call.setTargetObjectURI("urn:echoservice-service");
    call.setEncodingStyleURI("http://schemas.xmlsoap.org/soap/encoding/");
    this.url = new URL("http://localhost:8080/soap/servlet/rpcrouter");
    this.SOAPActionURI = "urn:echoservice-service";
  }
  public synchronized void setEndPoint(URL url)
  {
    this.url = url;
  }
  public synchronized URL getEndPoint()
  {
    return url;
  }
  public synchronized java.lang.String echo
    (java.lang.String meth1_inType1) throws SOAPException
  {
    if (url == null)
    {
      throw new SOAPException(Constants.FAULT_CODE_CLIENT,
      "A URL must be specified via " +
      "EchoServiceProxy.setEndPoint(URL).");
    }
    call.setMethodName("echo");
    Vector params = new Vector();
    Parameter meth1_inType1Param = new Parameter("meth1_inType1",
      java.lang.String.class, meth1_inType1, null);
    params.addElement(meth1_inType1Param);
    call.setParams(params);

    // Start a Timer
    Timer timer = new Timer();
    timer.start();

    Response resp = call.invoke(url, SOAPActionURI);

    // Stop the Timer
    timer.stop();
    // Print the response time by calculating the difference
    System.out.println("Response Time = " + timer.getDifference());

    // Check the response.
    if (resp.generatedFault())
    {
      Fault fault = resp.getFault();
      throw new SOAPException(fault.getFaultCode(), fault.getFaultString());
    }
    else
    {
      Parameter retValue = resp.getReturnValue();
      return (java.lang.String)retValue.getValue();
    }
  }
}

 第 3 步：重新編譯修改過的服務(wù)代理

必須重新編譯修改過的服務(wù)代理源文件，只要使用 javac 命令或其它任何編譯器即可。

第 4 步：開發(fā)一個(gè)客戶機(jī)程序

開發(fā)一個(gè)客戶機(jī)應(yīng)用程序，該應(yīng)用程序可以使用服務(wù)代理來調(diào)用 Web 服務(wù)。它可以是一個(gè)簡單的 Java 程序或一個(gè)基于 AWT/Swing 的 Java GUI 應(yīng)用程序。

結(jié)束語

服務(wù)質(zhì)量是企業(yè)對企業(yè)交易的一個(gè)重要條件，因此也是 Web 服務(wù)中的一個(gè)必需元素。 在 Web 服務(wù)應(yīng)用程序的實(shí)現(xiàn)中需要滿足各種 QoS 屬性，比如可用性、可訪問性、完整性、性能、可靠性、常規(guī)性和安全性。當(dāng)您向 Web 服務(wù)加入事務(wù)性特征的需要時(shí)，屬性會(huì)變得更加復(fù)雜。諸如 HTTP 和 SOAP 之類協(xié)議的一些局限性可能會(huì)阻礙 QoS 的實(shí)現(xiàn)，但有許多方法可以在 Web 服務(wù)中提供主動(dòng)的 QoS。

參考資料

• 請參與本文的討論論壇。
  
• “可靠 HTTP”（HTTPR）為 HTTP 實(shí)現(xiàn)了原子性。
  
• “塊可擴(kuò)展交換協(xié)議”（BEEP）還可將 Web 服務(wù)數(shù)據(jù)打包以便傳送。
  
• 請閱讀“直接因特網(wǎng)消息封裝”（DIME）規(guī)范以理解 Web 服務(wù)中的數(shù)據(jù)編碼。
  
• 了解更多關(guān)于 IBM Web 服務(wù)概念性體系結(jié)構(gòu)的知識(shí)。
  
• 從 alphaWorks 下載 Web Services ToolKit。
  
• 了解更多關(guān)于“Java 消息傳遞服務(wù)”的知識(shí)。
  
• 了解更多關(guān)于 OASIS 組織的“業(yè)務(wù)交易協(xié)議”（BTP）的知識(shí)。
  
• 了解更多關(guān)于消息排隊(duì)和 IBM MQSeries 的知識(shí)。
  
• 看一看 IBM 的出版物并訂閱消息傳遞實(shí)用服務(wù)。

關(guān)于作者

Anbazhagan Mani 是位于印度的 IBM Software Labs 的軟件工程師。他有 WebSphere 系列工具、XML、Java 技術(shù)、BPM、工作流和對象技術(shù)這些方面的工作經(jīng)驗(yàn)。最近，他一直致力于 Web 服務(wù) QoS、P2P 計(jì)算和“業(yè)務(wù)流程集成”（Business Process Integration）?？梢酝ㄟ^ manbazha@in.ibm.com 與他聯(lián)系。

Arun Nagarajan 是位于印度的 IBM Global Services 的軟件工程師。他以前曾從事 XML 和 Java 技術(shù)如 JavaBeans、J2EE 和 WebSphere。目前，他一直在從事不同的 Web 服務(wù)技術(shù)如 SOAP、WSDL、UDDI 等等?？梢酝ㄟ^ anagaraj@in.ibm.com 與他聯(lián)系。