姜淑芳 雍寧 葛華森

【摘要】 “服務(wù)器推送技術(shù)”是最近Web技術(shù)中最熱門的一個(gè)流行術(shù)語。它也是繼“Ajax”之后又一個(gè)倍受追捧的Web技術(shù)。該技術(shù)最近的流行跟“Ajax ”也有著密切的關(guān)系。隨著 Ajax技術(shù)的興起，這讓廣大的web開發(fā)人員又一次看到了使用瀏覽器來替代桌面應(yīng)用的大好機(jī)會，并且這次機(jī)會非常大。Ajax將整個(gè)頁面的刷新變成頁面局部的刷新，并且數(shù)據(jù)的傳送是以異步方式進(jìn)行。

【關(guān)鍵詞】 Web 消息推送 消息推送技術(shù) 服務(wù)器 消息服務(wù) Ajax

一、引言

很多應(yīng)用譬如信息檢測監(jiān)控、即時(shí)通信功能、即時(shí)報(bào)價(jià)信息系統(tǒng)都需要將后臺發(fā)生的變化實(shí)時(shí)傳送到前段客戶端而無須客戶端不停地刷新、發(fā)送請求。本文主要介紹了Web層的消息推送和服務(wù)層的消息服務(wù)業(yè)務(wù)，消息推送介紹了套接字、HTTP請求輪詢及其各種原理、Html5還有多客戶端兼容性支持，服務(wù)層的消息推送業(yè)務(wù)里介紹了消息域和消息確認(rèn)模塊。

二、Web 層的消息推送

2.1 套接字

套接字可以使用接口來進(jìn)行全雙工的通訊。也就是可以通過 Flash XMLSocket、Java Applet 技術(shù)實(shí)現(xiàn)。但是由于有的時(shí)候?qū)崿F(xiàn)方案與商業(yè)中技術(shù)綁定過緊，此不能屬于Web 標(biāo)準(zhǔn)化范圍，而且還存在一些定的限制，這里不細(xì)述。

2.2 HTTP 請求-輪詢

當(dāng)前的 Web 應(yīng)用業(yè)務(wù)都是基于 HTTP 協(xié)議實(shí)現(xiàn)的，HTTP協(xié)議就規(guī)定了那種通過請求來反應(yīng)的處理模式，而在應(yīng)用層的單工通訊模式對于實(shí)現(xiàn)真正的服務(wù)器推送方式又變得難了。為了基于 HTTP 協(xié)議進(jìn)行“推送”實(shí)現(xiàn)，可由客戶端發(fā)起 HTTP 請求輪詢，服務(wù)端在請求后返回響應(yīng)。根據(jù)輪詢的執(zhí)行時(shí)間、請求的處理方式，分為以下輪詢方式：

簡單輪詢方式原理：客戶端一般會以定時(shí)的方式發(fā)起請求，服務(wù)端接到請求后返回響應(yīng)消息。

輪詢原理、客戶端/服務(wù)端的簡單實(shí)現(xiàn)；

可以根據(jù)應(yīng)用的場景調(diào)整輪詢時(shí)間的間隔；

服務(wù)端需要即時(shí)處理大量的請求。

長輪詢方式原理：客戶端在發(fā)起請求了之后服務(wù)端將該請求掛起（也就是暫時(shí)不響應(yīng)），直到超時(shí)、異?；蛐枰幚眄憫?yīng)（推送消息內(nèi)容）時(shí)才返回響應(yīng)。然后，客戶端在收到響應(yīng)后再次輪詢（也就是請求）到服務(wù)端，同時(shí)開始處理其響應(yīng)。

此原理的實(shí)時(shí)性較高；

服務(wù)端需要在必要時(shí)管理掛起請求。

HTTP 流方式原理：客戶端發(fā)起請求后在服務(wù)器端處理請求，并且通過 HTTP 流的方式一直向客戶端寫入數(shù)據(jù)消息，直到超時(shí)或異常才返回給服務(wù)器響應(yīng)。在連接斷開后客戶端會再次和多次請求到服務(wù)端，這也就屬于長輪詢方式的一種。

