Web Services Mario Arrigoni Neri

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

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

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

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

Linguaggi di supporto UDDI WSDL SOAP URI HTML HTTP Dinamico Statico Accesso/ ricerca Descrizione Accesso/ fruizione

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

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

Stato dell’arte - architettura 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…) WS-Security WS-Routing etc… WSDL BPEL4WS XML UDDI WSDL SOAP HTTP

Ciclo di vita 2 3 1 4 5 WSDL - Web Service Description Remote Web Service Repository (Web Sites) Write Client Code Service Requestor Invoke Web Service Manual Lookup SOAP Request SOAP Response WSDL - Web Service Description SOAP - Web Service Message Protocol WSDL File Web service Publish Web 1 2 3 4 5 HTTP GET

Come funzionano? – SOAP Requestor (http trasporto) Messaggi SOAP Client SOAP Endpoint Fornitore di Web Service Componenti: Il codice che deve essere pubblicato come WS Un server SOAP (Apache Axis) Un server HTTP (Apache) Un client SOAP (Apache Axis)

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..

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

Il messaggio SOAP: Header L’header SOAP (opzionale): meccanismo di estensione che permette di inserire nel messaggio dell’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

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"

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

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>

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>

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

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>

Prenotazione tramite SOAP – 2 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)

Prenotazione tramite SOAP – 3 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>

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>

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>

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.1 Host: travelcompany.example.org Accept: text/html;q=0.5, application/soap+xml HTTP GET POST /Reservations HTTP/1.1 Host: travelcompany.example.org Content-Type: application/soap+xml; charset="utf-8" Content-Length: nnnn .. HTTP POST HTTP/1.1 200 OK Content-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 Response

Binding – 2 MAIL From: a.oyvind@mycompany.example.com To: reservations@travelcompany.example.org Subject: Travel to LA Date: Thu, 29 Nov 2001 13:20:00 EST Message-Id: <EE492E16A090090276D208424960C0C@mycompany.example.com> Content-Type: application/soap+xml <?xml version='1.0' ?> <env:Envelope xmlns:env="http://www.w3.org/2003/05/soap-envelope"> <env:Header>… MAIL

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)

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 …

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>

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>

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>

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>

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>

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>

Tipi di accessi (porte) – 2 One-way Request-response <wsdl:operation name=“.."> <wsdl:input message=“.." name=“.. "/> </wsdl:operation> <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>

Tipi di accessi (porte) – 3 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>

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)

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=“..”> <wsdl:input name=“..“> </wsdl:input> <wsdl:output name=“..“> </wsdl:output> </wsdl:operation>

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>

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>

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>

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 Invoke through SOAP Web Service Requestor Web Service Provider Discover or access WSDL Register WSDL UDDI repository

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

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