浅谈.net remoting 与 webservice

1. .NET Remoting

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

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

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

　　　　　　　　　　　　　　　　.NET Remoting协同工作能力 

 下图是.NET Remoting的体系结构图 

　　　　　　　　　　　　　　　　.NET Remoting通信体系结构 

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

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

（2）信道：信道是服务器和客户机进行通信用的（这里的服务器和客户机并不一定都是计算机，也可能是进程）。在.NET Remoting中，提供了三种信道类型：TCP、HTTP、IPC，另外，也可以定制不同的信道以适应不同的通信协议。 

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

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

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

　　为序列化消息， .NET Remoting 提供了两类格式程序接收器： BinaryFormatter和SoapFormatter。选择的类型很大程度上取决于连接分布式对象的网络环境的类型。由于. NET  Remoting体系结构的可插入特性，可以创建自己的格式程序接收器，并插入到.NET Remoting基础设施中。这种灵活性使基础设施能够支持可能的各种线路格式。 

　　对于可以发送并接收二进制数据（例如TCP/IP）的网络传输协议，可以使用System.Runtime.Serialization.Formatters.Binary名字空间中定义的BinaryFormatter类型。顾名思义，BinaryFormatter将消息对象序列化为一个二进制格式的流。这是消息对象在线缆间进行传输的最有效而简洁的表示方式。一些网络传输系统不允许发送和接收二进制数据。这类传输迫使应用程序在发送之前将所有的二进制数据转换成ASCII文本表示形式。在这种情况下（或者要得到最佳协作能力的时候），.NET Remoting在System.Runtime.Serialization.Formatters.Soap名字空间中提供SoapFormatter类型。SoapFormatter使用消息的SOAP表示形式将消息序列化为流。 

（6）代理对象：前面也说过，客户端不能直接调用远程对象，客户机只能通过代理对象来操作远程对象。代理对象，又分为透明代理和真实代理。在客户机看来，代理对象和远程对象是一样的。客户机调用透明代理对象上的方法，透明代理再调用真实代理上的Invoke方法，Invoke方法再使用消息接受器把消息传递到信道上。 

下图是客户机的方法调用导致消息在信道间传递的一个体系结构图： 

　　　　　　　　　　　　　　消息在信道上的传递过程 

（6）消息接受器：如上图所示，消息接受器在服务器端和客户端都有，接受真实代理的调用，把序列化的消息发布到信道上。 

（7） 激活器：这涉及到对象生命期管理，客户机使用激活器在服务器上创建远程对象，或者说是申请一个远程对象的引用。 

（8）RemotingConfiguration类：该类用于配置远程服务器和客户机的一个实用类，它可以用于读取配置文件或者动态地配置远程对象。说明一点的是：RemotingConfiguration类中的大部分属性、方法都是静态的，这就意味着很多属性，如应用程序名称，只能通过当前属性或配置文件设置一次。如果应用程序运行在宿主环境中，例如 Internet 信息服务 (IIS)，则可能已经设置了该值（通常将其设置为虚拟目录）。如果未设置应用程序名称，则当前属性将返回空引用。 

（9） ChannelServices类：该类用于注册信道，并把消息分派到信道上。 

 

下面写一个.NET Remoting 的示例程序，示例工程的结构如下：

 其中，ClassLibrary是远程对象的类库，Client、Server是控制台程序。

ClassLibrary代码如下：

 1 using System;
 2 
 3 namespace ClassLibrary1
 4 {
 5     public class Class1:MarshalByRefObject
 6     {
 7          public Class1()
 8             : base()
 9         {
10             Console.WriteLine("远程对象被创建！");
11         }
12 
13          ~Class1()
14         {
15             Console.WriteLine("远程对象被析构！");
16         }
17 
18         public void SayHello(string name)
19         {
20             Console.WriteLine("你好，{0}", name);
21         }
22 
23         public int GetSomthing(string s)
24         {
25             if (s!=null)
26             { 
27                 Console.WriteLine("我执行了！");
28                 return s.Length;
29             }
30             return -1;           
31         }
32 
33     }
34 }

相关说明如下：

1.远程对象的创建

　　客户端在获取服务器端对象时，并不是获得实际的服务端对象，而是获得它的引用。因此在Remoting中，对于远程对象有一些必须的定义规范要遵循。

