ASP.NET Web服務還是.NET Remoting：如何選擇

申請免費試用、咨詢電話：400-8352-114

ASP.NET Web服務還是.NET Remoting：如何選擇

－－使用 Microsoft .NET 建立分布式應用程序

適用于：
  
Microsoft? ASP.NET Web 服務
  
Microsoft? .NET Framework
  
Microsoft? .NET Remoting

摘要：了解 Microsoft .NET Remoting 基礎結(jié)構(gòu)和 Microsoft ASP.NET Web 服務如何進行跨進程通信，了解這兩種技術的工作原理以及如何為您的應用程序選擇合適的技術。

概述

隨著時間的推移，已經(jīng)形成這樣一種慣例：即將應用程序構(gòu)建成一組組件，分布于計算機網(wǎng)絡之間，并作為整個程序的一部分一起運行。過去，分布式應用程序邏輯需要具備組件/對象技術，例如，Microsoft? 分布式組件對象模型 (DCOM)、Object Management Group 的公共對象請求代理程序體系結(jié)構(gòu) (CORBA) 或 Sun 的遠程方法調(diào)用 (RMI)。這些技術提供了可靠的、可升級的體系結(jié)構(gòu)，以滿足對應用程序日益增長的需要。

盡管這些基于組件的技術在 Intranet 環(huán)境中運行良好，但如果試圖將其應用到 Internet 上，則會遇到兩個大的問題。首先，這些技術不能進行交互操作。雖然這些技術都能處理對象，但在細節(jié)上卻不盡相同。例如，生命周期管理、對構(gòu)造函數(shù)的支持以及對繼承的支持程度。第二，更重要的是，它們都著眼于 RPC 形式的通信，這通常會圍繞對象方法的顯式調(diào)用而構(gòu)建緊密耦合的系統(tǒng)。

相反，基于瀏覽器的 Web 應用程序是松散耦合的，具有很強的互操作性。它們使用 HTTP 進行通信，交換許許多多不同格式的 MIME 類型數(shù)據(jù)。Web 服務使傳統(tǒng)的 Web 編程模型適用于各種應用程序，而不僅僅是基于瀏覽器的應用程序。它們使用 HTTP 和其他 Internet 協(xié)議交換 SOAP 消息。由于 Web 服務依賴于 HTTP、XML、SOAP 和 WSDL 等行業(yè)標準，在 Internet 上展示應用程序的功能，因此它們獨立于編程語言、平臺和設備。

ASP.NET Web 服務基礎結(jié)構(gòu)通過將 SOAP 消息映射到方法調(diào)用，為 Web 服務提供了簡單的 API。通過提供一種非常簡單的編程模型（基于將 SOAP 消息交換映射到方法調(diào)用），它實現(xiàn)了此機制。ASP.NET Web 服務的客戶端不需要了解用于創(chuàng)建它們的平臺、對象模型或編程語言。而服務也不需要了解向它們發(fā)送消息的客戶端。唯一的要求是：雙方都要認可正在創(chuàng)建和使用的 SOAP 消息的格式，該格式是由使用 WSDL 和 XML 架構(gòu) (XSD) 表示的 Web 服務合約定義來定義的。

.NET Remoting 為分布式對象提供了一個基礎結(jié)構(gòu)。它使用既靈活又可擴展的管線向遠程進程提供 .NET 的完全對象語義。ASP.NET Web 服務基于消息傳遞提供非常簡單的編程模型，而 .NET Remoting 提供較為復雜的功能，包括支持通過值或引用傳遞對象、回調(diào)，以及多對象激活和生命周期管理策略等。要使用 .NET Remoting，客戶端需要了解所有這些詳細信息，簡而言之，需要使用 .NET 建立客戶端。（或者使用支持 .NET Remoting 的其他框架，我們所知道的唯一一個框架是 Intrinsyc 的用于 Java 的 Ja.NET。）.NET Remoting 管線還支持 SOAP 消息，但必須注意這并沒有改變其對客戶端的要求。如果 Remoting 端點提供 .NET 專用的對象語義，不管是否通過 SOAP，客戶端必須理解它們。

