Web服務組合執行引擎中服務異步調用機制研究

摘 要:研究了BPEL4WS執行引擎WebJetFlow對Web服務的異步調用機制，在引擎的服務調用代理中對Web服務統一采用非阻塞雙傳輸異步調用，提高了調用線程的利用率。同時引入了cache機制并設計了相應的cache替換算法，保證了引擎對異步調用結果消息的匹配效率以及數據安全性， 通過實驗驗證引擎的性能有了明顯的提高。

關鍵詞:Web服務; BPEL4WS引擎; 異步調用; cache機制

中圖分類號:TP311

文獻標志碼:A

文章編號:1001-3695(2010)02-0558-05

doi:10.3969/j.issn.1001-3695.2010.02.043

Study of service asynchronous invocation mechanism in Webcomposite services execution engine

LI Ling-yong1， GAO Chun-ming 2， WEN Hua-nan1

(1.Dept. of Computer， College of Mathematics Computer Science， Hunan Normal University， Changsha 410081， China; 2. Dept. of Computer， College of Computer Communication， Hunan University， Changsha 410082， China)

Abstract:This paper studied the Web services asynchronous invocation mechanism of the BPEL4WS engine WebJetFlow. It used the non-blocking-dual-channel asynchronous invocation to invoke the Web services in the service invocation proxy of the engine in order to improve the utilization ratio of the invocation threads. Also it imported the cache mechanism and designed an algorithm for cache substitution， thus it ensured the efficiency in matching the asynchronous results and data security. Finally， the experiment results demonstrate that the performance of the engine has been improved obviously.

Key words:Web services; BPEL4WS engine; asynchronous invocation; cache mechanism

0 引言

Web服務是當前SOA實現的主流技術，越來越多的企業需要在SOA體系結構和Web服務技術框架下將企業已有的應用以Web服務的形式發布，并整合業務伙伴的Web服務以實現功能聚合，提供新的組合服務。多個Web服務按照工作流模型實現服務組合以滿足用戶需求，服務組合流程由多個成分Web服務構建并使用BPEL4WS(business process execution language for Web services)[1]等規范語言描述。服務組合流程被部署到BPEL4WS執行引擎上運行，由引擎按照事先編排的順序調用各成分Web服務來實現對流程的執行。

Web服務組合執行引擎的QoS(服務質量)保證是服務組合實用化的關鍵影響因素[2]。在當前網絡流量日益膨脹的情況下，一個服務組合流程很可能會被大量客戶端同時調用[3]，并且一個引擎上可能同時部署著多個服務組合流程，因此引擎可能成為服務組合性能的瓶頸。同時，由于服務實現中的各種原因，有些 Web 服務可能要花費相當長的時間才能響應請求。例如，如果某個Web服務需要人工介入或批處理，該Web服務可能要花數天時間才能獲得結果，這些延遲還可能導致某些傳輸機制超時。因此如何將長生命周期的服務調用轉換為異步調用也是BPEL4WS執行引擎必須要解決的問題。

WebJetFlow是一個多線程的、解耦流程執行和成分Web服務調用的BPEL4WS執行引擎[4]。WebJetFlow可以將對Web服務調用的同步模式轉換為單純的異步調用模式，減少了引擎等待Web服務調用返回結果的時間，極大地提高了流程的并發訪問執行效率，明顯改善了系統吞吐量和性能[5]。

本文討論了WebJetFlow對Web服務的異步調用機制，以及如何通過在引擎內核中引入cache機制并設計一種cache替換算法來提高cache的命中率，以此提高服務異步調用的響應信息與原請求信息的匹配效率，并進而使引擎對用戶提供QoS保障。

本文分析了當前的Web服務異步調用機制，給出了BPEL4WS執行引擎WebJetFlow的異步調用的設計，闡述了如何通過cache技術來提高服務異步調用的效率，給出了測試結果與分析。

1 Web服務異步調用機制分析

由SOAP定義的服務調用本質上是同步的，而且WSDL也只支持同步的交互模型，但并不是所有的Web服務都會同步工作，有時候對Web服務請求的響應并不是立即提供的，而是在最初的請求事務完成后的某個時候提供，即需要服務之間的異步通信。

