OWL-S为Web服务的语义描述提供了一个完美的模型,从服务的发现、协调、洽谈到服务的组合过程和数据转换,涉及到Web服务自动组合的整个过程,并提供了与原有标准结合使用的方法。但是OWL-S在互联网上的应用状况正如其他语义技术一样因为其复杂繁琐而难以得到推广。

IBM研究院、乔治亚大学LSDIS实验室联合提出了WSDL-S。他们提出了语义Web服务描述的需求有以下5条^{[ 3]}:基于现存的Web服务标准;机制应独立于语义标识语言;允许使用多种语言表示方法结合;支持XML-Schema的语义注解;在Web服务的模式类型和本体之间提供丰富的映射机制。

基于以上的需求,研究者们提出了WSDL-S方法作为为Web服务增加语义注解的机制。这个模型对语义标注语言未作规定,使用者可以使用任何一种语义标注语言来标注语义信息;WSDL-S兼容WSDL,开发者可以使用已经很熟悉的WSDL来描述非语义信息;使用增量工具开发者很容易从WSDL升级到WSDL-S。笔者认为OWL-S在逻辑描述方面的基础以及WSMO在F-Logic方面的基础使得它们成为表达丰富的语义描述语言,但是对于扩展WSDL这样的工业标准,增加语义信息是一种更为实际的方法。尽管OWL-S也考虑到了与WSDL的兼容,但是WSDL的开发者认为OWL-S是一种自上而下的标准,而WSDL-S是一种自下而上的标准,更容易推广与普及,更符合现实的应用情况。

WSDL主要扩展了以下元素:

(1)一个扩展元素:ModelReference,允许WSDL输入和输出类型模式与语义模型的概念一对一关联;

(2)一个扩展属性:SchemaMapping,允许WSDL输入和输出类型模式元素与语义模型多对多关联;

(3)两个新元素:Precondition and Effect,作为Operation元素的子元素,按照OWL-S的方法描述语义,用于服务发现;

(4)一个关于接口元素的扩展属性:ServiceCategorization,包括服务分类信息,用于服务发布注册,与OWL-S的Categorization对应。

相比OWL-S,WSDL-S的开发者们更强调语义描述框架的简洁、实用、开放性以及与现有规范的兼容性。

2007年,W3C提出SAWSDL为Web服务语义注解的候选推荐标准^{[ 4]},SAWSDL来源于WSDL-S,但是比WSDL-S更为开放,应用性更强。SAWSDL的目标仅仅定位为增强WSDL,这大大简化了为Web服务增加语义信息的工作,有利于推动语义Web服务的发展。SAWSDL仅仅定义了两个元素ModelReference和SchemaMapping(包括LiftingSchemaMapping和LoweringSchemaMapping),最大化地使用了XML技术,尽可能降低技术门槛。

SAWSDL并不是一门语义注解的语言,而是为WSDL和XML Schema提供了一种增加语义注解的机制,使得WSDL和XML Schema中的组件可以与外部的语义概念模型联系起来。在WSDL中使用语义注解本身并不会给WSDL文档增加任何语义信息,而是给出了一个语义参考模型的链接地址。当服务之间需要进行语义交互时,可以通过中间的标准本体来进行数据的转换、服务的发现和选择。ModelReference可以为任何一种WSDL的组件做注解,它直接指向一个概念模型的地址,而LiftingSchema用于把XML结构的数据映射到语义模型,LoweringSchema把语义模型的数据映射到XML结构。下面的代码对名为“OrderResponse”的元素进行了语义注解,ModelReference指向其语义模型,LiftingSchemaMapping指向其与高级语义模型映射的方法。

sawsdl:modelReference="http://www.w3.org/2002/ws/sawsdl/spec/ontology/purchaseorder#OrderConfirmation"

sawsdl:liftingSchemaMapping="http://www.w3.org/2002/ws/sawsdl/spec/mapping/Response2Ont.xslt">

…

