web services mario arrigoni neri. 2 risorse e servizi il semantic web si prefigge lo scopo di...

Web Services

Mario Arrigoni Neri

2

Risorse e servizi

Il semantic web si prefigge lo scopo di rappresentare e processare automaticamente le risorse disponibili sulla rete

La descrizione di una risorsa ne coglie la semantica ed include le informazioni sulla risorsa che possono essere utilizzate in maniera automatica da entità software

Non solo per scopi di visualizzazione, ma anche per un uso completo e coerente delle risorse

Le risorse statiche, che rappresentano uno stato delle cose e sono veicoli di informazione (o conoscenza) sono solo parte delle risorse disponibili sulla rete

3

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

4

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

5

I web services – 1

I Web service sono un nuovo tipo di applicazioni WEB.

Sono applicazioni auto-contenute, auto descriventi e modulari che possono essere pubblicate, localizzate ed invocate attraverso il Web.

Possono eseguire funzioni che vanno da operazioni elementari a complessi processi di business…

Una volta che un Web service è messo in linea altre applicazioni (ed altri web service) possono raggiungerlo ed invocarlo

IBM web service tutorial

6

Linguaggi di supporto

URI HTML HTTP

UDDI WSDL SOAP

Statico

Dinamico

Accesso/ricerca

Descrizione Accesso/fruizione

7

Caratteristiche dei WS

Protocolli WEB: i Web Service basati su HTTP sono progettati per essere fruiti sulla rete pubblica.

– Attraversa i firewall– Permette di operare su reti eterogenee

Interoperabilità: SOAP definisce uno standard comune che permette a sistemi differenti di dialogare indipendentemente dalle disomogeneità hardware (interplatform) e software (linguaggi)

XML: si propone ovviamente come substrato sintattico per tutti i linguaggi che sostengono la rete dei servizi

8

Tematiche classiche

Le problematiche principali per la costruzione di un sistema generale di erogazione di servizi sono:

– Interazione: occorre specificare una sintassi uniforme per rappresentare i messaggi che si scambiano i client ed i server, indipendentemente dal particolare linguaggio in cui sono implementati.SOAP come evoluzione di D-COM / CORBA

– Interfaccia: come descrivere in maniera uniforme le interfacce dei singoli componenti software?WSDL come evoluzione dell’IDL di corba

– Ricerca: modello fondamentalmente basato su elenchi pubblici: UDDI

9

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

10

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

11

Come funzionano? – SOAP

Componenti:– Il codice che deve essere pubblicato come WS– Un server SOAP (Apache Axis)– Un server HTTP (Apache)– Un client SOAP (Apache Axis)

(http trasporto)Requestor

Messaggi SOAP

Fornitore di Web ServiceEndpoint

Client SOAP

12

SOAP (Simple Object Access Protocol)

SOAP è un paradigma di dialogo tra sistemi software– Stateless: non viene gestito esplicitamente lo stato del dialogo– One-way: lo scambio di messaggi avviene secondo un semplice schema dal mittente al ricevente

Fornisce un guscio (Envelope) in cui inserire i messaggi application-dependent

L’applicazione può costruire una sovrastruttura che gestisca protocolli più complessi:– Richiesta / risposta– Richiesta / risposte multiple– Statefull connection– Ecc..

13

Il messaggio SOAP

SOAP Envelope

SOAP Header

Header Bock

Header Bock

SOAP Body

Body subelement

Body subelement

14

Il messaggio SOAP: Header

L’header SOAP (opzionale):

• meccanismo di estensione che permette di inserire nel messaggiodell’informazione extra rispetto all’applicazione

• le informazioni di controllo comprendono delle direttive, le informazioni sull’elaborazione del messaggio, ecc..

• questo meccanismo permette di estendere informazioni di controllo in maniera specifica per la specifica applicazione

• ogni blocco rappresenta un raggruppamento di informazioni e può essere indirizzato ai singoli nodi attraversati lungo la rete che possono modificarlo e/o eliminarlo fornendo valore aggiunto

15

Il messaggio SOAP: Body

• obbligatorio in ogni messaggio

• contiene le informazioni che si vogliono far passare dal mittente (initial SOAP sender) al destinatario (ultimate SOAP receiver)

• ogni nodo SOAP assume che il contenuto del corpo del messaggio sia application dependent e sia sostanzialmente comprensibile solo al destinatario finale

• il messaggio è naturalmente serializzato tramite un opportuno linguaggio XML che fa riferimento ai ns:

