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

   适用于：
   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 和其他 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 来描述消息。虽然现在这不是问题，但随着越来越多的工具完全着眼于架构，这种问题会越来越严重。
  
  第二，生成的 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 管线的人能使用它们吗？回答是：也许可以，如果您小心地将端点减少到基本数据类型和语义。也就是说，如果您要与其他 Web 服务工具包进行互操作，则需要将参数限制到内置的简单类型和您自己的数据类型（不能使用 DataSet 这样的 .NET Framework 类型），而且要避免客户端激活的对象和事件。简而言之，如果您关心使用范围，则需要把自己限制到 ASP.NET Web 服务所支持的那些功能。
  
  或者采取更好的方法，使用 ASP.NET Web 服务，因为这正是设计它们的目的所在。