选择 .NET 中的通信选项

.NET Framework 提供了几种与不同应用程序域中的对象进行通信的方式,每一种方式都具有特定级别的专业性和灵活性。例如,Internet 的发展已经使 XML Web 服务成为一种颇具吸引力的通信方法,这是因为 XML Web 服务是建立在使用 XML 的 HTTP 协议和 SOAP 格式化的通用基础结构之上的。这些都是公共标准,并且可以直接与当前的 Web 基础结构结合使用,而无须担心其他的代理或防火墙问题。

因为许多应用程序都要求使用 ASP.NET 创建的 Web 服务所不支持的功能,所以许多应用程序无法使用 ASP.NET Web 服务。下一节中的内容可以帮助您确定您的应用程序需要哪种类型的分布式应用程序支持。

ASP.NET、企业级服务还是 .NET 远程处理?

ASP.NET、企业级服务和 .NET 远程处理都是进程间通信 (IPC) 的实现方法。ASP.NET 提供一种由 Internet 信息服务 (IIS) 承载的基础结构,该基础结构非常适合处理基本类型,支持某些高级 Web 服务协议(在与 Web 服务扩展 (WSE) 一起使用时),而且为 Web 应用程序开发人员所熟悉。企业级服务是 COM+ 的托管实现,提供 COM+ 结构的所有灵活性和丰富性。.NET 远程处理是泛型的可扩展 IPC 系统,可以自承载或承载在 IIS 中,以开发和部署面向对象的分布式应用程序。.NET 远程处理的可插接式结构允许自定义协议和连网形式。

选择何种编程模型应该由以下三个主要标准决定:业务需求、集成需要以及编程模型是否为您所熟悉。此外,以下标准(按优先级顺序列出)可以帮助您选择所需分布式应用程序技术的类型。

  1. 安全需要

    在上述三个编程模型中,企业级服务具有最丰富的安全功能集合并且可以满足大多数情况的需要。ASP.NET 通过 IIS 提供身份验证,通过 SSL 提供加密,并且对于确保 Internet 规模应用程序的安全十分有用。通过 .NET Framework 的最新版本,.NET 远程处理的安全性已得到提升。在 .NET 远程处理的早期版本中,如果需要对调用进行加密或对客户端进行身份验证,必须使用在 IIS 中承载的基于 HTTP 的应用程序(无论它是 ASP.NET 应用程序还是远程处理应用程序)。在当前版本中,TcpChannelHttpChannel 支持 SSPI 加密和 Windows 集成身份验证。IpcChannel 还支持 Windows 身份验证以及对命名管道的访问控制列表 (ACL) 的直接设置。由于建议不要通过 Internet 使用远程对象,因此,现在有几个要求 HttpChannel 的新情况。如果您必须通过 Internet 通信,则建议您使用 ASP.NET 来创建 XML Web 服务。

备注

