|
Remoting 为应用程序间或进程间通讯提供了一种可行的途径。两个进程可以存在于同一台电脑也可以分 别存在于连网的局域网或者广域网中的两个不同的计算机上。计算机进程间通讯表面上看起来没什么大不 了的，不过，它却有一个相当复杂的过程。以下向你阐述原因。 在任何操作系统中，安全与稳定是两个最重要的目标。实现这两个目标的途径是把每个当前执行的应用程 序载入到单独的进程中去。由于这样的设计，应用程序进程彼此隔离，这样，一个进程中的代码就无法访 问到另外一个进程中的代码或数据。那样的设计，就强制性地使一个进程不可以也不可能访问到它不被允 许触及的资源范围，保证了，安全性的方面的目标实现。另外，这样的设计也通过保证一个问题进程对另外一 个进程或者操作系统进程的内存空间不会造成破坏而实现了在稳定方面的目标. .NET FRAMEWORK通过application domains提供了另一种级别的隔离,它授权两个或者更多程序运行在同 一进程中，维持着同级别的隔离好像他们是处于各自的进程中，但同时概观上又是一个多进程的整体。 进程间隔离的需求是很明显的，然而，却也存在着别外一个事实：进程间通讯有时也是需要的。 进程间通讯这一需求，总起来说，我们说remoting,web services 可能是最广为人知的remoting方式。不 过，它们却也不是你的仅有的选择。本文你将会看到.net remoting 技术的概观,这将帮助你选择各种各 样的remoting技术实现类型。。
marshalling，有两种完全不同的方式来marshal 一个对象; 当一个客户端发出一个向[mashalled by value(MBV)]对象的请求时，服务端创建一个完全一样的COPY并 把这个拷贝传至客户端.客户端就可以直接在客户端自已的进程内或者应用程序域里面使用这个对象的数 据与可执行函数体而不需要额外地向服务端发面其它请求。要实现MBV，在你的类里面你必须要么实现 ISerializable接口，要么添加<serialazable>属性标记。 frame 会在客户端就用程序域里创建一个代理，这样客户端就使用这个代码来访问服务端的源对象。要实 现MBR，一个类必须最少扩展System.MarshalByRefObject 类，下图展示了MBV与MBR的区别. 有了MBV与MBR的区别，你如何确定什么时间使用哪一种来对远程对象进行编程呢？在某些情况下，你没 得选择-你必须用MBR，这样的情况比如：你当一个应用程序组件必须运行在源远程应用程序域内,它要使 用服务端的操作系统句柄或者服务端文件，另外当客户端需要了解到服务端的对象中的变化的时候我们也 需要用到MBR。当使用MBV的时候Marshalled 过的对象的一份完全一样的被发送到客户端的拷贝是静态的 ，并不会影响到(/改变)服务端marshalled过的对象的状态。
术对客户机与服务端之间的数据传输方面的需求更少一些呢？MBV的话，需要一次性地把一个对象拷贝传 输到客户端，不过，如果这个对象太大的话，那样就是一个不小的工作量了，在对象拷贝被传送到客户端 后，对对象的访问就只限于客户端的应用程序域范围内，完全不需要涉及到传输机制． 相反的，MBR并不需要传送一个对象拷贝到客户端，每次访问对象都需要一个一来一回的数据信息的 传送，个人认为少量的请求可能不至于加重了通讯的负载，但是如果客户端发出的请求数以万计的话，这 个对带宽的影响由不得你不去考虑． 数据量比较大而客户机访问服务端次数相对不是很频繁，那就用MBR
channel是一个实现在应用程序域间客户端对象与服务端对象进行通讯的对象,.net framework 默认实 现了以下两种channel: HttpChannel：使用http协议实现地一种通道； 服务端实现一个通道用来在服务端与客户端进行通讯．HttpChannel类使用SOAP协议封装信息，soap协议 会把这个通讯内容以XML文件格式进行传输,相应的TchChannel却是使用字节码(二进制)格式地封装这些传 输信息．当然，二进制格式较为更高效一些(封装过的数据量更小)，而简单的文本形式的soap格式却是更 易于在网络安全性能方面要求较高像安装有防火墙这样的环境中等工作． 当你创建一个服务对象－远端对象，你也就为这个对象定义与注册了一个或多个通道，每一个通道有 一个特别的端口．通过注册一个通道/接口组合，你告诉了.net infrastructure 来监听通过这个通道的 端口以便随时获取请求信息．当一个消息到达里，framework 把它引导到正确的服务端对象，下图展示 了客户端与服务端的通讯情况，注意，当你在单独的一个系统里面运用remoting 里，客户端端口号与服 务端端口号不可以相同，因为对于一个指定的端口你只可以使用一次．
在客户端你的代码也同样的创建一通道与相应的一个指定的端口，它使用Activator类来获取远程对 象的一个引用，这个引用是对(MBV)的对象的引用，或许可能是(通过远程对象的代理MBR)的对象的引用， infrastructure 会考虑到这些细节--作为一个远程用户，你用不着关心远程服务端对象使用的是MBV还是 MBR或者其它方面的东西，在下面的demo程序中，你会发现是如此简单.
--------------------------demo-------------------------------------------- ，一个服务端，一个客户端，要使本实例切实可运行，打开vs.net命令行模式，为本项目创建一个文件夹 ，使文件夹为当前文件夹(意思，应该是cd 到项目所在文件夹). 远程类(RemoteClass)包含一个返回到请求方"secret"字符串的简单方法，类构造函数显示一个console消 息当客户端激动了这个类，当然，这里console message 只是一个演示，它并没有存在的必要性。注意， 本类唯一的与remoting 相关的一个方面是它继承自MarshalByRefObject.你可以使用任何文件编辑器来创 建本DEMO代码然后把它保存到一个项目文件夹下以RemotingClass.cs命名即可。然后，在命令行模式下， 以下面命令编译本类(一定要同一行中把命令全部输入进去)： 然后，你需要创建客户端(Client.cs),用它来调用远程类,它包含以下内容： 法体并显示返回数据。
型，你可以通过使用typeof()方法获得和类的名字空间和类名作为参数，第二个参数有以下部分：
8085: 指定远程类监听的端口，
编译本客户端，注意：编译器指定一个到你前面创建的RemotingClass.dll的引用. csc /debug /r:remoteclass.ell /r:System.Runtime.Remoting.dll Client.cs 内容：
下，才有可能会"监听"来自客户端的请求,
csc /debug /r:remoteclass.dll /r:System.Runtime.Remoting.dll Server.cs
1.再打开一个命令行窗口，切入到项目文件夹下，现在，你有两个打开的命令行窗口(这种需要是很明 显的) 端就处于监听状态下，监听来自客户端的请求， 好了，一个简单的实现.net framework的remoting 功能的例子就是这样了，不过，很少有现在 工作当中的应用程序需求会像本程序这么简单，不过，基本原理是一样的.
源代码：http://assets./sourcecode/3825.zip |
|
|
来自： ThinkTank_引擎 > 《Remoting》