.NET Framework 支持兩個截然不同的分布式編程模型 - Web 服務和分布式對象，這給開發(fā)人員造成了極大的混亂。系統(tǒng)何時應該使用 ASP.NET Web 服務，何時應該使用 .NET Remoting 呢？要回答這個問題，必須了解這兩種技術的工作原理。

序列化和元數(shù)據(jù)

所有分布式通信管線最終都完成兩項工作：將程序數(shù)據(jù)類型的實例封送到可以通過網(wǎng)絡傳送的消息中，并提供對那些消息的描述。前者是使用某種形式的序列化引擎（或稱為封送拆收器）完成的，后者是通過某種形式的元數(shù)據(jù)完成的。例如，對于大多數(shù)（現(xiàn)代的）DCOM 接口來說，序列化引擎是類型庫封送拆收器，而類型庫提供元數(shù)據(jù)。ASP.NET Web 服務和 .NET Remoting 之間的主要不同在于它們?nèi)绾螌?shù)據(jù)序列化為消息，以及它們?yōu)樵獢?shù)據(jù)選擇的格式。

ASP.NET Web 服務、XmlSerializer 和 XSD

ASP.NET Web 服務依賴于 System.Xml.Serialization.XmlSerializer 類，在運行時將數(shù)據(jù)封送到 SOAP 消息中以及從 SOAP 消息中封送數(shù)據(jù)。對于元數(shù)據(jù)，它們生成 WSDL 和 XSD 定義，說明消息中包含什么樣的內(nèi)容。完全依賴于 WSDL 和 XSD 使 ASP.NET Web 服務元數(shù)據(jù)具有可移植性；它表示數(shù)據(jù)結(jié)構(gòu)的方法，對于不同平臺上使用不同編程模型的其他 Web 服務工具包也可以理解。在某些情況下，這限制了可以從 Web 服務中提供的類型 - XmlSerializer 只能封送可以用 XSD 表示的數(shù)據(jù)。也就是說，XmlSerializer 將不能封送對象圖形，而且對于容器類型的支持也很有限。

盡管這些限制從傳統(tǒng)的分布式對象的角度來看似乎很重要，但它們有助于確保與其他 Web 服務框架的互操作性 - 這是松散耦合的 Web 服務模型的基本目標。大量自定義屬性使您能夠注釋數(shù)據(jù)類型，以控制 XmlSerializer 封送它們的方法，從而增強了對互操作性的支持。因此，您可以細致地控制在對象進行序列化時生成的 XML 的形狀。另外，還可以對基于 ASP.NET 的 Web 服務進行調(diào)整，以便用文字 XSD 或 SOAP 編碼規(guī)則（即 SOAP Section 5）描述消息。文字 XSD 是默認的，而且將成為以后的標準。它還包括 SOAP 編碼支持，以便與現(xiàn)有的工具包進行互操作。這對用戶很有幫助，特別是當用戶需要與現(xiàn)有 Web 服務或客戶端（它們需要使用預定義的消息格式進行通信）進行通信時更是如此。

.NET Remoting、IFormatter 和公共語言運行庫

.NET Remoting 依賴于 System.Runtime.Serialization 引擎所使用的 IFormatter 接口的可插入實現(xiàn)程序向/從消息中封送數(shù)據(jù)。有兩種標準的格式化程序：System.Runtime.Serialization.Formatters.Binary.BinaryFormatter 和 System.Runtime.Serialization.Formatters.Soap.SoapFormatter。顧名思義，BinaryFormatter 和 SoapFormatter 分別以二進制和 SOAP 格式封送類型。對于元數(shù)據(jù)，.NET Remoting 依賴于公共語言運行庫程序集，該程序集包含它們實現(xiàn)的數(shù)據(jù)類型的所有相關信息，并通過反射提供它。對于元數(shù)據(jù)而言，依賴于程序集更容易保留全運行時類型的系統(tǒng)保真度。因此，當 .NET Remoting 管線封送數(shù)據(jù)時，它包括類中所有公共和專有的成員，正確處理對象圖形并支持所有的容器類型（如 System.Collections.Hashtable）。但是，依賴運行時元數(shù)據(jù)也限制了 .NET Remoting 系統(tǒng)的使用范圍 - 客戶端必須理解 .NET 結(jié)構(gòu)才能與 .NET Remoting 端點進行通信。除了可插入的格式化程序外，.NET Remoting 層還支持可插入的通道，該通道去除了有關消息發(fā)送方法的細節(jié)。有兩種標準的通道，一種用于原始的 TCP，一種用于 HTTP。消息可以獨立于格式，通過任意一種通道進行發(fā)送。

