Web Service基础

wangping06

于 2009-11-16 13:54:00 发布

阅读量1.6k

点赞数

分类专栏：技术文档文章标签： service web soap web服务 header binding

本文链接：https://blog.csdn.net/wangping06/article/details/4815728

版权

技术文档专栏收录该内容

7 篇文章 0 订阅

订阅专栏

1.Web Service的基本概念

什么是Web Services？Web Services 是设计支持支持机器与机器的通过网络互操作的一种软件系统(W3C的定义).是一组可以通过网络调用的应用程序API .Web Services 是应用程序组件 , 使用开放协议进行通信 ,独立的（self-contained）并可自我描述 ,可通过使用UDDI来发现 ,可被其他应用程序使用的功能.

Web services 平台主要涉及到XML /SOAP/WSDL/UDDI四个主要元素.

(1)XML :XML是Extensible Markup Language的缩写,XML是一种类似于HTML的标记语言,XML是用来描述数据的,XML的标记不是在XML中预定义的，你必须定义自己的标记 XML使用文档类型定义（DTD）或者模式（Schema）来描述数据 ,XML使用DTD或者Schema后就是自描述的语言.
(2)SOAP :SOAP(Simple Object Access Protocol)简单对象访问协议是在分散或分布式的环境中交换信息的简单的协议，是一个基于XML的协议。

它包括四个部分：SOAP封装(envelop)，封装定义了一个描述消息中的内容是什么，是谁发送的，谁应当接受并处理它以及如何处理它们的框架;SOAP编码规则(encoding rules)，用于表示应用程序需要使用的数据类型的实例; SOAP RPC表示(RPC representation)，表示远程过程调用和应答的协定;SOAP绑定(binding)，使用底层协议交换信息。

　　a、SOAP的基本结构

　　SOAP中根元素是Envelope元素。Envelope元素中可以包含多个可选的Header元素，必须同时包含一个Body元素。Header元素必须是Envelope元素的直接子元素，并且要位于Body元素之前。

SOAP消息：

<?xml version="1.0" encoding="UTF-8">

<soap:Envelop xmlns:soap="http://schemas.xmlsoap.org/soap/envelope/">

<soap:Header xmlns:some-ns="http://www.wiley.com/soap/headers/">

<some-ns:autentication="some URI" env:mustUderstand="true/false" env:relay="true/false" env:role="some URI"/>

</soap:Header>

<soap:Body>

<mh:getBookPrice>

</mh:getBookPrice>

<soap:fault>

</soap:fault>

</soap:Body>

</soap:Envelope>

　　b、SOAP的命名空间

　　SOAP消息可以在Header元素和Body元素中包含若干不同的XML元素，使用唯一的命名空间来标识它们。xmlns:soap=http://schemas.xmlsoap.org/soap/envelope/命名空间定义了标准SOAP元素（例如：Envelope, Header和Body等）。Header元素的每个头文件都有自己的命名空间。

　　c、 SOAP头

　　SOAP header在Web Service中的应用越来越多，例如安全性、事务以及其他各种服务方面的大量“标准”文件头。SOAP文件头是扩展SOAP协议的一个功能非常强大的措施，SOAP文件头的扩展性是SOAP得以流行并且获得其他协议没有取得成功的另一个原因。

　　1 actor属性(next、ultimate receiver、none)

　　Actor是由SOAP注释定义的，在SOAP 1.2中，actor属性已经被更名为role。Actor属性和XML命名空间组合在一起使用，以确定要用哪个代码模块处理具体的Header。

Next角色表示消息路径中的下一个节点必须处理文件头。

Ultimate receiver角色表示只有消息的最终接收方才能处理指定的Header。

None:表示有效断开消息头

　　2 mustUnderstand属性

表示处理是否为强制性处理，如果一个节点不能识别某一个强制性Header，那么必定会产生SOAP错误。如果MustUnderstand属性的值是0，如果应用程序没有能够识别该文件头，那么必须删除此文件头。

3 relay属性

SOAP中介体可以删除它不能处理的消息头。如果我们新加一个特性，要求中介体必须处理它，就把relay属性设为true,否则设置为false。

d、SOAP体

