適用於：
Microsoft ASP.NET Web 服務
Microsoft .NET Framework
Microsoft .NET Remoting
摘要：瞭解 Microsoft .NET Remoting 基礎結構和 Microsoft ASP.NET Web 服務如何進行跨進程通訊，瞭解這兩種技術的工作原理以及如何為您的應用程式選擇合適的技術。
目錄
概述
序列化和中繼資料
分布式應用程式設計：ASP.NET Web 服務和 .NET Remoting
選擇體繫結構
小結
概述
隨著時間的推移，已經形成這樣一種慣例：即將應用程式構建成一組組件，分佈於電腦網路之間，並作為整個程式的一部分一起運行。過去，分布式應用程式邏輯需要具備組件/對象技術，例如，Microsoft 分散式元件物件模型 (DCOM)、Object Management Group 的公用對象請求代理程式體繫結構 (CORBA) 或 Sun 的遠程方法調用 (RMI)。這些技術提供了可靠的、可升級的體繫結構，以滿足對應用程式日益增長的需要。
儘管這些基於組件的技術在 Intranet 環境中運行良好，但如果試圖將其應用到 Internet 上，則會遇到兩個大的問題。首先，這些技術不能進行互動操作。雖然這些技術都能處理對象，但在細節上卻不盡相同。例如，生命週期管理、對建構函式的支援以及對繼承的支援程度。第二，更重要的是，它們都著眼於 RPC 形式的通訊，這通常會圍繞對象方法的顯式調用而構建緊密耦合的系統。
相反，基於瀏覽器的 Web 應用程式是鬆散耦合的，具有很強的互通性。它們使用 HTTP 進行通訊，交換許許多多不同格式的 MIME 類型資料。Web 服務使傳統的 Web 編程模型適用於各種應用程式，而不僅僅是基於瀏覽器的應用程式。它們使用 HTTP 和其他 網際網路通訊協定 (IP)交換 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 Framework 支援兩個截然不同的分布式編程模型 - 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 Section 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。訊息可以獨立于格式，通過任意一種通道進行發送。
各有利弊：Remoting 和 Web 服務
SOAP 格式化程式和 HTTP 通道的存在產生了這樣一個問題：可以使用 .NET Remoting 建立 Web 服務嗎？回答是肯定的也是否定的。標準的 Web 服務技術堆棧不僅依賴於基於 SOAP 的訊息，還依賴於訊息基於 WSDL 和 XSD 的描述。Remoting 管線能夠真正地產生描述端點所產生並使用的訊息的 WSDL 定義。但是，如果沿著這條思路走下去，會產生幾個問題。
首先，產生的 WSDL 檔案總是用 SOAP 編碼規則而不是文字 XSD 來描述訊息。雖然現在這不是問題，但隨著越來越多的工具完全著眼於架構，這種問題會越來越嚴重。
第二，產生的 WSDL 檔案包括 .NET Remoting 專用的擴充功能。例如，下面是使用 .NET Remoting 提供其行為的一個簡單的類。
public class Methods : MarshalByRefObject
{
// Now 方法返回當前的日期和時間
public string Now()
{
return System.DateTime.Now.ToString();
}
}
如果從此類中產生 WSDL，綁定資訊將包括 .NET Remoting 專用的詳細資料，如下所示。
<binding name='MethodsBinding' type='ns0:MethodsPortType'>
<soap:binding style='rpc'
transport='http://schemas.xmlsoap.org/soap/http'/>
<suds:class type='ns0:Methods' rootType='MarshalByRefObject'>
</suds:class>
<operation name='Now'>
<soap:operation soapAction=
'http://schemas.microsoft.com/clr/nsassem/RemSoap.Methods/methods#Now'/>
<suds:method attributes='public'/>
<input name='NowRequest'>...</input>
<output name='NowResponse'>...</output>
</operation>
</binding>
這些額外的元素是合法的，因為 WSDL 規範支援可擴充性。任何運作良好的 Web 服務工具包如果不理解它們都會簡單地忽略它們。但是，有些是 Web 服務工具包不能忽略的。例如，下面是一個返回 Microsoft ADO.NET System.Data.DataSet 的 Remoting 端點。
public class Methods : MarshalByRefObject
{
public System.Data.DataSet GetEmptyDataSet()
{
return new System.Data.DataSet();
}
}
下面是為此方法的輸出訊息產生的 WSDL 定義：
<message name='Methods.GetEmptyDataSetOutput'>
<part name='return' type='ns3:DataSet'/>
</message>
通常情況下，WSDL 訊息指的是使用 XML 結構描述在特定的命名空間中定義的類型。但在這種情況下，用於 DataSet 類型的命名空間的首碼 ns3 不是在 XSD 中定義的，而是通過運行時隱式定義的。本例中的首碼 ns3 應綁定到由以下 URI 確定的 XML 命名空間：
http://schemas.microsoft.com/clr/nsassem/System.Data/System.Data%2C%20Version%3D1.0.3300.0%2C%20Culture%3Dneutral%2C%20PublicKeyToken%3Db77a5c561934e089
此 WSDL 定義的用戶端是要瞭解這個“眾所周知”的 URI 的特殊意義 - 它是 .NET Framework 中包括的特定運行時程式集的嚴格名稱（由四部分組成）。這種 WSDL 對於使用 .NET Remoting 實現的用戶端非常有用，因為它們可以使用適於封送的資訊組建代理程式程式集。但是，對於不理解此 URI 並希望為 DataSet 類型找到架構定義的其他 Web 服務工具包（包括 ASP.NET），這種 WSDL 將毫無用處。
問題依然沒有解決：可以使用 .NET Remoting 建立 Web 服務嗎？嚴格地講，可以。但是，不使用 .NET Remoting 管線的人能使用它們嗎？回答是：也許可以，如果您小心地將端點減少到基礎資料型別 (Elementary Data Type)和語義。也就是說，如果您要與其他 Web 服務工具包進行互操作，則需要將參數限制到內建的簡單類型和您自己的資料類型（不能使用 DataSet 這樣的 .NET Framework 類型），而且要避免用戶端啟用的對象和事件。簡而言之，如果您關心使用範圍，則需要把自己限制到 ASP.NET Web 服務所支援的那些功能。
或者採取更好的方法，使用 ASP.NET Web 服務，因為這正是設計它們的目的所在。