env = “http://www.w3.org/2003/05/soap-envelope“enc = "http://www.w3.org/2003/05/soap-encoding“rpc = "http://www.w3.org/2003/05/soap-rpc"

16

Il messaggio SOAP: Esempio

<?xml version='1.0' ?><env:Envelope xmlns:env="http://www.w3.org/2003/05/soap-envelope"> <env:Header> <m:reservation xmlns:m="http://travelcompany.example.org/reservation" env:role="http://www.w3.org/2003/05/soap-envelope/role/next" env:mustUnderstand="true">… </m:reservation>… </env:Header> <env:Body> <p:itinerary xmlns:p="http://travelcompany.example.org/reservation/travel"> <p:departure> <p:departing>New York</p:departing><p:arriving>Los Angeles</p:arriving>… </p:departure> <p:return> <p:departing>Los Angeles</p:departing> <p:arriving>New York</p:arriving> </p:return> </p:itinerary> <q:lodging xmlns:q="http://travelcompany.example.org/reservation/hotels"> <q:preference>none</q:preference> </q:lodging> </env:Body></env:Envelope>

Blocco

17

Una possibile risposta – 1

<?xml version='1.0' ?><env:Envelope xmlns:env="http://www.w3.org/2003/05/soap-envelope"> <env:Header> … </env:Header> <env:Body> <p:itineraryClarification xmlns:p="http://travelcompany.example.org/reservation/travel"> <p:departure><p:departing> <p:airportChoices>JFK LGA EWR </p:airportChoices> </p:departing></p:departure> <p:return><p:arriving> <p:airportChoices>JFK LGA EWR </p:airportChoices> </p:arriving> </p:return> </p:itineraryClarification> </env:Body></env:Envelope>

18

Una possibile risposta – 2

<?xml version='1.0' ?><env:Envelope xmlns:env="http://www.w3.org/2003/05/soap-envelope"> <env:Header> … </env:Header> <env:Body> <p:itinerary xmlns:p="http://travelcompany.example.org/reservation/travel"> <p:departure> <p:departing>LGA</p:departing> </p:departure> <p:return> <p:arriving>EWR</p:arriving> </p:return> </p:itinerary> </env:Body></env:Envelope>

19

SOAP ed RPC

Uno dei principali impieghi di SOAP è l’incapsulamento tramite XML di chiamate di procedura remote (RPC)

Per eseguire una RPC occorrono alcune informazioni:– L’indirizzo del nodo SOAP che pubblica il servizio– Il nome della procedura da invocare– Gli identificatori ed i valori da assegnare ai singoli parametri della procedura– I nomi di parametri in uscita ed il tipo del valore restituito– Il pattern di dialogo da usare per svolgere la conversazione– Eventuali dati da inserire nell’header del messaggio SOAP

20

Prenotazione tramite SOAP – 1

<?xml version='1.0' ?><env:Envelope xmlns:env="http://www.w3.org/2003/05/soap-envelope" > <env:Header> <t:transaction xmlns:t="http://thirdparty.example.org/transaction" env:encodingStyle="http://example.com/encoding" env:mustUnderstand="true" >5</t:transaction> </env:Header> <env:Body> <m:chargeReservation env:encodingStyle="http://www.w3.org/2003/05/soap-encoding" xmlns:m="http://travelcompany.example.org/"> <m:reservation xmlns:m="http://travelcompany.example.org/reservation"> <m:code>FT35ZBQ</m:code> </m:reservation> <o:creditCard xmlns:o="http://mycompany.example.com/financial"> <n:name xmlns:n="http://mycompany.example.com/employees"> Mario Rossi </n:name> <o:number>123456789099999</o:number> <o:expiration>2005-02</o:expiration> </o:creditCard> </m:chargeReservation> </env:Body></env:Envelope>

21


La chiamata RPC è inserita come sottoelemento di env:Body La procedura “changeReservation” riceve in ingresso due parametri:

– reservation (composta dal solo campo code)– creditCard (composta dai campi name, number ed expiration).

L’attributo env:encodingStyle assume un valore che indica quale convenzione è stata utilizzata per codificare i parametri, in particolare il valore http://www.w3.org/2003/05/soap-encoding indica che la struttura è stata serializzata secondo le specifiche di default di SOAP

L’header contiene un blocco:– Riservato al destinatario data l’assenza di env:role– Comunica una informazione sulla transazione (codice 5)

22