　　由于Remoting传递的对象是以引用的方式，因此所传递的远程对象类必须继承MarshalByRefObject。MSDN对MarshalByRefObject的说明是：MarshalByRefObject 是那些通过使用代理交换消息来跨越应用程序域边界进行通信的对象的基类。不是从 MarshalByRefObject 继承的对象会以隐式方式按值封送。当远程应用程序引用一个按值封送的对象时，将跨越远程处理边界传递该对象的副本。因为您希望使用代理方法而不是副本方法进行通信，因此需要继承MarshallByRefObject。

　　需要注意的是Class1继承自MarshalByRefObject类，即声明为远程对象。关于MarshalByRefObject具体请参考MSDN。

 

Server的代码如下：

 

 1 using System;
 2 using System.Runtime.Remoting.Channels.Tcp;
 3 using System.Runtime.Remoting.Channels;
 4 using System.Runtime.Remoting;
 5 using ClassLibrary1;
 6 
 7 namespace Server
 8 {
 9     class Program
10     {
11         /// <summary>
12         /// 服务端应用
13         /// </summary>
14         /// <param name="args"></param>
15         static void Main(string[] args)
16         {
17             //利用TCP通道，并侦听12345端口
18             TcpServerChannel channel = new TcpServerChannel(12345);
19             ChannelServices.RegisterChannel(channel, true);
20             //使用WellKnown激活方式，并且使用SingleCall模式
21             RemotingConfiguration.RegisterWellKnownServiceType(typeof(Class1), "Class1", WellKnownObjectMode.SingleCall);
22             Console.Read();
23         }
24     }
25 }

相关说明如下：

1、Remoting的两种通道

　　Remoting的通道主要有三种：Tcp和Http和IPC。在.Net中，System.Runtime.Remoting.Channel中定义了IChannel接口。IChannel接口包括了TcpChannel通道类型和Http通道类型。它们分别对应Remoting通道的前两种类型。

　　TcpChannel类型放在名字空间System.Runtime.Remoting.Channel.Tcp中。Tcp通道提供了基于Socket的传输工具，使用Tcp协议来跨越Remoting边界传输序列化的消息流。TcpChannel类型默认使用二进制格式序列化消息对象，因此它具有更高的传输性能。HttpChannel类型放在名字空间　　　　System.Runtime.Remoting.Channel.Http中。它提供了一种使用Http协议，使其能在Internet上穿越防火墙传输序列化消息流。默认情况下，　　HttpChannel类型使用Soap格式序列化消息对象，因此它具有更好的互操作性。IPC不需要通道，适合本机使用，速度可想而知，比Tcp和Http都要快。

　　通常在局域网内，我们更多地使用TcpChannel；如果要穿越防火墙，则使用HttpChannel。服务端和客户端在同一台主机上，优先考虑IPC。

2、远程对象的激活方式

　　在访问远程类型的一个对象实例之前，必须通过一个名为Activation的进程创建它并进行初始化。这种客户端通过通道来创建远程对象，称为对象的激活。在Remoting中，远程对象的激活分为两大类：服务器端激活和客户端激活。

　　(1)服务器端激活，又叫做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状态。

　　(2)客户端激活。与WellKnown模式不同，Remoting在激活每个对象实例的时候，会给每个客户端激活的类型指派一个URI。客户端激活模式一旦获得客户端的请求，将为每一个客户端都建立一个实例引用。SingleCall模式和客户端激活模式是有区别的：首先，对象实例创建的时间不一样。客户端激活方式是客户一旦发出调用的请求，就实例化；而SingleCall则是要等到调用对象方法时再创建。其次，SingleCall模式激活的对象是无状态的，对象生命期的管理是由GC管理的，而客户端激活的对象则有状态，其生命周期可自定义。其三，两种激活模式在服务器端和客户端实现的方法不一样。尤其是在客户端，SingleCall模式是由GetObject()来激活，它调用对象默认的构造函数。而客户端激活模式，则通过CreateInstance()来激活，它可以传递参数，所以可以调用自定义的构造函数来创建实例。

 Client的代码如下：

 1 using System;
 2 using System.Collections.Generic;
 3 using System.Linq;
 4 using System.Text;
 5 using System.Runtime.Remoting.Channels.Tcp;
 6 using System.Runtime.Remoting.Channels;
 7 using ClassLibrary1;
 8 
 9 namespace Client
