文出处:
http://webservices.org/article/articleprint/663/-1/24/
作者:Uche Ogbuji 原文发表日期:2002年9月28日
翻译者:陈剑(
jchen@263.net) 译文发表日期:2002年10月10日
简介
对Web
services的大肆宣传(hype)已经接近顶峰,它成为了当前流行媒体最喜欢的炒作对象。这种宣传攻势同其它技术在全面开发和走向成熟前的状况没什
么两样。不管媒体的兴趣如何,Web services毫无疑问是一项发展前景颇为看好的重要技术。那些对Web
Services出现的动机、某些特定技术胜于竞争者的原因以及Web Services可能的技术成熟途径有透彻理解的公司和开发人员将在Web
Services的使用方面获得成功。
正是基于这样的原因,我将以Web Services的历史作为开篇。这并非出于怀旧的目的,Web
Services得以孕育的商业和技术环境以及在其发展历程中盛衰无常的参与者(公司或者组织)都将对Web
Services的未来产生重要的影响。你也许已经注意到了这一趋势,比如类似结构化信息标准推进组织(OASIS)这样的团体正在扮演为Web
Services制定安全、工作流和事务处理等协议标准的角色。有趣的是,OASIS曾经被看成是Web Services主流技术的反对者。
Web Services的表演舞台
分布式应用的开发在传统计算技术由集中式的主机计算向对等的小型计算机和工作站网络过渡阶段开始就
成为了重要的发展领域。在这一趋势的发展过程中,IT经理仍旧是其所在领域的专家。分布式开发的战略被限制在IT经理接受必要的输入并向管理层提交必要的
报告。运行和维护一个良好集成的数据中心才是关键,而对异步平台和环境的支持显得并不那么重要。在这种状况下,诸如电子数据交换(EDI)这样的部门在企
业中通常是作为一个完全独立的实体而存在。
虽然几乎所有的Web
Services的技术基础都是从小型机时代发展起来的,但是由于某些原因,在分布式计算的历史上,小型机时代却经常被人忽略。这大概是因为在同一时期
PC的革命性崛起掩盖了小型机时代的光芒。但是直到Internet投入广泛商业应用之前,PC并未对分布式计算领域做出什么突出的贡献。为了组织并提高
数据中心的可伸缩性,服务被分散到多台工作站上,这就要求一系列包括同步和异步方式在内的通讯机制和底层应用集成机制。结果,这一时期流行的体系架构和操
作系统(比如,DEC VMS、Tandem、HP以及Sun的Unix系统)开发出的分布式消息通讯(distributed
messaging)技术,其复杂程度即使在今天看来也让人咂舌。
IBM携MQSeries进入分布式消息通讯领域的时间稍晚。在
看到要求应用能运行在从小型机直到其大型主机上的需求之后,IBM收购了当时流行的ezBridge软件,并在其基础上开发出了MQSeries。
MQSeries从那个时代起就独领风骚,直到现在。然而,消息通讯技术要求已经习惯了过程化编程语言的程序员们以全新的思路看待和解决问题。程序员却希
望以自己熟悉的简单的函数调用方式来访问远程的过程。在80年代末期,分布式计算环境(DCE)的推出试图将多个相互竞争的远程过程调用技术标准化。这一
努力有意忽略了消息通讯技术,并且主要由于政治方面的原因,DCE并未获得业界的广泛支持。此时,新一代(但并不一定更好)的分布式计算技术开始涌现。
这个时期,IT经理们开始跻身公司管理高层,信息系统也成为公司战略的基础,在投资预算中所占的比例日渐增长。组织中的现实意味着大部分公司的计算技术
重点不再局限于单一的数据中心,与此相反,各类部门级的系统呈爆炸性增长。系统集成代替单一平台标准成为技术选择中最重要的考虑因素。IT经理们现在寻求
的是网络技术的标准化。因为面向对象技术许诺的可管理性、代码重用、降低成本以及提高投资回报率等等好处,IT公司们开始采用对象系统作为软件开发的标
准。由此带来的结果是,这一阶段涌现的分布式技术都打上了深深的对象技术的印记。
和DCE一样,CORBA(通用对象请求代理体系
架构)也是业界联盟试图对分布式过程技术进行标准化的产物。这一次,规模庞大的对象管理集团(OMG)将重点集中在跨平台应用中远程对象的访问请求之上。
由于CORBA试图使对象状态和生命周期的管理透明化,因此在可伸缩性上不如消息机制和DCE理想。同样的问题也困扰Microsoft推出的与
CORBA竞争的远程对象协议:组件对象模型(COM)和分布式组件对象模型(DCOM)。与此同时,e-mail和Web被证明是有史以来最成功的分布
式体系架构,其设计者采用的分布式开发技术充分利用了消息通讯技术和Internet的普遍连通性。各大厂商出于降低风险的目的,普遍支持这些标准。
在同一时期,其它专业化的分布式技术也相继出现。Java的流行导致了RMI(远程方法调用)协议的出现。在MQSeries获得成功后,Microsoft和Java也推出了自己的消息通讯技术。
在新千年来临之际,基于信息系统的需求和网络技术的经验积累,新一代的分布式计算技术呼之欲出。人们对于分布式计算技术的要求包括:
适合单一应用中的分布式操作以及不同应用间通用服务的调用。换句话说就是能够同时支持开发人员和系统集成商。
适合组织内部以及组织间的信息交换,要求跨平台支持和数据驱动(data-driven)。
尽可能与现存的Internet基础设施和谐共处。
在节点数、异构节点数以及节点复杂度增加时,具有良好的可扩展性。
有力的国际化支持。
容错性。节点紧耦合的网络通常存在单点失效的问题,在分布式系统中这一问题更加严重。 对来自流行厂商的通用软件开发和商业流程管理工具的有力支持。
在支持最简单的请求/响应机制的同时,在必要的时候也提供对复杂的流程协作、事务和安全性支持。
Web services横空出世
HP在其高端的UNIX平台上直接迈出了由小型机分布式计算时代进入现代Web
Services的令人瞩目的一步。从90年代早期到中期,HP的实验室开始着手研究如何解决分布式系统的技术和成本的难题。HP的研究成果被其称为e-
Speak,于1999年下半年正式推出。e-Speak致力于解决上节末尾列出的绝大多数需求,也许是业界的第一个Web
Services技术,当然也是第一个商业性Web
Services技术。e-Speak使用HTTP这样的通用协议,数据的表示采用的是XML,并且将各种联网系统看成能够快速插接数据流的“电子服务”
("e-services")。不幸的是,e-Speak的理念比目前的Web Services技术内聚性更强
,HP最近决定淡化e-Speak,转而支持更主流的Web Services。
UserLand社团也试图使用HTTP和XML技术来满足上述需求。UserLand的Dave
Winer领导了XML-RPC的开发工作。XML-RPC是一个简单的用于调用远程方法的系统,其协议文本只有短短的几页。目前,XML-RPC在开放
原码领域仍然十分流行。开放原码领域内相互竞争的项目和众多开放并且许可证免费的实现使XML-RPC具有良好的互操作性和低廉的成本。但是,由于
XML-RPC的草根出身和较早的推出时间,使其不可避免地存在一些显著的不足。例如,XML-RPC坚持使用ASCII字符串(虽然它使用的是国际化支
持良好的XML标准),这导致其基本上只能在英文环境中使用。而且,XML-RPC在数据类型的选择方面也比较随意。但是,更重要的是,XML-RPC被
限制在使用高度统一和结构化消息格式的简单请求/响应服务上。
在XML-RPC出现的同时,也存在其它更通用的XML消息通讯机
制。虽然它们中的大多数其实更适合于程序语言结构(constructs)的序列化(serialization)和数据库的内容转储(dumps),而
不是用于面向文档的消息通讯,但是比起严格的RPC方式来,还是要更灵活一些。其中最有名的是Allaire
公司提出的Web分布式数据交换协议(WDDX),目前一个相关的社团在继续这个开放规范的继续开发。
与此同时,XML和
Internet协议也对像EDI业界这样的其它技术团体带来革命性的影响。首先,出现了运行在SMTP(e-mail)上的EDI,同时为了避免增值网
络(VANs)高昂的交易费用,HTTP(Web)也被EDI采纳。接下去,诸如欧洲的CEN/ISSS和美国的XML/EDI等团体开始开发将EDI交
易编码成为XML的技术,因为EDI交易的消息内容以杂乱出名。这一系列的趋势使得早期出现的Web
Services主要解决的不是企业应用集成(EAI)的问题而是主要用于简化B2B交易。这些早期的XML/EDI系统在设计中利用了现有的稳定和通用
的EDI流程协作、安全等高级机制,而这些恰恰是目前Web
Services仍旧缺少的。这些努力导致了一个叫做电子商务XML(ebXML)的正式标准的出台。ebXML的支持者主要来自EDI阵营,但是稍后一
般被认为是擅长过程和对象的Sun也加入进来。从1999年底开始,ebXML进入了18月的开发周期。ebXML由SGML/XML业界先驱OASIS
和在传统EDI开发的扮演关键角色的联合国贸易推进和电子商务组织(UN/CEFACT)共同开发和维护。
回溯到1998年,一个用于结构化交换XML文档的规范——简单对象访问协议(SOAP)在一个小范围的组织中间酝酿,其中也包括软件巨人Microsoft。由于一些政治方面的原因,SOAP直到1999年下半年才正式发布。
分布式计算技术的发展历史(HISTORY OF DISTRIBUTED COMPUTING )
SOAP繁衍增生
SOAP生来就引起各方的争议。尽管从对SOAP采用的特殊类型系统到是追随SOAP阵营(由
Microsoft领导)还是ebXML(由Sun领导)等问题都充满争论,主要的业界厂商对Web Services将成为下一个重量级技术(the
next big thing)都心照不宣。SOAP来源自诞生XML-RPC的同一社团Userland's,因此在草根Web
Services阵营得以流行。SOAP不像XML-RPC那样简单,但是它确实解决了早期规范中的一些问题。开放源码的开发者们惊讶地发现,几乎所有的
商用系统厂商都对这个开放协议提供支持。其实想想XML的成功,这也就不足为奇了。SOAP的出现为分布式开发摆脱大型厂商和社团的严格限制提供了良机,
于是,各种SOAP开发组织如雨后春笋一般涌现出来。
SOAP只是一个通讯协议。很早就有迹象表明,对Web
Services的元数据(metadata)的标准化具有重要的意义。在创建这一个特殊的语言方面,多个方面均作出了努力。WebMethods
提出的Web接口定义语言(WIDL)是出现最早的标准之一,其目标是用于像XML-RPC和WDDX这样的第一代Web
Services系统。WIDL的设计效仿了作为CORBA和COM基础的接口定义语言,但是它是以XML的形式出现的。Microsoft在2000年
为Web
Services节点的服务描述开发了服务描述语言(SDL)和SOAP契约语言(SCL)。Microsoft还开发了用于Web服务信息注册和查找的
Web Services发现协议(DISCO),通过它用户能够找到用SCL描述的服务。
IBM推出了与之竞争的一系列规范:和
SDL与SCL类似的可访问网络服务规范语言(NASSL),和DISCO类似的服务发布和发现协议(ADS)。这些标准都集成到了IBM
alphaWorks的Web Services工具包中。IBM,
Microsoft以及Ariba等公司在以上提到的这些协议规范基础上最终提出了Web Services描述语言(WSDL)。
这三家公司还将其它们各自专有的发现系统整合后,提出了Web
Services目录系统——通用描述、发现和集成协议(UDDI)。UDDI包括白页、黄页和绿页。UDDI被作为一个有36家公司参与的联盟的产品推
出,现在该联盟的成员公司已经超过了100家。这一产品的定义非常详尽而且高度形式化,这和SOAP与WSDL的情况大不一样。SOAP和WSDL的规范
文本简单易懂而且易于实现。这一差异反应了Web Services的现状:诸如核心通讯和服务描述等底层技术细节的演化是由底向上(bottom
up),采用了一系列可以免费获得的语言和工具;而发现和商业/法律描述则根据集中式的信息授权和认证由顶向下(top down)演化。
这导致了Web
Services在“个性”("personality")方面的分化。首先,以“终极Perl黑客”("desperate Perl
hacker")为代表的Web Services草根阶层在部门级如鱼得水,但是和整个公司的战略背道而驰。其次,企业级Web
Services作为电子商务战略的基础等到高层的认可。目前,大部分成功的Web Services集中在草根阶层。以UDDI为代表的企业级Web
Services却还没有找到自己的核心价值所在(而且在某些情况下,甚至拒绝吸取EDI团体长期以来得到的教训)。
开发商站到前台
2001年4月召开的W3C Web Services研讨会(W3C Workshop on Web
services,WSWS)是对Web Services的未来发展的规划。此前,Web
Services主要是在W3C之外由草根阶层或者诸如UDDI.org这样的独立团体进行开发。W3C对Web
Services的支持是自然而然的事情。正如,它也是HTML、XML等其它Web标准的制订者一样。WSWS的目标是要确定W3C中有关Web
Services的活动的形式和目标。W3C已经成立了XML协议工作组(XML Protocol working group
,XMLPWG),虽然到目前为止,该工作组除了将一系列XML建议和候选协议分门别类之外,没有完成多少实质性的工作。对WSWS而言,XMLPWG将
不断充实,以便将SOAP扩展成为一个完善的W3C推荐标准。
对Web Services而言,机会在于使各种技术战略获得新生。WSWS正在考虑在基本协议的基础上实现一系列的高级特性:
IBM提出的Web Services节点语言(WSEL)试图解决Web Services的服务质量(QoS)等网络管理方面的问题,Web Services流语言(WSFL)则致力于Web Services的流程协作。
HP的eSpeak技术提出了更广泛和雄心勃勃的Web Services战略,讨论各类特定服务的核心概念和运行环境的需求,特别是对小型嵌入式设备的支持。
Microsoft也在强调QoS,并和IBM一起联合开发。
Jamcracker与BEA强调Web Services在集成方面的重要性。
Verisign强调安全性的重要性和数字认证的作用。Novell则强调在目录服务中授权和认证的管理。
其它的一些开发商则只是演示各自开发的支持Web Services开发和部署的专有框架,并将其作为未来可能出现的协议标准的模型提出。
WSWS同时拥有来自Web Services草根阶层(比如,UserLand 的Dave
Winer,XML-RPC和SOAP的开发者)和来自OASIS和ebXML的代表。后者最近刚刚结束了一场Web
Services社团内部争论,决定采用一个基于带附件email的SOAP传输协议(SOAP over e-mail with
attachments)来代替一个此前开发出的更加细化的特殊的消息通讯协议。笔者本人也受邀发表一篇关于如何使用W3C的资源描述框架标准
(Resource Description Framework ,RDF)来集成Web Services和其它元数据系统的论文。
协议栈的进展
WSWS的主要目的是构建Web
Services的“协议栈”或称体系结构。诸如Qos(服务质量)、安全性、流程协作(orchestration)以及事务管理等标准都将在这个协议
栈中找到自己的一席之地。SOAP和WSDL已经确立了Web
Services核心标准的地位,所以主要厂商间填补协议栈空缺部分的争斗成为2002下半年的主旋律。
安全性一直是受到特别重视的领域。很容易理解,在Web
Services成为公司防火墙外部流行的通讯机制之前,强有力的安全性必须得到保证。安全性表现于多个方面,其中之一是保证传输的内容
(payload)不被篡改。W3C的XML签名(XML
Signature)工作组致力于开发用于XML文档的数字签名系统,支持诸如canonicalization
(c14n)等协议规范。c14n将XML文档转换成一种标准格式以免诸如XML属性的排列顺序不会对XML文档含义带来影响的因素造成数字签名系统的误
判。XML加密工作组(XML Encryption working
group)致力于加密技术,制定包括加密数据并保证结果为格式良好(well-formed)的XML文档的XML加密句法和处理规范。XML密钥管理
工作组( XML Key Management working group)则制定用于管理数字密钥和信用认证令牌(trust
certification tokens)的简单Web
Services规范。2002年新出现的标准还包括安全断言标记语言(SAML)和WS-Security规范框架。我将在本文的下部讨论这几个规范标
准。
商业流程和工作流是协议栈中标准制定工作的另一活跃领域。ebXML是该领域的早期成员。ebXML协议族中的商业流程规范模
式(BPSS)和其注册与存贮(registry and
repository)标准提供了对管理业务伙伴能力和协议的支持。它同时还对持续运行交易(long-lived
transaction)的管理,安全以及服务质量提供支持。处于发展早期的还包括IBM、HP、Oracle、Sun等提出的交易权限标记语言
(XAML)。该协议已经合并进入其它Web
Services的交易规范的制定工作。IBM的WSFL和WSEL分别针对工作流和服务质量(Qos)提出。微软则提出了名为XLANG的工作流协议。
WSFL和XLANG都是对WSDL的扩展,正如人们预期的那样,这两个标准被合并成为一个更为通用的商业流程语言WS-Coordination。在本
文的下部,我将讨论WS-Coordination,WS-Transaction 和 BPELWS。
迈入2002
当我
们迈步进入2002年,Web Services在各个层面均获得了长足的进展。在草根阶层,多个开发者团体开始着手解决早期Web
Services声名狼藉的互操作性(interoperability)问题。在公司内部,Web
Services协议栈逐渐成型,开发商们迫切地期望Web Services相关规范尽快完善。在本文的第二部分,我将勾勒出Web
Services在当前(2002年)的状况,并且展望其未来发展。
关于作者:
Uche Ogbuj是Fourthought
Inc.的创始人和咨询师。他的公司为企业知识管理提供专业的XML解决方案,包括软件开发和咨询服务。Fourthought开发了用于XML,
RDF和知识管理应用的开放源码平台4Suite。Ogbuji先生是计算机工程师兼作家,他出生于尼日利亚,现在居住在美国Colorado的
Boulder。你可以通过Email和他联络。
关于译者:
陈剑,IBM中国开发中心软件工程师。 关注J2EE,Web Services, 面向对象,软件工程等技术。出生于天府之国四川,现在北京工作和生活。你可以通过Email和他联络。