Web Service概念梳理

计算机技术难理解的很多，Web Service 对我来说就是一个很难理解的概念；为了弄清它到底是什么，我花费了两周的时间，总算有了一些收获，参考了不少网上的资料，但有些概念说法不一。我以w3c和 一些早期介绍Web Service的书为准。如有错误，欢迎指正！

--------------------------------------------------------------

提前预警！概念太多，你需要仔细阅读，或要阅读两遍。

 

SOA                                                                       

Service Oriented Ambiguity 中文一般理解为，面向服务架构，简称SOA。

SOA的提出是在企业计算领域，就是要将紧耦合的系统，划分为面向业务的，粗粒度，松耦合，无状态的服务。服务发布出来供其他服务调用，一组互相依赖的服务就构成了SOA架构下的系统。

既然说是一种架构的话，所以一般认为SOA是包含了运行环境，编程模型，架构风格和相关方法论等在内的一整套新的分布式软件系统构造方法和环境，涵盖服务的整个生命周期。

Service-architecture.com将 SOA定义为：

本质上是服务的集合。服务间彼此通信，这种通信可能是简单的数据传送，也可能是两个或更多的服务协调进行某些活动。服务间需要某些方法进行连接。

所谓服务就是精确定义、封装完善、独立于其他服务所处环境和状态的函数。

虽然不同厂商或个人对 SOA有着不同的理解，但是我们仍然可以从上述的定义中看到 SOA的几个关键特性：一种粗粒度、松耦合服务架构，服务之间通过简单、精确定义接口进行通讯，不涉及底层编程接口和通讯模型。

(这不由的让我想到了另一个概念---“敏捷测试”，它强调拥抱变化，沟通、减少文档、快速迭代等。至于不同的公司或团队如何具体的实施并没有详细的规范，只要符合以上几点要求的公司或团队都可以认为实施了敏捷测试。)

对于SOA来说，读者并不需要太过较真SOA到是一个怎样的架构。只要符合它的定义和规范的软件系统都可以认为是SOA架构。

SOA 与 Web Service                                         

早在1996年Gartner就前瞻性地提出了面向服务架构的思想(SOA)，Web Service不知为何物，SOA还只是束之高阁的理论概念。直到2000年以后，W3C才成立了相关的委员会，开始讨论Web Service的相关标准，各大厂商一边积极参与标准制定，一边推出了一系列实实在在的产品。新的技术和新的产品出现，SOA找到了可以依托的凭借。随着 Web Service技术的推出和应用，SOA的思想被一个个效益显著的信息系统建设项目不断的示范，才逐渐成为现今的热门话题。

因为现在几乎所有的SOA应用场合都是和Web Service绑定的，所以不免有时候这两个概念混用。不可否认Web Service是现在最适合实现SOA的技术，SOA的走红在很大程度上归功于Web Service标准的成熟和应用普及。因为现在大家基本上认同Web Service技术在几方面体现了SOA的需要：

首先，是基于标准访问的独立功能实体满足了松耦合要求：在Web Service中所有的访问都通过SOAP访问进行，用WSDL定义的接口封装，通过UDDI进行目录查找，可以动态改变一个服务的提供方而无需影响客户端的配置，外界客户端是根本不关心访问服务器端的实现。

其次，适合大数据量低频率访问符合服务大颗粒度功能：基于性能和效率平衡的要求，SOA的服务提供的是大颗粒度的应用功能，而且跨系统边界的访问频率也不会象程序间函数调用那么频繁。通过使用WSDL和基于文本(Literal)的SOAP请求，可以实现能一次性接收处理大量数据。

最后，基于标准的文本消息传递为异构系统提供通讯机制：Web Service所有的通讯是通过SOAP进行的，而SOAP是基于XML的，XML是结构化的文本消息。从最早的EDI开始，文本消息也许是异构系统间通讯最好的消息格式，适用于SOA强调的服务对异构后天宿主系统的透明性。

综合上述观点，Web Service不愧为当前SOA的最好选择。然而，就SOA思想本身而言，并不一定要局限于Web Service方式的实现。更应该看到的是SOA本身强调的是实现业务逻辑的敏捷性要求，是从业务应用角度对信息系统实现和应用的抽象。随着人们认识的提高，还会有新技术不断的发明出来，更好的来满足这个要求。

上面涉及的名词太多，我们等一下还会单一的来介绍，用一句话总结它们之间的关系。 “SOA不是Web Service，Web Service是目前最适合实现SOA的技术。”

 

Web Service                                                       

在解释 Web Service 之前，先抛出一个问题。有没有一种办法可以实现跨应用程序进行通信和跨平台进行通信呢？

跨应用程序，主要是指我家开发的系统和别人家开发的系统之间是否可以通信。

跨平台，主要是指我家用Java开发的系统和别人家用.NET开发的系统是否可以通信。

像这样的需求有很多，例如腾讯QQ上面自带的天气功能。

腾讯要想获得实时的天气信息怎么办呢？有一种办法，那就是腾讯公司放个卫星上天，并且在公司中成立一个气象部门，天天关注于天气，然后每时每刻更新腾讯QQ上的这个天气预报信息；这显然不是一种明智的做法，只是想获取一下天气信息，居然要如此高的成本。

更简单的做法是让中国气象台提供实时的天气信息，然后，通过提供接口的方式给腾讯调用。那么这就遇到我上面所说的问题，如何跨应用与跨平台调用接口。

这个时候有聪明的读者会跳出来说，你傻啊！用HTTP协议啊，主流的编程语言都可以实现基于HTTP协议的应用开发。让中国气象台写个基于HTTP协议的天气接口给腾讯调用就可以了。当然，这是完全可以的。不过，Web Service之所以在HTTP之后被提出自然有它的特点。

