[转]解析.net remoting 技术要点

Remoting技术简介

一 Remoting技术出现的背景

1)分布式应用需求的迅速增长(Peer-to-Peer,Grid等技术的出现)
2)原有的C/S,B/S模式和技术已经不能胜任(串口RS232,Socket,RPC,DCOM技术各有缺点)

二 什么是Romoting?

采用分布式进行编程的一种技术，Remoting主要用于管理跨应用程序域的同步和异步RPC 会话。在默认情况下，Remoting使用 HTTP 或 TCP 协议，并使用 XML 编码的 SOAP 或本机二进制消息格式进行通信。.NET Remoting 提供了非常灵活和可扩展的编程框架,并且他可以管理对象的状态。

Remoting优点：
1) 性能: 如果调优.Net Remoting 的性能，那么他的性能非常好，速度接近DCOM.
2) 可扩展:.Net Remoting 可供你选择传输通道类型(如Http,Tcp)和格式类型（如Binary,Soap)。
3)?可配置：可以通过配置文件配置应用程序。
4) CLR和CTS的好处：由于.NET Remoting是基于.NET框架的，所以他拥有Common Type System(CTS) 和 Common Language Runtime(CLR)所拥有的易于使用和功能强大的特点。
5）互用性(Interoperability): .NET Remoting 支持开发标准（Http,SOAP,WSDL,XML).
6)?安全性
7)?生命周期管理

三 Remoting架构:

Remoting通过通道(channel)来传输消息。.NET Remoting支持两种默认的协议支持通道（Http和Tcp).

四 远程对象的两个含义

操作远程对象:对象运行在远程,客户端向他发送消息.
传递远程对象:将远程的对象拿到本地,或者将本地对象发送过去,然后我们可以对副本进行操作.

五 激活对象的两种方式:服务器激活和客户端激活

1 服务器激活：“服务器激活的对象”是由服务器控制生存期的对象。它们只在客户端调用对象的第一个方法时，根据需要由服务器创建。服务器激活的对象只支持默认的构造函数。
代码:

上面描述了一个服务器激活的 (wellknown) 类型，其激活方式设置为?SingleCall。

服务器激活的对象有两种激活模式：Singleton?和?SingleCall.
1) Singleton(单实例):
这些对象遵循传统的Singleton 设计模式，在这种模式中，任何时候内存中都只有一个实例，所有客户端都接受该实例提供的服务。
特点:
a.在服务器段只实例化一次,以后每次调用都访问同一个实例。
b.可以维持状态

2) SingleCall(单调用)
SingleCall?远程服务器类型总是为每个客户端请求设置一个实例。下一个方法调用将改由其他实例进行服务。从设计角度看，SingleCall?类型提供的功能非常简单。这种机制不提供状态管理，如果您需要状态管理，这将是一个不利之处；如果您不需要，这种机制将非常理想。也许您只关心负载平衡和 可伸缩性而不关心状态，那么在这种情况下，这种模式将是您理想的选择，因为对于每个请求都只有一个实例。如果愿意，开发人员可以向?SingleCall?对象提供自己的状态管理，但这种状态数据不会驻留在对象中，因为每次调用新的方法时都将实例化一个新的对象标识。
特点:
a.每次调用都实例化新的实例
b.更好地支持无状态编程模型

2 客户端激活
“客户端激活的对象”是当客户端调用?new?或?Activator.CreateInstance()?时在服务器上创建的。
代码：

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

六 Remoting VS Web Service?

这两者都是基于分布式的开发,而且.Net Remoting有时也可以配置为Web Service，两者有很多的相同之处。

一般来讲，我把他们的不同之处列为5个方面。

1) 开发部署
WebService开发和部署比较简单，Remoting相对WebService开发和部署要稍复杂。
2) 协议的开放性　
???? 两者都可支持HTTP,TCP,SMTP等多种协议。
????[一直以为WebService只支持HTTP协议,经idior指点,原来在Web Services Enhancements已有介绍，WebService也支持TCP,SMTP等协议。微软最新发布的wse应该是wse 3.0，以前还没听说过，真是汗颜！]
?? 更详细的内容待续...
3) 支持的类型系统
WebService只支持XSD类型系统，对象的类型的序列化受到限制，而Remoting可以通过序列化为Binary传输数据，支持更为广泛的数据类型
4) 安全性
由 于 ASP.NET Web 服务依赖于 HTTP，因此它们与标准的 Internet 安全性基础结构相集成。ASP.NET 利用 IIS 的安全性功能，为标准 HTTP 验证方案（包括基本、简要、数字证书，甚至 Microsoft　.NET Passport）提供了强有力的支持。
一般情况下，.NET Remoting 管线不能确保跨进程调用的安全。使用 ASP.NET 托管于 IIS 中的 .NET Remoting 端点可以利用 ASP.NET Web 服务可用的所有安全性功能，包括对使用 SSL 确保有线通信的安全性的支持。
5) 性能
从原始性能方面来讲，使用 TCP 信道和二进制格式化程序时，.NET Remoting 管线能够提供最快的通信。一般情况下，.NET Remoting的性能要比WebService高。

?

---------------------------------------------------------------------------------------------------------------------------------------

  Remoting 为应用程序间或进程间通讯提供了一种可行的途径。两个进程可以存在于同一台电脑也可以分别存在于连网的局域网或者广域网中的两个

不同的计算机上。计算机进程间通讯表面上看起来没什么大不了的，不过，它却有一个相当复杂的过程。以下向你阐述原因。

?在任何操作系统中，安全与稳定是两个最重要的目标。实现这两个目标的途径是把每个当前执行的应用程序载入到单独的进程中去。由于这样的设计，