2.3 HTML 5 - WebSocket

這是標(biāo)準(zhǔn)化的客戶端使用全雙工通訊的規(guī)范，但由于目前的服務(wù)器端規(guī)范還沒有形成一個(gè)真正的規(guī)范型，且大部分瀏覽器對新的 HTML5的兼容性還是有限的，這里不再敘述。

2.4 多客戶端支持

上述介紹是針對瀏覽器端的，而在實(shí)際應(yīng)用場景中，還需要考慮其他客戶端兼容性，例如 IOS、Android，甚至Linux等系統(tǒng)。在移動客戶端也就是軟件方面，需要考慮如下幾點(diǎn)：APIs 的多樣性：不同的客戶端在本地 APIs 接口逗存在不同樣子的差異，但基本都支持最基本的 HTTP 協(xié)議，因?yàn)檫@是一個(gè)基礎(chǔ)，而且直接用基于 HTTP 協(xié)議進(jìn)行開發(fā)的可以將差異變小。網(wǎng)絡(luò)連接不穩(wěn)定性：通信道打開后不一定能長時(shí)間維護(hù)，客戶端、服務(wù)端的狀態(tài)管理比較復(fù)雜。最小化的流量：需要盡量的最小化網(wǎng)絡(luò)流量需求，提升移動客戶端的持續(xù)可用性。

三、服務(wù)層的消息服務(wù)

消息是指系統(tǒng)或組件間通訊的一種低耦合的模式，是系統(tǒng)級的異步架構(gòu)的基礎(chǔ)元素。在 Web 消息推送中，服務(wù)端管理應(yīng)用狀態(tài)，當(dāng)其狀態(tài)發(fā)生了變化時(shí)需發(fā)送到客戶端，完成消息的推送。Java Message Service中需要重點(diǎn)關(guān)注如下技術(shù)點(diǎn)：消息域模塊：點(diǎn)對點(diǎn)——有且只有一個(gè)客戶端可以通過消息域接收到消息。發(fā)布/訂閱——通過發(fā)布給已經(jīng)訂閱的客戶端?？膳渲贸沙志没挠嗛啞Ｏ⒋_認(rèn)模塊：會話在本地事務(wù)在提交的時(shí)候會對接收數(shù)據(jù)來進(jìn)一步的確定，回滾的時(shí)候?qū)⒅貍魉械南ⅲ_(dá)到消息確認(rèn)的目的。非本地事務(wù)確認(rèn)方法是：Session.AUTO_ACKNOWLEDGE、Session.CLIENT_ACKNOWLEDGE、Session.DUPS_OK_ ACKNOWLEDGE

總結(jié) ：本文介紹了如何在現(xiàn)有的web消息推送技術(shù)基礎(chǔ)上選擇合適的方案開發(fā)一個(gè)“服務(wù)器推”的應(yīng)用，最優(yōu)的方案還是取決于應(yīng)用需求的本身。相對于傳統(tǒng)的 Web 應(yīng)用， 目前熱門開發(fā) Comet 應(yīng)用還是有一定的挑戰(zhàn)性的。需求推動技術(shù)的發(fā)展，相信 Comet 的應(yīng)用會變得和 AJAX 一樣普及。

參 考 文 獻(xiàn)

[1] 陳航，趙方. 基于服務(wù)器推送技術(shù)和XMPP的WebIM系統(tǒng)實(shí)現(xiàn)[J]. 計(jì)算機(jī)工程與設(shè)計(jì). 2010（05）

[2] C.J.Date著，數(shù)據(jù)庫系統(tǒng)導(dǎo)論（第七版）. 機(jī)械工業(yè)出版社

[3] Stephens著，數(shù)據(jù)庫設(shè)計(jì). 機(jī)械工業(yè)出版社

[4] 周婷，Comet：基于 HTTP 長連接的“服務(wù)器推”技術(shù). http：//www.ibm.com/developerworks/cn/web/wa-lo-comet/