Remoting 和 ASP.NET Web 服务

Remoting 和 ASP.NET Web
服务

 IT 设计中最好也是最坏的事情就是可以选择的体系结构组件太多了。Web 服务和 .NET
Remoting 就属于这种情况，有时很难决定针对不同的目的应该选用哪种技术。当然，正确的答案是为要解决的问题选择最佳的技术。
不要使用“始终使用 Web 服务”或“Web 服务是 Remoting 的子集，因此它就等于所有的
Remoting”等指令性的评述。本节将主要介绍这两种技术，说明在特定的情况下，为什么是选择这一种更有意义而不是另一种。

　　ASP.NET Web 服务和 .NET Remoting

　　让我们从 Web 服务的定义开始，定义说 Web
服务就是可以在 Web 上提供的服务。这个定义并不是很有用，我们不妨进一步把它提炼成“通过 SOAP 和 HTTP
访问的、可寻址的处理单元，这个处理单元是用 WSDL 描述的，可以通过 UDDI 发布。”这个定义就有用多了，因为它把 Web 服务和将 HTML
发送回浏览器的 Web 服务器区分开了。为了与 .NET Remoting 进行比较，我们特别强调了 Web 服务的定义，它与可在 Web
上提供的程序化的服务不同。例如，根据我们的定义，可以使用 WSDL 从客户端通过 HTTP 访问的远程主机就是 Web 服务。鉴于此（并强调
Microsoft ASP.NET Web 服务实现），对于分布式解决方案，在选择 ASP.NET Web 服务和 .NET Remoting 的“结合点”时，应该考虑哪些因素呢？

　　互操作性

 一种常见的 Microsoft
理论是：如果需要在不同系统之间进行互操作，应该选择使用开放标准 (SOAP、XML、HTTP) 的 Web 服务方法，而使用 .NET Remoting
决不是一种交互的解决方案；如果各种系统中的所有组件都是 CLR 托管的，则 .NET
Remoting“可能”是正确的选择。这一原则的适用范围很广，但有所区分还是非常有用的。.NET 远程对象的客户端应该是 .NET 客户端。如果您的功能必须在 Web（这里的 Web 即
Internet）上通过松散耦合的 SOAP 客户端（例如 Unix 进程）才能实现，则 Web
服务将是正确的选择。当然，Intranet 就不受这种限制：所有客户端都可以是 .NET 客户端，而且在这种配置中并不排除 .NET Remoting。同样，对于应用程序的中间层在防火墙之后并与 Web 层直接通信的环境，仍可选择 .NET Remoting。

　　强大的类型支持

　　.Net Remoting
支持所有托管的类型、类、接口、枚举、对象等，这通常被称为“多类型保真”。这里的关键在于，如果客户端和服务器组件都是在应用程序域中运行的 CLR
托管的对象，则数据类型的互操作是不成问题的。从根本上讲，我们拥有的是一个封闭的系统，会话的两端可以完全被理解，因此我们可以充分利用这一事实，处理好用于通信的数据类型和对象。

　　在各种系统并存的情况下，我们需要考虑系统之间的互操作性。对于可互操作的数据类型，我们要谨慎处理。例如，Web 服务数据类型的定义要基于 XML
架构定义 (XSD) 关于数据类型的说明。任何可以使用 XSD 进行描述并可以在 SOAP
上进行互操作的类型都可以使用。但是，这也确实使得某些数据类型不能使用。例如，对于无符号的字符类型或枚举，不存在相应的 W3C XSD 表示法。对于不同的 Web
服务实现，集合的处理不同，异常和数据集的处理也不同。另一个问题是，私有字段和属性不在 Web
服务调用之间传递，这对字段和属性本身来说并不是关键问题，但如果您的系统要求在不同的技术之间进行互操作，则在设计和测试系统时，这却是一个要考虑的因素，因为可以发送内容并不意味着可以接收到它。

　　再重复一遍，如果需要在不同的系统之间进行互操作，就不应该考虑使用 .NET Remoting 技术。如果是封闭的、CLR
托管的解决方案，则可以使用它。

　　状态管理

　　我们已经看到很多方法，使用基于激活方式（客户端激活或 Singleton）的 .Net Remoting
实现状态管理。对 .NET Remoting 和 Web 服务来说，通过 HTTP（带有不确定超时的无状态协议）来管理每个客户端的连接状态是件烦琐且不切实际的事情。但是，如果您需要维护状态，那么 Remoting
提供了一种基于每个对象的解决方案。Web 服务没有提供这种每个客户端的连接状态管理，但提供了对 ASP.NET 会话和应用程序对象的访问。

　　生存期管理

　　与状态管理有关的是生存期管理。正如我们所看到的，Remoting
为管理远程对象的生存期提供了功能强大的机制。Web 服务对象随 Web 服务的调用而存在和消失（从概念上讲，对同步和异步都是这样）。在这方面，Web 服务与
Remoting 相比，是一种单一调用类型。Remoting 对远程对象的激活和终止提供了更大程度上的控制。这对于您的设计可能有意义，也可能没意义。

　　按值调用和按引用调用

　　传递到 Web 服务调用的对象是经过序列化的，并按值进行传递。传递到 Remoting
的对象或被调用的对象本身可以按值或按引用进行传递。序列化的远程对象方法是在客户端进行处理的。在 Remoting 和 Web
服务之间进行选择时应该考虑这些不同。当然，这些考虑对您来说是否重要，也取决于要解决的问题的性质。

　　支持的协议

　　Web 服务调用仅限于 HTTP 上的 SOAP 编码的 XML。Remoting 可以使用 TCP
传输，或者扩展基础结构以支持自定义的协议。例如，在 www.gotdotnet.com 上的 jhawk 用户示例部分提供了一个使用 Named Pipe 的
Remoting 实现。

　　这里是 NamedPipe 自述文件的一个片段，阐明了 Remoting 的可扩展性：

　　通过实现 IChannel* 接口，可以使用可插入式通道结构将通道插入到 .NET Remoting 中。
Named Pipe
通道支持以下功能：

　　* 通过命名管道进行通信
　　* 同步消息
　　* 异步消息
　　* 单程消息
　　*
回调
　　* 通道接收
　　* 通道属性
　　* 自动生成管道名称

　　因此，如果您需要 Named Pipe，Remoting
可以提供解决方案。但是，与 SSPI NTLM 身份验证解决方案一样，Microsoft 目前也不支持这种解决方案，也许将来 Microsoft
会满足这种需要。