Corso di
Web Services
A A. 2010 2011
Domenico Rosaci
SOAP
SOAP
Introduzione
• I WS si basano sull’uso di diverse tecnologie
sottostanti
• Le tecnologie a cui siamo interessati in questo
contesto sono:
–
–
–
–
SOAP
WSDL
WS IL
UDDI
SOAP
2
Cos’è un Web Service?
• Un WS è un’interfaccia accessibile in rete per
funzionalità applicative, costruita utilizzando
tecnologie Internet standard
• In altre parole, se un’applicazione è tale che si può
accedere ad essa tramite una combinazione di
protocolli Internet standard come HTTP, XML,
SMTP, allora quell’applicazione è un Web Service
• Quindi si tratta di un concetto semplice, e per nulla
nuovo. Piuttosto, esso sintetizza dei concetti già
esistenti da anni relativamente al Web.
SOAP
3
Cos’è un WS
SOAP
4
Fondamenti di WS
• Un WS è quindi un’interfaccia posizionata tra il
codice dell’applicazione e l’utente dell’applicazione
• Agisce come un “livello di astrazione”, separando i
dettagli relativi alla piattaforma e al linguaggio di
programmazione dal modo in cui il codice
dell’applicazione è effettivamente invocato
• Questa astrazione consente ad ogni linguaggio che
supporta i WS di accedere alle funzionalità
dell’applicazione
SOAP
5
Fondamenti di WS
SOAP
6
Fondamenti di WS
• I WS che vediamo attualmente distribuiti (deployed)
sul Web sono siti Web HTML.
• In questi siti i servizi applicativi, cioè i meccanismi
per pubblicare, gestire, cercare contenuti sono
acceduti attraverso protocolli e formati standard:
HTTP e HTML
• Le applicazioni Client (i Web browser) possono
interagire con i servizi applicativi per portare avanti
task come ad esempio cercare in un catalogo di
libri, procedere ad un acquisto, ecc
SOAP
7
Fondamenti di WS
• Grazie al livello di astrazione dei WS, non importa
quale linguaggio sia stato usato per scrivere i
servizi applicativi, e se questo linguaggio è
differente da quello in cui è scritto il Browser
• Anche l’eventuale eterogeneità dei Sistemi
Operativi sottostanti alle applicazioni interagenti è
irrilevante
• I WS permettono così un’interoperabilità “cross
platform”
SOAP
8
Fondamenti di WS
• C’è attualmente uno sforzo notevole nella comunità Java per
definire un’esatta architettura per implementare i WS nel
framework di Java 2 EE
• Tutti le principali aziende sviluppatrici (IBM, Sun, etc) lavorano
continuamente per permettere il supporto dei WS nelle loro
piattaforme
• IBM per esempio ha integrato i WS nelle sue piattaforme
WebSphere, Tivoli, Lotus e DB”, mentre Microsoft ha fatto lo
stesso con la piattaforma .NET
SOAP
9
Aspetto dei WS
• I WS sono un framework per il supporto dei messaggi
• La forma più comune di WS è quella di chiamare procedure in
esecuzione su un server, tramite messaggi del tipo “chiama
questa procedura con questi argomenti” oppure “questo è il
risultato della chiamata della procedura”
• Il codice dell’applicazione contiene dtutta la logica di business
e codifica i task (aggiungere un libro a un catalogo, cercare un
libro, ecc.).
• Il Service Listener è in grado di comprendere i protocolli
(HTTP, SOAP, Jabber, etc.) e sta in ascolto dei messaggi di
richiesta
• Il Service Proxy può elaborare una risposta per il Service
Listener (ma può anche non esserci)
SOAP
10
Aspetto dei WS
SOAP
11
Aspetto dei WS
• Le componenti Service Proxy e Service Listener possono
essere componenti stand alone (un HTTP o TCP server ad
esempio) o possono essere eseguite nel contesto di altri tipi di
application server.
• Ad esempio, WebShere Application Server include librerie
built in per ricevere messaggi SOAP su HTTP ed usarli per
invocare applicazioni Java distribuite in WebSphere. Anche
Apache Web Server ha un modulo che implementa SOAP.
• La necessità di un Application Server non è fondamentale. I
WS possono essere implementati su qualunque sistema che
supporti le tecnologie Internet standard, anche su un palmtop
o su un cellulare.
SOAP
12
Aspetto dei WS
• I WS non richiedono il tradizionale modello Client Server per le
applicazioni, né richiedono un modello architetturale n tier.
• Possono essere implementati in qualunque contesto, anche
distribuito, a patto che siano presenti i protocolli Internet
standard.
SOAP
13
Intersezione di Business e
Programmazione
• I programmatori tendono a porsi questioni del tipo “come
posso eseguire questo task più velocemente?” oppure “Come
posso sfruttare l’ereditarietà tra gli oggetti?”
• Coloro che si preoccupano del business si pongono invece
delle domande del tipo “Come posso assicurarmi che chi usa
questo servizio sia realmente chi dice di essere?” oppure
“Come posso mettere insieme più WS in un workflow?”
• A volte i 2 punti di vista entrano in conflitto. Il Business
richiede efficacia, sicurezza, affidabilità, mentre la
programmazione ha come obiettivo l’efficienza, la semplicità e
la robustezzza.
SOAP
14
Business vs
Programmazione
• Difficilmente i tool WS riescono a conciliare entrambi gli
aspetti
• Ad esempio, SOAP::Lite è un ambiente di implementazione
SOAP basato su Perl, scritto essenzialmente per
programmatori. Fornisce un insieme di tool per invocare
moduli Perl attraverso messaggi SOAP
• Invece Apache Axis è un ambiente di sviluppo SOAP che
consente di implementare soluzioni più complesse,
realizzando processi o tenendo insieme più WS
• La cosa importante da sottolineare è che qualunque approccio
WS si basa sulle stesse tecnologie Web (WSDL, UDDI, ecc.).
La differenza sta nelle possibilità che il singolo approccio offre
al programmatore per interfacciarsi con l’applicazione.
SOAP
15
Integrazione Just-in-Time
• L’integrazione JIT consente di innestare il modello di
distribuzione delle applicazioni Internet sul modello chiamato
“Architettura WS”
SOAP
16
Integrazione JIT
• Il service provider pubblica una descrizione dei servizi che
offre attraverso il service registry
• Il service consumer cerca nel service registry i servizi che
soddisfano le sue necessità
• Il consumer può essere una persona o un programma
• Il binding fa riferimento a un consumer che sta realmente
utilizzando un servizio offerto da un provider
• La chiave per l’integrazione JIT è che essa può avvenire in
qualunque momento, anche a runtime, come nell’early binding
della OOP
• Il client potrebbe cioè non conoscere quali procedure
chiamerà fino a quando non viene eseguita la ricerca del
servizio e si trova il candidato adatto
SOAP
17
WS Technology Stack
• L’architettura WS è implementata attraverso l’utilizzo di cinque
tipi di tecnologie, organizzate in layer disposti su uno stack
SOAP
18
WS Technology Stack
• La struttura presenta un’evidente similitudine con lo stack dei
protocolli TCP-IP
SOAP
19
WS Technology Stack
• I layer addizionali packaging, description e discovery sono
essenziali per fornire l’integrazione JIT
• Ogni layer ha a che fare con un determinato business
problem, quindi non è necessario implementarli tutti. Quando
un nuovo layer va aggiunto, non è necessario riscrivere il
codice esistente
• L’ambiente distribuito che ne risulta è completamente
modulare, diversamente dalle vecchie soluzioni Java o Corba
per ambienti distribuiti
SOAP
20
Oltre lo Stack
• I layer dello stack WS non ricoprono tutte le problematiche
possibili. Per esempio, non danno soluzione ai problemi di
sicurezza, privacy, trust, workflow e molti altri
• Intervengono quindi altri standard quali:
–
–
–
–
–
–
–
–
–
XML (alternativa a SOAP)
XKMS (sicurezza)
SAML (sicurezza)
XML Dsig (firma digitale)
XML Enc (crypting)
XSD (ontologie)
P3P (privacy)
WSFL (workflow)
Jabber (Peer to peer)
SOAP
21
Layer 1: Discovery
• Il layer Discobery fornisce i meccanismi che permettono al
client di scoprire le descrizioni dei servizi dei provider
• Uno degli standard più largamente diffusi in questo contesto è
l’Universal Description Discovery and Integration (UDDI)
• IBM e Microsoft hanno congiuntamente proposto
un’alternativa ad UDDI, che è il Web Services Inspection
Language (WS Inspection)
SOAP
22
Layer 2: Description
• Quando un WS è implementato, occorre prendere delle
decisioni su come supporterà i protocolli di network, transport
e packaging
• Una descrizione del servizio rappresenta queste decisioni
• Il Web Service Description Language (WSDL) è lo standard de
facto in questo contesto
• RDF e DARPA sono altre alternative proposte dal W3C, èiù
ricche ma molto più complesse di WSDL
•
SOAP
23
Layer 3: Packaging
• Affinchè i dati delle applicazioni possona muoversi attraverso
la rete mediante il livello di trasporto, essi devono essere
“impacchettati” in un formato comprensibile da ognuno degli
attori coinvolti
• HTML potrebbe essere un formato candidabile, ma esso è
troppo strettamente legato alla presentazione delle
informazioni, piuttosto che alla rappresentazione del contenuto
informativo
• XML invece permette di rappresentare la struttura delle
informazioni
• SOAP è un formato di packaging molto comune, costruito su
XML
SOAP
24
Layer 4: Transport
• Il livello di trasporto include le varie tecnologie che permettono
la comunicazione application-to-application
• Alcuni protocolli utilizzati sono TCP, HTTP, SMTP e Jabber
• Il ruolo primario del livello di trasporto è quello di muovere dati
tra due o più locazioni della rete
• I WS possono essere costruiti sopra qualunque protocollo di
trasporto
• La scelta del protocollo di trasporto da utilizzare dipende dalle
esigenze specifiche. HTTP ad esempio include il servizio
firewall più ubiquo, ma non supporta la comunicazione
asincrona. Jabber invece, pur non essendo un vero standard,
rappresenta una buona soluzione per instaurare canali di
comunicazione asincrona.
SOAP
25
Layer 5: Network
• Il livello Network è lo stesso che nel modello TCP/IP
• Fornisce le principali funzionalità per l’addressing ed il routing
su rete
SOAP
26
Le applicazioni
• Le funzionalità del WS sono implementate attraverso un
codice, che rappresenta un generico “livello delle applicazioni”
che si serve dei vari layer dello stack sottostanti
SOAP
27
Modello Peer Services
• Rappresenta una visione alternativa dei WS
• Basato sull’architettura P2P, prevede che un insieme di
membri condividano una collezione di servizi
• Esistono evidenti similitudini tra il modello P2P e i WS
• La principale differenza è che nei sistemi P2P il ruolo di
consumer e provider è molto interscambiabile, mentre nei WS
la differenza è solitamente netta
• Instant Messaging è un esempio molto nodo di modello WS
P2P.
SOAP
28
SOAP: Concetti di base
• E’ un protocollo standard di packaging per i messaggi che si
scambiano le applicazioni
• La specifica definisce niente più che una semplice busta
absata su XML per le informazioni che vengono trasferite, ed
un insieme di regole per la traduzione dei tipi di dati delle
applicazioni in rappresentazioni XML
• SOAP è un’applicazione delle specifiche XML
• Si rifà fortemente agli standard XML come XML Schema e
XML Namespace
•
SOAP
29
XML Messaging
• Un messaggio può essere qualunque cosa: un ordinativo
d’acquisto, una prenotazione di un volo, una richiesta di
ricerca in un catalogo e così via
• Essendo XML indipendente da qualunque piattaforma o
linguaggio di programmazione, esso può consentire di fare
comunicare applicazioni che girano su sistemi operativi
diversi, basandosi su linguaggi diversi
SOAP
30
RPC e EDI
• SOAP ha due applicazioni possibili: RPC e EDI
• Remote Procedure Call (RPC) è un meccanismo che permette
a metodi che girano su macchine diverse di “chiamarsi” a
vicenda scambiandosi dei parametri
• Electronic Document Interchange (EDI) definisce un formato
standard per documenti e messaggi finanziari e commerciali
• Si può usare un “document style” SOAP basato su EDI, con
XML che rappresenterà ordini, tabelle fiscali e documenti
simili. Oppure usare un “RPC style” SOAP basato su RPC
dove XML rappresenterà argomenti per metodi o valori di
ritorno
SOAP
31
Necessità di una codifica
standard
• Un’informazione, come ad es. un numero di telefono, si può
rappresentare in diversi modi
SOAP
32
Codifica standard
• Oltre a dire che stiamo usando XML, dobbiamo definire:
– Il tipo di informazione che stiamo scambiando
– Come l’informazione viene espressa in XML
– Come inviare realmente l’informazione
Senza tali informazioni, le applicazioni non saprebbero decodificare i
messaggi, anche sapendo che essi sono codificati in XML. SOAP
fornisce questo tipo di informazioni
SOAP
33
Messaggi SOAP
• Un messaggio SOAP consiste di una busta contenete un
header (opzionale) e un body /richiesto)
• L’header contiene blocchi di informazione che indicano come
il messaggio deve essere processato (settaggi sul routing e
sulla delivery, asserzioni di autenticazione e autorizzazione, e
contesti di transazione)
• Il body contiene il messaggio vero e proprio. Qualunque cosa
possa essere espressa in XML può andare nel body di un
messaggio.
SOAP
34
Messaggi SOAP
SOAP
35
Messaggi SOAP
• La sintassi XML per rappresentare un messaggio SOAP
message è basata sul namespace
http://www.w3.org/2001/06/soap-envelope namespace.
SOAP
36
Esempio di document style
SOAP
SOAP
37
Esempio SOAP
• Nell’esempio si fa uso dei “namespace” per definire gli spazi
dei nomi principali “soap-envelop” (s), “soap-transaction” (m) e
“orderService” (n).
• Ogni messaggio possiede l’elemento “contenitore”
s:enevelope, l’elemento opzionale s:Header e l’elemento
obbligatorio “s:Body”
SOAP
38
Sintassi SOAP
• Ogni envelope può contenere esattamente un elemento Body
• Il contenuto dell’elemento Body, che può essere composto da
un qualunque numero di sottoelementi, rappresenta il
messaggio vero e proprio
• Ogni envelope può contenere al massimo un Header, che se
esiste deve apparire come il primo “figlio” di envelope
• Il proposito di un header è quello di comunicare informazioni
contestuali utili per processare un messaggio (ad esempio,
credenziali di autenticazione).
SOAP
39
Messaggi RPC Style
• Solitamente viaggiano in coppia: un messaggio di richiesta ed
un messaggio di risposta
• Si immagini, come esempio, che il server offra la seguente
funzione che ritorna il valore azionario di un’azienda:
• Public float getQuote(String symbol);
SOAP
40
Esempio di richiesta
SOAP
41
Esempio di risposta
SOAP
42
L’attributo mustUnderstand
• Questo attributo appare nell’header del messaggio. Se è
settato uguale a “true”, esso impone al ricevente del
messaggio di “comprendere” il contenuto dell’header oltre che
del body
• Se il contenuto dell’header non è stato compreso, e
mustUnderstand=“true”, il ricevente deve rifiutare il messaggio
anche nel caso riuscisse a comprendere il Body
SOAP
43
Encoding style
• Un encoding style è un insieme di regole che specificano
come i tipi di dato sono codificati attraverso la sintassi XML
• A tale scopo si usa l’attributo encodingStyle
SOAP
44
Distinguere tra le versioni
SOAP
• La versione di un messaggio SOAP può essere determinata
verificando il namespace.
• Ad esempio, la versione 1.1. usa il namespace
http://www.w3.org/2001/06/soap-envelope, mentre la 1.2 usa il
namespace http://www.w3.org/2001/06/soap-envelope.
• Se l’applicazione ricevente determina una versione SOAP non
supportata nel messaggio del ricevente, può comunicare al
ricevente qual è la versione supportata inserendo nell’header
l’attributo upgrade
SOAP
45
Esempi di errori SOAP
SOAP
46
Errori SOAP
SOAP
47
Errori standard
SOAP
48
“Custom” Faults
SOAP
49
L’attributo Misunderstood
SOAP
50
Il modello SOAP per lo
scambio di messaggi
• Processare un messaggio SOAP significa esaminare la busta
e poi effettuare delle operazioni. I dettagli tecnici su come le
operazioni sono implementate sono demandati alle
applicazioni
• Il “core” del modello sta nel fatto che mentre un messaggio
SOAP è una trasmissione one way da un sender a un
receiver, l’envelope può passare attraverso vari processori
• “intermediari”, e l’output di un intermediario diventa l’input del
successivo (pipeline)
• Un intermediario è un WS disegnato per stare tra il sender e il
receiver e aggiungere funzionalità alle transazioni tra i due.
• Ogni intermediario è chiamato attore e l’insieme degli
intermediari è chiamato message path
SOAP
51
Message Path
• La costruzione del message path non è coperta da SOAP.
Esistono altri protocolli, come WS-Routing, anche se nessuno
di essi è uno standard de facto
• SOAP può invece specificare quali parti dell’header devono
essere processate da uno specifico attore (targeting). Il
targeting non può essere applicato al body
• Per etichettare un actor, si usa l’attributo actor e si fa
riferimento all’URL dell’actor
• Per esempio, un venditore di libri può ricevere messaggi
SOAP dai suoi clienti, e stabilire che ogni messaggio prima
passi da un “third party” WS che ne estrae la firma digitale e la
verifica, e poi aggiunge un blocco all’header per informare il
venditore dell’esito della verifica
SOAP
52
Messaggi SOAP: esempio
SOAP
53
Esempio di Messaggio
SOAP
54
SOAP Routing Protocol
• WS Routing (Microsoft) definisce un header SOAP standard
per specificare il message path
SOAP
55
Messaggi RPC Style
• Regole per invocare una procedura RPC attraverso SOAP:
– Il metodo call si rappresenta attraverso una struttura dati in cui ogni
compo modella un parametro di ingresso e di uscita
– I nomi e l’ordine dei campi devono corrispondere ai nomi e all’ordine dei
parametri del metodo
•
•
•
•
•
Esempio:
String checkStatus(String orderCode, String customerID);
Può essere invocata con questi argomenti:
result = checkStatus("abc123", "Bob's Store")
Mediante la seguente busta SOAP
SOAP
56
Invocare un metodo
SOAP
57
Ritornare una risposta
SOAP
58
Codifica dei dati SOAP
•
•
•
•
•
•
•
•
Un “valore” rappresenta un dato o una combinazione di dati
Un “accessor” rappresenta una variabile
<name>
<firstname> Joe </firstname>
<lastname> Smith </lastname>
</name>
Joe è un valore, firstname è un accessor
name è un “compound accessor” perché è un elemento che
ha due “figli”
• Ci sono due tipi di compound accessor, le structs e gli array
SOAP
59
Struct e array
•
•
•
•
•
•
•
•
•
•
<!--A struct -->
<person>
<firstname>Joe</firstname>
<lastname>Smith</lastname>
</person>
<!--An array-->
<people>
<person name='joe smith'/>
<person name='john doe'/>
</people>
SOAP
60
Single-Referenced Accessor
•
•
•
•
•
•
•
•
•
<people>
<person name='joe smith'>
<address>
<street>111 First Street</street>
<city>New York</city>
<state>New York</state>
</address>
</person>
</people>
SOAP
61
Multi-Referenced Accessor
•
•
•
•
•
•
•
•
•
•
•
•
•
<people>
<person name='joe smith'>
<address href='#address-1'
</person>
<person name='john doe'>
<address href='#address-1'
</person>
</people>
<address id='address-1'>
<street>111 First Street</street>
<city>New York</city>
<state>New York</state>
</address>
SOAP
62
Accesso a dati esterni
• <person name='joe smith'>
• <address href='http://acme.com/data.xml#joe_smith' />
• </person>
SOAP
63
Definire tipi di dati SOAP
• 1. Usare l’ xsi:type attribute su ogni accessor in accordo alla
XML Schema specification:
• 2. <person>
• 3. <name xsi:type="xsd:string">John Doe</name>
• </person>
• 4. Referenziare un XML Schema document che definisce il
tipo dell’elemento:
• 5. <person xmlns="personschema.xsd">
• 6. <name>John Doe</name>
• 7. </person>
• 8. <!-- dove "personschema.xsd" definisce l’elemento name
• Come tipo=xsd:string -->
SOAP
64
Definire tipi di dato (continua)
• 9. Referenziare altri tipi di schema document che definiscono il
tipo di dato di un particolare elemento con la loro propria
definizione:
• 10. <person xmlns="urn:some_namespace">
• 11. <name>John Doe</name>
• 12. </person>
• 13. <dove "urn:some_namespace" indica un namespace in cui
il valore degli elementi nome è una stringa-->
SOAP
65
Tipi di dato SOAP
• I tipi di dato supportati sono quelli definite dalle specifiche
XML Schema
• Si prevedono due sintassi alternative per i valori dei tipi
• <SOAP-ENC:int>36</SOAP-ENC:int>
• <value xsi:type="xsd:int">36</value>
• Il primo metodo è conosciuto come “anonymous accessor”
(non è specificato il nome dell’elemento), mentre il secondo
metodo è conosciuto come “named accessor” (il nome
dell’accessor nell’esempio è value)
SOAP
66
Referenze multiple nei dati
• I dati multiple referenced possono essere usati per indicare
che due variabili condividono lo stesso spazio di memoria.
Esempio:
• <value xsi:type="xsd:int" id="v1">42</value>
• <value href="#v1" />
• In questo esempio, la seconda variabile (che non ha un nome,
perché manca l’id) “referenzia la prima variabile (il cui nome è
v1)
SOAP
67
Array
• L’array più semplice è l’array di byte, che usa il tipo standard
base 64
• <some_binary_data xsi:type="SOAP-ENC:base64">
• aDF4JIK34KJjk3443kjlkj43SDF43==
• </some_binary_data>
• Gli array regolari sono indicati come appartenenti al tipo
SOAP-ENC:Array o a un suo derivato
• Il tipo dabse dell’array è indicato attraverso l’attributo
arrayType
SOAP
68
Esempio di array
monodimensionale
• <some_array xsi:type="SOAP-ENC:Array" SOAPENC:arrayType="se:string[3]">
• <se:string>Joe</se:string>
• <se:string>John</se:string>
• <se:string>Marsha</se:string>
• </some_array>
• Nelle parentesi quadre è indicata la cardinalità dell’array. Se
l’array fosse multidimensionale, avremmo più coppie di
parentesi quadre
SOAP
69
Array bidimensionale
SOAP
70
Array parzialmente trasmessi
• Se abbiamo un array di 5 elementi e vogliamo trasmettere
solo gli ultimi 2, scriveremo:
• <names xsi:type="SOAP-ENC:Array" SOAPENC:arrayType="xsd:string[5]"
• SOAP-ENC:offset="[2]">
• <name>Item 4</name>
• <name>Item 5</name>
• </names>
• Dove l’attributo offset specifica da quale indice dell’array
iniziamo a trasmettere (il primo indice è 0)
SOAP
71
Array sparso
• E’ un array che contiene solo alcuni elementi tra quelli
possibili. Ad esempio, se abbiamo un array 10x10 e vogliamo
affermare che solo gli elementi [2,5] e [5,2] contengono dati,
scriveremo:
• <names xsi:type="SOAP-ENC:Array" SOAPENC:arrayType="xsd:string[10,10]">
• <name SOAP-ENC:position="[2,5]">data</name>
• <name SOAP-ENC:position="[5,2]">data</name>
• </names>
SOAP
72
Accessor Null
• <name xsi:type="xsd:string" xsi:nil="true" />
SOAP
73
SOAP Transport
• SOAP è un protocollo di packaging e funziona con qualunque
protocollo di trasporto sottostante
• HTTP è il protocollo di trasporto più comune
• Essendo HHTP un protocollo request-response-based, esso
rappresenta un modo naturale per esprimere richieste RPC
(attraverso la richiesta HTTP al server) e fornire le risposte
(attraverso la risposta HTTP)
SOAP
74
Esempi di SOAP over HTTP
•
•
•
•
•
POST /StockQuote HTTP/1.1
Content-Type: text/xml
Content-Length: nnnn
SOAPAction: "urn:StockQuote#GetQuote"
<s:Envelope xmlns:s="http://www.w3.org/2001/06/soapenvelope">
• ...
• </s:Envelope>
• L’header SOAPAction HTTP è definito dalle specifiche SOAP
Il suo valore è completamente arbitrario, ma ha lo scopo di
indicare al server HTTP cosa il messaggio intende chiedere
prima che l’XML venga processato.
SOAP
75