反向Ajax，第2部分：WebSocket

來源: yeeyan 發布時間: 2011-10-17 18:56 閱讀: 17782 次推薦: 3 原文鏈接 [收藏]

這一文章系列探討了如何使用反向Ajax（Reverse Ajax）技術來開發事件驅動的web應用，第1部分內容介紹了實現反向Ajax通信的幾種不同方式：輪詢（polling）、捎帶（piggyback）以及使用了長輪詢（long-polling）和流（streaming）的Comet。在本文中，我們學習一種新的實現反向Ajax的技術：使用WebSocket，一個新的HTML5 API。WebSocket可由瀏覽器廠商來做本地化實現，或是通過把調用委托給隱藏的被稱為FlashSocket的Flash組件這種橋接手段來實現。本文還討論了反向Ajax技術帶來的一些服務器端約束。

　　前言

　　時至今日，用戶期待的是可通過web訪問快速、動態的應用。這一文章系列展示了如何使用反向Ajax（Reverse Ajax）技術來開發事件驅動的web應用。該系列的第1部分介紹了反向Ajax、輪詢（polling）、流（streaming）、Comet和長輪詢（long polling）。你已經了解了Comet是如何使用HTTP長輪詢的，這是可靠地實現反向Ajax的最好方式，因為現有的所有瀏覽器都提供支持。

　　在本文中，我們將學習如何使用WebSocket來實現反向Ajax。代碼例子被用來幫助說明WebSocket、FlashSocket、服務器端約束、請求作用域（request-scoped）服務以及暫停長生存期請求等，你可以下載本文中用到的這些源代碼。

　　前提條件

　　理想情況下，要充分體會本文的話，你應該對JavaScrpit和Java有一定的了解。本文中創建的例子是使用Google Guice來構建的，這是一個使用Java編寫的依賴注入框架。若要讀懂文中所談內容，你應該要熟悉諸如Guice、Spring或是Pico一類的依賴注入框架的概念。

　　若要運行本文中的例子，你還需要最新版本的Maven和JDK（參見參考資料）。

　　WebSocket

　　在HTML5中出現的WebSocket是一種比Comet還要新的反向Ajax技術，WebSocket啟用了雙向的全雙工通信信道，許多瀏覽器（Firefox、Google Chrome和Safari）都已對此做了支持。連接是通過一個被稱為WebSocket握手的HTTP請求打開的，其用到了一些特殊的報頭。連接會保持在活動狀態，你可以使用JavaScript來寫入和接收數據，就像是在使用一個原始的TCP套接口一樣。

　　WebSocket URL的起始輸入是ws://或是wss://（在SSL上）。

　　圖1中的時間線說明了使用WebSocket的通信。一個帶有特定報頭的HTTP握手被發送到了服務器端，接著在服務器端或是客戶端就可以通過JavaScript來使用某種套接口（socket）了，這一套接口可被用來通過事件句柄異步地接收數據。

　　圖1. 使用WebSocket的反向Ajax

　　本文可下載的源代碼中有一個WebSocket例子，在運行該例子時，你應該會看到類似清單1的輸出。其說明了客戶端的事件是如何發生的，以及如何會立即在客戶端顯示出來。當客戶端發送一些數據時，服務器端回應客戶端的發送行為。

　　清單1. JavaScript中的WebSocket例子

[client] WebSocket connection opened
[server] 1 events
[event] ClientID =0
[server] 1 events
[event] At Fri Jun 1721:12:01 EDT 2011
[server] 1 events
[event] From 0 : qqq
[server] 1 events
[event] At Fri Jun 1721:12:05 EDT 2011
[server] 1 events
[event] From 0 : vv

　　通常情況下，在JavaScript中你會如清單2所說明的那樣來使用WebSocket，如果你的瀏覽器支持它的話。

　　清單2. JavaScript客戶端例子

　　發送和接收的數據可以是任意類型的，WebSocket可被看成是TCP套接口，因此這取決于客戶端和服務器端知道要來回發送的數據是哪種類型的。這里的例子發送的是JSON串。

　　在JavaScript WebSocket對象被創建后，如果在瀏覽器的控制臺（或是Firebug）中仔細看一下HTTP請求的話，你應該會看到WebSocket特有的報頭。清單3給出了一個例子。

　　清單3. HTTP請求和相應報頭示例

