概述
.NET Remoting 被誉为管理应用程序域之间的 RPC 的首选技术。应用程序域是公共语言运行库的隔离单元，它们是在进程内创建并运行的。这与 CLR 和非 CLR 托管的进程之间的进程间通信（互操作）不同。后一种类型的 RPC 通信（特别是 Web 上的）一般被认为是 Web 服务领域的问题。
一些 Microsoft 客户可能对 .NET Remoting 或多或少有些疑惑。我经常听到有人问“应该在什么时候使用 Remoting？”、“Remoting 何时会支持 NTLM？”、“如何保证远程会话的安全？”、“COM+ 怎么样？”以及“Remoting 如何管理事务？”
除了回答这些问题，本文将介绍一些使用 .NET Remoting 的最佳方法，并概要介绍当前可以获得的功能。摘要预测了该技术的未来发展方向，特别是有关 Web 服务和新兴的全局 XML Web Service 体系结构 (GXA) 规范的问题。
其中介绍了很多在开发过程中用到的简单易行的最佳方法，和我在开发多层 .NET 应用程序中获得的Remoting 的个人经验。
客户端/服务器通信
.NET Remoting 提供了一种很有用的方法，用于管理跨应用程序域的同步和异步 RPC 会话。远程对象代码可以运行在服务器上（如服务器激活的对象和客户端激活的对象），也可以运行在客户端上（其上的远程对象已经通过客户端/服务器的连接进行了序列化）。在任何一种情况下，只要完成初始化和配置（这并不困难），即可使用非常简单的编程语言，只需要少量的代码。远程对象（在按引用封送时是代理的对象）的使用对程序员是透明的。例如，早期的 Windows RPC 机制要求熟悉的类型和使用 IDL 工具的封装处理知识，并向开发人员公开 RPC 客户端和服务器存根的管理。Remoting 在为 .NET 提供 RPC 时要容易得多，而且由于使用简单易懂的 .NET 数据类型，从而消除了早期 RPC 机制中存在的类型不匹配的情况（这是一个非常大的威胁）。
默认情况下，可以将 Remoting 配置为使用HTTP或TCP 协议，并使用 XML 编码的 SOAP 或本机二进制消息格式进行通信。开发人员可以构建自定义的协议（通道）或消息格式（格式化程序），并在需要时由 Remoting 框架使用。服务器和客户端组件都可以选择端口，就象可以选择通信协议一样。由此带来的一个好处是，很容易建立并运行基本的通信。
但是，在选择通信类型时还要考虑状态管理。接下来将介绍 Remoting 提供的各种通信选项及其相关的设计含义。
