淺析Comet技術(shù)在Java Web實(shí)時(shí)系統(tǒng)開發(fā)中的應(yīng)用

淺析Comet技術(shù)在JavaWeb實(shí)時(shí)系統(tǒng)開發(fā)中的應(yīng)用

摘要:Comet技術(shù)通過實(shí)現(xiàn)服務(wù)器推(serverpush)來解決AJAX需要定時(shí)頻繁發(fā)送請求的問題，從而給Web實(shí)時(shí)系統(tǒng)帶來了全新的交互性。本文分析了Comet技術(shù)的兩種實(shí)現(xiàn)方式:長輪詢方式(long-polling)和流方式(streaming)，并通過一個(gè)服務(wù)器推送隨即數(shù)的實(shí)例，展示了使用Comet技術(shù)開發(fā)JavaWeb實(shí)時(shí)系統(tǒng)的開發(fā)方法和步驟。

關(guān)鍵詞:Comet;AJAX;服務(wù)器推送;Web實(shí)時(shí)系統(tǒng)

HTTP協(xié)議是互聯(lián)網(wǎng)上大量信息交換的基礎(chǔ)，其特點(diǎn)是，它是基于請求—響應(yīng)模式的無狀態(tài)的單向協(xié)議，即必須由客戶端發(fā)起一個(gè)請求建立連接，服務(wù)器接收請求，把數(shù)據(jù)返回給客戶端，然后釋放連接。下一次，再由客戶端發(fā)起另一次請求，重復(fù)上述過程。服務(wù)器始終處于“被動”地位。

HTTP協(xié)議這一特點(diǎn)，既成就了它的成功，也導(dǎo)致了它的局限性。服務(wù)器處理請求的經(jīng)典模式是一個(gè)線程處理一個(gè)連接，結(jié)束之后，關(guān)閉該連接，釋放線程以服務(wù)于其他請求。只要響應(yīng)速度足夠快，那么我們可以以相對較少的服務(wù)器為數(shù)量龐大的用戶提供服務(wù)。這非常適合于傳統(tǒng)的Web應(yīng)用，比如:搜索引擎、內(nèi)容管理系統(tǒng)和電子商務(wù)網(wǎng)站等。然而，這種方式并不能滿足有實(shí)時(shí)性要求的應(yīng)用的需求，很多應(yīng)用都需要服務(wù)器能實(shí)時(shí)地將更新的信息傳送到客戶端，而無須客戶端發(fā)出請求。例如，新聞標(biāo)題、證券報(bào)價(jià)和拍賣行情等。

在Web的早期，人們通過在HTML頭部加入META元信息來實(shí)現(xiàn)HTML自動刷新。該標(biāo)記指示瀏覽器每隔一定的時(shí)間間隔刷新一次頁面。這不僅帶來糟糕的用戶體驗(yàn)，而且是一種低效的做事方式。因?yàn)槿绻麤]有新的數(shù)據(jù)，該頁面就沒必要刷新;如果頁面只存在小范圍內(nèi)的變化，該頁面就沒有必要全部刷新。

AJAX(AsynchronousJavaScriptandXML，異步JavaScript和XML)的出現(xiàn)改變了上述情況。Ajax的工作原理相當(dāng)于在客戶和服務(wù)器之間加了—個(gè)中間層，使客戶請求與服務(wù)器響應(yīng)異步化。并不是所有的請求都提交給服務(wù)器，像—些數(shù)據(jù)驗(yàn)證和數(shù)據(jù)處理等都交給AJAX引擎自己來做，只有確定需要從服務(wù)器讀取新數(shù)據(jù)時(shí)再由AJAX引擎代為向服務(wù)器提交請求。使用Ajax的最大優(yōu)點(diǎn)就是能在不刷新整個(gè)頁面的前提下維護(hù)數(shù)據(jù)，使得Web應(yīng)用程序更為迅捷地響應(yīng)用戶交互，并避免了在網(wǎng)絡(luò)上發(fā)送那些沒有改變的信息。然而，AJAX仍然受限于Web請求/響應(yīng)模式的弱點(diǎn)，使得服務(wù)器不能推送實(shí)時(shí)動態(tài)的Web數(shù)據(jù)。

1Comet技術(shù)實(shí)現(xiàn)方式[1]

Comet技術(shù)被稱為反AJAX(ReverseAJAX)技術(shù)，它通過實(shí)現(xiàn)服務(wù)器推(serverpush)來解決AJAX需要定時(shí)頻繁發(fā)送請求的問題。通過Comet，客戶端所需要的響應(yīng)信息不再需要主動地去索取，而是在服務(wù)器端以事件(Event)的形式推至客戶端。