Request URL:ws://127.0.0.1:8080/async
Request Method:GET
Status Code:101 WebSocket Protocol Handshake

Request Headers
Connection:Upgrade
Host:127.0.0.1:8080
Origin:http://localhost:8080
Sec-WebSocket-Key1:1 &1~ 33188Yd]r8dp W75q
Sec-WebSocket-Key2:17; 229 *043M 8
Upgrade:WebSocket
(Key3):B4:BB:20:37:45:3F:BC:C7

Response Headers
Connection:Upgrade
Sec-WebSocket-Location:ws://127.0.0.1:8080/async
Sec-WebSocket-Origin:http://localhost:8080
Upgrade:WebSocket
(Challenge Response):AC:23:A5:7E:5D:E5:04:6A:B5:F8:CC:E7:AB:6D:1A:39

　　WebSocket握手使用所有的這些報頭來驗證并設置一個長生存期的連接，WebSocket的JavaScript對象還包含了兩個有用的屬性：

　　ws.url：返回WebSocket服務器的URL
　　ws.readyState：返回當前連接狀態的值
　　1. CONNECTING = 0
　　2. OPEN = 1
　　3. CLOSED = 2

　　服務器端對WebSocket的處理要稍加復雜一些，現在還沒有某個Java規范以一種標準的方式來支持WebSocket。要使用web容器（例如Tomcat或是Jetty）的WebSocket功能的話，你得把應用代碼和容器特定的庫緊密耦合在一起才能訪問WebSocket的功能。

　　示例代碼的websocket文件夾中的例子使用的是Jetty的WebSocket API，因為我們使用的是Jetty容器。清單4 給出了WebSocket的處理程序。（本系列的第3部分會使用不同的后端WebSocket API。）

　　清單4. Jetty容器的WebSocket處理程序

public final class ReverseAjaxServlet extends WebSocketServlet {
　　@Override
　　protected WebSocket doWebSocketConnect(HttpServletRequest request,String protocol) {
　　　　return [...]
　　}
}

　　就Jetty來說，有幾種處理WebSocket握手的方式，比較容易的一種方式是子類化Jetty的WebSocketServlet并實現doWebSocketConnect方法。該方法要求你返回Jetty的WebSocket接口的一個實例，你必須要實現該接口并返回代表了WebSocket連接的某種端點（endpoint）。清單5提供了一個例子。

　　清單5. WebSocket實現示例

class Endpoint implements WebSocket {
Outbound outbound;
@Override
publicvoid onConnect(Outbound outbound) {
　　this.outbound = outbound;
}
@Override
publicvoid onMessage(byte opcode, String data) {
　　// 在接收到消息時調用
　　// 你通常用到的就是這一方法
}
@Override
publicvoid onFragment(boolean more, byte opcode,byte[] data, int offset, int length) {
　　// 在完成一段內容時，onMessage被調用
　　// 通常不在這一方法中寫入東西
}
@Override
publicvoid onMessage(byte opcode, byte[] data,int offset, int length) {
　　onMessage(opcode, new String(data, offset, length));
}
@Override
publicvoid onDisconnect() {
　　outbound =null;
}
}

　　若要向客戶端發送消息的話，你要向outbound中寫入消息，如果清單6所示：

　　清單6. 發送消息給客戶端

if (outbound != null && outbound.isOpen()) {
　　outbound.sendMessage('Hello World !');
}

　　要斷開并關閉到客戶端的WebSocket連接的話，使用outbound.disconnect()。

　　WebSocket是一種實現無延遲雙向通信的非常強大的方法，Firefox、Google Chrome、Opera和其他的現代瀏覽器都支持這種做法。根據jWebSocket網站的說法：

　　1. Chrome從4.0.249版本開始包含本地化的WebSocket。
　　2. Safari 5.x包含了本地化的WebSocket。
　　3. Firefox 3.7a6和4.0b1+包含了本地化的WebSocket。
　　4. Opera從10.7.9.67開始包含了本地化的WebSocket。

　　欲了解更多關于jWebSocket方面的內容，請查閱參考資料。

　　優點

　　WebSocket功能強大、雙向、低延遲，且易于處理錯誤，其不會像Comet長輪詢那樣有許多的連接，也沒有Comet流所具有的一些缺點。它的API也很容易使用，無需另外的層就可以直接使用，而Comet則需要一個很好的庫來處理重連接、超時、Ajax請求、確認以及選擇不同的傳輸（Ajax長輪詢和jsonp輪詢）。

