摘  要： 提出一個應用于移動網絡的Web服務交互通信體系架構,，其將基于XML的系統(tǒng)通信的負擔從移動客戶轉移到外部中間件上,，該中間件像網關一樣,，使用快速的二進制協(xié)議以客戶/服務器方式與移動設備進行輕量級通信,，并同時負責解析對Web服務的請求,。
關鍵詞： Web服務,；面向服務的體系結構；移動計算,；移動設備

　面向服務的體系結構（SOA）技術包含了一個靈活的應用組件集合,，這些組件相互獨立并可以互操作,，公開訪問接口,，提供特定功能服務,，更好地滿足了大企業(yè)系統(tǒng)的業(yè)務需求。由于基于SOA構建的系統(tǒng)能更靈活地隨業(yè)務需求而變化,，有效解決了傳統(tǒng)大規(guī)模系統(tǒng)中任何子系統(tǒng)的細微需求變化及系統(tǒng)反應極度敏感的問題,。
　將SOA方法引入到Web，產生了Web服務技術,。該技術通過Web為運行在不同平臺上的應用之間提供了互操作和信息交換,。由于建立在XML和HTTP標準協(xié)議上，因此Web服務容易開發(fā)并通過Web在任何地方訪問,。
　Web服務技術優(yōu)勢明顯，引領企業(yè)業(yè)務主導權,，具有高度互操作性,、服務組件可發(fā)布性及易集成等特點。它也存在不足,，即Web服務用戶面對通信性能弱,、需處理基于XML的額外負擔。近年來,，移動應用開發(fā)領域已出現過量的可用Web服務,，雖然移動設備硬件能力已大大增強，但由于性能問題和移動平臺缺乏本地化開發(fā)支持,，易使用的Web服務卻漸漸偏離大多數移動平臺標準特征,。
1 Web服務概述
　Web服務主要使用HTTP和XML技術，為不同硬件及平臺上的應用系統(tǒng)提供標準方式的交互操作,，它像自包含的部件,，可以在Web上發(fā)布、定位和調用,，為應用在Web上提供一個獨立于硬件平臺和操作系統(tǒng)的標準通信機制,。
　由W3組織提出的Web服務構架，依據一些Web標準，如XML,、SOAP,、WSDL和UDDI，允許服務可以被任何應用描述,、查找和集成,。Web服務的實現分成SOAP Web服務和REST Web服務兩類?；赟OAP的Web服務適合在復雜的多層計算環(huán)境中實現SOA,，具有更大的靈活性和較低的集成成本，但在與輕量級信息系統(tǒng)通信時比REST Web服務要求更大的性能,。
　基于SOAP的Web服務主要有額外處理XML的性能問題和通信中缺乏事務支持兩種不足,。在繁忙和不穩(wěn)定的網絡上，相對于傳統(tǒng)方法的分布式計算（如CORBA或DCOM）,，與Web服務通信必須忍受低性能,，這是因為基于XML的信息系統(tǒng)追求簡單而不是效率。而且,，當對XML請求/響應編碼/解碼的額外負擔時,，肯定影響整個Web應用的性能。與Web服務通信中缺乏事務支持,，致使這種數據交換協(xié)議沒有狀態(tài),，正如Web服務提供者和Web服務用戶彼此不知相互狀態(tài)。
　當今移動設備中無線網接入已成為其標準特征,，移動Web服務應用的挑戰(zhàn)可歸結為兩點：移動硬件的能力（包括處理能力和網絡能力）和對移動平臺的本地化支持,。另外，對資源約束限制的移動設備應考慮采用已有的標準,。
2 移動設備及平臺現狀
2.1 移動設備及其局限性
　移動設備的能力不斷增長,，并滿足移動性和連接性等靈活性上的相關需求。未來幾年內,，蜂窩式無線通信網絡的數據流量有望保持幾十倍增長,，數據流量通常來自Web瀏覽，尤其是觀看視頻,。
　現在的智能手機具有最新式的硬件特征,，從移動性的角度講，智能手機是市場上最吸引人的移動設備,。智能手機的計算能力有顯著的提高,，如快速的處理器、更大容量的ROM和RAM,，它的發(fā)展趨勢是增強的無線網絡通信能力和高度聯(lián)接性等,。移動設備的主要硬件限制且必須解決的是巨大的電池消耗問題,，它導致了電池壽命縮短、無線網絡帶寬低和無線連接不穩(wěn)定等問題,。只要有電池自主性,，就可以達到相當好的移動性和連接性，穩(wěn)定地與無線接入點連接,，很少或沒有延遲地使用Web服務,。
2.2 移動平臺的支持
　為在移動平臺上開發(fā)Web服務客戶程序，現討論它們提供的現有支持,。
Sun公司將Java技術用于移動設備,，用標準模板訪問現有的Web服務，通過擴展J2ME平臺帶有的JSR 172[1],，被命名為J2ME WSS（Web Services Specification）的請求,，使J2ME轉成為標準的Java Web服務平臺，這些讓開發(fā)者容易創(chuàng)建客戶程序,，用于支持Java的移動設備,。WSS是移動服務架構平臺的一部分，設計它面向移動設備的新技術和服務,，為所有支持Java的移動設備提供標準應用環(huán)境,，用于滿足市場發(fā)展。
　在支持Web服務應用方面,，Apple公司在移動iPhone平臺上幾乎沒做努力,。SDK沒公開其內置的C對象庫，無法創(chuàng)建簡單的Web服務客戶程序,。而且,，當實現必需的基于XML的消息機制時，很少用到Cocoa構架的NSXML庫,。當需解析XML時，libxml2或KissXML庫肯定優(yōu)先使用,。iPhone平臺的工作區(qū)包括現有的應用功能程序的使用,，如wsdl2objc[2]，它派生出代理類,，以訪問源自WSDL規(guī)格的服務,。派生類包含Web服務公開的所有方法。不過,，開源社區(qū)作了明顯的努力,，用于創(chuàng)建易于使用的框架，以訪問Web服務,。
事實也證明,，Google公司沒使SOAP Web服務應用對Android平臺開發(fā)者社區(qū)是一個容易的任務。SDK甚至沒打包成工具包為Web服務接口產生派生類。在開發(fā)社區(qū)中,，Android平臺被認為是最適合在移動空間中作為Google服務的發(fā)布者,。
　在Windows Mobile平臺上應用Web服務是容易的工作，因為.NET框架適合同步和異步訪問,。與Windows Phone 7平臺類似,，通過簡單引用Web服務生成服務接口開放的代理類。
Nokia從Symbian系列60平臺提供Serene框架,，容易創(chuàng)建訪問Web服務的客戶程序應用,。該框架依賴J2ME JSR 172規(guī)格，提供創(chuàng)建相關豐富Web應用的全部支持,。
　除了Windows和Nokia平臺提供支持,，允許開發(fā)人員專注于設計和創(chuàng)造，其他平臺缺少本地化支持,，開發(fā)SOAP Web服務客戶程序要求更多的額外努力,。而且要在所有移動平臺上實現Web應用既麻煩又耗費資源，特定的平臺需要特定的工作環(huán)境,。
3 相關工作介紹
　目前,，開源社區(qū)提出的兩類解決辦法是解決問題的基礎，據此進行簡單改編,，針對基于SOAP的Web服務的局限性,，為大多數移動平臺能應用。
3.1 支持RESTFul架構
　參考文獻[3]提出的Web服務架構通過修改現有的SOAP Web服務解決通常SOAP消息系統(tǒng)的兩個資源耗費問題,，即由于密集的SOAP請求封裝機制帶來HTTP通信負擔,、移動設備端SOAP響應的解析，以適應移動設備的低資源特點,。參考文獻[4]的方法依據的是RESTful架構,，也因SOAP協(xié)議的傳輸中立性而帶來一系列的問題。通過為每類交互活動明確地分配另一個截然不同的URL,，現有的SOAP接口甚至優(yōu)化在RESTful架構中,。對同步和異步RESTful實現都進行了性能測試，結果很樂觀,，隨著HTTP負載的減輕,，從同步調用高達96%負載，減至異步調用的75%,。
3.2 使用移動Web服務代理

