基于Web Service的大文件傳輸設計與實現(xiàn)

李文杰　高鵬翔

摘 要： 分析了目前一些主流的文件傳輸方法，包括文件傳輸?shù)南嚓P協(xié)議以及Web Service技術等。在綜合考慮用戶對于跨防火墻通信和大數(shù)據(jù)量文件傳輸?shù)确矫嫘枨蟮幕A上，采用了基于Web Service技術的解決方案來實現(xiàn)文件傳輸系統(tǒng)。結合運用其他如多線程等多種技術，來有效解決一些大文件傳輸時經常遇到的如超時、用戶體驗等問題。

關鍵詞： 大文件傳輸； Web Service； 跨防火墻通信； 超時； 多線程； 用戶體驗

中圖分類號：TP315 文獻標志碼：A 文章編號：1006-8228（2014）01-27-02

0 引言

文件傳輸技術在企業(yè)中得到了廣泛應用。但對于跨防火墻傳輸（如圖1所示）和文件傳輸超時等問題，目前還缺少相關研究。為此，本文在分析各種文件傳輸技術的基礎上，提出了一種基于Web Service技術實現(xiàn)文件傳輸?shù)姆椒ā?/p>

1 數(shù)據(jù)傳輸技術

自60年代末電子數(shù)據(jù)交換技術出現(xiàn)以來，已發(fā)展出多種數(shù)據(jù)傳輸方式，如：遠程拷貝技術，各種文件傳輸協(xié)議，以及使用軟件制造技術開發(fā)的數(shù)據(jù)傳輸系統(tǒng)等。下面對運用最廣泛的文件傳輸?shù)南嚓P協(xié)議和數(shù)據(jù)傳輸系統(tǒng)的開發(fā)技術進行分析和比較。

1.1 文件傳輸協(xié)議

文件傳輸協(xié)議主要包括FTP、TFTP，F(xiàn)TPS[1-3]等。這些協(xié)議實現(xiàn)了文件的上傳、下載和安全管理等功能，得到了廣泛應用。但是，在安全性要求較高的環(huán)境中，防火墻可能會封鎖上述協(xié)議所依賴的端口。如果服務器的有關端口被封閉，那么上述協(xié)議就難以找到可行的運用方案。因此文件傳輸協(xié)議不能滿足跨防火墻傳輸?shù)男枰?/p>

1.2 數(shù)據(jù)傳輸系統(tǒng)的發(fā)展

數(shù)據(jù)傳輸系統(tǒng)最初基于客戶機/服務器模式實現(xiàn)，到90年代發(fā)展出以CORBA等為代表的分布式計算技術。CORBA等技術雖然在局域網內部的同源環(huán)境中表現(xiàn)良好，但仍存在平臺耦合性高、缺少跨防火墻通信支持等問題，因而不適合跨網絡異源環(huán)境中的數(shù)據(jù)傳輸。為此，必須發(fā)展更為統(tǒng)一和開放的技術標準。在這一背景下，Web Service技術逐漸得到推廣[8]。

1.3 Web Service

Web Service基于XML，Http，SOAP，WSDL和UDDI[4-7]等標準。SOAP建立在XML與HTTP之上，能實現(xiàn)跨平臺的數(shù)據(jù)傳輸；WSDL與UDDI則為分布式環(huán)境中發(fā)布和查找服務提供了支持。此外，Web Service基于XML與Http，因而能實現(xiàn)跨防火墻的文件傳輸（Http協(xié)議使用的80端口必須開放，否則不能滿足基本聯(lián)網需求）。基于上述優(yōu)點，本系統(tǒng)選用Web Service技術進行開發(fā)。

2 文件傳輸系統(tǒng)的關鍵技術

根據(jù)用戶要求，系統(tǒng)必須滿足GB級別的大文件傳輸。針對大文件傳輸中常見的內存占用大和傳輸失敗率高的問題，已經有分塊傳輸和斷點續(xù)傳等解決方案[9]；但對于超時問題目前仍缺少標準的解決方案。超時原因主要包括網絡故障和服務器作業(yè)時間過長兩方面。網絡故障可通過網絡恢復后重傳解決；作業(yè)時間的問題則需要具體分析。作業(yè)時間可分為兩階段。