　　缺點

　　WebSocket的缺點有這些：

　　1. 是一個來自HTML5的新規范，還沒有被所有的瀏覽器支持。

　　2. 沒有請求作用域（request scope），因為WebSocket是一個TCP套接口而不是一個HTTP請求，有作用域的請求服務，比如說Hibernate的SessionInViewFilter，就不太容易使用。Hibernate是一個持久性框架，其在HTTP請求的外圍提供了一個過濾器。在請求開始時，其在請求線程中設定了一個上下文（包括事務和JDBC連接）邊界；在請求結束時，過濾器銷毀這一上下文。

　　FlashSocket

　　對于不支持WebSocket的瀏覽器來說，有些庫能夠回退到FlashSocket（經由Flash的套接口）上。這些庫通常會提供同樣的官方WebSocket API，但他們是通過把調用委托給一個包含在網站中的隱藏的Flash組件來實現的。

　　優點

　　FlashSocket透明地提供了WebSocket的功能，即使是在不支持HTML5 WebSocket的瀏覽器上也是如此。

　　缺點

　　FlashSocket有著下面的這些缺點：

　　1. 其需要安裝Flash插件（通常情況下，所有瀏覽器都會有該插件）。

　　2. 其要求防火墻的843端口是打開的，這樣Flash組件才能發出HTTP請求來檢索包含了域授權的策略文件。如果843端口是不可到達的話，則庫應該有回退動作或是給出一個錯誤，所有的這些處理都需要一些時間（最多3秒，這取決于庫），而這會降低網站的速度。

　　3. 如果客戶端處在某個代理服務器的后面的話，到端口843的連接可能會被拒絕。

　　WebSocketJS項目提供了一種橋接方式，其要求一個至少是10版本的Flash來為Firefox 3、Inernet Explorer 8和Internet Explorer 9提供WebSocket支持。

　　建議

　　相比于Comet，WebSocket帶來了更多的好處。在日常開發中，客戶端支持的WebSocket速度更快，且產生較少的請求（從而消耗更少的帶寬）。不過，由于并非所有的瀏覽器都支持WebSocket，因此，對于Reverse Ajax庫來說，最好的選擇就是能夠檢測對WebSocket的支持，并且如果不支持WebSocket的話，還能夠回退到Comet（長輪詢）上。

　　由于這兩種技術需要從所有瀏覽器中獲得最好的做法并保持兼容性，因此我的建議是使用一個客戶端的JavaScript庫，該庫在這些技術之上提供一個抽象層。本系列的第3和第4部分內容會探討一些庫，第5部分則是說明它們的應用。在服務器端，正如下一節內容討論的那樣，事情則會稍加復雜一些。

　　服務器端的反向Ajax約束

　　現在你對客戶端可用的反向Ajax解決方案已經有了一個概觀，讓我們再來看看服務器端的反向Ajax解決方案。到目前為止，例子使用的都還主要是客戶端的JavaScript代碼。在服務器端，要接受反向Ajax連接的話，相比你所熟悉的短HTTP請求，某些技術需要特定的功能來處理長生存期的連接。為了得到更好的伸縮性，應該要使用一種新的線程模型，該模型需要Java中的某個特定API來暫停請求。還有，就WebSocket來說，你必須要正確地管理應用中用到的服務的作用域。

　　線程和非阻塞I/O

　　通常情況下，web服務器會把一個線程或是一個進程與每個傳入的HTTP連接關聯起來。這一連接可以是持久的（保持活動），這樣多個請求就可以通過這同一個連接進行了。在本文的例子中，Apache web服務器可以配置成mpm_fork或是mpm_worker模式來改變這一行為。Java web服務器（應用服務器也包括在內——這是同一回事）通常會為每個傳入的連接使用單獨的一個線程。

　　產生一個新的線程會帶來內存的消耗和資源的浪費，因為其并不保證產生的線程會被用到。連接可能會建立起來，但是沒有來自客戶端或是服務器端的數據在發送。不管這一線程是否被用到，其都會消耗用于調度和上下文切換的內存和CPU資源。而且，在使用線程模式來配置服務器時，你通常需要配置一個線程池（設定處理傳入連接的線程的最大數目）。如果該值配置不當，值太小的話，你最終就會遭遇線程饑餓問題；請求就會一直處于等待狀態直到有線程可用來處理它們，在達到最大并發連接時，響應時間就會下降。另一方面，配置一個高值則可會導致內存不足的異常，產生過多線程會消耗盡JVM的所有可用的堆，導致服務器崩潰。

