其实现的原理并没有本质的区别，在应用开发层面上有以下区别： 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的优缺点？ 优点： 1、能让我们进行分布式开发 2、Tcp通道的Remoting速度非常快 3、虽然是远程的，但是非常接近于本地调用对象 4、可以做到保持对象的状态 5、没有应用程序限制，可以是控制台，winform，iis，windows服务承载远程对象 缺点： 1、非标准的应用因此有平台限制 2、脱离iis的话需要有自己的安全机制 二、Remoting和Web服务的区别？     ASP.NET Web 服务基础结构通过将 SOAP 消息映射到方法调用，为 Web 服务提供了简单的 API。通过提供一种非常简单的编程模型（基于将 SOAP 消息交换映射到方法调用），它实现了此机制。ASP.NET Web 服务的客户端不需要了解用于创建它们的平台、对象模型或编程语言。而服务也不需要了解向它们发送消息的客户端。唯一的要求是：双方都要认可正在创建和使用的 SOAP 消息的格式，该格式是由使用 WSDL 和 XML 架构 (XSD) 表示的 Web 服务合约定义来定义的。      . NET Remoting 为分布式对象提供了一个基础结构。它使用既灵活又可扩展的管线向远程进程提供 .NET 的完全对象语义。ASP.NET Web 服务基于消息传递提供非常简单的编程模型，而 .NET Remoting 提供较为复杂的功能，包括支持通过值或引用传递对象、回调，以及多对象激活和生命周期管理策略等。要使用 .NET Remoting，客户端需要了解所有这些详细信息，简而言之，需要使用 .NET 建立客户端。.NET Remoting 管线还支持 SOAP 消息，但必须注意这并没有改变其对客户端的要求。如果 Remoting 端点提供 .NET 专用的对象语义，不管是否通过 SOAP，客户端必须理解它们。 三、最简单的Remoting的例子 1、远程对象： 建立类库项目：RemoteObject

using  System; namespace  RemoteObject {      public   class  MyObject:MarshalByRefObject     {          public   int  Add( int  a, int  b)         {              return  a + b;         }     } }

 

2、服务端 建立控制台项目：RemoteServer

 

using  System; using  System.Runtime.Remoting; namespace  RemoteServer {      class  MyServer     {         [STAThread]          static   void  Main( string [] args)         {             RemotingConfiguration.Configure( " RemoteServer.exe.config " );             Console.ReadLine();         }     } }

建立配置文件：app.config

< configuration >      < system .runtime.remoting >          < application  name ="RemoteServer" >              < service >                  < wellknown  type ="RemoteObject.MyObject,RemoteObject"  objectUri ="RemoteObject.MyObject"                     mode ="Singleton"   />              </ service >              < channels >                  < channel  ref ="tcp"  port ="9999" />              </ channels >          </ application >      </ system.runtime.remoting > </ configuration >

3、客户端： 建立控制台项目：RemoteClient

using  System; namespace  RemoteClient {      class  MyClient     {         [STAThread]          static   void  Main( string [] args)         {             RemoteObject.MyObject app  =  (RemoteObject.MyObject)Activator.GetObject( typeof (RemoteObject.MyObject),System.Configuration.ConfigurationSettings.AppSettings[ " ServiceURL " ]);             Console.WriteLine(app.Add( 1 , 2 ));             Console.ReadLine();         }     } }

建立配置文件：app.config

< configuration >   < appSettings >   < add  key ="ServiceURL"  value ="tcp://localhost:9999/RemoteObject.MyObject" />   </ appSettings > </ configuration >

4、测试 在最后编译的时候会发现编译报错： 1、找不到app.Add() 2、找不到RemoteObject 这是因为客户端RemoteClient没有添加RemoteObject的引用，编译器并不知道远程对象存在哪些成员所以报错，添加引用以后vs.net会在客户端也保存一个dll，可能大家会问这样如果对远程对象的修改是不是会很麻烦？其实不麻烦，对项目编译一次vs.net会重新复制dll。 然后直接运行客户端会出现“目标主机拒绝”的异常，也说明了通道没有打开 运行服务端再运行客户端出现“找不到程序集RemoteObject”！回头想想可以发现我们并在服务端对RemoteObject添加引用，编译的时候通过是因为这个时候并没有用到远程对象，大家可能不理解运行服务端的时候也通过？这是因为没有这个时候还没有激活远程对象。理所当然，对服务端要添加引用远程对象，毕竟我们的对象是要靠远程承载的。 现在再先后运行服务端程序和客户端程序，客户端程序显示3，测试成功。四、结束语我们通过一个简单的例子实现了最简单的remoting，对其实质没有做任何介绍，我想通过例子入门才是最简单的。

==============

MSMQ,Enterprise Service, DotNet Remoting,Web Service

 的优缺点

对于送耦合的引用，有一下四种选项。 1.MSMQ 从windows nt 开始微软就开始提供msmq 的支持，一直到现在的3.0，主要提供一下几个特性的支持。 可靠的消息传递，类似mail 系统，有脱机支持 可设置消息的优先级，Label的各种额外的标示 事务支持 通过DC,IC的灵活应用，有好的缩放性 对于客户端，要求必须是windows 系统，从windowsce 到windows .net 2003 都作支持。可以通过连接器跟其他的非微软技术集成.NET 有一个专门的封装 System.Messaing Namespace. 2.Enterprise Service .NET 中其实通过托管的Enterprise Service 跟 COM+ 应用架构交互。 从windows 2000 开始有这个组件，目前到windows 2003 版本是1.1 我认为有几个特性值得一用 对象池，对于对象构造特别慢，而又没有状态的应用特别适合。很类似我们 ADO.NET 中的连接吃。可以跟JIT去结合。 分布式事务协调，加上事务补偿。这是一大优点 另外一点就是送耦合事件，这一点对于plug and play 的订阅式应用很有帮助。 当然直接的客户端也必须是 windows 2000 以及以上的OS 3.DotNet Remoting 这个我用的最多，感觉也最深；） dotnet remoing 的中文翻译时远程处理，其实是一种.NET 平台下面很好的一种远程处理调用，提供了开发的架构。灵活的通讯传输协议，当然也可以自己去扩展。远程对象的调用提供了多种方式，可以使有状态的，也可以使无状态。对于开发人员，感觉根本地调用一样方便。这一点主要却别于Web Service。 其实这种应用类似一个相对耦合的应用。客户端和服务端丰富的通讯模型是基于.NET 平台。也就是说如果客户端不一定是.NET 平台的话，remoting 就显得不是很适合。一个简单的例子就是对象的传递 从remoting 服务端传递一个对象给客户端，可以是对象的远程的一个远程引用，也可以使一个对象的copy，就是我们通常说的mbr 或者mbv 当然，web 服务是无法实现对象的引用传递，web 服务只能是一个mbv，而web 服务这里的mbv 作的就不够彻底了。我在http://dotnet.mblogger.cn/montaque/posts/2094.aspx 提到他们走的不同的序列化方式。对于web 服务，只是一个很浅的copy。也就是说对象在传递到服务端的时候，并没有把 100% 的状态传递过去。 而remoting 传递的对象就比较地道。或许这就是一个.NET Remoting 相对于web 服务比较更贴近本地调用的一个体现 缺点前面提到了，就是丰富的特性是基于。NET 这个平台。.NET 中通过 System.Runtime.Remoting.Dll 4. web 服务。 这是个标准的东西，我的意见是标准的东西不见的都是最好的。在保证标准的同时，丢失了很多特性。

转载于:https://www.cnblogs.com/goodyao/archive/2008/09/17/1292517.html

相关资源：数据结构—成绩单生成器