目前對Web服務的異步調用主要通過回調機制來實現。回調是一種雙向調用模式，也就是說，被調用方在接口被調用時也會調用對方的接口。為實現自動回調機制，請求者在發送請求消息前必須進行回調注冊，即注冊相應的標志信息和相應的結果處理組件。發送請求后即可釋放請求線程，處理其他事務。當服務器處理完請求消息后，通過回調函數，把結果消息發送到服務請求者注冊的回調地址。請求者在接收到結果消息后會自動匹配注冊的回調信息，觸發相應的組件來處理結果。

Web服務的異步調用使得客戶端可以不必等待Web服務的返回結果而繼續執行，調用結果在客戶端注冊的回調函數(callback)中返回。因此對于客戶端的多個調用不會隨著調用數目的增多而發生顯著的速度變化，同時即使對某個Web服務的調用出現異常也不會影響到其他服務的調用。

為支持Web服務的異步調用，必須解決一些同步調用時無須考慮的問題:

a)必須定義回調函數以及接收服務響應結果的回調地址，并確保向服務提供方通知了這個地址。

b)客戶端發送的服務請求和服務端返回的響應結果應該分別使用不同的傳輸通道，因為如果使用相同的傳輸通道，一旦服務端對請求的處理所花的時間較長，可能造成客戶端的傳輸通道超時。

c)在不同的傳輸通道中，客戶端和服務端都要能夠正確地把服務的請求與響應關聯起來。

當前的很多平臺都對Web服務的異步調用提供了良好的支持。Apache軟件基金組織推出的開源SOAP引擎Apache Axis2 [6]就為Web服務的異步調用和實現提供了一流的支持。

Axis2可以同時在客戶端和服務端對Web服務的異步調用提供支持，它既支持單向傳輸的SMTP，又支持雙向傳輸的HTTP。因此，為了實現一次Web服務的請求—響應交互，在引擎端可以使用兩個SMTP傳輸通道或者兩個發送即關閉的HTTP傳輸通道(在發送請求消息之后馬上關閉該HTTP通道)來實現傳輸級別的異步。在引擎中可以使用useSeparateListener(true)標志來通知Axis2對此調用使用兩個不同的傳輸通道。這種傳輸級別的異步需要消息相關性機制的支持，也就是如何才能在兩個獨立的傳輸通道中正確地把服務的請求與響應關聯起來，引擎WebJetFlow和Axis2都支持WS-Addressing[7]，通過使用〈wsa:MessageID〉和〈wsa:RelatesTo〉 SOAP Header來實現消息相關性，以此來支持對模塊尋址。

同時，在Axis2中可以使用Non-Blocking API來異步調用Web服務，引擎可以通過一個Non-Blocking API把請求傳遞給Axis2，而引擎繼續去做其他工作。引擎將Axis2中的AxisCallback類包裝成一個回調對象，在該回調對象中，定義了接收服務響應結果的回調地址，當Axis2從服務器端收到響應時，就會通知這個回調對象。

至此，在引擎中實現對Web服務的異步調用的三個關鍵問題已經迎刃而解。下面給出BPEL4WS執行引擎WebJetFlow對Web服務異步調用的詳細設計。

2 WebJetFlow的異步調用機制分析

2.1 流程執行機制

高效的流程執行機制是提高引擎性能的關鍵，WebJetFlow是一個采用雙反饋控制環結構來保障服務請求的服務響應時間的BPEL4WS執行引擎[4]。對引擎內核的流程執行過程設計如圖1所示。

引擎內核主要由流程執行器和服務調用代理兩部分組成。在引擎內核中創建兩個獨立的線程池，即執行線程池和調用線程池，分別管理多線程模型中的執行線程和調用線程。引擎啟動的時候初始化四個JMS消息隊列:request和invoke隊列，分別用來緩存流程請求信息以及服務調用信息;response和result隊列，分別用來緩存服務調用響應信息以及invoke活動結果信息。

每一個流程請求消息到達之后都會被放入request隊列進行緩存。由process scheduler調度該隊列，逐個提取流程請求信息并交由從執行器線程池取出的流程執行線程處理。執行線程根據請求消息中的partnerLink、portType、operation三元組在數據庫中查找是否已經存在與該消息匹配的流程實例。如果沒有與該消息匹配的流程實例，將根據部署的服務組合流程信息創建一個實例并啟動該實例，然后處理BPEL4WS流程中的所有內部數據流和控制流。

