ajax|策略|技術平台
基於Ajax 架構的Web應用程式框架
之前我提到過"似Ajax" 的架構，現在我要說的Ajax架構也就是指專門針對這種Ajax架構而提供的架構。目前，我還沒有聽說過特別好的這個領域的流行架構。但我知道我的身邊，.NET領域，J2EE領域或PHP平台上都有這樣的架構和應用，我認為，正是因為有很多這樣應用，所以Ajax才會像某個模式一樣，被撰有一個專門的名詞。不過我感覺Ajax 漸漸層成了Ajax feature的代名詞，變成了XMLHTTP的代名詞，成了非同步通訊，不重新整理頁面的技術標記法。直到我看過Ajax in Action這本書，我才把Ajax和系統的架構、設計模式，分布式對象的序列化和我之前的項目和經曆聯絡在一切。
我修改了一些Jesse的圖，來說明我認為的基於Ajax的架構是什麼樣的。
這也就是我上面說的“似Ajax”架構，首先它是一個Web應用；它的表現層用DHTML＋CSS ＋ HTC控制項＋ Javascript ，伺服器端用.NET或任何的伺服器端技術，中間以XML方式序列化和還原序列化進行傳遞資料。
簡單的說，用戶端需要將請求的資料封裝成一個XML資料通過HTTP傳遞給伺服器端，伺服器端處理這個請求，並將結果也以XML的形式返回到用戶端，用戶端再處理這些請求，然後使用HTML+CSS進行展示。其實如果不是Web用戶端(瀏覽器)的問題，這是最簡單的架構，但關鍵問題在於上面我們說的Javascript端的對象封裝成一個XML，以及到服務端解析XML變成伺服器端對象，然後再將結果封裝成XML，傳回給用戶端(Javascript)，用戶端也解析XML資料，然後變成Javascript 中的對象的這個序列化和還原序列化的問題。另外一個問題就是表現層的展現問題，怎麼展現，用什麼控制項？
所以，一個Ajax架構的Web應用程式，必須解決下面的問題：
1. 雙向兩路的序列化問題
2. 表現層展現的問題
3. 傳輸時用戶端和伺服器端的資料安全問題
4. 效能問題
5. 國際化支援
最好玩的雙向兩路的序列化問題，最早接觸的是JSON ，它的問題在於擴充性，資料類型的支援和效能，但是平台無關性比較好，什麼瀏覽器都可以，因為它不需要用msxml2.DOMDocumen分析XML，本質上就是用字串描述對象；之後多平台的應用的遷移經曆中(比如CORBAR，J2EE的後台應用)，開始接觸到XML-RPC ，ICE，Hessian，Web Services等等。其中XML-RPC有Javascript 的支援庫，Web Services也有Javascript的支援庫，也就是你可以使用Javascript訪問或者獲得XML－RPC/Web Services的對象，但是如果你將其作為一個主要的通訊協議，那麼就會遇到另外一些問題，比如效能、國際化的問題，又會困擾你，XML-RPC和Web Services的一個主要問題都是效能，因為他們傳輸的XML大小都太大了，但顯然用這些實現一個Ajax的特性，那是完全沒有問題了。
比如，Atlas目前不也是使用一個Javascript庫調用Web Services嗎？，所以，你也可以這麼做，同樣你也可以用XML-RPC.NET 很快就可以實現一個Service，然後使用Scotandrew的XML-RPC javascript 庫就可以在Javascript中發一個XML-RPC 訊息請求這個服務，然後非同步獲得這個結果，然後展現它。所以從技術的實現上講，Ajax的特性非常容易實現，但從架構上來看。你需要思考更多的因素。當然直到最後，我們才發現，在項目中，最完美的方案是你自己寫一個雙向兩路的序列化引擎供你的Javascript用戶端使用。
這就說到了第二個問題，介面表現的問題，這個問題也是一個大的問題。這個問題一直會永遠存在，Ajax之前沒有人會太注意這些，但今天不同了，我想未來還會有很大的一個飛躍， Yahoo! 不是最近也開源了他的Yahoo! Web UI庫，Atlas 也表示要提供更多的前端UI控制項。無論如何，這個問題是，你的團隊或組織是否有一套經過項目或客戶檢驗的前端Javascript的庫。無論是自己用Javascript寫的也好，是自己寫的一套HTC的控制項陳列庫也好，總之這些是Ajax 架構中非常重要的一環。
Atlas 帶來了另外一個思考問題，就是伺服器端控制項可能可以通過某種方式和Javascript的控制項很好的整合在一起，以前我們用HTC解決了重用、效能、Behaviors、甚至模板功能。但是新的特性還是有比如資料的綁定、緩衝和校正、甚至是資料編碼和壓縮、加密和解密，Javascript UI前端還是有許多可以做的，而且如何無縫的整合兩者，這個有非常大的意義。
接著安全、效能、國際化等等，架構中的問題需要你依次考慮和解決，如果這麼看Ajax，我認為，目前的Ajax架構還有很長很長一段路要走，同樣真正完美支援Ajax架構的還需要繼續努力。這些也是我在這篇專欄文章中的觀點。
把這些合在一起，那麼Ajax架構的開發包或架構，就應該是包含了上述幾個問題(兩路雙向的序列化、Javascript UI 表現庫、安全、國際化和效能等等)解決方案的一個平台實現。
同樣也許你會說，不就是Ajax嗎? 我幹嘛要搞這麼複雜，一定要搞到架構這個層面。
我認為，
第一，從架構的層面看Ajax，然後再應用相關的技術，比你直接使用某個Ajax架構然後再理解Ajax，你會從這個過程中收穫更多。
第二，對於一個Team Dev/組織來說，真正Ajax架構的產品，可以帶來效益和具體的生產力。比如，我身邊就有擁有這樣的優勢的團隊，他們擁有一套統一的由Javascript+HTML+CSS+HTC的前端表現層，而背景業務系統有兩個平台，一個.NET平台和J2EE平台；同樣我身邊的也有這樣的團隊，他們擁有一套統一的由Javascript+DHTML+CSS+HTC＋VML+ASP.NET的前端表現層，但他們的後台業務層分別來自.NET平台、J2EE平台和Unix平台，我不能說Ajax架構的應用似乎就是統一Web 表現層。因為從今天看到他們的明天，也許會是, 一個ASP.NET V2+Atlas 的統一表現層，一個統一CAB+Smart Client 的統一表現層，也可以是一個WPF 3D的統一表現層，也可以是一個Xgl 案頭的統一層......
第三，從這架構的層面上，你也能夠非常容易理解SOA或ESB概念，和SOA相比，Ajax架構的區別在於，Ajax有足夠的鬆散耦合，但它依然以應用的資料為中心，更多的是一個面向Messages的架構，而且對於流行的WS-*協議的支援非常有限。
但是假如，今天你或你的團隊已經有了一個Ajax 架構的應用，那麼你是不是應該要小心選擇現有的Ajax架構，因為這些Ajax的特性，相對於目前的架構來說，是多麼小，但又可能會產生很大危害的一個因素。也許這樣的團隊並不多，也許也很多，但是只有我們從更高更深的層次來思考，那麼我們就能做出正確的選擇，並且從新的Ajax技術和研究中獲得好處。
結論
當我們回到文章的起點，我希望這樣能夠說明的我觀點，即Ajax-NET的架構或實現分為兩類，一類是基於Ajax應用程式架構的，一類是基於Ajax特性的，目前幾乎大部分的Ajax-NET的架構或實現都是基於Ajax特性，以Add-in 方式提供的代碼或架構。
Ajax-NET的實現/架構選取上的建議：
ASP.NET控制項形式已經成為串連伺服器和用戶端Ajax通訊的主要形式和選擇。
用戶端調用伺服器端頁面中的方法是Ajax的重要手段，使得用戶端可以更加靈活的獲得伺服器端的資料。
MagicAjax.NET，Anthem.NET用了"Hook ASP.NET"和Add－In的技術手段，使用上受到的影響比較多，這兩個架構中，最簡單的應用，第一選擇MagicAjax.NET，但總是優先使用Anthem.NET。
如果是自己寫的伺服器端控制項，那麼應該先掌握Anthem.NET的技術，然後使自己的控制項擁有Ajax的特性。
MagicAjax.NET, Anthem.NET和wwHoverPanel 對於國際化的支援都有待加強。
在Atlas沒有正式發布之前，在ASP.NET的應用中優先在自己的項目中使用類似wwHoverPanel的技術，即儘可能的使用用戶端回調功能，在特別需要的地方使用其方法調用的功能，充分發揮Ajax的特性，而不要因為Ajax而特意選擇某個Ajax的架構。
Atlas的強項在於伺服器端和用戶端控制項特性的整合、用戶端的資料繫結、校正、內建的多個用戶端Ajax 特性UI或組件，與ASP.NET的Profile, Membership ,Role 服務的整合，與Web Services和WCF 服務的整合，以及良好的國際化/開發工具支援的。因為它是一個完整的解決方案，所以最大的弱點是不能很容易地被老的Ajax架構的應用使用。另外該產品目前還在不斷開發中，距離部署到生產環境中的要求還有差距。
輕量級的雙向序列化可以考慮JSON格式，安全問題可以在傳遞的對象中增加欄位，然後在伺服器端進行校正。
對於原來已經有一套序列化架構的組織來說，其主要的目標是儘快將這個架構遷移/升級到ASP.NET V2，而不是優先考慮實現某個Ajax的特性。
Ajax 要求有足夠的力量關注前端的UI展現或開發，所以對Ajax實現/架構的選擇，最先要考察其用戶端的實現以及提供的Web UI。
看完這篇文章，我希望，今後我們再談起Ajax的時候，作為技術人員，我不用談論什麼Web 2.0，我一樣可以清楚的表達Ajax的概念
如果你是一個架構師，Ajax 不再是什麼非同步XMLHTTP調用，不再是不重新整理頁面，它可以幫忙你Review應用程式的架構。
對於你的團隊或老闆來說，Ajax可以是你統一介面表現層的一個策略，同樣也可能讓你有了一個建立一套部門或公司級能夠重用的UI類庫的機會。
同樣對於Javascript的開發人員來說，Ajax讓你們還需要瞭解一些業務，並證明前台的Web開發人員一樣很昂貴，後台開發也可以是技術含量不高的。
對於SOA的愛好者來說，Ajax架構讓你能夠站在面向訊息的架構和系統上來看面向服務；一般我們說，對內你首先要有一套面向訊息的架構，然後對外你就很容易延伸成一個面向服務面向Internet的分布式架構。
最後，不要討論Ajax的消亡，因為Ajax對於程式員來說，是一種力量均衡的策略，在Ajax中，Web前端的開發人員被重新重視，成為一支重要的力量。
後記
寫這些文字的某幾個段落，讓我有些痛苦，因為我本來沒想些這麼多。所以你不要太在意我對各個架構的評價和描述，這些都是技術的層面的東西，其實我寫這篇文字，主要是想突出Ajax的架構觀，以及設計模式和Web應用架構重構的考慮，續而你也能夠用類似橫切面的角度，用Ajax來看你目前的應用和架構，從而更深的瞭解分布式對象的序列化、效能、安全以及Ajax 和ASP.NET伺服器端控制項的融合。最後歡迎大家斧正。
- Ajax: 一個建立Web應用的新途徑
- Ajax的錯誤處理機制探討(2)
- Ajax的錯誤處理機制探討(1)
- 初次體驗.NET Ajax無重新整理技術
- Rails系統中的AJAX開發技術簡析(4)
