反向Ajax，第2部分：WebSocket

時間  2019-11-20
標籤 反向 ajax 部分 websocket 欄目 Ajax 简体版
原文   原文鏈接

英文原文：Reverse Ajax, Part 2: WebSocketsjavascript

 

　　前言html

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

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

　　前提條件git

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

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

　　WebSocketajax

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

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

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

　　圖1. 使用WebSocket的反向Ajax

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

　　清單1. JavaScript中的WebSocket例子

[html]  view plain copy
 
  1. [client] WebSocket connection opened  
  2. [server] 1 events  
  3. [event] ClientID =0  
  4. [server] 1 events  
  5. [event] At Fri Jun 1721:12:01 EDT 2011  
  6. [server] 1 events  
  7. [event] From 0 : qqq  
  8. [server] 1 events  
  9. [event] At Fri Jun 1721:12:05 EDT 2011  
  10. [server] 1 events  
  11. [event] From 0 : vv  

　　一般狀況下，在JavaScript中你會如清單2所說明的那樣來使用WebSocket，若是你的瀏覽器支持它的話。

　　清單2. JavaScript客戶端例子

[javascript]  view plain copy
 
  1. var ws = new WebSocket('ws://127.0.0.1:8080/async');  
  2. ws.onopen = function() {  
  3.     // 鏈接被打開時調用  
  4. };  
  5. ws.onerror = function(e) {  
  6.     // 在出現錯誤時調用，例如在鏈接斷掉時  
  7. };  
  8. ws.onclose = function() {  
  9.     // 在鏈接被關閉時調用  
  10. };  
  11. ws.onmessage = function(msg) {  
  12.     // 在服務器端向客戶端發送消息時調用  
  13.     // msg.data包含了消息  
  14. };  
  15. // 這裏是如何給服務器端發送一些數據  
  16. ws.send('some data');  
  17. // 關閉套接口  
  18. ws.close();  

　　發送和接收的數據能夠是任意類型的，WebSocket可被當作是TCP套接口，所以這取決於客戶端和服務器端知道要來回發送的數據是哪一種類型的。這裏的例子發送的是JSON串。

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

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

