英文原文：Reverse Ajax, Part 5: Event-driven web development

　　前言

　　這一文章系列展示了如何使用反向Ajax（Reverse Ajax）技術(shù)開發(fā)事件驅(qū)動的web應(yīng)用，第1部分內(nèi)容介紹了反向Ajax、輪詢（polling）、流（streaming）、Comet和長輪詢（long polling）；第2部分內(nèi)容說明了如何使用WebSocket來實(shí)現(xiàn)反向Ajax，并討論了使用Comet和WebSocket的web服務(wù)器的局限性；第3部分內(nèi)容說明了如果需要支持多種服務(wù)器，或是給用戶提供部署在他們自己的服務(wù)器上的獨(dú)立的web應(yīng)用的話，那么實(shí)現(xiàn)自己的Comet或是WebSocket通信系統(tǒng)會有哪些難點(diǎn)，該部分內(nèi)容還討論了Socket.IO；第4部分內(nèi)容談到了Atmosphere和CometD——最知名的用于Java技術(shù)服務(wù)器的開源反向Ajax庫。

　　到目前為止你已經(jīng)了解了創(chuàng)建通過事件來通信的組件，在本系列的最后一部分內(nèi)容中，我們把事件驅(qū)動開發(fā)的原則應(yīng)用到實(shí)踐中，構(gòu)建一個示例性的事件驅(qū)動web應(yīng)用。

　　你可以下載本文中使用的源代碼。

　　前提條件

　　理想情況下，要充分體會本文的話，你應(yīng)該對JavaScrpit和Java有一定的了解，并且要有一些web開發(fā)經(jīng)驗(yàn)。若要運(yùn)行本文中的例子，你還需要最新版本的Maven和JDK（參見參考資料）。

　　術(shù)語

　　你可能對事件驅(qū)動架構(gòu)（event-driven architecture，EDA）、EventBus系統(tǒng)、消息系統(tǒng)、復(fù)雜事件處理（complex event processing，CEP）和信道（channel）這些說辭并不陌生，這些術(shù)語和概念已出現(xiàn)多年。隨著技術(shù)的成熟，你可能會更頻繁地聽到這類說法。本節(jié)內(nèi)容為這些概念提供一些簡短的解釋。

　　事件（event）

　　在系統(tǒng)中會發(fā)生的一些事情的出現(xiàn)，事件通常具有屬性，比如說出現(xiàn)的時間（時間戳）、來源或位置（我們點(diǎn)擊的組件），以及一些描述事件的數(shù)據(jù)。根據(jù)系統(tǒng)的不同，事件還可以有其他的一些屬性選擇。

　　事件驅(qū)動架構(gòu)（Event-driven architecture，EDA）

　　也稱作基于事件的編程，這是一種架構(gòu)設(shè)計，在這種設(shè)計中，應(yīng)用由通過發(fā)送和接收事件來通信和執(zhí)行的組件構(gòu)成。Swing的圖形化用戶界面（GUI）就是一個EDA例子，每個Swing組件都可以監(jiān)聽事件、對事件作出反應(yīng)、發(fā)送其他事件等。EDA由幾個部分組成：事件生產(chǎn)者、事件消費(fèi)者、事件和處理軟件。

　　1. 事件生產(chǎn)者（event producer）——該組件發(fā)出事件。在本文的例子中，表單的提交按鈕就是一個事件生產(chǎn)者。

　　2. 事件消費(fèi)者（event consumer）——監(jiān)聽特定事件的組件。例如，例子中的表單提交這種情況，瀏覽器監(jiān)聽表單的提交按鈕上的點(diǎn)擊操作，把表單數(shù)據(jù)發(fā)送給服務(wù)器。

　　3. 事件處理軟件（event-processing software）——這是系統(tǒng)的核心，事件生產(chǎn)者發(fā)布事件，事件消費(fèi)者注冊自身以接收事件。根據(jù)軟件的不同，處理過程可以很簡單（只是把接收到的事件轉(zhuǎn)發(fā)給消費(fèi)者），或很復(fù)雜（CEP）。有了CEP，軟件就可以支持各種各樣的處理方式，比如說事件的匯集、過濾和轉(zhuǎn)換等。

　　Esper就是這樣的一個軟件例子。事件處理軟件不僅可以表現(xiàn)成一個獨(dú)立的運(yùn)行應(yīng)用，其還可以是整合到你的應(yīng)用中的庫。

　　消息系統(tǒng)（messaging system）