Body元素要包含应用程序专有的数据或者错误消息。应用程序的专有数据可以是任意XML数据或者是提供给过程调用的任意参数。只有SOAP消息最后的接收方应该处理SOAP Body。

Fault元素

　　e、SOAP消息传递模式

　　SOAP支持四种消息传递模式（RPC/Literal, Document/ Literal, RPC/Encoded, and Document/Encoded），但是WS-I Basic Profile只允许RPC/Literal和Document/ Literal，不支持SOAP encoding，因为它会引起严重的互操作性。Literal表示可以根据XML模式验证XML文档的有效性。

　　1 Document/ Literal消息传递模式

　　Document/ Literal消息传递模式中，SOAP的Body元素包含一个XML格式良好的文档段；

　　2 RPC/Literal消息传递模式

　　RPC/Literal消息传递模式将Body元素格式化成struct。PRC请求消息包含调用的方法名称与输入参数。RPC响应消息则包含返回值和各种输出参数（或者错误）；　

(3)WSDL: Web services 描述语言，它的主要构成要素有五个.

definitions:定义即将发送给Web服务，或者从Web服务读取的信息

types：定义WSDL定义中所用到的数据类型，即XML Schema Types;

messages : 对一组消息的输入和输出参数的定义;

portTypes : 定义Web服务的操作;

binding ：描述特定服务接口的协议、数据格式、安全性和其它属性.

service : 制定特定服务的URL和提供的调用接口，包含一组端口元素. 这样Web services 就实现了自我描述.

<?xml version="1.0"?>

<definitions name="StockQuote"

targetNamespace="http://example.com/stockquote.wsdl"

          xmlns:tns="http://example.com/stockquote.wsdl"

          xmlns:xsd1="http://example.com/stockquote.xsd"

          xmlns:soap="http://schemas.xmlsoap.org/wsdl/soap/"

          xmlns="http://schemas.xmlsoap.org/wsdl/">

    <types>

       <schema targetNamespace="http://example.com/stockquote.xsd"

              xmlns="http://www.w3.org/2000/10/XMLSchema">

           <element name="TradePriceRequest">

              <complexType>

                  <all>

                      <element name="tickerSymbol" type="string"/>

                  </all>

              </complexType>

           </element>

           <element name="TradePrice">

              <complexType>

                  <all>

                      <element name="price" type="float"/>

                  </all>

              </complexType>

           </element>

       </schema>

    </types>

    <message name="GetLastTradePriceInput">

        <part name="body" element="xsd1:TradePriceRequest"/>

    </message>

    <message name="GetLastTradePriceOutput">

        <part name="body" element="xsd1:TradePrice"/>

    </message>

    <portType name="StockQuotePortType">

        <operation name="GetLastTradePrice">

           <input message="tns:GetLastTradePriceInput"/>

           <output message="tns:GetLastTradePriceOutput"/>

        </operation>

    </portType>

    <binding name="StockQuoteSoapBinding" type="tns:StockQuotePortType">

        <soap:binding style="document" transport="http://schemas.xmlsoap.org/soap/http"/>

        <operation name="GetLastTradePrice">

           <soap:operation soapAction="http://example.com/GetLastTradePrice"/>

           <input>

               <soap:body use="literal"/>

           </input>

           <output>

               <soap:body use="literal"/>

           </output>

        </operation>

    </binding>

    <service name="StockQuoteService">

        <documentation>My first service</documentation>

        <port name="StockQuotePort" binding="tns:StockQuoteBinding">

           <soap:address location="http://example.com/stockquote"/>

        </port>

    </service>

</definitions>



　　service是一套＜port＞元素。在一一对应形式下，每个＜port＞元素都和一个location关联。如果同一个＜binding＞有多个＜port＞元素与之关联，可以使用额外的URL地址作为替换。

一个WSDL文档中可以有多个＜service＞元素，而且多个＜service＞元素十分有用，其中之一就是可以根据目标URL来组织端口。这样，我就可以方便的使用另一个＜service＞来重定向查询申请。我的客户端程序仍然工作，因为这种根据协议归类的服务不随服务而变化。多个＜service＞元素的另一个作用是根据特定的协议划分端口。例如，我可以把所有的HTTP端口放在同一个＜service＞中，所有的SMTP端口放在另一个＜service＞里。我的客户可以搜索与它可以处理的协议相匹配的＜service＞。