当然，这里拿Web Service 与HTTP进行比较是不合适。因为HTTP是互联网上应用最为广泛的一种网络协议。而Web Service是一种部署在Web上的对象或者是应用程序组件，Web Service数据的传输同样需要借助HTTP协议。

更详细的定义：

Web service是一个平台独立的，低耦合的，自包含的、基于可编程的web的应用程序，可使用开放的XML（标准通用标记语言下的一个子集）标准来描述、发布、发现、协调和配置这些应用程序，用于开发分布式的互操作的应用程序。

SOAP                                                                  

Simple Object Access Protocol，中文为简单对象访问协议，简称SOAP。

SOAP是基于XML在分散或分布式的环境中交换信息的简单的协议。允许服务提供者和服务客户经过防火墙在INTERNET进行通讯交互。

SOAP的设计是为了在一个松散的、分布的环境中使用XML对等地交换结构化的和类型化的信息提供了一个简单且轻量级的机制。

XML是可以扩展标记语言。

SOAP 消息的基本结构

当SOAP消息真正需要在网络上实际传输的时候，SOAP消息能够与不同的底层传输协议进行绑定，同时，SOAP消息可以在很多种消息传输模式中使用。包括超文本传输协议（HTTP），简单邮件传输协议（SMTP），多用途网际邮件扩充协议（MIME）。它还支持从消息系统到远程过程调用协议（RPC）等大量的应用程序。

当然，最多的情况还是绑定在HTTP协议上面传输。这就导致大多数人认为SOAP就是HTTP + XML，或者认为SOAP是HTTP post请求的一个专用版本，遵循一种特殊的XML消息格式。

虽然，我们看到的大多情况确实如此，但这并不是SOAP本质与全部。

这个请求你用fiddler可抓不到，我是用wireshark抓的，它可以截获网卡的所有请求。

WSDL                                                                    

Web Services Description Language，网络服务描述语言，简称WSDL。它是一门基于 XML 的语言，用于描述 Web Services 以及如何对它们进行访问。

WSDL 文档主要使用以下几个元素来描述某个 web service ：

<portType>  web service 执行的操作。

<message>  web service 使用的消息。

<types>     web service 使用的数据类型。

<binding>   web service 使用的通信协议。

WSDL 端口

<portType> 元素是最重要的 WSDL 元素。

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

WSDL 消息

<message> 元素定义一个操作的数据元素。

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

WSDL types

<types> 元素定义 web service 使用的数据类型。

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

WSDL Bindings

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

对于接口来说，接口文档非常重要，它描述如何访问接口。那么WSDL就可以看作Web Service接口的一种标准格式的“文档”。我们通过阅读WSDL就知道如何调用Web Service接口了。

UDDI                                                                   

Universal Description, Discovery and Integration"，可译为“通用描述、发现与集成服务”，简称UDDI。

WSDL用来描述了访问特定的 Web Service的一些相关的信息，那么在互联网上，或者是在企业的不同部门之间，如何来发现我们所需要的 Web Service呢？而 Web Service提供商又如何将自己开发的 Web Serivce公布到因特网上呢？这就需要使用到 UDDI 了。

UDDI 是一个独立于平台的框架，用于通过使用 Internet 来描述服务，发现企业，并对企业服务进行集成。

UDDI 指的是通用描述、发现与集成服务

UDDI 是一种用于存储有关 web services 的信息的目录。

UDDI 是一种由 WSDL 描述的 web services 界面的目录。

UDDI 经由 SOAP 进行通信

UDDI 被构建入了微软的 .NET 平台

下面，提供两张图，体会一下UDDI的安装与发布。

UDDI可以帮助 Web 服务提供商在互联网上发布 Web services的信息。UDDI 是一种目录服务，企业可以通过 UDDI 来注册和搜索 Web services。

通过前面的介绍，SOAP、WSDL和UDDI就构成了web Service的三要素。

Web Services体系结构                  

在Web Serivce的体系结构中涉及到三个角色，一个是 Web Service提供者，一个是 Web Service中介，还有一个就是 Web Service请求者；同时还涉及到三类动作，即发布，查找，绑定，

Web Service提供者：

可以发布 Web Service，并且对使用自身服务的请求进行响应，Web Service的拥有者，它会等待其他的服务或者是应用程序访问自己。

Web Service请求者：

也就是 Web Service功能的使用者，它通过服务注册中心也就是 Web Service中介者查找到所需要的服务，再利用 SOAP 消息向 Web Service提供者发送请求以获得服务。

Web Service中介：

也称为服务代理，用来注册已经发布的 Web Service提供者，并对其进行分类，同时提供搜索服务，简单来说的话，Web Service中介者的作用就是把一个 Web Service请求者和合适的 Web Service提供者联系在一起，充当一个管理者的角色，一般是通过 UDDI来实现。

发布：

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

发现（查找）：

使得 Web Service请求者可以通过 Web Service中介者来查找到特定种类的 Web Service 接口。

绑定：

这里就是实现让Web Serivce请求者能够使用Web Serivce提供者提供的Web Serivce接口。

============================================

好了，最后终于回答前面的问题了，Web Service相对于HTTP有什么优点？。

1.接口中实现的方法和要求参数一目了然。

2.不用担心大小写问题。

3.不用担心中文urlencode问题。

4.代码中不用多次声明认证（账号，密码）参数。

5.传递参数可以为数组，对象等。

那么，第二个问题，Web Service能被HTTP替代么？ 答案是肯定的。

===============================================

最后，花了这么多时间了解一个过时的技术，真是日了狗了！最近再研究接口测试， Web Service是个绕不开的技术。当然，我的了解还包含了Web Service的开发 和测试。