　　一種事件驅(qū)動應(yīng)用類型，在這種應(yīng)用中，事件生產(chǎn)者把消息發(fā)布到信道中，事件消費(fèi)者則通過信道進(jìn)行訂閱。事件生產(chǎn)者和消費(fèi)者彼此之間沒有鏈接，是完全獨(dú)立開來的。在這種類型的事件驅(qū)動應(yīng)用中，通常用到的術(shù)語是消息（message）而不是事件（event）。

　　信道（channel）

　　消息系統(tǒng)中分類事件的一種方式。其代表了事件生產(chǎn)者希望事件發(fā)送到的目的地。例如，在一個聊天室應(yīng)用中，某個信道可能會是 /chatapplication/chatrooms/asdrt678，該信道標(biāo)識了一個事件生產(chǎn)者可以發(fā)送消息的特定的聊天室，圖形化的組件應(yīng)該要訂閱該信道，目的是顯示最新到達(dá)的消息。

　　某些消息系統(tǒng)提供了兩種類型的信道：隊(duì)列（queue）和主題（topic）。

　　1. 隊(duì)列（queue）——當(dāng)某條消息被發(fā)送到隊(duì)列中時，只有一個事件消費(fèi)者拿到并處理該條消息，其他消費(fèi)者不會看到它。隊(duì)列可被持久化，以保證交付。最好的隊(duì)列例子是郵遞請求，某個web應(yīng)用在用戶注冊時發(fā)布一條消息到隊(duì)列 /myapp/mail/user-registration中，可能有多個郵件應(yīng)用訂閱了這一隊(duì)列，如果沒有的話，消息也不會丟失。

　　2. 主題（topic）——當(dāng)某條消息發(fā)送到某個主題上時，每個訂閱者都可以接收到它，主題通常是沒有持久化的。一個例子是監(jiān)控軟件的一個主題/event/system/cpu/usage，生產(chǎn)者定期往其中發(fā)送CPU的使用情況；另一方面，這一主題可能會沒有或是有多個訂閱者，這取決于他們的興趣所在。

　　發(fā)布/訂閱（publish/subscribe）

　　事件驅(qū)動的解決方案實(shí)現(xiàn)了發(fā)布/訂閱模式。事件生產(chǎn)者在處理軟件中發(fā)布事件，事件消費(fèi)者通過訂閱來接收它們。事件消費(fèi)者訂閱的方式依賴于軟件。在消息應(yīng)用中，它們訂閱信道（比如說，還可以有選擇地把過濾規(guī)則應(yīng)用在事件類型上）。使用諸如Esper一類的CEP，可通過類SQL的請求來定義你所感興趣的事件，完成訂閱操作。

　　為什么使用事件驅(qū)動的解決方案

　　在一個傳統(tǒng)的通信方案中，如果系統(tǒng)A需要來自系統(tǒng)B的信息，就會發(fā)送一個請求給B。系統(tǒng)B會處理該請求，系統(tǒng)A則會停在那里等待響應(yīng)。在處理完成時，響應(yīng)會送回給系統(tǒng)A。在這一同步的通信模式中，資源的消耗是低效的，因?yàn)樵诘却憫?yīng)時浪費(fèi)掉了處理時間。

　　在異步模式中，系統(tǒng)A會從系統(tǒng)B中訂閱它響應(yīng)的信息。然后系統(tǒng)A可以選擇性地給系統(tǒng)B發(fā)送通知，并立刻返回，系統(tǒng)A可以繼續(xù)處理其他事情，這一步驟是可選的。通常情況下，在事件驅(qū)動的應(yīng)用中，你不需要請求其他系統(tǒng)發(fā)送事件，因?yàn)槟悴恢浪鼈兪钦l。當(dāng)系統(tǒng)B發(fā)布響應(yīng)時，系統(tǒng)A會立刻接收到。

　　事件驅(qū)動架構(gòu)的一個優(yōu)點(diǎn)是其允許更好的伸縮性。可伸縮性是系統(tǒng)在滿足其目標(biāo)的同時適應(yīng)需求、容量或是強(qiáng)度變化的能力。通過消除暫停時間，事件驅(qū)動的架構(gòu)通常有著更好的表現(xiàn)，以及有更高的處理效率。

　　另一個優(yōu)點(diǎn)表現(xiàn)在應(yīng)用的開發(fā)和維護(hù)方面。使用事件驅(qū)動的解決方案，應(yīng)用的每個組件都可以是完全獨(dú)立和解耦的。

　　事件驅(qū)動的解決方案允許有更好的反應(yīng)時間，因?yàn)橥ㄐ庞兄偷难舆t。

　　把事件驅(qū)動的解決方案應(yīng)用在web上

