鄭學偉

遼寧廣播電視大學(沈陽 10034)

隨著信息技術(shù)日益融進我們的工作生活中，各種企業(yè)商業(yè)信息服務應用平臺在社會發(fā)展中起著越來越重要的作用，各個企業(yè)的信息系統(tǒng)在選擇開發(fā)平臺、通訊協(xié)議和開發(fā)語言方面都有其自己的方式，“信息孤島” 的情況日益嚴重，大量的信息數(shù)據(jù)冗余出現(xiàn)，隨著網(wǎng)絡信息交換的日益頻繁，越來越多的企業(yè)希望自己的系統(tǒng)具有很強的兼容能力，能夠?qū)崿F(xiàn)跨平臺、跨語言，從而是不同系統(tǒng)間的數(shù)據(jù)交換更加高效方便。

Web Service是基于網(wǎng)絡的、分布式的模塊化組件，是一種基于Web的中間件技術(shù)。提供給外界一個接口，不同的客戶可以通過編程的方式來調(diào)用它提供的服務，被外界日益廣泛接受，越來越多的運用在各種服務程序間的數(shù)據(jù)通信中。Web Service的主要核心技術(shù)是XML、SOAP和WSDL。SOAP協(xié)議是訪問 Web Service最常用的協(xié)議。數(shù)據(jù)格式基于XML文檔，具備互操作行格式，各個基于不同平臺的服務程序可以在彼此不是同一數(shù)據(jù)標準的情況下進行無縫的數(shù)據(jù)交換。但是也正是由于SOAP具有這一特性導致SOAP的數(shù)據(jù)交換效率較為低下。SOAP消息的格式是基于XML，SOAP在進行數(shù)據(jù)通信時必須先對傳送數(shù)據(jù)進行格式化。即將所有數(shù)據(jù)格式轉(zhuǎn)換為XML數(shù)據(jù)，而XML格式的有點是數(shù)據(jù)可操作性，而缺點則是占用數(shù)據(jù)交換空間大。同樣，在進行SOAP數(shù)據(jù)交換時，接收端在接收XML消息后必須將接收到的數(shù)據(jù)進行反操作。SOAP消息交換程序直接降低了Web Service的工作效率。因此，提高Web Service性能的關鍵就在于提高對數(shù)據(jù)進行XML格式化和反操作的速度。

1 Web服務性能指標

Web Service性能主要有兩項：一是Web Service運行環(huán)境實現(xiàn)服務調(diào)用功能的能力；二是其執(zhí)行功能的能力的度量。響應時間要求越短越好，吞吐量則要求在相同響應時間內(nèi)越好。響應時間是指在發(fā)送端將消息發(fā)出后接收到接收端的回復這一周期。影響響應時間的因素很多，包括網(wǎng)絡延遲時間(通訊網(wǎng)上的傳播時延和接口的傳輸延遲)，以及服務端(服務執(zhí)行)和中間節(jié)點(集線器、路由器和調(diào)制解調(diào)器的開關時間)的處理延遲。延遲的長時間處理是影響響應時間的關鍵因素，也是最難解決的地方。吞吐量是指每個時間單位執(zhí)行處理的請求數(shù)(例如：每秒的 I/O操作數(shù))，它通常是在服務器端進行評估。有很多吞吐量的測量因素是以工作單位的定義而定，通常的因素有：點對點的吞吐量(傳輸性能的量化)、節(jié)點吞吐量(處理性能的量化)和系統(tǒng)整體的吞吐量(又名系統(tǒng)的一致吞吐量)。系統(tǒng)整體的吞吐量受到傳輸和處理鏈中局部吞吐量這些小的執(zhí)行元件的限制。

2 Web服務消息處理優(yōu)化研究

