隨著時間的推移，已經形成這樣一種慣例：即將應用程序構建成一組組件，分布於計算機網絡之間，並作為整個程序的一部分一起運行。過去，分布式應用程序邏輯需要具備組件/對象技術，例如，Microsoft? 分布式組件對象模型 (DCOM)、Object Management Group 的公共對象請求代理程序體系結構 (CORBA) 或 Sun 的遠程方法調用 (RMI)。這些技術提供了可靠的、可升級的體系結構，以滿足對應用程序日益增長的需要。
盡管這些基於組件的技術在 Intranet 環境中運行良好，但如果試圖將其應用到 Internet 上，則會遇到兩個大的問題。首先，這些技術不能進行交互操作。雖然這些技術都能處理對象，但在細節上卻不盡相同。例如，生命周期管理、對構造函數的支持以及對繼承的支持程度。第二，更重要的是，它們都著眼於 RPC 形式的通信，這通常會圍繞對象方法的顯式調用而構建緊密耦合的系統。
相反，基於浏覽器的 Web 應用程序是松散耦合的，具有很強的互操作性。它們使用 HTTP 進行通信，交換許許多多不同格式的 MIME 類型數據。Web 服務使傳統的 Web 編程模型適用於各種應用程序，而不僅僅是基於浏覽器的應用程序。它們使用 HTTP 和其他 Internet 協議交換 SOAP 消息。由於 Web 服務依賴於 HTTP、XML、SOAP 和 WSDL 等行業標准，在 Internet 上展示應用程序的功能，因此它們獨立於編程語言、平台和設備。
ASP.NET Web 服務基礎結構通過將 SOAP 消息映射到方法調用，為 Web 服務提供了簡單的 API。通過提供一種非常簡單的編程模型（基於將 SOAP 消息交換映射到方法調用），它實現了此機制。ASP.NET Web 服務的客戶端不需要了解用於創建它們的平台、對象模型或編程語言。而服務也不需要了解向它們發送消息的客戶端。唯一的要求是：雙方都要認可正在創建和使用的 SOAP 消息的格式，該格式是由使用 WSDL 和 XML 架構 (XSD) 表示的 Web 服務合約定義來定義的。
NET Remoting 為分布式對象提供了一個基礎結構。它使用既靈活又可擴展的管線向遠程進程提供 .NET 的完全對象語義。ASP.NET Web 服務基於消息傳遞提供非常簡單的編程模型，而 .NET Remoting 提供較為復雜的功能，包括支持通過值或引用傳遞對象、回調，以及多對象激活和生命周期管理策略等。要使用 .NET Remoting，客戶端需要了解所有這些詳細信息，簡而言之，需要使用 .NET 建立客戶端。（或者使用支持 .NET Remoting 的其他框架，我們所知道的唯一一個框架是 Intrinsyc 的用於 Java 的 Ja.NET。）.NET Remoting 管線還支持 SOAP 消息，但必須注意這並沒有改變其對客戶端的要求。如果 Remoting 端點提供 .NET 專用的對象語義，不管是否通過 SOAP，客戶端必須理解它們。
.NET 框架支持兩個截然不同的分布式編程模型 - Web 服務和分布式對象，這給開發人員造成了極大的混亂。系統何時應該使用 ASP.NET Web 服務，何時應該使用 .NET Remoting 呢？要回答這個問題，必須了解這兩種技術的工作原理。
返回頁首
序列化和元數據
所有分布式通信管線最終都要做兩件事：將程序數據類型實例封送為能夠在網絡上傳遞的消息，並且提供對消息樣式的描述。前者是使用某種形式的序列化引擎（或稱為封送拆收器）完成的，後者是通過某種形式的元數據完成的。例如，對於大多數（現代的）DCOM 接口來說，序列化引擎是類型庫封送拆收器，而類型庫提供元數據。ASP.NET Web 服務和 .NET Remoting 之間的主要不同在於它們如何將數據序列化為消息，以及它們為元數據選擇的格式。
ASP.NET Web 服務、XmlSerializer 和 XSD
ASP.NET Web 服務依賴於 System.Xml.Serialization.XmlSerializer 類，在運行時將數據封送到 SOAP 消息中以及從 SOAP 消息中封送數據。對於元數據，它們生成 WSDL 和 XSD 定義，說明消息中包含什麼樣的內容。完全依賴於 WSDL 和 XSD 使 ASP.NET Web 服務元數據具有可移植性；它表示數據結構的方法，對於不同平台上使用不同編程模型的其他 Web 服務工具包也可以理解。在某些情況下，這限制了可以從 Web 服務中提供的類型 - XmlSerializer 只能封送可以用 XSD 表示的數據。也就是說，XmlSerializer 將不能封送對象圖形，而且對於容器類型的支持也很有限。
盡管這些限制從傳統的分布式對象的角度來看似乎很重要，但它們有助於確保與其他 Web 服務框架的互操作性 - 這是松散耦合的 Web 服務模型的基本目標。大量自定義屬性使您能夠注釋數據類型，以控制 XmlSerializer 封送它們的方法，從而增強了對互操作性的支持。因此，您可以細致地控制在對象進行序列化時生成的 XML 的形狀。另外，還可以對基於 ASP.NET 的 Web 服務進行調整，以便用文字 XSD 或 SOAP 編碼規則（例如，SOAP 第 5 節）來描述消息。文字 XSD 是默認的，而且將成為以後的標准。它還包括 SOAP 編碼支持，以便與現有的工具包進行互操作。這對用戶很有幫助，特別是當用戶需要與現有 Web 服務或客戶端（它們需要使用預定義的消息格式進行通信）進行通信時更是如此。
.NET Remoting、IFormatter 和公共語言運行庫
NET Remoting 依賴於 System.Runtime.Serialization 引擎所使用的 IFormatter 接口的可插入實現程序向/從消息中封送數據。有兩個格式化程序， System.Runtime.Serialization.Formatters.Binary.BinaryFormatter 和 System.Runtime.Serialization.Formatters.Soap.SoapFormatter。顧名思義，BinaryFormatter 和 SoapFormatter 分別以二進制和 SOAP 格式封送類型。對於元數據，.NET Remoting 依賴於公共語言運行庫程序集，該程序集包含它們實現的數據類型的所有相關信息，並通過反射提供它。對於元數據而言，依賴於程序集更容易保留全運行時類型的系統保真度。因此，當 .NET Remoting 管線封送數據時，它包括類中所有公共和專有的成員，正確處理對象圖形並支持所有的容器類型（例如，System.Collections.Hashtable）。但是，依賴運行時元數據也限制了 .NET Remoting 系統的使用范圍 — 客戶端必須理解 .NET 體系結構才能與 .NET Remoting 端點進行通信。除了可插入的格式化程序外，.NET Remoting 層還支持可插入的信道，該信道去除了有關消息發送方法的細節。有兩種標准的信道，一種用於原始的 TCP，一種用於 HTTP。消息可以獨立於格式，通過任意一種信道進行發送。
