在RTM Release之前，我已經差不多將Web Service Proxy的分析寫完了，可惜一個“驚天地泣鬼神”的RTM一出，這片文章的誕生晚了20多天。
使用Web Service Proxy應該是使用ASP.NET AJax訪問Web Service最常用的方法了。服務器端會根據ScriptManager中添加的Service引用而對於Web Service類進行分析，並生成相應的客戶端腳本。這樣開發人員就能在客戶端方便而且直觀地訪問Web Services方法了。這是ASP.Net中很重要的功能。
從官方文檔上看來，CTP和RTM似乎在腳本使用這方面沒有很大的改變，只要在服務器端將一些CustomAttribute改變一下就可以了。的確沒錯，在使用方式上只有這點細微改變，但是事實上，從生成腳本本身來說，CTP和RTM的做法大相徑庭。它們的之間的區別主要有兩點：
- 對於生成服務器端類型的腳本（例如您可以使用new Jeffz.WebServiceProxyDemo.Employee()來構造一個對象）來說，CTP中可以自定義，RTM則不可以。
- 對於生成WebService方法的代理來說，CTP生成的代碼很少，RTM生成的代碼很多，但是符合客戶端“類”的標准。也就是說，RTM版本完全將一個服務器端的類“映射”到了客戶端——當然只有需要生成代理的那些方法，也不包括其實現。另外，RTM中增加了Cache功能，這是通過返回status code為304實現的。
我在標題中的“可歎”大都是指第1點。在RTM中，客戶端Serialize方法取消了對於自定義序列化的支持，這樣在服務器端也少了相應自定義服務器端類型腳本的功能。原本能夠使用自定義的辦法，“完美”地在服務器端和客戶端處理復雜對象中的“循環引用”問題，現在當然已經行不通了。從這一點上來說，真不知道算是進步了還是退步了，雖然依舊能夠使用JavaScriptConveter進行擴展，但是從“美學”上來說，現在的做法只能屬於“workaround”的范疇。而且，對於服務器端代碼的分析也沒有很大的價值了，因此在這片文中我只是對於客戶端的Proxy腳本進行一些分析和比較。
至於第2點，個人認為是配合了目前的Web Serivce訪問方式而改變的。它遵守了以下的規范和特點：
- 使用ASP.Net AJax中定義“類”規范將服務器端Web Service類映射到了客戶端中。
- 提供了客戶端訪問Web Service方法所需要的proxy。
- 支持defaultUserContext、defaultSucceededCallback和defaultFailedCallback。
對了更清晰地理解CTP和RTM之間的區別，以及RTM中構造Proxy的形式，我們來分別看一下CTP和RTM中的proxy腳本（以下Proxy代碼均經過整理）。
首先，我們在CTP和RTM中定義一個相同的復雜類型：Employee。代碼如下：
namespace Jeffz.WebServicesProxyDemo
{
public class Employee
{
public string Name;
public int Age;
}
}