各有利弊：Remoting 和 Web 服務

SOAP 格式化程序和 HTTP 通道的存在產(chǎn)生了這樣一個問題：可以使用 .NET Remoting 建立 Web 服務嗎？回答是肯定的也是否定的。標準的 Web 服務技術堆棧不僅依賴于基于 SOAP 的消息，還依賴于消息基于 WSDL 和 XSD 的描述。Remoting 管線能夠真正地生成描述端點所產(chǎn)生并使用的消息的 WSDL 定義。但是，如果沿著這條思路走下去，會產(chǎn)生幾個問題。

首先，生成的 WSDL 文件總是用 SOAP 編碼規(guī)則而不是文字 XSD 來描述消息。雖然現(xiàn)在這不是問題，但隨著越來越多的工具完全著眼于架構(gòu)，這種問題會越來越嚴重。

第二，生成的 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 規(guī)范支持可擴展性。任何運作良好的 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 架構(gòu)在特定的命名空間中定義的類型。但在這種情況下，用于 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 實現(xiàn)的客戶端非常有用，因為它們可以使用適于封送的信息生成代理程序集。但是，對于不理解此 URI 并希望為 DataSet 類型找到架構(gòu)定義的其他 Web 服務工具包（包括 ASP.NET），這種 WSDL 將毫無用處。

問題依然沒有解決：可以使用 .NET Remoting 建立 Web 服務嗎？嚴格地講，可以。但是，不使用 .NET Remoting 管線的人能使用它們嗎？回答是：也許可以，如果您小心地將端點減少到基本數(shù)據(jù)類型和語義。也就是說，如果您要與其他 Web 服務工具包進行互操作，則需要將參數(shù)限制到內(nèi)置的簡單類型和您自己的數(shù)據(jù)類型（不能使用 DataSet 這樣的 .NET Framework 類型），而且要避免客戶端激活的對象和事件。簡而言之，如果您關心使用范圍，則需要把自己限制到 ASP.NET Web 服務所支持的那些功能。

或者采取更好的方法，使用 ASP.NET Web 服務，因為這正是設計它們的目的所在。

分布式應用程序設計：ASP.NET Web 服務和 .NET Remoting

ASP.NET Web 服務支持 XML 架構(gòu)類型系統(tǒng)，提供一種簡單的編程模型，使用范圍廣，可以跨平臺使用。.NET Remoting 支持運行時類型的系統(tǒng)，提供較復雜的編程模型，使用范圍較窄。這種本質(zhì)上的差別是決定使用哪種技術的主要因素。但是，還要考慮很多其他設計因素，包括傳輸協(xié)議、主機進程、安全性、性能、狀態(tài)管理以及對事務的支持等。

傳輸協(xié)議和主機進程

盡管 SOAP 規(guī)范并不要求用 HTTP 作為傳輸協(xié)議，但是客戶端只能通過 HTTP 訪問使用 ASP.NET Web 服務實現(xiàn)的 Web 服務，因為它是 ASP.NET 支持的唯一一種傳輸協(xié)議。服務是通過 IIS 調(diào)用的，并在 ASP.NET 的輔助進程 aspnet_wp.exe 中執(zhí)行。

