Web service architetture e standard - Tesi - cap1

Il Web Service: architetture e standard Capitolo 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

1


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

2


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 .

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

3


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.

4


È 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]

5

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

6


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

7


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.

8


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.

9


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

10


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.

11


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

12


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.

13


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.

14


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>

15


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.

16


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.

17


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.

18


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.

19


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.

20


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>pma77@libero.it</TO>
13 <FROM> info@microlaben.com </FROM>
14 <CC> marzocca@poliba.it</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.

21


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

22


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.

23


Discovery Layer UDDI

Service Layer Web service e W3DL

Information Layer XML

Packaging Layer SOAP

Protocol Layer HTTP, SMTP, FTP

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.

24


• 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
7 <soap:Envelope
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>

25


LISTING 1.7 – esempio di un messaggio di errore

2 <soap:Envelope
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

26


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

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

27


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>

28


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.

29


Nella figura 1.5 si può vedere il flusso delle interazioni tra le componenti di un Web
vedere

Service.

Service
Registy PUBLISH
FIND
WSDL + UDDI
WSDL + UDDI

BIND
Service Service
Requester Provider

FIGURA 1.5 – i passaggi di informazioni tra i 3 stati avviene con messaggi
SOAP; 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 standard
comunicazione

SOAP. La pura connettività però non consente di avere servizi di livello enterprise

capaci di gestire aspetti critici quali sicurezza, qualità del servizio, transaz
transazionalità, ecc. .

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

30


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

31


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.

32


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

33


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.

Business
BPEL4WS
Process

Transaction
Reliable s Quality of
Security
Messaging Coordination Service

WSDL, UDDI Description

SOAP
Altri Protocolli Messaging
XML e Servizi

Trasports Trasport
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

34


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.

http://www.automobili.org/berline/XS201

CLIENT RISORSE

Caratteristiche motore
Caratteristiche interni
info rivenditori

XS201.xml

FIGURA 1.7 – richiesta di una risorsa attraverso un URI.

35


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

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"/>
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).

36



2 <b:Sezione xmlns:b="http://www.biblio-embedded.it"
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.


2 <b:Elenco xmlns:b="http://www.biblio-embedded.it"
4 <Libro id="01" xlink:href="http://www.biblioembedded.it/Sezione/01/Elenco/01"/>
8 .....
9 </b:Elenco>


2 <b:Libro xmlns:b="http://www.biblio-embedded.it"
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

37


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.


2 <b:Prenotazioni xmlns:b="http://www.biblio-embedded.it"
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.

38


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.

RICHIESTA
HTTP www.biblio-embedded.org/Sezione
GET

Web Server
../Serzione/01
../Sezione/02
../Sezione/03
../Serzione/01 ……..
../Sezione/02 Risposta Http
Risorse
../Sezione/03
……..
Documento XML

FIGURA 1.8 – richiesta GET da parte di un client verso un Web Server.

RICHIESTA <Prenotazione>
HTTP …….. www.biblio-embedded.org/
GET </Prenotazione> Prenotazioni
Documento XML
Web Server

../Prenotazioni/01
../Prenotazioni/02
../Prenotazioni/03
Risposta Http
Risorse
www.biblio-embedded.org/Prenotazioni/04
URI per acedere alla risorsa

FIGURA 1.9 – richiesta POST da parte di un client verso un Web Server.

39


1.4.2 Un confronto, REST vs SOAP

Riprendendo l’esempio del paragrafo precedente è possibile sottolineare alcuni aspetti

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 che si vuole
propria

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
www.biblioembedded.it/soap/s ).

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

capire a quale risorsa è des
destinata.

Questo tipo di meccanismo può creare alcuni problemi che riguardano:

• la gestione degli accessi alle risorse

• il meccanismo di caching delle risorse

URI SOAP
Richiesta
<GetBook> HTTP POST http:/……/SOAP
……..
</GetBook> SOAP
Server SOAP
Web Server

envelope
XML Doc /vediSezioni(id)
/trovaLibro(id)
/Prenotalibro(id)
……..
<Book-id> Risposta Http
……..
</Book-id>
XML Doc

FIGURA 1.10 – richiesta SOAP da parte di un client verso un Web Server.

40


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
NO!!

