Web service architetture e standard - Tesi - cap1
-
Upload
pma77 -
Category
Technology
-
view
4.076 -
download
3
description
Transcript of Web service architetture e standard - Tesi - cap1
Il Web Service: architetture e standard Capitolo 1
1
Capitolo 1
Il Web Service: architetture e standard
Nel capitolo viene analizzata la metamorfosi che sta subendo Internet in questi ultimi
anni ovvero il passaggio da un Web popolato da pagine ad un Web fornitore di servizi.
A questo proposito viene presentata la tecnologia dei Web Service . Vengono dapprima
descritti gli strumenti base che utilizza e, in seguito, sono discusse le sue caratteristiche
e i diversi ambiti e le diverse situazioni in cui è possibile applicarla.
1.1 Introduzione ai Web Service
I Web Service hanno ridefinito il modo con cui viene utilizzato il Web: non solo
pubblicazione e consultazione di pagine statiche ma strumento per integrare le
applicazioni, interagire e creare business.
Questa nuova generazione di applicazioni Internet consente ai privati di accedere a
servizi studiati appositamente per le loro esigenze, e alle aziende di comunicare e
gestire i loro rapporti con clienti, partner e fornitori in modo semplice e immediato.
L’accesso ai Web Service è possibile a qualunque dispositivo in grado di interagire con
la Rete come PC, telefoni cellulari, palmari o notebook.
Il concetto di “integrazione” diviene sempre più comune, assumendo connotazione
sempre più estesa. Qualsiasi dispositivo fornito di interfaccia Ethernet e di un Web
server può accedere alla rete e quindi comunicare (ad esempio, fotocopiatrici, lavatrici,
macchinari industriali).
In questo modo, infatti, il dispositivo diventa accessibile da ogni parte del mondo per il
controllo, la diagnostica, l’attuazione; un semplice browser può sostituire una costosa e
Il Web Service: architetture e standard Capitolo 1
2
complessa interfaccia utente composta da pulsanti e display.
Consideriamo un esempio applicativo in cui una macchina fotocopiatrice rileva un mal
funzionamento ad uno dei suoi motori; nell’era “preistorica” dei dispositivi intelligenti
la fotocopiatrice avrebbe semplicemente scritto un codice di errore su un file log e
visualizzato sull’LCD un messaggio d’allerta. Nel mondo dei Web Service la
fotocopiatrice, dopo aver eseguito i due step descritti in precedenza, manderà un
“messaggio” di notifica ad un servizio di proxy che a sua volta invocherà un Web
Service remoto il quale a sua volta processerà il “messaggio” e prendendo opportune
decisioni:
• procedere con un’auto-diagnostica per capire l’entità del mal funzionamento;
• verificare se è necessaria la sostituzione del pezzo;
• controllare nel magazzino se è disponibile il pezzo destinato alla sostituzione;
• inviare tutte le informazioni necessarie al palmare di un tecnico pronto ad
intervenire.
Un Web Service può essere scritto in un qualsiasi linguaggio di programmazione e,
come tutte le applicazioni Web, anch’esso ha la caratteristica fondamentale di
trasmettere informazioni in formato testuale attraverso un protocollo di tipo
request/reply (in particolare l’HTTP).
Un classico Web browser è in grado di incapsulare le informazioni (secondo le modalità
previste dal protocollo) e di inviare una richiesta ad un server che elabora i dati ricevuti
e ritorna un risultato incapsulato all’interno di una risposta HTTP (solitamente una
pagina HTML). Allo stesso modo i Web Service sfruttano tale protocollo per
comunicare tra di loro inviandosi informazioni: la differenza sostanziale sta nel fatto
che con un documento HTML viene descritto sia un insieme di informazioni che la
modalità con cui le stesse vengono presentate graficamente (interpretabile solo da essere
Il Web Service: architetture e standard Capitolo 1
3
umani), mentre i Web Service si scambiano informazioni strutturate (cioè capaci di
auto-descriversi in modo da essere comprensibili sia ad un agente software che umano).
Da qui nasce l’esigenza di un linguaggio di “markup” come l’XML che ha la
caratteristica principale di essere del “semplice testo” da cui è possibile estrarre le
informazioni attraverso strumenti di parsing1.
L’XML è un metalinguaggio, cioè non specifica una semantica e quindi non definisce
dei tag preesistenti; si capisce facilmente che questo risulta essere un mezzo per la
comunicazione troppo generico, infatti è necessario che i Web Service (scritti da
programmatori diversi) “parlino la stessa lingua”.
È necessario un meccanismo che permetta alle diverse parti di concordare la sintassi e la
semantica da utilizzare per la rappresentazione delle informazioni in formato XML e
quindi permetta di descrivere alcune regole cui lo stesso documento dovrà sottostare per
essere considerato valido.
Esistono alcune differenze sui dettagli di implementazione dei Web Service : i tre
standard principali che analizzeremo in questo capitolo sono SOAP (vedere paragrafo
1.3), REST (vedere paragrafo 1.4) e XML-RPC (vedere paragrafo 1.5).
1.2 Il trasporto e la rappresentazione dell’informazione
Dalle premesse del paragrafo precedente si è appreso come il linguaggio comune per lo
scambio dei dati sia l’XML e come il protocollo di trasporto sia l’HTTP.
Questo paragrafo fornisce una visione generale di questi due strumenti per poi
addentrarsi in quelle che sono le caratteristiche salienti dei Web Service .
1In informatica, il “parsing” o analisi sintattica è il processo atto ad analizzare uno stream continuo in
input (letto per esempio da un file o una tastiera) in modo da determinare la sua struttura grammaticale
grazie ad una data grammatica formale.
Il Web Service: architetture e standard Capitolo 1
4
1.2.1 Il protocollo HTTP
Il protocollo HTTP (HyperText Transfer Protocol)[8] è impiegato per il trasferimento
di documenti ipertestuali principalmente in formato HTML.
L’ HTML è un semplice linguaggio di markup che si occupa di definire la
formattazione con cui il client HTTP (tipicamente un browser Web) visualizzerà le
informazioni.
Il funzionamento del protocollo HTTP è molto semplice. L’utilizzo di un servizio HTTP
si compone di una serie di transazioni, ognuna delle quali si articola in queste fasi:
� apertura della connessione;
� invio da parte del client di una richiesta;
� risposta da parte del server;
� chiusura della connessione.
In questo modo, il programma server non deve tenere traccia delle transazioni che
iniziano e finiscono ogni volta che un utente compie un’azione attraverso il suo
programma client (il protocollo è senza stato).
La richiesta inviata dal programma client (tipicamente un browser) deve contenere il
metodo di invio dell’informazione (i più comuni sono GET e POST) (vedere paragrafo
1.2.1.6), l’indicazione della risorsa cui si vuole accedere (ad esempio una pagina
HTML, oppure una figura), la versione del protocollo utilizzato ed eventualmente REST2
l’indicazione dei tipi di dati che possono essere gestiti dal programma client (si parla in
questi casi di tipi MIME) (vedere paragrafo 1.2.1.1). Naturalmente sono possibili
richieste più ricche di informazioni.
La risposta del server HTTP è costituita da un’intestazione che, tra le altre cose,
specifica il modo in cui l’informazione allegata deve essere interpretata.
2 In realtà non è uno standard ma uno stile architetturale.
Il Web Service: architetture e standard Capitolo 1
5
È importante comprendere subito che l’intestazione viene staccata dall’inizio
dell’informazione allegata attraverso una riga vuota, composta dalla sequenza
<CR><LF>. Al termine della ricezione dell’oggetto richiesto, la connessione ha
termine. In una connessione HTTP le informazioni tra client e server vengono
scambiate in chiaro.
La sempre maggior necessità di sicurezza nelle telecomunicazioni ha dato vita ad un
nuovo protocollo che implica la cifratura del traffico, l’ HTTPS. La sua trattazione va
oltre gli scopi di questa tesi.
1.2.1.1 Analisi di una connessione HTTP
Per comprendere in pratica il funzionamento di una connessione HTTP, si può utilizzare
il programma telnet al posto di un navigatore normale. Si suppone di poter accedere al
nodo http://www.info.ilbello.com nel quale è stato installato Apache Web server con
successo e di prelevare il file index.html.
Lanciando da consolle il comando:
telnet www.info.ilbello.com http
Telnet risponde e si mette in attesa di ricevere il messaggio da inviare al server:
Trying 192.168.1.1...
Connected to www.info.ilbello.com .
Escape character is ’\^]’.
Si deve iniziare a scrivere, cominciando con una riga contenente il metodo, la risorsa e
la versione del protocollo, continuando con una riga contenente le possibilità di
visualizzazione del client (i tipi MIME). Ogni riga è terminata con il carattere
<CR><LF> .
GET /index.html HTTP/1.0[Invio]
Accept: text/html[Invio]
Il Web Service: architetture e standard Capitolo 1
6
[Invio]
Appena si invia una riga vuota, il server intende che la richiesta è terminata e risponde
(vedi il listato 1.1).
LISTING 1.1 – esempio della risposta di un server HTTP 1 HTTP/1.1 200 OK 2 Date: Tue, 2 Mar 2009 17:44:46 GMT 3 Server: Apache/1.2.4 4 Last-Modified: Tue, 2 Mar 2009 21:07:24 GMT 5 ETag: "6b003-792-34a9628c" 6 Content-Length: 1938 7 Accept-Ranges: bytes 8 Connection: close 9 Content-Type: text/html 10 11 <!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2 Final//EN"> 12 <HTML> 13 <HEAD> 14 <TITLE>Test Page for Linux’s Apache Installation</TITLE> 15 </HEAD> 16 <!-- Background white, links blue (unvisited), navy(visited),red(active) --> 17 <BODY 18 BGCOLOR="#FFFFFF" 19 TEXT="#000000" 20 LINK="#0000FF" 21 VLINK="#000080" 22 ALINK="#FF0000" 23 > 24 <H1 ALIGN="CENTER">It Worked!</H1> 25 <P> 26 If you can see this, it means that the installation of the 27 <A 28 HREF="http://www.apache.org/" 29 >Apache</A> 30 software on this Linux system was successful. You may now add content to 31 this directory and replace this page. 32 </P> 33 ... 34 ... 35 </BODY> 36 </HTML> 37 Connection closed by foreign host.
Il messaggio restituito dal server è composto da un’intestazione in cui l’informazione
più importante è il tipo di messaggio allegato (il tipo MIME), cioè in questo caso
Content-Type: text/html, seguita da una riga vuota e quindi dall’oggetto richiesto, cioè il
contenuto del file index.html che è una pagina HTML.
Il Web Service: architetture e standard Capitolo 1
7
Al termine della ricezione dell’oggetto richiesto, la connessione ha termine. Infatti lo si
può osservare dal messaggio dato da telnet:
Connection closed by foreign host.
Il lavoro di un programma client è tutto qui: inviare richieste al server HTTP, ricevere le
risposte e gestire i dati, possibilmente visualizzandoli o mettendo comunque l’utente in
grado di fruirne.Ora esamineremo tutte le parti che compongono una richiesta e una
risposta HTTP.
1.2.1.2 I tipi MIME
MIME è una codifica standard per definire il trasferimento di documenti multimediali
attraverso la rete. L’acronimo sta per Multipurpose Internet Mail Extentions e la sua
origine è appunto legata ai trasferimenti di dati allegati ai messaggi di posta, come il
nome lascia intendere. Il protocollo HTTP utilizza lo stesso standard e con questo il
programma server informa il programma client del tipo di oggetto che gli viene inviato.
Nello stesso modo, il programma client, all’atto della richiesta di una risorsa, informa il
server dei tipi MIME (vedi tabella 1.1) che è in grado di gestire.
Il server HTTP, per poter comunicare il tipo MIME al client, deve avere un modo per
riconoscere la natura degli oggetti che costituiscono le risorse accessibili. Questo modo
è dato dall’estensione, per cui, la stessa scelta dell’estensione per i file accessibili
attraverso il protocollo HTTP è praticamente obbligatoria, ovvero, dipende dalla
configurazione dei tipi MIME.
Tipo MIME Estensione Descrizione image/gif gif Immagine GIF image/jpeg jpeg, jpg Immagine JPEG image/tiff tiff, tif Immagine TIFF text/html html, htm Testo formattato in HTML text/plain txt Testo puro video/mpeg mpe, mpeg, mpg Animazione MPEG
TABELLA 1.1 – alcuni tipi MIME
Il Web Service: architetture e standard Capitolo 1
8
1.2.1.3 Campi di richiesta
Come si evince dagli esempi mostrati precedentemente, la richiesta fatta dal programma
client è composta da una prima riga in cui si dichiara il tipo, la risorsa desiderata e la
versione del protocollo.
GET /index.html HTTP/1.0
Di seguito vengono indicati una serie di campi, più o meno facoltativi. Questi campi
sono costituiti da un nome seguito da due punti (:), da uno spazio e dall’informazione
che gli si vuole abbinare.
Campo «Connection». Nell’implementazione originale di HTTP, ogni richiesta al
server creava un nuovo socket. Questo approccio, pur essendo molto semplice, è lento.
Per ovviare a questo problema, si realizzarono le connessioni keep-alive: al termine di
ogni comunicazione il socket non viene chiuso. Per instaurare una connessione di
questo genere, nell’header della richiesta bisogna aggiungere questa riga:
Connection: Keep-Alive
Nel HTTP 1.1 tutte le connessioni sono keep-alive, a meno che non sia specificata
questa direttiva nell’header della richiesta:
Connection: close
Campo «Accept». Una o più righe contenenti un campo Accept possono essere incluse
per indicare i tipi MIME che il client è in grado di gestire (cioè di ricevere).
Se non viene indicato alcun campo Accept, si intende che siano accettati almeno i tipi
text/plain e text/html.
I tipi MIME sono organizzati attraverso due parole chiave separate da una barra
obliqua. In pratica si distingue un tipo e un sottotipo MIME. È possibile indicare un
gruppo di tipi MIME mettendo un asterisco al posto di una o di entrambe le parole
chiave, in modo da selezionare tutto il gruppo relativo.
Il Web Service: architetture e standard Capitolo 1
9
Ad esempio:
Accept: */*
rappresenta tutti i tipi MIME;
Accept: text/*
rappresenta tutti i sottotipi MIME che appartengono al tipo text; mentre
Accept: audio/basic
rappresenta un tipo e un sottotipo MIME particolare.
simili alle seguenti:
Accept-Encoding:x-gzip,x-deflate,gzip,deflate,identity
Accept-Charset:iso-8859-1,utf-8;q=0.5,*;q=0.5
Accept-Language:en
Campo «User-Agent». Il campo User-Agent permette di informare il server sul nome
e sulla versione dell’applicativo particolare che svolge la funzione di client. Per
convenzione, il nome di questo è seguito da una barra obliqua e dal numero della
versione. Tutto quello che dovesse seguire sono solo informazioni addizionali per le
quali non è stabilita una forma precisa.
Per esempio, nel caso di Netscape, si potrebbe avere un’indicazione del tipo seguente:
User-Agent:Mozilla/4.04 [en] (X11;I;Linux 2.0.32 i586)
1.2.1.4 Campi di risposta
La risposta del server HTTP a una richiesta del programma client si compone di
un’intestazione seguita eventualmente da un allegato, che costituisce la risorsa a cui il
client vuole accedere. L’intestazione è separata dall’allegato da una riga vuota. La
prima riga è costituita dal codice di stato della risposta.
Il Web Service: architetture e standard Capitolo 1
10
Nella migliore delle ipotesi dovrebbe presentarsi come nell’esempio seguente:
HTTP/1.0 200 OK
Il resto dell’intestazione è composto da campi, simili a quelli utilizzati per le richieste
dei programmi clienti:
Codice Descrizione 200 OK
201 Creato
202 Accettato
204 Nessun contenuto
300 Scelte multiple
301 Spostato in modo permanente
302 Spostato temporaneamente
304 Non modificato
400 Richiesta errata
401 Non autorizzato
403 Proibito
404 Non trovato
500 Errore interno del server HTTP
501 Servizio non realizzato (non disponibile)
502 Gateway errato
503 Servizio non disponibile
TABELLA 1.2 – tipi di risposta di un server http
Campo «Allow». Viene utilizzato dal programma server per informare il programma
client dei metodi che possono essere utilizzati. Viene restituita tale informazione
quando il client tenta di utilizzare un metodo di richiesta che il serve non è in grado di
gestire. Segue un esempio.
Allow: GET, HEAD, POST
Il Web Service: architetture e standard Capitolo 1
11
Campo «Content-Length». Indica al programma client la dimensione (in byte)
dell’allegato. Se viene utilizzato il metodo HEAD, con cui non viene restituito alcun
allegato, permette di conoscere in anticipo la dimensione della risorsa.
Content-Length: 1938.
Campo «Content-Type». Indica al programma client il tipo MIME a cui appartiene la
risorsa (allegata o meno). Segue l’esempio più comune.
Content-Type: text/html
1.2.1.5 I moduli FORM
Il tipo di comunicazione che avviene tra programma client e programma server,
descritta nelle sezioni precedenti, è nascosta all’utente dal browser, il quale agisce
tramite la richiesta e l’invio di documenti HTML. Questo avviene, ad esempio,
cliccando su un link, compilando un FORM oppure puntando il navigatore su un sito.
I moduli FORM nei documenti HTML sono il modo più complesso e completo per
permettere ad un utente di interagire con un servizio. I moduli FORM consentono
l’inserimento di molte informazioni che poi vengono trasmesse al server. I dati inseriti
attraverso i FORM possono essere trasmessi con una richiesta GET oppure POST.
I moduli FORM vengono generati dal programma client (cioè dal navigatore) in base
alle direttive incontrate all’interno di un documento HTML. Ciò significa che
l’apparenza di questi moduli può essere diversa a seconda del programma client
utilizzato e del sistema operativo. Ad esempio, in figura 1.1 è mostrato un semplice
modulo visualizzato con il browser Mozilla Firefox.
Il Web Service: architetture e standard Capitolo 1
12
FIGURA 1.1 – Un semplice modulo FORM visualizzato attraverso Mozilla Firefox.
Nel listato 1.2 è mostrato il codice HTML per generare il FORM della figura 1.1.
LISTING 1.2 1 <html> 2 <head> 3 <title>Semplice Modulo Form</title> 4 </head> 5 <body> 6 <h1 align="center"><em><strong>Semplice Modulo Form</strong></em></h1> 7 <form action ="controlloDati.pl" 8 method ="post" name="sempliceForm" target="_self"> 9 <p align="center">Username: 10 <input type="text" name="user"> 11 <br /> 12 <br /> 13 Provincia: 14 <input type="text" name="prov" /> 15 </p> 16 <p align="center"><br /> 17 <input name="submit" type="submit" value="Invia" /> 18 </p> 19 </form> 20 </body> 21 </html>
In riga 8 viene richiamato il metodo di trasmissione di tipo POST. Qui definiamo il
nome del FORM attraverso l’attributo name, il metodo utilizzato per l’invio delle
Il Web Service: architetture e standard Capitolo 1
13
informazioni al server (vedere paragrafo 1.2.1.6) attraverso l’attributo method e il file
risiedente nel server a cui inviare i dati inseriti nel FORM tramite l’attributo action.
Alle righe 10 e 14 vengono definiti i due campi di testo in cui l’utente può inserire i dati
richiesti e i relativi nomi attraverso l’attributo name.
Nella riga 17 viene definito il pulsante che l’utente premerà una volta conclusa la
compilazione della pagina. Una volta premuto il pulsante, i dati inseriti dall’utente
verranno inviati come input al file controlloDati.pl nella forma “attributo=valore”; per
esempio:
usernameText=Antonella e provinciaText=Bari;
è importante sottolineare che il file controlloDati.pl non è una semplice pagina HTML
ma un gateway (vedere paragrafo 1.2.1.7), attraverso il quale saranno effettuate delle
elaborazioni che l’ HTML non è in grado di processare essendo solo un linguaggio di
formattazione.
Il modo in cui i dati vengono inviati al server sarà discusso nel paragrafo 1.2.1.6.
1.2.1.6 Metodi HTTP
Esistono differenze nel modo con cui le informazioni possono essere inviate dal client al
server durante la richiesta di una risorsa. Il modo fondamentale attraverso cui ciò viene
controllato dal programma client è la scelta del metodo della richiesta. I metodi più usati
sono GET e POST ma grande importanza stanno acquisendo anche i metodi PUT e
DELETE per il loro utilizzo nella realizzazione di Web Service di tipo REST (vedere
paragrafo 1.4).
Metodo GET. Quando un programma client invia una richiesta utilizzando il metodo
GET, appende all’URL tutte le informazioni aggiuntive necessarie. In pratica, l’URI
stesso comprende l’informazione.
Il Web Service: architetture e standard Capitolo 1
14
Per convenzione, la richiesta è distinta dalla parte dell’URI che identifica la risorsa
attraverso un punto interrogativo e le coppie “nome=valore” sono separate dal carattere
“&” (e commerciale).
Nell’esempio del paragrafo 1.2.1.5, se avessimo scelto GET come attributo METHOD
al server sarebbe stato inviato un URI di questo genere:
http://localhost/controlloDati.pl?user=Antonella&prov=Bari
Il metodo GET, in quanto aggiunge all’URL la stringa di richiesta, permette all’utente
di controllare e di memorizzare il flusso di dati, per esempio attraverso un segnalibro
(bookmark). Con la semplice memorizzazione dell’URI, l’utente può richiamare
un’operazione di inserimento dati, senza dover ricominciare dal principio.
D’altra parte, il fatto che possa esistere traccia delle informazioni inserite nel FORM
all’interno della cronologia del browser può essere uno svantaggio dal punto di vista
della sicurezza e della privacy.
Altro inconveniente nell’utilizzo di tale metodo sta nel fatto che esiste un limite alla
dimensione degli URI e di conseguenza anche alla quantità di dati che si possono
accodare.
Un aspetto molto interessante del metodo GET è che, per inviare dei dati al server, può
non essere necessario l’utilizzo di un FORM ma è sufficiente un semplice link
(alternativa molto veloce), simile a quello in figura 1.2, generato dal codice 1.3.
La richiesta effettuata in questo modo è identica a quella effettuata dal FORM di figura
1.1 utilizzante GET come metodo di trasmissione. Questa semplicità viene pagata in
termini di elasticità: tramite una URL i parametri passati saranno sempre gli stessi (nel
caso di figura 1.2, ad esempio, il campo user varrà sempre Antonella).
Tale limitazione, rispetto all’utilizzo del FORM, riveste un ruolo più o meno
importante in dipendenza dell’applicazione e del risultato che si vuole ottenere.
Il Web Service: architetture e standard Capitolo 1
15
FIGURA 1.2 – Una semplice pagina con un link contenente informazioni per il server
LISTING 1.3 – codice HTML per la generazione della pagina di figura 1.2
LISTING 1.3 <html> <head> <title>Link contente informazioni per il server</title> </head> <body> <h2>Ecco un link contente informazioni per il server: <br /> <a href="http://localhost/controlloDati.pl?user=Antonella&prov=Bari"> http://localhost/controlloDati.pl?user=Antonella&prov=Bari </a></h2> </body> </html>
Il Web Service: architetture e standard Capitolo 1
16
Metodo POST. Il metodo POST è stato progettato per porre rimedio ai limiti del
metodo GET. Con tale metodo, i dati dei moduli FORM vengono inviati in modo
separato dall’URI, mentre il gateway (vedi paragrafo 1.2.1.7) li riceve dal programma
server attraverso lo standard input.
Metodo PUT. Questo metodo richiede che l’entità associata sia memorizzata nell’URI
fornito. Se l’URI richiesto esiste già, l’entità potrebbe essere considerata come una
versione modificata di quella contenuta nel server. In questo caso, se l’aggiornamento
va a buon fine il codice di risposta da parte del server sarà 200, altrimenti 204.
Se, invece, una nuova risorsa viene creata, il server deve informarne il client attraverso
un codice di risposta 201. Il metodo PUT è usato dal linguaggio di scripting PHP nel
caso debbano essere inviati al server dati binari (immagini, per esempio) o file.
Metodo DELETE Questo metodo richiede al server l’eliminazione della risorsa
indicata nell’URI. Le risposte del server potrebbero essere 200 (transazione eseguita
correttamente) oppure 202 se l’operazione non è stata eseguita. Un aspetto importante
da tener presente è che il client, anche in presenza di risposta di tipo 200 da parte del
server, non può avere la certezza che la risorsa sia stata effettivamente cancellata. Per
acquisire questa garanzia saranno necessari controlli ulteriori.
1.2.1.7 Il meccanismo del CGI
HTTP è un protocollo client-server progettato per gestire documenti ipertestuali e per
permettere l’interazione con programmi lato server (cioè risiedenti fisicamente sulla
macchina server), detti gateway, attraverso le specifiche CGI (Common gateway
interface). Nel caso mancasse questa ultima caratteristica in un server Web, questo
sarebbe molto simile ad un semplice file server.
Il Web Service: architetture e standard Capitolo 1
17
L’interfaccia CGI permette quindi di realizzare programmi che interagiscono con gli
utenti attraverso il protocollo HTTP. La figura 1.3 illustra il meccanismo.
FIGURA 1.3 – Il meccanismo CGI
I programmi gateway, detti anche cgi-bin o più semplicemente CGI, possono essere
realizzati con qualunque linguaggio, purché siano in grado di interagire attraverso le
specifiche del protocollo CGI. L’utilizzo di una stringa di richiesta da parte del client
presume che la risorsa sia un programma in grado di utilizzare l’informazione contenuta
in tale stringa.
Segue un esempio banale di un URI contenente una richiesta:
http://www.info.ilbello.com/cgi-bin/saluti.pl?buongiorno
Quando l’indirizzo della risorsa di un URI fa riferimento a un programma, questo può
ricevere un’informazione aggiuntiva legata a un file o a una directory particolare.
Il Web Service: architetture e standard Capitolo 1
18
Si ottiene questo aggiungendo l’indicazione del percorso che identifica questo file o
questa directory, per esempio:
http://www.info.ilbello.com/cgi-bin/elabora.pl/archivio.doc
Come già detto, l’input di un programma gateway sono dei dati provenienti dal server
HTTP, derivanti da una richiesta del client. Il programma eseguirà delle elaborazioni e
restituirà, tipicamente, una pagina HTML. L’aspetto interessante è che questa pagina
può non essere statica ma dinamica, cioè può cambiare da una richiesta all’altra.
Supponiamo che l’utente dal browser abbia la possibilità di scegliere se conoscere la
temperatura o l’umidità di una certa località. In questa località è stato posizionato un
server con dei sensori appositi. Il server HTTP passerà come input al programma CGI la
richiesta dell’utente (o umidità o temperatura). Il programma CGI leggerà dal sensore il
dato richiesto e restituirà una pagina in cui indicherà il valore del parametro
meteorologico richiesto. La pagina così generata verrà restituita dal server HTTP al
client HTTP. A seguito di una successiva richiesta, il parametro di interesse potrebbe
cambiare e, di conseguenza, anche la pagina HTML restituita sarà diversa.
Si è visto come l’utilizzo di programmi CGI (rispetto al semplice HTML) sia
indispensabile nel caso di creazione di pagine dinamiche e di utilizzo di dati provenienti
da sensori. Infatti i programmi gateway possono essere scritti anche in C così da avere,
almeno teoricamente, l’accesso a qualsiasi risorsa hardware/software del server su cui
girano. In questi ultimi anni, l’uso dei CGI sta diminuendo a favore di strumenti come il
PHP perché più semplici e potenti. Questo non è sicuramente vero per i sistemi
embedded a microcontrollore in quanto un interprete e un engine PHP sono consistenti
in termini di occupazione di memoria.
Il Web Service: architetture e standard Capitolo 1
19
1.2.1.8 I server HTTP
I server HTTP (altrimenti noti come server Web) sono nodi della rete che implementano
il protocollo HTTP ed in particolare hanno la capacità di rispondere alle richieste dei
client, principalmente fornire pagine Web e eseguire programmi CGI. Esempi illustri di
server di questo genere sono: Apache, Boa e IIS.
Il server HTTP mostra ai programmi client solo una parte dei dati contenuti all’interno
del proprio sistema, attraverso una sorta di astrazione; per esempio,
http://www.info.ilbello.com/index.html non è il file index.html che si trova nella
directory radice del filesystem del nodo www.info.ilbello.com.
Questa accessibilità dei dati attraverso il protocollo HTTP può essere gestita in vario
modo. Apache e Boa utilizzano per questo, la direttiva seguente:
DocumentRoot directory_root_html
dove directory_root_html rappresenta la directory da cui si possono diramare i
documenti HTML. Se per esempio si trattasse della riga seguente
DocumentRoot /home/httpd/html
e un client volesse accedere al documento http://www.info.ilbello.com /ciao.html
il file restituito effettivamente sarebbe /home/httpd/html/ciao.html.
1.2.2 Il metalinguaggio XML
L’eXtensible Markup Language (XML) [9] è nato nel febbraio del 1998 come
raccomandazione del W3C (World Wide Web Consortium) ed è una rivisitazione del
più complesso SGML (Standard Generalized Markup Language).
E’ una tecnologia che permette di rappresentare informazioni in formato testuale
definendo un metalinguaggio, ossia un insieme di regole per creare altri linguaggi.
Il Web Service: architetture e standard Capitolo 1
20
A differenza dell’HTML, l’XML permette di pubblicare informazioni non solo relative
a come i dati sono strutturati ma anche al significato che essi hanno (cioè al loro
contesto). La rappresentazione dei dati in maniera testuale lo rende compatibile con
qualsiasi piattaforma.
Un documento XML è sostanzialmente un file di testo che contiene un elemento (root)
che può contenere altri elementi. Le “regole di contenimento” sono specificate da una
grammatica formale basata su espressioni regolari. Gli elementi sono delimitati da tag e
possono avere degli attributi, ogni tag una volta aperto va sempre chiuso. La definizione
della sintassi e della semantica di un documento XML può avvenire con due strumenti:
DTD (Document Type Definition) [10] e XSD (XML Schema Definition) [11].
Essi provvedono alla definizione dei nuovi tag e di nuove strutture introdotti nel
documento XML. Il loro uso non è obbligatorio ma è fortemente consigliato in tutti i
casi.
Il DTD è uno standard nato precedentemente all’XML e scritto in SGML, le
specificazioni DTD di un documento XML possono risiedere sia all’esterno che
all’interno del documento stesso.
Nel listato 1.4 è mostrato un semplice esempio di documento XML-DTD. La prima
parte riguarda le definizioni DTD (dalla riga 2 alla riga 9) e indicano i tag permessi e il
tipo di valore contenuto.
L’XSD è definito usando lo stesso XML, è più complesso rispetto al DTD e ma ad oggi
non riscuote un grande successo; il W3C però ne raccomanda l’uso perché il DTD usa
una sintassi propria richiedendo editor ed elaboratori ad-hoc.
Il Web Service: architetture e standard Capitolo 1
21
LISTING 1.4 – esempio di documento XML 1 <?xml version="1.0"?> 2 <!DOCTYPE EMAIL [ 3 <!ELEMENT EMAIL (TO, FROM, CC, SUBJECT , BODY)> 4 <!ELEMENT TO (#PCDATA )> 5 <!ELEMENT FROM (#PCDATA)> 6 <!ELEMENT CC (#PCDATA )> 7 <!ELEMENT SUBJECT (#PCDATA)> 8 <!ELEMENT BODY (#PCDATA)> 9 ]>
10 11 <EMAIL> 12 <TO>[email protected]</TO> 13 <FROM> [email protected] </FROM> 14 <CC> [email protected]</CC> 15 <SUBJECT>esempio DTD</SUBJECT> 16 <BODY>Hello, World</BODY> 17 </EMAIL>
Se gli elementi di un documento sono annidati correttamente e rispettano le regole
precedentemente illustrate allora il documento è detto well-formed. Se inoltre rispetta le
regole semantiche specificate dal DTD o XSD associato allora il documento è detto
valido. Per elaborare i file XML si usano strumenti software chiamati parser. Esistono
principalmente due tipi di parser: quelli basati su il DOM (Document Object Model)
[12] e quelli basati su SAX (Simple API for XML) [13].
L’interfaccia di programmazione SAX legge ciascun carattere di un documento XML
generando un evento in corrispondenza di determinate informazioni quali l’inizio e la
fine di un documento, l’inizio e la fine di un elemento, l’individuazione di un attributo
ed altre ancora; è adatto a documenti di dimensioni notevoli poiché non carica tutto il
file durante l’elaborazione. La navigazione avviene solo in avanti come se si avesse un
indice in grado solo di avanzare per permettere la lettura ed è proprio questa sua
caratteristica che lo rende più efficiente ma anche maggiormente oneroso dal punto di
vista implementativo.
Il Web Service: architetture e standard Capitolo 1
22
In definitiva, è consigliabile usare dei parser SAX in caso di documenti XML:
• di grandi dimensioni;
• non soggetti a modifiche;
• sui quali si devono eseguire operazioni di conteggio (o simili).
Il DOM, a differenza del SAX, carica l’intero documento XML in memoria; in questo
modo si interfaccia direttamente con la rappresentazione gerarchica (come albero di
nodi) dei dati in memoria. Questa tipologia di parser, che utilizza di solito al proprio
interno un parser SAX, permette una più semplice elaborazione delle informazioni
contenute al prezzo di una maggiore quantità di memoria richiesta. Nel caso di
documenti di grandi dimensioni l’utilizzo di un parser di questo tipo potrebbe essere
problematico.
Quindi, i parser DOM sono consigliati in caso di documenti XML:
• strutturati in modo complesso;
• di dimensioni ridotte;
• la cui elaborazione dipende dalle informazioni contenute in tutto il documento.
Solo DOM è una raccomandazione del W3C.
Il parser più diffuso è il Xerces sviluppato dal consorzio Apache: esistono
implementazioni sia in Java che in C/C++; il parser di default in Java è il Crimson.
1.3 Lo standard SOAP
Il Simple Object Access Protocol [14] è un protocollo basato su XML che permette a
due applicazioni di comunicare tra loro via Web. Nato alla fine degli anni ’90 dalla
collaborazione tra IBM, Sun e Microsoft, SOAP definisce la sintassi dei messaggi che
due applicazioni possono scambiarsi utilizzando i protocolli Internet, come ad esempio
HTTP, per fornire dati e richiedere elaborazioni; inoltre introduce alcune convenzioni
Il Web Service: architetture e standard Capitolo 1
23
per la rappresentazione delle richieste e delle risposte secondo il paradigma RPC
(Remote Procedure Call) che non è altro che un modo per accedere, in modo
trasparente, a servizi remoti come se si trattassero di servizi locali.
Il vantaggio di tale protocollo è l’indipendenza dalla piattaforma hardware/software, dal
linguaggio di programmazione utilizzato per sviluppare le applicazioni comunicanti e
dalla tecnologia usata; infatti, in questo modo, è possibile utilizzare il Web non solo per
la pubblicazione di documenti contenti informazioni fruibili da agenti umani (le pagine
HTML) ma fornire dati destinati ad applicazioni (che sono alla base del concetto di
Web Service).
Una volta definito un modo comune di programmare può essere opportuno rendere
disponibili i Web Service a chiunque ne avesse bisogno, quindi occorre specificare
quelle che sono le modalità di accesso al servizio:
• il nome della procedura da invocare,
• i parametri di ingresso e quelli di uscita,
• l’URL a cui accedere.
Tutte queste informazioni sono descritte attraverso un documento XML che si basa sul
formato WSDL (vedere paragrafo 1.3.1).
Infine, per facilitare la ricerca di un particolare servizio esiste un vero e proprio data-
base sul quale si pubblicano i Web Service che prende il nome di UDDI repository
(vedere paragrafo 1.3.2); in questo “contenitore” i servizi sono organizzati per categorie
e attraverso un motore di ricerca verranno forniti i Web Service e il relativo documento
WSDL che descriverà quindi le modalità di accesso attraverso gli strumenti SOAP.
Il Web Service: architetture e standard Capitolo 1
24
FIGURA 1.4 – la suddivisione a livelli di un Web Service di tipo SOAP.
Quanto descritto è, in definitiva, un sistema multi-livello (vedere figura 1.4) che realizza
un meccanismo per la ricerca, la descrizione e la chiamata di funzionalità fornite da un
servizio Web.
Il messaggio SOAP viene suddiviso secondo la seguente struttura:
• Envelope: Identifica il documento XML come messaggio SOAP, rappresenta il
contenitore del messaggio cioè costituisce l’elemento root.
• Header: E’ un elemento opzionale che contiene informazioni globali su come
elaborare il documento, ad esempio la lingua di riferimento del messaggio, la data
dell’invio, ecc. . . oppure dati per la gestione della transazione e per l’autenticazione.
• Body: Contiene il messaggio vero e proprio (payload) e può rappresentare la richiesta
di un’elaborazione o la risposta derivata da una elaborazione.
Discovery Layer UDDI
Service Layer Web service e W3DL
Protocol Layer HTTP, SMTP, FTP
Information Layer XML
Packaging Layer SOAP
Il Web Service: architetture e standard Capitolo 1
25
• Fault: Se presente, fornisce informazioni sugli errori riscontrati durante la
computazione; questo elemento può essere presente soltanto nei messaggi di risposta
(vedere listato 1.7).
LISTING 1.5 – esempio di richiesta SOAP 1 POST /BookPrice HTTP/1.1 2 Host: www.bookserver.com 3 Content-Type: text/xml; 4 charset="utf-8" 5 Content-Length: nnnn 6 SOAPAction: /bookserver/BookPrice#GetBookPrice 7 8 <?xml version="1.0" encoding="UTF-8"?> 9 <soap :Envelope 10 xmlns :soap ="http://www.w3.org/2001/12/soapenvelope" 11 soap :encodingStyle ="http://www.w3.org/2001/12/soapencoding"> 12 <soap :Header> 13 <mybook :Trans 14xmls:m="http://www.add.com/trans/"soap :mustUnderstand ="1"> 15 234 16 </mybook :Trans > 17 </soap :Header> 18 <soap :Body xmlns :mybook ="http://www.books.com/soapbook"> 19 <mybook :GetBookPrice > 20 <mybook :ID>24-20-06-1981</mybook :ID> 21 </mybook :GetBookPrice > 22 </soap :Body > 23 </soap :Envelope >
LISTING 1.6 – esempio di risposta SOAP 1 HTTP/1.0 200 OK 2 Content-Type: text/xml; 3 charset="utf-8" 4 Content-Length: nnnn 5 6 <?xml version="1.0" encoding="UTF-8"?> 7 <soap :Envelope 8 xmlns :soap ="http://www.w3.org/2001/12/soapenvelope" 9 soap :encodingStyle ="http://www.w3.org/2001/12/soapencoding"> 10 <soap :Header> 11 <mybook :Trans 12 xmls:m="http://www.add.com/trans/"soap :mustUnderstand ="1"> 13 234 14 </mybook :Trans > 15 </soap :Header> 16 <soap :Body xmlns :mybook ="http://www.books.com/soapbook"> 17 <mybook :GetBookPriceResponse > 18 <mybook :Price >55.20</mybook :Price > 19 </mybook :GetBookPriceResponse > 20 </soap :Body > 21 </soap :Envelope >
Il Web Service: architetture e standard Capitolo 1
26
LISTING 1.7 – esempio di un messaggio di errore 1 <?xml version="1.0" encoding="UTF-8"?> 2 <soap :Envelope 3 xmlns :soap ="http://www.w3.org/2001/12/soapenvelope" 4 soap :encodingStyle ="http://www.w3.org/2001/12/soapencoding"> 5 <soap :Body > 6 <soap :Fault > 7 <faultcode >Client</faultcode > 8 <faultstring >Invalid Request</faultstring > 9 </soap :Fault > 10 </soap :Body > 11 </soap :Envelope >
Come si può vedere nell’esempio (listati 1.5, 1.6 e 1.7), SOAP definisce soltanto la
struttura dei messaggi e non il loro contenuto. I tag per descrivere una richiesta di
elaborazione (oppure per avere un risultato) vengono definiti in uno schema specifico
ed utilizzati all’interno della struttura SOAP sfruttando il meccanismo dei namespace,
cioè attraverso la possibilità di indicare in modo univoco a quale schema di metadati fa
riferimento, reperibile in rete ad un indirizzo persistente (URI) (per esempio,
http://www.w3.org/2001/12/soapenvelope, vedere listato 1.5, riga 3); l’elemento fa parte
quindi di una particolare area semantica e dovrà sottostare alle regole che ne governano
l’utilizzo. La conseguenza forse di maggior rilievo di questa architettura dati è che più
schemi di metadati possono convivere in uno stesso file XML, realizzando ognuno una
comprensione “parziale”, relativa cioè alla propria area di competenza semantica, e
aprendo in tal modo la via all’uso modulare di più schemi per descrivere o gestire uno
stesso documento.
1.3.1 Il documento WSDL
Il Web Services Description Language (WSDL) [15] nasce da un consorzio formato da
IBM, Microsoft e Ariba con lo scopo di trovare delle modalità per standardizzare i Web
Service (di tipo SOAP ma non solo). E’ un linguaggio formale XML-based che descrive
l’interfaccia al Web Service e fornisce ad un’applicazione le informazioni necessarie
Il Web Service: architetture e standard Capitolo 1
27
per accedere allo specifico servizio;permette di indicare il formato dei messaggi da
inviare, i metodi esposti dal Web Service, i parametri e i valori di ritorno quindi
consente di usare i Web Service senza conoscere a priori le API con cui sono
implementati. Lo scopo dei WSDL è permettere alle applicazioni l’interfacciamento
automatico, cioè permettere ai software di comunicare senza l’intervento dell’utente in
modo tale da rendere il processo trasparente. Sia elementi astratti che implementazioni
pratiche sono combinati per definire le funzionalità e i meccanismi di accesso al Web
Service, tali elementi sono:
• Type: è il contenitore per la definizione dei tipi dei dati scambiati, possono essere
scalari o complessi.
• Message: è un messaggio identificato da un nome composto da più part; gli
elementi del message definiscono in modo astratto i tipi dei dati scambiati.
• Operation: definisce in modo astratto il tipo di operazione descritta dal Web
Service, può essere di tipo input, output e fault (errore).
• Port type: un insieme di operazioni astratte e di messaggi.
• Binding: specifica il protocollo usato (HTTP, FTP, ecc. . . ) e il formato dei dati
delle port type.
• Port: indica l’indirizzo IP o l’URL a cui effettuare la connessione, provvede quindi
alla specificazione dell’endpoint che fornisce il servizio.
• Service: è un insieme di port type.
LISTING 1.8 – esempio di un documento WSDL 1 <?xml version="1.0" encoding="UTF-8"?> 2 <definitions name ="AxisAdminService" 3 targetNamespace="http://www.opensource.lk/AxisAdmin" 4 xmlns ="http://schemas.xmlsoap.org/wsdl/" 5 xmlns :SOAP-ENC="http://schemas.xmlsoap.org/soap/encoding/" 6 xmlns :soap ="http://schemas.xmlsoap.org/wsdl/soap/" 7 xmlns :tns ="http://www.opensource.lk/AxisAdmin" 8 xmlns :xsd ="http://www.w3.org/2001/XMLSchema" 9 xmlns :xsd1 ="http://www.opensource.lk/xsd" 10 xmlns :xsi ="http://www.w3.org/2001/XMLSchemainstance">
Il Web Service: architetture e standard Capitolo 1
28
11 <types > 12 <schema targetNamespace="http://www.opensource.lk/xsd" 13 xmlns ="http://www.w3.org/2001/XMLSchema" 14 xmlns :wsdl ="http://schemas.xmlsoap.org/wsdl/"> 15 <element name ="updateWSDD"> 16 <complexType > 17 <sequence > 18 <element name ="wsdd" type ="xsd:base64Binary"/> 19 </sequence > 20 </complexType > 21 </element > 22 <element name ="updateWSDDResponse"> 23 <complexType > 24 <sequence > 25 <element name ="return" type ="xsd:boolean"/> 26 </sequence > 27 </complexType > 28 </element > 29 </schema > 30 </types > 31 <message name ="updateWSDD"> 32 <part element ="xsd1:updateWSDD" name="parameters"/> 33 </message > 34 <message name ="updateWSDDResponse"> 35 <part element ="xsd1:updateWSDDResponse" name="parameters"/> 36 </message > 37 <portType name ="AxisAdminService"> 38 <operation name ="updateWSDD"> 39 <input message ="tns:updateWSDD" name="updateWSDD"/> 40 <output message ="tns:updateWSDDResponse"name="updateWSDDResponse"/> 41 </operation > 42 </portType > 43 <binding name ="AxisAdminPortBinding" type ="tns:AxisAdminService"> 44 <soap :binding style ="document" transport ="http://schemas.xmlsoap.org/soap/http"/> 45 <operation name ="updateWSDD"> 46 <soap :operation soapAction ="AxisAdmin#updateWSDD" style ="document"/> 47 <input name ="updateWSDD"> 48 <soap :body namespace ="http://www.opensource.lk/AxisAdmin" 49 use="literal"/> 50 </input > 51 <output name ="updateWSDDResponse"> 52 <soap :body namespace ="http://www.opensource.lk/AxisAdmin" 53 use="literal"/> 54 </output > 55 </operation > 56 </binding > 57 <service name ="AxisAdmin"> 58 <port binding ="tns:AxisAdminPortBinding" 59 name="AxisAdminParamPort"> 60 <soap :address 61 location ="http://localhost/axis/AxisAdmin"/> 62 </port > 63 </service > 64 </definitions >
Il Web Service: architetture e standard Capitolo 1
29
Esistono particolari tools capaci di interpretare il WSDL e generare lo scheletro
dell’applicazione client (o anche del server stesso) nei vari linguaggi di
programmazione. In seguito, attraverso un meccanismo di local proxy, è possibile
accedere al Web Service come se fosse una semplice chiamata ad una funzione locale.
1.3.2 Lo standard UDDI
L’Universal Discovery, Description ed Integration (UDDI) [16] offre un modo di
pubblicare sul Web informazioni dettagliate sui Web Service . E’ una specifica
(opzionale) per la realizzazione di registri distribuiti di Web Service. Si basa
essenzialmente su standard, in particolare HTTP, DNS, XML, ed è appoggiato da W3C
e IETF. Originariamente è stato un consorzio creato da Microsoft e IBM per permettere
un migliore utilizzo dei Web Service , mentre a partire dalla release 3.0 è diventato un
consorzio aperto che conta diversi membri.
Sostanzialmente, UDDI, è un sistema centrale all’interno del quale sono contenuti i
riferimenti (principalmente indirizzi Web) dei Web Service inseriti dalle aziende; per
segnalare il proprio, sia commerciale che senza fini di lucro, è sufficiente registrarsi, un
esempio è www.xmethods.net.
L’interrogazione dei registri può essere effettuata da browser o con il SOAP.
Le informazioni gestite da UDDI sono di tre tipi:
• pagine bianche: contengono informazioni anagrafiche delle aziende come nome,
indirizzo, numero di telefono, ecc. . .
• pagine gialle: contengono le liste dei Web Service divisi per categoria
permettendo, quindi, una rapida ricerca del servizio.
• pagine verdi: contengono informazioni tecniche sui Web Service come l’URL
dove risiedono e gli eventuali file WSDL.
Il Web Service: architetture e standard
Nella figura 1.5 si può ved
Service.
FIGURA 1.5 SOAP; i servizi risiedono fisicamente nel “service
descrizione risiede sia nel “service registry” che nel “service provider”.
1.3.3 I Web Service di seconda generazione
Le caratteristiche dei Web Service descritte finora mettono a disposizione le
funzionalità di connettività e comunic
SOAP. La pura connettività però non consente di avere servizi di
capaci di gestire aspetti critici quali sicurezza, qualità del
A tale proposito sono nate e
servizi simili a quelli che si trovano
specifiche è denominato di
Service
Requester
FIND
WSDL + UDDI
Il Web Service: architetture e standard
Nella figura 1.5 si può vedere il flusso delle interazioni tra le componenti
FIGURA 1.5 – i passaggi di informazioni tra i 3 stati avviene con messaggiSOAP; i servizi risiedono fisicamente nel “service provider”; la loro
descrizione risiede sia nel “service registry” che nel “service provider”.
1.3.3 I Web Service di seconda generazione
Le caratteristiche dei Web Service descritte finora mettono a disposizione le
funzionalità di connettività e comunicazione fra consumer e provider per lo
SOAP. La pura connettività però non consente di avere servizi di
capaci di gestire aspetti critici quali sicurezza, qualità del servizio, transaz
A tale proposito sono nate e stanno nascendo una serie di specifiche atte a definire
servizi simili a quelli che si trovano negli Application Server. L’insieme di queste
specifiche è denominato di seconda generazione. Le specifiche di base e di prima
Service
Registy
Service
Provider
PUBLISH
WSDL + UDDI
BIND
Capitolo 1
30
ere il flusso delle interazioni tra le componenti di un Web
i passaggi di informazioni tra i 3 stati avviene con messaggi provider”; la loro
descrizione risiede sia nel “service registry” che nel “service provider”.
Le caratteristiche dei Web Service descritte finora mettono a disposizione le
azione fra consumer e provider per lo standard
SOAP. La pura connettività però non consente di avere servizi di livello enterprise
servizio, transazionalità, ecc. .
una serie di specifiche atte a definire
negli Application Server. L’insieme di queste
seconda generazione. Le specifiche di base e di prima
Service
Provider
PUBLISH
WSDL + UDDI
Il Web Service: architetture e standard Capitolo 1
31
generazione hanno raggiunto un livello di stabilità accettabile grazie alla cooperazione
fra i fornitori di servizi. Al contrario le specifiche di seconda generazione, necessarie
alla creazione di servizi enterprise, non sembrano ancora convergere verso un livello di
stabilità che consenta la creazione di prodotti interoperabili. Le aree principali cui si
rivolgono queste specifiche sono:
• coordinamento fra Web Service ;
• gestione della sicurezza;
• qualità del servizio.
Di seguito verrà fornita una rapida descrizione di alcune di queste specifiche.
1.3.3.1 Coordinamento fra Web Service
Le specifiche di coordinamento dei Web Services si basano su WS-Coordination.
Questa specifica descrive un framework estensibile che mette a disposizione protocolli
in grado di coordinare azioni di applicazioni distribuite basate su Web Service.
Il coordinamento di Web Services può avere diversi fini, in particolare si sta prestando
maggior attenzione a:
• Processi atomici (da un punto di vista transazionale) composti da Web Service
(WS-AtomicTransaction).
• Long running process composti da Web Service (WS-BusinessActivity).
WS-AtomicTransaction usa ed estende il framework di WS-Coordination e si utilizza
nel caso in cui si abbia la necessità di aggregare diversi Web Services in un unità logica
di lavoro (LUW). WS-BusinessActivity usa ed estende il framework di WS-
Coordination per definire dei protocolli di coordinamento atti ad aggregare operazioni
di business non contenute in un’unità logica di lavoro. Il protocollo prevede la gestione
Il Web Service: architetture e standard Capitolo 1
32
delle eccezioni nel caso di fallimento permettendo di eseguire delle operazioni di
compensazione.
1.3.3.2 Gestione della sicurezza
Esistono varie specifiche di sicurezza che formano un framework detto WSSecurity.
Alcuni dei temi affrontati dal framework sono:
• autenticazione e autorizzazione;
• relazione con altre tecnologie di sicurezza (ad esempio algoritmi di crittografia,
protocolli di trasporto sicuri, sistemi di autenticazione);
• federazione di domini di Sicurezza;
• definizione e gestione delle Policy;
Nel campo della sicurezza esistono diverse specifiche al di fuori del framework
WSSecurity (ad esempio XML-Encryption, XML-Digital Signature, SAML, XKMS,
XRML).
Queste specifiche sono spesso parzialmente sovrapposte a quelle di WSSecurity e a
volte in diretta competizione. Un numero così ampio di specifiche non aiuta il
raggiungimento di uno standard ufficiale anzi favorisce coloro che producono e
vendono implementazioni custom di questo tipo.
Le specifiche di sicurezza sono quelle che probabilmente presentano il maggiore livello
di instabilità. Questa situazione è una delle maggiori cause della lenta adozione dei Web
Service nelle comunicazioni inter-aziendali. E’ chiaro infatti che in questo scenario la
sicurezza diventa un must, ma non essendoci specifiche, i prodotti in larga parte non
sono interoperabili per cui il problema diventa di difficile soluzione.
Il Web Service: architetture e standard Capitolo 1
33
1.3.3.3 Qualità del servizio
Queste specifiche servono a definire e osservare i livelli di servizio che devono essere
rispettati dai Web Service . Rientrano in questa categoria temi come:
• Policy
• Messaging
• Management
Le Policy definiscono i livelli di servizio ed eventuali altre regole di business dei Web
Service. Le specifiche sul messaging rientrano nello standard WS-Reliable Messaging
che indirizza i problemi di gestione dei messaggi asincroni. Questa specifica assume un
ruolo rilevante in questo tipo di architetture in quanto si basa fortemente sulla
comunicazione asincrona. In particolare, il WS-Reliable Messaging si occupa di:
• garantire la consegna dei messaggi (delivery guaranteed);
• fornire l’ordine di consegna dei messaggi (In-order delivery);
• controllare e cancellare dei messaggi duplicati (At most once delivery).
Le specifiche relative al management definiscono i protocolli di comunicazione delle
infrastrutture di management, con tali protocolli sarà possibile gestire qualunque
elemento del sistema informativo, ma naturalmente in prima battuta ci si focalizza sulla
gestione dei Web Service stessi.
1.3.3.4 Business Process Execution Language
BPEL è un linguaggio basato sull’XML costruito per descrivere formalmente i processi
commerciali ed industriali (workflow, definisce i meccanismi e i formati con cui
avvengono le interazioni tra i servizi Web). Una volta descritto il processo è possibile
Il Web Service: architetture e standard Capitolo 1
34
eseguirlo su particolari motori di workflow che si basano sugli standard WS-
Coordination. La sua implementazione per Web Service è chiamata BPEL4WS
(patrocinata da IBM, Microsoft, Siebel, SAP e altri). Per facilitare la scrittura del codice
BPEL4WS esistono ambienti visuali (ad esempio Oracle BPEL Designer) che
permettono di disegnare in modo grafico i processi. Come si vede in figura 1.6, il
BPEL4WS si colloca nell’ultimo livello della struttura architetturale dei Web Service
SOAP di seconda generazione.
FIGURA 1.6 – architettura a livelli dei Web Service SOAP di seconda generazione.
1.4 L’architettura REST
REST è l’acronimo di REpresentational State Transfer ed è un’alternativa a SOAP per
fornire servizi Web con XML. Il concetto si basa su una dissertazione di Roy Fielding
[17] e il suo punto di forza è l’affermare che si ha già a disposizione tutto ciò che serve
BPEL4WS
WSDL, UDDI
Reliable
Messaging Security
Transactions
Coordination
Business
Process
Quality of
Service
Description
SOAP
XML
Altri Protocolli
e Servizi Messaging
Trasports Trasport
Il Web Service: architetture e standard Capitolo 1
35
per implementare un Web Service: l’HTTP con i suoi metodi, il supporto agli URI e
l’architettura server/client.
A differenza di SOAP, REST non è un protocollo ma è uno “stile architetturale”, sfrutta
i quattro metodi dell’HTTP (GET, POST, PUT e DELETE) ed il concetto di “risorsa”:
questa è, ad esempio, l’astrazione di un oggetto reale descritto attraverso una pagina
XML e al quale è associato un URI che permette di poter raggiungere la risorsa stessa.
Per chiarire quest’ultimo concetto introduciamo un esempio (figura 1.7): un client (un
browser Web) referenzia una risorsa (l’automobile berlina modello XS201)
collocata in rete e raggiungibile attraverso uno specifico URI
(http://www.automobili.org/berline/XS201); ciò che gli viene restituito è una
rappresentazione della risorsa (il documento XML, “XS201.xml”) che pone il client in
un particolare stato (possiamo chiamarlo “stato XS201”) da cui è possibile raggiungere,
attraverso degli iper-link, le altre risorse (ad esempio, “Caratteristiche motore” a cui
sarà associato lo stato “motore XS201”, e così via). C’è quindi un trasferimento di stati
che permetterà all’applicazione client di raggiungere la risorsa desiderata e, a seconda
dei diritti che si hanno, potrà essere consultata, modificata o cancellata.
FIGURA 1.7 – richiesta di una risorsa attraverso un URI.
CLIENT
RISORSE
Caratteristiche motore
Caratteristiche interni
info rivenditori
XS201.xml
http://www.automobili.org/berline/XS201
Il Web Service: architetture e standard Capitolo 1
36
1.4.1 Un esempio di Web Service
In questo paragrafo descriveremo l’implementazione di un Web Service per la gestione
dell’archivio di una biblioteca, in particolare un cliente potrà:
• consultare le varie sezioni (narrativa, storia, informatica, ecc. . . );
• avere informazioni dettagliate sui libri;
• prenotare un libro.
Il Web server della biblioteca fornisce un URI particolare:
www.biblio-embedded.it/Sezione
che permette di accedere alla risorsa “Sezione”, cioè ad uno stato iniziale in cui è
mostrata la lista completa delle sezioni della biblioteca: ad ognuna di esse è associato un
iper-link per passare alla risorsa successiva. Per fare questo viene usata la specifica
Xlink [18] che descrive una modalità standard per inserire collegamenti ipertestuali
all’interno del file . Il documento restituito al client sarà del tipo mostrato nel listato 1.9.
LISTING 1.9 – esempio di documento XML-REST 1 <?xml version="1.0"?> 2 <b:Sezioni xmlns :b="http://www.biblio-embedded.it" 3 xmlns :xlink ="http://www.w3.org/1999/xlink"> 4 <Sezione id ="01" xlink :href ="http://www.biblioembedded.it/Sezione/01"/> 5 <Sezione id ="02" xlink :href ="http://www.biblioembedded.it/Sezione/02"/> 6 <Sezione id ="03" xlink :href ="http://www.biblioembedded.it/Sezione/03"/> 7 <Sezione id ="04" xlink :href ="http://www.biblioembedded.it/Sezione/04"/> 8 ..... 9 </b:Sezioni > Nella lista di link si sceglierà quello desiderato per accedere allo stato successivo
consultando una nuova risorsa (vedere listato 1.10).
Il Web Service: architetture e standard Capitolo 1
37
LISTING 1.10 – esempio di documento XML-REST 1 <?xml version="1.0"?> 2 <b:Sezione xmlns :b="http://www.biblio-embedded.it" 3 xmlns :xlink ="http://www.w3.org/1999/xlink"> 4 <Sezione -id>01</Sezione -id> 5 <Nome>Narrativa</Nome> 6 <Descrizione >Secondo piano,stanza 3</Descrizione > 7 <Elenco xlink :href ="http://www.biblio-embedded.it/Sezione/01/Elenco"/> 8 <Numero -libri >5500</Numero -libri > 9 </b:Sezione >
In questo nuovo stato è possibile avere informazioni più dettagliate sulla sezione (il
nome, la descrizione, la quantità di libri che contiene), inoltre un iper-link permette di
ottenere l’elenco dei libri presenti. I listati 1.11 e 1.12 mostrano l’avanzamento negli
stati successivi e le risorse ad essi associate.
LISTING 1.11 – esempio di documento XML-REST 1 <?xml version="1.0"?> 2 <b:Elenco xmlns :b="http://www.biblio-embedded.it" 3 xmlns :xlink ="http://www.w3.org/1999/xlink"> 4 <Libro id ="01" xlink :href ="http://www.biblioembedded.it/Sezione/01/Elenco/01"/> 5 <Libro id ="02" xlink :href ="http://www.biblioembedded.it/Sezione/01/Elenco/02"/> 6 <Libro id ="03" xlink :href ="http://www.biblioembedded.it/Sezione/01/Elenco/03"/> 7 <Libro id ="04" xlink :href ="http://www.biblioembedded.it/Sezione/01/Elenco/04"/> 8 ..... 9 </b:Elenco > LISTING 1.12 – esempio di documento XML-REST 1 <?xml version="1.0"?> 2 <b:Libro xmlns :b="http://www.biblio-embedded.it" 3 xmlns :xlink ="http://www.w3.org/1999/xlink"> 4 <Libro -id>03</Libro -id> 5 <Sezione >Narrativa</Sezione > 6 <Titolo >Cuore</Titolo > 7 <Autore >Edmondo De Amicis</Autore > 8 <Editore >Embedded</Editore > 9 <Quantità >2</Quantità > 10 </b:Libro >
L’esempio mostra un archivio di libri ma la stessa struttura potrebbe essere riproposta
per applicazioni in cui il numero di risorse è molto elevato (quindi il numero di pagine
Il Web Service: architetture e standard Capitolo 1
38
XML). Per evitare di avere una lista molto lunga di pagine statiche (associate ad ogni
risorsa) è possibile utilizzare link logici piuttosto che quelli fisici: cioè, l’URI descrive
“quale è” la risorsa desiderata ma non identifica un oggetto “fisico” (il documento
XML); un data-base conterrà le informazioni di tutte le risorse e per ogni richiesta fatta
attraverso un URL logico ci sarà un parser in grado di capire a quale risorsa si vuole
accedere e lancerà una query. Solitamente un’applicazione client fornisce un form che
sarà riempito con le informazioni sulla risorsa e che genera automaticamente un URL
per lanciare la query. Le richieste viste nell’esempio possono essere gestite attraverso
un normale browser indipendentemente dalla piattaforma hardware/software. Il metodo
HTTP utilizzato per consultare le risorse sarà il GET. Vediamo, invece, come creare un
servizio di prenotazioni attraverso il metodo POST: anche in questo caso si associa un
URI ad una particolare risorsa “Prenotazioni” (www.biblio-embedded.it/Prenotazioni).
Il documento XML che descrive una prenotazione può avere la forma mostrata nel
listato 1.13.
LISTING 1.13 – esempio di documento XML-REST 1 <?xml version="1.0"?> 2 <b:Prenotazioni xmlns :b="http://www.biblio-embedded.it" 3 xmlns :xlink ="http://www.w3.org/1999/xlink"> 4 <Prenotazione -id>251</Prenotazione -id> 5 <Utente -id>2009</Utente -id> 6 <Sezione >03</Sezione > 7 <Libro -id>09</Libro -id> 8 <Data>15-03-2009</Data> 9 </b:Prenotazioni >
Questo documento può essere creato automaticamente da un form seguendo le
specifiche semantiche fissate da www.biblio-embedded.it. Tali specifiche possono
essere pubblicate in un documento DTD chiamato WRDL (Web Resource Description
Language); quest’ultimo, a differenza del WSDL, non è uno standard riconosciuto a
livello di W3C quindi non può essere considerato come uno strumento universale.
Il Web Service: architetture e standard Capitolo 1
39
Uno dei maggiori esponenti del REST, Paul Prescod, ha definito un file WRDL.dtd [19]
di riferimento per lo sviluppo di Web Service. A questo punto è possibile inviare al
Web server la nostra richiesta di prenotazione che avrà come risposta un indirizzo URI
univoco che rappresenta la nuova risorsa. Le figure 1.8 e 1.9 mostrano la
“comunicazione” tra client e Web server attraverso i metodi GET e POST.
FIGURA 1.8 – richiesta GET da parte di un client verso un Web Server.
FIGURA 1.9 – richiesta POST da parte di un client verso un Web Server.
URI per acedere alla risorsa
Risposta Http
../Prenotazioni/01
../Prenotazioni/02
../Prenotazioni/03
Risorse
www.biblio-embedded.org/
Prenotazioni
<Prenotazione>
……..
</Prenotazione>
Documento XML
www.biblio-embedded.org/Prenotazioni/04
Risposta Http
RICHIESTA
HTTP
GET
../Serzione/01
../Sezione/02
../Sezione/03 ……..
Risorse
../Serzione/01
../Sezione/02
../Sezione/03
……..
Documento XML
W
eb
Se
rve
r
www.biblio-embedded.org/Sezione
We
b S
erv
er
RICHIESTA
HTTP
GET
Il Web Service: architetture e standard
1.4.2 Un confronto, REST vs SOAP
Riprendendo l’esempio del paragrafo precedente è possibile sottolineare
che rendono il REST adatto a particolari scenari applicativi. La
l’infrastruttura aggiuntiva di cui ha bisogno il SOAP
principale di incapsulare il payload (cioè l’informazione
inviare) dentro un envelope SOAP sta
server: ad esempio un server
Tutte le richieste SOAP sono inviate ad un URI unico (ad esempio,
www.biblioembedded.it/soap/s
esaminare il messaggio e smistarlo verso la risorsa corretta; questo vuol dire
server SOAP non è in grado di interpretare il contenuto del messaggio
capire a quale risorsa è des
Questo tipo di meccanismo può creare alcuni problemi che riguardano:
• la gestione degli accessi alle risorse
• il meccanismo di caching delle risorse
FIGURA 1.10
SOAP
envelope
<GetBook>
……..
</GetBook>
XML Doc
<Book-id>
……..
</Book-id>
XML Doc
Il Web Service: architetture e standard
1.4.2 Un confronto, REST vs SOAP
Riprendendo l’esempio del paragrafo precedente è possibile sottolineare
che rendono il REST adatto a particolari scenari applicativi. La figura 1.10 evidenzia
l’infrastruttura aggiuntiva di cui ha bisogno il SOAP rispetto al REST. Il vantaggio
principale di incapsulare il payload (cioè l’informazione vera e prop
inviare) dentro un envelope SOAP sta nel poter utilizzare differenti tipologie di Web
server: ad esempio un server SMTP piuttosto che uno HTTP.
Tutte le richieste SOAP sono inviate ad un URI unico (ad esempio,
www.biblioembedded.it/soap/servlet/messagerouter). Sarà poi compito del server SOAP
esaminare il messaggio e smistarlo verso la risorsa corretta; questo vuol dire
server SOAP non è in grado di interpretare il contenuto del messaggio
capire a quale risorsa è destinata.
meccanismo può creare alcuni problemi che riguardano:
• la gestione degli accessi alle risorse
• il meccanismo di caching delle risorse
FIGURA 1.10 – richiesta SOAP da parte di un client verso un Web Server.
URI SOAP
Richiesta
HTTP POST
envelope
http:/……/SOAP
We
b S
erv
er
Risposta Http
Se
rv
er S
OA
P
Capitolo 1
40
Riprendendo l’esempio del paragrafo precedente è possibile sottolineare alcuni aspetti
figura 1.10 evidenzia
rispetto al REST. Il vantaggio
vera e propria che si vuole
nel poter utilizzare differenti tipologie di Web
Tutte le richieste SOAP sono inviate ad un URI unico (ad esempio,
). Sarà poi compito del server SOAP
esaminare il messaggio e smistarlo verso la risorsa corretta; questo vuol dire che il
server SOAP non è in grado di interpretare il contenuto del messaggio ma solamente di
meccanismo può creare alcuni problemi che riguardano:
Server.
/vediSezioni(id)
/trovaLibro(id)
/Prenotalibro(id)
……..
Il Web Service: architetture e standard Capitolo 1
41
1.4.2.1 La gestione degli accessi alle risorse
Utilizzando un servizio REST è possibile associare ad ogni utente un URI specifica per
limitare il suo accesso ad alcune risorse; in questo modo è possibile sfruttare un server
proxy (o un altro tipo di intermediario) in grado di gestire gli accessi sulla base degli
URI e del metodo invocato (GET, POST, ecc. . . ) (vedere figura 1.11 e 1.12). Nel caso
di un servizio SOAP l’informazione della risorsa è ben nascosta dentro l’envelope,
quindi non è sufficiente un server proxy per bloccare accessi non autorizzati (vedere
figura 1.13).Web Server
FIGURA 1.11 – accesso negato ad una risorsa REST attraverso un server proxy.
FIGURA 1.12 – accesso consentito ad una risorsa REST attraverso un server proxy.
NO!!
Server
Proxy
Serzione 01
Sezione 02
Sezione 03
……..
Sezione 10
We
b S
erv
er
www.biblio-embedded.org/Anto/Sezione/01
OK!!
Server
Proxy
Serzione 01
Sezione 02
Sezione 03
……..
Sezione 10
We
b S
erv
er
www.biblio-embedded.org/Anto/Sezione/01
Il Web Service: architetture e standard
FIGURA 1.13
La soluzione più banale è quella di estendere le funzionalità del server
che riesca ad interpretare la semantica del messaggio e capire
richiesta, ma non tutte le applicazioni potrebbero
identificare la risorsa (vedere figura 1.14)
conoscano tutte le semantiche
Un’alternativa a questa
nell’utilizzo dei modelli RDF
rappresentare le informazioni e i legami che intercorrono fra di esse in un formato
facilmente elaborabile dai computer: in questo modo i messaggi SOAP sono
interpretabili dinamicamente
“RDF/DAML”.
URI SOAP
http://…../SOAP
Il Web Service: architetture e standard
FIGURA 1.13 – chiamata ad un metodo SOAP attraverso un server proxy.
La soluzione più banale è quella di estendere le funzionalità del server
che riesca ad interpretare la semantica del messaggio e capire
richiesta, ma non tutte le applicazioni potrebbero usare la stessa semantica pe
identificare la risorsa (vedere figura 1.14) quindi occorrono server proxy “ad hoc” che
conoscano tutte le semantiche di tutte i messaggi SOAP che potrebbero ricevere.
Un’alternativa a questa soluzione che non limita la scalabilità del server proxy sta
modelli RDF [23] o DAML [24], cioè specifiche W3C per
informazioni e i legami che intercorrono fra di esse in un formato
elaborabile dai computer: in questo modo i messaggi SOAP sono
dinamicamente dal server proxy attraverso delle richieste ad URI
URI SOAP ???
Server
Proxy
We
b S
erv
er
http://…../SOAP
Capitolo 1
42
proxy.
La soluzione più banale è quella di estendere le funzionalità del server proxy in modo
quale è la risorsa
usare la stessa semantica per
quindi occorrono server proxy “ad hoc” che
di tutte i messaggi SOAP che potrebbero ricevere.
soluzione che non limita la scalabilità del server proxy sta
cioè specifiche W3C per
informazioni e i legami che intercorrono fra di esse in un formato
elaborabile dai computer: in questo modo i messaggi SOAP sono
dal server proxy attraverso delle richieste ad URI
Se
rve
r S
OA
P
vediSerzione(01)
……..
Il Web Service: architetture e standard Capitolo 1
43
Risposta del Cache Server
RICHIESTA
HTTP
GET
Sezione 01
Sezione 02
…….
Sezione 10
We
b S
erv
er
www.biblio-embedded.org/Sezioni
Sezione 01
Sezione 02
…….
Sezione 10
Cache
Server
FIGURA 1.14 – due messaggi SOAP con stesse funzionalitàma semantica differente.
1.4.2.2 Il meccanismo di caching delle risorse
L’efficienza dei Web Service di tipo REST può essere aumentata utilizzando dei cache
server capaci di memorizzare i documenti XML per permettere di ridurre il tempo di
accesso ad una risorsa (vedere figura 1.15). Infatti, le richieste vengono fatte attraverso
il metodo GET e questo permette ad un cache server di fornire una copia “locale” della
risorsa (nel caso in cui questa sia stata memorizzata al primo accesso).
FIGURA 1.15 – il REST permette di ridurre il tempo di accesso alle risorse attraverso cache server.
Il Web Service: architetture e standard Capitolo 1
44
Per quanto riguarda i Web Service SOAP si è visto che le richieste dei client vengono
inoltrate ad un unico URI attraverso il metodo POST, questo vuol dire che non si
potranno sfruttare meccanismi di caching per due motivi:
1. l’URI si riferisce al server SOAP e non ad una reale risorsa immagazzinabile nel
cache server.
2. Solamente il metodo GET può ritornare una risorsa immagazzinata e questo è in
antitesi con l’architettura di “tipo POST” del SOAP.
Concludendo, non esiste una scelta migliore dell’altra in assoluto ma dipende dai
contesti applicativi. Per una trattazione più ampia rimandiamo a [20]; in [21] è
presentato un caso di studio in cui vengono utilizzate entrambe le tecnologie applicate al
flusso di dati, controlli e servizi tra organizzazioni e processi.
1.5 Lo standard XML-RPC
L’XML-RPC [25] è un protocollo codificato in XML per chiamate a procedure remote
su HTTP. La sua caratteristica principale è la semplicità, infatti definisce un ristretto
gruppo di tipi di dati e di comandi. Fu ideato nel1995 da Dave Winer della UserLand
Software in collaborazione con la Microsoft; quest’ultima rendendosi conto
dell’estrema semplicità incominciò ad aggiungere nuove funzionalità all’XML-RPC
sino ad evolvere questo standard nell’attuale SOAP. Un server XML-RPC utilizza un
input composto da una semplice codifica XML di una chiamata di metodo inviata come
http POST. Un esempio di richiesta è mostrato nel listato 1.14.
Il Web Service: architetture e standard Capitolo 1
45
LISTING 1.14 – esempio di richiesta XML-RPC 1 POST: /myXMLRPC/server.php HTTP/1.0 2 User-Agent: myUserAgent 3 Host: prova.unige.it 4 Content-Type: text/xml 5 Content-lenght: nnnn 6 7 <?xml version=’1.0’ encoding=’iso-8859-1’ ?> 8 <methodCall> 9 <methodName>somma</methodName> 10 <params> 11 <param> 12 <value> 13 <int>5</ int> 14 </ value> 15 </ param> 16 <param> 17 <value> 18 <int>7</ int> 19 </ value> 20 </ param> 21 </ params> 22 </ methodCall>
Le prime righe mostrano gli header HTTP necessari ad ottenere una risposta corretta dal
server:
• viene specificato il metodo di scambio dati (POST);
• l’URI a cui accedere;
• l’user agent utilizzato, cioè descrive il client utilizzato;
• l’host a cui collegarsi;
• il tipo di contenuto e la lunghezza in byte della chiamata.
Il nodo di root, che deve chiamarsi obbligatoriamente methodCall, contiene il nodo
figlio methodName avente come valore il nome della funzione. Nell’esempio, somma()
ha come parametri (contenuti nel tag params) due numeri interi. La risposta restituita
dal server è un messaggio XML che può rappresentare il dato richiesto (listato 1.15)
oppure un errore (listato 1.16).
Il Web Service: architetture e standard Capitolo 1
46
LISTING 1.15 – esempio di risposta XML-RPC 1 HTTP/1.1 200 OK 2 Connection: close 3 Content-Lenght: nnnn 4 Content-Type: text/xml 5 Date: Sun, 15 Feb 2009 16:50:00 GMT 6 Server: MyServer 7 8 <?xml version=’1.0’ encoding=’iso-8859-1’ ?> 9 <methodResponse > 10 <params > 11 <param > 12 <value > 13 <int >12</int > 14 </value > 15 </param > 16 </params > 17 </methodResponse > LISTING 1.16 – tipica risposta di errore XML-RPC 1 HTTP/1.1 200 OK 2 Connection: close 3 Content-Lenght: nnnn 4 Content-Type: text/xml 5 Date: Sun, 15 Feb 2009 16:50:00 GMT 6 Server: MyServer 7 8 <?xml version=’1.0’ encoding=’iso-8859-1’ ?> 9 <methodResponse > 10 <fault > 11 <value > 12 <struct > 13 <member > 14 <name>faultCode</name> 15 <value ><int >206</int ></value > 16 </member > 17 <member > 18 <name>faultString</name> 19 <value ><string >Tipo parametro errato</string ></value > 20 </member > 21 </struct > 22 </value > 23 </fault > 24 </methodResponse >
Il Web Service: architetture e standard Capitolo 1
47
Il messaggio di risposta sarà composto dagli header HTTP e dal documento XML che
ha come nodo di root methodResponse; nel caso in cui si verifichi un errore si ha un
nodo figlio chiamato fault che è composto da due membri obbligatori, faultCode e
faultString: sarà compito del client comprendere il codice di errore e comportarsi di
conseguenza. I tipi supportati da XML-RPC sono riportati nella seguente tabella.
TABELLA 1.3 – tipi di dato supportati da XML-RPC.
1.5.1 Un confronto, XML-RPC vs SOAP
L’obiettivo del protocollo XML-RPC è di fornire uno strumento molto semplice per
fare chiamate a procedure remote in maniera rapida e indipendentemente dalla
piattaforma hardware/software utilizzata. Un primo riscontro lo si ha davanti alle
specifiche XML-RPC: sono circa sette pagine che comprendono esempi e FAQ, mentre
le specifiche SOAP sono raccolte in quaranta pagine. Chiaramente occorre tener
presente che le potenzialità del SOAP sono di gran lunga maggiori rispetto all’XML-
RPC (ad esempio supporta gli standard US-ASCII, UTF-8 e UTF-16) ma non sempre
Tipo Descrizione
INT intero a 32bitcon segno
STRING una stringa ASCII che può contenere i bytes NULL(alcune
implementazioni supportano anche UNICODE)
BOOLEN può valere 1(true) o 0(false)
DOUBLE un numero a virgola mobile con doppia precisione (l’accuratezza può
variare a seconda dell’implementazione)
BASE64 un dato ditipo binario codificato in base 64
ARRAY un vettore monodimensionale di valori di qualsiasi tipo
STRUCT un insieme di coppie “chiave-valore”. La chiave è una stringa, il valore
può essere di qualsiasi tipo
Il Web Service: architetture e standard Capitolo 1
48
un Web Service può averne bisogno. SOAP fa un ampio uso del meccanismo del
namespace e di tag per specificare gli attributi; se da un lato appesantisce la struttura del
messaggio dall’altro fornisce agli sviluppatori uno strumento molto più flessibile per
descriverei dati che si stanno inviando (è possibile descrivere strutture dati complesse).
Nel caso in cui i dati da trasmettere sono di tipo standard (int, float, boolean, ecc. . . ) e
chiamate dei metodi sono semplici allora l’XML-RPC è la scelta che consente di avere
un applicazione più veloce e “leggera”.
1.6 I Web Service e i sistemi embedded
Per quanto detto finora si può pensare che il mondo dei Web Service sia limitato ad
Internet e all’e-business ma parallelamente si sono sviluppati nuovi scenari in cui i Web
Service rappresentano soluzioni innovative: ad esempio, nell’ambito dell’automazione
industriale (vedere paragrafo 2.2). La roadmap delle tecnologie a livello industriale
evidenzia lo svilupparsi di due tipologie di tecnologie che domineranno il futuro delle
strumentazioni:
• i Micro Sistemi Tecnologici o Micro Sistemi Elettromeccanici (MST/MEMS);
• le Internet technology.
In particolare la combinazione di entrambi darà vita agli Smart Systems, cioè dispositivi
con un bagaglio di funzionalità aggiuntive per il monitoraggio, la “diagnosi” dei
problemi, le configurazioni e le auto configurazioni, il controllo remoto , l’accesso
remoto, ecc. . . Tutto ciò permette controlli più veloci e accurati, favorisce la creazione
di un database dei “fault” e, quindi, contribuisce in maniera notevole alla riduzione dei
costi di mantenimento dei macchinari e a garantirne una vita più lunga.
La possibilità di fornire i dispositivi industriali di porte di I/O remote e di piccole PLC
con connessioni IP/Ethernet è economico, consente comunicazioni attraverso Internet e
permette di manipolare i dati usando browser standard; infatti si prevede che nei
Il Web Service: architetture e standard Capitolo 1
49
prossimi anni tutte le connessioni di un impianto industriale saranno di tipo IP/Ethernet
eccetto per le connessioni a più basso livello come quelle con sensori e attuatori.
Una volta definite le caratteristiche hardware del sistema di controllo occorre
specificare quelle software, in particolare si possono intraprendere due strade:
1. si ha un service host che comunica con un sistema embedded ospitante un Web
server; quest’ultimo fornisce informazioni sul dispositivo e permette di
modificarne i parametri attraverso pagine HTML statiche o dinamiche. Sul
service host ci sarà un Web browser che può essere usato come semplice
interfaccia del dispositivo.
2. la topologia del sistema è simile alla precedente con la differenza che sul sistema
embedded risiedono servizi che sfruttano il protocollo SOAP per implementare
vari metodi di comunicazione e di chiamata di procedure remote. In questo modo
si ha un sistema più dinamico e versatile: ad esempio, non è strettamente legato
all’HTML ma può sfruttare altri tipi di protocollo come quello per la trasmissione
di email (SMTP).
Gli scenari applicativi, in cui è opportuno impiegare Web Service , possono essere
riassunti in 4 tipologie:
• Operazione/Monitoraggio: un operatore richiede una misura (nel caso di un
sensore) o agisce su un attuatore e ha come ritorno i dati relativi all’operazione
(vedere figura 1.16-a).
• Diagnosi/Monitoraggio: un operatore richiede particolari informazioni sullo stato
del dispositivo; come ritorno ha una serie di dati nel tempo (figura 1.16-b).
Il Web Service: architetture e standard Capitolo 1
50
Dati diagnosi
Se
rvic
e
Ho
st
Em
be
dd
ed
Sy
ste
m
Richiesta dati diagnosi
Se
rvic
e
Ho
st
Em
be
dd
ed
Sy
ste
m
Richiesta dati monitoraggio
Termina invio
invio dati monitoraggio
Se
rvic
e
Ho
st
Em
be
dd
ed
Sy
ste
m Allarme
Allarme
Allarme ricevuto
Se
rvic
e
Ho
st
Em
be
dd
ed
Sy
ste
m Richiesta configurazione
Configurazione Attuale
Nuova configurazione
Pronto
• Configurazione: un operatore è in grado di modificare da remoto un ampio range di
parametri di configurazione che verranno memorizzati permanentemente in una
memoria non volatile (figura 1.16-c).
• Allarmi: informano gli addetti alla sicurezza e manutenzione (ad esempio la carica
di una batteria ha raggiunto un livello critico). Gli allarmi vengono generati quando
si verificano particolari condizioni e possono essere inviati in vari modi (anche via e-
mail) (figura 1.16-d).
a)
a) b)
c) d)
FIGURA 1.16 – i differenti scenari in cui si muovono i servizi remoti.Sono mostrati i principali dati e messaggi scambiati tra service host ed embedded system.
Il Web Service: architetture e standard
WE
B /
SO
AP
IN
TE
RFA
CE
INTERNET
Consideriamo un impianto industriale in cui questi tipi di scenari si fondano
esempio, si deve costantemente monitorare diversi sensori
ecc... ), si deve agire sui valori di alcune valvole,
parametri. Ognuno dei componenti è controllato
occuparsi delle operazioni descritte
presentata come un Web
FIGURA 1.17 – una generica architettura di un sistema embedded. Laparametri (che si trovano in una zona di memoria dedicata) e verificare i dati delle varie misurazioni.Web/SOAP permette la connessione piccolo database.
Il Web Service: architetture e standard
WE
B /
SO
AP
IN
TE
RFA
CE
PARAMETRI
CO
NT
RO
LLO
DATI
Consideriamo un impianto industriale in cui questi tipi di scenari si fondano
esempio, si deve costantemente monitorare diversi sensori (pressione, temperatura,
), si deve agire sui valori di alcune valvole, si devono misurare particolari
parametri. Ognuno dei componenti è controllato da un microprocessore che, oltre ad
occuparsi delle operazioni descritte sopra, deve fornire “un’interfaccia virtuale”
come un Web Service(vedere figura 1.17).
generica architettura di un sistema embedded. La parte di controllo si occupa di impostare i valori dei in una zona di memoria dedicata) e verificare i dati delle varie misurazioni.
Web/SOAP permette la connessione tra il sistema embedded e il service host. La parte di memoria “Dati” ha la funzione di un
Capitolo 1
51
Sensore
Temperatura
Controllo
Valvole
Sensore
Pressione
Misurazioni
Consideriamo un impianto industriale in cui questi tipi di scenari si fondano insieme: ad
(pressione, temperatura,
si devono misurare particolari
da un microprocessore che, oltre ad
sopra, deve fornire “un’interfaccia virtuale”
parte di controllo si occupa di impostare i valori dei in una zona di memoria dedicata) e verificare i dati delle varie misurazioni. L’interfaccia
embedded e il service host. La parte di memoria “Dati” ha la funzione di un
Il Web Service: architetture e standard Capitolo 1
52
1.7 Conclusioni
Il SOAP è uno standard W3C, promosso e sviluppato con l’ausilio dei più grandi player
del settore IT (Microsoft lo ha integrato in VisualStudio) ed ha molti vantaggi rispetto
ad altre implementazioni di Web Service . Molte aziende che mettono a disposizione
Web Service di tipo SOAP lo fanno senza tanta pubblicità: ad esempio, la FedEx fu
costretta ad eliminare il suo server pubblico SOAP dopo che venne utilizzato per scopi
fraudolenti dagli hacker. Questo vuol dire che la crescita di questi Web Service è
limitata alle transazioni semi private, cioè accessibili a soci autenticati e autorizzati (in
questo ambito si stanno muovendo i Web Service di seconda generazione). Infine, c’è
da considerare numerose situazioni in cui emergono problematiche dovute
all’immagazzinamento dei dati e alla larghezza di banda: infatti SOAP da questo punto
di vista è molto esigente e quindi poco adatto a particolari scenari applicativi. Il REST
non è uno standard riconosciuto ma uno stile architetturale. Utilizza i metodi dell’HTTP
che lo rendono particolarmente scalabile e con una struttura estremamente semplice.
Molti fornitori di servizi Web pubblici (come Amazon, Ebay, Yahoo, ecc. . . ) hanno
sviluppato implementazioni di Web Service sia in SOAP che in REST riscontrando un
maggiore successo di quest’ultimo: la ragione principale sta nel fatto che il REST è lo
strumento più veloce e meno complesso per trasmettere informazioni strutturate.
L’XML-RPC è un compromesso tra la semplicità di REST e la complessità di SOAP.
La tendenza di questi ultimi anni è di rappresentare le informazioni online (anche di tipo
particolare) in XML attraverso vari linguaggi di marcatura: ad esempio, l’X3D [26]
serve a descrivere semanticamente la grafica vettoriale 3D e la realtà virtuale; il CML
(Chemical Markup Language) è la base di un linguaggio XML specializzato per la
chimica e per la scienza in generale. E’ chiaro che la trasmissione di questo genere di
informazioni richiede delle strutture dati complesse che l’XML-RPC, a differenza di
SOAP, non può definire.