.NET Remoting 使您能夠在任何類型的應用程序（包括 Windows 窗體、托管的 Windows 服務、控制臺應用程序或 ASP.NET 輔助進程）中靈活地托管遠程對象。正如前面所述，.NET Remoting 提供兩個傳輸通道 - TCP 和 HTTP。這兩個通道都能使用套接字提供任意發(fā)送和接收進程之間的通信。

它還能將 HTTP 通道與 IIS 和 ASP.NET 輔助進程集成。這一點很重要，原因有以下幾點。首先，它是當客戶端請求到達時自動啟動 .NET Remoting 端點的唯一方法。.NET Remoting 管線不包括啟動遠程服務器所需的 DCOM 類型的服務控制管理器 (SCM)。如果從任意進程中提供遠程對象，則需要確保那些進程正在運行。還要確保它們是線程安全的，例如，在啟動線程 B 以關閉進程后，線程 A 不能激活對象。如果從 ASP.NET 提供遠程對象，則可以利用 Aspnet_wp.exe 輔助進程，這樣既可自動啟動又具有線程安全的優(yōu)勢。第二，與 IIS 集成是確?？邕M程 .NET Remoting 調(diào)用的唯一途徑，如下一節(jié)所述。

ASP.NET Web 服務和 .NET Remoting 基礎結(jié)構(gòu)都是可擴展的。您可以過濾入站和出站消息，從多方面控制類型封送和元數(shù)據(jù)的生成。使用 .NET Remoting，還能實現(xiàn)您自己的格式化程序和通道。

安全性

由于 ASP.NET Web 服務依賴于 HTTP，因此它們與標準的 Internet 安全性基礎結(jié)構(gòu)相集成。ASP.NET 利用 IIS 的安全性功能，為標準 HTTP 驗證方案（包括基本、簡要、數(shù)字證書，甚至 Microsoft? .NET Passport）提供了強有力的支持。（還可以使用 Windows 集成驗證，但只能用于信任域中的客戶端。）使用可用的 HTTP 驗證方案的一個優(yōu)勢在于，無需在 Web 服務中更改代碼，IIS 是在 ASP.NET Web 服務被調(diào)用之前執(zhí)行驗證的。ASP.NET 還支持基于 .NET Passport 的驗證和其他自定義的驗證方案。ASP.NET 支持基于目標 URL 的訪問控制，并通過與 .NET 代碼訪問安全性 (CAS) 基礎結(jié)構(gòu)的集成支持訪問控制。SSL 可用于確保通信的安全。

盡管這些標準傳輸技術對于確保 Web 服務相當有效，但它們只能做到這種程度。在涉及到不同信任域中多個 Web 服務的復雜情況下，還得建立自定義的特殊解決方案。Microsoft 和其他公司正致力于創(chuàng)建一套安全性規(guī)范，該規(guī)范將基于 SOAP 消息的可擴展性提供消息級別的安全性功能。這些規(guī)范之一是 XML Web 服務安全性語言（WS-Security [英文]），它為消息級別的憑據(jù)傳輸、消息完整性和消息保密定義了框架。

正如上一節(jié)所述，一般情況下，.NET Remoting 管線不能確?？邕M程調(diào)用的安全。使用 ASP.NET 托管于 IIS 中的 .NET Remoting 端點可以利用 ASP.NET Web 服務可用的所有安全性功能，包括對使用 SSL 確保有線通信的安全性的支持。如果您正在使用托管在進程中的 TCP 通道或 HTTP 通道（而不是 aspnet_wp.exe），則必須自己執(zhí)行身份驗證、授權(quán)和保密機制。

另一個要關注的安全性問題是，在不必更改默認安全性策略的情況下，從不完全信任的環(huán)境中執(zhí)行代碼的能力。ASP.NET Web 服務客戶端代理可以在這些環(huán)境中工作，但 .NET Remoting 代理則不能。要從不完全信任的環(huán)境中使用 .NET Remoting 代理，需要特殊的序列化權(quán)限。默認情況下，該權(quán)限不會授予從 Intranet 或 Internet 上下載的代碼。如果要在不完全信任的環(huán)境中使用 .NET Remoting 客戶端，則需要更改從那些區(qū)域中加載的代碼的默認安全性策略。當您從運行于沙箱（如下載的 Windows 窗體應用程序）中的客戶端連接到系統(tǒng)時，ASP.NET Web 服務是較簡單的選擇，因為不需要更改安全性策略。

