Semantic Web Services

Mario Arrigoni Neri

2

Le generazioni del WEB

Internet fase 1: contenuti statici– Pagine HTML– Risorse FTP– L’utente sa cosa vuole e dove recuperarlo

Internet fase 2: applicazioni web– Personalizzazione del livello presentation.. VB-Script, J-Script, DHTML– Contenuti dinamici (Servlet, JSP, ASP, Applet, …)– L’applicazione interagisce con l’utente

Internet fase 3: semantic web– Documenti “leggibili” da agenti artificiali– Servizi utilizzabili da agenti artificiali

3

Aspetti dinamici del sem-web

URI, HTML, HTTPStatico WWW

Infomazione•ricerca

•estrazione•rappresentazione

•interpretazione•manutenzione

RDF, RDF(S), OWLSemantic Web

UDDI, WSDL, SOAPWeb ServicesDinamico

ApplicazioniOWL-S

Semantic WS

Sintattico Semantico

4

Linguaggi di supporto

URI HTML HTTP

UDDI WSDL SOAP

Statico

Dinamico

Accesso/ricerca

Descrizione Accesso/fruizione

5

Stato dell’arte - architettura

HTTP

SOAP

WSDL

UDDI

WSDL

WS-Security

WS-Rout ing

etc…

BPEL4WS

XML

UDDI: fornisce ai client un meccanismo per trovare i web service. Un registro UDDI è simile ad un “corba trader”, o ad un DNS di applicazioni

WSDL: definisce i servizi come una collezione di terminali di rete o porte. Ogni porta è descritta da un indirizzo di rete; insiemi di porte definiscono i servizi

SOAP: fornisce un sistema standard per costruire messaggi di richiesta e le risposte fornite dai singoli servizi. Sostanzialmente è un sistema per eseguire chiamate RPC su una rete tramite HTTP (ma non solo…)

6

Ciclo di vita

RemoteWeb ServiceRepository(Web Sites)

WriteClient Code

Service Requestor

Invoke Web Service

Manual Web Service

Lookup

SOAP Request

SOAP Response

WSDL - Web Service DescriptionSOAP - Web Service Message Protocol

WSDL File

Remote Web service

Publish Web Service

1

2

3

4

5

HTTP GET

7

Il messaggio SOAP

SOAP Envelope

SOAP Header

Header Bock

Header Bock

SOAP Body

Body subelement

Body subelement

8

Elementi WSDL

Type – è il contenitore per le definizioni di tipi di dato. Ogni definizione fa riferimento ad un particolare sistema di tipi, come ad esempio XSD

Message – una definizione astratta e tipizzata dei flussi di dati da e verso il servizio

Operation – una descrizione astratta di un’azione svolta dal servizio Port type – un insieme di operazioni supportate da uno o più nodi Binding – un protocollo concreto ed una specifica del formato dei

dati per un particolare port type Port – un singolo nodo definito come la combinazione di un binding e

di un indirizo di rete Service – una collezione di nodi (interdipendenti)

9

UDDI – classificazione – 2

UDDI utilizza tre tipologie distinte di registri:

Contengono informazioni sul business: nome, descrizione, contatti

Informazioni sulla classificazione del business e sui tipi di servizi forniti

Informazioni su come ottenere (usare) un determinato servizio: es. l’URL del descrittore WSDL

White Pages

Yellow Pages

Green Pages

10

E la semantica?

Nel quadro fin qui delineato tutti i vari linguaggi descrivono la struttura di servizi e messaggi da un punto di vista sintattico

Recentemente i Web Service hanno incominciato a trarre beneficio dagli avanzamenti del Semantic Web

E’ infatti facile evidenziare vari errori dovuti a fraintendimenti sintattici:– Livello di contenuto: il servizio ritorna “Milano”, mentre il richiedente si aspetta “MI”– Livello di unità di misura: conversione da cm a pollici– Livello di messaggio: Il servizio restituisce una estensione come la coppia <larghezza, altezza>, mentre il cliente

richiede l’area

11

Servizi “semantic based”

Ricerca automatica del servizio: WS adatti ad erogare il servizio richiesto. L’informazione necessaria per la ricerca viene fornita in maniera machine-processable (semantic UDDI). Il formalismo dovrebbe essere usato dal responsabile del servizio per pubblicarlo

Invocazione automatica:– Invocazione manuale: l’utente compila una form / codifica un codice che invia messaggi SOAP / usa un’interfaccia

SOAP generata automaticamente– Partendo dalla descrizione formale di altro livello del servizio l’invocazione viene eseguita automaticamente

Composizione di servizi: data una descrizione del servizio desiderato e dei servizi disponibili, un sistema artificiale è in grado di comporre WS semplici per costruire servizi complessi