⑴ 準備階段：進行文件的壓縮與分割等。準備時間與數(shù)據(jù)量成正比，難以通過程序控制。

⑵ 傳輸階段：傳送分割得到的文件分塊。分塊大小可由程序指定，因此傳輸時間可控。

上傳時，客戶機是數(shù)據(jù)源。第⑴階段已在客戶端完成，客戶機發(fā)出的請求均處于第⑵階段，因此時間可控。非網絡故障的情況下不會發(fā)生超時。

下載時，服務器是數(shù)據(jù)源。收到客戶機發(fā)出的下載請求后，服務器處于第⑴階段，時間難以控制，大數(shù)據(jù)量時極易發(fā)生超時。因此，本文重點解決下載作業(yè)的超時問題。

2.1 解決下載作業(yè)超時問題

解決超時問題通常的思路是增加等待時間[10]，但這不能從根本上解決問題：首先，某些應用背景下能夠設置的等待時間有限；其次，即使允許無限等待，等待中的客戶機也不能獲得服務器的作業(yè)進度，畫面在下載開始后的較長時間里處于假死狀態(tài)，用戶可能會誤以為系統(tǒng)崩潰。為此，本文結合多線程技術提出了新的解決方案。具體如下。

⑴ 解決畫面假死問題。為此，需要在服務器處于準備階段時就獲得作業(yè)進度。首先在服務器端創(chuàng)建作業(yè)進度報告進程，用于獲取下載作業(yè)的進度，當收到客戶端請求時，該進程向客戶端返回當前作業(yè)進度；此外，客戶端也要指定負責向進度報告進程發(fā)出請求的線程。需要注意：該線程不能同時負責發(fā)起下載請求。因為客戶機線程發(fā)起下載請求后必須等待服務器準備作業(yè)完成或超時才能執(zhí)行下一步操作，所以等待期間無法向進度報告進程發(fā)出請求，從而無法及時獲得作業(yè)進度，不能真正解決畫面假死問題。因此，必須使用多線程技術：在客戶端建立兩個線程，分別負責發(fā)起下載請求和查詢作業(yè)進度。

⑵ 解決超時問題。發(fā)起下載請求的線程可能會發(fā)生超時。超時發(fā)生時不能簡單地中止下載，因為服務器可能仍在進行下載準備，并沒有失敗。所以本文采用如下方法：若發(fā)起下載請求的線程超時，客戶機程序繼續(xù)通過進度查詢線程獲得服務器的作業(yè)進度。若服務器最終成功完成準備作業(yè)，就進入文件分塊傳輸階段；若服務器準備作業(yè)最終失敗，就真正中止下載作業(yè)，報告錯誤。詳細流程如下。

① 下載準備階段

客戶機程序建立子線程用于發(fā)起下載請求；服務器收到請求后由下載進程啟動準備工作，作業(yè)進度報告進程則記錄準備作業(yè)的進度；子線程發(fā)起請求后，客戶機主線程按一定時間間隔不斷向服務器端進度報告進程發(fā)起輪詢請求以獲得最新的作業(yè)進度。因為發(fā)起下載請求的是子線程而非主線程，所以即使超時，也不會影響客戶機主線程與服務器下載進程，從而解決了因超時導致下載作業(yè)無法進行的問題。因為無論超時發(fā)生與否主線程都能正常運行，所以能夠不斷把獲得的下載作業(yè)進度反映到用戶界面上，從而解決了畫面假死問題（圖2）。

② 文件傳輸階段

服務器準備完畢后開始傳輸文件分塊。由于服務器下載進程傳送文件塊時可以附帶進度信息，并且客戶機也可以根據(jù)下載的文件塊數(shù)目計算進度，所以客戶機主線程不再需要依賴進度報告進程獲得進度信息，但仍需要把進度信息反映到用戶界面以改善用戶體驗（圖3）。

2.2 上傳作業(yè)中應用進度反饋機制

前面已經論述過上傳作業(yè)不用擔心超時的問題，但用戶體驗可以活用下載作業(yè)的方法予以改善：根據(jù)已上傳文件塊的數(shù)目計算進度并實時反映到用戶界面，改善用戶體驗。

