Il Web Service: architetture e standard                                            Capitolo 1Capitolo 1Il Web Service: arc...
Il Web Service: architetture e standard                                           Capitolo 1complessa interfaccia utente c...
Il Web Service: architetture e standard                                                           Capitolo 1umani), mentre...
Il Web Service: architetture e standard                                            Capitolo 11.2.1 Il protocollo HTTPIl pr...
Il Web Service: architetture e standard                                               Capitolo 1È importante comprendere s...
Il Web Service: architetture e standard                                           Capitolo 1        [Invio]Appena si invia...
Il Web Service: architetture e standard                                                Capitolo 1Al termine della ricezion...
Il Web Service: architetture e standard                                            Capitolo 11.2.1.3 Campi di richiestaCom...
Il Web Service: architetture e standard                                         Capitolo 1Ad esempio:        Accept: */*ra...
Il Web Service: architetture e standard                                               Capitolo 1Nella migliore delle ipote...
Il Web Service: architetture e standard                                        Capitolo 1Campo «Content-Length». Indica al...
Il Web Service: architetture e standard                                                           Capitolo 1              ...
Il Web Service: architetture e standard                                             Capitolo 1informazioni al server (vede...
Il Web Service: architetture e standard                                               Capitolo 1Per convenzione, la richie...
Il Web Service: architetture e standard                                                               Capitolo 1          ...
Il Web Service: architetture e standard                                              Capitolo 1Metodo POST. Il metodo POST...
Il Web Service: architetture e standard                                          Capitolo 1L’interfaccia CGI permette quin...
Il Web Service: architetture e standard                                          Capitolo 1Si ottiene questo aggiungendo l...
Il Web Service: architetture e standard                                             Capitolo 11.2.1.8 I server HTTPI serve...
Il Web Service: architetture e standard                                           Capitolo 1A differenza dell’HTML, l’XML ...
Il Web Service: architetture e standard                                          Capitolo 1LISTING 1.4 – esempio di docume...
Il Web Service: architetture e standard                                          Capitolo 1In definitiva, è consigliabile ...
Il Web Service: architetture e standard                                           Capitolo 1per la rappresentazione delle ...
Il Web Service: architetture e standard                                                         Capitolo 1       Discovery...
Il Web Service: architetture e standard                                   Capitolo 1• Fault: Se presente, fornisce informa...
Il Web Service: architetture e standard                                         Capitolo 1LISTING 1.7 – esempio di un mess...
Il Web Service: architetture e standard                                           Capitolo 1per accedere allo specifico se...
Il Web Service: architetture e standard                                                Capitolo 111 <types>12 <schema targ...
Il Web Service: architetture e standard                                           Capitolo 1Esistono particolari tools cap...
Il Web Service: architetture e standard                                                             Capitolo 1Nella figura...
Il Web Service: architetture e standard                                            Capitolo 1generazione hanno raggiunto u...
Il Web Service: architetture e standard                                         Capitolo 1delle eccezioni nel caso di fall...
Il Web Service: architetture e standard                                         Capitolo 11.3.3.3 Qualità del servizioQues...
Il Web Service: architetture e standard                                                              Capitolo 1eseguirlo s...
Il Web Service: architetture e standard                                                           Capitolo 1per implementa...
Il Web Service: architetture e standard                                               Capitolo 11.4.1 Un esempio di Web Se...
Il Web Service: architetture e standard                                             Capitolo 1LISTING 1.10 – esempio di do...
Il Web Service: architetture e standard                                            Capitolo 1XML). Per evitare di avere un...
Il Web Service: architetture e standard                                                                             Capito...
Il Web Service: architetture e standard                                                                    Capitolo 11.4.2...
Il Web Service: architetture e standard                                                                 Capitolo 11.4.2.1 ...
Il Web Service: architetture e standard                                                               Capitolo 1          ...
Il Web Service: architetture e standard                                                                      Capitolo 1   ...
Il Web Service: architetture e standard                                          Capitolo 1Per quanto riguarda i Web Servi...
Il Web Service: architetture e standard                                       Capitolo 1LISTING 1.14 – esempio di richiest...
Il Web Service: architetture e standard                    Capitolo 1LISTING 1.15 – esempio di risposta XML-RPC1 HTTP/1.1 ...
Il Web Service: architetture e standard                                                 Capitolo 1Il messaggio di risposta...
Il Web Service: architetture e standard                                             Capitolo 1un Web Service può averne bi...
Il Web Service: architetture e standard                                            Capitolo 1prossimi anni tutte le connes...
Il Web Service: architetture e standard                                                                                   ...
Web service architetture e standard - Tesi - cap1
Web service architetture e standard - Tesi - cap1
Upcoming SlideShare
Loading in...5
×

Web service architetture e standard - Tesi - cap1

4,276

Published on

Inquesto primo capitolo della tesi "SVILUPPO E IMPLEMENTAZIONE SU MICROCONTROLLORE DI UN’APPLICAZIONE WEB SERVER PER IL CONTROLLO DI UN SISTEMA EMBEDDED" 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.

Published in: Technology
0 Comments
1 Like
Statistics
Notes
  • Be the first to comment

No Downloads
Views
Total Views
4,276
On Slideshare
0
From Embeds
0
Number of Embeds
1
Actions
Shares
0
Downloads
119
Comments
0
Likes
1
Embeds 0
No embeds

No notes for slide

Web service architetture e standard - Tesi - cap1

  1. 1. Il Web Service: architetture e standard Capitolo 1Capitolo 1Il Web Service: architetture e standardNel capitolo viene analizzata la metamorfosi che sta subendo Internet in questi ultimianni 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 dapprimadescritti gli strumenti base che utilizza e, in seguito, sono discusse le sue caratteristichee i diversi ambiti e le diverse situazioni in cui è possibile applicarla.1.1 Introduzione ai Web ServiceI Web Service hanno ridefinito il modo con cui viene utilizzato il Web: non solopubblicazione e consultazione di pagine statiche ma strumento per integrare leapplicazioni, interagire e creare business.Questa nuova generazione di applicazioni Internet consente ai privati di accedere aservizi studiati appositamente per le loro esigenze, e alle aziende di comunicare egestire 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 conla Rete come PC, telefoni cellulari, palmari o notebook.Il concetto di “integrazione” diviene sempre più comune, assumendo connotazionesempre più estesa. Qualsiasi dispositivo fornito di interfaccia Ethernet e di un Webserver 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 ilcontrollo, la diagnostica, l’attuazione; un semplice browser può sostituire una costosa e 1
  2. 2. Il Web Service: architetture e standard Capitolo 1complessa interfaccia utente composta da pulsanti e display.Consideriamo un esempio applicativo in cui una macchina fotocopiatrice rileva un malfunzionamento ad uno dei suoi motori; nell’era “preistorica” dei dispositivi intelligentila fotocopiatrice avrebbe semplicemente scritto un codice di errore su un file log evisualizzato sull’LCD un messaggio d’allerta. Nel mondo dei Web Service lafotocopiatrice, 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 WebService remoto il quale a sua volta processerà il “messaggio” e prendendo opportunedecisioni: • 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 ditrasmettere informazioni in formato testuale attraverso un protocollo di tiporequest/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 ricevutie ritorna un risultato incapsulato all’interno di una risposta HTTP (solitamente unapagina HTML). Allo stesso modo i Web Service sfruttano tale protocollo percomunicare tra di loro inviandosi informazioni: la differenza sostanziale sta nel fattoche con un documento HTML viene descritto sia un insieme di informazioni che lamodalità con cui le stesse vengono presentate graficamente (interpretabile solo da essere 2
  3. 3. Il Web Service: architetture e standard Capitolo 1umani), mentre i Web Service si scambiano informazioni strutturate (cioè capaci diauto-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 lacaratteristica principale di essere del “semplice testo” da cui è possibile estrarre leinformazioni attraverso strumenti di parsing1.L’XML è un metalinguaggio, cioè non specifica una semantica e quindi non definiscedei tag preesistenti; si capisce facilmente che questo risulta essere un mezzo per lacomunicazione troppo generico, infatti è necessario che i Web Service (scritti daprogrammatori diversi) “parlino la stessa lingua”.È necessario un meccanismo che permetta alle diverse parti di concordare la sintassi e lasemantica da utilizzare per la rappresentazione delle informazioni in formato XML equindi permetta di descrivere alcune regole cui lo stesso documento dovrà sottostare peressere considerato valido.Esistono alcune differenze sui dettagli di implementazione dei Web Service : i trestandard principali che analizzeremo in questo capitolo sono SOAP (vedere paragrafo1.3), REST (vedere paragrafo 1.4) e XML-RPC (vedere paragrafo 1.5).1.2 Il trasporto e la rappresentazione dell’informazioneDalle premesse del paragrafo precedente si è appreso come il linguaggio comune per loscambio 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 poiaddentrarsi 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 ininput (letto per esempio da un file o una tastiera) in modo da determinare la sua struttura grammaticalegrazie ad una data grammatica formale. 3
  4. 4. Il Web Service: architetture e standard Capitolo 11.2.1 Il protocollo HTTPIl protocollo HTTP (HyperText Transfer Protocol)[8] è impiegato per il trasferimentodi documenti ipertestuali principalmente in formato HTML.L’ HTML è un semplice linguaggio di markup che si occupa di definire laformattazione con cui il client HTTP (tipicamente un browser Web) visualizzerà leinformazioni.Il funzionamento del protocollo HTTP è molto semplice. L’utilizzo di un servizio HTTPsi 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 cheiniziano e finiscono ogni volta che un utente compie un’azione attraverso il suoprogramma client (il protocollo è senza stato).La richiesta inviata dal programma client (tipicamente un browser) deve contenere ilmetodo di invio dell’informazione (i più comuni sono GET e POST) (vedere paragrafo1.2.1.6), l’indicazione della risorsa cui si vuole accedere (ad esempio una paginaHTML, oppure una figura), la versione del protocollo utilizzato ed eventualmente REST2l’indicazione dei tipi di dati che possono essere gestiti dal programma client (si parla inquesti casi di tipi MIME) (vedere paragrafo 1.2.1.1). Naturalmente sono possibilirichieste 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
  5. 5. Il Web Service: architetture e standard Capitolo 1È importante comprendere subito che l’intestazione viene staccata dall’iniziodell’informazione allegata attraverso una riga vuota, composta dalla sequenza<CR><LF>. Al termine della ricezione dell’oggetto richiesto, la connessione hatermine. In una connessione HTTP le informazioni tra client e server vengonoscambiate in chiaro.La sempre maggior necessità di sicurezza nelle telecomunicazioni ha dato vita ad unnuovo protocollo che implica la cifratura del traffico, l’ HTTPS. La sua trattazione vaoltre gli scopi di questa tesi.1.2.1.1 Analisi di una connessione HTTPPer comprendere in pratica il funzionamento di una connessione HTTP, si può utilizzareil programma telnet al posto di un navigatore normale. Si suppone di poter accedere alnodo http://www.info.ilbello.com nel quale è stato installato Apache Web server consuccesso e di prelevare il file index.html.Lanciando da consolle il comando: telnet www.info.ilbello.com httpTelnet 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 ela versione del protocollo, continuando con una riga contenente le possibilità divisualizzazione 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
  6. 6. Il Web Service: architetture e standard Capitolo 1 [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 HTTP1 HTTP/1.1 200 OK2 Date: Tue, 2 Mar 2009 17:44:46 GMT3 Server: Apache/1.2.44 Last-Modified: Tue, 2 Mar 2009 21:07:24 GMT5 ETag: "6b003-792-34a9628c"6 Content-Length: 19387 Accept-Ranges: bytes8 Connection: close9 Content-Type: text/html1011 <!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 <BODY18 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 the27 <A28 HREF="http://www.apache.org/"29 >Apache</A>30 software on this Linux system was successful. You may now add content to31 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’informazionepiù importante è il tipo di messaggio allegato (il tipo MIME), cioè in questo casoContent-Type: text/html, seguita da una riga vuota e quindi dall’oggetto richiesto, cioè ilcontenuto del file index.html che è una pagina HTML. 6
  7. 7. Il Web Service: architetture e standard Capitolo 1Al termine della ricezione dell’oggetto richiesto, la connessione ha termine. Infatti lo sipuò 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 lerisposte e gestire i dati, possibilmente visualizzandoli o mettendo comunque l’utente ingrado di fruirne.Ora esamineremo tutte le parti che compongono una richiesta e unarisposta HTTP.1.2.1.2 I tipi MIMEMIME è una codifica standard per definire il trasferimento di documenti multimedialiattraverso la rete. L’acronimo sta per Multipurpose Internet Mail Extentions e la suaorigine è appunto legata ai trasferimenti di dati allegati ai messaggi di posta, come ilnome lascia intendere. Il protocollo HTTP utilizza lo stesso standard e con questo ilprogramma 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 ilserver 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 perriconoscere la natura degli oggetti che costituiscono le risorse accessibili. Questo modoè dato dall’estensione, per cui, la stessa scelta dell’estensione per i file accessibiliattraverso il protocollo HTTP è praticamente obbligatoria, ovvero, dipende dallaconfigurazione 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
  8. 8. Il Web Service: architetture e standard Capitolo 11.2.1.3 Campi di richiestaCome si evince dagli esempi mostrati precedentemente, la richiesta fatta dal programmaclient è composta da una prima riga in cui si dichiara il tipo, la risorsa desiderata e laversione del protocollo. GET /index.html HTTP/1.0Di seguito vengono indicati una serie di campi, più o meno facoltativi. Questi campisono costituiti da un nome seguito da due punti (:), da uno spazio e dall’informazioneche gli si vuole abbinare.Campo «Connection». Nell’implementazione originale di HTTP, ogni richiesta alserver creava un nuovo socket. Questo approccio, pur essendo molto semplice, è lento.Per ovviare a questo problema, si realizzarono le connessioni keep-alive: al termine diogni comunicazione il socket non viene chiuso. Per instaurare una connessione diquesto genere, nell’header della richiesta bisogna aggiungere questa riga: Connection: Keep-AliveNel HTTP 1.1 tutte le connessioni sono keep-alive, a meno che non sia specificataquesta direttiva nell’header della richiesta: Connection: closeCampo «Accept». Una o più righe contenenti un campo Accept possono essere incluseper 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 tipitext/plain e text/html.I tipi MIME sono organizzati attraverso due parole chiave separate da una barraobliqua. In pratica si distingue un tipo e un sottotipo MIME. È possibile indicare ungruppo di tipi MIME mettendo un asterisco al posto di una o di entrambe le parolechiave, in modo da selezionare tutto il gruppo relativo. 8
  9. 9. Il Web Service: architetture e standard Capitolo 1Ad esempio: Accept: */*rappresenta tutti i tipi MIME; Accept: text/*rappresenta tutti i sottotipi MIME che appartengono al tipo text; mentre Accept: audio/basicrappresenta 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:enCampo «User-Agent». Il campo User-Agent permette di informare il server sul nomee sulla versione dell’applicativo particolare che svolge la funzione di client. Perconvenzione, il nome di questo è seguito da una barra obliqua e dal numero dellaversione. Tutto quello che dovesse seguire sono solo informazioni addizionali per lequali 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 rispostaLa risposta del server HTTP a una richiesta del programma client si compone diun’intestazione seguita eventualmente da un allegato, che costituisce la risorsa a cui ilclient vuole accedere. L’intestazione è separata dall’allegato da una riga vuota. Laprima riga è costituita dal codice di stato della risposta. 9
  10. 10. Il Web Service: architetture e standard Capitolo 1Nella migliore delle ipotesi dovrebbe presentarsi come nell’esempio seguente: HTTP/1.0 200 OKIl resto dell’intestazione è composto da campi, simili a quelli utilizzati per le richiestedei 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 httpCampo «Allow». Viene utilizzato dal programma server per informare il programmaclient dei metodi che possono essere utilizzati. Viene restituita tale informazionequando il client tenta di utilizzare un metodo di richiesta che il serve non è in grado digestire. Segue un esempio. Allow: GET, HEAD, POST 10
  11. 11. Il Web Service: architetture e standard Capitolo 1Campo «Content-Length». Indica al programma client la dimensione (in byte)dell’allegato. Se viene utilizzato il metodo HEAD, con cui non viene restituito alcunallegato, 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 larisorsa (allegata o meno). Segue l’esempio più comune. Content-Type: text/html1.2.1.5 I moduli FORMIl tipo di comunicazione che avviene tra programma client e programma server,descritta nelle sezioni precedenti, è nascosta all’utente dal browser, il quale agiscetramite 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 perpermettere ad un utente di interagire con un servizio. I moduli FORM consentonol’inserimento di molte informazioni che poi vengono trasmesse al server. I dati inseritiattraverso i FORM possono essere trasmessi con una richiesta GET oppure POST.I moduli FORM vengono generati dal programma client (cioè dal navigatore) in basealle direttive incontrate all’interno di un documento HTML. Ciò significa chel’apparenza di questi moduli può essere diversa a seconda del programma clientutilizzato e del sistema operativo. Ad esempio, in figura 1.1 è mostrato un semplicemodulo visualizzato con il browser Mozilla Firefox. 11
  12. 12. Il Web Service: architetture e standard Capitolo 1 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.21 <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 ilnome del FORM attraverso l’attributo name, il metodo utilizzato per l’invio delle 12
  13. 13. Il Web Service: architetture e standard Capitolo 1informazioni al server (vedere paragrafo 1.2.1.6) attraverso l’attributo method e il filerisiedente 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 datirichiesti e i relativi nomi attraverso l’attributo name.Nella riga 17 viene definito il pulsante che l’utente premerà una volta conclusa lacompilazione della pagina. Una volta premuto il pulsante, i dati inseriti dall’utenteverranno inviati come input al file controlloDati.pl nella forma “attributo=valore”; peresempio: usernameText=Antonella e provinciaText=Bari;è importante sottolineare che il file controlloDati.pl non è una semplice pagina HTMLma un gateway (vedere paragrafo 1.2.1.7), attraverso il quale saranno effettuate delleelaborazioni che l’ HTML non è in grado di processare essendo solo un linguaggio diformattazione.Il modo in cui i dati vengono inviati al server sarà discusso nel paragrafo 1.2.1.6.1.2.1.6 Metodi HTTPEsistono differenze nel modo con cui le informazioni possono essere inviate dal client alserver durante la richiesta di una risorsa. Il modo fondamentale attraverso cui ciò vienecontrollato dal programma client è la scelta del metodo della richiesta. I metodi più usatisono GET e POST ma grande importanza stanno acquisendo anche i metodi PUT eDELETE per il loro utilizzo nella realizzazione di Web Service di tipo REST (vedereparagrafo 1.4).Metodo GET. Quando un programma client invia una richiesta utilizzando il metodoGET, appende all’URL tutte le informazioni aggiuntive necessarie. In pratica, l’URIstesso comprende l’informazione. 13
  14. 14. Il Web Service: architetture e standard Capitolo 1Per convenzione, la richiesta è distinta dalla parte dell’URI che identifica la risorsaattraverso 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 METHODal server sarebbe stato inviato un URI di questo genere: http://localhost/controlloDati.pl?user=Antonella&prov=BariIl metodo GET, in quanto aggiunge all’URL la stringa di richiesta, permette all’utentedi controllare e di memorizzare il flusso di dati, per esempio attraverso un segnalibro(bookmark). Con la semplice memorizzazione dell’URI, l’utente può richiamareun’operazione di inserimento dati, senza dover ricominciare dal principio.D’altra parte, il fatto che possa esistere traccia delle informazioni inserite nel FORMall’interno della cronologia del browser può essere uno svantaggio dal punto di vistadella sicurezza e della privacy.Altro inconveniente nell’utilizzo di tale metodo sta nel fatto che esiste un limite alladimensione degli URI e di conseguenza anche alla quantità di dati che si possonoaccodare.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 figura1.1 utilizzante GET come metodo di trasmissione. Questa semplicità viene pagata intermini di elasticità: tramite una URL i parametri passati saranno sempre gli stessi (nelcaso di figura 1.2, ad esempio, il campo user varrà sempre Antonella).Tale limitazione, rispetto all’utilizzo del FORM, riveste un ruolo più o menoimportante in dipendenza dell’applicazione e del risultato che si vuole ottenere. 14
  15. 15. Il Web Service: architetture e standard Capitolo 1 FIGURA 1.2 – Una semplice pagina con un link contenente informazioni per il serverLISTING 1.3 – codice HTML per la generazione della pagina di figura 1.2LISTING 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
  16. 16. Il Web Service: architetture e standard Capitolo 1Metodo POST. Il metodo POST è stato progettato per porre rimedio ai limiti delmetodo GET. Con tale metodo, i dati dei moduli FORM vengono inviati in modoseparato dall’URI, mentre il gateway (vedi paragrafo 1.2.1.7) li riceve dal programmaserver attraverso lo standard input.Metodo PUT. Questo metodo richiede che l’entità associata sia memorizzata nell’URIfornito. Se l’URI richiesto esiste già, l’entità potrebbe essere considerata come unaversione modificata di quella contenuta nel server. In questo caso, se l’aggiornamentova 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 attraversoun codice di risposta 201. Il metodo PUT è usato dal linguaggio di scripting PHP nelcaso debbano essere inviati al server dati binari (immagini, per esempio) o file.Metodo DELETE Questo metodo richiede al server l’eliminazione della risorsaindicata nell’URI. Le risposte del server potrebbero essere 200 (transazione eseguitacorrettamente) oppure 202 se l’operazione non è stata eseguita. Un aspetto importanteda tener presente è che il client, anche in presenza di risposta di tipo 200 da parte delserver, non può avere la certezza che la risorsa sia stata effettivamente cancellata. Peracquisire questa garanzia saranno necessari controlli ulteriori.1.2.1.7 Il meccanismo del CGIHTTP è un protocollo client-server progettato per gestire documenti ipertestuali e perpermettere l’interazione con programmi lato server (cioè risiedenti fisicamente sullamacchina server), detti gateway, attraverso le specifiche CGI (Common gatewayinterface). Nel caso mancasse questa ultima caratteristica in un server Web, questosarebbe molto simile ad un semplice file server. 16
  17. 17. Il Web Service: architetture e standard Capitolo 1L’interfaccia CGI permette quindi di realizzare programmi che interagiscono con gliutenti attraverso il protocollo HTTP. La figura 1.3 illustra il meccanismo. FIGURA 1.3 – Il meccanismo CGII programmi gateway, detti anche cgi-bin o più semplicemente CGI, possono essererealizzati con qualunque linguaggio, purché siano in grado di interagire attraverso lespecifiche del protocollo CGI. L’utilizzo di una stringa di richiesta da parte del clientpresume che la risorsa sia un programma in grado di utilizzare l’informazione contenutain tale stringa.Segue un esempio banale di un URI contenente una richiesta: http://www.info.ilbello.com/cgi-bin/saluti.pl?buongiornoQuando 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
  18. 18. Il Web Service: architetture e standard Capitolo 1Si ottiene questo aggiungendo l’indicazione del percorso che identifica questo file oquesta directory, per esempio: http://www.info.ilbello.com/cgi-bin/elabora.pl/archivio.docCome già detto, l’input di un programma gateway sono dei dati provenienti dal serverHTTP, derivanti da una richiesta del client. Il programma eseguirà delle elaborazioni erestituirà, tipicamente, una pagina HTML. L’aspetto interessante è che questa paginapuò 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 latemperatura o l’umidità di una certa località. In questa località è stato posizionato unserver con dei sensori appositi. Il server HTTP passerà come input al programma CGI larichiesta dell’utente (o umidità o temperatura). Il programma CGI leggerà dal sensore ildato richiesto e restituirà una pagina in cui indicherà il valore del parametrometeorologico richiesto. La pagina così generata verrà restituita dal server HTTP alclient HTTP. A seguito di una successiva richiesta, il parametro di interesse potrebbecambiare e, di conseguenza, anche la pagina HTML restituita sarà diversa.Si è visto come l’utilizzo di programmi CGI (rispetto al semplice HTML) siaindispensabile nel caso di creazione di pagine dinamiche e di utilizzo di dati provenientida 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 cuigirano. In questi ultimi anni, l’uso dei CGI sta diminuendo a favore di strumenti come ilPHP perché più semplici e potenti. Questo non è sicuramente vero per i sistemiembedded a microcontrollore in quanto un interprete e un engine PHP sono consistentiin termini di occupazione di memoria. 18
  19. 19. Il Web Service: architetture e standard Capitolo 11.2.1.8 I server HTTPI server HTTP (altrimenti noti come server Web) sono nodi della rete che implementanoil protocollo HTTP ed in particolare hanno la capacità di rispondere alle richieste deiclient, principalmente fornire pagine Web e eseguire programmi CGI. Esempi illustri diserver di questo genere sono: Apache, Boa e IIS.Il server HTTP mostra ai programmi client solo una parte dei dati contenuti all’internodel proprio sistema, attraverso una sorta di astrazione; per esempio,http://www.info.ilbello.com/index.html non è il file index.html che si trova nelladirectory radice del filesystem del nodo www.info.ilbello.com.Questa accessibilità dei dati attraverso il protocollo HTTP può essere gestita in variomodo. Apache e Boa utilizzano per questo, la direttiva seguente: DocumentRoot directory_root_htmldove directory_root_html rappresenta la directory da cui si possono diramare idocumenti HTML. Se per esempio si trattasse della riga seguente DocumentRoot /home/httpd/htmle un client volesse accedere al documento http://www.info.ilbello.com /ciao.htmlil file restituito effettivamente sarebbe /home/httpd/html/ciao.html.1.2.2 Il metalinguaggio XMLL’eXtensible Markup Language (XML) [9] è nato nel febbraio del 1998 comeraccomandazione del W3C (World Wide Web Consortium) ed è una rivisitazione delpiù complesso SGML (Standard Generalized Markup Language).E’ una tecnologia che permette di rappresentare informazioni in formato testualedefinendo un metalinguaggio, ossia un insieme di regole per creare altri linguaggi. 19
  20. 20. Il Web Service: architetture e standard Capitolo 1A differenza dell’HTML, l’XML permette di pubblicare informazioni non solo relativea come i dati sono strutturati ma anche al significato che essi hanno (cioè al lorocontesto). La rappresentazione dei dati in maniera testuale lo rende compatibile conqualsiasi 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 unagrammatica formale basata su espressioni regolari. Gli elementi sono delimitati da tag epossono avere degli attributi, ogni tag una volta aperto va sempre chiuso. La definizionedella 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 neldocumento XML. Il loro uso non è obbligatorio ma è fortemente consigliato in tutti icasi.Il DTD è uno standard nato precedentemente all’XML e scritto in SGML, lespecificazioni DTD di un documento XML possono risiedere sia all’esterno cheall’interno del documento stesso.Nel listato 1.4 è mostrato un semplice esempio di documento XML-DTD. La primaparte riguarda le definizioni DTD (dalla riga 2 alla riga 9) e indicano i tag permessi e iltipo di valore contenuto.L’XSD è definito usando lo stesso XML, è più complesso rispetto al DTD e ma ad ogginon riscuote un grande successo; il W3C però ne raccomanda l’uso perché il DTD usauna sintassi propria richiedendo editor ed elaboratori ad-hoc. 20
  21. 21. Il Web Service: architetture e standard Capitolo 1LISTING 1.4 – esempio di documento XML1 <?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 ]>1011 <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 regoleprecedentemente illustrate allora il documento è detto well-formed. Se inoltre rispetta leregole semantiche specificate dal DTD o XSD associato allora il documento è dettovalido. Per elaborare i file XML si usano strumenti software chiamati parser. Esistonoprincipalmente 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 XMLgenerando un evento in corrispondenza di determinate informazioni quali l’inizio e lafine di un documento, l’inizio e la fine di un elemento, l’individuazione di un attributoed altre ancora; è adatto a documenti di dimensioni notevoli poiché non carica tutto ilfile durante l’elaborazione. La navigazione avviene solo in avanti come se si avesse unindice in grado solo di avanzare per permettere la lettura ed è proprio questa suacaratteristica che lo rende più efficiente ma anche maggiormente oneroso dal punto divista implementativo. 21
  22. 22. Il Web Service: architetture e standard Capitolo 1In 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 questomodo si interfaccia direttamente con la rappresentazione gerarchica (come albero dinodi) dei dati in memoria. Questa tipologia di parser, che utilizza di solito al propriointerno un parser SAX, permette una più semplice elaborazione delle informazionicontenute al prezzo di una maggiore quantità di memoria richiesta. Nel caso didocumenti di grandi dimensioni l’utilizzo di un parser di questo tipo potrebbe essereproblematico.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: esistonoimplementazioni sia in Java che in C/C++; il parser di default in Java è il Crimson.1.3 Lo standard SOAPIl Simple Object Access Protocol [14] è un protocollo basato su XML che permette adue applicazioni di comunicare tra loro via Web. Nato alla fine degli anni ’90 dallacollaborazione tra IBM, Sun e Microsoft, SOAP definisce la sintassi dei messaggi chedue applicazioni possono scambiarsi utilizzando i protocolli Internet, come ad esempioHTTP, per fornire dati e richiedere elaborazioni; inoltre introduce alcune convenzioni 22
  23. 23. Il Web Service: architetture e standard Capitolo 1per la rappresentazione delle richieste e delle risposte secondo il paradigma RPC(Remote Procedure Call) che non è altro che un modo per accedere, in modotrasparente, a servizi remoti come se si trattassero di servizi locali.Il vantaggio di tale protocollo è l’indipendenza dalla piattaforma hardware/software, dallinguaggio di programmazione utilizzato per sviluppare le applicazioni comunicanti edalla tecnologia usata; infatti, in questo modo, è possibile utilizzare il Web non solo perla pubblicazione di documenti contenti informazioni fruibili da agenti umani (le pagineHTML) ma fornire dati destinati ad applicazioni (che sono alla base del concetto diWeb Service).Una volta definito un modo comune di programmare può essere opportuno renderedisponibili i Web Service a chiunque ne avesse bisogno, quindi occorre specificarequelle 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 sulformato 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 categoriee attraverso un motore di ricerca verranno forniti i Web Service e il relativo documentoWSDL che descriverà quindi le modalità di accesso attraverso gli strumenti SOAP. 23
  24. 24. Il Web Service: architetture e standard Capitolo 1 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 realizzaun meccanismo per la ricerca, la descrizione e la chiamata di funzionalità fornite da unservizio Web.Il messaggio SOAP viene suddiviso secondo la seguente struttura:• Envelope: Identifica il documento XML come messaggio SOAP, rappresenta ilcontenitore del messaggio cioè costituisce l’elemento root.• Header: E’ un elemento opzionale che contiene informazioni globali su comeelaborare il documento, ad esempio la lingua di riferimento del messaggio, la datadell’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 richiestadi un’elaborazione o la risposta derivata da una elaborazione. 24
  25. 25. Il Web Service: architetture e standard Capitolo 1• Fault: Se presente, fornisce informazioni sugli errori riscontrati durante lacomputazione; questo elemento può essere presente soltanto nei messaggi di risposta(vedere listato 1.7).LISTING 1.5 – esempio di richiesta SOAP1 POST /BookPrice HTTP/1.12 Host: www.bookserver.com3 Content-Type: text/xml;4 charset="utf-8"5 Content-Length: nnnn6 SOAPAction: /bookserver/BookPrice#GetBookPrice78 <?xml version="1.0" encoding="UTF-8"?>9 <soap:Envelope10 xmlns:soap="http://www.w3.org/2001/12/soapenvelope"11 soap:encodingStyle="http://www.w3.org/2001/12/soapencoding">12 <soap:Header>13 <mybook:Trans14xmls:m="http://www.add.com/trans/"soap:mustUnderstand="1">15 23416 </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 SOAP1 HTTP/1.0 200 OK2 Content-Type: text/xml;3 charset="utf-8"4 Content-Length: nnnn56 <?xml version="1.0" encoding="UTF-8"?>7 <soap:Envelope8 xmlns:soap="http://www.w3.org/2001/12/soapenvelope"9 soap:encodingStyle="http://www.w3.org/2001/12/soapencoding">10 <soap:Header>11 <mybook:Trans12 xmls:m="http://www.add.com/trans/"soap:mustUnderstand="1">13 23414 </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
  26. 26. Il Web Service: architetture e standard Capitolo 1LISTING 1.7 – esempio di un messaggio di errore1 <?xml version="1.0" encoding="UTF-8"?>2 <soap:Envelope3 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 lastruttura dei messaggi e non il loro contenuto. I tag per descrivere una richiesta dielaborazione (oppure per avere un risultato) vengono definiti in uno schema specificoed 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 fariferimento, 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 partequindi di una particolare area semantica e dovrà sottostare alle regole che ne governanol’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 unacomprensione “parziale”, relativa cioè alla propria area di competenza semantica, eaprendo in tal modo la via all’uso modulare di più schemi per descrivere o gestire unostesso documento.1.3.1 Il documento WSDLIl Web Services Description Language (WSDL) [15] nasce da un consorzio formato daIBM, Microsoft e Ariba con lo scopo di trovare delle modalità per standardizzare i WebService (di tipo SOAP ma non solo). E’ un linguaggio formale XML-based che descrivel’interfaccia al Web Service e fornisce ad un’applicazione le informazioni necessarie 26
  27. 27. Il Web Service: architetture e standard Capitolo 1per accedere allo specifico servizio;permette di indicare il formato dei messaggi dainviare, i metodi esposti dal Web Service, i parametri e i valori di ritorno quindiconsente di usare i Web Service senza conoscere a priori le API con cui sonoimplementati. Lo scopo dei WSDL è permettere alle applicazioni l’interfacciamentoautomatico, cioè permettere ai software di comunicare senza l’intervento dell’utente inmodo tale da rendere il processo trasparente. Sia elementi astratti che implementazionipratiche sono combinati per definire le funzionalità e i meccanismi di accesso al WebService, 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 WSDL1 <?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"> 27
  28. 28. Il Web Service: architetture e standard Capitolo 111 <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:address61 location="http://localhost/axis/AxisAdmin"/>62 </port>63 </service>64 </definitions> 28
  29. 29. Il Web Service: architetture e standard Capitolo 1Esistono particolari tools capaci di interpretare il WSDL e generare lo scheletrodell’applicazione client (o anche del server stesso) nei vari linguaggi diprogrammazione. In seguito, attraverso un meccanismo di local proxy, è possibileaccedere al Web Service come se fosse una semplice chiamata ad una funzione locale.1.3.2 Lo standard UDDIL’Universal Discovery, Description ed Integration (UDDI) [16] offre un modo dipubblicare sul Web informazioni dettagliate sui Web Service . E’ una specifica(opzionale) per la realizzazione di registri distribuiti di Web Service. Si basaessenzialmente su standard, in particolare HTTP, DNS, XML, ed è appoggiato da W3Ce IETF. Originariamente è stato un consorzio creato da Microsoft e IBM per permettereun migliore utilizzo dei Web Service , mentre a partire dalla release 3.0 è diventato unconsorzio aperto che conta diversi membri.Sostanzialmente, UDDI, è un sistema centrale all’interno del quale sono contenuti iriferimenti (principalmente indirizzi Web) dei Web Service inseriti dalle aziende; persegnalare il proprio, sia commerciale che senza fini di lucro, è sufficiente registrarsi, unesempio è 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
  30. 30. Il Web Service: architetture e standard Capitolo 1Nella figura 1.5 si può vedere il flusso delle interazioni tra le componenti di un Web vedereService. 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 generazioneLe caratteristiche dei Web Service descritte finora mettono a disposizione lefunzionalità di connettività e comunicazione fra consumer e provider per lo standard comunicazioneSOAP. La pura connettività però non consente di avere servizi di livello enterprisecapaci 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 definireservizi simili a quelli che si trovano negli Application Server. L’insieme di questespecifiche è denominato di seconda generazione. Le specifiche di base e di prima 30
  31. 31. Il Web Service: architetture e standard Capitolo 1generazione hanno raggiunto un livello di stabilità accettabile grazie alla cooperazionefra i fornitori di servizi. Al contrario le specifiche di seconda generazione, necessariealla creazione di servizi enterprise, non sembrano ancora convergere verso un livello distabilità che consenta la creazione di prodotti interoperabili. Le aree principali cui sirivolgono 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 ServiceLe specifiche di coordinamento dei Web Services si basano su WS-Coordination.Questa specifica descrive un framework estensibile che mette a disposizione protocolliin grado di coordinare azioni di applicazioni distribuite basate su Web Service.Il coordinamento di Web Services può avere diversi fini, in particolare si sta prestandomaggior 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 utilizzanel caso in cui si abbia la necessità di aggregare diversi Web Services in un unità logicadi lavoro (LUW). WS-BusinessActivity usa ed estende il framework di WS-Coordination per definire dei protocolli di coordinamento atti ad aggregare operazionidi business non contenute in un’unità logica di lavoro. Il protocollo prevede la gestione 31
  32. 32. Il Web Service: architetture e standard Capitolo 1delle eccezioni nel caso di fallimento permettendo di eseguire delle operazioni dicompensazione.1.3.3.2 Gestione della sicurezzaEsistono 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 frameworkWSSecurity (ad esempio XML-Encryption, XML-Digital Signature, SAML, XKMS,XRML).Queste specifiche sono spesso parzialmente sovrapposte a quelle di WSSecurity e avolte in diretta competizione. Un numero così ampio di specifiche non aiuta ilraggiungimento di uno standard ufficiale anzi favorisce coloro che producono evendono implementazioni custom di questo tipo.Le specifiche di sicurezza sono quelle che probabilmente presentano il maggiore livellodi instabilità. Questa situazione è una delle maggiori cause della lenta adozione dei WebService nelle comunicazioni inter-aziendali. E’ chiaro infatti che in questo scenario lasicurezza diventa un must, ma non essendoci specifiche, i prodotti in larga parte nonsono interoperabili per cui il problema diventa di difficile soluzione. 32
  33. 33. Il Web Service: architetture e standard Capitolo 11.3.3.3 Qualità del servizioQueste specifiche servono a definire e osservare i livelli di servizio che devono essererispettati dai Web Service . Rientrano in questa categoria temi come: • Policy • Messaging • ManagementLe Policy definiscono i livelli di servizio ed eventuali altre regole di business dei WebService. Le specifiche sul messaging rientrano nello standard WS-Reliable Messagingche indirizza i problemi di gestione dei messaggi asincroni. Questa specifica assume unruolo rilevante in questo tipo di architetture in quanto si basa fortemente sullacomunicazione 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 delleinfrastrutture di management, con tali protocolli sarà possibile gestire qualunqueelemento del sistema informativo, ma naturalmente in prima battuta ci si focalizza sullagestione dei Web Service stessi.1.3.3.4 Business Process Execution LanguageBPEL è un linguaggio basato sull’XML costruito per descrivere formalmente i processicommerciali ed industriali (workflow, definisce i meccanismi e i formati con cuiavvengono le interazioni tra i servizi Web). Una volta descritto il processo è possibile 33
  34. 34. Il Web Service: architetture e standard Capitolo 1eseguirlo 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 codiceBPEL4WS esistono ambienti visuali (ad esempio Oracle BPEL Designer) chepermettono di disegnare in modo grafico i processi. Come si vede in figura 1.6, ilBPEL4WS si colloca nell’ultimo livello della struttura architetturale dei Web ServiceSOAP 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 RESTREST è l’acronimo di REpresentational State Transfer ed è un’alternativa a SOAP perfornire 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
  35. 35. Il Web Service: architetture e standard Capitolo 1per implementare un Web Service: l’HTTP con i suoi metodi, il supporto agli URI el’architettura server/client.A differenza di SOAP, REST non è un protocollo ma è uno “stile architetturale”, sfruttai 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 paginaXML 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 (unbrowser 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 è unarappresentazione della risorsa (il documento XML, “XS201.xml”) che pone il client inun particolare stato (possiamo chiamarlo “stato XS201”) da cui è possibile raggiungere,attraverso degli iper-link, le altre risorse (ad esempio, “Caratteristiche motore” a cuisarà associato lo stato “motore XS201”, e così via). C’è quindi un trasferimento di statiche permetterà all’applicazione client di raggiungere la risorsa desiderata e, a secondadei 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
  36. 36. Il Web Service: architetture e standard Capitolo 11.4.1 Un esempio di Web ServiceIn questo paragrafo descriveremo l’implementazione di un Web Service per la gestionedell’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/Sezioneche 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 uniper-link per passare alla risorsa successiva. Per fare questo viene usata la specificaXlink [18] che descrive una modalità standard per inserire collegamenti ipertestualiall’interno del file . Il documento restituito al client sarà del tipo mostrato nel listato 1.9.LISTING 1.9 – esempio di documento XML-REST1 <?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 successivoconsultando una nuova risorsa (vedere listato 1.10). 36
  37. 37. Il Web Service: architetture e standard Capitolo 1LISTING 1.10 – esempio di documento XML-REST1 <?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 (ilnome, la descrizione, la quantità di libri che contiene), inoltre un iper-link permette diottenere l’elenco dei libri presenti. I listati 1.11 e 1.12 mostrano l’avanzamento neglistati successivi e le risorse ad essi associate.LISTING 1.11 – esempio di documento XML-REST1 <?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-REST1 <?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 ripropostaper applicazioni in cui il numero di risorse è molto elevato (quindi il numero di pagine 37
  38. 38. Il Web Service: architetture e standard Capitolo 1XML). Per evitare di avere una lista molto lunga di pagine statiche (associate ad ognirisorsa) è possibile utilizzare link logici piuttosto che quelli fisici: cioè, l’URI descrive“quale è” la risorsa desiderata ma non identifica un oggetto “fisico” (il documentoXML); un data-base conterrà le informazioni di tutte le risorse e per ogni richiesta fattaattraverso un URL logico ci sarà un parser in grado di capire a quale risorsa si vuoleaccedere e lancerà una query. Solitamente un’applicazione client fornisce un form chesarà riempito con le informazioni sulla risorsa e che genera automaticamente un URLper lanciare la query. Le richieste viste nell’esempio possono essere gestite attraversoun normale browser indipendentemente dalla piattaforma hardware/software. Il metodoHTTP utilizzato per consultare le risorse sarà il GET. Vediamo, invece, come creare unservizio di prenotazioni attraverso il metodo POST: anche in questo caso si associa unURI ad una particolare risorsa “Prenotazioni” (www.biblio-embedded.it/Prenotazioni).Il documento XML che descrive una prenotazione può avere la forma mostrata nellistato 1.13.LISTING 1.13 – esempio di documento XML-REST1 <?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 lespecifiche semantiche fissate da www.biblio-embedded.it. Tali specifiche possonoessere pubblicate in un documento DTD chiamato WRDL (Web Resource DescriptionLanguage); quest’ultimo, a differenza del WSDL, non è uno standard riconosciuto alivello di W3C quindi non può essere considerato come uno strumento universale. 38
  39. 39. Il Web Service: architetture e standard Capitolo 1Uno 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 alWeb server la nostra richiesta di prenotazione che avrà come risposta un indirizzo URIunivoco 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
  40. 40. Il Web Service: architetture e standard Capitolo 11.4.2 Un confronto, REST vs SOAPRiprendendo l’esempio del paragrafo precedente è possibile sottolineare alcuni aspettiche rendono il REST adatto a particolari scenari applicativi. La figura 1.10 evidenzial’infrastruttura aggiuntiva di cui ha bisogno il SOAP rispetto al REST. Il vantaggioprincipale di incapsulare il payload (cioè l’informazione vera e prop che si vuole propriainviare) dentro un envelope SOAP sta nel poter utilizzare differenti tipologie di Webserver: 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 SOAPwww.biblioembedded.it/soap/s ).esaminare il messaggio e smistarlo verso la risorsa corretta; questo vuol dire che ilserver SOAP non è in grado di interpretare il contenuto del messaggio ma solamente dicapire 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
  41. 41. Il Web Service: architetture e standard Capitolo 11.4.2.1 La gestione degli accessi alle risorseUtilizzando un servizio REST è possibile associare ad ogni utente un URI specifica perlimitare il suo accesso ad alcune risorse; in questo modo è possibile sfruttare un serverproxy (o un altro tipo di intermediario) in grado di gestire gli accessi sulla base degliURI e del metodo invocato (GET, POST, ecc. . . ) (vedere figura 1.11 e 1.12). Nel casodi un servizio SOAP l’informazione della risorsa è ben nascosta dentro l’envelope,quindi non è sufficiente un server proxy per bloccare accessi non autorizzati (vederefigura 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
  42. 42. Il Web Service: architetture e standard Capitolo 1 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 modoche riesca ad interpretare la semantica del messaggio e capire quale è la risorsarichiesta, ma non tutte le applicazioni potrebbero usare la stessa semantica pe peridentificare la risorsa (vedere figura 1.14) quindi occorrono server proxy “ad hoc” checonoscano tutte le semantiche di tutte i messaggi SOAP che potrebbero ricevere.Un’alternativa a questa soluzione che non limita la scalabilità del server proxy stanell’utilizzo dei modelli RDF [23] o DAML [24], cioè specifiche W3C perrappresentare le informazioni e i legami che intercorrono fra di esse in un formatofacilmente elaborabile dai computer: in questo modo i messaggi SOAP sonointerpretabili dinamicamente dal server proxy attraverso delle richieste ad URI“RDF/DAML”. 42
  43. 43. Il Web Service: architetture e standard Capitolo 1 FIGURA 1.14 – due messaggi SOAP con stesse funzionalitàma semantica differente.1.4.2.2 Il meccanismo di caching delle risorseL’efficienza dei Web Service di tipo REST può essere aumentata utilizzando dei cacheserver capaci di memorizzare i documenti XML per permettere di ridurre il tempo diaccesso ad una risorsa (vedere figura 1.15). Infatti, le richieste vengono fatte attraversoil metodo GET e questo permette ad un cache server di fornire una copia “locale” dellarisorsa (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
  44. 44. Il Web Service: architetture e standard Capitolo 1Per quanto riguarda i Web Service SOAP si è visto che le richieste dei client vengonoinoltrate ad un unico URI attraverso il metodo POST, questo vuol dire che non sipotranno 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 daicontesti applicativi. Per una trattazione più ampia rimandiamo a [20]; in [21] èpresentato un caso di studio in cui vengono utilizzate entrambe le tecnologie applicate alflusso di dati, controlli e servizi tra organizzazioni e processi.1.5 Lo standard XML-RPCL’XML-RPC [25] è un protocollo codificato in XML per chiamate a procedure remotesu HTTP. La sua caratteristica principale è la semplicità, infatti definisce un ristrettogruppo di tipi di dati e di comandi. Fu ideato nel1995 da Dave Winer della UserLandSoftware in collaborazione con la Microsoft; quest’ultima rendendosi contodell’estrema semplicità incominciò ad aggiungere nuove funzionalità all’XML-RPCsino ad evolvere questo standard nell’attuale SOAP. Un server XML-RPC utilizza uninput composto da una semplice codifica XML di una chiamata di metodo inviata comehttp POST. Un esempio di richiesta è mostrato nel listato 1.14. 44
  45. 45. Il Web Service: architetture e standard Capitolo 1LISTING 1.14 – esempio di richiesta XML-RPC1 POST: /myXMLRPC/server.php HTTP/1.02 User-Agent: myUserAgent3 Host: prova.unige.it4 Content-Type: text/xml5 Content-lenght: nnnn67 <?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 dalserver: • 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 nodofiglio methodName avente come valore il nome della funzione. Nell’esempio, somma()ha come parametri (contenuti nel tag params) due numeri interi. La risposta restituitadal server è un messaggio XML che può rappresentare il dato richiesto (listato 1.15)oppure un errore (listato 1.16). 45
  46. 46. Il Web Service: architetture e standard Capitolo 1LISTING 1.15 – esempio di risposta XML-RPC1 HTTP/1.1 200 OK2 Connection: close3 Content-Lenght: nnnn4 Content-Type: text/xml5 Date: Sun, 15 Feb 2009 16:50:00 GMT6 Server: MyServer78 <?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-RPC1 HTTP/1.1 200 OK2 Connection: close3 Content-Lenght: nnnn4 Content-Type: text/xml5 Date: Sun, 15 Feb 2009 16:50:00 GMT6 Server: MyServer78 <?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> 46
  47. 47. Il Web Service: architetture e standard Capitolo 1Il messaggio di risposta sarà composto dagli header HTTP e dal documento XML cheha come nodo di root methodResponse; nel caso in cui si verifichi un errore si ha unnodo figlio chiamato fault che è composto da due membri obbligatori, faultCode efaultString: sarà compito del client comprendere il codice di errore e comportarsi diconseguenza. 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 SOAPL’obiettivo del protocollo XML-RPC è di fornire uno strumento molto semplice perfare chiamate a procedure remote in maniera rapida e indipendentemente dallapiattaforma hardware/software utilizzata. Un primo riscontro lo si ha davanti allespecifiche XML-RPC: sono circa sette pagine che comprendono esempi e FAQ, mentrele specifiche SOAP sono raccolte in quaranta pagine. Chiaramente occorre tenerpresente 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
  48. 48. Il Web Service: architetture e standard Capitolo 1un Web Service può averne bisogno. SOAP fa un ampio uso del meccanismo delnamespace e di tag per specificare gli attributi; se da un lato appesantisce la struttura delmessaggio dall’altro fornisce agli sviluppatori uno strumento molto più flessibile perdescriverei 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. . . ) echiamate dei metodi sono semplici allora l’XML-RPC è la scelta che consente di avereun applicazione più veloce e “leggera”.1.6 I Web Service e i sistemi embeddedPer quanto detto finora si può pensare che il mondo dei Web Service sia limitato adInternet e all’e-business ma parallelamente si sono sviluppati nuovi scenari in cui i WebService rappresentano soluzioni innovative: ad esempio, nell’ambito dell’automazioneindustriale (vedere paragrafo 2.2). La roadmap delle tecnologie a livello industrialeevidenzia lo svilupparsi di due tipologie di tecnologie che domineranno il futuro dellestrumentazioni: • 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è dispositivicon un bagaglio di funzionalità aggiuntive per il monitoraggio, la “diagnosi” deiproblemi, le configurazioni e le auto configurazioni, il controllo remoto , l’accessoremoto, ecc. . . Tutto ciò permette controlli più veloci e accurati, favorisce la creazionedi un database dei “fault” e, quindi, contribuisce in maniera notevole alla riduzione deicosti 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 PLCcon connessioni IP/Ethernet è economico, consente comunicazioni attraverso Internet epermette di manipolare i dati usando browser standard; infatti si prevede che nei 48
  49. 49. Il Web Service: architetture e standard Capitolo 1prossimi anni tutte le connessioni di un impianto industriale saranno di tipo IP/Etherneteccetto per le connessioni a più basso livello come quelle con sensori e attuatori.Una volta definite le caratteristiche hardware del sistema di controllo occorrespecificare 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 essereriassunti 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
  50. 50. Il Web Service: architetture e standard Capitolo 1 • 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

×