　　web框架過去依賴于傳統(tǒng)的請求-響應(yīng)模式，這導(dǎo)致了頁面的刷新。隨著Ajax、反向Ajax以及諸如CometD和Atmosphere一類的功能強(qiáng)大的框架的出現(xiàn)，現(xiàn)在把事件驅(qū)動架構(gòu)的概念應(yīng)用到web上來獲取解耦、可伸縮性和反應(yīng)性的好處已經(jīng)不是什么難事了。

　　客戶端

　　事件驅(qū)動架構(gòu)可應(yīng)用在GUI開發(fā)的客戶端。與創(chuàng)建一個傳統(tǒng)的web頁面不同，你可以把一個單獨(dú)的web頁面當(dāng)作容器使用。每個組件（頁面的每個組成部分）都可以是獨(dú)立的，你可以在web上放一個Java Swing GUI，就像包含了小工具（gadget）的Google頁面那樣。

　　你需要一個事件總線（event bus），例如，你需要開發(fā)一個JavaScript事件總線，其允許每個頁面組件從信道訂閱或是在信道中發(fā)布。事件也可以是異步的，在兩個或是多個事件到達(dá)后才觸發(fā)行為。事件總線可以用于頁面中的局部事件，但你也可以通過使用CometD或是Socket.IO來以插件的方式支持遠(yuǎn)端事件。

　　服務(wù)器端

　　在服務(wù)器端，你需要設(shè)置一個反向Ajax框架來支持事件驅(qū)動的框架。在本系列前幾部分的考察中，發(fā)現(xiàn)只有CometD有著事件驅(qū)動的方法。對于其他框架來說，你需要增加自定義的支持，這不是什么大問題。你還可以加入第三方的消息系統(tǒng)，比如說JMS（例如Apache ActiveMQ）或是像Esper那樣的CEP。一個更簡單的解決方案是Redis，其支持基本的發(fā)布/訂閱。

　　這一文章系列談?wù)摰氖鞘录?qū)動的web和反向Ajax，因此我們重點(diǎn)關(guān)注客戶端，不會去設(shè)置一個復(fù)雜的消息系統(tǒng)。

　　事件驅(qū)動web的例子

　　本文將要創(chuàng)建的例子是一個聊天室web應(yīng)用，該應(yīng)用使用一個用戶面板來列出連接的用戶。你的用戶名是加粗顯示的，活動用戶（20秒鐘后還處活躍狀態(tài)的那些）是綠色顯示的，20秒鐘后處于非活動狀態(tài)的那些是橙色顯示的。如果有用戶連接或是斷開連接，列表就會刷新。

　　出于安全目的，web.xml文件中配置了兩分鐘的會話超時，非活動狀態(tài)兩分鐘后，就會彈出一個窗口，你會被重定向到登錄頁面。

　　只要你不再處于會話中或是還未連接，就會被重定向到登錄頁面。登錄頁面要求輸入用戶名并會查看是否可讓你登錄到聊天室中。

　　一旦登錄成功，你就可以在聊天室中給所有用戶發(fā)送消息。一個控制臺也會顯示出來，記錄所有收到的事件。

　　該web應(yīng)用是基于事件的，有了上述的信息，你可以很容易地定義幾個事件：

　　1. 用戶連接

　　2. 用戶斷開連接

　　3. 會話過期

　　4. 接收到聊天消息

　　5. 如果沒有登錄的話，安全過濾器阻攔請求

　　6. 用戶變成非活動的

　　7. 用戶變成活動的

　　8. 所有其他與UI協(xié)調(diào)相關(guān)的事件

　　某些事件只局部于web應(yīng)用，由局部總線來識別，如清單1所示：

　　清單1. 總線設(shè)置

bus = { 
    local: new EventBus({
        name: 'EventBus Local'
    }), 
    remote: EventBus.cometd({
        name: 'EventBus Remote',
        logLevel: 'warn',
        url: document.location.href.substring(0,
            document.location.href.length -
            document.location.pathname.length) + '/async',
        onConnect: function() {
            bus.local.topic('/event/bus/remote/connected').publish();
        },
        onDisconnect: function() {
            bus.local.topic('/event/bus/remote/disconnected').publish();
        }
    }) 
};

it知識庫：反向Ajax，第5部分：事件驅(qū)動的Web開發(fā)，轉(zhuǎn)載需保留來源！

鄭重聲明：本文版權(quán)歸原作者所有，轉(zhuǎn)載文章僅為傳播更多信息之目的，如作者信息標(biāo)記有誤，請第一時間聯(lián)系我們修改或刪除，多謝。