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

代码:

<service>

  <wellknown mode="SingleCall" type="Hello.HelloService, Hello"

                    objectUri="HelloService.soap" />

</service>

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

服务器激活的对象有两种激活模式：Singleton 和 SingleCall.

1) Singleton(单实例):

这些对象遵循传统的Singleton 设计模式，在这种模式中，任何时候内存中都只有一个实例，所有客户端都接受该实例提供的服务。

特点:

a.在服务器段只实例化一次,以后每次调用都访问同一个实例。

b.可以维持状态

2) SingleCall(单调用)

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

特点:

a.每次调用都实例化新的实例

b.更好地支持无状态编程模型

2 客户端激活

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

代码：

<service>

  <activated type="Hello.HelloService, Hello"

              objectUri="HelloService.soap" />

</service>

上面描述了一个客户端激活的类型。请注意，我们不再需要 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高。

根据需求，我们的系统必须以C/S方式构建，而且是三层架构，这样一来，就出现了服务器端和客户端通信的问题。      



       为了解决双方的通信问题，还要考虑效率、性能等方面，经过分析、试验，我们根据效率、移植、开发难易等几个因素，舍弃了一开始提出的WebService、消息队列机制，以及有人建议的基于流I/O自己解析数据的通信方式，在分析了目前主流的RPC方式（DCOM、CORBA、.NET Remoting）及我们的开发平台后，最终选择了微软新推出的.NET Remoting机制。我们的原因如下：

       1、.NET Remoting是目前分布式对象实现RPC的一种主要方式。

       2、.NET Remtoing在性能上可以达到DCOM，或者与之相差不多。

       3、.NET Remoting建立在.NET定义的公共数据类型CTS及运行环境CLR之上，和.NET框架有着很好的互操作性，因此功能强大切易于使用。

       4、扩展性和安全性方面都比较好。



       从试验结果来看，该机制可以实现C/S模式下的双方通信，而且在性能上具有很好的保障。根据我们开发完毕的系统性能来看，Remoting机制很好的实现了我们赋予它的任务，或者说，我们采用Remoting机制达到了我们预期的目标。



       下面，对我们采用Remoting机制进行开发这一从无到有过程中的一些资料、感悟进行整理。


基本概念

       .NET Remoting是微软随.NET推出的一种分布式应用解决方案，被誉为管理应用程序域之间的 RPC 的首选技，它允许不同应用程序域之间进行通信（这里的通信可以是在同一个进程中进行、一个系统的不同进程间进行、不同系统的进程间进行）。



       更具体的说，Microsoft .NET Remoting 提供了一种允许对象通过应用程序域与另一对象进行交互的框架。也就是说，使用.NET Remoting，一个程序域可以访问另外一个程序域中的对象，就好像这个对象位于自身内部，只不过，对这个远程对象的调用，其代码是在远程应用程序域中进行的，例如在本地应用程序域中调用远程对象上一个会弹出对话框的方法，那么，这个对话框，则会在远程应用程序域中弹出。



.NET Remoting框架提供了多种服务，包括激活和生存期支持，以及负责与远程应用程序进行消息传输的通讯通道。格式化程序用于在消息通过通道传输之前，对其进行编码和解码。应用程序可以在注重性能的场合使用二进制编码，在需要与其他远程处理框架进行交互的场合使用 XML 编码。在从一个应用程序域向另一个应用程序域传输消息时，所有的 XML 编码都使用 SOAP 协议。出于安全性方面的考虑，远程处理提供了大量挂钩，使得在消息流通过通道进行传输之前，安全接收器能够访问消息和序列化流。


一般来说，.NET Remoting包括如下几点主要元素：

Ø         远程对象：运行在Remoting服务器上的对象。客户端通过代理对象来间接调用该对象的服务，如上图的“通信体系结构”所示。在.NET Remoting体系中，要想成为远程对象提供服务，该对象的类必须是MarshByRefObject的派生对象。另外，要说明的是，需要在网络上传递的对象，例如“参数”，则必须是可序列化的。

Ø         信道：信道是服务器和客户机进行通信用的（这里的服务器和客户机并不一定都是计算机，也可能是进程）。在.NET Remoting中，提供了三种信道类型：TCP、HTTP、IPC，另外，也可以定制不同的信道以适应不同的通信协议（至于如何定制，我尚未涉及到，因此，不好说）。

Ø         消息：客户机和服务器通过消息进行信息交换，消息在信道中传递。这里的消息包括，远程对象的信息，调用方法名称，参数，返回值等。

Ø         格式标识符：该标识符标明了消息是按照什么样的格式被发送到信道上的，目前.NET 2.0提供了两种格式标识符：SOAP格式和二进制格式。SOAP格式标识符符合SOAP标准，比较通用，可以和非.NET 框架的Web服务通信。二进制格式标识符，则在速度、效率上面更生一筹，但通用性较SOAP差。另外，Remoting还支持自定义的格式标识符。（顺便说一下：TCP信道，默认使用二进制格式传输，因为这个效率更高；Http信道则默认使用SOAP格式；不过在系统中，哪种信道具体使用哪种格式，则是可以根据需要设置的。）。

Ø         格式标识符提供程序：它用于把格式标识符和信道联系起来。在创建信道时，可以指定所要使用的标识符提供程序，一旦指定了提供程序，那么消息被发送到信道上的格式也就确定了下来。