SAWSDL把语义标注的工作交给了其他本体,而SAWSDL仅仅增加了一个通往相关本体的链接地址,人们并没有预先定义一个关于WSDL元素的本体结构,如何使用语义技术描述Operation、Interface、Fault这些WSDL中的元素成为需要解决的问题。WSMO在2008年提出了WSMO—Lite^{[ 5]},这是一种基于WSMO的轻量级的Web服务描述本体,借助SAWSDL机制,为Web服务语义描述提供了一套最小集。草案根据不同的技术发展水平提出了语义Web的协议栈,协议栈共有5层,而SAWSDL是无语义层与语义层衔接的关键部分,它通过简单的扩展允许WSDL组件可以被语义标识和注解,提供了语义层的基础。

WSMO-Lite本体由4个子本体组成:Ontology、ClassficationRoot(Category)、NonFunctionalParameter、Condition and Effect(Capability)。Ontology定义了服务信息模型的数据集;Classification用于描述服务在类别目录中的信息,从而描述服务的功能;NonFunctionalParameter描述服务的非功能信息;而Condition and Effect用来描述服务可以做什么。从图1^{[ 5]}中可以看出,WSDL元素使用ModelReference分别指向WSMO-Lite不同的子本体,Schema元素或者Type指向了Ontology本体,其中包含描述数据的本体和XML模式元素与高层本体的映射关系;Operation指向了用于描述服务功能和能力的ClassficationRoot以及Condition and Effect;而Endpoint、Bingding元素的注释指向了Non-Functional本体。

图1

	Figure Option ViewDownloadNew Window
	图1 WSDL注解和规则

WSMO-Lite还提出了使用WSMO-Lite进行语义标注的三条规则:

(1)一致性规则,如果XML模式信息同时有A1和A2注释,那么A1指向的语义模型必须能够通过A2定义的转换关系与XML模式信息相互转换;

(2)完整性规则,WSDL元素的每个输入信息都必须有一致的A1和A2(Lowering)注释,每个输出信息都必须有一致的A1和A2(Lifting)注释;

(3)完整性规则,一个接口的所有操作必须使用功能描述性注释,这条规则保证了接口内的所有操作都不被自动客户端忽视。

至此,WSDL的语义描述有了一个较为完整的语义标注机制和描述模型,通过SAWSDL这样一种中间机制,使得有语义和无语义两种服务能够共同工作。

对比OWL-S和SAWSDL,二者均出自为Web服务增加语义信息的目的,但是方法途径却是从两个方向而来。OWL-S首先构造了Web服务描述的本体,然后通过Grounding与现存Web服务描述标准自上而下进行衔接;而SAWSDL并没有构建一个描述Web服务的标准本体,而是增加语义注解机制,通过语义注解机制使得WSDL元素及XML Schema与高层的语义模型相关。

文献[6]对比了这两种方法的相同点和差异。笔者认为二者的不同主要在于出发点不同,SAWSDL仅仅关注对WSDL的语义标注,并不试图定义一套对Web服务的语义描述标准,而是通过注解机制为Web服务的语义描述构造了一个开放的空间和结构,把选择何种语义表达方式和语义描述语言统统留给了用户和服务的开发者。用户完全可以根据自己对自动化的需求选择合适的语义模型,而不必被复杂的语义模型所牵绊。但是局限性也显而易见,SAWSDL仅仅能够对WSDL中已有的元素增加语义注解,对Web服务的语义描述并不全面。而OWL-S则不同,其制定者来自语义研究机构,其出发点是构建Web服务标准完善的语义描述模型,完全从语义的角度来描述Web服务。由于目前语义网络的技术并没有得到广泛的应用,从现有标准向上选择恰当的语义模型,一步步为现有技术标准增加语义信息的做法肯定是优于使用繁琐复杂语义的描述模型向下兼容现有标准的做法。正如有学者指出:在后SAWSDL时代,与其在各种语义Web服务描述方法中争出一个胜负,不如去思考如何利用各种优秀的方法去增强SAWSDL^{[ 7]}。

