用.Net Remoting访问远程对象

用.Net Remoting访问远程对象 

 Net提供了好几种通信协议与方式使得这种开发变得简单而快速，你甚至无需知道太多的传输协议与编码细节。因此，无论你开发一个web应用还是关键的、涉及多操作系统和多通信协议的企业级应用，.Net都将对你提供全面的支持。跨进程的对象通信技术一直是个复杂的工作，现在这些复杂的处理工作都交给.Net framework来完成了。

    .Net Remoting能使客户端应用调用位于本机或者网络上其他进程中的对象，你也可以利用.Net Remoting调用同一个进程中不同应用域中的对象。.Net Remoting提供了一种可以把远程对象的通信机制从特定服务器和客户端中分离出来的抽象方法，因此，它是灵活的、方便的，并且是易于定制的。你可以更换通信协议和交换格式，而无需重新编译客户端和服务器端应用。另外，这个远程机制并不针对任何特定的应用模式，你可以从一个web application、一个主控台应用、一个windows service---------甚至是任何你需要的系统发起调用。远程服务器也可以是任何类型的可执行系统，任何应用都可以宿主/容纳（作为一个对象容器）一个远程对象并且对任何客户端提供该远程对象的服务。

 选择.Net调用协议 

    .Net Framework 提供了好几种面对不同应用域的对象调用方法，每一种方式都有其独特的技术与弹性。比如，Internet的快速成长使得XML/Web Service成为一种极富诱惑力的通信手段，因为Web Service建立在Http协议和以XML作为交换格式的Soap协议之上，而这一基础架构普遍存在。它们已经是公共标准，可以在web架构中随时使用，而不用担心访问代理和防火墙的问题。    

    但是，并非所有的应用都应该使用Web Service，基于Http连接的Soap数据流传输（serialization）存在严重的效率问题。这里我们将探讨那一种对象互操作协议适合于你的应用。 

Asp.net 还是 Remoting?   

    Asp.net和.net remoting都是进程间通信的实现方式。Asp.net基于IIS，这种基础架构已为开发者熟悉。 .net remoting则是一种更加一般性的、扩展的进程间互操作机制。通过.net remoting你不仅可以产生基于IIS的XML Web Service服务（和包括安全性、延展性、session、ASP.net和IIS等应用形态），也可以产生任何其他通信协议和传输格式的应用。 

    你需要的通信方式和你熟悉的开发模式是你选择Asp.net或者remoting的两条基本准则。无论你如何选择，你需要用最简单的方法达到你的目标。

     下面是一些根据优先级排列的互操作通信协议（XML web service built with asp.net, XML web service built with .net remoting）的选择原则。

 （1）安全性

     如果你注重调用的安全性，无论是一个ASP.net应用还是一个remoting应用，你必须使用宿主在IIS上的基于HTTP的应用模式。这是因为Asp.net和.net remoting使用IIS提供的安全性服务。.net remoting并不提供位于IIS之外的独立的安全性策略，比如在一个windows service应用之中。  

    尽管你可以在任何应用域中使用.net remoting（不像用asp.net构建的xml web service，必须寄生/宿主在IIS中），但是你必须独立提供安全性服务，除非你的.net remoting应用基于IIS。  

    如果你使用HTTP连接，你无需使用XML/SOAP封包格式，你可以使用二进制编码来提升传输速度。 

（2）速度  

    在用ASP.net构建的XML Web Services中，.Net Remoting具备潜在的性能优势，因为.net remoting允许你使用二进制编码与缺省的tcpchannel，这将导致极好的互操作性能。即使你不使用缺省的tcpchannel，你依然可以在httpchannel（基于IIS或者任何httpchannel侦听程序）中指定二进制编码传输格式。

    使用二进制编码传输可以显著的提高调用效率，即使你使用httpchannel而不是用tcpchannel. 如果你并不关心安全性问题，比如你的系统运行在防火墙区域内，那么采用httpchannel和二进制编码传输是最佳选择。  

    当不需要使用.net remoting时，用Asp.net构建的Xml web services常常使用soap封包，其效率低于二进制编码传输，但也能提供较好的执行性能。  

（3）互操作  

    如果你希望在不同的操作系统之间互操作，那么无论是asp.net还是.net remoting，你典型地需要使用soap协议。基于asp.net的xml web services比.net remoting提供更多的soap封包定制的灵活性，这将是不同平台之间的互操作变得更加容易。  

    当然，你也可以使用.net remoting实施不同操作系统的互操作，.net remoting优先用于同.net客户端的通信。  

（4）伸缩性  

如果你的应用宿主在IIS中，将给你最大的伸缩性，无论使用.net remoting还是asp.net.  

（5）使用CLR特性  

    因为.net remoting优先用于.net client的通信，那么有下述基于asp.net的xml web services所不具备的clr特性可用。   

• interfaces.
• CallContext.
• properties.
• indexers.
• Managed Extensions for C++.
• Type fidelity between the client and server applications.
• delegates.

（6）面向对象的应用设计

    用asp.net构建的xml web services应用并非面向对象的设计范例，它们本质上都是一些无状态的web资源，比如web page等等，尽管IIS和ASP.net基础架构提供了一些状态服务。  

    .net remoting对象则是真正意义上的对象，它们具有面向对象的所有特征，而这些特征则是asp.net所不具备的。    

l         远程对象的引用  

l         多种对象激活机制  

l         面向对象的状态管理  

l         分布式对象生命周期管理     

    下面介绍一下用asp.net构建的xml web services、system.net 命名空间和.net remoting之间的区别。

  XML Web Services

     如果你希望用web application模型构建具有强大asp.net http运行时支持的asp应用，包括强大的Microsoft Visual Studio.Net的支持，那么用asp.net 构建xml web services是的选择。

     由于xml web services的基础架构，你能够很容易的产生攻其他应用使用的组件，或者使用其他应用的组件。但是两台计算机之间的精确数据类型并不被支持，仅能传递一些参数。

System.Net Namespace  

 你能使用syste.net namespace中的类从底至上构建一个完整的对象调用结构，你也能使用system.net类架构一些嵌入到remoting体系结构中的通信协议和数据传输格式。

.Net Remoting    

.net remoting 提供了沟通对象间调用的工具，包括但不限于xml web services.使用.net remoting，你可以做到：

l         在任何应用域中发布和使用对象服务，不能这个应用域是主控台应用、windows form, IIS, XML web service, 或者是一个windows service。

l         保证全托管代码类型的精确性。而XML web serivces使用soap格式，不支持所有的类型细节。   

l         以引用方式传递对象，并且返回特定应用领域的特定对象。

l         直接控制对象激活与对象生命周期的管理。

l         实现和使用第三方通道channel或协议，以扩展通信功能适应你的特殊需求。

l         直接参与对象通信处理，以实现你需要的功能特性。

     建立两个不同进程中对象之间的平滑通信，是一个普遍性的应用开发需求，尤其是在构建大型分布式应用系统时。具备通信需求的两个不同的进程可以位于一台计算机上，也可以分布于相距遥远的两台计算机上。

     传统上，这要求开发者不仅具备通信对象双方的知识，而且要求具备在底层协议、应用开发接口、配置工具或者文件方面的深厚知识。一句话，这是一项要求具备深厚的技术背景与经验的复杂任务。

Trackback: http://tb.blog.csdn.net/TrackBack.aspx?PostId=577258