Web Services：重整山河待后生

发表于 2年以前 | 总阅读数：386 次

长江后浪推前浪，前浪死在沙滩上。前面介绍过CGI，其实很多人从未用过甚至听过CGI。确实如此，毕竟这是在九十年代中叶，Web时代大爆发之前出现的技术，虽然各类语言都支持CGI，但几乎只在C/C++语言中流行。后来随着PHP、Java Web、.Net的兴起，而被拍死于沙滩，目前只在鹅厂仍有使用。今天介绍的Web Service曾经也是后浪，带着一统接入层网关协议、一统RPC江湖的双重期望傲然出世，然而时至今日却也几乎无人谈起，实在令人唏嘘。

Web Services，一词有广义和狭义之分。狭义而言，其表示一种特定的，基于SOAP协议Web服务技术（SOAP Web Services）。广义而言，泛指各种类型的Web服务，而不特指其实现方式，不仅包含SOAP Web Service，也包括Restful的API（被称作 Restful Web Services）。当然了，Web Services（以下简称WS）这个词用的最多的就是其狭义的含义，而本文也基于此。

1WS与SOA、RPC

从思想上看，WS属于SOA组件模型的一种具体实现。SOA即 Service-Oriented Architecture（面向服务的架构），并非一种具体而言的技术体系，而是一种服务化架构设计的思想。其实现形式多种多样（WS只是接入层SOA的一种实现），现已广泛应用于各大企业的后台之中。

从用法上看，WS是一种RPC技术。RPC即 Remote Procedure Call（远程过程调用），简单而言RPC可以概况为：“就像调用本地的类和函数（方法）一样，来调用远程的类以及函数（方法）”。虽然其内部仍旧是通过TCP或HTTP来通信的，但是其通信过程对于程序员来说是透明的。程序员无需关系其具体的通信细节，只需要向执行普通的类和函数一样去执行就可以了。另一种著名的RPC实现是RMI，只不过RMI的服务端和客户端都限制为Java语言实现，而WS则不限语言。

2WS三剑客

WS技术体系包含三大组成部分：SOAP、WSDL、UDDI。

2.1SOAP

看名字SOAP和上文的SOA很像，但其意却大相径庭。SOAP全称 Simple Object Access Protocol（简单对象访问协议）。其本质是描述了在一个RPC过程中对象传递的规范（谷歌Protocol Buffers也是基于同样目的）。

具体而言SOAP协议只描述两部分内容：一是介质，二是格式。格式就是一种特定的XML格式，而介质即承载该格式的网络协议，可以是HTTP/HTTPS、TCP、UDP、SMTP甚至JMS。当然最流行的就是基于HTTP的了。基于HTTP的SOAP，其Content-Type为 application/soap+xml。

SOAP是一种特殊的XML格式，它主要包含两个元素：Envelope 和 Body。包含soap:Envelope和soap:Body的XML才是合法的SOAP格式。另外还有两个可选元素：Header 和 Fault。Body元素中包含了向服务端请问的函数名，参数等信息。

请求示例：

<?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.w3schools.com/prices">
    <m:Item>Apples</m:Item>
  </m:GetPrice>
</soap:Body>

</soap:Envelope>

如上述实例所示，请求的函数为GetPrice，函数参数名Item，参数值为Apple。

完整的请求响应实例:

<?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.w3schools.com/prices">
    <m:Price>1.90</m:Price>
  </m:GetPriceResponse>
</soap:Body>

</soap:Envelope>

上面的请求和返回的示例来源于网络，感谢：

https://www.runoob.com/soap/soap-body.html

2.2WSDL

由于客户端编码接入WS还是过于繁复，所以SOAP WS体系的一大组成部分就是 WSDL（Web Services Description Language）。WSDL是一种IDL（接口描述语言）。服务端通过UDDI发布WSDL文件，客户端通过WS编译工具（比如wsimport）编译WSDL，得到stub代码（桩代码：客户端代码接入WS的大体框架，程序员只需要编写逻辑）。

