什么是Web service?

你可能早就听说过Web service了，你也可能已经对Web service有一些概念了。一时间，好像所有的计算机期刊、书籍和网站都开始提及Web service。然而，当前大多数对Web service的介绍都没能清楚的说明Web service到底是什么。他们只是鼓吹Web service是多么多么的好，简直就像是在做广告。在本文中会讲清楚两件事：Web service到底是什么；在什么情况下你应该使用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
返回的数据就应该是这样：
21,晴
这个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的代码。

Web Service 是一种新的web应用程序分支，他们是自包含、自描述、模块化的应用，可以发布、定位、通过web调用。Web Service可以执行从简单的请求到复杂商务处理的任何功能。一旦部署以后，其他Web Service应用程序可以发现并调用它部署的服务。
Web Service是一种应用程序，它可以使用标准的互联网协议，像超文本传输协议(HTTP)和XML，将功能纲领性地体现在互联网和企业内部网上。可将Web服务视作Web上的组件编程。
1 历史
web广泛用到的技术：
◆TCP/IP：通用网络协议，被各种设备使用
◆HTML：通用用户界面，可以使用HTML标签显示数据
◆Java：写一次可以在任何地方运行的通用编程语言
◆XML ：通用数据表达语言，在web上传送机构化数据的容易方法
他们的特点是其开放性，跨平台性，开放性正是Web services的基础。
2 Web发展的趋势
内容更动态化
◆带宽Bandwidth更便宜，易于获得
◆存储器Storage更便宜，更易获得
◆普遍式计算变得更加重要：大量的设备，例如移动电话，页面，电脑，pc，已经在Internet上变得普遍，平台变得更多元化，象XML这样的跨平台技术变得更重要
3 Web Services扮演什么角色？
上述的这些趋势意味着，更加智能的处理，操作和汇总内容变得十分重要。让我们看看按照Web services角度所预示的四个趋势：
◆内容更加动态：一个web service必须能合并从多个不同源来的内容，可以包括股票，天气，新闻等，在传统环境中的内容，如存货水平，购物订单或者目录信息等，都从后端系统而来
◆带宽更加便宜：web services可以分发各种类型的内容（音频，视频流等）
◆存储更便宜: web services必须能聪明地处理大量数据，意味着要使用数据库，LDAP目录，缓冲，和负载平衡软件等技术保持可扩展能力
◆普遍式计算更重要：web services不能要求客户使用某一版本的windows的传统浏览器，必须支持各种设备，平台，浏览器类型，各种内容类型。
4 两种重要技术
要达到这样的目标，Web services要使用两种技术：
◆XML XML是在web上传送结构化数据的伟大方式，Web services要以一种可靠的自动的方式操作数据，HTML不会满足要求，而XML可以使web services十分方便的处理数据，它的内容与表示的分离十分理想
◆SOAP SOAP使用XML消息调用远程方法，这样web services可以通过HTTP协议的post和get方法与远程机器交互，而且，SOAP更加健壮和灵活易用。
其他象UDDI和WSDL技术与XML和SOAP技术紧密结合用于服务发现。

从前，分布式的应用程序逻辑需要使用分布式的对象模型，诸如：微软的分布式组件对象模型(DCOM)、对象管理集团的公用对象请求代理程序体系结构(CORBA)或Sun的远程方法调用(RMI)。通过使用这种基本结构，开发人员仍可拥有使用本地模型所提供的丰富资源和精确性，并可将服务置于远程系统中。
当我已经有了我中意的中间件平台（RMI, Jini, CORBA, DCOM 等等)时，为什么还要为Web而烦恼呢？中间件确实提供了强大的服务实现手段，但是，这些系统有一个共同的缺陷，那就是它们无法扩展到互联网上：它们要求服务客户端与系统提供的服务本身之间必须进行紧密耦合，即要求一个同类基本结构。这样的系统往往十分脆弱：如果一端的执行机制发生变化，那么另一端便会崩溃。例如，如果服务器应用程序的接口发生更改，那么客户端便会崩溃。
要求提供紧密耦合的基本结构，无可厚非，许多应用程序均是基于这种系统构建而成的。但是，当各个公司需要相互合作、或信息技术提供商扩大业务范围时，便很难实现单一而统一的基本结构。您根本无法保证您希望与之进行远程通信的管道的另一端，具备所有您需要的基本结构：对于它使用的操作系统、对象模型或编程语言，您可能一无所知。
相反，Web服务彼此是松散偶合的。连接中的任何一方均可更改执行机制，却不影响应用程序的正常运行。从技术角度讲，人们已转向使用一种基于消息的异步技术来实现高可靠性的系统性能，通过使用诸如HTTP、简单邮件传输协议(SMTP)以及至为重要的XML来实现统一的连接。
Web作为信息发布者的力量就在于简单且无处不在，这对解决现在这样一个分裂中间件世界很重要。Web通过在传统中间件平台上更有效实现的Services，来提供一个统一且广泛适用的接口，这样就改善了这个平台。
从一个N层应用程序结构的角度来看，web service只是一个方便程序访问的包装，服务还是要靠中间件来实现。访问包括服务请求处理（监听者）和一个支持商业逻辑操作的接口，商业逻辑本身是由传统的中间件平台实现的。
从理论上讲，开发人员可通过调用Web应用编程接口(API)（就像调用本地服务一样），将Web服务集成到应用程序中，不同的是Web API调用可通过互联网发送给位于远程系统中的某一服务。例如，Microsoft Passport服务使得开发人员能够对某应用程序进行验证。通过Passport服务编程，开发人员可以充分利用Passport的基本结构，通过运行Passport来维护用户数据库，以确保它的正常运行、定期备份等等。
消息传递系统将通信的基本单元打包成自我描述型的数据包（又称作消息），并将其放到网络缆线中。消息传递系统与分布式对象系统之间的本质区别在于：要求发送方辨识接收方的基本结构的程度有所不同。在分布式系统中，发送方需对接收方的情况作出种种猜测：应用程序是如何激活或拆包的，调用的是什么样的界面，等等。
另一方面，消息传递系统会在缆线格式级上创建合同。发送方既不需考虑消息被接收后的情况，也不需考虑接发双方之间的通信情况，唯一需要考虑的是接收方是否能辩识发送的消息内容。
在缆线格式级上创建合同的优势不言而喻。例如，接收方可在任何时刻进行更改，而不会干扰发送方的消息发送，只要它仍可辩识原有消息的内容。另外，发送方无需任何特殊的软件即可与接收方通信：只要它发出正确格式的消息，接收方就可以响应。