Comet技術(shù)的實(shí)現(xiàn)方式有兩種:長輪詢方式(long-polling)和流方式(streaming)。

長輪詢:HTTP的連接保持，服務(wù)器端會阻塞請求，直到服務(wù)器端有一個(gè)事件觸發(fā)或者到達(dá)超時(shí)?？蛻舳嗽谑盏巾憫?yīng)后再次發(fā)出請求，重新建立連接。通過這種方式，服務(wù)器可以在數(shù)據(jù)可用的任何時(shí)候?qū)?shù)據(jù)“推”到客戶端。因?yàn)檫@種方案基于AJAX，請求異步發(fā)出，無須安裝插件，IE、MozillaFireFox都支持。

流方式:在流方式中，服務(wù)器推數(shù)據(jù)返回客戶端，但不關(guān)閉連接，連接始終保持，直到超時(shí)，超時(shí)后通知客戶端重新建立連接，并關(guān)閉原來的連接。

在長輪詢方式下，客戶端是在XMLHttpRequest的readystate為4(即數(shù)據(jù)傳輸結(jié)束)時(shí)調(diào)用回調(diào)函數(shù)，進(jìn)行信息處理。當(dāng)readystate為4時(shí)，數(shù)據(jù)傳輸結(jié)束，連接已經(jīng)關(guān)閉。MozillaFirefox提供了對流方式的支持，即readystate為3時(shí)(數(shù)據(jù)仍在傳輸中)，客戶端可以讀取數(shù)據(jù)，從而無須關(guān)閉連接，就能讀取處理服務(wù)器端返回的信息。IE在readystate為3時(shí)，不能讀取服務(wù)器返回的數(shù)據(jù)，目前IE不支持流方式。

不管是長輪詢還是流，請求都需要在服務(wù)器上存在一段較長時(shí)間，因此Comet被稱為“基于HTTP長連接的服務(wù)器推技術(shù)”。這打破了每個(gè)請求一個(gè)線程的模型。這個(gè)模型顯然對Comet不適用。Java對此提出了非阻塞IO(non-blockingIO)解決方案，Java通過它的NIO庫提供非阻塞IO處理Comet。

傳統(tǒng)的阻塞式IO，每個(gè)連接必須要開一個(gè)線程來處理，您始終從一個(gè)線程中讀取流直到整個(gè)流完成，然后關(guān)閉連接。因此阻塞式IO對大量并發(fā)的短生命周期連接不會造成問題。而非阻塞IO處理連接是異步的。當(dāng)某個(gè)連接發(fā)送請求到服務(wù)器，服務(wù)器把這個(gè)連接請求當(dāng)作一個(gè)請求“事件”，并把這個(gè)“事件”分配給相應(yīng)的函數(shù)處理。我們把這個(gè)處理函數(shù)放到線程中去執(zhí)行，執(zhí)行完就把線程歸還。這樣一個(gè)線程就可以異步地處理多個(gè)事件。

為了獲得事件通知，我們需要一個(gè)機(jī)制，它只在需要讀時(shí)才讀，需要寫時(shí)才寫，但又保持連接打開以迅速響應(yīng)發(fā)生的事件。為了方便這個(gè)過程，就要用到NIO，它已是1.4版本以后的Java語言的一部分。

2使用Java開發(fā)Comet風(fēng)格的Web應(yīng)用

支持Comet的JavaWeb開源服務(wù)器有Tomcat6.0.14和Jetty6.1.14，它們的實(shí)現(xiàn)方法各不相同。下面我們以Tomcat為例來說明開發(fā)Comet風(fēng)格的Web應(yīng)用的步驟[2]。

本例以流方式實(shí)現(xiàn)了一個(gè)Comet應(yīng)用。服務(wù)器每隔一定的時(shí)間間隔產(chǎn)生一個(gè)0~9之間的隨機(jī)數(shù)，將數(shù)據(jù)推送到客戶端?？蛻舳私邮詹@示。

第一，要下載和安裝Tomcat6.X(本文截稿時(shí)，Tomcat最新版本是6.0.24)。

第二，為了使用Comet，要求服務(wù)器支持NIO，所以要修改Tomcat配置文件conf/server.xml，即啟用異步版本的IO連接器，這個(gè)非常關(guān)鍵。如下所示:

第三，該項(xiàng)目需要Comet的API支持，Tomcat6自帶的CometAPI包為catalina.jar，在Tomcat安裝目錄下的lib目錄中。

第四，編寫Servlet。通過servlet實(shí)現(xiàn)CometProcessor接口。這個(gè)接口要求實(shí)現(xiàn)event()方法，在配置的Http11NioProtocol調(diào)用event()方法來處理請求，而不是doGet或doPost。最基本的支持Comet的servlet實(shí)現(xiàn)如程序清單1所