當流程實例執行到一個invoke活動時，將服務調用信息發送到服務調用代理中的invoke隊列，并對該流程實例進行狀態持久化，然后該執行線程繼續去處理其他的請求信息;同時在服務調用代理中，由invoke scheduler調度invoke隊列，逐個提取invoke信息并交由服務調用線程處理。服務調用線程將invoke信息包裝成OMElement格式之后，通過Non-Blocking API執行真正的Web服務異步調用，引擎端異步調用Web服務代碼如下(以能實現最大程度的異步執行的非阻塞雙傳輸模式為例):

// 解析invoke信息并包裝成OMElement格式

OMElement invoke= parseInvoke();

ServiceClient serviceClient = new ServiceClient();

Options options = new Options();

// 綁定需要異步調用的Web服務地址

options.setTo(new EndpointReference (\"http://wjf.cslab211.com/SampleService\"));

// 通知Axis2使用雙通道傳輸

options.setUseSeparateListener(true);

serviceClient.setOptions(options);

// 創建AxisCallback回調對象callback用于接收異步響應的結果

AxisCallback callback = new MyCallback();

// 非阻塞異步調用，結果回調給callback

serviceClient.sendReceiveNonBlocking(payload， callback);

// 執行其他操作，無須阻塞等待響應結果

……

如果流程中有flow分支活動，服務調用代理從調用線程池中取出多個線程同時執行Web服務調用，從而有效實現分支活動的并發執行。

引擎對外發布了一個response receiver服務，是一個標準的Web服務，作為回調地址專門負責接收引擎發出的Web服務調用異步返回的結果;然后將返回結果放入response隊列，由invoke調度器調度該隊列，將返回結果和invoke消息實例匹配之后，得到流程實例ID，然后組裝成invoke活動結果信息，將其送入result隊列排隊，由流程調度器調度該隊列，根據invoke活動調用結果消息找到之前已經被持久化的流程實例，將其激活并按流程控制順序及數據依賴執行下一個活動。依此類推，直到整個組合服務流程執行完畢。

流程執行器控制BPEL4WS流程的執行，而服務調用代理負責處理流程引擎對Web服務的調用，這樣就解耦了流程的執行與對服務的調用，使得執行線程不需要等待調用結果而被釋放去執行其他的流程實例，提高了流程執行線程的利用率;同時通過Axis2的Non-Blocking API向服務提供者發送SOAP消息，異步調用具體的Web服務，使得服務調用線程不需要等待服務響應結果而被釋放去處理其他的invoke消息，提高了服務調用線程的利用率。

2.2 引擎消息格式設計

在異步調用過程中，客戶端與服務端之間要交互兩次而且處理周期的長短不確定，同時，在二次交互的過程中，客戶端和服務端都會不斷地接收或發出新的消息。因此，要實現異步調用，就要解決在不同的傳輸通道中，客戶端和服務端如何將返回結果與請求消息正確地關聯起來。引擎在發送Web服務請求消息時，必須攜帶能夠惟一標志該請求消息的相關集信息。當服務器處理完該請求后，就可以根據消息相關集來確定該將結果發給哪個請求者。

為此，定義一個二元組的消息相關集CS=〈messageID，timeStamp〉。其中:messageID為UUID格式的消息標志符;time-Stamp為消息發送的時間戳。UUID標志符的極低重復率使得messageID值與時間戳組合在一起可以保證惟一地標志一條消息。

WebJetFlow組合服務執行引擎是由消息驅動的，引擎內核組件之間通過共享四個消息隊列的信息來實現交互，因此必須規范定義系統中各種消息的結構。引擎中的消息全部采用標準的SOAP envelope格式，在header里面加入了表示消息相關集的messageID和timeStamp、流程標志符、流程實例標志符以及可以使引擎支持異步消息流以及跨多個傳輸協議發送消息的WS-Addressing規范中的元素，如〈messageID〉 〈replyTo〉和 〈relatesTo〉等。引擎消息header格式如下(為節省篇幅，命名空間的定義未列出):

〈soapenv:Header〉

〈wjf:ProcessName〉流程標志〈/ wjf:ProcessName〉

〈wjf:ProcessInstance〉流程實例標志〈/ wjf: ProcessInstance 〉

〈wjf:TimeStamp〉該消息發送時的時間戳〈/ wjf: TimeStamp 〉

〈wsa:Action〉指定處理該消息的操作〈/wsa: Action〉

〈wsa:MessageID〉該消息的UUID標志符〈/wsa:MessageID〉

〈wsa:ReplyTo〉〈wsa:Address〉響應消息接收地址〈/wsa:Address〉 〈/wsa:ReplyTo〉

〈wsa:RelatesTo〉源請求消息的UUID標志符〈/wsa:RelatesTo〉

〈/soapenv:Header〉

〈Action〉元素用來指定處理該消息的方法，包括服務地址、端口類型以及輸入/輸出操作名稱。

〈ReplyTo〉元素用來指明異步接收結果的地址，對于WebJetFlow引擎，可以將該元素設置為引擎對外發布的response receiver服務地址，同時這個地址代表的也是一個標準的Web服務，服務地址如下:

〈wsa:ReplyTo〉〈wsa:Address〉

http://wjf.cslab211.com/ResponseReceiver

〈/wsa:Address〉〈/wsa:ReplyTo〉

結果消息不需要設置〈ReplyTo〉元素，但必須設置〈Rela-tesTo〉元素，以便引擎可以根據〈RelatesTo〉元素中的相關集CS將返回結果與已經被緩存或持久化的請求作匹配。

在引擎內核中流動的消息主要有以下四種:

a)流程請求信息。客戶端通過browser或者以RPC方式發出的對引擎上所部署的組合服務流程的請求信息，信息中必須指明所要調用的動作。

b)服務調用信息。從執行器發送過來的被執行線程封裝好了的invoke請求消息。

