理解Web服務的服務質量

申請免費試用、咨詢電話：400-8352-114

理解Web服務的服務質量 
 
－－改善Web服務的性能

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

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

2002 年 1 月

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

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

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

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

Web 服務的 QoS 需求

支持 Web 服務中的 QoS 的主要需求如下：

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

可訪問性：可訪問性是服務質量的一個方面，表示能夠為 Web 服務請求提供服務的程度。它可以表示為一種可能性尺度，用來表示在某個時間點上成功地實例化服務的成功率或機會。Web 服務可用但卻無法訪問這種情形是可能存在的。可以通過構建一個可高度伸縮的系統(tǒng)使 Web 服務得到很高的可訪問性?？缮炜s性是指不管請求量如何變化，都能夠始終如一地為請求服務的能力。

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

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

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

啟用 QoS 的 Web 服務

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

什么是預期的延遲？

什么是可接受的往返時間？

程序員在開發(fā)調用 Web 服務的應用程序時要能夠理解 Web 服務的 QoS 特征。

理想情況下，啟用 QoS 的 Web 服務平臺應該能夠支持許多種不同類型的應用程序：

有不同的 QoS 需求

使用不同類型的通信和計算資源

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

IBM 設計出的 Web 服務體系結構包含一個名為“端點描述”的獨立的層，來向服務描述添加額外的語義，如 QoS 屬性。

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

在使用啟用 QoS 的 Web 服務平臺建立綁定期間，應該執(zhí)行下列步驟：

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

QoS 中介者在 UDDI 中搜索服務提供者。

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

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

Web 服務的性能瓶頸

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

HTTP

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

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

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

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

使用異步消息隊列

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

它是異步的：一個消息傳遞服務提供者可以在消息到達時向請求者傳遞消息，請求者不必為接收消息而請求消息。

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

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

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

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

SOAP 和性能

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

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

使用 XML 解析器分析 SOAP 信封內包含的 XML 信息也很耗時。

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

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

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

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

SOAP 性能中 XML 解析器的角色

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

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

壓縮 XML

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

影響 Web 服務性能的其它因素

還有其它因素會影響 Web 服務性能，這些因素是 Web 服務應用程序無法控制的，比如：

Web 服務器的響應時間和可用性。

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

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

提供主動 Web 服務 QoS 的方法

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

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

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

事務性 QoS

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

事務的 ACID 屬性

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

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

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

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

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

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

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

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

Web Services ToolKit proxygen

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

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

開發(fā)一個能夠測量響應時間的代理包括如下步驟：

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

修改生成的服務代理，添加計時代碼（請參閱清單 2）。

重新編譯修改過的服務代理。

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

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

一般情況下，服務代理不是由程序員寫的。可以很容易地根據(jù) WSDL 文件生成服務代理。Web Service Toolkit（包含 alphaWorks WSTK）提供生成服務代理的工具（請參閱旁注）。清單 1 中給出了 EchoService 的一個樣本 WSDL 服務定義。這是一個簡單的 Web 服務，它回顯在末尾附加了一個“Hello”的原始字符串。

清單 1：一個簡單 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 步：修改已生成的服務代理

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

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

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 步：重新編譯修改過的服務代理

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

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

開發(fā)一個客戶機應用程序，該應用程序可以使用服務代理來調用 Web 服務。它可以是一個簡單的 Java 程序或一個基于 AWT/Swing 的 Java GUI 應用程序。

結束語

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

參考資料

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

關于作者

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

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