Web Service

1.引言

顾名思义Web Service—网络服务。先了解Service—服务是什么，字面上理解是满足你的需求所进行的活动。

web网络，连起来就是在网络上的服务。当然也有在本地的服务，比如单机游戏。

那么既然有单机的服务还要网络的干嘛，单机的还可以省流量啊。

1.1本地服务的缺陷：

*　本地资源不足。很多数据和资料，本地得不到，只有向其他网站要。

*　成本因素。本地提供服务，往往是不经济的，使用专业网站的服务更便宜。这里面涉及硬件和人员两部分，即使你买得起硬件，专门找一个人管理系统，也是很麻烦的事。

*　可移植性差。如果你想把本机的服务，移植到其他机器上，往往很困难，尤其是在跨平台的情况下。

比如QQ的天气预报功能，大家都知道要预测天气需要有卫星难道腾讯发射了自己的卫星？难道有天气预报功能的公司都要自己发射卫星？很明显不是，所有的数据都是中国气象局提供的，它给我们提供服务。

那么QQ和中国气象局是两个不同的系统他们是怎样进行通讯的呢？
他们是在同一个操作系统上？他们是用同一种语言编写的？

Web Service的特点

WebServices 提供一个建立分布式应用的平台，它实质上是一个中介，帮组处在不同操作系统或者不同编译语言的程序进行通讯和连接。使得各系统不是孤岛资源可以共享，产生松散耦合性。

特点：

1.WebServices 是自包含的。即在客户端不需要附加任何软件，只要客户机支持 HTTP 和XML 就 OK 了。

2.WebServices 是自我描述的。在客户端和服务端只需要知道请求和响应消息的格式和内容。

3.WebServices 是跨平台和跨语言的。客户端和服务端均可以在不同的平台和语言环境中实现，同时，不必为了支持 WebServices 而更改现有的代码。

4.WebServices 是基于开放和标准的。XML 和 HTTP 是WebServices 的主要技术基础，而 XML 和HTTP 早就成了业内标准了。

5.WebServices 是动态的。

6.WebServices 是可以组合的。也就是通过一个 WebService 访问另外一个 WebService 来达到组合的目的。通过组合 WebServices 便可以将简单的 WebServices 聚合成为实现更多复杂功能的复杂的服务。

7.WebServices 是松散耦合的。它完全解耦了客户端和服务端。

8.WebServices 提供编程访问的能力。换句话说，就是可以通过编写程序来访问Web 服务。

9.WebServices 是基于经过考验的成熟技术上构建的。比如 XML 和 HTTP。

10.WebServices 提供打包现有应用程序的能力。

11.WebServices 通过网络进行发布，查找和使用。

WebServices体系结构

如图有三个角色、三个动作。

服务提供者：响应（满足）客户端的请求（需求）。（绑定）就好比一家酒店一样你要想做大做强就要在公共平台注册，公众才容易找的到你。（注册、发布）

服务请求者：发出请求，联系服务提供者（绑定），但是你要怎么找到服务提供者呢？你就要去注册中心找。（发现）

服务注册中心：公共平台收集服务提供者的信息，方便请求者寻找服务。

发布：
通过发布操作，可以使 Web服务提供者向 Web 服务中介者注册自己的功能以及访问的接口。

发现（查找）：
使得 Web 服务请求者可以通过 Web 服务注册中心查找想要的服务。

绑定：
这里就是实现让服务请求者能够使用服务提供者提供的服务了，形成了松散耦合。

Web Service的本质

WebServices就是一组函数库，函数库不在你本地而是在远程机器上通过网络可以调用，使用这组函数库就可以把你的程序从应用层面提升到服务层面上来。

WebServices是基于 XML 和 HTTP 的， XML 和 HTTP都是标准（本身就是跨平台的），所以可以通过 Web 服务来实现不同应用程序和不同平台之间的通信。Web 服务允许独立于实现服务基于的硬件或者是软件平台和编写服务所用的编程语言使用服务，从而大大提高了不同应用程序共享数据和应用的能力。

WebServices的三大技术支持

SOAP

概述

