ASP.NET Web 服务还是 .NET Remoting：如何选择

目录

• 概述
• 序列化和元数据
• 分布式应用程序设计：ASP.NET Web 服务和 .NET Remoting
• 选择体系结构
• 小结

概述

随着时间的推移，已经形成这样一种惯例：即将应用程序构建成一组组件，分布于计算机网络之间，并作为整个程序的一部分一起运行。过去，分布式应用程序逻辑需要具备组件/对象技术，例如，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 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 来描述消息。虽然现在这不是问题，但随着越来越多的工具完全着眼于架构，这种问题会越来越严重。