Server
www.biblio-embedded.org/Anto/Sezione/01 Proxy

Web Server
Serzione 01
Sezione 02
Sezione 03
……..
Sezione 10

FIGURA 1.11 – accesso negato ad una risorsa REST attraverso un server proxy.

OK!!

Server
www.biblio-embedded.org/Anto/Sezione/01 Proxy
Web Server

Serzione 01
Sezione 02
Sezione 03
……..
Sezione 10

FIGURA 1.12 – accesso consentito ad una risorsa REST attraverso un server proxy.

41


URI SOAP ???

Server
http://…../SOAP Proxy

Server SOAP
Web Server
vediSerzione(01)
……..

FIGURA 1.13 – chiamata ad un metodo SOAP attraverso un server proxy.

La soluzione più banale è quella di estendere le funzionalità del server proxy in modo

che riesca ad interpretare la semantica del messaggio e capire quale è la risorsa

richiesta, ma non tutte le applicazioni potrebbero usare la stessa semantica pe
per

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

nell’utilizzo dei modelli RDF [23] o DAML [24], cioè specifiche W3C per

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 dal server proxy attraverso delle richieste ad URI

“RDF/DAML”.

42


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

RICHIESTA
Cache
HTTP www.biblio-embedded.org/Sezioni Server
GET
Web Server

Sezione 01
Sezione 02
…….
Sezione 10

Sezione 01
Sezione 02
…….
Sezione 10
Risposta del Cache Server

FIGURA 1.15 – il REST permette di ridurre il tempo di accesso alle risorse attraverso cache server.

43


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.

44


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

45


LISTING 1.15 – esempio di risposta XML-RPC

1 HTTP/1.1 200 OK
2 Connection: close
3 Content-Lenght: nnnn
5 Date: Sun, 15 Feb 2009 16:50:00 GMT
6 Server: MyServer
7
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
5 Date: Sun, 15 Feb 2009 16:50:00 GMT
6 Server: MyServer
7
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>

46


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.

Tipo Descrizione

INT intero a 32bitcon segno

una stringa ASCII che può contenere i bytes NULL(alcune
STRING
implementazioni supportano anche UNICODE)

BOOLEN può valere 1(true) o 0(false)

un numero a virgola mobile con doppia precisione (l’accuratezza può
DOUBLE
variare a seconda dell’implementazione)

BASE64 un dato ditipo binario codificato in base 64

ARRAY un vettore monodimensionale di valori di qualsiasi tipo

un insieme di coppie “chiave-valore”. La chiave è una stringa, il valore
STRUCT
può essere di qualsiasi tipo

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

47


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

48


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

49


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

Richiesta dati diagnosi
Richiesta dati monitoraggio

a)
Embedded System

Embedded System
Service Host

Service Host
invio dati monitoraggio

Dati diagnosi
Termina invio

a) b)

Richiesta configurazione Allarme
Embedded System

Embedded System
Service Host

Service Host

Allarme
Configurazione Attuale

Nuova configurazione

Allarme ricevuto
Pronto

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.

50


Consideriamo un impianto industriale in cui questi tipi di scenari si fondano insieme: ad

esempio, si deve costantemente monitorare diversi sensori (pressione, temperatura,

ecc... ), 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”

presentata come un Web Service(vedere figura 1.17).

Sensore
Temperatura

PARAMETRI
WEB /SOAP INTERFACE

Sensore
Pressione
CONTROLLO

Misurazioni
INTERNET
DATI

Controllo
Valvole

FIGURA 1.17 – una generica architettura di un sistema embedded. La parte di controllo si occupa di impostare i valori dei
parametri (che si trovano in una zona di memoria dedicata) e verificare i dati delle varie misurazioni. L’interfaccia
Web/SOAP permette la connessione tra il sistema embedded e il service host. La parte di memoria “Dati” ha la funzione di un
piccolo database.

51

Web service architetture e standard - Tesi - cap1

Web service architetture e standard - Tesi - cap1

Recommended

Recommended

More Related Content

What's hot

What's hot (19)

Similar to Web service architetture e standard - Tesi - cap1

Similar to Web service architetture e standard - Tesi - cap1 (20)

Web service architetture e standard - Tesi - cap1