随着时间的推移,已经形成这样一种惯例:即将应用程序构建成一组组件,分布于
计算机网络之间,并作为整个程序的一部分一起运行。过去,分布式应用程序逻辑需要具备组件/对象技术,例如,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 定义,说明消息中包含什么样的内容。完全依赖于