SOAP 呢，其指导理念是“唯一一个没有发明任何新技术的技术”，
是一种用于访问 Web 服务的协议。
因为 SOAP 基于XML 和 HTTP ，其通过XML 来实现消息描述，然后再通过 HTTP 实现消息传输。
SOAP 是用于在应用程序之间进行通信的一种通信协议。
因为是基于 XML 和HTTP 的，所以其独立于语言，独立于平台，并且因为 XML 的扩展性很好，
所以基于 XML 的 SOAP 自然扩展性也不差。
通过 SOAP 可以非常方便的解决互联网中消息互联互通的需求，
其和其他的 Web 服务协议构建起 SOA 应用的技术基础。
SOAP 协议的一个重要特点是它独立于底层传输机制，Web 服务应用程序可以根据需要选择自己的数据传输协议，
可以在发送消息时来确定相应传输机制。
由于 HTTP 协议本身的一些特点和局限性，
使得当 SOAP 使用HTTP 绑定的 Web 服务并不能满足某些企业应用的需求。
比如，HTTP 不是一个可靠传输协议，所以有可能在传输过程中出现问题，
然后 HTTP 协议基于Request/Response 模型，也就是说客户端需要在等待响应消息接收完成后才能继续执行，
而此时如果响应时间过长呢？
基于上面的这些需求，便需要选择合适的传输协议了。
关于这方面的内容的话，有点深奥了，有兴趣的可以去看看 IBM 的一些关于这方面内容的介绍。
还有一点需要提及一下，那就是 SOAP 是可以绕过防火墙的，将来将会作为 W3C 的标准进行发展。

一条 SOAP 消息就是一个普通的 XML 文档，包含下列元素：
• Envelope 元素，标识XML 文档一条 SOAP 消息
• Header 元素，包含头部信息的XML标签
• Body 元素，包含所有的调用和响应的主体信息的标签
• Fault 元素，错误信息标签。

以上的元素都在 SOAP的命名空间http://www.w3.org/2001/12/soap-envelope中声明；

SOAP的语法规则

• SOAP 消息必须用 XML 来编码
• SOAP 消息必须使用 SOAP Envelope 命名空间
• SOAP 消息必须使用 SOAP Encoding 命名空间
• SOAP 消息不能包含 DTD 引用 （<!DOCTYPE根元素 [元素声明]>）
• SOAP 消息不能包含 XML 处理指令 （<?xml-stylesheet type="text/css" href="1.css"?>）

SOAP 消息的基本结构

<? xml version="1.0"?>  <soap:Envelope  xmlns:soap="http://www.w3.org/2001/12/soap-envelope" soap:encodingStyle="http://www.w3.org/2001/12/soap-encoding">  <soap:Header>    ...    ...  </soap:Header>  <soap:Body>    ...    ...    <soap:Fault>      ...      ...    </soap:Fault>  </soap:Body>  </soap:Envelope> 

SOAP Envelope 元素

Envelope 元素是 SOAP 消息的根元素。它指明 XML 文档是一个SOAP 消息。它的属性 xmlns:soap的值必须是http://www.w3.org/2001/12/soap-envelope。
 encodingStyle 属性，语法：soap:encodingStyle=”URI”
encodingStyle 属性用于定义文档中使用的数据类型。此属性可出现在任何 SOAP 元素中，并会被应用到元素的内容及元素的所有子元素上。

<? xml version="1.0"?>  <soap:Envelope  xmlns:soap="http://www.w3.org/2001/12/soap-envelope" soap:encodingStyle="http://www.w3.org/2001/12/soap-encoding">    ...    Message information goes here    ...  </soap:Envelope> 

SOAP Header 元素

actor 属性，语法soap:actor=”URI”

通过沿着消息路径经过不同的端点，SOAP 消息可从某个发送者传播到某个接收者。并非 SOAP 消息的所有部分均打算传送到 SOAP 消息的最终端点，不过，另一个方面，也许打算传送给消息路径上的一个或多个端点。SOAP 的 actor 属性可被用于将 Header 元素寻址到一个特定的端点。

mustUnderstand 属性 ，语法soap:mustUnderstand=”0|1”

SOAP 的 mustUnderstand 属性可用于标识标题项对于要对其进行处理的接收者来说是强制的还是可选的。假如您向 Header 元素的某个子元素添加了 “mustUnderstand=”1”，则要求处理此头部的接收者必须认可此元素。

<? xml version="1.0"?> <soap:Envelope xmlns:soap="http://www.w3.org/2001/12/soap-envelope" soap:encodingStyle="http://www.w3.org/2001/12/soap-encoding"> <soap:Header> <m:Trans xmlns:m="http://www.jsoso.net/transaction/"  soap:mustUnderstand="1"  soap:actor="http://www.w3schools.com/appml/ “  >234</m:Trans> </soap:Header> ... ... </soap:Envelope> 

SOAP Body 元素

必需的 SOAP Body 元素可包含打算传送到消息最终端点的实际 SOAP 消息。Body元素中既可以包含SOAP定义的命名空间中的元素，如Fault，也可以是用户的应用程序自定义的元素。以下是一个用户定义的请求：

