20.06.2013 Views

Progetto e Sviluppo dell'Interfaccia di Storage in InterDataNet per il ...

Progetto e Sviluppo dell'Interfaccia di Storage in InterDataNet per il ...

Progetto e Sviluppo dell'Interfaccia di Storage in InterDataNet per il ...

SHOW MORE
SHOW LESS

You also want an ePaper? Increase the reach of your titles

YUMPU automatically turns print PDFs into web optimized ePapers that Google loves.

UNIVERSITÀ DEGLI STUDI DI FIRENZE<br />

Facoltà <strong>di</strong> Ingegneria<br />

Dipartimento <strong>di</strong> Elettronica e Telecomunicazioni<br />

Corso <strong>di</strong> Laurea <strong>in</strong><br />

Ingegneria delle Telecomunicazioni P.O.<br />

<strong>Progetto</strong> e <strong>Sv<strong>il</strong>uppo</strong> dell’Interfaccia<br />

<strong>di</strong> <strong>Storage</strong> <strong>in</strong> <strong>InterDataNet</strong><br />

<strong>per</strong> <strong>il</strong> Web of Data<br />

Relatori<br />

Prof. Franco Pirri<br />

Prof. D<strong>in</strong>o Giuli<br />

Tesi <strong>di</strong> Laurea <strong>di</strong><br />

Cristiano Costant<strong>in</strong>i<br />

Correlatori<br />

Anno Accademico 2006/2007<br />

Ing. Davide Ch<strong>in</strong>i<br />

Ing. Samuele Innocenti<br />

Ing. Maria Chiara Pettenati


R<strong>in</strong>graziamenti<br />

È stato duro arrivare <strong>in</strong> fondo a questo corso <strong>di</strong> stu<strong>di</strong>. Questo libro, questa<br />

tesi, non sono solo <strong>il</strong> frutto del lavoro <strong>di</strong> questi ultimi mesi passati nel laboratorio<br />

<strong>di</strong> Tecnologie della Telematica a Santa Marta, ma sono <strong>il</strong> risultato<br />

<strong>di</strong> un lungo <strong>per</strong>corso <strong>in</strong>iziato molti anni fa, forse con poca consapevolezza <strong>di</strong><br />

quello a cui sarei andato <strong>in</strong>contro.<br />

Ci sono stati momenti <strong>di</strong>ffic<strong>il</strong>i, esami pesanti da <strong>di</strong>gerire e professori con<br />

i quali non sono proprio riuscito ad entrare <strong>in</strong> s<strong>in</strong>tonia, ma ho saputo reagire<br />

e aggiustare <strong>il</strong> tiro, e questi sacrifici sono stati ripagati da momenti <strong>di</strong><br />

sod<strong>di</strong>sfazione e dall’<strong>in</strong>contro con <strong>per</strong>sone speciali.<br />

Due <strong>di</strong> queste sono sicuramente <strong>il</strong> professor Franco Pirri e <strong>il</strong> professor<br />

D<strong>in</strong>o Giuli, complici nel prendersi cura <strong>di</strong> noi studenti più <strong>di</strong> quanto spetta<br />

loro <strong>per</strong> dovere <strong>di</strong> <strong>in</strong>carico. Un sentito grazie a loro e agli <strong>in</strong>gegneri Davide<br />

Ch<strong>in</strong>i, Samuele Innocenti e Mariachiara Pettenati, miei preziosissimi<br />

correlatori. Nel portare al term<strong>in</strong>e questo lavoro si sono <strong>di</strong>mostrati attenti,<br />

<strong>di</strong>sponib<strong>il</strong>i e <strong>in</strong>teressati, e con loro ho stab<strong>il</strong>ito un ottimo rapporto <strong>di</strong><br />

collaborazione.<br />

R<strong>in</strong>grazio tutti i compagni <strong>di</strong> università che <strong>in</strong> questi anni mi hanno accompagnato,<br />

a partire da Alessandro Bernar<strong>di</strong>, con cui ho com<strong>in</strong>ciato<br />

questa lunga avventura. Un grazie particolare a Marco Chiesi, Leonardo<br />

Cipriani, Michela Paolucci e Irene Innocenti, <strong>per</strong>ché mi hanno supportato<br />

fornendomi libri, appunti ma soprattutto consigli che sono stati fondamentali.<br />

Un grazie al gruppo <strong>di</strong> <strong>per</strong>sone con cui ho stu<strong>di</strong>ato: Maddalena<br />

Barlotti, Emanuele Bonciani, Matteo Benassi, Leonardo Biancalani,<br />

Azzurra Tesi e Simona Asnaghi, Ilaria Nelli e Christian Berti,<br />

Francesco Guzzar<strong>di</strong> e Federico Puggelli. Nuovamente grazie a Davide<br />

Ch<strong>in</strong>i, <strong>per</strong>ché <strong>il</strong> suo contributo è stato <strong>il</strong> più prezioso e mi ha accompagnato<br />

f<strong>in</strong>o alla conclusione.<br />

R<strong>in</strong>grazio tutti gli studenti che leggeranno queste pag<strong>in</strong>e e auguro loro <strong>di</strong><br />

trovarvi <strong>in</strong>formazioni ut<strong>il</strong>i, ed <strong>in</strong>f<strong>in</strong>e mando un augurio anche ad Alessandro<br />

Cafissi, che questa avventura universitaria ha appena com<strong>in</strong>ciato.<br />

R<strong>in</strong>grazio l’<strong>in</strong>gegner Clau<strong>di</strong>o Bizzarri, che mi ha <strong>in</strong>iziato ad es<strong>per</strong>ienze<br />

professionali <strong>il</strong> cui valore <strong>per</strong> la mia formazione è <strong>in</strong>estimab<strong>il</strong>e. Grazie a


Davide Ch<strong>in</strong>i e Giulio Nesi, con i quali ho collaborato alla realizzazione<br />

progetti stupen<strong>di</strong>. R<strong>in</strong>grazio la Oris Immob<strong>il</strong>iare <strong>di</strong> Stefano e Roberto,<br />

Roberto Tognelli, i ragazzi dell’Esse<strong>di</strong> <strong>di</strong> Prato <strong>in</strong>sieme a Guido Mariani<br />

<strong>di</strong> Computercare, e la Global Informatica <strong>di</strong> Egi<strong>di</strong>o.<br />

Un sentito grazie al mio maestro Clau<strong>di</strong>o Manenti. Le <strong>di</strong>scipl<strong>in</strong>e che mi<br />

sta <strong>in</strong>segnando, lo Shaol<strong>in</strong> ed <strong>il</strong> Tai Chi, sono state due dei p<strong>il</strong>astri che mi<br />

hanno sostenuto <strong>in</strong> questi anni. R<strong>in</strong>grazio lui, i suoi maestri Chang Dsu<br />

Yao e Chang Wei Sh<strong>in</strong>, ed <strong>il</strong> suo allievo Giancarlo Acri.<br />

R<strong>in</strong>grazio i miei più cari amici, Giulio Nesi, che mi è sempre stato vic<strong>in</strong>o<br />

nei peggiori e nei migliori momenti, Marco Chiesi, sul quale sempre ho<br />

potuto contare, Alessandro Bernar<strong>di</strong>, Michelangelo Ner<strong>in</strong>i, F<strong>il</strong>ippo<br />

Fiaschi e Gianni Stefanelli. A quest’ultimo mando un saluto speciale<br />

e l’augurio <strong>di</strong> guarire al più presto dalla malattia che l’ha colpito. Grazie<br />

nuovamente a Davide Ch<strong>in</strong>i <strong>per</strong>ché <strong>in</strong> questi anni mi è stato soprattutto<br />

amico. Grazie a Crist<strong>in</strong>a Bellan<strong>di</strong>, cug<strong>in</strong>a e amica, a mio cug<strong>in</strong>o Stefano<br />

Orlan<strong>di</strong> e sua moglie Federica, con i quali con Chiara, Renni e Pippo<br />

abbiamo passato momenti <strong>in</strong><strong>di</strong>menticab<strong>il</strong>i.<br />

Un grazie <strong>in</strong>esaurib<strong>il</strong>e a mio padre Mario, e mia madre Tamara, i miei<br />

educatori, sostenitori e f<strong>in</strong>anziatori, senza i quali non sarebbe stato possib<strong>il</strong>e<br />

<strong>di</strong>ventare la <strong>per</strong>sona che sono oggi. Grazie a mio fratello Francesco <strong>per</strong><br />

avermi sopportato <strong>in</strong> questi anni e grazie a mio nonno Franco, la cui forza,<br />

tempra e coraggio sono stati fonte d’ispirazione nel mio <strong>di</strong>ventare adulto. Un<br />

grazie speciale va alla mia simpaticissima nonna Rolanda e all’<strong>in</strong><strong>di</strong>struttib<strong>il</strong>e<br />

nonna Nella Narcisa.<br />

Inf<strong>in</strong>e, <strong>il</strong> mio r<strong>in</strong>graziamento più grande va a Chiara, mia compagna nella<br />

vita, che <strong>in</strong>sieme al nostro cagnolone Renni rappresenta la mia piccola famiglia.<br />

Grazie <strong>per</strong> <strong>il</strong> sostegno, grazie <strong>per</strong> la compagnia, grazie <strong>per</strong> l’affetto.<br />

A lei de<strong>di</strong>co <strong>il</strong> mio futuro.<br />

Tutte queste <strong>per</strong>sone cui va la mia riconoscenza, rappresentano un’istantanea<br />

<strong>di</strong> questi ultimi anni della mia vita, e si sono meritate a pieno titolo <strong>di</strong><br />

essere nom<strong>in</strong>ate <strong>in</strong> queste pag<strong>in</strong>e <strong>per</strong>sonali.


Queste ultime righe che ho scritto sul mio fidato computer portat<strong>il</strong>e Dell,<br />

mentre la stampante cont<strong>in</strong>ua a sfornare le pag<strong>in</strong>e della tesi, sono uno degli<br />

ultimi compiti che svolgerò da studente e sto provando una forte emozione<br />

<strong>per</strong>ché questo è un momento unico.<br />

Una parte della mia vita f<strong>in</strong>isce qui, domani com<strong>in</strong>cia una nuova sfida<br />

nella quale potrò <strong>per</strong>ò contare su un nuovo potenziale. Per questo, <strong>per</strong> le<br />

conoscenze che grazie a essa ho acquisito, <strong>il</strong> mio r<strong>in</strong>graziamento f<strong>in</strong>ale va<br />

all’istituzione dell’Università degli Stu<strong>di</strong> <strong>di</strong> Firenze.<br />

Firenze, 10 Dicembre 2007<br />

Cristiano Costant<strong>in</strong>i


Alla memoria <strong>di</strong> mio zio Sergio<br />

1958-1999


In<strong>di</strong>ce<br />

Introduzione xiii<br />

I Ab<strong>il</strong>itare <strong>il</strong> Web of Data 1<br />

1 Web Of Data 2<br />

1.1 L’avvento del Semantic Web . . . . . . . . . . . . . . . . . . . 3<br />

1.2 Il Semantic Web è <strong>il</strong> futuro? . . . . . . . . . . . . . . . . . . . 6<br />

1.3 Dal Web <strong>di</strong> Documenti al web <strong>di</strong> Dati . . . . . . . . . . . . . . 8<br />

1.4 Infrastruttura del Web <strong>di</strong> dati . . . . . . . . . . . . . . . . . . 10<br />

2 Il progetto <strong>InterDataNet</strong> 13<br />

2.1 Content Management nel Web of Data . . . . . . . . . . . . . 14<br />

2.1.1 Nam<strong>in</strong>g and Data Addressab<strong>il</strong>ity . . . . . . . . . . . . 14<br />

2.1.2 Data Replication . . . . . . . . . . . . . . . . . . . . . 16<br />

2.1.3 Version<strong>in</strong>g . . . . . . . . . . . . . . . . . . . . . . . . . 18<br />

2.1.4 Data Access Control . . . . . . . . . . . . . . . . . . . 20<br />

2.1.5 The pursuit of <strong>in</strong>tero<strong>per</strong>ab<strong>il</strong>ity . . . . . . . . . . . . . . 23<br />

2.2 <strong>InterDataNet</strong>: una soluzione <strong>per</strong> l’<strong>in</strong>terdatawork<strong>in</strong>g . . . . . . 24<br />

2.2.1 Il “design pattern” della stratificazione applicato ai dati 25<br />

2.2.2 L’approccio bottom-up . . . . . . . . . . . . . . . . . . 27<br />

2.3 Architettura tecnologica <strong>di</strong> IDN . . . . . . . . . . . . . . . . . 30<br />

2.3.1 Core IDN-SA services . . . . . . . . . . . . . . . . . . 30<br />

Servizi LDNS ed LS . . . . . . . . . . . . . . . . . . . 30<br />

Servizio <strong>di</strong> Replica Management . . . . . . . . . . . . . 32


In<strong>di</strong>ce<br />

Servizio <strong>di</strong> Information History . . . . . . . . . . . . . 33<br />

Identity Service . . . . . . . . . . . . . . . . . . . . . . 35<br />

2.3.2 L’<strong>in</strong>formazione: IDN-IM . . . . . . . . . . . . . . . . . 36<br />

2.3.3 Le <strong>in</strong>terfacce verso l’esterno <strong>di</strong> IDN-SA . . . . . . . . . 37<br />

Virtual Repository . . . . . . . . . . . . . . . . . . . . 38<br />

<strong>Storage</strong> Interface . . . . . . . . . . . . . . . . . . . . . 41<br />

Legacy <strong>Storage</strong> Interface . . . . . . . . . . . . . . . . . 42<br />

2.4 Una migrazione <strong>in</strong>tero<strong>per</strong>ab<strong>il</strong>e . . . . . . . . . . . . . . . . . . 43<br />

2.5 Conclusioni . . . . . . . . . . . . . . . . . . . . . . . . . . . . 46<br />

II Analisi del servizio <strong>di</strong> <strong>Storage</strong> Interface 47<br />

3 Tecnologie <strong>per</strong> IDN e <strong>Storage</strong> Interface 48<br />

3.1 Service Oriented Architecture . . . . . . . . . . . . . . . . . . 49<br />

3.1.1 Motivazioni e Concetti fondamentali . . . . . . . . . . 49<br />

3.1.2 Ingre<strong>di</strong>enti . . . . . . . . . . . . . . . . . . . . . . . . . 51<br />

3.1.3 Term<strong>in</strong>ologia . . . . . . . . . . . . . . . . . . . . . . . 53<br />

3.1.4 Servizi . . . . . . . . . . . . . . . . . . . . . . . . . . . 54<br />

3.1.5 Considerazioni conclusive . . . . . . . . . . . . . . . . . 56<br />

3.2 Web Service . . . . . . . . . . . . . . . . . . . . . . . . . . . . 56<br />

3.2.1 WSDL . . . . . . . . . . . . . . . . . . . . . . . . . . . 59<br />

Struttura e ciclo <strong>di</strong> vita . . . . . . . . . . . . . . . . . 61<br />

Esempio <strong>di</strong> un servizio descritto da WSDL . . . . . . . 63<br />

Confronto tra WSDL 1.1 e 2.0 . . . . . . . . . . . . . . 69<br />

Estensione <strong>per</strong> <strong>il</strong> b<strong>in</strong><strong>di</strong>ng su HTTP <strong>di</strong> WSDL 2.0 . . . 70<br />

3.2.2 SOAP . . . . . . . . . . . . . . . . . . . . . . . . . . . 74<br />

3.2.3 Conclusioni . . . . . . . . . . . . . . . . . . . . . . . . 75<br />

3.3 Representational State transfer . . . . . . . . . . . . . . . . . 76<br />

3.4 Resource Oriented Architecture . . . . . . . . . . . . . . . . . 79<br />

3.5 Mappa delle tecnologie . . . . . . . . . . . . . . . . . . . . . . 81<br />

3.6 Resource Description Framework . . . . . . . . . . . . . . . . 82<br />

3.6.1 RDF schema . . . . . . . . . . . . . . . . . . . . . . . 85<br />

4 Scenari applicativi 90<br />

4.1 <strong>Storage</strong> <strong>di</strong> immag<strong>in</strong>i con dati Exif . . . . . . . . . . . . . . . . 92<br />

4.1.1 Ruolo <strong>di</strong> SI . . . . . . . . . . . . . . . . . . . . . . . . 93<br />

4.1.2 Aspetti r<strong>il</strong>evanti . . . . . . . . . . . . . . . . . . . . . . 93<br />

vi


In<strong>di</strong>ce<br />

4.1.3 Conseguenze <strong>per</strong> SI . . . . . . . . . . . . . . . . . . . . 94<br />

4.2 <strong>Storage</strong> <strong>di</strong> MIME type con associati metadati . . . . . . . . . 94<br />

4.2.1 Ruolo <strong>di</strong> SI . . . . . . . . . . . . . . . . . . . . . . . . 95<br />

4.2.2 Aspetti r<strong>il</strong>evanti . . . . . . . . . . . . . . . . . . . . . . 96<br />

4.2.3 Conseguenze <strong>per</strong> SI . . . . . . . . . . . . . . . . . . . . 96<br />

4.3 <strong>Storage</strong> <strong>per</strong> ambiente <strong>di</strong>stributo . . . . . . . . . . . . . . . . . 96<br />

4.3.1 Ruolo <strong>di</strong> SI . . . . . . . . . . . . . . . . . . . . . . . . 98<br />

4.3.2 Aspetti r<strong>il</strong>evanti . . . . . . . . . . . . . . . . . . . . . . 98<br />

4.3.3 Conseguenze <strong>per</strong> SI . . . . . . . . . . . . . . . . . . . . 98<br />

4.4 Memorizzazione <strong>di</strong> <strong>in</strong>formazioni strutturate . . . . . . . . . . . 98<br />

4.4.1 Ruolo <strong>di</strong> SI . . . . . . . . . . . . . . . . . . . . . . . . 100<br />

4.4.2 Aspetti r<strong>il</strong>evanti . . . . . . . . . . . . . . . . . . . . . . 101<br />

4.4.3 Conseguenze <strong>per</strong> SI . . . . . . . . . . . . . . . . . . . . 101<br />

4.5 <strong>Storage</strong> <strong>per</strong> <strong>il</strong> Web orientato ai dati . . . . . . . . . . . . . . . 101<br />

4.5.1 Ruolo <strong>di</strong> SI . . . . . . . . . . . . . . . . . . . . . . . . 104<br />

4.5.2 Aspetti r<strong>il</strong>evanti . . . . . . . . . . . . . . . . . . . . . . 104<br />

4.5.3 Conseguenze <strong>per</strong> SI . . . . . . . . . . . . . . . . . . . . 105<br />

4.6 Intero<strong>per</strong>ab<strong>il</strong>ità con sistemi legacy . . . . . . . . . . . . . . . . 105<br />

4.6.1 Ruolo <strong>di</strong> SI . . . . . . . . . . . . . . . . . . . . . . . . 108<br />

4.6.2 Aspetti r<strong>il</strong>evanti . . . . . . . . . . . . . . . . . . . . . . 109<br />

4.6.3 Conseguenze <strong>per</strong> SI . . . . . . . . . . . . . . . . . . . . 110<br />

4.7 Servire <strong>il</strong> Replica Management <strong>di</strong> IDN . . . . . . . . . . . . . 110<br />

4.7.1 Ruolo <strong>di</strong> SI . . . . . . . . . . . . . . . . . . . . . . . . 111<br />

4.7.2 Aspetti r<strong>il</strong>evanti . . . . . . . . . . . . . . . . . . . . . . 111<br />

4.7.3 Conseguenze <strong>per</strong> SI . . . . . . . . . . . . . . . . . . . . 112<br />

5 Requisiti dell’Interfaccia 113<br />

5.1 Notazione . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 114<br />

5.2 Def<strong>in</strong>izioni . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 115<br />

5.3 Informazioni sulla specifica <strong>di</strong> requisiti . . . . . . . . . . . . . 117<br />

5.4 Requisiti . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 117<br />

III <strong>Progetto</strong> dell’<strong>in</strong>terfaccia e sv<strong>il</strong>uppo <strong>di</strong> una implementazione<br />

<strong>di</strong> riferimento <strong>per</strong> <strong>il</strong> servizio 125<br />

6 <strong>Progetto</strong> dell’Interfaccia 126<br />

6.1 Information Model e descrizione dell’<strong>in</strong>terfaccia . . . . . . . . 127<br />

vii


In<strong>di</strong>ce<br />

6.1.1 Information Model delle Risorse: SI-R . . . . . . . . . 128<br />

6.1.2 Information model dei messaggi ed o<strong>per</strong>azioni dell’<strong>in</strong>terfaccia<br />

. . . . . . . . . . . . . . . . . . . . . . . . . . 130<br />

Messaggi <strong>di</strong> <strong>in</strong>put, <strong>di</strong> output, <strong>di</strong> fault e generalità . . . 131<br />

O<strong>per</strong>azioni base dello storage <strong>per</strong>sistente . . . . . . . . 134<br />

O<strong>per</strong>azioni <strong>per</strong> funzionalità <strong>di</strong> <strong>per</strong>formance . . . . . . . 136<br />

O<strong>per</strong>azioni specializzate <strong>per</strong> dati e metadati . . . . . . 138<br />

O<strong>per</strong>azioni <strong>per</strong> funzionalità specifiche . . . . . . . . . . 140<br />

O<strong>per</strong>azioni <strong>per</strong> la gestione degli eventi . . . . . . . . . 142<br />

6.1.3 Interfaccia delle notifiche . . . . . . . . . . . . . . . . . 143<br />

6.1.4 Dati predef<strong>in</strong>iti . . . . . . . . . . . . . . . . . . . . . . 145<br />

6.2 Data Model XML . . . . . . . . . . . . . . . . . . . . . . . . . 146<br />

6.2.1 Panoramica schema XML dei messaggi . . . . . . . . . 147<br />

6.2.2 Panoramica schema XML dei tipi predef<strong>in</strong>iti . . . . . . 149<br />

6.3 Il WSDL dell’<strong>in</strong>terfaccia . . . . . . . . . . . . . . . . . . . . . 150<br />

6.3.1 Def<strong>in</strong>izione del protocollo: <strong>il</strong> b<strong>in</strong><strong>di</strong>ng del WSDL . . . . 152<br />

6.3.2 Il WSDL 1.1 del servizio . . . . . . . . . . . . . . . . . 154<br />

7 Implementazione del Servizio 156<br />

7.1 Implementazione Java con JAX-WS 2.1 . . . . . . . . . . . . . 157<br />

7.2 Implementazione PHP su Apache Web Server . . . . . . . . . 159<br />

7.3 Esempio <strong>di</strong> messaggi e <strong>di</strong> comunicazione . . . . . . . . . . . . 162<br />

7.3.1 Esempio <strong>di</strong> lettura: o<strong>per</strong>azione Read . . . . . . . . . . 163<br />

7.3.2 Esempio <strong>di</strong> scrittura: o<strong>per</strong>azione Update . . . . . . . . 166<br />

Conclusioni 169<br />

IV Appen<strong>di</strong>ci 172<br />

A WSDL e XML Schema <strong>di</strong> <strong>Storage</strong> Interface 173<br />

A.1 <strong>Storage</strong> Interface XML Schema . . . . . . . . . . . . . . . . . 173<br />

A.2 <strong>Storage</strong> Interface Predef<strong>in</strong>ed Types . . . . . . . . . . . . . . . 188<br />

A.3 <strong>Storage</strong> Interface WSDL 2.0 . . . . . . . . . . . . . . . . . . . 189<br />

A.4 <strong>Storage</strong> Interface WSDL 1.1 . . . . . . . . . . . . . . . . . . . 199<br />

Bibliografia 212<br />

viii


Elenco delle figure<br />

1.1 Risorse <strong>in</strong>tercollegate dal punto <strong>di</strong> vista del Web tra<strong>di</strong>zionale<br />

e da un punto <strong>di</strong> vista del Web semantico . . . . . . . . . . . . 5<br />

1.2 “From a Web of documents to a Web of Data” [Ayers07a] . . . 9<br />

1.3 Come <strong>il</strong> Semantic Web si costruisce sulle attuali strutture Web 10<br />

1.4 Semantic Web verso <strong>il</strong> Web of Data . . . . . . . . . . . . . . . 12<br />

2.1 Modello generale <strong>per</strong> <strong>il</strong> controllo dell’accesso agli oggetti . . . 21<br />

2.2 Il logo del progetto . . . . . . . . . . . . . . . . . . . . . . . . 24<br />

2.3 Interdatawork<strong>in</strong>g <strong>in</strong> IDN . . . . . . . . . . . . . . . . . . . . . 25<br />

2.4 I componenti <strong>di</strong> IDN . . . . . . . . . . . . . . . . . . . . . . . 26<br />

2.5 Il sistema dei nomi . . . . . . . . . . . . . . . . . . . . . . . . 31<br />

2.6 Coreografia al livello <strong>di</strong> Replica Management . . . . . . . . . . 32<br />

2.7 Revisioni successive <strong>di</strong> due documenti nel modello UEVM . . . 34<br />

2.8 <strong>InterDataNet</strong> Information Model . . . . . . . . . . . . . . . . 37<br />

2.9 Due documenti Web (pag<strong>in</strong>e HTML) e due documenti IDN<br />

(DAG IDN-IM) che rappresentano la stessa <strong>in</strong>formazione . . . 39<br />

2.10 Ut<strong>il</strong>izzo <strong>di</strong> Virtual Repository da parte <strong>di</strong> applicazioni IDN<br />

orientate al Web . . . . . . . . . . . . . . . . . . . . . . . . . 40<br />

2.11 <strong>Storage</strong> Interface e Legacy <strong>Storage</strong> Interface . . . . . . . . . . 42<br />

2.12 Paragone tra Web e IDN . . . . . . . . . . . . . . . . . . . . . 44<br />

2.13 Dal Web al Semantic Web attraverso <strong>il</strong> Web 2.0 ed <strong>il</strong> Web of<br />

Data . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45<br />

3.1 “Web Services Standards as of Q1 2007 by <strong>in</strong>noQ” . . . . . . . 58<br />

3.2 Struttura <strong>di</strong> f<strong>il</strong>e WSDL 1.1 e WSDL 2.0 . . . . . . . . . . . . 61


Elenco delle figure<br />

3.3 Esempio astratto <strong>di</strong> servizio che fornisce o<strong>per</strong>azioni <strong>di</strong> lettura<br />

e <strong>di</strong> scrittura <strong>di</strong> risorse composte da dati e più metadati. . . . 63<br />

3.4 “Mappa” delle tecnologie <strong>per</strong> erogare servizi nel web. . . . . . 81<br />

3.5 “Cristiano created the <strong>InterDataNet</strong> home page” . . . . . . . . 83<br />

4.1 <strong>Storage</strong> Interface <strong>per</strong> immag<strong>in</strong>i con Exif <strong>in</strong> uno scenario Rich<br />

Internet Application (derivata da [Stearn07]) . . . . . . . . . . 93<br />

4.2 Ambiente SOA <strong>per</strong> ab<strong>il</strong>itare <strong>il</strong> Distributed Author<strong>in</strong>g and Version<strong>in</strong>g<br />

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 95<br />

4.3 Ambiente SOA <strong>per</strong> F<strong>il</strong>e System <strong>di</strong>stribuito . . . . . . . . . . . 97<br />

4.4 Servizio <strong>di</strong> <strong>Storage</strong> e <strong>di</strong> Data Brows<strong>in</strong>g <strong>per</strong> l’author<strong>in</strong>g <strong>di</strong><br />

<strong>in</strong>formazioni strutturate . . . . . . . . . . . . . . . . . . . . . 100<br />

4.5 Accesso ed <strong>in</strong><strong>di</strong>rizzamento <strong>per</strong> HTTP e <strong>per</strong> un Web Service <strong>di</strong><br />

storage . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 103<br />

4.6 Accesso ed <strong>in</strong><strong>di</strong>rizzamento <strong>per</strong> metadati <strong>di</strong> una risorsa . . . . . 104<br />

4.7 Intero<strong>per</strong>ab<strong>il</strong>ità con sistemi legacy: possib<strong>il</strong>i soluzioni implementative<br />

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 107<br />

4.8 Intero<strong>per</strong>ab<strong>il</strong>ità con sistemi legacy . . . . . . . . . . . . . . . . 109<br />

4.9 Layered Architecture <strong>di</strong> <strong>InterDataNet</strong> . . . . . . . . . . . . . . 111<br />

4.10 Interazione tra livello <strong>di</strong> storage e <strong>di</strong> replica . . . . . . . . . . 112<br />

6.1 Information Model <strong>di</strong> SI-R. . . . . . . . . . . . . . . . . . . . 129<br />

6.2 Mapp<strong>in</strong>g <strong>di</strong> associazioni <strong>di</strong> metadati <strong>di</strong> SI-R con relazioni RDF.130<br />

6.3 Information Model dei messaggi <strong>di</strong> <strong>in</strong>put e <strong>di</strong> output . . . . . 133<br />

6.4 Tipi <strong>di</strong> messaggi <strong>di</strong> fault. . . . . . . . . . . . . . . . . . . . . 133<br />

6.5 Information model dei messaggi e delle o<strong>per</strong>azioni base <strong>per</strong> la<br />

memorizzazione <strong>per</strong>sistente. . . . . . . . . . . . . . . . . . . . 137<br />

6.6 Information model dei messaggi e delle o<strong>per</strong>azioni <strong>per</strong> funzionalità<br />

duplicazione, lista <strong>di</strong> risorse e lista <strong>di</strong> metadati. . . . . . 138<br />

6.7 Information model dei messaggi e delle o<strong>per</strong>azioni <strong>di</strong> memorizzazione<br />

<strong>di</strong> s<strong>in</strong>goli dati o s<strong>in</strong>goli metadati. . . . . . . . . . . . 141<br />

6.8 Information model dei messaggi e delle o<strong>per</strong>azioni <strong>per</strong> funzionalità<br />

<strong>di</strong> lock<strong>in</strong>g e validazione. . . . . . . . . . . . . . . . . . . 142<br />

6.9 Information model dei messaggi e delle o<strong>per</strong>azioni a supporto<br />

della notifica <strong>di</strong> eventi. . . . . . . . . . . . . . . . . . . . . . . 144<br />

6.10 Interfaccia <strong>per</strong> le notifiche. . . . . . . . . . . . . . . . . . . . . 145<br />

6.11 Information model dei metadati predef<strong>in</strong>iti <strong>di</strong> <strong>Storage</strong> Interface.146<br />

x


Elenco delle figure<br />

7.1 O<strong>per</strong>azione Read: rappresentazione XML dei messaggi . . . . 163<br />

7.2 O<strong>per</strong>azione Read: serializzazione <strong>in</strong> HTTP dei messaggi <strong>di</strong><br />

figura 7.1 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 164<br />

7.3 O<strong>per</strong>azione Read: serializzazione SOAP dei messaggi <strong>di</strong> figura<br />

7.1 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 165<br />

7.4 O<strong>per</strong>azione Update: rappresentazione XML dei messaggi . . . 166<br />

7.5 O<strong>per</strong>azione Update: serializzazione <strong>in</strong> HTTP dei messaggi <strong>di</strong><br />

figura 7.4 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 167<br />

7.6 O<strong>per</strong>azione Update: serializzazione SOAP dei messaggi <strong>di</strong> figura<br />

7.4 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 168<br />

xi


Elenco delle tabelle<br />

3.1 Esempi pratici <strong>di</strong> loose coupl<strong>in</strong>g . . . . . . . . . . . . . . . . . 52<br />

3.2 Ciclo <strong>di</strong> vita del WSDL . . . . . . . . . . . . . . . . . . . . . . 63


Introduzione<br />

Alla conferenza sul World Wide Web del 1994, Tim Berners-Lee <strong>il</strong>lustrò <strong>per</strong><br />

primo l’idea <strong>di</strong> un Web <strong>in</strong> cui <strong>il</strong> significato delle <strong>in</strong>formazioni fosse processab<strong>il</strong>e<br />

dagli elaboratori. Questa evoluzione dell’ancora attuale Web of Documents,<br />

che è stata poi def<strong>in</strong>ita Semantic Web, ha riscosso negli anni grande <strong>in</strong>teresse<br />

da parte degli addetti del settore ed ha dato <strong>il</strong> via a numerose ricerche<br />

scientifiche e nuovi sv<strong>il</strong>uppi tecnologici.<br />

Dopo più <strong>di</strong> <strong>di</strong>eci anni <strong>per</strong>ò queste idee – secondo le parole recenti del<br />

loro stesso <strong>in</strong>ventore – rimangono largamente irrealizzate: non si sono ancora<br />

visti su larga scala agenti <strong>in</strong>telligenti capaci <strong>di</strong> eseguire compiti assegnati dai<br />

loro proprietari umani. C’è chi sostiene che questo tipo <strong>di</strong> applicazioni possa<br />

proliferare soltanto con standard ben def<strong>in</strong>iti ed affermati e l’<strong>in</strong>stab<strong>il</strong>ità delle<br />

tecnologie <strong>per</strong> l’espressione <strong>di</strong> una semantica con<strong>di</strong>visa, che <strong>in</strong> questi ultimi<br />

c<strong>in</strong>que anni hanno subito una cont<strong>in</strong>ua evoluzione, non è certo stata <strong>di</strong> aiuto.<br />

Nell’attuale <strong>di</strong>battito sull’evoluzione del World Wide Web, sta guadagnando<br />

sempre più attenzione la tesi che <strong>il</strong> Web of Data costituisca un necessario<br />

passo <strong>in</strong>terme<strong>di</strong>o tra Web of Documents e Web Semantico.<br />

I documenti, nel Web of Data, sono scomposti <strong>in</strong> unità <strong>in</strong>formative<br />

elementari ed <strong>in</strong><strong>di</strong>rizzab<strong>il</strong>i – con sufficiente granularità – <strong>per</strong> consentirne una<br />

effettiva ed efficiente elaborazione ed ab<strong>il</strong>itando così, <strong>in</strong> ultima analisi,<br />

l’<strong>in</strong>tero<strong>per</strong>ab<strong>il</strong>ità tra dati (<strong>in</strong>terdatawork<strong>in</strong>g).<br />

Sebbene le attuali applicazioni nate sotto l’etichetta gergale <strong>di</strong> Web 2.0<br />

siano improntate alla gestione <strong>di</strong> “unità elementari <strong>di</strong> dati”, s<strong>in</strong>golarmente<br />

<strong>in</strong><strong>di</strong>rizzab<strong>il</strong>i e tra <strong>di</strong> loro collegate, non si può affermare che <strong>il</strong> Web 2.0 sia


Introduzione<br />

già una realizzazione del Web of Data, ma è piuttosto un “Transitional Web”,<br />

un Web <strong>di</strong> transizione, nel quale le s<strong>in</strong>gole applicazioni manovrano le <strong>in</strong>formazioni<br />

con un sim<strong>il</strong>e approccio, senza <strong>per</strong>ò renderle tra loro <strong>in</strong>tero<strong>per</strong>ab<strong>il</strong>i<br />

a livello globale, su scala Web.<br />

In altre parole, le applicazioni Web 2.0 realizzano soluzioni specifiche,<br />

usualmente esponendo una propria API tramite un Web Service, e danno<br />

così vita a molteplici soluzioni eterogenee <strong>per</strong> ognuna delle quali è necessario<br />

un client realizzato ad-hoc. Nel Web orientato ai documenti è avvenuto <strong>il</strong><br />

contrario: <strong>il</strong> suo successo è dovuto all’universalità del l<strong>in</strong>guaggio HTML ed<br />

all’unformità dell’<strong>in</strong>terfaccia HTTP.<br />

La strada che da qui porterà all’ab<strong>il</strong>itazione del Web of Data passa <strong>per</strong><br />

due macro-passaggi fondamentali:<br />

• Il primo è l’<strong>in</strong><strong>di</strong>viduare una rappresentazione delle risorse <strong>in</strong>formative<br />

e dei loro metadati con un modello dell’<strong>in</strong>formazione uniformato.<br />

• Il secondo è <strong>il</strong> <strong>di</strong>segno e la realizzazione <strong>di</strong> una soluzione <strong>in</strong>frastrutturale<br />

che <strong>per</strong>metta la gestione delle risorse così rappresentate pur provenendo<br />

da piattaforme eterogenee.<br />

Aff<strong>in</strong>chè <strong>il</strong> Web of Data possa <strong>di</strong>ventare la base <strong>per</strong> gli agenti software<br />

<strong>in</strong>telligenti del Web semantico, è necessario che questi passaggi <strong>in</strong>croc<strong>in</strong>o <strong>il</strong><br />

<strong>per</strong>corso dell’<strong>in</strong>tegrazione con l’attuale Web.<br />

Il progetto <strong>InterDataNet</strong> (IDN) si muove <strong>in</strong> questa <strong>di</strong>rezione. Si tratta<br />

<strong>di</strong> un’architettura stratificata <strong>di</strong> <strong>in</strong>terdatawork<strong>in</strong>g, orientata alla gestione<br />

<strong>in</strong>tero<strong>per</strong>ab<strong>il</strong>e <strong>di</strong> <strong>in</strong>formazioni <strong>di</strong>stribuite che ha l’obiettivo <strong>di</strong> migliorare<br />

l’<strong>in</strong>terazione e la collaborazione tra organizzazioni <strong>in</strong> rete.<br />

<strong>InterDataNet</strong> – allo stu<strong>di</strong>o dal 2001 presso <strong>il</strong> Laboratorio <strong>di</strong> Tecnologie<br />

della Telematica al Dipartimento <strong>di</strong> Elettronica e Telecomunicazioni della<br />

Facoltà <strong>di</strong> Ingegneria presso l’Università degli Stu<strong>di</strong> <strong>di</strong> Firenze – propone<br />

un modello data oriented <strong>per</strong> la rappresentazione <strong>di</strong> <strong>in</strong>formazioni strutturate<br />

ed è progettato come middleware, <strong>in</strong><strong>di</strong>pendente dalle applicazioni, composto<br />

da servizi stratificati che gestiscono gli aspetti logici del trattamento delle<br />

risorse.<br />

Uno <strong>di</strong> questi aspetti è la gestione della memorizzazione <strong>per</strong>sistente delle<br />

unità elementari <strong>di</strong> <strong>in</strong>formazioni e questo tema sarà l’argomento pr<strong>in</strong>cipale<br />

del lavoro qui presentato.<br />

xiv


Introduzione<br />

In questo rapporto <strong>di</strong> tesi si affronterà la progettazione delle specifiche e<br />

lo sv<strong>il</strong>uppo <strong>di</strong> una reference implementation <strong>per</strong> un servizio <strong>di</strong> storage <strong>per</strong>sistente<br />

orientato al Web of Data. Tra i suoi requisiti fondamentali, ci sarà<br />

quello <strong>di</strong> poter essere ut<strong>il</strong>izzato <strong>per</strong> costituire <strong>il</strong> layer più basso dell’architettura<br />

stratificata <strong>di</strong> <strong>InterDataNet</strong>, dal quale <strong>il</strong> servizio ere<strong>di</strong>terà <strong>il</strong> nome <strong>di</strong><br />

“<strong>Storage</strong> Interface”.<br />

Durante la stesura delle specifiche sarà def<strong>in</strong>ito un modello <strong>in</strong>formativo<br />

<strong>per</strong> un tipo <strong>di</strong> risorsa sul quale sia possib<strong>il</strong>e ipotizzare <strong>di</strong> gettare le fondamenta<br />

del Web of Data e <strong>di</strong> IDN.<br />

<strong>Storage</strong> Interface <strong>per</strong>metterà qu<strong>in</strong><strong>di</strong> <strong>di</strong> gestire la memorizzazione <strong>di</strong> risorse<br />

basate su questo modello, <strong>in</strong>terfacciando le unità <strong>in</strong>formative elementari a<br />

specifici sistemi <strong>di</strong> storage quali f<strong>il</strong>e system o database.<br />

Un ruolo chiave <strong>di</strong> un sim<strong>il</strong>e servizio, al quale sarà dato risalto <strong>in</strong> questa<br />

relazione, è la possib<strong>il</strong>ità <strong>di</strong> ab<strong>il</strong>itare <strong>il</strong> riuso <strong>di</strong> risorse preesistenti nei sistemi<br />

legacy. Per armonizzare l’eterogeneità delle <strong>in</strong>formazioni presenti negli attuali<br />

sistemi <strong>di</strong>stribuiti, è richiesta un’<strong>in</strong>terfaccia comune con la quale esporre i dati<br />

e che <strong>per</strong>metta una visione unificata dei contenuti <strong>di</strong>sponib<strong>il</strong>i. La stesura della<br />

specifica del servizio sarà costruita <strong>in</strong>torno a queste esigenze.<br />

Lo stu<strong>di</strong>o del servizio pone le basi <strong>per</strong> una realizzazione concreta <strong>di</strong> Inter-<br />

DataNet. Da un lato, <strong>Storage</strong> Interface costituisce <strong>il</strong> servizio base sul quale<br />

<strong>il</strong> resto dell’architettura porrà le sue fondamenta. Da un altro, gli stu<strong>di</strong> che<br />

portano alla sua realizzazione saranno riut<strong>il</strong>izzati <strong>per</strong> lo sv<strong>il</strong>uppo tecnico dei<br />

servizi nei livelli su<strong>per</strong>iori e questo lavoro fornirà un modello <strong>di</strong> progettazione<br />

<strong>per</strong> la loro realizzazione.<br />

Per raggiungere questo obiettivo saranno analizzati a largo campo i pr<strong>in</strong>cipi<br />

del Representational State Transfer (REST), che propone uno st<strong>il</strong>e <strong>per</strong><br />

ottenere scalab<strong>il</strong>ità e <strong>per</strong>formance nella gestione <strong>di</strong> risorse, e delle Service<br />

Oriented Architecture (SOA), le quali forniscono un approccio mirato alla<br />

<strong>in</strong>tero<strong>per</strong>ab<strong>il</strong>ità tra piattaforme eterogenee. Saranno prese <strong>in</strong> esame anche le<br />

tecniche con le quali concretizzare questi pr<strong>in</strong>cipi e si affronteranno argomenti<br />

come i Web Service e le Resource Oriented Architecture (ROA).<br />

Questi aspetti sono <strong>di</strong> fondamentale importanza <strong>per</strong> una buona progettazione<br />

<strong>di</strong> <strong>Storage</strong> Interface e <strong>per</strong> lo sv<strong>il</strong>uppo dei servizi che appartengono agli<br />

altri livelli <strong>di</strong> <strong>InterDataNet</strong>.<br />

xv


Introduzione<br />

La presente relazione <strong>di</strong> tesi sarà articolata nei seguenti capitoli:<br />

Capitolo 1 – Web Of Data<br />

Descriverà gli aspetti pr<strong>in</strong>cipali del concetto <strong>di</strong> Web of Data, come questo ha<br />

orig<strong>in</strong>e nel Web attuale e come potrà agire a supporto del Web Semantico.<br />

Capitolo 2 – Il progetto <strong>InterDataNet</strong><br />

Illustrerà i concetti e le motivazioni su cui si basa <strong>il</strong> progetto <strong>InterDataNet</strong>,<br />

ne presenterà i pr<strong>in</strong>cipi <strong>di</strong> funzionamento, la f<strong>il</strong>osofia ed i componenti.<br />

Capitolo 3 – Tecnologie <strong>per</strong> IDN e <strong>Storage</strong> Interface<br />

Illustrerà lo stato dell’arte delle tecnologie <strong>di</strong> r<strong>il</strong>ievo <strong>per</strong> questa tesi che ruotano<br />

<strong>in</strong>torno al Web , <strong>in</strong> particolare si esam<strong>in</strong>eranno le Service Oriented<br />

Architecture (SOA), i Web Service, <strong>il</strong> Web Service Description Language<br />

(WSDL), <strong>il</strong> Representational State Transfer (REST), le Resource Oriented<br />

Architecture (ROA) ed <strong>il</strong> Resource Description Framework (RDF).<br />

Capitolo 4 – Scenari applicativi<br />

Presenterà lo stu<strong>di</strong>o dei casi applicativi <strong>in</strong> cui è stato proiettato <strong>il</strong> servizio<br />

<strong>di</strong> <strong>Storage</strong> Interface, dal quale sono emerse le caratteristiche e le funzionalità<br />

desiderab<strong>il</strong>i dal servizio.<br />

Capitolo 5 – Requisiti dell’Interfaccia<br />

Presenterà la Specifica dei Requisiti Software <strong>di</strong> <strong>Storage</strong> Interface, elaborata<br />

durante questo lavoro <strong>di</strong> tesi.<br />

Capitolo 6 – <strong>Progetto</strong> dell’Interfaccia<br />

Descriverà l’<strong>in</strong>formation model del servizio, le o<strong>per</strong>azioni e l’<strong>in</strong>terfaccia e<br />

presenterà <strong>il</strong> data model XML, i due WSDL conformi agli standard 1.1 e 2.0,<br />

<strong>il</strong> b<strong>in</strong><strong>di</strong>ng HTTP ed <strong>il</strong> b<strong>in</strong><strong>di</strong>ng SOAP <strong>per</strong> <strong>Storage</strong> Interface.<br />

xvi


Introduzione<br />

Capitolo 7 – Implementazione del Servizio<br />

Illustrerà i progetti ed <strong>il</strong> funzionamento <strong>di</strong> una applicazione <strong>in</strong> Java con SOAP<br />

ed una <strong>in</strong> PHP <strong>in</strong> st<strong>il</strong>e ROA che sono state realizzate sulla base dell’<strong>in</strong>terfaccia<br />

del servizio def<strong>in</strong>ita nel capitolo 6.<br />

Appen<strong>di</strong>ce A – WSDL e XML Schema <strong>di</strong> <strong>Storage</strong> Interface<br />

In appen<strong>di</strong>ce, saranno riportati i f<strong>il</strong>e XML ed f<strong>il</strong>e WSDL prodotti <strong>in</strong> questo<br />

lavoro <strong>di</strong> tesi, i quali contengono le specifiche del servizio <strong>di</strong> <strong>Storage</strong> Interface<br />

def<strong>in</strong>ito nel capitolo 6.<br />

xvii


Parte I<br />

Ab<strong>il</strong>itare <strong>il</strong> Web of Data


Capitolo<br />

1<br />

Web Of Data<br />

“Errors us<strong>in</strong>g <strong>in</strong>adequate data are much less than those us<strong>in</strong>g<br />

no data at all.”<br />

Charles Babbage<br />

Se la si cercasse oggi, non si troverebbe una def<strong>in</strong>izione precisa ed universalmente<br />

riconosciuta <strong>di</strong> cosa sia <strong>il</strong> Web of Data. È un concetto emergente<br />

che ha orig<strong>in</strong>e nelle tendenze correnti del Web 2.0 e del futuro Web semantico.<br />

Non c’è uno standard o una implementazione pratica che lo rappresenta,<br />

ma se ne deduce l’esistenza osservando la <strong>di</strong>rezione <strong>in</strong> cui le ultime tecnologie<br />

si stanno sp<strong>in</strong>gendo.<br />

In questo capitolo sarà analizzato prima <strong>di</strong> tutto <strong>il</strong> Web semantico, che<br />

può fornire una valida motivazione al Web of Data. Verrà confrontato con<br />

<strong>il</strong> panorama attuale e cercheremo <strong>di</strong> capire se <strong>il</strong> Web si stia effettivamente<br />

muovendo <strong>in</strong> questa <strong>di</strong>rezione.


Web Of Data L’avvento del Semantic Web<br />

Cercheremo poi <strong>di</strong> capire che significato abbia un Web orientato ai dati,<br />

analizzando i segni riconoscib<strong>il</strong>i nelle ultime tendenze tecnologiche, e verrà<br />

<strong>in</strong>f<strong>in</strong>e offerta una panoramica sulle <strong>in</strong>frastrutture che lo potranno sostenere.<br />

1.1 L’avvento del Semantic Web<br />

Il Web tra<strong>di</strong>zionale è pr<strong>in</strong>cipalmente composto <strong>di</strong> documenti scritti <strong>in</strong><br />

HTML, ed è proprio grazie alla semplicità ed alla imme<strong>di</strong>atezza <strong>di</strong> questo<br />

l<strong>in</strong>guaggio che ha avuto successo. Si tratta <strong>di</strong> un l<strong>in</strong>guaggio <strong>di</strong> markup, ovvero<br />

<strong>di</strong> un l<strong>in</strong>guaggio a marcatori <strong>di</strong> documento che descrive i meccanismi<br />

<strong>di</strong> rappresentazione presentazionali del testo.<br />

Ad esempio si usa l’HTML <strong>per</strong> contrassegnare che “L’avvento del Semantic<br />

Web” è un titolo se racchiu<strong>di</strong>amo questa str<strong>in</strong>ga <strong>di</strong> testo tra due tag quali<br />

ed . Il browser molto probab<strong>il</strong>mente <strong>per</strong> <strong>di</strong>segnare sullo schermo<br />

tale scritta userà un carattere specifico e una <strong>di</strong>mensione più grande rispetto<br />

agli altri contenuti.<br />

Per lo più HTML fornisce un <strong>in</strong>sieme <strong>di</strong> simboli che <strong>per</strong>mettono <strong>di</strong> specificare<br />

come una pag<strong>in</strong>a dovrà apparire ai vostri occhi, ed <strong>in</strong>fatti la maggior<br />

parte delle <strong>in</strong>formazioni sul Web tra<strong>di</strong>zionale sono progettate <strong>per</strong> <strong>il</strong> consumo<br />

da parte <strong>di</strong> esseri umani. La pr<strong>in</strong>cipale funzione <strong>di</strong> una pag<strong>in</strong>a Web che non<br />

riguarda la sua rappresentazione grafica è l’hy<strong>per</strong>l<strong>in</strong>k, <strong>il</strong> collegamento i<strong>per</strong>testuale:<br />

sempre tramite contrassegni, si può marcare (con <strong>il</strong> tag anchor ovvero<br />

) un str<strong>in</strong>ga <strong>di</strong> testo <strong>in</strong> modo da renderla <strong>in</strong>terattiva al clic del mouse<br />

da parte dell’utente. L’effetto <strong>di</strong> questa <strong>in</strong>terazione solitamente comporta<br />

l’a<strong>per</strong>tura <strong>di</strong> un nuovo documento che risulta appunto collegato. Questo fa<br />

si che si possa def<strong>in</strong>ire <strong>il</strong> Web come una vasta raccolta mon<strong>di</strong>ale <strong>di</strong> documenti<br />

(<strong>in</strong> genere multime<strong>di</strong>ali) nel quale si può navigare grazie all’uso <strong>di</strong> questi<br />

collegamenti.<br />

Tuttavia l’<strong>in</strong>formazione contenuta sul Web può essere def<strong>in</strong>ita <strong>in</strong> modo che<br />

un computer possa usarla non soltanto <strong>per</strong> rappresentarla sullo schermo, ma<br />

anche <strong>per</strong> ottenere <strong>in</strong>tero<strong>per</strong>ab<strong>il</strong>ità ed <strong>in</strong>tegrazione tra applicazioni e sistemi.<br />

È <strong>in</strong> questo ambito che entra <strong>in</strong> gioco la tecnologia chiamata Semantic<br />

Web <strong>il</strong> cui obiettivo è fornire strumenti e standard <strong>per</strong> trattare l’<strong>in</strong>formazione<br />

presente sul Web <strong>in</strong> modo automatico da parte <strong>di</strong> elaboratori. Per<br />

<strong>per</strong>mettere <strong>per</strong>ò l’elaborazione automatica e lo scambio macch<strong>in</strong>a-macch<strong>in</strong>a<br />

3


Web Of Data L’avvento del Semantic Web<br />

<strong>di</strong> <strong>in</strong>formazioni è necessario rappresentarle <strong>in</strong> modo che <strong>il</strong> computer possa<br />

comprenderle.<br />

Secondo l’<strong>in</strong>ventore del WWW, Tim Berner-Lee, <strong>il</strong> “Web semantico non<br />

è separato dal Web, ma è una sua estensione, nella quale alle <strong>in</strong>formazioni<br />

è dato un significato ben def<strong>in</strong>ito che <strong>per</strong>mette una migliore coo<strong>per</strong>azione tra<br />

computer e <strong>per</strong>sone” [Cardoso]<br />

È <strong>in</strong>teressante osservare che un hy<strong>per</strong>l<strong>in</strong>k è una <strong>in</strong>formazione si <strong>in</strong>terpretab<strong>il</strong>e<br />

dalla macch<strong>in</strong>a, ma l’uso più comune è l’azione <strong>di</strong> a<strong>per</strong>tura del<br />

collegamento <strong>in</strong> conseguenza <strong>di</strong> un <strong>di</strong>retto comando impartito da chi ut<strong>il</strong>izza<br />

<strong>il</strong> computer. Il Semantic Web pone l’accento soprattutto sulla elaborazione<br />

automatica. Per farsi una prima idea può essere ut<strong>il</strong>e pensare ad un programma<br />

spider <strong>di</strong> un motore <strong>di</strong> ricerca, che esam<strong>in</strong>a <strong>in</strong> automatico i documenti da<br />

<strong>in</strong><strong>di</strong>cizzare: <strong>il</strong> successo <strong>di</strong> una ricerca <strong>di</strong> una qualche keyword <strong>di</strong>penderà dalla<br />

capacità con cui lo spider ha compreso quali pag<strong>in</strong>e trattano tale argomento.<br />

A <strong>di</strong>fferenza <strong>di</strong> quando un browser visualizza una pag<strong>in</strong>a <strong>in</strong> seguito ad<br />

un comando ricevuto <strong>di</strong>rettamente tramite una <strong>per</strong>iferica <strong>di</strong> <strong>in</strong>put, lo spider<br />

lavora <strong>in</strong> autonomia e mette <strong>in</strong> pratica una <strong>in</strong>terazione macch<strong>in</strong>a-macch<strong>in</strong>a.<br />

Il l<strong>in</strong>guaggio XML, Extensible Markup Language [XML], gioca un<br />

ruolo importante <strong>in</strong> questo campo: <strong>in</strong>fatti <strong>in</strong> modo sim<strong>il</strong>e a come HTML<br />

contrassegna un titolo o un collegamento, XML def<strong>in</strong>isce una s<strong>in</strong>tassi <strong>per</strong><br />

contrassegnare elementi <strong>di</strong> <strong>in</strong>formazione. L’adozione <strong>di</strong> XML ab<strong>il</strong>ita le macch<strong>in</strong>e<br />

ad un alto grado <strong>di</strong> <strong>in</strong>tero<strong>per</strong>ab<strong>il</strong>ità poiché <strong>per</strong>mette lo scambio <strong>di</strong><br />

dati <strong>in</strong> un l<strong>in</strong>guaggio comune che è portato <strong>per</strong> l’elaborazione automatica.<br />

Tuttavia XML <strong>di</strong> <strong>per</strong> se non aggiunge un significato. Di solito è tramite<br />

accor<strong>di</strong> raggiunti tra le parti che ut<strong>il</strong>izzano le <strong>in</strong>formazioni che si def<strong>in</strong>isce <strong>il</strong><br />

significato <strong>di</strong> un documento co<strong>di</strong>ficato <strong>in</strong> XML.<br />

Nel Semantic Web la def<strong>in</strong>izione delle relazioni tra le risorse avviene tramite<br />

<strong>il</strong> Resource Description Framework (RDF) [RDF]: è nato <strong>per</strong> descrivere<br />

le <strong>in</strong>formazioni, <strong>in</strong> particolare quelle presenti sul Web ed è una delle<br />

tecnologie fondamentali della sua estensione semantica. È un l<strong>in</strong>guaggio <strong>di</strong><br />

metadati semplice e polivalente <strong>per</strong> rappresentare <strong>in</strong>formazioni e fornisce un<br />

modello <strong>per</strong> descrivere e creare relazioni tra risorse. Il legame <strong>di</strong> parentela<br />

tra RDF e Web è l’URI: una risorsa RDF è def<strong>in</strong>ita come un qualsiasi oggetto<br />

che sia univocamente identificato da un Uniform Resource Identifier<br />

[RFC3986]. Le risorse sono dotate <strong>di</strong> proprietà. Le proprietà sono identificate<br />

dal loro tipo ed <strong>per</strong> una determ<strong>in</strong>ata risorsa hanno un corrispondente<br />

4


Web Of Data L’avvento del Semantic Web<br />

valore. I tipi <strong>di</strong> proprietà esprimono la relazione tra <strong>il</strong> valore e la risorsa. Un<br />

tipo quando identificato da un suo proprio URI assume carattere universale.<br />

La struttura base <strong>di</strong> RDF è molto semplice e usa delle terne <strong>per</strong> descrivere<br />

le proprietà <strong>di</strong> una risorsa. Queste terne si trovano <strong>in</strong> forma <strong>di</strong> Soggetto-<br />

Pre<strong>di</strong>cato-Oggetto.<br />

La notazione a triple fornisce un meccanismo flessib<strong>il</strong>e <strong>per</strong> relazionare ogni<br />

cosa ad ogni altra. RDF si appoggia agli URI <strong>per</strong> <strong>per</strong>mettere la def<strong>in</strong>izione<br />

<strong>di</strong> concetti vali<strong>di</strong> a livello globale. Ad esempio quando un URI è ut<strong>il</strong>izzato<br />

<strong>per</strong> def<strong>in</strong>ire un soggetto, affermazioni che lo riguardano possono essere pubblicate<br />

ovunque sul Web con la garanzia che avranno lo stesso significato.<br />

In altre parole, le <strong>in</strong>formazioni descritte tramite URI possono essere trovate,<br />

ut<strong>il</strong>izzate, con<strong>di</strong>vise e aggregate più fac<strong>il</strong>mente.<br />

RDF è usato <strong>in</strong>oltre come base su cui costruire le ontologie: una ontologia<br />

è un vocabolario comune che fornisce un ben def<strong>in</strong>ito <strong>in</strong>sieme <strong>di</strong> costrutti <strong>per</strong><br />

la realizzazione <strong>di</strong> una conoscenza <strong>di</strong> livello su<strong>per</strong>iore da usare <strong>per</strong> specificare<br />

la semantica delle term<strong>in</strong>ologie <strong>in</strong> un ben def<strong>in</strong>ito e non ambiguo modo.<br />

Nel Semantic Web si usa <strong>il</strong> Web Ontology Language (OWL) [RFC3986].<br />

OWL fornisce un vocabolario <strong>per</strong> descrivere le proprietà e le classi <strong>di</strong> oggetti<br />

con valore semantico [Cardoso]. L’obiettivo è ab<strong>il</strong>itare <strong>in</strong>ferenze sulle<br />

<strong>in</strong>formazioni e dunque arricchire <strong>il</strong> valore della conoscenza trattata.<br />

l<strong>in</strong>k<br />

Resource<br />

l<strong>in</strong>k<br />

Tra<strong>di</strong>tional Web Vision Semantic Web Vision<br />

l<strong>in</strong>k<br />

l<strong>in</strong>k<br />

Resource<br />

l<strong>in</strong>k<br />

Resource<br />

l<strong>in</strong>k<br />

Resource<br />

l<strong>in</strong>k<br />

l<strong>in</strong>k<br />

Resource<br />

l<strong>in</strong>k<br />

Resource<br />

Resource<br />

l<strong>in</strong>k<br />

Resource<br />

l<strong>in</strong>k<br />

humanResource<br />

HR<br />

salesman Jack<br />

Shop<br />

responsible<br />

support<br />

hasServices<br />

Product<br />

Services<br />

hasProducts<br />

track<br />

<strong>di</strong>rector<br />

Products<br />

sell<br />

collegue<br />

Jhon<br />

sell<br />

Product<br />

Figura 1.1: Risorse <strong>in</strong>tercollegate dal punto <strong>di</strong> vista del Web tra<strong>di</strong>zionale e<br />

da un punto <strong>di</strong> vista del Web semantico<br />

5


Web Of Data Il Semantic Web è <strong>il</strong> futuro?<br />

La figura 1.1 <strong>il</strong>lustra graficamente <strong>il</strong> confronto tra Web <strong>di</strong> documenti <strong>in</strong>terconnessi<br />

e Web semantico. Il Web tra<strong>di</strong>zionale è dotato <strong>di</strong> ridotta <strong>per</strong>cezione<br />

e riconosce soltanto un collegamento da un documento. La navigazione delle<br />

risorse <strong>per</strong> scoprire una qualche <strong>in</strong>formazione è demandata all’<strong>in</strong>telligenza<br />

umana. L’uomo comprende <strong>il</strong> significato dei collegamenti basandosi sull’<strong>in</strong>terpretazione<br />

della loro descrizione, e si orienta <strong>in</strong> base al significato letterale.<br />

Qu<strong>in</strong><strong>di</strong> è <strong>in</strong> grado <strong>di</strong> svolgere un ragionamento che lo porterà ad esempio ad<br />

<strong>in</strong><strong>di</strong>viduare, se esiste, la pag<strong>in</strong>a che può fornire supporto ai clienti su un sito<br />

<strong>di</strong> acquisti onl<strong>in</strong>e.<br />

L’idea del Web semantico è che sia la macch<strong>in</strong>a ad eseguire questi compiti<br />

o una parte <strong>di</strong> essi, grazie a tecniche che <strong>per</strong>mettono <strong>di</strong> aumentare la<br />

<strong>per</strong>cezione ed <strong>in</strong>terpretarne almeno <strong>in</strong> parte <strong>il</strong> significato.<br />

1.2 Il Semantic Web è <strong>il</strong> futuro?<br />

Sebbene molte delle idee che stanno <strong>di</strong>etro al Web semantico nascono nella<br />

<strong>di</strong>scipl<strong>in</strong>a dell’Intelligenza Artificiale, <strong>il</strong> suo <strong>di</strong>segno è e resta una estensione<br />

del Web esistente. La “R” <strong>di</strong> risorsa nel Resource Description Framework<br />

è la stessa “R” che troviamo <strong>in</strong> Uniform Resource Identifier. Anche se si<br />

usano <strong>in</strong> questo campo [Ayers07c] non solo <strong>per</strong> <strong>in</strong><strong>di</strong>viduare un documento<br />

che una <strong>per</strong>sona può leggere ma appunto se ne estende <strong>il</strong> concetto così da<br />

poter identificare ogni cosa, reale o virtuale, gli URI che troviamo <strong>in</strong> RDF<br />

sono proprio gli stessi che <strong>il</strong> Web usa da ormai quasi 20 anni.<br />

Il Semantic Web è soprattutto un <strong>per</strong>corso [Ayers06] e molto <strong>di</strong> quello che si<br />

sta stu<strong>di</strong>ando <strong>in</strong> questo campo tratta argomenti <strong>di</strong> avanguar<strong>di</strong>a, molto lontani<br />

anche dal Web arricchito <strong>di</strong> tecnologie <strong>di</strong>namiche, <strong>in</strong>terazioni as<strong>in</strong>crone ed<br />

effetti grafici <strong>di</strong> nuova generazione che stiamo ut<strong>il</strong>izzando oggi chiamandolo<br />

Web 2.0 1 .<br />

Come la storia ci <strong>in</strong>segna, anche fuori dal mondo <strong>in</strong>formatico, molte rivoluzioni<br />

nate da ben motivati propositi sono f<strong>in</strong>ite <strong>di</strong>sastrosamente. Con<br />

1.244.449.601 <strong>di</strong> utenti 2 <strong>il</strong> Web oggi ha una <strong>in</strong>erzia tale che non è possib<strong>il</strong>e<br />

cambiare <strong>di</strong>rezione senza andare <strong>in</strong>contro a fallimenti miserab<strong>il</strong>i. Se dobbia-<br />

1 http://en.wikipe<strong>di</strong>a.org/wiki/Web_2.0<br />

2 ve<strong>di</strong> http://www.<strong>in</strong>ternetworldstats.com, statistiche del 30 settembre 2007<br />

6


Web Of Data Il Semantic Web è <strong>il</strong> futuro?<br />

mo abbandonare la concezione <strong>di</strong> Web <strong>di</strong> Documenti tra <strong>di</strong> loro collegati, è<br />

necessario farlo con mani <strong>di</strong> velluto.<br />

Di fatto è proprio quello che sta accadendo. Nel Web 2.0 possiamo già<br />

vedere che tag, aggregatori, sistemi <strong>di</strong> content rank<strong>in</strong>g ci assistono nel migliorare<br />

la nostra es<strong>per</strong>ienza giornaliera. Quando ad esempio con <strong>il</strong> cursore del<br />

mouse <strong>in</strong><strong>di</strong>cate <strong>il</strong> numero <strong>di</strong> stelle con le quali votare un video che avete appena<br />

visto su YouTube.com, <strong>di</strong> fatto state assegnando un valore semantico a<br />

quel contenuto, <strong>il</strong> cui significato verrà <strong>in</strong>terpretato da un sistema <strong>per</strong> valutare<br />

l’<strong>in</strong>teresse della risorsa pubblicata. Probab<strong>il</strong>mente non ci sarà OWL <strong>di</strong>etro a<br />

tale significato semantico, piuttosto vi sarà un rout<strong>in</strong>e appositamente scritta<br />

da un qualche es<strong>per</strong>to <strong>di</strong> programmazione, e qu<strong>in</strong><strong>di</strong> <strong>il</strong> valore espresso ha senso<br />

soltanto <strong>in</strong> un contesto locale al sito. L’idea è che <strong>in</strong> un futuro prossimo <strong>il</strong><br />

video che voi avete votato sarà semanticamente <strong>in</strong>teressante anche fuori al<br />

sito <strong>di</strong> YouTube grazie ad RDF, OWL ed altre tecnologie ancora <strong>in</strong> fase <strong>di</strong><br />

sv<strong>il</strong>uppo.<br />

Il Web Semantico si evolve qu<strong>in</strong><strong>di</strong> a piccoli passi. Lo fa secondo i pr<strong>in</strong>cipi<br />

che ruotano <strong>in</strong>torno all’Extreme Programm<strong>in</strong>g [Ayers06]: release frequenti e<br />

con piccole mo<strong>di</strong>fiche ci <strong>per</strong>mettono un maggior controllo sul progetto ed <strong>il</strong><br />

feedback ricevuto ci rassicura se <strong>per</strong>corriamo la giusta <strong>di</strong>rezione o ci <strong>per</strong>mette<br />

<strong>di</strong> trovarla grazie a piccole mo<strong>di</strong>fiche.<br />

Danny Ayers [Ayers06], <strong>in</strong><strong>di</strong>vidua 3 strategie con cui portare avanti questa<br />

evoluzione del Web:<br />

• <strong>il</strong> primo approccio è assegnare ai contenuti attuali un valore <strong>in</strong>terpretab<strong>il</strong>e<br />

dalle macch<strong>in</strong>e. Un esempio è l’ut<strong>il</strong>izzo che si può fare <strong>in</strong> HTML<br />

dell’attributo rel=”...”, che può essere assegnato ai tag e .<br />

Si usa già adesso <strong>per</strong> specificare ad esempio un foglio <strong>di</strong> st<strong>il</strong>e CSS <strong>per</strong><br />

una pag<strong>in</strong>a: <strong>in</strong><strong>di</strong>ca<br />

al browser che la risorsa <strong>in</strong><strong>di</strong>cata da href è uno StyleSheet <strong>per</strong> <strong>il</strong><br />

documento <strong>in</strong> cui si trova questo tag;<br />

• una seconda strategia, che consiste nell’<strong>in</strong>serire <strong>in</strong>formazioni fruib<strong>il</strong>i<br />

dalle macch<strong>in</strong>e nei contenuti HTML esistenti, potrebbe risultare più<br />

appetib<strong>il</strong>e. L’<strong>in</strong>iziativa dei microformats [Dimon05] viaggia <strong>in</strong> questa<br />

<strong>di</strong>rezione;<br />

• oppure si possono aggiungere <strong>in</strong>terfacce orientate al Web semantico<br />

ai sistemi Web esistenti. L’idea è quella <strong>di</strong> fornire e ricevere RDF<br />

7


Web Of Data Dal Web <strong>di</strong> Documenti al web <strong>di</strong> Dati<br />

tramite HTTP. Feed quali Atom ed RSS sono un esempio <strong>di</strong> quest’approccio,<br />

ma probab<strong>il</strong>mente nell’imme<strong>di</strong>ato i benefici non giustificheranno<br />

lo sforzo <strong>di</strong> sv<strong>il</strong>uppo necessario ad approntare i sistemi esistenti:<br />

molti sv<strong>il</strong>uppatori non hanno la volontà o l’<strong>in</strong>teresse ad adottare <strong>il</strong> Web<br />

semantico, ma cercano soltanto qualcosa <strong>per</strong> migliorare la user ex<strong>per</strong>ience.<br />

L’attenzione è pr<strong>in</strong>cipalmente posta su user <strong>in</strong>terface e content<br />

management system.<br />

1.3 Dal Web <strong>di</strong> Documenti al web <strong>di</strong> Dati<br />

Sul <strong>per</strong>corso che ci porterà nel futuro del Web, l’unica cosa che sembra<br />

certa è che l’attenzione si sposterà dal documento al dato: Web Service e<br />

tecnologie come AJAX o le Rich Internet Application sono basate su HTML,<br />

HTTP ed URI ma la loro attenzione non si rivolge al documento come un<br />

tutt’uno. Le applicazioni che usano queste tecnologie si concentrano piuttosto<br />

su s<strong>in</strong>gole <strong>in</strong>formazioni con le quali svolgere un qualche tipo <strong>di</strong> elaborazione.<br />

In pratica si sta concentrando l’<strong>in</strong>teresse su contenuti che hanno una grana<br />

più f<strong>in</strong>e rispetto all’<strong>in</strong>tera pag<strong>in</strong>a HTML.<br />

Sta emergendo <strong>il</strong> concetto <strong>di</strong> Web of Data and Programs [Bratt05]<br />

[Bratt05S] contrapposto appunto al Web of Documents. Il Web <strong>di</strong> programmi<br />

è quello dei Web Service, <strong>il</strong> Web dei dati è quello che porta al Semantic Web<br />

e si manifesta con collezioni <strong>di</strong> <strong>in</strong>formazioni <strong>in</strong>terconnesse che troviamo nel<br />

panorama del Web 2.0 al fianco delle collezioni <strong>di</strong> documenti i<strong>per</strong>testuali<br />

tra<strong>di</strong>zionali.<br />

Digg, del.icio.us, Flickr, YouTube e Blogger assomigliano più ad<br />

una applicazioni che ad un sito tra<strong>di</strong>zionale. Offrono servizi <strong>per</strong> trattare<br />

bookmark, immag<strong>in</strong>i o video, appunti, commenti e descrizioni. Qu<strong>in</strong><strong>di</strong> sono<br />

<strong>in</strong>centrati sul dato piuttosto che sul documento che lo contiene ovvero <strong>il</strong><br />

documento che viene mostrato sul vostro browser. Molti <strong>di</strong> questi siti offrono<br />

anche la possib<strong>il</strong>ità <strong>di</strong> accedere <strong>di</strong>rettamente ai dati trattati con delle apposite<br />

API. Un’altro importante esempio è <strong>il</strong> Simple <strong>Storage</strong> Service <strong>di</strong> Amazon<br />

che <strong>per</strong>mette la memorizzazione <strong>di</strong> <strong>in</strong>formazioni generiche, con l’<strong>in</strong>terfaccia <strong>di</strong><br />

un Web Service RESTful [RichardsonRuby], le quali possono essere descritte<br />

tramite metadati ed ut<strong>il</strong>izzate ad esempio tramite AJAX [Hansen]. Il tutto<br />

appare più come un database flessib<strong>il</strong>e modellato <strong>in</strong>torno al Web che non un<br />

<strong>in</strong>sieme <strong>di</strong> pag<strong>in</strong>e HTML consultab<strong>il</strong>i con un browser. Qu<strong>in</strong><strong>di</strong> <strong>il</strong> Web of Data<br />

8


Web Of Data Dal Web <strong>di</strong> Documenti al web <strong>di</strong> Dati<br />

è un concetto fondamentale <strong>per</strong> <strong>il</strong> Semantic Web, ma <strong>il</strong> Semantic Web non è<br />

necessariamente <strong>il</strong> suo unico f<strong>in</strong>e.<br />

Data<br />

Web of documents<br />

Data<br />

Content model layer<br />

Web of documents<br />

Web of data<br />

Documents<br />

Figura 1.2: “From a Web of documents to a Web of Data” [Ayers07a]<br />

Il Web 2.0 qu<strong>in</strong><strong>di</strong> ha già fatto qualche passo <strong>in</strong> <strong>di</strong>rezione del Web of Data.<br />

Molte recenti tecnologie presentano un aspetto che merita particolare<br />

attenzione: sono strutturate, <strong>di</strong>rettamente o <strong>in</strong><strong>di</strong>rettamente, su <strong>di</strong> un content<br />

model layer [Ayers07a] ovvero poggiano le loro basi su <strong>di</strong> un data model<br />

orientato ai contenuti. Questo modello è descritto nelle specifiche del formato<br />

Atom, dentro alla Java Content Repository ed <strong>in</strong> numerosi altri sistemi dell’o<strong>di</strong>erno<br />

Web. Il content model layer tratta documenti e metadati a questi<br />

associati come un tutt’uno. Concepire questo modo <strong>di</strong> funzionare secondo un<br />

pr<strong>in</strong>cipio <strong>di</strong> stratificazione ci offre una migliore panoramica sulle potenzialità<br />

<strong>di</strong> questo approccio. Uno strato <strong>di</strong> astrazione che modella i contenuti ed i<br />

metadati associati funziona con un Web basato sui documenti, con un Web<br />

orientato ai dati ed è compatib<strong>il</strong>e alle prospettive del Web semantico.<br />

Si può pensare che questo data model rappresenti un passo <strong>in</strong>terme<strong>di</strong>o<br />

e graduale verso <strong>il</strong> Web of Data. In figura 1.2 si può vedere come questa<br />

strategia <strong>per</strong>metta una transizione graduale da una concezione all’altra. Il<br />

Web of Documents che si appoggia sul content model layer può essere visto<br />

come l’<strong>in</strong>sieme delle pag<strong>in</strong>e dei siti che forniscono l’accesso alle <strong>in</strong>formazioni<br />

dei servizi del Web 2.0.<br />

L’URI <strong>di</strong>viene qu<strong>in</strong><strong>di</strong> uno strumento generalizzato, <strong>per</strong> accedere non più<br />

9


Web Of Data Infrastruttura del Web <strong>di</strong> dati<br />

soltanto ad un documento, ma <strong>in</strong><strong>di</strong>rizza f<strong>in</strong>emente le risorse [Ayers07b]. Le<br />

tecnologie del semantic Web quali RDF ed OWL ci aiuteranno a renderne<br />

universale l’uso ed <strong>il</strong> significato.<br />

1.4 Infrastruttura del Web <strong>di</strong> dati<br />

Da un punto <strong>di</strong> vista tecnologico, <strong>il</strong> Semantic Web ut<strong>il</strong>izza l’attuale <strong>in</strong>frastruttura<br />

del Web <strong>per</strong> ottenere accesso ai dati <strong>di</strong> cui ha bisogno. Le <strong>in</strong>formazioni<br />

del Web of Data quando non sono <strong>di</strong>rettamente impacchettate dentro<br />

a documenti HTML, usano <strong>per</strong> l’accesso la stessa <strong>in</strong>terfaccia HTTP.<br />

Non ci sono nuovi protocolli se non <strong>il</strong> SOAP, ma questo non è altro che<br />

un meccanismo <strong>per</strong> <strong>in</strong>viare XML tramite (pr<strong>in</strong>cipalmente) HTTP.<br />

Manca una architettura che ponga delle convenzioni su come eseguire<br />

l’author<strong>in</strong>g <strong>di</strong> questi dati.<br />

Semantic Web Stack<br />

(lower levels)<br />

HTTP<br />

Apache Apache<br />

Web Web Servers Servers<br />

Underly<strong>in</strong>g Web systems<br />

Data Interchange:<br />

RDF<br />

MS MS IIS IIS<br />

Ontology: OWL<br />

URI / IRI<br />

SQL SQL<br />

databases<br />

XML<br />

HTTP + SOAP FTP, F<strong>il</strong>e, smtp ...<br />

Java Java<br />

Conta<strong>in</strong>ers Conta<strong>in</strong>ers<br />

Figura 1.3: Come <strong>il</strong> Semantic Web si costruisce sulle attuali strutture Web<br />

Gli standard <strong>per</strong> i Web Service coprono aspetti <strong>di</strong> programmazione, favoriscono<br />

l’<strong>in</strong>tero<strong>per</strong>ab<strong>il</strong>ità soprattutto tra sistemi e l<strong>in</strong>guaggi <strong>di</strong>versi, ma spesso<br />

ogni sv<strong>il</strong>uppatore sceglie una sua soluzione <strong>per</strong> affrontare <strong>il</strong> problema <strong>di</strong> come<br />

rappresentare le risorse. I Web service <strong>in</strong> quanto ad author<strong>in</strong>g mancano delle<br />

Convention over Configuration che fornirebbero ai programmatori elementi<br />

comuni da ut<strong>il</strong>izzare <strong>per</strong> rendere i sistemi maggiormente <strong>in</strong>tero<strong>per</strong>ab<strong>il</strong>i.<br />

10


Web Of Data Infrastruttura del Web <strong>di</strong> dati<br />

Eppure l’<strong>in</strong>teresse che <strong>il</strong> REST sta riscuotendo, al <strong>di</strong> la <strong>di</strong> tutti i benefici<br />

conclamati, non è altro che una richiesta da parte del mondo dei programmatori<br />

<strong>di</strong> qualcosa che <strong>in</strong>crementi la user ex<strong>per</strong>ience ma che fondamentalmente<br />

sia semplice da usare così come è lo stato HTTP.<br />

Il Web semantico suggerisce cosa si potrà fare. Abbiamo visto che un<br />

passo <strong>in</strong>terme<strong>di</strong>o è <strong>il</strong> Web of Data, e che questo ha senso <strong>di</strong> esistere anche<br />

senza <strong>il</strong> primo. Ma ancora non esiste una architettura che favorisca <strong>il</strong> cambio<br />

del modo <strong>di</strong> concepire <strong>il</strong> Web, e i nuovi standard non trattano questo<br />

argomento. Ognuno implementa una sua soluzione, sebbene l’author<strong>in</strong>g <strong>di</strong><br />

<strong>in</strong>formazioni oggigiorno sia un pattern consolidato, grazie anche alla vasta<br />

<strong>di</strong>ffusione dei <strong>di</strong>versi Content Management System. Sistemi <strong>di</strong> controllo <strong>di</strong><br />

versione e <strong>di</strong> gestione del lavoro collaborativo hanno <strong>per</strong>messo la nascita <strong>di</strong><br />

alcuni dei maggiori elementi <strong>di</strong> <strong>in</strong>teresse del recente Web, prima fra tutti<br />

l’es<strong>per</strong>ienza <strong>in</strong>novativa <strong>di</strong> Wikipe<strong>di</strong>a. Abbiamo <strong>per</strong>ò visto che non è proponib<strong>il</strong>e<br />

l’adozione <strong>di</strong> soluzioni ra<strong>di</strong>cali, qu<strong>in</strong><strong>di</strong> serve qualcosa che possa s<strong>il</strong>entemente<br />

immettersi nel panorama attuale. Probab<strong>il</strong>mente <strong>il</strong> Web Semantico<br />

stenta a farsi vedere sul panorama attuale proprio <strong>per</strong>chè si sta aspettando<br />

che l’evoluzione naturale selezioni le giuste convenzioni.<br />

La JCR 3 è una tecnologia che si sp<strong>in</strong>ge <strong>in</strong> questa <strong>di</strong>rezione: è una API<br />

che ab<strong>il</strong>ita lo sv<strong>il</strong>uppo <strong>di</strong> applicazioni orientate ai contenuti. Fornisce dei<br />

meto<strong>di</strong> <strong>per</strong> l’author<strong>in</strong>g <strong>di</strong> dati e si basa su un layer <strong>di</strong> astrazione che agevola<br />

l’<strong>in</strong>tero<strong>per</strong>ab<strong>il</strong>ità con sistemi legacy <strong>di</strong> vario tipo.<br />

Purtroppo la soluzione è ut<strong>il</strong>e soltanto <strong>per</strong> applicazioni Java, e sebbene<br />

possa essere rivestita con servizi Web, manca <strong>di</strong> quella generalità che ha fatto<br />

<strong>il</strong> successo dell’HTTP.<br />

Si può ipotizzare che <strong>per</strong> favorire la nascita del Web of Data sia necessario<br />

formulare anche dei Content Management System orientati ia dati, che con<strong>di</strong>vidano<br />

lo stesso modello <strong>per</strong> l’<strong>in</strong>formazione. A <strong>di</strong>fferenza <strong>di</strong> database tra<strong>di</strong>zionali,<br />

i dati gestiti da un CMS <strong>di</strong> questo tipo, saranno esposti tramite una<br />

<strong>in</strong>terfaccia sim<strong>il</strong>e ad HTTP, saranno orientati ad esprimere relazioni grazie<br />

ad RDF e supporteranno <strong>il</strong> reason<strong>in</strong>g <strong>per</strong> mezzo delle ontologie. Avranno visib<strong>il</strong>ità<br />

globale grazie all’<strong>in</strong><strong>di</strong>rizzamento ed identificazione tramite URI, supporteranno<br />

sistemi <strong>di</strong> controllo <strong>di</strong> versione, e saranno <strong>di</strong>stribuiti. Gestiranno<br />

3 Content Repository for JavaTM technology API<br />

11


Web Of Data Infrastruttura del Web <strong>di</strong> dati<br />

l’accesso e la collaborazione <strong>di</strong> utenti sparsi <strong>in</strong> tutto <strong>il</strong> mondo, e favoriranno<br />

<strong>il</strong> nascere <strong>di</strong> comunità che con i propri contributi ne aumenteranno <strong>il</strong> valore.<br />

Web of Documets<br />

<strong>in</strong>frastructures<br />

Semantic Web Stack<br />

Exist<strong>in</strong>g Document Oriented Resources<br />

Web of Data<br />

<strong>in</strong>frastructure<br />

New Pure Data<br />

Oriented Resources<br />

Figura 1.4: Semantic Web verso <strong>il</strong> Web of Data<br />

La recente evoluzione ci suggerisce <strong>di</strong> cercare una soluzione nel campo dei<br />

Web Service e delle Service Oriented Architecture (SOA) [Erl]. I pr<strong>in</strong>cipi del<br />

Representational State Transfer (REST) [Fiel<strong>di</strong>ng] sono <strong>di</strong> <strong>in</strong>teresse fondamentale<br />

poichè, anche se f<strong>in</strong>ora abbiamo parlato <strong>di</strong> dati, stiamo <strong>di</strong>scutendo<br />

<strong>di</strong> accesso a risorse. Soprattutto, qualsiasi <strong>in</strong>tervento si <strong>in</strong>serirà nel panorama<br />

attuale gradualmente, senza imporre nessun ra<strong>di</strong>cale cambiamento, ma<br />

fornedo una strada fac<strong>il</strong>e da <strong>per</strong>correre che orienterà nella stessa <strong>di</strong>rezione i<br />

progetti <strong>di</strong> sv<strong>il</strong>uppo a seguire.<br />

La figura 1.4 ipotizza come l’avvento <strong>di</strong> tali soluzioni a sostegno del Web<br />

Semantico potrebbe <strong>in</strong>serirsi nel panorama attuale, attuando <strong>il</strong> vellutato spostamento<br />

<strong>di</strong> para<strong>di</strong>gma che dal Web of Documents porterà def<strong>in</strong>itivamente<br />

alla nascita <strong>di</strong> un Web of Data a cui sia possib<strong>il</strong>e dare una def<strong>in</strong>izione.<br />

12


Capitolo<br />

2<br />

Il progetto <strong>InterDataNet</strong><br />

“...I believe that at the end of the century the use of words and<br />

general educated op<strong>in</strong>ion w<strong>il</strong>l have altered so much that one<br />

w<strong>il</strong>l be able to speak of mach<strong>in</strong>es th<strong>in</strong>k<strong>in</strong>g without expect<strong>in</strong>g to<br />

be contra<strong>di</strong>cted”<br />

Alan Tour<strong>in</strong>g, 1950<br />

Il progetto <strong>InterDataNet</strong> (IDN) nasce <strong>per</strong> venire <strong>in</strong>contro alle esigenze<br />

<strong>di</strong> collaborazione ed <strong>in</strong>tero<strong>per</strong>ab<strong>il</strong>ità che sorgono nell’affrontare le problematiche<br />

<strong>di</strong> un Web orientato ai dati. IDN propone una architettura stratificata<br />

e un modello <strong>per</strong> le <strong>in</strong>formazioni che hanno l’ambizione <strong>di</strong> poter ab<strong>il</strong>itare <strong>il</strong><br />

Web of Data grazie ad una soluzione globale che fac<strong>il</strong>iti <strong>il</strong> riut<strong>il</strong>izzo e la<br />

con<strong>di</strong>visione <strong>di</strong> risorse.<br />

I concetti fondamentali e la descrizione del suo funzionamento sono argomento<br />

<strong>di</strong> questo capitolo.


Il progetto <strong>InterDataNet</strong> Content Management nel Web of Data<br />

Nella sezione 2.1 verrà offerta una panoramica delle motivazioni e delle<br />

idee su cui è stato costruito <strong>il</strong> progetto.<br />

In 2.2 sarà <strong>il</strong>lustrata nel suo <strong>in</strong>sieme l’architettura della soluzione proposta<br />

e verrà <strong>in</strong>trodotta la Service Architecture (IDN-SA), <strong>il</strong> modello<br />

<strong>in</strong>formativo (IDN-IM) e l’<strong>in</strong>terfaccia con le applicazioni (IDN-API).<br />

Il loro funzionamento sarà approfon<strong>di</strong>to <strong>in</strong> 2.3 dove si <strong>il</strong>lustreranno i vari<br />

livelli (IDN-SI,IDN-RM,IDN-IH e IDN-VR), i servizi <strong>per</strong> i nomi (LS ed<br />

LDNS) ed i concetti <strong>di</strong> applicazione IDN, documento IDN e Primitive<br />

Data Unit.<br />

La sezione 2.4 <strong>in</strong>f<strong>in</strong>e effettuerà una proiezione IDN nel contesto del Web<br />

e del Web of Data.<br />

2.1 Content Management nel Web of Data<br />

Il network<strong>in</strong>g globale rafforza <strong>il</strong> bisogno <strong>di</strong> rendere le risorse riut<strong>il</strong>izza<strong>il</strong>i tra<br />

<strong>per</strong>sone, comunità ed organizzazioni sparse <strong>in</strong> tutto <strong>il</strong> mondo, ed <strong>in</strong> previsione<br />

<strong>di</strong> un Web Semantico questa esigenza si fa più forte.<br />

Tuttavia molta della letteratura <strong>in</strong>torno al web semantico ruota su problemi<br />

<strong>di</strong> <strong>in</strong>ferenza, mach<strong>in</strong>e learn<strong>in</strong>g e gestione delle ontologie. Il problema<br />

dell’author<strong>in</strong>g collaborativo delle <strong>in</strong>formazioni ancora non è stato affrontato<br />

seriamente, ed <strong>il</strong> Web Semantico stenta a decollare.<br />

Uno dei pr<strong>in</strong>cipali ostacoli allo sv<strong>il</strong>uppo è dovuto al fatto che l’es<strong>per</strong>ienza<br />

semantica rimane spesso conf<strong>in</strong>ata a livello locale. L’<strong>in</strong>formatica <strong>di</strong> oggi <strong>in</strong>vece<br />

chiede soluzioni <strong>di</strong>stribuite, e progettare sistemi che possano funzionare <strong>in</strong><br />

rete non è <strong>per</strong> niente fac<strong>il</strong>e. Ci vuol poco <strong>per</strong> scambiare qualche dato attraverso<br />

HTTP, ma mettere <strong>in</strong> pie<strong>di</strong> una architettura completa è un’altra cosa:<br />

la <strong>di</strong>scipl<strong>in</strong>a dei sistemi <strong>di</strong>stribuiti tra computer e <strong>per</strong>sone, è una delle più<br />

<strong>in</strong>teressanti ed allo stesso tempo è una delle sfide più <strong>di</strong>ffic<strong>il</strong>i della moderna<br />

Information Technology.<br />

Nei prossimi paragrafi verranno brevemente <strong>di</strong>scussi concetti fondamentali<br />

<strong>per</strong> porre delle solide basi all’author<strong>in</strong>g nel mondo a cui <strong>il</strong> Web of Data<br />

appartiene: quello dei sistemi <strong>di</strong>stribuiti.<br />

2.1.1 Nam<strong>in</strong>g and Data Addressab<strong>il</strong>ity<br />

È necessario <strong>in</strong><strong>di</strong>care le risorse. Serve poterlo fare <strong>per</strong>chè vogliamo essere<br />

<strong>in</strong> grado <strong>di</strong> venire a conoscenza <strong>di</strong> una <strong>in</strong>formazione, poterla mo<strong>di</strong>ficare,<br />

14


Il progetto <strong>InterDataNet</strong> Content Management nel Web of Data<br />

copiarla o stamparla e <strong>per</strong> eseguire queste o<strong>per</strong>azioni dobbiamo essere <strong>in</strong><br />

grado <strong>di</strong> <strong>in</strong><strong>di</strong>care al calcolatore la risorsa che ci <strong>in</strong>teressa. Ma non basta,<br />

spesso possiamo anche avere necessità <strong>di</strong> passare <strong>in</strong>formazioni a qualcuno,<br />

qu<strong>in</strong><strong>di</strong> è necessario che <strong>il</strong> modo <strong>in</strong> cui la risorsa viene recu<strong>per</strong>ata possa anche<br />

essere compreso da essere umani e che <strong>per</strong> entrambi esista un modo comune<br />

ed uniforme <strong>per</strong> specificare senza ambiguità le modalità <strong>di</strong> recu<strong>per</strong>o dei dati<br />

<strong>di</strong> <strong>in</strong>teresse.<br />

Serve qu<strong>in</strong><strong>di</strong> un nome ed un sistema <strong>di</strong> nam<strong>in</strong>g <strong>di</strong>stribuito. Un nome<br />

è una str<strong>in</strong>ga <strong>di</strong> caratteri usata <strong>per</strong> riferirsi a un’entità. Per o<strong>per</strong>are su <strong>di</strong><br />

essa è necessario un punto d’accesso, anche esso dotato <strong>di</strong> nome che si<br />

def<strong>in</strong>isce <strong>in</strong><strong>di</strong>rizzo [TanenbaumSteen]. In generale, una entità può avere<br />

più <strong>di</strong> un punto <strong>di</strong> accesso, si pensi <strong>per</strong> esempio ad una <strong>per</strong>sona che ha più<br />

numeri <strong>di</strong> telefono al quale contattarla. È necessario che <strong>il</strong> sistema <strong>di</strong> nomi sia<br />

separato dal meccanismo <strong>di</strong> accesso poichè le risorse spesso cambiano la loro<br />

collocazione ma si deve poter cont<strong>in</strong>uare a chiamarle ugualmente: ad esempio<br />

un cellulare può essere smarrito ma la compagnia telefonica ci fornirà una<br />

scheda grazie alla quale essere contattati usando lo stesso vecchio numero. Un<br />

nome <strong>in</strong> un sistema <strong>di</strong> questo tipo è detto <strong>in</strong><strong>di</strong>pendente dalla posizione.<br />

Quando <strong>il</strong> nome fornisce <strong>in</strong>formazioni sul punto <strong>di</strong> accesso ad una entità,<br />

è importante considerare la questione della sua unicità. Ad esempio se una<br />

entità ha più <strong>di</strong> un <strong>in</strong><strong>di</strong>rizzo, può non essere chiaro quale debba essere usato.<br />

I nomi, quando sono usati <strong>per</strong> identificare univocamente un’entità sono<br />

detti identificatori e sono caratterizzati dai seguenti aspetti:<br />

• ad ogni nome è associata al massimo una entità<br />

• ogni entità è referenziata al massimo da un identificatore<br />

• un identificatore si riferisce sempre alla stessa entità (cioè non è mai<br />

riusato)<br />

Gli identificatori si usano pr<strong>in</strong>cipalmente <strong>per</strong> riferisi ad una entità <strong>in</strong> modo<br />

non ambiguo.<br />

Oltre a nomi che <strong>in</strong><strong>di</strong>rizzano e nomi che identificano, esistono i nomi <strong>di</strong><br />

tipo Human Friendly Name (HFN). Hanno come scopo pr<strong>in</strong>cipale l’essere<br />

usati da <strong>per</strong>sone la dove gli <strong>in</strong><strong>di</strong>rizzi o gli identificatori <strong>in</strong> formato macch<strong>in</strong>a<br />

15


Il progetto <strong>InterDataNet</strong> Content Management nel Web of Data<br />

abbiano una forma non imme<strong>di</strong>atamente comprensib<strong>il</strong>e, come ad esempio <strong>il</strong><br />

l<strong>in</strong>guaggio b<strong>in</strong>ario. I nomi dei f<strong>il</strong>e ed i nomi del DNS sono i più <strong>di</strong>ffusi esempi<br />

<strong>di</strong> HFN.<br />

Il nome usato nel Web è quello degli Uniform Resource Identifier<br />

(URI). Gli URI, <strong>in</strong> senso lato, forniscono funzioni <strong>per</strong> identificare le risorse<br />

<strong>in</strong> modo “amichevole” <strong>per</strong> gli esseri umani. Questi comprendono come sotto<strong>in</strong>sieme<br />

gli Uniform Resource Locator (URL): gli URL sono URI che<br />

oltre a identificare amichevolmente le risorse, ne specificano anche <strong>il</strong> punto<br />

<strong>di</strong> accesso.<br />

Sebbene siano nati <strong>per</strong> le pag<strong>in</strong>e web, non ci sono contro<strong>in</strong><strong>di</strong>cazioni ad<br />

ut<strong>il</strong>izzare URI <strong>per</strong> chiamare, <strong>in</strong><strong>di</strong>rizzare ed identificare parti più piccole <strong>di</strong><br />

un documento, qu<strong>in</strong><strong>di</strong> sono ottimi can<strong>di</strong>dati <strong>per</strong> rimanere protagonisti anche<br />

<strong>in</strong> un Web orientato ai dati. Tuttavia è standar<strong>di</strong>zzato <strong>in</strong><strong>di</strong>care una pag<strong>in</strong>a<br />

attraverso un URL, ma non esiste nessuno standard da adottare quando si<br />

trattano <strong>in</strong>formazioni a grana più f<strong>in</strong>e <strong>di</strong> una pag<strong>in</strong>a.<br />

Ci sono pareri <strong>di</strong>scordanti su come ut<strong>il</strong>izzare path, query e fragment dello<br />

schema <strong>di</strong> un URI [RFC3986] <strong>per</strong> chiamare, <strong>in</strong><strong>di</strong>rizzare ed identificare <strong>in</strong>formazioni,<br />

e oggi si adottano soluzioni locali ad-hoc che rendono <strong>di</strong>fficoltosa<br />

l’<strong>in</strong>terazione tra sistemi.<br />

Spesso i meto<strong>di</strong> si equivalgono, e ad oggi è importante trovare un modo<br />

uniforme <strong>per</strong> regolare l’esposizione dei dati.<br />

2.1.2 Data Replication<br />

Una politica <strong>di</strong> replicazione dei dati consiste <strong>in</strong> regole adottate <strong>in</strong> un<br />

sistema <strong>in</strong>formatico <strong>per</strong> gestire duplicati <strong>di</strong> risorse. Per motivi <strong>di</strong> efficienza<br />

e/o <strong>per</strong> motivi <strong>di</strong> affidab<strong>il</strong>ità, <strong>in</strong> un sistema <strong>di</strong>stribuito potrebbe essere<br />

conveniente o necessario non limitarsi a mantenere una sola copia delle<br />

<strong>in</strong>formazioni.<br />

L’esistenza <strong>di</strong> più repliche ci <strong>per</strong>mette ad esempio <strong>di</strong> prevenire l’<strong>in</strong>accessib<strong>il</strong>ità<br />

alle <strong>in</strong>formazioni qualora un problema <strong>di</strong> rete, un crash <strong>di</strong> sistema<br />

o un guasto rendano un server irraggiungib<strong>il</strong>e. Se <strong>in</strong>fatti vi sono più fonti<br />

dalle quali poter re<strong>per</strong>ire la stessa <strong>in</strong>formazione, se una <strong>di</strong> queste non funziona<br />

possiamo provare con un’altra. Le probab<strong>il</strong>ità <strong>di</strong> fallire l’accesso ad una<br />

16


Il progetto <strong>InterDataNet</strong> Content Management nel Web of Data<br />

risorsa <strong>di</strong>m<strong>in</strong>uiscono con l’aumentare del numero <strong>di</strong> copie <strong>di</strong>ffuse nel sistema.<br />

Una buona politica <strong>di</strong> repliche può rendere più fac<strong>il</strong>e la gestione dei backup<br />

ed <strong>in</strong> caso <strong>di</strong> corruzione <strong>di</strong> dati, ut<strong>il</strong>izzando meccanismi come i cheksum 1 ,<br />

è possib<strong>il</strong>e prevenire la <strong>per</strong><strong>di</strong>ta <strong>di</strong> <strong>in</strong>formazioni identificando la risorsa non<br />

valida e risanarla con una copia <strong>in</strong>tegra.<br />

Più copie, o più <strong>in</strong> generale, più fonti dalle quali att<strong>in</strong>gere <strong>in</strong>formazioni<br />

migliorano le prestazioni <strong>per</strong> due motivi: posizionando una copia vic<strong>in</strong>o al<br />

processo che la usa <strong>di</strong>m<strong>in</strong>uisce <strong>il</strong> tempo <strong>di</strong> accesso (si pensi ad una struttura<br />

che offre servizi <strong>in</strong> tutto <strong>il</strong> mondo e che posiziona server <strong>di</strong> replica <strong>in</strong> ogni nazione<br />

<strong>per</strong> questo motivo). Ma anche <strong>in</strong> una rete locale può essere conveniente<br />

avere più server s<strong>in</strong>cronizzati tra <strong>di</strong> loro e che si <strong>di</strong>vidono <strong>il</strong> carico <strong>di</strong> lavoro.<br />

Più <strong>in</strong> generale, la replica <strong>per</strong>mette <strong>di</strong> risolvere problemi <strong>di</strong> scalab<strong>il</strong>ità.<br />

La trasparenza alla replica è <strong>il</strong> nascondere all’utente l’esistenza <strong>di</strong> più<br />

copie <strong>di</strong> una risorsa. Ad esempio è trasparente <strong>il</strong> meccanismo con cui un browser<br />

Web mantiene una replica nella cache <strong>per</strong> migliorare l’efficienza <strong>in</strong> caso<br />

<strong>di</strong> un accesso ripetuto alla stessa risorsa, mentre <strong>in</strong>vece non lo è <strong>il</strong> masterizzare<br />

una copia <strong>di</strong> backup, se non altro <strong>per</strong>chè comporta almeno che l’utente<br />

si prenda cura fisicamente <strong>di</strong> riporre <strong>il</strong> compact <strong>di</strong>sc <strong>in</strong> un luogo sicuro.<br />

Per ottenere la trasparenza alle repliche qu<strong>in</strong><strong>di</strong> ogni copia agli occhi dell’utente<br />

ha lo stesso nome e lo stesso identificatore. Di conseguenza è necessario<br />

che sia trasparente anche l’ubicazione, ovvero non è possib<strong>il</strong>e <strong>per</strong> un utente<br />

<strong>in</strong><strong>di</strong>care dove la risorsa sia collocata fisicamente.<br />

Se non fosse così l’utente prendendo coscienza dei luoghi fisici <strong>in</strong> cui le<br />

repliche risiedono, vedrebbe che esse sono più <strong>di</strong> una.<br />

Ut<strong>il</strong>izzando meccanismi <strong>di</strong> replicazione dei dati si accetta <strong>il</strong> compromesso<br />

<strong>di</strong> dover affrontare i problemi che ci sono <strong>per</strong> mantenere e garantire la loro<br />

consistenza. Quando viene mo<strong>di</strong>ficata una copia, questa <strong>di</strong>venta <strong>di</strong>versa<br />

dalle altre ed è necessario un meccanismo che le possa aggiornare o <strong>in</strong>validare.<br />

Ad esempio quando si accede ad una pag<strong>in</strong>a Web che ha contenuti che<br />

variano con molta frequenza, si pensi ad esempio ad un sito <strong>di</strong> <strong>in</strong>formazioni<br />

giornalistiche, è necessario gestire la consistenza della cache. Se l’orig<strong>in</strong>ale<br />

1 Checksum, tradotto letteralmente significa somma <strong>di</strong> controllo. È una sequenza <strong>di</strong> bit<br />

che viene ut<strong>il</strong>izzata <strong>per</strong> verificare l’<strong>in</strong>tegrità <strong>di</strong> un dato o <strong>di</strong> un messaggio che può subire<br />

alterazioni.<br />

17


Il progetto <strong>InterDataNet</strong> Content Management nel Web of Data<br />

viene aggiornata la copia locale dovrà essere <strong>in</strong>validata e ricaricata al prossimo<br />

accesso. Il protocollo HTTP ha delle funzionalità che <strong>per</strong>mettono <strong>di</strong><br />

gestire la cache <strong>in</strong> queste situazioni, ma a causa delle <strong>di</strong>fficoltà implementative<br />

(spesso i documenti ed i siti sono creati senza alcuna considerazione<br />

<strong>di</strong> questi aspetti) capita spesso <strong>di</strong> trovarci <strong>in</strong> situazioni <strong>in</strong> cui è necessario<br />

un refresh forzato da parte dell’utente <strong>per</strong> ottenere l’ultimo aggiornamento<br />

(col rischio <strong>di</strong> non accorgersi della sua esistenza). Oppure capita <strong>il</strong> contrario,<br />

cioè la risorsa viene trasferita completamente ogni volta che viene ut<strong>il</strong>izzata<br />

anche se non è cambiata.<br />

Esistono <strong>di</strong>versi modelli <strong>per</strong> gestire la consistenza, ed <strong>in</strong> genere si accettano<br />

dei compromessi, come ad esempio accettare che la copia che stiamo<br />

ut<strong>il</strong>izzando potrebbe non essere la più aggiornata, <strong>per</strong> b<strong>il</strong>anciare i benefici<br />

con l’aumento della complessità.<br />

Quando deci<strong>di</strong>amo se ricorrere a meccanismi <strong>di</strong> replicazione si deve <strong>in</strong>f<strong>in</strong>e<br />

tener conto, <strong>per</strong> <strong>il</strong> b<strong>il</strong>ancio f<strong>in</strong>ale, degli effetti negativi sulle prestazioni <strong>in</strong> caso<br />

<strong>di</strong> mo<strong>di</strong>fica, dovuti alla necessità <strong>di</strong> propagare l’o<strong>per</strong>azione ad ogni replica<br />

esistente, e anche del costo richiesto <strong>in</strong> term<strong>in</strong>i <strong>di</strong> spazio <strong>per</strong> memorizzare<br />

tutte le copie.<br />

Nel progettare <strong>in</strong>frastrutture <strong>per</strong> l’author<strong>in</strong>g nel Web orientato ai dati è<br />

qu<strong>in</strong><strong>di</strong> preferib<strong>il</strong>e poter pianificare f<strong>in</strong> dalle prime fasi se è necessario adottare<br />

una politica <strong>di</strong> replicazione e con quale modalità. Bisogna tener conto<br />

che potrebbe essere impossib<strong>il</strong>e <strong>in</strong>serire <strong>in</strong> un sistema avviato delle soluzioni<br />

avanzate <strong>per</strong> la gestione della consistenza.<br />

2.1.3 Version<strong>in</strong>g<br />

Il controllo <strong>di</strong> versione è la gestione <strong>di</strong> versioni multiple <strong>di</strong> un <strong>in</strong>sieme<br />

<strong>di</strong> <strong>in</strong>formazioni usato soprattutto nello sv<strong>il</strong>uppo <strong>di</strong> progetti <strong>in</strong>formatici o<br />

<strong>in</strong>gegneristici <strong>per</strong> controllare l’evoluzione dei documenti. È usato <strong>per</strong> organizzare<br />

<strong>il</strong> lavoro quando le specifiche del progetto <strong>di</strong>pendono da una squadra<br />

<strong>di</strong> <strong>per</strong>sone, e cosiste pr<strong>in</strong>cipalmente nell’assegnare ai documenti un numero<br />

o una etichetta <strong>di</strong> versione allo stato che questi assumono a seguito <strong>di</strong><br />

mo<strong>di</strong>fiche.<br />

Le mo<strong>di</strong>fiche apportate vengono tracciate e si parla <strong>di</strong> revisione <strong>di</strong> un<br />

progetto <strong>per</strong> <strong>in</strong><strong>di</strong>care l’evoluzione dell’<strong>in</strong>sieme <strong>di</strong> documenti. Le tecniche <strong>di</strong><br />

18


Il progetto <strong>InterDataNet</strong> Content Management nel Web of Data<br />

controllo <strong>di</strong> versione aiutano a gestire l’<strong>in</strong>tegrazione ed <strong>il</strong> conflitto dei<br />

documenti tra più utenti, <strong>in</strong> particolare una numerazione progressiva agevola<br />

<strong>il</strong> procedere a ritroso quando <strong>il</strong> progetto si trova davanti a vicoli ciechi.<br />

Esistono <strong>di</strong>versi modelli <strong>per</strong> la gestione del controllo <strong>di</strong> versione [Ch<strong>in</strong>i05]<br />

ed <strong>in</strong> generale si <strong>di</strong>fferenziano <strong>in</strong> base allo schema adottato <strong>per</strong> enumerare le<br />

revisioni.<br />

Le ultime tecniche <strong>per</strong>mettono una gestione del branch<strong>in</strong>g, ovvero lo sv<strong>il</strong>uppo<br />

parallelo <strong>di</strong> un progetto quando due o più parti si curano dell’evolvere<br />

<strong>di</strong> aspetti <strong>di</strong>versi, e fac<strong>il</strong>itano <strong>il</strong> merge ovvero <strong>il</strong> ricongiungimento del lavoro<br />

svolto dai <strong>di</strong>versi gruppi.<br />

Sebbene <strong>in</strong> l<strong>in</strong>ea <strong>di</strong> pr<strong>in</strong>cipio si possa parlare <strong>di</strong> controllo <strong>di</strong> versione anche<br />

dove la progettazione avviene con documenti cartacei, è nel CAD 2 che<br />

<strong>il</strong> version<strong>in</strong>g ha avuto <strong>di</strong>ffusione ed è grazie all’aus<strong>il</strong>io <strong>di</strong> appositi strumenti<br />

<strong>in</strong>formatici che si possono apprezzare i benefici maggiori <strong>per</strong> l’organizzazione<br />

<strong>di</strong> un progetto. I <strong>di</strong>versi tool ut<strong>il</strong>izzano modelli <strong>di</strong> versionamento <strong>di</strong>fferenti<br />

[Ch<strong>in</strong>i05] e grazie a repository comuni accessib<strong>il</strong>i tramite reti <strong>in</strong>formatiche<br />

agevolano la collaborazione e la coor<strong>di</strong>nazione dei gruppi <strong>di</strong> lavoro.<br />

Sebbene sia stato ut<strong>il</strong>izzato prevalentemente nel campo della progettazione<br />

<strong>di</strong> software, <strong>il</strong> version<strong>in</strong>g si sta estendendo oggigiorno nel campo della<br />

gestione documentale e dell’author<strong>in</strong>g concorrente. In questi campi è<br />

<strong>di</strong> <strong>in</strong>teresse soprattutto la possib<strong>il</strong>ità <strong>di</strong> ottenere la tracciab<strong>il</strong>ità delle mo<strong>di</strong>fiche<br />

effettuate dai <strong>di</strong>versi utenti e <strong>di</strong> consultarne la storia ovvero la sequenza<br />

<strong>di</strong> stati <strong>in</strong> cui i documenti si sono trovati dal momento <strong>in</strong> cui sono stati posti<br />

sotto controllo.<br />

Ad esempio, questi aspetti sono particolarmente <strong>in</strong>teressanti <strong>per</strong> <strong>il</strong> campo<br />

dell’<strong>in</strong>formatica giuri<strong>di</strong>ca [Paolucci06]: gli strumenti <strong>di</strong> controllo agevolerebbero<br />

l’organizzazione degli atti che ancora oggi sono legati a documenti<br />

prevalentemente cartacei.<br />

Ma non solo: alla base del successo <strong>di</strong> Wikipe<strong>di</strong>a 3 , l’enciclope<strong>di</strong>a libera<br />

del Web, c’è <strong>il</strong> suo sistema <strong>di</strong> controllo <strong>di</strong> versione che ha <strong>per</strong>messo anche ad<br />

utenti anonimi <strong>di</strong> contribuire ai contenuti. Grazie alla tracciab<strong>il</strong>ità ed allo<br />

storico è <strong>in</strong>fatti possib<strong>il</strong>e riprist<strong>in</strong>are i documenti la dove un <strong>in</strong>tervento <strong>di</strong> un<br />

2 Computer Aided Design ovvero Progettazione Assistita dal Calcolatore<br />

3 http://www.wikipe<strong>di</strong>a.org<br />

19


Il progetto <strong>InterDataNet</strong> Content Management nel Web of Data<br />

utente non competente o male <strong>in</strong>tenzionato abbia compromesso la veri<strong>di</strong>cità<br />

<strong>di</strong> una voce.<br />

Nell’author<strong>in</strong>g orientato ai dati, l’ut<strong>il</strong>izzo <strong>di</strong> meccanismi <strong>di</strong> versionameto<br />

risulta qu<strong>in</strong><strong>di</strong> un elemento davvero <strong>in</strong>teressante: agevola la collaborazione e<br />

fac<strong>il</strong>ita l’apporto <strong>di</strong> contributi, e come abbiamo visto questa è una delle chiavi<br />

che ha reso possib<strong>il</strong>e <strong>il</strong> successo <strong>di</strong> molti dei servizi <strong>di</strong> social network<strong>in</strong>g famosi<br />

nel Web 2.0. Inoltre apre la strada <strong>per</strong> la creazione <strong>di</strong> servizi nel campo<br />

dell’e-Government.<br />

Così come <strong>per</strong> la gestione delle repliche, <strong>il</strong> controllo <strong>di</strong> versione è un<br />

elemento da considerare nella pianificazione <strong>di</strong> una architettura <strong>per</strong> <strong>il</strong> Web<br />

of Data.<br />

2.1.4 Data Access Control<br />

Per eseguire alcune o<strong>per</strong>azioni su specifiche risorse è necessario essere<br />

<strong>in</strong> possesso della corretta autorizzazione. Non si può accedere alla casella<br />

<strong>di</strong> posta elettronica <strong>di</strong> chiunque si voglia, non si può scaricare f<strong>il</strong>e se non si<br />

accettano le con<strong>di</strong>zioni a cui è sottoposto <strong>il</strong> loro ut<strong>il</strong>izzo, non si può cancellare<br />

un documento - solitamente - se questo non ci appartiene.<br />

Il controllo degli accessi è la verifica dei priv<strong>il</strong>egi d’accesso ad una<br />

risorsa o ad un servizio, al seguito della quale <strong>il</strong> sistema fornisce o nega<br />

l’autorizzazione al suo ut<strong>il</strong>izzo. Il controllo degli accessi <strong>in</strong>sieme ad’autenticazione,<br />

alla <strong>in</strong>staurazione <strong>di</strong> un canale sicuro e all’au<strong>di</strong>t<strong>in</strong>g, rientra tra gli<br />

aspetti pr<strong>in</strong>cipali della gestione della sicurezza <strong>in</strong> un sistema <strong>di</strong>stribuito<br />

[TanenbaumSteen].<br />

Un canale sicuro protegge mittenti e dest<strong>in</strong>atari dalle <strong>in</strong>tercettazioni,<br />

dalle alterazioni e dalle contraffazioni dai messaggi. È strettamente correlato<br />

al concetto <strong>di</strong> autenticazione: non ha importanza conoscere con certezza<br />

chi è <strong>il</strong> mittente <strong>di</strong> un messaggio se non si può essere certi dell’<strong>in</strong>tegrità <strong>di</strong><br />

quest’ultimo.<br />

L’autenticazione è la verifica dell’identità <strong>di</strong>chiarata da un utente, da<br />

un client, da un server, <strong>di</strong> un host o da altre entità <strong>di</strong> un sistema. Il meccanismo<br />

più comune <strong>per</strong> assicurare l’autenticazione è la password, ovvero una<br />

chiave comune, segreta, conosciuta soltanto dalle due parti comunicanti. La<br />

password prevede che avvenga una registrazione tra le due parti, <strong>di</strong>retta<br />

20


Il progetto <strong>InterDataNet</strong> Content Management nel Web of Data<br />

o <strong>in</strong><strong>di</strong>retta, ma <strong>in</strong> un sistema complesso ciò può non rappresentare la via<br />

migliore. Per offrire la scalab<strong>il</strong>ità è necessaria l’adozione <strong>di</strong> un meccanismo<br />

evoluto <strong>per</strong> la concessione delle autorizzazioni, qualcosa che <strong>per</strong>metta l’autorizzazione<br />

tramite delega <strong>di</strong> terze parti e l’autenticazione tra <strong>di</strong>fferenti dom<strong>in</strong>i<br />

<strong>di</strong> appartenenza.<br />

L’au<strong>di</strong>t<strong>in</strong>g è <strong>il</strong> tener traccia delle o<strong>per</strong>azioni che vengono svolte da una<br />

entità autenticata. Sebbene non fornisca una vera protezione contro le m<strong>in</strong>acce,<br />

questo meccanismo <strong>per</strong>mette l’analisi delle falle <strong>di</strong> sicurezza e talvolta<br />

<strong>di</strong> risolvere i problemi verificatisi <strong>in</strong> seguito ad attacchi 4 .<br />

Subject<br />

O<strong>per</strong>ation Request Authorized Request<br />

Reference<br />

Monitor<br />

Object<br />

Figura 2.1: Modello generale <strong>per</strong> <strong>il</strong> controllo dell’accesso agli oggetti<br />

Quando <strong>il</strong> sistema tratta risorse è fondamentale <strong>il</strong> controllo degli accessi. Il<br />

modello generale <strong>per</strong> <strong>il</strong> controllo degli accessi <strong>in</strong> figura 2.1 comprende un soggetto,<br />

un oggetto ed un reference monitor [TanenbaumSteen]. Un soggetto<br />

è una entità che solleva una richiesta d’accesso ad un oggetto. Le o<strong>per</strong>azioni<br />

sono eseguite attraverso delle apposite <strong>in</strong>terfacce. La protezione contro gli accessi<br />

non autorizzati è eseguita solitamente da un apposito processo chiamato<br />

reference monitor che nel caso più semplice memorizza quale soggetto può<br />

compiere una determ<strong>in</strong>ata o<strong>per</strong>azione. Pertanto <strong>in</strong> un ambiente trusted è<br />

fondamentale che questo processo sia a prova <strong>di</strong> manomissioni.<br />

Il reference monitor ut<strong>il</strong>izza la matrice <strong>di</strong> controllo degli accessi <strong>per</strong><br />

determ<strong>in</strong>are i priv<strong>il</strong>egi <strong>di</strong> accesso. Nella matrice è memorizzato <strong>per</strong> ogni<br />

soggetto i priv<strong>il</strong>egi <strong>di</strong> cui gode su ogni oggetto. In sistemi con numerosi<br />

oggetti e soggetti, la matrice non è implementata <strong>di</strong>rettamente <strong>in</strong> memoria,<br />

ma tramite altri meto<strong>di</strong> come le ACL o liste delle possib<strong>il</strong>ità.<br />

Una Access Control List (ACL) è una lista dei priv<strong>il</strong>egi <strong>di</strong> accesso<br />

memorizzata dentro ad ogni oggetto.<br />

4 L’attacco è l’ut<strong>il</strong>izzo <strong>di</strong> una vulnerab<strong>il</strong>ità <strong>per</strong> mettere <strong>in</strong> pratica una o<strong>per</strong>azione non<br />

autorizzata<br />

21


Il progetto <strong>InterDataNet</strong> Content Management nel Web of Data<br />

Le possib<strong>il</strong>ità, o capab<strong>il</strong>ity, <strong>in</strong>vece vengono date al soggetto, ed <strong>il</strong> reference<br />

monitor gestisce la protezione alle risorse sulla loro base: la matrice <strong>di</strong><br />

controllo <strong>di</strong>viene qu<strong>in</strong><strong>di</strong> un <strong>in</strong>crocio <strong>di</strong> oggetti e capab<strong>il</strong>ity <strong>il</strong> cui numero è <strong>in</strong><br />

genere <strong>in</strong><strong>di</strong>pendente da quello dei soggetti. Le capab<strong>il</strong>ity sono paragonab<strong>il</strong>i a<br />

ticket sulla base del quale vengono dati <strong>per</strong>messi al suo detentore, ed è chiaro<br />

che risulta necessario proteggerlo da manomissioni ad esempio tramite una<br />

firma.<br />

La <strong>di</strong>fferenza fondamentale tra ACL e capab<strong>il</strong>ity è che <strong>il</strong> reference monitor<br />

<strong>in</strong> questo secondo caso non è <strong>in</strong>teressato a conoscere <strong>il</strong> soggetto della<br />

richiesta, la capab<strong>il</strong>ity è sufficiente. Questo meccanismo è importante nei<br />

sistemi <strong>di</strong>stribuiti quando le autorizzazioni devono essere eseguite tra <strong>di</strong>versi<br />

dom<strong>in</strong>i, dove non è detto che un soggetto sia conosciuto <strong>in</strong> entrambi oppure<br />

dove, anche se conosciuto, questo non possa essere autenticato.<br />

ACL e capab<strong>il</strong>ity list implementano efficientemente una matrice <strong>di</strong> controllo<br />

<strong>in</strong> quanto si ignorano tutti gli elementi vuoti con un conseguente risparmio<br />

si spazio ed elaborazione. Tuttavia le liste possono comunque crescere oltre<br />

i limiti <strong>di</strong> gestione. Un dom<strong>in</strong>io <strong>di</strong> protezione <strong>per</strong>mette <strong>di</strong> ridurre queste<br />

liste. Un dom<strong>in</strong>io <strong>di</strong> protezione è un <strong>in</strong>sieme <strong>di</strong> coppie che specificano <strong>per</strong> un dato oggetto quali o<strong>per</strong>azioni possono essere<br />

eseguite. Il controllo non viene effettuato sul soggetto autore della richiesta,<br />

ma sul dom<strong>in</strong>io <strong>di</strong> protezione. Il reference monitor qu<strong>in</strong><strong>di</strong> controlla <strong>il</strong> dom<strong>in</strong>io<br />

<strong>di</strong> protezione ed <strong>in</strong> seguito verifica se questa può essere portata a term<strong>in</strong>e.<br />

L’approccio basato su gruppi <strong>di</strong> utenti, sui certificati e sui ruoli fanno<br />

parte del controllo accessi con dom<strong>in</strong>io <strong>di</strong> protezione.<br />

Probab<strong>il</strong>mente una <strong>in</strong>frastruttura <strong>per</strong> <strong>il</strong> Web of Data dovrà supportare<br />

una politica versat<strong>il</strong>e del controllo degli accessi, ab<strong>il</strong>itando sia meccanismi<br />

più restrittivi, necessari <strong>in</strong> campi applicativi più rigorosi quali ad esempio<br />

l’e-governemet, sia meccanismi più semplici dove è preferib<strong>il</strong>e favorire<br />

User-Generated Content, e dovrà supportare meccanismi cone gli attribute<br />

certificate e la delega [TanenbaumSteen].<br />

Per l’autenticazione e la creazione <strong>di</strong> un canale sicuro può essere <strong>in</strong>vece<br />

<strong>in</strong>teressante valutare l’uso <strong>di</strong> un approccio s<strong>in</strong>gle sign-on come <strong>in</strong><br />

Kerberos [Zappia06].<br />

Inf<strong>in</strong>e potrebbe essere necessario valutare quali <strong>in</strong>terfacce esporre <strong>in</strong> caso<br />

si richieda un meccanismo <strong>di</strong> au<strong>di</strong>t<strong>in</strong>g esterno al sistema.<br />

22


Il progetto <strong>InterDataNet</strong> Content Management nel Web of Data<br />

2.1.5 The pursuit of <strong>in</strong>tero<strong>per</strong>ab<strong>il</strong>ity<br />

È molto sentita al giorno d’oggi l’esigenza <strong>di</strong> rendere le applicazioni maggiormente<br />

<strong>in</strong>tero<strong>per</strong>ab<strong>il</strong>i tra <strong>di</strong> loro. Intero<strong>per</strong>ab<strong>il</strong>ità 5 significa che due implementazioni<br />

<strong>di</strong> sistemi o componenti <strong>di</strong> due <strong>di</strong>versi produttori possono coesistere<br />

e collaborare basandosi unicamente sui reciproci servizi specificati da<br />

uno standard comune [TanenbaumSteen].<br />

È un concetto base <strong>per</strong> le ultime tendenze tecnologiche. Gli stessi Web<br />

Service sono def<strong>in</strong>iti dal World Wide Web Consortium come “[...] sistemi<br />

software progettati <strong>per</strong> supportare una <strong>in</strong>terazione macch<strong>in</strong>a-macch<strong>in</strong>a <strong>in</strong>tero<strong>per</strong>ab<strong>il</strong>e<br />

attraverso le reti” [WSArch] e le Service Oriented Architecture<br />

hanno la proprietà <strong>di</strong> High Intero<strong>per</strong>ab<strong>il</strong>ity [Josuttis] tra i requisiti<br />

pr<strong>in</strong>cipali.<br />

In senso più pratico l’<strong>in</strong>tero<strong>per</strong>ab<strong>il</strong>ità si ottiene adottando standard comuni<br />

sui quali basare i propri progetti, ma non è un obiettivo fac<strong>il</strong>e da raggiungere,<br />

soprattutto <strong>in</strong> ambito enterprise: nella maggioranza dei casi non è possib<strong>il</strong>e<br />

ricostruire da zero i sistemi esistenti e sono adottate soluzioni <strong>di</strong> conversione e<br />

traduzione <strong>di</strong> <strong>in</strong>formazioni che <strong>in</strong> alcuni casi possono essere molto complesse<br />

da implementare.<br />

Sicuramente è <strong>di</strong> aiuto uno standard affermato verso <strong>il</strong> quale convergere,<br />

e sul quale progettare nuove soluzioni. Ad esempio XML è un l<strong>in</strong>guaggio<br />

complesso da ut<strong>il</strong>izzare, ma la sua standar<strong>di</strong>zzazione ha <strong>per</strong>messo la nascita<br />

<strong>di</strong> strumenti <strong>di</strong> sv<strong>il</strong>uppo e <strong>di</strong> pratiche <strong>di</strong>ffuse e consolidate che rendono <strong>il</strong><br />

b<strong>il</strong>ancio tra vantaggi e svantaggi assai favorevole, almeno nel campo delle<br />

applicazioni <strong>di</strong>stribuite (non a caso XML è alla base degli standard su cui si<br />

basano i Web Service).<br />

L’<strong>in</strong>tero<strong>per</strong>ab<strong>il</strong>ità è una questione sp<strong>in</strong>osa <strong>per</strong> <strong>il</strong> Web of Data: la nascita e<br />

l’adozione <strong>di</strong> sistemi con questo orientamento <strong>di</strong>penderà dalla <strong>di</strong>fficoltà con<br />

cui le applicazioni esistenti potranno essere <strong>in</strong>tero<strong>per</strong>ab<strong>il</strong>i con le nuove architetture,<br />

e da come queste potranno essere <strong>in</strong>tero<strong>per</strong>ab<strong>il</strong>i con le <strong>in</strong>frastrutture<br />

esistenti.<br />

5 Il concetto è imparentato ma non va confuso con la portab<strong>il</strong>ità ovvero la capacità <strong>di</strong><br />

una applicazione <strong>di</strong> poter essere eseguita su sistemi <strong>di</strong>fferenti.<br />

23


Il progetto <strong>InterDataNet</strong> <strong>InterDataNet</strong>: una soluzione <strong>per</strong> l’<strong>in</strong>terdatawork<strong>in</strong>g<br />

2.2 <strong>InterDataNet</strong>: una soluzione <strong>per</strong> l’<strong>in</strong>terdatawork<strong>in</strong>g<br />

Figura 2.2: Il logo del progetto<br />

Per favorire l’<strong>in</strong>tero<strong>per</strong>ab<strong>il</strong>ità e la collaborazione nel mondo del Web orientato<br />

ai Dati nasce <strong>il</strong> progetto <strong>InterDataNet</strong> (IDN). Concepito nell’ambito<br />

del dottorato <strong>di</strong> “Telematica e Società dell’Informazione” presso la Facoltà <strong>di</strong><br />

Ingegneria dell’Università degli Stu<strong>di</strong> <strong>di</strong> Firenze, IDN è un reference model<br />

<strong>di</strong> una architettura <strong>per</strong> l’InterDataWork<strong>in</strong>g [MelDec00].<br />

Lo sv<strong>il</strong>uppo del progetto è <strong>in</strong> corso da alcuni anni ed attualmente la fase<br />

<strong>di</strong> progettazione è <strong>in</strong> uno sta<strong>di</strong>o avanzato. In questa fase si stanno implementando<br />

le funzionalità base con lo scopo <strong>di</strong> verificare e validare le scelte<br />

progettuali effettuate. Esiste un sito web sul quale si possono trovare <strong>in</strong>formazioni<br />

aggiornate sul progresso dei lavori. Lo potete trovare all’<strong>in</strong><strong>di</strong>rizzo<br />

http://www.<strong>in</strong>terdatanet.org.<br />

La struttura fisica e logica <strong>di</strong> IDN si basa sul concetto <strong>di</strong> stratificazione:<br />

così come Internet risolve i problemi della comunicazione <strong>in</strong> reti <strong>in</strong>terconnesse<br />

delegando agli strati la cura <strong>di</strong> aspetti specifici come <strong>il</strong> trasporto, <strong>il</strong><br />

rout<strong>in</strong>g ed <strong>il</strong> network<strong>in</strong>g [RFC1122] [Tanenbaum], <strong>InterDataNet</strong> propone l’uso<br />

<strong>di</strong> layer <strong>di</strong>fferenti <strong>per</strong> ab<strong>il</strong>itare a livello globale la collaborazione tra<br />

<strong>per</strong>sone, imprese ed organizzazioni.<br />

Questa f<strong>in</strong>alità è caratterizzata sicuramente da un forte effetto network 6 ,<br />

6 L’effetto network è una caratteristica <strong>per</strong> la quale un bene o un servizio possiedono,<br />

<strong>per</strong> un cliente potenziale, un valore che <strong>di</strong>pende dal numero <strong>di</strong> altri clienti che lo abbiano<br />

acquistato o dal numero <strong>di</strong> utenti del servizio. http://en.wikipe<strong>di</strong>a.org/wiki/<br />

Network_effect<br />

24


Il progetto <strong>InterDataNet</strong> <strong>InterDataNet</strong>: una soluzione <strong>per</strong> l’<strong>in</strong>terdatawork<strong>in</strong>g<br />

<strong>InterDataNet</strong><br />

Middleware<br />

IDN Compliant Application<br />

Virtual Repository Layer<br />

Information History Layer<br />

Replica Management Layer<br />

<strong>Storage</strong> Interface Layer<br />

F<strong>il</strong>esystem,<br />

database, etc.<br />

Generic storage<br />

architecture<br />

IDN APIs<br />

HTTP(S), SMTP(S),<br />

FTP(S), etc.<br />

Generic network<br />

communication architecture<br />

Figura 2.3: Interdatawork<strong>in</strong>g <strong>in</strong> IDN<br />

e qu<strong>in</strong><strong>di</strong> è necessaria prima <strong>di</strong> tutto l’adozione <strong>in</strong> massa <strong>di</strong> uno standard<br />

comune.<br />

Per questo motivo IDN si presenta come un modello <strong>di</strong> riferimento che può<br />

essere adottato liberamente da <strong>per</strong>sone, imprese ed organizzazioni.<br />

Tuttavia <strong>il</strong> valore <strong>in</strong>iziale <strong>di</strong> questa architettura è nei servizi che fornisce<br />

a supporto della collaborazione tra utenti <strong>in</strong> rete ed <strong>il</strong> suo progetto è passato<br />

attraverso lo stu<strong>di</strong>o delle funzionalità e dei requisti necessari <strong>per</strong> porre delle<br />

solide fondamenta.<br />

Per favorirne l’adozione e poter così raggiungere quella massa critica che<br />

giustificherebbe un suo uso ancora più <strong>di</strong>ffuso, è stata data particolare attenzione<br />

allo stu<strong>di</strong>o dell’<strong>in</strong>tegrazione con le <strong>in</strong>frastrutture del Web tra<strong>di</strong>zionale<br />

e del Web 2.0.<br />

2.2.1 Il “design pattern” della stratificazione applicato<br />

ai dati<br />

Da un certo punto <strong>di</strong> vista IDN può essere vista come un design pattern<br />

7 che descrive <strong>il</strong> modello, le <strong>in</strong>tenzioni e le motivazioni, i campi<br />

applicativi, le conseguenze, la struttura ed una implementazione <strong>di</strong><br />

riferimento <strong>di</strong> una soluzione <strong>per</strong> un Web of Data collaborativo.<br />

7 Ovvero una soluzione formale riut<strong>il</strong>izzab<strong>il</strong>e ad un problema contestualizza-<br />

to [DesignPatterns]<br />

25


Il progetto <strong>InterDataNet</strong> <strong>InterDataNet</strong>: una soluzione <strong>per</strong> l’<strong>in</strong>terdatawork<strong>in</strong>g<br />

IDN si pone l’obiettivo <strong>di</strong> fornire un Information Model con<strong>di</strong>viso ed una<br />

architettura <strong>di</strong> riferimento <strong>per</strong> la gestione <strong>di</strong> questo modello che sia capace<br />

<strong>di</strong> offrire:<br />

• l’<strong>in</strong><strong>di</strong>rizzamento globale delle risorse<br />

• un <strong>in</strong>sieme <strong>di</strong> servizi orientati alla collaborazione <strong>in</strong> sistemi <strong>di</strong>stribuiti<br />

• delle specifiche f<strong>in</strong>alizzate a garantire l’<strong>in</strong>tero<strong>per</strong>ab<strong>il</strong>ità<br />

Per descrivere i concetti, <strong>il</strong> modello e le tecnologie <strong>di</strong> IDN si <strong>in</strong>troducono<br />

tre concetti pr<strong>in</strong>cipali.<br />

IDN Compliant Application<br />

IDN APIs<br />

IDN Service Architecture (IDN-SA)<br />

Network communication<br />

and storage architecture<br />

Applications use IDN-IM to represent<br />

pieces of <strong>in</strong>formation and documents<br />

Applications <strong>in</strong>teract<br />

with IDN-IM<br />

through IDN-APIs<br />

IDN-SA implements IDN-IM<br />

Figura 2.4: I componenti <strong>di</strong> IDN<br />

IDN-IM<br />

Con <strong>il</strong> nome <strong>di</strong> IDN-IM (<strong>InterDataNet</strong> Information Model) è <strong>in</strong><strong>di</strong>cato<br />

<strong>il</strong> modello dell’<strong>in</strong>formazione alla base dell’architettura. È un modello<br />

astratto, <strong>in</strong><strong>di</strong>pendente da contesti specifici e dalle tecnologie adottate <strong>per</strong><br />

rappresentarlo. Def<strong>in</strong>isce i requisiti, le proprietà, i pr<strong>in</strong>cipi e la struttura<br />

delle <strong>in</strong>formazioni.<br />

IDN-SA (<strong>InterDataNet</strong> Service Architecture) è <strong>in</strong>vece <strong>il</strong> modello<br />

dell’architettura stratificata <strong>di</strong> IDN. È basata sui pr<strong>in</strong>cipi delle SOA,<br />

le architetture orientate ai servizi (ve<strong>di</strong> capitolo 3.1), e del REST (ve<strong>di</strong><br />

capitolo 3.3).<br />

Le <strong>in</strong>terfacce esposte da IDN-SA vengono chiamate le IDN-API (IDN<br />

Application Programm<strong>in</strong>g Interface), e <strong>per</strong>mettono lo sv<strong>il</strong>uppo <strong>di</strong> applicazioni<br />

basate sulle risorse rappresentate dall’IDN-IM. Un ruolo importante<br />

26


Il progetto <strong>InterDataNet</strong> <strong>InterDataNet</strong>: una soluzione <strong>per</strong> l’<strong>in</strong>terdatawork<strong>in</strong>g<br />

è giocato proprio dalle applicazioni: queste usano le funzionalità esposte<br />

dalle IDN-API <strong>per</strong> implementare la bus<strong>in</strong>ess logic.<br />

La figura 2.4 <strong>il</strong>lustra come questi tre aspetti <strong>in</strong>teragiscono.<br />

2.2.2 L’approccio bottom-up<br />

Per capire al meglio cosa fa IDN è ut<strong>il</strong>e esam<strong>in</strong>arla secondo l’approccio<br />

“bottom-up” 8 , ovvero dal basso verso l’alto, nel senso degli strati <strong>di</strong> ISN-SA.<br />

Si parte dal basso, dall’<strong>in</strong>terfaccia <strong>di</strong> storage, e se ne spiegano i concetti<br />

tramite passi successivi <strong>in</strong> cui servizi vengono aggiunti livello <strong>per</strong> livello.<br />

Il primo livello è lo <strong>Storage</strong> Interface (IDN-SI). Contiene un unico tipo<br />

<strong>di</strong> servizio che prende lo stesso nome del livello. La sua funzione è memorizzare<br />

<strong>in</strong>formazioni ed esporle tramite una <strong>in</strong>terfaccia uniforme. Deve rimanere<br />

semplice e deve offrire funzionalità bas<strong>il</strong>ari. Può essere visto come un servizio<br />

Resource Oriented che memorizza <strong>in</strong>formazioni e metadati a questi associati<br />

ovvero come punto <strong>di</strong> accesso ad un repository <strong>di</strong> base <strong>per</strong> una SOA. Infatti è<br />

un servizio <strong>in</strong><strong>di</strong>pendente dal resto <strong>di</strong> IDN e può essere riutlizzato <strong>in</strong> contesti<br />

<strong>in</strong> cui si hanno necessità <strong>di</strong> memorizzazazione <strong>in</strong>formazioni <strong>di</strong> questo tipo.<br />

Durante <strong>il</strong> lavoro <strong>di</strong> tesi sono stati esam<strong>in</strong>ati i possib<strong>il</strong>i casi <strong>di</strong> ut<strong>il</strong>izzo<br />

<strong>di</strong> <strong>Storage</strong> Interface Service, anche al <strong>di</strong> fuori <strong>di</strong> IDN. Nel capitolo 4 si può<br />

trovare l’analisi <strong>di</strong> questi scenari.<br />

Il punto <strong>di</strong> riferimento <strong>per</strong> IDN-SI è <strong>il</strong> Web Service Amazon Simple <strong>Storage</strong><br />

Service (S3) 9 : è un servizio Web esistente, ed ha anche un riscontro<br />

commerciale. Amazon è una compagnia americana che si de<strong>di</strong>ca al commercio<br />

elettronico. Da qualche tempo offre una serie <strong>di</strong> servizi commerciali che<br />

si basano sui Web Service, tra i quali figura anche <strong>il</strong> Simple <strong>Storage</strong> Service.<br />

Con S3, Amazon vende spazio sul Web a costi vantaggiosi ed offre garanzie<br />

<strong>di</strong> affidab<strong>il</strong>tà che possono <strong>in</strong>teressanti <strong>per</strong> alcune tipologie <strong>di</strong> clienti.<br />

Gli 800 m<strong>il</strong>ioni <strong>di</strong> risorse memorizzate nella piattaforma <strong>di</strong> Amazon a giugno<br />

del 2006 sono <strong>di</strong>ventate 5 m<strong>il</strong>iar<strong>di</strong> <strong>in</strong> apr<strong>il</strong>e del 2007, e sono raddoppiate<br />

ad ottobre dello stesso anno, con un picco <strong>di</strong> 27.601 transazioni <strong>per</strong> secondo 10 .<br />

8 L’approccio “bottom-up” è contrapposto all’approccio “top-down” nel quale IDN è<br />

spiegata ed <strong>il</strong>lustrata dall’alto<br />

9 http://s3.amazonaws.com/, ve<strong>di</strong> anche [RichardsonRuby], capitolo 3<br />

10 http://blogs.barrons.com/techtraderda<strong>il</strong>y/2007/10/18/<br />

web-20-summit-amazon-gives-update-on-web-services/<br />

27


Il progetto <strong>InterDataNet</strong> <strong>InterDataNet</strong>: una soluzione <strong>per</strong> l’<strong>in</strong>terdatawork<strong>in</strong>g<br />

La <strong>di</strong>fferenza tra S3 ed un comune servizio <strong>di</strong> Web Host<strong>in</strong>g è che Amazon<br />

vi offre spazio Web <strong>di</strong>etro l’<strong>in</strong>terfaccia <strong>di</strong> un Web Service.<br />

Per attirare l’<strong>in</strong>teresse dei possib<strong>il</strong>i clienti Amazon fornisce sia una <strong>in</strong>terfaccia<br />

SOAP sia una <strong>in</strong>terfaccia RESTful basata su HTTP. Inoltre sono<br />

<strong>di</strong>sponib<strong>il</strong>i librerie pronte <strong>per</strong> molti l<strong>in</strong>guaggi <strong>di</strong> programmazione.<br />

Ricor<strong>di</strong>amoci <strong>per</strong> un momento che <strong>il</strong> tipico servizio <strong>di</strong> host<strong>in</strong>g <strong>per</strong>mette<br />

la pubblicazione <strong>di</strong> un sito Web accessib<strong>il</strong>e <strong>in</strong> lettura con HTTP, ma solitamente<br />

è grazie ad FTP che vi si caricano sopra i contenuti. Il sito <strong>in</strong> host<strong>in</strong>g<br />

è pensato <strong>per</strong> servire pag<strong>in</strong>e Web, sebbene se ne possa fare un ut<strong>il</strong>izzo <strong>di</strong>verso.<br />

Amazon S3 è pensato <strong>per</strong> servire un Web Service, ma grazie alla sua<br />

<strong>in</strong>terfaccia RESTful può almeno <strong>in</strong> l<strong>in</strong>ea teorica, fornire documenti Web ad<br />

un Browser (questo pr<strong>in</strong>cipio <strong>di</strong> <strong>in</strong>tero<strong>per</strong>ab<strong>il</strong>ità è stato fondamentale <strong>per</strong> <strong>il</strong><br />

suo successo).<br />

Qu<strong>in</strong><strong>di</strong> adesso possiamo immag<strong>in</strong>are un servizio che ci offre funzioni <strong>di</strong> storage<br />

adottando l’<strong>in</strong>terfaccia IDN-SI: possiamo tranqu<strong>il</strong>lamente considerarlo<br />

un fratello <strong>di</strong> Amazon S3.<br />

IDN-SI tuttavia è una specifica, <strong>in</strong> particolare è una specifica libera. Permette<br />

a chiunque <strong>di</strong> sv<strong>il</strong>uppare una propria implementazione, <strong>di</strong> mettere <strong>in</strong><br />

pie<strong>di</strong> una <strong>in</strong>frastruttura hardware e <strong>di</strong> vendere spazio così come fa Amazon,<br />

ma <strong>il</strong> beneficio <strong>per</strong> gli utenti è la possib<strong>il</strong>ità <strong>di</strong> scegliere lo storage provider<br />

col miglior rapporto qualità/prezzo. In particolare è possib<strong>il</strong>e pensare anche<br />

ad implementazioni <strong>di</strong> <strong>in</strong>terfacce <strong>di</strong> storage locali, cioè da far funzionare<br />

sul proprio computer, <strong>in</strong> modo da rendere <strong>il</strong> nostro lavoro <strong>in</strong>tero<strong>per</strong>ab<strong>il</strong>e tra<br />

locale e remoto.<br />

Quest’ultimo concetto ci suggerisce <strong>il</strong> primo scal<strong>in</strong>o verso l’alto nella p<strong>il</strong>a<br />

protocollare <strong>di</strong> IDN: pren<strong>di</strong>amo l’<strong>in</strong>terfaccia <strong>di</strong> storage e ricopriamola con un<br />

servizio che offre la replica delle risorse. Abbiamo aggiunto ad IDN <strong>il</strong> livello <strong>di</strong><br />

Replica Management (IDN-RM). Grazie a questo approccio è possib<strong>il</strong>e<br />

implementare una soluzione trasparente che può gestire una <strong>di</strong>stribuzione dei<br />

contenuti con i benefici <strong>di</strong> prestazioni e scalab<strong>il</strong>ità che la replicazione apporta.<br />

Pensiamo ad esempio un servizio <strong>di</strong> replica che mantiene s<strong>in</strong>cronizzate delle<br />

copie su uno <strong>Storage</strong> Interface collocato <strong>in</strong> azienda con le copie su un <strong>Storage</strong><br />

Interface sul proprio computer.<br />

Il livello IDN-RM è composto da due servizi: <strong>il</strong> servizio <strong>di</strong> gestione delle<br />

repliche ed <strong>il</strong> servizio <strong>di</strong> localizzazione. Questa separation of concern è sug-<br />

28


Il progetto <strong>InterDataNet</strong> <strong>InterDataNet</strong>: una soluzione <strong>per</strong> l’<strong>in</strong>terdatawork<strong>in</strong>g<br />

gerita dallo st<strong>il</strong>e delle SOA. In particolare <strong>il</strong> servizio <strong>di</strong> gestione amm<strong>in</strong>istra<br />

la creazione e la <strong>di</strong>stribuzione delle copie, mentre <strong>il</strong> Localization Service<br />

gestisce le associazioni identificatore-<strong>in</strong><strong>di</strong>rizzi: esistendo più repliche <strong>di</strong><br />

una unica risorsa, <strong>per</strong> ogni identificatore esistono più <strong>in</strong><strong>di</strong>rizzi <strong>per</strong> poterla<br />

recu<strong>per</strong>are.<br />

Il passo successivo verso la collaborazione è uno strato che si occupa <strong>di</strong><br />

controllare la versione delle <strong>in</strong>formazioni. Questo compito è svolto dal layer<br />

<strong>di</strong> Information History (IDN-IH) Il servizio <strong>in</strong> questo strato <strong>in</strong>tercetta<br />

tutte le richieste <strong>di</strong> o<strong>per</strong>azioni sulle risorse e può gestire, <strong>in</strong> caso <strong>di</strong> mo<strong>di</strong>fica,<br />

una politica <strong>per</strong> <strong>il</strong> versionamento.<br />

Il controllo <strong>di</strong> versione <strong>in</strong> questo caso esula dal suo tipico ut<strong>il</strong>izzo nel<br />

campo della progettazione. Il concetto è <strong>in</strong>terpretato <strong>in</strong> senso più generale<br />

come storico <strong>di</strong> collezioni <strong>di</strong> <strong>in</strong>formazioni, e qu<strong>in</strong><strong>di</strong> può essere impiegato <strong>per</strong><br />

un blog piuttosto che <strong>per</strong> atti amm<strong>in</strong>istrativi.<br />

Lo strato f<strong>in</strong>ale <strong>in</strong>terviene <strong>per</strong> ricostruire l’<strong>in</strong>formazioni replicate e versionate<br />

presentantole agli utenti come un tutt’uno, esponendo le risorse <strong>di</strong>etro<br />

ad un servizio <strong>di</strong> autenticazione s<strong>in</strong>gle sign-on, e fornendo l’aus<strong>il</strong>io <strong>di</strong> un<br />

servizio <strong>di</strong> HFN. Questo strato viene chiamato Virtual Repository (IDN-<br />

VR). Il livello è composto da 3 servizi che curano gli aspetti <strong>di</strong> aggregazione<br />

(<strong>il</strong> Virtual Repository Service nel quale <strong>il</strong> livello si identifica), autenticazione<br />

(Authentication Service) e nam<strong>in</strong>g (servizio <strong>di</strong> LDNS). Il livello <strong>di</strong> IDN-VR<br />

espone <strong>di</strong>rettamente le IDN-API, e <strong>per</strong>tanto è anche <strong>il</strong> punto <strong>di</strong> accesso all’<strong>in</strong>tero<br />

stack <strong>di</strong> <strong>InterDataNet</strong>. In particolare <strong>il</strong> <strong>di</strong>rettore <strong>di</strong> orchestra è <strong>il</strong><br />

servizio che ha lo stesso nome del livello: è <strong>il</strong> Virtual Repository Service che<br />

gestisce la orchestration 11 dell’<strong>in</strong>tero sistema.<br />

L’idea chiave <strong>di</strong> IDN-VR è la trasparenza: <strong>il</strong> consumatore <strong>di</strong> servizi del<br />

Virtual Repository non <strong>per</strong>cepisce <strong>il</strong> sistema <strong>di</strong>stribuito che esiste al <strong>di</strong> sotto<br />

<strong>di</strong> questo.<br />

IDN-VR ricopre <strong>in</strong>f<strong>in</strong>e una posizione importante <strong>per</strong> ab<strong>il</strong>itare l’<strong>in</strong>tero<strong>per</strong>ab<strong>il</strong>ità<br />

con i sistemi esistenti, fornendo documenti che saranno usati dalle<br />

applicazioni legacy. In generale potranno essere necessarie rout<strong>in</strong>e <strong>di</strong> conver-<br />

11 In ambito SOA la orchestration è un modo <strong>di</strong> aggregare i servizi <strong>in</strong> uno nuovo che<br />

abbia un controllo centrale sul sistema [Josuttis]<br />

29


Il progetto <strong>InterDataNet</strong> Architettura tecnologica <strong>di</strong> IDN<br />

sione, ma ad esempio nel Web <strong>il</strong> servizio <strong>di</strong> virtual repository potrebbe offrire<br />

contenuti <strong>di</strong>rettamente <strong>in</strong> XML (o XHTML) ad un normale Browser Web.<br />

2.3 Architettura tecnologica <strong>di</strong> IDN<br />

Lo sv<strong>il</strong>uppo dei livelli <strong>di</strong> IDN è <strong>in</strong> corso. Nel lavoro <strong>di</strong> questa tesi gli<br />

stu<strong>di</strong> si sono concentrati sul livello <strong>in</strong>feriore ed hanno avuto come risultato la<br />

specifica del progetto ed una implementazione <strong>di</strong> riferimento <strong>per</strong> lo <strong>Storage</strong><br />

(ve<strong>di</strong> capitoli 6 e 7).<br />

Questa sezione offre una panoramica dei concetti che riguardano le tecnologie<br />

ed i vari componenti dell’architettura e ne <strong>il</strong>lustra <strong>il</strong> funzionamento.<br />

2.3.1 Core IDN-SA services<br />

Le funzionalità offerte da <strong>InterDataNet</strong> a supporto della collaborazione<br />

e dell’organizzazione delle <strong>in</strong>formazioni sono gestite grazie ad un’approccio<br />

stratificato. Nei vari strati si trovano dei servizi che hanno delle funzionalità<br />

specifiche. In questa sezione verrà esam<strong>in</strong>ato <strong>il</strong> funzionamento dei pr<strong>in</strong>cipali<br />

servizi <strong>di</strong> IDN.<br />

Servizi LDNS ed LS<br />

Il nam<strong>in</strong>g e l’<strong>in</strong><strong>di</strong>rizzamento <strong>in</strong> IDN sono gestiti da due servizi <strong>di</strong>st<strong>in</strong>ti:<br />

<strong>il</strong> Logical Doma<strong>in</strong> Name System (LDNS) ed <strong>il</strong> Localization Service<br />

(LS). Le necessità <strong>di</strong> offrire un meccanismo Human Friendly agli utenti<br />

<strong>di</strong> applicazioni, così da <strong>per</strong>mettere <strong>il</strong> riconoscimento delle risorse agli esseri<br />

umani, unita all’esigenza <strong>di</strong> gestire la <strong>di</strong>s<strong>per</strong>sione <strong>di</strong> dati duplicati <strong>per</strong> questioni<br />

<strong>di</strong> prestazioni e scalab<strong>il</strong>ità, hanno portato a formulare una soluzione su<br />

tre livelli. In particolare le funzionalità <strong>di</strong> nomenclatura, <strong>di</strong> identificazione<br />

e <strong>di</strong> <strong>in</strong><strong>di</strong>rizzamento sono state <strong>di</strong>vise, ed i due servizi gestiscono la trasformazione<br />

da una tipologia all’altra. È stato deciso <strong>di</strong> affrontare <strong>il</strong> problema<br />

<strong>di</strong>saccoppiando le funzionalità <strong>di</strong> trasformazione <strong>in</strong> due servizi separati <strong>per</strong><br />

seguire le l<strong>in</strong>ee guida delle architetture SOA.<br />

In figura 2.5 possiamo vedere <strong>il</strong>lustrato questo meccanismo.<br />

Gli utenti <strong>di</strong> IDN possono assegnare alle risorse dei nomi HFN a piacere<br />

così da poterle ut<strong>il</strong>izzare <strong>in</strong> modo più pratico. Qu<strong>in</strong><strong>di</strong> <strong>per</strong> ogni risorsa<br />

30


Il progetto <strong>InterDataNet</strong> Architettura tecnologica <strong>di</strong> IDN<br />

LDNS<br />

LS<br />

URL<br />

HFN<br />

URN<br />

HFN<br />

URL URL<br />

Figura 2.5: Il sistema dei nomi<br />

possono esistere più nomi HFN def<strong>in</strong>iti dagli utenti, ma <strong>per</strong> l’identificazione<br />

<strong>per</strong>sistente delle stesse <strong>il</strong> sistema fa uso <strong>di</strong> un’unica URN.<br />

Il servizio <strong>di</strong> LDNS gestisce le associazioni fra HFN ed URN, <strong>per</strong>mettendo<br />

agli utenti <strong>di</strong> poter recu<strong>per</strong>are l’unica URN associata ad un HFN oppure la<br />

lista <strong>di</strong> HFN che si riferiscono alla medesima URN.<br />

Data l’esistenza <strong>di</strong> più copie che replicano una risorsa, non è sufficiente<br />

l’identificazione tramite URN <strong>per</strong> potervi accedere. Qu<strong>in</strong><strong>di</strong> è necessario gestire<br />

un secondo livello <strong>di</strong> associazioni, questa volta tra URN ed un nome<br />

che <strong>per</strong>metta l’<strong>in</strong><strong>di</strong>rizzamento. In IDN ogni localizzazione avviene tramite<br />

un URL: un URL <strong>in</strong><strong>di</strong>rizza una specifica copia <strong>di</strong> una risorsa.<br />

Il servizio LS <strong>per</strong>mette al sistema <strong>di</strong> gestire la lista <strong>di</strong> URL associati ad<br />

una s<strong>in</strong>gola URN ed <strong>il</strong> proce<strong>di</strong>mento <strong>di</strong> risoluzione <strong>in</strong>versa.<br />

Il meccanismo è traparente <strong>per</strong> gli utenti, <strong>in</strong> quanto essi si troveranno a<br />

lavorare esclusivamente con HFN. Qu<strong>in</strong><strong>di</strong> dal punto <strong>di</strong> vista delle applicazioni,<br />

un HFN svolge <strong>in</strong> IDN funzioni <strong>di</strong> <strong>in</strong><strong>di</strong>rizzamento: ogni applicazione può<br />

richiedere l’accesso ad una risorsa tramite le IDN-API esposte come abbiamo<br />

visto dal Virtual Repository.<br />

È <strong>in</strong>teressante far notare come <strong>il</strong> DNS (Doma<strong>in</strong> Name System) svolga <strong>per</strong><br />

gli host <strong>in</strong> Internet funzioni anloghe alla comb<strong>in</strong>azione dei due servizi <strong>di</strong><br />

gestione dei nomi <strong>in</strong> IDN: <strong>il</strong> DNS gestisce le associazioni tra nomi ed <strong>in</strong><strong>di</strong>rizzi<br />

IP, tuttavia ad un <strong>in</strong><strong>di</strong>rizzo possono essere associati più nomi ed ad un nome<br />

più <strong>in</strong><strong>di</strong>rizzi. La gestione separata <strong>in</strong> IDN è necessaria <strong>per</strong> garantire almeno<br />

<strong>in</strong> modo astratto che ogni risorsa sia univocamente identificata.<br />

31


Il progetto <strong>InterDataNet</strong> Architettura tecnologica <strong>di</strong> IDN<br />

Servizio <strong>di</strong> Replica Management<br />

Le istanze dei servizi <strong>di</strong> replica management hanno l’<strong>in</strong>carico <strong>di</strong> gestire<br />

l’accesso concorrente alle risorse e fornire un sistema efficace <strong>di</strong> replicazione<br />

delle stesse.<br />

Da un punto <strong>di</strong> vista <strong>di</strong> coreografia 12 dei servizi, <strong>il</strong> livello IDN-RM ha come<br />

protagonista <strong>il</strong> servizio stesso <strong>di</strong> Replica Management che <strong>in</strong>teragisce con LS,<br />

con altri RM, con <strong>il</strong> livello <strong>di</strong> <strong>Storage</strong> Interface ed <strong>il</strong> livello <strong>di</strong> Information<br />

History.<br />

Information History<br />

Layer<br />

Replica Management Layer<br />

Localization<br />

Service<br />

<strong>Storage</strong> Interface Layer<br />

<strong>Storage</strong> Interface<br />

Service<br />

Information History<br />

Service<br />

Replica Management<br />

Service<br />

<strong>Storage</strong> Interface<br />

Service<br />

Replica Management<br />

Service<br />

<strong>Storage</strong> Interface<br />

Service<br />

Figura 2.6: Coreografia al livello <strong>di</strong> Replica Management<br />

I legami tra i servizi sono <strong>il</strong>lustrati <strong>in</strong> figura 2.6.<br />

La sequenza tipica degli eventi si svolge <strong>in</strong> questo modo [Grossi06]:<br />

1. Il livello su<strong>per</strong>iore <strong>in</strong>via richieste <strong>di</strong> accesso su base URN ad IDN-RM<br />

2. RM ottiene la lista degli URL che sono associati alla risorsa<br />

3. RM seleziona un URL tra quelli ricevuti secondo un qualche algoritmo<br />

4. RM richiede la risorsa alla istanza <strong>di</strong> servizio <strong>di</strong> storage che la contiene<br />

5. un messaggio <strong>di</strong> risposta viene <strong>in</strong>viato al livello su<strong>per</strong>iore<br />

12 In ambito SOA la choreography è <strong>il</strong> modo <strong>in</strong> cui i servizi sono aggregati <strong>per</strong><br />

formare i processi del bus<strong>in</strong>ess def<strong>in</strong>endone le regole e le politiche con cui i servizi<br />

collaborano [Josuttis]<br />

32


Il progetto <strong>InterDataNet</strong> Architettura tecnologica <strong>di</strong> IDN<br />

Tuttavia <strong>il</strong> livello ricopre un ruolo importante a livello <strong>di</strong> gestione delle<br />

autorizzazioni alle risorse tra organizzazioni <strong>di</strong>fferenti. È previsto che <strong>per</strong> ogni<br />

organizzazione esistano uno o più servizi <strong>di</strong> RM che hanno la responsab<strong>il</strong>ità<br />

<strong>di</strong> gestire gli accessi [Zappia06]. Infatti le risorse <strong>di</strong> storage dei livelli <strong>in</strong>feriori<br />

sono cotrollate da un servizio <strong>di</strong> replica. Qualora si presenti la necessità <strong>di</strong><br />

ottenere risorse al <strong>di</strong> fuori del proprio dom<strong>in</strong>io <strong>di</strong> responsab<strong>il</strong>ità, è prevista<br />

la comunicazione tra pari.<br />

Sono <strong>in</strong> corso <strong>di</strong> def<strong>in</strong>izione i meccanismi con i quali gestire queste <strong>in</strong>terazioni,<br />

<strong>in</strong> particolare si stanno valutando protocolli con delega e come gestire<br />

l’autenticazione cross-realm.<br />

L’altro aspetto <strong>di</strong> cui RM si cura è la politica <strong>di</strong> propagazione delle<br />

copie ovvero come e quando effettuare una replica e secondo quale modello<br />

garantire la consistenza dei dati e dell’esecuzione delle o<strong>per</strong>azioni.<br />

La def<strong>in</strong>izione <strong>di</strong> questi meccanismi è tuttora <strong>in</strong> fase <strong>di</strong> stu<strong>di</strong>o e <strong>per</strong>tanto<br />

si cosiglia <strong>di</strong> controllare <strong>il</strong> sito http://www.<strong>in</strong>terdatanet.org <strong>per</strong> ottenre<br />

<strong>in</strong>formazioni aggiornate.<br />

Servizio <strong>di</strong> Information History<br />

Nello strato <strong>di</strong> Information History troviamo un unico servizio che ha <strong>il</strong><br />

compito <strong>di</strong> fare <strong>il</strong> controllo <strong>di</strong> versione. Il servizio si chiama con lo stesso<br />

none del livello.<br />

È pensato <strong>per</strong> essere posto tra un servizio <strong>di</strong> gestione delle repliche ed uno<br />

<strong>di</strong> Virtual Repository e si comporta più che altro come un f<strong>il</strong>tro che <strong>in</strong>tercetta<br />

le o<strong>per</strong>azioni che mo<strong>di</strong>ficano le risorse, ne aumenta (o più <strong>in</strong> generale ne<br />

controlla) <strong>il</strong> numero <strong>di</strong> versione e tiene traccia memorizzando le <strong>di</strong>fferenze.<br />

Il servizio offre anche funzionalità <strong>di</strong> navigazione dello storico che non<br />

si trovano <strong>di</strong>rettamente esposte sul livello sottostante. Grazie ad IDN-IH è<br />

possib<strong>il</strong>e richiedere l’accesso ad una risorsa nello stato <strong>in</strong> cui si trovava <strong>in</strong> un<br />

momento precedente.<br />

IDN usa UEVM (Unified Extensional Version<strong>in</strong>g Model) [UEVM99] come<br />

modello <strong>per</strong> svolgere <strong>il</strong> controllo <strong>di</strong> versione [Ch<strong>in</strong>i05]. UEVM è un modello<br />

che <strong>per</strong>mette <strong>di</strong> gestire le versioni <strong>di</strong> documenti strutturati come DAG (Direct<br />

33


Il progetto <strong>InterDataNet</strong> Architettura tecnologica <strong>di</strong> IDN<br />

Acyclic Graph) 13 con la particolarità <strong>di</strong> riuscire a versionare sia i contenuti<br />

che gli aspetti strutturali.<br />

I dati <strong>in</strong> IDN sono collegati con due tipologie <strong>di</strong> relazione: l<strong>in</strong>k <strong>di</strong> riferimento<br />

e l<strong>in</strong>k <strong>di</strong> composizione.<br />

Il documento del modello UEVM che viene versionato <strong>in</strong> IDN è strutturato<br />

da tutte le risorse tra le quali esiste un <strong>per</strong>corso <strong>di</strong> l<strong>in</strong>k <strong>di</strong> composizione.<br />

L’orientamento del collegamento tra due risorse stab<strong>il</strong>isce una relazione <strong>di</strong><br />

padre e figlio tra <strong>di</strong> esse. In particolare essendo <strong>il</strong> grafo aciclico ed orientato,<br />

esiste un unico nodo ra<strong>di</strong>ce che non ha nessun padre.<br />

Il documento da versionare è visto qu<strong>in</strong><strong>di</strong> come una istantanea <strong>di</strong> risorse e<br />

delle relazioni <strong>di</strong> composizione che le legano. Due documenti UEVM <strong>di</strong>st<strong>in</strong>ti<br />

possono essere collegati soltanto da l<strong>in</strong>k <strong>di</strong> riferimento.<br />

In UEVM la mo<strong>di</strong>fica <strong>di</strong> una risorsa prevede la propagazione dell’aggiornamento<br />

del numero <strong>di</strong> versione ai padri del nodo, qu<strong>in</strong><strong>di</strong> la propagazione<br />

risale ricorsivamente f<strong>in</strong>o alla ra<strong>di</strong>ce del documento.<br />

D<br />

v1<br />

Revision 1 Revision 2<br />

B<br />

v1<br />

A<br />

v1<br />

E<br />

v1<br />

C<br />

v1<br />

Update on a<br />

ch<strong>il</strong>d resource<br />

D<br />

v1<br />

B B<br />

v2 v2<br />

A A<br />

v1 v2<br />

E E<br />

v1 v2<br />

Figura 2.7: Revisioni successive <strong>di</strong> due documenti nel modello UEVM<br />

In figura 2.7 possiamo vedere quello che succede dopo una mo<strong>di</strong>fica <strong>di</strong><br />

una risorsa: <strong>il</strong> nodo figlio “E” viene mo<strong>di</strong>ficato e qu<strong>in</strong><strong>di</strong> verrà creata una<br />

13 In verità UEVM è def<strong>in</strong>ito <strong>per</strong> strutture ad Albero, ma può essere generalizzato<br />

ed applicato anche a DAG, ovvero grafi <strong>in</strong> cui si hanno archi orientati e non esistono<br />

cicli [Ch<strong>in</strong>i05]<br />

C<br />

v1<br />

34


Il progetto <strong>InterDataNet</strong> Architettura tecnologica <strong>di</strong> IDN<br />

nuova versione della risorsa che <strong>in</strong><strong>di</strong>vidua, <strong>di</strong>fferente dalla prima. Sebbene <strong>il</strong><br />

nodo padre “B” rimanga <strong>in</strong>alterato nei contenuti, nella struttura subisce una<br />

alterazione poichè un suo figlio non è più lo stesso. Ed è <strong>per</strong> questo motivo<br />

che è necessario versionare <strong>il</strong> nodo padre: la versione 1 del nodo “B” ha <strong>in</strong>fatti<br />

come figli “D v1” ed “E v1”, la versione 2 ha <strong>in</strong>vece come figli “D v1” (che non<br />

è cambiato) ed “E v2”.<br />

È proprio questo l’aspetto fondamentale <strong>di</strong> UEVM: <strong>per</strong>mette <strong>di</strong> tenere<br />

traccia non soltanto dello storico delle s<strong>in</strong>gole risorse, ma anche la struttura<br />

che queste hanno avuto.<br />

Identity Service<br />

L’architetura IDN prevede <strong>in</strong>oltre la gestione <strong>di</strong> Identità ed autenticazione.<br />

Questo aspetto è <strong>in</strong> fase <strong>di</strong> stu<strong>di</strong>o, si possono tuttavia fare alcune<br />

considerazioni <strong>di</strong> carattere generale.<br />

Per andare <strong>in</strong>contro ai pr<strong>in</strong>cipi delle Service Oriented Architecture, la<br />

gestione delle identità degli utenti sarà svolta da un’apposito servizio.<br />

Il servizio sarà orchestrato dal Virtual Repository, e da un punto <strong>di</strong> vista<br />

logico lo si può collocare <strong>in</strong> questo livello. Tuttavia la gestione delle autorizzazioni<br />

è trasversale alla struttura, e <strong>per</strong>tanto è possib<strong>il</strong>e che sia richiesta<br />

una sua <strong>in</strong>terazione con tutti i livelli.<br />

Attualmente si si sta analizzando l’approccio <strong>di</strong> Kerberos 14 [Zappia06] <strong>per</strong><br />

applicare una politica <strong>di</strong> S<strong>in</strong>gle Sign-On e la def<strong>in</strong>izione <strong>di</strong> ACL.<br />

In questa prospettiva si sono previsti due punti <strong>di</strong> accesso alle <strong>in</strong>formazioni:<br />

<strong>per</strong> gli utenti tramite <strong>il</strong> layer <strong>di</strong> Virtual Repository e tramite livello<br />

<strong>di</strong> Replica Management: questo deve essere accessib<strong>il</strong>e dall’esterno dell’organizzazione<br />

<strong>per</strong> <strong>per</strong>mettere l’<strong>in</strong>tero<strong>per</strong>ab<strong>il</strong>ita fra dom<strong>in</strong>i <strong>di</strong>versi, ed è stato<br />

stab<strong>il</strong>ito che l’<strong>in</strong>terazione, al <strong>di</strong> fuori del dom<strong>in</strong>io, possa avvenire solo tra<br />

servizi a livello <strong>di</strong> RM.<br />

È chiaro qu<strong>in</strong><strong>di</strong> che si rende necessario un qualche meccanismo <strong>di</strong> autenticazione<br />

tra servizi <strong>di</strong> Replica, ovvero sarà necessaria una qualche certification<br />

authority che possa garantire l’affidab<strong>il</strong>ità delle entità <strong>in</strong> gioco. Si stanno<br />

stu<strong>di</strong>ando le funzionalità ed i pr<strong>in</strong>cipi che offre Kerberos a riguardo e come<br />

<strong>in</strong>tegrarle nell’architettura <strong>di</strong> IDN.<br />

14 http://web.mit.edu/kerberos/<br />

35


Il progetto <strong>InterDataNet</strong> Architettura tecnologica <strong>di</strong> IDN<br />

2.3.2 L’<strong>in</strong>formazione: IDN-IM<br />

Un “Information Model” può essere def<strong>in</strong>ito come un metodo universale<br />

<strong>per</strong> rappresentare entità <strong>in</strong> un sistema, def<strong>in</strong>dendo le proprietà, le relazioni e<br />

le o<strong>per</strong>azioni che su <strong>di</strong> esse si possono eseguire.<br />

È un concetto astratto, <strong>in</strong><strong>di</strong>pendente da implementazioni specifiche le<br />

quali <strong>in</strong>vece supportano un “Data Model”, ovvero una rappresentazione concreta<br />

delle <strong>in</strong>formazioni <strong>in</strong> un qualche l<strong>in</strong>guaggio <strong>in</strong>formatico (ad esempio<br />

XML o con classi <strong>in</strong> C++ o Java).<br />

IDN def<strong>in</strong>isce le risorse con un suo “Information Model” (IDN- IM) che<br />

può essere adattato a data model appartenenti a contesti <strong>di</strong>fferenti e che<br />

qu<strong>in</strong><strong>di</strong> aumenta la scalab<strong>il</strong>ità dell’<strong>in</strong>tera architettura.<br />

L’<strong>in</strong>formazione <strong>in</strong> IDN è formalizzata come una aggregazione <strong>di</strong> unità elementari<br />

chiamate Primitive Information Unit le quali contengono dati,<br />

metadati ed hanno delle relazioni con altre primitive (ve<strong>di</strong> figura 2.8, lato<br />

s<strong>in</strong>istro). Esse rappresentano i no<strong>di</strong> del grafo <strong>di</strong> un documento IDN.<br />

Sulle relazioni tra i no<strong>di</strong> vige una restrizione: un documento IDN-IM deve<br />

rispettare <strong>il</strong> v<strong>in</strong>colo <strong>di</strong> poter essere rappresentato con un DAG, un grafo<br />

<strong>di</strong>retto ed aciclico. È importante osservare che un albero è un caso particolare<br />

<strong>di</strong> un DAG, e qu<strong>in</strong><strong>di</strong> IDN-IM è compatib<strong>il</strong>e con tutti quei documenti<br />

che sono modellati con XML o DOM. Inoltre anche la maggior parte dei database<br />

relazionali mantiene una struttura gerarchica coerente che può essere<br />

mappata almeno <strong>in</strong> un DAG. La scelta <strong>di</strong> ut<strong>il</strong>izzare un DAG è un limite alla<br />

<strong>in</strong>tero<strong>per</strong>ab<strong>il</strong>ità <strong>di</strong> IDN, tuttavia è necessaria <strong>per</strong> poter implementare politiche<br />

<strong>di</strong> controllo <strong>di</strong> versione, ed è comunque una soluzione più generale <strong>di</strong> un<br />

normale albero.<br />

In figura 2.8 è riportata la rappresentazione <strong>di</strong> due documento IDN, fatti<br />

<strong>di</strong> Primitive Data Unit aggregate con l<strong>in</strong>k <strong>di</strong> composizione. Si noti la presenza<br />

<strong>di</strong> un collegamento <strong>di</strong> riferimento tra due <strong>di</strong>versi documenti, e come a<br />

loro volta i no<strong>di</strong> “B” e “C” che hanno come figlio <strong>in</strong> comune <strong>il</strong> nodo “D” ed<br />

<strong>in</strong><strong>di</strong>viduano a loro volta dei nuovi documenti IDN.<br />

Una precisazione è dovuta: sebbene <strong>il</strong> documento IDN-IM ed <strong>il</strong> modello <strong>di</strong><br />

documento UEVM <strong>il</strong>lustrato <strong>in</strong> 2.3.1 sembrano essere la stessa cosa (e <strong>di</strong> fatto<br />

si usa la stessa term<strong>in</strong>ologia <strong>per</strong> <strong>in</strong><strong>di</strong>care <strong>il</strong> nome dei collegamenti), ancora<br />

non è stata fatta nessuna assunzione specifica a riguardo. Infatti potrebbe<br />

36


Il progetto <strong>InterDataNet</strong> Architettura tecnologica <strong>di</strong> IDN<br />

A primitive <strong>in</strong>formation unit<br />

Primitive Information Unit<br />

<br />

<br />

+ <br />

<br />

IDN Document - Doc1<br />

Doc1<br />

root<br />

B<br />

<br />

<br />

IDN<br />

Document<br />

A<br />

<br />

<br />

D<br />

<br />

<br />

C<br />

<br />

<br />

IDN<br />

Document<br />

Figura 2.8: <strong>InterDataNet</strong> Information Model<br />

L<strong>in</strong>k Types:<br />

aggregation<br />

reference<br />

Doc2<br />

D<br />

<br />

<br />

E<br />

<br />

<br />

Doc2<br />

root<br />

D<br />

<br />

<br />

esistere la necessità versionare <strong>in</strong>sieme un gruppo <strong>di</strong> documenti IDN, oppure<br />

<strong>per</strong> un qualche motivo, non ci <strong>in</strong>teressa tenere sotto controllo <strong>di</strong> versione<br />

l’<strong>in</strong>tero documento (<strong>per</strong>chè ad esempio i l<strong>in</strong>k <strong>di</strong> composizione raggruppano<br />

primitive <strong>di</strong> cui non è richiesto tener traccia).<br />

In conclusione, le IDN-API forniscono funzionalità <strong>per</strong> gestire documenti<br />

IDN-IM. Questo modello è pensato <strong>per</strong> funzionare <strong>in</strong> IDN-SA, ed i servizi<br />

che abbiamo esam<strong>in</strong>ato <strong>in</strong> 2.3.1 sono pensati <strong>per</strong> offrire supporto e favorire<br />

l’adozione <strong>di</strong> questa architettura.<br />

Si noti tuttavia che <strong>il</strong> concetto <strong>di</strong> documento IDN-IM non è <strong>di</strong>rettamente<br />

impiegato <strong>in</strong>ternamente nei servizi <strong>di</strong> IDN-SA, ma traspare soltando al livello<br />

più alto. In particolare, IDN può essere vista come una scatola chiusa 15 che<br />

espone le IDN-API <strong>per</strong> gestire <strong>il</strong> modello dell’<strong>in</strong>formazione.<br />

2.3.3 Le <strong>in</strong>terfacce verso l’esterno <strong>di</strong> IDN-SA<br />

I servizi ed i livelli esam<strong>in</strong>ati f<strong>in</strong>o ad adesso hanno funzioni specifiche,<br />

orientate al content management oppure alla gestione <strong>di</strong> aspetti dei sistemi<br />

<strong>di</strong>stribuiti.<br />

Il Virtual Repository e lo <strong>Storage</strong> Interface hanno un ruolo concettualmente<br />

<strong>di</strong>verso: essi realizzano l’<strong>in</strong>tero<strong>per</strong>ab<strong>il</strong>ità con <strong>il</strong> mondo esterno.<br />

15 L’approccio “black box”, ve<strong>di</strong> sezione 2.2.2<br />

37


Il progetto <strong>InterDataNet</strong> Architettura tecnologica <strong>di</strong> IDN<br />

Virtual Repository<br />

Come abbiamo visto VR è <strong>il</strong> servizio che espone le IDN-API, le quali<br />

<strong>per</strong>mettono <strong>di</strong> eseguire o<strong>per</strong>azioni su IDN-IM. Il modello <strong>in</strong>formativo è stato<br />

esam<strong>in</strong>ato nel dettaglio <strong>in</strong> 2.3.2. Si tratta <strong>di</strong> una <strong>in</strong>formazione strutturata<br />

che ha le proprietà <strong>di</strong> un DAG, i cui no<strong>di</strong> sono stati <strong>in</strong><strong>di</strong>cati con <strong>il</strong> nome <strong>di</strong><br />

Primitive Information Unit.<br />

Questo DAG <strong>per</strong>ò non esiste <strong>di</strong>rettamente, cioè non viene memorizzato<br />

<strong>per</strong> <strong>in</strong>tero: è scomposto nelle primitive, ognuna delle quali ha un proprio<br />

nome, collegate <strong>per</strong> mezzo <strong>di</strong> una relazioni che abbiamo def<strong>in</strong>ito con <strong>il</strong> nome<br />

“l<strong>in</strong>k <strong>di</strong> composizione”. Il nam<strong>in</strong>g <strong>in</strong> IDN è globale ed <strong>in</strong><strong>di</strong>rizza i no<strong>di</strong> del<br />

DAG. Di fatto, ogni documento si identifica con <strong>il</strong> suo nodo ra<strong>di</strong>ce ed ogni<br />

primitiva che abbia dei figli tramite l<strong>in</strong>k <strong>di</strong> composizione è vista a sua volta<br />

come un documento IDN.<br />

Ogni primitiva ha <strong>in</strong>oltre un numero arbitrario <strong>di</strong> altre proprietà che<br />

descrivono caratteristiche <strong>di</strong> sistema o <strong>di</strong> utente.<br />

Il term<strong>in</strong>e virtual è dovuto proprio al fatto che questo servizio offre, tramite<br />

le sue API, l’accesso ad un documento che non esiste <strong>in</strong> quanto tale. Il<br />

term<strong>in</strong>e repository che tradotto <strong>in</strong> italiano significa “deposito”, ci suggerisce<br />

che l’accesso a questo documento virtuale prevede la sua memorizzazione <strong>in</strong><br />

una struttura pre<strong>di</strong>sposta.<br />

La <strong>di</strong>fferenza importante tra un documento tra<strong>di</strong>zionale pubblicato sul Web<br />

ed un documento virtuale è che <strong>in</strong> IDN avviene <strong>di</strong>rettamente <strong>il</strong> riut<strong>il</strong>izzo delle<br />

<strong>in</strong>formazioni: due documenti <strong>di</strong>versi possono entrambi contenere la stessa<br />

primitiva. Non è qu<strong>in</strong><strong>di</strong> necessrio copiare i dati e non si hanno i problemi<br />

che comporta la necessità <strong>di</strong> tenerli s<strong>in</strong>cronizzati. Qualora <strong>per</strong> f<strong>in</strong>alità <strong>di</strong><br />

<strong>per</strong>formance e scalab<strong>il</strong>ità questo meccanismo sia necessario la sua gestione è<br />

delegata allo specifico servizio <strong>di</strong> Replica Management.<br />

È ut<strong>il</strong>e fare un esempio <strong>per</strong> spiegare questo concetto. Immag<strong>in</strong>iamo <strong>di</strong><br />

avere due pag<strong>in</strong>e Web <strong>di</strong>st<strong>in</strong>te, come <strong>in</strong> figura 2.9 che contengono ad esempio<br />

i dati anagrafici <strong>di</strong> una stessa <strong>per</strong>sona. Nel Web tra<strong>di</strong>zionale è necessario che<br />

nell’ HTML <strong>di</strong> entrambi i documenti siano riportate le <strong>in</strong>formazioni quali nome,<br />

cognome, <strong>in</strong><strong>di</strong>rizzo etc. e se una <strong>di</strong> queste cambia, ad esempio l’<strong>in</strong><strong>di</strong>rizzo<br />

<strong>di</strong> domic<strong>il</strong>io <strong>in</strong> seguito ad un trasloco, è necessario tracciare tutte i documenti<br />

che hanno ut<strong>il</strong>izzato tale <strong>in</strong>formazione e provvedere a mo<strong>di</strong>ficarla.<br />

38


Il progetto <strong>InterDataNet</strong> Architettura tecnologica <strong>di</strong> IDN<br />

Web Server<br />

TO: Web Browsers TO: IDN applications<br />

Web Doc A<br />

Bla bla bla bla bla bla bla<br />

bla bla bla bla bla bla bla<br />

bla bla bla bla bla bla bla<br />

bla bla bla bla bla bla bla<br />

bla bla bla<br />

bla bla bla<br />

bla bla bla<br />

bla bla bla<br />

FirstName LastName<br />

My address, 123<br />

City - State<br />

Web Doc B<br />

Bla bla bla bla bla bla bla<br />

bla bla bla bla bla bla bla<br />

bla bla bla<br />

bla bla bla<br />

bla bla bla<br />

bla bla bla<br />

bla bla bla<br />

bla bla bla<br />

same <strong>in</strong>formation,<br />

duplicated data<br />

FirstName<br />

LastName<br />

My address,<br />

123<br />

City - State<br />

Virtual Repository Service<br />

IDN Doc A<br />

bla<br />

A<br />

bla<br />

bla<br />

FirstName<br />

LastName<br />

My address,<br />

123<br />

City - State<br />

same <strong>in</strong>formation,<br />

shared data<br />

IDN Doc B<br />

Figura 2.9: Due documenti Web (pag<strong>in</strong>e HTML) e due documenti IDN (DAG<br />

IDN-IM) che rappresentano la stessa <strong>in</strong>formazione<br />

Grazie alla proprietà <strong>di</strong> essere un DAG, e grazie alla global addressab<strong>il</strong>ity<br />

a livello dei no<strong>di</strong>, <strong>in</strong> IDN è possib<strong>il</strong>e avere due documenti che con<strong>di</strong>vidono,<br />

ad esempio, gli stessi dati anagrafici.<br />

Per capire meglio questo esempio è ut<strong>il</strong>e analizzarlo nel suo conteso applicativo.<br />

I documenti presi <strong>in</strong> esempio appartengono alla categoria delle pag<strong>in</strong>e<br />

HTML, che qu<strong>in</strong><strong>di</strong> hanno come ultimo f<strong>in</strong>e <strong>il</strong> visualizzare sullo schermo delle<br />

<strong>in</strong>formazioni che un essere umano possa leggere.<br />

Nell’esempio precedente “Web Page A” e “IDN Doc A” rappresentano le<br />

stesse <strong>in</strong>formazioni. È spontaneo qu<strong>in</strong><strong>di</strong> chiedersi come <strong>il</strong> documento IDN<br />

possa arrivare allo schermo <strong>di</strong> un utente <strong>di</strong> IDN.<br />

In figura 2.10 sono <strong>il</strong>lustrate alcune soluzioni a questo problema.<br />

Virtual Repository è naturalmente portato <strong>per</strong> essere usato <strong>in</strong> molti mo<strong>di</strong>.<br />

I documenti possono essere trasformati <strong>in</strong> pag<strong>in</strong>e HTML da visualizzare sui<br />

browser grazie a processi <strong>in</strong> esecuzione su specifici server:<br />

• si possono creare applicazioni IDN dentro ai moduli CGI presenti nella<br />

maggior parte dei Web Server, ut<strong>il</strong>izzando l<strong>in</strong>guaggi come Perl, PHP,<br />

ASP, Python, Ruby<br />

bla<br />

bla<br />

B<br />

bla<br />

39


Il progetto <strong>InterDataNet</strong> Architettura tecnologica <strong>di</strong> IDN<br />

Virtual Repository Service IDN CGI Application<br />

IDN Doc A<br />

bla<br />

A<br />

bla<br />

bla<br />

FirstName<br />

LastName<br />

My address,<br />

123<br />

City - State<br />

CGI Process:<br />

Pearl, PHP, ASP<br />

Web Doc A<br />

Bla bla bla bla bla bla bla<br />

bla bla bla bla bla bla bla<br />

bla bla bla bla bla bla bla<br />

bla bla bla bla bla bla bla<br />

bla bla bla<br />

bla bla bla<br />

bla bla bla<br />

bla bla bla<br />

FirstName LastName<br />

My address, 123<br />

City - State<br />

Web Browsers<br />

Ajax XUL<br />

FLEX S<strong>il</strong>verlight<br />

XHTML + CSS<br />

Figura 2.10: Ut<strong>il</strong>izzo <strong>di</strong> Virtual Repository da parte <strong>di</strong> applicazioni IDN<br />

orientate al Web<br />

• si possono realizzare applicazioni Java con servlet o JSP che possono<br />

essere <strong>in</strong>stallate su Web Conta<strong>in</strong>er come Apache Tomcat<br />

Le tecnologie delle Rich <strong>in</strong>ternet application offrono <strong>per</strong>ò soluzioni alternative<br />

molto attraenti:<br />

• le <strong>in</strong>formazioni possono essere trasformate con tecniche Asynchronous<br />

JavaScript and XML<br />

• tramite FLEX o tecnologie sim<strong>il</strong>i come XUL e S<strong>il</strong>verLight i documenti<br />

IDN possono essere presentati <strong>di</strong>rettamente dentro ai Browser più<br />

recenti<br />

Inf<strong>in</strong>e, grazie all’ut<strong>il</strong>izzo <strong>di</strong> <strong>in</strong>terfacce RESTful che <strong>per</strong>mettono <strong>di</strong> accedere<br />

ad un documento IDN-IM esposto come XML<br />

• si può <strong>di</strong>rettamente visualizzare un documento se questo è XHTML e<br />

vi è associato un foglio <strong>di</strong> st<strong>il</strong>e che ne specifica la presentazione<br />

In conclusione, Virtual Repository <strong>per</strong>mette l’<strong>in</strong>tero<strong>per</strong>ab<strong>il</strong>ità verso l’alto,<br />

con <strong>il</strong> Web tra<strong>di</strong>zionale ed <strong>il</strong> Web 2.0. Questo servizio im<strong>per</strong>sonifica IDN ed<br />

è centrale <strong>per</strong> la creazione <strong>di</strong> applicazioni basate su questa architettura così<br />

come lo è <strong>il</strong> protocollo TCP <strong>per</strong> lo stack <strong>di</strong> Internet.<br />

IDN Rich Internet Applications<br />

SCREEN<br />

40


Il progetto <strong>InterDataNet</strong> Architettura tecnologica <strong>di</strong> IDN<br />

Lo sv<strong>il</strong>uppo <strong>di</strong> VR è ancora <strong>in</strong> una fase prelim<strong>in</strong>are e ancora non è stata<br />

def<strong>in</strong>ita la sua <strong>in</strong>terfaccia, ovvero la IDN-API. Pr<strong>in</strong>cipalmente sono stati fatti<br />

stu<strong>di</strong> teorici sulle funzionalità e i requisiti <strong>per</strong> un suo ut<strong>il</strong>izzo <strong>in</strong> <strong>di</strong>versi campi,<br />

dal Semantic Web [IDN07a] agli atti amm<strong>in</strong>istrativi [Paolucci06].<br />

Ma tutti i requisiti dei livelli <strong>di</strong> <strong>Storage</strong> Interface e <strong>di</strong> Replica Management<br />

sono derivati da necessità <strong>di</strong> supportare gli strati su<strong>per</strong>iori e <strong>per</strong> questo sono<br />

importanti gli stu<strong>di</strong> svolti <strong>per</strong> la realizzazione del livello più alto.<br />

<strong>Storage</strong> Interface<br />

Lo <strong>Storage</strong> Interface al contrario Virtual Repository, gestisce l’<strong>in</strong>terazione<br />

verso <strong>il</strong> basso. Permettere la memorizzazione è tra le f<strong>in</strong>alità <strong>di</strong> IDN: piuttosto<br />

che proporre una soluzione globale <strong>di</strong> storage, IDN def<strong>in</strong>isce una API con la<br />

quale adattare le soluzioni esistenti.<br />

Il punto <strong>di</strong> vista è <strong>in</strong>verso a quello del Virtual Repository: non è tramite<br />

l’esposizione <strong>di</strong> una API che si ab<strong>il</strong>ita l’<strong>in</strong>tero<strong>per</strong>ab<strong>il</strong>ità, ma è tramite la sua<br />

implementazione.<br />

Gli strati <strong>di</strong> IDN-SA sono pensati <strong>per</strong> poter essere costruiti sopra ad SI e<br />

non <strong>in</strong>teressa come vengono salvate le risorse <strong>in</strong> realtà.<br />

La specifica <strong>di</strong> <strong>Storage</strong> Interface <strong>in</strong> IDN avviene attraverso la def<strong>in</strong>izione<br />

delle funzionalità, delle o<strong>per</strong>azioni e dei protocolli <strong>di</strong> accesso alle risorse <strong>di</strong><br />

storage, ma non vi sono v<strong>in</strong>coli o requisiti che descrivono come implementare<br />

queste soluzioni se non le necessità <strong>di</strong> rispettarne l’<strong>in</strong>terfaccia.<br />

In particolare, le risorse a questo livello non sono né documenti IDN né<br />

primitive data unit, ma qualcosa che attraversando i livelli ha subito <strong>di</strong>verse<br />

trasformazioni. Le entità trattate da <strong>Storage</strong> Interface sono dati con associati<br />

metadati.<br />

È possib<strong>il</strong>e immag<strong>in</strong>are <strong>di</strong> realizzare servizi <strong>di</strong> storage che implementano<br />

SI e che si basano su database server, su f<strong>il</strong>e system, su documenti <strong>di</strong>sponib<strong>il</strong>i<br />

nel Web.<br />

Lo sv<strong>il</strong>uppo dell’<strong>in</strong>terfaccia e <strong>di</strong> una implementazione <strong>di</strong> riferimento viene<br />

<strong>di</strong>scusso nel dettaglio nel capitolo 6 <strong>di</strong> questa tesi. Durante <strong>il</strong> lavoro <strong>di</strong><br />

tesi è stato def<strong>in</strong>ito <strong>Storage</strong> Interface come un Web Service che espone una<br />

<strong>in</strong>terfaccia orientata alle risorse e fornisce le capacità <strong>di</strong> o<strong>per</strong>are su <strong>di</strong> esse.<br />

41


Il progetto <strong>InterDataNet</strong> Architettura tecnologica <strong>di</strong> IDN<br />

Per i dettagli si rimanda al capitolo de<strong>di</strong>cato al suo progetto. Per ora è<br />

sufficiente anticipare che l’<strong>in</strong>terfaccia si sv<strong>il</strong>uppa <strong>in</strong>torno alle o<strong>per</strong>azioni base<br />

della memorizzazione <strong>per</strong>sistente: creazione, mo<strong>di</strong>fica, lettura e cancellazione.<br />

Virtual Repository Layer<br />

Information History Layer<br />

Replica Management Layer<br />

SI API<br />

<strong>Storage</strong><br />

Service<br />

SQL<br />

database<br />

SI API SI API SI API SI API<br />

<strong>Storage</strong><br />

Service<br />

f<strong>il</strong>e system<br />

Enterprise<br />

Information<br />

Service<br />

Enterprise Enterprise<br />

Database<br />

Enterprise<br />

Database Database<br />

Me<strong>di</strong>a<br />

<strong>Storage</strong><br />

Service<br />

Flickr<br />

YouTube<br />

Social<br />

Network<br />

Service<br />

social network<br />

Figura 2.11: <strong>Storage</strong> Interface e Legacy <strong>Storage</strong> Interface<br />

Implementare un servizio <strong>di</strong> storage <strong>per</strong> IDN significa sv<strong>il</strong>uppare una applicazione<br />

che supporta le API def<strong>in</strong>ite da SI. Le proprietà def<strong>in</strong>ite dalle<br />

specifiche della sua <strong>in</strong>terfaccia fanno sì che su tale applicazione si possa montare<br />

lo stack dei livelli su<strong>per</strong>iori. In figura 2.11 si può vedere <strong>il</strong>lustrata questa<br />

situazione, dove gli altri strati <strong>di</strong> IDN pongono le loro basi su una varietà <strong>di</strong><br />

<strong>di</strong>fferenti servizi <strong>di</strong> storage implementati con <strong>di</strong>verse tecnologie.<br />

Legacy <strong>Storage</strong> Interface<br />

In figura 2.11 è possib<strong>il</strong>e apprezzare un altro importante aspetto <strong>di</strong> SI.<br />

Tramite la sua <strong>in</strong>terfaccia, è possib<strong>il</strong>e ut<strong>il</strong>izzare <strong>in</strong> IDN risorse create al <strong>di</strong><br />

fuori <strong>di</strong> essa.<br />

Ad esempio, un database <strong>di</strong> una impresa che già esiste, un servizio <strong>di</strong><br />

storage <strong>di</strong> contenuti multime<strong>di</strong>ali, oppure rappresentazioni <strong>di</strong> <strong>in</strong><strong>di</strong>vidui ed<br />

organizzazioni <strong>di</strong> un sito <strong>di</strong> social network<strong>in</strong>g. Si può pensare <strong>di</strong> rendere<br />

queste risorse <strong>di</strong>sponib<strong>il</strong>i <strong>in</strong> IDN sv<strong>il</strong>uppando dei servizi che espongono le<br />

risorse già esistenti.<br />

Molte scelte implementative non sono scontate e la soluzione migliore <strong>per</strong><br />

realizzare una tale applicazione <strong>di</strong>pende anche dal modo <strong>in</strong> cui si può avere<br />

42


Il progetto <strong>InterDataNet</strong> Una migrazione <strong>in</strong>tero<strong>per</strong>ab<strong>il</strong>e<br />

accesso alla fonte delle <strong>in</strong>formazioni. Spesso saranno possib<strong>il</strong>i più strade e<br />

non è detto che <strong>in</strong> ogni situazione si possa identificarne una migliore <strong>di</strong> altre.<br />

Sarà necessario o<strong>per</strong>are delle scelte che <strong>di</strong>penderanno da ogni caso specifico.<br />

Questo aspetto è importante poichè <strong>il</strong> panorama del Web è attualmente<br />

molto complesso e ricco <strong>di</strong> risorse che non si possono gettare via. Una qualsiasi<br />

soluzione <strong>di</strong> <strong>in</strong>ternetwork<strong>in</strong>g o una <strong>in</strong>frastruttura <strong>per</strong> <strong>il</strong> Semantic Web<br />

o <strong>per</strong> <strong>il</strong> Web of Data che abbia l’ambizione <strong>di</strong> servire a tutti gli utenti del<br />

Web non può non tenerne <strong>in</strong> considerazione gli aspetti <strong>di</strong> come recu<strong>per</strong>are<br />

del patrimonio <strong>in</strong>formativo pre-esistente.<br />

<strong>Storage</strong> Interface non risolve <strong>il</strong> problema <strong>in</strong> term<strong>in</strong>i assoluti poichè la<br />

varietà <strong>di</strong> risorse <strong>di</strong>sponib<strong>il</strong>i è <strong>in</strong>controllab<strong>il</strong>mente vasta. L’obiettivo dell’approccio<br />

ut<strong>il</strong>izzato è favorire e fac<strong>il</strong>itare la realizzazione <strong>di</strong> soluzioni <strong>per</strong><br />

connettere i due universi.<br />

2.4 Una migrazione <strong>in</strong>tero<strong>per</strong>ab<strong>il</strong>e<br />

L’architettura proposta da IDN realizza qu<strong>in</strong><strong>di</strong> una visione <strong>di</strong> Web of Data<br />

orientata alla collaborazione ed alla <strong>in</strong>tero<strong>per</strong>ab<strong>il</strong>ità. I documenti sono<br />

spezzati <strong>in</strong> parti più piccole che favoriscono <strong>il</strong> loro riut<strong>il</strong>izzo grazie all’<strong>in</strong><strong>di</strong>rizzamento<br />

globale ed a strumenti <strong>di</strong> supporto <strong>per</strong> l’atuhor<strong>in</strong>g.<br />

In particolare l’approccio <strong>InterDataNet</strong> sposta gli aspetti <strong>di</strong> collaborazione<br />

orientata ai dati dal livello applicativo alla <strong>in</strong>frastruttura. IDN-SA<br />

ed IDN-IM da questo punto <strong>di</strong> vista possono essere paragonati ad HTTP ed<br />

HTML che hanno spostato nel livello <strong>in</strong>frastrutturale la gestione <strong>di</strong> documenti<br />

i<strong>per</strong>testuali. In figura 2.12<br />

Una adozione su larga scala <strong>di</strong> IDN porterebbe qu<strong>in</strong><strong>di</strong> alla <strong>in</strong>tero<strong>per</strong>ab<strong>il</strong>ità<br />

a livello <strong>di</strong> dati apportando i benefici dell’<strong>in</strong>terdatawork<strong>in</strong>g.<br />

Non è tuttavia fac<strong>il</strong>e sv<strong>il</strong>uppare soluzioni <strong>in</strong> questo ambito. Il merito della<br />

rapida <strong>di</strong>ffusione dell’adozione HTTP ed HTML è sicuramente da ricercare<br />

nella loro semplicità. Ma va anche detto che hanno trovato un terreno fert<strong>il</strong>e<br />

<strong>in</strong> Internet che aveva appena raggiunto estensione globale.<br />

Oggi <strong>il</strong> bisogno <strong>di</strong> un Web orientato ai dati è sentito soprattutto <strong>per</strong><br />

l’avvento delle future tecnologie semantiche, ma con i suoi m<strong>il</strong>ioni <strong>di</strong> utenti,<br />

con la sua vastità <strong>di</strong> <strong>in</strong>formazioni e con migliaia <strong>di</strong> programmi <strong>di</strong>fferenti, <strong>il</strong><br />

43


Il progetto <strong>InterDataNet</strong> Una migrazione <strong>in</strong>tero<strong>per</strong>ab<strong>il</strong>e<br />

HTTP<br />

servers<br />

Web<br />

WWW<br />

HTML<br />

f<strong>il</strong>e<br />

f<strong>il</strong>e<br />

f<strong>il</strong>e<br />

IDN-SA<br />

IDN<br />

IDN<br />

applications<br />

IDN-IM<br />

Virtual Repository<br />

Information History<br />

Replica Management<br />

<strong>Storage</strong> Interface<br />

SI Resources<br />

Figura 2.12: Paragone tra Web e IDN<br />

Web non è un terreno che si può esplorare liberamente come lo era Internet<br />

alla f<strong>in</strong>e degli anni novanta. Il costo dell’<strong>in</strong>tero<strong>per</strong>ab<strong>il</strong>ità non può essere<br />

annullato.<br />

IDN si propone come soluzione <strong>per</strong> <strong>il</strong> Web of Data che m<strong>in</strong>imizza le <strong>di</strong>fficoltà<br />

<strong>di</strong> <strong>in</strong>tero<strong>per</strong>azione grazie all’uso <strong>di</strong> concetti astratti applicab<strong>il</strong>i ai modelli<br />

<strong>in</strong>formativi attuali.<br />

La figura 2.13 riprende <strong>il</strong> confronto precedente <strong>il</strong>lustrando come IDN si<br />

<strong>in</strong>serisce nello scenario complesso del Web attuale. In figura sono <strong>il</strong>lustrate<br />

le fasi successive <strong>di</strong> questo processo a partire dal Web orig<strong>in</strong>ale.<br />

1. La prima fase è stata quella del Web basato su HTTP ed HTML<br />

2. Il Web 2.0 mantiene al suo centro HTTP ed HTML 16 ma mostra una<br />

a<strong>per</strong>tura nei confronti <strong>di</strong> dati più piccoli <strong>di</strong> un documento, sia concettualmente,<br />

sia tecnicamente grazie a tecnologie come XML. Nel Web<br />

2.0 XML (o altri formati ad-hoc) è usato grazie ad Ajax dentro a documenti<br />

HTML oppure tramite i Web Service dentro a Rich Internet<br />

Application<br />

16 Più spesso è usato XHTML che formalizza i documenti i<strong>per</strong>testuali secondo le regole<br />

<strong>di</strong> XML<br />

44


Il progetto <strong>InterDataNet</strong> Una migrazione <strong>in</strong>tero<strong>per</strong>ab<strong>il</strong>e<br />

Web Web 2.0 Web of Data<br />

WWW<br />

HTML<br />

HTTP<br />

servers<br />

f<strong>il</strong>e<br />

f<strong>il</strong>e<br />

f<strong>il</strong>e<br />

WWW<br />

HTML XML<br />

XML<br />

+<br />

data<br />

XML<br />

XML<br />

HTTP<br />

servers<br />

f<strong>il</strong>e<br />

f<strong>il</strong>e<br />

f<strong>il</strong>e<br />

Rich Internet<br />

Applications<br />

data<br />

data<br />

data<br />

HTTP+SOAP<br />

Web Services<br />

XML data<br />

XML data<br />

XML data<br />

WWW<br />

HTML<br />

XML<br />

data<br />

+<br />

HTTP<br />

servers<br />

f<strong>il</strong>e<br />

f<strong>il</strong>e<br />

f<strong>il</strong>e<br />

Rich Internet<br />

Applications<br />

XML<br />

data<br />

+<br />

HTTP+SOAP<br />

Web Services<br />

XML data<br />

XML data<br />

XML data<br />

XHTML<br />

+<br />

CSS<br />

IDN<br />

Web Services<br />

IDN<br />

applications<br />

IDN-IM<br />

IDN-VR Virtual Repository<br />

IDN-IH Information History<br />

IDN-RM Replica Management<br />

IDN-SI <strong>Storage</strong> Interface<br />

XML data<br />

XML data<br />

XML data<br />

Semantic<br />

Web<br />

Figura 2.13: Dal Web al Semantic Web attraverso <strong>il</strong> Web 2.0 ed <strong>il</strong> Web of<br />

Data<br />

SI data<br />

3. Un Web of Data realizzato con IDN deve <strong>in</strong>tegrarsi con <strong>il</strong> Web ed <strong>il</strong><br />

Web 2.0. Grazie a <strong>Storage</strong> Interface è possib<strong>il</strong>e <strong>in</strong>terfacciarsi alle risorse<br />

già <strong>di</strong>sponib<strong>il</strong>i (database, repository <strong>di</strong> XML, documenti pubblicati sul<br />

Web) e poterle riusare. A livello applicativo <strong>in</strong>vece, IDN-IM gioca un<br />

ruolo centrale e ab<strong>il</strong>ita:<br />

• lo sv<strong>il</strong>uppo <strong>di</strong> nuove applicazioni<br />

• la creazione <strong>di</strong> servizi che possono essere usati <strong>per</strong> <strong>in</strong>tero<strong>per</strong>are<br />

con le RIA<br />

• l’<strong>in</strong>tero<strong>per</strong>ab<strong>il</strong>ità con <strong>il</strong> World Wide Web<br />

• le basi <strong>per</strong> un Web semantico globale<br />

Lo scenario è complesso e la figura 2.13 non pretende <strong>di</strong> esaurire l’argomento.<br />

Permette <strong>per</strong>ò <strong>di</strong> farsi una idea delle possib<strong>il</strong>ità che si prospettano<br />

e sottol<strong>in</strong>ea l’importanza e la necessità <strong>di</strong> far coesistere ed <strong>in</strong>tero<strong>per</strong>are i<br />

sistemi.<br />

RDF<br />

IDN-SA<br />

45


Il progetto <strong>InterDataNet</strong> Conclusioni<br />

2.5 Conclusioni<br />

Abbiamo visto cosa è <strong>InterDataNet</strong>: sono stati trattati i motivi <strong>per</strong> cui<br />

nasce, i concetti su cui pone le sue fondamenta, gli aspetti generali dell’architettura,<br />

i servizi pr<strong>in</strong>cipali ed <strong>il</strong> modello delle <strong>in</strong>formazioni su cui si<br />

basa.<br />

Si è più volte parlato <strong>di</strong> sitemi <strong>di</strong>stribuiti, <strong>di</strong> SOA e <strong>di</strong> REST, ma a<br />

qualcuno può sembrare strano che nel descrivere una architettura <strong>per</strong> la collaborazione<br />

e l’ab<strong>il</strong>itazione del Web of Data non siano stati trattati argomenti<br />

come Web Services, WSDL oppure non sia stato citato Java.<br />

IDN è stata descritta <strong>in</strong> term<strong>in</strong>i <strong>di</strong> Service Oriented Architecture che<br />

<strong>in</strong> pratica sono realizzate quasi esclusivamente con Web Service, ma la loro<br />

descrizione è astratta e <strong>per</strong>mette <strong>in</strong> l<strong>in</strong>ea teorica molte altre soluzioni<br />

tecniche.<br />

Ad esempio è <strong>in</strong>teressante <strong>il</strong> caso <strong>in</strong> cui si ut<strong>il</strong>izza un approccio misto che<br />

ut<strong>il</strong>izza soluzioni <strong>di</strong>verse tra livelli. Ad esempio <strong>il</strong> livello più alto <strong>di</strong> IDN<br />

può esporre un Web Service, ma può essere costruito su livelli sottostanti i<br />

cui servizi sono consumati tramite librerie locali. Non cambiano i pr<strong>in</strong>cipi<br />

<strong>di</strong> funzionamento <strong>di</strong> IDN-SA, ma le prestazioni ne risentono <strong>in</strong> positivo <strong>in</strong><br />

quanto nei livelli <strong>in</strong>feriori non è necessario <strong>in</strong>vocare servizi remoti.<br />

Nei prossimi capitoli verranno descritti aspetti teorici e pratici su cui fondare<br />

sia <strong>il</strong> progetto, sia le specifiche, sia le implementazioni dei servizi <strong>di</strong> IDN.<br />

In particolare nella seconda e nella terza parte verrà <strong>di</strong>scusso nel dettaglio<br />

gli aspetti che riguardano <strong>il</strong> primo <strong>di</strong> essi: lo <strong>Storage</strong> Interface.<br />

46


Parte II<br />

Analisi del servizio <strong>di</strong> <strong>Storage</strong><br />

Interface


Capitolo<br />

3<br />

Tecnologie <strong>per</strong> IDN e <strong>Storage</strong><br />

Interface<br />

“Young man, <strong>in</strong> mathematics you don’t understand th<strong>in</strong>gs. You<br />

just get used to them”<br />

John von Neumann<br />

In questo capitolo si affronteranno tematiche che riguardano le pr<strong>in</strong>cipali<br />

tecnologie <strong>di</strong> riferimento <strong>per</strong> lo sv<strong>il</strong>uppo <strong>di</strong> <strong>InterDataNet</strong> e del servizio <strong>di</strong><br />

<strong>Storage</strong> Interface.<br />

Si parlerà <strong>di</strong> Service Oriented Architecture (SOA) e <strong>di</strong> Representational<br />

State Transfer (REST) e <strong>di</strong> Web Service, WSDL, HTTP,<br />

ROA e RDF.


Tecnologie <strong>per</strong> IDN e <strong>Storage</strong> Interface Service Oriented Architecture<br />

Le prime due sono tecnologie astratte e riguardano aspetti teorici e st<strong>il</strong>istici:<br />

SOA e REST propongono degli st<strong>il</strong>i <strong>per</strong> realizzare architetture <strong>di</strong>stribuite<br />

senza scendere nei dettagli su come realizzarle.<br />

I Web Service sono lo standard <strong>di</strong> fatto <strong>per</strong> la realizzaizone <strong>di</strong> architetture<br />

<strong>in</strong> st<strong>il</strong>e SOA, le Resource Oriented Architecture (ROA) <strong>in</strong>vece propongono<br />

una implementazione REST che si basa su HTTP.<br />

Inf<strong>in</strong>e sarà trattato RDF. RDF è uno standard <strong>per</strong> la descrizione <strong>di</strong> metata<strong>di</strong><br />

<strong>di</strong> risorse <strong>in</strong><strong>di</strong>rizzate da URI, ed è uno dei p<strong>il</strong>astri su cui si fonda <strong>il</strong><br />

Web semantico.<br />

3.1 Service Oriented Architecture<br />

È <strong>di</strong>ffic<strong>il</strong>e trovare una def<strong>in</strong>izione esatta del term<strong>in</strong>e SOA. Il problema<br />

non sta nel fatto che non esistono def<strong>in</strong>izioni, ma che ce ne sono troppe.<br />

Analizzando le <strong>di</strong>verse op<strong>in</strong>ioni 1 alla f<strong>in</strong>e si scopre che tutte concordano sul<br />

fatto che SOA sia “un para<strong>di</strong>gma <strong>per</strong> una migliore flessib<strong>il</strong>ità”.<br />

Le Service Oriented Architecture non sono architetture concrete: sono<br />

un qualcosa che conduce alla realizzazione <strong>di</strong> una architettura concreta. Si<br />

può chiamare st<strong>il</strong>e, para<strong>di</strong>gma, concetto, prospettiva, f<strong>il</strong>osofia o rappresentazione.<br />

È un approccio, un modo <strong>di</strong> pensare che guida le decisioni quando si<br />

progettano architetture software.<br />

3.1.1 Motivazioni e Concetti fondamentali<br />

Lo st<strong>il</strong>e SOA nasce <strong>per</strong> far fronte alla necessità <strong>di</strong> flessib<strong>il</strong>ità nelle moderne<br />

architetture software. La flessib<strong>il</strong>ità è necessaria <strong>per</strong> mantenere soluzioni <strong>di</strong><br />

qualità e rispettare i tempi del mercato, ma <strong>il</strong> suo prezzo comporta <strong>di</strong> avere<br />

a che fare con delicate questioni <strong>di</strong> organizzazione dei progetti, dei processi,<br />

dei ruoli delle entità co<strong>in</strong>volte e così via.<br />

Le SOA suggeriscono come affrontare questi aspetti, <strong>in</strong> particolare le caratteristiche<br />

<strong>di</strong>ffic<strong>il</strong>i da gestire dei gran<strong>di</strong> sistemi come i sistemi <strong>di</strong>stribuiti,<br />

1 In [Josuttis] si trova una analisi <strong>di</strong> varie def<strong>in</strong>izioni <strong>di</strong> Service Oriented Architecture<br />

apparse <strong>in</strong> articoli, libri o sul Web. Le pr<strong>in</strong>cipali fonti <strong>di</strong> riferimento sono [OasisSOA06],<br />

[Erl], [NewcomerLomow] e varie def<strong>in</strong>izioni apparse su http://www.wikipe<strong>di</strong>a.org. Altre<br />

def<strong>in</strong>izioni si trovano su [Natis03], [Hansen] e [Weerawarana].<br />

49


Tecnologie <strong>per</strong> IDN e <strong>Storage</strong> Interface Service Oriented Architecture<br />

che appartengono a <strong>di</strong>fferenti proprietari e ci aiuta ad affrontare i problemi<br />

<strong>di</strong> eterogeneità.<br />

I gran<strong>di</strong> sistemi <strong>in</strong>fatti usano piattaforme e l<strong>in</strong>guaggi <strong>di</strong> programmazione<br />

<strong>di</strong>fferenti, girano su network che non sono controllati da un s<strong>in</strong>golo responsab<strong>il</strong>e<br />

e “ut<strong>il</strong>izzano ed organizzano capacità <strong>di</strong>stribuite” [OasisSOA06].<br />

A <strong>di</strong>fferenza <strong>di</strong> altri approcci ai sistemi <strong>di</strong>stribuiti, le SOA si caratterizzano<br />

<strong>per</strong>ché tra i presupposti <strong>di</strong> progettazione si accetta l’eterogeneità. Solitamente<br />

f<strong>in</strong>o ad ora era tipico pensare <strong>di</strong> risolvere i problemi <strong>di</strong> compatib<strong>il</strong>ità<br />

e d’<strong>in</strong>tero<strong>per</strong>ab<strong>il</strong>ità tra sistemi e applicazioni semplicemente adottando un’unica<br />

soluzione ed elim<strong>in</strong>ando le <strong>di</strong>fferenze (“usiamo tutti Java”, “usiamo tutti<br />

.NET”etc.), ma questi approcci, vuoi <strong>per</strong> motivi commerciali, vuoi <strong>per</strong> motivi<br />

tecnici non hanno funzionano <strong>in</strong> assoluto.<br />

L’approccio SOA parte dal presupposto che l’eterogeneità non si può elim<strong>in</strong>are,<br />

se poi <strong>il</strong> nostro sistema è omogeneo tanto meglio.<br />

Alla base delle Service Oriented Architecture ci sono tre concetti fondamentali:<br />

i servizi, l’<strong>in</strong>tero<strong>per</strong>ab<strong>il</strong>ità e <strong>il</strong> loose coupl<strong>in</strong>g.<br />

Sv<strong>il</strong>uppare software significa astrarre la realtà. In <strong>in</strong>formatica si può astrarre<br />

da <strong>di</strong>versi punti <strong>di</strong> vista, le SOA <strong>per</strong>ò, con <strong>il</strong> concetto <strong>di</strong> servizio, si<br />

concentrano sugli aspetti che riguardano l’astrazione da un punto <strong>di</strong> vista<br />

del bus<strong>in</strong>ess: un servizio è una rappresentazione <strong>di</strong> una qualche funzionalità<br />

reale, come ad esempio “l’or<strong>di</strong>ne <strong>di</strong> un cliente”, e non un’astrazione tecnica<br />

come “la connessione a server”.<br />

Conseguentemente a questo, un servizio deve essere progettato <strong>in</strong> modo che<br />

le sue <strong>in</strong>terfacce possano essere comprese da chi le ut<strong>il</strong>izza, dagli utenti f<strong>in</strong>ali,<br />

dai non addetti al settore, senza che complicati aspetti tecnici traspaiano. Il<br />

vantaggio è che a questo livello <strong>di</strong> astrazione non <strong>in</strong>teressano più i dettagli<br />

<strong>di</strong>pendenti dalle specifiche piattaforme e può esserci eterogeneità tra <strong>di</strong> esse.<br />

Connettere sistemi eterogenei significa <strong>in</strong>tero<strong>per</strong>ab<strong>il</strong>ità. Sistemi eterogenei<br />

sono <strong>in</strong>tero<strong>per</strong>ab<strong>il</strong>i se possono funzionare <strong>in</strong>sieme, ad esempio scambiandosi<br />

risorse o <strong>in</strong>vocando funzioni remote.<br />

50


Tecnologie <strong>per</strong> IDN e <strong>Storage</strong> Interface Service Oriented Architecture<br />

L’<strong>in</strong>tero<strong>per</strong>ab<strong>il</strong>ità richiede <strong>per</strong>ò che vi sia tolleranza ai guasti: <strong>in</strong>fatti, <strong>in</strong><br />

un sistema <strong>di</strong>stribuito complesso è <strong>di</strong>ffic<strong>il</strong>e garantire la robustezza 2 poiché<br />

spesso non è fac<strong>il</strong>e, se non ad<strong>di</strong>rittura impossib<strong>il</strong>e, poter co<strong>in</strong>volgere tutte le<br />

parti <strong>per</strong> le procedure <strong>di</strong> verifica e <strong>di</strong> test del sistema. Gli imprevisti sono<br />

comuni ed è necessario che vi sia tolleranza <strong>per</strong>ché altrimenti anche piccole<br />

banalità potrebbero mandare <strong>in</strong> crisi l’<strong>in</strong>tero apparato.<br />

La chiave <strong>per</strong> raggiungere l’<strong>in</strong>tero<strong>per</strong>ab<strong>il</strong>ità è <strong>il</strong> loose coupl<strong>in</strong>g, <strong>in</strong> altre<br />

parole “<strong>di</strong>saccoppiamento”. Significa ridurre le <strong>di</strong>pendenze ai m<strong>in</strong>imi term<strong>in</strong>i,<br />

così che gli effetti <strong>di</strong> mo<strong>di</strong>fiche o imprevisti abbia meno <strong>in</strong>fluenza ed i sistemi<br />

possano restare o<strong>per</strong>ativi anche se parti <strong>di</strong> essi sono fuori uso. Il loose coupl<strong>in</strong>g<br />

contribuisce alla tolleranza ai guasti e alla flessib<strong>il</strong>ità, e grazie ad esso la<br />

progettazione prende strade che evitano colli <strong>di</strong> bottiglia che ostacolerebbero<br />

la scalab<strong>il</strong>ità.<br />

Un modo <strong>per</strong> <strong>in</strong>trodurre <strong>il</strong> loose coupl<strong>in</strong>g è evitare la centralizzazione più<br />

<strong>di</strong> quanto non sia necessario, ma sfortunatamente almeno un po’ <strong>di</strong> centralità<br />

è necessaria.<br />

La progettazione <strong>di</strong> architetture SOA passa dalla pratica del loose coupl<strong>in</strong>g:<br />

<strong>in</strong> tabella 3.1 sono elencati alcuni esempi pratici che <strong>il</strong>lustrano <strong>il</strong> concetto <strong>di</strong><br />

<strong>di</strong>saccoppiamento.<br />

Ogni forma <strong>di</strong> <strong>di</strong>saccoppiamento tuttavia porta con sé delle contro<strong>in</strong><strong>di</strong>cazioni.<br />

Per questa ragione è necessario fare scelte solo dopo un attento esame<br />

delle conseguenze e <strong>il</strong> loose coupl<strong>in</strong>g non dovrebbe essere mai considerato<br />

come f<strong>in</strong>e a sé stante.<br />

3.1.2 Ingre<strong>di</strong>enti<br />

Per stab<strong>il</strong>ire una SOA non è sufficiente <strong>in</strong>trodurre servizi, <strong>in</strong>tero<strong>per</strong>ab<strong>il</strong>ità<br />

e <strong>di</strong>saccoppiamento nella nostra architettura. È necessario trovare anche<br />

<strong>il</strong> giusto grado <strong>di</strong> centralità, aver cura dei processi, e progettare le<br />

<strong>in</strong>frastrutture.<br />

2 La robustezza <strong>in</strong> <strong>in</strong>formatica è la qualità <strong>di</strong> un sistema <strong>di</strong> resistere a situazioni<br />

impreviste non contemplate dalle specifiche.<br />

51


Tecnologie <strong>per</strong> IDN e <strong>Storage</strong> Interface Service Oriented Architecture<br />

Accoppiamento Stretto<br />

Connessioni fisiche Punto-Punto Tramite me<strong>di</strong>atore<br />

St<strong>il</strong>e <strong>di</strong> Comunicazione S<strong>in</strong>crono As<strong>in</strong>crono<br />

Data Model<br />

Tipi complessi comuni Solo tipi semplici<br />

Tipizzazione del sistema Forte Debole<br />

Pattern <strong>di</strong> <strong>in</strong>terazione<br />

Controllo della logica dei<br />

processi<br />

B<strong>in</strong><strong>di</strong>ng<br />

Navigazione attraverso oggetti<br />

ad albero complessi<br />

Loose copl<strong>in</strong>g<br />

Centrale Distribuito<br />

Statico D<strong>in</strong>amico<br />

Incentrata sui dati, messaggi<br />

autocontenuti<br />

Piattaforma Forti <strong>di</strong>pendenze da<br />

piattaforma<br />

In<strong>di</strong>pendente dalla piattaforma<br />

Transazioni Commit <strong>in</strong> due fasi<br />

Compensazione<br />

Deployment<br />

Versionamento<br />

Simultaneo In tempi <strong>di</strong>fferenti<br />

Aggiornamenti espliciti Aggiornamenti Impliciti<br />

Tabella 3.1: Esempi pratici <strong>di</strong> loose coupl<strong>in</strong>g<br />

È nelle <strong>in</strong>frastrutture che si rende concreto tecnicamente <strong>il</strong> concetto<br />

d’<strong>in</strong>tero<strong>per</strong>ab<strong>il</strong>ità.<br />

Nelle SOA la chiave <strong>per</strong> le <strong>in</strong>frastrutture è l’Entrerprise Service Bus (ESB)<br />

che <strong>per</strong>mette <strong>di</strong> <strong>in</strong>vocare servizi tra sistemi <strong>di</strong>fferenti. Un’ESB è uno strato<br />

software <strong>di</strong> astrazione basato su un sistema <strong>di</strong> messaggistica che è responsab<strong>il</strong>e<br />

della trasformazione delle <strong>in</strong>formazioni, del rout<strong>in</strong>g, del monitoraggio, del<br />

logg<strong>in</strong>g e ha a che fare con la sicurezza, l’affidab<strong>il</strong>ità, l’amm<strong>in</strong>istrazione dei<br />

servizi e spesso anche con tecnologie <strong>di</strong> workflow e bus<strong>in</strong>ess process model<strong>in</strong>g<br />

<strong>per</strong> l’<strong>in</strong>tegrazione dei flussi aziendali.<br />

Tutte le possib<strong>il</strong>ità offerte dalle SOA si concretizzano nelle architetture,<br />

le quali formano un sistema funzionante e manutenib<strong>il</strong>e. Per formalizzare<br />

un’architettura si deve classificare i <strong>di</strong>fferenti tipi <strong>di</strong> servizi, decidere la quantità<br />

<strong>di</strong> <strong>di</strong>saccoppiamento, limitare <strong>il</strong> data model delle <strong>in</strong>terfacce ai servizi,<br />

def<strong>in</strong>ire politiche, regole e pattern, chiarire ruoli e responsab<strong>il</strong>ità, decidere<br />

l’<strong>in</strong>frastruttura tecnologica e quali standard usare.<br />

Nelle architetture è necessario poi stab<strong>il</strong>ire i processi appropriati. Per<br />

processo si <strong>in</strong>tende una generica sequenza <strong>di</strong> passi <strong>per</strong> sod<strong>di</strong>sfare una necessità<br />

52


Tecnologie <strong>per</strong> IDN e <strong>Storage</strong> Interface Service Oriented Architecture<br />

o raggiungere un qualche obiettivo.<br />

Ci sono <strong>di</strong>versi processi che entrano <strong>in</strong> gioco quando si progetta e si realizza<br />

una SOA: i processi che modellano la bus<strong>in</strong>ess logic (BPM, Bus<strong>in</strong>ess<br />

Process Model<strong>in</strong>g), i processi che def<strong>in</strong>iscono <strong>il</strong> ciclo <strong>di</strong> vita <strong>di</strong> un servizio<br />

(Service Lifecycle) e quelli che determ<strong>in</strong>ano la produzione del software <strong>per</strong><br />

i modelli ipotizzati (MDSD, Model-driven Software Development). Inoltre,<br />

<strong>il</strong> processo <strong>di</strong> mettere <strong>in</strong>sieme tutti i processi prende <strong>il</strong> nome <strong>di</strong> governance.<br />

Con questo term<strong>in</strong>e ci si riferisce anche alle attività <strong>di</strong> ricerca <strong>di</strong> <strong>per</strong>sonale<br />

<strong>per</strong> lo sv<strong>il</strong>uppo, dei sistemisti che si occu<strong>per</strong>anno della manutenzione delle<br />

macch<strong>in</strong>e, dei responsab<strong>il</strong>i del <strong>per</strong>sonale etc.<br />

3.1.3 Term<strong>in</strong>ologia<br />

Prima <strong>di</strong> analizzare più nel dettaglio <strong>il</strong> concetto <strong>di</strong> servizio è ut<strong>il</strong>e fare alcuni<br />

chiarimenti sulla term<strong>in</strong>ologia usata nelle Service Oriented Architecture.<br />

Si usano i term<strong>in</strong>i provider e consumer <strong>per</strong> <strong>in</strong><strong>di</strong>care i ruoli dei sistemi<br />

che comunicano tramite servizi:<br />

• Provider è un sistema che implementa un servizio cosicché un altro<br />

sistema lo possa <strong>in</strong>vocare<br />

• Consumer è un sistema che <strong>in</strong>voca un servizio<br />

• Il term<strong>in</strong>e partecipant, ovvero partecipante, <strong>in</strong><strong>di</strong>ca sia un provider sia<br />

un consumer<br />

Si preferisce usare questi term<strong>in</strong>i <strong>in</strong>vece <strong>di</strong> client e server poiché sono più<br />

<strong>in</strong><strong>di</strong>cati nel contesto dei servizi SOA. Tuttavia nel caso più <strong>di</strong>ffuso un provider<br />

è <strong>il</strong> server dei servizi, mentre <strong>il</strong> consumer è <strong>il</strong> client che li usa.<br />

Per choreography si <strong>in</strong>tende l’aggregare i servizi <strong>per</strong> formare processi<br />

che implementano la bus<strong>in</strong>ess-logic. La choreography def<strong>in</strong>isce le regole e le<br />

politiche che <strong>per</strong>mettono ai servizi <strong>di</strong> collaborare. Ogni servizio co<strong>in</strong>volto<br />

vede e contribuisce solo a una parte del processo.<br />

Per orchestration si <strong>in</strong>tende <strong>il</strong> comporre più servizi <strong>in</strong> uno nuovo con un<br />

controllo centrale sull’<strong>in</strong>tero processo.<br />

53


Tecnologie <strong>per</strong> IDN e <strong>Storage</strong> Interface Service Oriented Architecture<br />

3.1.4 Servizi<br />

Il term<strong>in</strong>e servizio ha <strong>il</strong> significato <strong>di</strong> “attività svolta da qualcuno <strong>per</strong> qualcun<br />

altro”. In ambito SOA un servizio è una realizzazione <strong>di</strong> una funzionalità<br />

del bus<strong>in</strong>ess con una tecnologia <strong>in</strong>formatica.<br />

Il f<strong>in</strong>e primario <strong>di</strong> un servizio è rappresentare un passo <strong>di</strong> una funzione<br />

del bus<strong>in</strong>ess <strong>per</strong> <strong>il</strong> mondo reale, <strong>in</strong> altre parole i non addetti ai lavori devono<br />

essere capaci <strong>di</strong> capire <strong>il</strong> suo compito e gli aspetti tecnici dovrebbero rimanere<br />

trasparenti. Esistono comunque servizi, classificati come “tecnici”, che non<br />

rispettano questo pr<strong>in</strong>cipio.<br />

Da un punto <strong>di</strong> vista applicativo, un servizio è un’<strong>in</strong>terfaccia <strong>per</strong> scambiare<br />

messaggi che restituiscono o cambiano lo stato <strong>di</strong> una qualche entità.<br />

Yefim V. Natis afferma [Natis03]:<br />

“Un nome migliore <strong>per</strong> le SOA sarebbe Interface Oriented Architecture”.<br />

Spesso la creazione <strong>di</strong> un’architettura software basata su SOA com<strong>in</strong>cia<br />

dalla def<strong>in</strong>izione <strong>di</strong> un’<strong>in</strong>terfaccia sulla quale si costruiscono le applicazioni.<br />

I servizi possono essere caratterizzati da molti tipi <strong>di</strong> attributi, tuttavia<br />

non è chiaro quali siano obbligatori e quali opzionali <strong>per</strong> una SOA. Si può<br />

avere a che fare con servizi auto-contenuti, a grana grossa, visib<strong>il</strong>i, senza<br />

stato, idempotenti, riut<strong>il</strong>izzab<strong>il</strong>i, componib<strong>il</strong>i.<br />

Tutte le def<strong>in</strong>izioni <strong>di</strong> SOA concordano che sia una f<strong>in</strong>alità <strong>di</strong> un servizio<br />

l’essere auto-contenuto (<strong>in</strong><strong>di</strong>pendente, autonomo). Alcune <strong>di</strong>pendenze tuttavia<br />

non sono elim<strong>in</strong>ab<strong>il</strong>i qu<strong>in</strong><strong>di</strong> l’obiettivo va <strong>in</strong>terpretato come ridurre le<br />

<strong>di</strong>pendenze ai m<strong>in</strong>imi term<strong>in</strong>i, e qu<strong>in</strong><strong>di</strong> è <strong>di</strong>rettamente collegato al concetto<br />

<strong>di</strong> <strong>di</strong>saccoppiamento.<br />

I servizi sono un’astrazione che nasconde i dettagli implementativi all’ut<strong>il</strong>izzatore<br />

e spesso questo si paga con tempi <strong>di</strong> trasmissione ed elaborazione<br />

più lunghi. Per questo è meglio avere un’unica chiamata al servizio che trasferisca<br />

tutte le <strong>in</strong>formazioni. Una grana grossa aiuta a separare la struttura<br />

54


Tecnologie <strong>per</strong> IDN e <strong>Storage</strong> Interface Service Oriented Architecture<br />

<strong>in</strong>terna dei dati <strong>di</strong> un provider <strong>per</strong> servizi dalla sua <strong>in</strong>terfaccia esterna ma <strong>il</strong><br />

problema è def<strong>in</strong>ire quando la grana è grossa, <strong>in</strong>fatti si ha spesso un’elaborazione<br />

<strong>di</strong> dati che non sono necessari, con conseguente spreco <strong>di</strong> risorse e <strong>di</strong><br />

tempo.<br />

Un’altra proprietà dei servizi è la loro visib<strong>il</strong>ità. Per chiamare un servizio<br />

si deve sa<strong>per</strong>e che esso esiste.<br />

Un servizio stateless non mantiene traccia tra una chiamata e un’altra.<br />

Un servizio può avere uno stato dal punto <strong>di</strong> vista tecnico e dal punto <strong>di</strong><br />

vista del bus<strong>in</strong>ess. Se i servizi debbano non mantenere uno stato <strong>di</strong>pende da<br />

molti fattori e dalla situazione <strong>in</strong> cui si usano.<br />

L’idempotenza è l’ab<strong>il</strong>ità <strong>di</strong> rieseguire un’o<strong>per</strong>azione se non siete sicuri<br />

che questa sia stata completata. Se <strong>il</strong> servizio è idempotente, dopo una<br />

richiesta alla quale non si è ricevuto risposta <strong>di</strong> conferma, si può rimandare<br />

la chiamata senza temere che questa comporti effetti desiderati.<br />

Ci sono casi <strong>in</strong> cui ottenere l’idempotenza è <strong>di</strong>ffic<strong>il</strong>e, ma <strong>in</strong> un’architettura<br />

SOA semplifica molti altri aspetti, qu<strong>in</strong><strong>di</strong> è sempre opportuno porsi<br />

l’obiettivo <strong>di</strong> realizzare servizi che hanno questa proprietà.<br />

Un servizio SOA dovrebbe essere riut<strong>il</strong>izzab<strong>il</strong>e. Evitare la ridondanza è<br />

un obiettivo generale dello sv<strong>il</strong>uppo del software. Idealmente ogni funzionalità<br />

dovrebbe essere implementata una sola volta. Un caso tipico <strong>di</strong> riut<strong>il</strong>izzo<br />

<strong>in</strong> ambito SOA è quando tutti i sistemi chiamano lo stesso servizio <strong>per</strong> una<br />

certa funzione. Ci sono dei limiti a quest’approccio che pr<strong>in</strong>cipalmente <strong>di</strong>pendono<br />

dalle esigenze <strong>di</strong> <strong>per</strong>formance e qu<strong>in</strong><strong>di</strong> è opportuno <strong>in</strong><strong>di</strong>viduare <strong>il</strong><br />

giusto trade-off tra riut<strong>il</strong>izzo e prestazioni.<br />

Una funzionalità, quando necessario, può essere sud<strong>di</strong>visa <strong>in</strong> passi più piccoli<br />

che sono rappresentati da servizi. Questi possono qu<strong>in</strong><strong>di</strong> essere composti<br />

tra <strong>di</strong> loro. Questa composizione è alla base della modellazione dei processi<br />

del bus<strong>in</strong>ess.<br />

55


Tecnologie <strong>per</strong> IDN e <strong>Storage</strong> Interface Web Service<br />

Inoltre, i servizi possono essere caratterizzati da attributi non funzionali<br />

come la Quality of Service (QoS), le con<strong>di</strong>zioni <strong>di</strong> ut<strong>il</strong>izzo possono essere<br />

v<strong>in</strong>colate da un Service Level Agreement (SLA) e possono avere un<br />

comportamento semantico specificato dalle pre-con<strong>di</strong>zioni e dalle postcon<strong>di</strong>zioni,<br />

3.1.5 Considerazioni conclusive<br />

Le SOA non sono una soluzione adottab<strong>il</strong>e <strong>in</strong> ogni circostanza: <strong>il</strong> loro<br />

ut<strong>il</strong>izzo è ideale quando abbiamo a che fare con sistemi <strong>di</strong>stribuiti eterogenei<br />

appartenenti a organizzazioni <strong>di</strong>verse, altrimenti la complessità aggiunta<br />

potrebbe comportare un costo <strong>in</strong>ut<strong>il</strong>e.<br />

Nella prossima sezione esam<strong>in</strong>eremo nel dettaglio i Web Service. Molte<br />

def<strong>in</strong>izioni <strong>di</strong> SOA <strong>in</strong>cludono <strong>il</strong> term<strong>in</strong>e <strong>di</strong> Web Service, ma i due concetti<br />

sono <strong>in</strong> verità autonomi. SOA è un para<strong>di</strong>gma, i Web Service sono un modo<br />

possib<strong>il</strong>e <strong>per</strong> realizzare delle <strong>in</strong>frastrutture e si possono usare <strong>per</strong> creare delle<br />

Service Oriented Architecture. Anche se i Web Service stanno emergendo<br />

come lo standard <strong>di</strong> fatto <strong>per</strong> le implementazioni, si possono formulare SOA<br />

basate su molte altre tecnologie (CORBA, MQ, Tibco, ecc).<br />

3.2 Web Service<br />

Il W3C fornisce la seguente def<strong>in</strong>izione:<br />

“Un Web Service è un sistema software progettato <strong>per</strong> supportare<br />

un’<strong>in</strong>terazione <strong>in</strong>tero<strong>per</strong>ab<strong>il</strong>e tra macch<strong>in</strong>e su reti <strong>in</strong>formatiche.<br />

Ha un’<strong>in</strong>terfaccia descritta <strong>in</strong> un formato processab<strong>il</strong>e dagli<br />

elaboratori (nello specifico, usando WSDL).<br />

Altri sistemi <strong>in</strong>teragiscono con <strong>il</strong> Web Service come prescritto<br />

dalla sua descrizione, ut<strong>il</strong>izzando messaggi SOAP, tipicamente<br />

trasportati con HTTP usando una serializzazione XML <strong>in</strong> congiunzione<br />

con altri standard correlati al Web.” [WSArch]<br />

Più <strong>in</strong> generale <strong>il</strong> term<strong>in</strong>e è usato <strong>per</strong> riferirsi ad un <strong>in</strong>sieme <strong>di</strong> standard,<br />

e talvolta nei servizi SOAP non è neanche ut<strong>il</strong>izzato. Questi standard def<strong>in</strong>iscono<br />

sia i protocolli usati <strong>per</strong> la comunicazione, sia <strong>il</strong> formato delle <strong>in</strong>terfacce<br />

usate <strong>per</strong> specificare i servizi.<br />

56


Tecnologie <strong>per</strong> IDN e <strong>Storage</strong> Interface Web Service<br />

Il term<strong>in</strong>e è stato coniato dalla Microsoft nel 2000 <strong>per</strong> descrivere un <strong>in</strong>sieme<br />

<strong>di</strong> tecnologie <strong>di</strong> comunicazione basate su eXtensible Markup Language<br />

(XML) e Hy<strong>per</strong>text Transmission Protocol (HTTP). A questi due<br />

standard si è aggiunto SOAP, sv<strong>il</strong>uppato <strong>in</strong>izialmente dalla stessa Microsoft,<br />

che usa XML <strong>per</strong> scambiare <strong>in</strong>formazioni su una connessione basata<br />

su HTTP e TCP/IP. Grazie all’apporto <strong>di</strong> IBM sono nati <strong>il</strong> Web Service<br />

Description Language (WSDL) e l’Universal Description Discovery<br />

and Innovation (UDDI), e alla f<strong>in</strong>e del 2000 i Web Service erano<br />

ufficialmente adottati e supportati da Oracle, HP e Sun.<br />

Oggi questo movimento è sostenuto da <strong>di</strong>verse compagnie, riunite <strong>in</strong> tre<br />

organizzazioni che curano la stesura delle specifiche: <strong>il</strong> W3C 3 , OASIS 4 e<br />

WS-I 5 .<br />

Esistono più <strong>di</strong> c<strong>in</strong>quanta standard specificati da queste tre organizzazioni.<br />

Il prospetto <strong>in</strong> figura 3.1 6 offre una panoramica della moltitu<strong>di</strong>ne <strong>di</strong> standard<br />

che ruotano <strong>in</strong>torno a questa tecnologia.<br />

Fra tutti questi, i fondamentali sono XML, HTTP, WSDL, SOAP e UDDI:<br />

• XML è usato come formato generale <strong>per</strong> descrivere i modelli e i tipi dei<br />

dati<br />

• HTTP è <strong>il</strong> protocollo <strong>di</strong> basso livello usato <strong>per</strong> comunicare<br />

• WSDL è usato <strong>per</strong> def<strong>in</strong>ire le <strong>in</strong>terfacce<br />

• SOAP è un protocollo specifico <strong>per</strong> scambiare messaggi<br />

• UDDI è lo standard <strong>per</strong> gestire <strong>il</strong> Web Service<br />

3 World Wide Web Consortium, http://www.w3.org/, è <strong>il</strong> responsab<strong>il</strong>e dei pr<strong>in</strong>cipali<br />

standard dei Web Service, ovvero XML, WSDL e SOAP<br />

4 Organization for the Advancement of Structured Information Standards, http://<br />

www.oasis-open.org/<br />

5 Web Service Intero<strong>per</strong>ab<strong>il</strong>ity Organization, http://www.ws-i.org/<br />

6 Si r<strong>in</strong>grazia Thomas Sutter <strong>per</strong> la concessione all’ut<strong>il</strong>izzo della figura. Il poster<br />

orig<strong>in</strong>ale è <strong>di</strong>sponib<strong>il</strong>e su http://www.<strong>in</strong>noq.com/.<br />

57


Tecnologie <strong>per</strong> IDN e <strong>Storage</strong> Interface Web Service<br />

Figura 3.1: “Web Services Standards as of Q1 2007 by <strong>in</strong>noQ”<br />

58


Tecnologie <strong>per</strong> IDN e <strong>Storage</strong> Interface Web Service<br />

Gli altri standard, a cui spesso ci si riferisce con <strong>il</strong> term<strong>in</strong>e WS-* poiché<br />

molti hanno un nome che com<strong>in</strong>cia con questa sigla, trattano aspetti <strong>di</strong><br />

<strong>in</strong>tero<strong>per</strong>ab<strong>il</strong>ità (WS-I Basic Prof<strong>il</strong>e, WS-I Basic Security Prof<strong>il</strong>e), specifica<br />

dei processi del bus<strong>in</strong>ess (BPEL), aspetti <strong>di</strong> sicurezza (XML Signature,<br />

XML Encryption, WS-Security, WS-Trust, WS-Federation, Web Services<br />

Security Kerberos B<strong>in</strong><strong>di</strong>ng, Web S<strong>in</strong>gle Sign-On Intero<strong>per</strong>ab<strong>il</strong>ity Prof<strong>il</strong>e), affidab<strong>il</strong>ità,<br />

transazioni, messaggistica, pubblicazione e sottoscrizione<br />

(WS-ReliableMessag<strong>in</strong>g, WS-Reliab<strong>il</strong>ity, WS-Coor<strong>di</strong>nation, WS-Transaction,<br />

WS-Notification, WS-Event<strong>in</strong>g) 7 .<br />

Realizzare un servizio che possa essere def<strong>in</strong>ito come Web Service vuol <strong>di</strong>re<br />

ado<strong>per</strong>are alcune <strong>di</strong> queste tecnologie <strong>in</strong> fase <strong>di</strong> progettazione o implementazione.<br />

L’unico standard fondamentale è WSDL tutti gli altri sono opzionali.<br />

Ad esempio non è necessario usare SOAP e nemmeno HTTP.<br />

Si comunica con un Web Service effettuando chiamate alle o<strong>per</strong>azioni della<br />

sua <strong>in</strong>terfaccia. La comunicazione è protocol-driven e <strong>di</strong> tipo po<strong>in</strong>t-to-po<strong>in</strong>t.<br />

Il vantaggio <strong>di</strong> una comunicazione p<strong>il</strong>otata dal protocollo è che provider e<br />

consumer possono ut<strong>il</strong>izzare strumenti <strong>di</strong>fferenti <strong>per</strong> le chiamate al servizio.<br />

Spesso, nelle SOA, si usano Web Service <strong>in</strong>terme<strong>di</strong>ari <strong>per</strong> <strong>di</strong>saccoppiare tra<br />

<strong>di</strong> loro i servizi (ve<strong>di</strong> pag<strong>in</strong>a 51).<br />

Questi aspetti nella pratica si amm<strong>in</strong>istrano tramite <strong>il</strong> WSDL: esistono<br />

8 , <strong>in</strong> tutti i più <strong>di</strong>ffusi l<strong>in</strong>guaggi <strong>di</strong> programmazione, strumenti o librerie<br />

che analizzando <strong>il</strong> f<strong>il</strong>e che descrive <strong>il</strong> servizio e generano <strong>il</strong> co<strong>di</strong>ce necessario a<br />

gestirne gli aspetti <strong>in</strong>frastrutturali, sia lato server che lato client. Questi strumenti<br />

si occupano delle questioni <strong>di</strong> comunicazione, così che i programmatori<br />

debbano curarsi soltanto degli aspetti <strong>di</strong> logica delle applicazioni.<br />

3.2.1 WSDL<br />

Web Services Description Languages (WSDL) è lo standard usato <strong>per</strong><br />

descrivere un Web Service. Come abbiamo visto <strong>in</strong> 3.1.4, un servizio è tecnicamente<br />

una <strong>in</strong>terfaccia <strong>per</strong> scambiare messaggi che variano lo stato <strong>di</strong> una<br />

qualche entità oppure <strong>per</strong>mettono <strong>il</strong> trasferimento <strong>di</strong> una risorsa.<br />

7 Per una panoramica completa si veda http://en.wikipe<strong>di</strong>a.org/wiki/WS-*<br />

8 http://en.wikipe<strong>di</strong>a.org/wiki/List_of_Web_service_Frameworks<br />

59


Tecnologie <strong>per</strong> IDN e <strong>Storage</strong> Interface Web Service<br />

Di fatto <strong>il</strong> WSDL è un l<strong>in</strong>guaggio che descrive le <strong>in</strong>terfacce <strong>di</strong> Web Service<br />

tramite la specifica delle o<strong>per</strong>azioni, dei tipi <strong>di</strong> dati, dei meccanismi <strong>di</strong><br />

trasporto e dei punti <strong>di</strong> accesso al servizio.<br />

WSDL usa una s<strong>in</strong>tassi XML, ovvero un f<strong>il</strong>e “.wsdl” è un f<strong>il</strong>e XML conforme<br />

all’XML Schema def<strong>in</strong>ito <strong>in</strong> http://schemas.xmlsoap.org/wsdl/<br />

oppure <strong>in</strong> http://www.w3.org/2002/ws/desc/ns/wsdl20.xsd e che ha una<br />

semantica def<strong>in</strong>ita <strong>in</strong> [WSDL1.1] o [WSDL2]. Esistono <strong>in</strong>fatti due versioni<br />

importanti <strong>di</strong> questo standard: WSDL 1.1 e WSDL 2.0.<br />

La versione 1.1 è l’evoluzione <strong>di</strong>retta del primo standard, lo 1.0, sv<strong>il</strong>uppato<br />

da Microsoft ed IBM nel 2000. A marzo del seguente anno le stesse<br />

sottoposero le specifiche al W3C XML Activity Group, e queste furono pubblicate<br />

come “W3C Note” 9 con numero <strong>di</strong> revisione 1.1 ma praticamente<br />

senza nessuna mo<strong>di</strong>fica r<strong>il</strong>evante 10 .<br />

Subito dopo, <strong>il</strong> W3C ha de<strong>di</strong>cato un gruppo <strong>di</strong> lavoro allo sv<strong>il</strong>uppo <strong>di</strong> una<br />

sua versione, <strong>il</strong> WSDL 1.2, del quale la prima bozza è stata pubblicata a luglio<br />

dell’anno successivo. Per le sostanziali <strong>di</strong>fferenze dalla versione precedente<br />

fu deciso <strong>di</strong> r<strong>in</strong>umerare lo standard come WSDL 2.0, <strong>il</strong> quale dopo un lungo<br />

travaglio, è <strong>di</strong>venuto da poco una “W3C Recommendation” 11 , <strong>in</strong> data 26<br />

giugno 2007. Per questo motivo, ancora, <strong>il</strong> WSDL 2.0 non gode <strong>di</strong> molta<br />

<strong>di</strong>ffusione 12 e non è supportato dai più importanti strumenti <strong>di</strong> sv<strong>il</strong>uppo<br />

de<strong>di</strong>cati ai Web Service.<br />

Le due versioni comunque sono concettualmente sim<strong>il</strong>i. La maggior parte<br />

delle <strong>in</strong>novazioni riguardano la s<strong>in</strong>tassi, l’estensib<strong>il</strong>ità, ed <strong>il</strong> supporto a<br />

protocolli <strong>di</strong>versi da SOAP.<br />

9 Una W3C Note è un documento reso <strong>di</strong>sponib<strong>il</strong>e dal W3C soltanto <strong>per</strong> <strong>di</strong>scussioni.<br />

La sua pubblicazione non implica <strong>il</strong> supporto del W3C o dei suoi membri.<br />

10 Si può trovare la specifica 1.0 all’<strong>in</strong><strong>di</strong>rizzo http://xml.coverpages.org/<br />

wsdl20000929.html. La nota ufficiale del W3C [WSDL1.1] è pubblicata all’<strong>in</strong><strong>di</strong>rizzo<br />

http://www.w3.org/TR/wsdl. I due documenti sono praticamente identici.<br />

11 Una W3C Recommendation è lo stage f<strong>in</strong>ale del processo <strong>di</strong> ratificazione <strong>di</strong> un grup-<br />

po <strong>di</strong> lavoro del World Wide Web Consortium.<br />

È equivalente alla pubblicazione <strong>di</strong> uno<br />

standard <strong>in</strong>dustriale.<br />

12 Il supporto al WSDL 2.0 è rimasto escluso dall’ultima versione della “Java API<br />

for XML Web Services” a causa dei ritar<strong>di</strong> nella sua ratificazione a raccomandazione<br />

[JAX-WS21]. La JAX-WS 2.1 è stata <strong>in</strong>fatti r<strong>il</strong>asciata <strong>il</strong> 7 maggio 2007, e sebbene <strong>il</strong> supporto<br />

a WSDL 2.0 fosse tra i goals, l’ex<strong>per</strong>t group ha deciso rimandare ad una revisione<br />

futura della API.<br />

60


Tecnologie <strong>per</strong> IDN e <strong>Storage</strong> Interface Web Service<br />

Struttura e ciclo <strong>di</strong> vita<br />

Il WSDL descrive i servizi dall’alto verso <strong>il</strong> basso, ovvero parte dai tipi <strong>di</strong><br />

dati ut<strong>il</strong>izzati e f<strong>in</strong>isce con l’<strong>in</strong><strong>di</strong>rizzo del servizio. Ci sono quattro strati nella<br />

descrizione (ve<strong>di</strong> figura 3.2):<br />

• Il primo strato descrive i tipi <strong>di</strong> dati ed i messaggi<br />

• Il secondo strato descrive l’<strong>in</strong>terfaccia del servizio, che consiste <strong>in</strong> una<br />

o più o<strong>per</strong>azioni i cui parametri <strong>di</strong> <strong>in</strong>put ed output ut<strong>il</strong>izzano i tipi<br />

def<strong>in</strong>iti nel primo strato<br />

• Il terzo strato descrive <strong>il</strong> b<strong>in</strong><strong>di</strong>ng ovvero <strong>il</strong> legame tra protocollo e <strong>il</strong><br />

formato con cui si forniscono le o<strong>per</strong>azioni<br />

• Il quarto strato def<strong>in</strong>isce <strong>il</strong> punto <strong>di</strong> accesso ovvero l’<strong>in</strong><strong>di</strong>rizzo con cui<br />

accedere al servizio<br />

WSDL 1.1 WSDL 2.0<br />

def<strong>in</strong>itions description<br />

types<br />

message<br />

portType<br />

o<strong>per</strong>ation<br />

<strong>in</strong>put<br />

output<br />

b<strong>in</strong><strong>di</strong>ng<br />

service<br />

port<br />

types<br />

<strong>in</strong>terface<br />

o<strong>per</strong>ation<br />

<strong>in</strong>put<br />

output<br />

b<strong>in</strong><strong>di</strong>ng<br />

service<br />

endpo<strong>in</strong>t<br />

Abstract<br />

Section<br />

Concrete<br />

Section<br />

SOAP<br />

TCP<br />

Figura 3.2: Struttura <strong>di</strong> f<strong>il</strong>e WSDL 1.1 e WSDL 2.0<br />

Java-API<br />

.NET-API<br />

C++ API<br />

PHP-API<br />

XML-RPC<br />

HTTP<br />

I primi due strati compongono la parte astratta del WSDL, gli altri<br />

la parte concreta. Sv<strong>il</strong>uppare un Web Service basato su WSDL significa<br />

mappare questa parte astratta ad una API, <strong>in</strong> un qualche l<strong>in</strong>guaggio <strong>di</strong><br />

programmazione: i consumer <strong>in</strong>vocheranno meto<strong>di</strong> <strong>di</strong> questa API, i provider<br />

61


Tecnologie <strong>per</strong> IDN e <strong>Storage</strong> Interface Web Service<br />

<strong>in</strong>vece forniranno i servizi implementando l’<strong>in</strong>terfaccia. Infatti la descrizione<br />

dei tipi e delle o<strong>per</strong>azioni <strong>in</strong> WSDL avviene a presc<strong>in</strong>dere dai l<strong>in</strong>guaggi <strong>di</strong><br />

programmazione o dai protocolli <strong>di</strong> trasporto.<br />

Nella parte concreta, i b<strong>in</strong><strong>di</strong>ng def<strong>in</strong>iscono la comunicazione tra provider<br />

e consumer. Ci sono molti framework <strong>in</strong> <strong>di</strong>versi l<strong>in</strong>guaggi <strong>di</strong> programmazione<br />

che forniscono strumenti che processano <strong>il</strong> f<strong>il</strong>e, generano le classi, le funzioni<br />

o le librerie nello specifico l<strong>in</strong>guaggio e ne ricavano i dettagli necessari <strong>per</strong><br />

<strong>in</strong>staurare la comunicazione. Qu<strong>in</strong><strong>di</strong>, <strong>per</strong> i programmatori <strong>di</strong> Web Service,<br />

la comunicazione <strong>di</strong>venta più una questione <strong>di</strong> configurazione che non <strong>di</strong><br />

programmazione e molti non hanno mai a che fare <strong>di</strong>rettamente con SOAP<br />

o HTTP.<br />

Inf<strong>in</strong>e, i servizi def<strong>in</strong>iscono un elenco dei punti <strong>di</strong> accesso al quale un<br />

consumer può trovare un determ<strong>in</strong>ato b<strong>in</strong><strong>di</strong>ng dell’<strong>in</strong>terfaccia.<br />

Gli strati <strong>di</strong> cui è composto un documento WSDL, oltre a sud<strong>di</strong>videre la<br />

sua struttura da un punto <strong>di</strong> vista logico, <strong>per</strong>mettono anche <strong>di</strong> separare gli<br />

aspetti concettuali <strong>per</strong> la sua creazione. I <strong>di</strong>versi team possono occuparsi<br />

della scrittura <strong>di</strong> parti <strong>di</strong>fferenti del documento.<br />

Lo sv<strong>il</strong>uppo del f<strong>il</strong>e si svolge <strong>in</strong> quattro fasi:<br />

• Il primo passo consiste nello scrivere un documento che descrive l’<strong>in</strong>terfaccia<br />

del servizio usando soltanto i primi due livelli del WSDL. Questo<br />

lavoro è svolto sulla base dei requisiti del prodotto ed è competenza dei<br />

manager e dei responsab<strong>il</strong>i <strong>di</strong> livello più alto.<br />

• Il passo successivo riguarda l’adeguamento della prima parte del f<strong>il</strong>e<br />

alle convenzioni ut<strong>il</strong>izzate da altri servizi della SOA con cui <strong>in</strong>tegrare<br />

<strong>il</strong> prodotto. In pratica significa adottare i corretti namespace XML e<br />

ridef<strong>in</strong>ire i tipi dei dati con XML Schema specifici. Questo compito è<br />

svolto dai progettisti e dagli <strong>in</strong>gegneri del software.<br />

• Nel terzo passo si decidono gli aspetti <strong>in</strong>frastrutturali e <strong>per</strong>tanto entra<br />

<strong>in</strong> gioco <strong>il</strong> protocollo. In questa fase si usa la sezione dei b<strong>in</strong><strong>di</strong>ng del<br />

WSDL <strong>per</strong> la configurazione del servizio.<br />

• Inf<strong>in</strong>e, al momento <strong>di</strong> <strong>in</strong>stallare <strong>il</strong> servizio su un server, si comp<strong>il</strong>a la<br />

quarta parte del WSDL con l’<strong>in</strong><strong>di</strong>rizzo dell’endpo<strong>in</strong>t dove sarà possib<strong>il</strong>e<br />

raggiungerlo.<br />

I passi del ciclo <strong>di</strong> vita sono riassunti <strong>in</strong> tabella 3.2.<br />

62


Tecnologie <strong>per</strong> IDN e <strong>Storage</strong> Interface Web Service<br />

Layer<br />

Interfaccia del<br />

servizio<br />

Interfaccia con<br />

namespace e altri<br />

dettagli<br />

WSDL 1.1 WSDL 2.0 Fase <strong>di</strong> sv<strong>il</strong>uppo Ruoli <strong>di</strong> competenza<br />

<strong>Progetto</strong> prelim<strong>in</strong>are<br />

Protocollo Configurazione Infrastructure Team<br />

Punto <strong>di</strong> accesso<br />

,<br />

,<br />

<br />

,<br />

,<br />

<br />

,<br />

<br />

,<br />

<br />

<strong>Progetto</strong> del servizio<br />

e/o sv<strong>il</strong>uppo<br />

dell'implementazione<br />

Product manager e<br />

Bus<strong>in</strong>ess manager<br />

Progettisti del servizio<br />

e/o sv<strong>il</strong>uppatori<br />

Deployment e runtime Amm<strong>in</strong>istratori del<br />

sistema<br />

Tabella 3.2: Ciclo <strong>di</strong> vita del WSDL<br />

Esempio <strong>di</strong> un servizio descritto da WSDL<br />

Per capire come funziona e come è fatto un WSDL, <strong>in</strong>troduciamo un<br />

Web Service <strong>di</strong> esempio. Si ipotizza un servizio che <strong>per</strong>mette la lettura e<br />

la scrittura <strong>di</strong> una generica risorsa.<br />

In figura 3.2 è riportata una rappresentazione grafica dell’<strong>in</strong>terfaccia <strong>di</strong><br />

questo servizio.<br />

MyService<br />

GetIn<br />

GetOut<br />

Error<br />

SetIn<br />

SetOut<br />

Error<br />

MyInterface<br />

GetO<strong>per</strong>ation<br />

GetIn GetOut<br />

id data<br />

meta<br />

meta<br />

SetO<strong>per</strong>ation<br />

SetIn SetOut<br />

data<br />

id<br />

meta<br />

meta<br />

Error<br />

<strong>in</strong>fo<br />

Error<br />

<strong>in</strong>fo<br />

Figura 3.3: Esempio astratto <strong>di</strong> servizio che fornisce o<strong>per</strong>azioni <strong>di</strong> lettura e<br />

<strong>di</strong> scrittura <strong>di</strong> risorse composte da dati e più metadati.<br />

Le sue caratteristiche sono:<br />

• Il servizio gestisce un certo tipo <strong>di</strong> risorse<br />

63


Tecnologie <strong>per</strong> IDN e <strong>Storage</strong> Interface Web Service<br />

• Le risorse sono costituite da dati e da proprità (metadati).<br />

• Il servizio offre due tipi <strong>di</strong> o<strong>per</strong>azioni: lettura e scrittura.<br />

• La lettura avviene <strong>in</strong>viando l’ID della risorsa <strong>in</strong> <strong>in</strong>put ed ottenendo <strong>in</strong><br />

risposta i dati ed e le proprietà<br />

• La scrittura avviene <strong>in</strong>viando l’ID della risorsa <strong>in</strong>sieme a dati e metadati<br />

che si vuol memorizzare<br />

• Qualora si verifichi un errore, viene <strong>in</strong>viata una risposta <strong>di</strong>versa che<br />

specifica <strong>in</strong>formazioni sul problema<br />

Per rappresentare le risorse e i messaggi <strong>di</strong> questo modello si ut<strong>il</strong>izza XML<br />

Schema. I tipi si def<strong>in</strong>iscono <strong>in</strong> un f<strong>il</strong>e esterno che sarà poi importato nel<br />

WSDL della sezione dei .<br />

Il listato seguente <strong>il</strong>lustra una possib<strong>il</strong>e soluzione <strong>per</strong> la formalizzazione<br />

del data model dell’esempio presentato.<br />

<br />

<br />

<br />

<br />

<br />

<br />

<br />

<br />

<br />

<br />

<br />

<br />

<br />

<br />

<br />

<br />

64


Tecnologie <strong>per</strong> IDN e <strong>Storage</strong> Interface Web Service<br />

<br />

<br />

<br />

<br />

<br />

<br />

<br />

<br />

<br />

<br />

<br />

<br />

<br />

<br />

<br />

<br />

<br />

<br />

<br />

<br />

<br />

<br />

Questo schema XML def<strong>in</strong>isce due tipi:<br />

• <br />

• <br />

Insieme al tipo predef<strong>in</strong>ido xsd:<strong>in</strong>teger, sono usati <strong>per</strong> rappresentare le <strong>in</strong>formazioni,<br />

le proprietà e gli identificatori delle risorse.<br />

Inoltre sono def<strong>in</strong>iti c<strong>in</strong>que elementi che rappresentano i messaggi scambiati:<br />

• <br />

65


Tecnologie <strong>per</strong> IDN e <strong>Storage</strong> Interface Web Service<br />

• <br />

• <br />

• <br />

• <br />

Il servizio, basato su questi tipi <strong>di</strong> dati, può essere descritto con WSDL 1.1<br />

nel seguente modo:<br />

<br />

<br />

<br />

<br />

<br />

<br />

<br />

<br />

<br />

<br />

<br />

<br />

<br />

<br />

<br />

<br />

<br />

<br />

<br />

<br />

<br />

<br />

66


Tecnologie <strong>per</strong> IDN e <strong>Storage</strong> Interface Web Service<br />

<br />

<br />

<br />

<br />

<br />

<br />

<br />

<br />

<br />

<br />

<br />

<br />

<br />

<br />

<br />

<br />

<br />

<br />

<br />

<br />

<br />

<br />

<br />

<br />

<br />

<br />

<br />

<br />

<br />

<br />

<br />

<br />

<br />

<br />

<br />

<br />

<br />

<br />

<br />

<br />

<br />

67


Tecnologie <strong>per</strong> IDN e <strong>Storage</strong> Interface Web Service<br />

Si noti che <strong>il</strong> f<strong>il</strong>e <strong>di</strong> esempio prescrive l’ut<strong>il</strong>izzo del protocollo SOAP <strong>per</strong><br />

la comunicazione, e def<strong>in</strong>isce come punto <strong>di</strong> accesso al servizio l’<strong>in</strong><strong>di</strong>rizzo<br />

http://example.org/myService/soap.<br />

Il seguente listato riporta <strong>in</strong>vece un WSDL 2.0 che descrive lo stesso servizio<br />

(stessi tipi, stessa <strong>in</strong>terfaccia, stesso protocollo, stesso endpo<strong>in</strong>t):<br />

<br />

<br />

<br />

<br />

<br />

<br />

<br />

<br />

<br />

<br />

<br />

<br />

<br />

<br />

<br />

<br />

<br />

<br />

<br />

<br />

68


Tecnologie <strong>per</strong> IDN e <strong>Storage</strong> Interface Web Service<br />

<br />

<br />

<br />

<br />

<br />

<br />

<br />

<br />

<br />

Come si può vedere, la descrizione fatta con WSDL 2.0 è più snella. Nella<br />

prossima sezione saranno <strong>il</strong>lustrate le <strong>di</strong>fferenze tra i due stantdard.<br />

Confronto tra WSDL 1.1 e 2.0<br />

Rispetto alla e<strong>di</strong>zione 1.1, WSDL 2.0 <strong>in</strong>troduce mo<strong>di</strong>fiche alla s<strong>in</strong>tassi dei<br />

documenti, apporta <strong>in</strong>novazioni <strong>per</strong> su<strong>per</strong>are i limiti della versione precedente<br />

e lo standard, curato stavolta da un work<strong>in</strong>g group del W3C, è redatto con<br />

più precisione.<br />

Osservando <strong>il</strong> precedente esempio si notano subito le <strong>di</strong>fferenze s<strong>in</strong>tattiche.<br />

In WSDL 2.0:<br />

• L’elemento <strong>di</strong> ra<strong>di</strong>ce XML è stato r<strong>in</strong>om<strong>in</strong>ato da a <br />

• L’elemento è stato r<strong>in</strong>om<strong>in</strong>ato <br />

• L’elemento è stato r<strong>in</strong>om<strong>in</strong>ato con <br />

• La sezione degli elementi è stata rimossa e le o<strong>per</strong>azioni<br />

adesso si riferisco <strong>di</strong>rettamente ai tipi def<strong>in</strong>iti <strong>in</strong> <br />

• Sono stati cambiati i namespace, che <strong>in</strong> WSDL 2.0 ad URI nel dom<strong>in</strong>io<br />

del W3C. Il namespace pr<strong>in</strong>cipale ad esempio è cambiato da http:<br />

//schemas.xmlsoap.org/wsdl/ a http://www.w3.org/ns/wsdl.<br />

69


Tecnologie <strong>per</strong> IDN e <strong>Storage</strong> Interface Web Service<br />

Le altre novità <strong>in</strong>trodotte sono:<br />

• La nuova specifica usa XML Information Set [XMLInfoset] <strong>per</strong> def<strong>in</strong>ire<br />

i documenti WSDL con più precisione [Padmanabhuni07].<br />

•<br />

È stata aggiunta la possib<strong>il</strong>ità <strong>di</strong> <strong>in</strong>cludere più documenti: un servizio<br />

può essere def<strong>in</strong>ito <strong>in</strong> f<strong>il</strong>e <strong>di</strong>versi che puntano allo stesso namespace<br />

usando un meccanismo <strong>di</strong> <strong>in</strong>clusione.<br />

• WSDL 2.0 aggiunge nuovi pattern <strong>per</strong> lo scambio <strong>di</strong> messaggi<br />

[WSDL2adjuncts], ed <strong>il</strong> meccanismo adesso è estensib<strong>il</strong>e.<br />

•<br />

È stato <strong>in</strong>trodotto <strong>il</strong> supporto <strong>per</strong> l’ere<strong>di</strong>tarietà <strong>di</strong> <strong>in</strong>terfacce: una<br />

<strong>in</strong>terfaccia può essere def<strong>in</strong>ita come estensione <strong>di</strong> altre (ere<strong>di</strong>tarietà<br />

multipla) [Moreau04]. In WSDL 1.1, quando <strong>in</strong> servizi <strong>di</strong>fferenti si<br />

ut<strong>il</strong>izza la stessa o<strong>per</strong>azione, è necessario replicarla <strong>in</strong> tutti i f<strong>il</strong>e <strong>in</strong><br />

cui si usa. In WSDL 2.0, grazie alla ere<strong>di</strong>tarietà, le o<strong>per</strong>azioni sono<br />

riut<strong>il</strong>izzab<strong>il</strong>i.<br />

• WSDL 2.0 è adesso esten<strong>di</strong>b<strong>il</strong>e anche <strong>per</strong> gli attributi.<br />

• Come è possib<strong>il</strong>e vedere confrontando gli esempi precedenti, la specifica<br />

dei b<strong>in</strong><strong>di</strong>ng è stata semplificata [Padmanabhuni07].<br />

• Il b<strong>in</strong><strong>di</strong>ng SOAP supporta ora nativamente <strong>il</strong> b<strong>in</strong><strong>di</strong>ng con la versione<br />

1.2 [WSDL2adjuncts] (<strong>in</strong> WSDL 1.1 è stato aggiunto tramite una<br />

estensione esterna allo standard che è <strong>per</strong>ò supportata oramai da molti<br />

framework <strong>per</strong> Web Service).<br />

• Lo standard è stato r<strong>il</strong>asciato <strong>in</strong>sieme alla specifica del b<strong>in</strong><strong>di</strong>ng su<br />

HTTP [WSDL2adjuncts]. Questo <strong>per</strong>mette la convergenza tra Web<br />

Service e RESTful Service [Orchard05] [Ch<strong>in</strong>thaka07] [Haas05]<br />

Questo ultimo punto sarà approfon<strong>di</strong>to nel prossimo paragrafo.<br />

Estensione <strong>per</strong> <strong>il</strong> b<strong>in</strong><strong>di</strong>ng su HTTP <strong>di</strong> WSDL 2.0<br />

Per client che <strong>in</strong>teragiscono con risorse remote, <strong>il</strong> Representational State<br />

Transfer e le Resource Oriented Architecture (ve<strong>di</strong> sezione 3.3 a<br />

pag<strong>in</strong>a 76) sono <strong>di</strong>venuti velocemente un’alternativa ai Web Service, specialmente<br />

<strong>per</strong>ché non richiedono l’uso e la comprensione <strong>di</strong> SOAP.<br />

70


Tecnologie <strong>per</strong> IDN e <strong>Storage</strong> Interface Web Service<br />

Tuttavia si sta tentando <strong>di</strong> far convergere i due mon<strong>di</strong>, così che i Web<br />

Service possano applicare i concetti del REST e godere dei benefici delle<br />

ROA e viceversa [Ch<strong>in</strong>thaka07]. La specifica <strong>per</strong> <strong>il</strong> b<strong>in</strong><strong>di</strong>ng con HTTP <strong>di</strong><br />

WSDL 2.0 [WSDL2adjuncts], si muove a supporto <strong>di</strong> questa convergenza.<br />

Le ROA [RichardsonRuby] sono orientate alle risorse, usano HTTP <strong>per</strong> <strong>il</strong><br />

trasporto e sono tecnicamente semplici da sv<strong>il</strong>uppare, ma lasciano la gestione<br />

<strong>di</strong> molti aspetti nelle mani dello sv<strong>il</strong>uppatore e non offrono supporto <strong>per</strong><br />

gestire l’affidab<strong>il</strong>ità, l’<strong>in</strong>tegrità, QoS, etc.<br />

I Web Service sono orientati ai servizi, sono <strong>in</strong><strong>di</strong>pendenti dal protocollo<br />

e sono progettati <strong>per</strong> essere esten<strong>di</strong>b<strong>il</strong>i, ma la maggior parte usa SOAP e<br />

l’estensib<strong>il</strong>ità ha portato a una proliferazione <strong>di</strong> standard nella quale è <strong>di</strong>ffic<strong>il</strong>e<br />

orientarsi. Entrambi i modelli hanno punti <strong>di</strong> forza e punti deboli.<br />

Sotto questo punto <strong>di</strong> vista, <strong>il</strong> b<strong>in</strong><strong>di</strong>ng HTTP <strong>di</strong> WSDL 2.0 è importante<br />

<strong>per</strong>ché <strong>per</strong>mette <strong>di</strong> def<strong>in</strong>ire le <strong>in</strong>terazioni con i servizi usando le o<strong>per</strong>azioni<br />

base <strong>di</strong> HTTP: GET, POST, PUT, DELETE ma anche HEAD, OPTIONS<br />

o i meto<strong>di</strong> estesi da WebDAV [RFC2518]. I messaggi sono trasferiti tramite<br />

una serializzazione <strong>di</strong>rettamente nella start-l<strong>in</strong>e, negli header e nel body <strong>di</strong><br />

una richiesta ed una risposta HTTP [RFC2616]. Grazie a queste possib<strong>il</strong>ità<br />

offerte dal b<strong>in</strong><strong>di</strong>ng su HTTP, è possib<strong>il</strong>e specificare con WSDL un servizio<br />

che rispetta le regole e i pr<strong>in</strong>cipi delle ROA.<br />

Il seguente listato mostra le mo<strong>di</strong>fiche <strong>per</strong> l’esempio <strong>in</strong> 3.2.1 con le quali è<br />

possib<strong>il</strong>e realizzare una implementazione ROA dell’<strong>in</strong>terfaccia:<br />

<br />

...<br />

<br />

<br />

<br />


Tecnologie <strong>per</strong> IDN e <strong>Storage</strong> Interface Web Service<br />

whttp:location="{wt:id}"<br />

whttp:<strong>in</strong>putSerialization="application/x-www-form-urlencoded"/><br />

<br />

<br />

<br />

<br />

<br />

<br />

Il co<strong>di</strong>ce mostrato implementa l’<strong>in</strong>terfaccia del nostro esempio su HTTP.<br />

L’uso <strong>di</strong> questa estensione è <strong>in</strong><strong>di</strong>cato dal valore dell’attributo type dell’elemento<br />

.<br />

L’esempio ci <strong>di</strong>ce che <strong>il</strong> servizio è <strong>di</strong>sponib<strong>il</strong>e all’endpo<strong>in</strong>t http://example.<br />

org/myService/rest. Una tipica <strong>in</strong>terazione request-response <strong>per</strong> la lettura<br />

della risorsa con identificatore “123” potrebbe essere la seguente:<br />

GET myService/rest/123 HTTP/1.1<br />

Host: example.org<br />

HTTP/1.1 200 Ok<br />

Content-Type: application/xml<br />

Content-Length: 106<br />

2007-11-26<br />

Cristiano<br />

<br />

Hello World!<br />

<br />

L’esempio seguente <strong>in</strong>vece mostra i messaggi HTTP <strong>in</strong> seguito ad un<br />

errore <strong>di</strong> scrittura.<br />

72


Tecnologie <strong>per</strong> IDN e <strong>Storage</strong> Interface Web Service<br />

PUT myService/rest/124 HTTP/1.1<br />

Host: example.org<br />

Content-Type: application/xml<br />

Content-Length: 106<br />

2007-11-26<br />

Cristiano<br />

<br />

Hello aga<strong>in</strong>!<br />

<br />

HTTP/1.1 500 Internal Server Error<br />

Content-Type: text/html<br />

Content-Length: 22<br />

An error has occurred!<br />

Nell’estensione HTTP, la serializzazione delle <strong>in</strong>formazioni <strong>di</strong>st<strong>in</strong>gue tra<br />

meto<strong>di</strong> senza corpo del messaggio (GET, DELETE, etc.) e meto<strong>di</strong> con corpo<br />

(POST, PUT, etc.). Nei primi, tutti i parametri devono essere serializzati<br />

nell’URI della richiesta. Questa opzione comporta limiti sui contenuti accettati<br />

<strong>per</strong>ché deve essere rispettato lo schema dell’Uniform Resource Identifier.<br />

Un messaggio serializzab<strong>il</strong>e nell’URI <strong>di</strong> una richiesta deve essere un complex-<br />

Type XML che contiene una unica , i cui figli sono derivati<br />

da xsd:simpleType [Ch<strong>in</strong>thaka07].<br />

Per gli altri meto<strong>di</strong>, la serializzazione è più flessib<strong>il</strong>e, e <strong>per</strong>mette <strong>di</strong> specificare<br />

sia una serializzazione nel corpo della richiesta (<strong>in</strong>putSerialization=<br />

application/xml), sia un approccio misto con parte dei parametri dentro<br />

la URI e parte dentro <strong>il</strong> body (<strong>in</strong>putSerialization=application/x-www-formurlencoded).<br />

In aggiunta, alcuni parametri possono essere serializzati negli<br />

header della richiesta e della risposta.<br />

73


Tecnologie <strong>per</strong> IDN e <strong>Storage</strong> Interface Web Service<br />

3.2.2 SOAP<br />

SOAP è <strong>il</strong> primo standard dei Web Service ad essere stato espressamente<br />

sv<strong>il</strong>uppato <strong>per</strong> questi. Orig<strong>in</strong>ariamente era acronimo <strong>di</strong>“Simple Object Acess<br />

Protocol” tuttavia SOAP si è <strong>di</strong>mostrato essere tutt’altro che semplice e non<br />

riguarda l’accesso agli oggetti.<br />

Di conseguenza nella versione 1.2 <strong>il</strong> nome non è più usato come acronimo.<br />

Qualcuno lo <strong>in</strong>terpreta oggi con <strong>il</strong> significato <strong>di</strong> “Service Oriented Architecture<br />

Protocol” [WSArch], ma sebbene spesso <strong>in</strong> una SOA si usi SOAP, la<br />

<strong>di</strong>zione non è ufficializzata da nessuno standard – anzi, le SOA sono concettualmente<br />

astratte e non prescrivono l’uso <strong>di</strong> nessuna particolare tecnologia,<br />

standard o protocollo.<br />

Le versioni <strong>di</strong> SOAP esistenti sono la 1.1 e la 1.2 , tuttavia non ci sono<br />

<strong>di</strong>fferenze significative e sono <strong>in</strong>visib<strong>il</strong>i a chi sv<strong>il</strong>uppa Web Services <strong>in</strong> modo<br />

or<strong>di</strong>nario.<br />

In sé SOAP non è un protocollo <strong>di</strong>ffic<strong>il</strong>e ed ha come scopo pr<strong>in</strong>cipale far<br />

comunicare due parti che conoscono poco l’una dell’altra scambiandosi messaggi<br />

<strong>in</strong> XML. Il trasporto è delegato pr<strong>in</strong>cipalmente ad HTTP, ma si può<br />

usare anche con SMTP, <strong>il</strong> protocollo <strong>di</strong> Internet <strong>per</strong> <strong>il</strong> trasferimento <strong>di</strong> posta<br />

elettronica.<br />

Un messaggio SOAP <strong>in</strong> genere consiste <strong>di</strong> due parti, riunite nella cosiddetta<br />

envelope. Le due parti sono <strong>il</strong> body, obbligatorio, che contiene <strong>il</strong><br />

messaggio vero e proprio, e l’header, facoltativo, che contiene <strong>in</strong>formazioni<br />

<strong>per</strong> <strong>in</strong>stradare <strong>il</strong> messaggio o <strong>di</strong> sicurezza.<br />

L’envelope non contiene l’<strong>in</strong><strong>di</strong>rizzo del dest<strong>in</strong>atario: questo compito spetta<br />

al protocollo che trasporta <strong>il</strong> messaggio. Ad esempio l’<strong>in</strong><strong>di</strong>rizzo sarà un<br />

URL se <strong>il</strong> messaggio SOAP è trasportato da HTTP, <strong>in</strong>vece sarà un <strong>in</strong><strong>di</strong>rizzo<br />

e-ma<strong>il</strong> se si usa come protocollo <strong>di</strong> trasporto SMTP.<br />

Il seguente esempio, preso dalle specifiche ufficiali [SOAP1.2], mostra un<br />

tipico messaggio:<br />

<br />

74


Tecnologie <strong>per</strong> IDN e <strong>Storage</strong> Interface Web Service<br />

<br />

<br />

1<br />

2001-06-22T14:00:00-05:00<br />

<br />

<br />

<br />

<br />

Pick up Mary at school at 2pm<br />

<br />

<br />

<br />

Il pr<strong>in</strong>cipale <strong>in</strong>conveniente con SOAP è che <strong>il</strong> pars<strong>in</strong>g <strong>di</strong> XML e l’overhead<br />

da esso <strong>in</strong>trodotto, rappresentano un collo <strong>di</strong> bottiglia, spesso <strong>in</strong>sormontab<strong>il</strong>e,<br />

alle prestazioni del sistema [TanenbaumSteen].<br />

A questo <strong>in</strong>conveniente si cerca <strong>di</strong> ovviare grazie a standard come <strong>il</strong> Message<br />

Transmission Optimization Mechanism [MTOM], che usa XMLb<strong>in</strong>ary<br />

Optimized Packag<strong>in</strong>g [XOP] <strong>per</strong> offrire una serializzazione MI-<br />

ME Multipart/Related [RFC2112] dei messaggi SOAP, ma gli strumenti<br />

più ut<strong>il</strong>izzati oggi <strong>per</strong> costruire web Service offrono ancora poco supporto a<br />

questi standard.<br />

3.2.3 Conclusioni<br />

Decidere se ut<strong>il</strong>izzare o no i Web Service, significa analizzare e comparare<br />

i benefici con gli sforzi richiesti e i problemi che si portano con sé contestualmente<br />

alla soluzione ricercata <strong>per</strong> un problema specifico. Le alternative <strong>per</strong><br />

ab<strong>il</strong>itare le SOA senza i Web Service implicano <strong>per</strong>ò o l’uso <strong>di</strong> soluzioni proprietarie<br />

oppure <strong>il</strong> fare tutto da soli, da zero, e costruirsi strumenti ad-hoc<br />

<strong>per</strong> realizzare servizi <strong>in</strong>tero<strong>per</strong>ab<strong>il</strong>i, e può <strong>di</strong>ventare molto <strong>di</strong>ffic<strong>il</strong>e se abbiamo<br />

a che fare con sistemi eterogenei.<br />

Si noti anche che spetta a noi decidere quali dei vari standard WS ut<strong>il</strong>izzare,<br />

e ad esempio si potrebbe usare WSDL soltanto come formato <strong>per</strong> def<strong>in</strong>ire le<br />

<strong>in</strong>terfacce, ma usare propri protocolli <strong>per</strong> implementarle.<br />

75


Tecnologie <strong>per</strong> IDN e <strong>Storage</strong> Interface Representational State transfer<br />

In questo caso WSDL è ut<strong>il</strong>e più che altro come l<strong>in</strong>guaggio <strong>di</strong> modellazione<br />

delle <strong>in</strong>terfacce da ut<strong>il</strong>izzare <strong>in</strong> fase <strong>di</strong> progettazione. Ciò non toglie<br />

che sopra a un WSDL ben def<strong>in</strong>ito si possa costruire a posteriori un Web<br />

Service, adottando gli altri standard WS uno <strong>per</strong> volta quando necessario.<br />

Anzi, le pratiche <strong>di</strong> sv<strong>il</strong>uppo <strong>di</strong> SOA con i Web Service suggeriscono <strong>di</strong> non<br />

adottare aspetti specifici degli standard f<strong>in</strong>ché i dettagli non entrano davvero<br />

<strong>in</strong> gioco [Josuttis].<br />

Ad esempio si può specificare un’<strong>in</strong>terfaccia con WSDL senza <strong>di</strong>re niente<br />

su come chiamare i servizi, oppure si può ado<strong>per</strong>are BPEL 13 <strong>per</strong> modellare<br />

<strong>il</strong> workflow senza usare nessun altro protocollo specifico.<br />

Inoltre, grazie agli strumenti <strong>di</strong> sv<strong>il</strong>uppo <strong>di</strong>sponib<strong>il</strong>i, potrebbe ad<strong>di</strong>rittura<br />

essere banale implementare un servizio pienamente funzionante partendo da<br />

un WSDL.<br />

Nella prossima sezione sarà <strong>di</strong>scusso <strong>il</strong> Representational State Transfer<br />

(REST): <strong>in</strong>torno a questo st<strong>il</strong>e sono nate le Resource Oriented Architecture,<br />

che non si basano sugli standard WS-*. I f<strong>il</strong>osofi delle SOA spesso criticano<br />

la mancanza <strong>di</strong> aspetti <strong>di</strong> sicurezza, <strong>di</strong> componib<strong>il</strong>ità e così via [Josuttis],<br />

tuttavia i suoi pr<strong>in</strong>cipi possono essere r<strong>il</strong>evanti quando si tratta <strong>di</strong> offrire a<br />

sistemi esterni l’accesso a dati o risorse.<br />

3.3 Representational State transfer<br />

Diversamente a quanto avviene <strong>per</strong> <strong>il</strong> term<strong>in</strong>e SOA ed <strong>il</strong> term<strong>in</strong>e Web of<br />

Data, <strong>il</strong> Representional State Transfer, a cui ci si riferisce con l’acronimo<br />

REST, ha una orig<strong>in</strong>e ed una def<strong>in</strong>izione riconosciuta e legittimata, ed è nel<br />

capitolo c<strong>in</strong>que della tesi <strong>di</strong> dottorato <strong>di</strong> Roy T. Fiel<strong>di</strong>ng, pubblicata nel 2000<br />

[Fiel<strong>di</strong>ng].<br />

Tuttavia, <strong>il</strong> term<strong>in</strong>e è stato mis<strong>in</strong>terpretato da molti ed usato erroneamente<br />

<strong>in</strong> molti contesti, e non è imme<strong>di</strong>ato farsi una idea chiara del suo significato<br />

<strong>in</strong> questa giungla <strong>di</strong> op<strong>in</strong>ioni.<br />

13 Bus<strong>in</strong>ess Process Execution Language, è un l<strong>in</strong>guaggio basato su XML <strong>per</strong> orchestrare<br />

servizi <strong>in</strong> Web Service composti o procedurali. Gli ambienti <strong>di</strong> sv<strong>il</strong>uppo <strong>per</strong>mettono <strong>di</strong><br />

<strong>di</strong>segnare graficamente i f<strong>il</strong>e BPEL.<br />

76


Tecnologie <strong>per</strong> IDN e <strong>Storage</strong> Interface Representational State transfer<br />

Il REST è uno st<strong>il</strong>e <strong>per</strong> architetture software che Roy T. Fiel<strong>di</strong>ng ha def<strong>in</strong>ito<br />

nella sua tesi. È lo st<strong>il</strong>e del Web, ed <strong>in</strong>fatti è nato durante la stesura del<br />

protocollo HTTP <strong>di</strong> cui Fiel<strong>di</strong>ng è coautore [RFC2616]. Il REST un modello<br />

astratto, ed <strong>il</strong> Web è una architettura concreta che si basa sui pr<strong>in</strong>cipi <strong>di</strong><br />

questo modello. Questo modello è def<strong>in</strong>ito da un <strong>in</strong>sieme <strong>di</strong> v<strong>in</strong>coli architetturali,<br />

che applicati ad un sistema lo rendono RESTful: <strong>il</strong> Web è RESTful<br />

non soltanto <strong>per</strong>ché rispetta questi v<strong>in</strong>coli, ma <strong>per</strong>ché è <strong>il</strong> caso specifico dal<br />

quale sono stati dedotti i pr<strong>in</strong>cipi <strong>per</strong> def<strong>in</strong>ire <strong>il</strong> modello.<br />

Il primo v<strong>in</strong>colo che una architettura RESTful deve rispettare è l’<strong>in</strong>terazione<br />

tra componenti <strong>di</strong> tipo client-server. Il sistema è fatto <strong>di</strong> componenti<br />

classificati come server, che offrono servizi e rimangono <strong>in</strong> ascolto <strong>di</strong> richieste,<br />

oppure client, i quali fruiscono dei servizi e ut<strong>il</strong>izzano un connettore <strong>per</strong> <strong>in</strong>viare<br />

richieste. Il concetto <strong>di</strong> connettore <strong>in</strong> REST è un elemento che <strong>in</strong>capsula le<br />

attività <strong>di</strong> accesso alle risorse e <strong>di</strong> trasferimento delle loro rappresentazioni.<br />

Il secondo v<strong>in</strong>colo del REST è l’assenza <strong>di</strong> stato della <strong>in</strong>terazione clientserver.<br />

Questo concetto è spesso fra<strong>in</strong>teso, poiché anche un servizio o una<br />

risorsa possono avere uno stato, ma <strong>il</strong> REST pone questo v<strong>in</strong>colo specificatamente<br />

sulla comunicazione: ogni richiesta da parte <strong>di</strong> un client deve<br />

contenere tutte le <strong>in</strong>formazioni necessarie aff<strong>in</strong>ché possa essere compresa, e<br />

non può trarre vantaggio da contenuti memorizzati nel server. Lo stato della<br />

sessione è qu<strong>in</strong><strong>di</strong> mantenuto <strong>in</strong>teramente nel client. L’applicazione <strong>di</strong> questo<br />

pr<strong>in</strong>cipio migliora la visib<strong>il</strong>ità, poiché una <strong>in</strong>terazione che contiene tutte le<br />

<strong>in</strong>formazioni può essere più fac<strong>il</strong>mente monitorata, ed <strong>in</strong>crementa l’affidab<strong>il</strong>ità<br />

e la scalab<strong>il</strong>ità del sistema. L’overhead <strong>in</strong>trodotto dalla ripetizione dei<br />

dati può <strong>per</strong>ò portare ad un peggioramento delle prestazioni.<br />

Per migliorare l’efficienza dei sistemi, <strong>in</strong> REST si sua <strong>il</strong> concetto <strong>di</strong> cache,<br />

ovvero un client, <strong>per</strong> richieste ripetute, può usare una risposta memorizzata<br />

<strong>in</strong> precedenza, elim<strong>in</strong>ando così la necessità <strong>di</strong> alcune <strong>in</strong>terazioni. Questo<br />

v<strong>in</strong>colo richiede che i dati <strong>di</strong> una risposta siano etichettati come cachable o<br />

non-cachable, implicitamente o esplicitamente.<br />

L’architettura primor<strong>di</strong>ale del Web era def<strong>in</strong>ita dall’<strong>in</strong>sieme <strong>di</strong> v<strong>in</strong>coli clientcache-stateless-server.<br />

Quello che <strong>di</strong>st<strong>in</strong>gue <strong>il</strong> REST da altre architetture basate<br />

sul network<strong>in</strong>g, è <strong>il</strong> v<strong>in</strong>colo <strong>di</strong> <strong>in</strong>terfaccia uniforme tra componenti.<br />

77


Tecnologie <strong>per</strong> IDN e <strong>Storage</strong> Interface Representational State transfer<br />

Questo pr<strong>in</strong>cipio <strong>di</strong>saccoppia le implementazioni dalle funzionalità, semplifica<br />

<strong>il</strong> sistema e migliora la visib<strong>il</strong>ità delle <strong>in</strong>terazioni, ma degrada l’efficienza<br />

poiché le <strong>in</strong>formazioni sono trasferite <strong>in</strong> una forma generalizzata piuttosto<br />

che <strong>in</strong> una forma specificatamente progettata <strong>per</strong> i bisogni applicativi. Una<br />

<strong>in</strong>terfaccia uniforme è efficiente <strong>per</strong> la trasmissione <strong>di</strong> i<strong>per</strong>me<strong>di</strong>a a grana grossa.<br />

Questo pr<strong>in</strong>cipio impone ulteriori v<strong>in</strong>coli sulle <strong>in</strong>terfacce <strong>di</strong> un sistema<br />

RESTful, nelle quali si deve avere identificazione delle risorse e la loro<br />

manipolazione deve avvenire tramite una rappresentazione. Una risorsa è<br />

una qualsiasi <strong>in</strong>formazione dotata <strong>di</strong> nome: un documento, un’immag<strong>in</strong>e, un<br />

oggetto non virtuale (una <strong>per</strong>sona, un animale, una città). In REST si usano<br />

resource identifier <strong>per</strong> identificare particolari risorse co<strong>in</strong>volte nelle <strong>in</strong>terazioni<br />

tra i componenti del sistema, i quali compiono azioni su <strong>di</strong> esse usando<br />

una resource representation <strong>per</strong> catturarne lo stato. Una rappresentazione <strong>in</strong><br />

REST è una sequenza <strong>di</strong> byte più una sequenza <strong>di</strong> metadati che descrivono<br />

questi byte.<br />

Un’architettura REST è stratificata. Questo <strong>per</strong>mette <strong>di</strong> adattare i sistemi<br />

ai requisiti <strong>di</strong> scalab<strong>il</strong>ità dei gran<strong>di</strong> network come Internet. La stratificazione<br />

<strong>per</strong>mette alle architetture <strong>di</strong> essere composte <strong>di</strong> layer gerarchici,<br />

così da <strong>di</strong>saccoppiarne i componenti e promuovere l’<strong>in</strong><strong>di</strong>pendenza tra stati<br />

non a<strong>di</strong>acenti, ed i vari strati possono <strong>in</strong>capsulare servizi legacy od offrire<br />

nuovi servizi ai client pre-esistenti. D’altro canto, la stratificazione <strong>in</strong>crementa<br />

la complessità dei sistemi, aggiunge overhead ed aumenta la latenza<br />

nell’elaborazione dei dati.<br />

L’ultimo v<strong>in</strong>colo che Fiel<strong>di</strong>ng aggiunge al ad un sistema REST deriva dallo<br />

st<strong>il</strong>e “code-on-demand”, <strong>per</strong> <strong>il</strong> quale un sistema RESTful <strong>per</strong>mette <strong>di</strong><br />

estendere le funzionalità scaricando ed eseguendo nuove istruzioni <strong>in</strong> forma<br />

<strong>di</strong> applet o script. Questo v<strong>in</strong>colo è opzionale, <strong>per</strong>ché <strong>per</strong>mette <strong>di</strong> estendere<br />

le funzionalità limitate dal v<strong>in</strong>colo <strong>di</strong> <strong>in</strong>terfaccia uniforme, ma riduce la<br />

visib<strong>il</strong>ità del sistema.<br />

Questo term<strong>in</strong>e è stato usato spesso <strong>per</strong> descrivere una tipologia <strong>di</strong> servizi<br />

Web non basati su SOAP, ma come abbiamo visto <strong>il</strong> REST non prescrive<br />

l’uso <strong>di</strong> particolari protocolli o standard e non specifica quali o<strong>per</strong>azioni deve<br />

offrire una <strong>in</strong>terfaccia, purché questa sia uniforme e sia orientata alle risorse.<br />

78


Tecnologie <strong>per</strong> IDN e <strong>Storage</strong> Interface Resource Oriented Architecture<br />

Il REST assomiglia <strong>di</strong> più alle Service Oriented Architecture che non ai Web<br />

Service.<br />

Nella prossima sezione saranno prese <strong>in</strong> esame le Resource Oriented Architecture,<br />

che come vedremo sono una implementazione <strong>di</strong> questi pr<strong>in</strong>cipi.<br />

3.4 Resource Oriented Architecture<br />

Nel panorama dei Web Service, RESTful è stato usato come aggettivo <strong>per</strong><br />

classificare una tipologia <strong>di</strong> servizi basati su un approccio che usa i meto<strong>di</strong><br />

<strong>di</strong> HTTP <strong>per</strong> eseguire o<strong>per</strong>azioni remote, <strong>in</strong> contrapposizione all’approccio<br />

tipico che usa WSDL 1.1, SOAP e Java, considerati da molti <strong>di</strong>ffic<strong>il</strong>i da<br />

usare e da imparare 14 . Questi servizi hanno riscosso un <strong>di</strong>screto <strong>in</strong>teresse<br />

ultimamente, soprattutto da parte <strong>di</strong> sv<strong>il</strong>uppatori orientati alla realizzazione<br />

<strong>di</strong> servizi <strong>di</strong> largo consumo <strong>per</strong> <strong>il</strong> Web, e qu<strong>in</strong><strong>di</strong> non <strong>in</strong>teressati alla costruzione<br />

<strong>di</strong> complessi sistemi enterprise.<br />

L’orig<strong>in</strong>e <strong>di</strong> questa categorizzazione è dovuta alla natura <strong>di</strong> HTTP, che rappresenta<br />

l’esempio <strong>di</strong> riferimento <strong>di</strong> <strong>in</strong>terfaccia uniforme, così come richiesto<br />

dallo st<strong>il</strong>e REST. Ma molti servizi etichettati come RESTful non rispettano<br />

gli altri v<strong>in</strong>coli <strong>di</strong> questo st<strong>il</strong>e. I puristi <strong>di</strong> questa f<strong>il</strong>osofia non esitano a<br />

def<strong>in</strong>irli servizi “accidentally RESTful”, servizi “low REST” o “REST-RPC”.<br />

In questo panorama confuso, si sono <strong>in</strong>serite le Resource Oriented Architecture<br />

(ROA). Le ROA, presentate da Leonard Richardson e Sam Ruby<br />

nel libro “RESTFul Web Service” [RichardsonRuby] , prescrivono delle l<strong>in</strong>ee<br />

guida <strong>per</strong> realizzare architetture RESTFul concrete. Gli autori adottano<br />

questo term<strong>in</strong>e <strong>per</strong> designare architetture che rispettano i pr<strong>in</strong>cipi del RE-<br />

ST, ma mentre quest’ultimo specifica solo criteri <strong>di</strong> progettazione generici, le<br />

Resource Oriented Architecture sono esplicitamente legate alle tecnologie del<br />

Web. Nelle ROA le risorse sono <strong>in</strong><strong>di</strong>rizzate da URI e l’<strong>in</strong>terfaccia uniforme<br />

ut<strong>il</strong>izzata è HTTP.<br />

14 Su questo concordano i sostenitori <strong>di</strong> entrambi gli approcci, ve<strong>di</strong> “Big Web Service<br />

Are Not Simple” su [RichardsonRuby] e “Am I Stupid or Is Java Web Services Really<br />

Hard?” su [Hansen]<br />

79


Tecnologie <strong>per</strong> IDN e <strong>Storage</strong> Interface Resource Oriented Architecture<br />

Gli URI <strong>in</strong> questo contesto, devono essere descrittivi, ovvero deve esistere<br />

una corrispondenza <strong>in</strong>tuitiva tra questi e le risorse che <strong>in</strong><strong>di</strong>rizzano, e devono<br />

essere strutturati. La strutturazione dei nomi <strong>per</strong>mette ai client <strong>di</strong> costruire<br />

gli <strong>in</strong><strong>di</strong>rizzi delle risorse alle quali desiderano accedere. Ci sono tre regole<br />

base <strong>per</strong> progettare gli URI :<br />

• Si usa <strong>il</strong> path <strong>per</strong> co<strong>di</strong>ficare la gerarchia (es. /parent/ch<strong>il</strong>d)<br />

• Quando non esiste gerarchia si usa la punteggiatura (es. //parent/ch<strong>il</strong>d1;ch<strong>il</strong>d2)<br />

• Si ut<strong>il</strong>izzano le query <strong>per</strong> le variab<strong>il</strong>i che rappresentano l’<strong>in</strong>put <strong>di</strong> un<br />

algoritmo (es. /search?q=jellyfish&start=20)<br />

Nelle ROA ci sono solo poche o<strong>per</strong>azione base che si possono eseguire su<br />

una risorsa, e queste sono def<strong>in</strong>ite dal protocollo HTTP :<br />

• Con HTTP GET si recu<strong>per</strong>a la rappresentazione <strong>di</strong> una risorsa<br />

• HTTP POST serve <strong>per</strong> creare nuove risorse<br />

• Si mo<strong>di</strong>ficano le risorse ut<strong>il</strong>izzando HTTP PUT<br />

• HTTP DELETE cancella le risorse<br />

Le ROA considerano parte dell’<strong>in</strong>terfaccia uniforme anche i meto<strong>di</strong> HTTP<br />

HEAD e HTTP OPTIONS.<br />

Il vantaggio <strong>di</strong> questa <strong>in</strong>terfaccia è che <strong>il</strong> metodo GET è safe, qu<strong>in</strong><strong>di</strong> una<br />

richiesta che ut<strong>il</strong>izza questo metodo non cambia nessun stato nel server. Sia<br />

GET che PUT e DELETE godono della proprietà <strong>di</strong> idempotenza : un o<strong>per</strong>azione<br />

idempotente su una risorsa fa si che <strong>in</strong>viare una richiesta sia equivalente<br />

all’<strong>in</strong>vio <strong>di</strong> una molteplicità <strong>di</strong> richiesta identiche. La seconda richiesta e le<br />

seguenti lasceranno la risorsa esattamente nello stato <strong>in</strong> cui lo ha lasciato la<br />

prima.<br />

La safety e l’idempotenza sono importanti <strong>per</strong>chè <strong>per</strong>mettono ai client <strong>di</strong><br />

fare richiesta HTTP affidab<strong>il</strong>i <strong>in</strong> network che non lo sono. La POST non è<br />

né safe né idempotente.<br />

80


Tecnologie <strong>per</strong> IDN e <strong>Storage</strong> Interface Mappa delle tecnologie<br />

L’approccio ROA si propone come alternativa semplice ai ben più complessi<br />

Web Service basati su SOAP, ma le funzionalità offerte coprono tutti<br />

gli aspetti necessari ai sistemi più complessi e molto lavoro è lasciato nelle<br />

mani del programmatore. Si sta assistendo ad una timida convergenza delle<br />

due tecnologie [V<strong>in</strong>oski07], <strong>in</strong> particolare le nuove specifiche dei WSDL supportano<br />

la def<strong>in</strong>izione delle <strong>in</strong>terfacce su HTTP <strong>in</strong> st<strong>il</strong>e ROA [Ch<strong>in</strong>thaka07],<br />

e forse <strong>in</strong> futuro si potranno estendere alcuni standard dei Web Service anche<br />

ai servizi sv<strong>il</strong>uppati con questo st<strong>il</strong>e.<br />

3.5 Mappa delle tecnologie<br />

Start Here<br />

Figura 3.4: “Mappa” delle tecnologie <strong>per</strong> erogare servizi nel web.<br />

Nei precedenti paragrafi abbiamo preso <strong>in</strong> esame le varie tecnologie ut<strong>il</strong>izzab<strong>il</strong>i<br />

nella realizzazione <strong>di</strong> servizi Web. Per orientarsi meglio <strong>in</strong> quest’area, è<br />

opportuno puntualizzare quali sono le tecnologie che si escludono a vicenda.<br />

81


Tecnologie <strong>per</strong> IDN e <strong>Storage</strong> Interface Resource Description Framework<br />

Il seguente elenco presenta le pr<strong>in</strong>cipale scelte che si presentano al progettista<br />

<strong>di</strong> un sistema <strong>di</strong>stribuito <strong>di</strong> questo tipo:<br />

• SOA vs. Distributed Objects<br />

(ovvero si sceglie la granularità del sistema)<br />

• REST vs. RPC<br />

(ovvero si sceglie tra approccio alle risorse o approccio alle procedure)<br />

• HTTP vs. SOAP<br />

(ovvero si sceglie quale protocollo usare)<br />

In particolare un approccio SOA non esclude che i servizi possano essere<br />

realizzati come ROA, ed <strong>il</strong> protocollo SOAP può essere usato con uno st<strong>il</strong>e<br />

REST.<br />

Inf<strong>in</strong>e, <strong>il</strong> WSDL può essere applicato <strong>in</strong> tutti i <strong>per</strong>corsi ed <strong>il</strong> suo uso può<br />

rendere <strong>in</strong>tero<strong>per</strong>ab<strong>il</strong>i <strong>di</strong>fferenti protocolli.<br />

La figura 3.4 rappresenta una “mappa” delle strade che si possono <strong>per</strong>correre<br />

<strong>in</strong> quest’area.<br />

3.6 Resource Description Framework<br />

RDF è un l<strong>in</strong>guaggio sv<strong>il</strong>uppato dal World Wide Web Consortium <strong>per</strong><br />

standar<strong>di</strong>zzare l’uso dei metadati. Si basa su XML ed <strong>in</strong>sieme ad esso è fondamentale<br />

<strong>per</strong> <strong>il</strong> Semantic Web poiché fornisce dei meccanismi più adatti<br />

allo sv<strong>il</strong>uppo <strong>di</strong> l<strong>in</strong>guaggi <strong>per</strong> rappresentare ontologie.<br />

Il data model <strong>di</strong> RDF è <strong>in</strong>fatti pensato <strong>per</strong> fornire una descrizione standard<br />

delle risorse Web ed è orientato all’<strong>in</strong>terpretazione da parte <strong>di</strong> elaboratori.<br />

Oltre alla descrizione, RDF è usato anche <strong>per</strong> def<strong>in</strong>ire relazioni tra risorse.<br />

RDF def<strong>in</strong>isce una risorsa come un oggetto che sia univocamente identificab<strong>il</strong>e<br />

grazie a Uniform Resource Identifier. Può essere qualcosa come<br />

una pag<strong>in</strong>a web, una canzone, una <strong>per</strong>sona o un’altra entità.<br />

Il framework <strong>per</strong>mette <strong>di</strong> creare nuove relazioni che aggiungono alle risorse<br />

primitive <strong>di</strong> modellazione predef<strong>in</strong>ite. Con queste si esprime la semantica dei<br />

dati senza la necessità <strong>di</strong> fare nessuna assunzione. Lo standard def<strong>in</strong>isce come<br />

82


Tecnologie <strong>per</strong> IDN e <strong>Storage</strong> Interface Resource Description Framework<br />

referenziare i metadati, come def<strong>in</strong>irne <strong>il</strong> loro nome ed come specificarne <strong>il</strong><br />

contenuto.<br />

Le risorse hanno delle proprietà associate ad esse. Le proprietà sono identificate<br />

da tipi e i tipi hanno un valore corrispondente. I tipi esprimono le<br />

relazioni dei valori associati alle risorse.<br />

La struttura base <strong>di</strong> RDF è semplice e <strong>di</strong> base usa delle terne <strong>di</strong> espressioni<br />

che rappresentano soggetto, pre<strong>di</strong>cato, oggetto <strong>di</strong> una relazione:<br />

• Soggetto: qualcosa identificato dal suo URI<br />

• Pre<strong>di</strong>cato: <strong>il</strong> tipo <strong>di</strong> metadato anch’esso identificato da un URI (chiamato<br />

anche Proprietà)<br />

• Oggetto: <strong>il</strong> valore del suddetto metadato<br />

Non ci sono altri costrutti s<strong>in</strong>tattici oltre alle triple ed ogni documento<br />

RDF è equivalente ad un <strong>in</strong>sieme non or<strong>di</strong>nato <strong>di</strong> queste.<br />

Ci sono <strong>di</strong>verse forme <strong>per</strong> esprimerle, e quella che usa XML è la più<br />

comune.<br />

http://www.<strong>in</strong>terdatanet.org<br />

subject, pre<strong>di</strong>cate, object<br />

Creator<br />

Cristiano<br />

Resource Pro<strong>per</strong>ty Type Pro<strong>per</strong>ty Value<br />

Figura 3.5: “Cristiano created the <strong>InterDataNet</strong> home page”<br />

L’esempio <strong>in</strong> figura 3.5 descrive la seguente affermazione usando una tripla<br />

RDF:<br />

“Cristiano created the <strong>InterDataNet</strong> home page”.<br />

La home page <strong>di</strong> <strong>InterDataNet</strong> è una risorsa, la quale ha come URI http://<br />

www.<strong>in</strong>terdatanet.org ed ha una proprietà , “creator”, con valore Cristiano.<br />

83


Tecnologie <strong>per</strong> IDN e <strong>Storage</strong> Interface Resource Description Framework<br />

Il grafico rappresentato <strong>in</strong> figura si esprime <strong>in</strong> XML con <strong>il</strong> seguente statement:<br />

<br />

<br />

<br />

Cristiano<br />

<br />

<br />

La prma l<strong>in</strong>ea <strong>di</strong> questo esempio usa un namespace <strong>per</strong> def<strong>in</strong>ire esplicitamente<br />

<strong>il</strong> significato delle nozioni specificate.<br />

Il primo namespace, http://www.w3.org/1999/02/22-rdf-syntax-ns#,<br />

si riferisce al documento che descrive la s<strong>in</strong>tassi RDF.<br />

Il secondo namespace, http://dubl<strong>in</strong>core.org/2003/03/24/dces#, si<br />

riferisce alla descrizione del Dubl<strong>in</strong> Core (DC), una semplice ontologia su<br />

autori e pubblicazioni.<br />

Il Dubl<strong>in</strong> Core 15 è un <strong>in</strong>sieme <strong>di</strong> 15 elementi che rappresentano metadati<br />

sv<strong>il</strong>uppati orig<strong>in</strong>ariamente <strong>per</strong> favorire la sco<strong>per</strong>ta <strong>di</strong> risorse nel web. Dubl<strong>in</strong><br />

Core def<strong>in</strong>isce metadati <strong>per</strong> descrivere ad esempi:<br />

• Titolo della risorsa<br />

• Il soggetto trattato<br />

• Una breve descrizione dei contenuti<br />

• Il creatore ovvero l’autore<br />

• L’e<strong>di</strong>tore<br />

15 http://dubl<strong>in</strong>core.org<br />

84


Tecnologie <strong>per</strong> IDN e <strong>Storage</strong> Interface Resource Description Framework<br />

Il seguente esempio mostra uno scenario realistico <strong>di</strong> ut<strong>il</strong>izzo dei metadati<br />

del DC. Si può osservare che più <strong>di</strong> una coppia pre<strong>di</strong>cato-valore può essere<br />

<strong>in</strong><strong>di</strong>cata <strong>per</strong> una risorsa.<br />

<br />

<br />

<br />

Cristiano<br />

<br />

<strong>InterDataNet</strong><br />

The next generation of <strong>in</strong>formation and data network<strong>in</strong>g<br />

<br />

<br />

<strong>InterDataNet</strong>, SOA, REST,<br />

Web Of Data, <strong>Storage</strong>, Service<br />

<br />

<br />

Def<strong>in</strong>ition of the IDN architecture for the Web of Data<br />

<br />

Davide, Mariachiara, Samuele<br />

<br />

<br />

L’esempio esprime <strong>il</strong> creatore, <strong>il</strong> soggetto, <strong>il</strong> titolo, la descrizione ed i<br />

contributori della risorsa “http://www.<strong>in</strong>terdatanet.org”.<br />

3.6.1 RDF schema<br />

Uno dei problemi <strong>di</strong> RDF è che si può usare <strong>per</strong> specificare pre<strong>di</strong>cati b<strong>in</strong>ari<br />

<strong>per</strong> una risorsa, ma non si può <strong>di</strong>re a quali tipi <strong>di</strong> dati si applicano e quali<br />

relazioni ci sono tra <strong>di</strong> essi. Ad esempio, si potrebbe voler <strong>di</strong>re che <strong>il</strong> creator<br />

del precedente esempio è una <strong>per</strong>sona.<br />

RDF Schema (RDFS) colma questa lacuna fornendo un sistema <strong>per</strong> def<strong>in</strong>ire<br />

tipi da usare con RDF.<br />

85


Tecnologie <strong>per</strong> IDN e <strong>Storage</strong> Interface Resource Description Framework<br />

Grazie a RDFS si possono costruire modelli <strong>di</strong> oggetti da assegnare alle<br />

risorse, con i quali def<strong>in</strong>irne <strong>il</strong> significato reale.<br />

Gli elementi RDFS <strong>per</strong>mettono <strong>di</strong> affermare che una risorsa appartiene<br />

ad una classe o ad una sottoclasse, <strong>in</strong> maniera sim<strong>il</strong>e a come avviene nei<br />

l<strong>in</strong>guaggi <strong>di</strong> programmazione orientati agli oggetti. La <strong>di</strong>chiarazione <strong>di</strong> un<br />

tipo avviene con lo statement rdfs:Class mentre con rdfs:subClassOf si <strong>di</strong>chiara<br />

una specializzazione.<br />

L’appartenenza <strong>di</strong> una risorsa ad un tipo avviene con <strong>il</strong> pre<strong>di</strong>cato rdf:type,<br />

ed è possib<strong>il</strong>e def<strong>in</strong>ire che una risorsa è una istanza <strong>di</strong> più classi.<br />

Una proprietà RDFS può essere vista come un’attributo <strong>di</strong> una classe.<br />

Si def<strong>in</strong>iscono le proprietà <strong>di</strong> una classe con lo statement rdfs:Pro<strong>per</strong>ty. A<br />

<strong>di</strong>fferenza <strong>di</strong> come avviene l<strong>in</strong>guaggi orientati agli oggetti, nei quali le classi<br />

contengono le proprietà nella loro def<strong>in</strong>izione, <strong>in</strong> RDF Schema queste vengono<br />

“attaccate” <strong>di</strong>namicamente <strong>per</strong> mezzo del pre<strong>di</strong>cato rdfs:doma<strong>in</strong>. Con questo<br />

si <strong>in</strong><strong>di</strong>ca la classe <strong>in</strong> cui questa proprietà può essere usata. Con <strong>il</strong> pre<strong>di</strong>cato<br />

rdfs:range <strong>in</strong>vece si specificano i valori che questa proprietà può assumere.<br />

Nel seguente esempio si mostra come grazie si può usare RDF Schema <strong>per</strong><br />

<strong>di</strong>chiarare la classe che def<strong>in</strong>isce <strong>il</strong> tipo “Person”:<br />

<br />

<br />

<br />

The class of people.<br />

<br />

<br />

<br />

<br />

<br />

<br />

<br />


Tecnologie <strong>per</strong> IDN e <strong>Storage</strong> Interface Resource Description Framework<br />

rdf:resource="http://www.w3.org/2000/03/example/classes#Integer"/><br />

<br />

<br />

<br />

<br />

<br />

<br />

<br />

<br />

Nell’esempiola è <strong>di</strong>chiarata la classe Person che possiede le proprietà age<br />

ed universityRole. La prima ha valori numerici che appartengono agli <strong>in</strong>teri,<br />

la seconda ha un valore che è una istanza della classe UniversityRoleType.<br />

Riassumendo, grazie all’uso <strong>di</strong> classi, proprietà e valori, RDF Schema<br />

<strong>per</strong>mette <strong>di</strong> def<strong>in</strong>ire risorse ed <strong>il</strong> loro tipo.<br />

RDFS è tecnologicamente avanzato <strong>in</strong> confronto a RDF poiché fornisce<br />

un modo <strong>per</strong> costruire un modello <strong>per</strong> oggetti dal quale i dati attuali sono<br />

referenziati e che ci <strong>di</strong>ce cosa significano <strong>in</strong> realtà, e <strong>in</strong> questo si avvic<strong>in</strong>a ai<br />

l<strong>in</strong>guaggi <strong>per</strong> le ontologie.<br />

Per capire meglio le potenzialità <strong>di</strong> RDFS, si riportano i pr<strong>in</strong>cipali elementi<br />

del vocabolario def<strong>in</strong>ito nello standard [RDFSchema]:<br />

• rdfs:Resource<br />

Tutte le cose descritte da RDF sono chiamate risorse e sono istanze<br />

della classe rdfs:Resource. Ogni altra classe è una sottoclasse <strong>di</strong> questa.<br />

rdfs:Resouece a sua volta è una istanza <strong>di</strong> rdfs:Class.<br />

• rdfs:Class<br />

È la classe delle risorse che sono classi <strong>in</strong> RDF. Ricorsivamente, rdfs:Class<br />

è una istanza <strong>di</strong> rdfs:Class.<br />

87


Tecnologie <strong>per</strong> IDN e <strong>Storage</strong> Interface Resource Description Framework<br />

• rdfs:Literal<br />

È la classe dei valori letterali come le str<strong>in</strong>ghe e gli <strong>in</strong>teri. I valori <strong>di</strong> proprietà<br />

come str<strong>in</strong>ghe testuali sono un esempio <strong>di</strong> rdfs:Literal. rdfs:Literal<br />

è una sottoclasse <strong>di</strong> rdfs:Resource.<br />

• rdfs:Datatype<br />

rdfs:Datatype è la classe dei tipi <strong>di</strong> dati. Tutte le istanze <strong>di</strong> rdfs:Datatype<br />

corrispondono al modello descritto <strong>in</strong> [RDFConcepts].<br />

rdfs:Datatype è sia una istanza che una sottoclasse <strong>di</strong> rdfs:Class. Ogni<br />

istanza <strong>di</strong> rdfs:Datatype è una sottoclasse <strong>di</strong> rdfs:Literal.<br />

• rdf:XMLLiteral<br />

È una classe <strong>di</strong> valori XML. rdf:XMLLiteral è una istanza <strong>di</strong> rdfs:Datatype<br />

e sottoclasse <strong>di</strong> rdfs:Literal.<br />

• rdf:Pro<strong>per</strong>ty<br />

È la classe delle proprità. rdf:Pro<strong>per</strong>ty è una istanza <strong>di</strong> rdfs:Class.<br />

• rdfs:range<br />

È una istanza <strong>di</strong> rdf:Pro<strong>per</strong>ty usata <strong>per</strong> affermare che <strong>il</strong> valore della<br />

proprietà è una istanza <strong>di</strong> una o più classi.<br />

Ad esempio la tripla:<br />

“P rdfs:range C”<br />

afferma che “P” è una istanza <strong>di</strong> rdf:Pro<strong>per</strong>ty, che “C” è una istanza della<br />

classe rdfs:Class e che le risorse che compaiono come oggetto <strong>in</strong> una<br />

tripla <strong>in</strong> cui <strong>il</strong> pre<strong>di</strong>cato è “P” sono istanze della classe “C”.<br />

La proprietà rdfs:range si applica alle proprietà.<br />

• rdfs:doma<strong>in</strong><br />

È una istanza <strong>di</strong> rdf:Pro<strong>per</strong>ty usata <strong>per</strong> affermare che ogni risorsa a cui<br />

è stata data questa propriteà è una istanza <strong>di</strong> una o più classi.<br />

Ad esempio la tripla:<br />

“P rdfs:doma<strong>in</strong> C”<br />

afferma che “P” è una istanza <strong>di</strong> rdf:Pro<strong>per</strong>ty, che “C” è una istanza della<br />

classe rdfs:Class e che le risorse che compaiono come soggetto <strong>in</strong> una<br />

tripla <strong>in</strong> cui <strong>il</strong> pre<strong>di</strong>cato è “P” sono istanze della classe “C”.<br />

88


Tecnologie <strong>per</strong> IDN e <strong>Storage</strong> Interface Resource Description Framework<br />

• rdf:type<br />

È un’istanza <strong>di</strong> rdf:Pro<strong>per</strong>ty usata <strong>per</strong> affermare che la risorsa è una<br />

istanza <strong>di</strong> una classe.<br />

Una tripla nella forma:<br />

“R rdf:type C”<br />

afferma che “C” è una istanza <strong>di</strong> rdfs:Class e che “R” è una istanza <strong>di</strong> “C”.<br />

• rdfs:subClassOf<br />

La proprietà rdfs:subClassOf è usata <strong>per</strong> affermare che tutte li istanze<br />

della classe sono anche istanze <strong>di</strong> un’altra.<br />

Una tripla nella forma:<br />

“C1 rdfs:subClassOf C2”<br />

afferma che “C1” è una istanza <strong>di</strong> rdfs:Class, “C2” è una istanza <strong>di</strong><br />

rdfs:Class e che “C1” è una sottoclasse <strong>di</strong> “C2”. La classe rdfs:Class è<br />

transitiva.<br />

• rdfs:subPro<strong>per</strong>tyOf<br />

La proprietà rdfs:subPro<strong>per</strong>tyOf è usata <strong>per</strong> affermare che le tutte risorse<br />

che possiedono una proprietà ne possiedono anche un’altra.<br />

Ad esempio la tripla:<br />

“P1 rdfs:subPro<strong>per</strong>tyOf P2”<br />

afferma che “P1” è una istanza <strong>di</strong> rdfs:Pro<strong>per</strong>ty, “P2” è una istanza <strong>di</strong><br />

rdfs:Pro<strong>per</strong>ty e che “P1” è una sottoproprietà <strong>di</strong> “P2”. La proprietà<br />

rdfs:subPro<strong>per</strong>tyOf è transitiva.<br />

• rdfs:label<br />

È una proprietà che può essere usata <strong>per</strong> fornire un nome humanreadable<br />

della risorsa.<br />

• rdfs:comment<br />

È una proprietà che può essere usata <strong>per</strong> fornire una descrizione humanreadable<br />

della risorsa.<br />

89


Capitolo<br />

4<br />

Scenari applicativi<br />

“For a successful technology, reality must take precedence over<br />

public relations, for Nature cannot be fooled.”<br />

Richard Feynman<br />

In questo capitolo verranno analizzati e <strong>di</strong>scussi alcuni possib<strong>il</strong>i scenari<br />

applicativi <strong>per</strong> <strong>il</strong> servizio <strong>di</strong> <strong>Storage</strong> Interface. Questo stu<strong>di</strong>o non solo ha <strong>il</strong><br />

f<strong>in</strong>e <strong>di</strong> <strong>il</strong>lustrare dove un sim<strong>il</strong>e servizio possa trovare <strong>in</strong>teressi applicativi,<br />

ma serve anche <strong>per</strong> valutare quanto le tecnologie f<strong>in</strong>ora <strong>il</strong>lustrate possano<br />

sod<strong>di</strong>sfare esigenze pratiche che si <strong>in</strong>contrano <strong>in</strong> contesti reali.<br />

Il servizio <strong>di</strong> <strong>Storage</strong> Interface nasce <strong>per</strong> offrire una funzionalità <strong>di</strong> <strong>in</strong>terfacciamento<br />

alla memorizzazione dei dati <strong>per</strong> <strong>InterDataNet</strong>, l’architettura<br />

descritta nel capitolo 2. L’approccio stratificato <strong>di</strong> IDN <strong>in</strong> particolare pone


Scenari applicativi<br />

questo servizio nel livello più basso: <strong>in</strong>fatti le sue funzioni separano la logica<br />

degli altri servizi dalla implementazione pratica delle <strong>in</strong>frastrutture che<br />

memorizzano <strong>in</strong>formazioni e qu<strong>in</strong><strong>di</strong> getta le fondamenta <strong>per</strong> costruire gli altri<br />

livelli. In questo capitolo, si è tenuto conto <strong>di</strong> questa impostazione nelle<br />

rappresentazioni grafiche riportate, spostando idealmente verso <strong>il</strong> basso <strong>il</strong><br />

servizio.<br />

L’impiego <strong>di</strong> SI <strong>in</strong> IDN <strong>per</strong>mette <strong>di</strong> <strong>in</strong>terfacciare la Service Architecture<br />

a sistemi eterogenei <strong>di</strong> storage, e <strong>di</strong>saccoppia gli altri servizi dalla necessità<br />

<strong>di</strong> avere una memoria <strong>in</strong>terna <strong>per</strong>sistente, la quale può risultare <strong>di</strong>ffic<strong>il</strong>e da<br />

coor<strong>di</strong>nare <strong>in</strong> grande un sistema <strong>di</strong>stribuito.<br />

Tuttavia SI è un servizio <strong>di</strong> una SOA, e <strong>per</strong>tanto deve essere progettato<br />

quantomeno <strong>per</strong> essere riut<strong>il</strong>izzab<strong>il</strong>e.<br />

Il riut<strong>il</strong>izzo è uno dei motivi dello stu<strong>di</strong>o presentato <strong>in</strong> questo capitolo:<br />

siccome <strong>in</strong> tutti gli scenari si usa l’<strong>in</strong>terfaccia <strong>di</strong> SI <strong>per</strong> memorizzare<br />

dati, allora tra <strong>di</strong> essi è possib<strong>il</strong>e scambiare <strong>in</strong>formazioni è questo favorisce<br />

l’<strong>in</strong>tero<strong>per</strong>ab<strong>il</strong>ità.<br />

Un’altro aspetto è <strong>per</strong>ò forse più importante: l’analisi teorica degli scenari<br />

ha <strong>per</strong>messo un attento stu<strong>di</strong>o delle funzioni che SI può offrire e grazie a<br />

questo si è potuto progettare un servizio più solido e versat<strong>il</strong>e.<br />

Da questa analisi deriva lo stu<strong>di</strong>o dei requisiti che verrà formalizzato nel<br />

capitolo 5.<br />

Di particolare importanza sono gli ultimi due scenari, presentati <strong>in</strong> 4.6<br />

ed <strong>in</strong> 4.7. Il primo tratta gli aspetti <strong>di</strong> <strong>in</strong>tero<strong>per</strong>ab<strong>il</strong>ità ed è fondamentale<br />

<strong>per</strong> IDN, come <strong>di</strong>scusso <strong>in</strong> 2.1.5. L’altro, ultimo scenario <strong>di</strong> questo capitolo,<br />

è l’anello che ricongiunge con la prima parte che abbiamo affrontato: <strong>in</strong><br />

questo scenario si analizza <strong>il</strong> funzionamento <strong>di</strong> <strong>Storage</strong> Interface nel contesto<br />

<strong>di</strong> <strong>InterDataNet</strong>, ovvero <strong>il</strong> suo funzionamento <strong>in</strong>sieme al Replica Management<br />

service.<br />

Ogni scenario sarà strutturato <strong>in</strong> 4 parti: verrà presentata una panoramica<br />

<strong>per</strong> <strong>in</strong>trodurre <strong>il</strong> contesto analizzato, dopo <strong>il</strong> quale sarà considerato più nel<br />

dettaglio <strong>il</strong> ruolo del servizio <strong>di</strong> storage. Verrà <strong>in</strong>f<strong>in</strong>e presentato un elenco<br />

degli aspetti più importanti e delle conseguenze.<br />

91


Scenari applicativi <strong>Storage</strong> <strong>di</strong> immag<strong>in</strong>i con dati Exif<br />

4.1 <strong>Storage</strong> <strong>di</strong> immag<strong>in</strong>i con dati Exif<br />

Exchangeable image f<strong>il</strong>e format è una specifica <strong>per</strong> formati <strong>di</strong> f<strong>il</strong>e<br />

immag<strong>in</strong>e, usata nelle fotocamere <strong>di</strong>gitali <strong>per</strong> descrivere l’<strong>in</strong>formazione con<br />

metadati [Exif2002].<br />

Exif, questa è l’abbreviazione ufficiale, associa all’<strong>in</strong>formazione grafica<br />

dati come le impostazioni <strong>di</strong> scatto (a<strong>per</strong>tura, uso del flash, b<strong>il</strong>anciamento<br />

del bianco, etc.), <strong>il</strong> modello della fotocamera, <strong>il</strong> nome dell’autore ed altro. Le<br />

specifiche def<strong>in</strong>iscono quali tag 1 sono supportati e come co<strong>di</strong>ficarli all’<strong>in</strong>terno<br />

del f<strong>il</strong>e. Alcune <strong>di</strong> queste <strong>in</strong>formazioni sono ut<strong>il</strong>izzate <strong>per</strong> ottimizzare la<br />

stampa <strong>di</strong> fotografie <strong>di</strong>gitali, spesso <strong>in</strong> maniera automatica <strong>in</strong> quanto riconosciute<br />

<strong>di</strong>rettamente dai software <strong>di</strong> controllo. Altre sono <strong>in</strong>vece usate <strong>per</strong> f<strong>in</strong>i<br />

<strong>di</strong> catalogazione, archivio o <strong>per</strong> semplice curiosità.<br />

Tutte le più importanti applicazioni che gestiscono immag<strong>in</strong>i <strong>di</strong>gitali oggigiorno<br />

sono capaci <strong>di</strong> leggere e mostrare all’utente questo set <strong>di</strong> metadati.<br />

Le applicazioni Web raggiungono l’obiettivo grazie ad una elaborazione<br />

lato server, che estrapola dal f<strong>il</strong>e le <strong>in</strong>formazioni e le rende <strong>di</strong>sponib<strong>il</strong>i <strong>per</strong><br />

l’utente all’<strong>in</strong>terno <strong>di</strong> una pag<strong>in</strong>a HTML o con apposite API 2 .<br />

Si ipotizza uno scenario <strong>in</strong> cui un Servizio Web <strong>di</strong> <strong>Storage</strong> fornisca accesso<br />

elementare ad un set <strong>di</strong> primitive <strong>per</strong> ab<strong>il</strong>itare la consultazione <strong>di</strong> immag<strong>in</strong>i<br />

e metadati Exif associati. Tale servizio può trovare impiego <strong>in</strong> un generico<br />

contesto <strong>di</strong> Rich Internet Application (RIA), <strong>in</strong> cui può essere usato <strong>per</strong><br />

realizzare ad una applicazione <strong>in</strong> st<strong>il</strong>e Web 2.0, un generico programma a<br />

<strong>in</strong>terfaccia grafica <strong>per</strong> desktop o un semplice sito Web <strong>di</strong>namico.<br />

In figura 4.1 sono <strong>il</strong>lustrati i <strong>di</strong>versi approcci alle RIA. A s<strong>in</strong>istra troviamo<br />

i più “leggeri” (progettati <strong>per</strong> i browser), verso destra i più impegnativi<br />

[Stearn07]. La figura mostra le <strong>di</strong>fferenti tecnologie che entrano <strong>in</strong> gioco<br />

nei <strong>di</strong>fferenti approcci. Alla base <strong>di</strong> questo, ci sono i backend service: <strong>per</strong><br />

backend service si <strong>in</strong>tende un servizio esterno che fornisce accesso, aggrega e<br />

<strong>per</strong>mette <strong>il</strong> consumo <strong>di</strong> risorse remote.<br />

1 I metadati dell’immag<strong>in</strong>e sono chiamati col nome <strong>di</strong> tag nel testo dello standard Exif<br />

2 Per esempio http://www.flickr.com/, http://www.pbase.com/ o http://<br />

imageshack.us/<br />

92


Scenari applicativi <strong>Storage</strong> <strong>di</strong> immag<strong>in</strong>i con dati Exif<br />

GUI<br />

Bus<strong>in</strong>ess Logic<br />

Environment<br />

Backend services<br />

Web site<br />

HTML Markup languages<br />

Programm<strong>in</strong>g languages<br />

CGI<br />

Browser based<br />

Ajax, Flex,<br />

OpenLaszlo<br />

Interpreted<br />

Comp<strong>il</strong>ed<br />

Browser Application framework Virtual mach<strong>in</strong>e<br />

<strong>Storage</strong> Interface implementation<br />

for images repository<br />

Hybrid<br />

XULRunner<br />

<strong>Storage</strong> Interface API<br />

F<strong>il</strong>e<br />

System<br />

Desktop based<br />

Rich Client<br />

platform<br />

RDBMS<br />

...<br />

Generic<br />

Application<br />

Figura 4.1: <strong>Storage</strong> Interface <strong>per</strong> immag<strong>in</strong>i con Exif <strong>in</strong> uno scenario Rich<br />

Internet Application (derivata da [Stearn07])<br />

4.1.1 Ruolo <strong>di</strong> SI<br />

Il servizio <strong>di</strong> storage nel contesto <strong>di</strong> una RIA si colloca tra i backend<br />

services.<br />

Si tratta <strong>di</strong> servizio riut<strong>il</strong>izzab<strong>il</strong>e che fornisce funzioni comuni <strong>di</strong> memorizzazione<br />

<strong>per</strong>sistente, che può essere composto con altri servizi <strong>per</strong> essere<br />

<strong>in</strong>tegrato <strong>in</strong> una qualche architettura SOA.<br />

Il servizio favorisce l’<strong>in</strong>tero<strong>per</strong>ab<strong>il</strong>ità poichè presenta la stessa <strong>in</strong>terfaccia<br />

<strong>per</strong> accedere alle immag<strong>in</strong>i ed ai loro metadati.<br />

4.1.2 Aspetti r<strong>il</strong>evanti<br />

• Risorse che contengono una immag<strong>in</strong>e<br />

• Metadati associati all’immag<strong>in</strong>e<br />

• Accesso, consultazione e ricerca <strong>di</strong> metadati<br />

93


Scenari applicativi <strong>Storage</strong> <strong>di</strong> MIME type con associati metadati<br />

4.1.3 Conseguenze <strong>per</strong> SI<br />

• Esporre primitive che <strong>per</strong>mettono l’accesso ad una risorsa<br />

• Esporre primitive <strong>per</strong> la gestione dei metadati<br />

4.2 <strong>Storage</strong> <strong>di</strong> MIME type con associati metadati<br />

Si può pensare ad una generalizzazione del caso precedente, <strong>in</strong> cui si trattano<br />

generici Internet me<strong>di</strong>a type, conosciuti come Mime type, piuttosto<br />

che f<strong>il</strong>e <strong>per</strong> immag<strong>in</strong>e soltanto.<br />

Motivazioni sim<strong>il</strong>i hanno portato alla def<strong>in</strong>izione dello standard WebDAV,<br />

Web-based Distributed Author<strong>in</strong>g and Version<strong>in</strong>g [RFC2291].<br />

WebDAV def<strong>in</strong>isce delle estensioni <strong>di</strong> HTTP che <strong>per</strong>mettono all’utente <strong>di</strong><br />

gestire <strong>in</strong> modo collaborativo f<strong>il</strong>e <strong>in</strong> un server remoto.<br />

L’esigenza <strong>di</strong> trattare metadati deriva dalla necessità <strong>di</strong> poter associare<br />

ad una risorsa <strong>in</strong>formazioni <strong>di</strong> sistema quali data <strong>di</strong> creazione e mo<strong>di</strong>fica,<br />

proprietario, <strong>di</strong>ritti <strong>di</strong> accesso ed altro.<br />

Il versionamento, che nell’attuale implementazione <strong>di</strong> WebDAV non è ancora<br />

supportato, avrebbe comportato la necessità <strong>di</strong> gestire ulteriori metadati<br />

come ad esempio stato, revisione, lock, autore.<br />

L’impossib<strong>il</strong>ità <strong>di</strong> def<strong>in</strong>ire a priori un <strong>in</strong>sieme esaustivo, ha comportato<br />

come requisito la necessità <strong>di</strong> gestire <strong>in</strong> modo generalizzato quelle che <strong>in</strong> Web-<br />

DAV sono def<strong>in</strong>ite proprietà: <strong>in</strong> [RFC2518], HTTP Extensions for Distributed<br />

Author<strong>in</strong>g, sono def<strong>in</strong>iti nuovi meto<strong>di</strong> come PROPFIND e PROPPATCH<br />

che <strong>per</strong>mettono l’accesso e la mo<strong>di</strong>fica delle proprietà.<br />

WebDAV pone altri requisiti: la possib<strong>il</strong>ità <strong>di</strong> eseguire o<strong>per</strong>azioni <strong>di</strong> copia,<br />

spostamento e r<strong>in</strong>om<strong>in</strong>azione, la gestione <strong>di</strong> collezioni, collegamenti, sicurezza<br />

e versionamento. Per gestire f<strong>il</strong>e <strong>di</strong> <strong>di</strong>mensioni significative, è prevista <strong>in</strong>oltre<br />

la possib<strong>il</strong>ità <strong>di</strong> accesso parziale alle risorse.<br />

La gestione <strong>di</strong> collezioni comporta la necessità <strong>di</strong> visualizzarne liste dei<br />

contenuti, <strong>di</strong> crearle e cancellarle, aggiungervi e rimuovere risorse.<br />

94


Scenari applicativi <strong>Storage</strong> <strong>di</strong> MIME type con associati metadati<br />

Bus<strong>in</strong>ess<br />

Processes<br />

Choreography<br />

Services<br />

Layer<br />

Collections<br />

Service<br />

Distributed<br />

Author<strong>in</strong>g and Version<strong>in</strong>g<br />

Orchestration Service<br />

<strong>Storage</strong><br />

<strong>Storage</strong><br />

Interface<br />

Interface<br />

API<br />

API<br />

<strong>Storage</strong> Interface API<br />

<strong>Storage</strong><br />

<strong>Storage</strong><br />

Interface<br />

Interface<br />

<strong>Storage</strong><br />

Service<br />

Service<br />

Service<br />

Security<br />

Service<br />

Version<strong>in</strong>g<br />

Service<br />

Figura 4.2: Ambiente SOA <strong>per</strong> ab<strong>il</strong>itare <strong>il</strong> Distributed Author<strong>in</strong>g and<br />

Version<strong>in</strong>g<br />

Si ipotizza qu<strong>in</strong><strong>di</strong> uno scenario <strong>in</strong> cui un servizio web con funzionalità<br />

comparab<strong>il</strong>i a quelle fornite da WebDAV fornisce accesso a risorse <strong>di</strong>stribuite.<br />

Progettandolo come una SOA, si può pensare alla necessità <strong>di</strong> separare la<br />

bus<strong>in</strong>ess logic <strong>in</strong> più servizi separati: oltre al servizio <strong>di</strong> memorizzazione, si<br />

può immag<strong>in</strong>are la necessità <strong>di</strong> servizi <strong>per</strong> <strong>per</strong> gestire le collezioni, la sicurezza<br />

ed <strong>il</strong> controllo <strong>di</strong> versione, nonchè <strong>di</strong> un servizio che orchestra <strong>il</strong> sistema.<br />

Come si può vedere <strong>in</strong> figura 4.2, più servizi con <strong>di</strong>verse funzionalità vengono<br />

aggregati e consumati <strong>per</strong> formare l’architettura <strong>per</strong> questa soluzione.<br />

4.2.1 Ruolo <strong>di</strong> SI<br />

Il servizio <strong>di</strong> storage <strong>in</strong>terviene quando si ha l’effettivo accesso ai dati.<br />

SI gestisce <strong>il</strong> transito dell’<strong>in</strong>formazione memorizzata nella risorsa, nonché<br />

dei metadati associati. Potrebbe essere opportuno gestire altri aspetti quali<br />

collezioni, sicurezza e revisioni tramite opportuni servizi <strong>di</strong>staccati.<br />

95


Scenari applicativi <strong>Storage</strong> <strong>per</strong> ambiente <strong>di</strong>stributo<br />

4.2.2 Aspetti r<strong>il</strong>evanti<br />

• Publish<strong>in</strong>g <strong>di</strong> me<strong>di</strong>a type<br />

• Proprietà arbitrarie<br />

• Accesso parziale<br />

• SI come basic data service <strong>di</strong> una SOA<br />

4.2.3 Conseguenze <strong>per</strong> SI<br />

• Le risorse necessitano un mime type specificato<br />

• Necessità <strong>di</strong> gestire metadati <strong>in</strong> coppie nome/valore<br />

• In<strong>di</strong>rizzamento ed accesso a parti delle risorse<br />

4.3 <strong>Storage</strong> <strong>per</strong> ambiente <strong>di</strong>stributo<br />

Qualora le risorse esposte dal nostro servizio <strong>di</strong> storage abbiano la necessità<br />

<strong>di</strong> poter essere raggiunte tramite una <strong>in</strong>terfaccia tipo F<strong>il</strong>e System<br />

<strong>di</strong>stribuito, entrano <strong>in</strong> gioco importanti v<strong>in</strong>coli che devono essere considerati<br />

<strong>in</strong> fase <strong>di</strong> progettazione.<br />

Un F<strong>il</strong>e System <strong>di</strong>stribuito si compone <strong>di</strong> due parti [TanenbaumSteen]:<br />

<strong>Storage</strong> Service e Directory Service. Il Directory Service offre funzioni <strong>di</strong><br />

raggruppamento, e <strong>in</strong> questo è sim<strong>il</strong>e al concetto <strong>di</strong> collezione del precedente<br />

scenario. In più serve offre <strong>il</strong> controllo accessi e nam<strong>in</strong>g.<br />

Lo <strong>Storage</strong> Service <strong>di</strong> un f<strong>il</strong>e system può adottare due modelli <strong>di</strong> funzionamento.<br />

Nel Modello upload/download <strong>il</strong> f<strong>il</strong>e system fornisce soltanto due<br />

o<strong>per</strong>azioni pr<strong>in</strong>cipali: lettura e scrittura La risorsa è trasferita <strong>per</strong> <strong>in</strong>tero nelle<br />

due <strong>di</strong>rezioni, <strong>per</strong>tanto <strong>il</strong> modello è <strong>di</strong> semplice realizzazione ed ut<strong>il</strong>izzo.<br />

Tuttavia si ha un forte spreco <strong>di</strong> risorse nel caso <strong>di</strong> f<strong>il</strong>e <strong>di</strong> grosse <strong>di</strong>mensioni<br />

che necessitano <strong>di</strong> essere mo<strong>di</strong>ficati <strong>in</strong> piccola parte. Nel Modello ad<br />

accesso remoto <strong>in</strong>vece vi sono o<strong>per</strong>azioni <strong>per</strong> aprire e chiudere i f<strong>il</strong>e, leggerne<br />

e scriverne parti e navigare <strong>il</strong> loro contenuto (seek). Il <strong>di</strong>rectory service è<br />

<strong>in</strong><strong>di</strong>pendente dal modello usato <strong>per</strong> lo storage service.<br />

96


Scenari applicativi <strong>Storage</strong> <strong>per</strong> ambiente <strong>di</strong>stributo<br />

Un’altra caratteristica tipica dei f<strong>il</strong>e system <strong>di</strong>stribuiti è la replicazione.<br />

Ab<strong>il</strong>itare la replicazione comporta vantaggi e problemi da affrontare: se da<br />

un lato affidab<strong>il</strong>ità, <strong>di</strong>sponib<strong>il</strong>ità e prestazioni beneficiano dall’ut<strong>il</strong>izzo <strong>di</strong> una<br />

strategia <strong>di</strong> <strong>di</strong>ffusione <strong>di</strong> più repliche, da l’altro entrano <strong>in</strong> gioco fattori <strong>di</strong>ffic<strong>il</strong>i<br />

da gestire quali la trasparenza e la consistenza.<br />

In genere la trasparenza è soltanto <strong>per</strong> l’utente e la consistenza è gestita<br />

da processi specifici. Questi aspetti qu<strong>in</strong><strong>di</strong> non comportano complicazioni<br />

particolari <strong>per</strong> gli aspetti <strong>di</strong> memorizzazione.<br />

Il nostro <strong>Storage</strong> Service ben si presta a realizzare uno <strong>Storage</strong> Service <strong>di</strong> un<br />

f<strong>il</strong>e system <strong>di</strong>stribuito. In una soluzione basata sulle SOA, <strong>il</strong> servizio può essere<br />

affiancato da altri che gestiscono aspetti specifici come <strong>il</strong> raggruppamento<br />

<strong>in</strong> <strong>di</strong>rectory e la replicazione.<br />

Per un modello ad accesso remoto <strong>di</strong>venta fondamentale la necessità <strong>di</strong><br />

accesso parziale.<br />

In figura 4.2 è <strong>il</strong>lustrata la coreografia <strong>di</strong> questo scenario.<br />

Bus<strong>in</strong>ess<br />

Processes<br />

Choreography<br />

Services<br />

Layer<br />

Directory<br />

Service<br />

Distributed<br />

F<strong>il</strong>e System<br />

Orchestration Service<br />

<strong>Storage</strong><br />

<strong>Storage</strong><br />

Interface<br />

Interface<br />

API<br />

API<br />

<strong>Storage</strong> Interface API<br />

<strong>Storage</strong><br />

<strong>Storage</strong><br />

Interface<br />

Interface<br />

<strong>Storage</strong><br />

Service<br />

Service<br />

Service<br />

Replication<br />

Service<br />

Figura 4.3: Ambiente SOA <strong>per</strong> F<strong>il</strong>e System <strong>di</strong>stribuito<br />

97


Scenari applicativi Memorizzazione <strong>di</strong> <strong>in</strong>formazioni strutturate<br />

4.3.1 Ruolo <strong>di</strong> SI<br />

Implementa uno <strong>Storage</strong> Service secondo un modello upload/download o<br />

ad accesso remoto.<br />

4.3.2 Aspetti r<strong>il</strong>evanti<br />

• Accesso remoto<br />

• Directory service separato da storage service<br />

• Replicazione<br />

• Più livelli <strong>di</strong> gestione dei nomi<br />

4.3.3 Conseguenze <strong>per</strong> SI<br />

• Supporto <strong>per</strong> accesso a grana f<strong>in</strong>e (modello accesso remoto)<br />

4.4 Memorizzazione <strong>di</strong> <strong>in</strong>formazioni strutturate<br />

Le future esigenze <strong>di</strong> memorizzazione <strong>di</strong> <strong>in</strong>formazioni, con l’avvento <strong>di</strong><br />

tecnologie <strong>per</strong> l’espressione <strong>di</strong> semantica <strong>per</strong> la mach<strong>in</strong>e-to-mach<strong>in</strong>e <strong>in</strong>tero<strong>per</strong>ab<strong>il</strong>ity,<br />

alimentano sempre più la necessità <strong>di</strong> gestire <strong>in</strong>formazioni strutturate.<br />

Nelle applicazioni le strutture dati ut<strong>il</strong>izzate sono le liste (array, stack, code,<br />

l<strong>in</strong>ked list), alberi, grafi generici [CormenLeisersonRivest]. Questi ultimi<br />

sono i più complessi da gestire.<br />

In conseguenza della larga <strong>di</strong>ffusione <strong>di</strong> XML, HTML, DOM, le strutture<br />

ad albero sono <strong>in</strong>vece le più comuni, ma non hanno la stessa capacità<br />

espressiva <strong>di</strong> un qualsiasi grafo.<br />

Un caso particolare <strong>di</strong> grafi sono quelli orientati ed aciclici (DAG) 3 , che<br />

sono sim<strong>il</strong>i ad alberi, ma ogni nodo può avere più <strong>di</strong> un padre. Qu<strong>in</strong><strong>di</strong><br />

gli alberi sono un sotto<strong>in</strong>sieme dei DAG. Molti degli algoritmi applicab<strong>il</strong>i a<br />

strutture dati ad albero possono essere estesi anche a grafi orientati aciclici,<br />

e questa proprietà li rende una alternativa <strong>in</strong>teressante.<br />

3 Direct Acyclic Graph<br />

98


Scenari applicativi Memorizzazione <strong>di</strong> <strong>in</strong>formazioni strutturate<br />

Dal punto <strong>di</strong> vista del nostro servizio <strong>di</strong> storage, vi sono vari approcci che<br />

si possono ut<strong>il</strong>izzare <strong>per</strong> supportare strutture <strong>di</strong> dati a priori <strong>in</strong>cognite.<br />

Un primo approccio, che può essere visto come l’analogo del modello<br />

upload/download dei f<strong>il</strong>e system, prevede che <strong>il</strong> servizio fosse capace soltanto<br />

<strong>di</strong> leggere e scrivere una risorsa <strong>per</strong> <strong>in</strong>tero: <strong>in</strong> tal modo la strutturazione è<br />

trasparente e non comporta ulteriori requisiti <strong>di</strong> progettazione.<br />

Un secondo approccio può ut<strong>il</strong>izzare <strong>il</strong> servizio <strong>per</strong> memorizzare esclusivamente<br />

i no<strong>di</strong> delle strutture: se da un lato questo non comporta requisiti<br />

ad<strong>di</strong>zionali <strong>per</strong> la memorizzazione, da un altro lato la gestione delle relazioni<br />

comporta <strong>in</strong>vece la necessità <strong>di</strong> memorizzarle ed associarle alle risorse e<br />

fornire funzionalità <strong>di</strong> navigazione dei no<strong>di</strong>. Un approccio Service Oriented<br />

Architecture potrebbe suggerire la realizzazione <strong>di</strong> due servizi <strong>di</strong>st<strong>in</strong>ti <strong>per</strong><br />

assolvere questi compiti.<br />

Il servizio <strong>di</strong> <strong>Storage</strong> potrebbe assolvere a funzioni <strong>di</strong> memorizzazione <strong>di</strong><br />

relazioni come metadati delle risorse, eventualmente adottando le specifiche<br />

RDF (ve<strong>di</strong> capitolo 3.6 a pag<strong>in</strong>a 82). Un secondo specifico servizio potrebbe<br />

<strong>in</strong>vece assolvere le funzioni <strong>di</strong> navigazione della struttura. In figura 4.4 si è<br />

voluto mettere <strong>in</strong> evidenza i ruoli dei servizi ipotizzati <strong>per</strong> questo caso.<br />

Una terza possib<strong>il</strong>ità è <strong>in</strong>tegrare funzionalità <strong>di</strong> navigazione delle risorse<br />

nel servizio <strong>di</strong> storage stesso: questa possib<strong>il</strong>ità presenta analogie col modello<br />

ad accesso remoto dei f<strong>il</strong>e system <strong>in</strong> quanto si crea la necessità <strong>di</strong> gestire con<br />

opportune primitive le o<strong>per</strong>azioni <strong>di</strong> a<strong>per</strong>tura e chiusura <strong>di</strong> una risorsa, accesso<br />

<strong>in</strong> lettura e scrittura dei no<strong>di</strong> e delle relazioni, navigazione ed algoritmi<br />

<strong>di</strong> visita.<br />

Il problema pr<strong>in</strong>cipale <strong>di</strong> questo approccio è che una soluzione generale<br />

valida <strong>per</strong> ogni tipo <strong>di</strong> struttura potrebbe risultare <strong>di</strong>ffic<strong>il</strong>mente realizzab<strong>il</strong>e:<br />

le funzionalità <strong>di</strong> navigazione generiche risulterebbero potenzialmente<br />

complesse da def<strong>in</strong>ire o la soluzione sarebbe <strong>di</strong> poco aiuto.<br />

Se le strutture fossero specificatamente implementate con XML (o l’<strong>in</strong>formation<br />

model sia con esso compatib<strong>il</strong>e) vi sarebbe la <strong>di</strong>sponib<strong>il</strong>ità <strong>di</strong> standard<br />

<strong>di</strong>ffusi e conosciuti quali XPath ed XQuery, che potrebbero usati <strong>per</strong> offrire<br />

la navigazione delle strutture dati e mantenere allo stesso tempo <strong>il</strong> servizio<br />

entro i limiti della f<strong>il</strong>osofia delle SOA.<br />

99


Scenari applicativi Memorizzazione <strong>di</strong> <strong>in</strong>formazioni strutturate<br />

Bus<strong>in</strong>ess<br />

Processes<br />

Choreography<br />

Services<br />

Layer<br />

data nodes<br />

<strong>Storage</strong><br />

<strong>Storage</strong><br />

Interface<br />

Interface<br />

API<br />

API<br />

<strong>Storage</strong> Interface API<br />

<strong>Storage</strong><br />

<strong>Storage</strong><br />

Interface<br />

Interface<br />

<strong>Storage</strong><br />

Service<br />

Service<br />

Service<br />

Structured Data<br />

Author<strong>in</strong>g<br />

Orchestration Service<br />

relations<br />

navi-gation<br />

Data Browser<br />

Service<br />

Figura 4.4: Servizio <strong>di</strong> <strong>Storage</strong> e <strong>di</strong> Data Brows<strong>in</strong>g <strong>per</strong> l’author<strong>in</strong>g <strong>di</strong><br />

<strong>in</strong>formazioni strutturate<br />

Vista la <strong>di</strong>ffusione <strong>di</strong> XML e derivati, un approccio misto <strong>in</strong> cui l’<strong>in</strong>terrogazione<br />

tramite XQuery sia attuab<strong>il</strong>e a livello <strong>di</strong> Servizio <strong>di</strong> <strong>Storage</strong> qualora la<br />

risorsa sia <strong>di</strong> tipo XML (<strong>in</strong>teso come MIME type) potrebbe essere comunque<br />

sufficiente a garantire la co<strong>per</strong>tura della stragrande maggioranza dei casi <strong>in</strong><br />

cui <strong>il</strong> servizio può trovare impiego.<br />

Esistono anche meto<strong>di</strong> che generalizzano l’impiego <strong>di</strong> XQuery <strong>per</strong> l’accesso<br />

<strong>di</strong> <strong>in</strong>formazioni non-XML [Robie07]: implementare un supporto <strong>di</strong> XQuery<br />

a livello <strong>di</strong> <strong>in</strong>terfaccia del servizio apre qu<strong>in</strong><strong>di</strong> nuove strade che possono essere<br />

sufficienti ad assolvere ai requisiti richiesti ed ab<strong>il</strong>itare <strong>in</strong>tero<strong>per</strong>ab<strong>il</strong>ità con<br />

un vasto numero <strong>di</strong> sistemi.<br />

4.4.1 Ruolo <strong>di</strong> SI<br />

In questo scenario lo <strong>Storage</strong> Service assolve <strong>il</strong> compito <strong>di</strong> memorizzare<br />

le <strong>in</strong>formazioni strutturata. Sono r<strong>il</strong>evanti le <strong>di</strong>fferenze sulle modalità <strong>di</strong><br />

funzionamento a seconda dell’approccio che si vuole implementare.<br />

100


Scenari applicativi <strong>Storage</strong> <strong>per</strong> <strong>il</strong> Web orientato ai dati<br />

In particolare <strong>in</strong> IDN è stato deciso <strong>di</strong> affrontare i problemi della strutturazione<br />

delle <strong>in</strong>formazioni ad un livello su<strong>per</strong>iore (nel livello <strong>di</strong> Virtual<br />

Repository) e <strong>per</strong>tanto SI segue <strong>il</strong> primo degli approcci qui presentati.<br />

Tuttavia i requisiti <strong>di</strong> SI potranno specificare come opzionali le funzionalità<br />

viste nel secondo e terzo approccio, purchè non vadano contro gli altri<br />

pr<strong>in</strong>cipi descritti.<br />

4.4.2 Aspetti r<strong>il</strong>evanti<br />

• Informazione strutturata<br />

• Navigazione <strong>in</strong>terna o esterna al servizio<br />

• Diversi approcci <strong>per</strong> lo storag<strong>in</strong>g (s<strong>in</strong>goli no<strong>di</strong> o <strong>in</strong>tere strutture)<br />

• Diffusione <strong>di</strong> XML e standard derivati<br />

• Estensib<strong>il</strong>ità <strong>di</strong> XQuery a non-XML<br />

4.4.3 Conseguenze <strong>per</strong> SI<br />

• Accesso upload/download<br />

• Soluzione con gestione <strong>di</strong> relazioni e compatib<strong>il</strong>ità con RDF<br />

• Soluzione con gestione <strong>di</strong> strutture e compatib<strong>il</strong>ità con XML<br />

•<br />

È possib<strong>il</strong>e che sia necessario fornire primitive <strong>per</strong> la visita<br />

• Eventuale uso <strong>di</strong> XQuery<br />

4.5 <strong>Storage</strong> <strong>per</strong> <strong>il</strong> Web orientato ai dati<br />

Con l’avvento <strong>di</strong> tecnologie orientate alla semantica ed alla <strong>in</strong>tero<strong>per</strong>ab<strong>il</strong>ità<br />

macch<strong>in</strong>a-macch<strong>in</strong>a, ci stiamo spostando dal modello <strong>di</strong> “Web of documents”<br />

ad un modello <strong>di</strong> “Web of data and programs” [Bratt05]: <strong>il</strong> Web<br />

semantico ed i Web Service.<br />

In un Web non più orientato al documento, la questione cruciale <strong>per</strong><br />

i sistemi <strong>di</strong> memorizzazione <strong>di</strong>venta la granularità con cui le <strong>in</strong>formazioni<br />

<strong>di</strong>ventano accessib<strong>il</strong>i ed <strong>in</strong><strong>di</strong>rizzab<strong>il</strong>i.<br />

101


Scenari applicativi <strong>Storage</strong> <strong>per</strong> <strong>il</strong> Web orientato ai dati<br />

Nel Web un documento è <strong>in</strong><strong>di</strong>rizzato da una propria URL ma grazie all’uso<br />

dei fragment, si possono <strong>in</strong><strong>di</strong>rizzare anche parti <strong>di</strong> un una pag<strong>in</strong>a HTML. I<br />

meto<strong>di</strong> <strong>di</strong> accesso alle risorse <strong>per</strong>ò agiscono solo ad un livello più alto: HTTP<br />

traferisce <strong>in</strong>fatti l’<strong>in</strong>tera pag<strong>in</strong>a e non è possib<strong>il</strong>e richiedere <strong>il</strong> traferimento<br />

<strong>di</strong> un suo frammento. Qu<strong>in</strong><strong>di</strong> nel Web si possono <strong>in</strong><strong>di</strong>rizzare risorse ad un<br />

livello più f<strong>in</strong>e <strong>di</strong> quello a cui si può o<strong>per</strong>are.<br />

In verità, quando una pag<strong>in</strong>a contiene una immag<strong>in</strong>e, questa è trasferita<br />

separatamente: una immag<strong>in</strong>e è caratterizzata da un URL proprio e non<br />

da un frammento dell’URL della pag<strong>in</strong>a che la contiene. A <strong>di</strong>fferenza del<br />

frammento, l’immag<strong>in</strong>e può essere riut<strong>il</strong>izzata <strong>in</strong> due o più <strong>di</strong>verse pag<strong>in</strong>e<br />

Web, oppure può essere considerata essa stessa come documento.<br />

Anche i frame HTML funzionano <strong>in</strong> questo modo, ma questa tecnologia<br />

ha non è stata apprezzata e non ha avuto <strong>di</strong>ffusione <strong>per</strong> via <strong>di</strong> <strong>di</strong>versi problemi<br />

<strong>di</strong> compatib<strong>il</strong>ità con la maggior parte dei browser 4 .<br />

Si osservi <strong>in</strong>oltre che <strong>il</strong> sito Web ha un suo <strong>in</strong><strong>di</strong>rizzo e che spesso co<strong>in</strong>cide<br />

con <strong>il</strong> nome dell’host che lo ospita, e che la home page che viene mostrata<br />

<strong>per</strong> default <strong>in</strong> realtà ha un suo <strong>in</strong><strong>di</strong>rizzo. Qu<strong>in</strong><strong>di</strong> nel Web l’<strong>in</strong><strong>di</strong>rizzamento<br />

avviene a 3 livelli: sito, pag<strong>in</strong>a, frammento.<br />

In figura 4.5, lato s<strong>in</strong>istro, è mostrato come avviene l’accesso e l’<strong>in</strong><strong>di</strong>rizzamento<br />

<strong>di</strong> risorse nel Web.<br />

In un Web orientato ai dati potrebbe essere necessario o<strong>per</strong>are più <strong>in</strong> profon<strong>di</strong>tà<br />

nel documento. Si pensi ad esempio a due pag<strong>in</strong>e che contengono la<br />

stessa <strong>in</strong>formazione, e che la si voglia riut<strong>il</strong>izzare nei due documenti come<br />

con le immag<strong>in</strong>i nel Web tra<strong>di</strong>zionale.<br />

È necessario <strong>in</strong><strong>di</strong>viduare <strong>il</strong> giusto compromesso tra risorsa <strong>in</strong><strong>di</strong>rizzab<strong>il</strong>e<br />

e risorsa accessib<strong>il</strong>e ed ogni entità a cui si <strong>in</strong>tende accedere deve avere un<br />

proprio URL.<br />

In figura 4.5, lato destro, è <strong>il</strong>lustrato un servizio <strong>di</strong> storage che come <strong>il</strong><br />

Web <strong>per</strong>mette <strong>di</strong> o<strong>per</strong>are su una risorsa soltanto <strong>in</strong> blocco. In questo caso<br />

una o<strong>per</strong>azione <strong>di</strong> lettura traferirà l’<strong>in</strong>tera risorsa ed una o<strong>per</strong>azione <strong>di</strong><br />

mo<strong>di</strong>fica comporterà l’<strong>in</strong>vio anche delle parti che non sono state cambiate.<br />

Questo modo <strong>di</strong> funzionare è sim<strong>il</strong>e al modello upload/download dei f<strong>il</strong>e system<br />

<strong>di</strong>stribuiti che è stato <strong>il</strong>lustrato <strong>in</strong> 4.3. Si osservi <strong>in</strong>f<strong>in</strong>e che un servizio<br />

4 http://www.itc.virg<strong>in</strong>ia.edu/desktop/web/frames_problems.html<br />

102


Scenari applicativi <strong>Storage</strong> <strong>per</strong> <strong>il</strong> Web orientato ai dati<br />

GET<br />

POST<br />

PUT<br />

DELETE<br />

Host name<br />

Web server<br />

<br />

#section<br />

HTTP<br />

Web Page<br />

Fragment<br />

Service Endpo<strong>in</strong>t<br />

read<br />

update<br />

...<br />

<strong>Storage</strong> Interface API<br />

Accessible resource<br />

Addressable<br />

resource<br />

part<br />

Figura 4.5: Accesso ed <strong>in</strong><strong>di</strong>rizzamento <strong>per</strong> HTTP e <strong>per</strong> un Web Service <strong>di</strong><br />

storage<br />

è <strong>in</strong><strong>di</strong>rizzato da un URL che specifica <strong>il</strong> suo endpo<strong>in</strong>t, così come un sito web<br />

è <strong>in</strong><strong>di</strong>rizzato dal nome del dom<strong>in</strong>io su cui risiede.<br />

La scelta del giusto livello <strong>di</strong> <strong>in</strong><strong>di</strong>rizzamento ed accesso ha a che fare <strong>di</strong>rettamente<br />

con <strong>il</strong> tipo <strong>di</strong> risorse che <strong>il</strong> servizio <strong>di</strong> <strong>Storage</strong> Interface può trattare.<br />

Se lo si usa nel Web of Data è ovvio che non ha senso memorizzare una pag<strong>in</strong>a<br />

html <strong>per</strong> <strong>in</strong>tero.<br />

Tuttavia la granularità delle <strong>in</strong>formazioni trasferite <strong>di</strong>pende dal contesto<br />

<strong>in</strong> cui ci troviamo: se nel Web <strong>il</strong> tipico documento traferito è una pag<strong>in</strong>a<br />

HTML che può talvolta essere molto corposa, <strong>in</strong> un ambito più generico come<br />

una SOA basata sui Web Service, un documento può essere memorizzato<br />

scomposto <strong>in</strong> frammenti, i quali avranno un proprio URL, che saranno poi<br />

ricomposti da un’apposito Web Service o da una Web Application. In questo<br />

modo <strong>il</strong> progettista può ottenere <strong>il</strong> livello <strong>di</strong> accesso e <strong>di</strong> <strong>in</strong><strong>di</strong>rizzamento desiderato.<br />

Il costo è che <strong>per</strong> offrire un documento classico si dovrà aggiungere<br />

uno strato tra <strong>il</strong> browser Web ed <strong>il</strong> servizio <strong>di</strong> storage.<br />

Un ulteriore passo <strong>in</strong> avanti nella formalizzazione <strong>di</strong> un meccanismo <strong>per</strong><br />

l’accesso ai dati ce lo suggerisce WebDAV. Con questo protocollo, grazie<br />

ai meto<strong>di</strong> PROPFIND e PROPPATCH, sulle proprietà si può o<strong>per</strong>are<br />

103


Scenari applicativi <strong>Storage</strong> <strong>per</strong> <strong>il</strong> Web orientato ai dati<br />

<strong>in</strong><strong>di</strong>vidualmente, senza dover trasferire l’<strong>in</strong>tera risorsa. Si può ad esempio<br />

leggere <strong>il</strong> contenuto <strong>di</strong> un s<strong>in</strong>golo metadato con una chiamata del metodo<br />

PROPFIND alla risorsa, specificando <strong>il</strong> nome della proprietà.<br />

Qu<strong>in</strong><strong>di</strong> <strong>in</strong> WevDAV l’accesso ai dati è più f<strong>in</strong>e rispetto al Web tra<strong>di</strong>zionale.<br />

In figura 4.6 è <strong>il</strong>lustrato un servizio <strong>di</strong> storage che come WebDAV offre la<br />

possib<strong>il</strong>ità <strong>di</strong> lavorare su metadati associati ad una risorsa.<br />

meta-read<br />

meta-update<br />

Service Endpo<strong>in</strong>t<br />

read<br />

update<br />

Accessible metadata<br />

<strong>Storage</strong> Interface API<br />

Accessible resource<br />

Addressable<br />

resource<br />

part<br />

Figura 4.6: Accesso ed <strong>in</strong><strong>di</strong>rizzamento <strong>per</strong> metadati <strong>di</strong> una risorsa<br />

4.5.1 Ruolo <strong>di</strong> SI<br />

Dall’analisi <strong>di</strong> questo scenario emerge che <strong>Storage</strong> Interface può a tutti<br />

gli effetti essere usato come repository <strong>per</strong> <strong>il</strong> Web of Data, e che la <strong>di</strong>fferenza<br />

con <strong>il</strong> Web tra<strong>di</strong>zionale è <strong>il</strong> target a cui <strong>il</strong> servizio è rivolto.<br />

4.5.2 Aspetti r<strong>il</strong>evanti<br />

• In<strong>di</strong>rizzab<strong>il</strong>ità ed accesso non sempre corrispondono<br />

• Livelli <strong>di</strong> <strong>in</strong><strong>di</strong>rizzamento <strong>di</strong> URL: sito, documento, frammento<br />

• Grana <strong>di</strong> accesso del Web of Data<br />

• Layer <strong>in</strong>terme<strong>di</strong>o tra Web of Data e Browser Web<br />

104


Scenari applicativi Intero<strong>per</strong>ab<strong>il</strong>ità con sistemi legacy<br />

• Livelli <strong>di</strong> accesso <strong>di</strong> WebDAV: risorsa e metadati <strong>di</strong> risorsa<br />

4.5.3 Conseguenze <strong>per</strong> SI<br />

• Serve una o<strong>per</strong>azione <strong>di</strong> ricomb<strong>in</strong>azione <strong>per</strong> poter offrire una pag<strong>in</strong>a<br />

HTML<br />

•<br />

È necessario trovare <strong>il</strong> giusto equ<strong>il</strong>ibrio tra <strong>in</strong><strong>di</strong>rizzamento ed accesso<br />

• Il servizio ha un suo <strong>in</strong><strong>di</strong>rizzo<br />

• Le risorse hanno un <strong>in</strong><strong>di</strong>rizzo proprio<br />

• L’<strong>in</strong><strong>di</strong>rizzo <strong>di</strong> un dato deve essere un URL completo<br />

• I browser Web non sono <strong>il</strong> target <strong>di</strong>retto <strong>di</strong> SI<br />

• Si deve poter accedere ai metadati s<strong>in</strong>golarmente<br />

4.6 Intero<strong>per</strong>ab<strong>il</strong>ità con sistemi legacy<br />

Un aspetto importante <strong>per</strong> garantire l’<strong>in</strong>tero<strong>per</strong>ab<strong>il</strong>ità riguarda l’<strong>in</strong>tegrazione<br />

del servizio <strong>di</strong> storage con i sistemi legacy.<br />

Per armonizzare l’etereogenità dei sistemi esistenti è necessaria una <strong>in</strong>terfaccia<br />

comune <strong>per</strong> <strong>il</strong> servizio <strong>di</strong> storage che possa essere costruita sopra le<br />

applicazioni esistenti.<br />

Pr<strong>in</strong>cipalmente i problemi che possono <strong>in</strong>sorgere <strong>di</strong>pendono dai requisiti<br />

<strong>di</strong> memorizzazione del sistema che vogliamo <strong>in</strong>terfacciare.<br />

Infatti, se <strong>il</strong> servizio <strong>di</strong> storage <strong>per</strong>mette la memorizzazione <strong>di</strong> <strong>in</strong>formazioni<br />

generiche, ciò non è vero <strong>per</strong> sistemi legacy che si può aver bisogno <strong>di</strong><br />

rendere <strong>in</strong>tero<strong>per</strong>ab<strong>il</strong>i e sorge <strong>il</strong> problema <strong>di</strong> come gestire questa <strong>di</strong>scordanza<br />

tra le strutture dati.<br />

Ad esempio un database ha solitamente una struttura molto rigida ed <strong>il</strong><br />

tipo <strong>di</strong> <strong>in</strong>formazioni memorizzab<strong>il</strong>i è fortemente tipizzato. Se pensiamo ad<br />

un database relazionale, su cui si realizza una <strong>in</strong>terfaccia <strong>di</strong> storage legacy, è<br />

ovvio che su <strong>di</strong> esso non sarà possib<strong>il</strong>e memorizzare un qualsiasi tipo MIME<br />

come nello scenario visto <strong>in</strong> 4.2 . Diventa anche impossib<strong>il</strong>e gestire arbitrari<br />

metadati da associare alla risorsa.<br />

105


Scenari applicativi Intero<strong>per</strong>ab<strong>il</strong>ità con sistemi legacy<br />

Per gestire questo problema si possono pensare 3 <strong>di</strong>versi approcci.<br />

In un primo caso, si può prevedere un meccanismo <strong>di</strong> verifica della conformità<br />

delle <strong>in</strong>formazioni immesse: è necessario che <strong>il</strong> servizio implementi<br />

un meccanismo <strong>per</strong> validare <strong>il</strong> tipo <strong>di</strong> risorsa che viene creata o subisce una<br />

mo<strong>di</strong>fica, così da rifiutare risorse che non è possib<strong>il</strong>e memorizzare nel sistema<br />

sottostante. In questi casi, potrebbe essere necessario un meccanismo <strong>per</strong><br />

<strong>in</strong>formare l’ut<strong>il</strong>izzatore su cosa è accettato.<br />

Una prima <strong>di</strong>scrim<strong>in</strong>azione può essere gestita con i MIME type, tuttavia<br />

la conformità ad un tipo non ci <strong>per</strong>mette <strong>di</strong> <strong>di</strong>scernere tra risorse valide <strong>per</strong><br />

una generica struttura dati. Inoltre i MIME type sono def<strong>in</strong>iti e controllati<br />

<strong>in</strong> numero chiuso da IANA 5 , la Internet Assigned Numbers Authority, e<br />

non rappresentano tutte le possib<strong>il</strong>i strutture dati. I MIME possono essere<br />

casomai ut<strong>il</strong>i <strong>per</strong> sistemi legacy che memorizzano <strong>in</strong>ternamente un qualche<br />

tipo <strong>di</strong> f<strong>il</strong>e.<br />

Se la risorsa è XML potrebbe essere <strong>in</strong>teressante supportare una validazione<br />

basata su XML Schema poichè <strong>per</strong>mette soluzioni più articolate che <strong>in</strong><br />

alcune situazioni possono portare a risolvere i problemi <strong>di</strong> consistenza. Ad<br />

esempio un database ha solitamente una struttura che può essere rappresentata<br />

con questo meccanismo e <strong>per</strong>tanto può essere usato <strong>per</strong> garantire la<br />

conformità con una qualche struttura dati XML. Eventualmente potrebbe<br />

essere richista una trasformazione, ad esempio con XSLT, <strong>per</strong> poter adattare<br />

le <strong>in</strong>formazioni tra i due sistemi, e <strong>per</strong>tanto l’implementazione potrebbe<br />

dover svolgere procedure <strong>di</strong> conversione <strong>per</strong> raggiungere questo obiettivo.<br />

Una seconda soluzione prevede che <strong>il</strong> servizio <strong>di</strong> storage si prenda carico<br />

<strong>di</strong> gestire <strong>il</strong> surplus <strong>in</strong>formativo qualora questo non sia conforme.<br />

Nel caso <strong>di</strong> un <strong>di</strong> un servizio <strong>per</strong> <strong>in</strong>tero<strong>per</strong>are con un database legacy, si<br />

può pensare ad affiancare un nuovo supporto <strong>di</strong> memorizzazione <strong>per</strong> ab<strong>il</strong>itare<br />

la trattazione <strong>di</strong> ogni possib<strong>il</strong>e risorsa immessa. In questo caso <strong>per</strong>ò le nuove<br />

<strong>in</strong>formazioni non potranno essere consultate sui vecchi sistemi, qu<strong>in</strong><strong>di</strong> questa<br />

soluzione potrebbe essere valida soltanto <strong>per</strong> situazioni <strong>in</strong> cui si applica una<br />

migrazione morbida che porta all’abbandono dei vecchi sistemi.<br />

5 http://www.iana.org/assignments/me<strong>di</strong>a-types/<br />

106


Scenari applicativi Intero<strong>per</strong>ab<strong>il</strong>ità con sistemi legacy<br />

Inf<strong>in</strong>e una variante del primo caso potrebbe essere quella <strong>in</strong> cui l’arbitrarietà<br />

<strong>di</strong> memorizzazione è <strong>per</strong>messa soltanto ai metadati <strong>di</strong> risorsa. In<br />

questo modo <strong>il</strong> sistema può cont<strong>in</strong>uare ad associare <strong>in</strong>formazioni arbitrarie,<br />

ma <strong>per</strong> la risorsa rimane <strong>il</strong> v<strong>in</strong>colo <strong>di</strong> dover essere validab<strong>il</strong>e e compatib<strong>il</strong>e<br />

con i sistemi legacy.<br />

I tre casi sono schematizzati <strong>in</strong> figura 4.7.<br />

valid<br />

data<br />

<strong>Storage</strong> Interface API<br />

Legacy <strong>Storage</strong> Service #1<br />

storage<br />

Legacy<br />

system<br />

any<br />

data<br />

any<br />

data<br />

<strong>Storage</strong> Interface API<br />

Legacy <strong>Storage</strong> Service #2<br />

old<br />

storage<br />

Legacy<br />

system<br />

new<br />

storage<br />

valid<br />

data<br />

any<br />

meta<br />

data<br />

<strong>Storage</strong> Interface API<br />

Legacy <strong>Storage</strong> Service #3<br />

storage<br />

Legacy<br />

system<br />

metadata<br />

metadata<br />

metadata<br />

Figura 4.7: Intero<strong>per</strong>ab<strong>il</strong>ità con sistemi legacy: possib<strong>il</strong>i soluzioni<br />

implementative<br />

Il primo caso corrisponde al <strong>di</strong>segno <strong>di</strong> s<strong>in</strong>istra <strong>in</strong> figura 4.7, contrassegnato<br />

con la lettera “A”. Soltanto i dati vali<strong>di</strong> possono entrare ed essere<br />

memorizzati poiché si usa <strong>di</strong>rettamente lo storage del sistema legacy.<br />

Il secondo caso corrisponde al <strong>di</strong>segno centrale, contrassegnato con la lettera<br />

“B”. Questa volta è ammessa <strong>in</strong> <strong>in</strong>gresso una qualsiasi risorsa, purché<br />

conforme al modello <strong>in</strong>formativo <strong>di</strong> SI. Il surplus <strong>in</strong>formativo è gestito da nuove<br />

basi <strong>di</strong> dati o da f<strong>il</strong>e system non-legacy. Ovviamente queste <strong>in</strong>formazioni<br />

non saranno <strong>di</strong>sponib<strong>il</strong>i <strong>per</strong> i vecchi sistemi.<br />

Il terzo caso corrisponde al <strong>di</strong>segno a destra, contrassegnato con la lettera<br />

“C”. Soltanto i dati vali<strong>di</strong> possono entrare ma si accettano metadati arbitrari<br />

e le <strong>in</strong>formazioni immesse saranno compatib<strong>il</strong>i con i vecchi sistemi. I metadati<br />

107


Scenari applicativi Intero<strong>per</strong>ab<strong>il</strong>ità con sistemi legacy<br />

possono essere usati <strong>per</strong> descrivere le nuove proprietà che i sistemi basati su<br />

SI ut<strong>il</strong>izzano <strong>per</strong> <strong>il</strong> loro funzionamento.<br />

Si osservi che questi approcci offrono soluzioni quando si ha la necessità<br />

<strong>di</strong> memorizzare. Non è necessario approntare questi meccanismi (e non è<br />

necessario dover scegliere tra una delle tre possib<strong>il</strong>ità) qualora si <strong>in</strong>tenda<br />

usare SI <strong>per</strong> <strong>in</strong>terfacciare un sistema legacy <strong>in</strong> sola lettura o si preferisca<br />

usare un normale servizio <strong>di</strong> storage a fianco <strong>di</strong> uno <strong>per</strong> i sistemi legacy <strong>per</strong><br />

la memorizzazione.<br />

È <strong>in</strong>teressante <strong>in</strong>f<strong>in</strong>e osservare che <strong>il</strong> solo servizio <strong>di</strong> storage potrebbe non<br />

essere sufficiente a fornire tutte le altre funzionalità necessarie <strong>per</strong> ab<strong>il</strong>itare<br />

l’<strong>in</strong>tero<strong>per</strong>ab<strong>il</strong>ità con sistemi legacy.<br />

Per esempio se <strong>il</strong> nuovo sistema deve poter gestire funzioni <strong>per</strong> <strong>il</strong> lavoro<br />

collaborativo come <strong>il</strong> lock<strong>in</strong>g o <strong>il</strong> version<strong>in</strong>g, potrebbe essere richiesto lo stu<strong>di</strong>o<br />

<strong>di</strong> un sistema più complesso, <strong>in</strong> cui a fianco del servizio <strong>di</strong> storage compaiono<br />

servizi specifici <strong>per</strong> questi altri aspetti, ed ognuno ha un livello <strong>di</strong> <strong>in</strong>terazione<br />

specifico con le strutture legacy.<br />

Per <strong>il</strong> controllo <strong>di</strong> versione ad esempio si rende necessario tracciare ogni<br />

mo<strong>di</strong>fica <strong>di</strong> una risorsa: <strong>il</strong> servizio <strong>di</strong> storage può memorizzare le varie copie,<br />

ma quando una <strong>di</strong> queste subisce una mo<strong>di</strong>fica è complicato recu<strong>per</strong>are lo<br />

stato precedente. Pertanto potrebbe essere necessario <strong>in</strong>terfacciare i sistemi<br />

legacy anche con <strong>il</strong> servizio <strong>di</strong> version<strong>in</strong>g, <strong>in</strong> modo da copiare le risorse ogni<br />

volta che queste subiscono mo<strong>di</strong>fiche dall’esterno.<br />

In figura 4.8 è riportato uno scenario esempio <strong>di</strong> questo tipo.<br />

4.6.1 Ruolo <strong>di</strong> SI<br />

Si usa l’<strong>in</strong>terfaccia <strong>di</strong> SI <strong>per</strong> implementare servizi <strong>di</strong> storage Legacy. Qualora<br />

sia necessario accedere alle risorse <strong>in</strong> scrittura è necessario decidere come<br />

o<strong>per</strong>are sui dati <strong>in</strong> <strong>in</strong>gresso.<br />

In <strong>InterDataNet</strong> si richiede quantomeno la possib<strong>il</strong>ità <strong>di</strong> memorizzare metadati<br />

arbitrari, poichè anche <strong>per</strong> gestire risorse valide <strong>per</strong> i sistemi legacy,<br />

è necessario potervi associare delle proprietà che servono al sistema <strong>per</strong> la<br />

gestione <strong>di</strong> queste. Pertanto <strong>in</strong> IDN sarà usata almeno la soluzione descritta<br />

nel terzo caso. I requisiti <strong>di</strong> SI potranno specificare come opzionali le<br />

108


Scenari applicativi Intero<strong>per</strong>ab<strong>il</strong>ità con sistemi legacy<br />

<strong>Storage</strong> Interface API<br />

Legacy <strong>Storage</strong> Service<br />

metadata<br />

metadata<br />

metadata<br />

New SOA Layer Legacy Layer<br />

Orchestration<br />

Service<br />

Service for Version<strong>in</strong>g<br />

of legacy resources<br />

Service for Replication<br />

of legacy resources<br />

storage<br />

Legacy system<br />

Figura 4.8: Intero<strong>per</strong>ab<strong>il</strong>ità con sistemi legacy<br />

funzionalità delle altre ipotesi, purchè non vadano contro gli altri pr<strong>in</strong>cipi<br />

descritti.<br />

L’<strong>in</strong>terfaccia garantisce soltanto l’<strong>in</strong>tero<strong>per</strong>ab<strong>il</strong>ità a livello <strong>di</strong> storag<strong>in</strong>g e<br />

potrebbe non essere sufficiente <strong>per</strong> <strong>in</strong>terfacciare completamente le vecchie<br />

risorse.<br />

4.6.2 Aspetti r<strong>il</strong>evanti<br />

• SI come API che può essere usata <strong>per</strong> <strong>in</strong>terfacciare sistemi legacy<br />

• Diverse possib<strong>il</strong>ità <strong>di</strong> ut<strong>il</strong>izzo, a seconda dei requisiti <strong>di</strong> <strong>in</strong>tero<strong>per</strong>azione<br />

• Esigenze <strong>di</strong>verse <strong>per</strong> <strong>in</strong>tero<strong>per</strong>are con livelli su<strong>per</strong>iori a seconda dei f<strong>in</strong>i<br />

applicativi<br />

• Metadati predef<strong>in</strong>iti <strong>per</strong> <strong>Storage</strong> Interface e <strong>per</strong> i sistemi legacy<br />

109


Scenari applicativi Servire <strong>il</strong> Replica Management <strong>di</strong> IDN<br />

4.6.3 Conseguenze <strong>per</strong> SI<br />

• I servizi <strong>di</strong> storage legacy necessitano <strong>di</strong> funzionalità non-SI e non note<br />

a priori <strong>per</strong> <strong>in</strong>tero<strong>per</strong>are<br />

• Alcuni sistemi possono essere <strong>in</strong>terfacciati soltanto se si ab<strong>il</strong>ita la validazione<br />

delle risorse trattate<br />

• SI potrebbe dover supportare XML Schema, XSLT o altri meccanismi<br />

<strong>di</strong> validazione/trasformazione<br />

• tipizzazione delle risorse <strong>di</strong> SI tramite metadati specifici<br />

4.7 Servire <strong>il</strong> Replica Management <strong>di</strong> IDN<br />

Nella service architecture <strong>di</strong> <strong>InterDataNet</strong> è previsto che <strong>il</strong> livello più<br />

basso si occupi <strong>di</strong> questioni <strong>di</strong> storage. L’<strong>in</strong>formazione subisce trasformazioni<br />

nel passare dal livello applicativo ai livelli sottostanti. Il livello <strong>di</strong> <strong>Storage</strong><br />

Interface è l’ultimo, e deve poter memorizzare dati e metadati così come<br />

ricevuti dal livello <strong>di</strong> Replica Management.<br />

In figura 4.9 è mostrato l’architettura IDN, <strong>in</strong> particolare è evidenziato<br />

come l’<strong>in</strong>formazione si trasforma nel passaggio <strong>di</strong> livello <strong>in</strong> livello.<br />

Replica Management può usare più servizi <strong>di</strong> <strong>Storage</strong> Interface <strong>per</strong> gestire<br />

le copie delle <strong>in</strong>formazioni <strong>di</strong> IDN. In l<strong>in</strong>ea <strong>di</strong> pr<strong>in</strong>cipio, SI dovrà memorizzare<br />

una trasformazione <strong>di</strong> una primitive <strong>in</strong>formation unit dell’Information Model<br />

che durante la <strong>di</strong>scesa sarà stata arricchita <strong>di</strong> <strong>in</strong>formazioni <strong>di</strong> versionamento,<br />

<strong>di</strong> nam<strong>in</strong>g e <strong>di</strong> localizzazione. Attraversando lo stack <strong>di</strong> IDN-SA verso <strong>il</strong> basso,<br />

ogni livello aggiungerà dei nuovi metadati <strong>di</strong> servizio con i quali svolgere<br />

le sue funzioni.<br />

In particolare ogni livello <strong>in</strong> genere arricchisce con proprie Service Metadata<br />

le User Data e la User Metadata ricevute dal livello su<strong>per</strong>iore.<br />

Con User Data e Metadata si <strong>in</strong>tendono le <strong>in</strong>formazioni che ogni livello riceve<br />

dall’alto. Con Service Metadata si <strong>in</strong>tendono le <strong>in</strong>formazioni che hanno<br />

orig<strong>in</strong>e nel livello.<br />

Nel processo <strong>in</strong>verso è molto probab<strong>il</strong>e che <strong>per</strong> garantire la trasparenza<br />

questi metadati saranno rimossi.<br />

110


Scenari applicativi Servire <strong>il</strong> Replica Management <strong>di</strong> IDN<br />

Application Layer<br />

Virtual Repository<br />

Layer<br />

Information History<br />

Layer<br />

Replica Management<br />

Layer<br />

<strong>Storage</strong> Interface<br />

Layer<br />

SI API<br />

<strong>Storage</strong><br />

Service<br />

Application Application<br />

Virtual Repository<br />

Service<br />

Information History<br />

Service<br />

Replica Management<br />

Service<br />

SI API<br />

<strong>Storage</strong><br />

Service<br />

SI API<br />

Legacy<br />

<strong>Storage</strong><br />

Service<br />

Figura 4.9: Layered Architecture <strong>di</strong> <strong>InterDataNet</strong><br />

Concentriamoci sul rapporto tra SI e Replica Management: <strong>in</strong> figura 4.10<br />

è schematizzato <strong>il</strong> flusso <strong>di</strong> scambio contenuti tra i due servizi.<br />

Il servizio <strong>di</strong> gestione delle repliche avrà necessità <strong>di</strong> memorizzare varie <strong>in</strong>formazioni<br />

<strong>per</strong> la copia. Ad esempio l’URL della replica master, <strong>in</strong>formazioni<br />

sulla scadenza, o proprietà <strong>di</strong> lettura/scrittura <strong>di</strong> questa specifica replica.<br />

Queste <strong>in</strong>formazioni si aggiungono agli User Metadata ricevuti dal livello<br />

su<strong>per</strong>iore.<br />

4.7.1 Ruolo <strong>di</strong> SI<br />

Memorizza <strong>in</strong>formazioni che saranno poi gestite dall’architettura <strong>di</strong> IDN.<br />

4.7.2 Aspetti r<strong>il</strong>evanti<br />

•<br />

È <strong>il</strong> servizio <strong>di</strong> storage <strong>di</strong> IDN<br />

111


Scenari applicativi Servire <strong>il</strong> Replica Management <strong>di</strong> IDN<br />

Replica Manager<br />

Replica<br />

Service<br />

<strong>Storage</strong> Interface<br />

<strong>Storage</strong> Interface API<br />

SM SI<br />

SM RM<br />

UM IH<br />

UM RM<br />

UD<br />

UD<br />

Figura 4.10: Interazione tra livello <strong>di</strong> storage e <strong>di</strong> replica<br />

4.7.3 Conseguenze <strong>per</strong> SI<br />

• Il servizio <strong>di</strong> storage deve essere compatib<strong>il</strong>e con <strong>il</strong> data model del livello<br />

<strong>di</strong> replica<br />

112


Capitolo<br />

5<br />

Requisiti dell’Interfaccia<br />

“Walk<strong>in</strong>g on water and develop<strong>in</strong>g software from specification<br />

is easy, provided both are frozen.”<br />

Edward V. Berard<br />

In questo capitolo saranno descritti i requisiti <strong>di</strong> <strong>Storage</strong> Interface. I<br />

requisiti sono stati analizzati, <strong>di</strong>scussi ed approvati dal Team <strong>di</strong> progettazione<br />

<strong>di</strong> <strong>InterDataNet</strong> ed <strong>il</strong> risultato esposto <strong>in</strong> questo capitolo riporta i requisiti<br />

ufficiali, <strong>in</strong> l<strong>in</strong>gua <strong>in</strong>glese e ognuno dei quali è identificab<strong>il</strong>e da un co<strong>di</strong>ce <strong>di</strong><br />

riferimento unico.<br />

L’elenco dei requisiti è riportato alla f<strong>in</strong>e del capitolo, mentre nella prima<br />

parte sono riportate def<strong>in</strong>izioni e convenzioni adottate nel documento.


Requisiti dell’Interfaccia Notazione<br />

In questo documento l’acronimo SI è ut<strong>il</strong>izzato al posto del nome esteso<br />

<strong>di</strong> <strong>Storage</strong> Interface.<br />

5.1 Notazione<br />

La seguente term<strong>in</strong>ologia e le convenzioni tipografiche sono state usate <strong>in</strong><br />

questo documento:<br />

Le keyword “MUST”, “MUST NOT”, “REQUIRED”, “SHALL”, “SHALL<br />

NOT”, “SHOULD”, “SHOULD NOT”, “RECOMMENDED”, “MAY” ed “OP-<br />

TIONAL” usate <strong>in</strong> questo documento devono essere <strong>in</strong>terpretate come descritto<br />

<strong>in</strong> [RFC2119].<br />

• MUST, REQUIRED, SHALL: Il requisito è assoluto, e la specifica<br />

<strong>di</strong> SI o la sua implementazione devono aderire.<br />

• SHOULD, RECOMMENDED: Possono esistere alcune ragioni <strong>per</strong><br />

le quali <strong>il</strong> requisito sia ignorato, tuttavia è richiesta una valida motivazione<br />

comprensib<strong>il</strong>e del motivo del rifiuto.<br />

• MAY, OPTIONAL: Il requisito è opzionale, e può essere ignorato<br />

<strong>per</strong> motivi <strong>di</strong> tempismo o semplificazione.<br />

Ogni requisito è classificato secondo una classificazione derivata dallo standard<br />

[IEEE-STD-830-199], <strong>in</strong> particolare:<br />

• Functional: <strong>il</strong> requisito descrive una funzione, una azione fondamentale<br />

che deve essere svolta durante l’esecuzione del software accettando<br />

o processando l’<strong>in</strong>put o processando e generando l’output.<br />

• Performance: <strong>il</strong> requisito def<strong>in</strong>isce dei v<strong>in</strong>coli da rispettare sulle<br />

prestazione durante l’esecuzione delle sue funzioni.<br />

• Design Constra<strong>in</strong>ts: <strong>il</strong> requisito def<strong>in</strong>isce un v<strong>in</strong>colo <strong>di</strong> progettazione<br />

che può essere imposto da altri standard, limiti hardware, etc.<br />

• Standard Compliance: <strong>il</strong> requisito specifica uno standard al quale<br />

aderire, eventualmente esplicitando gli aspetti specifici.<br />

114


Requisiti dell’Interfaccia Def<strong>in</strong>izioni<br />

• Software System Attributes: <strong>il</strong> requisito specifica un attributo<br />

richiesto al software.<br />

• Reliab<strong>il</strong>ity: <strong>il</strong> requisito specifica fattori richiesti <strong>per</strong> stab<strong>il</strong>ire l’affidab<strong>il</strong>ità<br />

del sistema a conslusione del suo sv<strong>il</strong>uppo.<br />

• Ava<strong>il</strong>ab<strong>il</strong>ity: <strong>il</strong> requisito specifica fattori <strong>per</strong> def<strong>in</strong>ire <strong>il</strong> livello <strong>di</strong> <strong>di</strong>sponib<strong>il</strong>ità<br />

(on-time, recu<strong>per</strong>o e backup dei dati) che <strong>il</strong> sistema deve<br />

garantire.<br />

• Security: <strong>il</strong> requisito specifica fattori <strong>di</strong> protezione da adottare contro<br />

ut<strong>il</strong>izzi accidentali o malevoli.<br />

• Ma<strong>in</strong>ta<strong>in</strong>ab<strong>il</strong>ity: <strong>il</strong> requisito specifica attributi relativi alle necessità<br />

<strong>di</strong> manutenzione del sistema.<br />

• Portab<strong>il</strong>ity: <strong>il</strong> requisito specifica attributi relativi alla migrazione del<br />

sistema su piattaforme <strong>di</strong>fferenti.<br />

5.2 Def<strong>in</strong>izioni<br />

Le seguenti def<strong>in</strong>izione specificano <strong>il</strong> significato dei term<strong>in</strong>i <strong>in</strong>contrati <strong>in</strong><br />

questa specifica la dove possa sorgere ambiguità nella loro <strong>in</strong>terpretazione.<br />

Le def<strong>in</strong>izioni qui presentate sono da considerarsi normative.<br />

• API: Application Programm<strong>in</strong>g Interface ovvero <strong>in</strong>terfaccia <strong>di</strong> programmazione<br />

<strong>di</strong> una applicazione. In<strong>di</strong>ca un <strong>in</strong>sieme <strong>di</strong> procedure<br />

<strong>di</strong>sponib<strong>il</strong>i <strong>per</strong> lo sv<strong>il</strong>uppatore <strong>in</strong> un qualche l<strong>in</strong>guaggio <strong>di</strong> programmazione,<br />

raggruppate <strong>per</strong> formare un set <strong>di</strong> strumenti specifici <strong>per</strong> un<br />

determ<strong>in</strong>ato compito.<br />

• CRUD: Acronimo <strong>di</strong> create, read, update e delete sono le quattro<br />

o<strong>per</strong>azioni base della memorizzazione <strong>per</strong>sistente.<br />

• Data (Dato): Una <strong>in</strong>formazione <strong>in</strong> un formato adatto ad elaboratori.<br />

• Uniform Interface (Interfaccia Uniforme): Concetto fondamentale<br />

del REST e delle ROA secondo <strong>il</strong> quale i servizi devono essere<br />

progettati con la stessa <strong>in</strong>terfaccia.<br />

115


Requisiti dell’Interfaccia Def<strong>in</strong>izioni<br />

• IT: Acronimo <strong>di</strong> Information Technology.<br />

• Metatada (Metadato): Informazioni che descrivono dati.<br />

• REST: Acronimo <strong>di</strong> Representational State Transfer, è uno st<strong>il</strong>e <strong>per</strong> architetture<br />

software <strong>per</strong> sistemi <strong>di</strong> contenuti i<strong>per</strong>multime<strong>di</strong>ali <strong>di</strong>stribuiti,<br />

<strong>di</strong> cui <strong>il</strong> World Wide Web è ritenuto l’esempio simbolo.<br />

• RESTful: Un sistema progettato strettamente secondo lo st<strong>il</strong>e REST.<br />

• Resouce (Risorsa): Il term<strong>in</strong>e risorsa nel Web è usato <strong>in</strong> senso generico<br />

<strong>per</strong> ogni entità che può essere identificata tramite URI. Nel contesto<br />

dello <strong>Storage</strong> Interface <strong>per</strong> risorsa si <strong>in</strong>tende Dati e Metadati a questi<br />

associati.<br />

• RDF: Resource Description Framework, uno standard del W3C <strong>per</strong><br />

descrivere risorse <strong>per</strong> mezzo <strong>di</strong> metadati.<br />

• ROA: Resource Oriented Architecture, un tipo <strong>di</strong> architettura <strong>in</strong> st<strong>il</strong>e<br />

REST implementata su HTTP.<br />

• SI: Acronimo <strong>di</strong> <strong>Storage</strong> Interface ovvero <strong>il</strong> soggetto <strong>di</strong> questa specifica<br />

dei requisiti.<br />

• Service (Servizio): Nei <strong>di</strong>zionari servizio significa “Prestazione <strong>di</strong> un<br />

compito <strong>per</strong> qualcuno” [DizGarzanti], <strong>in</strong> questo contesto è <strong>il</strong> servizio<br />

delle SOA ovvero una “realizzazione IT <strong>di</strong> una qualche funzionalità <strong>di</strong><br />

bus<strong>in</strong>ess”.<br />

• SOA: Service Oriented Architecture, ovvero architettura orientata ai<br />

servizi, è un para<strong>di</strong>gma <strong>per</strong> la progettazione <strong>di</strong> soluzioni <strong>di</strong> gestione<br />

<strong>di</strong> processi del bus<strong>in</strong>ess <strong>in</strong> sistemi eterogenei sotto <strong>il</strong> controllo <strong>di</strong><br />

organizzazioni <strong>di</strong>fferenti.<br />

• Legacy Source (Sorgente Legacy): una fonte <strong>di</strong> dati <strong>in</strong><strong>di</strong>pendente<br />

da SI i quali possono essere esposti come risorse del servizio (ad esempio<br />

un database pre-esistente ad SI).<br />

• Ticket: Una chiave o un certificato elettronico che servono <strong>per</strong> provare<br />

l’identità <strong>di</strong> un utente.<br />

• URL: Uniform Resource Locator.<br />

116


Requisiti dell’Interfaccia Informazioni sulla specifica <strong>di</strong> requisiti<br />

• URI: Uniform Resource Identifier.<br />

• Validation (Validazione): Intesa <strong>in</strong> senso <strong>di</strong> “validazione <strong>di</strong> risorse”<br />

significa <strong>il</strong> controllo che dei dati sod<strong>di</strong>sf<strong>in</strong>o un formato predeterm<strong>in</strong>ato<br />

o sia conforme a requisiti <strong>di</strong> lunghezza, <strong>di</strong> caratteri o altri criteri <strong>di</strong><br />

<strong>in</strong>put.<br />

5.3 Informazioni sulla specifica <strong>di</strong> requisiti<br />

Si riporta la specifica ufficiale dei requisiti del servizio <strong>di</strong> <strong>Storage</strong> Interface.<br />

Il testo ufficiale è <strong>in</strong> l<strong>in</strong>gua <strong>in</strong>glese.<br />

Ogni requisito è descritto da:<br />

• Co<strong>di</strong>ce identificativo<br />

• Classificazione del requisito<br />

• Testo del requisito ufficiale (<strong>in</strong> <strong>in</strong>glese)<br />

• Eventuale descrizione <strong>in</strong> italiano<br />

Ogni requisito ha un co<strong>di</strong>ce identificativo del tipo “RXXX” dove alle X si<br />

sostituisce un co<strong>di</strong>ce numerico <strong>di</strong> 3 cifre. Il co<strong>di</strong>ce è assegnato al requisito<br />

progressivamente <strong>in</strong> or<strong>di</strong>ne cronologico. I co<strong>di</strong>ci dei requisiti rifiutati non<br />

sono stati riut<strong>il</strong>izzati, rendendo <strong>in</strong> questo modo univoca l’identificazione <strong>di</strong><br />

ogni requisito.<br />

La descrizione è da considerarsi normativa la dove ambiguità possano<br />

<strong>in</strong>sorgere nell’<strong>in</strong>terpretazione del requisito.<br />

Il documento ufficiale (<strong>in</strong> l<strong>in</strong>gua <strong>in</strong>glese) è pubblicato sul sito http://www.<br />

<strong>in</strong>terdatanet.org. Sullo stesso sito saranno pubblicate eventuali mo<strong>di</strong>fiche<br />

o revisioni.<br />

5.4 Requisiti<br />

Requirement R001 – Functional Requirement<br />

SI MUST manage Resources made of Data and Metadata<br />

117


Requisiti dell’Interfaccia Requisiti<br />

La funzionalità pr<strong>in</strong>cipale <strong>di</strong> SI è def<strong>in</strong>ita da questo requisito: <strong>il</strong> <strong>Storage</strong><br />

Interface deve <strong>per</strong>mettere <strong>di</strong> ut<strong>il</strong>izzare risorse composte da un dato, e <strong>di</strong><br />

poter gestire dei metadati che sono associati a questi dati.<br />

Requirement R002 – Functional Requirement<br />

SI MUST provide a Service for manag<strong>in</strong>g resources<br />

Questo requisito specifica che SI deve essere un Servizio e che deve offrire<br />

funzionalità <strong>di</strong> gestione <strong>di</strong> Risorse.<br />

Requirement R003 – Functional Requirement<br />

SI MUST provide CRUD functionality on Resources<br />

Il servizio deve offrire le 4 funzionalità dello storage <strong>per</strong>sistente, ovvero creazione<br />

<strong>di</strong> nuove risorse, recu<strong>per</strong>o <strong>di</strong> risorse esistenti, mo<strong>di</strong>fica e cancellazione.<br />

Requirement R004 – Design Constra<strong>in</strong>t<br />

The Service MUST be globally addressable<br />

Il servizio deve avere un nome che ne specifica <strong>il</strong> punto <strong>di</strong> accesso, <strong>in</strong> altre<br />

parole <strong>il</strong> suo endpo<strong>in</strong>t<br />

Requirement R005 – Functional Requirement<br />

A Resource MUST be identified and addressed<br />

Qu<strong>in</strong><strong>di</strong> una risorsa deve avere un nome che ne specifica <strong>il</strong> punto <strong>di</strong> accesso<br />

ed identità.<br />

118


Requisiti dell’Interfaccia Requisiti<br />

Requirement R006 – Standard Compliance<br />

A Resource MUST be identified and addressed us<strong>in</strong>g URLs<br />

Si richiede che adottati Uniform Resource Locator (URL) come sistema <strong>di</strong><br />

nomi <strong>per</strong> identificare ed <strong>in</strong><strong>di</strong>rizzare le risorse.<br />

Requirement R008 – Design Constra<strong>in</strong>t<br />

SI’s <strong>in</strong>terface MUST be abstract<br />

L’<strong>in</strong>terfaccia def<strong>in</strong>ita dalla specifica <strong>di</strong> SI deve essere astratta, ovvero si richiede<br />

che le o<strong>per</strong>azioni ed i messaggi siano descritti senza riferimenti a protocolli<br />

o l<strong>in</strong>guaggi <strong>di</strong> programmazione specifici.<br />

Requirement R009 – Design Constra<strong>in</strong>t<br />

SI’s <strong>in</strong>terface MUST be RESTful<br />

L’<strong>in</strong>terfaccia deve essere progettata secondo lo st<strong>il</strong>e dei sistemi REST.<br />

Requirement R010 – Functional Requirement<br />

SI SHOULD be implemented as a ROA<br />

Requirement R011 – Portab<strong>il</strong>ity<br />

SI MAY support other protocol than HTTP<br />

Visto che l’<strong>in</strong>terfaccia <strong>di</strong> SI deve essere astratta, è possib<strong>il</strong>e pensare ad una sua<br />

implementazioe basata su altri protocolli <strong>di</strong> trasporto <strong>per</strong> f<strong>in</strong>i <strong>di</strong> flessib<strong>il</strong>ità.<br />

119


Requisiti dell’Interfaccia Requisiti<br />

Requirement R012 – Portab<strong>il</strong>ity<br />

SI MAY be implemented us<strong>in</strong>g other architectural solution<br />

Requirement R013 – Design Constra<strong>in</strong>t<br />

SI’s MUST be implementable us<strong>in</strong>g <strong>di</strong>fferent programm<strong>in</strong>g languages<br />

Requirement R015 – Security<br />

SI MUST handle access control on Resources<br />

L’<strong>in</strong>terfaccia deve qu<strong>in</strong><strong>di</strong> essere progettata seguendo criteri che <strong>per</strong>mettano <strong>di</strong><br />

controllare l’accesso <strong>di</strong> una risorsa, e <strong>per</strong>tanto le o<strong>per</strong>azione devono prevedere<br />

<strong>il</strong> trasporto <strong>di</strong> credenziali <strong>per</strong> l’autorizzazione <strong>di</strong> accesso ad una risorsa, <strong>per</strong><br />

una determ<strong>in</strong>ata entità, svolgendo una determ<strong>in</strong>ata o<strong>per</strong>azione.<br />

Requirement R016 – Security<br />

SI MUST support <strong>di</strong>fferent authentication/authorization/au<strong>di</strong>t systems<br />

Deve essere possib<strong>il</strong>e <strong>per</strong> SI l’implementazione con <strong>di</strong>versi meccanismi <strong>di</strong><br />

protezione, <strong>in</strong> cui si prevede anche la delega <strong>di</strong> autorizzazione tra entità.<br />

In generale, sarà necessario supportare criteri che gestiscano l’autorizzazione<br />

basandosi sulle entità <strong>in</strong> gioco quali: detentore dei <strong>di</strong>ritti sulla risorsa, richiedente<br />

dell’o<strong>per</strong>azione <strong>di</strong> accesso, sistema <strong>di</strong> accesso e lo stesso servizio <strong>di</strong><br />

<strong>Storage</strong> Interface.<br />

Requirement R021 – Functional Requirement<br />

SI MUST support notification messages to designed recipients <strong>in</strong> result of<br />

events generated by o<strong>per</strong>ations on Resources<br />

In particolare si richiede che l’<strong>in</strong>terfaccia def<strong>in</strong>ita abbia <strong>il</strong> supporto <strong>per</strong> la<br />

120


Requisiti dell’Interfaccia Requisiti<br />

comunicazione <strong>di</strong> notifiche ad entità autorizzate qualora un evento su una<br />

risorsa debba essere tracciato, <strong>per</strong> f<strong>in</strong>i <strong>di</strong> manutenzione o altri scopi.<br />

Requirement R022 – Functional Requirement<br />

SI MAY support notification messages to designed recipients <strong>in</strong> result of<br />

generic events<br />

Messaggi <strong>di</strong> notifica possono orig<strong>in</strong>are da eventi non conseguenti ad o<strong>per</strong>azioni<br />

su risorse, ad esempio eventi pianificati.<br />

Requirement R023 – Design Constra<strong>in</strong>t<br />

SI MUST be able to expose the Data from Legacy Sources as Resources<br />

Il servizio deve essere progettato applicando tutti quei criteri che possono<br />

semplificare l’adattamento a sistemi <strong>di</strong> storage pre-esistenti.<br />

Requirement R024 – Functional Requirement<br />

SI MAY validate the stored Resources and Resources after creation or<br />

update or an explicit request<br />

Il servizio può offrire funzionalità <strong>di</strong> validazione delle risorse, ovvero deve<br />

essere possib<strong>il</strong>e l’uso <strong>di</strong> procedure generiche che restituiscano <strong>in</strong>formazioni su<br />

una risorsa. In particolare possono essere previsti meccanismi <strong>di</strong> validazione<br />

<strong>di</strong> risorse memorizzate, <strong>di</strong> risorse nuove durante la loro creazione o <strong>di</strong> risorse<br />

mo<strong>di</strong>ficate durante l’o<strong>per</strong>azione <strong>di</strong> aggiornamento.<br />

Requirement R025 – Standard Compliance<br />

SI SHOULD use WSDL for the def<strong>in</strong>ition of the Abstract Interface<br />

Per offrire una migliore <strong>in</strong>tero<strong>per</strong>ab<strong>il</strong>ità, se possib<strong>il</strong>e, dovrebbe essere offerta<br />

una descrizione dell’<strong>in</strong>terfaccia astratta <strong>di</strong> SI tramite le specifiche <strong>di</strong> WSDL.<br />

121


Requisiti dell’Interfaccia Requisiti<br />

Requirement R036 – Standard Compliance<br />

SI MAY use WSDL for the describ<strong>in</strong>g Interface implementations<br />

Le implementazioni dell’<strong>in</strong>terfaccia <strong>di</strong> SI potrebbero essere descritte con WSDL<br />

grazie alle sue estensioni <strong>per</strong> HTTP e SOAP. In particolare potrebbe essere<br />

ut<strong>il</strong>e def<strong>in</strong>ire una nuova estensione <strong>di</strong> WSDL <strong>per</strong> descrivere <strong>in</strong>terfacce che<br />

usano altri protocolli, ad esempio TCP.<br />

Requirement R026 – Standard Compliance<br />

Resources SHOULD be compatible with RDF <strong>in</strong>formation model<br />

Il modello con cui RDF descrive i metadati dovrebbe essere compatib<strong>il</strong>e con<br />

i metadati <strong>di</strong> SI <strong>in</strong> modo da poter offrire tramite RDF i metadati associati<br />

ai dati <strong>di</strong> una risorsa.<br />

Requirement R027 – Standard Compliance<br />

Resources SHOULD be compatible with RDF Schema type system<br />

Dovrebbe poter essere possib<strong>il</strong>e usare RDF Schema <strong>per</strong> def<strong>in</strong>ire le classi a cui<br />

una risorsa appartiene.<br />

Requirement R028 – Functional Requirement<br />

SI MAY support specific o<strong>per</strong>ations for management or for <strong>per</strong>formance<br />

improvements<br />

Si possono def<strong>in</strong>ire altre o<strong>per</strong>azioni sulle risorse, ad esempio <strong>per</strong> la creazione<br />

<strong>di</strong> duplicati, o <strong>per</strong> recu<strong>per</strong>are l’elenco <strong>di</strong> risorse presenti <strong>in</strong> un determ<strong>in</strong>ato<br />

storage.<br />

Requirement R037 – Functional Requirement<br />

122


Requisiti dell’Interfaccia Requisiti<br />

O<strong>per</strong>ations <strong>di</strong>fferent from the basic CRUD MUST be optional <strong>in</strong> specific<br />

implementations<br />

Per implementare un servizio <strong>di</strong> <strong>Storage</strong> Interface deve essere sufficiente supportare<br />

le quattro o<strong>per</strong>azioni <strong>di</strong> creazione, lettura, mo<strong>di</strong>fica e cancellazione,<br />

qu<strong>in</strong><strong>di</strong> ogni requisito funzionale obbligatorio deve essere offerto attraverso<br />

queste quattro o<strong>per</strong>azioni.<br />

Requirement R029 – Functional Requirement<br />

SI MAY allow Lock<strong>in</strong>g and Unlock<strong>in</strong>g of Resources<br />

Si possono def<strong>in</strong>ire o<strong>per</strong>azioni che <strong>per</strong>mettono <strong>di</strong> bloccare l’accesso alle risorse<br />

durante la loro mo<strong>di</strong>fica.<br />

Requirement R030 – Standard Compliance<br />

SI MUST allow XML representation of Resources<br />

Requirement R031 – Design Constra<strong>in</strong>t<br />

SI MUST support synchronous and asynchronous <strong>in</strong>teraction<br />

Le specifiche dell’<strong>in</strong>terfaccia non devono impe<strong>di</strong>re la possib<strong>il</strong>ità <strong>di</strong> implementazioni<br />

con un meccanismo as<strong>in</strong>crono.<br />

Requirement R033 – Functional Requirement<br />

SI MUST support arbitrary Metadata on resources<br />

Deve essere possib<strong>il</strong>e memorizzare <strong>per</strong> una determ<strong>in</strong>ata risorsa, metadati <strong>di</strong><br />

tipo sconosciuto.<br />

123


Requisiti dell’Interfaccia Requisiti<br />

Requirement R034 – Functional Requirement<br />

Metadata SHOULD be univocally identified by a qualified name<br />

Ogni metadato <strong>in</strong> una risorsa deve avere un nome che lo identifica e questo<br />

nome deve avere vali<strong>di</strong>tà globale <strong>per</strong>chè ad esempio appartiene ad un<br />

namespace def<strong>in</strong>ito con URI.<br />

Requirement R035 – Functional Requirement<br />

Metadata value SHOULD have a type def<strong>in</strong>ed by the qualified name<br />

Il nome specificato <strong>per</strong> la risorsa implica che <strong>il</strong> valore del metadato abbia un<br />

tipo la cui s<strong>in</strong>tassi e semantica siano <strong>in</strong><strong>di</strong>viduati dal nome e namespace a cui<br />

esso appartiene. Un meccanismo <strong>di</strong> validazione può ad esempio curarsi della<br />

verifica che questi valori siano conformi.<br />

Requirement R036 – Functional Requirement<br />

Data and Metadata MUST be hierarchically subor<strong>di</strong>nated to the resource<br />

I dati ed i metadati sono contenuti nella risorsa e ne sono figli.<br />

Requirement R037 – Functional Requirement<br />

SI MUST allow <strong>di</strong>rect access to Metadata<br />

Deve essere possib<strong>il</strong>e ottenere <strong>il</strong> valore <strong>di</strong> un metadato tramite <strong>in</strong><strong>di</strong>rizzamento<br />

<strong>di</strong>retto, ad esempio comb<strong>in</strong>ando <strong>il</strong> nome del metadato con l’URL della risorsa.<br />

124


Parte III<br />

<strong>Progetto</strong> dell’<strong>in</strong>terfaccia e<br />

sv<strong>il</strong>uppo <strong>di</strong> una<br />

implementazione <strong>di</strong> riferimento<br />

<strong>per</strong> <strong>il</strong> servizio


Capitolo<br />

6<br />

<strong>Progetto</strong> dell’Interfaccia<br />

“Never underestimate the bandwidth of a station wagon full of<br />

tapes hurtl<strong>in</strong>g down the highway.”<br />

Andrew S. Tanenbaum<br />

In questo capitolo sarà descritto <strong>il</strong> progetto dell’<strong>in</strong>terfaccia del servizio<br />

“<strong>InterDataNet</strong> <strong>Storage</strong> Interface”.<br />

Il risultato presentato è frutto dell’analisi degli scenari applicativi e dei<br />

requisiti che sono stati esposti nei capitoli 4 e 5. <strong>Storage</strong> Interface si presenta<br />

come un servizio la cui <strong>in</strong>terfaccia espone o<strong>per</strong>azioni <strong>per</strong> la gestione<br />

della memorizzazione <strong>per</strong>sistente <strong>di</strong> risorse. In questo capitolo sarà fornita la<br />

specifica delle o<strong>per</strong>azioni, <strong>il</strong> modello dell’<strong>in</strong>formazione ed i protocolli<br />

<strong>per</strong> la comunicazione.


<strong>Progetto</strong> dell’Interfaccia Information Model e descrizione dell’<strong>in</strong>terfaccia<br />

L’<strong>in</strong>terfaccia del servizio scambia messaggi che trasportando <strong>in</strong>formazioni,<br />

<strong>per</strong>mettono <strong>il</strong> trattamento delle risorse def<strong>in</strong>ite <strong>in</strong> questa specifica. Il<br />

servizio offre delle specifiche funzioni <strong>per</strong> poter gestire queste risorse. Una<br />

determ<strong>in</strong>ata funzionalità del servizio è realizzata da una o<strong>per</strong>azione. Durante<br />

l’esecuzione <strong>di</strong> una o<strong>per</strong>azione, avviene lo scambio <strong>di</strong> messaggi tra consumer<br />

e provider del servizio. I messaggi sono classificati <strong>in</strong> messaggi <strong>di</strong> <strong>in</strong>put,<br />

output o fault e raggruppati <strong>in</strong> base alle funzionalità che offrono.<br />

Nella prima sezione verrà presentato l’<strong>in</strong>formation model della risorsa, l’<strong>in</strong>formation<br />

model dei messaggi e la specifica delle o<strong>per</strong>azioni. Saranno <strong>in</strong>oltre<br />

presentati i metadati predef<strong>in</strong>iti, che assolvono a funzioni nate dalla specifica<br />

dei requisiti.<br />

Il modello verrà formalizzato con WSDL e <strong>il</strong> protocollo verrà descritto<br />

come b<strong>in</strong><strong>di</strong>ng dell’<strong>in</strong>terfaccia def<strong>in</strong>ita con questo standard. Sarà fornita una<br />

descrizione del servizio con WSDL 2.0, della quale sarà <strong>il</strong>lustrato <strong>il</strong> b<strong>in</strong><strong>di</strong>ng<br />

su HTTP e su SOAP 1.1, ed una descrizione equivalente con WSDL 1.1 solo<br />

col b<strong>in</strong><strong>di</strong>ng SOAP 1.1. La scelta <strong>di</strong> fornire due versione è dettata dallo scarso<br />

supporto dei tool <strong>di</strong> sv<strong>il</strong>uppo <strong>per</strong> <strong>il</strong> WSDL 2.0, e dalla larga <strong>di</strong>ffusione della<br />

precedente e<strong>di</strong>zione.<br />

Il WSDL si basa sulla formalizzazione <strong>in</strong> XML del data model <strong>per</strong> le<br />

risorse e <strong>per</strong> i messaggi. Il data model sarà presentato <strong>in</strong> 6.2 ut<strong>il</strong>izzando<br />

XML Schema.<br />

Le scelte <strong>di</strong> implementazione rispettano i requisiti ed i v<strong>in</strong>coli elencati nel<br />

capitolo 5.<br />

I documenti XML descritti <strong>in</strong> questo capitolo sono riportati <strong>per</strong> <strong>in</strong>tero <strong>in</strong><br />

appen<strong>di</strong>ce A.<br />

6.1 Information Model e descrizione dell’<strong>in</strong>terfaccia<br />

Nei paragrafi <strong>di</strong> questa sezione saranno riportate le specifiche e le proprietà<br />

dei modelli <strong>in</strong>formativi <strong>per</strong> le risorse e <strong>per</strong> i messaggi. Le scelte si fondano<br />

127


<strong>Progetto</strong> dell’Interfaccia Information Model e descrizione dell’<strong>in</strong>terfaccia<br />

sulla specifica dei requisiti esposti nel capitolo 5 e sullo stu<strong>di</strong>o casi applicativi<br />

svolto nel capitolo 4.<br />

Per i modelli presentati saranno richiamati, ed eventualmente <strong>di</strong>scussi, i<br />

requisiti che hanno motivato le scelte <strong>di</strong> progettazione.<br />

6.1.1 Information Model delle Risorse: SI-R<br />

Si def<strong>in</strong>isce <strong>Storage</strong> Interface Resource e si <strong>in</strong><strong>di</strong>ca con l’acronimo SI-R<br />

l’entità trattata dal servizio <strong>di</strong> storage.<br />

Sulla base dei requisiti R001, R005, R006, R026, R027, R033, R034, R035,<br />

R036 e R037, sono state formulate le seguenti proprietà <strong>per</strong> <strong>il</strong> modello della<br />

risorsa:<br />

• SI-R contiene dati e metadati, ovvero <strong>in</strong>formazioni <strong>in</strong> formato adatto<br />

agli elaboratori e ulteriori <strong>in</strong>formazioni che forniscono una descrizione<br />

dei dati.<br />

• La risorsa è una rappresentazione dei dati che essa contiene. I metadati<br />

sono proprietà <strong>di</strong> questa rappresentazione.<br />

• Ogni risorsa ha un identificatore, che lo identifica univocamente sul<br />

servizio <strong>di</strong> storage su cui è mantenuta.<br />

• L’identificatore, composto con l’<strong>in</strong><strong>di</strong>rizzo del servizio, fornisce un URL<br />

che <strong>per</strong>mette l’accesso alla risorsa<br />

• Tra servizi <strong>di</strong> storage <strong>di</strong>fferenti, si usano gli URL <strong>per</strong> <strong>in</strong><strong>di</strong>rizzare e<br />

identificare globalmente le risorse <strong>in</strong> modo univoco<br />

• Ogni metadato ha un nome ed è usato <strong>per</strong> associare una proprietà ad<br />

una risorsa<br />

• Il nome identifica <strong>il</strong> metadato nell’ambito della risorsa, qu<strong>in</strong><strong>di</strong> <strong>per</strong> ogni<br />

risorsa può esistere un solo metadato con quel nome<br />

• Il nome <strong>di</strong> un metadato identifica universalmente <strong>il</strong> suo tipo e la sua<br />

semantica.<br />

128


<strong>Progetto</strong> dell’Interfaccia Information Model e descrizione dell’<strong>in</strong>terfaccia<br />

• Il nome <strong>di</strong> un metadato è un URI ed è possib<strong>il</strong>e adottare <strong>il</strong> meccanismo<br />

dei Namespace XML <strong>per</strong> l’identificazione del nome tramite prefisso<br />

• Il valore <strong>di</strong> un metadato è <strong>in</strong><strong>di</strong>rizzato dalla comb<strong>in</strong>azione dell’URL della<br />

risorsa e del nome del metadato.<br />

Il <strong>di</strong>segno <strong>in</strong> figura 6.1 rappresenta la struttura della risorsa.<br />

SI-Resource-Model<br />

resId<br />

serviceEndPo<strong>in</strong>t<br />

0..*<br />

0..1<br />

resId?<br />

name<br />

readonly?<br />

resId?<br />

mime?<br />

enco<strong>di</strong>ng?<br />

readonly?<br />

meta<br />

data<br />

Figura 6.1: Information Model <strong>di</strong> SI-R.<br />

Il requisito R026 raccomanda la compatib<strong>il</strong>ità con l’<strong>in</strong>formation model <strong>di</strong><br />

RDF e la specifica dell’<strong>in</strong>formation model ne ha tenuto conto. I requisiti<br />

R005, R035 e R037 <strong>per</strong>mettono la def<strong>in</strong>izione del seguente mapp<strong>in</strong>g tra le<br />

entità <strong>di</strong> una terna RDF e gli elementi della risorsa.<br />

Per ogni risorsa <strong>di</strong> <strong>Storage</strong> Interface si assume che ogni associazione tra<br />

dato e metadato equivale ad una terna RDF <strong>in</strong> cui:<br />

• Il soggetto della relazione è identificato dalla risorsa [R005]<br />

• Il pre<strong>di</strong>cato è rappresentato dal nome del metadato [R035]<br />

• L’oggetto è rappresentato dal valore del metadato [R037]<br />

In figura 6.2 sono mostrate graficamente le relazioni <strong>di</strong> questo mapp<strong>in</strong>g.<br />

129


<strong>Progetto</strong> dell’Interfaccia Information Model e descrizione dell’<strong>in</strong>terfaccia<br />

resource/data<br />

subject, pre<strong>di</strong>cate, object<br />

metadata name<br />

metadata value<br />

Resource Pro<strong>per</strong>ty Type Pro<strong>per</strong>ty Value<br />

Figura 6.2: Mapp<strong>in</strong>g <strong>di</strong> associazioni <strong>di</strong> metadati <strong>di</strong> SI-R con relazioni RDF.<br />

Grazie a questo aspetto è possib<strong>il</strong>e memorizzare <strong>in</strong> una risorsa sentenze<br />

RDF.<br />

In particolare, si è scelto <strong>di</strong> formalizzare l’<strong>in</strong>formation model delle risorse<br />

<strong>in</strong> modo generico onde fornire una maggiore versat<strong>il</strong>ità rappresentativa.<br />

Qualora una risorsa <strong>di</strong> <strong>Storage</strong> Interface abbia un modello più preciso, grazie<br />

al meccanismo <strong>di</strong> RDF Schema è possib<strong>il</strong>e <strong>di</strong>chiararla come appartenete a<br />

tipi specifici. Il meccanismo sarà <strong>il</strong>lustrato meglio più avanti.<br />

6.1.2 Information model dei messaggi ed o<strong>per</strong>azioni<br />

dell’<strong>in</strong>terfaccia<br />

Le o<strong>per</strong>azioni ed i messaggi dell’<strong>in</strong>terfaccia sono formulati sulla base dei<br />

requisiti R002, R003, R009, R015, R016, R021, R022, R024, R028, R029 ed<br />

R037.<br />

Le o<strong>per</strong>azioni sono raggruppate <strong>in</strong> c<strong>in</strong>que gruppi:<br />

• CRUD: si compone delle quattro o<strong>per</strong>azioni dei sistemi <strong>di</strong> memorizzazione<br />

<strong>per</strong>sistente, e <strong>per</strong>mette <strong>di</strong> o<strong>per</strong>are sul servizio creando, leggendo,<br />

mo<strong>di</strong>ficando e cancellando le risorse. Il requisito R003 è l’orig<strong>in</strong>e <strong>di</strong><br />

questo gruppo.<br />

• Plus: si compone <strong>di</strong> tre o<strong>per</strong>azioni che forniscono o<strong>per</strong>azioni aus<strong>il</strong>iarie<br />

<strong>per</strong> la gestione <strong>di</strong> risorse, quali la duplicazione <strong>di</strong>retta, l’elenco delle<br />

risorse <strong>di</strong> un servizio e l’elenco dei nomi dei metadati <strong>di</strong> una specifica<br />

130


<strong>Progetto</strong> dell’Interfaccia Information Model e descrizione dell’<strong>in</strong>terfaccia<br />

risorsa. Questo gruppo non nasce da requisiti specifici, ma è <strong>per</strong>messo<br />

da R028. Le funzionalità sono state dedotte da considerazioni <strong>di</strong><br />

carattere pratico emerse nell’analisi degli scenari.<br />

• Specialized: si compone <strong>di</strong> quattro o<strong>per</strong>azioni <strong>per</strong> la lettura e la mo<strong>di</strong>fica<br />

<strong>di</strong>retta dei dati e dei metadati. Le o<strong>per</strong>azioni sui metadati sono<br />

conseguenza del requisito R037, le o<strong>per</strong>azioni sui dati nascono da<br />

considerazioni pratiche e sono <strong>per</strong>messe dal requisito R028.<br />

• Functional: si compone <strong>di</strong> tre o<strong>per</strong>azioni che offrono funzioni atte a<br />

sod<strong>di</strong>sfare requisiti opzionali del servizio. La funzionalità <strong>di</strong> Lock<strong>in</strong>g<br />

è offerta sulla base del requisito R029, la funzionalità <strong>di</strong> validazione<br />

sulla base <strong>di</strong> R024. La funzionalità <strong>di</strong> verefica <strong>di</strong> con<strong>di</strong>zione nasce da<br />

considerazioni pratiche ed è <strong>per</strong>messai da R028<br />

• Event: Sulla base dei requisiti R021 ed R022, si offrono le funzionalità<br />

<strong>di</strong> gestione <strong>di</strong> sottoscrizione e <strong>di</strong> notifica <strong>di</strong> eventi.<br />

Durante le chiamate <strong>di</strong> o<strong>per</strong>azioni si ha uno scambio <strong>di</strong> messaggi tra le<br />

entità <strong>in</strong> gioco. Un messaggio è essenzialmente una <strong>in</strong>formazione che viene<br />

trasmessa al provider (messaggio <strong>di</strong> <strong>in</strong>put) o dal provider (messaggio <strong>di</strong><br />

output). Alcuni messaggi trasportano <strong>in</strong>formazioni, altri segnalano errori<br />

(messaggi <strong>di</strong> fault). La pr<strong>in</strong>cipale tipologia <strong>di</strong> messaggi è quella che contiene<br />

dati o metadati <strong>di</strong> SI-R, ad esempio <strong>il</strong> messaggio <strong>di</strong> output <strong>di</strong> una o<strong>per</strong>azione<br />

<strong>di</strong> lettura oppure <strong>il</strong> messaggio <strong>di</strong> <strong>in</strong>put <strong>di</strong> una o<strong>per</strong>azione <strong>di</strong> mo<strong>di</strong>fica.<br />

I modelli rappresentati nelle figure hanno i nomi che sono stati ut<strong>il</strong>izzati<br />

nella rappresentazione XML, la quale sarà <strong>in</strong>trodotta nella sezione 6.2.<br />

Nei prossimi paragrafi sarà presentata la specifica delle o<strong>per</strong>azioni del<br />

servizio, <strong>in</strong>sieme con i modelli dei messaggi che ogni<br />

Messaggi <strong>di</strong> <strong>in</strong>put, <strong>di</strong> output, <strong>di</strong> fault e generalità<br />

I messaggi delle o<strong>per</strong>azioni sul servizio sono classificati <strong>in</strong> messaggi <strong>di</strong> <strong>in</strong>put,<br />

messaggi <strong>di</strong> output o messaggi <strong>di</strong> fault. Questa classificazione segue<br />

<strong>il</strong> punto <strong>di</strong> vista del provider del servizio, <strong>per</strong> <strong>il</strong> quale un messaggio <strong>di</strong> <strong>in</strong>put<br />

è un messaggio che proviene dall’esterno (da consumer a provider) ed un<br />

messaggio <strong>di</strong> output è <strong>di</strong>retto verso l’esterno (da provider a consumer). I<br />

131


<strong>Progetto</strong> dell’Interfaccia Information Model e descrizione dell’<strong>in</strong>terfaccia<br />

messaggi <strong>di</strong> fault, sono usati <strong>per</strong> comunicare un qualche <strong>in</strong>conveniente avvenuto<br />

durante la chiamata <strong>di</strong> una o<strong>per</strong>azione, e <strong>in</strong> questi casi si sostituiscono<br />

al messaggio <strong>di</strong> risposta.<br />

Sulla base dei requisiti e su considerazioni pratiche, i messaggi <strong>di</strong> <strong>in</strong>put<br />

presentano delle caratteristiche comuni <strong>per</strong> ogni o<strong>per</strong>azione. Il requisito R015<br />

ed R016 richiedono che le <strong>in</strong>formazioni <strong>di</strong> autenticazione siano trasmesse<br />

<strong>in</strong>sieme ad un messaggio <strong>di</strong> <strong>in</strong>put. Considerazioni pratiche derivate dallo<br />

stu<strong>di</strong>o degli scenari hanno suggerito <strong>di</strong> aggiungere <strong>in</strong>formazioni <strong>di</strong> controllo<br />

che <strong>per</strong>mettono <strong>il</strong> management ed <strong>il</strong> debug del servizio.<br />

Per questo, un messaggio <strong>di</strong> <strong>in</strong>put trasporta opzionalmente:<br />

• Informazioni <strong>di</strong> autenticazione che <strong>per</strong>mettono l’attuazione del controllo<br />

degli accessi.<br />

• Informazioni sull’agent ut<strong>il</strong>izzato dal consumer, <strong>in</strong> modo da identificare<br />

specifici problemi applicativi o <strong>di</strong> compatib<strong>il</strong>ità tra implementazioni <strong>di</strong><br />

servizi e implementazioni <strong>di</strong> client.<br />

• Informazioni sull’orig<strong>in</strong>e del messaggio <strong>di</strong> <strong>in</strong>put, <strong>in</strong> modo da ottimizzare<br />

le <strong>per</strong>formance <strong>di</strong> memorizzazione e la tracciab<strong>il</strong>ità delle risorse<br />

memorizzate.<br />

• Informazioni <strong>per</strong> tracciare i messaggi, ad esempio <strong>in</strong> cui si è formulato<br />

l’<strong>in</strong>vio o una chiave univoca del messaggio.<br />

Le <strong>in</strong>formazioni <strong>per</strong> la tracciab<strong>il</strong>ità sono trasportate anche nei messaggi <strong>di</strong><br />

output.<br />

In figura 6.3 è rappresentato <strong>il</strong> modello dei messaggi su cui ogni <strong>in</strong>put ed<br />

output si basa.<br />

Si def<strong>in</strong>iscono sei messaggi <strong>di</strong> tipo fault:<br />

• Generic fault: descrive un errore generico <strong>per</strong> <strong>il</strong> quale non si è potuto<br />

rispondere ad una richiesta (ad esempio <strong>per</strong> via <strong>di</strong> un timeout)<br />

• Con<strong>di</strong>tion fault: è fallita la verifica <strong>di</strong> una con<strong>di</strong>zione specificata dalla<br />

richiesta<br />

132


<strong>Progetto</strong> dell’Interfaccia Information Model e descrizione dell’<strong>in</strong>terfaccia<br />

<strong>in</strong>put<br />

0..1<br />

0..1<br />

0..1<br />

0..1<br />

auth<br />

agent<br />

orig<strong>in</strong><br />

trace<br />

output<br />

0..1<br />

trace<br />

Figura 6.3: Information Model dei messaggi <strong>di</strong> <strong>in</strong>put e <strong>di</strong> output<br />

• Unsupported fault: la richiesta ha chiamato una qualche funzionalità<br />

non supportata dalla specifica implementazione del servizio<br />

• Unauthorized fault: la richiesta ha fallito la verifica delle autorizzazioni<br />

necessarie al suo espletamento<br />

• Internal Error: si è verificato un errore <strong>in</strong>terno al servizio e la richiesta<br />

non può essere portata a term<strong>in</strong>e<br />

• Input Error: <strong>il</strong> messaggio <strong>di</strong> <strong>in</strong>put non è valido e la richiesta non può<br />

essere portata a term<strong>in</strong>e<br />

generic con<strong>di</strong>tion<br />

unsupported unauthorized<br />

<strong>in</strong>ternalError <strong>in</strong>putError<br />

Figura 6.4: Tipi <strong>di</strong> messaggi <strong>di</strong> fault.<br />

133


<strong>Progetto</strong> dell’Interfaccia Information Model e descrizione dell’<strong>in</strong>terfaccia<br />

Alcuni messaggi <strong>di</strong> <strong>in</strong>put specificano una query sui dati, una query<br />

sui metadati o una con<strong>di</strong>zione. Le query sono delle <strong>in</strong>formazioni testuali<br />

passate al servizio, <strong>il</strong> cui effetto è la restituzione <strong>di</strong> dati o <strong>di</strong> metadati <strong>in</strong> genere<br />

<strong>di</strong>fferenti da quelli esattamente memorizzati nella risorsa. L’<strong>in</strong>terpretazione<br />

delle query e l’azione da <strong>in</strong>traprendere <strong>di</strong>pendono dalla implementazione del<br />

servizio. I dati e i metadati trasformati sono restituiti con <strong>in</strong>formazioni che<br />

<strong>di</strong>chiarano la trasformazione che è stata effettuata. Ad esempio, un servizio<br />

può implementare l’accesso parziale ai dati <strong>di</strong> SI-R grazie alle query, e i dati<br />

restituiti saranno accompagnati da <strong>in</strong>formazioni che descrivono <strong>il</strong> range <strong>di</strong><br />

dati restituito.<br />

Le con<strong>di</strong>zioni pongono un v<strong>in</strong>colo sull’espletamento della chiamata all’o<strong>per</strong>azione.<br />

I servizi che supportano le con<strong>di</strong>zioni, dovranno portare avanti <strong>il</strong><br />

processo <strong>in</strong>nescato dall’o<strong>per</strong>azione soltanto se la con<strong>di</strong>zione è verificata. In<br />

caso contrario, la risposta deve essere un messaggio <strong>di</strong> con<strong>di</strong>tion fault.<br />

L’implementazione <strong>di</strong> queste funzionalità non è obbligatoria, e un servizio<br />

potrà rispondere con un messaggio <strong>di</strong> errore <strong>di</strong> tipo unsupported fault a<br />

chiamate <strong>di</strong> o<strong>per</strong>azioni che contengono con<strong>di</strong>zioni o query.<br />

Ogni o<strong>per</strong>azione è con<strong>di</strong>zionata alle autorizzazioni <strong>in</strong> possesso al chiamante.<br />

Nella descrizione delle o<strong>per</strong>azioni seguenti, è sempre possib<strong>il</strong>e che <strong>in</strong> caso <strong>di</strong><br />

<strong>di</strong>ritti <strong>in</strong>sufficienti sia <strong>in</strong>viato un messaggio <strong>di</strong> errore <strong>di</strong> tipo unauthorized<br />

fault.<br />

O<strong>per</strong>azioni base dello storage <strong>per</strong>sistente<br />

L’o<strong>per</strong>azione Create si usa <strong>per</strong> creare una nuova risorsa. La chiamata da<br />

orig<strong>in</strong>e alla seguente <strong>in</strong>terazione:<br />

• In Input, è opzionale l’<strong>in</strong>vio dei dati della risorsa e <strong>di</strong> zero o più<br />

metadati.<br />

• La chiamata causa la creazione <strong>di</strong> una nuova risorsa nel servizio <strong>di</strong><br />

storage che contiene una copia dei dati e dei metadati <strong>in</strong>viati.<br />

• In output, viene restituito l’identificatore della nuova risorsa.<br />

134


<strong>Progetto</strong> dell’Interfaccia Information Model e descrizione dell’<strong>in</strong>terfaccia<br />

L’o<strong>per</strong>azione Read si usa <strong>per</strong> leggere una risorsa memorizzata. La chiamata<br />

da orig<strong>in</strong>e alla seguente <strong>in</strong>terazione:<br />

• In Input, si <strong>in</strong>via l’identificatore della risorsa <strong>di</strong> cui si vuole leggere dati<br />

e metadati. Sono supportati query su dati, metadati e con<strong>di</strong>zioni <strong>di</strong><br />

esecuzione.<br />

• L’o<strong>per</strong>azione è safe, ovvero la chiamata non è causa <strong>di</strong> azioni che<br />

mo<strong>di</strong>ficano lo stato della risorsa.<br />

• In output, viene restituito un messaggio che contiene i dati ed i metadati<br />

della risorsa.<br />

L’o<strong>per</strong>azione Update si usa <strong>per</strong> apportare una mo<strong>di</strong>fica ad una risorsa. La<br />

chiamata da orig<strong>in</strong>e alla seguente <strong>in</strong>terazione:<br />

• In Input, si <strong>in</strong>via l’identificatore della risorsa che si vuole mo<strong>di</strong>ficare,<br />

<strong>in</strong>sieme ai dati ed ai metadati, così come li si vuole memorizzare. È<br />

supportata l’esecuzione sottoposta a con<strong>di</strong>zione.<br />

• La chiamata causa la memorizzazione dei dati e dei metadati ricevuti<br />

nella risorsa specificata dall’identificatore. Il non <strong>in</strong>vio dei dati, o <strong>il</strong> non<br />

<strong>in</strong>vio dei metadati non comporta la loro cancellazione. L’o<strong>per</strong>azione<br />

è idempotente, ovvero <strong>il</strong> risultato non cambia ripetendo più volte la<br />

chiamata con gli stessi parametri <strong>di</strong> <strong>in</strong>put.<br />

• In output, <strong>in</strong> caso l’esecuzione proceda regolarmente, viene restituito un<br />

messaggio senza nessuna ulteriore <strong>in</strong>formazione. Un errore comporta<br />

l’<strong>in</strong>vio <strong>di</strong> un messaggio <strong>di</strong> fault appropriato.<br />

L’o<strong>per</strong>azione Delete rimuove una risorsa dal servizio. La chiamata da orig<strong>in</strong>e<br />

alla seguente <strong>in</strong>terazione:<br />

• In Input, si <strong>in</strong>via l’identificatore della risorsa che si desidera rimuovere.<br />

È supportata l’esecuzione sottoposta a con<strong>di</strong>zione.<br />

• La chiamata causa la rimozione della risorsa dal servizio <strong>di</strong> storage.<br />

L’identificatore e qu<strong>in</strong><strong>di</strong> l’URL della risorsa non sono più vali<strong>di</strong>, e una<br />

successiva richiesta sulla risorsa fornirà un errore. L’o<strong>per</strong>azione è idempotente,<br />

ovvero <strong>il</strong> risultato non cambia ripetendo più volte la chiamata<br />

con gli stessi parametri <strong>di</strong> <strong>in</strong>put.<br />

135


<strong>Progetto</strong> dell’Interfaccia Information Model e descrizione dell’<strong>in</strong>terfaccia<br />

• In output, <strong>in</strong> caso l’esecuzione proceda regolarmente, viene restituito un<br />

messaggio senza nessuna ulteriore <strong>in</strong>formazione. Un errore comporta<br />

l’<strong>in</strong>vio <strong>di</strong> un messaggio <strong>di</strong> fault appropriato.<br />

In figura 6.5 è riportato lo schema del modello <strong>di</strong> queste o<strong>per</strong>azioni <strong>in</strong>sieme<br />

ai messaggi scambiati.<br />

O<strong>per</strong>azioni <strong>per</strong> funzionalità <strong>di</strong> <strong>per</strong>formance<br />

L’o<strong>per</strong>azione Duplicate crea un duplicato <strong>di</strong> una risorsa specificata. La<br />

chiamata da orig<strong>in</strong>e alla seguente <strong>in</strong>terazione:<br />

• In Input, si <strong>in</strong>via l’identificatore della risorsa che si desidera duplicare.<br />

È supportata l’esecuzione sottoposta a con<strong>di</strong>zione.<br />

• La chiamata causa la creazione <strong>di</strong> una nuova risorsa che è una copia<br />

della risorsa <strong>di</strong> cui si è passato l’identificatore <strong>in</strong> <strong>in</strong>put.<br />

• In output, viene restituito l’identificatore della nuova risorsa.<br />

L’o<strong>per</strong>azione List fornisce un elenco degli identificatori delle risorse presenti<br />

nel servizio. La chiamata da orig<strong>in</strong>e alla seguente <strong>in</strong>terazione:<br />

• Non ci sono parametri richiesti <strong>in</strong> <strong>in</strong>put oltre a quelli comuni a tutti i<br />

messaggi (autorizzazione, traccia, etc.).<br />

• L’o<strong>per</strong>azione è safe, ovvero la chiamata non è causa <strong>di</strong> azioni che<br />

mo<strong>di</strong>ficano lo stato della risorsa.<br />

• In output, viene restituito l’elenco degli identificatori delle risorse memorizzate<br />

nel servizio.<br />

L’o<strong>per</strong>azione ProbeMeta fornisce l’elenco dei nomi dei metadati che sono<br />

stati associati ad una risorsa. La chiamata da orig<strong>in</strong>e alla seguente<br />

<strong>in</strong>terazione:<br />

• In Input, si <strong>in</strong>via l’identificatore della risorsa che si desidera duplicare.<br />

• L’o<strong>per</strong>azione è safe, ovvero la chiamata non è causa <strong>di</strong> azioni che<br />

mo<strong>di</strong>ficano lo stato della risorsa.<br />

136


<strong>Progetto</strong> dell’Interfaccia Information Model e descrizione dell’<strong>in</strong>terfaccia<br />

Create<br />

createIn<br />

Read<br />

readIn<br />

Update<br />

Delete<br />

deleteIn<br />

Input messages Output messages<br />

0..*<br />

0..1<br />

1<br />

0..1<br />

0..*<br />

0..1<br />

name<br />

meta<br />

data<br />

mime?<br />

enco<strong>di</strong>ng?<br />

resId<br />

queryData<br />

queryMeta<br />

con<strong>di</strong>tion<br />

0..*<br />

updateIn meta<br />

1<br />

1<br />

0..1<br />

0..1<br />

0..1<br />

name<br />

path?<br />

resId<br />

data<br />

mime?<br />

enco<strong>di</strong>ng?<br />

range?<br />

unit?<br />

con<strong>di</strong>tion<br />

resId<br />

con<strong>di</strong>tion<br />

createOut<br />

readOut<br />

1<br />

0..*<br />

0..1<br />

updateOut<br />

deleteOut<br />

name<br />

path?<br />

resId<br />

meta<br />

data<br />

mime?<br />

enco<strong>di</strong>ng?<br />

range?<br />

unit?<br />

Figura 6.5: Information model dei messaggi e delle o<strong>per</strong>azioni base <strong>per</strong> la<br />

memorizzazione <strong>per</strong>sistente.<br />

137


<strong>Progetto</strong> dell’Interfaccia Information Model e descrizione dell’<strong>in</strong>terfaccia<br />

• In output, viene restituito l’elenco dei nomi dei metadati memorizzati<br />

nella risorsa.<br />

In figura 6.6 è riportato lo schema del modello <strong>di</strong> queste o<strong>per</strong>azioni <strong>in</strong>sieme<br />

ai messaggi scambiati.<br />

Duplicate<br />

Input messages Output messages<br />

duplicateIn<br />

List<br />

ProbeMeta<br />

probeMetaIn<br />

1<br />

0..1<br />

resId<br />

con<strong>di</strong>tion<br />

duplicateOut<br />

1<br />

resId<br />

listIn listOut 0..*<br />

resId<br />

1<br />

resId<br />

0..*<br />

probeMetaOut metaName<br />

Figura 6.6: Information model dei messaggi e delle o<strong>per</strong>azioni <strong>per</strong> funzionalità<br />

duplicazione, lista <strong>di</strong> risorse e lista <strong>di</strong> metadati.<br />

O<strong>per</strong>azioni specializzate <strong>per</strong> dati e metadati<br />

L’o<strong>per</strong>azione ReadData recu<strong>per</strong>a soltanto <strong>il</strong> dato della risorsa. La chiamata<br />

da orig<strong>in</strong>e alla seguente <strong>in</strong>terazione:<br />

• In Input, si <strong>in</strong>via l’identificatore della risorsa <strong>di</strong> cui si vuole leggere i<br />

dati. Sono supportati query su dati e con<strong>di</strong>zioni <strong>di</strong> esecuzione.<br />

• L’o<strong>per</strong>azione è safe, ovvero la chiamata non è causa <strong>di</strong> azioni che<br />

mo<strong>di</strong>ficano lo stato della risorsa.<br />

• In output, viene restituito un messaggio che contiene i dati della risorsa.<br />

L’o<strong>per</strong>azione ReadMeta fornisce la lettura <strong>di</strong> un s<strong>in</strong>golo metadato associato<br />

alla risorsa. La chiamata da orig<strong>in</strong>e alla seguente <strong>in</strong>terazione:<br />

138


<strong>Progetto</strong> dell’Interfaccia Information Model e descrizione dell’<strong>in</strong>terfaccia<br />

• In Input, si <strong>in</strong>via l’identificatore della risorsa ed <strong>il</strong> nome del metadato<br />

che si vuole leggere. Sono supportati query su metadati e con<strong>di</strong>zioni <strong>di</strong><br />

esecuzione.<br />

• L’o<strong>per</strong>azione è safe, ovvero la chiamata non è causa <strong>di</strong> azioni che<br />

mo<strong>di</strong>ficano lo stato della risorsa.<br />

• In output, viene restituito un messaggio che contiene <strong>il</strong> metadato richiesto.<br />

L’o<strong>per</strong>azione UpdateData <strong>per</strong>mette la mo<strong>di</strong>fica dei soli dati della risorsa.<br />

La chiamata da orig<strong>in</strong>e alla seguente <strong>in</strong>terazione:<br />

• In Input, si <strong>in</strong>via l’identificatore della risorsa che si vuole mo<strong>di</strong>ficare,<br />

<strong>in</strong>sieme ai dati, così come li si vuole memorizzare. È supportata<br />

l’esecuzione sottoposta a con<strong>di</strong>zione.<br />

• La chiamata causa la memorizzazione dei dati ricevuti nella risorsa specificata<br />

dall’identificatore. L’o<strong>per</strong>azione è idempotente, ovvero <strong>il</strong> risultato<br />

non cambia ripetendo più volte la chiamata con gli stessi parametri<br />

<strong>di</strong> <strong>in</strong>put.<br />

• In output, <strong>in</strong> caso l’esecuzione proceda regolarmente, viene restituito un<br />

messaggio senza nessuna ulteriore <strong>in</strong>formazione. Un errore comporta<br />

l’<strong>in</strong>vio <strong>di</strong> un messaggio <strong>di</strong> fault appropriato.<br />

L’o<strong>per</strong>azione UpdateMeta <strong>per</strong>mette la mo<strong>di</strong>fica <strong>di</strong> un s<strong>in</strong>golo metadato<br />

associato alla risorsa. La chiamata da orig<strong>in</strong>e alla seguente <strong>in</strong>terazione:<br />

• In Input, si <strong>in</strong>via l’identificatore della risorsa e <strong>il</strong> nome del metadato<br />

che si vuole mo<strong>di</strong>ficare, <strong>in</strong>sieme al valore del metadato così come lo si<br />

vuole memorizzare. È supportata l’esecuzione sottoposta a con<strong>di</strong>zione.<br />

• La chiamata causa la memorizzazione del metadato ricevuto nella risorsa<br />

specificata dall’identificatore. L’o<strong>per</strong>azione è idempotente, ovvero<br />

<strong>il</strong> risultato non cambia ripetendo più volte la chiamata con gli stessi<br />

parametri <strong>di</strong> <strong>in</strong>put.<br />

• In output, <strong>in</strong> caso l’esecuzione proceda regolarmente, viene restituito un<br />

messaggio senza nessuna ulteriore <strong>in</strong>formazione. Un errore comporta<br />

l’<strong>in</strong>vio <strong>di</strong> un messaggio <strong>di</strong> fault appropriato.<br />

139


<strong>Progetto</strong> dell’Interfaccia Information Model e descrizione dell’<strong>in</strong>terfaccia<br />

In figura 6.7 è riportato lo schema del modello <strong>di</strong> queste o<strong>per</strong>azioni <strong>in</strong>sieme<br />

ai messaggi scambiati.<br />

O<strong>per</strong>azioni <strong>per</strong> funzionalità specifiche<br />

L’o<strong>per</strong>azione Lock previene la scrittura o la lettura <strong>di</strong> una risorsa. La<br />

chiamata da orig<strong>in</strong>e alla seguente <strong>in</strong>terazione:<br />

• In Input, si <strong>in</strong>viano l’identificatore della risorsa e le <strong>in</strong>formazioni sul<br />

lock da applicare. È supportata l’esecuzione sottoposta a con<strong>di</strong>zione.<br />

• La chiamata causa l’assegnazione o la rimozione <strong>di</strong> un lock alla risorsa.<br />

Una successiva o<strong>per</strong>azione sulla stessa risorsa, è sottoposta alla verifica<br />

della con<strong>di</strong>zione <strong>di</strong> lock<strong>in</strong>g. L’o<strong>per</strong>azione è idempotente, ovvero<br />

<strong>il</strong> risultato non cambia ripetendo più volte la chiamata con gli stessi<br />

parametri <strong>di</strong> <strong>in</strong>put.<br />

• In output, <strong>in</strong> caso l’esecuzione proceda regolarmente, viene restituito un<br />

messaggio senza nessuna ulteriore <strong>in</strong>formazione. Un errore comporta<br />

l’<strong>in</strong>vio <strong>di</strong> un messaggio <strong>di</strong> fault appropriato.<br />

L’o<strong>per</strong>azione Verify <strong>per</strong>mette la verifica <strong>di</strong> una con<strong>di</strong>zione su una risorsa.<br />

La chiamata da orig<strong>in</strong>e alla seguente <strong>in</strong>terazione:<br />

• In Input, è <strong>in</strong>viato l’identificatore della risorsa e la con<strong>di</strong>zione.<br />

• L’o<strong>per</strong>azione è safe, ovvero la chiamata non è causa <strong>di</strong> azioni che<br />

mo<strong>di</strong>ficano lo stato della risorsa.<br />

• In output, <strong>il</strong> risultato un booleano che specifica l’esito della verifica<br />

della con<strong>di</strong>zione.<br />

L’o<strong>per</strong>azione Validate restituisce <strong>in</strong>formazioni sulla conformità della risorsa<br />

sulla base dei tipi <strong>per</strong> cui è stata def<strong>in</strong>ita. La chiamata da orig<strong>in</strong>e alla seguente<br />

<strong>in</strong>terazione:<br />

• In Input, è <strong>in</strong>viato l’identificatore della risorsa.<br />

• L’o<strong>per</strong>azione è safe, ovvero la chiamata non è causa <strong>di</strong> azioni che<br />

mo<strong>di</strong>ficano lo stato della risorsa.<br />

140


<strong>Progetto</strong> dell’Interfaccia Information Model e descrizione dell’<strong>in</strong>terfaccia<br />

ReadData<br />

UpdateData<br />

Input messages Output messages<br />

readDataIn<br />

ReadMeta<br />

readMetaIn<br />

1<br />

0..1<br />

0..1<br />

resId<br />

queryData<br />

con<strong>di</strong>tion<br />

0..1<br />

updateDataIn data<br />

UpdateMeta<br />

updateMetaIn<br />

1<br />

0<br />

1<br />

0..1<br />

resId<br />

metaName<br />

0..1<br />

queryMeta<br />

0..1<br />

1<br />

1<br />

0..1<br />

0..1<br />

con<strong>di</strong>tion<br />

resId<br />

mime?<br />

enco<strong>di</strong>ng?<br />

range?<br />

unit?<br />

con<strong>di</strong>tion<br />

path?<br />

resId<br />

metaName<br />

meta<br />

con<strong>di</strong>tion<br />

readdataOut 0..1<br />

data<br />

readMetaOut<br />

0..1<br />

updateDataOut<br />

updateMetaOut<br />

mime?<br />

enco<strong>di</strong>ng?<br />

range?<br />

unit?<br />

name<br />

path?<br />

meta<br />

Figura 6.7: Information model dei messaggi e delle o<strong>per</strong>azioni <strong>di</strong><br />

memorizzazione <strong>di</strong> s<strong>in</strong>goli dati o s<strong>in</strong>goli metadati.<br />

141


<strong>Progetto</strong> dell’Interfaccia Information Model e descrizione dell’<strong>in</strong>terfaccia<br />

• In output, viene restituito un elenco <strong>di</strong> associazioni tra tipo e risultato<br />

della validazione. Per ogni tipo a cui la risorsa appartiene è verificata<br />

la vali<strong>di</strong>tà. Si veda 6.1.4 <strong>per</strong> ulteriori dettagli sulla validazione.<br />

In figura 6.8 è riportato lo schema del modello <strong>di</strong> queste o<strong>per</strong>azioni <strong>in</strong>sieme<br />

ai messaggi scambiati.<br />

Lock<br />

Verify<br />

Input messages Output messages<br />

lockIn<br />

verifyIn<br />

Validate<br />

validateIn<br />

1<br />

1<br />

0..1<br />

1<br />

1<br />

1<br />

resId<br />

lockInfo<br />

con<strong>di</strong>tion<br />

resId<br />

con<strong>di</strong>tion<br />

resId<br />

lockOut<br />

verifyOut 1<br />

result<br />

validateOut<br />

0..*<br />

vali<strong>di</strong>ty<br />

type<br />

result<br />

Figura 6.8: Information model dei messaggi e delle o<strong>per</strong>azioni <strong>per</strong><br />

funzionalità <strong>di</strong> lock<strong>in</strong>g e validazione.<br />

O<strong>per</strong>azioni <strong>per</strong> la gestione degli eventi<br />

L’o<strong>per</strong>azione Subscrive specifica l’<strong>in</strong>tenzione <strong>di</strong> sottoscrivere a notifiche<br />

<strong>di</strong> eventi <strong>di</strong> una risorsa. La chiamata da orig<strong>in</strong>e alla seguente <strong>in</strong>terazione:<br />

• In Input, è <strong>in</strong>viato l’id della risorsa e <strong>il</strong> nome dell’evento a cui ci si<br />

<strong>in</strong>tende sottoscrivere, congiuntamente al punto <strong>di</strong> accesso a cui <strong>in</strong>viare<br />

le notifiche qualora <strong>di</strong>sponib<strong>il</strong>e.<br />

• La chiamata causa l’iscrizione (o la sua revoca) alla lista dei dest<strong>in</strong>atari<br />

<strong>di</strong> notifiche <strong>in</strong> seguito ad eventi <strong>per</strong> la risorsa specificata. L’o<strong>per</strong>azione<br />

142


<strong>Progetto</strong> dell’Interfaccia Information Model e descrizione dell’<strong>in</strong>terfaccia<br />

è idempotente, ovvero <strong>il</strong> risultato non cambia ripetendo più volte la<br />

chiamata con gli stessi parametri <strong>di</strong> <strong>in</strong>put.<br />

• In output, <strong>in</strong> caso l’esecuzione proceda regolarmente, viene restituito un<br />

messaggio senza nessuna ulteriore <strong>in</strong>formazione. Un errore comporta<br />

l’<strong>in</strong>vio <strong>di</strong> un messaggio <strong>di</strong> fault appropriato.<br />

L’o<strong>per</strong>azione Poll restituisce l’elenco <strong>di</strong> risorse sulla quale si è verificato un<br />

evento a cui <strong>il</strong> consumer si è sottoscritto. La verifica dell’identità del consumer<br />

avviene tramite l’<strong>in</strong>vio delle <strong>in</strong>formazioni <strong>di</strong> autenticazione. Il servizio<br />

può usare questo meccanismo <strong>per</strong> notificare eventi qualora <strong>il</strong> consumer non<br />

abbia un proprio endpo<strong>in</strong>t al quale <strong>in</strong>viare messaggi. Questo meccanismo<br />

è alternativo all’<strong>in</strong>vio <strong>di</strong>retto <strong>di</strong> notifiche, qualora un consumer abbia un<br />

punto <strong>di</strong> accesso. Nel prossimo paragrafo sarà trattato questo aspetto più<br />

dettagliatamente. La chiamata da orig<strong>in</strong>e alla seguente <strong>in</strong>terazione:<br />

• Non ci sono parametri richiesti <strong>in</strong> <strong>in</strong>put oltre a quelli comuni a tutti i<br />

messaggi (autorizzazione, traccia, etc.).<br />

• L’o<strong>per</strong>azione è safe, ovvero la chiamata non è causa <strong>di</strong> azioni che<br />

mo<strong>di</strong>ficano lo stato della risorsa.<br />

• In output, è restituita la lista degli eventi a cui l’identità autenticata<br />

risulta sottoscritta.<br />

In figura 6.9 è riportato lo schema del modello <strong>di</strong> queste o<strong>per</strong>azioni <strong>in</strong>sieme<br />

ai messaggi scambiati.<br />

6.1.3 Interfaccia delle notifiche<br />

I requisiti R021 e R022 specificano che <strong>Storage</strong> Interface deve supportare<br />

la notifica <strong>di</strong> eventi tramite messaggi a dest<strong>in</strong>atari designati. L’o<strong>per</strong>azione<br />

Notify è qu<strong>in</strong><strong>di</strong> un’o<strong>per</strong>azione che dal punto <strong>di</strong> vista del provider, trasmette<br />

un messaggio output, poiché è dal servizio che è avviata la chiamata. Le<br />

specifiche <strong>di</strong> <strong>Storage</strong> Interface def<strong>in</strong>iscono l’<strong>in</strong>terfaccia delle notifiche un<br />

punto <strong>di</strong> accesso implementato sul consumer che <strong>per</strong>mette l’<strong>in</strong>vio <strong>di</strong> messaggi<br />

<strong>di</strong> tipo notifyOut <strong>in</strong> conseguenza <strong>di</strong> eventi.<br />

143


<strong>Progetto</strong> dell’Interfaccia Information Model e descrizione dell’<strong>in</strong>terfaccia<br />

Subscribe<br />

Poll<br />

Input messages Output messages<br />

subscribeIn<br />

1<br />

notifyIn<br />

resId<br />

0..1<br />

subscriber<br />

1<br />

eventName<br />

subscribeOut<br />

notifyOut 0..*<br />

event<br />

resId<br />

eventName<br />

time?<br />

Figura 6.9: Information model dei messaggi e delle o<strong>per</strong>azioni a supporto<br />

della notifica <strong>di</strong> eventi.<br />

Tuttavia l’<strong>in</strong>vio <strong>di</strong> un messaggio prevede che <strong>il</strong> dest<strong>in</strong>atario fornisca un<br />

punto <strong>di</strong> accesso cui spe<strong>di</strong>re la notifica e che qu<strong>in</strong><strong>di</strong> implementi l’<strong>in</strong>terfaccia<br />

<strong>di</strong> cui sopra, ma non tutti i consumer ne sono dotati. Per questo motivo<br />

è possib<strong>il</strong>e ut<strong>il</strong>izzare l’o<strong>per</strong>azione <strong>di</strong> poll<strong>in</strong>g descritta nell’ultimo paragrafo<br />

della precedente sezione.<br />

L’o<strong>per</strong>azione Notify <strong>in</strong>via un messaggio unico col quale si <strong>in</strong>forma un<br />

evento avvenuto su una risorsa. L’<strong>in</strong>terazione <strong>di</strong> una o<strong>per</strong>azione <strong>di</strong> notifica è<br />

la seguente:<br />

• Un evento su una risorsa <strong>per</strong> <strong>il</strong> quale esista una entità sottoscritta con<br />

punto <strong>di</strong> accesso causa l’emissione del messaggio <strong>di</strong> notifica.<br />

• In output, è <strong>in</strong>viata una lista <strong>di</strong> uno o più eventi che sono avvenuti ed<br />

ai quali <strong>il</strong> dest<strong>in</strong>atario risulta sottoscritto.<br />

In figura 6.10 è riportato lo schema del modello <strong>di</strong> questa o<strong>per</strong>azione e del<br />

messaggio. Si noti che si tratta dello stesso messaggio <strong>di</strong> output visto nella<br />

o<strong>per</strong>azione <strong>di</strong> Poll.<br />

144


<strong>Progetto</strong> dell’Interfaccia Information Model e descrizione dell’<strong>in</strong>terfaccia<br />

Notify<br />

Output messages<br />

notifyOut<br />

6.1.4 Dati predef<strong>in</strong>iti<br />

0..*<br />

event<br />

resId<br />

eventName<br />

time?<br />

Figura 6.10: Interfaccia <strong>per</strong> le notifiche.<br />

La specifica <strong>di</strong> <strong>Storage</strong> Interface fornisce dei tipi <strong>di</strong> metadati predef<strong>in</strong>iti.<br />

Come def<strong>in</strong>ito da R035, <strong>il</strong> nome del metadato ne identifica <strong>il</strong> tipo, la s<strong>in</strong>tassi<br />

e la semantica.<br />

Il metadato <strong>di</strong> nome “types” contiene un elenco <strong>di</strong> type. Ogni elemento<br />

specifica che la risorsa appartiene ad uno specifico tipo, <strong>il</strong> quale sarà ut<strong>il</strong>izzato<br />

<strong>in</strong> fase <strong>di</strong> validazione nella chiamata dell’o<strong>per</strong>azione Validate. In caso non<br />

sia associato questo metadato alla risorsa, la funzione <strong>di</strong> validazione non<br />

effettua nessuna verifica. I type sono nomi qualificati, <strong>in</strong> particolare un type<br />

può essere un rdf:type, <strong>il</strong> meccanismo <strong>di</strong> validazione <strong>di</strong> RDF Schema può<br />

essere adottato. Grazie a questa funzionalità <strong>Storage</strong> Interface rispetta la<br />

raccomandazione del requisito R027.<br />

L’o<strong>per</strong>azione <strong>di</strong> Lock o<strong>per</strong>a <strong>di</strong>rettamente sul metadato <strong>di</strong> nome “lock”.<br />

Le <strong>in</strong>formazioni <strong>di</strong> lock<strong>in</strong>g che seguono alla chiamata <strong>di</strong>retta dell’o<strong>per</strong>azione,<br />

memorizzano <strong>il</strong> proprietario e la data del lock <strong>in</strong> questo metadato. Di fatto,<br />

l’o<strong>per</strong>azione Lock è una scorciatoia <strong>per</strong> l’uso <strong>di</strong> UpdateMeta con valore . Per<br />

recu<strong>per</strong>are <strong>in</strong>formazioni sullo stato del lock. Va sottol<strong>in</strong>eato che tutte queste<br />

o<strong>per</strong>azioni richiedono l’autorizzazione del chiamante, e <strong>in</strong> genere potrebbero<br />

fallire qualora i <strong>di</strong>ritti non siano sufficienti.<br />

Si ricorda che <strong>per</strong> <strong>il</strong> requisito R034 i nomi qui def<strong>in</strong>iti dovranno avere una<br />

qualifica universale (ad esempio si possono usare degli URI) nel data model<br />

che sarà adottato. Il metadato “namespace” <strong>per</strong>mette <strong>di</strong> usare <strong>il</strong> meccanismo<br />

che <strong>per</strong>mette una s<strong>in</strong>tassi abbreviata <strong>per</strong> specificare i nomi dei metadati<br />

145


<strong>Progetto</strong> dell’Interfaccia Data Model XML<br />

<strong>di</strong> una risorsa. In particolare, nel data model basato su XML sarà usato <strong>il</strong><br />

meccanismo dei namespace [XMLNamespace] <strong>per</strong> la qualifica dei nomi. In<br />

astratto, <strong>il</strong> contenuto <strong>di</strong> “namespace” è una lista <strong>di</strong> URI e prefissi, grazie al<br />

quale un nome può essere qualificato attraverso una implementazione che usa<br />

<strong>il</strong> prefisso al posto dell’<strong>in</strong>tero URI.<br />

In figura 6.11 sono riportati I modelli <strong>in</strong>formativi<br />

lock<br />

name=“lock”<br />

1<br />

1<br />

owner<br />

creation<br />

namespaces<br />

name=“namespaces”<br />

types<br />

name=“types”<br />

0..*<br />

uri<br />

prefix<br />

ns<br />

0..*<br />

type<br />

Figura 6.11: Information model dei metadati predef<strong>in</strong>iti <strong>di</strong> <strong>Storage</strong> Interface.<br />

6.2 Data Model XML<br />

Il requisito R030 richiede che l’<strong>in</strong>formation model ut<strong>il</strong>izzato <strong>per</strong> le risorse e<br />

i messaggi <strong>di</strong> <strong>Storage</strong> Interface, <strong>il</strong>lustrato <strong>in</strong> sezione 6.1, possa essere rappresentato<br />

con XML. Tuttavia i requisiti R025 e R036 raccomandano l’impiego<br />

<strong>di</strong> WSDL <strong>per</strong> descrivere l’<strong>in</strong>terfaccia del servizio e poichè WSDL si basa<br />

su tipi <strong>di</strong> dati XML, è stato realizzato un documento XML Schema ( ve<strong>di</strong><br />

[XMLSchema1] e [XMLSchema2]) che formalizza <strong>il</strong> data model XML del<br />

modello dell’<strong>in</strong>formazione.<br />

Il risultato è stato sud<strong>di</strong>viso <strong>in</strong> due f<strong>il</strong>e:<br />

• primo, idn-storage-<strong>in</strong>terface.xsd, sono formalizzati <strong>in</strong> XML messaggi<br />

scambiati dall’<strong>in</strong>terfaccia<br />

146


<strong>Progetto</strong> dell’Interfaccia Data Model XML<br />

• Nel secondo, idn-storage-<strong>in</strong>terface-ext.xsd, sono formalizzati i metadati<br />

predef<strong>in</strong>iti <strong>di</strong> SI-R<br />

Questi f<strong>il</strong>e saranno <strong>di</strong>rettamente importati nei documenti WSDL che def<strong>in</strong>iscono<br />

<strong>il</strong> servizio, ed <strong>in</strong> particolare gli stessi f<strong>il</strong>e .xsd sono riut<strong>il</strong>izzab<strong>il</strong>i <strong>per</strong><br />

le <strong>in</strong>terfacce descritte con WSDL 2.0 o WSDL 1.1.<br />

Per via della loro lunghezza, questi documenti riportati <strong>in</strong> appen<strong>di</strong>ce A.<br />

Saranno brevemente <strong>il</strong>lustrati i punti salienti <strong>in</strong> questa sezione.<br />

6.2.1 Panoramica schema XML dei messaggi<br />

Il documento idn-storage-<strong>in</strong>terface.xsd def<strong>in</strong>isce la s<strong>in</strong>tassi XML dei messaggi<br />

dell’<strong>in</strong>terfaccia e <strong>di</strong>chiara i tipi fondamentali su cui essa si basa <strong>per</strong> <strong>il</strong><br />

funzionamento.<br />

I messaggi sono rappresentati con elementi (xsd:element) ed i tipi sono<br />

sia xsd:complexType che xsd:simpleType. Inoltre è def<strong>in</strong>ito come elemento lo<br />

schema <strong>di</strong> SI-R: .<br />

I tipi più importanti sono quelli che rappresentano gli elementi fondamentali<br />

che compongono SI-R e i tipi base da cui derivano i messaggi.<br />

• : rappresenta l’identifier delle risorse,<br />

ed è derivato da xsd:anyURI (si ricorda che SI-R è identificata da URL).<br />

• : rappresenta <strong>il</strong> nucleo dell’<strong>in</strong>formazione<br />

<strong>di</strong> una risorsa. Si tratta <strong>di</strong> un elemento che contiene una<br />

sequenza <strong>di</strong> caratteri, byte o XML.<br />

• : rappresenta una <strong>in</strong>formazione<br />

che descrive la risorsa. In XML un metadato ha obbligatoriamente<br />

un attributo <strong>di</strong> nome “name” che def<strong>in</strong>isce <strong>il</strong> nome del metadato e ne<br />

identifica <strong>il</strong> suo tipo grazie ad un URI.<br />

147


<strong>Progetto</strong> dell’Interfaccia Data Model XML<br />

Tutti i messaggi derivano dai seguenti tipi base:<br />

• <br />

• <br />

• <br />

Questi tipi def<strong>in</strong>iscono la s<strong>in</strong>tassi XML del modello descritto <strong>in</strong> 6.1.<br />

La s<strong>in</strong>tassi dei messaggi è formalizzata da istanze <strong>di</strong> elementi. Per ogni<br />

tipo <strong>di</strong> messaggio descritto <strong>in</strong> 6.1, esiste un elemento che lo rappresenta <strong>in</strong><br />

XML. Alcuni esempi sono:<br />

• rappresenta un messaggio <strong>di</strong> <strong>in</strong>put dell’o<strong>per</strong>azione<br />

<strong>di</strong> creazione.<br />

• rappresenta un messaggio <strong>di</strong> <strong>in</strong>put dell’o<strong>per</strong>azione<br />

<strong>di</strong> lettura.<br />

• rappresenta un messaggio <strong>di</strong> output<br />

dell’o<strong>per</strong>azione <strong>di</strong> lettura.<br />

• rappresenta un messaggio <strong>di</strong> notifica<br />

<strong>in</strong>viato dal servizio.<br />

• rappresenta un messaggio <strong>di</strong><br />

errore che viene trasmesso qualora l’o<strong>per</strong>azione richiesta non possa<br />

essere portata a term<strong>in</strong>e <strong>per</strong> <strong>di</strong>ritti <strong>in</strong>sufficienti.<br />

Il “targetNamespace” <strong>di</strong> questo schema è l’<strong>in</strong><strong>di</strong>rizzo<br />

http://www.<strong>in</strong>terdatanet.org/ns/<strong>Storage</strong>Interface, al quale è associato <strong>il</strong> prefisso<br />

locale “idnsi”.<br />

Nel seguente listato è riportato l’<strong>in</strong>izio del documento, nel quale si può<br />

vedere l’elemento ra<strong>di</strong>ce della def<strong>in</strong>izione dello schema con gli attributi che<br />

contiene:<br />

148


<strong>Progetto</strong> dell’Interfaccia Data Model XML<br />

<br />

Il documento completo dello schema è riportato <strong>in</strong> appen<strong>di</strong>ce A.1.<br />

6.2.2 Panoramica schema XML dei tipi predef<strong>in</strong>iti<br />

Il documento idn-storage-<strong>in</strong>terface-ext.xsd def<strong>in</strong>isce la s<strong>in</strong>tassi XML dei<br />

metadati predef<strong>in</strong>iti <strong>di</strong> una SI-R. Questi sono def<strong>in</strong>iti come estensione <strong>di</strong><br />

“idnsi:meta”, def<strong>in</strong>ito dal documento visto nel precedente paragrafo, e rappresentano<br />

i metadati che def<strong>in</strong>iscono <strong>il</strong> tipo della risorsa, i namespace ut<strong>il</strong>izzati<br />

lo stato del lock.<br />

Il significato semantico <strong>di</strong> questi elementi è stato descritto <strong>in</strong> 6.1.4 e nel<br />

documento sono <strong>di</strong>chiarati come complexType che def<strong>in</strong>iscono la s<strong>in</strong>tassi XML.<br />

Usando la notazione del prefisso locale questi si <strong>in</strong><strong>di</strong>cano con:<br />

• idnsix:types<br />

• idnsix:lock<br />

• idnsix:namespaces<br />

I nomi estesi con l’URI espresso completamente sono i seguenti.<br />

• http://www.<strong>in</strong>terdatanet.org/ns/<strong>Storage</strong>Interface/ext#types<br />

• http://www.<strong>in</strong>terdatanet.org/ns/<strong>Storage</strong>Interface/ext#lock<br />

• http://www.<strong>in</strong>terdatanet.org/ns/<strong>Storage</strong>Interface/ext#namespaces<br />

Un metadato <strong>di</strong> una SI-R <strong>il</strong> cui nome corrisponde ad uno dei tre visti qui<br />

sopra, deve rispettare la s<strong>in</strong>tassi del tipo. Il seguente esempio mostra un<br />

metadato <strong>di</strong> una SI-R che memorizza <strong>in</strong>formazioni sul lock<strong>in</strong>g.<br />

149


<strong>Progetto</strong> dell’Interfaccia Il WSDL dell’<strong>in</strong>terfaccia<br />

<br />

Cristiano<br />

2007-11-21T11:13:10<br />

<br />

Il prefisso locale “idnsix” è associato al “targetNamespace” <strong>di</strong> questo schema,<br />

http://www.<strong>in</strong>terdatanet.org/ns/<strong>Storage</strong>Interface/ext.<br />

Nel seguente listato è riportato l’<strong>in</strong>izio del documento, nel quale si può<br />

vedere l’elemento ra<strong>di</strong>ce della def<strong>in</strong>izione dello schema con gli attributi che<br />

contiene:<br />

<br />

Il documento, riportato <strong>per</strong> <strong>in</strong>tero <strong>in</strong> appen<strong>di</strong>ce A.2, formalizza la s<strong>in</strong>tassi<br />

XML <strong>di</strong> questi metadati.<br />

6.3 Il WSDL dell’<strong>in</strong>terfaccia<br />

Il requisito R025 raccomanda l’impiego <strong>di</strong> WSDL <strong>per</strong> descrivere l’<strong>in</strong>terfaccia<br />

del servizio <strong>in</strong> term<strong>in</strong>i astratti (data model dei tipi e delle o<strong>per</strong>azioni),<br />

<strong>il</strong> requisito R036 <strong>in</strong>vece <strong>per</strong>mette che WSDL sia usato <strong>per</strong> def<strong>in</strong>ire la sua<br />

implementazione.<br />

L’<strong>in</strong>terfaccia <strong>di</strong> <strong>Storage</strong> Interface è formalizzata con un WSDL conforme<br />

allo standard 2.0 [WSDL2], raccolto nel f<strong>il</strong>e idn-storage-<strong>in</strong>terface.wsdl, <strong>il</strong><br />

cui testo è riportato <strong>per</strong> <strong>in</strong>tero <strong>in</strong> appen<strong>di</strong>ce A.3.<br />

150


<strong>Progetto</strong> dell’Interfaccia Il WSDL dell’<strong>in</strong>terfaccia<br />

Il “targetNamespace” del WSDL è l’<strong>in</strong><strong>di</strong>rizzo<br />

http://www.<strong>in</strong>terdatanet.org/ns/<strong>Storage</strong>Interface, che corrisponde al namespace<br />

del documento dei messaggi, visto nella sezione precedente.<br />

Nel seguente listato è riportato l’<strong>in</strong>izio del WSDL, nel quale si può vedere<br />

l’elemento ra<strong>di</strong>ce con i suoi attributi:<br />

<br />

Il documento def<strong>in</strong>isce le o<strong>per</strong>azioni, le quali ut<strong>il</strong>izzano i messaggi rappresentati<br />

con <strong>il</strong> data model XML presentato nel paragrafo precedente.<br />

Il wsdl def<strong>in</strong>isce 8 <strong>in</strong>terfacce:<br />

• : è una <strong>in</strong>terfaccia speciale,<br />

che raggruppa i messaggi <strong>di</strong> errore generati dal servizio, ed è<br />

ut<strong>il</strong>zzata soltanto <strong>per</strong> semplificare la struttura del documento.<br />

• : def<strong>in</strong>isce le o<strong>per</strong>azioni<br />

base <strong>per</strong> lo storage <strong>per</strong>sistente ed estende l’<strong>in</strong>terfaccia<br />

idnsi:<strong>Storage</strong>Interface.Faults.<br />

• : def<strong>in</strong>isce o<strong>per</strong>azioni<br />

aus<strong>il</strong>iarie <strong>per</strong> la gestione delle risorse.<br />

• : def<strong>in</strong>isce le<br />

o<strong>per</strong>azioni <strong>per</strong> l’accesso specializzato ai dati ed ai metadati <strong>di</strong> una SI-R.<br />

• : def<strong>in</strong>isce o<strong>per</strong>eazioni<br />

<strong>per</strong> assolvere a funzionalità <strong>di</strong> lock<strong>in</strong>g e validazione.<br />

• : def<strong>in</strong>isce l’<strong>in</strong>terfaccia<br />

<strong>per</strong> la gestione degli eventi.<br />

151


<strong>Progetto</strong> dell’Interfaccia Il WSDL dell’<strong>in</strong>terfaccia<br />

• : def<strong>in</strong>isce l’<strong>in</strong>terfaccia che<br />

<strong>in</strong>globa tutte le <strong>in</strong>terfacce <strong>di</strong> cui sopra, e qu<strong>in</strong><strong>di</strong> def<strong>in</strong>isce un servizio<br />

che offre tutte le funzionalità descritte da questa specifica.<br />

• : def<strong>in</strong>isce l’<strong>in</strong>terfaccia<br />

<strong>per</strong> l’output <strong>di</strong> messaggi <strong>di</strong> notifica.<br />

Queste <strong>in</strong>terfacce def<strong>in</strong>iscono la s<strong>in</strong>tassi del modello def<strong>in</strong>ito come visto<br />

nella sezione 6.1, e rispechiano lo stesso raggrouppamento.<br />

Il seguente esempio <strong>il</strong>lustra una parte del documento, dove si def<strong>in</strong>isce<br />

l’<strong>in</strong>terfaccia <strong>per</strong> le o<strong>per</strong>azioni <strong>di</strong> base e l’<strong>in</strong>terfaccia completa.<br />

<br />

.....<br />

<br />

<br />

<br />

<br />

<br />

.....<br />

<br />

.....<br />

<br />

.....<br />

<br />

6.3.1 Def<strong>in</strong>izione del protocollo: <strong>il</strong> b<strong>in</strong><strong>di</strong>ng del WSDL<br />

Il WSDL è ut<strong>il</strong>izzato <strong>per</strong> specificare <strong>il</strong> protocollo <strong>di</strong> trasporto del servizio<br />

<strong>di</strong> <strong>Storage</strong> Interface. In particolare, <strong>il</strong> documento descrive le regole <strong>per</strong><br />

la comunicazione sia con HTTP, sia con SOAP.<br />

152


<strong>Progetto</strong> dell’Interfaccia Il WSDL dell’<strong>in</strong>terfaccia<br />

Il requisito R010 raccomanda una implementazione Resource Oriented Architecture<br />

del servizio. Il b<strong>in</strong><strong>di</strong>ng HTTP del WSDL è def<strong>in</strong>ito nel documento<br />

come riportato nel seguente listato:<br />

<br />

.....<br />

<br />

<br />

.....<br />

<br />

La porzione <strong>di</strong> co<strong>di</strong>ce riportata <strong>il</strong>lustra come <strong>il</strong> b<strong>in</strong><strong>di</strong>ng <strong>di</strong> nome<br />

“<strong>Storage</strong>RoaB<strong>in</strong><strong>di</strong>ng” def<strong>in</strong>isca l’uso <strong>di</strong> “http://www.w3.org/ns/wsdl/http” <strong>per</strong><br />

<strong>il</strong> trasporto. Nel documento, sono poi riportate le regole <strong>di</strong> serializzazione<br />

<strong>per</strong> le o<strong>per</strong>azioni. Nella porzione <strong>di</strong> co<strong>di</strong>ce riportata possiamo vedere<br />

la specifica dell’o<strong>per</strong>azioni “idnsi:read” e “idnsi:update”. Il documento specifica<br />

che <strong>il</strong> messaggio <strong>di</strong> <strong>in</strong>put della lettura sia serializzato <strong>in</strong> una richiesta<br />

GET <strong>di</strong> HTTP e che appende all’URL del servizio l’identificatore della risorsa,<br />

e che siano applicate le regole <strong>di</strong> default <strong>per</strong> la serializzazione del<br />

messaggio <strong>di</strong> output nella risposta. Il messaggio <strong>di</strong> scrittura <strong>in</strong>vece usa <strong>il</strong><br />

metodo PUT ed <strong>in</strong> più specifica l’uso <strong>di</strong> una serializzazione dell’<strong>in</strong>put <strong>di</strong> tipo<br />

“application/x-www-form-urlencoded”.<br />

Il requisito R011 <strong>per</strong>mette la def<strong>in</strong>izione <strong>di</strong> servizi <strong>di</strong> <strong>Storage</strong> Interface che<br />

ut<strong>il</strong>izzano protocolli <strong>di</strong>fferenti. Visto che con un WSDL è fac<strong>il</strong>e descrivere una<br />

implementazione SOAP, questa è stata aggiunta con uno specifico b<strong>in</strong><strong>di</strong>ng.<br />

Il seguente listato mostra una porzione della sua def<strong>in</strong>izione:<br />

153


<strong>Progetto</strong> dell’Interfaccia Il WSDL dell’<strong>in</strong>terfaccia<br />

<br />

.....<br />

<br />

<br />

.....<br />

<br />

Nella prossimo capitolo, nella sezione 7.3, saranno <strong>il</strong>lustrati degli esempi<br />

concreti <strong>di</strong> come <strong>in</strong> una o<strong>per</strong>azione <strong>di</strong> lettura i messaggi sono rappresentati<br />

<strong>in</strong> XML e come avviene <strong>il</strong> b<strong>in</strong><strong>di</strong>ng su HTTP e su SOAP.<br />

Il documento completo del WSDL è riportato <strong>in</strong> appen<strong>di</strong>ce A.3,<br />

6.3.2 Il WSDL 1.1 del servizio<br />

Il WSDL descrive la s<strong>in</strong>tassi dei messaggi e <strong>il</strong> protocollo col quale si eseguono<br />

le o<strong>per</strong>azioni <strong>di</strong> un Web Service. <strong>Storage</strong> Interface è stato formalizzato<br />

sullo standard WSDL 2.0, tuttavia molti strumenti <strong>per</strong> lo sv<strong>il</strong>uppo <strong>di</strong> Web<br />

Service, ancora non riconoscono <strong>il</strong> nuovo formato. WSDL 1.1 è più <strong>di</strong>ffuso<br />

ma pone alcune limitazioni che lo rendono <strong>in</strong>adatto alla descrizione <strong>di</strong> alcuni<br />

tipi <strong>di</strong> servizi.<br />

In particolare con WSDL 1.1 non è possib<strong>il</strong>e def<strong>in</strong>ire una ROA, cioè un<br />

servizio che si basa sui meto<strong>di</strong> <strong>di</strong> HTTP.<br />

Tuttavia questa e<strong>di</strong>zione funziona bene con SOAP e, sebbene <strong>di</strong>fferisca<br />

nella s<strong>in</strong>tassi, un servizio che usa questo protocollo è possib<strong>il</strong>e descriverlo sia<br />

con WSDL 1.1 che con WSDL 2.0.<br />

Per questo motivo, durante <strong>il</strong> lavoro <strong>di</strong> tesi è stato sv<strong>il</strong>uppato un documento<br />

che descrive l’<strong>in</strong>terfaccia <strong>di</strong> <strong>Storage</strong> Interface limitatamente al supporto <strong>di</strong><br />

154


<strong>Progetto</strong> dell’Interfaccia Il WSDL dell’<strong>in</strong>terfaccia<br />

SOAP, che usa le specifiche e la s<strong>in</strong>tassi della precedente e<strong>di</strong>zione <strong>di</strong> WSDL. I<br />

due documenti <strong>di</strong>fferiscono nella forma, ma rappresentano lo stesso servizio.<br />

In appen<strong>di</strong>ce A.4 è riportato <strong>il</strong> documento del WSDL 1.1 che descrive <strong>il</strong><br />

servizio ed <strong>il</strong> protocollo SOAP.<br />

155


Capitolo<br />

7<br />

Implementazione del Servizio<br />

“I have always wished for my computer to be as easy to use as<br />

my telephone; my wish has come true because I can no longer<br />

figure out how to use my telephone.”<br />

Bjarne Stroustrup<br />

A partire dai WSDL, sono stati sv<strong>il</strong>uppati due prototipi <strong>per</strong> <strong>il</strong> servizio <strong>di</strong><br />

<strong>Storage</strong> Interface.<br />

Il primo è stato realizzato <strong>in</strong> Java 1 , che oggigiorno è una delle pr<strong>in</strong>cipali<br />

piattaforme <strong>per</strong> lo sv<strong>il</strong>uppo <strong>di</strong> Web Service basati su SOAP.<br />

L’altro prototipo è stato sv<strong>il</strong>uppato ut<strong>il</strong>izzando PHP 2 ed è stato testato<br />

su un web server Apache.<br />

1 http://java.sun.com/<br />

2 http://www.php.net/


Implementazione del Servizio Implementazione Java con JAX-WS 2.1<br />

L’approccio Java <strong>per</strong>mette <strong>di</strong> sv<strong>il</strong>uppare e mantenere soluzioni più complesse,<br />

e qu<strong>in</strong><strong>di</strong> si presta meglio come piattaforma <strong>per</strong> affrontare la sfida della<br />

realizzazione della architettura <strong>di</strong> <strong>InterDataNet</strong>.<br />

PHP d’altro canto è un l<strong>in</strong>guaggio semplice ma dotato <strong>di</strong> alta capacità<br />

espressiva nei confronti <strong>di</strong> HTTP e ben si adatta <strong>per</strong> realizzare soluzioni ROA<br />

ed alla prototipizzazione veloce <strong>di</strong> applicazioni. Il servizio che si basa su PHP<br />

ha <strong>per</strong>messo <strong>di</strong> verificare <strong>il</strong> funzionamento dei meccanismi del protocollo <strong>di</strong><br />

comunicazione def<strong>in</strong>ito dal WSDL.<br />

Nei prossimi paragrafi saranno descritti i due progetti e saranno presentati<br />

degli esempi <strong>di</strong> esecuzione delle o<strong>per</strong>azioni fondamentali <strong>di</strong> <strong>Storage</strong> Interface.<br />

7.1 Implementazione Java con JAX-WS 2.1<br />

Per realizzare un servizio <strong>di</strong> <strong>Storage</strong> Interface <strong>in</strong> l<strong>in</strong>guaggio Java è stata<br />

usata la Reference Implementation 3 della Java API for XML-Based Web<br />

Services (JAX-WS), versione 2.1 [JAX-WS21]. La JAX-WS è una specifica<br />

della Sun che def<strong>in</strong>isce un <strong>in</strong>sieme <strong>di</strong> classi e <strong>in</strong>terfacce Java che possono<br />

essere ado<strong>per</strong>ate <strong>per</strong> creare Web Service basati su XML. Si basa su Java<br />

Architecture for XML B<strong>in</strong><strong>di</strong>ng (JAXB), versione 2.1 [JAXB21], che offre<br />

strumenti <strong>per</strong> la trasformazione <strong>di</strong> oggetti Java <strong>in</strong> XML e viceversa.<br />

In JAX-WS, si programmano oggetti che rappresentano i servizi e che trasferiscono<br />

messaggi rappresentati da istanze <strong>di</strong> classi Java, le quali prima <strong>di</strong><br />

essere trasmesse sono trasformati <strong>in</strong> XML tramite una procedura chiamata<br />

marshall<strong>in</strong>g. Il processo <strong>in</strong>verso, detto unmarshall<strong>in</strong>g, trasforma i messaggi<br />

XML ricevuti <strong>in</strong> classi. Pertanto <strong>in</strong> JAX-WS si programma un servizio usando<br />

un data model Java, che <strong>per</strong>ò è <strong>in</strong>tero<strong>per</strong>ab<strong>il</strong>e con altri servizi <strong>di</strong> altre<br />

piattaforme grazie al mapp<strong>in</strong>g con <strong>il</strong> data model con<strong>di</strong>viso basato su XML.<br />

Il servizio è stato sv<strong>il</strong>uppato secondo un approccio “start from WSDL”<br />

[Hansen]. Questo approccio consiste nel partire da un WSDL che def<strong>in</strong>isce<br />

l’<strong>in</strong>terfaccia del servizio, i tipi ed <strong>il</strong> b<strong>in</strong><strong>di</strong>ng col protocollo, dal quale generare<br />

<strong>il</strong> co<strong>di</strong>ce sorgente sul quale implementare la logica del servizio.<br />

3 http://jax-ws.dev.java.net/<br />

157


Implementazione del Servizio Implementazione Java con JAX-WS 2.1<br />

La reference implementation delle JAX-WS fornisce un programma, WSIM-<br />

PORT, che analizza un WSDL e genera le <strong>in</strong>terfacce Java del servizio e le<br />

classi Java che rappresentano <strong>il</strong> data model XML. Grazie a queste <strong>in</strong>terfacce,<br />

un servizio si realizza creando classi che le estendono, un client si realizza<br />

creando classi che usano queste <strong>in</strong>terfacce. Le JAX-WS si occupano <strong>di</strong> gestire<br />

tutti gli aspetti <strong>di</strong> marshall<strong>in</strong>g e <strong>di</strong> comunicazione, ed <strong>il</strong> programmatore<br />

non deve fare altro che scrivere un normale programma Java <strong>in</strong> cui usa queste<br />

classi.<br />

L’implementazione <strong>di</strong> <strong>Storage</strong> Interface basata sulle JAX-WS usa <strong>il</strong> WSDL<br />

def<strong>in</strong>ito usando la specifica 1.1 (ve<strong>di</strong> ??) e si basa sul protocollo SOAP <strong>per</strong><br />

la comunicazione. Il supporto <strong>per</strong> <strong>il</strong> WSDL 2.0 è stato programmato <strong>per</strong> una<br />

futura revisione delle librerie JAX-WS.<br />

Il progetto <strong>di</strong> questo servizio, basato su Maven [MassolPorter], è sud<strong>di</strong>viso<br />

<strong>in</strong> 4 sottoprogetti:<br />

• Il primo progetto genera ut<strong>il</strong>izza WSIMPORT <strong>per</strong> la generazione delle<br />

classi e delle <strong>in</strong>terfacce Java.<br />

• Il secondo, contiene la classe Jcr<strong>Storage</strong>Service: questa classe implementa<br />

le <strong>in</strong>terfacce Java derivate dal WSDL e gestisce le o<strong>per</strong>azioni<br />

memorizzando i dati ed i metadati <strong>di</strong> una SI-R su Jack Rabbit, un<br />

content repository Java sv<strong>il</strong>uppato dalla Apache Foundation.<br />

• Il terzo progetto implementa una applicazione che manda <strong>in</strong> esecuzione<br />

<strong>il</strong> servizio Stand-Alone. Infatti, la classe che rappresenta <strong>il</strong> servizio<br />

implementa le <strong>in</strong>terfacce <strong>di</strong> <strong>Storage</strong> Interface e ne mette <strong>in</strong> pratica la<br />

logica, ma non rappresenta una applicazione. In questo progetto, si<br />

usano strumenti della JAX- WS che ut<strong>il</strong>izzando la classe del servizio,<br />

aprono un punto <strong>di</strong> ascolto sul computer su cui viene eseguita l’applicazione,<br />

gestiscono <strong>il</strong> trasferimento usando <strong>il</strong> protocollo designato ed<br />

effettuano <strong>il</strong> marshall<strong>in</strong>g.<br />

• Il quarto progetto ut<strong>il</strong>izza <strong>il</strong> servizio del secondo progetto <strong>per</strong> realizzare<br />

un .WAR che può essere <strong>in</strong>stallato su un conta<strong>in</strong>er Java come Tomcat<br />

o Glassfish [Hansen], sul quale siano configurate le librerie della JAX-<br />

WS. In questo caso è <strong>il</strong> conta<strong>in</strong>er che si occupa degli aspetti precedenti,<br />

158


Implementazione del Servizio Implementazione PHP su Apache Web Server<br />

ed <strong>in</strong> particolare questa soluzione è ut<strong>il</strong>e <strong>per</strong> poter meglio gestire più<br />

servizi <strong>in</strong>stallati nella stessa macch<strong>in</strong>a.<br />

Il prototipo sv<strong>il</strong>uppato implementa le funzionalità base, le funzionalità <strong>per</strong><br />

la duplicazione e lista <strong>di</strong> risorse e metadati, e le funzionalità <strong>per</strong> l’accesso<br />

<strong>di</strong>retto a dati e metadati.<br />

7.2 Implementazione PHP su Apache Web<br />

Server<br />

L’implementazione del servizio <strong>di</strong> <strong>Storage</strong> Interface <strong>in</strong> st<strong>il</strong>e Resource Oriented<br />

Architecture, è stata realizzata <strong>in</strong> PHP, poiché questo l<strong>in</strong>guaggio è <strong>di</strong> sua<br />

natura portato <strong>per</strong> realizzare Web Service <strong>in</strong> st<strong>il</strong>e ROA. Infatti PHP, che<br />

significa Hy<strong>per</strong>text Preprocessor, è nato <strong>per</strong> gestire la generazione <strong>di</strong>namica<br />

delle pag<strong>in</strong>e HTML del Web e <strong>per</strong> essere <strong>in</strong>tergrato nei web server come modulo<br />

CGI e qu<strong>in</strong><strong>di</strong> possiede tutte le funzionalità necessarie <strong>per</strong> implementare<br />

questo tipo <strong>di</strong> architetture.<br />

Nello specifico, <strong>il</strong> PHP è stato ut<strong>il</strong>e <strong>per</strong> gestire la comunicazione con <strong>il</strong><br />

protocollo HTTP secondo le regole def<strong>in</strong>ite nel B<strong>in</strong><strong>di</strong>ng HTTP del WSDL<br />

2.0 del servizio <strong>di</strong> <strong>Storage</strong> Interface, come è stato descritto <strong>in</strong> 6.3.1. Inoltre<br />

<strong>il</strong> l<strong>in</strong>guaggio si <strong>in</strong>tegra bene con <strong>il</strong> database MySQL 4 , che è stato usato <strong>per</strong><br />

la memorizzazione <strong>per</strong>sistente delle <strong>in</strong>formazioni.<br />

Il servizio sv<strong>il</strong>uppato è stato <strong>in</strong>stallato su un Web Server Apache 5 con<br />

supporto <strong>per</strong> questo l<strong>in</strong>guaggio, semplicemente caricando i f<strong>il</strong>e <strong>in</strong> una cartella<br />

appositamente designata al progetto. L’endpo<strong>in</strong>t del servizio è <strong>per</strong>tanto dato<br />

dalla comb<strong>in</strong>azione del nome del server e del <strong>per</strong>corso che <strong>in</strong><strong>di</strong>vidua la cartella<br />

(nello specifico, trattandosi <strong>di</strong> un server non pubblico, l’endpo<strong>in</strong>t del servizio<br />

usato <strong>per</strong> i test era http://localhost/idn/phpSI/).<br />

Questa implementazione si basa sul WSDL 2.0 ed usa <strong>il</strong> b<strong>in</strong><strong>di</strong>ng HTTP,<br />

ma offre <strong>il</strong> solo supporto alle quatrto o<strong>per</strong>azioni base della memorizzazione:<br />

creazione, lettura, mo<strong>di</strong>fica e rimozione.<br />

4 http://www.mysql.com/<br />

5 http://httpd.apache.org/<br />

159


Implementazione del Servizio Implementazione PHP su Apache Web Server<br />

Il WSDL del servizio è riportato nel seguente listato:<br />

<br />

<br />

<br />

<br />

<br />

<br />

Come si può osservare, <strong>il</strong> documento richiama <strong>il</strong> WSDL def<strong>in</strong>ito nel capitolo<br />

precedente, e specifica un suo endpo<strong>in</strong>t al quale fruire del servizio.<br />

Il progetto dell’applicazione sv<strong>il</strong>uppata è molto semplice: <strong>il</strong> servizio si compone<br />

<strong>di</strong> un unico f<strong>il</strong>e <strong>in</strong> PHP, <strong>di</strong> nome service.php, nel quale è implementata<br />

tutta la logica del programma, affiancato da un f<strong>il</strong>e .htaccess che configura<br />

alcune opzioni <strong>di</strong> Apache, e da un database <strong>per</strong> la memorizzazione dei dati<br />

e <strong>di</strong> metadati delle risorse SI-R. Il database si compone <strong>di</strong> due tabelle <strong>di</strong><br />

MySQL, una <strong>per</strong> i dati ed una <strong>per</strong> i metadati, la cui chiave primaria è:<br />

• un INT 6 , con la proprietà <strong>di</strong> auto <strong>in</strong>crement 7 <strong>per</strong> la tabella dei “data”<br />

• la comb<strong>in</strong>azione <strong>di</strong> un VARCHAR(255) 8 e <strong>di</strong> un INT <strong>per</strong> la tabella dei<br />

“metadata”<br />

6 Un INT <strong>in</strong> MySQL è un numero <strong>in</strong>tero.<br />

7 Questa proprietà fa si che ad ogni nuova riga sia assegnato un valore <strong>per</strong> l’<strong>in</strong>tero<br />

<strong>in</strong>crementato progressivamente.<br />

8 Ovvero una str<strong>in</strong>ga <strong>di</strong> lunghezza variab<strong>il</strong>e <strong>di</strong> massimo 255 caratteri.<br />

160


Implementazione del Servizio Implementazione PHP su Apache Web Server<br />

La chiave primaria della tabella dei dati, comb<strong>in</strong>ata con l’endpo<strong>in</strong>t rappresenta<br />

anche l’identificativo della risorsa ed <strong>il</strong> suo punto <strong>di</strong> accesso: ad<br />

esempio, la risorsa con chiave primaria uguale a “123” ha come identificatore<br />

http://localhost/idn/phpSI/123.<br />

La tabella dei metadati è <strong>in</strong>vece <strong>in</strong><strong>di</strong>cizzata da una str<strong>in</strong>ga, che rappresenta<br />

<strong>il</strong> nome del metadato, <strong>in</strong> comb<strong>in</strong>azione con un <strong>in</strong>tero, che rappresenta l’<strong>in</strong><strong>di</strong>ce<br />

della riga della tabella dati a cui <strong>il</strong> metadato è associato.<br />

Qu<strong>in</strong><strong>di</strong>, una SI-R <strong>in</strong> questa implementazione, è memorizzata <strong>in</strong> una riga<br />

della tabella “data” ed <strong>di</strong> tante righe della tabella “metadata” pari al numero<br />

dei metadati associati alla risorsa.<br />

Il programma gestisce le quattro o<strong>per</strong>azioni base:<br />

• Durante l’o<strong>per</strong>azione Create, <strong>il</strong> programma usa i dati ed i metadati<br />

ricevuti nella richiesta e li memorizza <strong>in</strong> nuove righe delle tabelle. Il<br />

messaggio della risposta restituisce come identificatore della SI-R appena<br />

creata, l’<strong>in</strong>tero che MySQL assegna alla muova riga della tabella<br />

“data”.<br />

• Durante una o<strong>per</strong>azione <strong>di</strong> Read, <strong>il</strong> programma recu<strong>per</strong>a dal database<br />

i dati ed i metadati della risorsa, formula <strong>il</strong> messaggio che contiene<br />

l’XML e lo restituisce nel contenuto della risposta http.<br />

• Durante l’o<strong>per</strong>azione <strong>di</strong> Update, <strong>il</strong> programma <strong>in</strong><strong>di</strong>vidua le righe dei<br />

dati e dei metadati corrispondenti all’identificatore della risorsa ed ai<br />

nomi dei metadati ricevuti tramite la richiesta HTTP e <strong>in</strong> queste salva<br />

i nuovi contenuti ricevuti.<br />

• Durante l’o<strong>per</strong>azione <strong>di</strong> Delete, <strong>il</strong> programma rimuove le righe corrispondenti<br />

ai dati ed ai metadati della SI-R.<br />

Un ruolo importante <strong>per</strong> <strong>il</strong> funzionamento del programma è la configurazione<br />

<strong>di</strong> Apache <strong>per</strong> la cartella <strong>in</strong> cui si trova <strong>il</strong> servizio. Grazie al f<strong>il</strong>e .htaccess,<br />

<strong>il</strong> Web Server è stato configurato <strong>per</strong> applicare delle regole <strong>di</strong> URL rewrit<strong>in</strong>g<br />

alle richieste ricevute nel <strong>per</strong>corso del servizio.<br />

161


Implementazione del Servizio Esempio <strong>di</strong> messaggi e <strong>di</strong> comunicazione<br />

È <strong>in</strong>fatti necessario che tutte le richieste che <strong>di</strong>pendono dall’endpo<strong>in</strong>t del<br />

servizio siano gestite dal programma, e che qu<strong>in</strong><strong>di</strong> ogni richiesta sia re<strong>in</strong><strong>di</strong>rizzata<br />

<strong>in</strong>teramente a http://localhost/idn/phpSI/service.php. Il <strong>per</strong>corso<br />

è passato come parametro al programma. Questo meccanismo <strong>per</strong>mette <strong>di</strong><br />

rispettare le regole del WSDL dove nel b<strong>in</strong><strong>di</strong>ng http si specifica come formare<br />

l’URL durante una o<strong>per</strong>azione.<br />

Ad esempio <strong>per</strong> <strong>il</strong> b<strong>in</strong><strong>di</strong>ng dell’o<strong>per</strong>azione “idnsi:ReadMeta”, <strong>il</strong> b<strong>in</strong><strong>di</strong>ng specifica<br />

la seguente regola <strong>per</strong> formalizzare le richieste:<br />

<br />

Questo significa che <strong>per</strong> accedere ad esempio al metadato “idnsi:types”<br />

appartenente alla risorsa “123”, è necessario eseguire una richiesta con <strong>il</strong> metodo<br />

GET sulla risorsa <strong>in</strong><strong>di</strong>rizzata da http://localhost/idn/phpSI/123/<br />

meta/idnsi:types. In PHP è stato possib<strong>il</strong>e implementare questo meccanismo<br />

grazie all’URL rewrit<strong>in</strong>g, con <strong>il</strong> quale Apache è stato configurato <strong>per</strong><br />

<strong>in</strong>oltrare ogni richiesta <strong>di</strong> questo tipo all’<strong>in</strong><strong>di</strong>rizzo: http://localhost/idn/<br />

phpSI/service.php?resId=123&arg=meta&value=idnsi:types.<br />

Nella prossima sezione saranno <strong>il</strong>lustrati degli esempi <strong>di</strong> come queste due<br />

implementazioni scambiano messaggi HTTP.<br />

7.3 Esempio <strong>di</strong> messaggi e <strong>di</strong> comunicazione<br />

Sulla base del WSDL del servizio <strong>di</strong> <strong>Storage</strong> Interface, si riporta un tipico<br />

esempio <strong>di</strong> messaggi e <strong>di</strong> come questi vengano trasportati. Verrà <strong>il</strong>lustrato,<br />

sia <strong>in</strong> HTTP che <strong>in</strong> SOAP, un esempio <strong>di</strong> o<strong>per</strong>azione <strong>di</strong> lettura (Read) e <strong>di</strong><br />

scrittura (Update).<br />

162


Implementazione del Servizio Esempio <strong>di</strong> messaggi e <strong>di</strong> comunicazione<br />

7.3.1 Esempio <strong>di</strong> lettura: o<strong>per</strong>azione Read<br />

In figura 7.1 sono riportati due esempi <strong>di</strong> messaggi <strong>per</strong> una o<strong>per</strong>azione <strong>di</strong><br />

lettura <strong>di</strong> una risorsa. Gli esempi sono rappresentati <strong>in</strong> XML e corrispondono<br />

al messaggio <strong>di</strong> <strong>in</strong>put e <strong>di</strong> output <strong>di</strong> un esempio <strong>di</strong> chiamata alla o<strong>per</strong>azione<br />

“idnsi:Read”.<br />

In figura 7.2 sono riportate la request e la response del B<strong>in</strong><strong>di</strong>ng HTTP<br />

che corrispondono ai due messaggi.<br />

In figura 7.3 sono riportati i messaggi HTTP della stessa o<strong>per</strong>azione ma<br />

su protocollo SOAP.<br />

XML Messages for Read o<strong>per</strong>ation<br />

Read Input Message<br />

<br />

Example client<br />

::SrBCRJUFmFSzU::<br />

MSG 112233<br />

123<br />

<br />

Read Output Message<br />

<br />

MSG 112233<br />

<br />

http://example.org/myExample<br />

<br />

<br />

2007-11-20<br />

<br />

<br />

this is simply an example<br />

<br />

<br />

Hello World<br />

<br />

<br />

Figura 7.1: O<strong>per</strong>azione Read: rappresentazione XML dei messaggi<br />

163


Implementazione del Servizio Esempio <strong>di</strong> messaggi e <strong>di</strong> comunicazione<br />

WSDL HTTP B<strong>in</strong><strong>di</strong>ng: Read Messages<br />

Read Input Message / HTTP Request<br />

GET /idn/phpSI/123?agent=Example%20client&auth=::SrBCRJUFmFSzU::<br />

&trace=MSG%20112233 HTTP/1.1<br />

Host: localhost<br />

Connection: Keep-Alive<br />

Content-Type: application/x-www-form-urlencoded<br />

Read Output Message / HTTP Response<br />

HTTP/1.1 200 Ok<br />

Content-Type: application/xml<br />

Content-Length: 593<br />

<br />

MSG 112233<br />

<br />

http://example.org/myExample<br />

<br />

<br />

2007-11-20<br />

<br />

<br />

this is simply an example<br />

<br />

<br />

Hello World<br />

<br />

<br />

Figura 7.2: O<strong>per</strong>azione Read: serializzazione <strong>in</strong> HTTP dei messaggi <strong>di</strong> figura<br />

7.1<br />

164


Implementazione del Servizio Esempio <strong>di</strong> messaggi e <strong>di</strong> comunicazione<br />

WSDL SOAP B<strong>in</strong><strong>di</strong>ng: Read Messages<br />

Read Input Message / SOAP over an HTTP Response<br />

POST /idn/soap HTTP/1.1<br />

Host: localhost<br />

Connection: Keep-Alive<br />

Content-Type: text/xml; charset=utf-8<br />

SOAPAction: "urn:#Read"<br />

Content-Length: 474<br />

<br />

<br />

<br />

<br />

Example client<br />

::SrBCRJUFmFSzU::<br />

MSG 112233<br />

123<br />

<br />

<br />

<br />

Read Output Message / SOAP over an HTTP Response<br />

HTTP/1.1 200 Ok<br />

Content-type: text/xml;charset="utf-8"<br />

Content-Length: 799<br />

<br />

<br />

<br />

<br />

MSG 112233<br />

<br />

http://example.org/myExample<br />

<br />

<br />

2007-11-20<br />

<br />

<br />

this is simply an example<br />

<br />

<br />

Hello World<br />

<br />

<br />

<br />

<br />

Figura 7.3: O<strong>per</strong>azione Read: serializzazione SOAP dei messaggi <strong>di</strong> figura<br />

7.1<br />

165


Implementazione del Servizio Esempio <strong>di</strong> messaggi e <strong>di</strong> comunicazione<br />

7.3.2 Esempio <strong>di</strong> scrittura: o<strong>per</strong>azione Update<br />

In figura 7.4 sono riportati due esempi <strong>di</strong> messaggi <strong>per</strong> una o<strong>per</strong>azione<br />

<strong>di</strong> scrittura <strong>di</strong> una risorsa. Gli esempi sono rappresentati <strong>in</strong> XML e corrispondono<br />

al messaggio <strong>di</strong> <strong>in</strong>put e <strong>di</strong> output <strong>di</strong> un esempio <strong>di</strong> chiamata alla<br />

o<strong>per</strong>azione “idnsi:Update”.<br />

In figura 7.5 sono riportate la request e la response del B<strong>in</strong><strong>di</strong>ng HTTP<br />

che corrispondono ai due messaggi.<br />

In figura 7.6 sono riportati i messaggi HTTP della stessa o<strong>per</strong>azione ma<br />

su protocollo SOAP.<br />

XML Messages for Update o<strong>per</strong>ation<br />

Update Input Message<br />

<br />

Example client<br />

::SrBCRJUFmFSzU::<br />

MSG 112233<br />

123<br />

<br />

2007-11-20<br />

<br />

<br />

Cristiano<br />

<br />

<br />

Hello World<br />

<br />

<br />

Update Output Message<br />

<br />

MSG 112233<br />

<br />

Figura 7.4: O<strong>per</strong>azione Update: rappresentazione XML dei messaggi<br />

166


Implementazione del Servizio Esempio <strong>di</strong> messaggi e <strong>di</strong> comunicazione<br />

WSDL HTTP B<strong>in</strong><strong>di</strong>ng: Update Messages<br />

Update Input Message / HTTP Request<br />

PUT /idn/phpSI/123 HTTP/1.1<br />

Host: localhost<br />

Connection: Keep-Alive<br />

Content-Type: application/x-www-form-urlencoded<br />

Content-Length: 425<br />

agent=Example%20client&auth=::SrBCRJUFmFSzU::&trace=MSG%20112233<br />

&meta[]=%3Cidnsi%3Ameta+xmlns%3Aidnsi%3D%22http%3A%2F%2Fwww.<br />

<strong>in</strong>terdatanet.org%2Fns%2F<strong>Storage</strong>Interface%22+name%3D%22http%3A%2F<br />

%2Fexample.org%2FmySample%23date%22%3E2007-11-20%3C%2Fidnsi%3<br />

Ameta%3E%0D%0A<br />

&meta[]=%3Cidnsi%3Ameta+xmlns%3Aidnsi%3D%22http%3A%2F%2Fwww.<br />

<strong>in</strong>terdatanet.org%2Fns%2F<strong>Storage</strong>Interface%22+name%3D%22http%3A%2F<br />

%2Fexample.org%2FmySample%23author%22%3ECristiano%3C%2Fidnsi%3<br />

Ameta%3E%0D%0A<br />

&data=%3Cidnsi%3Adata+xmlns%3Aidnsi%3D%22http%3A%2F%2Fwww.<strong>in</strong>t<br />

erdatanet.org%2Fns%2F<strong>Storage</strong>Interface%22+mime%3D%22text%2Fpla<strong>in</strong>%2<br />

2%3EHello+World%3C%2Fidnsi%3Adata%3E<br />

Update Output Message / HTTP Response<br />

HTTP/1.1 200 Ok<br />

Content-Type: application/xml<br />

Content-Length: 139<br />

<br />

MSG 112233<br />

<br />

Figura 7.5: O<strong>per</strong>azione Update: serializzazione <strong>in</strong> HTTP dei messaggi <strong>di</strong><br />

figura 7.4<br />

167


Implementazione del Servizio Esempio <strong>di</strong> messaggi e <strong>di</strong> comunicazione<br />

WSDL SOAP B<strong>in</strong><strong>di</strong>ng: Update Messages<br />

Update Input Message / SOAP over an HTTP Response<br />

POST /idn/soap HTTP/1.1<br />

Host: localhost<br />

Connection: Keep-Alive<br />

Content-Type: text/xml; charset=utf-8<br />

SOAPAction: "urn:#Update"<br />

Content-Length: 648<br />

<br />

<br />

<br />

<br />

Example client<br />

::SrBCRJUFmFSzU::<br />

MSG 112233<br />

123<br />

<br />

2007-11-20<br />

<br />

<br />

Cristiano<br />

<br />

<br />

Hello World<br />

<br />

<br />

<br />

<br />

Update Output Message / SOAP over an HTTP Response<br />

HTTP/1.1 200 Ok<br />

Content-type: text/xml;charset="utf-8"<br />

Content-Length: 267<br />

<br />

<br />

<br />

<br />

MSG 112233<br />

<br />

<br />

<br />

Figura 7.6: O<strong>per</strong>azione Update: serializzazione SOAP dei messaggi <strong>di</strong> figura<br />

7.4<br />

168


Conclusioni<br />

Il pr<strong>in</strong>cipale obiettivo <strong>di</strong> questo lavoro <strong>di</strong> tesi è stato la redazione della<br />

specifica <strong>di</strong> un’<strong>in</strong>terfaccia <strong>per</strong> un servizio <strong>di</strong> <strong>Storage</strong> f<strong>in</strong>alizzata a fornire un<br />

supporto <strong>in</strong>frastrutturale al Web of Data. L’idea <strong>di</strong> questa applicazione è<br />

nata nel contesto del progetto <strong>InterDataNet</strong> (IDN), nel quale era previsto<br />

che <strong>il</strong> layer più basso della sua architettura stratificata orientata ai servizi, si<br />

occupasse degli aspetti <strong>di</strong> <strong>in</strong>terfacciamento ai sistemi <strong>di</strong> memorizzazione.<br />

La formalizzazione <strong>di</strong> questo oggetto durante <strong>il</strong> lavoro <strong>di</strong> tesi ha richiesto<br />

<strong>in</strong>izialmente un’analisi degli scenari applicativi possib<strong>il</strong>i <strong>in</strong> cui un tale servizio<br />

<strong>di</strong> <strong>Storage</strong> può trovare impiego, lo stu<strong>di</strong>o dei requisiti <strong>di</strong> progettazione e la<br />

scelta della forma con cui fornirne le specifiche.<br />

Il secondo obiettivo <strong>di</strong> questo lavoro, è stato la realizzazione un applicativo<br />

conforme all’<strong>in</strong>terfaccia specificata che potesse verificare la vali<strong>di</strong>tà della<br />

soluzione proposta. Questo compito ha richiesto lo stu<strong>di</strong>o delle <strong>di</strong>verse piattaforme<br />

tecnologiche su cui basare le <strong>in</strong>frastrutture e la scelta <strong>di</strong> strumenti e<br />

l<strong>in</strong>guaggi <strong>di</strong> programmazione con cui realizzare queste implementazioni.<br />

Nella prima fase del lavoro, è stato generalizzato <strong>il</strong> problema del servizio<br />

<strong>di</strong> storage della visione <strong>di</strong> IDN al contesto più generale dei sistemi <strong>di</strong>stribuiti,<br />

delle architetture orientate ai servizi e quelle orientate alle risorse, ed <strong>in</strong>f<strong>in</strong>e, al<br />

Web of Data. Per fare questo, <strong>il</strong> servizio <strong>di</strong> <strong>Storage</strong> è stato analizzato come un<br />

servizio generico, capace <strong>di</strong> offrire le sue funzionalità <strong>in</strong> contesti <strong>di</strong>versi che al<br />

giorno d’oggi richiamano l’<strong>in</strong>teresse della comunità degli sv<strong>il</strong>uppatori. È stato<br />

analizzato come componente <strong>di</strong> una Rich Internet Application, come servizio


Conclusioni<br />

base <strong>per</strong> l’author<strong>in</strong>g collaborativo <strong>di</strong> risorse <strong>di</strong>stribuite, come base <strong>per</strong> la<br />

memorizzazione delle <strong>in</strong>formazioni nel Semantic Web. Particolare attenzione<br />

è stat