10 {
11     class Program
12     {
13         static void Main(string[] args)
14         {
15             try
16             {
17                 //使用TCP通道连接
18                 TcpClientChannel channel = new TcpClientChannel();
19                 ChannelServices.RegisterChannel(channel, true);
20                 //获取远程对象
21                 Class1 class1 = (Class1)Activator.GetObject(typeof(Class1), "tcp://localhost:12345/Class1");
22                 //调用远程对象的方法
23                 class1.SayHello("DebugLZQ");
24                 class1.SayHello("http://www.cnblogs.com/DebugLZQ");
25 
26                 int i=class1.GetSomthing("DebugLZQ");
27                 Console.WriteLine("输入的长度是，{0}", i);
28             }
29             catch (Exception ex)
30             {
31                 Console.WriteLine(ex.Message );
32             }
33             Console.Read();
34         }
35     }
36 }

程序的运行结果如下：

Server端运行结果

Client端运行结果：

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

　　2.Web Service

 Web Service也叫XML Web Service。 Web Service是一种可以接收从Internet或者Intranet上的其它系统中传递过来的请求，轻量级的独立的通讯技术。是通过SOAP在Web上提供的软件服务，使用WSDL文件进行说明，并通过UDDI进行注册。

　　 XML：(Extensible Markup Language)扩展型可标记语言。面向短期的临时数据处理、面向万维网络，是Soap的基础。

　　 Soap：(Simple Object Access Protocol)简单对象存取协议。是XML Web Service 的通信协议。当用户通过UDDI找到你的WSDL描述文档后，他通过可以SOAP调用你建立的Web服务中的一个或多个操作。SOAP是XML文档形式的调用方法的规范，它可以支持不同的底层接口，像HTTP(S)或者SMTP。

　　 WSDL：(Web Services Description Language) WSDL 文件是一个 XML 文档，用于说明一组 SOAP 消息以及如何交换这些消息。大多数情况下由软件自动生成和使用。

　　 UDDI (Universal Description, Discovery, and Integration) 是一个主要针对Web服务供应商和使用者的新项目。在用户能够调用Web服务之前，必须确定这个服务内包含哪些商务方法，找到被调用的接口定义，还要在服务端来编制软件，UDDI是一种根据描述文档来引导系统查找相应服务的机制。UDDI利用SOAP消息机制（标准的XML/HTTP）来发布，编辑，浏览以及查找注册信息。它采用XML格式来封装各种不同类型的数据，并且发送到注册中心或者由注册中心来返回需要的数据。

　　Web Service的主要目标是跨平台的可互操作性。为了实现这一目标，Web Service 完全基于XML（可扩展标记语言）、XSD（XML Schema）等独立于平台、独立于软件供应商的标准，是创建可互操作的、分布式应用程序的新平台。因此使用Web Service有许多优点:

　　1、跨防火墙的通信

　　如果应用程序有成千上万的用户，而且分布在世界各地，那么客户端和服务器之间的通信将是一个棘手的问题。因为客户端和服务器之间通常会有防火墙或者代理服务器。传统的做法是，选择用浏览器作为客户端，写下一大堆ASP页面，把应用程序的中间层暴露给最终用户。这样做的结果是开发难度大，程序很难维护。 要是客户端代码不再如此依赖于HTML表单，客户端的编程就简单多了。如果中间层组件换成Web Service的话，就可以从用户界面直接调用中间层组件，从而省掉建立ASP页面的那一步。要调用Web Service，可以直接使用Microsoft SOAP Toolkit或.net这样的SOAP客户端，也可以使用自己开发的SOAP客户端，然后把它和应用程序连接起来。不仅缩短了开发周期，还减少了代码复杂度，并能够增强应用程序的可维护性。同时，应用程序也不再需要在每次调用中间层组件时，都跳转到相应的"结果页"。

　　2、应用程序集成

　　企业级的应用程序开发者都知道，企业里经常都要把用不同语言写成的、在不同平台上运行的各种程序集成起来，而这种集成将花费很大的开发力量。应用程序经常需要从运行的一台主机上的程序中获取数据；或者把数据发送到主机或其它平台应用程序中去。即使在同一个平台上，不同软件厂商生产的各种软件也常常需要集成起来。通过Web Service，应用程序可以用标准的方法把功能和数据"暴露"出来，供其它应用程序使用。