出于安全原因,强烈建议您通过安全信道公开远程处理终结点。永远不要向 Internet 公开不安全的远程处理终结点。

  1. 交互操作

    如果您需要不同操作系统之间的交互操作,则应使用 ASP.NET 创建的 XML Web 服务。与 .NET 远程处理相比,ASP.NET 文件将使您在定义 SOAP 通信的形状和样式时具有更多的灵活性。通过这种灵活性,与不同平台和客户端的交互操作就会变得更加容易。.NET 远程处理并不用于与 .NET 以外的平台进行交互操作。

    .NET Framework 远程处理并不用于与 Web 服务进行交互操作。有关在 Web 服务和远程处理之间进行选择的更多信息,请参见 Performance Best Practices at a Glance(英文)中的“How to choose between Web services, remoting, and Enterprise Services”和 Improving .NET Application Performance and Scalability(英文)中的“Prescriptive Guidance for Choosing Web Services, Enterprise Services, and .NET Remoting”。

  2. 速度

    如果速度是实际决定因素,则企业级服务可以为分布式应用程序提供最佳性能。在应用程序要求实际的处理后,.NET 远程处理和 ASP.NET 文件之间的性能差别非常小。如果您使用 .NET 远程处理,则具有 BinaryFormatter 的 TcpChannel 将在多台计算机中获得最佳性能。在同一台计算机上,则应使用具有 BinaryFormatter 的 IpcChannel。

  3. 可伸缩性

    在 IIS 内承载您的应用程序可为您提供所需的可伸缩性。自承载的 .NET 远程处理要求您生成自己的可伸缩基础结构。如果您考虑将 IIS 与 .NET 远程处理一起使用以获得可伸缩性,则应考虑改用通过 ASP.NET 创建的 Web 服务。

  4. 公共语言运行库功能的使用

    企业级服务和 .NET 远程处理都可以更好地利用 .NET 客户端,这样,您可以在应用程序中使用一些 .NET 功能,而这些功能是通过使用 ASP.NET 创建的 XML Web 服务所无法提供的功能,包括:

    • 接口

    • CallContext

    • 属性

    • 索引器

    • C++

    • 客户端和服务器应用程序之间的类型保真

    • 如果这些功能十分重要,则选择“企业级服务”(如果可能),然后选择 .NET 远程处理。

  5. 面向对象的应用程序设计

    企业级服务对象和 .NET 远程处理对象都属于对象,并且可以按对象来处理。因此,您可以在应用程序中使用以下对于 ASP.NET 不可用的面向对象的功能。

    • 对远程处理对象的对象引用

    • 若干个对象激活选项

    • 面向对象的状态管理

    • 分布式对象生存期管理

    • 如果这些功能十分重要,则选择“企业级服务”(如果可能),然后选择 .NET 远程处理。

  6. 自定义传输或连网形式。如果您需要支持自定义传输(例如,用户数据报协议 (UDP))或自定义连网形式(例如 CSV),.NET 远程处理是可以满足这些需要的唯一可插接式结构。

  7. 跨应用程序域通信。如果您需要在同一进程内支持不同应用程序域中对象之间的通信,则必须使用 .NET 远程处理。

以下几节包括使用 ASP.NET、System.Net 命名空间、企业级服务和 .NET 远程处理创建的 XML Web 服务之间存在的一些差异的简短摘要。

XML Web 服务

如果您通过使用 Web 应用程序模型和 ASP.NET HTTP 运行库(包括 Microsoft Visual Studio NET 中的强支持)构造 Active Server Pages (ASP) 应用程序,则使用 ASP.NET 创建的 XML Web 服务可以很好地工作。使用 XML Web 服务基础结构,您可以轻松地为其他应用程序创建要使用的组件,或者使用其他应用程序已通过使用最适合基于 Web 的应用程序的协议、格式和数据类型创建的组件。它不支持计算机之间的完全类型保真,并且只能传递某些类型的参数。有关更多信息,请参见使用 ASP.NET 和 XML Web 服务客户端创建的 XML Web 服务

System.Net 命名空间

可以使用 System.Net 命名空间中的类从套接字级别生成整个通信结构。还可以使用 System.Net 类实现可插入到远程处理结构中的通信协议和序列化格式。有关更多信息,请参见网络编程

企业级服务。

企业级服务是在 .NET 远程处理基础结构的基础上构建的,可以提供 COM+ 分布式对象模型所具备的所有丰富性和灵活性,包括支持大范围分布式事务。

.NET 远程处理

.NET 远程处理提供了用于实现任意数量的全面通信方案(包括 XML Web 服务)的工具。使用 .NET 远程处理可以:

  • 在任意类型的应用程序域中发布或使用服务,无论该域是控制台应用程序、Windows 窗体、IIS、XML Web 服务还是 Windows 服务。

  • 在二进制格式的通信中保持完整的托管代码类型系统保真度,包括支持泛型类型。

    备注

    XML Web 服务使用 SOAP 格式化,这种格式化不会保持所有的类型详细信息。

  • 通过引用传递对象并返回到特定应用程序域中的特定对象。

  • 直接控制激活特性和对象生存期。

  • 实现和使用第三方信道或协议来扩展通信以满足特定要求。

  • 直接参与通信进程以创建所需的功能。

请参见

其他资源

远程对象
.NET Framework 远程处理概述
远程处理示例
高级远程处理