載csdn)兩位華人Ajax開源架構創始人揭示Ajax架構選擇奧秘

AJAX 已流行二、三年了，現今所謂 Web 2.0 網站或多或少有 AJAX 影子。然而新的 AJAX 架構仍不斷誕生，現有的架構也在持續推出新的版本。為什嗎？

　　首先，AJAX應用範圍持續擴大，從 del.icio.us 簡易的編輯功能，到 999fang.com 整合 AJAX 和資料庫搜尋，到 Google Spreadsheets 近似 Windows 應用程式。再者，AJAX已緩步進入公司專屬應用程式。
除了User Friendly，安全、開發及維護成本、與現有應用伺服器、服務和開發環境的整合度等更是公司專屬應用程式的重點。這些都已跳脫早期架構的範疇。

　　目前 AJAX 在公司專屬應用程式正處於 Geoffrey Moore 所謂的Chasm中，預期接下二年會慢慢大量投入使用。而在消費型網站的應用正走過高成長期，聚光燈的焦點將逐漸移到如Google Spreadsheets的應用。

　　在這種背景之下，AJAX架構如雨後春筍，層出不窮。很多開發人員朋可能都有自己的偏好，但是仍有一些開發人員面對這麼多架構，可能會感覺無從下手。我們可以從多個面向來看這些架構。

　　從功能面來看，可分為以下幾類：

　　1、瀏覽器端的底層連結庫，如 Prototype, script.aculo.us, jQuery 等。

　　2、瀏覽器端UI組件庫，如 Ext-JS, Dojo 等。

　　3、整合式架構，如 ZK, Backbase, IceFaces 等。

　　其中，底層連結庫應用最廣、輕巧易整合力但功能有限。整合式架構則包括瀏覽器端及伺服器端的完整架構。

　　DWR和GWT則較難分類。DWR基本是JavaScript-to-Java 的 RPC架構，而GWT則是在RPC 加上瀏覽器端開發工具。

　　從應用面來看，可粗分網站應用程式和公司專屬應用程式。底層連結庫多用於網站應用程式或當其它架構的基礎。UI組件庫則二者都有，而整合式架構側重在公司專屬應用程式。

　　從系統架構來看，可分Client-centric和Server-centric。所謂 Client-centric 是指你寫的程式碼(UI部份)主要執行的地方在用戶端 (即瀏覽器)，而 Server-centric 則在伺服器端。大部份架構多是 Client-centric，如Dojo, Prototype，GWT，Ext-JS，Backbase等。而Server-centric則以ZK為代表。

　　一般讀者不太注意架構的差別，但它是決定開發及維護成本的關鍵。

　　讀到這裡，可能仍有人心存疑問：到底哪種架構適合我的應用程式？事實上，沒有單一個架構適合所有應用。對於強調簡易直覺介面的Web 2.0網站而言，通常只有幾個需要 AJAX化的功能，可藉由瀏覽器端的底層連結庫的協助，並投入相當資源，以使這些AJAX 化出眾奪目才是最重要的。對於現有Web應用程式，如架構於Struts、JSP或JSF等，則可依其對JavaScript熟悉度而選擇瀏覽器端UI組件庫或整合式架構。使用瀏覽器端 UI組件庫，需要較多定製化JavaScript程式碼才能整合到原應用程式中。而使用整合式架構，則要視其是否支援現已使用的架構。例如，若使用.NET平台，則只能使用 Microsoft的架構。若使用JSP則可使用ZK和Backbase。若使用JSF則可使用ZK，Backbase和IceFaces。

　　利用ZK架構設計的Web應用程式具備豐富的胖用戶端特性和簡單的設計模型。ZK包括一個基於AJAX可自動進行互動式操作的事件驅動引擎和一套相容XUL (XML User-interface Language——基於XML的使用者介面語言)的組件。利用直觀的事件驅動模型，你可以用具有XUL特性的組件來表示你的應用程式並通過由使用者觸發的監聽事件來操作這些組件。目前，ZK 3.0 版本發行。提供了基於XUL和XHTML現成豐富的組件：網格、標籤頁裝飾器、樹形目錄、組合框、圖表、捲軸、分割條、音頻等等。此外，還提供了宏組件，能夠開發新組件像搭積木一樣簡單和方便。編寫指令碼(Script)功能可以用EL expressions和你偏好的指令碼語言，包含但不僅限於Java、JavaScript、Ruby、Groovy和MVEL的語言。值得一提的是，最新版本還整合了Google Maps, FCKeditor, Dojo以及 Timeline，並且提供對Google最新發行的手機操作平台Android的開發支援。

