构件网址提交

第Ⅰ部分基础知识第1章基于服务的计算第2章Web服务的基本标准第3章Web服务编程第4章企业架构第5章面向服务的计算:原则第1章基于服务的计算当我们浏览网页、填写表单或者在网上购物的时候,我们就在参与分布式计算,然而我们对这个分布式计算的其他组成部分一无所知.
Web服务很有趣,因为它们提供了一种构建和部署这种分布式计算的途径,通过这种途径,程序员、管理员和用户的工作效率可以大幅度提高.

大多数研究人员和从业人员一致认为,尽管今天的Web在很多方面是成功的,但这并不意味着Web无所不能,它还存在很多局限.
Web上的信息没有经过组织,它可能不准确、不一致,更糟糕的是甚至无法理解.
目前信息定位技术的准确率较低(包含一些无关的结果),并且不完善(会丢失一些相关的信息).
大部分信息都是静态的,并且Web站点一般都不会表现出结构性很强的程序化行为.
唯一的程序化行为发生在有表单被提交到运行于指定URL的一个脚本上时,但这些脚本只能提供固定的接口和行为,这无疑增加了构建和维护分布式应用程序的复杂程度.

本章将介绍导致Web服务浮出水面的几个关键原因.
它们指引着新的Web服务标准和技术陆续浮出水面,而且它们还为评价几种相互竞争的不同方法提供了基础.
1.
1关于Web的种种构想对于Web的未来,大部分似是而非的构想基于以下原则,其中许多原则已经改弦易辙.
Web已经无所不在,并将继续保持这种势头.
它没有一个核心的管理机构,而是由一些异构的、拥有自治能力的构件(component,也称组件)组成.
目前,这些构件还主要是普通的网页,但总体而言,它们会逐渐被程序取代.
换句话说,今天的Web同时提供着内容和服务,但随着时间的推移,Web将逐步侧重于提供后者(即服务).
由于组成Web的各种构件能够任意改动,所以今天的Web被称为是动态的.
然而从目前来看,Web还不是完全动态的,因为组成Web的各种构件只能在几个有限的方面进行交互:通常是Web页中的可见部分或者Cookie是否可以通过浏览器来设置和检索.
Web将开始支持协作性的对等(Peer-to-Peer,P2P,点对点)交互模式,与此同时,Web将继续支持客户端/服务器(C/S)交互模式.

1.
1.
1语义Web万维网之父蒂姆·伯纳斯-李(TimBerners-Lee)曾经描述了他对Web的构想,并把这个构想称为"语义Web"(SemanticWeb).
今天的Web已经过调整,适合人们使用.
换句话说,Web上的信息通常采用统一的标记来表示,然后通过不同的浏览器进行相应的显示.
人们通常能够理解信息的内容,因为他们与网页开发人员有同样的背景知识.
如果开发的程序不能表达和利用这些背景知识,它们就只能以硬编码方式进行处理,这显然不适用于细节不断变化的Web动态环境.

例如,我们可以写一个所谓的抓屏程序,程序可以自动地从amazon.
com的搜索结果页上提取出每本书的价格.
当然,程序的执行依赖于网页的语法(网页是按照某种形式文法编码而成的).
直觉告诉我们,程序应该通过某种适当的方式来解析查询结果页的内容,从而得到价格.
根据所指定Web站点上的网页结构的不同,这些程序指令可能会有很大的不同,例如可能会有这样的指令:从第5个框架(frame)第2个表格的第3行读取第7个单元格中的数值.
尽管使用现有的工具可以简化这个解析和读取过程,但编写程序对程序员来说仍然是痛苦的工作.
而且,一旦程序所读取的Web页在结构上发生变化,那么它将无法执行或者表现异常(尽管这些变化表面上看起来似乎毫不相关).

在语义Web中,网页不只是由显示方面的细节来标识的,它还包含了对内容含义的独立呈现.
也就是说,针对前面的例子,搜索结果页会告诉我们价格是多少.
即使网页布局已经发生变化,用于抽取价格的这个程序也会找到价格.
换而言之,网页标识已经从单纯的语法分析(只捕捉信息的结构)发展到语义分析(捕捉信息的含义).

1.
1.
2对等计算与我们主题相关的另一个重要的Web发展趋势是P2P计算.
今天的Web用于进行信息交互,在这些交互中,大部分信息存放在服务器端,而大量的智能则集中在客户端.
这种交互双方的不对称意味着信息趋向于集中在大型的服务器端,其后果是严重影响整个系统的功能.
如果服务器死机,整个系统都会受影响.
如果交互双方在交互过程中相互妥协,又会导致系统安全性受损.
P2P模式的关键思想在于不同构件之间是对等的.
每个构件都既作为服务器又作为客户端,正因如此,对等的几个构件有时又称为"服务客户端"(servent).

