浅谈.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包括如下几点主要元素： 

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

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

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

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

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

为序列化消息， .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表示形式将消息序列化为流。 

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

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

　　　　　　　　　　　　　　消息在信道上的传递过程 

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

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

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

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

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

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

ClassLibrary代码如下：

using System;

namespace ClassLibrary1
{
    public class Class1:MarshalByRefObject
    {
         public Class1()
            : base()
        {
            Console.WriteLine("远程对象被创建！");
        }

         ~Class1()
        {
            Console.WriteLine("远程对象被析构！");
        }

        public void SayHello(string name)
        {
            Console.WriteLine("你好，{0}",name);
        }

        public int GetSomthing(string s)
        {
            if (s!=null)
            { 
                Console.WriteLine("我执行了！");
                return s.Length;
            }
            return -1;           
        }

    }
}

相关说明如下：

1.远程对象的创建

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

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

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

Server的代码如下：

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

namespace Server
{
    class Program
    {
        /// <summary>
        /// 服务端应用
        /// </summary>
        /// <param name="args"></param>
        static void Main(string[] args)
        {
            //利用TCP通道，并侦听12345端口
            TcpserverChannel channel = new TcpserverChannel(12345);
            ChannelServices.RegisterChannel(channel,true);
            //使用WellKNown激活方式，并且使用SingleCall模式
            RemotingConfiguration.RegisterWellKNownServiceType(typeof(Class1),"Class1",WellKNownObjectMode.SingleCall);
            Console.Read();
        }
    }
}

 相关说明如下：

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的代码如下：

using System;
using System.Collections.Generic;
using System.Linq;
using System.Text;
using System.Runtime.Remoting.Channels.Tcp;
using System.Runtime.Remoting.Channels;
using ClassLibrary1;

namespace Client
{
    class Program
    {
        static void Main(string[] args)
        {
            try
            {
                //使用TCP通道连接
                TcpClientChannel channel = new TcpClientChannel();
                ChannelServices.RegisterChannel(channel,true);
                //获取远程对象
                Class1 class1 = (Class1)Activator.Getobject(typeof(Class1),"tcp://localhost:12345/Class1");
                //调用远程对象的方法
                class1.SayHello("DebugLZQ");
                class1.SayHello("http://www.cnblogs.com/DebugLZQ");

                int i=class1.GetSomthing("DebugLZQ");
                Console.WriteLine("输入的长度是，{0}",i);
            }
            catch (Exception ex)
            {
                Console.WriteLine(ex.Message );
            }
            Console.Read();
        }
    }
}

程序的运行结果如下：
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的一个特例。

结束语

无论是Web Service还是Microsoft.Net Remoting都可以说是博大精深。整个Web Service和Remoting的内容不是我这一篇小文所能尽述的，正如问题所示“浅谈”，欢迎批评指正！

传统上，我们把计算机后台程序（Daemon）提供的功能，称为"服务"（service）。比如，让一个杀毒软件在后台运行，它会自动监控系统，那么这种自动监控就是一个"服务"。

通俗地说，"服务"就是计算机可以提供的某一种功能。

  根据来源的不同，"服务"又可以分成两种：一种是"本地服务"（使用同一台机器提供的服务，不需要网络），另一种是"网络服务"（使用另一台计算机提供的服务，必须通过

网络才能完成）。"网络服务"（Web Service）的本质，就是通过网络调用其他网站的资源。举例来说，去年我写过一个"四川大地震图片墙"，它能动态显示关于四川地震的最新

图片。但是，所有的图片都不是储存在我的服务器上，而是来自flickr.com。我只是发出一个动态请求，要求flickr.com向我提供图片。这种情况下，flickr.com提供的就是一种

Web service。如果我把图片都存放在本地服务器，不调用flickr.com，那么我就是在

使用"本地服务"。所以，Web service让你的网站可以使用其他网站的资源，比如在网页上显示天气、地图、twitter上的最新动态等等。

综上：WebService是两个计算机之间通讯（交谈）的技术。并且现在炒的很火的SOA、云计算在技术层面上都是WebService。

