使用DWR反轉AJAX的失敗經驗和教訓 過去一周，我試圖使用DWR的反轉AJAX功能，開發一個基於Web的頁面即時通訊系統，但是失敗了。出現的技術障礙是，除了當前得到的ScriptSession外，想盡辦法得到的其他ScriptSession，都像是被閹割過的，根本不能夠從伺服器端向用戶端發送訊息和JavaScript代碼。可能是因為，DWR的反轉AJAX功能是使用定時輪詢實現的，如果用戶端瀏覽器不發起輪詢，伺服器端再怎麼做都是沒用的！這樣，點對點通過Html頁面通訊，就無法實現了。只能夠實現DWR提供的例子那樣的Web聊天室的應用。下面，總結一下發現的瀏覽器和DWR反轉AJAX功能的Bug和一些經驗。 一、IE是能力最差的瀏覽器，Firefox不錯其他瀏覽器，還沒有試過。1，反轉AJAX的功能，在Firefox上能夠得到正確的應用，但是，在IE上，就無法實現即時的頁面接收。2，IE是最不符合規範的瀏覽器。DOM的實現也不夠規範，使用標準的DOM方法，在Firefox中正確顯示，但在IE7中卻毫無作用。當然，這並不是大問題，還是有一些辦法可以克服IE的缺點的。 二、DWR的反轉AJAX功能1，除了當前得到的ScriptSession外，想盡辦法得到的其他ScriptSession，都像是被閹割過的，根本不能夠從伺服器端向用戶端發送訊息和JavaScript代碼。2，DWR架構的
DwrUtil
類DwrUtil類是一個伺服器端的代理類，允許Java程式員調用用戶端的Java代碼。這個類實際上只是一個助手類，它實際上是使用ScriptSession的Script欄位，向用戶端發送特定的JavaScript代碼而已。這個類的存在，僅僅是方便了使用者使用一些常見的功能而已。3，DwrUtil類和ScriptSession類，缺少區分向哪一個瀏覽器的哪一個頁面發送JavaScript代碼的能力。這造成了嚴重的問題。1）缺少區分瀏覽器的能力，就不能夠實現瀏覽器使用者的點對點之間的通訊。2）即使我得到了ScriptSession,它們也失去了向用戶端傳輸JS代碼的能力。3）不能區分頁面，這樣，就會發生伺服器傳輸的資訊發祥錯誤的頁面的情況。如果2個頁面沒有相同的頁面元素，會報缺少頁面元素的錯誤。如果2個頁面的元素一樣，那麼就會發生顯示錯誤的資訊的情況。 總之，現在DWR的反轉AJAX功能還有很大的不足！ 三、DWRDWR提供了使用JS遠程調用Java類的功能。這是一種RPC遠程調用的機制。類似於RMI等遠程方法調用。每一個發布的Java類都會自動產生一個對應的JavaScript類。這個javaScript類，是遠程Java類的本地存根，是一個代理類。它們簡單的通過XMLHttpRequest對象，調用伺服器端的Java類的對應方法，然後把結果返回。DWR對於廣大的Java程式員來說是一大福音。不必學習和編寫複雜的JavaSript代碼和AJAX代碼，只需要編寫Java類和方法，就能夠完成大部分的AJAX應用。另一方面，DWR這樣的遠程RPC調用，存在安全問題，這和其他遠程調用機制是一樣的，必須要有安全機制的保證，才能夠真正運用。DWR已經提供了安全機制。不過我還沒有細看JDWR的遠程調用機制，需要採用與其他遠程調用機制一樣的編程模式。那就是，應當遠程發布粗粒度的Java類和方法，而不應該公布細粒度的對象，否則將會造成嚴重的效能問題。如，應該公布業務模組的服務層的類，或者是表現層的業務委派層的業務委派類這樣粗粒度，面向具體應用的類。絕不能夠公布資料訪問層的類。那些類是細粒度的。而且，使用資料訪問類的方法，能夠實現對資料庫的CRUD操作，將會造成嚴重的安全性漏洞。要記住，DWR的用戶端是瀏覽器。任何人都能夠在自己的機器上編寫JS代碼，然後遠端存取我們發布的Java類。不進行安全控制，是絕對危險的！ 我對DWR架構，也只是略知一二，看來有必要對DWR架構進行深入和系統的學習和研究。研究和發展DWR的反轉AJAX功能。必要的時候，自己創造這樣一種反轉AJAX的功能。如，使用定時器，定時使用AJAX非同步查詢服務器的方式，我想，DWR可能也是這樣實現反轉AJAX功能的。