<? xml version="1.0"?> <soap:Envelope xmlns:soap="http://www.w3.org/2001/12/soap-envelope" soap:encodingStyle="http://www.w3.org/2001/12/soap-encoding"> <soap:Body>    <m:GetPrice xmlns:m="http://www.jsoso.net/prices">       <m:Item>Apples</m:Item>    </m:GetPrice> </soap:Body> </soap:Envelope> 

上面的例子请求苹果的价格。请注意，上面的 m:GetPrice 和 Item 元素是应用程序专用的元素。它们并不是 SOAP 标准的一部分。而对应的 SOAP 响应应该类似这样：

<?xml version="1.0"?>  <soap:Envelope  xmlns:soap="http://www.w3.org/2001/12/soap-envelope" soap:encodingStyle="http://www.w3.org/2001/12/soap-encoding">  <soap:Body>     <m:GetPriceResponse xmlns:m="http://www.jsoso.net/prices">        <m:Price>1.90</m:Price>     </m:GetPriceResponse>  </soap:Body>  </soap:Envelope> 

SOAP Fault 元素

SOAP Fault 元素用于存留 SOAP 消息的错误和状态信息。

可选的 SOAP Fault 元素用于指示错误消息。
如果已提供了 Fault 元素，则它必须是 Body 元素的子元素。在一条 SOAP 消息中，Fault 元素只能出现一次。

SOAP 的 Fault 元素拥有下列子元素：

SOAP Fault 代码
在下面定义的 faultcode 值必须用于描述错误时的 faultcode 元素中：

HTTP 协议

HTTP 在 TCP/IP 之上进行通信。HTTP 客户机使用 TCP 连接到 HTTP 服务器。在建立连接之后，客户机可向服务器发送 HTTP 请求消息：

POST /item HTTP/1.1Host: 189.123.345.239Content-Type: text/plainContent-Length: 200

随后服务器会处理此请求，然后向客户机发送一个 HTTP 响应。此响应包含了可指示请求状态的状态代码：

200 OKContent-Type: text/plainContent-Length: 200

在上面的例子中，服务器返回了一个 200 的状态代码。这是 HTTP 的标准成功代码。
假如服务器无法对请求进行解码，它可能会返回类似这样的信息：

400 Bad RequestContent-Length: 0

SOAP HTTP Binding
SOAP 方法指的是遵守 SOAP 编码规则的 HTTP 请求/响应。

HTTP + XML = SOAP
SOAP 请求可能是 HTTP POST 或 HTTP GET 请求。
HTTP POST 请求规定至少两个 HTTP 头：Content-Type 和 Content-Length。

SOAP 的请求和响应的 Content-Length 头规定请求或响应主体的字节数。
语法

Content-Length: bytes 

例子

POST /item HTTP/1.1Content-Type: application/soap+xml; charset=utf-8Content-Length: 250

HTTP协议中的SOAP 实例

下面的例子中，一个 GetStockPrice 请求被发送到了服务器。此请求有一个 StockName 参数，而在响应中则会返回一个 Price 参数。此功能的命名空间被定义在此地址中： “http://www.jsoso.net/stock”
SOAP 请求：(注意HTTP的Head属性)

 POST /InStock HTTP/1.1 Host: www.jsoso.net  Content-Type: application/soap+xml; charset=utf-8 Content-Length: XXX  <? xml version="1.0"?>  <soap:Envelope  xmlns:soap="http://www.w3.org/2001/12/soap-envelope" soap:encodingStyle="http://www.w3.org/2001/12/soap-encoding">    <soap:Body xmlns:m="http://www.jsoso.net/stock">      <m:GetStockPrice>        <m:StockName>IBM</m:StockName>      </m:GetStockPrice>    </soap:Body>    </soap:Envelope> 

SOAP 响应：(注意HTTP的Head属性)

HTTP/1.1 200 OK  Content-Type: application/soap+xml; charset=utf-8 Content-Length: XXX  <? xml version="1.0"?>  <soap:Envelope  xmlns:soap="http://www.w3.org/2001/12/soap-envelope" soap:encodingStyle="http://www.w3.org/2001/12/soap-encoding">    <soap:Body xmlns:m="http://www.jsoso.net/stock">      <m:GetStockPriceResponse>        <m:Price>34.5</m:Price>      </m:GetStockPriceResponse>    </soap:Body>    </soap:Envelope> 

WSDL

概述