　　有人預測，Silverlight、Flex等RIA架構的出現，將對AJAX架構構成嚴重威脅，我的看法剛好相反。Silverlight、Flex等是大型軟體公司企圖以私人 protocol 壟斷新興市場的老方法。然而網際網路的巨大並不是任何人所能控制的。感謝Tim Berners-Lee等人無私的貢獻，網際網路已成為最公平最開放的平台了。事實上 Flex 不久前才剛轉為 Open Source，這對定價超過一萬美元的軟體，算是個重大的挫敗。

　　陳金洲觀點

　　毫無疑問，AJAX被越來越多的接受。這不僅僅體現在技術的應用上，更體現在行業範圍內的需求提升上。Web應用這種類型不僅僅被用在企業業務系統，更多被用在Web2.0應用中。這些應用意味著以前只能被幾十人幾百人使用的系統，突然之間會有幾十萬幾百萬的使用者。使用者有了更多選擇，能夠吸引使用者駐留的，除了華麗的介面，那麼就是流暢的操作介面和快速的響應。作為實現不打斷使用者操作的關鍵技術AJAX, 從吸引使用者這一點上，具有不可替代的使命。

　　意味著華麗、AJAX的Web2.0應用同樣也衝擊著公司專屬應用程式的需求。雖然沒有統計資料，但可以看到越來越多的公司專屬應用程式要求更直觀的介面，更流暢的操作，更少的延遲。例如，在前兩年，級聯下拉框的實現，大多數的架構（或者應用）的實現是選中一個時重新整理整個頁面，然後根據選中的那個更新下一個下拉框的待選值列表。這個實現在今天看起來幾乎是完全不可接受的，無論對客戶還是對開發人員。

　　開發人員這邊，去年還有關於AJAX幾宗罪的討論，然而現在看來，更多的討論沉浸到了某一個具體技術中。在認清AJAX技術本質之後，更多的開發人員或欣然接受，或使用者要求，開始了AJAX相關技術的學習和使用。從我周圍看來，曾經認為JavaScript是不太入流的語言的程式員，現在已然逐漸發現，JavaScript很有趣，很強大；用JavaScript實現很酷的網頁效果，很有成就感，等等。

　　另外， AJAX這個詞本身，早已遠遠超越了它所代表的本來含義。AJAX原本是非同步JavaScript和XML。然而一看到一個絢麗的網頁（Web應用），幾乎大多數人，具備Web相關知識的，第一個問題往往是：這用的AJAX吧？──AJAX現在幾乎成為圓角、拖拽、絢麗、無重新整理的代名詞。當一個名稱上升為一種概念、一種直覺的時候，我們應該知道，相關的技術應用到了什麼程度。

　　現在幾乎已經沒有人手工與XMLHttp對象打交道，絕大多數的開發人員都使用Buffalo, DWR, Prototype等輔助庫、架構進行開發。

　　AJAX架構的選擇

　　由於現在很少有人只用一種AJAX技術，我將AJAX架構的範圍擴大一些，分為偏重展現、偏重傳輸、工具型三個部分。由於我自己的Web工作語言主要在Java, Ruby以及Python之間，以下的評價不包含PHP, .NET下的一些工具。另外，對自己開發的和它的主要競爭者DWR有主要的比較，其他的僅作泛泛評述，估妄言之。

　　偏重展現：YUI, Qooxdoo, Dojo

　　·YUI ：目前設計比較完整，美觀，全面的介面工具庫。

　　·Qooxdoo: 開源的另一種選擇。

　　·Dojo: 比較完善的庫結構，豐富的介面控制項。

　　偏重傳輸：Buffalo, DWR

　　Buffalo特性：

　　1、基於prototype。如果你的AJAX應用也是基於prototype，那麼可以減少重複載入prototype的頻寬，並且獲得相當一致的編程概念。

