remoting socket webservice

最新推荐文章于 2024-08-28 21:39:09 发布

qizhanfeng

最新推荐文章于 2024-08-28 21:39:09 发布

阅读量104

点赞数

文章标签：网络操作系统 runtime

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是最好的。

4：最简单例子 下面给出一个极其简单的Sample： 4.1远程对象 首先，创建一个项目，名为 RemoteObject，该项目经过编译后产生的DLL文件要在remoting客户端的项目和服务器端的项目中被引用。该项目包含一个类 MyObject，即 Remoting使用的远程对象，如下：

using System;
using System.Windows.Forms;

namespace RemoteObject
{
 public class MyObject : MarshalByRefObject { private int i = 0; public int Add(int a, int b) { return a + b; } public int Count() { return ++i; } } }

4.2Server端 新建项目 RemoteServer（控制台）， Server端要引用MyObject的DLL。

using System;
using System.Runtime.Remoting;
using System.Runtime.Remoting.Channels;
using System.Runtime.Remoting.Channels.Tcp;

namespace RemoteServer
{
 class MyServer { [STAThread] static void Main(string[] args) { TcpServerChannel channel = new TcpServerChannel(9999); ChannelServices.RegisterChannel(channel); RemotingConfiguration.RegisterWellKnownServiceType(typeof(RemoteObject.MyObject), "RemoteObject", WellKnownObjectMode.SingleCall); System.Console.WriteLine("Press Any Key"); System.Console.ReadLine(); } } }

4.3Client端 新建项目 RemoteClient（控制台）， Client端也要引用MyObject的DLL。

using System;
using System.Runtime.Remoting.Channels;
using System.Runtime.Remoting.Channels.Tcp;

namespace RemoteClient
{
 class MyClient { [STAThread] static void Main(string[] args) { ChannelServices.RegisterChannel(new TcpClientChannel()); RemoteObject.MyObject remoteobj = (RemoteObject.MyObject)Activator.GetObject(typeof(RemoteObject.MyObject), "tcp://localhost:9999/RemoteObject"); Console.WriteLine("1 + 2 = " + remoteobj.Add(1, 2).ToString()); Console.WriteLine("i = " + remoteobj.Count().ToString());

Console.ReadLine(); } } }

好了，一次运行生成的RemoteServer.exe和RemoteClient.exe ，你就会发现原来Remoting是这样简单。

Remoting是面向对象的。

例如服务器端有一个“聊天室”的对象，你可以这样编程：

聊天室room=(聊天室)Activator.GetObject(typeof(聊天室),"http://www.qq.com;1234/room"); SessionIdSessionId=room.logon(我的QQ号，密码); if(SesionId!=Guid.Empty) room.SendMessage("大家好，我是Wiki！"); 上面首先从服务器获得一个服务对象（连接），调用这个对象的logon函数注册用户，当取得授权之后在聊天室里发言。 如果程序员仅仅使用socket完成这个脚本你会怎样写？在客户端、服务器端要处理通讯、协议、信令解析、最后才是业务逻辑，至少要写5000行代码。使用Remoting和写本地、单进程内的程序几乎没有区别，直接实现业务逻辑。而socket相当于你未吃菜之前先种地，如果你此时确实有的是时间、对蔬菜有最严格的要求、有种菜的技能。

其实现的原理并没有本质的区别，在应用开发层面上有以下区别：
1、Remoting可以灵活的定义其所基于的协议，如果定义为HTTP，则与Web Service就没有什么区别了，一般都喜欢定义为TCP，这样比Web Service稍为高效一些
2、Remoting不是标准，而Web Service是标准；
3、Remoting一般需要通过一个WinForm或是Windows服务进行启动，而Web Service则需要IIS进行启动。
4、在VS.net开发环境中，专门对Web Service的调用进行了封装，用起来比Remoting方便

我建议还是采用Web Service好些，对于开发来说更容易控制
Remoting一般用在C/S的系统中，Web Service是用在B/S系统中
后者还是各语言的通用接口
相同之处就是都基于XML