Immaginando che la RPC sia stata definita come avente due parametri in uscita: il codice della prenotazione e l’URL a cui sono raggiungibili i dettagli della stessa, oltre al valore ritornato che contiene lo stato di conferma o attesa dell’ordine.

<?xml version='1.0' ?><env:Envelope xmlns:env="http://www.w3.org/2003/05/soap-envelope" > <env:Header> … </env:Header> <env:Body> <m:chargeReservationResponse env:encodingStyle="http://www.w3.org/2003/05/soap-encoding“ xmlns:rpc="http://www.w3.org/2003/05/soap-rpc" xmlns:m="http://travelcompany.example.org/"> <rpc:result>m:status</rpc:result> <m:status>confirmed</m:status> <m:code>FT35ZBQ</m:code> <m:viewAt>http://travelcompany.example.org/reservations?code=FT35ZBQ</m:viewAt> </m:chargeReservationResponse> </env:Body></env:Envelope>

23

Estensioni – 1

SOAP fornisce un metodo standard per implementare un sistema di dialogo basato su richiesta-risposta.

– La richiesta ha la proprietà “http://www.w3.org/2003/05/soap/bindingFramework/ExchangeContext/ExchangePatternName” impostata a “http://www.w3.org/2003/05/soap/mep/soap-response/“

– E si auto-associa un identificatore tramite la proprietà “http://www.w3.org/2003/05/soap/mep/OutboundMessage”

– La risposta si associa alla richiesta tramite la stessa proprietà Errori nell’interpretazione della richiesta

<env:Envelope xmlns:env="http://www.w3.org/2003/05/soap-envelope”> <env:Header> <env:NotUnderstood qname="t:transaction" xmlns:t="http://thirdparty.example.org/transaction"/> </env:Header> <env:Body>… <env:Fault> <env:Reason> <env:Text xml:lang="en-US">Header not understood</env:Text></env:Reason> </env:Fault> </env:Body></env:Envelope>

24

Estensioni – 2

E’ possibile usare encoding diversi da quello di default di SOAP, ad esempio è possibile usare RDF

<env:Envelope xmlns:env="http://www.w3.org/2003/05/soap-envelope"> <env:Body> <rdf:RDF xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#"

xmlns:x=http://travelcompany.example.org/vocab#env:encodingStyle="http://www.w3.org/1999/02/22-rdf-syntax-ns#">

<x:ReservationRequest rdf:about="http://travelcompany.example.org/reservations?code=FT"> <x:passenger>Marco Rossi</x:passenger> <x:outbound><x:TravelRequest>

<x:to>LAX</x:to><x:from>LGA</x:from><x:date>2001-12-14</x:date> </x:TravelRequest></x:outbound> <x:return> <x:TravelRequest>

<x:to>JFK</x:to><x:from>LAX</x:from><x:date>2001-12-20</x:date> </x:TravelRequest></x:return> </x:ReservationRequest> </rdf:RDF> </env:Body></env:Envelope>

25

Binding – 1

Dato che SOAP è un linguaggio XML può usare una molteplicità di protocolli per il trasporto

GET /travelcompany.example.org/reservations?code=FT35ZBQ HTTP/1.1Host: travelcompany.example.orgAccept: text/html;q=0.5, application/soap+xml

HTTP/1.1 200 OKContent-Type: application/soap+xml; charset="utf-8"Content-Length: nnnn

<?xml version='1.0' ?><env:Envelope xmlns:env="http://www.w3.org/2003/05/soap-envelope"> …

HTTP GET

POST /Reservations HTTP/1.1Host: travelcompany.example.orgContent-Type: application/soap+xml; charset="utf-8"Content-Length: nnnn ..

HTTP POST

HTTPResponse

26

Binding – 2

From: [email protected]: [email protected]: Travel to LADate: Thu, 29 Nov 2001 13:20:00 ESTMessage-Id: <[email protected]>Content-Type: application/soap+xml

<?xml version='1.0' ?><env:Envelope xmlns:env="http://www.w3.org/2003/05/soap-envelope"> <env:Header>…

MAIL

27

WSDL

Il formato specifico dei messaggi SOAP dipende da come il servizio è stato definito a livello di RPC

WSDL (Web Service Description Language) permette di esprimere proprio queste definizioni

WSDL è un linguaggio XML che permette di descrivere servizi come insiemi di nodi (o porte) che operano sulla base di messaggi

Servizi e messaggi sono descritti:– In modo astratto, indipendente dalla particolare tecnologia– Associati alla particolare infrastruttura da utilizzare (protocollo di

trasporto)