在P2P模式下,Web不是由等着被程序访问的被动网页组成,而是由能够相互通信的动态程序组成.
原则上讲,这种动态程序之间能够相互协商,并可以为彼此间的交互主动提供建议.
然而,目前的P2P方法还缺乏语义,这意味着应用程序间的交互必须以静态硬编码的方式实现,从而阻碍了应用程序之间进行灵活的协商.
因此,目前的P2P模式只能实现一些简单的应用(如文件共享),也只有在这些简单的应用中,人们才可以添加语义成分.

1.
1.
3流程与协议综上所述,尽管在Web上调用程序(如servlet)是可行的,但是如今的Web大体上还是静态和被动的.
然而,真正的挑战在于如何才能找到并正确地调用程序.
第一代服务方法解决了这个难题,它提供了一种手段,借助这种手段,可以指定程序的参数和输出,通常采用可扩展标记语言(eXtensibleMarkupLanguage,XML)来表示.
具体而言,这些标准提供了一种方法来定位人们所需要的服务,并且可以通过超文本传输协议(HypertextTransferProtocol,HTTP)在Web上调用这些服务,HTTP同样也是Web浏览器所使用的协议.
我们调用程序来执行一些业务流程,这些业务流程同时也在调用各方之间的高层交互.
相对于服务调用这种临时的两方交互而言,业务流程是典型的长期的多方交互.
除了查询天气或兑换货币这种比较小的例子,很多服务通常被用作一些较复杂的业务流程中的一部分.
鉴于此,"面向流程(process-oriented)的服务"这一观点应运而生.
业务流程建模标准正在逐步发展中,越来越接近于Web服务标准的扩展.

1.
1.
4语用Web将前面所讲的内容综合起来,就知道"语用Web"(PragmaticWeb)这个词的含义了.
在这里,"语用"的意思是,对于Web的理解要基于上下文环境中的业务流程.
我们会在本书其他部分对"语用"的其他含义进行具体的讲解.
因为本书是从Web服务如何用来建立大型、开放式的信息系统这一角度来描述Web服务技术的,因此应该讲一下萌芽中的语用Web.
语用Web为构件之间的协商整合了一套可行的技术,这是它的重要特征.
协商在现实生活中是很常见的.
然而,在今天的计算机应用程序中,大部分要协商的东西已经提前由人处理,只有那些最微不足道的协商才自动执行.
随着支持在线竞拍和物品交换的在线市场的出现,这一切都在发生着变化.
针对最优竞价的算法和策略并不是面向服务的计算(Service-OrientedComputing,SOC)的核心内容.
然而,成功地参与到协商中依靠三个要素:①对协商的内容进行语义建模;②作为一个对等体与其他各方进行交互;③作为实际业务流程的一部分执行长期的交互.
以上的几方面构成了本书的中心论题.
本书并不想解决各种应用程序中出现的协商问题,因为解决这些问题所需的技术依赖于应用程序本身.
但是,本书会介绍Web服务的一些概念和技术,而Web服务恰好是这些尚待解决的应用程序问题的解决方案中不可或缺的一部分.
在我们看来,Web将会变得对人和机器同样可用,而且会变得更加主动而不再是被动的.
以下内容总结了Web发展的几个主要趋势.
自动化.
人机器.
更丰富的标记.
HTML语言向XML语言的转变使得Web上的文档和数据结构的语法规范化.
然而,仅有XML语言,对于获取这些文档和数据结构的语义或真正的含义也还是不够的.
我们还需要更多的表述方法.
尽管这些表述方法也是用XML语言的语法给出的,但是它们处于一个与XML语言截然不同的层次上.

更丰富的活动.
被动主动;服务流程.
更强大的交互.
客户端/服务器模式(C/S模式)对等模式(P2P模式)协作模式.
容易适应的上下文环境.
语义互相理解语用.
以上列出的各种Web发展趋势将我们带到了大大超出当前理解的语义Web范围的境界,并且把语用加入了我们的视野.
因此,对这些趋势的一个最好的命名就是语用Web.
1.
2发展史让我们从分布式计算和信息建模的角度快速回顾一下信息技术的历史.
众所周知,计算技术已经从集中式系统发展到分时系统,再发展到客户端/服务器模式(C/S模式),乃至现在又发展到对等计算模式(P2P模式).