1 总括
服务被服务提供者service providers部署deploy到web上，由一个给定的web service提供的功能使用WSDL描述。
部署的服务被发布publish到web上，服务代理service broker帮助服务提供者和服务请求者service requestor互相发现。
一个服务请求者使用一个API向服务代理请求需要的服务，当服务代理返回结果后，服务请求者使用这些结果绑定bind到一个实际的服务上。
这里讨论的所有通讯可以使用任何协议，但为了简单，选择SOAPVersion 2.0 协议，它允许应用程序调用远程对象的方法。
2 Web Services 组件
有三种组件：
   ◆服务提供者：提供服务，进行注册以使服务可用
   ◆服务代理：服务交换所，服务提供者和服务请求者之间的媒介
   ◆服务请求者：向服务代理请求服务，调用这些服务创建应用程序
3 Web Services操作
三种操作：
   ◆发布/不发布（Publish/Unpublish）：提供者向代理发布（注册）服务或不发布（移去）这些服务的注册
   ◆发现（Find）：由服务请求者向服务代理执行find操作，服务请求者描述要找的服务，服务代理分发匹配的结果
   ◆绑定（Bind）：在服务请求者和服务提供者之间绑定，这两部分协商以使请求者可以访问和调用提供者的服务
4 UDDI － 通用发现，描述和整合
这是一个Web services的信息注册的规范，基于UDDI的web services注册可以被发现。UDDI的发现方法是：在web上有一种分布的注册服务，商务和服务以一种通用的XML格式描述，XML中的结构化数据易于发现，分析和操作。
5 WSDL － Web 服务描述语言
如果我们打算找出一个地方的所有web services，我们需要一种描述他们的通用语言。如果我提供了一种服务，我需要能够向外部世界描述它，同时如果我想要使用一种服务，我也要描述我要找什么，WSDL正是这个目的。
下面是一个描述一个web services的WSDL文档：
<binding name="StockQuoteServiceBinding" type="StockQuoteServiceType">
  <soap:binding style="rpc" transport="http://schemas.xmlsoap.org/soap/http"/>
  <operation name="getQuote">
    <soap:operation soapAction="http://www.getquote.com/GetQuote"/>
    <input>
      <soap:body type="InMessageRequest"
     namespace="urn:live-stock-quotes"
    encoding="http://schemas.xmlsoap.org/soap/encoding/"/>
    </input>
    <output>
      <soap:body type="OutMessageResponse"
     encoding="http://schemas.xmlsoap.org/soap/encoding/"/>
    </output>
  </operation>
</binding>
这是一个股票报价服务的定义的一部分，它定义了一个叫做getQuote的方法，同时带有相关的SOAP信息，以使一段代码可以发现这种服务，调用一个方法，且处理响应。
6 总结
结合这些技术，我们就有了使web services工作的基础结构。服务提供者可以描述自己，服务请求者可以描述自己要找什么，服务代理可以自动决定哪个请求者－提供者对是一个好的匹配，一旦产生了一个匹配，就可以使用必要的绑定信息用标准的方法（ways）找到与这种服务交互的方法（methods）。

