圖5dWMVC的示意圖。圖中顯示了三元組對(duì)象在客戶和服務(wù)器間的分布。由SoR發(fā)起的入站更改通知導(dǎo)致了模型和視圖間的實(shí)時(shí)雙向更新。
SSE機(jī)制作為 HTML5 的組成部分，允許服務(wù)器端組件異步啟動(dòng)，并將數(shù)據(jù)從服務(wù)器端組件實(shí)時(shí)推送到瀏覽器?？蛻舳私M件可以使用SSE發(fā)起請(qǐng)求，向服務(wù)器申請(qǐng)建立一個(gè)非傳統(tǒng)的HTTP連接。一旦客戶端組件接收到所發(fā)起的請(qǐng)求，它繼續(xù)對(duì)隨后的服務(wù)器響應(yīng)進(jìn)行監(jiān)聽(tīng)。與此同時(shí)，服務(wù)器保持同一客戶-服務(wù)器初始連接是活躍的。一旦新的數(shù)據(jù)可用，服務(wù)器無(wú)需客戶的額外請(qǐng)求，就立刻通過(guò)該初始連接將這些數(shù)據(jù)推送給客戶。這樣，SEE給出了一種從服務(wù)器到客戶瀏覽器的解決方案，該解決方法使用了異步的發(fā)布-訂閱事件通知。
WebSocket是一種提供瀏覽器和服務(wù)器間全雙工連接的通信協(xié)議。當(dāng)客戶發(fā)送初始請(qǐng)求到服務(wù)器時(shí)，WebSocket通知服務(wù)器該HTTP連接可能會(huì)升級(jí)為全雙工的TCP/IP WebSocket連接，通知使用了一種特殊的HTTP報(bào)頭。一旦WebSocket連接被建立，就可在需要時(shí)用于在瀏覽器和服務(wù)器間相互發(fā)送數(shù)據(jù)。
使用SSE和WebSocket通信協(xié)議，服務(wù)器可以異步地將模型駐留內(nèi)存的更改發(fā)布到瀏覽器。但是正如前面所討論過(guò)的，模型架構(gòu)的分層可能會(huì)跨越服務(wù)器的邊界，并可能包括應(yīng)用服務(wù)器之外的外部SoR(參見(jiàn)圖4)。由于SoR中的數(shù)據(jù)記錄可被其他應(yīng)用或用戶修改，因此每當(dāng)這樣的帶外更改發(fā)生時(shí)，SoR應(yīng)具有 變化數(shù)據(jù)捕獲 (change data capture，CDC)機(jī)制去探測(cè)并捕獲更改，實(shí)時(shí)地發(fā)起并推送入站數(shù)據(jù)更改到應(yīng)用服務(wù)器，實(shí)現(xiàn)端到端的雙向發(fā)布-訂閱通信模型(如圖5和圖6所示)。在圖6中，dWMVC輪轂的中心表示了共享的SoR和CDC數(shù)據(jù)源。數(shù)據(jù)的實(shí)時(shí)同步由數(shù)據(jù)源和相關(guān)駐留內(nèi)存域模型對(duì)象之間的雙向交互所維持。在圖6中，每個(gè)輪輻間的微型dWMV表示了一個(gè)獨(dú)立的業(yè)務(wù)應(yīng)用(集成的企業(yè)生態(tài)系統(tǒng)中)，或是一個(gè)獨(dú)立的應(yīng)用用戶。
圖6dWMVC輪圖。圖中顯示了由SoR發(fā)起的入站更改通知，并顯示所引發(fā)的模型和所有視圖間的實(shí)時(shí)雙向更新情況(以微型WMVC展示)。
基于Web的架構(gòu)棧中加入了XHR-Ajax、SSE和WebSocket等技術(shù)，還有數(shù)據(jù)庫(kù)廠商提供了數(shù)據(jù)庫(kù)入站通信能力，所有這些一起使得傳統(tǒng)oMVC中視圖和模型間的雙向交互通信在dWMVC中得到了復(fù)興。越來(lái)越多的數(shù)據(jù)庫(kù)廠商，包括 PostgreSQL 、 Oracle 等傳統(tǒng)關(guān)系數(shù)據(jù)庫(kù)廠商和 RethinkDB 、 Cassandra 等 NoSQL 數(shù)據(jù)庫(kù)廠商，已經(jīng)實(shí)現(xiàn)或者規(guī)劃去提供CDC機(jī)制，以改進(jìn)應(yīng)用服務(wù)器的入站推送通知。
點(diǎn)對(duì)點(diǎn)WMVC(pWMVC)
對(duì)于上面所論及的兩種WMVC，它們的架構(gòu)語(yǔ)義都是基于 客戶-服務(wù)器范例 的，即用戶瀏覽器向服務(wù)器發(fā)送HTTP請(qǐng)求，取回服務(wù)器端的內(nèi)容，服務(wù)器則回應(yīng)以包含請(qǐng)求信息的一個(gè)或更多的響應(yīng)。這類方法中，服務(wù)器負(fù)責(zé)存儲(chǔ)，并發(fā)送所有內(nèi)容及對(duì)所有請(qǐng)求的響應(yīng)。但是這樣的集中式方法可能會(huì)導(dǎo)致性能上的瓶頸。因?yàn)闉榱酥С炙锌赡艿恼?qǐng)求負(fù)載，需要對(duì)服務(wù)器基礎(chǔ)設(shè)施的資源進(jìn)行適當(dāng)?shù)財(cái)U(kuò)展和復(fù)制。當(dāng)前由于高頻度實(shí)時(shí)內(nèi)容發(fā)布需求在數(shù)量上日益增長(zhǎng)，這類方法會(huì)產(chǎn)生問(wèn)題，尤其是在(意料之外的)高通量負(fù)載的期間。最優(yōu)的系統(tǒng)無(wú)疑是那種能以去中心化的方式支持高質(zhì)量終端用戶體驗(yàn)的系統(tǒng)，這樣的系統(tǒng)可以使用戶用最短的路由和時(shí)間獲取到數(shù)據(jù)。借助于 點(diǎn)對(duì)點(diǎn) (Peer-to-peer，P2P)數(shù)據(jù)交換及通信，終端用戶可以從其它的用戶那里交互、檢索和接收內(nèi)容。無(wú)疑，這樣的架構(gòu)繞開或降低了集中式服務(wù)器的負(fù)載和潛在瓶頸問(wèn)題。
傳統(tǒng)的點(diǎn)對(duì)點(diǎn)系統(tǒng)需要用戶顯式地安裝專用的桌面應(yīng)用或插件。在 WebRTC (Web實(shí)時(shí)通信，Web Real-Time Communication)協(xié)議被標(biāo)準(zhǔn)化并被瀏覽器支持之前，瀏覽器本身并不具備使對(duì)等系統(tǒng)的工作直接相互通信的能力?，F(xiàn)在WebRTC標(biāo)準(zhǔn)已被大多數(shù)的瀏覽器所支持。它是一種API定義，提供了無(wú)服務(wù)器的瀏覽器到瀏覽器(瀏覽器P2P)直接數(shù)據(jù)交換和通信范例。WebRTC對(duì)Web應(yīng)用引入了點(diǎn)到點(diǎn)的解決方案，它允許Web瀏覽器打開到其它瀏覽器的直接通信通道，無(wú)需對(duì)每個(gè)Web請(qǐng)求-響應(yīng)的集中式服務(wù)場(chǎng)景進(jìn)行處理(參見(jiàn)圖7和圖8)。