狀態(tài)管理

默認情況下，ASP.NET Web 服務模型采用無狀態(tài)的服務體系結(jié)構(gòu)；它并不是本能地與來自同一個用戶的多個調(diào)用相關。另外，客戶端每次調(diào)用 ASP.NET Web 服務時，都創(chuàng)建一個新的對象以服務于該請求。方法調(diào)用完成后，該對象即被破壞。要保持請求間的狀態(tài)，可以使用 ASP.NET 頁面所使用的技術（即會話和應用程序?qū)傩园部梢詧?zhí)行自定義的解決方案。

.NET Remoting 支持許多狀態(tài)管理選項，并且可能與來自同一個用戶的多個調(diào)用相關或不相關，這取決于您選擇的對象生命周期架構(gòu)。SingleCall 對象是無狀態(tài)的（如用于調(diào)用 ASP.NET Web 服務的對象），Singleton 對象共享所有客戶端的狀態(tài)，客戶端激活的對象在每個客戶端的基礎上保持狀態(tài)（帶有其產(chǎn)生的所有相關的可升級性和可靠性問題）。

性能

從原始性能方面來講，使用 TCP 通道和二進制格式化程序時，.NET Remoting 管線能夠提供最快的通信。在我們進行的比較 ASP.NET Web 服務和 .NET Remoting 的相對性能的幾乎所有的測試中，ASP.NET Web 服務在性能上都超出了使用 HTTP 或 TCP 通道的 SOAP 格式化程序的 .NET Remoting 端點。更有意思的是，使用二進制格式化程序和 HTTP 通道的 ASP.NET 和 .NET Remoting 端點在性能上非常相近。有關詳細信息，請參閱性能比較：.NET Remoting 與 ASP.NET Web 服務。

企業(yè)服務

ASP.NET Web 服務或通過 .NET Remoting 提供的對象可以使用本地事務根據(jù)單個數(shù)據(jù)庫協(xié)調(diào)工作。如果需要根據(jù)多個資源協(xié)調(diào)工作，它可以使用 .NET 企業(yè)服務（也稱為 COM+）公布的事務（由 COM+ 管線管理的 DTC 分布式事務）。但要注意的是，ASP.NET Web 服務和 .NET Remoting 管線都不能傳播公布的事務，因此兩種端點都不可能通過跨進程的調(diào)用繼承公布的事務。

這不一定是件壞事。一般來講，公布的事務比本地事務代價要高，而要跨進程傳播公布的事務，則代價會更高。如果您確實需要這種功能，簡單的解決方案是在 .NET 企業(yè)服務服務器應用程序中展開一個從 System.EnterpriseServices.ServicedComponent 中衍生的類（有關詳細信息，請參閱 COM+ Integration: How .NET Enterprise Services Can Help You Build Distributed Applications [英文]）。對該類對象的跨進程調(diào)用將使用 DCOM 進行處理，以確保正確傳播事務環(huán)境。較難的解決方案是使用底層的 API，手動傳播分布的事務。

值得注意的是，傳統(tǒng)的分布式事務模型一般不適用于松散耦合的 Web 服務。基于補償事務的模型（即，撤消其他事務所提交工作的事務）更有意義，因為其隔離約束條件并不是很嚴格。在包括 Microsoft 的 Web 服務供應商中有一種普遍的說法，即 Web 服務空間需要的事務模型越靈活，該空間中進行的工作越多。等到定義出 Web 服務事務的標準方法時，您就可以根據(jù)情況使用本地或公布的事務實現(xiàn)自己的補償架構(gòu)了。

選擇體系結(jié)構(gòu)

