语义Web服务

OWL-S（Web Ontology Language for Services），是用OWL语言描述的Web Service的Ontology。它也是一种具有显式语义的无歧义的机器可理解的标记语言（markup language），用来描述Web Service的属性和功能。OWL-S的早期版本叫做DAML-S（DARPA Agent Markup Language for Services，基于DAML+OIL）。本文主要介绍OWL-S 1.0版。

Upper ontology for services

上图是Service的上层Ontology。在OWL-S中，一个Service由三部分来描述ServiceProfile，ServiceModel，ServiceGrouding。简单来说，ServiceProfile描述服务是做什么的，ServiceModel描述服务是怎么做的，ServiceGrounding描述怎么访问服务。一个Service最多被一个ServiceModel描述，一个ServiceGrounding必须和一个Service相关联。以下将详细描述这三个部分。

一、Service Profile

Service Profile描述一个服务主要包含三方面信息。
首先，服务提供者的白页和黄页信息。比如服务提供者的联系方式。
其次，服务的功能信息。主要是指服务的IOPE：Input，Output，Precondition，Effect。IOPE是OWL-S中的主要内容之一，在Service Model中还会详细描述。
最后，Service Profile可以提供服务的所属的分类，服务QoS信息。Service Profile也提供了一种机制来描述各种服务的特性，服务提供者可以自己定义。
Service Profile最大的特点就是双向的，服务提供者可以用Profile描述服务的功能，服务请求者可以用Profile描述所需服务的需求。这样服务发现时，matchmaker可以利用这种双向的信息进行匹配。
另一方面，Service Profile是registry-model-neutral的，也就是说，Profile支持各种各样的registry model，最常用的registry model比如UDDI的基于服务注册中心的集中式解决方案。而在特殊情况下，比如某个服务供不应求，那么可以建立服务请求的注册中心，对每个服务请求进行注册，当服务响应完一个请求后，从注册中心中取出下一个进行响应。这与UDDI是完全相反的一个过程。由于Service Profile是双向的，它完全支持这种方式的registry model。对于P2P方式的registry model，没有统一的注册中心，Service Profile也能够支持。

二、Service Model

Service Model主要是服务提供者用来描述服务的内部流程。一个Service通常被称之为一个Process（过程）。首先定义Process的Ontology：

Top level of process ontology

Process分为三类：Atomic Process，Composite Process，Simple Process。

<owl:Class rdf:ID="Process">
<rdfs:comment> The most general class of processes </rdfs:comment>
<rdfs:subClassOf rdf:resource="&time;#IntervalEvent"/>
<owl:unionOf rdf:parseType="Collection">
<owl:Class rdf:about="#AtomicProcess"/>
<owl:Class rdf:about="#SimpleProcess"/>
<owl:Class rdf:about="#CompositeProcess"/>
</owl:unionOf>
</owl:Class>

Atomic Process（原子过程）是不可再分的过程，可以直接被调用。每一个原子过程都必须与提供一个grounding信息，用于描述如何去访问这个过程。
Composite Process（复合过程）是由若干个原子和复合过程构成的过程。每个过程由一个ControlConstruct定义。ControlConstruct定义了复合过程中每个子过程的执行顺序。OWL-S中定义的控制流有 Sequence，Split，Split+Join，Unordered，Choice，If-Then-Else，Iterate，Repeat-Until这几种。
下面这个例子是复合过程“航班预定服务”的描述：
<process:CompositeProcess rdf:ID="BravoAir_Process">
<rdfs:label> This is the top level process for BravoAir </rdfs:label>
<process:composedOf>
<process:Sequence>
<process:components rdf:parseType="Collection">
<process:AtomicProcess rdf:about="#GetDesiredFlightDetails"/>
<process:AtomicProcess rdf:about="#SelectAvailableFlight"/>
9
<process:CompositeProcess rdf:about="#BookFlight"/>
</process:components>
</process:Sequence>
</process:composedOf>
</process:CompositeProcess>
该过程由三个子过程组成：GetDesiredFlightDetails，SelectAvailableFlight，BookFlight。它们按照顺序执行。
Simple Process是一个抽象概念，它不能被直接调用，也不能与grounding绑定。观察一个服务通常可以有不同的粒度，当我们需要关心一个服务的内部细节时，可以将这个服务定义成Simple Process。一个Atomic Process可以realizes一个Simple Process，一个Composite Process可以collapseTo一个Simple Process。
IOPE是OWL-S中一个非常重要的概念。IOPE是指Inputs，Outputs，Preconditions，Effects。类似于程序设计语言中的相应概念。Inputs和Outputs是指服务的输入和输出，可以理解为数据的变换；Preconditions和Effects是指服务的前提条件和效果，即服务执行前应该满足的条件和服务执行后实际产生的效果，可以理解为状态的改变。OWL-S中可以定义条件式Outputs和Effects，即只有在某种条件满足的情况下，Outputs和Effects才能产生。例如Selling Service的IOPE可以如下定义：

