2. Anthem.Net
目前是1.0版本，其設計理念是通過另外一個思路，遵循這樣的理念--既然ASP.Net的各個標准控件沒有實現提交功能，那麼我可以產生一個提交的接口，然後繼承原來的標准控件，然後再實現這個接口，這樣每個控件都可以向服務器端單獨進行提交。
每個控件的發生過程類似MagicAJax.NET，Anthem.NET提供了各個控件Javascript端的提交函數－這等於也截取了__doPostBack，之後Anthem.NET 還提供了完善的客戶端的事件比如PostCallBack 和PreCallBack 這樣的客戶端事件，之後也將使用XMLHttpRequest 模擬一個傳統的頁面提交請求到服務器端，服務器端生成頁面實例，這個過程和MagicAJax.Net一樣，最後是將Rendered的HTML在控件的Render() 事件傳回到客戶端，客戶端控件的innerHtml被賦值，動態更新。
和MagicAJax.NET不同的是，Anthem.NET沒有容器的概念，因為每個控件都增加了提交接口，所以可以單獨的提交，所以單位是以一個控件為單位進行一次提交，Anthem.NET的花費更小些(但服務器端是類似的，因為整個ASP.Net頁面的Pipeline都會進行)。
此外，Anthem.NET 還有另外的功能，就是可以通過客戶端調用頁面中的方法並獲得結果/數據，這種情況下，你將調用Anthem_InvokePageMethod 方法，而不是Anthem.Net提供的默認各個控件的提交方法。這樣Javascript的回調處理函數中的result.value 將可以獲得調用的服務端的某個方法(該方法以[Anthem.Method]為標記)的執行結果，因為JavascriptPost的數據中有Page/MasterPage/Control 了，那麼服務器端很容易通過這個標識獲得方法的地址，應用反射尋找[Anthem.Method]標記，然後調用，將結果返回到客戶端。
Anthem.NET支持返回對象，DataSet，DataTable和 WriteDataRow(WriteDataSet,WriteDataTable,WriteDataRow,WriteObject)，返回的是符合是JSON規范的字符串，這樣客戶端的Javascript就可以使用這些對象了。不同於MagicAJax.NET，Anthem.Net 沒有使用HTTP Model，所以結果是在頁面的PreRender() 事件中處理和返回請求的結果。
2.1 AJax.Net Professional
我沒有看過Ajax.NET Professional 的源代碼，但從例子中看得其支持調用頁面的某個方法，以及返回對象，DataSet，DataTable的數據，我認為Ajax.NET Professional 的實現和Anthem.NET 原理是一樣的，雖然Ajax.NET Professional 使用了HTTP Model，這個只是和Anthem.NET 一樣，最終處理結果的返回處理上稍有不同不同。比較起來，AJax.NET Professional 沒有重新繼承所有常用的ASP.NET控件實現部分提交的功能，所以可能AJax.Net Professional 比較強項的是調用頁面上的某個方法，並在客戶端獲得結果的數據，這個已經夠實現大部分的AJax的功能了。
從這個層面上看，我認為Ajax.NET Professional 是相對笨重和復雜了。Anthem.NET不使用HTTP Model，提供控件基本的局部提交，也提供數據層面的客戶端方法調用。AJax.Net Professional 的源代碼似乎總是不想共享 ，這也是我不喜歡它的另外一個原因。
無論如何，大家都沒有提供兩路的數據交換，即客戶端可以獲得服務器端的方法並獲得結果和數據，但是目前都支持將這些對象/數據修改之後返回給服務器端。
Anthem.Net 的一些不足和想法：
1) Anthem.NET 也是一種"Hook ASP.NET"原理，旨在彌補ASP.Net的整頁面的提交和PostBack，並且在客戶端的數據訪問和交互上做了加強。
2) Anthem.NET需要重新將ASP.Net提供的控件進行繼承和包裝，所以使用和功能的兼容性上非常敏感。
3) 也許微軟下個版本的ASP.NET的標准控件可以借鑒Anthem.Net的做法，給各個控件增加這個遠程回調的接口。
4) 目前版本的功能已經非常強大和略有些復雜了，而且部署比較方便，無需設置HTTP Model。
3. wwHoverPanel AJax Control for ASP.Net
wwHoverPanel AJax Control for ASP.NET 這也是一個ASP.Net的控件，但是提供了客戶端回調(高級回調)、客戶端調用頁面方法，以及雙向兩路的序列化功能。
wwHoverPanel 吸取了MagicAJax.NET 和 Anthem.NET的優點，同時又結合了ASP.Net的客戶端回調功能，是一個輕量級的AJax組件。
看待wwHoverPanel 最大的兩個特性中的一個是用很簡單的方式實現了一個HoverPanel Behavior，這個實現比目前Atalas的Behavior 要簡單，作者Rick Strahl 也強調這個主要是結合他具體的應用，比如這裡提供了一個小的Html板，可以顯示獲得的結果信息。
wwHoverPanel 也提供一個局部回調的方法，但是這點的實現上和MagicAJax.NET 以及 Anthem.NET完全不同，它是使用一個StartCallback的Javascript來組合查詢字符串提交並且使用XMLHTTP發請求到服務器的某個頁面(由ServerUrl 屬性指定)，之後這個頁面將結果以Response.Write()的原生Html內容返回。這個和ASP.NET的回調方法非常類似，而且還支持將請求發到本頁之外的ASP.NET並獲得結果，所以它增強了原來ASP.Net的客戶端回調的方法，即支持其它頁面的回調。可以說，這是一種基於URL的客戶端回調。
wwHoverPanel 提供的第二個功能是，客戶端可以調用服務器端中的某個頁面的方法(這些方法以[CallbackMethod]進行標識)，這種情況下，你要設置EventHandlerMode="CallPageMethod" ，然後使用wwHoverPanel.服務器方法名(參數，參數，...，回調處理函數)的方式進行調用。這個其實使用的是一個Javascript的CallMethod 方法，調用服務器端的請求。Javascript 的HandleCallback 則用來處理返回的結果，邏輯相對簡單，盡管控件的innerHTML 也被賦值，但這個主要是為了維護作為客戶端回調結果顯示的小的Html板的內容，否則就是調用頁面中的方法了，那麼結果就直接給客戶端的回調方法了。
特色三，就是我說的雙路的序列化功能了，其實這個場景我們也非常需要，比如我們用客戶端回調或XMLHTTP請求獲得了一個定單對象，那麼客戶端修改之後，我還想把它作為一個客戶端調用的輸入參數，返回到服務器端。這時候兩路雙向的序列化就需要了，因為這次服務器需要將Javascript的函數傳了的數據序列化成.Net的類。這也就是JSON的雙向序列化了(主要代碼在JSONSerializer.cs )，這也是我挺喜歡的一個功能，因為我對這個功能關注很久，但是目前流行的AJax-NET的框架都不支持這個功能。
目前在wwHoverPanel 的場景中，我認為這是一種輕量級的實現，對於多層嵌套多組引用的對象圖類型或是大規模容量訪問壓力下，客戶端和服務器端都還需要優化，所以如果其作為AJax架構，客戶端和服務器端通信和傳遞數據的通訊層上，顯然是有些單薄了。
wwHoverPanel 的一些不足和想法：
1) 該控件是目前我見過.Net平台下，惟一同時支持客戶端回調和頁面方法調用的AJax 控件，同時又支持兩路雙向的序列化。
2) 相對來說，wwHoverPanel是設計最簡單的一個，而且是基於控件不依賴HTTP Model和ASP.Net Page Pipeline，也不依賴VIEwState
3) 該控件能夠讓你在AJax特性實現的技術層面上，能夠在客戶回調和客戶端調用頁面方法兩者中取得平衡。
4) 目前的客戶端回調支持其它頁面的回調，但是其結果輸出需要輸出原始的Html，這個影響應用的分層和設計。
5) JSON的雙向序列化是一個不錯的方案，但高性能的場景下，應該考慮實現更高效的序列化框架
4. Atlas
這個產品，我就不列舉具體的功能了，而主要說一下我對其的看法和持有的態度。因為在我的AJax書評中提到過問題。
Atlas 是一個個性鮮明的產品，其優點是明顯的，缺點也是明顯的，但首先你必須認識到它還是一個比較復雜，擁有較高學習曲線的解決方案。對於其復雜性，老實說目前，大多數人還缺乏真實的感受。
最近的一個個版本-Jan CTP，我們看到了一些特性，其強大之處在於：
1.客戶端(Javascript)的數據綁定、校驗帶來便利。
2. 新的Update Panels不僅擁有了MagicAJax.Net 的特性，而且功能更強，是目前Atlas中異步回調的主要控件。
3.內置了一些具體AJax特性的控件，比如AutoCompleteExtender ，DragOverlayExtender
4. 提供了一些使用的控件比如，ScriptManager, Triggers ,TimerControl
5. 主要用途著重在提供一個客戶端控件和服務器端控件的特性集成的方案和容易使用的開發效率上。
但缺點也是明顯的，比如：
1. 客戶端的Behaviors還很弱，模板(Templates)和UI增強(UI Enhancements)功能還沒有看到。
2. 所謂的客戶端Atlas控件(“Atlas” ClIEnt Controls)和服務器端的Atlas控件(“Atlas” Server Controls) 還沒有一個明確的規范，所以現在你基本上還不能創建自定義的Atlas控件(無論客戶端還是服務器端的)。
3. 目前還只支持調用Web Services的服務，對於ASP.Net的內置的服務以及WCF的服務支持也沒有看見，也不支持頁面或控件內的方法調用
4. 功能上還不穩定，一些功能僅是在特定條件下的特性實現，還不能滿足部署生產環境的要求。我認為，如果Atlas發布Go-Live License，那麼可以考慮Atlas的放入到正式的項目或應用中。
我並不建議，你現在就將它應用在一個老的ASP.NET 項目中，或是老項目遷移到ASP.NET v2.0時優先考慮它；更多時候，如果你是創建一個新的ASP.Net應用，而又跨越了其學習曲線的情況下，可以考慮使用它。目前的情況下，對於Atlas，我建議，你應該保持足夠的關注和實踐學習，但是要抑制住將其應用到項目中的興趣；因為Ajax，你現在可以開始關注和學習它，但是你不能因為要實現AJax一個特性，而立即選擇Atlas，那麼是可能有風險的。
注： Atals 的Microsoft.Web.Script.Serialization 命名空間中有JavascriptObjectDeserializer和JavaScriptObjectSerializer兩個對象，第一，我不確定其是否也是JSON 序列化，而且我也不確定目前是否支持兩路雙向的序列化；第二，目前的版本，我還不能進行自定義或擴展，同時也很難對於其性能做任何的結論。