如果您正在設計一個基于 .NET 的分布式應用程序，則需要考慮本文中討論的所有問題，并對系統(tǒng)體系結(jié)構(gòu)的應有結(jié)果得出一些結(jié)論。一般來講，這比您想像的要容易些。但總有一些特殊的情況需要其他的方法，以下是您可以進行的某些一般假設，可為您簡化情況。

首先，在默認情況下使用 ASP.NET Web 服務。它們的執(zhí)行和使用都很簡單，可以為客戶端平臺提供盡可能寬的使用范圍，而且可以從默認安全性策略下沙箱中運行的代碼中調(diào)用 ASP.NET Web 服務客戶端代理代碼。

如果要使用較傳統(tǒng)的帶有 CLR 類型保真度的分布式對象模型，不需要與其他平臺進行互操作，而且由您控制客戶端和服務器的配置，請考慮使用 .NET Remoting。如果您選擇 .NET Remoting，最好使 HTTP 通道與 IIS 和 ASP.NET 集成，否則，必須建立自己的進程生命周期管理和安全性基礎結(jié)構(gòu)。假定 .NET Remoting 需要 .NET 客戶端，使用二進制格式化程序而不是 SOAP 格式化程序是很有意義的；互操作性將不成問題，而且性能將顯著提高。

最后，如果需要公布的事務，請使用企業(yè)服務 (COM+)。如果您執(zhí)行 ServicedComponents，則出于性能方面的考慮，默認情況下它們將部署在庫應用程序中。如果它們需要在遠程計算機上運行，則將它們部署在服務器應用程序中。（如果您需要執(zhí)行不同的進程安全性令牌 [而不是 aspnet_wp.exe 使用的令牌] 的代碼，即使在相同的計算機上，可能也要考慮使用 COM+ 服務器應用程序。）

以下是三個基于這些理念的公共體系結(jié)構(gòu)。

圖 1：簡單的 3 層體系結(jié)構(gòu)

圖 1 顯示了一個簡單的 3 層體系結(jié)構(gòu)，它帶有 Web 服務器領域，支持一系列不同的客戶端。所有服務器端的代碼都在 ASP.NET 輔助進程 aspnet_wp.exe 中執(zhí)行。這三種不同類型的客戶端可以使用 HTTP 訪問服務器領域?；跒g覽器的客戶端調(diào)用 ASP.NET Web 頁面；多客戶端（如 Windows 窗體應用程序、Microsoft? Visual Basic? 6 應用程序）和其他 Web 服務使用 ASP.NET Web 服務；根據(jù)需要，.NET 多客戶端（如 Windows 窗體應用程序）和 Web 服務使用 ASP.NET Web 服務，或使用 HTTP 通道和二進制格式化程序的 .NET Remoting（假定它不在沙箱中）。

圖 2：使用 ASP.NET 的 n 層體系結(jié)構(gòu)

一些非常大的應用程序使用一套輔助計算機從 Web 服務器的外層分擔工作。這種體系結(jié)構(gòu)如圖 2 所示。請注意，在這種情況下，第二層也通過 ASP.NET 提供功能。

圖 3：使用企業(yè)服務 (COM+) 的 n 層體系結(jié)構(gòu)

圖 3 顯示此體系結(jié)構(gòu)的另一種版本，其第二層使用在 COM+ 中部署的 ServicedComponents 提供功能。

顯然，這些并不是 .NET Framework 所支持的所有可能的體系結(jié)構(gòu)。但是，它為您設計自己的系統(tǒng)提供了適當?shù)幕A。

小結(jié)

雖然 .NET Remoting 基礎結(jié)構(gòu)和 ASP.NET Web 服務都可以進行跨進程通信，但每種設計適用于不同的用戶。ASP.NET Web 服務的編程模型很簡單，使用范圍很廣。.NET Remoting 的編程模型較復雜，使用范圍較窄。請務必了解這兩種技術的工作原理，并選擇適合您應用程序的技術。在任意一種情況下，都要使用 IIS 和 ASP.NET 管理進程生命周期，并提供一般的安全性。