第一代信息系统以集中化处理的方式提供计算能力,这些集中式处理系统被一些自身并没有数据处理能力的简单终端控制和访问.
第二代信息系统被组织为服务器的形式.
这些服务器提供一些通用的信息处理、数据、文件和应用程序,与服务器交互的客户端则提供专用的信息处理、输入和输出.
第三代信息系统有了对等计算技术,它使一系列分布式处理器中的每一个节点既可以是"客户端",又可以是"服务器".
该过程也可能用到服务器.
初现端倪的下一代信息系统是协作性的.
在下一代信息系统中,可以通过具有自治性、主动性和异构性等特性的构件共同实现解决方案.
既成事实的是,正崭露头角的系统已经包括了协作机制的各个方面.
在这种协作机制中,构件本身不仅可以作为对等体相互处理,而且可以在更高层上相互理解.
在此,我们认为,"协作"这个词包括智能帮助(intelligenthelp)和智能竞争(intelligentcompetition)两方面的内容.
在计算技术发展的早期阶段,数据和应用程序无法分开,因而可维护性和可升级性较差.
利用数据库管理系统(DBMS),可以将数据与应用程序分离,使数据和应用程序独立存在而不依赖于对方.
人们希望数据可以被应用程序所使用而不是预先放在应用程序中(希望应用程序可以通过访问数据库来获得数据,而不是提前将其写在程序中).
通过诸多努力,人们已经可以让新的应用程序访问旧的数据,也可以把新的数据载入到旧的应用程序中,这从某种程度上实现了数据和应用程序相分离的愿望.
然而,从这个愿望的全景来看,它并没完全实现,这是因为,尽管基于结构化查询语言(SQL)访问关系型数据库的方法可以被标准化,但是这些数据的语义仍然是特定的而不是标准化的.
举例来说,数据库两个列中同样的词语"雇员"可能是同一个概念,也可能是不同的概念.

Internet也存在同样的问题.
在早期,应用程序和数据的格式是特定的,而不是标准化的.
HTML标准促成了浏览器的出现.
通过浏览器,人们可以随时随地访问网上的信息.
当有人直接参与理解和处理信息时,通过浏览器的方法很有效,但这样不能很好地实现自动化处理.
因此,Web的语义问题越来越受到重视自然在情理之中.

Web仅仅是这个异构化浪潮的冰山一角.
这里有一个有趣的二难推理:Web上的资源管理越分散,越独立,其潜在价值就越大,但提取其价值也变得越难.
由于Web服务可以应用于独立设计的系统,因此创建具有高价值的系统变得很容易,而且从这些系统中提取有价值的东西也比以前容易得多.
1.
3开放式环境在信息系统向着前述分布性、非耦合性、局部智能性以及协作性等趋势进一步发展的同时,Web也在发生类似的演化——从局域专用网发展到广域专用网,例如"企业外网"(extranet)和"虚拟专用网络"(VPN)向公用Internet的发展.
发展的结果就是信息系统的构件可以来自不同的组织,也就是说,信息系统是开放的.
"开放"隐含的意思是,信息系统中的构件是自治的、异构的,并且系统的配置可以动态地变化.

我们通常希望能够约束构件的设计和行为,因此也就限制了信息系统的开放性.
然而,信息系统还是不得不与开放的外界进行交互.
举例来说,一个公司可以开发一个企业集成系统,并且专门在企业内部使用.
然而,这个系统又不得不处理一些外部事务,例如,处理产品供应和产品链业务.
换句话说,其实系统仍然需要运行在一个开放式的环境中.
因此,以这种开放式环境作为思考问题的基础对我们大有裨益.
现在,我们来回顾一下开放信息系统的一些关键特征.

鉴于自治性、异构性和动态性与开放信息环境的关系,下面先回顾一下这些概念.
理解并区分这些概念的一个简单方法就是,把这些概念与用户、设计者和管理员的独立性分别联系起来.
1.
3.
1自治性自治性(autonomy)是指,在某个环境中构件可以在自身的控制下独立运行.
让我们设想一个经营电子商务网站的问题.
网站可能需要从它的商品目录上删除条目,也可能不需要.
网站甚至可能需要对它已经承诺过的商品提供送货服务,也可能不需要.
当然,在现实中,如果合同违约,人们应当寻求相关的法律资源来解决问题!
实际上,开放系统中的合同和协议之所以如此重要,就是因为构件的自治性.
我们将在本书的第15章和第18章再次讨论这些问题.

