Web Services，一词有广义和狭义之分。狭义而言，其表示一种特定的，基于SOAP协议Web服务技术（SOAP Web Services）。广义而言，泛指各种类型的Web服务，而不特指其实现方式，不仅包含SOAP Web Service，也包括Restful的API（被称作 Restful Web Services）。当然了，Web Services（以下简称WS）这个词用的最多的就是其狭义的含义，而本文也基于此。
1. WS 与 SOA、RPC
从思想上看，WS属于SOA组件模型的一种具体实现。SOA即 Service-Oriented Architecture（面向服务的架构），并非一种具体而言的技术体系，而是一种服务化架构设计的思想。其实现形式多种多样（WS只是接入层SOA的一种实现），现已广泛应用于各大企业的后台之中。
从用法上看，WS是一种RPC技术。RPC即 Remote Procedure Call（远程过程调用），简单而言RPC可以概况为：“就像调用本地的类和函数（方法）一样，来调用远程的类以及函数（方法）”。虽然其内部仍旧是通过TCP或HTTP来通信的，但是其通信过程对于程序员来说是透明的。程序员无需关系其具体的通信细节，只需要向执行普通的类和函数一样去执行就可以了。另一种著名的RPC实现是RMI，只不过RMI的服务端和客户端都限制为Java语言实现，而WS则不限语言。
2. 三剑客
WS技术体系包含三大组成部分：SOAP、WSDL、UDDI。
2.1 SOAP
看名字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。
（本系列文章将WS一文放置到【接入层】部分，正是由于SOAP WS主要是基于HTTP的，而基于其他介质的SOAP WS，并不一定处于接入层！）
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>Apple</m:Item>
</m:GetPrice>
</soap:Body>
</soap:Envelope>如上述实例所示，请求的函数为GetPrice，函数参数名Item，参数值为Apple。
完整的请求响应实例，请参照：SOAP Body
2.2 WSDL
由于客户端编码接入WS还是过于繁复，所以SOAP WS体系的一大组成部分就是 WSDL（Web Services Description Language）。WSDL是一种IDL（接口描述语言）。服务端通过UDDI发布WSDL文件，客户端通过WS编译工具（比如wsimport）编译WSDL，得到stub代码（桩代码：客户端代码接入WS的大体框架，程序员只需要编写逻辑）。
WSDL其格式也是一种定制XML。其主要功能就是描述了函数（方法）接口。这样利用编译工具即可编译出服务端函数的stub，然后客户端就像调用本地函数那样调用服务端的WS函数啦。wsdl格式非三言两语说清，详细描述也脱离本系列文章形而上的宗旨。大家自行谷歌，或者参考阅读如下实例，天气服务wsdl：
webxml.com.cn/WebServic
wsimport是JDK自带的工具，可以编译本地或互联网（通过URL）上的WSDL。另外CXF包含一个wsdl2java的工具，和wsimport类似。
注解：
- IDL一词出自CORBA，但是后来其含义已范化。
- CXF是Apache基金会针对Java WS的一个工具包（库）。丰富了Java WS的功能。
2.3 UDDI
分布式系统中必不可少却又常常为人所忽略的一个服务是：命名服务。笔者个人认为当今互联网最成功的命名服务莫过于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服务接口的实现方式。
未来技术如何更迭尚未可知，但在抚今追昔，寻觅技术发展轨迹的过程中可以发现，没有任何一种技术能长盛不衰，而一门过时的技术也可能重新被炒起冷饭。
长江后浪推前浪，重整山河待后生。