28

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’operazione 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) … anche se …

29

Struttura di un file WSDL

Il dizionario di WSDL fa riferimento al namespace:“http://schemas.xmlsoap.org/wsdl/”

Una interfaccia WSDL è composta da una serie di definizioni inserite all’interno dell’elemento radice definitions

Ad ogni documento WSDL può essere associato un nome, che costituisce una forma semplificata di “commento”

Inoltre può essere specificato il targetNamespace, che deve essere necessariamente non locale e viene usato come contenitore

Il riferimento ad una specifica definizione WSDL (service, port, message,…) può essere fatto tramite un QName

<wsdl:definitions xmlns:wsdl=http://schemas.xmlsoap.org/wsdl name=“…” targetNamespace=“http://www.elet.polimi.it” xmlns:myNS=“http://www.elet.polimi.it”> ...</wsdl:definitions>

30

Tipi

L’elemento types contiene tutte le definizioni dei tipi

Per ragioni pragmatiche (come visto in RDF[S]), spesso si usano i tipi di XSD, ma non è un obbligo

<wsdl:definitions xmlns:wsdl=http://schemas.xmlsoap.org/wsdl name=“…”><wsdl:types>

<xsd:schema …../></wsdl:types>

</wsdl:definitions>

31

Tipi – linee guida

Usare la forma elemento-sottoelemento piuttosto che introdurre degli attributi

Non includere attributi o elementi che siano peculiari di una particolare codifica (es: soap:root)

Per definire gli array derivare il tipo dall’array definito in SOAP encoding schema

Usare xsd:anyType per campi o parametri non tipizzati

<wsdl:definitions xmlns:wsdl="http://schemas.xmlsoap.org/wsdl/" xmlns:soapenc="http://schemas.xmlsoap.org/soap/encoding/"> <wsdl:types> <schema xmlns="http://www.w3.org/2001/XMLSchema"> <complexType name="ArrayOf_xsd_string"> <complexContent> <restriction base="soapenc:Array"> <attribute ref="soapenc:arrayType" wsdl:arrayType="xsd:string[]"/> </restriction></complexContent></complexType></schema> </wsdl:types> </wsdl:definitions>

32

Messaggi

I messaggi consistono in una o più parti logiche

Ogni parte logica è associaata con un tipo utilizzando un attributo di tipo

Gli attributi di tipo sono estendibili dall’utente, ma WSDL ne definisce alcuni, tra cui:

– element: si riferisce ad un elemento XSD tramite un QName– type: si riferisce ad un tipo (semplice o complesso) tramite un QName

<definitions xmlns="http://schemas.xmlsoap.org/wsdl/“><message name=“..”> *

<part name=“..” element=“qname”? type=“qname”?/>*</message>

</definitions>

33

Messaggi: parti logiche

Le parti sono un meccanismo flessibile per astrarre elementi logici del messaggio (es: parametri di una chiamata RPC)

Il sistema di binding può far riferimento alla singola parte per specificare i dettagli implementativi

<wsdl:message name="loginRequest"> <wsdl:part name=“id" type="xsd:string"/> <wsdl:part name="pw" type="xsd:string"/> </wsdl:message>

<wsdl:types><schema …> <complexType name=“Composite”><all> <element name=“id” type=“xsd:string”/> <element name=“pw” type=“xsd:string”/> </all></complexType> </schema></wsd:types> <wsdl:message name="loginRequest"> <wsdl:part name=“composite" type=“myns:Composite”/> </wsdl:message>

34

Tipi di accessi (porte) – 1

La tipizzazione dei servizi avviene attraverso una lista di operazioni elementari, ciascuna descritta tramite:

– Tipo di interazione– Tipizzazione dei messaggi in ingresso / uscita

WSDL definisce quattro ripi di interazione:– One-way: il terminale (nodo) riceve un messaggio (procedura)– Request-response: il nodo riceve un messaggio ed invia una risposta (funzione)– Solicit-response: il nodo invia un messaggio e riceve un messaggio correlato

(interrupt)– Notification: il nodo invia un messaggio (sensore / interrupt)

<wsdl:portType name=“myServicePort"> <wsdl:operation name=“…" …/> * </wsdl:message>

35


One-way

Request-response

<wsdl:operation name="login" parameterOrder=“id pw"> <wsdl:input message="intf:loginRequest" name="loginRequest"/> <wsdl:output message="intf:loginResponse" name="loginResponse"/> <wsdl:fault name=“…” message=“…”/> </wsdl:operation>