简而言之,软件构件之所以具有自治性,是因为它们反映出来的人们以及人们对Web表现出来的共同兴趣具有自治性.
换句话说,自治性的原因涉及社会政治性.
资源被自治的实体所拥有和掌控,这就是他们的行为具有自治性的原因了.

自治性也存在一些技术上的原因.
因为构件可能存在错误的需求或有缺陷的实现,也就可能作出出乎人们意料的行为,这是最简单的例子.
如果能处理好这些行为异常的构件,那我们的系统就是健壮的.
另一个更微妙的原因是,有时候构件的某些方面被设计成对外非透明的.
例如,一个封装良好的数据类型的实现能够对外隐藏它的内部结构,也正因为隐藏部分的存在,此数据类型的实例的行为就是不可控的.
让我们来考虑一个例子:以散列表方式实现的一个字典数据类型,这个字典数据类型支持将元素插入字典和复制字典中所有的元素这两种操作.
散列表的大小以及散列函数的形式是被隐藏起来的.
对一个使用此数据类型的程序员来说,如果他调用复制所有元素这个操作,那么复制的元素的排列顺序就表现出不可控性.
如果在复制元素的过程中散列表的大小由于空间和效率等某些内部原因而发生改变,那么复制的元素的排列顺序甚至也会随着一连串的调用而发生改变.

在实际中,这方面的主要例子经常出现在企业的遗留系统中.
在一个企业的遗留系统中,基于内部的考虑,数据库管理系统可能被设计为可以单方面决定是否允许一个事务完成.
而在其他构件看来,它们似乎可以完全自由决定一个事务是否可以完成.
另外,关于自治性的某些实例将有可能导致系统的错误.
举例来说,你正在向某个网站提交一个表格,可是在提交过程中此网站的文件系统出现了问题,那么你做出的更改就没被记录下来,这样从表面上看,就像是系统单方面丢弃了你提交的数据.

自治性带来的影响之一是更新只能发生在局部控制下.
换句话说,你可以请求其他参与者做某些事情,但是你不能强迫他们做.
这个简单的例子说明了面向对象计算的局限性.
我们可以调用对象中的方法,而且如果我们有某个对象的句柄,它的方法就会根据我们的调用来执行.
相比之下,对于开放环境而言,有另外一种同样合理的状况,即一个构件接收到运行某个方法的请求时,它可以决定是否接受这个请求.
相对于面向对象的计算而言,基于服务的计算的一个优点在于其更注重构件的自治性.

1.
3.
2异构性异构性指的是,同一个系统中的各种构件在设计和构造上是不同的.
就像自治性一样,异构性同样既涉及社会和政治的问题,又存在技术上的问题.
构件设计师和架构师可能希望用不同的方法来构造构件(为了满足不同的性能需求).
在很多情况下,异构性是历史问题造成的:今天存在的构件可能出自遗留系统,而这些遗留系统最初建立仅仅是为了一些小的应用,但是到了最后,它们都被扩展并且加入同一个系统中.

异构性问题可能出现在一个系统的各个方面(如网络协议、信息编码以及数据格式).
毫无疑问,为系统的每一层都实施标准化能够降低异构程度,并且可以通过提高构件之间协同工作的能力来提高生产率.
网际协议(IP)、超文本传输协议(HTTP)、通用字符集(UCS)、通用字符集转换规范(UTF-8)以及XML语言等标准能够得到广泛地应用,也是出于这个原因.
标准总是在发展变化之中,因此,不同软件构件的各个方面既有可能落后于标准,也有可能符合标准.
但是通常来说,建立并且遵循较低层的标准要更加容易.

异构性问题也会出现在语义层和应用层.
在这两层,异构性问题更加难以解决,甚至难以察觉.
例如,员工薪水计算系统和员工福利计算系统可能都要涉及员工.
然而,员工薪水计算系统通常把员工看成支付薪水的对象,而员工福利计算系统通常把员工看成领取保健福利的对象.
在某些情况下,各系统会正确地工作并且相互一致.
经理可以获得这两个系统总的信息并进行有意义的计算,得出他需要的一些数据(如每个员工每个月的平均费用).
但是,现实中的某些事件可能会使两个系统由于与生俱来的异构性而导致行为的差异.
考虑这样一个问题,Anne是某公司的一名员工,她既要领取薪水,又要领取保健福利.
有一天,她退休了,系统的问题随之而来.
如果公司在员工退休的第一年继续给他们提供保健福利,那么Anne就应该继续与员工福利计算系统保持关系,而与员工薪水计算系统脱离关系.
这样一来,合计的数据就不再具有任何意义.