　　2、Bind: 提供了對結果資料的處理，直接將資料繫結到頁面對象並展示，這是一個動人的特性。在2.0中，Bind能力更加強大，能夠將值直接綁定到表單元素、表格、DIV/Span、甚至整個表單上。關鍵是這種綁定是無侵入並且與buffalo整體結構完全整合，對外表現只有一個簡單的{{buffalo.bindReply}}或者{{Buffalo.Bind.bind}}即可。

　　3、序列化：Buffalo支援任意對象，任意深度，任意資料結構的Java到JavaScript以及JavaScript到Java的雙向序列化，並且支援引用。

　　4、生命週期對象訪問：1.2.4之前需要繼承一個BuffaloService,從1.2.4開始就不需要繼承了，引入了安全執行緒的BuffaloContext對象，只需要通過BuffaloContext.getContext()即可獲得一個安全執行緒的引用，並且對Request的各種屬性進行操作。

　　5、對Collection/Array的模糊處理：Buffalo中提供了對Collection/Array對象的模糊識別能力。例如：伺服器端有一個方法需要List參數，用戶端傳遞過去一個javascript數組就可以了，不需要費心的組裝對象。

　　6、用戶端組裝對象：Buffalo支援在用戶端組裝對象，甚至可以直接將整個表單序列化為一個對象作為參數傳給遠程用戶端。

　　7、對重載方法的處理能力：由於Java與JavaScript之間類型的不匹配，DWR的代碼產生無法對重載方法進行處理。例如，sum(double,double), sum(int, int) DWR很可能不知道你要調用哪一個。從2.0開始Buffalo支援了對重載的處理。

　　DWR特性：

　　1、支援Batch，可以將多個Service函數調用放在一個XMLHttpRequest請求中完成。

　　2、Converter：可以轉換任意類型的Java對象到JavaScript，並允許直接使用。例如：Customer類包含一個address變數，當AjaxCall返回Customer對象的時候，可以直接在Javascript中使用customer.address來獲得Address的資訊。

　　3、允許Expose部分函數和屬性。（Buffalo無限制，可以訪問Service中的任意函數。）

　　4、DWR2.0中提出了Reverse Ajax，提供在Java代碼中來處理頁面上元素的功能。

　　工具型：Prototype, JQuery, Dojo

　　·Prototype：得益於Ruby語言的設計，它使得你能夠以幾乎類似於編寫Ruby的方式編寫JavaScript。由於綁定在Ruby On Rails的發行包中，它成為近兩年最流行的AJAX工具。早期它小巧靈活，現在由於加入太多的特性，日漸臃腫。目前1.6版本大小已經超過120K。

　　·JQuery：Prototype的主要競爭者。簡單是它最大的優點。大多數常見的複雜操作、效果，JQuery的代碼量能夠比Prototype少50%以上。

　　·Dojo：採用類似於Java包的管理方式，實現按需載入JS。提供了全面的AJAX、DOM操作支援。然而需要在HTML TAG中嵌入額外的屬性，使得網頁不能遵守W3C標準，不少開發人員對此耿耿於懷。

　　來自RIA架構的衝擊？

　　我並不贊同這種說法，恰恰相反，我認為像Silverlight，Flex等這些RIA架構要考慮來自Web應用的衝擊。Web領域幾乎已經不存在技術壁壘，能做哪些，那些不適合，負載平衡等等已經有充分的資源可以參考。各種模式都可以靈活的應用到其中，各種測試載入器（如Selenium網頁測試載入器）、開發工具支援得非常出色。而RIA架構要考慮的問題遠遠要比現在的Web應用多得多。
除了RIA所承諾的更容易的實現華麗的效果──在多種JS庫的支援下這些效果在Web下並非難事──他們有更多的問題需要考慮：資源的擷取和釋放，測試的支援，本機存放區的問題，事件機制，狀態的同步，客戶機、伺服器資料互動機制（序列化還原序列化）等等。RIA想如同現在的Web應用般大規模，遠不到時候。大多數基於RIA應用的考慮是讓應用能夠離線運行，然而與此同時瀏
覽器也在發展，基於網頁的本地存貯已經在Google Reader中可以實際使用。也許某一天瀏覽器就是一個完美的RIA平台，Web應用只需添加本地存貯支援就可以離線使用──類似於Flex、Silverlight的RIA技術，與Web應用，哪個更容易被接受，還真難見分曉。