为了能清楚地描述Web Service 和Remoting之间得区别,我打算从他们的体系结构上来说起:
Web Service大体上分为5个层次:
1. Http传输信道
2. XML的数据格式
3. SOAP封装格式
4. WSDL的描述方式
5. UDDI

总体上来讲，.NET 下的 Web Service结构比较简单，也比较容易理解和应用：
一般来讲在.NET结构下的WebService应用都是基于.net framework以及IIS的架构之下，所以部署(Dispose)起来相对比较容易点.
从实现的角度来讲，

首先WebService必须把暴露给客户端的方法所在的类继承于：System.Web.Services.WebService这个基类
其次所暴露的方法前面必须有[WebMethod]或者[WebMethodAttribute]

WebService的运行机理
首先客户端从服务器的到WebService的WSDL，同时在客户端声称一个代理类(Proxy Class)
这个代理类负责与WebService服务器进行Request 和Response
当一个数据（XML格式的）被封装成SOAP格式的数据流发送到服务器端的时候，就会生成一个进程对象并且把接收到这个Request的SOAP包进行解析，然后对事物进行处理，处理结束以后再对这个计算结果进行SOAP包装，然后把这个包作为一个Response发送给客户端的代理类(Proxy Class)，同样地，这个代理类也对这个SOAP包进行解析处理，继而进行后续操作。

这就是WebService的一个运行过程。
下面对.net Remoting进行概括的阐述：
.net Remoting 是在DCOM等基础上发展起来的一种技术，它的主要目的是实现跨平台、跨语言、穿透企业防火墙，这也是他的基本特点，与WebService有所不同的是，它支持HTTP以及TCP信道，而且它不仅能传输XML格式的SOAP包，也可以传输传统意义上的二进制流，这使得它变得效率更高也更加灵活。而且它不依赖于IIS，用户可以自己开发(Development)并部署(Dispose)自己喜欢的宿主服务器，所以从这些方面上来讲WebService其实上是.net Remoting的一种特例。
Remoting的两种通道
　　Remoting的通道主要有两种：Tcp和Http。在.Net中，System.Runtime.Remoting.Channel中定义了 IChannel接口。IChannel接口包括了TcpChannel通道类型和Http通道类型。它们分别对应Remoting通道的这两种类型

1. remoting 是MarshByReference的，可以传变量的引用，直接对服务器对象操作。速度快，适合intranet（企业内部互联网）。
webservice 是MarshByValue的，必须传对象的值。速度慢，可以过FIREWALL,配置比较简单，适合internet（因特网）。
2. 一般来说，remoting是和平台相关的，需要客户和服务器都是.NET，但可配置特性比较好，可以自定义协议。web service可以做到跨平台通信，但必须采用SOAP协议。

3. Soap消息有rpc和文档两种样式。文档样式的body元素中包含一个或多个元素，可以是任何内容，只要接受者理解就行了。rpc样式的的body元素中包含调用的方法或远程过程的名称，以及代表方法参数的元素。

.net对这两种样式的实现就是web service 和remoting .
概括的说Remoting与Web Services的区别是：
（1）既支持TCP信道又支持HTTP信道，传输速度快
（2）即可传输XML的SOAP包又可传输二进制流，效率高
（3）Remoteing主要用于C/S结构项目
（4）不一定要依赖IIS服务器

qizhanfeng

关注

0
点赞
踩
0

收藏

觉得还不错? 一键收藏
0
评论
remoting socket webservice

&lt;wbr&gt;&lt;/wbr&gt;1：socket VS remoting&lt;wbr&gt;&lt;wbr&gt;&lt;wbr&gt;使用socket无疑是效率最高的。但是，在复杂的接口环境下，socket的开发效率也是最低的。故在兼顾开发效率的情况下，可以使用remoting来代替socket开发。并且：&lt;br style="pADDinG-BoTT...
复制链接

扫一扫