除了WebService 通讯外,系统间通讯有很多种技术，如像qq的这种Socket通讯在银行系统中广泛应用，.Net Remoting、DCom等通讯方式也应用很 多，

但是这些方式有如下缺点：

•        通讯数据格式不统一，同样一个"你好"这样的字符串在不同的协议中有不同的表示方法，异构系统集成很麻烦。一个系统一个模样。

•        采用Socket、 .Net Remoting、DCom需要打开很多端口，而企业网络安全的一个基本原则就是“尽可能少的打开端口”，很多企业网络甚至严格规定“只能打开80端口”，

因此需要一种“跨防火墙”的技术（跨防火墙就是走80端口进行通讯）

•        这些通讯方式的协议是不开放的，要想知道服务提供了哪些方法、如何调用，必须能够自描述

WSDL（Web Service Description Language）

你会怎样向别人介绍你的Web service有什么功能，以及每个函数调用时的参数呢？你可能会自己写一套文档，你甚至可能会口头上告诉需要使用你的Web service的人。

这些非正式的方法至少都有一个严重的问题：当程序员坐到电脑前，想要使用你的Web service的时候，他们的工具(如Visual Studio)无法给他们提供任何帮助，因为这些工具根本就不了解你的Web service。解决方法是：用机器能阅读的方式提供一个正式的描述文档。Web service描述语言(WSDL)就是这样一个基于XML的语言，用于描述Web service及其函数、参数和返回值。因为是基于XML的，所以WSDL既是机器可阅读的，又是人可阅读的，这将是一个很大的好处。一些最新的开发工具既能根据你的Web service生成WSDL文档，又能导入WSDL文档，生成调用相应Web service的代码

Web服务器描述语言是用XML文档来描述Web服务的标准，是Web服务的接口定义语言，由Ariba、Intel、IBM、MS等共同提出，通过WSDL，可描述Web服务的三个基本属性：

·服务做些什么——服务所提供的操作（方法）

·如何访问服务——和服务交互的数据格式以及必要协议

·服务位于何处——协议相关的地址，如URL