WSDL 即Web Services Description Language也就是 Web 服务描述语言。
是基于 XML的用于描述 Web 服务以及如何访问 Web 服务的语言。
服务提供者通过服务描述将所有用于访问 Web服务的规范传送给服务请求者，
要实现 Web服务体系结构的松散耦合，服务描述是一个关键，
不管是请求者还是服务提供者，通过服务描述便可以不必了解对方的底层平台，编程语言等，
服务描述与底层的 SOAP 基础结构相结合，
足以封装服务请求者的应用程序和服务提供者的 Web服务之间的这个细节。
WSDL 描述了 Web服务的三个基本属性：
（1）服务所提供的操作
（2）如何访问服务
（3）服务位于何处（通过 URL 来确定就 OK 了）

WSDL 文档结构

WSDL 文档是利用这些主要的元素来描述某个 web service 的：

一个 WSDL 文档的主要结构是类似这样的：

<definitions><types>   definition of types........</types><message>   definition of a message....</message><portType>   definition of a port.......</portType><binding>   definition of a binding....</binding></definitions>

WSDL 文档可包含其它的元素，比如 extension 元素，以及一个 service 元素，此元素可把若干个 web services 的定义组合在一个单一的 WSDL 文档中。

WSDL 端口

元素是最重要的 WSDL 元素。
它可描述一个 web service、可被执行的操作，以及相关的消息。
可以把 元素比作传统编程语言中的一个函数库（或一个模块、或一个类）。

WSDL 消息

元素定义一个操作的数据元素。
每个消息均由一个或多个部件组成。可以把这些部件比作传统编程语言中一个函数调用的参数。

WSDL types

元素定义 web service 使用的数据类型。
为了最大程度的平台中立性，WSDL 使用 XML Schema 语法来定义数据类型。

WSDL Bindings

元素为每个端口定义消息格式和协议细节。

WSDL 实例

这是某个 WSDL 文档的简化的片段：

<message name="getTermRequest">   <part name="term" type="xs:string"/></message><message name="getTermResponse">   <part name="value" type="xs:string"/></message><portType name="glossaryTerms">  <operation name="getTerm">        <input message="getTermRequest"/>        <output message="getTermResponse"/>  </operation></portType>

在这个例子中， 元素把 “glossaryTerms” 定义为某个端口的名称，把 “getTerm” 定义为某个操作的名称。

操作 “getTerm” 拥有一个名为 “getTermRequest” 的输入消息，以及一个名为 “getTermResponse” 的输出消息。

元素可定义每个消息的部件，以及相关联的数据类型。

对比传统的编程，glossaryTerms 是一个函数库，而 “getTerm” 是带有输入参数 “getTermRequest” 和返回参数 getTermResponse 的一个函数。

WSDL 端口

WSDL 端口可描述由某个 web service 提供的界面（合法操作）。

<portType> 元素是最重要的 WSDL 元素。
它可描述一个 web service、可被执行的操作，以及相关的消息。
端口定义了指向某个 web service 的连接点。可以把该元素比作传统编程语言中的一个函数库（或一个模块、或一个类），而把每个操作比作传统编程语言中的一个函数。

操作类型

请求-响应是最普通的操作类型，不过 WSDL 定义了四种类型：

One-Way 操作
一个 one-way 操作的例子：

<message name="newTermValues">   <part name="term" type="xs:string"/>   <part name="value" type="xs:string"/></message><portType name="glossaryTerms">   <operation name="setTerm">      <input name="newTerm" message="newTermValues"/>   </operation></portType >

在这个例子中，端口 “glossaryTerms” 定义了一个名为 “setTerm” 的 one-way 操作。

这个 “setTerm” 操作可接受新术语表项目消息的输入，这些消息使用一条名为 “newTermValues” 的消息，此消息带有输入参数 “term” 和 “value”。不过，没有为这个操作定义任何输出。

Request-Response 操作

一个 request-response 操作的例子：

<message name="getTermRequest">   <part name="term" type="xs:string"/></message><message name="getTermResponse">   <part name="value" type="xs:string"/></message><portType name="glossaryTerms">  <operation name="getTerm">    <input message="getTermRequest"/>    <output message="getTermResponse"/>  </operation></portType>

在这个例子中，端口 “glossaryTerms” 定义了一个名为 “getTerm” 的 request-response 操作。

“getTerm” 操作会请求一个名为 “getTermRequest” 的输入消息，此消息带有一个名为 “term” 的参数，并将返回一个名为 “getTermResponse” 的输出消息，此消息带有一个名为 “value” 的参数。

WSDL 绑定

