微软 .NET Remoting体系结构评估

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

在IIS之外集成
　　
　　在 IIS 之外进行远程集成的方法有很多，如下所示。

　　在控制台应用程序中集成

　　开发人员可以编写一个启动 Remoting 基础结构的控制台应用程序，然后把它“留在附近”。把它留在附近的唯一原因，是因为它包含集成了远程调用的应用程序域。编写一个这样的程序非常简单：只需调用 RemotingConfiguration.Configure 方法，把您的远程主机配置文件传递给它，然后只需等待由某个事件，比如按键或收到特定的消息等来终止进程。

　　这种方法的优势是不要求使用中间层上的 IIS，但不可以随时生成，因此适用于演示、开发和测试。这并不是说它一无是处，只是用途有限而已。

　　在 GUI 应用程序中集成

　　开发人员还可以编写一个启动 Remoting 基础结构的 Windows GUI 应用程序，然后把它“留在附近”。同样，需要继续执行的唯一原因是它包含集成了远程调用的应用程序域。它的开发方法与控制台应用程序的方法相同：Remoting 主机可以直接启动，也可以根据用户的交互操作启动。同样，这种方法也具有不需要中间层上的 IIS 的优势，并可用于演示和测试。对该程序做一些变化可以得到对等网络（逻辑）winforms 应用程序，例如，聊天类型的应用程序。同样，该程序的使用范围也很有限。

　　在系统服务中集成

　　这种可能性非常有意思，因为 Remoting 基础结构提供的功能竟没有系统服务概念本身所提供的功能多。系统服务可以配置为在计算机启动时启动，并保留在周围直到您让它们离开，这对于远程集成是非常理想的。请注意，通过为虚拟应用程序设置“高隔离模式”，也可以将 IIS 应用程序配置为具有类似行为。关于这个问题还有很多内容值得探讨，本文就不讨论了。客户询问了许多关于这种机制的难题，包括它的用途。首先，介绍一些它的优点：我们已经介绍了服务本身的好处；另外，我们可以完全控制主机进程的激活，例如，可以选择是使用动态发布还是使用客户端激活；不需要 IIS，因为我们可以加载用户配置文件，并可以使用 TCP 上的二进制编码消息获得良好的性能。

　　系统服务也需要具有可伸缩性，并可作为 Remoting 服务器重新使用，因为多层的分布式应用程序将需要这些功能。例如，如果没有 IIS，集成服务将不得不管理自己的审核和授权，而这二者都是 IIS 在标准情况下附带的。

　　由于这些原因，系统服务集成机制的用途很有限，也许要在一个受约束的环境下使用，这种环境中的消息要排队进行单独交换，而安全性不是问题，或者还可以使用 TCP 上的 IPSec。

　　企业服务管理

　　为了使远程组件参与到 COM+ 环境中（并在 COM+ 的上下文中运行），需要从 ServicedComponent 中继承。ServicedComponent 和 System.EnterpriseServices 命名空间中提供的其他功能都允许 CLR 组件指定多个 COM+ 属性，如表示事务要求和服务器进程执行的属性等。再加上严格命名机制和使用 regsvcs 命令，远程组件可以成为整个 COM+ 环境中的一部分。

　　假设远程组件需要从 MarshalByRefObject 中继承，COM+ 组件需要从 ServicedComponent 中继承（而且在 .NET 托管代码中没有多重继承功能），如何实现这一点呢？幸运的是，ServicedComponent 是从 ContextBoundObject 派生的，而后者又是从我们需要的 MarshalByRefObject 派生的。在 Remoting 上直接构建 COM+ 集成是完全可以的，而且确实能够获得由企业服务提供的显而易见的优势，例如对象池、分布式的事务支持和基于角色的安全性等。但是，如何做到这一点以及这样的方法对未来验证的体系结构会产生什么样的影响，还是不得而知的。

　　我们有理由期待，随着时间的推移，COM+ 的上下文基础结构和 Remoting 的上下文基础结构将越来越接近。但在现阶段，如何做到这一点以及何时做到这一点还不很清楚。

URL查看 http://www.qqread.com/dotnet/y520949000.html