Remoting 优缺点 (转载)

Remoting 优缺点

帮助描述
      .NET 远程处理使您能够方便地构建大范围分布式应用程序，而不管应用程序组件是全部集中在一台计算机上还是分布在世界各地。您可以生成这样的客户端应用程序：它们使用同一台计算机（或可通过网络达到的其他任何计算机）上的其他进程中的对象。您也可以使用 .NET 远程处理与同一进程中的其他应用程序域进行通信

      .NET 远程处理为进程间通信提供了一种抽象的方法，它将可远程处理的对象与特定客户端或服务器应用程序域以及特定的通信机制隔离开来。因此，这很灵活且容易自定义。可以用一种通信协议替换另一种通信协议，或者用一种序列化格式替换另一种序列化格式，而不必重新编译客户端或服务器。此外，远程处理系统假定没有特别的应用程序模型。可以从 Web 应用程序、控制台应用程序、Windows 服务，即差不多可以从希望使用的任何程序中进行通信。远程处理服务器也可以是任何类型的应用程序域。任何应用程序都可以承载远程处理对象并向其计算机或网络上的任何客户端提供服务。

（《Microsoft .NET Remoting》）
容错
       容错是指一个系统内部出现故障时系统能够恢复。创建容错系统的一块基石就是冗余。例如，汽车有两车灯。如果一个车灯坏了可以继续使用另一个车灯到达目的地。
      由于其本性，分布式应用开发利用冗余的概念应用于分布式对象从而构建容错系统。将完全相同的代码功能--或者面向对的应用开发中对象副本--分散到各个节点，这样发生在某节点的故障不会影响其它节点运行的冗余对象的可能性增加。一旦故障发生，其中的一个冗余对象就可以开始执行故障节点的工作，让系统继续执行。

扩展性
      正如分布式应用程序激活容错系统一样，它们通过将应用程序的各种功能区分散到单独的节点实现可扩展性。
      另外，把单独的应用程序分发在不同机器上运行将获得更好的性价比。

管理
      采用这种模型，可以在服务器上修改业务规则而不会或几乎不会中断客户端服务。

和Web Services 对比
（《是使用 ASP.NET Web 服务还是使用 .NET Remoting：如何选择》）
       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，客户端必须理解它们。