SOAP協(xié)議只定義了數(shù)據(jù)格式的基本，而不是精確地綁定。也就是說SOAP協(xié)議的框架規(guī)范在具體操作時極富于靈活性。對于任何數(shù)據(jù)的路由、防火墻的通道以及數(shù)據(jù)的可靠傳輸SOAP都沒有進行硬性的規(guī)定。SOAP協(xié)議中數(shù)據(jù)的定義的本質(zhì)上就是一條以XML形式的文檔。一條SOAP消息就是一個普通的XML文檔，在數(shù)據(jù)傳送過程中相同數(shù)據(jù)的重復調(diào)用大量的發(fā)生在SOAP傳輸過程中，可以利用這一特點，將大量的重復調(diào)用數(shù)據(jù)通過一種機制嵌入SOAP通信過程中。在SOAP通信過程中，客戶端發(fā)送SOAP請求時，可以預設一個信息模板，在客戶端將數(shù)據(jù)發(fā)送出去后，模板并不清空，而是完整的保留下來，將數(shù)據(jù)進行XML格式化的結(jié)果保存在模板中，客戶端在進行數(shù)據(jù)發(fā)送時，可以將待發(fā)送的數(shù)據(jù)同模板進行比較，如果再一次通信時處理的數(shù)據(jù)同前一次數(shù)據(jù)相同或者結(jié)構(gòu)相同時，可以直接將信息模板進行套用，不需要對待處理的數(shù)據(jù)進行完整的處理，要實現(xiàn)上訴的功能需要進行以下幾方面處理：將已經(jīng)發(fā)生過的數(shù)據(jù)進行抽取，進行數(shù)據(jù)命名后進行標注，針對不同的服務方式進行不同的模板，在后續(xù)構(gòu)建XML時在調(diào)用標注時套取模板，避免了發(fā)送類似 SOAP消息時重新進行序列化操作的開銷。模板建立好以后，客戶端再進行數(shù)據(jù)發(fā)送時，對于下面要發(fā)送的數(shù)據(jù)，在進行數(shù)據(jù)序列化之前，首先要在數(shù)據(jù)存儲表中進行迭代查找。查找到相同的標注名之后，在對模板中的方法名進行進一步的查找，如果有目標方法，則直接套用模板進行數(shù)據(jù)的序列化，如果沒有，則對新的數(shù)據(jù)格式進行序列化，再講序列化的方法以新的標注存儲進模板中。每一次遇見新的數(shù)據(jù)格式，都要將數(shù)據(jù)格式以模板的形式存儲進數(shù)據(jù)序列中，存儲空間滿時，為防止數(shù)據(jù)溢出導致信息傳輸崩潰，根據(jù)“最近最久未使用(LRU)”方法，將一段時間內(nèi)最少使用的模板刪除掉，系統(tǒng)需要根據(jù)LRU將系統(tǒng)的數(shù)據(jù)調(diào)用頻率進行排序，這樣可以保證模板的使用效率，當需要刪除很少使用的模板是，可以將數(shù)據(jù)鏈表中模板進行排序，尾部為最少使用的，首部始終為上一次使用或剛剛建立好的。

數(shù)據(jù)信息的發(fā)送方通過模板的使用減少了數(shù)據(jù)操作時間后，如果信息的數(shù)據(jù)接收方?jīng)]有同樣進行反序列化操作，則對于數(shù)據(jù)的整體性能提升意義不大。SOAP中數(shù)據(jù)通信的反序列化操作以如下方式進行，在反序列化階段也可以使用基于模板的方式來提升性能。該方法的大致描述如，反序列化數(shù)據(jù)的模板，模板是通過預先定義好的 SOAP消息的 XML Schema獲得的，并為每個服務程序制定模板。

模板是由不變的標簽部分和變化的數(shù)據(jù)序列化方法組成。tSoap處理器提取接收到SOAP請求消息中第一個標簽塊的內(nèi)容和模板是相同的。tSoap處理器從請求消息中提取變化的部分后將提取下一個標簽塊。當 SOAP消息中有多個標簽時，則需要對待反序列化的數(shù)據(jù)進行重復操作，一直到套用到合適的模板為止。如果 SOAP消息中只有一個標簽時，到這步就結(jié)束了。然后tSoap處理器反復執(zhí)行前邊操作，直到SOAP請求消息的結(jié)束部分。驗證是通過比較請求消息和模板的標簽塊的字符串。驗證成功，則說明兩個字符串匹配。另一方面，如果兩個字符串不匹配，也就是驗證失敗，則模板不可用。tSoap處理器提取 SOAP消息的結(jié)構(gòu)和模板進行比較，另外，由于驗證是通過把每個標簽塊的字符串和模板的標簽塊進行比較，因此，和現(xiàn)有驗證每個標簽的方法比較，tSoap方法可以有比較好的性能改進?？梢杂矛F(xiàn)有的 SOAP處理器進行服務程序的驗證，因此，tSoap方法減少了構(gòu)建系統(tǒng)的成本。

Web Service性能測試主要從響應時間和吞吐量兩個方面進行測評，這種方案在這兩個方面能夠改善SOAP消息處理的性能，進而對整個Web Service的服務質(zhì)量得到了一定的提高?；谀０宓姆椒ㄔ谕掏铝糠矫媸瞧渌椒ǖ?.5倍?；谀０宓姆椒ㄔ谕掏铝糠矫嫱瑯痈潜绕渌椒ㄐЧ?。當消息的容量大小逐漸遞增時，基于模板的方法和其他方法的吞吐量曲線都逐步的減小，但比其他方法每秒處理的事務數(shù)要多出幾倍。

3 結(jié)語

隨著信息技術(shù)的飛速發(fā)展，Web服務以其特有的跨平臺、快語言的便利特性正在得到越來越廣泛的應用，而應用的要求也越來越高，各個服務系統(tǒng)SOAP的應用已經(jīng)不僅僅滿足于其原有的特性，正在要求其具備更快的反應速度與信息處理能力，因此如何提高基于SOAP的Web Service信息通信能力是目前數(shù)據(jù)通信研究的熱點所在，基于模板的序列化與反序列化SOAP數(shù)據(jù)處理模式對于Web Service服務效率的提升有著非常明顯的改善。

[1]柴曉路,梁宇奇.Web Servicess技術(shù)、架構(gòu)、和應用[M].北京:北京電子工業(yè)出版社,2003.

[2]余曉峰.SOAP安全性模型的設計與實現(xiàn)[D].杭州:浙江大學,2003.