我认为,下一代互联网软件将建立在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简介
由两部分组成
·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 难以实现的服务。
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