(4) UDDI :Universal Description Discovery and Integration即统一描述、发现和集成协议。UDDI同时也是Web服务集成的一个体系框架。它包含了服务描述与发现的标准规范。UDDI规范利用了W3C和Internet工程任务组织(IETF)的很多标准作为其实现基础，比如扩展标注语言（XML），HTTP和域名服务(DNS)这些协议。有了它我们的Web services 就可以注册到UDDI中心.供其客户查找使用.

白页：地址、联系人和已知标识符 (服务的公司：名称、地址、联系方式等等；)

黄页：基于标准分类法的行业类别（例如 North American Industry Classification System 和 Standard Industrial Classification）的行业类别；“

绿页：有关业务公开的服务的技术信息

Web services 一般分为4类:

(1)面向业务的服务(Business-Oriented Web Service): 该类服务针对的是那些面向企业应用服务;

(2)面向客户的服务(Consumer-Oriented Web Service): 此类服务针对的是那些原先的B2C的网站的改造，比如我们完全就可以在个人理财桌面系统中集成(调用)Internet上的股票价格查询Web服务、机票预定Web服务等，使得个人理财应用的自动化程度更高。

(3)面向设备的服务(Device-Oriented Web Service): 此类服务的使用终端一般是手持设备和日用家电，比如Palm、PocketPC、手机等。。

(4)面向系统的服务(System-Oriented Web Service): 一些传统意义上的系统服务，比如用户权限认证，系统监控等，譬如跨国企业的所有在线服务可以使用同一个用户权限认证Web服务。

2.Web Service优势和缺点

Web Services 的具有以下优点:

(1)跨平台:Web Services完全基于XML（可扩展标记语言）、XSD（XML Schema）等独立于平台、独立于软件供应商的标准;

(2)自描述:Web Services 使用WSDL标准语言进行自我描述,包括服务的方法/参数/类型/返回值等相关的完备信息.

(3)模块化:Web Services 是应用程序组件,我们可以使用任何开发平台来开发,并且按照模块进行封装.

(4)跨放火墙:Web Services 使用http协议进行通信,可以穿越防火墙.

Web Services 的缺点:

(1)效率低下,不适合做单应用系统的开发.

(2)安全问题,Web Services的没有自身的安全机制,必须借助http协议或IIS等宿主程序实现信息安全加密

3.Web Services使用的场合

那么什么时候应该使用Web Services,从上面的总结我们可以看出.使用Web Services能够带来利益的情况.

(1)跨防火墙的通信
(2)应用程序集成,主要是指企业应用系统的集成.
(3)B2B的集成,主要是指电子商务平台的集成.
(4)软件和数据重用,软件重用是一个很大的主题，重用的形式很多，重用的程度有大有小。最基本的形式是源代码模块或者类一级的重用，另一种形式是二进制形式的组件重用。
有一些情况，不适合使用Web Services。

　　(1)单机应用程序

　　单机应用程序如office等,可以直接调用系统Windows API/COM进行编程,实现功能效率更高.

　　(2)局域网的同构应用程序
例如在局域网里,使用COM+和.NET Remoting进行通信，会获得更高的效率.我们不需要使用Web Services.

4.Web Services安全问题

安全问题是开发和部署Web Services涉及最多的问题,主要还是防止重要信息的泄露.包括非法请求和恶意攻击.网络常见的安全问题Web Services都会面临.

Web Services的部署方式一般包括3种:

(1)IIS托管.这个最简单,直接借助IIS,发布方式类网站发布.

(2)Console.可以驻留在控制台程序中.

(3)Windows Service.驻留在系统服务中.
最常见的就是Web Services通过IIS托管发布,这个方式好处是它可以使用所有的ASP.Net的认证授权机制。

Web Services处在表示层和业务逻辑层之间.当然它可以直接地与数据库交互.简单的验证办法就是调用方法里实现对请求的合法性的判断.通过验证我们就执行Web Method,返回用户数据简单的办法是使用System.Web.Services.Protocols.SoapHeader的类。来传递客户票据到服务器进行验证.下面将实现简单的Web Services和验证机制.