基於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，你會從這個過程中收穫更多。
第二，對於一個開發團隊/組織來說，真正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服務器端控件的融合。最後歡迎大家斧正。