加入收藏 | 设为首页 | 会员中心 | 我要投稿 李大同 (https://www.lidatong.com.cn/)- 科技、建站、经验、云计算、5G、大数据,站长网!
当前位置: 首页 > 综合聚焦 > 服务器 > 安全 > 正文

WebService 概念入门

发布时间:2020-12-17 00:03:00 所属栏目:安全 来源:网络整理
导读:Web service是什么? 我认为,下一代互联网软件将建立在Web service(也就是"云")的基础上。 我把学习笔记和学习心得,放到网志上,欢迎指正。 今天先写一个最基本的问题,Web service到底是什么? 一、Web service的概念 想要理解Web service,必须先理解

Web service是什么?


我认为,下一代互联网软件将建立在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等
文件 的生成通常是利用厂商提供的工具来完成
3.SOAP



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


分布式应用程序和浏览器   研究一下当前的应用程序开发,你会发现一个绝对的倾向:人们开始偏爱基于浏览器的瘦客户应用程序。这当然不是因为瘦客户能够提供更好的用户界面,而是因为它能够避免花在桌面应用程序发布上的高成本。发布桌面应用程序成本很高,一半是因为应用程序安装和配置的问题,另一半是因为客户和服务器之间通信的问题。   传统的Windows富客户应用程序使用DCOM来与服务器进行通信和调用远程对象。配置好DCOM使其在一个大型的网络中正常工作将是一个极富挑战性的工作,同时也是许多IT工程师的噩梦。事实上,许多IT工程师宁愿忍受浏览器所带来的功能限制,也不愿在局域网上去运行一个DCOM。在我看来,结果就是一个发布容易,但开发难度大而且用户界面极其受限的应用程序。极端的说,就是你花了更多的资金和时间,却开发出从用户看来功能更弱的应用程序。不信?问问你的会计师对新的基于浏览器的会计软件有什么想法:绝大多数商用程序用户希望使用更加友好的Windows用户界面。   关于客户端与服务器的通信问题,一个完美的解决方法是使用HTTP协议来通信。这是因为任何运行Web浏览器的机器都在使用HTTP协议。同时,当前许多防火墙也配置为只允许HTTP连接。   许多商用程序还面临另一个问题,那就是与其他程序的互操作性。如果所有的应用程序都是使用COM或.NET语言写的,并且都运行在Windows平台上,那就天下太平了。然而,事实上大多数商业数据仍然在大型主机上以非关系文件(VSAM)的形式存放,并由COBOL语言编写的大型机程序访问。而且,目前还有很多商用程序继续在使用C++、Java、Visual Basic和其他各种各样的语言编写。现在,除了最简单的程序之外,所有的应用程序都需要与运行在其他异构平台上的应用程序集成并进行数据交换。这样的任务通常都是由特殊的方法,如文件传输和分析,消息队列,还有仅适用于某些情况的的API,如IBM的"高级程序到程序交流(APPC)"等来完成的。在以前,没有一个应用程序通信标准,是独立于平台、组建模型和编程语言的。只有通过Web Service,客户端和服务器才能够自由的用HTTP进行通信,不论两个程序的平台和编程语言是什么。   什么是Web Service   对这个问题,我们至少有两种答案。从表面上看,Web Service 就是一个应用程序,它向外界暴露出一个能够通过Web进行调用的API。这就是说,你能够用编程的方法通过Web来调用这个应用程序。我们把调用这个Web Service 的应用程序叫做客户。例如,你想创建一个Web Service ,它的作用是返回当前的天气情况。那么你可已建立一个ASP页面,它接受邮政编码作为查询字符串,然后返回一个由逗号隔开的字符串,包含了当前的气温和天气。要调用这个ASP页面,客户端需要发送下面的这个HTTP GET请求:   http://host.company.com/weather.asp?zipcode=20171   返回的数据就应该是这样:   这个ASP页面就应该可以算作是Web Service 了。因为它基于HTTP GET请求,暴露出了一个可以通过Web调用的API。当然,Web Service 还有更多的东西。   下面是对Web Service 更精确的解释: Web Services是建立可互操作的分布式应用程序的新平台。作为一个Windows程序员,你可能已经用COM或DCOM建立过基于组件的分布式应用程序。COM是一个非常好的组件技术,但是我们也很容易举出COM并不能满足要求的情况。   Web Service平台是一套标准,它定义了应用程序如何在Web上实现互操作性。你可以用任何你喜欢的语言,在任何你喜欢的平台上写Web Service ,只要我们可以通过Web Service标准对这些服务进行查询和访问。   新平台   Web Service平台需要一套协议来实现分布式应用程序的创建。任何平台都有它的数据表示方法和类型系统。要实现互操作性,Web Service平台必须提供一套标准的类型系统,用于沟通不同平台、编程语言和组件模型中的不同类型系统。在传统的分布式系统中,基于界面(interface)的平台提供了一些方法来描述界面、方法和参数(译注:如COM和COBAR中的IDL语言)。同样的,Web Service平台也必须提供一种标准来描述Web Service,让客户可以得到足够的信息来调用这个Web Service。最后,我们还必须有一种方法来对这个Web Service进行远程调用。这种方法实际是一种远程过程调用协议(RPC)。为了达到互操作性,这种RPC协议还必须与平台和编程语言无关。下面几个小节就简要介绍了组成Web Service平台的这三个技术。   XML和XSD   可扩展的标记语言(XML)是Web Service平台中表示数据的基本格式。除了易于建立和易于分析外,XML主要的优点在于它既是平台无关的,又是厂商无关的。无关性是比技术优越性更重要的:软件厂商是不会选择一个由竞争对手所发明的技术的。   XML解决了数据表示的问题,但它没有定义一套标准的数据类型,更没有说怎么去扩展这套数据类型。例如,整形数到底代表什么?16位,32位,还是64位?这些细节对实现互操作性都是很重要的。W3C制定的XML Schema(XSD)就是专门解决这个问题的一套标准。它定义了一套标准的数据类型,并给出了一种语言来扩展这套数据类型。Web Service平台就是用XSD来作为其数据类型系统的。当你用某种语言(如VB.NET或C#)来构造一个Web Service时,为了符合Web Service标准,所有你使用的数据类型都必须被转换为XSD类型。你用的工具可能已经自动帮你完成了这个转换,但你很可能会根据你的需要修改一下转换过程。在第二章中,我们将深入XSD,学习怎样转换自定义的数据类型(例如类)到XSD的类型。   SOAP   Web Service建好以后,你或者其他人就会去调用它。简单对象访问协议(SOAP)提供了标准的RPC方法来调用Web Service。实际上,SOAP在这里有点用词不当:它意味着下面的Web Service是以对象的方式表示的,但事实并不一定如此:你完全可以把你的Web Service写成一系列的C函数,并仍然使用SOAP进行调用。SOAP规范定义了SOAP消息的格式,以及怎样通过HTTP协议来使用SOAP。SOAP也是基于XML和XSD的,XML是SOAP的数据编码方式。第三章我们会讨论SOAP,并结识SOAP消息的各种元素。   WSDL   你会怎样向别人介绍你的Web Service有什么功能,以及每个函数调用时的参数呢?你可能会自己写一套文档,你甚至可能会口头上告诉需要使用你的Web Service的人。这些非正式的方法至少都有一个严重的问题:当程序员坐到电脑前,想要使用你的Web Service的时候,他们的工具(如Visual Studio)无法给他们提供任何帮助,因为这些工具根本就不了解你的Web   service。解决方法是:用机器能阅读的方式提供一个正式的描述文档。Web Service描述语言(WSDL)就是这样一个基于XML的语言,用于描述Web Service及其函数、参数和返回值。因为是基于XML的,所以WSDL既是机器可阅读的,又是人可阅读的,这将是一个很大的好处。一些最新的开发工具既能根据你的Web Service生成WSDL文档,又能导入WSDL文档,生成调用相应Web Service的代码。

(编辑:李大同)

【声明】本站内容均来自网络,其相关言论仅代表作者个人观点,不代表本站立场。若无意侵犯到您的权利,请及时与联系站长删除相关内容!

    推荐文章
      热点阅读