我认为，下一代互联网软件将建立在Web service（也就是"云"）的基础上。
我把学习笔记和学习心得，放到网志上，欢迎指正。
今天先写一个最基本的问题，Web service到底是什么？
一、Web service的概念
想要理解Web service，必须先理解什么是Service（服务）。
传统上，我们把计算机后台程序（Daemon）提供的功能，称为"服务"（service）。比如，让一个杀毒软件在后台运行，它会自动监控系统，那么这种自动监控就是一个"服务"。通俗地说，"服务"就是计算机可以提供的某一种功能。
根据来源的不同，"服务"又可以分成两种：一种是"本地服务"（使用同一台机器提供的服务，不需要网络），另一种是"网络服务"（使用另一台计算机提供的服务，必须通过网络才能完成）。
举例来说，我现在有一批图片，需要把它们的大小缩小一半。那么，我们可以把"缩放图片"看成是一种服务。你可以使用"本地服务"，在自己计算机上用软件缩小图片，也可以使用"网络服务"，将图片上传到某个网站，让服务器替你缩小图片，完成后再通过网络送回给你。这就好比，一件事你可以自己做，也可以交给另一个人去做。肚子饿了，你可以自己做饭，也可以打电话去订一份比萨，让店家替你做好送上门。
"网络服务"（Web Service）的本质，就是通过网络调用其他网站的资源。
举例来说，去年我写过一个"四川大地震图片墙"，它能动态显示关于四川地震的最新图片。但是，所有的图片都不是储存在我的服务器上，而是来自flickr.com。我只是发出一个动态请求，要求flickr.com向我提供图片。这种情况下，flickr.com提供的就是一种Web service。如果我把图片都存放在本地服务器，不调用flickr.com，那么我就是在使用"本地服务"。
所以，Web service让你的网站可以使用其他网站的资源，比如在网页上显示天气、地图、twitter上的最新动态等等。
二、Web Service架构和云
如果一个软件的主要部分采用了"网络服务"，即它把存储或计算环节"外包"给其他网站了，那么我们就说这个软件属于Web Service架构。
Web Service架构的基本思想，就是尽量把非核心功能交给其他人去做，自己全力开发核心功能。比如，如果你要开发一个相册软件，完全可以使用Flickr的网络服务，把相片都储存到它上面，你只要全力做好相册本身就可以了。总体上看，凡是不属于你核心竞争力的功能，都应该把它"外包"出去。
最近很红的"云计算"（cloud computing）或者"云服务"（cloud services），实际上就是Web Service的同义词，不过更形象一些罢了。它们不说你把事情交给其他计算机去做，而说你把事情交给"云"去做。
三、本地服务的缺陷
"网络服务"是未来软件开发和使用的趋势，本地服务将用得越来越少，主要因为以下三个原因：
* 本地资源不足。很多数据和资料，本地得不到，只有向其他网站要。
* 成本因素。本地提供服务，往往是不经济的，使用专业网站的服务更便宜。这里面涉及硬件和人员两部分，即使你买得起硬件，专门找一个人管理系统，也是很麻烦的事。
* 可移植性差。如果你想把本机的服务，移植到其他机器上，往往很困难，尤其是在跨平台的情况下。
四、Web Service的优势
除了本地服务的缺点以外，Web Service还有以下的优越性：
* 平台无关。不管你使用什么平台，都可以使用Web service。
* 编程语言无关。只要遵守相关协议，就可以使用任意编程语言，向其他网站要求Web service。这大大增加了web service的适用性，降低了对程序员的要求。
* 对于Web service提供者来说，部署、升级和维护Web service都非常单纯，不需要考虑客户端兼容问题，而且一次性就能完成。
* 对于Web service使用者来说，可以轻易实现多种数据、多种服务的聚合（mashup），因此能够做出一些以前根本无法想像的事情。
五、Web service的发展趋势
根据我的观察，目前Web service有这样几种发展趋势。
* 在使用方式上，RPC和soap的使用在减少，Restful架构占到了主导地位。
* 在数据格式上，XML格式的使用在减少，json等轻量级格式的使用在增多。
* 在设计架构上，越来越多的第三方软件让用户在客户端（即浏览器），直接与云端对话，不再使用第三方的服务器进行中转或处理数据。
Web Service简介
1.定义
由两部分组成
·SOAP--Web Service之间的基本通信协议。
·
WSDL--Web Service描述语言，它定义了Web Service做什么，怎么做和查询的信息。
2.简单的Web Service实现
包含四个基本步骤
·创建Web Service的商业逻辑（通常是一些java类）
·将这些java类部署到一个SOAP
服务器
上
·生成客户访问代码
·部署客户应用
注意：WSDL等
文件
的生成通常是利用厂商提供的工具来完成
Soap 是 XML
Web Service
的通信协议。当把 SOAP 描述为一种通信协议时，多数人都会想到 DCOM 或 CORBA，并且会问“SOAP 如何激活对象？”或“SOAP 使用什么样的命名服务？”等问题。虽然 SOAP 实现方案可能会包含上述内容，但 SOAP 标准并未对其进行规定。SOAP 一种规范，用来定义消息的 XML 格式 - 这是规范中所必需的部分。包含在一对 SOAP 元素中的、结构正确的 XML 段就是 SOAP 消息。这是不是很简单？
SOAP 规范的其他部分介绍如何将程序数据表示为 XML，以及如何使用 SOAP 进行远程过程调用 (RPC)。这些可选的规范部分用于实现 RPC 形式的应用程序，其中客户端将发出一条 SOAP 消息（包含可调用函数，以及要传送到该函数的参数），然后服务器将返回包含函数执行结果的消息。目前，多数 SOAP 实现方案都支持 RPC 应用程序，这是因为习惯于开发 COM 或 CORBA 应用程序的编程人员熟悉 RPC 形式。SOAP 还支持文档形式的应用程序，在这类应用程序中，SOAP 消息只是 XML 文档的一个包装。文档形式的 SOAP 应用程序非常灵活，许多新的 XML Web Service 都利用这一特点来构建使用 RPC 难以实现的服务。
SOAP 规范的最后一个可选部分定义了包含 SOAP 消息的 HTTP 消息的样式。此 HTTP 绑定非常重要，因为几乎所有当前的 OS（以及许多以前的 OS）都支持 HTTP。HTTP 绑定虽然是可选的，但几乎所有 SOAP 实现方案都支持 HTTP 绑定，因为它是 SOAP 的唯一标准协议。由于这一原因，人们通常误认为 SOAP 必须使用 HTTP。其实，有些实现方案也支持 MSMQ、MQ 系列、SMTP 或 TCP/IP 传输，但由于 HTTP 非常普遍，几乎所有当前的 XML
Web Service
都使用它。由于 HTTP 是 Web 的核心协议，因此大多数组织的网络基础结构都支持 HTTP，并且员工已经了解了如何对其进行管理。如今，已经建立了用于 HTTP 的安全保护、监视和负载平衡的基础结构。
4.WSDL解析
WSDL描述语言一般包含三部分
·What部分--包括了type、message和portType元素
Type：定义了Web Service使用的数据结构（使用XML Schema定义）
Message：一个Message是SOAP的基本通信元素。每个Message可以有一个或多个Part，每个Part代表一个参数。
PortType：消息汇总为不同的操作并归入到一个被称为portType的实体中。一个portType代表一个接口（Web Service支 持的操作集合），每个Web Service可以有多个接口，它们都使用portType表示。每个操作又包含了input和 output部分。
·How部分--包含binding元素
binding元素将portType绑定到特定的通信协议上（如HTTP上的SOAP协议）
·Where部分--由service元素组成
它将portType,binding以及Web Service实际的位置（URI）放在一起描述
5.客户端
通常Web Service可以有三种类型的客户
·商业伙伴（Business Partner）--包括分发商，零售商以及大型消费者）
此类客户通过SOAP、WSDL、ebXML、uddi等XML技术与Web Service连接
·瘦客户--包括Web浏览器、PDA以及无线设备
该类客户通常经由轻量协议(如HTTP)与Web Service连接
·肥客户--包括Applet、各类应用以及现存
系统
通常使用重量级协议（如IIOP）连接Web Service