c)服務調用響應信息。Web服務提供方返回的服務響應信息，等待與源服務調用信息的實例匹配。

d)Invoke活動結果信息。當服務調用響應信息與源服務調用信息的實例匹配找到該invoke活動所屬的流程實例標志之后，即形成本信息，它被壓入result隊列，等待流程調度器process scheduler的調度以用來激活流程實例繼續執行，其body部分格式和服務調用響應信息相同。

3 WebJetFlow的異步調用機制設計

3.1 利用cache技術提高異步響應結果的匹配效率

服務響應信息異步返回需要與之前已經被序列化的invoke實例匹配，invoke活動結果消息返回需要與之前已經被序列化的流程實例匹配。當外部服務響應時間較長時，可以將invoke實例和流程實例序列化到硬盤中，但是如果外部服務響應時間很短，很有可能將流程實例序列化到硬盤中及反序列化到內存中的時間比等待外部服務響應的時間還要長，這等于人為地延長了系統的整體響應時間。

為了進一步提高異步響應結果的匹配效率，參照CPU的cache技術原理，采用如下設計:

在執行器和調用代理中分別開辟一塊長度視系統實際內存大小而定的內存空間作為executor cache和proxy cache，考慮存取速度的因素，采用一維數組結構來實現，分別定義為cacheE和cacheP。在process executor中，流程實例Pi由于執行invoke活動而被序列化到硬盤中的同時，將其一個副本放入cacheE[i];在service invoker proxy中，invoke實例Ii由于需要等待外部服務響應而被序列化到數據庫中，同時將其一個副本放入cacheP[i]，以保證Pi和Ii在各自cache中的索引值是一致的。因為一個BPEL4WS流程可能會包含多個invoke活動，所以在Pi的生命周期中可能會對應多個Ii，但是在同一時刻，它們是一一對應的。

由于cache的大小不可能無限擴大，當cache中的數據已滿的時候，必須將當前等待緩存的Pi和Ii按照一定的算法將cache中的某一條實例替換掉。這里的cache替換算法的優劣將直接影響接下來的結果匹配效率。參考LFRU[8]算法，筆者設計了以下cache替換算法。

3.2 Cache替換算法

假設cacheE的大小為n，將cacheE中流程實例的訪問概率按升序排列，訪問概率符合Zipf法則[9]。根據Zipf法則，排序后第k個流程實例的訪問概率為Fk=Ckα，C=1∑ni=11iα。其中α>0。

雖然流程實例每次被命中之后都要從cacheE中刪除，但是一旦執行到該流程的下一個invoke活動的時候，該流程實例又會再次被放入cacheE中以等待invoke活動返回結果。因此，Pk有一個計數器Ck(記錄Pk進入cacheE的次數，每進入一次相當于訪問Pk一次，Ck的值越大說明Pk越受歡迎，訪問頻率越高，Ck≥1)，Pk還有兩個時間戳tfirst和tlast，分別記錄其第一次和最后一次進入cacheE的時刻，假設發生替換動作的時刻為t，所具有的優先權的值Wk=Ω-mΩ×Vk+mΩ×Vk。其中:m是執行替換操作的次數;Vk表示Pk上次被訪問的時刻距替換時刻的間隔Vk=t-tlast;Vk表示Pk被訪問的平均時間間隔Vk=t-tfirstCk;Ω是一個根據以往替換操作統計的經驗值所設立的一個相對較大的常數，所以Wk=Ω-mΩ×(t-tlast)+mΩ×t-tfirstCk。

