2. Un Web service è un sistema software progettato per
supportare l'interoperabilità machine-to-machine su una
rete. Ha un'interfaccia descritta in un formato leggibile
da una macchina (specificamente WSDL). Altri sistemi
interagiscono con il servizio Web in un modo previsto
dalla sua descrizione WSDL usando messaggi SOAP, in
genere trasmessi tramite HTTP in formato XML con altri
standard web previsti per una architettura SOA.
(definizione del W3C)
Cosa sono i Web Services
3. Le applicazioni client interagiscono con la
componente di logica applicativa utilizzando un
protocollo di trasporto ed una struttura dati ad-hoc
molto spesso proprietaria e legata al linguaggio di
programmazione utilizzato.
Architettura 3 tier
4. L’utilizzo dei web services consente di disaccoppiare
l’invocazione del Client dalla logica applicativa
interponendo uno strato che consente di esporre il
servizio utilizzando un protocollo di trasporto e di
struttura dati standard
Architettura basata su servizi
5. I Web Services solitamente utilizzano come:
protocollo di trasporto HTTP
protocollo dati XML (SOAP)
HTTP è un protocollo semplice, leggero, robusto e ben
tollerato anche dai sistemi di sicurezza più avanzati.
XML è un protocollo aperto e altamente versatile che ha
permesso la definizione del protocollo SOAP che
garantisce ricchezza espressiva, estendibilità, portabilità e
facilità di comprensione.
Protocolli utilizzati
6. I web services sono creati da dei produttori, catalogati in
un registro pubblico per poi essere ricercati ed utilizzati dai
consumatori, secondo questi passaggi logici.
1. Il produttore costruisce il servizio e lo descrive
utilizzando il linguaggio WSDL, registra il servizio nel
registry UDDI utilizzato per catalogare i servizi e basato
su XML
2. Il consumatore cerca il servizio nel registro UDDI, ottiene
la descrizione WSDL del servizio
3. Il consumatore dialoga con il WS utilizzando SOAP
Modello del servizio
9. SOAP è un protocollo leggero che permette di
scambiare informazioni in ambiente distribuito:
SOAP è basato su XML.
SOAP gestisce informazione strutturata.
SOAP gestisce informazione tipata.
SOAP non definisce alcuna semantica per applicazioni
o scambio messaggi, ma fornisce un mezzo per
definirla.
Simple Object Access Protocol
10. Il principale svantaggio di SOAP è costituito proprio
dalla sua natura testuale, che lo rende molto meno
performante rispetto alle sue controparti binarie
(CORBA e .NET Remoting).
SOAP non definisce semantiche per i dati e le
chiamate, ma tramite l'uso dei Namespaces XML,
SOAP permette di dichiararne la semantica usando
grammatiche XML definite nei namespaces.
Svantaggi e potenzialità
11. Un messaggio SOAP è composto da:
1. Un elemento radice, envelope,
obbligatorio.
Il namespace di SOAP viene dichiarato
all’interno di questo elemento
2. Un elemento header opzionale.
Il suo scopo è quello di trasportare
informazioni non facenti parte del
messaggio, destinate alle varie parti che il
messaggio attraverserà per arrivare al suo
destinatario finale.
3. Un elemento body obbligatorio.
Questo elemento contiene il messaggio vero
e proprio.
Struttura SOAP
14. SOAP non è altro che un documento XML che segue
determinate regole.
Per maneggiare un documento SOAP si possono
usare quindi gli stessi strumenti utilizzati per i
documenti XML
Un documento SOAP deve rispettare le regole di
formattazione e validazione
SOAP e XML
15. Un documento XML deve essere ben formato
1. deve iniziare con la dichiarazione: <? xml version=“1.0” ?>
2. deve avere un unico elemento radice.
3. tutte i tag che si aprono devono essere chiusi
4. se un elemento è vuoto, ossia non contiene nessun
elemento di testo al suo interno, può essere anche
rappresentato con una forma speciale di tag: <foto />
5. Si deve rispettare il maiuscolo/minuscolo (case-sensitive)
6. Tutti gli elementi debbono essere annidati propriamente
7. Tutti i valori degli attributi vanno espressi tra doppi apici.
Formattazione XML
16. Un documento XML deve essere valido cioè deve
rispettare una “grammatica”, ossia deve rispettare
una struttura ed una grammatica degli elementi che
compongono i documenti scambiati.
E' possibile utilizzare come descrittore un DTD
(Document Type Definition) o una maniera ancor più
espressiva tramite un XML Schema (XSD)
Validazione XML
18. WSDL è un linguaggio di tipo XML per descrivere
servizi di rete come un insieme di punti terminali
operanti su messaggi contenenti informazione di tipo
“documentale” o “procedurale”.
Solitamente viene creato dal produttore del servizio
al fine di esporre le modalità di invocazione
(endpoint, protocollo, operazione, parametri di
input/output) e successivamente viene pubblicato nel
registry UDDI al fine della visibilità in rete.
Web Service Definition Language
19. WSDL cerca di separare gli aspetti “astratti” della descrizione
di un servizio da quelli “concreti” che lo legano a particolari
protocolli di rete o di RPC.
1. Livello astratto: il servizio viene definito genericamente
riferendosi alle operazioni offerte (interfacce) e al tipo di
messaggi scambiati per ciascuna di esse.
2. Livello concreto: le descrizioni astratte vengono
istanziate legandole a una implementazione reale
(protocolli, indirizzi di rete, ecc.).
Livelli di definzione del servizio
20. La descrizione astratta di un servizio web è composta:
1. Dalla definizione del tipo di messaggi scambiati tra
client e server durante la fruizione del servizio.
2. Dalla definizione delle operazioni tramite le quali si
interagisce col servizio scambiando messaggi.
3. Dalla definizione delle porte astratte di connessione,
cioè collezioni di operazioni (interfacce) esposte dal
servizio.
Descrizione astratta
21. La descrizione concreta di un servizio web è
composta:
1. Dai binding che legano ciascuna porta astratta a un
protocollo e a un formato dati per i messaggi
scambiati.
2. Dalle porte, che legano le porte astratte istanziate dai
binding a indirizzi di rete reali.
3. Dai servizi, composti da insiemi di porte correlate (che
spesso offrono modalità differenti di accesso alla
stessa tipologia di servizio).
Descrizione concreta
22. <definitions>
<types>
i tipi di dati che verranno trasmessi
</types>
<message>
i messaggi scambiati
</message>
<portType>
le operazioni (funzioni) supportate
</portType>
<binding>
come si scambiano i messaggi (dettagli SOAP) e protocollo di comunicazione
</binding>
<service>
dove trovare il servizio
</service>
</definitions>
Struttura del WSDL
26. Il root element di un WSDL è costituito dal tag definitions il quale
contiene la definizione dei namaspace utilizzati. In particolare definisce
i namespace pubblici delle specifiche WSDL, SOAP E XSD e namespace
di progetto usati per la definizione dei documenti di stile.
<wsdl:definitions name="serverProva"
targetNamespace=http://www.prometheo.it/corsoWS
xmlns:corsoWS=http://www.prometheo.it/corsoWS
xmlns:soap=http://schemas.xmlsoap.org/wsdl/soap/
xmlns:wsdl=http://schemas.xmlsoap.org/wsdl/
xmlns:xsd=http://www.w3.org/2001/XMLSchema>
…
</wsdl:definitions>
Il Root element: tag definitions
27. Passiamo in rassegna gli elementi del WSDL partendo dall’ultimo.
Il tag service definisce il servizio, i riferimenti al binding dei
dettagli del servizio tramite un nome logico, i riferimenti della
location dove il servizio è esposto.
<wsdl:service name="serverProva">
<wsdl:port binding="corsoWS:serverProvaSOAP" name="serverProvaSOAP">
<soap:address location="http://EIDOS-NBGDT:8088/mockserverProvaSOAP"/>
</wsdl:port>
</wsdl:service>
Servizio esposto: tag service
28. Il tag binding definisce il formato del messaggio, i dettagli del
protocollo per ogni Port ed il SoapAction.
<wsdl:binding name="serverProvaSOAP" type="corsoWS:serverProva">
<soap:binding style="document" transport="http://schemas.xmlsoap.org/soap/http"/>
<wsdl:operation name="hello">
<soap:operation soapAction="http://www.prometheo.it/corsoWS/hello"/>
<wsdl:input><soap:body use="literal"/></wsdl:input>
<wsdl:output><soap:body use="literal"/></wsdl:output>
</wsdl:operation>
</wsdl:binding>
Formato dei messaggi:tag binding
29. Il PortType descrive il servizio, le operazioni che possono essere
eseguite e i messaggi che sono coinvolti in queste operazioni.
Può essere paragonato ad una libreria di funzioni (o un modulo,
o una classe) in un tradizionale linguaggio di programmazione.
<wsdl:portType name="serverProva">
<wsdl:operation name="hello">
<wsdl:input message="corsoWS:helloRequest"/>
<wsdl:output message="corsoWS:helloResponse"/>
</wsdl:operation>
</wsdl:portType>
Dettagli del servizio: tag portType
30. L'elemento <message> definisce gli elementi di dati di una
operazione. Ogni messaggio può essere costituito da una o più
parti. Le parti possono essere paragonate a dei parametri di una
chiamata di funzione in un linguaggio di programmazione
tradizionale.
<wsdl:message name="helloRequest">
<wsdl:part element="corsoWS:helloRequest" name="parameters"/>
</wsdl:message>
<wsdl:message name="helloResponse">
<wsdl:part element="corsoWS:helloResponse" name="parameters"/>
</wsdl:message>
Elementi dei messaggi: tag message
31. Questo tag serve per contente o importare l’XSD utilizzato per
definire i tag dell’XML oggetto di scambio del payload SOAP
<wsdl:types>
<xsd:schema targetNamespace="http://www.prometheo.it/corsoWS">
<xsd:element name="helloRequest">
<xsd:complexType>
<xsd:sequence><xsd:element name="nomeUtente" type="xsd:string"/></xsd:sequence>
</xsd:complexType>
</xsd:element>
<xsd:element name="helloResponse">
<xsd:complexType>
<xsd:sequence><xsd:element name="echoUtente" type="xsd:string"/></xsd:sequence>
</xsd:complexType>
</xsd:element>
</xsd:schema>
</wsdl:types>
XSD del messaggio XML: tag types
32. Gli stili di invocazione dei messaggi possono essere di
Document o RPC
Document style: si adotta quando i servizi richiedono di
scambiarsi veri e propri documenti/dati XML
Il Body contiene il contenuto informativo del
messaggio formattato in XML
Il documento scambiato può avere struttura e
contenuti qualunque, non definiti a priori
Stili di invocazione
33. RPC style: si adotta quando si vuole invocare una procedura
remota
Utilizza una struttura del corpo del messaggio
convenzionale che rappresenta le informazioni necessarie
per una RPC: nome della procedura o metodo, segnatura
(opzionale), parametri
La risposta della RPC (cioè il valore di ritorno della
chiamata) è restituita nel Body di un altro messaggio
SOAP, secondo il meccanismo richiesta-risposta (p.e: la
chiamata è inviata mediante request HTTP e la risposta
fornita come response HTTP)
Stili di invocazione
34. RPC:
Realizza un’invocazione di procedura
Basata sulla segnatura della procedura
Sincrona
Effettua il marshalling/unmarshalling dei parametri da/verso XML
Document
Sia sincrona che asincrona
Basata sui contenuti del documento
Usata quando si devono scambiare dati semi strutturati e di una
certa dimensione
Stile in sintesi
35. L’operation è l’unità di interazione elementare con un Web
service, ed è eseguita attraverso lo scambio di messaggi.
Convenzionalmente:
1. input messages: inviati dall’utilizzatore al Service
2. output messages: messaggi inviati dal Service.
L’interazione con i Web Services può essere asincrona.
Scambi asincroni possono verificarsi all’interno di una
operazione a due messaggi, oppure tra due operazioni a
messaggio singolo
Operazioni e messaggi asincroni
36. Un’operazione può essere:
1. request-response: il service riceve una richiesta(input
message) e restituisce la risposta relativa(output message)
2. solicit-response: il service invia un messaggio (output
message) e riceve una risposta (input message)
3. one-way:il service riceve un messaggio (input message)
4. notification: il servizio invia un messaggio (output message)
A queste operazioni corrispondono diverse combinazioni di
messaggi in input e output
MEP : Message Exchange Patterns
37. A fronte di una richiesta si aspetta una risposta (esempio: servizio
web)
<operation name="op1">
<input name="op1Request" message="..." />
<output name="op1Response" message="..." />
<fault name="op1Fault" message="..." />
</operation>
Request / Response
38. Viene ricevuto un messaggio di output che scatena un evento una
invocazione (esempio: messaggio promozionale di acquisto)
<operation name="op2">
<output name="op2Solicit" message="..." />
<input name="op2Response" message="..." />
<fault name="op2Fault" message="..." />
</operation>
Solicit/Response
39. Viene previsto l’invio di un messaggio al quale non fa seguito una
risposta (esempio: logging )
<operation name="op3">
<input name="op3in" message="..." />
</operation>
One-Way
40. Viene effettuata una notifica a seguito di un’azione precedente
(esempio: mail di notifica)
<operation name="op4">
<output name="op4out" message="..." />
</operation>
Notification
41. Java Web Services: il Server
Creazione di un Web Services Server in Java
42. Con NetBeans è possibile, tramite tool semplificati,
creare una classe di gestione delle invocazioni e gli
skeleton del servizio.
La classe di gestione utilizza la specifica JSR-109 relativa
ai Web Services che tramite le Annotation consente di
definire i parametri di configurazione del servizio.
Gli skeleton sono delle classi Java che mappano lo
schema XSD dei messaggi e le operation del WSDL.
Creazione di WS Server
43. Parametri richiesti:
1. Creare un nuovo «Web
Services from WSDL»
2. Definire nome,
package, sorgente
WSDL
Creazione di WS Server
44. La classe di handler serveProva dovrà essere popolata con il codice
necessario per gestire la risposta, di seguito un semplice esempio
@WebService(serviceName = "serverProva", portName = "serverProvaSOAP",
endpointInterface = "it.prometheo.corsows.ServerProva", targetNamespace =
"http://www.prometheo.it/corsoWS", wsdlLocation = "WEB-
INF/wsdl/serverProva/serverProva.wsdl")
public class serverProva {
public it.prometheo.corsows.HelloResponse hello(it.prometheo.corsows.HelloRequest
helloRequest) {
HelloResponse helloResponse = new HelloResponse();
helloResponse.setEchoUtente("Ciao " + helloRequest.getNomeUtente() );
return helloResponse;
}
}
Classe di handler
45. Le classi skeleton generate
automaticamente sono utilizzate per
mappare le operazioni ed i tipi di dati.
Sono inseriti in una cartella gestita da
NetBeans.
Classi skeleton
46. Java Web Services: il Client
Creazione di un Web Services Client in Java
47. Con NetBeans è possibile, tramite tool semplificati,
creare anche gli stub del servizio.
Gli stub sono delle classi Java che mappano lo schema
XSD dei messaggi e le operation del WSDL.
E’ compito dello sviluppatore la creazione della classe
client che effettui l’invocazione utilizzando gli stub.
Creazione di WS Client
48. Parametri richiesti:
1. Creare un nuovo
«Web Services Client»
2. Definire sorgente
WSDL, package.
Creazione di WS Client
49. La classe client utilizza gli stub per popolare la busta SOAP.
L’oggetto di envelope viene tradotto in blocco XML SOAP dalle
librerie java che implementano la specifica JSR-109, in particolare
viene utilizzato METRO.
public class Client {
public static void main(String[] args) {
ServerProva serverProva = (new ServerProva_Service()).getServerProvaSOAP();
ObjectFactory objectFactory = new ObjectFactory();
HelloRequest helloRequest = objectFactory.createHelloRequest();
helloRequest.setNomeUtente( "Andrea" );
HelloResponse helloResponse = serverProva.hello(helloRequest);
String responseWS = helloResponse.getEchoUtente();
System.out.println( responseWS );
}
}
Classe Client di invocazione
50. Le classi stub generate, come nel caso
delle classi skeleton,
automaticamente sono utilizzate per
mappare le operazioni ed i tipi di dati.
Sono inseriti in una cartella gestita da
NetBeans
Classi stub