异构性可能会造成构件运行时的复杂化,因为异构性意味着对其他构件的假设更少.
尽管如此,还是有极好的理由能够说明,异构性的出现和继续发展是有道理的.
而如果放弃异构性,将导致大量构件都需要被重新设计并且重新实现.
不同的构件设计者即便乐于承受随之而来的成本,也很难放弃异构性,因为这样做无异于承认我们有能力掌握概念上一体的设计.
然而,一体化既是困难的也是脆弱的.
这意味着,如果有人能创建出概念上一体的设计,那么这种设计往往是不可靠的.
更重要的是,这种系统将会是脆弱的,因为构件会根据本地环境的变化而演化,我们将不得不持续地重新集成这些构件.

因此,更实际的做法是让构件保持其异构性,而不是将许多种弱的需求强加于构件的交互中.
毕竟,这才是我们需要TCP/IP协议和HTTP协议等标准化协议的原因.
1.
3.
3动态性一个开放环境可以在两个主要方面展现其动态性.
首先,由于具有自治性,此开放环境中的参与者能够执行任意行为.
具体说来,这些参与者可以根据发生在自身构造上的改变而改变自身的行为.
其次,它们也可以一时心血来潮而加入或退出开放环境.
作为系统管理员独立性的一个反映,这一点值得分离出来.
为了适应系统中构件的添加、移除、临时性的空缺、更改以及替换等行为,一个大规模的开放式系统很有必要这样设计.

根据动态性的第一个方面,独立的构件可以动态地改变行为,动态地改变结构与实现,以及动态地改变交互.
也就是说,这些构件的外部可观测行为可能会发生变化(例如,构件如何完成行为或者发生行为,以及构件如何与其他构件进行交互).

1.
3.
4挑战开放的环境造成了很多技术上的更大挑战.
具体说来,我们必须找到某种方法,以便将系统参与者的数量控制在一定范围内,并且还要在遵守自治性并适应众多参与者的异构性的同时保持协调性.
在某些情况下,由于参与者范围不明,我们无法根据资源的功能性、可靠性和可信性等特性来了解所有可用的资源.
这就意味着发现所需的资源、决定如何使用资源、实际利用资源以及核查资源的灵活性等问题全都是巨大的挑战.

构件自治性和异构性的结果,就是构件必须以局部方式处理.
换句话说,每个构件必须独立决定如何与其他构件进行交互.
这将增加配置全局性信息的难度.
为了确保不同部分之间的平等,某些级别的全局性信息是必要的.
然而,全局性信息可能会使系统处于不一致的状态,并且会给系统的维护带来隐患.
尽管开放环境中的构件在实际运行中很可能经常互相依赖,但是只要采用正确的方法设计构件,便可以保持构件的自治性和异构性,从而消除构件之间相互依赖的问题.

对于保持构件自治性和异构性,有一个观点认为,这样的限制迫使我们去设计那些简单的或者狭隘的交互协议,这样构件之间不必要的依赖性才会消除.
对于保持构件动态性,有一个观点认为,如果按照假设的那样做,它将大大降低构建和管理系统的难度.
此外,动态性还使系统有能力避免失效,使系统更有能力抓住某些特定的机遇.
举例来说,如果某个构件失效,被设计成具有动态性的系统就会从容地处理这次失效,即系统可以轻而易举地用其他的构件来替代失效的构件.
同样,在实际使用中,如果出现更好的构件或更好的解决方案,动态系统就能够利用它们来代替原来的构件或解决方案,从而更好地达到业务目标.

此外,在实际运行中,动态系统常常可以恰当地放宽对构件的限制.
因此,只有当系统需要时,全局性的信息才会被收集和汇总.
更重要的是,只要能够尽快纠正不一致问题(当然要依靠手边特殊的软件),动态系统一般允许出现不一致的情况.
被纠正了的活动多数情况下具有全局性的基础,但是只能应用在局部.
例如,一次电子商务交易正确完成的必要条件是买主已经收到货物,并且卖主已经收到了支付的款项.
事实上,这些事件严格地同步几乎是不可能的,但是采用一种可靠的支付机制却是可能的(例如采用信用卡支付和可靠的送货服务).
如果某些意外导致卖方存货不足而不能送货,那么在这种支付机制下,应允许撤销计入买方信用卡借方账户的记录.
本书的5.
4.
2节会介绍一个更详细的例子.
总的来说,有很多好例子可以说明如何放宽约束,这些约束在计算机出现之前就已经在制约人们处理业务的方式了.
其中的某些例子可以很好地适应在线环境.