　另一解決辦法是在移動網絡中引入Web服務代理,，它像移動設備和Web服務之間的網關一樣[5]。代理從移動設備接收輸入參數,，調用請求的服務,，并向移動設備返回結果,。結果令人滿意，因為消除了移動設備端的XML處理,，獲得了改進性能,。性能測試顯示，響應時間很少且數據負荷低,。
　目前,，研究領域存在以上兩種辦法的主要原因是有個通用理念，即移動設備上任何可行的通信架構必須包括中間件,，它存在于設備之外,，負責與Web服務通信且必須處理XML的重擔。那些中間件像網關服務器一樣工作,，與移動設備輕量級通信,，并承擔檢索來自Web服務的響應。這種類型架構對確保與Web服務更可靠的通信會有更大的機會,。無線通信是移動設備上易于波動的行為,，會造成無線訪問出錯。網關將最大可能地運行在專用硬件上,，將證明確保去查找一些與Web服務的通信狀態(tài),。連接錯誤時，會啟用重試機制,。
4 基于中間件的Web服務應用構架
　在提出的通信架構中引入中間件,，它像SOAP和瘦客戶之間的網關，而瘦客戶剝離了處理XML的重擔,。網關是移動客戶的服務器,，承擔著移動客戶請求響應的任務。通用的通信系統(tǒng)架構如圖1所示,，移動客戶將必須使用二進制協(xié)議維持與網關的輕量級C/S通信,。當然，任何比SOAP協(xié)議更輕量級的協(xié)議都可以使用（如REST）,，但眾所周知二進制協(xié)議大致與SOAP協(xié)議功能相當,。二進制協(xié)議簡單，不如XML或SOAP標準,，但它們能提供同樣層次的擴展性和低通信腳本上的安全性。而且,，從開發(fā)者支持的角度,，成功的協(xié)議會為所有重要的編程語言和開發(fā)平臺提供客戶端口。