每個流程實例都有一個權值W，執行替換操作時，首先計算cacheE中所有流程實例的W值，然后將W值最大的流程實例替換出cacheE。

a)在剛開始執行替換操作時，即當m→0時，Wk→Vk，即將上一次被訪問的時刻距替換時刻間隔值最大的實例替換出cacheE，此時算法等同于LRU算法。

b) 當替換操作的次數足夠多時，即當m→Ω時，Wk→Vk，即將歷次被訪問的平均時間間隔最大的實例替換出cacheE，平均被訪問的時間間隔越大說明被訪問的頻率越小，此時算法等同于LFU算法。

在替換次數0→Ω的過程中，算法從LRU逐步過渡到LFU，很好地模擬了LFRU算法。

以上是執行器緩存cacheE的替換算法。由于流程實例和invoke實例是一一對應的，而且在各自的cache中的索引值相同，若Pk在cacheE中將流程實例Pi替換掉，則在調用代理緩存cacheP中后續執行替換操作時，應該用invoke實例Ik替換掉Ii。

3.3 基于雙cache的異步響應結果匹配流程

當異步返回的結果信息需要與原來的實例匹配的時候，優先查找cache，找到相應的實例并與其組裝;如果沒有找到相應的實例就去數據庫中執行查找操作。由于所有的實例只需要匹配一次，對于cache的命中率要求較高，否則反而增加了額外的在cache中搜索的開銷。匹配成功以后，在cache中和數據庫中被匹配到的實例都要刪除。

Response receiver接收到服務調用響應信息之后，將其放入response隊列，然后由守護線程開始對結果進行匹配的流程。匹配策略如下:

a)若response隊列不為空，從response隊列中取出一條服務調用響應信息，根據其相關集CS在cacheP中查找被緩存的調用信息實例，否則轉入i)。

b)如果沒有在cacheP中命中到相應的調用信息實例，轉入c)，否則轉入d)。

c)根據相關集CS在數據庫中查找被持久化的調用信息實例，匹配成功轉d)，否則轉h)。

d)把被匹配到的調用信息中所包含的流程實例ID組裝到服務調用響應信息的header中形成invoke活動結果信息并放入result隊列，刪除數據庫中的該調用信息實例。如果在cacheP中命中，從數據庫中抽取下一個調用信息實例填補(并非替換)到cacheP中，轉入e)。

e)調度result隊列中的invoke活動結果信息，根據流程實例ID在cacheE中查找被緩存的流程實例。如果沒有在cacheE中命中到相應的流程實例，轉入f)，否則轉入g)。

f)根據流程實例ID在數據庫中查找被持久化的流程實例，匹配成功轉入g)，否則轉入h)。

g)將invoke活動結果信息body中的有效載荷傳遞給匹配到的流程實例，刪除數據庫中的該流程實例，如果在cacheE中命中，從數據庫中抽取下一個流程實例填補到cacheE中，轉入i)。

h)拋出異常，本次匹配失敗，轉入a)。

i)本次匹配成功，轉入a)。

為了縮短系統響應時間，響應結果與實例匹配組裝成功之后馬上將組裝結果回送，而對于cache填充以及數庫中的實例刪除等操作由專門的清掃線程sweeper來負責完成。

4 測試結果與分析

4.1 測試目的

對Web服務組合執行引擎WebJetFlow進行了改進，將非阻塞雙傳輸異步調用以及cache機制引入后，引擎的性能是否有了明顯的提高。

4.2 測試方案與步驟

a)使用Mercury公司的LoadRunner8.0同時產生大量的虛擬用戶來分別對引擎進行壓力測試，引擎通過接收外部消息來啟動已經部署的流程或繼續執行已經啟動的流程實例，當CPU利用率穩定在80%左右的時候，對比改進前后引擎的最大負載量變化情況。

b)使用LoadRunner模擬對引擎進行并發訪問，開始使用10個虛擬用戶進行并發，執行完畢之后再增加10個并發數。依此類推，直到并發數目達到100個，測試引擎在每個并發量檔次的響應時間和成功率。