1.
4服务简介就像上一代的"对象"一样,"服务"是现在我们这个时代的头号强势词汇.
并且无论你走到哪里,都会看到厂商或分析家在推销服务.
在现代计算技术时代,服务就像是慈母观念与传统美德那样众所周知的常识.
但是与慈母观念不同的是,服务对不同的人有不同的意义.
Web服务的定义就有如下几种:可以通过开放标准的Internet访问的业务逻辑(微软公司).
通过Web上的标准协议提供的、封装的、松耦合的、按约定规约的软件功能(DestiCorp公司).
可以通过标准的Internet技术与其他构件进行交互的松耦合的软件构件(Gartner公司).
以URI标识的软件应用,软件的接口以及绑定可以被XML人为地定义、描述和发现,而且可以通过基于Internet的协议,使用基于XML的消息与其他软件应用进行交互(W3C).
尽管我们的重点是Web服务,但先回顾一下不同组织对服务的不同观点还是大有裨益的,这些不同的观点可以反映出这些组织的背景和关注点.
网络领域:服务可以由带宽、可用性、出错率以及诸如此类的性质来刻画.
长途通信领域:服务既被认为是来电显示或者呼叫转移之类的电话功能,也被认为是窄带、宽带(其本身又分为几种)这样的基础连接服务.
系统领域:服务就是计费、存储以及其他关键的操作功能.
这些功能经常与所谓的操作——支持系统捆绑在一起.
Web应用领域:服务就是相应的网页,特别是那些具有特定格式的网页,或者不仅有特定格式,还有编程接口的网页.
无线领域:在无线领域的Web应用方面,服务包括像公共短信息服务(SMS)那样的消息传输.
如果以上的观点有什么共同点的话,那就是,服务是一种能力,这种能力通常(但不总是)可以远程地提供与开发.
因此,我们对Web服务的定义是:一种可以在整个Web上"应用"的功能.
在后续章节中,我们将逐一解释这个"应用"的所有分支,不过,其本质在于这种"应用"已经超出了简单的调用.
不论怎样,上述的回答提供了一个试金石,我们可以通过这个试金石来判断人们期望的"服务"在分布式系统中到底扮演着何种角色.

1.
5使用服务服务提供了一种编程的构想,即支持为开放的分布式系统而构造的所有正确的编程模型.
采用模块化的服务架构,是因为每个服务都提供了一个特定的"提供者-订阅者"接口.
这个接口使提高灵活性成为可能(例如,允许代理以透明的方式来提供基于旧服务的新服务),允许代理恰当地进行服务组合.
一般对于工程软件而言,组合性是一种非常强大的特性,甚至可以认为是当前人们对服务的兴趣所在.

尽管服务必须被调用,但对它们的调用常常是隐式的.
例如,很多网络和电报服务就不是直接调用的,它们只是其他被调用的更为基础的服务的变体.
也就是说,你可能调用了一个用于传送数据包的服务,通过网络来传送一系列数据包;通过同样的编程接口并且依靠所提供的底层服务,你可能需要根据传送数据包的紧急程度的不同而得到不同的质量保证.
在电报中,服务的定义是根据效益进行规范的(因此是经济的).
例如,查找一个电话号码是一个单机的服务,但是进一步拨打出去就是电话业务中的一项功能了.
如果想知道其中的差异,请看美国联邦通信委员会(FCC)的逆向电话指导原则[FCC,1996].
网络专家可能对电报不那么感兴趣,但是相似的考虑(甚至是规范)应该开始应用于Web服务,这既因为其中包含了电话业务,又因为不断增长的Web服务在经济上的重要性吸引了立法者们的注意.
1.
6发展中的Web乍一看,Web无处不在,并且具有如此均一的可访问性,以至于起初Web容易被想象为一个巨型系统.
Web唯一的一个显著用途看上去是交换带标记的文档,Web唯一的特征看上去是那些文档之间的超链接.