Monitoraggio dell’esecuzione: con una rappresentazione della struttura dinamica del servizio si può tenere traccia dello stato corrente ed eventualmente del punto nel workflow in cui si è verificato un errore

12

OWL-S

Come descrivere la semantica?– Alcuni tentativi autonomi nati all’interno della comunità dei WS– Dato che esistono linguaggi generali per descrivere ontologie (OIL, DAML+OIL, OWL), perché non usare quelli?– In realtà OWL-S (OWL for Services) non è altro che una particolare (TOP) ontology per la descrizione di servizi

Occorre evidenziare i principali concetti da rappresentare: domande– Cosa richiede il servizio agli utenti (umani/artificiali) e cosa fornisce loro?

Service Profile

– Come opera? Service Model

– Come viene usato? Service Grounding

13

OWL-S top ontology

ser:Service

rdfs:range

owl:inverseOf

xmlns:ser = “http://www.daml.org/services/owl-s/1.0/Service.owl#”

ser:provides

owl:Thing

ser:providedBy

rdfs:domain

rdfs:range rdfs:domain

ser:ServiceProfile ser:presents

ser:presentedBy

owl:inverseOf

rdfs:domain

rdfs:range

ser:ServiceModel

ser:describedBy

rdfs:domain

rdfs:range

ser:describes

owl:inverseOf

ser:ServiceGrounding

ser:supportsrdfs:domain

rdfs:range

ser:supportedBy

owl:inverseOf

Un servizio ha al più un modelloUn grounding è supportato da uno ed un solo servizio

14

OWL-S top ontologyP

roce

ss M

odel

Gro

undi

ng

Development … Deployment … Use …

Publication

Simulation

Verification

Discovery

Composition

Selection

Invocation, Interoperation

Monitoring, Recovery

Pro

file

15

Service Profile – 1

Che organizzazione fornisce il servizio?

Tre relazioni (non funzionali):– serviceName: fornisce il nome del servizio, può essere utilizzato come

identificativo del servizio– textDescription: breve descrizione del servizio.– contactInformation: fornisce un riferimento a persone responsabili del

servizio.Il range della relazione può essere ristretto a seconda delle necessità:FOAF, VCard, ecc..

<owl:ObjectProperty rdf:ID=“contactInformation”><rdfs:domain rdf:resource=“#Profile”/>

</owl:ObjectProperty>

xmlns:prof = “http://www.daml.org/services/owl-s/1.0/Profile.owl#”

16

Service Profile – 2

Che funzione fornisce il servizio?

Definito tramite IOPE (relazioni funzionali):– Input: flusso di dati in ingresso (numero di carta di credito)– Output: flusso di dati in uscita (ricevuta)– Precondition: vincoli sullo stato del mondo (carta valida)– Effects: effetti sul mondo reale (addebito sulla carta)

L’ontologia del profilo non fornisce un vocabolario specifico, ma prende in prestito quello (più esteso) dell’ontologia di processo

17

Service Profile – 3

Quali caratteristiche ha il servizio?

owl:Thing

prof:serviceParameter

ser:ServiceProfile

prof:Profile

rdfs:subClassOf

prof:ServiceParameter

prof:ServiceCategoryprof:serviceCategory

xsd:stringprof:serviceParameterName

prof:sParameter

xsd:stringprof:categoryName

prof:taxonomy

prof:value

prof:code

18

Service Model – 1

La descrizione del servizio si affida all’ontologia dei processi:

prof:hasProcess

ser:ServiceModel

proc:ProcessModel

rdfs:subClassOf

proc:Process

proc:AtomicProcess

proc:SimpleProcess

proc:CompositeProcess

owl:disjointWith

U

=

19

Service Model – 2

IO (PE)

proc:Process proc:hasParameter proc:Parameter

proc:hasInput proc:Input

proc:hasOutput proc:ConditionalOutput

rdfs:domainrdfs:subPropertyOf

rdfs:subPropertyOf rdfs:subClassOf

rdfs:subClassOf

proc:coConditionproc:Condition

proc:UnConditionalOutput

rdfs:subClassOfrdfs:domain

20

Service Model – 3

(IO) PE

proc:Process proc:hasPrecondition proc:Precondition

proc:hasEffect proc:ConditionalEffect

rdfs:domain

proc:ceConditionproc:Condition

proc:UnConditionalEffect

rdfs:subClassOfrdfs:domain

rdfs:domain rdfs:range

rdfs:range

21

Service Model – 4

Unconditional Effect / Output

proc:ConditionalEffect

owl:onProperty

proc:ceConditionproc:UnConditionalEffect

rdfs:subClassOf

owl:Restriction

0

owl:cardinality

∩

=

proc:ConditionalOutput

owl:onProperty

proc:coConditionproc:UnConditionalOutput

