XML Webservice实现原理及相关知识

好多书籍只介绍创建XML Webservice，并没有详细介绍XML WebService的工作原理以及各部分(例如IIS Asp.net)
在XML WebService中所起的作用.
学习后整理了一下,希望对读者有所帮助!

(一).XML WebService作用
  XML WebService在应用程序中所起的作用与.Net远程调用处理组件相同.
  用户不能直接使用WebService,只能通过Asp.net Web应用程序或Windows桌面
  客户端来调用.
(二).XML WebService与.Net远程处理区别
  1. XML WebService比.Net远程处理对象所受的限制更多。它类似于.Net远程处理
     的单独调用对象的工作机制。 不能创建一个单独的或是由客户端激活的对象.
  2.XML WebService的创建和设计比远程组件更容易/简单.
  3.Net远程处理二进制通信要比XML WebService SOAP格式通信要快捷.
  4.XML WebService较.Net远程处理扩展性强。 它支持以跨平台使用为目的的开放标准.
  5.XML WebService不需要专门的宿主程序，而是由Asp.net承载。 可以访问一些重要的
    平台服务，如：数据缓存/网络会话状态管理/身份验证/全局共享应用程序集合等。而.Net
    远程处理则很难实现这些功能.
  6.XML WebService运行在IIS和ASP.NET之上，使用http信道(80端口)与客户通信。
    可以自由跨越防火墙.
(三).XML WebService创建与调用过程
  I.服务端创建
     1.使用IIS，在Web服务器上新建一个虚拟目录来存放XML Web服务.
     2.建立XML WebService类，使用[WebMethod]属性来标记方法可以被远程调用.
     3.在虚拟目录中部署XML Web服务的文件.
  II.客户端使用
     1.客户端通过URL或文件查询或UDDI注册，发现XML WebService
     2.客户端请求描述XML WebService的WSDL文档。
     3.客户端在WSDL文档的基础上生成一个代理类。
     4.客户端生成代理类的实例，并调用XML Webservice，发送消息并接受处理后结果.
       也就是说调用XML WebService是由客户端生成的代理类实例对象完成的.
(四).IIS作用
  1.IIS通过虚拟目录提供对Web服务器进行访问。简单的说： 就是将"c:/MyWeb"映射
    一个URL地址形式的虚拟目录:"http://192.168.83.66/MyWeb",供本机或Internet
    上计算机访问Webservice.
  2.虚拟目录的权限与普通目录不同。根据默认设置，不允许远程用户浏览虚拟目录，运行
    可执行文件，新建文件和下载某些文件类型文件。可以根据需要自定义IIS虚拟目录权限设置.
  3.IIS对Internet进行公开处理. IIS并不负责运行Asp或Asp.net布面 或XML Webservice,而是
    维护一个注册的文件扩展名列表。如果IIS收到对某一种文件类型的请求，就把工作提交给
    Asp.net工作进程，由Asp.net工作进程处理剩下的工作.
(五).XML WebService和SOAP标准支持的数据类型
  不知道读者有没有遇到这种情况，在调用WebService并给一个方法传递了一个DataRow参数时，运行
  时会抛出异常： "没法将参数序列化！"，如果把DataRow加入到DataSet中，并将DataSet作为参数
  传递再运行就OK了。 这是因为：XML WebService只能对数据集DataSet对象类型进行XML序列化，
  不能对DataRow对象类型进行XML序列化造成的错误.  所以了解一下XML WebService支持序列化的基
  本数据类型是比较重要的.它支持的数据类型如下:
  1.基本数据类型. 
      标准类型，如：int float bool DateTime string等基本数据类型
  2.枚举.
      支持枚举Enum定义的类型
  3.自定义对象.
      可以传递任意基于自定义类或结构创建的对象。 但要注意一点： 它只能传输数据成员(变量和属性).
      如果定义了方法，则方法不能进行序列化传输,序列化后只剩下数据成员.
  4.DataSet对象
      支持DataSet,切记：不支持DataTable和DataRow,DataSet已经是XML Webservice能够支持的最小的可序列化对象.
  5.XmlNode对象
      基于XmlNode的对象可以表示XML文档的一部分.
  6.数组和集合
      可以使用任何被支持的类型的数组和简单集合，包括: DataSet对象/XmlNode对象和自定义对象.

 Remoting是一个分布式处理服务。服务器端首先创建通道（Channel），并自动开启监听通道。根据客户端发出的请求，传递远程对象。

因此，编写 Remoting程序，主要分为三部分：
1、被传递的远程对象；
2、服务器端监听程序；
3、客户端请求和处理对象程序；

 

一、Remoting的优缺点？

优点：

1、能让我们进行分布式开发

2、Tcp通道的Remoting速度非常快

3、虽然是远程的，但是非常接近于本地调用对象

4、可以做到保持对象的状态

5、没有应用程序限制，可以是控制台，winform，iis，windows服务承载远程对象

缺点：

1、非标准的应用因此有平台限制

2、脱离iis的话需要有自己的安全机制

 

 

二、Remoting和Web Service

 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的一种特例。

再次我们对WebService 以及Remoting做一个比较

WebService的特点是：平台独立性（Platform-independent）、跨语言（只要能支持XML的语言都可以）以及穿透企业防火墙

但是它的缺点也很明显，就是需要部署一台Web Server;而且速度比较慢；

.net Remoting的特点是

他的优点是用户既可以使用TCP信道方式进行二进制流方式通信，也可以使用HTTP信道进行SOAP格式的性通信

效率相对WebService要高不少；但是它的缺点也很明显，.net remoting只能应用于MS 的.net framework之下。

从性能上来讲Remoting的效率和传统的DCOM、COM+的性能很相近！

三、Remoting和Socket

socket与remoting根本就不是设计成一样的用途的，remoting主要用于跨越应用程序边界的对象传输，大部分功能相当于webservice

 

首先，.NET Remoting不过是建立在Socket上的高级应用。

其次Socket是用来传输数据的，而.NET Remoting是远程调用对象的，两个根本就不是干一件事的。

 

四、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，客户端必须理解它们。