然而,Web对于很多人来说实际意味着很多事情,尽管Web的很多应用都具有相似性,我们还是要很好地理解这些应用之间的差异,以便据此进行编程.
为此,我们需要学习一下由Sun公司首席科学家BillJoy所给出的关于Web的分类,这会对我们进一步理解Web大有裨益.
依据某终端用户对接口形态的经验,Joy将Web主要划分为如下四种[Joy,2000].
近程Web(NearWeb):传统的通过PC机的鼠标—键盘—显示器的交互,主要目的是网上冲浪.
远程Web(FarWeb):通过一台计算机进行跨越房间的交互(正如通过TV进行远程控制),主要用于娱乐(例如,听音乐或看电影).
随处Web(HereWeb):通过移动设备进行交互,用窄带进行输入和输出.
特殊Web:通过新式的接口技术进行交互(例如,语音和可穿戴的计算设备).
Joy定义了另外两种不直接与用户交互的Web.
一种是企业对企业(B2B)Web,这种Web处理的是B2B电子商务中的供应链问题.
另一种是弥漫Web(pervasiveWeb),这种Web处理的是设备与设备的交互.
下面根据发展历程列出Web服务的特征(如表1.
1所示),这对我们是很有帮助的.
表1.
1Web上的各种服务的发展历程代际范围技术示例第一代所有浏览器任意HTML网页第二代有规划的屏幕捕捉器系统地生成HTML内容第三代标准的Web服务形式描述的服务第四代语义的语义Web服务语义描述的服务系统地生成HTML内容是指数据驱动的Web站点,这种Web站点具有定义良好的可视结构.
amazon.
com这样的商业Web站点就是例子.
这些HTML内容是自动解析的,尽管解析所用的语法可能是特定的而且难以维护,同时这些内容的结构也不足以清楚地反映页面的可视结构.
形式描述的服务是通过当前的Web服务标准(将在第2章介绍)描述的.
目前,在实践中,这些形式描述的服务是主要提供商通过特殊的工具包发布出来的.
本章的练习1、练习2和练习3将要求你回顾三种这样的工具包.
而语义描述的服务超越了当前的Web服务,它明确地对服务的意义进行了描述.
1.
7标准化组织既然服务包含了不同实体的实现与不同系统之间密切的协同与交互,那么为几种关于服务的技术拟定标准就很自然了.
正如在多数计算机科学中的那样,服务的标准化通常是以"既定事实"的方式推动的,标准的建立依赖于它被大量提供商和用户所采纳的事实.
尽管如此,标准化组织还是发挥了重要的作用.
这些标准化组织一方面带头提出法律上的标准.
另一方面,它们也整理实践中不断涌现的标准并将其正式化,并且将规则的副本提供给市场.

下面是一些最著名的服务标准化组织和创始人.
本书将多次提到它们的特别贡献.
IETF(互联网工程任务组).
此组织负责互联网相关处理技术规范的研究和制定.
除了TCP/IP协议簇和URL之外,IETF组织也负责HTTP协议和其他有关服务的协议[例如,会话初始化协议(SIP)和SMTP协议].

OMG(对象管理组织).
此组织已经开发出许多关于建模/交互的标准,并发布了分布式对象系统的标准.
我们最熟悉的标准包括"统一建模语言"(UML)和"公用对象请求代理程序体系结构"(CORBA).
OMG最近还提出了模型驱动的架构(MDA).

W3C(万维网联盟).
该组织促进了Web处理技术标准的发展.
W3C大多数时候关注Web的表现层,遵循其他网络标准和其他相关计算标准(例如,事务处理标准).
W3C标准中与服务有关的主要标准包括XML语言、XMLSchema、WSDL、SOAP和WSCI等.
OASIS(结构化信息标准促进组织).
该组织标准化了一系列有关Web服务的协议和方法,包括通用业务语言(UBL)、UDDI及Web服务的业务流程执行语言(BPEL4WS),并与UN/CEFACT协作制定了ebXML标准.
UN/CEFACT(联合国贸易促进与电子商务中心).
该组织旨在通过对处理流程和信息流的简化和调谐来促进国际交易.
它的任务是改进发达或发展中经济体的商业、贸易和行政管理组织的能力,高效地交换产品和服务,并以此来对全球的商业增长作出贡献.
UN/CEFACT最重要的一项发展是对ebXML的规约,该语言是全球电子服务信息应用的一个框架.