WSDL 绑定可为 web service 定义消息格式和协议细节。

绑定到 SOAP
一个 请求 - 响应 操作的例子：

<message name="getTermRequest">   <part name="term" type="xs:string" /></message><message name="getTermResponse">   <part name="value" type="xs:string" /></message><portType name="glossaryTerms">  <operation name="getTerm">      <input message="getTermRequest" />      <output message="getTermResponse" />  </operation></portType><binding type="glossaryTerms" name="b1"><soap:binding style="document"transport="http://schemas.xmlsoap.org/soap/http" />  <operation>    <soap:operation     soapAction="http://example.com/getTerm" />    <input>      <soap:body use="literal" />    </input>    <output>      <soap:body use="literal" />    </output>  </operation></binding>

binding 元素有两个属性 - name 属性和 type 属性。
name 属性定义 binding 的名称，而 type 属性指向用于 binding 的端口，在这个例子中是 “glossaryTerms” 端口。

soap:binding 元素有两个属性 - style 属性和 transport 属性。

style 属性可取值 “rpc” 或 “document”。在这个例子中我们使用 document。transport 属性定义了要使用的 SOAP 协议。在这个例子中我们使用 HTTP。

operation 元素定义了每个端口提供的操作符。

对于每个操作，相应的 SOAP 行为都需要被定义。同时您必须如何对输入和输出进行编码。在这个例子中我们使用了 “literal”。

UDDI

概述

UDDI 即 Universal Description，Discovery and Integration（通用描述、发现与集成服务），也就是通用的描述，发现以及整合。

WSDL 呢，用来描述了访问特定的 Web 服务的一些相关的信息，可以在互联网上，
或者是在企业的不同部门之间，如何来发现我们所需要的 Web 服务呢？
而 Web 服务提供商又如何将自己开发的 Web 服务公布到因特网上，
这就需要使用到 UDDI 了，UDDI的话，是一个跨产业，跨平台的开放性架构，
可以帮助 Web 服务提供商在互联网上发布 Web 服务的信息。
UDDI 呢是一种目录服务，企业可以通过 UDDI 来注册和搜索 Web 服务。
简单来时候话，UDDI 就是一个目录，只不过在这个目录中存放的是一些关于 Web 服务的信息而已。
并且 UDDI 通过SOAP 进行通讯，构建于 . Net 之上。

什么是 UDDI？

UDDI 是一个独立于平台的框架，用于通过使用 Internet 来描述服务，发现企业，并对企业服务进行集成。
UDDI 指的是通用描述、发现与集成服务
UDDI 是一种用于存储有关 web services 的信息的目录。
UDDI 是一种由 WSDL 描述的 web services 界面的目录。
UDDI 经由 SOAP 进行通信
UDDI 被构建入了微软的 .NET 平台

UDDI 基于什么？

UDDI 使用 W3C 和 IETF* 的因特网标准，比如 XML、HTTP 和 DNS 协议。
UDDI 使用 WSDL 来描述到达 web services 的界面
此外，通过采用 SOAP，还可以实现跨平台的编程特性，大家知道，SOAP 是 XML 的协议通信规范，可在 W3C 的网站找到相关的信息。
*注释：IETF - Internet Engineering Task Force

UDDI 的好处

任何规模的行业或企业都能得益于 UDDI。
在 UDDI 之前，还不存在一种 Internet 标准，可以供企业为它们的企业和伙伴提供有关其产品和服务的信息。也不存在一种方法，来集成到彼此的系统和进程中。

UDDI 规范帮助我们解决的问题：

使得在成百万当前在线的企业中发现正确的企业成为可能
定义一旦首选的企业被发现后如何启动商业
扩展新客户并增加对目前客户的访问
扩展销售并延伸市场范围
满足用户驱动的需要，为在全球 Internet 经济中快速合作的促进来清除障碍

UDDI 如何被使用

假如行业发布了一个用于航班比率检测和预订的 UDDI 标准，航空公司就可以把它们的服务注册到一个 UDDI 目录中。然后旅行社就能够搜索这个 UDDI 目录以找到航空公司预订界面。当此界面被找到后，旅行社就能够立即与此服务进行通信，这样由于它使用了一套定义良好的预订界面。

谁在支持 UDDI？

UDDI 是一个跨行业的研究项目，由所有主要的平台和软件提供商驱动，比如：Dell, Fujitsu, HP, Hitachi, IBM, Intel, Microsoft, Oracle, SAP, 以及 Sun, 它既是一个市场经营者的团体，也是一个电子商务的领导者。
已有数百家公司参与了这个 UDDI 团体。