3 結束語

實際運行中，本系統(tǒng)實現(xiàn)了跨網絡的數(shù)據(jù)傳輸。即使客戶機需要穿越防火墻連接另一網絡中的服務器，也能成功完成傳輸。此外，系統(tǒng)在數(shù)量級為GB的文件傳輸中同樣表現(xiàn)良好。特別是下載作業(yè)，服務器的準備時間通常在30分鐘以上，客戶機沒有因為長時間等待而失敗，并能夠在服務器準備期間通過請求不斷獲得準備作業(yè)的進度；在開始文件分塊的傳輸后，客戶機能夠繼續(xù)取得傳輸進度，使用戶得以不間斷地監(jiān)控整個傳輸過程，獲得良好的用戶體驗。可見，本文提出的解決方案在跨網絡、大數(shù)據(jù)量的文件傳輸作業(yè)中有著廣闊的應用前景。

但是，目前的方法仍存在有待解決的問題：①作業(yè)時間過長。目前必須等待客戶機（上傳作業(yè)）或服務器（下載作業(yè)）準備好所有文件分塊后才能開始傳輸。如果可以在生成第一個文件分塊之后就開始傳輸，就能大幅度縮短時間。但要做到這一點，還需要兼顧數(shù)據(jù)完整性等問題，這需要進一步研究。②取消操作的實現(xiàn)。在傳輸文件分塊的階段，要取消傳輸作業(yè)，只要通知服務器結束傳輸，清除已傳數(shù)據(jù)即可。但在下載作業(yè)的準備階段中，服務器可能忙于執(zhí)行讀取、壓縮等操作，即使收到用戶的取消請求也不能立即停止。如何使服務器在準備過程中能及時響應取消請求，也需要繼續(xù)研究和探討。

參考文獻：

[1] J. Postel， J. Reynolds. FILE TRANSFER PROTOCOL （FTP）[S].

RFC 959， October 1985. http：//tools.ietf.org/html/rfc959.

[2] G. Malkin， A. Harkin. TFTP Option Extension[S]. RFC 2347， May

1998. http：//tools.ietf.org/html/rfc2347.

[3] T. Dierks， E. Rescorla. The Transport Layer Security （TLS）

Protocol[S]. RFC 5246， August 2008.http：//tools.ietf.org/html/rfc5246.

[4] Tim Bray， Jean Paoli， C. M. Sperberg-McQueen， Eve Maler，

Fran?ois Yergeau. Extensible Markup Language （XML） 1.0 （Fifth Edition）[S]. W3C Recommendation，26 November 2008. http：//www.w3.org/TR/REC-xml/.

[5] Martin Gudgin， Marc Hadley， Noah Mendelsohn， Jean-Jacques

Moreau， Henrik Frystyk Nielsen， Anish Karmarkar， Yves Lafon. SOAP Version 1.2[S]. W3C Recommendation， 27 April 2007. http：//www.w3.org/TR/soap12-part1/.

[6] Erik Christensen， Francisco Curbera， Greg Meredith， Sanjiva

Weerawarana. Web Services Description Language （WSDL） 1.1[S]. W3C Note， 15 March 2001. http：//www.w3.org/TR/wsdl.

[7] Peter Brittenham， Francisco Cubera， Dave Ehnebuske， Steve

Graham. Understanding WSDL in a UDDI registry， Part 1[OL]. IBM developerWorks， 01 Sep 2001. http：//www.ibm.com/developerworks/library/ws-wsdl/.

[8] Ramesh Nagappan，Robert Skoczylas，Rima Patel Sriganesh 著，龐

大剛，陶程譯.Java Web服務開發(fā)[M].清華大學出版社，2004.

[9] 黎苑文，程明智，徐秀花，楊義先.斷點續(xù)傳及多線程機制在遠程傳版

中的應用研究[J].北京印刷學院學報，2012.20（6）：53-56

[10] Apache Software Foundation. Timeout Configuration[EB/OL].

April 2012.http：//axis.apache.org/axis2/java/core/docs/http-

transport.html.