<wsdl:operation name=“.."> <wsdl:input message=“.." name=“.. "/></wsdl:operation>

36


Solicit-response

Notification

<wsdl:operation name=“.." parameterOrder=“.."> <wsdl:output message=“" name=“.."/> <wsdl:input message=“.." name=“.."/> <wsdl:fault name=“…” message=“…”/> </wsdl:operation>

<wsdl:operation name=“.."> <wsdl:output message=“.." name=“.. "/></wsdl:operation>

37

Convenzioni

Nomi degli attributi (messaggi): è sempre necessario poter fare riferimento ad ogni messaggio per eseguirne il binding.se il nome di uno o più messaggi non viene specificato WSDL lo costruisce per default:

– One-way o Notification: omonimo dell’operazione– Request-response o Solicit-response: composto dal nome

dell’operazione e dai suffissi “Request”, “Solicit” e “Response”

In un contesto RPC è utile ricostruire la signature originaria del metodo, per questo motivo l’attributo parameterOrder elenca i parametri nell’ordine in cui compaiono nel prototipo (escluso il valore di ritorno)

38

Binding

Un binding definisce i formati ed i protocolli per le operazioni ed i messaggi definiti in un particolare portType

Possono coesistere più binding per lo stesso portType

L’associazione tra il binding ed il portType avviene tramite l’attributo type

<wsdl:binding name=“.." type=“..">… binding dependent …

<wsdl:operation name=“..”>… binding dependent …

<wsdl:input name=“..“>… binding dependent …

</wsdl:input> <wsdl:output name=“..“>

… binding dependent … </wsdl:output></wsdl:operation>

39

Binding – esempio SOAP

<wsdl:binding name=“myServiceSoapBinding" type="intf:myServicePort"> <wsdlsoap:binding style="rpc" transport="http://schemas.xmlsoap.org/soap/http"/>

<wsdl:operation name="login"> <wsdlsoap:operation soapAction=""/> <wsdl:input name="loginRequest">

<wsdlsoap:body encodingStyle="http://schemas.xmlsoap.org/soap/encoding/" namespace="http://myNamespace" use="encoded"/> </wsdl:input> <wsdl:output name="loginResponse">

<wsdlsoap:body encodingStyle="http://schemas.xmlsoap.org/soap/encoding/" namespace="http://myNamespacete" use="encoded"/> </wsdl:output> </wsdl:operation></wsdl:binding>

40

Altri Binding

HTTP GET & POST

MIME

<binding name=“..” type=“..” xmlns:http=“..”> <http:binding verb=“GET”/> <operation name=“..”> <http:operation location=“o1/A(part1)B(part2)/part3”/> <input><http:urlReplacement/></input> <output><mime:content type=“image/gif”/></output> </operation></binding>

<binding name=“..” type=“..” xmlns:http=“..”> <operation name=“..”> <output><mime:multipartRelated> <mime:part><soap:budy…/></mime:part> <mime:part><mime:content part=“docs” type=“text/html”/></mime:part> <mime:multipartRelated></output> </operation></binding>

41

Service e Ports

Un elemento service definisce un servizio tramite una serie di sottoelementi ports, che associano un nome convenzionale con lo specifico binding e l’indirizzo del nodo che fornisce il servizio

<wsdl:service name=“myServiceService"> <wsdl:port binding=“myNS:myServiceSoapBinding" name=“myService"> <wsdlsoap:address location="http://localhostservices/myService"/> </wsdl:port> </wsdl:service>

42

UDDI (Universal Description, Discovery and Integration)

UDDI fornisce un registro per servizi ed è esseziale per l’uso dinamico degli stessi

API di UDDI:– Publication API – insieme autenticato di funizioni che permettono alle

società di pubblicare servizi e specifiche di servizi– Inquiry API – insieme pubblico di funzioni che permtono all’utente di

cercare ed estrarre informazioni dai registri UDDI

Web ServiceRequestor

UDDIrepository

Web Service Provider

Invoke through SOAP

Discover or access

WSDL

RegisterWSDL

43

UDDI – classificazione – 1

UDDI classifica i bussiness ed i servizi sulla base di tassonomie

Perché classificare?

– La ricerca per parole chiave può restituire un gran numero di servizi

– La classificazione permette empiricamente una ricerca migliore e più mirata agli effettivi bisogni dell’utente

44

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

web services mario arrigoni neri. 2 risorse e servizi il semantic web si prefigge lo scopo di...

Documents