c)通過LoadRunner生成等級為0、1和2的請求各100個，在初始時刻將各個等級的請求同時提交20個，然后每隔5 s將各個等級的請求同時追加提交20個。引擎線程池初始線程數設置為20個，線程池的內線程上限設為40個。各個等級的線程配額初始值分別為u0(t)=10，u1(t)=6，u2(t)=4;各個等級的用戶期望響應時間分別為R0=7 s，R1=12 s，R2=15 s。

4.3 測試結果

測試在兩臺PC機(奔騰 3.0 GHz處理器，1 GB內存，Nvidia7600顯卡)上完成，測試了引擎的最大負載量變化情況，如圖2所示。引擎對每個并發量檔次的響應時間，如圖3所示。引擎對每個并發量檔次的成功率，如圖4所示。

通過測試，得到以下結論:

a)當CPU利用率穩定在80%左右的時候，改進后引擎的最大負載量比改進前大約提高了13%，而滿載負荷(CPU占用率達到100%)大約提高了29%。

b)當虛擬用戶的并發數目依次增加達到100個的時候，改進后引擎在每個并發量檔次的響應時間和成功率分別比改進前都有了明顯的提高。改進前引擎的并發用戶達到70的時候就會出現響應異常的情況，改進之后的引擎對不超過100個的并發用戶可以正常響應。

以上性能對比測試表明，本文將非阻塞雙傳輸異步調用以及cache機制引入到WebJetFlow中，顯著地提高了引擎的吞吐量，增強了引擎應付高負載請求的能力;引擎在每個并發量檔次的響應時間和成功率分別都有了明顯的提高。

5 結束語

在Internet上，網絡流量和距離是導致基于Web服務的應用程序性能下降的主要原因之一，因此在遇到任何可能耗時較長的Web服務請求時，異步調用模式都是一個很好的方法。

本文討論了BPEL4WS引擎WebJetFlow的Web服務異步調用機制，在引擎的服務調用代理中，對Web服務的調用采用非阻塞雙傳輸異步調用，調用線程無須等待服務的響應，所有響應結果由統一的服務接口接收，調用線程可以繼續去處理其他的調用請求，提高了調用線程利用率。同時引入了cache機制并設計了相應的cache替換算法，保證了那些調用外部響應時間短的服務流程實例可以很快被從內存中取出并往下執行，而對于等待時間較長的流程實例將會被持久化到數據庫中，cache中的實例保證了引擎對異步調用結果消息的匹配效率，數據庫中的實例副本提供了數據安全性，即使掉電也不會丟失數據。

在以后的高負載實際測試環境中繼續完善該異步調用機制，是筆者下一步要做的工作。

參考文獻:

[1]IBM. BPEL4WS， business process execution language for Web ser-vices version 1.1[EB/OL].(2007-02-08) [2009-05-20]. http://ww-w-128.ibm.com/developerworks/library/specification/ws-bpel/.

[2]CARDOSO J， SHETH A， MILLER J， et al. Quality of service for workflows and Web service processes[J]. Journal of Web Semantics， 2004， 1(3):281-308.

[3]NORRIS J， COLEMAN K， FOX A， et al. OnCall: defeating spikes with a free-market application cluster[C]//Proc of the 1st International Conference on Autonomic Computing. Washington DC: IEEE Computer Society， 2004: 198-205.

[4]陳偉安，高春鳴. 一種基于反饋控制的Web服務組合執行引擎設計[J]. 計算機工程與應用， 2007，43(29):154-158.

[5]袁小娟，高春鳴. Web服務組合執行引擎中服務代理運行機制研究[J]. 計算機工程與應用， 2007， 43(28):103-106.

[6]The Axis2 Development Team. Apache Axis2 DOCS [DB/OL]. (2009-05-08)[2009-05-20]. http://ws.apache.org/axis2.

[7]BOSWORTH A， KALER C， FREY J， et al. Web services addressing (WS-Addressing)[EB/OL]. (2003-03-13)[2009-05-20]. http://ww-w.microsoft.com/taiwan/msdn/library/2003/Apr-2003/ws-addressin-ng.htm.

[8]劉志明，彭宇行. 集群VOD系統中磁盤cache替換算法研究[J]. 計算機工程， 2004， 30(7):139-140，180.

[9]RONALD R P， CHASE J S， GADDE S， et al.The trickle-down effect: Web caching and server request distribution[J]. Computer Communications， 2002， 25(4):345-356.