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 会满足这种需要。
性能
如果性能对您的设计确实至关重要，那么通过 TCP 使用二进制消息格式的 Remoting 确实提供了一些显著的性能优势。对于本文所介绍的结果，如果要完整了解产生此结果的测试环境和测试，请参阅性能比较：.NET Remoting 与 ASP.NET Web 服务一文。
这里是从这篇文章中总结出的一些性能统计：
图例：ASMX - Web 服务，其他都是 Remoting 解决方案
WS 表示集成远程组件的 Windows 服务。
图 1：性能统计
文章接下来对性能图表进行了解释，如下所述：
“如上所示，对于 WS_TCP_Binary，其中的对象被配置为使用 TCP 通道和 Binary 格式化程序，而主机是 Windows 服务，其性能要优于其他的分布式技术。这是因为该方法通过原始 TCP 套接字传输二进制数据（比 HTTP 的效率高），且数据不需要编码/解码，因而降低了系统开销。可以看到，WS_TCP_Binary 和最慢的方法之间存在约 60% 的性能差距。
虽然 IIS_HTTP_Binary 与 WS_HTTP_Binary 产生的二进制负载相同，但其速度较慢，原因是从 IIS (Inetinfo.exe) 到 Aspnet_wp.exe 之间有额外的进程跃点。IIS_HTTP_SOAP 与 WS_HTTP_SOAP 的性能差别也是由此造成的。
WS_HTTP_Binary 和 WS_TCP_SOAP 的性能几乎相同。尽管前者有 HTTP 分析方面的额外系统开销，后者有 SOAP 分析方面的额外系统开销，但在本例中 HTTP 分析的系统开销与 SOAP 分析的系统开销几乎相同。
ASP.NET Web 服务的性能优于 IIS_HTTP_SOAP 和 WS_HTTP_SOAP，因为 ASP.NET XML 序列化比 .NET Remoting SOAP 序列化的效率高。从上述内容可以看出，ASP.NET Web 服务与 IIS_HTTP_Binary 的性能几乎相同。”
如果原始速度确实非常重要，那么这“60% 性能差距”就很有意义了。其缺点是要将服务器集成在 Windows 服务中，以便使用 TCP 协议（请参阅前面的远程集成一节）。它有效地权衡了性能的安全性，而且是一种“最好不要用于 Internet 或不安全的 Intranet”的方法。
小结
ASP.NET Web 服务基于 XML，用于要求使用 HTTP（假定它们集成在 IIS）的实际应用中，能够提供简单的编程模式和强大的跨平台支持，它通过使用 SoapExtensions 提供了一定程度的扩展性，例如加密数据流。Remoting 的编程模式更为复杂，但就协议和消息格式而言，它在类型保真、状态管理和扩展性方面具有明显的优势。Remoting 不能用于非 .NET 客户端，因此无法实现 Internet 客户端与远程主机的直接连接。当在 IIS 之外集成时，Remoting 不能提供安全性模型。当集成在 IIS 时，Remoting 可以提供与 ASP.NET 相同的安全性功能，包括使用 SSL 等安全协议。如果不需要考虑与其他平台的互操作性，而且客户端和服务器的配置完全在您的控制之下，则可以考虑使用 .NET Remoting。使用 Remoting 时，使用了 HTTP 通道的 IIS 集成要优于非 IIS 集成，这样，可以得益于相关的安全性和伸缩性基础结构。当然，这意味着您必须能够在解决方案中与 IIS 进行互操作。如果这无法实现，那么使用 Remoting“可能”就是件无法实现的艰巨任务了，这与要解决的问题的性质有关。由于 .NET Remoting 要求使用 .NET 客户端，因此有必要使用最快的可用格式化程序，这样一来，选择二进制而不选择 SOAP 将产生更好的性能。请记住上文的最佳方法一节的建议，在发布时使用此格式化程序，而不要在开发过程中使用。
摘要
.NET Remoting 是在某些分布式解决方案中使用的有效工具，它在所支持的协议和消息格式方面提供了可扩展的模型，并能在特定的情况下提供性能优势。它不应直接部署在 Internet 上，而且它的服务器对象应该集成在 IIS 之下，以充分利用 IIS 为在其控制下运行的进程提供的安全性和性能特性。
对于“封闭”的分布式解决方案，其中的客户端和服务器都是 CLR 托管的进程，应该考虑使用 Remoting。例如，Intranet 解决方案中使用安全 TCP 通道（如 IPSec）或 HTTP 的任意层中的组件，或者通过防火墙与 .NET Web 层组件会话的中间层应用程序组件。在这种情况下，当证实应用程序使用 SOAP 格式化程序后，应该选择二进制格式化程序和 HTTP 通道。
对于要与非 CLR 客户端进行互操作的系统，请使用 ASMX Web 服务，但要谨慎处理某些数据类型（请参阅强大的类型支持一节）。
请注意，使用 TCP 在 IIS 之外集成会带来性能优势，但需要自定义的安全性。
设计与实现
实现和配置 Remoting 是一个相当容易的过程。在此过程中，首先要选择 Remoting 主机、协议和激活模式。请尽量简化设计和实现过程，并认真考虑哪种接口发布机制对您的解决方案最有意义。建议的方法是，只把接口作为最易懂的概念模型来发布，但这样一来就不能使用客户端激活的对象。调试程序、事件日志和网络监视是开发过程中非常有用的工具，在开发远程组件时，它们也能助您一臂之力。
Remoting 的未来
象“何时使用 Remoting、何时使用 Web 服务”等问题都是很难回答的问题，更何况术语的定义也不是很清楚。例如，如果 Web 服务的定义不清楚，Remoting 就有可能配置为 Web 服务。
或许将来 Remoting 和 ASMX 技术能逐步融合。但在目前，我们至少可以比较合理地说明何时使用哪种技术，如上所述。
当前的开发重点是提供路由、安全性和事务支持的 GXA 实现。这种实现要基于使用 SOAP 标头，而目前的直接目标是扩展 Web 服务的功能。虽然如本文所述，从传统意义上讲，GXA 不支持 .NET Remoting，但它支持 Remoting 解决的很多问题，如状态和事务管理等。虽然现在的 GXA 实现可以解决 Web 服务所面对的许多问题，但它最根本的目的是尽量以不需要太高技术含量的方式解决这些问题。看到 GXA 的开发对 Web 服务和 .Net Remoting 的影响，将是一件充满乐趣的事情。
1138
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