IOPE实例

下面一个例子是用OWL-S描述一个“航班预定确认服务”：
<process:AtomicProcess rdf:ID="ConfirmReservation">
<process:hasInput rdf:resource="#ReservationID_In"/>
<process:hasInput rdf:resource="#Confirm_In"/>
<process:hasOutput rdf:resource="#PreferredFlightItinerary_Out"/>
<process:hasOutput rdf:resource="#AcctName_Out"/>
<process:hasOutput rdf:resource="#ReservationID_Out"/>
<process:hasEffect rdf:resource="#HaveSeat"/>
</process:AtomicProcess>
<process:Input rdf:ID="ReservationID_In">
10
<process:parameterType rdf:resource="&concepts;#ReservationNumber"/>
</process:Input>
<process:UnConditionalOutput rdf:ID="PreferredFlightItinerary_Out">
<process:parameterType rdf:resource="&concepts;#FlightItinerary"/>
</process:UnConditionalOutput>
<process:UnConditionalEffect rdf:ID="HaveSeat">
<process:ceEffect rdf:resource="&concepts;#HaveFlightSeat"/>
</process:UnConditionalEffect>
航班预定确认服务是一个原子过程，所以它必须定义该服务的IOPEs，以及每个参数的类型。比如一个输入参数ReservationID_In，它的类型是ReservationNumber，这个类型是在服务提供者定义的Ontology：Concepts中定义。
Service Profile和Service Model中都用到了IOPE，两者并不需要完全一致，通常，Profile中的IOPEs是Service Model中的IOPEs的子集，这根据服务提供者需要发布那些功能而给定。
最后，我们考察一个比较形象的Web Service 的Process Model的例子，Amazon的网上书店的Web Service：

Amazon Web Service的过程模型

Amazon这个服务通过Choice控制结构表示可以在Search，Shop，Shopping Cart三个子服务中选择一个。Shop服务是一个顺序结构，首先需要查书Search，如果找到，则调用Shopping Cart服务，否则什么都不做，这是通过选择结构来描述。而Search和Shopping Cart分别可以在几个原子服务中进行选择，比如Search可以是Author Search，也可以是Artist Search。
通过这个例子我们可以看到，OWL-S的过程模型可以非常自然的表达复合服务的逻辑过程，这是因为它借鉴了很多程序设计语言的特征。

三、Service Grounding

Service Profile和Service Model都是关于服务的抽象的描述，而Service Grounding是涉及到服务的具体的规范。简单来说，它描述服务是如何被访问的。具体的，它需要指定服务访问的协议，消息格式，端口等等。但是OWL-S规范中并没有定义语法成分来描述具体的消息，而是利用WSDL规范。选择WSDL，一方面是因为WSDL是对具体消息进行描述的重要规范，另一方面因为它具有强大的工业支持。
由于OWL-S利用了WSDL来描述具体的消息，所以在OWL-S和WSDL之间需要进行概念的映射。参见下图：

Mapping between OWL-S and WSDL

OWL-S和WSDL之间需要进行三方面的映射。
a) OWL-S的Atomic Process映射到WSDL中的operation；
b) OWL-S中Atomic Process的Inputs和Outputs映射到WSDL中的message；
c) OWL-S中Inputs和Outputs的类型（OWL Class定义）映射到WSDL中的abstract type（XML Schema定义）。
从上图可以看到，OWL-S Grounding比WSDL更抽象一些，两者之间有良好的对应关系。

 

OWL-S协议栈

OWL-S协议栈

对比我们熟悉的Web Services协议栈：

传统Web服务协议栈

我们看到在服务发现上OWL-S Service Profile代替了UDDI，在服务组装上OWL-S Process Model代替了BPEL4WS和WSCI。但是这并不意味着用OWL-S取代UDDI或者BPEL4WS。我们需要将 OWL-S和现有的各种成熟的技术结合起来使用。
比如，对于UDDI，我们可以通过OWL-S Service Profile来提供Capability Search，而不是传统的Keyword Search。这可以通过利用UDDI中的TModel编码OWL-S 的Capability描述而实现。CMU的OWL-S/UDDI matchmaker就是OWL-S和UDDI结合的一个例子。