　該架構的優(yōu)點如下：
?。?）移動客戶必須維持輕量級通信,，即較小帶寬和較低處理能力要求,。
　（2）可以開發(fā)出高級的安全措施,，因為網關中間件將代表移動客戶工作,。
　（3）為防止任何通信錯誤（移動設備到網關或網關到Web服務）,，存儲一些狀態(tài)用于保證透明地與移動客戶通信,，網關保持全部的通信狀態(tài)，當斷線后的所有方重回線上時,，繼續(xù)重試通信連接,。
　（4）從實現架構的角度看,，容易設計出軟件工具,，幾乎自動地從WSDL文檔開始，創(chuàng)建完全網關和移動客戶部件,；系統(tǒng)架構容易生成和測試,，優(yōu)于任何的現有實現。
唯一不足的是這種構架可能增加總的請求應答時間,。系統(tǒng)或許贏得些時間,，如果網關上執(zhí)行的XML處理量巨大，但是這并不準確,，因為兩通信線路必須建立并維護,，因此這早于任何實際實現的測量，該方向上沒有明確的結論,。
　使用大量Web服務的Web應用實現是接下來應用領域里的工作,。移動應用市場正尋找解決授權移動設備與Web服務集成的辦法，并盡可能降低當前的性能問題,。Web服務的研究者[5]證明并不存在實際的工作區(qū),，將嘗試通過更快的XML解析器、全面協(xié)議優(yōu)化和數據壓縮等來消費Web服務,，提高移動客戶的性能,。參考文獻[3]、[5]的研究者證實了設計通信架構的努力,，包括存在于外部設備的中間件部件,，負責與Web服務通信時的XML處理。
　下一步工作包括創(chuàng)建一個更加詳細的原型,，支持在主流移動平臺上的Web應用現存的開發(fā),，主要是為實現新的Windows Phone 8平臺而提出的架構。該平臺確定容易創(chuàng)建Web服務的客戶應用,，相比之下,，基于網關的體系架構的性能試驗還不如它重要,。在基于網關的構架實現中，主要將對Windows Phone客戶程序的封裝帶寬進行測量,，并與容易創(chuàng)建的.NET Framework下的SOAP Web服務客戶程序的數據結果進行比較,，兩個方案的系統(tǒng)性能和可靠性也將進行測試和對比。
參考文獻
[1] JSR 172： J2METM Web services specification[EB/OL].http：//jcp.org/en/jsr/detail?id=172,， 2012-01-20.
[2] wsdl2objc library homepage[EB/OL]. http：//code.google.com/p/wsdl2objc/,，2012-01-20.
[3] AIJAZ F， ZAHID S A,， CHAUDHARY M,， et al. Enabling high performance mobile Web services provisioning[C].Vehicular Technology Conference Fall（VTC 2009-Fall），2009：1-6.
[4] 劉振海,，姜利群,，殷兆麟，等.移動Web服務的研究與應用[J].計算機工程與設計,，2009,，30（11）：2711-2713.
[5] ADA?觭AL M， BENER A B. Mobile Web services： a new agent-based framework[J]. Internet Computing,， 2006,，10（3）：58-65.