Remoting基础，比较，应用

基础：

 

什么是Remoting，简而言之，我们可以将其看作是一种分布式处理方式 。从微软的产品角度来看，可以说Remoting就是DCOM的一种升级，它改善了很多功能，并极好的融合到.Net平台下。Microsoft .NET Remoting 提供了一种允许对象通过应用程序域与另一对象进行交互的框架。这也正是我们使用Remoting的原因。为什么呢？在Windows操作系统中，是将应用程序分离为单独的进程。这个进程形成了应用程序代码和数据周围的一道边界。如果不采用 进程间通信（RPC）机制，则在一个进程中执行的代码就不能访问另一进程。这是一种操作系统对应用程序的保护机制。然而在某些情况下，我们需要跨过应用程序域，与另外的应用程序域进行通信，即穿越边界。 　　在Remoting中是通过通道（channel）来实现两个应用程序域之间对象的通信的。首先，客户端通 过Remoting，访问通道以获得服务端对象，再通过代理解析为客户端对象。这就提供一种可能性，即以服务的方式来发布服务器对象。远程对象代码可以运 行在服务器上（如服务器激活的对象和客户端激活的对象），然后客户端再通过Remoting连接服务器，获得该服务对象并通过序列化在客户端运行。 　　在Remoting中，对于要传递的对象，设计者除了需要了解通道的类型和端口号之外，无需再 了解数据包的格式。但必须注意的是，客户端在获取服务器端对象时，并不是获得实际的服务端对象，而是获得它的引用。这既保证了客户端和服务器端有关对象的 松散耦合，同时也优化了通信的性能。

 

Remoting的两种通道：

 

Remoting的通道主要有两种：Tcp和Http。在.Net中，System.Runtime.Remoting.Channels中定义了 IChannel接口。IChannel接口包括了TcpChannel通道类型和Http通道类型。它们分别对应Remoting通道的这两种类型。 　　TcpChannel类型放在名字空间 System.Runtime.Remoting.Channels.Tcp中。Tcp通道提供了基于Socket 的传输工具，使用Tcp协议来跨越Remoting边界传输序列化的消息流。TcpChannel类型默认使用二进制格式序列化消息对象，因此它具有更高 的传输性能。HttpChannel类型放在名字空间System.Runtime.Remoting.Channels.Http中。它提供了一种使用 Http协议，使其能在Internet上穿越防火墙传输序列化消息流。默认情况下，HttpChannel类型使用Soap格式序列化消息对象，因此它具有更好的互操作性。通常在局域网内，我们更多地使用TcpChannel；如果要穿越防火墙，则使用HttpChannel。

 

 

 

 

远程对象的激活方式：

 

在访问远程类型的一个对象实例之前，必须通过一个名为Activation的进程创建它并进行初始化。这种客户端通过通道来创建远程对象，称为对象的激活。在Remoting中，远程对象的激活分为两大类：服务器端激活和客户端激活。 　　服务器端激活，又叫做WellKnow方式，很多又翻译为知名对象。为什么称为知名对象激活模式呢？是因为服务器应用程序在激活对象实例之前会在一个众所周知的 统一资源标识符(URI)上来发布这个类型。然后该服务器进程会为此类型配置一个WellKnown对象，并根据指定的端口或地址来发布对象。. Net Remoting把服务器端激活又分为SingleTon模式和SingleCall模式两种。 　　SingleTon模式：此为有状态模式。如果设置为SingleTon激活方式，则 Remoting将为所有客户端建立同一个对象实例。当对象处于活动状态时， SingleTon实例会处理所有后来的客户端访问请求，而不管它们是同一个客户端，还是其他客户端。SingleTon实例将在方法调用中一直维持其状 态。举例来说，如果一个远程对象有一个累加方法（i=0；++i），被多个客户端（例如两个）调用。如果设置为SingleTon方式，则第一个客户获得 值为1，第二个客户获得值为2，因为他们获得的对象实例是相同的。如果熟悉Asp.Net的状态管理，我们可以认为它是一种Application状态。 　　SingleCall模式：SingleCall是一种无状态模式。一旦设置为 SingleCall模式，则当客户端调用远程对象的方法时， Remoting会为每一个客户端建立一个远程对象实例，至于对象实例的销毁则是由GC自动管理的。同上一个例子而言，则访问远程对象的两个客户获得的都 是1。我们仍然可以借鉴Asp.Net的状态管理，认为它是一种Session状态。 　　客户端激活。与WellKnown模式不同， Remoting在激活每个对象实例的时候，会给每个客户端激活的类型指派一个URI。客户端激活模式一旦获得客户端的请求，将为每一个客户端都建立一个 实例引用。SingleCall模式和客户端激活模式是有区别的：首先，对象实例创建的时间不一样。客户端激活方式是客户一旦发出调用的请求，就实例化； 而SingleCall则是要等到调用对象方法时再创建。其次，SingleCall模式激活的对象是无状态的，对象生命期的管理是由GC管理的，而客户 端激活的对象则有状态，其生命周期可自定义。其三，两种激活模式在服务器端和客户端实现的方法不一样。尤其是在客户端，SingleCall模式是由 GetObject()来激活，它调用对象默认的构造函数。而客户端激活模式，则通过CreateInstance()来激活，它可以传递参数，所以可以 调用自定义的构造函数来创建实例。

 

比较：

1：socket VS remoting

    使用socket无疑是效率最高的。但是，在复杂的接口环境下，socket的开发效率也是最低的。故在兼顾开发效率的情况下，可以使用remoting来代替socket开发。并且：
    1、Tcp通道的Remoting速度非常快。
    你可以通过端口查看工具，发现remoting比直接socket传输的内容，应该是属于同一个数量级的。我的另一个担心是，大客户端数量的情况下，remoting传输效率会不会很低，结果经过现场测试，同时对300个客户端进行数据通信，不存在信息丢失情况。
    2、虽然是远程的，但是非常接近于本地调用对象。
    也就是完全符合面向对象思想。
    3、可以做到保持对象的状态
    直接使用socket传输机制，我们必须花大量的精力来处理异常、断网、死机等现象，使用remoting，这些工作会大大简化。

2：remoting vs webservice 
    1、webservice在framework2.0状态下只能寄宿于IIS等应用服务器中。微软直到3.0才提供了servicehost来寄宿 webservice，这就极大地限制了webservice在使用中的灵活性。在framework2.0环境下，如果你有一个应用要脱离IIS而存 在，就不得不抛弃webservice。（除非你想代码实现一个WEB应用服务器）
    2、remoting可寄宿在你自己的代码中，也可寄宿在windows服务及IIS中。最大程度的提供了开发和部署的灵活性。
    3、remoting在使用http通道的时候，也如webservice一样支持穿透路由。
    4、remoting与websercie相比，提供双向通信。哪怕是将remoting寄宿在IIS中，也支持。
    5、webservice客户端自动生成的代理类比较复杂。而remoting一般来说，都是手动编写客户端代码。
    6、当然，webservice最主要优势是，它是一个行业标准，而remoting只是微软自己内部的标准，如果你的应用要脱离微软的平台，就只能使用webservice了。

3：remoting vs wcf
    与wcf的比较，更多的是从平台的普及度上来说。在当前环境下，2.0的普及度还是最高的。如果哪一天3.0甚至4.0普及了，当然WCF是最好的。