WSDL其格式也是一种定制XML。其主要功能就是描述了函数（方法）接口。这样利用编译工具即可编译出服务端函数的stub，然后客户端就像调用本地函数那样调用服务端的WS函数啦。wsdl格式非三言两语说清，详细描述也脱离本系列文章形而上的宗旨。大家自行谷歌，或者参考阅读如下实例，天气服务wsdl：

http://www.webxml.com.cn/WebServices/WeatherWS.asmx?wsdl

复制URL到浏览器打开，可以看到XML。

wsimport是JDK自带的工具，可以编译本地或互联网（通过URL）上的WSDL。另外CXF包含一个wsdl2java的工具，和wsimport类似。

注解：

IDL一词出自CORBA，但是后来其含义已范化。
CXF是Apache基金会针对Java WS的一个工具包（库）。丰富了Java WS的功能。

2.3UDDI

分布式系统中必不可少却又常常为人所忽略的一个服务是：命名服务。笔者个人认为当今互联网最成功的命名服务莫过于DNS和URL了。大型企业内部网络也建有拥有各自系统特色的命名服务。SOAP WS要实现制霸的梦想，理所应当的发明了自己的命名服务：UDDI。

UDDI：通用描述发现和集成 (Universal Description, Discovery, and Integration)

ws服务端开发完成之后需要向UDDI注册，并发布，这一过程中每个WS会或者一个UUID。发布之后其他人才可见。而接入WS的客户端程序，也需要通过UDDI注册中心的分发路由到相应的WS，然后将响应返回给客户端。当然其实际过程比我文字概括的要复杂的多，请见下图：

图片来源于网络

3重整山河待后生

其实通过对WS是三大组件的介绍，可以发现WS与之前的CORBA技术有很多相似之处。同样是一种RPC，传递对象，并且使用IDL（接口定义语言，WSDL之于WS）生成stub桩代码。

在上个世纪90年代，随着RPC概念的兴起，CORBA技术逐渐走入人们的视野，这是OMG组织发布的一个雄心勃勃的标准。但历史总是相似，就像学术界的ISO/OSI七层参考模型一样，最终被工业界的TCP/IP取代。CORBA也由于种种原因，在推广后呈现出种种的水土不服。后来以微软、IBM为首的公司开始力推WS，由于各位大佬的加持，WS曾红极一时。

但WS也并非完全没有问题，各家厂商之间的标准并非完全一致，真正达到完美跨语言的RPC还是过于乐观。另外WS使用过程（接入以及发布等）中的复杂度让许多人望而却步。尽管WS出发点是让程序员从异构系统的跨网络通信过程中解放出来，专注于业务逻辑。但是为实现这一目标却又引入了另一维度的复杂度。

进入新世纪，网络规模日益扩大。各类公共的服务接口层出不穷，看似是WS技术最为拿手的场景。但最终人们开始回归初心，从新出发。不再纠结RPC，不再自制目录服务。利用已有的HTTP和URL，借着JS与Ajax的春风，API技术逐渐成为公认的Web服务接口的实现方式。WS在Web接入层的网关协议争夺战中宣告失败。

而在另一方面，WS还可以用于企业内部各个服务直接的通信。但随着各类互联网大厂陆续对外开源RPC解决方案（比如阿里dubbo，Facebook的Thrift，谷歌grpc等），全新的RPC时代来临，迎来爆发，WS于此也已没有用武之地。单就其序列化协议SOAP而言，和谷歌开源的protobuf也有明显差距。所以如今已很少看到WS的身影了。题外话，WS在两千年前后有两个坚定的支持者、推动者。一个是微软，另外一个是IBM。站在今天回看，这两个曾经的IT巨人在互联网时代确实落寞，在开源世界中也远不如互联网巨头有影响力。

未来技术如何更迭尚未可知，但在抚今追昔，寻觅技术发展轨迹的过程中可以发现，没有任何一种技术能长盛不衰，而一门过时的技术也可能重新被炒起冷饭。

长江后浪推前浪，重整山河待后生。