　　Java最近引入一個新的I/O API，其被稱為非阻塞式的I/O。這一API使用一個選擇器來避免每次有新的HTTP連接在服務器端建立時都要綁定一個線程的做法，當有數據到來時，就會有一個事件被接收，接著某個線程就被分配來處理該請求。因此，這種做法被稱為每個請求一個線程（thread-per-request）模式。其允許web服務器，比如說WebSphere和Jetty等，使用固定數量的線程來容納并處理越來越多的用戶連接。在相同硬件配置的情況下，在這一模式下運行的web服務器的伸縮性要比運行在每個連接一個線程（thread-per-connection）模型下的好得多。

　　在Philip McCarthy（Comet and Reverse Ajax的作者）的博客中，關于這兩種線程模式的可伸縮性有一個很有意思的衡量基準（參見參考資料中的鏈接）。在圖2中，你會發現同樣的模式：在有太多連接時，線程模式會停止工作。

　　圖2. 線程模式的衡量基準

　　每個連接一個線程模式（圖2中的Threads）通常會有一個更好的響應時間，因為所有的線程都已啟動、準備好且是等待中，但在連接的數目過高時，其會停止提供服務。在每個請求一個線程模式（圖2中的Continuations）中，線程被用來為到達的請求提供服務，連接則是通過一個NIO選擇器來處理。響應時間可能會較慢一些，但線程會回收再用，因此該方案在大容量連接方面有著更好的伸縮性。

　　想要了解線程在幕后是如何工作的話，可以把一個LEGO™積木塊想象成是選擇器，每次傳入的連接到達這一LEGO積木塊時，其由一個管腳來標識。LEGO積木塊/選擇器有著與連接數一樣多的管腳（一樣多的鍵）。那么，只需要一個線程來等待新事件的發生，然后在這些管腳上遍歷就可以了。當有事情發生時，選擇器線程從發生的事件中檢索出鍵值，然后就可以使用一個線程來為傳入的請求提供服務。

　　“Rox Java NIO Tutorial”這一教程有很好的使用Java中的NIO的例子（參見參考資料）。

　　有請求作用域的服務

　　許多框架都提供了服務或是過濾器（filter）來處理到達servlet的web請求，例如，某個過濾器會：

　　1. 把JDBC連接綁定到某個請求線程上，這樣整個請求就只用到一個連接。

　　2. 在請求結束時提交所做的改變。

　　另一個例子是Google Guice（一個依賴注入庫）的Guice Servlet擴展。類似于Spring，Guice可把服務綁定在請求的作用域內，一個實例至多只會為每個新請求創建一次（參閱參考資料獲得更多信息）。

　　通常的做法包括了使用用戶id來把從儲存庫中檢索出來的用戶對象緩存在請求中，用戶id則是取自集群化的HTTP會話。在Google Guice中，你可能會有類似清單7中給出的代碼。

　　清單7. 請求作用域的綁定

@Provides
@RequestScoped
Member member(AuthManager authManager,
MemberRepository memberRepository) {
　　return memberRepository.findById(authManager.getCurrentUserId());
}

　　當某個member被注入到類中時，Guice會嘗試這從請求中獲取該對象，如果沒有找到的話，它就會執行儲存庫調用并把結果放在請求中。

　　請求作用域可與除了WebSocket之外的其他任何的反向Ajax解決方案一起使用，任何其他的依賴于HTTP請求的解決方案，無論是短的還是長的生存期的都可以，每個請求都會通過servlet分發系統，過濾器都會被執行。在完成一個暫停的（長生存其）HTTP請求時，你會在這一系列的后繼部分中了解到還有另一種做法可讓請求再次通過過濾器鏈。

　　對于WebSocket來說，數據直接到達onMessage回調函數上，就像是在TCP套接口中的情況那樣。不存在任何的HTTP請求送達這一數據，故也不存在獲取或是存放作用域對象的請求上下文。因此在onMessage回調中使用需要作用域對象的服務就會失敗。可下載源代碼中的guice-and-websocket例子說明了如何繞過這一限制，以便仍然可在onMessage回調中使用請求作用域對象。當你運行這一例子，并在網頁上點擊每個按鈕來測試一個Ajax調用（有請求作用域的）、一個WebSocket調用和一個使用了模擬請求作用域的WebSocket調用時，你會得到圖3所示的輸出。