WS-I(网络服务互操作性组织).
该组织是一个开放性的行业组织,旨在提升跨平台、跨操作系统、跨编程语言的Web服务的互操作性.
WS-I创建并且支持服务之间消息交换的通用协议.
其目前最主要的贡献是BasicProfile1.
0版(BP1.
0).
对于由SOAP1.
1、HTTP1.
1、XML1.
0、XMLSchemaParts1和2、UDDI版本2和WSDL1.
1组成的基本Web服务,BP1.
0做出了一致的规范.
BPMI.
org(业务流程管理国际组织).
该组织致力于对业务流程的管理进行标准化.
所谓的业务流程包括:组合应用、公司部门和商业伙伴.
微软公司提出了基于(演算的工作流建模语言XLANG.
IBM公司提出了基于Petri网的Web服务流语言(WSFL).
BPMI.
org把这两种方法用业务流程建模语言(BPML)统一起来.
在这点上,BPML1.
0和BPEL4WS有相似之处.
WFMC(工作流管理联盟).
该组织发展了工作流模型和工作流引擎的模型,同时也为监视和控制工作流制定了协议.
FIPA(智能物理代理基金会).
该组织推动了工业应用的技术和规范,使得智能代理系统的对等交互更加顺畅[FIPA].
FIPA的标准包括代理管理技术与代理交际语言.
1.
8本书概览本书是根据两种不同的互补方案来组织的.
第一种组织方案是基于SOC抽象出来的几个主要的层,范围是从原始消息到个人服务、会话和结构安排,再到由多方参与的复杂形式(由参与互操作的、异构的各团队之间的高层次协议提供支持).
这种方案如图1.
1所示,该图展示了各抽象层以及它们之间的关系、Web服务的几个方面和SOC的提出.
第二个方案追踪Web服务的发展路径、SOC的历史和当前具体状态,以及它们正在前进的方向和应该前进的方向.
整本书的主题涵盖了基础互联、服务质量(QoS)和企业互操作.
对于标准化服务,服务协议(特别是电子服务的标准化)已经有了很大的进步.
其中一个大进步便是电子服务XML(ebXML),它在图1.
1最右边的框中.
最左边的框中是语义Web研究组织与W3C合作的结晶.
中间的框中主要是IBM、微软、BEA、惠普和Sun等公司的标准化工作的成果.
这些标准基本上是从一个标准化组织中分离出来的,但是最终会被一个或多个此类组织所认可.

图1.
1电子商务自动化流程中不同标准草案之间的关系每个框都用到了以下的抽象层.
传输层提供分布式服务系统中构件之间交流信息的基础协议.
XML是企业间互操作的基础,也为语义Web的构想打下了基础.
这一层的标准描述了语法上组织良好的数据和文档应遵循的语法,以及对数据结构的验证方法.
通信层描述了文档与服务调用之间交互所用的标准.
服务描述与绑定层基于Web服务的实现、接口和结果描述了Web服务的功能.
对话是服务之间交互的一个实例,它描述了通过个人服务、文档与调用进行交换的结果.
编排(Choreography)协议将Web服务调整为模式,用来提供一个理想中的结果.
编排在跨控制域时使用,用于确保协调和互操作性.
事务协议不但规约了自治的构件的行为,而且意图纠正当异常和约定失灵发生时所产生的问题.
编制(Orchestration)层为工作流和业务流程提供了协议,这些工作流和业务流程由更为初级的服务和构件组成.
它们规约了要正确执行的流程所需的控制流和数据流.
编制隐含要求一个中央控制机制(好比交响乐队的指挥),但编排却不是这样(好比舞台上的舞者).
编制一般用于控制域内.

合约与协定层将自治的构件之间的约定形式化,目的是使电子服务自动化,并提供具有法律效力的结果.
发现层规约了服务(发布其功能)与客户(需要定位这些功能并使用该服务)之间的协议和语言.
1.
9说明这些方法提供了一系列简化工作的服务(如货币转换).
微软的MapPoint网站(http://www.
microsoft.
com/mappoint/webservice)提供了查找城市地图的Web服务(基于微软公司收购的mapblast.
com网站的技术).

1.
10练习1.
学习amazon.
com网站Web服务工具套件的许可文件,并且根据自治性、异构性和动态性等概念来评价它们所给出的服务(举例说明).
下一步,设想出你可能从这个工具套件中遇到的其他形式的自治性、异构性和动态性,即使这些性质并没有明确地写在文档中.

2.
用Google网站的Web服务工具套件来重复练习1要求的内容.
3.
用微软MapPoint网站的Web服务工具套件来重复练习1要求的内容.
4.
下列哪几项技术可以保持参与其中的构件的自治性(可能有多项,也可能没有)A.
构件A和构件B之间通过TCP/IP协议提供的socket(套接字)来传输消息.
B.
构件A和构件B之间进行远程过程调用(RPC).
C.
构件A和构件B之间进行远程方法调用(如JavaRMI).
D.
构件A和构件B之间用SMTP协议来传输E-mail.
5.
用JSP(JavaServerPages)或ASP(ActiveServerPages)等编程方式来创建一个网页,使用户可以对本地数据库进行搜索.
以书店为例,存储图书的作者、标题、出版商、出版年份以及价格等信息.
如果要简单一些,该数据库可以做成一个简单的文件.
本练习是实现Web服务的预备练习,可帮助你了解本地安装的细节.