Service Oriented Architecture & Web Sémantique

1

1

Service Oriented Architecture &Web Sémantique

Catherine Faron [email protected]

INSA Bourges Catherine Faron Zucker 2

SOA Service Oriented Architecture

Modèle d'interaction applicative qui met en œuvre desservices (composants logiciels): avec une forte cohérence interne (par l'utilisation d'un format

d’échange pivot, le plus souvent XML) et des couplages externes lâches (par l'utilisation d'une couche

d'interface interopérable, le plus souvent un service web) Le service est une action exécutée par un fournisseur

(producteur) à l'attention d'un client (consommateur) Le bus a un rôle de médiateur (middleware) entre le

consommateur et le producteur du service, et réalise ainsi lecouplage lâche. Il peut aussi fournir une gamme de services: en particulier, sur la base des patterns EIP (Enterprise Integration

Pattern), fournir des fonctionnalités de split, combine, etc.permettant de combiner l'appel sur plusieurs services


SOA Services Web


SOA Protocoles et normes

XML format des données échangées

SOAP Simple Object Access Protocol invocation d’un service, la transmission d’une requête à

une service WSDL Web Service Description Language

description des interfaces des services UDDI Universal Description Discovery & Integration

gestion d’un annuaire de services BPEL Business Process Execution Language

orchestration de services


Web Services Architecture Stack


SOA Service Description centered

Découverte de services web Annuaires UDDI

Orchestration de services web Collaboration entre processus métier Composition de services web Gestion de processus métier (BPM), Workflow WSFL, BPML

Découverte et Orchestration de services reposentsur la description des services web

2


Towards Semantic Web Services

WSDL Recommandation du W3C http://www.w3.org/2002/ws/desc/ http://www.w3.org/TR/2007/REC-wsdl20-20070626/

RDF Mapping http://www.w3.org/TR/2007/NOTE-wsdl20-rdf-20070626/

SAWSDL Semantic Annotation for WSDL http://www.w3.org/TR/sawsdl/



« The Semantic Web is an extension of the current webin which information is given well-defined meaning,better enabling computers and people to work incooperation » Tim Berners Lee, 2001

Le Web Sémantique désigne un ensemble detechnologies visant à rendre le contenu des ressourcesdu Web accessible et utilisable par les programmes etagents logiciels, grâce à un système de méta-donnéesformelles … que peuvent contenir les ressources elles-mêmes

grâce au langage de balisage qu’est XML Les ressources deviennent auto-descriptives

… tout comme les services web avec WSDL



WSDL for WS Description Language RDF for Resource Description Framework

The Resource Description Framework is alanguage for representing information aboutresources in the World Wide Web

RDF SchemaRDF Vocabulary Description Language

OWL Web Ontology Language


The Semantic Web in a Nutshell

nomage

syntaxe

sémantique

URI Unicode

XML NS XML Schema

RDF RDF Schema SPARQL

RulesOWL

Logic

Proof

Trust

Dig

ital S

igna

ture


XML et les langages du WS

XML exprime la syntaxe XML Schema exprime la grammaire RDF exprime la sémantique, la signification des balises

<book> <author> <Person> <name> David Lodge </name> </Person> </author> <title> Small World </title></book>

<aaa> <bbb> <ddd> <eee> David Lodge </eee> </ddd> </bbb> <ccc> Small World </ccc></aaa>


XML et les langages du WS

A Book is a kind of Document Documents have an author, which is a Person Documents have a title which is a Literal

Décrire le sens selon un modèle: RDF En utilisant des vocabulaires standardisés,

ontologies: RDFS, OWL Pour répondre à des requêtes : SPARQL

3


Description, Vocabulaire, Ontologie

Vocabulaire Ensemble de termes liés à un domaine

Ontologie Ensemble structuré des concepts d’un domaine et des

relations entre concepts Terme

Mot ou groupe de mots désignant un concept Concept

Représente un ensemble d’objets et leurs propriétés Intension versus Extension, Instances

Relation Signature, Extension & Intension

14

Web Services Architecture

http://www.w3.org/TR/ws-arch/


Web Service

A web service is a software system designed tosupport interoperable machine-to-machine interactionover a network

It has an interface described in a machine-processable format (specifically WSDL)

Other systems interact with the Web service in amanner prescribed by its description using SOAPmessages, typically conveyed using HTTP with anXML serialization in conjunction with other Web-related standards


Agents, Requesters, Providers

The provider entity is the person or organization thatprovides an appropriate agent to implement aparticular service

A requester entity is a person or organization thatwishes to make use of a provider entity's Webservice. It will use a requester agent to exchangemessages with the provider entity's provider agent

The requester entity and the provider entity mustfirst agree on both the semantics and the mechanicsof the message exchange


Web Service Description

The mechanics of the message exchange aredocumented in a web service description (WSD)

The WSD is a machine-processable specification ofthe web service's interface, written in WSDL It defines the message formats, datatypes, transport

protocols, and transport serialization formats that should beused between the requester agent and the provider agent

It specifies one or more network locations at which aprovider agent can be invoked

It may provide some information about the messageexchange pattern that is expected


Web Service Semantics

The semantics of a Web service is the sharedexpectation about the behavior of the service, inresponse to messages that are sent to it It is the contract between the requester entity and the

provider entity regarding the purpose and consequences ofthe interaction

This contract represents the overall agreement betweenthe requester entity and the provider entity on how and whytheir respective agents will interact

It is not necessarily written or explicitly negotiated. It maybe explicit or implicit, oral or written, machine processableor human oriented, legal or informal (non-legal)

4


WS Description and Semantics

The service description represents a contract governingthe mechanics of interacting with a particular service

The service semantics represents a contract governingthe meaning and purpose of that interaction

The dividing line between these two is not necessarily rigid.As more semantically rich languages are used to describethe mechanics of the interaction, more of the essentialinformation may migrate from the informal semantics to theservice description

As this migration occurs, more of the work required toachieve successful interaction can be automated


Process of Engaging a Web Service


Using Web Services (step 1)

The requester and provider entities become knownto each other the requester agent is the initiator. It must become aware of

the provider entity, i.e., obtain its address : (1) directly fromthe provider entity; or (2) from a discovery service whichlocates a suitable service description (which contains theprovider agent's invocation address) via an associatedfunctional description, either through manual discovery orautonomous selection

the provider agent is the initiator. It occurs in some push orsubscription scenarios


Using Web Services (step 2)

The requester and provider entities agree on theservice description (a WSDL document) andsemantics that will govern the interaction betweenthe requester agent and the provider agent Both entities communicate directly with each other, to

explicitly agree on the service description and semantics The provider entity publishes and offers both the service

description and semantics as take-it-or-leave-it contracts The service description and semantics is defined and

published by the requester entity and offered to providerentities on a take-it-or-leave-it basis

The service description and semantics may be defined as astandard by an industry organization


Using Web Services (steps 3 & 4)

The service description and semantics are input to,or embodied in, both the requester agent and theprovider agent as appropriate

The requester agent and provider agent exchangeSOAP messages on behalf of their owners


Architectural Models

A model is a coherent subset of the architecture thattypically revolves around a particular aspect of theoverall web services architecture, from a particularpoint of view

A model explains and encapsulate a significanttheme within the overall architecture Message Oriented Model Service Oriented Model Resource Oriented Model Policy Model

5


OWL Ontology of WSA Concepts

L’ontologie des modèles d’architecture desweb services est représentée en OWLhttp://www.w3.org/2004/02/wsa/


Message Oriented Model of the WSA

Focuses on messages, on message structures, onthe relationship between message senders andreceivers and how messages are transmitted - withno reference as to the reasons for the messages,nor to their significance


Message Oriented Model of the WSA


Service Oriented Model of the WSA

Focuses on aspects of services and actions toexplicate the relationships between an agent andthe services it provides and requests

Builds on the MOM, but its focus is on action ratherthan message





For a web service to be compliant with this architecture there mustbe sufficient service description associated with the service toenable its use by other parties.

Ideally, a service description will give sufficient information so thatan automatic agent may not only use the service but also decide ifthe service is appropriate; that in turn implies a description of thesemantics of the service.

Web services are focused on actions. It is convenient, for thepurposes of characterizing their semantics, to capture this in termsof tasks. The semantics of any computational system is bound withthe behavior of the system and the intended semantics is boundwith some desired behavior. Tasks combine the concept of actionwith intention: web services are invoked with a given purpose inmind. The purpose can be expressed as an intended goal state.

6



Service description set of documents that describe the interface to and

semantics of a service contains the details of the interface and, potentially, the

expected behavior of the service. This includes its datatypes, operations, transport protocol information, andadress. It could also include categorization and othermetadata to facilitate discovery and utilization.

There are many potential uses of service descriptions: tofacilitate the construction and deployment of services, tolocate appropriate services, to automatically discoverappropriate provider agents in those case where requesteragents are able to make suitable choices.



Service Interface Abstract boundary that a service exposes

Defines the types of messages and the message exchangepatterns that are involved in interacting with the service,together with any conditions implied by those messages



Service Semantics Behavior expected when interacting with the service

Expresses a contract (not necessarily a legal contract)between the provider entity and the requester entity

Expresses the intended real-world effect of invoking theservice

May be formally described in a machine readable form,identified but not formally defined, or informally defined viaan out of band agreement between the provider entity andthe requester entity


Web Service Discovery

Discovery is the act of locating a machine-processabledescription of a web service-related resource that may havebeen previously unknown and that meets certain functionalcriteria It involves matching a set of functional and other criteria with a

set of resource descriptions. The goal is to find an appropriateWeb service-related resource

If a requester entity does not already know what service itwishes to engage, it must discover one Human end users or agents may initiate discovery Requester entities may find service descriptions during

development for static binding, or during execution for dynamicbinding


Web Service Discovery

A discovery service is a service that enables agentsto retrieve web service-related resource descriptions

A discovery service is used to publish (by a provider)and search (by a requester) for descriptions meetingcertain functional or semantic criteria For dynamic discovery, the requester agent may interact

directly with the discovery service to find an appropriateprovider agent to engage.

For static discovery, a human may interact with thediscovery service through an appropriate software agent,such as a browser


Web Service Discovery Process

7



The discovery service somehow obtains both theweb service description (WSD) and an associatedfunctional description (FD) of the service The FD is a machine-processable description of the

functionality (or partial semantics) of the service offered: afew words of meta data or a URI, or a TModel (in UDDI) ora collection of RDF or OWL statements

This architecture does not specify or care how thediscovery service obtains the WSD or FD if the discovery service is a search engine, then it might crawl

the Web, collecting service descriptions if the discovery service is a registry (such as UDDI), then the

provider entity needs to actively publish its WSD and FD



The requester entity supplies criteria to the discoveryservice to select a web service description based onits associated functional description, capabilities andpotentially other characteristics One might locate a service having certain desired

functionality or semantics It may also be possible to specify non-functional criteria

related to the provider (performance or reliability criteria,provider entity’s name, provider entity's vendor rating)

The discovery service returns one or more Webservice descriptions (or references to them) that meetthe specified criteria


Manual versus Autonomous Discovery

Under manual discovery, a requester human uses adiscovery service (typically at design time) to locateand select a service description

Under autonomous discovery, the requester agentperforms this task, either at design time or run time.

Although the steps are similar in either case, theconstraints and needs are significantly different Interface requirements Need for standardization Trust


Web Services Semantics

Using technologies such as WSDL, a web service can bedescribed in a machine readable document, fosteringinteroperability and permitting tools a higher degree ofautomation to the development of web services. Howevercurrent technologies are probably not yet sufficient to meetinteroperability requirements on a global scale

It should be possible to identify the real-world entitiesreferenced by elements of messages, by using standardizedontology languages, such as OWL

It should be possible to identify the expected effects of anyactions undertaken by requester and provider agents

the provider agent should be able to accurately determinewhether the requested actions are warranted


Web Services Architecture Stack

42

WSDL 2.0 Web ServicesDescription Language

http://www.w3.org/2002/ws/desc/

8


WSDL in a Nutshell

provides a model and an XML format for describingWeb services

enables one to separate the description of theabstract functionality offered by a service fromconcrete details of a service description such ashow and where that functionality is offered

is a language for describing the abstract functionalityof a service as well as a framework for describingthe concrete details of a service description


WSDL in a Nutshell

At an abstract level, WSDL describes a web servicein terms of the messages it sends and receives An operation associates a message exchange pattern with

one or more messages A message exchange pattern identifies the sequence and

cardinality of messages sent and/or received as well aswho they are logically sent to and/or received from

An interface groups together operations At a concrete level, a binding specifies transport and

wire format details for one or more interfaces An endpoint associates a network address with a binding A service groups together endpoints that implement a

common interface


WSDL in a Nutshell

A WSDL service description indicates how potentialclients are intended to interact with the describedservice. It represents an assertion that the describedservice fully implements and conforms to

A WSDL interface describes potential interactionswith a web service, not required interactions The declaration of an operation in a WSDL interface is not

an assertion that the interaction described by the operationmust occur

It is an assertion that if such an interaction is initiated, thenthe declared operation describes how that interaction isintended to occur


WSDL in a Nutshell

An XML Information Set A component model as an additional layer of

abstraction above the XML Infoset it imposes many semantic constraints over and above

structural conformance to this XML Infoset

The definition of each component includes a mapping thatspecifies how values in the component model are derivedfrom corresponding items in the XML Infoset

An XML document that is valid with respect to the WSDLXML Schema and that maps to a valid WSDL ComponentModel is conformant to the WSDL specification


WSDL Component Model

Set of components with attached properties, whichcollectively describe a Web service

Components are typed collections of properties thatcorrespond to different aspects of Web services Description, Element Declaration, Type Definition, Interface, Interface Fault, Interface Operation, Interface

Message Reference, Interface Fault Reference Binding, Binding Fault, Binding Operation, Binding

Message Reference, Binding Fault Reference, Service EndPoint


WSDL Component Model

Component Containment Hierarchy

9


Description Component

The Description component is just a container fortwo categories of components WSDL components: interfaces, bindings and services Type system components describing the constraints on a

message's content and thus message types An Element Declaration component defines the name and

content model of an element information item such as thatdefined by an XML Schema global element declaration

A Type Definition component defines the content model of anelement information item such as that defined by an XMLSchema global type definition


WSDL Infoset Diagram


Type System Components

<types><xs:schema xmlns:xs="http://www.w3.org/2001/XMLSchema"

targetNamespace="http://greath.example.com/resSvc" xmlns="http://greath.example.com/resSvc">

<xs:element name="checkAvailability" type="tCheckAvailability"/> <xs:complexType name="tCheckAvailability">

<xs:sequence> <xs:element name="checkInDate" type="xs:date"/> <xs:element name="checkOutDate" type="xs:date"/> <xs:element name="roomType" type="xs:string"/></xs:sequence>

</xs:complexType> <xs:element name="checkAvailabilityResponse" type="xs:double"/> <xs:element name="invalidDataError" type="xs:string"/>

</xs:schema></types>


Interface Component

An Interface component describes sequences ofmessages that a service sends and/or receives It does this by grouping related messages into operations An operation is a sequence of input and output messages,

and an interface is a set of operations An interface can optionally extend other interfaces

The operations directly defined on an interface are referred toas the declared operations of the interface

The interface extension mechanism behaves in a similar wayfor all other components that can be defined inside an interface,namely Interface Fault components


Interface Component

<interface name="reservationInterface"><fault name="invalidDataFault"

element= "ghns:invalidDataError"/><operation name="opCheckAvailability"

pattern="http://www.w3.org/ns/wsdl/in-out"style="http://www.w3.org/ns/wsdl/style/iri"wsdlx:safe = "true"><input messageLabel="In »

element="ghns:checkAvailability" /><output messageLabel="Out"

element="ghns:checkAvailabilityResponse"/><outfault ref="tns:invalidDataFault"

messageLabel="Out"/></operation>

</interface>


Interface Fault Component

A fault is an event that occurs during the executionof a message exchange that disrupts the normalflow of messages A fault is typically raised when a party is unable to

communicate an error condition inside the normal messageflow, or a party wishes to terminate a message exchange

A fault message may be used to communicate out of bandinformation such as the reason for the error, the origin ofthe fault, as well as other informal diagnostics such as aprogram stack trace

10


Interface Fault Component

An Interface Fault component describes a fault thatmay occur during invocation of an operation of theinterface It declares an abstract fault by naming it and indicating the

contents of the fault message Faults other than the ones described in the Interface

component may also be generated at run-time The Interface component describes faults that have

application level semantics, i.e. that the client or service isexpected to handle, and potentially recover from, as part ofthe application processing logic


Interface Operation Component

An Interface Operation component describes anoperation that a given interface supports

An operation is an interaction with the serviceconsisting of a set of (ordinary and fault) messagesexchanged between the service and the otherparties involved in the interaction

The sequencing and cardinality of the messagesinvolved in a particular interaction is governed by themessage exchange pattern used by the operation



A message exchange pattern (MEP) defines Placeholders for messages the participants in the pattern

i.e., the sources and sinks of the messages the cardinality and sequencing of messages exchanged by

the participants

The service whose operation is using the patternbecomes one of the participants of the pattern



8 predefined MEPs (WSDL 2.0 Adjuncts & WSDL 2.0Additional MEPs In-Only Robust In-Only In-Out In-Optional-Out Out-Only Robust Out-Only Out-In Out-Optional-In



An operation style specifies additional informationabout an operation For example, it may define structural constraints on the

element declarations of the interface message reference orinterface fault components used by the operation

The message placeholders defined in a messageexchange pattern are associated with specificmessage types by the operation that uses thepattern by means of message and fault references


Interface Message Reference

Defines the content of a message exchanged in anoperation By default, the message content is defined by an XML-based

type system such as XML Schema A message exchange pattern defines a set of placeholder

messages that participate in the pattern and assigns them uniquemessage labels within the pattern (e.g. 'In', 'Out')

The purpose of an Interface Message Reference component is toassociate an actual message element with a message in thepattern, as identified by its message label.

Later, when the message exchange pattern is instantiated,messages corresponding to that particular label will follow theelement assignment made by the Interface Message Referencecomponent

11


Interface Message Reference

<operation><input messageLabel="xs:NCName"?

element="union of xs:QName, xs:token"? ><documentation />*

</input><output messageLabel="xs:NCName"?

element="union of xs:QName, xs:token"? ><documentation />*

</output></operation>


Interface Fault Reference Component

Associates a defined type, specified by an InterfaceFault component, to a fault message exchanged inan operation A message exchange pattern defines a set of placeholder

messages that participate in the pattern and assigns themunique message labels within the pattern (e.g. 'In', 'Out')

The purpose of an Interface Fault Reference component isto associate an actual message type with a fault messageoccurring in the pattern

In order to identify the fault message it describes, theInterface Fault Reference component uses the messagelabel of the message the fault is associated with, as a key


Interface Fault Reference Component

<operation><infault ref="xs:QName »

messageLabel="xs:NCName"? ><documentation />*

</infault>*<outfault ref="xs:QName »

messageLabel="xs:NCName"? ><documentation />*

</outfault>*</operation>


Binding Component

Specifies concrete message format andtransmission protocol details for an interface, andmust supply such details for every operation andfault in the interface

In the general case, binding details for each operation andfault are specified using operation and fault elementsinside a binding element

However, in some cases it is possible to use defaultingrules to supply the information


Binding Component

In order to accommodate new kinds of messageformats and transmission protocols, bindings aredefined using extensions to the WSDL 2.0 language,via WSDL 2.0's open content model

WSDL 2.0 Part 2 defines binding extensions forSOAP 1.2 and HTTP 1.1 as predefined extensions,so that SOAP 1.2 or HTTP 1.1 bindings can beeasily defined in WSDL 2.0 documents


Binding Component

<binding name="reservationSOAPBinding"interface="tns:reservationInterface"type="http://www.w3.org/ns/wsdl/soap"wsoap:protocol=

"http://www.w3.org/2003/05/soap/bindings/HTTP/"><operation ref="tns:opCheckAvailability" wsoap:mep="http://www.w3.org/2003/05/soap/mep/

soap-response"/><fault ref="tns:invalidDataFault"

wsoap:code="soap:Sender"/></binding>

12


Binding Component

Binding Fault Component describes a concrete binding of a particular fault within an interface

to a particular concrete message format Binding Operation Component

describes the concrete message format(s) and protocolinteraction(s) associated with a particular interface operation for agiven endpoint

Binding Message Reference Component describes a concrete binding of a particular message participating

in an operation to a particular concrete message format Binding Fault Reference Component

describes a concrete binding of a particular fault participating in anoperation to a particular concrete message format


Service Component

Specifies a single interface that the service willsupport, and a list of endpoint locations where thatservice can be accessed The endpoints thus are alternate places at which the

service is provided Each endpoint must also reference a previously defined

binding to indicate what protocols and transmission formatsare to be used at that endpoint

A service is only permitted to have one interface


Service Component

<service name="reservationService" interface="tns:reservationInterface">

<endpoint name="reservationEndpoint" binding="tns:reservationSOAPBinding"

address="http://greath.example.com/ 2004/reservation"/>

</service>


EndPoint Component

defines the particulars of a specific endpoint atwhich a given service is available

The Binding component specified by the bindingproperty of an Endpoint component is said to beapplied to the Interface component which is thevalue of the interface property of the parent Servicecomponent of the Endpoint

If this Binding component has an interface property,its value must be the Interface component theBinding component is applied to


Mapping WSDL into RDF

XML does not provide generic rules for composing differentvocabularies, so combining for example the WSDL description of aWeb service, the service's policies and other information can bedone in many significantly different ways (e.g. extending WSDL,extending the policy language, creating a special XML container forall the information etc.), and little interoperability can be expectedwhen such combined documents are used

The Semantic web allows knowledge from many different sources tobe easily combined so that unexpected data connections can beused. The RDF graph structure, together with the use of URIs foridentifying nodes, make it very easy for different documents to bebrought together. If some WSDL document describes a Web service,a policy document expresses constraints and capabilities of theservice and a general description specifies the author of the service,all this information can be merged in RDF and the resulting graph willcontain the whole information associated with the single service



http://www.w3.org/TR/2007/NOTE-wsdl20-rdf-20070626/

XML applications that require a high level ofcomposability (or decomposability) are increasingly beingbased on RDF and OWL, which can be thought of as anadvanced schema language for RDF

WSDL 2.0 document represented in RDF can be moreeasily extended with arbitrary RDF assertions and theWSDL 2.0 information can be more easily associatedwith arbitrary other knowledge

13



WSDL constructs can be expressed in RDF by using OWLclasses of resources and assertions over individual resources Components (Interfaces, Operations, etc., including extensions)

are turned into resources identified with the appropriate URIs Things are represented as resources

Element declarations gathered from XML Schema Message content models Message exchange patterns Operation styles

All these resources are given the appropriate types using rdf:typestatements (an interface will belong to the class Interface, etc.)

All relationships in WSDL (like an Operation's belonging to anInterface and having a given operation style) are turned into RDFstatements using appropriate properties, such as operation andoperationStyle.



The main objective of this specification is to present astandard RDF and OWL vocabulary to express WSDL 2.0, sothat WSDL 2.0 documents can be transformed into RDF andmerged with other Semantic Web data

This specification can be implemented

as a standalone tool,

as part of a tool that generates WSDL descriptions (outputting theRDF form in parallel to the XML form), or

as part of a tool that processes RDF data, enabling the ability toread WSDL documents as RDF input.


WSDL Ontology Description class

The WSDL Description component is mapped to a single instance ofthe class Description, which uses the properties interface,binding and service to point to its interfaces, bindings andservices

All WSDL Interface components are represented in RDF asinstances of the Interface class

WSDL interfaces can extend other WSDL interfaces, which isindicated by the property extends

Interfaces may have operations and faults, represented asinstances of the InterfaceOperation and InterfaceFaultclasses, each pointed to with the propertiesinterfaceOperation and interfaceFault

Interfaces, operations and faults each have a name which isrepresented as a literal value of the property rdfs:label


WSDL Ontology Interface classes

Properties applicable to InterfaceOperation instances

messageExchangePattern property points to an instanceof the class MessageExchangePattern

operationStyle property points to an instance of theclass OperationStyle

interfaceMessageReference property points to aninstance of the class InterfaceMessageReference

interfaceFaultReference property points to aninstance of the class InterfaceFaultReference



Instances of InterfaceMessageReference andInterfaceFaultReference

can indicate their direction

input message references and input fault references are instances ofthe class InputMessage

output message references and output fault references are instancesof the class OutputMessage

indicate the appropriate message labels, using the propertymessageLabel which points to an instance of MessageLabelrepresenting a particular message in the operation's MEP



Instances of InterfaceMessageReference andof InterfaceFault point to element declarations (as QName instances) using

the property elementDeclaration

specify their message content model with the propertymessageContentModel, indicating one of the fourpossible instances of the class MessageContentModel.

Instances of InterfaceFaultReference refer totheir interface faults directly using the propertyinterfaceFault

14


WSDL Ontology Binding classes

WSDL binding components are represented in RDF asinstances of the class Binding

To indicate a particular interface for which bindinginformation is specified with this WSDL binding, theparticular Interface instance is pointed to using theproperty binds

Binding types (for example SOAP binding or HTTPbinding) are classes in RDF and a binding type isindicated by pointing to the appropriate class, using theproperty rdf:type

Every binding component has a name, represented as aliteral value of the property rdfs:label



The structure of bindings follows the structure of interfaces

Binding operations and faults are represented using theclasses BindingOperation and BindingFault

The Binding points to them using the propertiesbindingOperation and bindingFault.

Binding operations further contain message and faultreferences, represented as instances of the classesBindingMessageReference andBindingFaultReference, and pointed to by theproperties bindingMessageReference andbindingFaultReference



Within this structure, each component points to the appropriatecomponent from the interface structure

BindingOperation instances point toInterfaceOperation instances

BindingFault instances point to InterfaceFaultinstances

BindingMessageReference andBindingFaultReference instances point toInterfaceMessageReference andInterfaceFaultReference instances

To provide these pointers, we use the property bindsbetween the pairs of components


WSDL Ontology Service classes

WSDL services are represented in RDF as instancesof the class Service

Each service has a single interface to which it pointusing the property implements.

Each service has one or more endpoints, to which itpoints using the property endpoint.

Services have a name, represented in the RDF formas a literal value of the property rdfs:label


WSDL Ontology Service classes

Endpoints are represented as instances of the classEndpoint, with two notable properties:

a mandatory single usesBinding property points tothe binding used by this endpoint

an optional single address points to the networkresource which actually offers the service

Endpoints have a name, which is represented in theRDF form as a literal value of the propertyrdfs:label


WSDL Ontology MEP classes

WSDL defines an extensible set of MEPs, with 8 predefined ones,each following one of the three predefined fault propagation rules

In the RDF representation of WSDL MEPs are represented asinstances of the class MessageExchangePattern

The three predefined fault propagation rules are disjointsubclasses of that class, named NoFaults,FaultReplacesMessage and MessageTriggersFault

Every MEP defines a set of message labels by which messagereferences in operations can position themselves within the pattern

The message labels are represented by an IRI formed by theMEP IRI, the hash sign '#' and the actual message label

these IRIs are referenced from the MEPs with the propertydefinesMessageLabel

15


WSDL Ontology MEP classes

Predefined MEPs and their message labels: In-Only: http://www.w3.org/ns/wsdl/in-only#In Robust In-Only: http://www.w3.org/ns/wsdl/robust-in-only#In In-Out: http://www.w3.org/ns/wsdl/in-out#In

http://www.w3.org/ns/wsdl/in-out#Out In-Optional-Out: http://www.w3.org/ns/wsdl/in-opt-out#In

http://www.w3.org/ns/wsdl/in-opt-out#Out Out-Only: http://www.w3.org/ns/wsdl/out-only#Out Robust Out-Only: http://www.w3.org/ns/wsdl/robust-out-only#Out Out-In: http://www.w3.org/ns/wsdl/out-in#Out

http://www.w3.org/ns/wsdl/out-in#In Out-Optional-In: http://www.w3.org/ns/wsdl/out-opt-in#Out

http://www.w3.org/ns/wsdl/out-opt-in#In


WSDL Ontology Operation styles

WSDL 2.0 predefines 3 operation styles: RPC style, IRI style andMultipart style. These are identified with their IRIs, which are instancesof the class OperationStyle

The RPC style additionally introduces the property rpc signature,which is represented in RDF using the signature property whichcan be attached to interface operations that follow the RPC style toindicate the parameter order for the operation

The property points to an instance of the class Signature, subclassof rdf:Seq, and every member represents an argument specification

Each argument uses the property elementDeclaration to specifyan element, and the rdf:type of an argument indicates its direction(one of the classes InArgument, OutArgument, InOutArgument,ReturnArgument)


WSDL Ontology SOAP Biding

A WSDL binding that binds to SOAP

is typed (using rdf:type) as an instance of the classhttp://www.w3.org/ns/wsdl/soap

indicates the SOAP version it uses with the property version

specifies with the property protocol the underlying protocol it uses

Each SOAP binding operation specifies the SOAP message exchangepattern it uses by pointing it using the property soapMEP whose rangeis the SOAP 1.2 class that contains all the SOAP MEPs :http://www.w3.org/2006/02/soap12/abstractions#classOfMEPs

…


WSDL Ontology HTTP Biding

WSDL bindings that bind to HTTP are identified as instances of theclass http://www.w3.org/ns/wsdl/http

The HTTP bindings that make use of HTTP cookies are furtheridentified as instances of the class BindingUsingHTTPCookies

HTTP binding operations can specify a number of HTTP parameterswhich are represented in RDF with the properties location,locationIgnoreUncited, method, inputSerialization,outputSerialization, faultSerialization andqueryParameterSeparator.

…


WSDL Ontology vs Component Model

The WSDL component model consists of components, componentproperties and sets of components

The WSDL ontology supplies a set of classes, properties, datatypes,and distinguished individuals for representing WSDL data

The ontology contains axioms which express some of theconstraints the WSDL specification imposes on legal sets of WSDLcomponents whether indirectly (via the XML Schema constraints onthe infoset which canonically encodes WSDL component models) ordirectly (via the natural language of the WSDL specs, or thecorresponding Z formalization of that language)

RDF, RDFS, and OWL are all less (and differently) expressive thanthe subset of Z used to formalize the WSDL specification

In a nutshell, RDF, RDFS, and OWL are relatively small fragmentsof first order logic, whereas Z encompasses all of first order logicplus set theory. Z supports validation of component models, that is,the acceptance or rejection of component models

90

Semantic Annotations forWSDL and XML Schema

http://www.w3.org/TR/sawsdl/

16


SAWSDL in a Nutshell

SAWSDL is a set of extension attributes for WSDLand XSD that allows description of additionalsemantics of WSDL components

SAWSDL defines how semantic annotation isaccomplished using references to semantic models,e.g. ontologies

SAWSDL provides mechanisms by which conceptsfrom the semantic models, typically defined outsidethe WSDL document, can be referenced from withinWSDL and XML Schema components usingannotations



For example, SAWSDL provides a way to annotate WSDLinterfaces and operations with categorization information thatcan be used to publish a Web service in a registry

The annotations on schema types can be used during Webservice discovery and composition

In addition, SAWSDL defines an annotation mechanism forspecifying the data mapping of XML Schema types to andfrom an ontology; such mappings could be used duringinvocation, particularly when mediation is required

To accomplish semantic annotation, SAWSDL definesextension attributes that can be applied both to WSDLelements and to XML Schema elements



Among WSDL components representing service descriptions

Element Declaration, Type Definition and Interface dealwith the abstract definition of a service

Binding and Service deal with service implementation

SAWSDL focuses on semantically annotating the abstractdefinition of a service to enable dynamic discovery,composition and invocation of services

It does not address the annotation of service implementations


WSDL Model References

modelReference is an extension attribute to specifythe association between a WSDL or XML Schemacomponent and a concept in some semantic model It is used to to annotate XML Schema type

definitions, element declarations, and attributedeclarations as well as WSDL interfaces,operations, and faults.

Model references can contain multiple pointers Multiple model references all apply



SAWSDL does not define an additional container element forembeding semantic models since WSDL already allows extensionelements within a wsdl:description element

<wsdl:description ...> <rdf:RDF ...> <owl:Class rdf:ID="OrderRequest"/>

... </rdf:RDF> <wsdl:types> <xs:element name="OrderRequest"

sawsdl:modelReference="http://...#OrderRequest">...</xs:element>

</wsdl:types> </wsdl:description>



Annotating Interfaces with model references A modelReference on a WSDL interface element

provides a reference to a concept or concepts in asemantic model that describe the Interface

It enables to categorize interfaces according to somemodel

17



Annotating Oerations with model references The annotation of the operation element carries a reference to a

concept in a semantic model that provides a high leveldescription of the operation, specifies its behavioral aspects orincludes other semantic definitions

Although inputs and outputs provide one way of capturing thesemantics of an operation, a simple semantic annotationindicating the intended behavior of a given operation as a verbconcept may be useful at certain times. During service discovery,this verb provides a coarse indication of whether this service is amatch for a given request. This can act as way to reduce thenumber of services whose input and output must be checked.

Operations can also be annotated with category references



Annotating Faults with model references The annotation of the fault element carries a reference

to a concept in a semantic model that provides a highlevel description of the fault and can include othersemantic definitions

The fault annotation does not describe the faultmessage, which should be annotated in the XMLschema



Annotating XML Schema documents withmodel references Annotating simple types

Annotating complex type At complex type container level

At the member element or attribute level

Annotating elements

Annotating attributes


WSDL Schema Mappings

A Schema mapping relates the instance data defined by an XMLSchema doc with some semantic data defined by a semantic model

liftingSchemaMapping and loweringSchemaMapping are twoextension attributes that are added to XML Schema elementdeclarations and type definitions for specifying mappings betweensemantic data and XML Lifting schema mappings lift data from XML to a semantic model Lowering schema mappings lower data from a semantic model into

an XML structure Schema mappings are useful when the structure of the instance data

does not correspond trivially to the organization of the semantic data. The mappings are used when mediation code is generated to

support invocation of a Web service Schema mappings can contain multiple pointers

Multiple schema mappings are interpreted as alternatives


Mapping SAWSDL into RDF

<http://www.w3.org/ns/sawsdl#modelReference> rdf:type rdf:Property .

<http://www.w3.org/ns/sawsdl#liftingSchemaMapping>rdf:type rdf:Property .

<http://www.w3.org/ns/sawsdl#loweringSchemaMapping>rdf:type rdf:Property .