XML和XSD
可扩展的标记语言(XML)是Web service平台中表示数据的基本格式。除了易于建立和易于分析外，XML主要的优点在于它既是平台无关的，又是厂商无关的。无关性是比技术优越性更重要的：软件厂商是不会选择一个由竞争对手所发明的技术的。
XML解决了数据表示的问题，但它没有定义一套标准的数据类型，更没有说怎么去扩展这套数据类型。例如，整形数到底代表什么？16位，32位，还是64位？这些细节对实现互操作性都是很重要的。W3C制定的XML Schema(XSD)就是专门解决这个问题的一套标准。它定义了一套标准的数据类型，并给出了一种语言来扩展这套数据类型。Web service平台就是用XSD来作为其数据类型系统的。当你用某种语言(如VB.NET或C#)来构造一个Web service时，为了符合Web service标准，所有你使用的数据类型都必须被转换为XSD类型。你用的工具可能已经自动帮你完成了这个转换，但你很可能会根据你的需要修改一下转换过程。在第二章中，我们将深入XSD，学习怎样转换自定义的数据类型(例如类)到XSD的类型。

SOAP
Web service建好以后，你或者其他人就会去调用它。简单对象访问协议(SOAP)提供了标准的RPC方法来调用Web service。实际上，SOAP在这里有点用词不当：它意味着下面的Web service是以对象的方式表示的，但事实并不一定如此：你完全可以把你的Web service写成一系列的C函数，并仍然使用SOAP进行调用。SOAP规范定义了SOAP消息的格式，以及怎样通过HTTP协议来使用SOAP。SOAP也是基于XML和XSD的，XML是SOAP的数据编码方式。第三章我们会讨论SOAP，并结识SOAP消息的各种元素。

综上我们还可以得出以下结论：

请求、返回的XML数据格式（有哪些节点、节点的名字等等）WebService 用SOAP协议进行规定，方法描述信息XML用WSDL协议规定。WebService技术是与语言、平台无关，因此.net可以访问java编写的WebService、java也可以访问.net编写的webservice，PHP、python等各种语言也几乎都支持webservice，因此可以说webservice可以实现跨语言方法调用。

但是如果自己构建请求、返回xml，解析xml请求，自己负责方法描述信息更新是很麻烦的，.net就提供了简化开发WebService。

WebService的创建和使用

下面以两个数的大小比较为例来说明在服务器端的创建和在客户端的调用方法：

1、  服务器端（ServerWeb）：就想写普通方法一样，不需要处理请求、响应。服务器端新建“Web服务”（asmx），在远端可以调用的方法上标注[WebMethod]。

Webadd.cs               

  新建的web服务

2、客户端添加对asmx的“服务器引用”，然后就可以调用***SoapClient类中的方法。就“好像”直接调用了服务端的方法。

添加服务引用的时候工具读取asmx的WSDL自动生成了ServiceReference1中的类，这些类帮我们来拼Http请求，并且把Http返回值拆成函数的返回。

客户端“添加服务引用”，填写asmx的地址。然后就可以调用Service References下自动生成的***SoapClient类了。

用WebService的时候如果服务端的接口定义发生变化，则需要重新添加对服务端的引用，因为Service References中的类是工具读取WSDL定义自动生成的。在服务引用上点击右键，选择“更新服务引用”。如果只是修改了WebService内部实现，而接口没变，则不需要“更新服务引用”，因为WSDL没变，Soap没变。

.Net remoting

Net remoting 是简化网络通讯的技术，底层仍然是TCP等东西。

remoting要添加对System.Runtime.Remoting的引用

编写服务接口类库项目，正常写法！WebService中WSDL相当于对服务端方法的描述；.net Remoting中走的是二进制数据，因此必须一个描述服务端方法的接口类库。

服务端实现服务接口，继承自MarshalByRefObject，然后运行备注中的代码注册服务。

客户端代码在备注中

Remoting和WebService的区别：Remoting效率高，走的是普通TCP， WebService则是Http协议，需要IIS、ASP.Net、XML解析等，效率低。Remoting适合于内网通讯， WebService适合于外网通讯。

除非项目要求，否则以后尽量用WCF。.Net Remoting是微软私有协议，因此如果要跨平台调用还是普通Socket或者WebService。

用法说明:

1、新建接口项目，定义服务接口。

注意：remoting要添加对System.Runtime.Remoting的引用

2、新建服务器端项目（控制台的，或者WinForm，或者Windows服务等）

定义实现服务接口的类，还要继承继承自MarshalByRefObject类

服务器启动时调用

            //注册通道，通过TCP的9999端口对外提供服务

            TcpChannel tcpChannel = new TcpChannel(9999);

            ChannelServices.RegisterChannel(tcpChannel);

            //注册服务：第一个参数为服务的实现类，第二个参数为服务的名字。

            RemotingConfiguration.RegisterWellKNownServiceType(typeof(TestServiceImpl),

                "test",WellKNownObjectMode.Singleton);

注册服务。如果控制台程序，控制不要让程序退出，

            //主要目的是不要让服务器退出

            while (true)

            {

                string s = Console.ReadLine();

                if (s == "quit")

                {

                    return;

                }

            }

3、客户端：新建客户端项目，引用服务接口

            TcpChannel tcpChannel = new TcpChannel();

            ChannelServices.RegisterChannel(tcpChannel,false);

            ITestService test =

                (ITestService)Activator.Getobject(typeof(ITestService),"tcp://127.0.0.1:9999/test");//第一个参数为服务实现的接口，第二个参数为服务的地址：最后一部分是服务在服务器端RegisterWellKNownServiceType时第二个参数的名字

然后就可以调用服务端方法了。

接口项目

ItestService.cs

客户端项目

服务器端项目

                                                                                     WCF

WCF（Windows Communication foundation）是微软的统一网络通讯开发的技术，无论底层用.Net Remoting还是WebService还是Restful还是MSMQ等，只要修改配置文件即可。所以WCF并不是新技术。

WCF和.Net Remoting、WebService等技术的关系就像ADO.Net和sqlServer、Oracle驱动的关系一样。通过VS的“WCF服务配置编辑器”简化配置，修改不同的协议。

一开始内网运行就行，后来想运行到公网，那么如果一开始用.net remoting写后来改成WebService还是有工作量的，因为写法不一样，但是用WCF就不一样了。

新建“WCF服务库”，WCF服务库可以Host在IIS上、单独的WinForm程序等。

WCF、.Net Remoting和WebService的关系： .Net Remoting是普通的TCP通讯，适合于局域网，效率高； WebService是基于Http协议，适合于广域网，效率低；WCF是对.Net Remoting、 WebService等的简化、统一，可以通过配置来切换不同的底层实现，代码几乎不用动。

总结：

WCF 支持多种通信协议 Http/Https 、TCP/UDP、MSMQ、命名管道、对等网、

　　消息可达性、事务流等。

WCF 可以与ASP.NET 集成、共享一个上下文（HttpContext）。

WCF 支持多种消息传输格式 :text,binary,mtom,Json 等。

WCF 安全性要强：支持对称安全、非对称安全、消息安全、传输安全、

　　SSL 流安全、Windows 流安全等。

WCF 支持多种会话模式：单向、双向、请求/响应。

WCF 支持REST 。

WCF 支持多种格式化方式。DataContractSerializer、XmlSerializer、　

　  DataContractJsonSerializer 等。

WCF 支持 WAS hosting、Windows 服务 hosting、Self-Hosting、IIS hosting 等。

WCF 支持多种并发模式：单例、单调、会话 。

（1）WCF可以不依赖于IIS。

（2）WCF可以配置成BasicHttpBinding来兼容（或者说变身成）WS。

（3）WCF可以基于TCP或者MessegeQueue来传输数据。

（4）WCF的可配置性比WS强，比如安全性。

（5）WCF可以是有状态的，并支持事务。

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

     .net remoting与webservice都是用来通信的框架，它们最大的优点是可以像调用本地对象一样调用远程对象，比如：Uploader uploader = new Uploader();uploader.Save(file);可以用这样简洁而抽象的调用实现上传，不用自已对socket进行一系列的处理，可以把更多精力放在业务逻辑上；区别：1、webservice是用的应用层协议http封装的，所以它可以被很多其它语言调用，很多语言也都实现了webservice代理端封装以及工具，只要知道webservice的地址(比如：http://www.baidu.com/SomeService.asmx)，就可以用，所以webservice的点特是好用、通用、效率一般；.net remoting是用传输层协议tcp封装的，所以可以以二进制传输数据，效率高；.net remoting基于.net的反射机制，只方便.net使用（其它语言反射机制实现不同，有的根本没有反射）； 2、webservice能穿越防火墙，是因为http协议是现在广泛应用的协议，防火墙一般不会作屏蔽，并不说webservice有某功能穿越防火墙； 3、 只能在winform下用吗？如果你是用.net开发，任何类型的应用程序都可以使用.net remoting与webservice，包括winform，asp.net,wpf,silverlight...，只要能using ...就可以按它们的方式用了1）.net Remoting的工作原理是什么？

答案：服务器端向客户端发送一个进程编号，一个程序域编号，以确定对象的位置。

2)  使用ASMX的XML Web服务与使用SOAP的.NET Remoting的区别?

答案：Web服务使用的消息机制，而Remoting采用的RPC. Web Service能用于不同平台，不同语言，Remoting只适用于.Net。效率上Remoting高于Xml Web Service

3）简要谈一下您对微软.NET 构架下remoting和webservice两项技术的理解以及实际中的应用。

答案：WS主要是可利用HTTP，穿透防火墙。而Remoting可以利用TCP/IP，二进制传送提高效率。

4）.概述.NET里对 remoting 和 webservice 两项技术的理解和实际中的应用。

答案：远程逻辑调用，remoing接口只能用在.net

remoting是.net 中用来跨越machine,process,appdomain 进行方法调用的技术,对于三成结构的程序，就可以使用remoting技术来构建．它是分布应用的基础技术.相当于以前的DCOM

 Web Service是一种构建应用程序的普通模型，并能在所有支持internet网通讯的操作系统上实施。Web Service令基于组件的开发和web的结合达到最佳，基于组件的对象模型。