　　圖3. 使用了請求作用域服務的WebSocket處理程序

　　在使用下面任一種技術時，你可能都會遇到這些問題：

　　1. Spring

　　2. Hibernate

　　3. 任何其他需要請求作用域或是每一請求模型的框架，比如說OpenSessionInViewFilter。

　　4. 任何在過濾器的內部使用ThreadLocal這一設施來指定變量的作用域為請求線程并在以后訪問這些變量的系統。

　　Guice有一個優雅的解決方案，如清單8所示：

　　清單8. 在WebSocket的onMessage回調中模擬一個請求作用域

// 在調用doWebSocketMethod時
// 保存到請求的引用
HttpServletRequest request = [...]
Map, Object> bindings =new HashMap, Object>();
// 我有一個服務需要一個請求來獲取會話
// 因此我提供一個請求，但你可以提供任何其他
// 可能需要的綁定
bindings.put(Key.get(HttpServletRequest.class), request);
ServletScopes.scopeRequest(new Callable() {
　　@Override
　　public Object call() throws Exception {
　　// 調用你的儲存庫或是任何用到作用域對象的服務
　　　　outbound.sendMessage([...]);
　　　　return null;
　　}
}, bindings).call();

　　暫停長生存期請求

　　若使用Comet的話，還有另一障礙存在，那就是服務器端如何在不影響性能的情況下暫停一個長生存期請求，然后在服務器端事件到來時盡可能快地恢復并完成請求呢？

　　很顯然，你不能簡單地讓請求和響應停在那里，這會引發線程饑餓和高內存消耗。暫停非阻塞式的I/O中的一個長生存期請求，在Java中這需要一個特有的API。Servlet 3.0規范提供了這樣的一個API（參見本系列的第1部分內容）。清單9給出了一個例子。

　　清單9. 使用Servlet 3.0來定義一個異步的servlet

<?xml version="1.0" encoding="UTF-8"?>

<web-app version="3.0" xmlns="http://java.sun.com/xml/ns/javaee"
xmlns:j2ee="http://java.sun.com/xml/ns/javaee"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="http://java.sun.com/xml/ns/j2ee http://java.sun.com/xml
/ns/j2ee/web-app_3.0.xsd">

<servlet>
<servlet-name>events</servlet-name>
<servlet-class>ReverseAjaxServlet</servlet-class>
<async-supported>true</async-supported>
</servlet>

<servlet-mapping>
<servlet-name>events</servlet-name>
<url-pattern>/ajax</url-pattern>
</servlet-mapping>

</web-app>

　　在定義了一個異步的servlet之后，你就可以使用Servlet 3.0 API來掛起和恢復一個請求，如清單10所示：

　　清單10. 掛起和恢復一個請求

AsyncContext asyncContext = req.startAsync();
// 把asyncContext的引用保存在某處

// 然后在需要的時候，在另一個線程中你可以恢復并完成
HttpServletResponse req =
(HttpServletResponse) asyncContext.getResponse();
req.getWriter().write("data");
req.setContentType([...]);
asyncContext.complete();

　　在Servlet 3.0之前，每個容器都有著且現在仍有著自己的機制。Jetty的延續（continuation）就是一個很有名的例子；Java中的許多反向Ajax庫都依賴于Jetty的continuation。其并非什么精彩絕倫的做法，也不需要你的應用運行在Jetty容器上。該API的聰明之處在于其能夠檢測出你正在運行的容器，如果是運行在另一個容器上，比如說Tomcat或是Grizzly，那么如果Servlet 3.0 API可用的話，就回退到Servlet 3.0 API上。這對于Comet來說沒有問題，但如果你想要利用WebSocket的優勢的話，目前別無選擇，只能使用容器特有的功能。

　　Servlet 3.0規范還沒有發布，但許多容器都已經實現了這一API，因為這也是實施反向Ajax的一種標準做法。

　　結束語

