La presentazione è in caricamento. Aspetta per favore

La presentazione è in caricamento. Aspetta per favore

Semantic Web Services Mario Arrigoni Neri. 2 Le generazioni del WEB Internet fase 1: contenuti statici – Pagine HTML – Risorse FTP – Lutente sa cosa vuole.

Presentazioni simili


Presentazione sul tema: "Semantic Web Services Mario Arrigoni Neri. 2 Le generazioni del WEB Internet fase 1: contenuti statici – Pagine HTML – Risorse FTP – Lutente sa cosa vuole."— Transcript della presentazione:

1 Semantic Web Services Mario Arrigoni Neri

2 2 Le generazioni del WEB Internet fase 1: contenuti statici – Pagine HTML – Risorse FTP – Lutente 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, …) – Lapplicazione interagisce con lutente Internet fase 3: semantic web – Documenti leggibili da agenti artificiali – Servizi utilizzabili da agenti artificiali

3 3 Aspetti dinamici del sem-web URI, HTML, HTTP Statico WWW Infomazione ricerca estrazione rappresentazione interpretazione manutenzione RDF, RDF(S), OWL Semantic Web UDDI, WSDL, SOAP Web Services Dinamico Applicazioni OWL-S Semantic WS SintatticoSemantico

4 4 Linguaggi di supporto URI HTMLHTTP UDDI WSDLSOAP Statico Dinamico Accesso/ ricerca DescrizioneAccesso/ fruizione

5 5 Stato dellarte - architettura HTTP SOAP WSDL UDDI WSDL WS-Security WS-Routing 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 6 Ciclo di vita Remote Web Service Repository (Web Sites) Write Client Code Service Requestor Invoke Web Service Manual Web Service Lookup SOAP Request SOAP Response WSDL - Web Service Description SOAP - Web Service Message Protocol WSDL File Remote Web service Publish Web Service HTTP GET

7 7 Il messaggio SOAP SOAP Envelope SOAP Header Header Bock SOAP Body Body subelement

8 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 unazione 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 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. lURL del descrittore WSDL White Pages Yellow Pages Green Pages

10 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, mentre il cliente richiede larea

11 11 Servizi semantic based Ricerca automatica del servizio: WS adatti ad erogare il servizio richiesto. Linformazione 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: lutente compila una form / codifica un codice che invia messaggi SOAP / usa uninterfaccia SOAP generata automaticamente – Partendo dalla descrizione formale di altro livello del servizio linvocazione 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 dellesecuzione: 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 12 OWL-S Come descrivere la semantica? – Alcuni tentativi autonomi nati allinterno 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 13 OWL-S top ontology ser:Service rdfs:range owl:inverseOf xmlns:ser = ser:provides owl:Thing ser:providedBy rdfs:domain rdfs:range rdfs:domain ser:ServiceProfileser:presents ser:presentedBy owl:inverseOf rdfs:domain rdfs:range ser:ServiceModel ser:describedBy rdfs:domain rdfs:range ser:describes owl:inverseOf ser:ServiceGrounding ser:supports rdfs:domain rdfs:range ser:supportedBy owl:inverseOf Un servizio ha al più un modello Un grounding è supportato da uno ed un solo servizio

14 14 OWL-S top ontology Process Model Grounding Development … Deployment … Use … Publication Simulation Verification Discovery Composition Selection Invocation, Interoperation Monitoring, Recovery Profile

15 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.. xmlns:prof =

16 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) Lontologia del profilo non fornisce un vocabolario specifico, ma prende in prestito quello (più esteso) dellontologia di processo

17 17 Service Profile – 3 Quali caratteristiche ha il servizio? owl:Thing prof:serviceParameter ser:ServiceProfile prof:Profile rdfs:subClassOf prof:ServiceParameter prof:ServiceCategory prof:serviceCategory xsd:string prof:serviceParameterName prof:sParameter xsd:string prof:categoryName prof:taxonomy prof:value prof:code