　　XML Web services 提供了在松耦合环境中使用标准协议（HTTP、XML、SOAP 和 WSDL）交换消息的能力。消息可以是结构化的、带类型的，也可以是松散定义的。

　　3、B2B的集成

　　B2B 指的是Business to Business，as in businesses doing business with other businesses,商家(泛指企业)对商家的电子商务，即企业与企业之间通过互联网进行产品、服务及信息的交换。通俗的说法是指进行电子商务交易的供需双方都是商家(或企业、公司)，她们使用了Internet的技术或各种商务网络平台，完成商务交易的过程。

　　Web Service是B2B集成成功的关键。通过Web Service，公司可以只需把关键的商务应用"暴露"给指定的供应商和客户，就可以了，Web Service运行在Internet上，在世界任何地方都可轻易实现，其运行成本就相对较低。Web Service只是B2B集成的一个关键部分，还需要许多其它的部分才能实现集成。 用Web Service来实现B2B集成的最大好处在于可以轻易实现互操作性。只要把商务逻辑"暴露"出来，成为Web Service，就可以让任何指定的合作伙伴调用这些商务逻辑，而不管他们的系统在什么平台上运行，使用什么开发语言。这样就大大减少了花在B2B集成上的时间和成本。

　　4、软件和数据重用

　　Web Service在允许重用代码的同时，可以重用代码背后的数据。使用Web Service，再也不必像以前那样，要先从第三方购买、安装软件组件，再从应用程序中调用这些组件；只需要直接调用远端的Web Service就可以了。另一种软件重用的情况是，把好几个应用程序的功能集成起来，通过Web Service "暴露"出来，就可以非常容易地把所有这些功能都集成到你的门户站点中，为用户提供一个统一的、友好的界面。 可以在应用程序中使用第三方的Web Service 提供的功能，也可以把自己的应用程序功能通过Web Service 提供给别人。两种情况下，都可以重用代码和代码背后的数据。

　　从以上论述可以看出，Web Service 在通过Web进行互操作或远程调用的时候是最有用的。不过，也有一些情况，Web Service根本不能带来任何好处，Web Service有以下缺点：

　　1、 单机应用程序

　　目前，企业和个人还使用着很多桌面应用程序。其中一些只需要与本机上的其它程序通信。在这种情况下，最好就不要用Web Service，只要用本地的API就可以了。COM非常适合于在这种情况下工作，因为它既小又快。运行在同一台服务器上的服务器软件也是这样。当然Web Service 也能用在这些场合，但那样不仅消耗太大，而且不会带来任何好处。

　　2、 局域网的一些应用程序

　　在许多应用中，所有的程序都是在Windows平台下使用COM，都运行在同一个局域网上。在这些程序里，使用DCOM会比SOAP/HTTP有效得多。与此相类似，如果一个.net程序要连接到局域网上的另一个.net程序，应该使用.net Remoting。其实在.net Remoting中，也可以指定使用SOAP/HTTP来进行Web Service 调用。不过最好还是直接通过TCP进行RPC调用，那样会有效得多。 

小结：从体系结构上来说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的一个运行过程。  

 

 3..NET Remoting与Web Service比较

1、.net remoting使用HttpChannel，可以和WebService一样使用Http协议的各种好处，比如传透防火墙。但WebService是一个跨平台的东东，Java和.Net可以互相提供和引用对方的WebService，.net remoting就限制于.net平台使用。

2、.net remoting是有状态的，是紧密耦合；web service是无状态的（因为http是无状态的），是松散耦合；总的来说remoting适合局域网内，对性能和响应效率要求较高的场合；而web service适合跨网络，跨系统，对移植性和通用性要求较高的场合；remoting和web service严格的说都不是和J2EE的EJB对应的技术，如果一定要比较，那么部署在COM+/MTS的.net remoting组件可以和EJB对应。

3、.net remoting在局域网上的表现绝对是大大强于web services，使用tcp管道不失真的传输数据，从而减轻了序列化和反序列化的工作，当然使用WEB服务的时候，一台计算机存储32位整数的方式与另一台计算机的存储方式是不同的，因此需要像XML这样易于理解的格式。web services 是IIS执行的，而.NET Remoting的扩展性强，使用HTTP信道和XML可以达到web services的技术的一部分，个人觉得可以把web service看成是.NET Remoting的一个特例。

 转自：http://www.cnblogs.com/DebugLZQ/archive/2012/07/30/2614815.html