微软 .NET Remoting体系结构评估

来源：Microsoft 作者：出处：巧巧读书 2005-11-24 进入讨论组

动态发布

　　还需要考虑服务器激活方法的最后一个类型，即动态发布。这是一种服务器激活的类型，通过提供程序化的发布机制，可以对对象结构进行更多的控制。它允许在特定的 URL 发布特定的对象，并可以选择使用参数化的构造函数。

从结构上讲，这种类型可以看作是服务器激活的 Singleton 类型的一个微小变形。有关动态发布的信息，请参阅 .NET Framework Developer's Guide。

　　客户端激活的对象

　　“客户端激活的对象”是当客户端调用 new 或 Activator.CreateInstance() 时在服务器上创建的。客户端本身使用生存期租用系统，可以参与到这些实例的生存期中。这种激活机制能够提供最广泛的设计灵活性。如果使用客户端激活，当客户端试图激活对象时，激活请求将发送到服务器。这种机制允许使用参数化的构造函数和针对每个客户端的连接状态管理。使用客户端激活，每个客户端接受其特定的服务器实例提供的服务，从而简化了多个调用时对象状态的保存过程。但使用这些对象时一定要谨慎，因为很容易忘记会话是分布式的，对象实际上不仅在进程之外，而且在多层应用程序的情况下，还有可能在计算机之外（在 Internet 上设置一个属性并不过分）。实用而不花哨的接口应该成为这里的准则：为了提高性能，我们可能需要在高度结合与松散耦合之间进行权衡。要创建客户端激活类型的实例，可以通过编程的方法配置应用程序，也可以进行静态配置。在服务器上进行客户端激活的配置相当简单，例如，以下代码片段

＜service＞
＜activated type="Hello.HelloService, Hello"
objectUri="HelloService.soap" /＞
＜/service＞

　　描述了一个客户端激活的类型。请注意，我们不再需要 URL，因为对于客户端激活的类型，类型本身就足以激活了。另外，wellknown 标记已被 activated 标记替代。

　　扩展性

　　在处理远程方法调用的过程中，.NET Remoting 将格式化的“消息”沿 Remoting 的“通道”从客户端发送到服务器。消息格式和通道本身都是完全可扩展和可自定义的。默认的通道或格式化程序都可以由自定义构建的组件所替代。消息在传输过程中可以在多个“接收点”被截取和更改，允许对消息进行自定义的处理（例如消息加密）。.NET Framework Developer's Guide (Sinks and Sink Chains) 中介绍了自定义机制，而且 Internet 上已经出现了一些自定义的通道和格式化程序（例如，Named Pipe 通道的实现）。大多数人对这种扩展性并不感兴趣，因为该技术提供的默认格式化程序和通道已经可以在最广的范围内使用（即 TCP 和 HTTP，尤其是与 SOAP 消息格式化程序一起使用）。但是在最初的设计阶段，需要考虑各种解决方案选项，记住这种功能还是有必要的。

　　异常传播

　　.NET Remoting 完全支持跨 Remoting 边界的异常传播，这是对使用错误代码，如 DCOM 的重大改进。

　　使用 Remoting 异常，最好将异常类标记为可序列化的并实现 ISerializable 接口。这样，可以跨 Remoting 边界对异常进行正确地序列化，也可以在构造过程中将自定义的数据添加到异常中。对于需要远程处理以及在使用中要保持一致的异常，最好定义您自己的异常类。确保使用此方法能捕获所有异常并进行正确传播，而且不允许未处理的异常跨过 Remoting 边界。

转载:http://www.qqread.com/dotnet/y520949000.html