那么什么是web service 平台呢？最基本的平台是XML加HTTP。HTTP是一个在Internet上广泛使用的协议。XML是一种元语言，你可以用它书写特定的语言来描述客户和服务之间或者组件和复杂服务之间的交互。在web server之后，XML格式的消息被转变成中间件的请求，返回的结果也会转化成XML格式。
有必要增加一些服务，同时保持简单性和普遍性，来把Web构建成一个功能更强大的平台。可以认为功能全面的web services平台是XML＋HTTP＋SOAP＋WSDL＋UDDI。在更高层次上，可能还要加上一些尚未广泛接受的技术如XAML,XLANG, XKMS,和XFS。
以下是对这些平台要素的简要描述。需要指出的是，这些还是发展中的技术，很多时候对一个问题会有多种解决方案。
◆SOAP (Simple Object Access Protocol，远程调用)
◆UDDI (Universal Description, Discovery and Integration Service贸易，目录服务)
◆WSDL (描述服务特征)
◆XLANG/XAML (为包括多种web services的复杂web事务提供支持）
◆XKMS (XML Key Management Specification) - 支持认证和注册，这个工作还在进展之中
SOAP
SOAP是用在分散或分布的环境中交换信息的简单的协议，它是一个基于XML的协议，定义了传递XML-encoded数据时的统一方式。包括三个部分：封装定义了一个描述消息中包含什么内容以及如何处理它们的框架，编码规则用于表示应用程序定义的数据类型的实例，另外还有一个表示远程过程调用和应答的协定。SOAP被设计为可以与各种其它协议结合使用。
SOAP的兴起是基于这样一种认识，无论现在的中间件是如何的好，他们都需要一个WAN包装。以XML格式发送消息有很多好处，如能够确保互用性。中间件使用者看来愿意容忍解析和序列化XML文档的代价，因为这可以让他们的软件使用范围更宽。
IBM, Microsoft, UserLand,和DevelopMentor在2000年向W3C提交了SOAP，并成为W3C的Note，SOAP更长远的发展规划现在是由W3C的XML协议工作组来制定。这有力的表明了直到W3C工作组交付规范为止，SOAP都将是一个稳定的规范。
UDDI (Universal Description, Discovery and Integration Service)
UDDI为客户提供了动态查找其它Web Services的机制。使用UDDI接口，商务处理可以动态的连接到外部的商务合作者提供的服务上。一个UDDI注册类似于CORBA的trader，也可以把它想象成商业应用程序的DNS服务。一个UDDI注册有两种客户：要发布一个服务（和使用接口）的商务应用，以及想要得到特定服务的客户。UDDI层在SOAP层之上，并假定请求和应答都是以SOAP消息传送的UDDI对象。
WSDL ：Web服务定义语言
Web服务描述语言(WSDL)是一种XML语法，为服务提供者提供了描述构建在不同协议或编码方式之上的Web Service请求基本格式的方法。WSDL用来描述一个Web Service能做什么，它的位置在哪里，如何调用它等等。在假定以SOAP/HTTP/MIME 作为远程对象调用机制的情况下，WSDL会发挥最大作用。UDDI注册描述了Web Service的绝大多数方面，包括服务的绑定细节。WSDL可以看作是UDDI服务描述的子集。
WSDL将服务定义为一个网络端点的集合，或者说端口的集合。在WSDL里面，端点及消息的抽象定义与它们具体的网络实现和数据格式绑定是分离的。这样就可以重用这些抽象定义：消息，需要交换的数据的抽象描述；端口类型，操作的抽象集合。针对一个特定端口类型的具体协议和数据格式规范构成一个可重用的绑定。一个端口定义成网络地址和可重用的绑定的联接，端口的集合定义为服务。因此一个WSDL文档在定义网络服务的时候使用如下的元素：
类型-- 使用某种的类型系统（比如XSD）定义数据类型的容器
消息-- 通讯数据抽象的有类型的定义
操作-- 服务支持的动作的抽象描述
端口类型-- 一个操作的抽象集合，该操作由一个或多个端点支持
绑定-- 针对一个特定端口类型的具体的协议规范和数据格式规范
端口-- 一个单一的端点，定义成一个绑定和一个网络地址的联接
服务-- 相关的端点的集合
所以，可以这样说，WSDL给客户提供了一个模板，方便他们描述和绑定服务。
XLANG
数据库中的事务的传统概念是原子性，即要么不做，要么全做。在分布式的系统中维持这种原子性，一般采用一种代价昂贵的处理方式，即两相承诺。另一个相对优化的模型也在研究之中（最初叫做sagas，由Hector Garcia-Molina提出），即每个动作都有一个明确的互补动作，用以取消该动作产生的结果。在现实生活中，这种互补动作的例子很多，比如说，你在信用卡里取出$52，互补动作就是存入$52，你发出一封Email说“你将会在7天内拿到你预定的产品”，互补动作就是发Email说“哦，你还得多等几天”。XLang就是基于这样一个概念，用来表示任何要取消的请求的互补动作。而Web Service的分布式基础将推动XLang规范的发展，使之能完成复杂的撤销操作。
XKMS (XML Key Management Specification)
XKMS是Microsoft和Verisign用XML应用程序集成PKI和数字认证（用于Internet事务安全性）的成果。关键的思想是将签名处理放到Web上的可信服务器（trust server）上，这样小客户就不必自己来做这些内容。XKMS依赖于XML数字签名规范和正在制定中的XML加密规范。现在的XKMS规范依赖于XML，SOAP，WSDL。

评论

1 楼 helloqidi 2010-08-23  

忒长了吧，能否简练点，呵呵