应用程序进程彼此隔离，这样，一个进程中的代码就无法访问到另外一个进程中的代码或数据。那样的设计，就强制性地使一个进程不可以也不可能访

问到它不被允许触及的资源范围，保证了，安全性的方面的目标实现。另外，这样的设计也通过保证一个问题进程对另外一个进程或者操作系统进程的

内存空间不会造成破坏而实现了在稳定方面的目标.
? .NET?FRAMEWORK通过application domains提供了另一种级别的隔离,它授权两个或者更多程序运行在同一进程中，维持着同级别的隔离好像他们是

处于各自的进程中，但同时概观上又是一个多进程的整体。
?? 进程间隔离的需求是很明显的，然而，却也存在着别外一个事实：进程间通讯有时也是需要的。对分布式计算与分布式测量的强调与需要变得越来起

迫切。.NET FRAME. WORK 框架提供了几种途径来解决进程间通讯这一需求，总起来说，我们说remoting,web services 可能是最广为人知的remoting方

式。不过，它们却也不是你的仅有的选择。本文你将会看到.net remoting 技术的概观,这将帮助你选择各种各样的remoting技术实现类型。。
?? Remoting 在服务端的一个进程里面生成一个可以在客户端的另一个进程里面可编程的对象，这就是marshalling，有两种完全不同的方式来

marshal 一个对象;
??? 1.Marshal by value:服务端创建一个对象的copy,并把COPY传递到客户端;
??? 2.Marshal by reference:客户端创建该对象的代码并使用此代理来访问这个对象.当一个客户端发出一个向[mashalled by value(MBV)]对象的请求时，

服务端创建一个完全一样的COPY并把这个拷贝传至客户端.客户端就可以直接在客户端自已的进程内或者应用程序域里面使用这个对象的数据与可执行函数

体而不需要额外地向服务端发面其它请求。要实现MBV，在你的类里面你必须要么实现ISerializable接口，要么添加<serialazable>属性标记。
?
? 与之相对，当一个客户要向一个[marshalled by reference(MBR)]过的对象发出请求的时候，.netframe. 会在客户端就用程序域里创建一个代理，这样

客户端就使用这个代码来访问服务端的源对象。要实现MBR，一个类必须最少扩展System.MarshalByRefObject 类，下图展示了MBV与MBR的区别.
??

  有了MBV与MBR的区别，你如何确定什么时间使用哪一种来对远程对象进行编程呢？在某些情况下，你没得选择-你必须用MBR，这样的情况比如：你当一个

应用程序组件必须运行在源远程应用程序域内,它要使用服务端的操作系统句柄或者服务端文件，另外当客户端需要了解到服务端的对象中的变化的时候我

们也需要用到MBR。当使用MBV的时候Marshalled 过的对象的一份完全一样的被发送到客户端的拷贝是静态的，并不会影响到(/改变)服务端marshalled过的对象的状态。

? 在很多情况下，MBV 或者MBR都是可行的，问题是哪一个更好呢？这里关心的一点是：带宽．那一种技术对客户机与服务端之间的数据传输方面的需求更少

一些呢？MBV的话，需要一次性地把一个对象拷贝传输到客户端，不过，如果这个对象太大的话，那样就是一个不小的工作量了，在对象拷贝被传送到客户端

后，对对象的访问就只限于客户端的应用程序域范围内，完全不需要涉及到传输机制．
　　相反的，MBR并不需要传送一个对象拷贝到客户端，每次访问对象都需要一个一来一回的数据信息的传送，个人认为少量的请求可能不至于加重了通讯的

负载，但是如果客户端发出的请求数以万计的话，这个对带宽的影响由不得你不去考虑．
　　那么选择基准呢？如果对象数据量比较小而应用程序要频繁访问这样的情况最好呢就是MBV,如果对象数据量比较大而客户机访问服务端次数相对不是很

频繁，那就用MBR
? --------------------------------------------------------------------------
?? channel是一个实现在应用程序域间客户端对象与服务端对象进行通讯的对象,.net framework 默认实现了以下两种channel:
? HttpChannel：使用http协议实现地一种通道；
　TcpChannel:? 使用Tcp协议实现的一种通道.
  这两者都是有双重目地的：他们在客户端实现一处通道，用来在客户方与远程服务端对象进行通讯，另在服务端实现一个通道用来在服务端与客户端进行

通讯．HttpChannel类使用SOAP协议封装信息，soap协议会把这个通讯内容以XML文件格式进行传输,相应的TchChannel却是使用字节码(二进制)格式地封装

这些传输信息．当然，二进制格式较为更高效一些(封装过的数据量更小)，而简单的文本形式的soap格式却是更易于在网络安全性能方面要求较高像安装有

防火墙这样的环境中等工作．
　　当你创建一个服务对象－远端对象，你也就为这个对象定义与注册了一个或多个通道，每一个通道有一个特别的端口．通过注册一个通道/接口组合，

你告诉了.net infrastructure 来监听通过这个通道的端口以便随时获取请求信息．当一个消息到达里，framework　把它引导到正确的服务端对象，下图

展示了客户端与服务端的通讯情况，注意，当你在单独的一个系统里面运用remoting 里，客户端端口号与服务端端口号不可以相同，因为对于一个指定的

端口你只可以使用一次．
　　在客户端你的代码也同样的创建一通道与相应的一个指定的端口，它使用Activator类来获取远程对象的一个引用，这个引用是对(MBV)的对象的引用，

或许可能是(通过远程对象的代理MBR)的对象的引用，你可以通过远程对象所在服务器URL，所以类名，和你指定的一个URI来唯一标识一个远程对象,

.netinfrastructure 会考虑到这些细节--作为一个远程用户，你用不着关心远程服务端对象使用的是MBV还是MBR或者其它方面的东西。