rdfs:subClassOf

owl:Restriction

0

owl:cardinality

∩

=

22

Service Model – 5

Rapporti tra tipi di processi

proc:AtomicProcess proc:SimpleProcess proc:CompositeProcessrealizesrealizedBy

expandcollapse

proc:ControlConstructcomposedBy

proc:ProcessComponent

Uproc:Process

=

components

proc:Sequence proc:Repeatuntil…

rdfs:subClassOf

23

Service Model – 6

ControlConstruct

proc:ControlConstruct

proc:Split-Joinproc:Repeat-While

owl:onProperty

proc:components owl:Restriction

owl:allValuesFrom ∩

proc:ProcessComponentBag

rdf-sh:List

owl:subClassOf

proc:ProcessComponent

owl:Restriction

rdf-sh:first

owl:allValuesFrom

owl:Restriction

rdf-sh:rest

owl:allValuesFrom owl:subClassOf

owl:subClassOf

proc:whileProcess

owl:domain

owl:range

proc:Condition

proc:whileCondition

24

Il problema del binging

In vari momenti è necessario identificare componenti IOPE tra i loro:– Associare input e precondizioni ed output con gli effetti– Associare i/o dei processi composti con quelli dei componenti– Associare input ed output di sottoprocessi tra di loro

Soluzione standard: uso le variabili (ovviamente) OWL non permette di usare in maniera “nativa” delle associazioni tra variabili

proc:ProcessComponent proc:sameValues rdf:Listrdfs:domain rdfs:range

proc:ValueOfproc:atProcess proc:theParameter

proc:Process proc:Parameterrdfs:domain rdfs:domain

25

Il Grounding

Il Grounding associa al servizio il modo in cui può essere effettivamente utilizzato

E’ possibile associare un grounding solo a servizi con processo atomico

Tecniche particolari per il grounding comportano la derivazione di sottoclassi di “ServiceGrounding”, come ad esempio “WSDLGrounding”

Ogni messaggio è da intendersi astratto, fino a quando non viene interessato da una risorsa di tipo “ServiceGrounding”

26

OWL-S e WSDL

Il grounding WSDL fornisce una (complessa) ontologia per associare ogni “pezzo” di OWL-S ad un frammento WSDL– Un processo atomico con in ed out corrisponde a una operazione request-response– Un processo atomico con input ma senza output corrisponde ad una operazione one-way– Processi con output ma senza input corrispondono alle operazioni di notifica– Un processo composto con input ed putput, e con l’invio dell’output precedente alla ricezione dell’input è un’operazione solicit-response.

OWL-S

WSDL

Process Model DL-Based Types

Atomic Process

Operation Message

Inputs / Outputs

Binding (SOAP)

27

Associazione con un WSDL – 1

Sono dati tre casi:– In una parte della definizione del messaggio WSDL l’attributo owl-s-attribute indica l’URI della descrizione OWL dell’oggetto in input e/o output. In questo caso seguendo il ramo parameterType in OWL-S si ottiene la descrizione semantica– Se una parte del messaggio usa un tipo OWL è possibile definire l’attributo encodingStyle=“http://www.w3.org/2002/07/owl” – In tutti gli elementi operation in WSDL l’attributo owl-s-process può indicare il processo atomico in OWL-S

gro:WsdlGrounding gro:hasAtomicProcessGrounding gro:WsdlAtomicProcessGrounding

rdfs:domain rdfs:range

gro:wsdlVersiongro:wsdlDocumentgro:wsdlOperationgro:wsdlnputMessagegro:wsdOutputMessagegro:wsdlnputsgro:wsdOutputs

WSDL

OWL-S

28

Associazione con un WSDL – 2

gro:WsdlAtomicProcessGrounding

gro:wsdlMessagePart

gro:wsdlnputsgro:WsdlinputMessageMap

xsd:string

proc:Parameter

gro:owlsParameter

owl:Thing

gro:xsltTransformation

Caso sempliceCaso complesso

Come traduco i messaggi da OWL-S a WSDL ?

29

Risorse

I servizi, in quanto processi, operano su risorse OWL-S fornisce una rudimentale ontologia delle risorse, che le distingue a seconda della loro natura Allocation Types

– ConsumableAllocation– ReusableAllocation

Capacity Types– DiscreteCapacity– ContinuousCapacity

Resource Composition– AtomicResource

UnitCapacityResource BatchCapacityResource

– AggregateResource ConjunctiveAggregateResource DisjunctiveAggregateResource

reusable(R) & use(A,R,T) capacity(R, start(T)) = capacity(R, end(T))

consumable(R) & use(A,R,T) capacity(R, start(T)) > capacity(R, end(T))

replenish(A,R,T) capacity(R, start(T)) < capacity(R, end(T))