2000年,Fielding在他的博士论文中提出适用于分布式超文本系统的REST (REpresentational State Transfer)架构^{[ 8]}。这种简洁而轻量级的软件架构风格非常适合互联网上的信息存取服务,Web上大量的服务属于信息存取类服务,复杂的交互非常少,这时使用HTTP协议中原有的Get、Post、Delete、Put 4个命令就完全可以胜任全部工作,而不必使用重量级的SOAP协议。这一架构风格很快在互联网上风行起来,原有大多数提供基于SOAP协议的Web服务系统都已经开始提供REST服务,如Amazon、Google。由于RESTful Web服务并非标准的Web服务,也无法使用WSDL来描述,通常人们只是使用人类可读的HTML文本来描述服务信息,手工来构建服务的获取方法。

随着Web2.0观念的深入人心,人们不再满足于仅仅从Web上被动获取信息,而且要创造信息;不仅仅被动地使用固定模式的信息服务,而且要使用各种信息服务构建新的信息模式。Mashups就是这样一种使用网络上开放的接口获取信息,构建新的信息应用的方法。目前关于Mashups还没有统一的定义,文献[9]认为Mashups是一种基于RESTful Web服务的组合,与通常意义上的服务组合相比,Mashups更为轻量级。Mashups是一种简单模式的服务组合,完全具备向大众推广的潜力,使得不具备编程技巧的普通Web用户也能够方便地使用,这也正是Mashups拥护者们的初衷。但是目前的情况却不是这样,一些研究者认为主要原因在于各种RESTful Web服务之间的数据格式、结构不一致,导致用户在制作Mashups时必须使用编程语言进行大量的数据中转(Data Mediation)工作^{[ 9]}。如果数据的中转能够实现完全的自动化,那么则可以大大简化用户制作Mashups的工作流程,笔者称这种Mashups为SMashups(Semantic Mashups)。文献[9]提出了SA-REST方法,为RESTful Web服务增加语义信息。SA-REST方法借鉴了SAWSDL的标注方法,为服务输入输出数据提供映射模型,通过Lifting Schema把输出的数据映射到与数据相关的本体模型中,通过Lowering Schema把输入的数据从本体模型转换为XML数据。这样两个服务的数据中转通过独立的本体进行转换和计算,而服务仅仅需要提供服务输入输出数据与本体的映射关系。图2显示了服务之间数据中转的流程。

图2

	Figure Option ViewDownloadNew Window
	图2 服务之间数据中转流程

使用SOAP协议的Web服务语义标注可以直接在WSDL文件中进行,而RESTful Web服务通常只使用HTML文档描述服务的获取方式。微格式能够方便地加入对服务的语义注解,而且不增加专门的描述文档。它是一种轻量级的子格式,通常用于嵌入到一些宿主语言中,如 HTML、XHTML 或 Atom。利用微格式,可以在描述Web服务的XHTML文档中嵌入语义注解,从而使得为人类编写的文档也能够被计算机识别^{[ 10]}。 SA-REST提出使用RFDa嵌入语义注解,使用GRDDL提取嵌入的语义信息。2008年SA-REST的部分研究人员又提出hRESTS——一种专用于描述RESTful Web服务的微格式标准,基于hRESTS之上的SA-REST要比使用RFDa更为简单^{[ 11]}。

2008年,WSMO组织针对RESTful Web服务发布了MicroWSMO^{[ 12]},与WSMO-Lite类似,MicroWSMO也由Ontology、Schema Mapping、Capability and Category、以及No-Functional Property 4个子本体组成。一个RESTful Web服务通常包含若干信息资源,每个资源的输入输出数据使用具体的与数据集相关的本体以及本体与服务数据之间的映射关系注解;对于整个Web服务使用Capability和Category来描述功能语义,用于服务的发现;同时对每个信息资源的操作语义也要使用Capability和Category描述;最后服务的非功能特性由No-Functional Property描述。与WSMO-Lite相同,MicroWSMO并不提供对每个操作的非功能语义注解。