CAPITOLO 2
Simple Object Access Protocol
Come si `e detto, l’ambiente Grid deve prevedere un’estrema eterogeneit`a di si-stemi coinvolti, appartenenti a diverse organizzazioni coinvolte nel sistema, e per questo deve basare le sue tecnologie su protocolli e interfacce standard e non proprietarie, che andranno a creare una rete di comunicazione tra i vari nodi del Grid.
Tra le varie tecnologie possibili, un ottimo candidato per l’interazione tra nodi remoti `e rappresentato dal framework per l’RPC denominato SOAP, uno stan-dard sviluppato e promosso dal Consorzio W3C basato sul linguaggio XML, a sua volta standard W3C ormai consolidato in un sempre pi`u vasto spettro di campi di applicazione.
2.1
Service Oriented Architecture
L’idea alla base delle architeture SOA `e quella di creare una rete di appli-cazioni che interagiscono senza che intercorrano legami stretti tra di essi. Per realizzare questo obiettivo ci si propone di basare le interazioni tra i nodi della rete su interfacce esportate in qualche modo da ogni nodo. Tali interfacce descri-vono il tipo di servizio fornito e indicano il protocollo d’accesso a tale servizio, in particolare i parametri di input richiesti e i parametri che descrivono l’output del servizio. Questo `e definito come un’unit`a logica di computazione che un service provider fornisce al service consumer che lo richiede.
Attraverso questo tipo di struttura `e possibile creare dei sistemi estremamente flessibili e dinamici, soprattutto se affiancata all’utilizzo di protocolli di comu-nicazione general purpose, standard e non proprietari: in questo modo anche l’interfaccia che descrive il servizio pu`o essere disaccoppiata dalle caratteristiche implementative del servizio stesso.
Altre caratteristiche progettuali di un’architettura SOA possono essere quelli
Figure 2.2: Ruoli dei nodi in un’applicazione SOA elencati di seguito:
• i messaggi scambiati devono essere descrivere la richiesta di servizio senza implicare comportamenti particolari nell’elaborazione;
• le richieste di servizio devono essere idempotenti, in modo da eliminare problemi relativi a chiamate duplicate e rendere possibile il fault recovery semplicemente duplicando la richiesta fallita;
• devono essere limitate il pi`u possibile le situazioni che richiedono protocolli di comunicazione stateful, che rendono il sistema meno robusto e scalabile. Questo tipo di architettura non `e legata a nessuna tecnologia in particolare, ma `e stata implementata da numerevoli sistemi di largo uso, quali RPC, DCOM, CORBA e i cosiddetti Web Services.
2.2
Web Services
Come per il Grid, non esiste una definizione universalmente accettata su cosa effettivamente siano i Web Services. Quello che viene generalmente accettato col nome di Web Service `e un’applicazione di tipo SOA basata su protocolli e standard legati alla rete Internet:
• HTTP/HTTPS, FTP o SMTP come protocollo di trasferimento dati; • XML per la codifica dei messaggi;
• SOAP come meccanismo per la fruizione dei servizi; • WSDL e UDDI per la pubblicazione delle interfacce; • ...
2.3
eXtensible Markup Language
Di seguito viene fornita una breve descrizione dell’ormai famoso linguaggio di markup XML, per poter poi introdurre il protocollo di comunicazione SOAP, basato su messaggi scritti in un dialetto XML.
2.3.1 Le origini
Il linguaggio XML fu sviluppato nel 19961 da XML Working Group,
originaria-mente noto come SGML Editorial Review Board, costituitosi sotto la guida del W3C. Si presenta come un linguaggio testuale di markup, ovvero un linguaggio che opera delimitando dati e informazioni per attribuire loro significati e carat-teristiche. Il predecessore di XML, Standard Generalized Markup Language o SGML, fu la base di partenza per la progettazione di XML, che ancora rimane un sottoinsieme valido del linguaggio SGML. Per descrivere le caratteristiche di questo linguaggio `e utile ricordare gli obiettivi progettuali di XML, descritti nella raccomandazione W3C2, che sono:
• XML deve essere utilizzabile in modo semplice su Internet; • XML deve supportare un gran numero di applicazioni; • XML deve essere compatibile con SGML;
• Deve essere facile lo sviluppo di programmi che elaborino documenti XML; • Il numero di caratteristiche opzionali deve essere mantenuto al minimo
possibile, idealmente a zero;
1
[27]
2
• I documenti XML dovrebbero essere leggibili da un uomo e ragionevolmente chiari;
• La progettazione XML dovrebbe essere rapida; • La progettazione XML deve essere formale e concisa; • I documenti XML devono essere facili da creare;
• Non `e di nessuna importanza l’economicit`a nel markup XML;
Alcuni di questi obiettivi, unito alla caratteristica di standard aperto e non pro-prietario, costituiscono dei veri punti di forza che hanno portato in breve tempo ad una rapidissima diffusione di dialetti XML per un ampio ventaglio di applica-zioni, dalla gestione di file di configurazione, a semplici applicazioni di database, all’RPC.
2.3.2 Documenti XML
In sostanza `e un linguaggio progettato per strutturare, conservare e scambiare3
dati. Nella Figura 2.3 viene mostrato un estratto da esempio di reale utilizzo del linguaggio XML: si nota immediatamente l’intelligibilit`a delle informazioni contenute e le relazioni tra i vari elementi. In XML sono utilizzate le parentesi angolari per distinguere tra metadati XML, posti all’interno delle parentesi, ov-vero la dichiarazione di tag e la definizione dei suoi eventuali attributi, e i dati veri e propri. Questa tipo notazione, obbligatoria in XML, deriva da una diffusa pratica di utilizzo di SGML.
3
Figure 2.3: Esempio di XML
La prima riga dell’esempio, chiamata XML declaration, specifica alcune informa-zioni sul documento stesso necessarie ad un parser per la sua corretta elaborazio-ne: a parte la versione del linguaggio XML utilizzata possono comparire anche altre informazioni, ad esempio la codifica dei caratteri utilizzata.
Il resto del documento invece descrive un insieme di dati secondo una gerarchia strutturata ad albero: XML impone che ogni documento abbia uno ed un solo nodo, datto radice, che conterr`a altri nodi a formare il documento stesso. La regola di composizione di espressioni XML `e la nidificazione: all’interno di ogni nodo si pu`o avere un dato oppure zero o pi`u altri nodi, venendosi quindi a crea-re una struttura ad albero, che pu`o avecrea-re teoricamente infiniti rami e livelli di strutturazione.
I tag (nodi) possono essere • aperti es.: hnome tagi; • chiusi es.: h/nome tagi; • vuoti es.: hnome tag /i.
In XML si rende obbligatoria la presenza di entrambi i tag di apertura e chiusura per nodi non vuoti. I nodi detti vuoti sono privi di di dati o sottonodi al loro inteno: specificando solo metadati, si possono aprire e chiudere nella stessa defi-nizione. Il tag di apertura pu`o riportare anche, tra il nome del tag e la parentesi angolare chiusa, un elenco di propriet`a, dette attributi, nella forma di assegna-mento chiave/valore. `E da notare come gli attributi, pur essendo ampiamente utilizzati nella pratica, non aggiungono alcuna potenza espressiva al lin-guaggio, essendo perfettamente possibile esprimere una metainformazione come attributo di un nodo o come un figlio di quest’ultimo.
Esiste un certo insieme di regole sintattiche per la corretta definizione di un do-cumento XML: un dodo-cumento che rispetta tutti i vincoli del linguaggio `e detto well formed, e risulta idoneo all’elaborazione da parte di un calcolatore, che pu`o ricavare facilmente tutti i dati contenuti insieme alla loro strutturazione.
Un documento XML ben formato pu`o essere caratterizzato da tag completamente personalizzabili, lasciando la pi`u totale libert`a all’utente di decidere la semantica dei dati strutturati contenuti nel documento stesso, nei limiti delle regole sintat-tiche. Per descrivere le caratteristiche dei tag utilizzati in un documento XML in una forma comprensibile al calcolatore, cos`ı come succede per SGML, `e neces-sario collegare in qualche modo una raccolta di metainformazioni, sia essa una DTD o un Xml Schema Definition4, che stabilisca uno spazio di nomi per i tag e
i vincoli sintattici di ogni tag. Ad esempio si pu`o limitare il numero e il tipo dei nodi figli di un tag, oppure gli attributi che gli sono affiancabili. Un documento XML che rispetta la sua DTD si definisce Valid Document.
Un semplice documento XML, sebbene abbia come scopo ultimo la sua elabo-razione da parte di un calcolatore, risulta di facile lettura per un essere umano,
4
Figure 2.4: Namespace in XML
mentre applicazioni pi`u complesse risultano nell’utilizzo di documenti pi`u prolissi e meno leggibili, seppur rimanendo comprensibili, come nel caso di SOAP.
2.3.3 Namespace
Essendo XML progettato per garantire l’interoperabilit`a tra applicazioni diverse, si rende necessario prendere in considerazioni problematiche dovute alla collisio-ne di nomi: ogni sviluppatore `e libero di stabilire i nomi dei tag che usa collisio-nella sua applicazione, e di attribuire loro il significato desiderato. Se due applicazioni diverse si ritrovassero ad utilizzare lo stesso nome attribuendogli per`o significati diversi si andrebbero a creare situazioni di incongruenza.
Per poter assegnare un significato univoco ad un identificatore sono stati introdot-ti i Namespace, grazie ai quali `e possibile riferire ad una parintrodot-ticolare applicazione ogni identificatore presente nel documento, specificando la URL alla quale de-v’essere recuperata la definizione della grammatica del documento. L’esempio riportato in Figura 2.4 mostra come venga indicato ed utilizzato un namespace. Il nome completo di ogni entit`a risulta quindi composto dal nome del namespa-ce di riferimento e dal suo proprio, separati dai due punti, andando cos`ı a
su-bordinare il significato dell’identificatore all’applicazione associata al documento XML.
2.3.4 Pregi e difetti di XML
I maggiori campi di applicazione di XML sono l’interscambio di dati tra sistemi in generale eterogenei e il salvataggio di dati su memoria. In particolare se i do-cumenti XML vengono scambiati tra soggetti distinti, come due aziende diverse, risulta estremamente efficace la chiarezza del contenuto anche ad un utente uma-no. Il supporto di XML a Unicode ne permette inoltre l’utilizzo senza limitazioni relative alla localizzazione della particolare applicazione in cui viene impiegato. Un’altra importante caratteristica `e quella di supportare la rappresentazione delle strutture dati fondamentali usate nei linguaggi di programmazione, come vettori, strutture, liste ed alberi, che unito alla sintassi rigorosa con cui `e definito rendono la sua elaborazione da parte di un calcolatore estremamente efficiente. Altri pregi sono l’assenza di licenze sul suo formato, la potenza espressiva e la compatibilit`a con SGML, la cui diffusione e presenza decennale rende XML un linguaggio di semplice adozione ed utilizzo.
I maggiori difetti di XML sono generalmente individuabili dal punto di vista del-l’efficienza: la sua sintassi prolissa e ridondante non aiuta certo a minimizzare l’utilizzo di memoria o di banda trasmissiva, sebbene sia possibile recuperare efficienza attraverso le principali tecniche di compressione dati, particolarmen-te efficienti sui documenti XML. Altre caratparticolarmen-teristiche del linguaggio che hanno subito alcune critiche[13] sono:
• la sua eccessiva genericit`a, che porta XML ad includere caratteristiche non essenziali quali gli attributi dei tag;
• la mancanza di un supporto nativo ai tipi di dato fondamentali quali interi o booleani, che sebbene descrivibili sono trasparenti al parser;
• la difficolt`a di rapporto tra il modello gerarchico proposto da XML con i paradigmi relazionale e orientato agli oggetti.
2.4
SOAP
Lo sviluppo di SOAP comincia nel 1998 da una collaborazione tra UserLand, DevelopMentor e Microsoft, che dopo la pubblicazione di un un primo “working draft” cedettero il progetto al W3C5, che mantiene a tutt’oggi il controllo sulla
sua standardizzazione. Essenzialmente SOAP `e un protocollo per la codifica di chiamate a procedure remote attraverso documenti XML. Sebbene questi siano generalmente inviati attraverso il protocollo HTTP, la specifica di SOAP si limi-ta a prevedere un protocollo di scambio dei dati, riferendosi principalmente ad HTTP solo a titolo di esempio.
La forma pi`u semplice di invio di un messaggio SOAP consiste fondamentalmente nella trasmissione di tale documento da un nodo SOAP ad un altro, che assumo-no quindi quello che nella termiassumo-nologia SOAP viene chiamato ruolo di sender e receiver rispettivamente. Nonostante questo schema basilare di comunicazione sia estremamente semplice, SOAP `e progettato affinch`e l’invio di tali messaggi sia inserito in pi`u complessi pattern di comunicazione, a partire da un semplice challenge/response per approdare a scambi continui di messaggi simili ad una “conversazione” SOAP tra sender e receiver, in cui possono anche figurare no-di SOAP intermeno-di tra gli estremi del canale no-di comunicazione, che possono a loro volta manipolare il contenuto del messagio SOAP, tipicamente in funzione
5
dell’intestazione del messaggio. I pattern di comunicazione supportati da SOAP v1.2 sono descritti in un’apposita sezione della raccomandazione W3C6.
2.4.1 Messaggi SOAP
Concettualmente un messaggio SOAP `e composto come in Figura 2.5. Data la natura del linguaggio usato nei messaggi SOAP, ovvero un dialetto XML, il loro schema logico risulta essere una struttura ad albero, con una sola radice chiamata Envelope, e almeno un blocco all’interno della sezione chiamata SOAP Body, in cui dev’essere specificato il contenuto informativo del messaggio SOAP, mentre la presenza della sezione Header `e opzionale.
L’Envelope deve fare riferimento ad un particolare namespace, individuabile
Figure 2.5: Struttura logica di un messaggio SOAP
6
all’indirizzo http://www.w3.org/2003/05/soap-envelope, che descrive gli elementi strutturali di un messaggio SOAP, ovvero lo stesso Envelope, le sezioni Header e Body, assieme alle altre caratteristiche inserite nella raccomandazione, come la gestione degli errori e gli attributi standard.
2.4.1.1 SOAP Header
I nodi contenuti nella sezione Header specificano metainformazioni che non fan-no concettualmente parte del contenuto del messaggio, come ad esempio direttive per eventuali nodi con un ruolo da intermediario lungo il tragitto di routing del messaggio SOAP. `E da notare che la specifica di SOAP non affronta il contenuto dei blocchi dello Header, che sono definibili a discrezione del programmatore, ma solo una serie di attributi per gestire il modo con cui il nodo SOAP si deve comportare a riguardo.
Un nodo interessato nel percorso seguito da un messaggio SOAP, sia esso in-termedio o ultimo destinatario, pu`o essere settato per rivestire un particolare ruolo, in un modo non stabilito dallo standard, che pu`o essere staticamente o dinamicamente assegnato. Lo standard prevede tre ruoli base assumibili da un nodo SOAP, ovvero none, next e ultimateReceiver. Un blocco header pu`o essere impostato come destinato ad un particolare ruolo, attraverso l’attributo opzio-nale env:role. Il nodo SOAP elabora il contenuto della sezione Header e decide se e quale ruoli impersonare; in base a questo, se un blocco contenuto nell’hea-der `e collegato al ruolo impersonato dal corrente nodo SOAP, allora pu`o essere elaborato, e verr`a in generale rimosso prima dell’eventuale reinvio del messag-gio lungo il suo tragitto. Bisogna fare per`o alcune precisazioni: non `e sicuro che un nodo SOAP, che pure assume un ruolo per cui un blocco header `e de-stinato, elabori tale blocco. Tipicamente pu`o succedere che, vista l’eterogeneit`a
riscontrabile in un’applicazione di tipo SOAP, il nodo “non capisca”, ovvero non sappia come elaborare, il blocco Header a lui competente. Per gestire questo tipo di situazioni, SOAP prevede un attributo opzionale per i blocchi contenuti nell’Header, avente nome env:mustUnderstand e a valore booleano. In caso un nodo non sappia come processare un blocco header a lui destinato e con l’attri-buto env:mustUnderstand impostato a true viene sollevato un SOAP Fault. In mancanza di fault, se un nodo intermedio trova un header block assegnato al suo rolo, il comportamento di default `e quello di rimuovere tale blocco prima di inoltrare il messaggio nella continuazione del suo cammino, a prescindere dal fatto che sia capace o meno di processare tale blocco. Questo comportamento pu`o essere controllato esplicitamente attraverso l’attributo opzionale env:relay, a valore booleano, che se impostato a true impone la preservazione del blocco header relativo lungo il tragitto seguito dal messaggio SOAP.
2.4.1.2 SOAP Body
Il contenuto informativo eventualmente trasportato da un messaggio SOAP trova spazio nei blocchi contenuti nella sezione Body. Il contenuto di questa sezione, in particolare nei nodi figli dell’elemento Body, `e fortemente dipendente dall’ap-plicazione, che pu`o inserire zero o pi`u blocchi di informazione destinati all’utimo ricevitore, posto alla fine del percorso di routing del messaggio. Sebbene sia pos-sibile inviare messaggi SOAP privi di contenuti informativi, ad esempio per scopi di segnalazione7, la sezione Body `e indicata come obbligatoria all’interno
dell’En-velope SOAP, a differenza della sezione Header quindi si deve sempre inserire il Body.
7
una parte della raccomandazione W3C descrive l’utilizzo di SOAP secondo il pattern one-way
Viene lasciata molta libert`a al programmatore su come definire i blocchi interni al Body: a parte la raccomandazione di legare il nome di ogni nodo ad un na-mespace, cosa che comunque non implica obbligatoriet`a, un blocco del Body pu`o contenere zero o pi`u nodi figli, i quali a loro volta possono essere o meno relativi ad un particolare namespace, e cos`ı via.
Un caso particolare di nodo figlio del Body, inserito nello standard, riguarda l’elemento Fault, descritto nella prossima sezione.
2.4.1.3 Gestione degli errori
In SOAP si prevede la possibilit`a di notificare gli errori incontrati durante il transito di un messaggio verso il suo ultimo ricevitore. Nonostante questo, `e da notare come la capacit`a di segnalare tale errori non sia sempre disponibile, in quanto il protocollo di trasferimento sottostante al livello SOAP potrebbe non averla.
Senza scendere troppo nel dettaglio, il nodo Fault `e posto come figlio diretto dell’elemento Body, e richiede obbligatoriamente due figli:
• code - in cui si specifica il codice d’errore con cui individuare univocamente il problema che ha sollevato la situazione di fault, suddiviso tra i campi Value (obbligatorio) e Subvalue (facoltativo);
• reason - contenente una o pi`u stringhe che descrivono la situazione di fault. Si possono anche avere ulteriori campi facoltativi, ad esempio per indicare quale nodo ha riscontrato la situazione di errore e il campo Detail, in cui si possono aggiungere vari dettagli secondo una struttura libera decisa dal programmatore. Le macro categorie di errore individuate dal campo code sono individuate secondo questa lista:
• VersionMismatch - dovuto ad una versione SOAP del messaggio non compatibile con le capacit`a di elaborazione del nodo;
• MustUnderstand - se un nodo non sa come elaborare un blocco contras-segnato come mustUnderstand per il suo ruolo;
• DataEncodingUnknown - dovuto alla codifica di caratteri utilizzata, non prevista dal nodo;
• Sender - se viene individuato un errore formale nel messaggio imputabile al trasmettitore, intendendo la necessit`a di modificare il messaggio prima di una eventuale ritrasmissione;
• Receiver - il ricevitore non riesce momentaneamente ad elaborare il mes-saggio, intendendo che una ritrasmissione futura dello stesso messaggio non modificato potrebbe essere correttamente elaborata.
2.4.2 SOAP come meccanismo RPC
Uno dei principali obiettivi della specifica SOAP, in particolare della versione 1.2, `e quello di supportare il suo utilizzo come meccanismo per le chiamate a metodo o procedura remota, pi`u semplicemente indicate come RPCs, supportando i prin-cipali linguaggi di programmazione. In questo senso, non esiste un particolare linguaggio a cui fare riferimento: si fa affidamento alla flessibilit`a espressiva di XML per mappare correttamente la definizione e l’invocazione di chiamate remo-te a metodi e procedure in un messaggio SOAP.
Si demanda al protocollo sottostante il livello SOAP la capacit`a di supportare l’invio della chiamata a procedura e all’eventuale risposta contenente il risultato dell’elaborazione: quando si utilizzi il binding HTTP, tali operazioni sono map-pate rispettivamente con la Request e la Response HTTP. In caso si utilizzi lo
schema one-way SOAP, che non prevede un valore di ritorno, la Response HTTP conterr`a una sezione Body vuota.
Per poter esprimere una chiamata a procedura remota con SOAP, sono in generale necessarie le seguenti informazioni:
• l’indirizzo del nodo su cui eseguire la procedura;
• il nome della procedura da eseguire o comunque un modo per individuarla univocamente8;
• gli identificatori e i valori dei parametri della procedura, sia di ingresso chee di uscita, assieme all’eventuale valore di ritorno;
• dev’essere possibile separare le informazioni necessarie per individuare il no-do target da quelle necessarie per l’esecuzione dela procedura, specialmente in relazione al protocollo sottostante9.
Il nodo su cui eseguire la procedura assume, dal punto di vista di SOAP, il ruo-lo di ultimate receiver, e deve poter capire quale sia la procedura da invocare: questa informazione pu`o essere collegata a meccanismi dovuti al protocollo sot-tostante oppure pu`o essere inserita come blocco header. Un esempio del primo metodo si ha in relazione al binding con HTTP, che prevede un insieme di header HTTP per specificare varie metainformazioni sul messaggio SOAP, tra cui anche la URI del metodo remoto. La chiamata a procedura remota vera e propria sar`a trasportata all’interno della sezione Body del messaggio SOAP.
8
ad esempio attraverso un URI
9
si pensi ad una richiesta HTTP POST, in cui sono presenti contemporaneamente metainformazioni HTTP e messaggio SOAP
2.4.2.1 Un esempio
Si mostrer`a a titolo di esempio l’uso di un servizio per una biglietteria elettroni-ca. Il programma utilizzato per questo esempio `e stato sviluppato nel linguaggio C++ attraverso l’uso del framework gSOAP: risulta utile mostrare qui come av-venga il mapping tra la chiamata a funzione e il messaggio SOAP relativo, anche se per una comprensione dettagliata dell’esempio si rimanda alla Sezione 2.4.3, in cui viene descritto pi`u nello specifico il funzionamento di gSOAP.
Si consideri il Listato 2.1, in cui vengono definiti i tipi dei parametri e il pro-totipo della funzione che rappresenta il servizio offerto da un server remoto ad un agenzia di viaggi. I primi due parametri sono effettivamente l’input richiesto dalla funzione, mentre l’ultimo parametro, che individua i posti diponibili per il volo, rappresenta un parametro di output per la funzione, il cui valore di ritorno `e utilizzato per la gestione degli errori.
Listing 2.1: Prototipo della procedura remota
1 c l a s s Volo 2 { 3 p u b l i c: 4 ch a r∗ codice ; // u n i c o pe r o g n i t r a t t a 5 } ; 6 7 c l a s s Data // g i o r n o d i p r e n o t a z i o n e 8 { 9 p u b l i c: 10 i n t giorno; 11 i n t mese; 12 i n t anno; 13 } ; 14 15 c l a s s Posto 16 { 17 p u b l i c: 18 i n t numero; // numero p o s t i pe r t a r i f f a
19 ch a r∗ t a r i f f a ; // t i p o l o g i a 20 Posto∗ l i n k ; // pe r c o s t r u i r e una l i n k e d l i s t 21 } ; 22 23 c l a s s D i s p o n i b i l i 24 { 25 p u b l i c: 26 Posto∗ p o s t i ; // l i n k e d l i s t 27 i n t quanti; // p o s t i t o t a l i 28 } ; 29 30 // p r o t o t i p o d e l l a f u n z i o n e remota 31 i n t d i s p o n i b i l i e ( Volo, 32 Data, 33 D i s p o n i b i l i& ) ;
Si assume che l’applicazione client sia gi`a a conoscenza delle informazioni ne-cessarie ad individuare in rete questo servizio, ovvero l’indirizzo del server e il prototipo in questione. Diversamente, sarebbe necessaria una fase detta di disco-very, in cui il client cerca queste informazioni, ottenibili tipicamente attraverso una descrizione WSDL iscritta in un registro UDDI.
Il problema fondamentale `e riuscire ad individuare all’interno del messaggio SOAP le porzioni di testo che descrivono i parametri in gioco e il valore da loro assunto. Un esempio di chiamata remota a tale servizio utilizzando SOAP `e mostrato nel Listato 2.2, in cui si utilizza HTTP come protocollo di trasferimento dati.
Listing 2.2: Chiamata a procedura remota via SOAP
1 POST / HTTP/ 1 . 1
2 Host: www. agenzia−viaggi . com:8081 3 User−Agent: gSOAP/ 2 . 7
4 Content−Type: text /xml ; charset=utf −8 5 Content−Length: 526
6 Connection: c l o s e 7 SOAPAction: ” ” 8
10 <SOAP−ENV:Envelope
11 xmlns:SOAP−ENV=” h t t p : // schemas . xmlsoap . o r g / soap / e n v e l o p e / ” 12 xmlns:SOAP−ENC=” h t t p : // schemas . xmlsoap . o r g / soap / e n c o d i n g / ” 13 x m l n s : x s i=” h t t p : //www. w3 . o r g /2001/ XMLSchema−i n s t a n c e ” 14 x m l n s : x s d=” h t t p : //www. w3 . o r g /2001/XMLSchema ” 15 x m l n s : a g e n z i a=” h t t p : //www. a g e n z i a −v i a g g i . com/ a g e n z i a . xsd ”> 16 <SOAP−ENV:Body> 17 <a g e n z i a : d i s p o n i b i l i> 18 <param−1> 19 <c o d i c e>AX120P</ c o d i c e> 20 </param−1> 21 <param−2> 22 <g i o r n o>5</ g i o r n o> 23 <mese>3</ mese> 24 <anno>2007</ anno> 25 </param−2> 26 </ a g e n z i a : d i s p o n i b i l i> 27 </SOAP−ENV:Body> 28 </SOAP−ENV:Envelope>
La sezione Body contiene la descrizione dei parametri di ingresso alla funzione re-mota. Si nota come le classi Volo e Data, codificate secondo la loro posizione nel prototipo come param-1 e param-2, vengano rappresentate secondo la struttura interna dei campi informativi.
Si presti attenzione allo header HTTP: la presenza del campo SOAPAction, il cui scopo `e quello di specificare quale sia il servizio destinatario della richie-sta SOAP, `e obbligatoria per il binding di SOAP con HTTP, anche nel ca-so presente in cui il servizio richiesto `e univocamente individuato dalla URL www.agenzia-viaggi.com:8081. In questi casi, il valore del campo SOAPAction `e una stringa nulla.
Una possibile risposta del server `e mostrata nel Listato 2.3, in cui viene fornito il valore del parametro di output.
1 HTTP/ 1 . 1 200 OK 2 Server: gSOAP/ 2 . 7
3 Content−Type: text /xml ; charset=utf −8 4 Content−Length: 552
5 Connection: c l o s e 6
7 <? xml v e r s i o n=” 1 . 0 ” e n c o d i n g=”UTF−8” ?>
8 <SOAP−ENV:Envelope
9 xmlns:SOAP−ENV=” h t t p : // schemas . xmlsoap . o r g / soap / e n v e l o p e / ” 10 xmlns:SOAP−ENC=” h t t p : // schemas . xmlsoap . o r g / soap / e n c o d i n g / ” 11 x m l n s : x s i=” h t t p : //www. w3 . o r g /2001/ XMLSchema−i n s t a n c e ” 12 x m l n s : x s d=” h t t p : //www. w3 . o r g /2001/XMLSchema ” 13 x m l n s : a g e n z i a=” h t t p : //www. a g e n z i a −v i a g g i . com/ a g e n z i a . xsd ”> 14 <SOAP−ENV:Body> 15 <a g e n z i a : D i s p o n i b i l i R e s p o n s e> 16 <p o s t i> 17 <numero>10</ numero> 18 <t a r i f f a>economy</ t a r i f f a> 19 <l i n k> 20 <numero>5</ numero> 21 <t a r i f f a>business</ t a r i f f a> 22 </ l i n k> 23 </ p o s t i> 24 <q u a n t i>15</ q u a n t i> 25 </ a g e n z i a : D i s p o n i b i l i R e s p o n s e> 26 </SOAP−ENV:Body> 27 </SOAP−ENV:Envelope>
In questo caso `e possibile notare come venga codificata una linked list, in questo caso la struttura dati con cui si descrivono i posti disponibili. Nella rappresen-tazione ad albero utilizzata in XML, ogni puntatore diventa la radice del sotto albero che contiene tutti gli elementi successivi.
La codifica per i tipi di dato fondamentali `e stata standardizzata dal W3C in [25].
2.4.2.2 Discovery
Un sistema basato sui Web Services `e per definizione distribuito, modulare ed eterogeneo: l’indipendenza tra i dettagli implementativi di un servizio e la fruibi-lit`a dello stesso `e ottenuta attraverso la modellizzazione di interfacce in linguaggi standard che descrivono le modalit`a di interazione tra i nodi. `E quindi possibile che un client non abbia conoscenza a priori di varie caratteristiche del servizio che richiede, come la URI del servizio o il prototipo. Lo standard attuale che sta-bilisce le regole per l’ottenimento a runtime di tali informazioni `e Web Services Interoperability, WS-I in breve, la cui gestione `e seguita collaborativamente da un insieme di imprese di grande dimensione, prime fra tutte IBM, Microsoft e SAP. Pi`u che progettare da zero protocolli e interfacce, WS-I descrive un Profilo che si compone di standard separati e promossi da enti diversi, ovvero SOAP, WSDL e UDDI. I primi due progetti sono portati avanti dal W3C, mentre l’ultimo `e uno standard OASIS.
Lo Universal Description Discovery and Integration `e un registro in linguaggio XML diviso nelle sezioni White, Yellow e Green Pages: in ques’ultima in parti-colare risiedono informazioni tecniche quali, ad esempio, le URI in cui risiedono le specifiche di ogni singolo Web Service. Tali specifiche sono descritte usando il Web Services Description Language, anch’esso basato su XML, attraverso il quale si pubblicano informazioni quali
• gli endpoint ai quali sono collegati i songoli servizi; • la struttura dei dati usati dai servizi;
• gli schemi XML da usare.
Per riassumere, la Figura 2.6 mostra gli strati di astrazione che partecipano in un’applicazione secondo lo standard WS-I.
Figure 2.6: Layer stack di WS-I
2.4.3 gSOAP
Sviluppato da Robert A. van Engelen, professore associato dell’Universit`a di Lei-den in Olanda, per conto della societ`a Genivia di cui `e fondatore, gSOAP `e un development toolkit che fornisce un’interfaccia di programmazione C/C++ per l’uso di SOAP/XML e lo sviluppo di Web Services. Il componente principale di gSOAP `e il preprocessore soapcpp2, il cui utilizzo verr`a descritto in seguito. Le specifiche definite da Engelen per lo sviluppo di gSOAP sono descritte di seguito.
generare le routine di [de]codifica dei tipi necessari alle procedure remote. `
E stato evidenziato come la parte fondamentale del messaggio SOAP che imple-menta l’RPC sia la descrizione dei parametri di input/output della procedura, e
la serializzazione e deserializzazione dei dati sono quindi alla base del meccanismo RPC.
supporto ai tipi di dato fondamentali in particolare se strutturati, che come gi`a detto non sono coperti dallo standard SOAP.
minimizzare le operazioni in memoria utilizzando direttamente i dati come sono stati allocati dall’applicazione.
minimizzare l’impiego di memoria Se gli eseguibili di client e server spesso rientrano in 150Kb di memoria, facilitando l’impiego in sistemi embedded, la gestione dei buffer per i messaggi dev’essere curata in modo da evitare grossi ingombri. Altra voce importante in termini di memoria riguarda la hash table costruita per la serializzazione delle strutture dati.
parsing efficiente di XML In particolare gSOAP `e fornito assieme ad un parser on-demand che non necessita la bufferizzazione di porzioni del documento XML.
consistenza delle strutture dati che devono essere adattate a diverse collo-cazioni in memoria prima e dopo il trasferimento dal client al server e viceversa, modificando opportunamente i puntatori che tengono insieme i dati.
supporto ad applicazioni legacy attraverso l’uso di routine precompilate per la codifica dei tipi primitivi e user-defined, che permette anche di supportare vecchi applicativi Fortran attraverso il binding con il C.
indipendenza dalla piattaforma di tutto il codice sorgente prodotto, che pu`o essere compilato ed eseguito su Linux, Unix, MS Windows 98/2000/NT/XP/CE, PocketPC e sistemi embedded.
2.4.3.1 Un esempio pratico: biglietteria elettronica
Riprenderemo qua l’esempio della biglietteria elettronica utilizzato nella Sezione 2.4, vedendo nel dettaglio i passi necessari per l’implementazione con gSOAP di tale servizio. Questa sezione non si propone come una guida all’uso di gSOAP, per la quale si rimanda a [4], ma vuole solo mostrare un esempio tipico del suo utilizzo.
Il processo di sviluppo di un’applicazione gSOAP pu`o iniziare da diversi presup-posti: ad esempio, se si necessita di un client per un servizio offerto da terze parti `e possibile partire dalla sua descrizione WSDL, da elaborare attraverso la utility wsdl2h fornita dal toolkit gSOAP, che produce un header da dare in input al preprocessore soapcpp2. Se invece si sviluppa un’applicazione da zero allora occorre scrivere a mano l’header gSOAP. Nel nostro caso, l’header agenzia.gh `e quello mostrato nel Listato 2.4.
Listing 2.4: agenzia.gh
1 // gsoap a g e n z i a s e r v i c e name : a g e n z i a
2 // gsoap a g e n z i a s e r v i c e ty p e : S e r v i c e P o r t T y p e
3 // gsoap a g e n z i a s e r v i c e p o r t : h ttp : / /www. a g e n z i a −v i a g g i . com : 8 0 8 1
4 // gsoap a g e n z i a schema namespace : h ttp : / /www. a g e n z i a −v i a g g i . com/ a g e n z i a . xsd 5 /∗ Parametri d i i n p u t ∗/ 6 c l a s s agenzia Volo 7 { 8 p u b l i c : 9 ch a r ∗ codice ; // u n i c o p er o g n i t r a t t a 10 } ; 11 c l a s s agenzia Data // g i o r n o d i p r e n o t a z i o n e 12 {
13 p u b l i c : 14 i n t giorno ; 15 i n t mese ; 16 i n t anno ; 17 } ; 18 c l a s s agenzia Posto 19 { 20 p u b l i c : 21 i n t numero ; // numero p o s t i p er t a r i f f a 22 ch a r ∗ t a r i f f a ; // t i p o l o g i a 23 Posto∗ l i n k ; // p er c o s t r u i r e una l i n k e d l i s t 24 } ; 25 26 /∗ Parametri d i o u t p u t ∗/ 27 c l a s s agenzia DisponibiliResponse 28 { 29 p u b l i c : 30 Posto∗ p o s t i ; // l i n k e d l i s t 31 i n t quanti ; // p o s t i t o t a l i 32 } ; 33 34 /∗ D i c h i a r a z i o n e d e l l e p r o c e d u r e ∗/ 35 i n t a g e n z i a d i s p o n i b i l i ( Volo, 36 Data, 37 DisponibiliResponse& ) ;
Si pu`o notare come sia i tipi di dato che il prototipo di funzione abbiano il prefisso agenzia separato da un doppio underscore dal nome vero e proprio. Questo `e il metodo usato da gSOAP per associare i nomi delle entit`a al namespace agenzia. La dichiarazione dei tipi di dato utilizzati dalle procedure chiamate attraverso SOAP `e utilizzata dal preprocessore soapcpp2 per la generazione delle relative routine di encoding, assieme ad una lunga serie di altre funzioni il cui scopo `e generalmente quello di codificare le porzioni del messaggio SOAP.
Dando in input a soapcpp2 il file header mostrato, vengono prodotti tutti i file necessari per utilizzare SOAP all’interno di un’applicazione distribuita C/C++:
• la descrizione WSDL del servizio e delle strutture dati relative;
• i prototipi dei messaggi SOAP di chiamata e risposta, in file XML dedicati; • le definizioni degli schemi XML usati nei messaggi SOAP;
• i file sorgente in cui sono definite tutte le funzioni di codifica e decodifica, sia per i client che per i server;
• i file header da utilizzare nei sorgenti dell’applicazione per il collegamento con il toolkit gSOAP;
• un file header dove viene dichiarata una classe proxy da utilizzare nella realizzazione dei client del servizio;
• un file header dove viene dichiarata una classe skeleton da estendere per la realizzazione del server.
Gli ultimi due file sono utili nello sviluppo di applicazioni C++: mentre l’utiliz-zo nel linguaggio C di gSOAP prevede l’uso di una struct soap per gestire il runtime del toolkit, le classi definite in questi header costruiscono un wrapping object-oriented per l’utilizzo di gSOAP in un’applicazione C++. Rimarrebbero comunque avulse dal paradigma object-oriented le implementazioni effettive delle procedure da chiamare attraverso gSOAP, il cui binding a runtime viene sempre effettuato attraverso il meccanismo C delle callback.
Come `e stato detto, il preprocessore soapcpp2 produce la dichiarazione di uno skeleton per la realizzazione di una classe server, le cui funzioni principali sono mostrate nel Listato 2.5.
Listing 2.5: Funzioni membro dello skeleton
1 c l a s s agenzia{ 2 p u b l i c:
3 [ . . . ]
4 v i r t u a l ˜ agenzia ( ) { soap destroy (t h i s) ; soap end (t h i s) ; soap done (t h i s) ; } ; 5
6 v i r t u a l i n t bind(c o n s t ch a r ∗ host , i n t port, i n t backlog) 7 { r e t u r n soap bind(t h i s , host , port , backlog ) ; } ;
8
9 v i r t u a l i n t accept( ) { r e t u r n soap accept(t h i s) ; } ; 10
11 v i r t u a l i n t serve( ) { r e t u r n soap serve(t h i s) ; } ; 12 } ;
Non `e mostrato il costruttore, che altro non fa se non settare le stringhe relative ai namespace usati, sia quelli standard SOAP sia quelli custom.
Lo skeleton prodotto `e gi`a direttamente utilizzabile per la realizzazione del server, in quanto permette sia il bind sull’endpoint relativo al servizio sia il dispatch della chiamata attraverso messaggio SOAP alla funzione agenzia disponibili. In particolare gSOAP richiede che l’implementazione di questa funzione accetti un ulteriore parametro oltre a quelli indicati nello header del Listato 2.4, ovvero un puntatore di tipo struct soap*, che referenzia la struttura fornita dalla API di gsoap per poter gestire il runtime del toolkit. Lo pseudocodice necessario per completare il server `e mostrato nel Listato 2.6.
Listing 2.6: Funzioni membro dello skeleton
1 [ . . . ] /∗ i n c l u s i o n e d e i f i l e p r o d o t t i da soapcpp2 ∗/ 2
3 i n t main ( ) 4 {
5 agenzia∗ a = new agenzia;
6 i f ( a−>bind ( ” l o c a l h o s t ” , 1 2 3 4 , 5 ) < 0 ) 7 { 8 /∗ g e s t i o n e d e l l ’ e r r o r e ∗/ 9 } 10 w h i l e ( 1 ) 11 { 12 i f ( a−>accept ( ) < 0 )
13 { 14 /∗ g e s t i o n e d e l l ’ e r r o r e ∗/ 15 } 16 a−>serve ( ) ; 17 } 18 19 r e t u r n 0 ; 20 } 21 22 i n t a g e n z i a d i s p o n i b i l i ( soap∗ soap , 23 agenzia Volo v, 24 agenzia Data d, 25 a g e n z i a D i s p o n i b i l i& res ) 26 { 27 /∗ i m pl e m e n t az i on e d e l l a r o u t i n e ∗/ 28 29 r e t u r n SOAP OK; 30 }
2.5
SwA: scambio di file
Il meccanismo precedentemente visto per l’utilizzo di SOAP non `e adatto al tra-sferimento di dati binari, in particolar modo se di grosse dimensioni, per i tempi necessari alla codifica/decodifica dei dati. Ad esempio, se all’interno di un file binario sono presenti i valori esadecimali x3C e 3E, corrispondenti ai valori nella tabella ASCII delle parentesi angolari aperta e chiusa, per garantire il corretto parsing del messaggio tali sequenze di bit dovrebbero essere sostituite con le se-quenze di escape < ed >10, rispettivamente, prima della trasmissione. Dopo
la ricezione bisognerebbe poi riportare il contenuto nella sua forma originale. Il metodo pi`u opportuno per inviare file di dimensione consistente attraverso SOAP `e di allegarli al messaggio, mantenendo comunque una separazione logica
10
tra i file e il messaggio SOAP stesso: a questo scopo sono state inserite nella rac-comandazione W3C[24] le metodologie di utilizzo di SOAP insieme agli standard MIME, DIME e MTOM per la codifica e il trasferimento di attachment.
2.5.1 MIME
Lo standard Multipurpose Internet Mail Extensions `e stato creato inizialmente co-me estensione dello standard SMTP per il trasferico-mento della posta elettronica[32], che supporta solo caratteri ASCII codificati a 7 bit, per permettere l’invio di dati arbitrari. Un obiettivo di progetto nello sviluppo di MIME era la compatibilit`a con i server mail preesistenti. Lo standard MIME prevede la classificazione delle informazioni a seconda del loro contenuto logico.
MIME affianca all’insieme di headers disponibili per SMTP un nuovo set di hea-ders destinati a specificare metainformazioni su blocchi di dati posti contestual-mente al messaggio destinato all’invio attraverso SMTP. Questi blocchi di dati prendono il nome di allegati. Tutti gli allegati MIME sono opzionali, e i valori di default specificano esattamente il comportamento dei client di posta precedenti MIME.
Gli header pi`u importanti sono:
• MIME-Version tipicamente settato al valore “1.0”;
• Content-Type permette di associare un tipo di file al blocco dati allegato, ad esempio per indicare la presenza di un’immagine JPEG (“image/jpeg”) o un file compresso (“application/zip”). Al valore del Content-Type pu`o essere associato un insieme di attributi, specificato nello stesso header. Par-ticolare importanza riveste il tipo multipart, attraverso il quale `e possibile inserire pi`u allegati nello stesso messaggio e che richiede il parametro
boun-dary. Questa caratteristica verr`a affrontata pi`u nel dettaglio nella Sezione 2.5.1.1;
• Content-Transfer-Encoding permette di specificare codifiche[20] che per-mettono la rappresentazione di caratteri non esprimibili con i 7-bit della tabella ASCII supportata da tutte le applicazioni SMTP. Di particolare ri-levanza i formati quoted-printable, utilizzato prevalentemente per i testi, e base64, per i dati binari;
• Content-ID usato per associare un identificatore unico all’allegato, par-ticolarmente utile per referenziare un singolo allegato in un messaggio con allegati multipli, come descritto nella prossima sezione.
2.5.1.1 Allegati multipli
Specificando il valore multipart per l’header Content-Type `e possibile inserire contemporaneamente nello stesso messaggio pi`u allegati. L’insieme degli alle-gati assume una struttura ad albero, che deve rispettare le seguenti regole di composizione:
• i nodi foglia devono essere degli allegati MIME semplici, ovvero possono avere un header Content-Type qualsiasi ad eccezione di multipart; • i nodi intermedi possono essere sia nodi semplici che nodi di tipo multipart. Nel caso di allegati di tipo multipart si deve specificare nell’header Content-Type anche un’altra informazione, chiamata boundary, che assume come valore una stringa arbitraria. Tale stringa viene usata come delimitatore dell’allegato, e pertanto dev’essere cura dell’utente o del software che adopera verificare che non
esista all’interno dell’allegato la stessa sequenza di caratteri. Un semplice esempio tratto da [12] `e mostrato nel Listato 2.7.
Listing 2.7: Esempio di email con allegato MIME
1 From: Nathaniel Borenstein <nsb@bellcore . com> 2 To: Ned Freed <ned@innosoft. com>
3 Subject: Sample message 4 MIME−Version : 1 . 0
5 Content−type : multipart/mixed ; boundary=”simple boundary” 6
7 This i s the preamble. I t i s to be ignored, though i t 8 i s a handy place f o r mail composers to include an 9 explanatory note to non−MIME compliant readers . 10 −−simple boundary
11
12 This i s i m p l i c i t l y typed pl a i n ASCII text. 13 I t does NOT end with a linebreak.
14 −−simple boundary
15 Content−type : text / plain ; charset=us−a s c i i 16
17 This i s e x p l i c i t l y typed pl a i n ASCII text. 18 I t DOES end with a linebreak.
19
20 −−simple boundary−−
21 This i s the epilogue. I t i s a l s o to be ignored.
Come si deduce dall’esempio, le parti che compongono il messaggio sono separate dal boundary, ed ogni parte pu`o contenere degli header MIME. In particolare il Content-Type permette di indicare volta per volta che tipo di informazione si sta inviando per ogni porzione del multipart. Tutto il corpo del messaggio dev’essere contenuto tra --boundary e --boundary--, all’interno dei quali si pu`o separare il messaggio di altre parti utilizzano --boundary come separatore. Se il corpo del messaggio contiene dei dati al di fuori dalle parti delimitate dai boun-daries, tali dati saranno ignorati. Di nuovo, dev’essere cura dell’utente o del software utilizzato verificare che i dati inseriti i ogni sezione non contengano la
stringa delimitatrice.
Nell’esempio si nota che il Content-Type pi`u esterno `e indicato come multipart/mixed: la categoria MIME multipart ha infatti dei sottotipi, definiti in diverse RFC e con delle implicazioni sul Content-Type delle parti del messaggio. Dei vari sot-totipi multipart specificati per MIME, ai fini della presente trattazione `e di fondamentale importanza il multipart/related. Questo sottotipo multipart indica la presenza di un insieme di allegati tra cui sussiste una dipendenza re-ciproca per la quale il corretto utilizzo dei dati non `e ottenibile in generale con l’elaborazione sequenziale degli allegati. Attraverso il parametro start previ-sto per queprevi-sto Content-Type `e possibile indicare quale allegato elaborare per primo, individuato attraverso il Content-ID. In mancanza del parametro start, opzionale per il multipart/related si pu`o utilizzare il parametro type, che deve essere presente e che individua il Content-Type dell’allegato principale.
Il tipo multipart/related `e quello utilizzato da SOAP per la trasmissione di allegati. Per semplificare il discorso verr`a fatto riferimento esplicito ad HTTP, protocollo privilegiato nella standardizzazione W3C di SOAP, ma tutte le se-guenti considerazioni valgono per qualsiasi protocollo di trasporto che supporti MIME.
Come `e stato visto nell’esempio in 2.2 il messaggio SOAP viene trasportato in una richiesta HTTP utilizzando lo standard MIME per gli allegati, con un Content-Type impostato al valore text/xml. Se per`o contestualmente al mes-saggio SOAP dev’essere inviato uno o pi`u file, viene costruito un “message pac-kage” attraverso il meccanismo MIME multipart/related. Il messaggio SOAP diventa l’allegato principale del multipart, mentre i file da allegare saranno altri semplici allegati, separati dal boundary e con il loro Content-Type e Contend-ID settati volta per volta.
Listing 2.8: Messaggio SOAP con un allegato
1 POST / cgi−bin/mime. c g i HTTP/ 1 . 1 2 Host: l o c a l h o s t
3 User−Agent : gSOAP/ 2 . 7
4 Content−Type : multipart / related ;
5 boundary=”==nGpzR/KspNNGb0UROC0B==”; 6 type=”text /xml ” ; 7 s t a r t=”<SOAP−ENV: Envelope>” 8 Content−Length : 11664 9 Connection: c l o s e 10 SOAPAction: ”” 11 12 −−==nGpzR/KspNNGb0UROC0B==
13 Content−Type : text /xml ; charset=utf −8 14 Content−Transfer−Encoding : binary 15 Content−ID : <SOAP−ENV: Envelope> 16
17 <?xml version =”1.0” encoding=”UTF−8”?>
18 <SOAP−ENV: Envelope
19 xmlns:SOAP−ENV=”http : / / schemas . xmlsoap . org/soap / envelope /” 20 xmlns:SOAP−ENC=”http : / / schemas . xmlsoap . org/soap / encoding/” 21 xmlns: x s i=”http : / /www.w3. org /2001/XMLSchema−instance ” 22 xmlns: xsd=”http : / /www.w3. org /2001/XMLSchema”
23 xmlns:m=”http : / / tempuri . org/m. xsd”> 24 <SOAP−ENV: Body>
25 <m: mimeRequest> 26 <image hr ef=”cid :< l o g o s p e c i a l >” /> 27 </m: mimeRequest> 28 </SOAP−ENV: Body> 29 </SOAP−ENV: Envelope> 30 −−==nGpzR/KspNNGb0UROC0B== 31 Content−Type : image/ jpeg
32 Content−Transfer−Encoding : binary 33 Content−ID : <l o g o s p e c i a l >
34
35 [ immagine jpg in formato binario ] 36 −−==nGpzR/KspNNGb0UROC0B==−−
Il Listato 2.8 mostra un esempio di messaggio SOAP con un allegato, in par-ticolare un’immagine JPEG. Per facilitare la lettura, il campo Content-Type
dell’intero messaggio `e stato spezzato su pi`u righe: nella pratica tutti gli attribu-ti devono stare sulla stessa linea dello header MIME.
Semanticamente non esiste alcuna differenza tra il messaggio SOAP con attach-ment e un messaggio SOAP normale: stabilito infatti il binding tra SOAP e il protocollo di trasporto con supporto a MIME, l’ambiente SOAP non `e nemmeno a conoscienza del suo incapsulamento MIME.
2.5.1.2 Riferimenti agli allegati
In una qualunque sezione del message package SOAP pu`o essere necessario riferir-si ad un’entit`a del package stesso, riferir-siano sezioni XML del messaggio SOAP o atta-chments. Per referenziare le entit`a all’interno del package vengono usate delle URI gerarchiche la cui sintassi `e definita nella RFC [http://www.ietf.org/rfc/rfc2396.txt]. Per risolvere la URI ed individuare l’entit`a corrispondente sono necessari due passaggi: prima di tutto `e necessario estendere eventuali URI relative ad URI assolute, poi si processano i risultati ottenuti per individuare l’entit`a. Il meccani-smo di costruzione delle URI utilizzate nei messaggi SOAP `e descritto nella RFC http://www.ietf.org/rfc/rfc2396.txt.
Per poter utilizzare URI relative `e necessario poter individuare una URI assoluta a cui le prime facciano riferimento. Nella RFC sono stabiliti quattro metodi, in ordine dal pi`u specifico al pi`u generico, di seguito elencati con riferimento al particolare uso in SOAP:
• Base URI all’interno del Document Content - in SOAP viene specifi-cato attraverso l’uso di XML Base, come specifispecifi-cato nella Raccomandazione http://www.w3.org/TR/xmlbase;
quale `e stato specificato un Content-Location in un heading MIME che contenga il messaggio SOAP principale del package;
• Base URI dalla Retrieval URI - in SOAP questa opportunit`a non `e utilizzabile;
• Default Base URI - come dall’RFC 2557, la Base URI di default sar`a thismessage:/.
2.5.1.3 Limiti di MIME
Esistono alcuni limiti del meccanismo fornito da MIME quando questo viene utilizzato per allegare dei file a messaggi SOAP:
Efficienza - Le sezioni che compongono il message package di un messaggio SOAP con i suoi allegati sono separate attraverso delle stringhe alfanimeriche. Sebbene questo sia molto pratico per il mittente, che pu`o inserire liberamente anche a pezzi il file mettendo il separatore dove opportuno, a lato ricevitore si hanno forti rallentamenti dovuti al necessario parsing di ogni byte alla ricerca dei boundary
Codifica - XML non si adatta molto bene al trasferimento di dati binari, che secondo le specifiche del linguaggio devono essere codificati nel formato Base64[8], che aumenta la dimensione dei dati trasmessi del 33% e non supporta lo streaming dei dati
XML Infoset - Per garantire l’interoperabilit`a dei Web Services sono stati sta-biliti degli standard aperti che impongono alcune strutture generali al messaggio:
in particolar modo, come nel caso di WS-Security, lo standard OASIS per garan-tire requisiti di sicurezza quali integrit`a e segretezza, spesso si presuppone che il formato del messaggio da trasferire rispetti lo standard XML Infoset per la strutturazione delle informazioni. Non rispettando MIME la struttura di XML Infoset, non permette l’applicazione di standard come WS-Security.
2.5.2 DIME
Microsoft proponeva la tecnologia Direct Internet Message Encapsulation come alternativa a MIME per migliorare l’efficienza del sistema di trasferimento dati. Questo nuovo metodo di incapsulazione dei dati abbandona l’utilizzo di stringhe separatrici per suddividere le entit`a logiche, introducendo una nuova struttura di headers tra i quali inserire l’indicazione della lunghezza in byte dell’entit`a. In questo modo `e possibile creare una struttura a record, esattamente come i message package del multipart MIME, e navigare rapidamente tra i vari record leggendo solamente le intestazioni relative.
Di seguito si elencano alcune caratteristiche dell’uso di DIME per l’incapsula-mento di messaggi SOAP con allegati:
• il primo record corrisponde al messaggio SOAP principale;
• i riferimenti ai vari record sono indicati attraverso una URI come attributo href usato per individuare il campo ID del record DIME;
• in caso di riferimenti incrociati, le URI relative devono essere convertite in assolute;
• nel caso di utilizzo di DIME su HTTP, loheader HTTP Content-Type deve essere impostato ad application/dime al posto dei normali application/-soap+xml o text/xml usati per i messaggi SOAP;
• se i messaggi DIME sono crittati o firmati elettronicamente, le informazioni sulla protezione devono essere inserite nello header del messaggio SOAP principale.
Attraverso DIME `e anche possibile l’utilizzo di tecniche di streaming, che per-mettono di non conservare completamente in memoria l’allegato sia in fase di invio che in fase di ricezione.
Nonostante la migliore performance ottenibile, DIME non `e compatibile con alcu-na struttura standard di messaggio, come ad esempio XML Infoset. Per questo, non `e adeguata all’integrazione con le altre tecnologie standard rivolte ai Web Services.
L’ultimo aggiornamento alle specifiche DIME risale al 2002[CITAZIONE]: la stes-sa Microsoft indica questa tecnologia come “superata” in favore del meccanismo proposto dal W3C chiamato Message Tranfer Optimization Mechanism.
2.5.3 MTOM
Lo standard MTOM cerca di ottimizzare la trasmissione dei dati permetten-do la codifica selettiva di porzioni del messaggio pur mantenenpermetten-do la struttura definita da XML Infoset. I dati su cui `e possibile effettuare l’ottimizzazione de-vono essere rappresentati secondo la codifica Base64, esplicitata con l’attributo xs:base64Binary, e non devono esistere spaziature prima, dopo o in mezzo ai dati da ottimizzare.
L’ottimizzazione dei dati strutturati secondo XML Infoset utilizzata dallo stan-dard MTOM corrisponde alla codifica XML-binary Optimized Packaging. Lo standard MTOM, e tutte le considerazioni presenti nella sezione seguente, `e mi-rato alla comunicazione tra nodi SOAP direttamente adiacenti: seppure sia pos-sibile stabilire un protocollo di trasmissione dati che affronti percorsi con nodi
intermedi, `e lasciato al programmatore o a future standardizzazioni affrontare questa problematica.
2.5.3.1 XOP
Lo scopo di questa convenzione `e di rendere disponibile un’efficiente metodo di serializzazione di un XML Infoset che contenga dati binari. Un package XOP vie-ne creato immettendo in un sistema di packaging estendibile, come ad esempio multipart MIME, una serializzazione di un XML Infoset le cui porzioni binarie codificate secondo Base64 vengono estratte, decodificate e immesse separatamen-te nel package11. All’interno dell’XML Infoset, vengono posti degli elementi che
specificano attraverso una URI la posizione dei dati binari estratti. L’intero pro-cesso `e schematizzato in Figura 2.7
L’ottimizzazione XOP `e rivolta solo ai dati binari codificati secondo Base64 con-tenuti come valore di elementi XML, quindi nessuna azione avr`a come oggetto attributi di un elemento o valori di un elemento non codificati in Base64.
Per poter garantire l’applicazione di alcuni protocolli standard, come ad esempio per WS-Security, deve sussistere una corrispondenza uno a uno tra l’XML Info-set prima dell’ottimizzazione e lo XOP InfoInfo-set risultante. Il seguente algoritmo descrive la creazione di uno XOP package:
• Controllare che l’XML Infoset non contenga alcun elemento avente name-space http://www.w3.org/2004/08/xop/include e nome Include, per evi-tare che il parser non riesca a processare correttamente il contenuto del messaggio SOAP;
• Identificare le porzioni ottimizzabili dell’XML package;
11
Figure 2.7: Architettura di XOP
• Creare un package XOP identico al package XML sostituendo alle porzioni ottimizzabili un elemento di tipo xop:Include, per il quale il namespace xop si riferisce a quello di cui al primo punto, costruito come segue:
– la porzione di dati binari in Base64 si decodifica e si inserisce come parte a s´e stante del package;
– si individua la URI corrispondente a tale parte del package e la si inserisce come attributo href dell’elemento xop:Include;
– se l’elemento oggetto dell’ottimizzazione, che risulta essere il padre dell’elemento xop:Include, ha un campo xmlmime:contentType spe-cificato questo dovrebbe essere riflesso nei metadati della sezione con-tenente l’allegato;
• Si serializza il XOP Infoset ottenuto in questo modo segnalandolo come se-zione principale del package avente il Content-Type indicato con il valore application/xop+xmlsecondo i metodi forniti dal sistema di serializzazio-ne usato, come ad esempio multipart MIME.
2.6
Conclusioni
In questa sezione `e stata fatta una veloce panoramica degli Web Services, di SOAP e della possibilit`a offerta dalle estensioni a questo protocollo di inviare dei file, anche binari e anche di grosse entit`a, attraverso l’uso di allegati ai messaggi SOAP.
Lo scopo di questa tesi sar`a l’integrazione nel sistema di consistenza e replicazio-ne dati su Grid Constanza, affrontato replicazio-nel prossimo Capitolo, di un meccanismo per il trasferimento di allegati secondo lo standard MTOM, da affiancare alla preesistente infrastruttura di scambio file basata su GridFTP. Al momento della scrittura, lo scambio file via MTOM `e previsto solo per la gestione della consi-stenza su DB replicati: i trasferimenti da eseguire riguarderanno file di testo, in particolare log file contenenti le query SQL eseguite sul DB modificato da pro-pagare alle repliche. Il supporto nativo ai file binari apre comunque la strada all’estensione dell’uso di SOAP+MTOM alla gestione di file.