18 18 Service Model – 1 La descrizione del servizio si affida allontologia dei processi: prof:hasProcess ser:ServiceModel proc:ProcessModel rdfs:subClassOf proc:Process proc:AtomicProcess proc:SimpleProcess proc:CompositeProcess owl:disjointWith U =

19 19 Service Model – 2 IO (PE) proc:Processproc:hasParameterproc:Parameter proc:hasInputproc:Input proc:hasOutputproc:ConditionalOutput rdfs:domain rdfs:subPropertyOf rdfs:subClassOf proc:coConditionproc:Condition proc:UnConditionalOutput rdfs:subClassOf rdfs:domain

20 20 Service Model – 3 (IO) PE proc:Processproc:hasPreconditionproc:Precondition proc:hasEffectproc:ConditionalEffect rdfs:domain proc:ceConditionproc:Condition proc:UnConditionalEffect rdfs:subClassOf rdfs:domain rdfs:range

21 21 Service Model – 4 Unconditional Effect / Output proc:ConditionalEffect owl:onProperty proc:ceCondition proc:UnConditionalEffect rdfs:subClassOf owl:Restriction 0 owl:cardinality = proc:ConditionalOutput owl:onProperty proc:coCondition proc:UnConditionalOutput rdfs:subClassOf owl:Restriction 0 owl:cardinality =

22 22 Service Model – 5 Rapporti tra tipi di processi proc:AtomicProcessproc:SimpleProcessproc:CompositeProcess realizes realizedBy expand collapse proc:ControlConstruct composedBy proc:ProcessComponent U proc:Process = components proc:Sequenceproc:Repeatuntil … rdfs:subClassOf

23 23 Service Model – 6 ControlConstruct proc:ControlConstruct proc:Split-Join proc:Repeat-While owl:onProperty proc:componentsowl: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 proc:whileProcess owl:domain owl:range proc:Condition proc:whileCondition

24 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:sameValuesrdf:List rdfs:domainrdfs:range proc:ValueOfproc:atProcessproc:theParameter proc:Processproc:Parameter rdfs:domain

25 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 esempioWSDLGrounding Ogni messaggio è da intendersi astratto, fino a quando non viene interessato da una risorsa di tipo ServiceGrounding

26 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 linvio delloutput precedente alla ricezione dellinput è unoperazione solicit-response. OWL-S WSDL Process ModelDL-Based Types Atomic Process OperationMessage Inputs / Outputs Binding (SOAP)

27 27 Associazione con un WSDL – 1 Sono dati tre casi: – In una parte della definizione del messaggio WSDL lattributo owl-s-attribute indica lURI della descrizione OWL delloggetto 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 lattributo encodingStyle=http://www.w3.org/2002/07/owl – In tutti gli elementi operation in WSDL lattributo owl-s-process può indicare il processo atomico in OWL-S gro:WsdlGrounding gro:hasAtomicProcessGrounding gro:WsdlAtomicProcessGrounding rdfs:domainrdfs:range gro:wsdlVersion gro:wsdlDocument gro:wsdlOperation gro:wsdlnputMessage gro:wsdOutputMessage gro:wsdlnputs gro:wsdOutputs WSDL OWL-S

28 28 Associazione con un WSDL – 2 gro:WsdlAtomicProcessGrounding gro:wsdlMessagePart gro:wsdlnputs gro:WsdlinputMessageMap xsd:string proc:Parameter gro:owlsParameter owl:Thing gro:xsltTransformation Caso semplice Caso complesso Come traduco i messaggi da OWL-S a WSDL ?

29 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))


Scaricare ppt "Semantic Web Services Mario Arrigoni Neri. 2 Le generazioni del WEB Internet fase 1: contenuti statici – Pagine HTML – Risorse FTP – Lutente sa cosa vuole."

Presentazioni simili


Annunci Google