[html]  view plain copy
 
  1. Request URL:ws://127.0.0.1:8080/async  
  2. Request Method:GET  
  3. Status Code:101 WebSocket Protocol Handshake  
  4.   
  5. Request Headers  
  6. Connection:Upgrade  
  7. Host:127.0.0.1:8080  
  8. Origin:http://localhost:8080  
  9. Sec-WebSocket-Key1:1 &1~ 33188Yd]r8dp W75q  
  10. Sec-WebSocket-Key2:17; 229 *043M 8  
  11. Upgrade:WebSocket  
  12. (Key3):B4:BB:20:37:45:3F:BC:C7  
  13.   
  14. Response Headers  
  15. Connection:Upgrade  
  16. Sec-WebSocket-Location:ws://127.0.0.1:8080/async  
  17. Sec-WebSocket-Origin:http://localhost:8080  
  18. Upgrade:WebSocket  
  19. (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處理程序

 

[java]  view plain copy
 
  1. public final class ReverseAjaxServlet extends WebSocketServlet {  
  2. 　　@Override  
  3. 　　protected WebSocket doWebSocketConnect(HttpServletRequest request,String protocol) {  
  4. 　　　　return [...]  
  5. 　　}  
  6. }  

 

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

　　清單5. WebSocket實現示例

[html]  view plain copy
 
  1. class Endpoint implements WebSocket {  
  2. Outbound outbound;  
  3. @Override  
  4. publicvoid onConnect(Outbound outbound) {  
  5. 　　this.outbound = outbound;  
  6. }  
  7. @Override  
  8. publicvoid onMessage(byte opcode, String data) {  
  9. 　　// 在接收到消息時調用  
  10. 　　// 你一般用到的就是這一方法  
  11. }  
  12. @Override  
  13. publicvoid onFragment(boolean more, byte opcode,byte[] data, int offset, int length) {  
  14. 　　// 在完成一段內容時，onMessage被調用  
  15. 　　// 一般不在這一方法中寫入東西  
  16. }  
  17. @Override  
  18. publicvoid onMessage(byte opcode, byte[] data,int offset, int length) {  
  19. 　　onMessage(opcode, new String(data, offset, length));  
  20. }  
  21. @Override  
  22. publicvoid onDisconnect() {  
  23. 　　outbound =null;  
  24. }  
  25. }  

 

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

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

[java]  view plain copy
 
  1. if (outbound != null && outbound.isOpen()) {  
  2. 　　outbound.sendMessage('Hello World !');  
  3. }  

　　要斷開並關閉到客戶端的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 三、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. 請求做用域的綁定

[Java]  view plain copy
 
  1. @Provides  
  2. @RequestScoped  
  3. Member member(AuthManager authManager,  
  4. MemberRepository memberRepository) {  
  5. 　　return memberRepository.findById(authManager.getCurrentUserId());  
  6. }  

　　當某個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回調中模擬一個請求做用域

[java]  view plain copy
 
  1. // 在調用doWebSocketMethod時  
  2. // 保存到請求的引用  
  3. HttpServletRequest request = [...]  
  4. Map, Object> bindings =new HashMap, Object>();  
  5. // 我有一個服務須要一個請求來獲取會話  
  6. // 所以我提供一個請求，但你能夠提供任何其餘  
  7. // 可能須要的綁定  
  8. bindings.put(Key.get(HttpServletRequest.class), request);  
  9. ServletScopes.scopeRequest(new Callable() {  
  10. 　　@Override  
  11. 　　public Object call() throws Exception {  
  12. 　　// 調用你的儲存庫或是任何用到做用域對象的服務  
  13. 　　　　outbound.sendMessage([...]);  
  14. 　　　　return null;  
  15. 　　}  
  16. }, bindings).call();  

　　暫停長生存期請求

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

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

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

[html]  view plain copy
 
  1. <?xml version="1.0" encoding="UTF-8"?>  
  2.   
  3. <web-app version="3.0" xmlns="http://java.sun.com/xml/ns/javaee"  
  4. xmlns:j2ee="http://java.sun.com/xml/ns/javaee"  
  5. xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"  
  6. xsi:schemaLocation="http://java.sun.com/xml/ns/j2ee http://java.sun.com/xml  
  7. /ns/j2ee/web-app_3.0.xsd">  
  8.   
  9. <servlet>  
  10. <servlet-name>events</servlet-name>  
  11. <servlet-class>ReverseAjaxServlet</servlet-class>  
  12. <async-supported>true</async-supported>  
  13. </servlet>  
  14.   
  15. <servlet-mapping>  
  16. <servlet-name>events</servlet-name>  
  17. <url-pattern>/ajax</url-pattern>  
  18. </servlet-mapping>  
  19.   
  20. </web-app>  

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

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

[java]  view plain copy
 
  1. AsyncContext asyncContext = req.startAsync();  
  2. // 把asyncContext的引用保存在某處  
  3.   
  4. // 而後在須要的時候，在另外一個線程中你能夠恢復並完成  
  5. HttpServletResponse req =  
  6. (HttpServletResponse) asyncContext.getResponse();  
  7. req.getWriter().write("data");  
  8. req.setContentType([...]);  
  9. 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，一個軟件項目管理和包容工具。

　　5. Java Development Kit, Version 6：得到Java平臺標準版（Java Platform, Standard Edition，Java SE），該平臺容許你在臺式機和服務器上，以及在當今要求苛刻的嵌入式環境上開發和部署Java應用。

　　6. 免費試用IBM軟件，下載使用版，登陸在線試用，在沙箱環境中使用產品，或是經過雲來訪問，有超過100種IBM產品試用版選擇。

　　討論

　　1. 如今就建立你的developerWorks我的資料，並設置一個關於Reverse Ajax的觀看列表。與developerWorks社區創建聯繫並保持聯繫。

　　2. 找到其餘在web開發方面感興趣的developerWorks成員。

　　3. 分享你的知識：加入一個關注web專題的developerWorks組。

　　4. Roland Barcia在他的博客中談論Web 2.0和中間件。

　　5. 關注developerWork成員的shared bookmarks on web topics。

　　6. 快速得到答案：訪問Web 2.0 Apps論壇。

　　7. 快速得到答案：訪問Ajax論壇。

相關文章
相關標籤/搜索
每日一句
    每一个你不满意的现在，都有一个你没有努力的曾经。
本站公眾號
   歡迎關注本站公眾號,獲取更多信息
聯繫我們 最近搜索 最新文章 沪ICP备13005482号-10 MyBatis教程 SQL 教程 MySQL教程 Java 教程 Thymeleaf 教程 Hibernate教程 Spring教程 Redis教程