　　WebSocket盡管存在一些不足之處，但卻是一個功能非常強大的反向Ajax解決方案。其目前還未在所有瀏覽器上實現，且如果沒有反向Ajax庫的幫助的話，在Java服務器端并不容易使用。因為你使用的不是標準的請求-響應風格，所有你不能依賴過濾器鏈的作用域執行。Comet和WebSocket需要服務器端的容器特定功能，因此在使用新出的容器時，你需要注意一下，它可能沒有做這方面的擴充。

　　請繼續關注這一系列的第3部分，該部分內容將探討用于Comet和WebSocket的不同的服務器端API，你還可了解到Atomsphere，這是一個反向Ajax框架。

　　下載

　　描述　　　　　　　　名稱　　　　　　　　　大小　　　下載方法

　　文章的源代碼　　 reverse_ajaxpt2_source.zip 14KB 　 HTTP

　　參考資料

　　1. “Start using HTML5 WebSockets today”（Nettuts+）：重溫在PHP中如何運行一個WebSocket服務器，并考慮如何構建一個客戶端來通過WebSocket協議發送和接收消息。

　　2. “The WebSocket API”（W3C, July 2011）：這一規范定義的API使得網頁能夠使用WebSocket協議來和遠程主機進行雙向通信。

　　3. jWebSocket支持的瀏覽器：了解jWebSocket和Flash套接口橋所支持瀏覽器的各方面信息。

　　4. 了解更多關于Servlet 3.0對異步處理的支持方面的內容。

　　5. Philip McCarthy的博客上的文章Comet & Java: Threaded Vs Nonblocking I/O中有著更多的內容。

　　6. The Rox Java NIO Tutorial這一教程收集了作者使用Java NIO庫的一些經驗，以及幾十條的訣竅、技巧、建議和充斥著互聯網的告誡做法。

　　7. 在維基百科上了解這些內容：

　　7.1 Ajax
　　7.2 Reverse Ajax
　　7.3 Comet
　　7.4 WebSockets

　　8. “Exploring Reverse AJAX”（Google Maps .Net Control博客，2006年8月）：獲得一些關于反向Ajax技術的介紹說明。

　　9. “Cross-domain communications with JSONP, Part 1: Combine JSONP and jQuery to quickly build powerful mashups”（developerWorks, February 2009）：了解如何把不起眼的跨域調用技術（JSONP）和一個靈活的JavaScript庫（JQuery）結合在一起，以令人驚訝的速度構建出一些功能強大的聚合應用。

　　10. “Cross-Origin Resource Sharing (CORS)”規范（W3C, July 2010）：了解更多關于這一機制的內容，該機制允許XHR執行跨域請求。

　　11. “Build Ajax applications with Ext JS”（developerWorks, July 2008）：對大大增強了JavaScript開發的這一框架有一個大概的了解。

　　12. “Compare JavaScript frameworks”（developerWorks, February 2010）：對極大地增強了JavaScript開發的那些框架有一個整體的了解。

　　13. “Mastering Ajax, Part 2: Make asynchronous requests with JavaScript and Ajax”（developerWorks, January 2006）：學習如何使用Ajax和XMLHttpRequest對象來創建一種永不會讓用戶等待服務器響應的請求/響應模型。

　　14. “Create Ajax applications for the mobile Web”（developerWorks, March 2010）：了解如何使用Ajax構建跨瀏覽器的智能手機Web應用。

　　15. “Where and when to use Ajax in your applications”（developerWorks, February 2008）：了解如何使用Ajax來改進網站，同時避免糟糕的用戶體驗。

　　16. “Improve the performance of Web 2.0 applications“（developerWorks, December 2009）：探討不同的瀏覽器端緩存機制。

　　17. “Introducing JSON”（JSON.org）：獲得對JSON語法的一個入門介紹。

　　18. developerWorks Web development zone：獲得各種談論基于Web的解決方案的文章。

　　19. developerWorks podcasts：收聽各種與軟件開發者進行的有趣的訪談和討論。

　　20. developerWorks technical events and webcasts：隨時關注developerWorks的技術事件和webcast的進展。

　　獲取產品和技術

　　1. WebSocketJS（WebSocket Flash Bridge）：獲取這一由Flash支持的HTML5 WebSocket實現。

　　2. Google Guice：獲取Google Guice，一個Java 5及以上版本的輕量級的依賴注入框架。

　　3. Jetty：獲取Jetty，一個web服務器和javax.servlet容器，外帶對WebSocket的支持。

　　4. Apache Maven：獲取Maven，一個軟件項目管理和包容工具。