Progetto e Sviluppo dell Interfaccia di Storage in InterDataNet per il Web of Data

Transcript

1 UNIVERSITÀ DEGLI STUDI DI FIRENZE Facoltà di Ingegneria Dipartimento di Elettronica e Telecomunicazioni Corso di Laurea in Ingegneria delle Telecomunicazioni P.O. Progetto e Sviluppo dell Interfaccia di Storage in InterDataNet per il Web of Data Tesi di Laurea di Cristiano Costantini Relatori Prof. Franco Pirri Correlatori Ing. Davide Chini Prof. Dino Giuli Ing. Samuele Innocenti Ing. Maria Chiara Pettenati Anno Accademico 2006/2007

2 Ringraziamenti È stato duro arrivare in fondo a questo corso di studi. Questo libro, questa tesi, non sono solo il frutto del lavoro di questi ultimi mesi passati nel laboratorio di Tecnologie della Telematica a Santa Marta, ma sono il risultato di un lungo percorso iniziato molti anni fa, forse con poca consapevolezza di quello a cui sarei andato incontro. Ci sono stati momenti difficili, esami pesanti da digerire e professori con i quali non sono proprio riuscito ad entrare in sintonia, ma ho saputo reagire e aggiustare il tiro, e questi sacrifici sono stati ripagati da momenti di soddisfazione e dall incontro con persone speciali. Due di queste sono sicuramente il professor Franco Pirri e il professor Dino Giuli, complici nel prendersi cura di noi studenti più di quanto spetta loro per dovere di incarico. Un sentito grazie a loro e agli ingegneri Davide Chini, Samuele Innocenti e Mariachiara Pettenati, miei preziosissimi correlatori. Nel portare al termine questo lavoro si sono dimostrati attenti, disponibili e interessati, e con loro ho stabilito un ottimo rapporto di collaborazione. Ringrazio tutti i compagni di università che in questi anni mi hanno accompagnato, a partire da Alessandro Bernardi, con cui ho cominciato questa lunga avventura. Un grazie particolare a Marco Chiesi, Leonardo Cipriani, Michela Paolucci e Irene Innocenti, perché mi hanno supportato fornendomi libri, appunti ma soprattutto consigli che sono stati fondamentali. Un grazie al gruppo di persone con cui ho studiato: Maddalena Barlotti, Emanuele Bonciani, Matteo Benassi, Leonardo Biancalani, Azzurra Tesi e Simona Asnaghi, Ilaria Nelli e Christian Berti, Francesco Guzzardi e Federico Puggelli. Nuovamente grazie a Davide Chini, perché il suo contributo è stato il più prezioso e mi ha accompagnato fino alla conclusione. Ringrazio tutti gli studenti che leggeranno queste pagine e auguro loro di trovarvi informazioni utili, ed infine mando un augurio anche ad Alessandro Cafissi, che questa avventura universitaria ha appena cominciato. Ringrazio l ingegner Claudio Bizzarri, che mi ha iniziato ad esperienze professionali il cui valore per la mia formazione è inestimabile. Grazie a

3 Davide Chini e Giulio Nesi, con i quali ho collaborato alla realizzazione progetti stupendi. Ringrazio la Oris Immobiliare di Stefano e Roberto, Roberto Tognelli, i ragazzi dell Essedi di Prato insieme a Guido Mariani di Computercare, e la Global Informatica di Egidio. Un sentito grazie al mio maestro Claudio Manenti. Le discipline che mi sta insegnando, lo Shaolin ed il Tai Chi, sono state due dei pilastri che mi hanno sostenuto in questi anni. Ringrazio lui, i suoi maestri Chang Dsu Yao e Chang Wei Shin, ed il suo allievo Giancarlo Acri. Ringrazio i miei più cari amici, Giulio Nesi, che mi è sempre stato vicino nei peggiori e nei migliori momenti, Marco Chiesi, sul quale sempre ho potuto contare, Alessandro Bernardi, Michelangelo Nerini, Filippo Fiaschi e Gianni Stefanelli. A quest ultimo mando un saluto speciale e l augurio di guarire al più presto dalla malattia che l ha colpito. Grazie nuovamente a Davide Chini perché in questi anni mi è stato soprattutto amico. Grazie a Cristina Bellandi, cugina e amica, a mio cugino Stefano Orlandi e sua moglie Federica, con i quali con Chiara, Renni e Pippo abbiamo passato momenti indimenticabili. Un grazie inesauribile a mio padre Mario, e mia madre Tamara, i miei educatori, sostenitori e finanziatori, senza i quali non sarebbe stato possibile diventare la persona che sono oggi. Grazie a mio fratello Francesco per avermi sopportato in questi anni e grazie a mio nonno Franco, la cui forza, tempra e coraggio sono stati fonte d ispirazione nel mio diventare adulto. Un grazie speciale va alla mia simpaticissima nonna Rolanda e all indistruttibile nonna Nella Narcisa. Infine, il mio ringraziamento più grande va a Chiara, mia compagna nella vita, che insieme al nostro cagnolone Renni rappresenta la mia piccola famiglia. Grazie per il sostegno, grazie per la compagnia, grazie per l affetto. A lei dedico il mio futuro. Tutte queste persone cui va la mia riconoscenza, rappresentano un istantanea di questi ultimi anni della mia vita, e si sono meritate a pieno titolo di essere nominate in queste pagine personali.

4 Queste ultime righe che ho scritto sul mio fidato computer portatile Dell, mentre la stampante continua a sfornare le pagine della tesi, sono uno degli ultimi compiti che svolgerò da studente e sto provando una forte emozione perché questo è un momento unico. Una parte della mia vita finisce qui, domani comincia una nuova sfida nella quale potrò però contare su un nuovo potenziale. Per questo, per le conoscenze che grazie a essa ho acquisito, il mio ringraziamento finale va all istituzione dell Università degli Studi di Firenze. Firenze, 10 Dicembre 2007 Cristiano Costantini

5 Alla memoria di mio zio Sergio

6 Indice Introduzione xiii I Abilitare il Web of Data 1 1 Web Of Data L avvento del Semantic Web Il Semantic Web è il futuro? Dal Web di Documenti al web di Dati Infrastruttura del Web di dati Il progetto InterDataNet Content Management nel Web of Data Naming and Data Addressability Data Replication Versioning Data Access Control The pursuit of interoperability InterDataNet: una soluzione per l interdataworking Il design pattern della stratificazione applicato ai dati L approccio bottom-up Architettura tecnologica di IDN Core IDN-SA services Servizi LDNS ed LS Servizio di Replica Management

7 Indice Servizio di Information History Identity Service L informazione: IDN-IM Le interfacce verso l esterno di IDN-SA Virtual Repository Storage Interface Legacy Storage Interface Una migrazione interoperabile Conclusioni II Analisi del servizio di Storage Interface 47 3 Tecnologie per IDN e Storage Interface Service Oriented Architecture Motivazioni e Concetti fondamentali Ingredienti Terminologia Servizi Considerazioni conclusive Web Service WSDL Struttura e ciclo di vita Esempio di un servizio descritto da WSDL Confronto tra WSDL 1.1 e Estensione per il binding su HTTP di WSDL SOAP Conclusioni Representational State transfer Resource Oriented Architecture Mappa delle tecnologie Resource Description Framework RDF schema Scenari applicativi Storage di immagini con dati Exif Ruolo di SI Aspetti rilevanti vi

8 Indice Conseguenze per SI Storage di MIME type con associati metadati Ruolo di SI Aspetti rilevanti Conseguenze per SI Storage per ambiente distributo Ruolo di SI Aspetti rilevanti Conseguenze per SI Memorizzazione di informazioni strutturate Ruolo di SI Aspetti rilevanti Conseguenze per SI Storage per il Web orientato ai dati Ruolo di SI Aspetti rilevanti Conseguenze per SI Interoperabilità con sistemi legacy Ruolo di SI Aspetti rilevanti Conseguenze per SI Servire il Replica Management di IDN Ruolo di SI Aspetti rilevanti Conseguenze per SI Requisiti dell Interfaccia Notazione Definizioni Informazioni sulla specifica di requisiti Requisiti III Progetto dell interfaccia e sviluppo di una implementazione di riferimento per il servizio Progetto dell Interfaccia Information Model e descrizione dell interfaccia vii

9 Indice Information Model delle Risorse: SI-R Information model dei messaggi ed operazioni dell interfaccia Messaggi di input, di output, di fault e generalità Operazioni base dello storage persistente Operazioni per funzionalità di performance Operazioni specializzate per dati e metadati Operazioni per funzionalità specifiche Operazioni per la gestione degli eventi Interfaccia delle notifiche Dati predefiniti Data Model XML Panoramica schema XML dei messaggi Panoramica schema XML dei tipi predefiniti Il WSDL dell interfaccia Definizione del protocollo: il binding del WSDL Il WSDL 1.1 del servizio Implementazione del Servizio Implementazione Java con JAX-WS Implementazione PHP su Apache Web Server Esempio di messaggi e di comunicazione Esempio di lettura: operazione Read Esempio di scrittura: operazione Update Conclusioni 169 IV Appendici 172 A WSDL e XML Schema di Storage Interface 173 A.1 Storage Interface XML Schema A.2 Storage Interface Predefined Types A.3 Storage Interface WSDL A.4 Storage Interface WSDL Bibliografia 212 viii

10 Elenco delle figure 1.1 Risorse intercollegate dal punto di vista del Web tradizionale e da un punto di vista del Web semantico From a Web of documents to a Web of Data [Ayers07a] Come il Semantic Web si costruisce sulle attuali strutture Web Semantic Web verso il Web of Data Modello generale per il controllo dell accesso agli oggetti Il logo del progetto Interdataworking in IDN I componenti di IDN Il sistema dei nomi Coreografia al livello di Replica Management Revisioni successive di due documenti nel modello UEVM InterDataNet Information Model Due documenti Web (pagine HTML) e due documenti IDN (DAG IDN-IM) che rappresentano la stessa informazione Utilizzo di Virtual Repository da parte di applicazioni IDN orientate al Web Storage Interface e Legacy Storage Interface Paragone tra Web e IDN Dal Web al Semantic Web attraverso il Web 2.0 ed il Web of Data Web Services Standards as of Q by innoq Struttura di file WSDL 1.1 e WSDL

11 Elenco delle figure 3.3 Esempio astratto di servizio che fornisce operazioni di lettura e di scrittura di risorse composte da dati e più metadati Mappa delle tecnologie per erogare servizi nel web Cristiano created the InterDataNet home page Storage Interface per immagini con Exif in uno scenario Rich Internet Application (derivata da [Stearn07]) Ambiente SOA per abilitare il Distributed Authoring and Versioning Ambiente SOA per File System distribuito Servizio di Storage e di Data Browsing per l authoring di informazioni strutturate Accesso ed indirizzamento per HTTP e per un Web Service di storage Accesso ed indirizzamento per metadati di una risorsa Interoperabilità con sistemi legacy: possibili soluzioni implementative Interoperabilità con sistemi legacy Layered Architecture di InterDataNet Interazione tra livello di storage e di replica Information Model di SI-R Mapping di associazioni di metadati di SI-R con relazioni RDF Information Model dei messaggi di input e di output Tipi di messaggi di fault Information model dei messaggi e delle operazioni base per la memorizzazione persistente Information model dei messaggi e delle operazioni per funzionalità duplicazione, lista di risorse e lista di metadati Information model dei messaggi e delle operazioni di memorizzazione di singoli dati o singoli metadati Information model dei messaggi e delle operazioni per funzionalità di locking e validazione Information model dei messaggi e delle operazioni a supporto della notifica di eventi Interfaccia per le notifiche Information model dei metadati predefiniti di Storage Interface.146 x

12 Elenco delle figure 7.1 Operazione Read: rappresentazione XML dei messaggi Operazione Read: serializzazione in HTTP dei messaggi di figura Operazione Read: serializzazione SOAP dei messaggi di figura Operazione Update: rappresentazione XML dei messaggi Operazione Update: serializzazione in HTTP dei messaggi di figura Operazione Update: serializzazione SOAP dei messaggi di figura xi

13 Elenco delle tabelle 3.1 Esempi pratici di loose coupling Ciclo di vita del WSDL

14 Introduzione Alla conferenza sul World Wide Web del 1994, Tim Berners-Lee illustrò per primo l idea di un Web in cui il significato delle informazioni fosse processabile dagli elaboratori. Questa evoluzione dell ancora attuale Web of Documents, che è stata poi definita Semantic Web, ha riscosso negli anni grande interesse da parte degli addetti del settore ed ha dato il via a numerose ricerche scientifiche e nuovi sviluppi tecnologici. Dopo più di dieci anni però queste idee secondo le parole recenti del loro stesso inventore rimangono largamente irrealizzate: non si sono ancora visti su larga scala agenti intelligenti capaci di eseguire compiti assegnati dai loro proprietari umani. C è chi sostiene che questo tipo di applicazioni possa proliferare soltanto con standard ben definiti ed affermati e l instabilità delle tecnologie per l espressione di una semantica condivisa, che in questi ultimi cinque anni hanno subito una continua evoluzione, non è certo stata di aiuto. Nell attuale dibattito sull evoluzione del World Wide Web, sta guadagnando sempre più attenzione la tesi che il Web of Data costituisca un necessario passo intermedio tra Web of Documents e Web Semantico. I documenti, nel Web of Data, sono scomposti in unità informative elementari ed indirizzabili con sufficiente granularità per consentirne una effettiva ed efficiente elaborazione ed abilitando così, in ultima analisi, l interoperabilità tra dati (interdataworking). Sebbene le attuali applicazioni nate sotto l etichetta gergale di Web 2.0 siano improntate alla gestione di unità elementari di dati, singolarmente indirizzabili e tra di loro collegate, non si può affermare che il Web 2.0 sia

15 Introduzione già una realizzazione del Web of Data, ma è piuttosto un Transitional Web, un Web di transizione, nel quale le singole applicazioni manovrano le informazioni con un simile approccio, senza però renderle tra loro interoperabili a livello globale, su scala Web. In altre parole, le applicazioni Web 2.0 realizzano soluzioni specifiche, usualmente esponendo una propria API tramite un Web Service, e danno così vita a molteplici soluzioni eterogenee per ognuna delle quali è necessario un client realizzato ad-hoc. Nel Web orientato ai documenti è avvenuto il contrario: il suo successo è dovuto all universalità del linguaggio HTML ed all unformità dell interfaccia HTTP. La strada che da qui porterà all abilitazione del Web of Data passa per due macro-passaggi fondamentali: Il primo è l individuare una rappresentazione delle risorse informative e dei loro metadati con un modello dell informazione uniformato. Il secondo è il disegno e la realizzazione di una soluzione infrastrutturale che permetta la gestione delle risorse così rappresentate pur provenendo da piattaforme eterogenee. Affinchè il Web of Data possa diventare la base per gli agenti software intelligenti del Web semantico, è necessario che questi passaggi incrocino il percorso dell integrazione con l attuale Web. Il progetto InterDataNet (IDN) si muove in questa direzione. Si tratta di un architettura stratificata di interdataworking, orientata alla gestione interoperabile di informazioni distribuite che ha l obiettivo di migliorare l interazione e la collaborazione tra organizzazioni in rete. InterDataNet allo studio dal 2001 presso il Laboratorio di Tecnologie della Telematica al Dipartimento di Elettronica e Telecomunicazioni della Facoltà di Ingegneria presso l Università degli Studi di Firenze propone un modello data oriented per la rappresentazione di informazioni strutturate ed è progettato come middleware, indipendente dalle applicazioni, composto da servizi stratificati che gestiscono gli aspetti logici del trattamento delle risorse. Uno di questi aspetti è la gestione della memorizzazione persistente delle unità elementari di informazioni e questo tema sarà l argomento principale del lavoro qui presentato. xiv

16 Introduzione In questo rapporto di tesi si affronterà la progettazione delle specifiche e lo sviluppo di una reference implementation per un servizio di storage persistente orientato al Web of Data. Tra i suoi requisiti fondamentali, ci sarà quello di poter essere utilizzato per costituire il layer più basso dell architettura stratificata di InterDataNet, dal quale il servizio erediterà il nome di Storage Interface. Durante la stesura delle specifiche sarà definito un modello informativo per un tipo di risorsa sul quale sia possibile ipotizzare di gettare le fondamenta del Web of Data e di IDN. Storage Interface permetterà quindi di gestire la memorizzazione di risorse basate su questo modello, interfacciando le unità informative elementari a specifici sistemi di storage quali file system o database. Un ruolo chiave di un simile servizio, al quale sarà dato risalto in questa relazione, è la possibilità di abilitare il riuso di risorse preesistenti nei sistemi legacy. Per armonizzare l eterogeneità delle informazioni presenti negli attuali sistemi distribuiti, è richiesta un interfaccia comune con la quale esporre i dati e che permetta una visione unificata dei contenuti disponibili. La stesura della specifica del servizio sarà costruita intorno a queste esigenze. Lo studio del servizio pone le basi per una realizzazione concreta di Inter- DataNet. Da un lato, Storage Interface costituisce il servizio base sul quale il resto dell architettura porrà le sue fondamenta. Da un altro, gli studi che portano alla sua realizzazione saranno riutilizzati per lo sviluppo tecnico dei servizi nei livelli superiori e questo lavoro fornirà un modello di progettazione per la loro realizzazione. Per raggiungere questo obiettivo saranno analizzati a largo campo i principi del Representational State Transfer (REST), che propone uno stile per ottenere scalabilità e performance nella gestione di risorse, e delle Service Oriented Architecture (SOA), le quali forniscono un approccio mirato alla interoperabilità tra piattaforme eterogenee. Saranno prese in esame anche le tecniche con le quali concretizzare questi principi e si affronteranno argomenti come i Web Service e le Resource Oriented Architecture (ROA). Questi aspetti sono di fondamentale importanza per una buona progettazione di Storage Interface e per lo sviluppo dei servizi che appartengono agli altri livelli di InterDataNet. xv

17 Introduzione La presente relazione di tesi sarà articolata nei seguenti capitoli: Capitolo 1 Web Of Data Descriverà gli aspetti principali del concetto di Web of Data, come questo ha origine nel Web attuale e come potrà agire a supporto del Web Semantico. Capitolo 2 Il progetto InterDataNet Illustrerà i concetti e le motivazioni su cui si basa il progetto InterDataNet, ne presenterà i principi di funzionamento, la filosofia ed i componenti. Capitolo 3 Tecnologie per IDN e Storage Interface Illustrerà lo stato dell arte delle tecnologie di rilievo per questa tesi che ruotano intorno al Web, in particolare si esamineranno le Service Oriented Architecture (SOA), i Web Service, il Web Service Description Language (WSDL), il Representational State Transfer (REST), le Resource Oriented Architecture (ROA) ed il Resource Description Framework (RDF). Capitolo 4 Scenari applicativi Presenterà lo studio dei casi applicativi in cui è stato proiettato il servizio di Storage Interface, dal quale sono emerse le caratteristiche e le funzionalità desiderabili dal servizio. Capitolo 5 Requisiti dell Interfaccia Presenterà la Specifica dei Requisiti Software di Storage Interface, elaborata durante questo lavoro di tesi. Capitolo 6 Progetto dell Interfaccia Descriverà l information model del servizio, le operazioni e l interfaccia e presenterà il data model XML, i due WSDL conformi agli standard 1.1 e 2.0, il binding HTTP ed il binding SOAP per Storage Interface. xvi

18 Introduzione Capitolo 7 Implementazione del Servizio Illustrerà i progetti ed il funzionamento di una applicazione in Java con SOAP ed una in PHP in stile ROA che sono state realizzate sulla base dell interfaccia del servizio definita nel capitolo 6. Appendice A WSDL e XML Schema di Storage Interface In appendice, saranno riportati i file XML ed file WSDL prodotti in questo lavoro di tesi, i quali contengono le specifiche del servizio di Storage Interface definito nel capitolo 6. xvii

19 Parte I Abilitare il Web of Data

20 Capitolo 1 Web Of Data Errors using inadequate data are much less than those using no data at all. Charles Babbage Se la si cercasse oggi, non si troverebbe una definizione precisa ed universalmente riconosciuta di cosa sia il Web of Data. È un concetto emergente che ha origine nelle tendenze correnti del Web 2.0 e del futuro Web semantico. Non c è uno standard o una implementazione pratica che lo rappresenta, ma se ne deduce l esistenza osservando la direzione in cui le ultime tecnologie si stanno spingendo. In questo capitolo sarà analizzato prima di tutto il Web semantico, che può fornire una valida motivazione al Web of Data. Verrà confrontato con il panorama attuale e cercheremo di capire se il Web si stia effettivamente muovendo in questa direzione.

21 Web Of Data L avvento del Semantic Web Cercheremo poi di capire che significato abbia un Web orientato ai dati, analizzando i segni riconoscibili nelle ultime tendenze tecnologiche, e verrà infine offerta una panoramica sulle infrastrutture che lo potranno sostenere. 1.1 L avvento del Semantic Web Il Web tradizionale è principalmente composto di documenti scritti in HTML, ed è proprio grazie alla semplicità ed alla immediatezza di questo linguaggio che ha avuto successo. Si tratta di un linguaggio di markup, ovvero di un linguaggio a marcatori di documento che descrive i meccanismi di rappresentazione presentazionali del testo. Ad esempio si usa l HTML per contrassegnare che L avvento del Semantic Web è un titolo se racchiudiamo questa stringa di testo tra due tag quali <h1> ed </h1>. Il browser molto probabilmente per disegnare sullo schermo tale scritta userà un carattere specifico e una dimensione più grande rispetto agli altri contenuti. Per lo più HTML fornisce un insieme di simboli che permettono di specificare come una pagina dovrà apparire ai vostri occhi, ed infatti la maggior parte delle informazioni sul Web tradizionale sono progettate per il consumo da parte di esseri umani. La principale funzione di una pagina Web che non riguarda la sua rappresentazione grafica è l hyperlink, il collegamento ipertestuale: sempre tramite contrassegni, si può marcare (con il tag anchor ovvero <a>) un stringa di testo in modo da renderla interattiva al clic del mouse da parte dell utente. L effetto di questa interazione solitamente comporta l apertura di un nuovo documento che risulta appunto collegato. Questo fa si che si possa definire il Web come una vasta raccolta mondiale di documenti (in genere multimediali) nel quale si può navigare grazie all uso di questi collegamenti. Tuttavia l informazione contenuta sul Web può essere definita in modo che un computer possa usarla non soltanto per rappresentarla sullo schermo, ma anche per ottenere interoperabilità ed integrazione tra applicazioni e sistemi. È in questo ambito che entra in gioco la tecnologia chiamata Semantic Web il cui obiettivo è fornire strumenti e standard per trattare l informazione presente sul Web in modo automatico da parte di elaboratori. Per permettere però l elaborazione automatica e lo scambio macchina-macchina 3

22 Web Of Data L avvento del Semantic Web di informazioni è necessario rappresentarle in modo che il computer possa comprenderle. Secondo l inventore del WWW, Tim Berner-Lee, il Web semantico non è separato dal Web, ma è una sua estensione, nella quale alle informazioni è dato un significato ben definito che permette una migliore cooperazione tra computer e persone [Cardoso] È interessante osservare che un hyperlink è una informazione si interpretabile dalla macchina, ma l uso più comune è l azione di apertura del collegamento in conseguenza di un diretto comando impartito da chi utilizza il computer. Il Semantic Web pone l accento soprattutto sulla elaborazione automatica. Per farsi una prima idea può essere utile pensare ad un programma spider di un motore di ricerca, che esamina in automatico i documenti da indicizzare: il successo di una ricerca di una qualche keyword dipenderà dalla capacità con cui lo spider ha compreso quali pagine trattano tale argomento. A differenza di quando un browser visualizza una pagina in seguito ad un comando ricevuto direttamente tramite una periferica di input, lo spider lavora in autonomia e mette in pratica una interazione macchina-macchina. Il linguaggio XML, Extensible Markup Language [XML], gioca un ruolo importante in questo campo: infatti in modo simile a come HTML contrassegna un titolo o un collegamento, XML definisce una sintassi per contrassegnare elementi di informazione. L adozione di XML abilita le macchine ad un alto grado di interoperabilità poiché permette lo scambio di dati in un linguaggio comune che è portato per l elaborazione automatica. Tuttavia XML di per se non aggiunge un significato. Di solito è tramite accordi raggiunti tra le parti che utilizzano le informazioni che si definisce il significato di un documento codificato in XML. Nel Semantic Web la definizione delle relazioni tra le risorse avviene tramite il Resource Description Framework (RDF) [RDF]: è nato per descrivere le informazioni, in particolare quelle presenti sul Web ed è una delle tecnologie fondamentali della sua estensione semantica. È un linguaggio di metadati semplice e polivalente per rappresentare informazioni e fornisce un modello per descrivere e creare relazioni tra risorse. Il legame di parentela tra RDF e Web è l URI: una risorsa RDF è definita come un qualsiasi oggetto che sia univocamente identificato da un Uniform Resource Identifier [RFC3986]. Le risorse sono dotate di proprietà. Le proprietà sono identificate dal loro tipo ed per una determinata risorsa hanno un corrispondente 4

23 Web Of Data L avvento del Semantic Web valore. I tipi di proprietà esprimono la relazione tra il valore e la risorsa. Un tipo quando identificato da un suo proprio URI assume carattere universale. La struttura base di RDF è molto semplice e usa delle terne per descrivere le proprietà di una risorsa. Queste terne si trovano in forma di Soggetto- Predicato-Oggetto. La notazione a triple fornisce un meccanismo flessibile per relazionare ogni cosa ad ogni altra. RDF si appoggia agli URI per permettere la definizione di concetti validi a livello globale. Ad esempio quando un URI è utilizzato per definire un soggetto, affermazioni che lo riguardano possono essere pubblicate ovunque sul Web con la garanzia che avranno lo stesso significato. In altre parole, le informazioni descritte tramite URI possono essere trovate, utilizzate, condivise e aggregate più facilmente. RDF è usato inoltre come base su cui costruire le ontologie: una ontologia è un vocabolario comune che fornisce un ben definito insieme di costrutti per la realizzazione di una conoscenza di livello superiore da usare per specificare la semantica delle terminologie in un ben definito e non ambiguo modo. Nel Semantic Web si usa il Web Ontology Language (OWL) [RFC3986]. OWL fornisce un vocabolario per descrivere le proprietà e le classi di oggetti con valore semantico [Cardoso]. L obiettivo è abilitare inferenze sulle informazioni e dunque arricchire il valore della conoscenza trattata. Traditional Web Vision Semantic Web Vision link Resource link link Resource link link Resource link link Resource link Resource link Resource link Resource link Resource director humanresource Jhon collegue HR salesman Jack Shop responsible support hasservices Product Services track sell Products hasproducts sell Product Figura 1.1: Risorse intercollegate dal punto di vista del Web tradizionale e da un punto di vista del Web semantico 5

24 Web Of Data Il Semantic Web è il futuro? La figura 1.1 illustra graficamente il confronto tra Web di documenti interconnessi e Web semantico. Il Web tradizionale è dotato di ridotta percezione e riconosce soltanto un collegamento da un documento. La navigazione delle risorse per scoprire una qualche informazione è demandata all intelligenza umana. L uomo comprende il significato dei collegamenti basandosi sull interpretazione della loro descrizione, e si orienta in base al significato letterale. Quindi è in grado di svolgere un ragionamento che lo porterà ad esempio ad individuare, se esiste, la pagina che può fornire supporto ai clienti su un sito di acquisti online. L idea del Web semantico è che sia la macchina ad eseguire questi compiti o una parte di essi, grazie a tecniche che permettono di aumentare la percezione ed interpretarne almeno in parte il significato. 1.2 Il Semantic Web è il futuro? Sebbene molte delle idee che stanno dietro al Web semantico nascono nella disciplina dell Intelligenza Artificiale, il suo disegno è e resta una estensione del Web esistente. La R di risorsa nel Resource Description Framework è la stessa R che troviamo in Uniform Resource Identifier. Anche se si usano in questo campo [Ayers07c] non solo per individuare un documento che una persona può leggere ma appunto se ne estende il concetto così da poter identificare ogni cosa, reale o virtuale, gli URI che troviamo in RDF sono proprio gli stessi che il Web usa da ormai quasi 20 anni. Il Semantic Web è soprattutto un percorso [Ayers06] e molto di quello che si sta studiando in questo campo tratta argomenti di avanguardia, molto lontani anche dal Web arricchito di tecnologie dinamiche, interazioni asincrone ed effetti grafici di nuova generazione che stiamo utilizzando oggi chiamandolo Web Come la storia ci insegna, anche fuori dal mondo informatico, molte rivoluzioni nate da ben motivati propositi sono finite disastrosamente. Con di utenti 2 il Web oggi ha una inerzia tale che non è possibile cambiare direzione senza andare incontro a fallimenti miserabili. Se dobbia vedi statistiche del 30 settembre

25 Web Of Data Il Semantic Web è il futuro? mo abbandonare la concezione di Web di Documenti tra di loro collegati, è necessario farlo con mani di velluto. Di fatto è proprio quello che sta accadendo. Nel Web 2.0 possiamo già vedere che tag, aggregatori, sistemi di content ranking ci assistono nel migliorare la nostra esperienza giornaliera. Quando ad esempio con il cursore del mouse indicate il numero di stelle con le quali votare un video che avete appena visto su YouTube.com, di fatto state assegnando un valore semantico a quel contenuto, il cui significato verrà interpretato da un sistema per valutare l interesse della risorsa pubblicata. Probabilmente non ci sarà OWL dietro a tale significato semantico, piuttosto vi sarà un routine appositamente scritta da un qualche esperto di programmazione, e quindi il valore espresso ha senso soltanto in un contesto locale al sito. L idea è che in un futuro prossimo il video che voi avete votato sarà semanticamente interessante anche fuori al sito di YouTube grazie ad RDF, OWL ed altre tecnologie ancora in fase di sviluppo. Il Web Semantico si evolve quindi a piccoli passi. Lo fa secondo i principi che ruotano intorno all Extreme Programming [Ayers06]: release frequenti e con piccole modifiche ci permettono un maggior controllo sul progetto ed il feedback ricevuto ci rassicura se percorriamo la giusta direzione o ci permette di trovarla grazie a piccole modifiche. Danny Ayers [Ayers06], individua 3 strategie con cui portare avanti questa evoluzione del Web: il primo approccio è assegnare ai contenuti attuali un valore interpretabile dalle macchine. Un esempio è l utilizzo che si può fare in HTML dell attributo rel=..., che può essere assegnato ai tag <a> e <link>. Si usa già adesso per specificare ad esempio un foglio di stile CSS per una pagina: <link rel= StyleSheet href=... type= text/css /> indica al browser che la risorsa indicata da href è uno StyleSheet per il documento in cui si trova questo tag; una seconda strategia, che consiste nell inserire informazioni fruibili dalle macchine nei contenuti HTML esistenti, potrebbe risultare più appetibile. L iniziativa dei microformats [Dimon05] viaggia in questa direzione; oppure si possono aggiungere interfacce orientate al Web semantico ai sistemi Web esistenti. L idea è quella di fornire e ricevere RDF 7

26 Web Of Data Dal Web di Documenti al web di Dati tramite HTTP. Feed quali Atom ed RSS sono un esempio di quest approccio, ma probabilmente nell immediato i benefici non giustificheranno lo sforzo di sviluppo necessario ad approntare i sistemi esistenti: molti sviluppatori non hanno la volontà o l interesse ad adottare il Web semantico, ma cercano soltanto qualcosa per migliorare la user experience. L attenzione è principalmente posta su user interface e content management system. 1.3 Dal Web di Documenti al web di Dati Sul percorso che ci porterà nel futuro del Web, l unica cosa che sembra certa è che l attenzione si sposterà dal documento al dato: Web Service e tecnologie come AJAX o le Rich Internet Application sono basate su HTML, HTTP ed URI ma la loro attenzione non si rivolge al documento come un tutt uno. Le applicazioni che usano queste tecnologie si concentrano piuttosto su singole informazioni con le quali svolgere un qualche tipo di elaborazione. In pratica si sta concentrando l interesse su contenuti che hanno una grana più fine rispetto all intera pagina HTML. Sta emergendo il concetto di Web of Data and Programs [Bratt05] [Bratt05S] contrapposto appunto al Web of Documents. Il Web di programmi è quello dei Web Service, il Web dei dati è quello che porta al Semantic Web e si manifesta con collezioni di informazioni interconnesse che troviamo nel panorama del Web 2.0 al fianco delle collezioni di documenti ipertestuali tradizionali. Digg, del.icio.us, Flickr, YouTube e Blogger assomigliano più ad una applicazioni che ad un sito tradizionale. Offrono servizi per trattare bookmark, immagini o video, appunti, commenti e descrizioni. Quindi sono incentrati sul dato piuttosto che sul documento che lo contiene ovvero il documento che viene mostrato sul vostro browser. Molti di questi siti offrono anche la possibilità di accedere direttamente ai dati trattati con delle apposite API. Un altro importante esempio è il Simple Storage Service di Amazon che permette la memorizzazione di informazioni generiche, con l interfaccia di un Web Service RESTful [RichardsonRuby], le quali possono essere descritte tramite metadati ed utilizzate ad esempio tramite AJAX [Hansen]. Il tutto appare più come un database flessibile modellato intorno al Web che non un insieme di pagine HTML consultabili con un browser. Quindi il Web of Data 8

27 Web Of Data Dal Web di Documenti al web di Dati è un concetto fondamentale per il Semantic Web, ma il Semantic Web non è necessariamente il suo unico fine. Data Data Web of documents Content model layer Web of data Documents Web of documents Figura 1.2: From a Web of documents to a Web of Data [Ayers07a] Il Web 2.0 quindi ha già fatto qualche passo in direzione del Web of Data. Molte recenti tecnologie presentano un aspetto che merita particolare attenzione: sono strutturate, direttamente o indirettamente, su di un content model layer [Ayers07a] ovvero poggiano le loro basi su di un data model orientato ai contenuti. Questo modello è descritto nelle specifiche del formato Atom, dentro alla Java Content Repository ed in numerosi altri sistemi dell odierno Web. Il content model layer tratta documenti e metadati a questi associati come un tutt uno. Concepire questo modo di funzionare secondo un principio di stratificazione ci offre una migliore panoramica sulle potenzialità di questo approccio. Uno strato di astrazione che modella i contenuti ed i metadati associati funziona con un Web basato sui documenti, con un Web orientato ai dati ed è compatibile alle prospettive del Web semantico. Si può pensare che questo data model rappresenti un passo intermedio e graduale verso il Web of Data. In figura 1.2 si può vedere come questa strategia permetta una transizione graduale da una concezione all altra. Il Web of Documents che si appoggia sul content model layer può essere visto come l insieme delle pagine dei siti che forniscono l accesso alle informazioni dei servizi del Web 2.0. L URI diviene quindi uno strumento generalizzato, per accedere non più 9

28 Web Of Data Infrastruttura del Web di dati soltanto ad un documento, ma indirizza finemente le risorse [Ayers07b]. Le tecnologie del semantic Web quali RDF ed OWL ci aiuteranno a renderne universale l uso ed il significato. 1.4 Infrastruttura del Web di dati Da un punto di vista tecnologico, il Semantic Web utilizza l attuale infrastruttura del Web per ottenere accesso ai dati di cui ha bisogno. Le informazioni del Web of Data quando non sono direttamente impacchettate dentro a documenti HTML, usano per l accesso la stessa interfaccia HTTP. Non ci sono nuovi protocolli se non il SOAP, ma questo non è altro che un meccanismo per inviare XML tramite (principalmente) HTTP. Manca una architettura che ponga delle convenzioni su come eseguire l authoring di questi dati. Semantic Web Stack (lower levels) Ontology: OWL Data Interchange: RDF XML HTTP URI / IRI HTTP + SOAP FTP, File, smtp... Apache Apache Web Web Servers Servers Underlying Web systems MS MS IIS IIS SQL SQL databases Java Java Containers Containers Figura 1.3: Come il Semantic Web si costruisce sulle attuali strutture Web Gli standard per i Web Service coprono aspetti di programmazione, favoriscono l interoperabilità soprattutto tra sistemi e linguaggi diversi, ma spesso ogni sviluppatore sceglie una sua soluzione per affrontare il problema di come rappresentare le risorse. I Web service in quanto ad authoring mancano delle Convention over Configuration che fornirebbero ai programmatori elementi comuni da utilizzare per rendere i sistemi maggiormente interoperabili. 10

29 Web Of Data Infrastruttura del Web di dati Eppure l interesse che il REST sta riscuotendo, al di la di tutti i benefici conclamati, non è altro che una richiesta da parte del mondo dei programmatori di qualcosa che incrementi la user experience ma che fondamentalmente sia semplice da usare così come è lo stato HTTP. Il Web semantico suggerisce cosa si potrà fare. Abbiamo visto che un passo intermedio è il Web of Data, e che questo ha senso di esistere anche senza il primo. Ma ancora non esiste una architettura che favorisca il cambio del modo di concepire il Web, e i nuovi standard non trattano questo argomento. Ognuno implementa una sua soluzione, sebbene l authoring di informazioni oggigiorno sia un pattern consolidato, grazie anche alla vasta diffusione dei diversi Content Management System. Sistemi di controllo di versione e di gestione del lavoro collaborativo hanno permesso la nascita di alcuni dei maggiori elementi di interesse del recente Web, prima fra tutti l esperienza innovativa di Wikipedia. Abbiamo però visto che non è proponibile l adozione di soluzioni radicali, quindi serve qualcosa che possa silentemente immettersi nel panorama attuale. Probabilmente il Web Semantico stenta a farsi vedere sul panorama attuale proprio perchè si sta aspettando che l evoluzione naturale selezioni le giuste convenzioni. La JCR 3 è una tecnologia che si spinge in questa direzione: è una API che abilita lo sviluppo di applicazioni orientate ai contenuti. Fornisce dei metodi per l authoring di dati e si basa su un layer di astrazione che agevola l interoperabilità con sistemi legacy di vario tipo. Purtroppo la soluzione è utile soltanto per applicazioni Java, e sebbene possa essere rivestita con servizi Web, manca di quella generalità che ha fatto il successo dell HTTP. Si può ipotizzare che per favorire la nascita del Web of Data sia necessario formulare anche dei Content Management System orientati ia dati, che condividano lo stesso modello per l informazione. A differenza di database tradizionali, i dati gestiti da un CMS di questo tipo, saranno esposti tramite una interfaccia simile ad HTTP, saranno orientati ad esprimere relazioni grazie ad RDF e supporteranno il reasoning per mezzo delle ontologie. Avranno visibilità globale grazie all indirizzamento ed identificazione tramite URI, supporteranno sistemi di controllo di versione, e saranno distribuiti. Gestiranno 3 Content Repository for JavaTM technology API 11

30 Web Of Data Infrastruttura del Web di dati l accesso e la collaborazione di utenti sparsi in tutto il mondo, e favoriranno il nascere di comunità che con i propri contributi ne aumenteranno il valore. Semantic Web Stack Web of Documets infrastructures Web of Data infrastructure Existing Document Oriented Resources New Pure Data Oriented Resources Figura 1.4: Semantic Web verso il Web of Data La recente evoluzione ci suggerisce di cercare una soluzione nel campo dei Web Service e delle Service Oriented Architecture (SOA) [Erl]. I principi del Representational State Transfer (REST) [Fielding] sono di interesse fondamentale poichè, anche se finora abbiamo parlato di dati, stiamo discutendo di accesso a risorse. Soprattutto, qualsiasi intervento si inserirà nel panorama attuale gradualmente, senza imporre nessun radicale cambiamento, ma fornedo una strada facile da percorrere che orienterà nella stessa direzione i progetti di sviluppo a seguire. La figura 1.4 ipotizza come l avvento di tali soluzioni a sostegno del Web Semantico potrebbe inserirsi nel panorama attuale, attuando il vellutato spostamento di paradigma che dal Web of Documents porterà definitivamente alla nascita di un Web of Data a cui sia possibile dare una definizione. 12

31 Capitolo 2 Il progetto InterDataNet...I believe that at the end of the century the use of words and general educated opinion will have altered so much that one will be able to speak of machines thinking without expecting to be contradicted Alan Touring, 1950 Il progetto InterDataNet (IDN) nasce per venire incontro alle esigenze di collaborazione ed interoperabilità che sorgono nell affrontare le problematiche di un Web orientato ai dati. IDN propone una architettura stratificata e un modello per le informazioni che hanno l ambizione di poter abilitare il Web of Data grazie ad una soluzione globale che faciliti il riutilizzo e la condivisione di risorse. I concetti fondamentali e la descrizione del suo funzionamento sono argomento di questo capitolo.

32 Il progetto InterDataNet Content Management nel Web of Data Nella sezione 2.1 verrà offerta una panoramica delle motivazioni e delle idee su cui è stato costruito il progetto. In 2.2 sarà illustrata nel suo insieme l architettura della soluzione proposta e verrà introdotta la Service Architecture (IDN-SA), il modello informativo (IDN-IM) e l interfaccia con le applicazioni (IDN-API). Il loro funzionamento sarà approfondito in 2.3 dove si illustreranno i vari livelli (IDN-SI,IDN-RM,IDN-IH e IDN-VR), i servizi per i nomi (LS ed LDNS) ed i concetti di applicazione IDN, documento IDN e Primitive Data Unit. La sezione 2.4 infine effettuerà una proiezione IDN nel contesto del Web e del Web of Data. 2.1 Content Management nel Web of Data Il networking globale rafforza il bisogno di rendere le risorse riutilizzaili tra persone, comunità ed organizzazioni sparse in tutto il mondo, ed in previsione di un Web Semantico questa esigenza si fa più forte. Tuttavia molta della letteratura intorno al web semantico ruota su problemi di inferenza, machine learning e gestione delle ontologie. Il problema dell authoring collaborativo delle informazioni ancora non è stato affrontato seriamente, ed il Web Semantico stenta a decollare. Uno dei principali ostacoli allo sviluppo è dovuto al fatto che l esperienza semantica rimane spesso confinata a livello locale. L informatica di oggi invece chiede soluzioni distribuite, e progettare sistemi che possano funzionare in rete non è per niente facile. Ci vuol poco per scambiare qualche dato attraverso HTTP, ma mettere in piedi una architettura completa è un altra cosa: la disciplina dei sistemi distribuiti tra computer e persone, è una delle più interessanti ed allo stesso tempo è una delle sfide più difficili della moderna Information Technology. Nei prossimi paragrafi verranno brevemente discussi concetti fondamentali per porre delle solide basi all authoring nel mondo a cui il Web of Data appartiene: quello dei sistemi distribuiti Naming and Data Addressability È necessario indicare le risorse. Serve poterlo fare perchè vogliamo essere in grado di venire a conoscenza di una informazione, poterla modificare, 14

33 Il progetto InterDataNet Content Management nel Web of Data copiarla o stamparla e per eseguire queste operazioni dobbiamo essere in grado di indicare al calcolatore la risorsa che ci interessa. Ma non basta, spesso possiamo anche avere necessità di passare informazioni a qualcuno, quindi è necessario che il modo in cui la risorsa viene recuperata possa anche essere compreso da essere umani e che per entrambi esista un modo comune ed uniforme per specificare senza ambiguità le modalità di recupero dei dati di interesse. Serve quindi un nome ed un sistema di naming distribuito. Un nome è una stringa di caratteri usata per riferirsi a un entità. Per operare su di essa è necessario un punto d accesso, anche esso dotato di nome che si definisce indirizzo [TanenbaumSteen]. In generale, una entità può avere più di un punto di accesso, si pensi per esempio ad una persona che ha più numeri di telefono al quale contattarla. È necessario che il sistema di nomi sia separato dal meccanismo di accesso poichè le risorse spesso cambiano la loro collocazione ma si deve poter continuare a chiamarle ugualmente: ad esempio un cellulare può essere smarrito ma la compagnia telefonica ci fornirà una scheda grazie alla quale essere contattati usando lo stesso vecchio numero. Un nome in un sistema di questo tipo è detto indipendente dalla posizione. Quando il nome fornisce informazioni sul punto di accesso ad una entità, è importante considerare la questione della sua unicità. Ad esempio se una entità ha più di un indirizzo, può non essere chiaro quale debba essere usato. I nomi, quando sono usati per identificare univocamente un entità sono detti identificatori e sono caratterizzati dai seguenti aspetti: ad ogni nome è associata al massimo una entità ogni entità è referenziata al massimo da un identificatore un identificatore si riferisce sempre alla stessa entità (cioè non è mai riusato) Gli identificatori si usano principalmente per riferisi ad una entità in modo non ambiguo. Oltre a nomi che indirizzano e nomi che identificano, esistono i nomi di tipo Human Friendly Name (HFN). Hanno come scopo principale l essere usati da persone la dove gli indirizzi o gli identificatori in formato macchina 15

34 Il progetto InterDataNet Content Management nel Web of Data abbiano una forma non immediatamente comprensibile, come ad esempio il linguaggio binario. I nomi dei file ed i nomi del DNS sono i più diffusi esempi di HFN. Il nome usato nel Web è quello degli Uniform Resource Identifier (URI). Gli URI, in senso lato, forniscono funzioni per identificare le risorse in modo amichevole per gli esseri umani. Questi comprendono come sottoinsieme gli Uniform Resource Locator (URL): gli URL sono URI che oltre a identificare amichevolmente le risorse, ne specificano anche il punto di accesso. Sebbene siano nati per le pagine web, non ci sono controindicazioni ad utilizzare URI per chiamare, indirizzare ed identificare parti più piccole di un documento, quindi sono ottimi candidati per rimanere protagonisti anche in un Web orientato ai dati. Tuttavia è standardizzato indicare una pagina attraverso un URL, ma non esiste nessuno standard da adottare quando si trattano informazioni a grana più fine di una pagina. Ci sono pareri discordanti su come utilizzare path, query e fragment dello schema di un URI [RFC3986] per chiamare, indirizzare ed identificare informazioni, e oggi si adottano soluzioni locali ad-hoc che rendono difficoltosa l interazione tra sistemi. Spesso i metodi si equivalgono, e ad oggi è importante trovare un modo uniforme per regolare l esposizione dei dati Data Replication Una politica di replicazione dei dati consiste in regole adottate in un sistema informatico per gestire duplicati di risorse. Per motivi di efficienza e/o per motivi di affidabilità, in un sistema distribuito potrebbe essere conveniente o necessario non limitarsi a mantenere una sola copia delle informazioni. L esistenza di più repliche ci permette ad esempio di prevenire l inaccessibilità alle informazioni qualora un problema di rete, un crash di sistema o un guasto rendano un server irraggiungibile. Se infatti vi sono più fonti dalle quali poter reperire la stessa informazione, se una di queste non funziona possiamo provare con un altra. Le probabilità di fallire l accesso ad una 16

35 Il progetto InterDataNet Content Management nel Web of Data risorsa diminuiscono con l aumentare del numero di copie diffuse nel sistema. Una buona politica di repliche può rendere più facile la gestione dei backup ed in caso di corruzione di dati, utilizzando meccanismi come i cheksum 1, è possibile prevenire la perdita di informazioni identificando la risorsa non valida e risanarla con una copia integra. Più copie, o più in generale, più fonti dalle quali attingere informazioni migliorano le prestazioni per due motivi: posizionando una copia vicino al processo che la usa diminuisce il tempo di accesso (si pensi ad una struttura che offre servizi in tutto il mondo e che posiziona server di replica in ogni nazione per questo motivo). Ma anche in una rete locale può essere conveniente avere più server sincronizzati tra di loro e che si dividono il carico di lavoro. Più in generale, la replica permette di risolvere problemi di scalabilità. La trasparenza alla replica è il nascondere all utente l esistenza di più copie di una risorsa. Ad esempio è trasparente il meccanismo con cui un browser Web mantiene una replica nella cache per migliorare l efficienza in caso di un accesso ripetuto alla stessa risorsa, mentre invece non lo è il masterizzare una copia di backup, se non altro perchè comporta almeno che l utente si prenda cura fisicamente di riporre il compact disc in un luogo sicuro. Per ottenere la trasparenza alle repliche quindi ogni copia agli occhi dell utente ha lo stesso nome e lo stesso identificatore. Di conseguenza è necessario che sia trasparente anche l ubicazione, ovvero non è possibile per un utente indicare dove la risorsa sia collocata fisicamente. Se non fosse così l utente prendendo coscienza dei luoghi fisici in cui le repliche risiedono, vedrebbe che esse sono più di una. Utilizzando meccanismi di replicazione dei dati si accetta il compromesso di dover affrontare i problemi che ci sono per mantenere e garantire la loro consistenza. Quando viene modificata una copia, questa diventa diversa dalle altre ed è necessario un meccanismo che le possa aggiornare o invalidare. Ad esempio quando si accede ad una pagina Web che ha contenuti che variano con molta frequenza, si pensi ad esempio ad un sito di informazioni giornalistiche, è necessario gestire la consistenza della cache. Se l originale 1 Checksum, tradotto letteralmente significa somma di controllo. È una sequenza di bit che viene utilizzata per verificare l integrità di un dato o di un messaggio che può subire alterazioni. 17

36 Il progetto InterDataNet Content Management nel Web of Data viene aggiornata la copia locale dovrà essere invalidata e ricaricata al prossimo accesso. Il protocollo HTTP ha delle funzionalità che permettono di gestire la cache in queste situazioni, ma a causa delle difficoltà implementative (spesso i documenti ed i siti sono creati senza alcuna considerazione di questi aspetti) capita spesso di trovarci in situazioni in cui è necessario un refresh forzato da parte dell utente per ottenere l ultimo aggiornamento (col rischio di non accorgersi della sua esistenza). Oppure capita il contrario, cioè la risorsa viene trasferita completamente ogni volta che viene utilizzata anche se non è cambiata. Esistono diversi modelli per gestire la consistenza, ed in genere si accettano dei compromessi, come ad esempio accettare che la copia che stiamo utilizzando potrebbe non essere la più aggiornata, per bilanciare i benefici con l aumento della complessità. Quando decidiamo se ricorrere a meccanismi di replicazione si deve infine tener conto, per il bilancio finale, degli effetti negativi sulle prestazioni in caso di modifica, dovuti alla necessità di propagare l operazione ad ogni replica esistente, e anche del costo richiesto in termini di spazio per memorizzare tutte le copie. Nel progettare infrastrutture per l authoring nel Web orientato ai dati è quindi preferibile poter pianificare fin dalle prime fasi se è necessario adottare una politica di replicazione e con quale modalità. Bisogna tener conto che potrebbe essere impossibile inserire in un sistema avviato delle soluzioni avanzate per la gestione della consistenza Versioning Il controllo di versione è la gestione di versioni multiple di un insieme di informazioni usato soprattutto nello sviluppo di progetti informatici o ingegneristici per controllare l evoluzione dei documenti. È usato per organizzare il lavoro quando le specifiche del progetto dipendono da una squadra di persone, e cosiste principalmente nell assegnare ai documenti un numero o una etichetta di versione allo stato che questi assumono a seguito di modifiche. Le modifiche apportate vengono tracciate e si parla di revisione di un progetto per indicare l evoluzione dell insieme di documenti. Le tecniche di 18

37 Il progetto InterDataNet Content Management nel Web of Data controllo di versione aiutano a gestire l integrazione ed il conflitto dei documenti tra più utenti, in particolare una numerazione progressiva agevola il procedere a ritroso quando il progetto si trova davanti a vicoli ciechi. Esistono diversi modelli per la gestione del controllo di versione [Chini05] ed in generale si differenziano in base allo schema adottato per enumerare le revisioni. Le ultime tecniche permettono una gestione del branching, ovvero lo sviluppo parallelo di un progetto quando due o più parti si curano dell evolvere di aspetti diversi, e facilitano il merge ovvero il ricongiungimento del lavoro svolto dai diversi gruppi. Sebbene in linea di principio si possa parlare di controllo di versione anche dove la progettazione avviene con documenti cartacei, è nel CAD 2 che il versioning ha avuto diffusione ed è grazie all ausilio di appositi strumenti informatici che si possono apprezzare i benefici maggiori per l organizzazione di un progetto. I diversi tool utilizzano modelli di versionamento differenti [Chini05] e grazie a repository comuni accessibili tramite reti informatiche agevolano la collaborazione e la coordinazione dei gruppi di lavoro. Sebbene sia stato utilizzato prevalentemente nel campo della progettazione di software, il versioning si sta estendendo oggigiorno nel campo della gestione documentale e dell authoring concorrente. In questi campi è di interesse soprattutto la possibilità di ottenere la tracciabilità delle modifiche effettuate dai diversi utenti e di consultarne la storia ovvero la sequenza di stati in cui i documenti si sono trovati dal momento in cui sono stati posti sotto controllo. Ad esempio, questi aspetti sono particolarmente interessanti per il campo dell informatica giuridica [Paolucci06]: gli strumenti di controllo agevolerebbero l organizzazione degli atti che ancora oggi sono legati a documenti prevalentemente cartacei. Ma non solo: alla base del successo di Wikipedia 3, l enciclopedia libera del Web, c è il suo sistema di controllo di versione che ha permesso anche ad utenti anonimi di contribuire ai contenuti. Grazie alla tracciabilità ed allo storico è infatti possibile ripristinare i documenti la dove un intervento di un 2 Computer Aided Design ovvero Progettazione Assistita dal Calcolatore

38 Il progetto InterDataNet Content Management nel Web of Data utente non competente o male intenzionato abbia compromesso la veridicità di una voce. Nell authoring orientato ai dati, l utilizzo di meccanismi di versionameto risulta quindi un elemento davvero interessante: agevola la collaborazione e facilita l apporto di contributi, e come abbiamo visto questa è una delle chiavi che ha reso possibile il successo di molti dei servizi di social networking famosi nel Web 2.0. Inoltre apre la strada per la creazione di servizi nel campo dell e-government. Così come per la gestione delle repliche, il controllo di versione è un elemento da considerare nella pianificazione di una architettura per il Web of Data Data Access Control Per eseguire alcune operazioni su specifiche risorse è necessario essere in possesso della corretta autorizzazione. Non si può accedere alla casella di posta elettronica di chiunque si voglia, non si può scaricare file se non si accettano le condizioni a cui è sottoposto il loro utilizzo, non si può cancellare un documento - solitamente - se questo non ci appartiene. Il controllo degli accessi è la verifica dei privilegi d accesso ad una risorsa o ad un servizio, al seguito della quale il sistema fornisce o nega l autorizzazione al suo utilizzo. Il controllo degli accessi insieme ad autenticazione, alla instaurazione di un canale sicuro e all auditing, rientra tra gli aspetti principali della gestione della sicurezza in un sistema distribuito [TanenbaumSteen]. Un canale sicuro protegge mittenti e destinatari dalle intercettazioni, dalle alterazioni e dalle contraffazioni dai messaggi. È strettamente correlato al concetto di autenticazione: non ha importanza conoscere con certezza chi è il mittente di un messaggio se non si può essere certi dell integrità di quest ultimo. L autenticazione è la verifica dell identità dichiarata da un utente, da un client, da un server, di un host o da altre entità di un sistema. Il meccanismo più comune per assicurare l autenticazione è la password, ovvero una chiave comune, segreta, conosciuta soltanto dalle due parti comunicanti. La password prevede che avvenga una registrazione tra le due parti, diretta 20

39 Il progetto InterDataNet Content Management nel Web of Data o indiretta, ma in un sistema complesso ciò può non rappresentare la via migliore. Per offrire la scalabilità è necessaria l adozione di un meccanismo evoluto per la concessione delle autorizzazioni, qualcosa che permetta l autorizzazione tramite delega di terze parti e l autenticazione tra differenti domini di appartenenza. L auditing è il tener traccia delle operazioni che vengono svolte da una entità autenticata. Sebbene non fornisca una vera protezione contro le minacce, questo meccanismo permette l analisi delle falle di sicurezza e talvolta di risolvere i problemi verificatisi in seguito ad attacchi 4. Operation Request Authorized Request Subject Reference Monitor Object Figura 2.1: Modello generale per il controllo dell accesso agli oggetti Quando il sistema tratta risorse è fondamentale il controllo degli accessi. Il modello generale per il controllo degli accessi in figura 2.1 comprende un soggetto, un oggetto ed un reference monitor [TanenbaumSteen]. Un soggetto è una entità che solleva una richiesta d accesso ad un oggetto. Le operazioni sono eseguite attraverso delle apposite interfacce. La protezione contro gli accessi non autorizzati è eseguita solitamente da un apposito processo chiamato reference monitor che nel caso più semplice memorizza quale soggetto può compiere una determinata operazione. Pertanto in un ambiente trusted è fondamentale che questo processo sia a prova di manomissioni. Il reference monitor utilizza la matrice di controllo degli accessi per determinare i privilegi di accesso. Nella matrice è memorizzato per ogni soggetto i privilegi di cui gode su ogni oggetto. In sistemi con numerosi oggetti e soggetti, la matrice non è implementata direttamente in memoria, ma tramite altri metodi come le ACL o liste delle possibilità. Una Access Control List (ACL) è una lista dei privilegi di accesso memorizzata dentro ad ogni oggetto. 4 L attacco è l utilizzo di una vulnerabilità per mettere in pratica una operazione non autorizzata 21

40 Il progetto InterDataNet Content Management nel Web of Data Le possibilità, o capability, invece vengono date al soggetto, ed il reference monitor gestisce la protezione alle risorse sulla loro base: la matrice di controllo diviene quindi un incrocio di oggetti e capability il cui numero è in genere indipendente da quello dei soggetti. Le capability sono paragonabili a ticket sulla base del quale vengono dati permessi al suo detentore, ed è chiaro che risulta necessario proteggerlo da manomissioni ad esempio tramite una firma. La differenza fondamentale tra ACL e capability è che il reference monitor in questo secondo caso non è interessato a conoscere il soggetto della richiesta, la capability è sufficiente. Questo meccanismo è importante nei sistemi distribuiti quando le autorizzazioni devono essere eseguite tra diversi domini, dove non è detto che un soggetto sia conosciuto in entrambi oppure dove, anche se conosciuto, questo non possa essere autenticato. ACL e capability list implementano efficientemente una matrice di controllo in quanto si ignorano tutti gli elementi vuoti con un conseguente risparmio si spazio ed elaborazione. Tuttavia le liste possono comunque crescere oltre i limiti di gestione. Un dominio di protezione permette di ridurre queste liste. Un dominio di protezione è un insieme di coppie <oggetto,privilegi di accesso> che specificano per un dato oggetto quali operazioni possono essere eseguite. Il controllo non viene effettuato sul soggetto autore della richiesta, ma sul dominio di protezione. Il reference monitor quindi controlla il dominio di protezione ed in seguito verifica se questa può essere portata a termine. L approccio basato su gruppi di utenti, sui certificati e sui ruoli fanno parte del controllo accessi con dominio di protezione. Probabilmente una infrastruttura per il Web of Data dovrà supportare una politica versatile del controllo degli accessi, abilitando sia meccanismi più restrittivi, necessari in campi applicativi più rigorosi quali ad esempio l e-governemet, sia meccanismi più semplici dove è preferibile favorire User-Generated Content, e dovrà supportare meccanismi cone gli attribute certificate e la delega [TanenbaumSteen]. Per l autenticazione e la creazione di un canale sicuro può essere invece interessante valutare l uso di un approccio single sign-on come in Kerberos [Zappia06]. Infine potrebbe essere necessario valutare quali interfacce esporre in caso si richieda un meccanismo di auditing esterno al sistema. 22

41 Il progetto InterDataNet Content Management nel Web of Data The pursuit of interoperability È molto sentita al giorno d oggi l esigenza di rendere le applicazioni maggiormente interoperabili tra di loro. Interoperabilità 5 significa che due implementazioni di sistemi o componenti di due diversi produttori possono coesistere e collaborare basandosi unicamente sui reciproci servizi specificati da uno standard comune [TanenbaumSteen]. È un concetto base per le ultime tendenze tecnologiche. Gli stessi Web Service sono definiti dal World Wide Web Consortium come [...] sistemi software progettati per supportare una interazione macchina-macchina interoperabile attraverso le reti [WSArch] e le Service Oriented Architecture hanno la proprietà di High Interoperability [Josuttis] tra i requisiti principali. In senso più pratico l interoperabilità si ottiene adottando standard comuni sui quali basare i propri progetti, ma non è un obiettivo facile da raggiungere, soprattutto in ambito enterprise: nella maggioranza dei casi non è possibile ricostruire da zero i sistemi esistenti e sono adottate soluzioni di conversione e traduzione di informazioni che in alcuni casi possono essere molto complesse da implementare. Sicuramente è di aiuto uno standard affermato verso il quale convergere, e sul quale progettare nuove soluzioni. Ad esempio XML è un linguaggio complesso da utilizzare, ma la sua standardizzazione ha permesso la nascita di strumenti di sviluppo e di pratiche diffuse e consolidate che rendono il bilancio tra vantaggi e svantaggi assai favorevole, almeno nel campo delle applicazioni distribuite (non a caso XML è alla base degli standard su cui si basano i Web Service). L interoperabilità è una questione spinosa per il Web of Data: la nascita e l adozione di sistemi con questo orientamento dipenderà dalla difficoltà con cui le applicazioni esistenti potranno essere interoperabili con le nuove architetture, e da come queste potranno essere interoperabili con le infrastrutture esistenti. 5 Il concetto è imparentato ma non va confuso con la portabilità ovvero la capacità di una applicazione di poter essere eseguita su sistemi differenti. 23

42 Il progetto InterDataNet InterDataNet: una soluzione per l interdataworking 2.2 InterDataNet: una soluzione per l interdataworking Figura 2.2: Il logo del progetto Per favorire l interoperabilità e la collaborazione nel mondo del Web orientato ai Dati nasce il progetto InterDataNet (IDN). Concepito nell ambito del dottorato di Telematica e Società dell Informazione presso la Facoltà di Ingegneria dell Università degli Studi di Firenze, IDN è un reference model di una architettura per l InterDataWorking [MelDec00]. Lo sviluppo del progetto è in corso da alcuni anni ed attualmente la fase di progettazione è in uno stadio avanzato. In questa fase si stanno implementando le funzionalità base con lo scopo di verificare e validare le scelte progettuali effettuate. Esiste un sito web sul quale si possono trovare informazioni aggiornate sul progresso dei lavori. Lo potete trovare all indirizzo La struttura fisica e logica di IDN si basa sul concetto di stratificazione: così come Internet risolve i problemi della comunicazione in reti interconnesse delegando agli strati la cura di aspetti specifici come il trasporto, il routing ed il networking [RFC1122] [Tanenbaum], InterDataNet propone l uso di layer differenti per abilitare a livello globale la collaborazione tra persone, imprese ed organizzazioni. Questa finalità è caratterizzata sicuramente da un forte effetto network 6, 6 L effetto network è una caratteristica per la quale un bene o un servizio possiedono, per un cliente potenziale, un valore che dipende dal numero di altri clienti che lo abbiano acquistato o dal numero di utenti del servizio. Network_effect 24

43 InterDataNet Middleware Il progetto InterDataNet InterDataNet: una soluzione per l interdataworking IDN Compliant Application IDN APIs Virtual Repository Layer Information History Layer Replica Management Layer Storage Interface Layer Filesystem, database, etc. Generic storage architecture HTTP(S), SMTP(S), FTP(S), etc. Generic network communication architecture Figura 2.3: Interdataworking in IDN e quindi è necessaria prima di tutto l adozione in massa di uno standard comune. Per questo motivo IDN si presenta come un modello di riferimento che può essere adottato liberamente da persone, imprese ed organizzazioni. Tuttavia il valore iniziale di questa architettura è nei servizi che fornisce a supporto della collaborazione tra utenti in rete ed il suo progetto è passato attraverso lo studio delle funzionalità e dei requisti necessari per porre delle solide fondamenta. Per favorirne l adozione e poter così raggiungere quella massa critica che giustificherebbe un suo uso ancora più diffuso, è stata data particolare attenzione allo studio dell integrazione con le infrastrutture del Web tradizionale e del Web Il design pattern della stratificazione applicato ai dati Da un certo punto di vista IDN può essere vista come un design pattern 7 che descrive il modello, le intenzioni e le motivazioni, i campi applicativi, le conseguenze, la struttura ed una implementazione di riferimento di una soluzione per un Web of Data collaborativo. 7 Ovvero una soluzione formale riutilizzabile ad un problema contestualizzato [DesignPatterns] 25

44 Il progetto InterDataNet InterDataNet: una soluzione per l interdataworking IDN si pone l obiettivo di fornire un Information Model condiviso ed una architettura di riferimento per la gestione di questo modello che sia capace di offrire: l indirizzamento globale delle risorse un insieme di servizi orientati alla collaborazione in sistemi distribuiti delle specifiche finalizzate a garantire l interoperabilità Per descrivere i concetti, il modello e le tecnologie di IDN si introducono tre concetti principali. Applications use IDN-IM to represent pieces of information and documents IDN Compliant Application IDN APIs Applications interact with IDN-IM through IDN-APIs IDN-IM IDN Service Architecture (IDN-SA) IDN-SA implements IDN-IM Network communication and storage architecture Figura 2.4: I componenti di IDN Con il nome di IDN-IM (InterDataNet Information Model) è indicato il modello dell informazione alla base dell architettura. È un modello astratto, indipendente da contesti specifici e dalle tecnologie adottate per rappresentarlo. Definisce i requisiti, le proprietà, i principi e la struttura delle informazioni. IDN-SA (InterDataNet Service Architecture) è invece il modello dell architettura stratificata di IDN. È basata sui principi delle SOA, le architetture orientate ai servizi (vedi capitolo 3.1), e del REST (vedi capitolo 3.3). Le interfacce esposte da IDN-SA vengono chiamate le IDN-API (IDN Application Programming Interface), e permettono lo sviluppo di applicazioni basate sulle risorse rappresentate dall IDN-IM. Un ruolo importante 26

45 Il progetto InterDataNet InterDataNet: una soluzione per l interdataworking è giocato proprio dalle applicazioni: queste usano le funzionalità esposte dalle IDN-API per implementare la business logic. La figura 2.4 illustra come questi tre aspetti interagiscono L approccio bottom-up Per capire al meglio cosa fa IDN è utile esaminarla secondo l approccio bottom-up 8, ovvero dal basso verso l alto, nel senso degli strati di ISN-SA. Si parte dal basso, dall interfaccia di storage, e se ne spiegano i concetti tramite passi successivi in cui servizi vengono aggiunti livello per livello. Il primo livello è lo Storage Interface (IDN-SI). Contiene un unico tipo di servizio che prende lo stesso nome del livello. La sua funzione è memorizzare informazioni ed esporle tramite una interfaccia uniforme. Deve rimanere semplice e deve offrire funzionalità basilari. Può essere visto come un servizio Resource Oriented che memorizza informazioni e metadati a questi associati ovvero come punto di accesso ad un repository di base per una SOA. Infatti è un servizio indipendente dal resto di IDN e può essere riutlizzato in contesti in cui si hanno necessità di memorizzazazione informazioni di questo tipo. Durante il lavoro di tesi sono stati esaminati i possibili casi di utilizzo di Storage Interface Service, anche al di fuori di IDN. Nel capitolo 4 si può trovare l analisi di questi scenari. Il punto di riferimento per IDN-SI è il Web Service Amazon Simple Storage Service (S3) 9 : è un servizio Web esistente, ed ha anche un riscontro commerciale. Amazon è una compagnia americana che si dedica al commercio elettronico. Da qualche tempo offre una serie di servizi commerciali che si basano sui Web Service, tra i quali figura anche il Simple Storage Service. Con S3, Amazon vende spazio sul Web a costi vantaggiosi ed offre garanzie di affidabiltà che possono interessanti per alcune tipologie di clienti. Gli 800 milioni di risorse memorizzate nella piattaforma di Amazon a giugno del 2006 sono diventate 5 miliardi in aprile del 2007, e sono raddoppiate ad ottobre dello stesso anno, con un picco di transazioni per secondo L approccio bottom-up è contrapposto all approccio top-down nel quale IDN è spiegata ed illustrata dall alto 9 vedi anche [RichardsonRuby], capitolo web-20-summit-amazon-gives-update-on-web-services/ 27

46 Il progetto InterDataNet InterDataNet: una soluzione per l interdataworking La differenza tra S3 ed un comune servizio di Web Hosting è che Amazon vi offre spazio Web dietro l interfaccia di un Web Service. Per attirare l interesse dei possibili clienti Amazon fornisce sia una interfaccia SOAP sia una interfaccia RESTful basata su HTTP. Inoltre sono disponibili librerie pronte per molti linguaggi di programmazione. Ricordiamoci per un momento che il tipico servizio di hosting permette la pubblicazione di un sito Web accessibile in lettura con HTTP, ma solitamente è grazie ad FTP che vi si caricano sopra i contenuti. Il sito in hosting è pensato per servire pagine Web, sebbene se ne possa fare un utilizzo diverso. Amazon S3 è pensato per servire un Web Service, ma grazie alla sua interfaccia RESTful può almeno in linea teorica, fornire documenti Web ad un Browser (questo principio di interoperabilità è stato fondamentale per il suo successo). Quindi adesso possiamo immaginare un servizio che ci offre funzioni di storage adottando l interfaccia IDN-SI: possiamo tranquillamente considerarlo un fratello di Amazon S3. IDN-SI tuttavia è una specifica, in particolare è una specifica libera. Permette a chiunque di sviluppare una propria implementazione, di mettere in piedi una infrastruttura hardware e di vendere spazio così come fa Amazon, ma il beneficio per gli utenti è la possibilità di scegliere lo storage provider col miglior rapporto qualità/prezzo. In particolare è possibile pensare anche ad implementazioni di interfacce di storage locali, cioè da far funzionare sul proprio computer, in modo da rendere il nostro lavoro interoperabile tra locale e remoto. Quest ultimo concetto ci suggerisce il primo scalino verso l alto nella pila protocollare di IDN: prendiamo l interfaccia di storage e ricopriamola con un servizio che offre la replica delle risorse. Abbiamo aggiunto ad IDN il livello di Replica Management (IDN-RM). Grazie a questo approccio è possibile implementare una soluzione trasparente che può gestire una distribuzione dei contenuti con i benefici di prestazioni e scalabilità che la replicazione apporta. Pensiamo ad esempio un servizio di replica che mantiene sincronizzate delle copie su uno Storage Interface collocato in azienda con le copie su un Storage Interface sul proprio computer. Il livello IDN-RM è composto da due servizi: il servizio di gestione delle repliche ed il servizio di localizzazione. Questa separation of concern è sug- 28

47 Il progetto InterDataNet InterDataNet: una soluzione per l interdataworking gerita dallo stile delle SOA. In particolare il servizio di gestione amministra la creazione e la distribuzione delle copie, mentre il Localization Service gestisce le associazioni identificatore-indirizzi: esistendo più repliche di una unica risorsa, per ogni identificatore esistono più indirizzi per poterla recuperare. Il passo successivo verso la collaborazione è uno strato che si occupa di controllare la versione delle informazioni. Questo compito è svolto dal layer di Information History (IDN-IH) Il servizio in questo strato intercetta tutte le richieste di operazioni sulle risorse e può gestire, in caso di modifica, una politica per il versionamento. Il controllo di versione in questo caso esula dal suo tipico utilizzo nel campo della progettazione. Il concetto è interpretato in senso più generale come storico di collezioni di informazioni, e quindi può essere impiegato per un blog piuttosto che per atti amministrativi. Lo strato finale interviene per ricostruire l informazioni replicate e versionate presentantole agli utenti come un tutt uno, esponendo le risorse dietro ad un servizio di autenticazione single sign-on, e fornendo l ausilio di un servizio di HFN. Questo strato viene chiamato Virtual Repository (IDN- VR). Il livello è composto da 3 servizi che curano gli aspetti di aggregazione (il Virtual Repository Service nel quale il livello si identifica), autenticazione (Authentication Service) e naming (servizio di LDNS). Il livello di IDN-VR espone direttamente le IDN-API, e pertanto è anche il punto di accesso all intero stack di InterDataNet. In particolare il direttore di orchestra è il servizio che ha lo stesso nome del livello: è il Virtual Repository Service che gestisce la orchestration 11 dell intero sistema. L idea chiave di IDN-VR è la trasparenza: il consumatore di servizi del Virtual Repository non percepisce il sistema distribuito che esiste al di sotto di questo. IDN-VR ricopre infine una posizione importante per abilitare l interoperabilità con i sistemi esistenti, fornendo documenti che saranno usati dalle applicazioni legacy. In generale potranno essere necessarie routine di conver- 11 In ambito SOA la orchestration è un modo di aggregare i servizi in uno nuovo che abbia un controllo centrale sul sistema [Josuttis] 29

48 Il progetto InterDataNet Architettura tecnologica di IDN sione, ma ad esempio nel Web il servizio di virtual repository potrebbe offrire contenuti direttamente in XML (o XHTML) ad un normale Browser Web. 2.3 Architettura tecnologica di IDN Lo sviluppo dei livelli di IDN è in corso. Nel lavoro di questa tesi gli studi si sono concentrati sul livello inferiore ed hanno avuto come risultato la specifica del progetto ed una implementazione di riferimento per lo Storage (vedi capitoli 6 e 7). Questa sezione offre una panoramica dei concetti che riguardano le tecnologie ed i vari componenti dell architettura e ne illustra il funzionamento Core IDN-SA services Le funzionalità offerte da InterDataNet a supporto della collaborazione e dell organizzazione delle informazioni sono gestite grazie ad un approccio stratificato. Nei vari strati si trovano dei servizi che hanno delle funzionalità specifiche. In questa sezione verrà esaminato il funzionamento dei principali servizi di IDN. Servizi LDNS ed LS Il naming e l indirizzamento in IDN sono gestiti da due servizi distinti: il Logical Domain Name System (LDNS) ed il Localization Service (LS). Le necessità di offrire un meccanismo Human Friendly agli utenti di applicazioni, così da permettere il riconoscimento delle risorse agli esseri umani, unita all esigenza di gestire la dispersione di dati duplicati per questioni di prestazioni e scalabilità, hanno portato a formulare una soluzione su tre livelli. In particolare le funzionalità di nomenclatura, di identificazione e di indirizzamento sono state divise, ed i due servizi gestiscono la trasformazione da una tipologia all altra. È stato deciso di affrontare il problema disaccoppiando le funzionalità di trasformazione in due servizi separati per seguire le linee guida delle architetture SOA. In figura 2.5 possiamo vedere illustrato questo meccanismo. Gli utenti di IDN possono assegnare alle risorse dei nomi HFN a piacere così da poterle utilizzare in modo più pratico. Quindi per ogni risorsa 30

49 Il progetto InterDataNet Architettura tecnologica di IDN LDNS LS HFN HFN URN URL URL URL Figura 2.5: Il sistema dei nomi possono esistere più nomi HFN definiti dagli utenti, ma per l identificazione persistente delle stesse il sistema fa uso di un unica URN. Il servizio di LDNS gestisce le associazioni fra HFN ed URN, permettendo agli utenti di poter recuperare l unica URN associata ad un HFN oppure la lista di HFN che si riferiscono alla medesima URN. Data l esistenza di più copie che replicano una risorsa, non è sufficiente l identificazione tramite URN per potervi accedere. Quindi è necessario gestire un secondo livello di associazioni, questa volta tra URN ed un nome che permetta l indirizzamento. In IDN ogni localizzazione avviene tramite un URL: un URL indirizza una specifica copia di una risorsa. Il servizio LS permette al sistema di gestire la lista di URL associati ad una singola URN ed il procedimento di risoluzione inversa. Il meccanismo è traparente per gli utenti, in quanto essi si troveranno a lavorare esclusivamente con HFN. Quindi dal punto di vista delle applicazioni, un HFN svolge in IDN funzioni di indirizzamento: ogni applicazione può richiedere l accesso ad una risorsa tramite le IDN-API esposte come abbiamo visto dal Virtual Repository. È interessante far notare come il DNS (Domain Name System) svolga per gli host in Internet funzioni anloghe alla combinazione dei due servizi di gestione dei nomi in IDN: il DNS gestisce le associazioni tra nomi ed indirizzi IP, tuttavia ad un indirizzo possono essere associati più nomi ed ad un nome più indirizzi. La gestione separata in IDN è necessaria per garantire almeno in modo astratto che ogni risorsa sia univocamente identificata. 31

50 Il progetto InterDataNet Architettura tecnologica di IDN Servizio di Replica Management Le istanze dei servizi di replica management hanno l incarico di gestire l accesso concorrente alle risorse e fornire un sistema efficace di replicazione delle stesse. Da un punto di vista di coreografia 12 dei servizi, il livello IDN-RM ha come protagonista il servizio stesso di Replica Management che interagisce con LS, con altri RM, con il livello di Storage Interface ed il livello di Information History. Information History Layer Information History Service Replica Management Layer Localization Service Replica Management Service Replica Management Service Storage Interface Layer Storage Interface Service Storage Interface Service Storage Interface Service Figura 2.6: Coreografia al livello di Replica Management I legami tra i servizi sono illustrati in figura 2.6. La sequenza tipica degli eventi si svolge in questo modo [Grossi06]: 1. Il livello superiore invia richieste di accesso su base URN ad IDN-RM 2. RM ottiene la lista degli URL che sono associati alla risorsa 3. RM seleziona un URL tra quelli ricevuti secondo un qualche algoritmo 4. RM richiede la risorsa alla istanza di servizio di storage che la contiene 5. un messaggio di risposta viene inviato al livello superiore 12 In ambito SOA la choreography è il modo in cui i servizi sono aggregati per formare i processi del business definendone le regole e le politiche con cui i servizi collaborano [Josuttis] 32

51 Il progetto InterDataNet Architettura tecnologica di IDN Tuttavia il livello ricopre un ruolo importante a livello di gestione delle autorizzazioni alle risorse tra organizzazioni differenti. È previsto che per ogni organizzazione esistano uno o più servizi di RM che hanno la responsabilità di gestire gli accessi [Zappia06]. Infatti le risorse di storage dei livelli inferiori sono cotrollate da un servizio di replica. Qualora si presenti la necessità di ottenere risorse al di fuori del proprio dominio di responsabilità, è prevista la comunicazione tra pari. Sono in corso di definizione i meccanismi con i quali gestire queste interazioni, in particolare si stanno valutando protocolli con delega e come gestire l autenticazione cross-realm. L altro aspetto di cui RM si cura è la politica di propagazione delle copie ovvero come e quando effettuare una replica e secondo quale modello garantire la consistenza dei dati e dell esecuzione delle operazioni. La definizione di questi meccanismi è tuttora in fase di studio e pertanto si cosiglia di controllare il sito per ottenre informazioni aggiornate. Servizio di Information History Nello strato di Information History troviamo un unico servizio che ha il compito di fare il controllo di versione. Il servizio si chiama con lo stesso none del livello. È pensato per essere posto tra un servizio di gestione delle repliche ed uno di Virtual Repository e si comporta più che altro come un filtro che intercetta le operazioni che modificano le risorse, ne aumenta (o più in generale ne controlla) il numero di versione e tiene traccia memorizzando le differenze. Il servizio offre anche funzionalità di navigazione dello storico che non si trovano direttamente esposte sul livello sottostante. Grazie ad IDN-IH è possibile richiedere l accesso ad una risorsa nello stato in cui si trovava in un momento precedente. IDN usa UEVM (Unified Extensional Versioning Model) [UEVM99] come modello per svolgere il controllo di versione [Chini05]. UEVM è un modello che permette di gestire le versioni di documenti strutturati come DAG (Direct 33

52 Il progetto InterDataNet Architettura tecnologica di IDN Acyclic Graph) 13 con la particolarità di riuscire a versionare sia i contenuti che gli aspetti strutturali. I dati in IDN sono collegati con due tipologie di relazione: link di riferimento e link di composizione. Il documento del modello UEVM che viene versionato in IDN è strutturato da tutte le risorse tra le quali esiste un percorso di link di composizione. L orientamento del collegamento tra due risorse stabilisce una relazione di padre e figlio tra di esse. In particolare essendo il grafo aciclico ed orientato, esiste un unico nodo radice che non ha nessun padre. Il documento da versionare è visto quindi come una istantanea di risorse e delle relazioni di composizione che le legano. Due documenti UEVM distinti possono essere collegati soltanto da link di riferimento. In UEVM la modifica di una risorsa prevede la propagazione dell aggiornamento del numero di versione ai padri del nodo, quindi la propagazione risale ricorsivamente fino alla radice del documento. Revision 1 Revision 2 A v1 A A v1 v2 B v1 C v1 B B v2 v2 C v1 D v1 E v1 Update on a child resource D v1 E E v1 v2 Figura 2.7: Revisioni successive di due documenti nel modello UEVM In figura 2.7 possiamo vedere quello che succede dopo una modifica di una risorsa: il nodo figlio E viene modificato e quindi verrà creata una 13 In verità UEVM è definito per strutture ad Albero, ma può essere generalizzato ed applicato anche a DAG, ovvero grafi in cui si hanno archi orientati e non esistono cicli [Chini05] 34

53 Il progetto InterDataNet Architettura tecnologica di IDN nuova versione della risorsa che individua, differente dalla prima. Sebbene il nodo padre B rimanga inalterato nei contenuti, nella struttura subisce una alterazione poichè un suo figlio non è più lo stesso. Ed è per questo motivo che è necessario versionare il nodo padre: la versione 1 del nodo B ha infatti come figli D v1 ed E v1, la versione 2 ha invece come figli D v1 (che non è cambiato) ed E v2. È proprio questo l aspetto fondamentale di UEVM: permette di tenere traccia non soltanto dello storico delle singole risorse, ma anche la struttura che queste hanno avuto. Identity Service L architetura IDN prevede inoltre la gestione di Identità ed autenticazione. Questo aspetto è in fase di studio, si possono tuttavia fare alcune considerazioni di carattere generale. Per andare incontro ai principi delle Service Oriented Architecture, la gestione delle identità degli utenti sarà svolta da un apposito servizio. Il servizio sarà orchestrato dal Virtual Repository, e da un punto di vista logico lo si può collocare in questo livello. Tuttavia la gestione delle autorizzazioni è trasversale alla struttura, e pertanto è possibile che sia richiesta una sua interazione con tutti i livelli. Attualmente si si sta analizzando l approccio di Kerberos 14 [Zappia06] per applicare una politica di Single Sign-On e la definizione di ACL. In questa prospettiva si sono previsti due punti di accesso alle informazioni: per gli utenti tramite il layer di Virtual Repository e tramite livello di Replica Management: questo deve essere accessibile dall esterno dell organizzazione per permettere l interoperabilita fra domini diversi, ed è stato stabilito che l interazione, al di fuori del dominio, possa avvenire solo tra servizi a livello di RM. È chiaro quindi che si rende necessario un qualche meccanismo di autenticazione tra servizi di Replica, ovvero sarà necessaria una qualche certification authority che possa garantire l affidabilità delle entità in gioco. Si stanno studiando le funzionalità ed i principi che offre Kerberos a riguardo e come integrarle nell architettura di IDN

54 Il progetto InterDataNet Architettura tecnologica di IDN L informazione: IDN-IM Un Information Model può essere definito come un metodo universale per rappresentare entità in un sistema, defindendo le proprietà, le relazioni e le operazioni che su di esse si possono eseguire. È un concetto astratto, indipendente da implementazioni specifiche le quali invece supportano un Data Model, ovvero una rappresentazione concreta delle informazioni in un qualche linguaggio informatico (ad esempio XML o con classi in C++ o Java). IDN definisce le risorse con un suo Information Model (IDN- IM) che può essere adattato a data model appartenenti a contesti differenti e che quindi aumenta la scalabilità dell intera architettura. L informazione in IDN è formalizzata come una aggregazione di unità elementari chiamate Primitive Information Unit le quali contengono dati, metadati ed hanno delle relazioni con altre primitive (vedi figura 2.8, lato sinistro). Esse rappresentano i nodi del grafo di un documento IDN. Sulle relazioni tra i nodi vige una restrizione: un documento IDN-IM deve rispettare il vincolo di poter essere rappresentato con un DAG, un grafo diretto ed aciclico. È importante osservare che un albero è un caso particolare di un DAG, e quindi IDN-IM è compatibile con tutti quei documenti che sono modellati con XML o DOM. Inoltre anche la maggior parte dei database relazionali mantiene una struttura gerarchica coerente che può essere mappata almeno in un DAG. La scelta di utilizzare un DAG è un limite alla interoperabilità di IDN, tuttavia è necessaria per poter implementare politiche di controllo di versione, ed è comunque una soluzione più generale di un normale albero. In figura 2.8 è riportata la rappresentazione di due documento IDN, fatti di Primitive Data Unit aggregate con link di composizione. Si noti la presenza di un collegamento di riferimento tra due diversi documenti, e come a loro volta i nodi B e C che hanno come figlio in comune il nodo D ed individuano a loro volta dei nuovi documenti IDN. Una precisazione è dovuta: sebbene il documento IDN-IM ed il modello di documento UEVM illustrato in sembrano essere la stessa cosa (e di fatto si usa la stessa terminologia per indicare il nome dei collegamenti), ancora non è stata fatta nessuna assunzione specifica a riguardo. Infatti potrebbe 36

55 Il progetto InterDataNet Architettura tecnologica di IDN A primitive information unit Primitive Information Unit <meta> <data> + <meta> IDN Document - Doc1 Doc1 root B <meta> <data> A <meta> <data> C <meta> <data> Link Types: aggregation reference Doc2 E <meta> <data> Doc2 root <meta> IDN Document D <meta> <data> IDN Document D <meta> <data> D <meta> <data> Figura 2.8: InterDataNet Information Model esistere la necessità versionare insieme un gruppo di documenti IDN, oppure per un qualche motivo, non ci interessa tenere sotto controllo di versione l intero documento (perchè ad esempio i link di composizione raggruppano primitive di cui non è richiesto tener traccia). In conclusione, le IDN-API forniscono funzionalità per gestire documenti IDN-IM. Questo modello è pensato per funzionare in IDN-SA, ed i servizi che abbiamo esaminato in sono pensati per offrire supporto e favorire l adozione di questa architettura. Si noti tuttavia che il concetto di documento IDN-IM non è direttamente impiegato internamente nei servizi di IDN-SA, ma traspare soltando al livello più alto. In particolare, IDN può essere vista come una scatola chiusa 15 che espone le IDN-API per gestire il modello dell informazione Le interfacce verso l esterno di IDN-SA I servizi ed i livelli esaminati fino ad adesso hanno funzioni specifiche, orientate al content management oppure alla gestione di aspetti dei sistemi distribuiti. Il Virtual Repository e lo Storage Interface hanno un ruolo concettualmente diverso: essi realizzano l interoperabilità con il mondo esterno. 15 L approccio black box, vedi sezione

56 Il progetto InterDataNet Architettura tecnologica di IDN Virtual Repository Come abbiamo visto VR è il servizio che espone le IDN-API, le quali permettono di eseguire operazioni su IDN-IM. Il modello informativo è stato esaminato nel dettaglio in Si tratta di una informazione strutturata che ha le proprietà di un DAG, i cui nodi sono stati indicati con il nome di Primitive Information Unit. Questo DAG però non esiste direttamente, cioè non viene memorizzato per intero: è scomposto nelle primitive, ognuna delle quali ha un proprio nome, collegate per mezzo di una relazioni che abbiamo definito con il nome link di composizione. Il naming in IDN è globale ed indirizza i nodi del DAG. Di fatto, ogni documento si identifica con il suo nodo radice ed ogni primitiva che abbia dei figli tramite link di composizione è vista a sua volta come un documento IDN. Ogni primitiva ha inoltre un numero arbitrario di altre proprietà che descrivono caratteristiche di sistema o di utente. Il termine virtual è dovuto proprio al fatto che questo servizio offre, tramite le sue API, l accesso ad un documento che non esiste in quanto tale. Il termine repository che tradotto in italiano significa deposito, ci suggerisce che l accesso a questo documento virtuale prevede la sua memorizzazione in una struttura predisposta. La differenza importante tra un documento tradizionale pubblicato sul Web ed un documento virtuale è che in IDN avviene direttamente il riutilizzo delle informazioni: due documenti diversi possono entrambi contenere la stessa primitiva. Non è quindi necessrio copiare i dati e non si hanno i problemi che comporta la necessità di tenerli sincronizzati. Qualora per finalità di performance e scalabilità questo meccanismo sia necessario la sua gestione è delegata allo specifico servizio di Replica Management. È utile fare un esempio per spiegare questo concetto. Immaginiamo di avere due pagine Web distinte, come in figura 2.9 che contengono ad esempio i dati anagrafici di una stessa persona. Nel Web tradizionale è necessario che nell HTML di entrambi i documenti siano riportate le informazioni quali nome, cognome, indirizzo etc. e se una di queste cambia, ad esempio l indirizzo di domicilio in seguito ad un trasloco, è necessario tracciare tutte i documenti che hanno utilizzato tale informazione e provvedere a modificarla. 38

57 Il progetto InterDataNet Architettura tecnologica di IDN TO: Web Browsers TO: IDN applications Web Server Virtual Repository Service Web Doc A Bla bla bla bla bla bla bla bla bla bla bla bla bla bla bla bla bla bla bla bla bla bla bla bla bla bla bla bla bla bla bla bla bla bla bla bla bla bla bla bla FirstName LastName My address, 123 City - State Web Doc B Bla bla bla bla bla bla bla bla bla bla bla bla bla bla bla bla bla bla bla bla bla bla bla bla bla bla bla bla bla bla bla bla FirstName LastName My address, 123 City - State IDN Doc A bla A bla bla FirstName LastName My address, 123 City - State IDN Doc B B bla bla bla same information, duplicated data same information, shared data Figura 2.9: Due documenti Web (pagine HTML) e due documenti IDN (DAG IDN-IM) che rappresentano la stessa informazione Grazie alla proprietà di essere un DAG, e grazie alla global addressability a livello dei nodi, in IDN è possibile avere due documenti che condividono, ad esempio, gli stessi dati anagrafici. Per capire meglio questo esempio è utile analizzarlo nel suo conteso applicativo. I documenti presi in esempio appartengono alla categoria delle pagine HTML, che quindi hanno come ultimo fine il visualizzare sullo schermo delle informazioni che un essere umano possa leggere. Nell esempio precedente Web Page A e IDN Doc A rappresentano le stesse informazioni. È spontaneo quindi chiedersi come il documento IDN possa arrivare allo schermo di un utente di IDN. In figura 2.10 sono illustrate alcune soluzioni a questo problema. Virtual Repository è naturalmente portato per essere usato in molti modi. I documenti possono essere trasformati in pagine HTML da visualizzare sui browser grazie a processi in esecuzione su specifici server: si possono creare applicazioni IDN dentro ai moduli CGI presenti nella maggior parte dei Web Server, utilizzando linguaggi come Perl, PHP, ASP, Python, Ruby 39

58 Il progetto InterDataNet Architettura tecnologica di IDN Virtual Repository Service IDN CGI Application Web Browsers IDN Doc A bla A bla bla FirstName LastName My address, 123 City - State CGI Process: Pearl, PHP, ASP Web Doc A Bla bla bla bla bla bla bla bla bla bla bla bla bla bla bla bla bla bla bla bla bla bla bla bla bla bla bla bla bla bla bla bla bla bla bla bla bla bla bla bla FirstName LastName My address, 123 City - State Ajax XUL FLEX Silverlight IDN Rich Internet Applications SCREEN XHTML + CSS Figura 2.10: Utilizzo di Virtual Repository da parte di applicazioni IDN orientate al Web si possono realizzare applicazioni Java con servlet o JSP che possono essere installate su Web Container come Apache Tomcat Le tecnologie delle Rich internet application offrono però soluzioni alternative molto attraenti: le informazioni possono essere trasformate con tecniche Asynchronous JavaScript and XML tramite FLEX o tecnologie simili come XUL e SilverLight i documenti IDN possono essere presentati direttamente dentro ai Browser più recenti Infine, grazie all utilizzo di interfacce RESTful che permettono di accedere ad un documento IDN-IM esposto come XML si può direttamente visualizzare un documento se questo è XHTML e vi è associato un foglio di stile che ne specifica la presentazione In conclusione, Virtual Repository permette l interoperabilità verso l alto, con il Web tradizionale ed il Web 2.0. Questo servizio impersonifica IDN ed è centrale per la creazione di applicazioni basate su questa architettura così come lo è il protocollo TCP per lo stack di Internet. 40

59 Il progetto InterDataNet Architettura tecnologica di IDN Lo sviluppo di VR è ancora in una fase preliminare e ancora non è stata definita la sua interfaccia, ovvero la IDN-API. Principalmente sono stati fatti studi teorici sulle funzionalità e i requisiti per un suo utilizzo in diversi campi, dal Semantic Web [IDN07a] agli atti amministrativi [Paolucci06]. Ma tutti i requisiti dei livelli di Storage Interface e di Replica Management sono derivati da necessità di supportare gli strati superiori e per questo sono importanti gli studi svolti per la realizzazione del livello più alto. Storage Interface Lo Storage Interface al contrario Virtual Repository, gestisce l interazione verso il basso. Permettere la memorizzazione è tra le finalità di IDN: piuttosto che proporre una soluzione globale di storage, IDN definisce una API con la quale adattare le soluzioni esistenti. Il punto di vista è inverso a quello del Virtual Repository: non è tramite l esposizione di una API che si abilita l interoperabilità, ma è tramite la sua implementazione. Gli strati di IDN-SA sono pensati per poter essere costruiti sopra ad SI e non interessa come vengono salvate le risorse in realtà. La specifica di Storage Interface in IDN avviene attraverso la definizione delle funzionalità, delle operazioni e dei protocolli di accesso alle risorse di storage, ma non vi sono vincoli o requisiti che descrivono come implementare queste soluzioni se non le necessità di rispettarne l interfaccia. In particolare, le risorse a questo livello non sono né documenti IDN né primitive data unit, ma qualcosa che attraversando i livelli ha subito diverse trasformazioni. Le entità trattate da Storage Interface sono dati con associati metadati. È possibile immaginare di realizzare servizi di storage che implementano SI e che si basano su database server, su file system, su documenti disponibili nel Web. Lo sviluppo dell interfaccia e di una implementazione di riferimento viene discusso nel dettaglio nel capitolo 6 di questa tesi. Durante il lavoro di tesi è stato definito Storage Interface come un Web Service che espone una interfaccia orientata alle risorse e fornisce le capacità di operare su di esse. 41

60 Il progetto InterDataNet Architettura tecnologica di IDN Per i dettagli si rimanda al capitolo dedicato al suo progetto. Per ora è sufficiente anticipare che l interfaccia si sviluppa intorno alle operazioni base della memorizzazione persistente: creazione, modifica, lettura e cancellazione. Virtual Repository Layer Information History Layer Replica Management Layer SI API Storage Service SI API SI API SI API SI API Storage Service Enterprise Information Service Media Storage Service Social Network Service SQL database file system Enterprise Enterprise Database Enterprise Database Database Flickr YouTube social network Figura 2.11: Storage Interface e Legacy Storage Interface Implementare un servizio di storage per IDN significa sviluppare una applicazione che supporta le API definite da SI. Le proprietà definite dalle specifiche della sua interfaccia fanno sì che su tale applicazione si possa montare lo stack dei livelli superiori. In figura 2.11 si può vedere illustrata questa situazione, dove gli altri strati di IDN pongono le loro basi su una varietà di differenti servizi di storage implementati con diverse tecnologie. Legacy Storage Interface In figura 2.11 è possibile apprezzare un altro importante aspetto di SI. Tramite la sua interfaccia, è possibile utilizzare in IDN risorse create al di fuori di essa. Ad esempio, un database di una impresa che già esiste, un servizio di storage di contenuti multimediali, oppure rappresentazioni di individui ed organizzazioni di un sito di social networking. Si può pensare di rendere queste risorse disponibili in IDN sviluppando dei servizi che espongono le risorse già esistenti. Molte scelte implementative non sono scontate e la soluzione migliore per realizzare una tale applicazione dipende anche dal modo in cui si può avere 42

61 Il progetto InterDataNet Una migrazione interoperabile accesso alla fonte delle informazioni. Spesso saranno possibili più strade e non è detto che in ogni situazione si possa identificarne una migliore di altre. Sarà necessario operare delle scelte che dipenderanno da ogni caso specifico. Questo aspetto è importante poichè il panorama del Web è attualmente molto complesso e ricco di risorse che non si possono gettare via. Una qualsiasi soluzione di internetworking o una infrastruttura per il Semantic Web o per il Web of Data che abbia l ambizione di servire a tutti gli utenti del Web non può non tenerne in considerazione gli aspetti di come recuperare del patrimonio informativo pre-esistente. Storage Interface non risolve il problema in termini assoluti poichè la varietà di risorse disponibili è incontrollabilmente vasta. L obiettivo dell approccio utilizzato è favorire e facilitare la realizzazione di soluzioni per connettere i due universi. 2.4 Una migrazione interoperabile L architettura proposta da IDN realizza quindi una visione di Web of Data orientata alla collaborazione ed alla interoperabilità. I documenti sono spezzati in parti più piccole che favoriscono il loro riutilizzo grazie all indirizzamento globale ed a strumenti di supporto per l atuhoring. In particolare l approccio InterDataNet sposta gli aspetti di collaborazione orientata ai dati dal livello applicativo alla infrastruttura. IDN-SA ed IDN-IM da questo punto di vista possono essere paragonati ad HTTP ed HTML che hanno spostato nel livello infrastrutturale la gestione di documenti ipertestuali. In figura 2.12 Una adozione su larga scala di IDN porterebbe quindi alla interoperabilità a livello di dati apportando i benefici dell interdataworking. Non è tuttavia facile sviluppare soluzioni in questo ambito. Il merito della rapida diffusione dell adozione HTTP ed HTML è sicuramente da ricercare nella loro semplicità. Ma va anche detto che hanno trovato un terreno fertile in Internet che aveva appena raggiunto estensione globale. Oggi il bisogno di un Web orientato ai dati è sentito soprattutto per l avvento delle future tecnologie semantiche, ma con i suoi milioni di utenti, con la sua vastità di informazioni e con migliaia di programmi differenti, il 43

62 Il progetto InterDataNet Una migrazione interoperabile Web WWW IDN IDN applications HTML IDN-IM HTTP servers IDN-SA Virtual Repository Information History Replica Management Storage Interface file file file SI Resources Figura 2.12: Paragone tra Web e IDN Web non è un terreno che si può esplorare liberamente come lo era Internet alla fine degli anni novanta. Il costo dell interoperabilità non può essere annullato. IDN si propone come soluzione per il Web of Data che minimizza le difficoltà di interoperazione grazie all uso di concetti astratti applicabili ai modelli informativi attuali. La figura 2.13 riprende il confronto precedente illustrando come IDN si inserisce nello scenario complesso del Web attuale. In figura sono illustrate le fasi successive di questo processo a partire dal Web originale. 1. La prima fase è stata quella del Web basato su HTTP ed HTML 2. Il Web 2.0 mantiene al suo centro HTTP ed HTML 16 ma mostra una apertura nei confronti di dati più piccoli di un documento, sia concettualmente, sia tecnicamente grazie a tecnologie come XML. Nel Web 2.0 XML (o altri formati ad-hoc) è usato grazie ad Ajax dentro a documenti HTML oppure tramite i Web Service dentro a Rich Internet Application 16 Più spesso è usato XHTML che formalizza i documenti ipertestuali secondo le regole di XML 44

63 Il progetto InterDataNet Una migrazione interoperabile Web WWW WWW Web 2.0 Rich Internet Applications Web of Data WWW Rich Internet Applications XHTML + CSS IDN applications Semantic Web HTML HTML XML + data XML XML XML data data data HTML XML + data XML + data IDN Web Services IDN-IM RDF HTTP servers HTTP servers HTTP+SOAP Web Services HTTP servers HTTP+SOAP Web Services IDN-VR Virtual Repository IDN-IH Information History IDN-RM Replica Management IDN-SI Storage Interface IDN-SA file file file file file file XML XML XML data data data file file file XML XML XML data data data XML XML XML data data data SI data Figura 2.13: Dal Web al Semantic Web attraverso il Web 2.0 ed il Web of Data 3. Un Web of Data realizzato con IDN deve integrarsi con il Web ed il Web 2.0. Grazie a Storage Interface è possibile interfacciarsi alle risorse già disponibili (database, repository di XML, documenti pubblicati sul Web) e poterle riusare. A livello applicativo invece, IDN-IM gioca un ruolo centrale e abilita: lo sviluppo di nuove applicazioni la creazione di servizi che possono essere usati per interoperare con le RIA l interoperabilità con il World Wide Web le basi per un Web semantico globale Lo scenario è complesso e la figura 2.13 non pretende di esaurire l argomento. Permette però di farsi una idea delle possibilità che si prospettano e sottolinea l importanza e la necessità di far coesistere ed interoperare i sistemi. 45

64 Il progetto InterDataNet Conclusioni 2.5 Conclusioni Abbiamo visto cosa è InterDataNet: sono stati trattati i motivi per cui nasce, i concetti su cui pone le sue fondamenta, gli aspetti generali dell architettura, i servizi principali ed il modello delle informazioni su cui si basa. Si è più volte parlato di sitemi distribuiti, di SOA e di REST, ma a qualcuno può sembrare strano che nel descrivere una architettura per la collaborazione e l abilitazione del Web of Data non siano stati trattati argomenti come Web Services, WSDL oppure non sia stato citato Java. IDN è stata descritta in termini di Service Oriented Architecture che in pratica sono realizzate quasi esclusivamente con Web Service, ma la loro descrizione è astratta e permette in linea teorica molte altre soluzioni tecniche. Ad esempio è interessante il caso in cui si utilizza un approccio misto che utilizza soluzioni diverse tra livelli. Ad esempio il livello più alto di IDN può esporre un Web Service, ma può essere costruito su livelli sottostanti i cui servizi sono consumati tramite librerie locali. Non cambiano i principi di funzionamento di IDN-SA, ma le prestazioni ne risentono in positivo in quanto nei livelli inferiori non è necessario invocare servizi remoti. Nei prossimi capitoli verranno descritti aspetti teorici e pratici su cui fondare sia il progetto, sia le specifiche, sia le implementazioni dei servizi di IDN. In particolare nella seconda e nella terza parte verrà discusso nel dettaglio gli aspetti che riguardano il primo di essi: lo Storage Interface. 46

65 Parte II Analisi del servizio di Storage Interface

66 Capitolo 3 Tecnologie per IDN e Storage Interface Young man, in mathematics you don t understand things. You just get used to them John von Neumann In questo capitolo si affronteranno tematiche che riguardano le principali tecnologie di riferimento per lo sviluppo di InterDataNet e del servizio di Storage Interface. Si parlerà di Service Oriented Architecture (SOA) e di Representational State Transfer (REST) e di Web Service, WSDL, HTTP, ROA e RDF.

67 Tecnologie per IDN e Storage Interface Service Oriented Architecture Le prime due sono tecnologie astratte e riguardano aspetti teorici e stilistici: SOA e REST propongono degli stili per realizzare architetture distribuite senza scendere nei dettagli su come realizzarle. I Web Service sono lo standard di fatto per la realizzaizone di architetture in stile SOA, le Resource Oriented Architecture (ROA) invece propongono una implementazione REST che si basa su HTTP. Infine sarà trattato RDF. RDF è uno standard per la descrizione di metatadi di risorse indirizzate da URI, ed è uno dei pilastri su cui si fonda il Web semantico. 3.1 Service Oriented Architecture È difficile trovare una definizione esatta del termine SOA. Il problema non sta nel fatto che non esistono definizioni, ma che ce ne sono troppe. Analizzando le diverse opinioni 1 alla fine si scopre che tutte concordano sul fatto che SOA sia un paradigma per una migliore flessibilità. Le Service Oriented Architecture non sono architetture concrete: sono un qualcosa che conduce alla realizzazione di una architettura concreta. Si può chiamare stile, paradigma, concetto, prospettiva, filosofia o rappresentazione. È un approccio, un modo di pensare che guida le decisioni quando si progettano architetture software Motivazioni e Concetti fondamentali Lo stile SOA nasce per far fronte alla necessità di flessibilità nelle moderne architetture software. La flessibilità è necessaria per mantenere soluzioni di qualità e rispettare i tempi del mercato, ma il suo prezzo comporta di avere a che fare con delicate questioni di organizzazione dei progetti, dei processi, dei ruoli delle entità coinvolte e così via. Le SOA suggeriscono come affrontare questi aspetti, in particolare le caratteristiche difficili da gestire dei grandi sistemi come i sistemi distribuiti, 1 In [Josuttis] si trova una analisi di varie definizioni di Service Oriented Architecture apparse in articoli, libri o sul Web. Le principali fonti di riferimento sono [OasisSOA06], [Erl], [NewcomerLomow] e varie definizioni apparse su Altre definizioni si trovano su [Natis03], [Hansen] e [Weerawarana]. 49

68 Tecnologie per IDN e Storage Interface Service Oriented Architecture che appartengono a differenti proprietari e ci aiuta ad affrontare i problemi di eterogeneità. I grandi sistemi infatti usano piattaforme e linguaggi di programmazione differenti, girano su network che non sono controllati da un singolo responsabile e utilizzano ed organizzano capacità distribuite [OasisSOA06]. A differenza di altri approcci ai sistemi distribuiti, le SOA si caratterizzano perché tra i presupposti di progettazione si accetta l eterogeneità. Solitamente fino ad ora era tipico pensare di risolvere i problemi di compatibilità e d interoperabilità tra sistemi e applicazioni semplicemente adottando un unica soluzione ed eliminando le differenze ( usiamo tutti Java, usiamo tutti.net etc.), ma questi approcci, vuoi per motivi commerciali, vuoi per motivi tecnici non hanno funzionano in assoluto. L approccio SOA parte dal presupposto che l eterogeneità non si può eliminare, se poi il nostro sistema è omogeneo tanto meglio. Alla base delle Service Oriented Architecture ci sono tre concetti fondamentali: i servizi, l interoperabilità e il loose coupling. Sviluppare software significa astrarre la realtà. In informatica si può astrarre da diversi punti di vista, le SOA però, con il concetto di servizio, si concentrano sugli aspetti che riguardano l astrazione da un punto di vista del business: un servizio è una rappresentazione di una qualche funzionalità reale, come ad esempio l ordine di un cliente, e non un astrazione tecnica come la connessione a server. Conseguentemente a questo, un servizio deve essere progettato in modo che le sue interfacce possano essere comprese da chi le utilizza, dagli utenti finali, dai non addetti al settore, senza che complicati aspetti tecnici traspaiano. Il vantaggio è che a questo livello di astrazione non interessano più i dettagli dipendenti dalle specifiche piattaforme e può esserci eterogeneità tra di esse. Connettere sistemi eterogenei significa interoperabilità. Sistemi eterogenei sono interoperabili se possono funzionare insieme, ad esempio scambiandosi risorse o invocando funzioni remote. 50

69 Tecnologie per IDN e Storage Interface Service Oriented Architecture L interoperabilità richiede però che vi sia tolleranza ai guasti: infatti, in un sistema distribuito complesso è difficile garantire la robustezza 2 poiché spesso non è facile, se non addirittura impossibile, poter coinvolgere tutte le parti per le procedure di verifica e di test del sistema. Gli imprevisti sono comuni ed è necessario che vi sia tolleranza perché altrimenti anche piccole banalità potrebbero mandare in crisi l intero apparato. La chiave per raggiungere l interoperabilità è il loose coupling, in altre parole disaccoppiamento. Significa ridurre le dipendenze ai minimi termini, così che gli effetti di modifiche o imprevisti abbia meno influenza ed i sistemi possano restare operativi anche se parti di essi sono fuori uso. Il loose coupling contribuisce alla tolleranza ai guasti e alla flessibilità, e grazie ad esso la progettazione prende strade che evitano colli di bottiglia che ostacolerebbero la scalabilità. Un modo per introdurre il loose coupling è evitare la centralizzazione più di quanto non sia necessario, ma sfortunatamente almeno un po di centralità è necessaria. La progettazione di architetture SOA passa dalla pratica del loose coupling: in tabella 3.1 sono elencati alcuni esempi pratici che illustrano il concetto di disaccoppiamento. Ogni forma di disaccoppiamento tuttavia porta con sé delle controindicazioni. Per questa ragione è necessario fare scelte solo dopo un attento esame delle conseguenze e il loose coupling non dovrebbe essere mai considerato come fine a sé stante Ingredienti Per stabilire una SOA non è sufficiente introdurre servizi, interoperabilità e disaccoppiamento nella nostra architettura. È necessario trovare anche il giusto grado di centralità, aver cura dei processi, e progettare le infrastrutture. 2 La robustezza in informatica è la qualità di un sistema di resistere a situazioni impreviste non contemplate dalle specifiche. 51

70 Tecnologie per IDN e Storage Interface Service Oriented Architecture Accoppiamento Stretto Connessioni fisiche Punto-Punto Tramite mediatore Stile di Comunicazione Sincrono Asincrono Data Model Tipi complessi comuni Tipizzazione del sistema Forte Debole Pattern di interazione Controllo della logica dei processi Binding Piattaforma Transazioni Deployment Versionamento Navigazione attraverso oggetti ad albero complessi Centrale Statico Forti dipendenze da piattaforma Commit in due fasi Simultaneo Aggiornamenti espliciti Loose copling Solo tipi semplici Incentrata sui dati, messaggi autocontenuti Distribuito Dinamico Indipendente dalla piattaforma Compensazione In tempi differenti Aggiornamenti Impliciti Tabella 3.1: Esempi pratici di loose coupling È nelle infrastrutture che si rende concreto tecnicamente il concetto d interoperabilità. Nelle SOA la chiave per le infrastrutture è l Entrerprise Service Bus (ESB) che permette di invocare servizi tra sistemi differenti. Un ESB è uno strato software di astrazione basato su un sistema di messaggistica che è responsabile della trasformazione delle informazioni, del routing, del monitoraggio, del logging e ha a che fare con la sicurezza, l affidabilità, l amministrazione dei servizi e spesso anche con tecnologie di workflow e business process modeling per l integrazione dei flussi aziendali. Tutte le possibilità offerte dalle SOA si concretizzano nelle architetture, le quali formano un sistema funzionante e manutenibile. Per formalizzare un architettura si deve classificare i differenti tipi di servizi, decidere la quantità di disaccoppiamento, limitare il data model delle interfacce ai servizi, definire politiche, regole e pattern, chiarire ruoli e responsabilità, decidere l infrastruttura tecnologica e quali standard usare. Nelle architetture è necessario poi stabilire i processi appropriati. Per processo si intende una generica sequenza di passi per soddisfare una necessità 52

71 Tecnologie per IDN e Storage Interface Service Oriented Architecture o raggiungere un qualche obiettivo. Ci sono diversi processi che entrano in gioco quando si progetta e si realizza una SOA: i processi che modellano la business logic (BPM, Business Process Modeling), i processi che definiscono il ciclo di vita di un servizio (Service Lifecycle) e quelli che determinano la produzione del software per i modelli ipotizzati (MDSD, Model-driven Software Development). Inoltre, il processo di mettere insieme tutti i processi prende il nome di governance. Con questo termine ci si riferisce anche alle attività di ricerca di personale per lo sviluppo, dei sistemisti che si occuperanno della manutenzione delle macchine, dei responsabili del personale etc Terminologia Prima di analizzare più nel dettaglio il concetto di servizio è utile fare alcuni chiarimenti sulla terminologia usata nelle Service Oriented Architecture. Si usano i termini provider e consumer per indicare i ruoli dei sistemi che comunicano tramite servizi: Provider è un sistema che implementa un servizio cosicché un altro sistema lo possa invocare Consumer è un sistema che invoca un servizio Il termine partecipant, ovvero partecipante, indica sia un provider sia un consumer Si preferisce usare questi termini invece di client e server poiché sono più indicati nel contesto dei servizi SOA. Tuttavia nel caso più diffuso un provider è il server dei servizi, mentre il consumer è il client che li usa. Per choreography si intende l aggregare i servizi per formare processi che implementano la business-logic. La choreography definisce le regole e le politiche che permettono ai servizi di collaborare. Ogni servizio coinvolto vede e contribuisce solo a una parte del processo. Per orchestration si intende il comporre più servizi in uno nuovo con un controllo centrale sull intero processo. 53

72 Tecnologie per IDN e Storage Interface Service Oriented Architecture Servizi Il termine servizio ha il significato di attività svolta da qualcuno per qualcun altro. In ambito SOA un servizio è una realizzazione di una funzionalità del business con una tecnologia informatica. Il fine primario di un servizio è rappresentare un passo di una funzione del business per il mondo reale, in altre parole i non addetti ai lavori devono essere capaci di capire il suo compito e gli aspetti tecnici dovrebbero rimanere trasparenti. Esistono comunque servizi, classificati come tecnici, che non rispettano questo principio. Da un punto di vista applicativo, un servizio è un interfaccia per scambiare messaggi che restituiscono o cambiano lo stato di una qualche entità. Yefim V. Natis afferma [Natis03]: Un nome migliore per le SOA sarebbe Interface Oriented Architecture. Spesso la creazione di un architettura software basata su SOA comincia dalla definizione di un interfaccia sulla quale si costruiscono le applicazioni. I servizi possono essere caratterizzati da molti tipi di attributi, tuttavia non è chiaro quali siano obbligatori e quali opzionali per una SOA. Si può avere a che fare con servizi auto-contenuti, a grana grossa, visibili, senza stato, idempotenti, riutilizzabili, componibili. Tutte le definizioni di SOA concordano che sia una finalità di un servizio l essere auto-contenuto (indipendente, autonomo). Alcune dipendenze tuttavia non sono eliminabili quindi l obiettivo va interpretato come ridurre le dipendenze ai minimi termini, e quindi è direttamente collegato al concetto di disaccoppiamento. I servizi sono un astrazione che nasconde i dettagli implementativi all utilizzatore e spesso questo si paga con tempi di trasmissione ed elaborazione più lunghi. Per questo è meglio avere un unica chiamata al servizio che trasferisca tutte le informazioni. Una grana grossa aiuta a separare la struttura 54

73 Tecnologie per IDN e Storage Interface Service Oriented Architecture interna dei dati di un provider per servizi dalla sua interfaccia esterna ma il problema è definire quando la grana è grossa, infatti si ha spesso un elaborazione di dati che non sono necessari, con conseguente spreco di risorse e di tempo. Un altra proprietà dei servizi è la loro visibilità. Per chiamare un servizio si deve sapere che esso esiste. Un servizio stateless non mantiene traccia tra una chiamata e un altra. Un servizio può avere uno stato dal punto di vista tecnico e dal punto di vista del business. Se i servizi debbano non mantenere uno stato dipende da molti fattori e dalla situazione in cui si usano. L idempotenza è l abilità di rieseguire un operazione se non siete sicuri che questa sia stata completata. Se il servizio è idempotente, dopo una richiesta alla quale non si è ricevuto risposta di conferma, si può rimandare la chiamata senza temere che questa comporti effetti desiderati. Ci sono casi in cui ottenere l idempotenza è difficile, ma in un architettura SOA semplifica molti altri aspetti, quindi è sempre opportuno porsi l obiettivo di realizzare servizi che hanno questa proprietà. Un servizio SOA dovrebbe essere riutilizzabile. Evitare la ridondanza è un obiettivo generale dello sviluppo del software. Idealmente ogni funzionalità dovrebbe essere implementata una sola volta. Un caso tipico di riutilizzo in ambito SOA è quando tutti i sistemi chiamano lo stesso servizio per una certa funzione. Ci sono dei limiti a quest approccio che principalmente dipendono dalle esigenze di performance e quindi è opportuno individuare il giusto trade-off tra riutilizzo e prestazioni. Una funzionalità, quando necessario, può essere suddivisa in passi più piccoli che sono rappresentati da servizi. Questi possono quindi essere composti tra di loro. Questa composizione è alla base della modellazione dei processi del business. 55

74 Tecnologie per IDN e Storage Interface Web Service Inoltre, i servizi possono essere caratterizzati da attributi non funzionali come la Quality of Service (QoS), le condizioni di utilizzo possono essere vincolate da un Service Level Agreement (SLA) e possono avere un comportamento semantico specificato dalle pre-condizioni e dalle postcondizioni, Considerazioni conclusive Le SOA non sono una soluzione adottabile in ogni circostanza: il loro utilizzo è ideale quando abbiamo a che fare con sistemi distribuiti eterogenei appartenenti a organizzazioni diverse, altrimenti la complessità aggiunta potrebbe comportare un costo inutile. Nella prossima sezione esamineremo nel dettaglio i Web Service. Molte definizioni di SOA includono il termine di Web Service, ma i due concetti sono in verità autonomi. SOA è un paradigma, i Web Service sono un modo possibile per realizzare delle infrastrutture e si possono usare per creare delle Service Oriented Architecture. Anche se i Web Service stanno emergendo come lo standard di fatto per le implementazioni, si possono formulare SOA basate su molte altre tecnologie (CORBA, MQ, Tibco, ecc). 3.2 Web Service Il W3C fornisce la seguente definizione: Un Web Service è un sistema software progettato per supportare un interazione interoperabile tra macchine su reti informatiche. Ha un interfaccia descritta in un formato processabile dagli elaboratori (nello specifico, usando WSDL). Altri sistemi interagiscono con il Web Service come prescritto dalla sua descrizione, utilizzando messaggi SOAP, tipicamente trasportati con HTTP usando una serializzazione XML in congiunzione con altri standard correlati al Web. [WSArch] Più in generale il termine è usato per riferirsi ad un insieme di standard, e talvolta nei servizi SOAP non è neanche utilizzato. Questi standard definiscono sia i protocolli usati per la comunicazione, sia il formato delle interfacce usate per specificare i servizi. 56

75 Tecnologie per IDN e Storage Interface Web Service Il termine è stato coniato dalla Microsoft nel 2000 per descrivere un insieme di tecnologie di comunicazione basate su extensible Markup Language (XML) e Hypertext Transmission Protocol (HTTP). A questi due standard si è aggiunto SOAP, sviluppato inizialmente dalla stessa Microsoft, che usa XML per scambiare informazioni su una connessione basata su HTTP e TCP/IP. Grazie all apporto di IBM sono nati il Web Service Description Language (WSDL) e l Universal Description Discovery and Innovation (UDDI), e alla fine del 2000 i Web Service erano ufficialmente adottati e supportati da Oracle, HP e Sun. Oggi questo movimento è sostenuto da diverse compagnie, riunite in tre organizzazioni che curano la stesura delle specifiche: il W3C 3, OASIS 4 e WS-I 5. Esistono più di cinquanta standard specificati da queste tre organizzazioni. Il prospetto in figura offre una panoramica della moltitudine di standard che ruotano intorno a questa tecnologia. Fra tutti questi, i fondamentali sono XML, HTTP, WSDL, SOAP e UDDI: XML è usato come formato generale per descrivere i modelli e i tipi dei dati HTTP è il protocollo di basso livello usato per comunicare WSDL è usato per definire le interfacce SOAP è un protocollo specifico per scambiare messaggi UDDI è lo standard per gestire il Web Service 3 World Wide Web Consortium, è il responsabile dei principali standard dei Web Service, ovvero XML, WSDL e SOAP 4 Organization for the Advancement of Structured Information Standards, Web Service Interoperability Organization, 6 Si ringrazia Thomas Sutter per la concessione all utilizzo della figura. Il poster originale è disponibile su 57

76 Tecnologie per IDN e Storage Interface Web Service Figura 3.1: Web Services Standards as of Q by innoq 58

77 Tecnologie per IDN e Storage Interface Web Service Gli altri standard, a cui spesso ci si riferisce con il termine WS-* poiché molti hanno un nome che comincia con questa sigla, trattano aspetti di interoperabilità (WS-I Basic Profile, WS-I Basic Security Profile), specifica dei processi del business (BPEL), aspetti di sicurezza (XML Signature, XML Encryption, WS-Security, WS-Trust, WS-Federation, Web Services Security Kerberos Binding, Web Single Sign-On Interoperability Profile), affidabilità, transazioni, messaggistica, pubblicazione e sottoscrizione (WS-ReliableMessaging, WS-Reliability, WS-Coordination, WS-Transaction, WS-Notification, WS-Eventing) 7. Realizzare un servizio che possa essere definito come Web Service vuol dire adoperare alcune di queste tecnologie in fase di progettazione o implementazione. L unico standard fondamentale è WSDL tutti gli altri sono opzionali. Ad esempio non è necessario usare SOAP e nemmeno HTTP. Si comunica con un Web Service effettuando chiamate alle operazioni della sua interfaccia. La comunicazione è protocol-driven e di tipo point-to-point. Il vantaggio di una comunicazione pilotata dal protocollo è che provider e consumer possono utilizzare strumenti differenti per le chiamate al servizio. Spesso, nelle SOA, si usano Web Service intermediari per disaccoppiare tra di loro i servizi (vedi pagina 51). Questi aspetti nella pratica si amministrano tramite il WSDL: esistono 8, in tutti i più diffusi linguaggi di programmazione, strumenti o librerie che analizzando il file che descrive il servizio e generano il codice necessario a gestirne gli aspetti infrastrutturali, sia lato server che lato client. Questi strumenti si occupano delle questioni di comunicazione, così che i programmatori debbano curarsi soltanto degli aspetti di logica delle applicazioni WSDL Web Services Description Languages (WSDL) è lo standard usato per descrivere un Web Service. Come abbiamo visto in 3.1.4, un servizio è tecnicamente una interfaccia per scambiare messaggi che variano lo stato di una qualche entità oppure permettono il trasferimento di una risorsa. 7 Per una panoramica completa si veda

78 Tecnologie per IDN e Storage Interface Web Service Di fatto il WSDL è un linguaggio che descrive le interfacce di Web Service tramite la specifica delle operazioni, dei tipi di dati, dei meccanismi di trasporto e dei punti di accesso al servizio. WSDL usa una sintassi XML, ovvero un file.wsdl è un file XML conforme all XML Schema definito in oppure in e che ha una semantica definita in [WSDL1.1] o [WSDL2]. Esistono infatti due versioni importanti di questo standard: WSDL 1.1 e WSDL 2.0. La versione 1.1 è l evoluzione diretta del primo standard, lo 1.0, sviluppato da Microsoft ed IBM nel A marzo del seguente anno le stesse sottoposero le specifiche al W3C XML Activity Group, e queste furono pubblicate come W3C Note 9 con numero di revisione 1.1 ma praticamente senza nessuna modifica rilevante 10. Subito dopo, il W3C ha dedicato un gruppo di lavoro allo sviluppo di una sua versione, il WSDL 1.2, del quale la prima bozza è stata pubblicata a luglio dell anno successivo. Per le sostanziali differenze dalla versione precedente fu deciso di rinumerare lo standard come WSDL 2.0, il quale dopo un lungo travaglio, è divenuto da poco una W3C Recommendation 11, in data 26 giugno Per questo motivo, ancora, il WSDL 2.0 non gode di molta diffusione 12 e non è supportato dai più importanti strumenti di sviluppo dedicati ai Web Service. Le due versioni comunque sono concettualmente simili. La maggior parte delle innovazioni riguardano la sintassi, l estensibilità, ed il supporto a protocolli diversi da SOAP. 9 Una W3C Note è un documento reso disponibile dal W3C soltanto per discussioni. La sua pubblicazione non implica il supporto del W3C o dei suoi membri. 10 Si può trovare la specifica 1.0 all indirizzo wsdl html. La nota ufficiale del W3C [WSDL1.1] è pubblicata all indirizzo I due documenti sono praticamente identici. 11 Una W3C Recommendation è lo stage finale del processo di ratificazione di un gruppo di lavoro del World Wide Web Consortium. È equivalente alla pubblicazione di uno standard industriale. 12 Il supporto al WSDL 2.0 è rimasto escluso dall ultima versione della Java API for XML Web Services a causa dei ritardi nella sua ratificazione a raccomandazione [JAX-WS21]. La JAX-WS 2.1 è stata infatti rilasciata il 7 maggio 2007, e sebbene il supporto a WSDL 2.0 fosse tra i goals, l expert group ha deciso rimandare ad una revisione futura della API. 60

79 Tecnologie per IDN e Storage Interface Web Service Struttura e ciclo di vita Il WSDL descrive i servizi dall alto verso il basso, ovvero parte dai tipi di dati utilizzati e finisce con l indirizzo del servizio. Ci sono quattro strati nella descrizione (vedi figura 3.2): Il primo strato descrive i tipi di dati ed i messaggi Il secondo strato descrive l interfaccia del servizio, che consiste in una o più operazioni i cui parametri di input ed output utilizzano i tipi definiti nel primo strato Il terzo strato descrive il binding ovvero il legame tra protocollo e il formato con cui si forniscono le operazioni Il quarto strato definisce il punto di accesso ovvero l indirizzo con cui accedere al servizio WSDL 1.1 WSDL 2.0 definitions types message porttype operation input output binding service port description types interface operation input output binding service endpoint Abstract Section Concrete Section Java-API.NET-API C++ API PHP-API SOAP XML-RPC HTTP TCP Figura 3.2: Struttura di file WSDL 1.1 e WSDL 2.0 I primi due strati compongono la parte astratta del WSDL, gli altri la parte concreta. Sviluppare un Web Service basato su WSDL significa mappare questa parte astratta ad una API, in un qualche linguaggio di programmazione: i consumer invocheranno metodi di questa API, i provider 61

80 Tecnologie per IDN e Storage Interface Web Service invece forniranno i servizi implementando l interfaccia. Infatti la descrizione dei tipi e delle operazioni in WSDL avviene a prescindere dai linguaggi di programmazione o dai protocolli di trasporto. Nella parte concreta, i binding definiscono la comunicazione tra provider e consumer. Ci sono molti framework in diversi linguaggi di programmazione che forniscono strumenti che processano il file, generano le classi, le funzioni o le librerie nello specifico linguaggio e ne ricavano i dettagli necessari per instaurare la comunicazione. Quindi, per i programmatori di Web Service, la comunicazione diventa più una questione di configurazione che non di programmazione e molti non hanno mai a che fare direttamente con SOAP o HTTP. Infine, i servizi definiscono un elenco dei punti di accesso al quale un consumer può trovare un determinato binding dell interfaccia. Gli strati di cui è composto un documento WSDL, oltre a suddividere la sua struttura da un punto di vista logico, permettono anche di separare gli aspetti concettuali per la sua creazione. I diversi team possono occuparsi della scrittura di parti differenti del documento. Lo sviluppo del file si svolge in quattro fasi: Il primo passo consiste nello scrivere un documento che descrive l interfaccia del servizio usando soltanto i primi due livelli del WSDL. Questo lavoro è svolto sulla base dei requisiti del prodotto ed è competenza dei manager e dei responsabili di livello più alto. Il passo successivo riguarda l adeguamento della prima parte del file alle convenzioni utilizzate da altri servizi della SOA con cui integrare il prodotto. In pratica significa adottare i corretti namespace XML e ridefinire i tipi dei dati con XML Schema specifici. Questo compito è svolto dai progettisti e dagli ingegneri del software. Nel terzo passo si decidono gli aspetti infrastrutturali e pertanto entra in gioco il protocollo. In questa fase si usa la sezione dei binding del WSDL per la configurazione del servizio. Infine, al momento di installare il servizio su un server, si compila la quarta parte del WSDL con l indirizzo dell endpoint dove sarà possibile raggiungerlo. I passi del ciclo di vita sono riassunti in tabella

81 Tecnologie per IDN e Storage Interface Web Service Layer Interfaccia del servizio Interfaccia con namespace e altri dettagli Protocollo Punto di accesso WSDL 1.1 WSDL 2.0 Fase di sviluppo Ruoli di competenza <types>, <message>, <porttype> <types>, <message>, <porttype> <types>, <interface> <types>, <interface> Progetto preliminare Progetto del servizio e/o sviluppo dell'implementazione Product manager e Business manager Progettisti del servizio e/o sviluppatori <binding> <binding> Configurazione Infrastructure Team <service> <service> Deployment e runtime Amministratori del sistema Tabella 3.2: Ciclo di vita del WSDL Esempio di un servizio descritto da WSDL Per capire come funziona e come è fatto un WSDL, introduciamo un Web Service di esempio. Si ipotizza un servizio che permette la lettura e la scrittura di una generica risorsa. In figura 3.2 è riportata una rappresentazione grafica dell interfaccia di questo servizio. MyService MyInterface GetIn GetOut Error GetOperation GetIn id GetOut data meta Error info SetIn SetOut Error SetOperation SetIn id data meta SetOut Error info Figura 3.3: Esempio astratto di servizio che fornisce operazioni di lettura e di scrittura di risorse composte da dati e più metadati. Le sue caratteristiche sono: Il servizio gestisce un certo tipo di risorse 63

82 Tecnologie per IDN e Storage Interface Web Service Le risorse sono costituite da dati e da proprità (metadati). Il servizio offre due tipi di operazioni: lettura e scrittura. La lettura avviene inviando l ID della risorsa in input ed ottenendo in risposta i dati ed e le proprietà La scrittura avviene inviando l ID della risorsa insieme a dati e metadati che si vuol memorizzare Qualora si verifichi un errore, viene inviata una risposta diversa che specifica informazioni sul problema Per rappresentare le risorse e i messaggi di questo modello si utilizza XML Schema. I tipi si definiscono in un file esterno che sarà poi importato nel WSDL della sezione dei <types>. Il listato seguente illustra una possibile soluzione per la formalizzazione del data model dell esempio presentato. <?xml version="1.0" encoding="utf-8"?> <xsd:schema xmlns=" xmlns:xsd=" targetnamespace=" elementformdefault="qualified"> <xsd:complextype name="metatype" mixed="true"> <xsd:sequence> <xsd:any minoccurs="0" maxoccurs="unbounded"/> </xsd:sequence> <xsd:attribute name="name" type="xsd:string" use="required"/> </xsd:complextype> <xsd:complextype name="datatype" mixed="true"> <xsd:sequence> <xsd:any minoccurs="0" maxoccurs="unbounded"/> </xsd:sequence> </xsd:complextype> <xsd:element name="getinelem"> <xsd:complextype> <xsd:attribute name="id" type="xsd:integer" use="required"/> 64

83 Tecnologie per IDN e Storage Interface Web Service </xsd:complextype> </xsd:element> <xsd:element name="setinelem"> <xsd:complextype> <xsd:sequence> <xsd:element name="meta" type="metatype" minoccurs="0" maxoccurs="unbounded"/> <xsd:element name="data" type="datatype"/> </xsd:sequence> <xsd:attribute name="id" type="xsd:integer" use="required"/> </xsd:complextype> </xsd:element> <xsd:element name="getoutelem"> <xsd:complextype> <xsd:sequence> <xsd:element name="meta" type="metatype" minoccurs="0" maxoccurs="unbounded"/> <xsd:element name="data" type="datatype"/> </xsd:sequence> </xsd:complextype> </xsd:element> <xsd:element name="setoutelem"/> <xsd:element name="errorelem"/> </xsd:schema> Questo schema XML definisce due tipi: <xsd:complextype name= metatype > <xsd:complextype name= datatype > Insieme al tipo predefinido xsd:integer, sono usati per rappresentare le informazioni, le proprietà e gli identificatori delle risorse. Inoltre sono definiti cinque elementi che rappresentano i messaggi scambiati: <xsd:element name= getinelem > 65

84 Tecnologie per IDN e Storage Interface Web Service <xsd:element name= setinelem > <xsd:element name= getoutelem > <xsd:element name= setoutelem /> <xsd:element name= errorelem /> Il servizio, basato su questi tipi di dati, può essere descritto con WSDL 1.1 nel seguente modo: <?xml version="1.0" encoding="utf-8"?> <definitions xmlns=" xmlns:wt=" xmlns:w11=" xmlns:xsd=" xmlns:soap=" targetnamespace=" <types> <xsd:schema> <xsd:import namespace=" schemalocation="myschema.xsd" /> </xsd:schema> </types> <message name="getinmsg"> <part name="input" element="wt:getinelem"/> </message> <message name="getoutmsg"> <part name="output" element="wt:getoutelem"/> </message> <message name="setinmsg"> <part name="input" element="wt:setinelem"/> </message> <message name="setoutmsg"> <part name="output" element="wt:setoutelem"/> </message> <message name="errormsg"> <part name="fault" element="wt:errorelem"/> </message> 66

85 Tecnologie per IDN e Storage Interface Web Service <porttype name="myinterface"> <operation name="get"> <input message="w11:getinmsg"/> <output message="w11:getoutmsg"/> <fault name="geterror" message="w11:errormsg"/> </operation> <operation name="set"> <input message="w11:setinmsg"/> <output message="w11:setoutmsg"/> <fault name="seterror" message="w11:errormsg"/> </operation> </porttype> <binding name="mysoapbinding" type="w11:myinterface"> <soap:binding style="document" transport=" <operation name="get"> <soap:operation soapaction="get"/> <input> <soap:body use="literal"/> </input> <output> <soap:body use="literal"/> </output> <fault name="geterror"/> </operation> <operation name="set"> <soap:operation soapaction="set"/> <input> <soap:body use="literal"/> </input> <output> <soap:body use="literal"/> </output> <fault name="seterror"/> </operation> </binding> <service name="myservice"> <port name="soapbinding" binding="w11:mysoapbinding"> <soap:address location=" </port> </service> </definitions> 67

86 Tecnologie per IDN e Storage Interface Web Service Si noti che il file di esempio prescrive l utilizzo del protocollo SOAP per la comunicazione, e definisce come punto di accesso al servizio l indirizzo Il seguente listato riporta invece un WSDL 2.0 che descrive lo stesso servizio (stessi tipi, stessa interfaccia, stesso protocollo, stesso endpoint): <?xml version="1.0" encoding="utf-8"?> <description xmlns=" xmlns:wt=" xmlns:w20=" xmlns:xsd=" xmlns:wsoap=" xmlns:whttp=" targetnamespace=" <types> <xsd:schema> <xsd:import namespace=" schemalocation="myschema.xsd"/> </xsd:schema> </types> <interface name="myinterface"> <fault name="error" element="wt:errorelem"/> <operation name="get" pattern=" <input element="wt:getinelem"/> <output element="wt:getoutelem"/> <outfault ref="w20:error"/> </operation> <operation name="set" pattern=" <input element="wt:setinelem"/> <output element="wt:setoutelem"/> <outfault ref="w20:error"/> </operation> </interface> 68

87 Tecnologie per IDN e Storage Interface Web Service <binding name="mysoapbinding" interface="w20:myinterface" type=" wsoap:version="1.1" wsoap:protocol=" <fault ref="w20:error"/> <operation ref="w20:get" wsoap:soapaction="get"/> <operation ref="w20:set" wsoap:soapaction="set"/> </binding> <service name="myservice" interface="w20:myinterface"> <endpoint name="soapbinding" binding="w20:mysoapbinding" address=" </service> </description> Come si può vedere, la descrizione fatta con WSDL 2.0 è più snella. Nella prossima sezione saranno illustrate le differenze tra i due stantdard. Confronto tra WSDL 1.1 e 2.0 Rispetto alla edizione 1.1, WSDL 2.0 introduce modifiche alla sintassi dei documenti, apporta innovazioni per superare i limiti della versione precedente e lo standard, curato stavolta da un working group del W3C, è redatto con più precisione. Osservando il precedente esempio si notano subito le differenze sintattiche. In WSDL 2.0: L elemento di radice XML è stato rinominato da <definitions> a <description> L elemento <port> è stato rinominato <endpoint> L elemento <porttype> è stato rinominato con <interface> La sezione degli elementi <message> è stata rimossa e le operazioni adesso si riferisco direttamente ai tipi definiti in <types> Sono stati cambiati i namespace, che in WSDL 2.0 ad URI nel dominio del W3C. Il namespace principale ad esempio è cambiato da http: //schemas.xmlsoap.org/wsdl/ a 69

88 Tecnologie per IDN e Storage Interface Web Service Le altre novità introdotte sono: La nuova specifica usa XML Information Set [XMLInfoset] per definire i documenti WSDL con più precisione [Padmanabhuni07]. È stata aggiunta la possibilità di includere più documenti: un servizio può essere definito in file diversi che puntano allo stesso namespace usando un meccanismo di inclusione. WSDL 2.0 aggiunge nuovi pattern per lo scambio di messaggi [WSDL2adjuncts], ed il meccanismo adesso è estensibile. È stato introdotto il supporto per l ereditarietà di interfacce: una interfaccia può essere definita come estensione di altre (ereditarietà multipla) [Moreau04]. In WSDL 1.1, quando in servizi differenti si utilizza la stessa operazione, è necessario replicarla in tutti i file in cui si usa. In WSDL 2.0, grazie alla ereditarietà, le operazioni sono riutilizzabili. WSDL 2.0 è adesso estendibile anche per gli attributi. Come è possibile vedere confrontando gli esempi precedenti, la specifica dei binding è stata semplificata [Padmanabhuni07]. Il binding SOAP supporta ora nativamente il binding con la versione 1.2 [WSDL2adjuncts] (in WSDL 1.1 è stato aggiunto tramite una estensione esterna allo standard che è però supportata oramai da molti framework per Web Service). Lo standard è stato rilasciato insieme alla specifica del binding su HTTP [WSDL2adjuncts]. Questo permette la convergenza tra Web Service e RESTful Service [Orchard05] [Chinthaka07] [Haas05] Questo ultimo punto sarà approfondito nel prossimo paragrafo. Estensione per il binding su HTTP di WSDL 2.0 Per client che interagiscono con risorse remote, il Representational State Transfer e le Resource Oriented Architecture (vedi sezione 3.3 a pagina 76) sono divenuti velocemente un alternativa ai Web Service, specialmente perché non richiedono l uso e la comprensione di SOAP. 70

89 Tecnologie per IDN e Storage Interface Web Service Tuttavia si sta tentando di far convergere i due mondi, così che i Web Service possano applicare i concetti del REST e godere dei benefici delle ROA e viceversa [Chinthaka07]. La specifica per il binding con HTTP di WSDL 2.0 [WSDL2adjuncts], si muove a supporto di questa convergenza. Le ROA [RichardsonRuby] sono orientate alle risorse, usano HTTP per il trasporto e sono tecnicamente semplici da sviluppare, ma lasciano la gestione di molti aspetti nelle mani dello sviluppatore e non offrono supporto per gestire l affidabilità, l integrità, QoS, etc. I Web Service sono orientati ai servizi, sono indipendenti dal protocollo e sono progettati per essere estendibili, ma la maggior parte usa SOAP e l estensibilità ha portato a una proliferazione di standard nella quale è difficile orientarsi. Entrambi i modelli hanno punti di forza e punti deboli. Sotto questo punto di vista, il binding HTTP di WSDL 2.0 è importante perché permette di definire le interazioni con i servizi usando le operazioni base di HTTP: GET, POST, PUT, DELETE ma anche HEAD, OPTIONS o i metodi estesi da WebDAV [RFC2518]. I messaggi sono trasferiti tramite una serializzazione direttamente nella start-line, negli header e nel body di una richiesta ed una risposta HTTP [RFC2616]. Grazie a queste possibilità offerte dal binding su HTTP, è possibile specificare con WSDL un servizio che rispetta le regole e i principi delle ROA. Il seguente listato mostra le modifiche per l esempio in con le quali è possibile realizzare una implementazione ROA dell interfaccia: <?xml version="1.0" encoding="utf-8"?>... <binding name="myrestbinding" interface="w20:myinterface" type=" <fault ref="w20:error" whttp:code="500 Internal Server Error"/> <operation ref="w20:get" whttp:method="get" whttp:location="{wt:id}"> <operation ref="w20:set" whttp:method="post" 71

90 Tecnologie per IDN e Storage Interface Web Service whttp:location="{wt:id}" whttp:inputserialization="application/x-www-form-urlencoded"/> </binding> <service name="myservice" interface="w20:myinterface"> <endpoint name="soapbinding" binding="w20:mysoapbinding" address=" <endpoint name="restbinding" binding="w20:myrestbinding" address=" </service> </description> Il codice mostrato implementa l interfaccia del nostro esempio su HTTP. L uso di questa estensione è indicato dal valore dell attributo type dell elemento <binding>. L esempio ci dice che il servizio è disponibile all endpoint org/myservice/rest. Una tipica interazione request-response per la lettura della risorsa con identificatore 123 potrebbe essere la seguente: GET myservice/rest/123 HTTP/1.1 Host: example.org HTTP/ Ok Content-Type: application/xml Content-Length: 106 <meta name="date"> </meta> <meta name="author">cristiano</meta> <data> Hello World! </data> L esempio seguente invece mostra i messaggi HTTP in seguito ad un errore di scrittura. 72

91 Tecnologie per IDN e Storage Interface Web Service PUT myservice/rest/124 HTTP/1.1 Host: example.org Content-Type: application/xml Content-Length: 106 <meta name="date"> </meta> <meta name="author">cristiano</meta> <data> Hello again! </data> HTTP/ Internal Server Error Content-Type: text/html Content-Length: 22 An error has occurred! Nell estensione HTTP, la serializzazione delle informazioni distingue tra metodi senza corpo del messaggio (GET, DELETE, etc.) e metodi con corpo (POST, PUT, etc.). Nei primi, tutti i parametri devono essere serializzati nell URI della richiesta. Questa opzione comporta limiti sui contenuti accettati perché deve essere rispettato lo schema dell Uniform Resource Identifier. Un messaggio serializzabile nell URI di una richiesta deve essere un complex- Type XML che contiene una unica <xsd:sequence>, i cui figli sono derivati da xsd:simpletype [Chinthaka07]. Per gli altri metodi, la serializzazione è più flessibile, e permette di specificare sia una serializzazione nel corpo della richiesta (inputserialization= application/xml), sia un approccio misto con parte dei parametri dentro la URI e parte dentro il body (inputserialization=application/x-www-formurlencoded). In aggiunta, alcuni parametri possono essere serializzati negli header della richiesta e della risposta. 73

92 Tecnologie per IDN e Storage Interface Web Service SOAP SOAP è il primo standard dei Web Service ad essere stato espressamente sviluppato per questi. Originariamente era acronimo di Simple Object Acess Protocol tuttavia SOAP si è dimostrato essere tutt altro che semplice e non riguarda l accesso agli oggetti. Di conseguenza nella versione 1.2 il nome non è più usato come acronimo. Qualcuno lo interpreta oggi con il significato di Service Oriented Architecture Protocol [WSArch], ma sebbene spesso in una SOA si usi SOAP, la dizione non è ufficializzata da nessuno standard anzi, le SOA sono concettualmente astratte e non prescrivono l uso di nessuna particolare tecnologia, standard o protocollo. Le versioni di SOAP esistenti sono la 1.1 e la 1.2, tuttavia non ci sono differenze significative e sono invisibili a chi sviluppa Web Services in modo ordinario. In sé SOAP non è un protocollo difficile ed ha come scopo principale far comunicare due parti che conoscono poco l una dell altra scambiandosi messaggi in XML. Il trasporto è delegato principalmente ad HTTP, ma si può usare anche con SMTP, il protocollo di Internet per il trasferimento di posta elettronica. Un messaggio SOAP in genere consiste di due parti, riunite nella cosiddetta envelope. Le due parti sono il body, obbligatorio, che contiene il messaggio vero e proprio, e l header, facoltativo, che contiene informazioni per instradare il messaggio o di sicurezza. L envelope non contiene l indirizzo del destinatario: questo compito spetta al protocollo che trasporta il messaggio. Ad esempio l indirizzo sarà un URL se il messaggio SOAP è trasportato da HTTP, invece sarà un indirizzo se si usa come protocollo di trasporto SMTP. Il seguente esempio, preso dalle specifiche ufficiali [SOAP1.2], mostra un tipico messaggio: <env:envelope xmlns:env=" 74

93 Tecnologie per IDN e Storage Interface Web Service <env:header> <n:alertcontrol xmlns:n=" <n:priority>1</n:priority> <n:expires> t14:00:00-05:00</n:expires> </n:alertcontrol> </env:header> <env:body> <m:alert xmlns:m=" <m:msg>pick up Mary at school at 2pm</m:msg> </m:alert> </env:body> </env:envelope> Il principale inconveniente con SOAP è che il parsing di XML e l overhead da esso introdotto, rappresentano un collo di bottiglia, spesso insormontabile, alle prestazioni del sistema [TanenbaumSteen]. A questo inconveniente si cerca di ovviare grazie a standard come il Message Transmission Optimization Mechanism [MTOM], che usa XMLbinary Optimized Packaging [XOP] per offrire una serializzazione MI- ME Multipart/Related [RFC2112] dei messaggi SOAP, ma gli strumenti più utilizzati oggi per costruire web Service offrono ancora poco supporto a questi standard Conclusioni Decidere se utilizzare o no i Web Service, significa analizzare e comparare i benefici con gli sforzi richiesti e i problemi che si portano con sé contestualmente alla soluzione ricercata per un problema specifico. Le alternative per abilitare le SOA senza i Web Service implicano però o l uso di soluzioni proprietarie oppure il fare tutto da soli, da zero, e costruirsi strumenti ad-hoc per realizzare servizi interoperabili, e può diventare molto difficile se abbiamo a che fare con sistemi eterogenei. Si noti anche che spetta a noi decidere quali dei vari standard WS utilizzare, e ad esempio si potrebbe usare WSDL soltanto come formato per definire le interfacce, ma usare propri protocolli per implementarle. 75

94 Tecnologie per IDN e Storage Interface Representational State transfer In questo caso WSDL è utile più che altro come linguaggio di modellazione delle interfacce da utilizzare in fase di progettazione. Ciò non toglie che sopra a un WSDL ben definito si possa costruire a posteriori un Web Service, adottando gli altri standard WS uno per volta quando necessario. Anzi, le pratiche di sviluppo di SOA con i Web Service suggeriscono di non adottare aspetti specifici degli standard finché i dettagli non entrano davvero in gioco [Josuttis]. Ad esempio si può specificare un interfaccia con WSDL senza dire niente su come chiamare i servizi, oppure si può adoperare BPEL 13 per modellare il workflow senza usare nessun altro protocollo specifico. Inoltre, grazie agli strumenti di sviluppo disponibili, potrebbe addirittura essere banale implementare un servizio pienamente funzionante partendo da un WSDL. Nella prossima sezione sarà discusso il Representational State Transfer (REST): intorno a questo stile sono nate le Resource Oriented Architecture, che non si basano sugli standard WS-*. I filosofi delle SOA spesso criticano la mancanza di aspetti di sicurezza, di componibilità e così via [Josuttis], tuttavia i suoi principi possono essere rilevanti quando si tratta di offrire a sistemi esterni l accesso a dati o risorse. 3.3 Representational State transfer Diversamente a quanto avviene per il termine SOA ed il termine Web of Data, il Representional State Transfer, a cui ci si riferisce con l acronimo REST, ha una origine ed una definizione riconosciuta e legittimata, ed è nel capitolo cinque della tesi di dottorato di Roy T. Fielding, pubblicata nel 2000 [Fielding]. Tuttavia, il termine è stato misinterpretato da molti ed usato erroneamente in molti contesti, e non è immediato farsi una idea chiara del suo significato in questa giungla di opinioni. 13 Business Process Execution Language, è un linguaggio basato su XML per orchestrare servizi in Web Service composti o procedurali. Gli ambienti di sviluppo permettono di disegnare graficamente i file BPEL. 76

95 Tecnologie per IDN e Storage Interface Representational State transfer Il REST è uno stile per architetture software che Roy T. Fielding ha definito nella sua tesi. È lo stile del Web, ed infatti è nato durante la stesura del protocollo HTTP di cui Fielding è coautore [RFC2616]. Il REST un modello astratto, ed il Web è una architettura concreta che si basa sui principi di questo modello. Questo modello è definito da un insieme di vincoli architetturali, che applicati ad un sistema lo rendono RESTful: il Web è RESTful non soltanto perché rispetta questi vincoli, ma perché è il caso specifico dal quale sono stati dedotti i principi per definire il modello. Il primo vincolo che una architettura RESTful deve rispettare è l interazione tra componenti di tipo client-server. Il sistema è fatto di componenti classificati come server, che offrono servizi e rimangono in ascolto di richieste, oppure client, i quali fruiscono dei servizi e utilizzano un connettore per inviare richieste. Il concetto di connettore in REST è un elemento che incapsula le attività di accesso alle risorse e di trasferimento delle loro rappresentazioni. Il secondo vincolo del REST è l assenza di stato della interazione clientserver. Questo concetto è spesso frainteso, poiché anche un servizio o una risorsa possono avere uno stato, ma il REST pone questo vincolo specificatamente sulla comunicazione: ogni richiesta da parte di un client deve contenere tutte le informazioni necessarie affinché possa essere compresa, e non può trarre vantaggio da contenuti memorizzati nel server. Lo stato della sessione è quindi mantenuto interamente nel client. L applicazione di questo principio migliora la visibilità, poiché una interazione che contiene tutte le informazioni può essere più facilmente monitorata, ed incrementa l affidabilità e la scalabilità del sistema. L overhead introdotto dalla ripetizione dei dati può però portare ad un peggioramento delle prestazioni. Per migliorare l efficienza dei sistemi, in REST si sua il concetto di cache, ovvero un client, per richieste ripetute, può usare una risposta memorizzata in precedenza, eliminando così la necessità di alcune interazioni. Questo vincolo richiede che i dati di una risposta siano etichettati come cachable o non-cachable, implicitamente o esplicitamente. L architettura primordiale del Web era definita dall insieme di vincoli clientcache-stateless-server. Quello che distingue il REST da altre architetture basate sul networking, è il vincolo di interfaccia uniforme tra componenti. 77

96 Tecnologie per IDN e Storage Interface Representational State transfer Questo principio disaccoppia le implementazioni dalle funzionalità, semplifica il sistema e migliora la visibilità delle interazioni, ma degrada l efficienza poiché le informazioni sono trasferite in una forma generalizzata piuttosto che in una forma specificatamente progettata per i bisogni applicativi. Una interfaccia uniforme è efficiente per la trasmissione di ipermedia a grana grossa. Questo principio impone ulteriori vincoli sulle interfacce di un sistema RESTful, nelle quali si deve avere identificazione delle risorse e la loro manipolazione deve avvenire tramite una rappresentazione. Una risorsa è una qualsiasi informazione dotata di nome: un documento, un immagine, un oggetto non virtuale (una persona, un animale, una città). In REST si usano resource identifier per identificare particolari risorse coinvolte nelle interazioni tra i componenti del sistema, i quali compiono azioni su di esse usando una resource representation per catturarne lo stato. Una rappresentazione in REST è una sequenza di byte più una sequenza di metadati che descrivono questi byte. Un architettura REST è stratificata. Questo permette di adattare i sistemi ai requisiti di scalabilità dei grandi network come Internet. La stratificazione permette alle architetture di essere composte di layer gerarchici, così da disaccoppiarne i componenti e promuovere l indipendenza tra stati non adiacenti, ed i vari strati possono incapsulare servizi legacy od offrire nuovi servizi ai client pre-esistenti. D altro canto, la stratificazione incrementa la complessità dei sistemi, aggiunge overhead ed aumenta la latenza nell elaborazione dei dati. L ultimo vincolo che Fielding aggiunge al ad un sistema REST deriva dallo stile code-on-demand, per il quale un sistema RESTful permette di estendere le funzionalità scaricando ed eseguendo nuove istruzioni in forma di applet o script. Questo vincolo è opzionale, perché permette di estendere le funzionalità limitate dal vincolo di interfaccia uniforme, ma riduce la visibilità del sistema. Questo termine è stato usato spesso per descrivere una tipologia di servizi Web non basati su SOAP, ma come abbiamo visto il REST non prescrive l uso di particolari protocolli o standard e non specifica quali operazioni deve offrire una interfaccia, purché questa sia uniforme e sia orientata alle risorse. 78

97 Tecnologie per IDN e Storage Interface Resource Oriented Architecture Il REST assomiglia di più alle Service Oriented Architecture che non ai Web Service. Nella prossima sezione saranno prese in esame le Resource Oriented Architecture, che come vedremo sono una implementazione di questi principi. 3.4 Resource Oriented Architecture Nel panorama dei Web Service, RESTful è stato usato come aggettivo per classificare una tipologia di servizi basati su un approccio che usa i metodi di HTTP per eseguire operazioni remote, in contrapposizione all approccio tipico che usa WSDL 1.1, SOAP e Java, considerati da molti difficili da usare e da imparare 14. Questi servizi hanno riscosso un discreto interesse ultimamente, soprattutto da parte di sviluppatori orientati alla realizzazione di servizi di largo consumo per il Web, e quindi non interessati alla costruzione di complessi sistemi enterprise. L origine di questa categorizzazione è dovuta alla natura di HTTP, che rappresenta l esempio di riferimento di interfaccia uniforme, così come richiesto dallo stile REST. Ma molti servizi etichettati come RESTful non rispettano gli altri vincoli di questo stile. I puristi di questa filosofia non esitano a definirli servizi accidentally RESTful, servizi low REST o REST-RPC. In questo panorama confuso, si sono inserite le Resource Oriented Architecture (ROA). Le ROA, presentate da Leonard Richardson e Sam Ruby nel libro RESTFul Web Service [RichardsonRuby], prescrivono delle linee guida per realizzare architetture RESTFul concrete. Gli autori adottano questo termine per designare architetture che rispettano i principi del RE- ST, ma mentre quest ultimo specifica solo criteri di progettazione generici, le Resource Oriented Architecture sono esplicitamente legate alle tecnologie del Web. Nelle ROA le risorse sono indirizzate da URI e l interfaccia uniforme utilizzata è HTTP. 14 Su questo concordano i sostenitori di entrambi gli approcci, vedi Big Web Service Are Not Simple su [RichardsonRuby] e Am I Stupid or Is Java Web Services Really Hard? su [Hansen] 79

98 Tecnologie per IDN e Storage Interface Resource Oriented Architecture Gli URI in questo contesto, devono essere descrittivi, ovvero deve esistere una corrispondenza intuitiva tra questi e le risorse che indirizzano, e devono essere strutturati. La strutturazione dei nomi permette ai client di costruire gli indirizzi delle risorse alle quali desiderano accedere. Ci sono tre regole base per progettare gli URI : Si usa il path per codificare la gerarchia (es. /parent/child) Quando non esiste gerarchia si usa la punteggiatura (es. //parent/child1;child2) Si utilizzano le query per le variabili che rappresentano l input di un algoritmo (es. /search?q=jellyfish&start=20) Nelle ROA ci sono solo poche operazione base che si possono eseguire su una risorsa, e queste sono definite dal protocollo HTTP : Con HTTP GET si recupera la rappresentazione di una risorsa HTTP POST serve per creare nuove risorse Si modificano le risorse utilizzando HTTP PUT HTTP DELETE cancella le risorse Le ROA considerano parte dell interfaccia uniforme anche i metodi HTTP HEAD e HTTP OPTIONS. Il vantaggio di questa interfaccia è che il metodo GET è safe, quindi una richiesta che utilizza questo metodo non cambia nessun stato nel server. Sia GET che PUT e DELETE godono della proprietà di idempotenza : un operazione idempotente su una risorsa fa si che inviare una richiesta sia equivalente all invio di una molteplicità di richiesta identiche. La seconda richiesta e le seguenti lasceranno la risorsa esattamente nello stato in cui lo ha lasciato la prima. La safety e l idempotenza sono importanti perchè permettono ai client di fare richiesta HTTP affidabili in network che non lo sono. La POST non è né safe né idempotente. 80

99 Tecnologie per IDN e Storage Interface Mappa delle tecnologie L approccio ROA si propone come alternativa semplice ai ben più complessi Web Service basati su SOAP, ma le funzionalità offerte coprono tutti gli aspetti necessari ai sistemi più complessi e molto lavoro è lasciato nelle mani del programmatore. Si sta assistendo ad una timida convergenza delle due tecnologie [Vinoski07], in particolare le nuove specifiche dei WSDL supportano la definizione delle interfacce su HTTP in stile ROA [Chinthaka07], e forse in futuro si potranno estendere alcuni standard dei Web Service anche ai servizi sviluppati con questo stile. 3.5 Mappa delle tecnologie Start Here Figura 3.4: Mappa delle tecnologie per erogare servizi nel web. Nei precedenti paragrafi abbiamo preso in esame le varie tecnologie utilizzabili nella realizzazione di servizi Web. Per orientarsi meglio in quest area, è opportuno puntualizzare quali sono le tecnologie che si escludono a vicenda. 81

100 Tecnologie per IDN e Storage Interface Resource Description Framework Il seguente elenco presenta le principale scelte che si presentano al progettista di un sistema distribuito di questo tipo: SOA vs. Distributed Objects (ovvero si sceglie la granularità del sistema) REST vs. RPC (ovvero si sceglie tra approccio alle risorse o approccio alle procedure) HTTP vs. SOAP (ovvero si sceglie quale protocollo usare) In particolare un approccio SOA non esclude che i servizi possano essere realizzati come ROA, ed il protocollo SOAP può essere usato con uno stile REST. Infine, il WSDL può essere applicato in tutti i percorsi ed il suo uso può rendere interoperabili differenti protocolli. La figura 3.4 rappresenta una mappa delle strade che si possono percorrere in quest area. 3.6 Resource Description Framework RDF è un linguaggio sviluppato dal World Wide Web Consortium per standardizzare l uso dei metadati. Si basa su XML ed insieme ad esso è fondamentale per il Semantic Web poiché fornisce dei meccanismi più adatti allo sviluppo di linguaggi per rappresentare ontologie. Il data model di RDF è infatti pensato per fornire una descrizione standard delle risorse Web ed è orientato all interpretazione da parte di elaboratori. Oltre alla descrizione, RDF è usato anche per definire relazioni tra risorse. RDF definisce una risorsa come un oggetto che sia univocamente identificabile grazie a Uniform Resource Identifier. Può essere qualcosa come una pagina web, una canzone, una persona o un altra entità. Il framework permette di creare nuove relazioni che aggiungono alle risorse primitive di modellazione predefinite. Con queste si esprime la semantica dei dati senza la necessità di fare nessuna assunzione. Lo standard definisce come 82

101 Tecnologie per IDN e Storage Interface Resource Description Framework referenziare i metadati, come definirne il loro nome ed come specificarne il contenuto. Le risorse hanno delle proprietà associate ad esse. Le proprietà sono identificate da tipi e i tipi hanno un valore corrispondente. I tipi esprimono le relazioni dei valori associati alle risorse. La struttura base di RDF è semplice e di base usa delle terne di espressioni che rappresentano soggetto, predicato, oggetto di una relazione: Soggetto: qualcosa identificato dal suo URI Predicato: il tipo di metadato anch esso identificato da un URI (chiamato anche Proprietà) Oggetto: il valore del suddetto metadato Non ci sono altri costrutti sintattici oltre alle triple ed ogni documento RDF è equivalente ad un insieme non ordinato di queste. Ci sono diverse forme per esprimerle, e quella che usa XML è la più comune. subject, predicate, object Creator Cristiano Resource Property Type Property Value Figura 3.5: Cristiano created the InterDataNet home page L esempio in figura 3.5 descrive la seguente affermazione usando una tripla RDF: Cristiano created the InterDataNet home page. La home page di InterDataNet è una risorsa, la quale ha come URI ed ha una proprietà, creator, con valore Cristiano. 83

102 Tecnologie per IDN e Storage Interface Resource Description Framework Il grafico rappresentato in figura si esprime in XML con il seguente statement: <?xml version="1.0" encoding="utf-8"?> <rdf:rdf xmlns:rdf=" xmlns:dc=" <rdf:description about=" <dc:creator>cristiano</dc:creator> </rdf:description> </rdf:rdf> La prma linea di questo esempio usa un namespace per definire esplicitamente il significato delle nozioni specificate. Il primo namespace, si riferisce al documento che descrive la sintassi RDF. Il secondo namespace, si riferisce alla descrizione del Dublin Core (DC), una semplice ontologia su autori e pubblicazioni. Il Dublin Core 15 è un insieme di 15 elementi che rappresentano metadati sviluppati originariamente per favorire la scoperta di risorse nel web. Dublin Core definisce metadati per descrivere ad esempi: Titolo della risorsa Il soggetto trattato Una breve descrizione dei contenuti Il creatore ovvero l autore L editore

103 Tecnologie per IDN e Storage Interface Resource Description Framework Il seguente esempio mostra uno scenario realistico di utilizzo dei metadati del DC. Si può osservare che più di una coppia predicato-valore può essere indicata per una risorsa. <?xml version="1.0" encoding="utf-8"?> <rdf:rdf xmlns:rdf=" xmlns:dc=" <rdf:description about=" <dc:creator>cristiano</dc:creator> <dc:title> InterDataNet The next generation of information and data networking </dc:title> <dc:subject> InterDataNet, SOA, REST, Web Of Data, Storage, Service </dc:subject> <dc:description> Definition of the IDN architecture for the Web of Data </dc:description> <dc:contributor>davide, Mariachiara, Samuele</dc:Contributor> </rdf:description> </rdf:rdf> L esempio esprime il creatore, il soggetto, il titolo, la descrizione ed i contributori della risorsa RDF schema Uno dei problemi di RDF è che si può usare per specificare predicati binari per una risorsa, ma non si può dire a quali tipi di dati si applicano e quali relazioni ci sono tra di essi. Ad esempio, si potrebbe voler dire che il creator del precedente esempio è una persona. RDF Schema (RDFS) colma questa lacuna fornendo un sistema per definire tipi da usare con RDF. 85

104 Tecnologie per IDN e Storage Interface Resource Description Framework Grazie a RDFS si possono costruire modelli di oggetti da assegnare alle risorse, con i quali definirne il significato reale. Gli elementi RDFS permettono di affermare che una risorsa appartiene ad una classe o ad una sottoclasse, in maniera simile a come avviene nei linguaggi di programmazione orientati agli oggetti. La dichiarazione di un tipo avviene con lo statement rdfs:class mentre con rdfs:subclassof si dichiara una specializzazione. L appartenenza di una risorsa ad un tipo avviene con il predicato rdf:type, ed è possibile definire che una risorsa è una istanza di più classi. Una proprietà RDFS può essere vista come un attributo di una classe. Si definiscono le proprietà di una classe con lo statement rdfs:property. A differenza di come avviene linguaggi orientati agli oggetti, nei quali le classi contengono le proprietà nella loro definizione, in RDF Schema queste vengono attaccate dinamicamente per mezzo del predicato rdfs:domain. Con questo si indica la classe in cui questa proprietà può essere usata. Con il predicato rdfs:range invece si specificano i valori che questa proprietà può assumere. Nel seguente esempio si mostra come grazie si può usare RDF Schema per dichiarare la classe che definisce il tipo Person : <?xml version="1.0" encoding="utf-8"?> <rdf:rdf xml:lang="en" xmlns:rdf=" xmlns:rdfs=" <rdfs:class rdf:id="person"> <rdfs:comment>the class of people.</rdfs:comment> <rdfs:subclassof rdf:resource=" </rdfs:class> <rdf:property ID="universityRole"> <rdfs:range rdf:resource="#universityrole"/> <rdfs:domain rdf:resource="#person"/> </rdf:property> <rdf:property ID="age"> <rdfs:range 86

105 Tecnologie per IDN e Storage Interface Resource Description Framework rdf:resource=" <rdfs:domain rdf:resource="#person"/> </rdf:property> <rdfs:class rdf:id="universityroletype"/> <UniversityRoleType rdf:id="professor"/> <UniversityRoleType rdf:id="researcher"/> <UniversityRoleType rdf:id="phd Student"/> <UniversityRoleType rdf:id="student"/> </rdf:rdf> Nell esempiola è dichiarata la classe Person che possiede le proprietà age ed universityrole. La prima ha valori numerici che appartengono agli interi, la seconda ha un valore che è una istanza della classe UniversityRoleType. Riassumendo, grazie all uso di classi, proprietà e valori, RDF Schema permette di definire risorse ed il loro tipo. RDFS è tecnologicamente avanzato in confronto a RDF poiché fornisce un modo per costruire un modello per oggetti dal quale i dati attuali sono referenziati e che ci dice cosa significano in realtà, e in questo si avvicina ai linguaggi per le ontologie. Per capire meglio le potenzialità di RDFS, si riportano i principali elementi del vocabolario definito nello standard [RDFSchema]: rdfs:resource Tutte le cose descritte da RDF sono chiamate risorse e sono istanze della classe rdfs:resource. Ogni altra classe è una sottoclasse di questa. rdfs:resouece a sua volta è una istanza di rdfs:class. rdfs:class È la classe delle risorse che sono classi in RDF. Ricorsivamente, rdfs:class è una istanza di rdfs:class. 87

106 Tecnologie per IDN e Storage Interface Resource Description Framework rdfs:literal È la classe dei valori letterali come le stringhe e gli interi. I valori di proprietà come stringhe testuali sono un esempio di rdfs:literal. rdfs:literal è una sottoclasse di rdfs:resource. rdfs:datatype rdfs:datatype è la classe dei tipi di dati. Tutte le istanze di rdfs:datatype corrispondono al modello descritto in [RDFConcepts]. rdfs:datatype è sia una istanza che una sottoclasse di rdfs:class. Ogni istanza di rdfs:datatype è una sottoclasse di rdfs:literal. rdf:xmlliteral È una classe di valori XML. rdf:xmlliteral è una istanza di rdfs:datatype e sottoclasse di rdfs:literal. rdf:property È la classe delle proprità. rdf:property è una istanza di rdfs:class. rdfs:range È una istanza di rdf:property usata per affermare che il valore della proprietà è una istanza di una o più classi. Ad esempio la tripla: P rdfs:range C afferma che P è una istanza di rdf:property, che C è una istanza della classe rdfs:class e che le risorse che compaiono come oggetto in una tripla in cui il predicato è P sono istanze della classe C. La proprietà rdfs:range si applica alle proprietà. rdfs:domain È una istanza di rdf:property usata per affermare che ogni risorsa a cui è stata data questa propriteà è una istanza di una o più classi. Ad esempio la tripla: P rdfs:domain C afferma che P è una istanza di rdf:property, che C è una istanza della classe rdfs:class e che le risorse che compaiono come soggetto in una tripla in cui il predicato è P sono istanze della classe C. 88

107 Tecnologie per IDN e Storage Interface Resource Description Framework rdf:type È un istanza di rdf:property usata per affermare che la risorsa è una istanza di una classe. Una tripla nella forma: R rdf:type C afferma che C è una istanza di rdfs:class e che R è una istanza di C. rdfs:subclassof La proprietà rdfs:subclassof è usata per affermare che tutte li istanze della classe sono anche istanze di un altra. Una tripla nella forma: C1 rdfs:subclassof C2 afferma che C1 è una istanza di rdfs:class, C2 è una istanza di rdfs:class e che C1 è una sottoclasse di C2. La classe rdfs:class è transitiva. rdfs:subpropertyof La proprietà rdfs:subpropertyof è usata per affermare che le tutte risorse che possiedono una proprietà ne possiedono anche un altra. Ad esempio la tripla: P1 rdfs:subpropertyof P2 afferma che P1 è una istanza di rdfs:property, P2 è una istanza di rdfs:property e che P1 è una sottoproprietà di P2. La proprietà rdfs:subpropertyof è transitiva. rdfs:label È una proprietà che può essere usata per fornire un nome humanreadable della risorsa. rdfs:comment È una proprietà che può essere usata per fornire una descrizione humanreadable della risorsa. 89

108 Capitolo 4 Scenari applicativi For a successful technology, reality must take precedence over public relations, for Nature cannot be fooled. Richard Feynman In questo capitolo verranno analizzati e discussi alcuni possibili scenari applicativi per il servizio di Storage Interface. Questo studio non solo ha il fine di illustrare dove un simile servizio possa trovare interessi applicativi, ma serve anche per valutare quanto le tecnologie finora illustrate possano soddisfare esigenze pratiche che si incontrano in contesti reali. Il servizio di Storage Interface nasce per offrire una funzionalità di interfacciamento alla memorizzazione dei dati per InterDataNet, l architettura descritta nel capitolo 2. L approccio stratificato di IDN in particolare pone

109 Scenari applicativi questo servizio nel livello più basso: infatti le sue funzioni separano la logica degli altri servizi dalla implementazione pratica delle infrastrutture che memorizzano informazioni e quindi getta le fondamenta per costruire gli altri livelli. In questo capitolo, si è tenuto conto di questa impostazione nelle rappresentazioni grafiche riportate, spostando idealmente verso il basso il servizio. L impiego di SI in IDN permette di interfacciare la Service Architecture a sistemi eterogenei di storage, e disaccoppia gli altri servizi dalla necessità di avere una memoria interna persistente, la quale può risultare difficile da coordinare in grande un sistema distribuito. Tuttavia SI è un servizio di una SOA, e pertanto deve essere progettato quantomeno per essere riutilizzabile. Il riutilizzo è uno dei motivi dello studio presentato in questo capitolo: siccome in tutti gli scenari si usa l interfaccia di SI per memorizzare dati, allora tra di essi è possibile scambiare informazioni è questo favorisce l interoperabilità. Un altro aspetto è però forse più importante: l analisi teorica degli scenari ha permesso un attento studio delle funzioni che SI può offrire e grazie a questo si è potuto progettare un servizio più solido e versatile. Da questa analisi deriva lo studio dei requisiti che verrà formalizzato nel capitolo 5. Di particolare importanza sono gli ultimi due scenari, presentati in 4.6 ed in 4.7. Il primo tratta gli aspetti di interoperabilità ed è fondamentale per IDN, come discusso in L altro, ultimo scenario di questo capitolo, è l anello che ricongiunge con la prima parte che abbiamo affrontato: in questo scenario si analizza il funzionamento di Storage Interface nel contesto di InterDataNet, ovvero il suo funzionamento insieme al Replica Management service. Ogni scenario sarà strutturato in 4 parti: verrà presentata una panoramica per introdurre il contesto analizzato, dopo il quale sarà considerato più nel dettaglio il ruolo del servizio di storage. Verrà infine presentato un elenco degli aspetti più importanti e delle conseguenze. 91

110 Scenari applicativi Storage di immagini con dati Exif 4.1 Storage di immagini con dati Exif Exchangeable image file format è una specifica per formati di file immagine, usata nelle fotocamere digitali per descrivere l informazione con metadati [Exif2002]. Exif, questa è l abbreviazione ufficiale, associa all informazione grafica dati come le impostazioni di scatto (apertura, uso del flash, bilanciamento del bianco, etc.), il modello della fotocamera, il nome dell autore ed altro. Le specifiche definiscono quali tag 1 sono supportati e come codificarli all interno del file. Alcune di queste informazioni sono utilizzate per ottimizzare la stampa di fotografie digitali, spesso in maniera automatica in quanto riconosciute direttamente dai software di controllo. Altre sono invece usate per fini di catalogazione, archivio o per semplice curiosità. Tutte le più importanti applicazioni che gestiscono immagini digitali oggigiorno sono capaci di leggere e mostrare all utente questo set di metadati. Le applicazioni Web raggiungono l obiettivo grazie ad una elaborazione lato server, che estrapola dal file le informazioni e le rende disponibili per l utente all interno di una pagina HTML o con apposite API 2. Si ipotizza uno scenario in cui un Servizio Web di Storage fornisca accesso elementare ad un set di primitive per abilitare la consultazione di immagini e metadati Exif associati. Tale servizio può trovare impiego in un generico contesto di Rich Internet Application (RIA), in cui può essere usato per realizzare ad una applicazione in stile Web 2.0, un generico programma a interfaccia grafica per desktop o un semplice sito Web dinamico. In figura 4.1 sono illustrati i diversi approcci alle RIA. A sinistra troviamo i più leggeri (progettati per i browser), verso destra i più impegnativi [Stearn07]. La figura mostra le differenti tecnologie che entrano in gioco nei differenti approcci. Alla base di questo, ci sono i backend service: per backend service si intende un servizio esterno che fornisce accesso, aggrega e permette il consumo di risorse remote. 1 I metadati dell immagine sono chiamati col nome di tag nel testo dello standard Exif 2 Per esempio o imageshack.us/ 92

111 Scenari applicativi Storage di immagini con dati Exif Web site Browser based Ajax, Flex, OpenLaszlo Hybrid XULRunner Desktop based Rich Client platform Generic Application GUI HTML Markup languages Programming languages Interpreted Business Logic Compiled Browser Application framework Virtual machine Environment CGI Storage Interface API Backend services Storage Interface implementation for images repository File System RDBMS... Figura 4.1: Storage Interface per immagini con Exif in uno scenario Rich Internet Application (derivata da [Stearn07]) Ruolo di SI Il servizio di storage nel contesto di una RIA si colloca tra i backend services. Si tratta di servizio riutilizzabile che fornisce funzioni comuni di memorizzazione persistente, che può essere composto con altri servizi per essere integrato in una qualche architettura SOA. Il servizio favorisce l interoperabilità poichè presenta la stessa interfaccia per accedere alle immagini ed ai loro metadati Aspetti rilevanti Risorse che contengono una immagine Metadati associati all immagine Accesso, consultazione e ricerca di metadati 93

112 Scenari applicativi Storage di MIME type con associati metadati Conseguenze per SI Esporre primitive che permettono l accesso ad una risorsa Esporre primitive per la gestione dei metadati 4.2 Storage di MIME type con associati metadati Si può pensare ad una generalizzazione del caso precedente, in cui si trattano generici Internet media type, conosciuti come Mime type, piuttosto che file per immagine soltanto. Motivazioni simili hanno portato alla definizione dello standard WebDAV, Web-based Distributed Authoring and Versioning [RFC2291]. WebDAV definisce delle estensioni di HTTP che permettono all utente di gestire in modo collaborativo file in un server remoto. L esigenza di trattare metadati deriva dalla necessità di poter associare ad una risorsa informazioni di sistema quali data di creazione e modifica, proprietario, diritti di accesso ed altro. Il versionamento, che nell attuale implementazione di WebDAV non è ancora supportato, avrebbe comportato la necessità di gestire ulteriori metadati come ad esempio stato, revisione, lock, autore. L impossibilità di definire a priori un insieme esaustivo, ha comportato come requisito la necessità di gestire in modo generalizzato quelle che in Web- DAV sono definite proprietà: in [RFC2518], HTTP Extensions for Distributed Authoring, sono definiti nuovi metodi come PROPFIND e PROPPATCH che permettono l accesso e la modifica delle proprietà. WebDAV pone altri requisiti: la possibilità di eseguire operazioni di copia, spostamento e rinominazione, la gestione di collezioni, collegamenti, sicurezza e versionamento. Per gestire file di dimensioni significative, è prevista inoltre la possibilità di accesso parziale alle risorse. La gestione di collezioni comporta la necessità di visualizzarne liste dei contenuti, di crearle e cancellarle, aggiungervi e rimuovere risorse. 94

113 Scenari applicativi Storage di MIME type con associati metadati Business Processes Choreography Distributed Authoring and Versioning Orchestration Service Collections Service Security Service Versioning Service Services Layer Storage Storage Interface Interface API API Storage Interface API Storage Storage Interface Interface Storage Service Service Service Figura 4.2: Versioning Ambiente SOA per abilitare il Distributed Authoring and Si ipotizza quindi uno scenario in cui un servizio web con funzionalità comparabili a quelle fornite da WebDAV fornisce accesso a risorse distribuite. Progettandolo come una SOA, si può pensare alla necessità di separare la business logic in più servizi separati: oltre al servizio di memorizzazione, si può immaginare la necessità di servizi per per gestire le collezioni, la sicurezza ed il controllo di versione, nonchè di un servizio che orchestra il sistema. Come si può vedere in figura 4.2, più servizi con diverse funzionalità vengono aggregati e consumati per formare l architettura per questa soluzione Ruolo di SI Il servizio di storage interviene quando si ha l effettivo accesso ai dati. SI gestisce il transito dell informazione memorizzata nella risorsa, nonché dei metadati associati. Potrebbe essere opportuno gestire altri aspetti quali collezioni, sicurezza e revisioni tramite opportuni servizi distaccati. 95

114 Scenari applicativi Storage per ambiente distributo Aspetti rilevanti Publishing di media type Proprietà arbitrarie Accesso parziale SI come basic data service di una SOA Conseguenze per SI Le risorse necessitano un mime type specificato Necessità di gestire metadati in coppie nome/valore Indirizzamento ed accesso a parti delle risorse 4.3 Storage per ambiente distributo Qualora le risorse esposte dal nostro servizio di storage abbiano la necessità di poter essere raggiunte tramite una interfaccia tipo File System distribuito, entrano in gioco importanti vincoli che devono essere considerati in fase di progettazione. Un File System distribuito si compone di due parti [TanenbaumSteen]: Storage Service e Directory Service. Il Directory Service offre funzioni di raggruppamento, e in questo è simile al concetto di collezione del precedente scenario. In più serve offre il controllo accessi e naming. Lo Storage Service di un file system può adottare due modelli di funzionamento. Nel Modello upload/download il file system fornisce soltanto due operazioni principali: lettura e scrittura La risorsa è trasferita per intero nelle due direzioni, pertanto il modello è di semplice realizzazione ed utilizzo. Tuttavia si ha un forte spreco di risorse nel caso di file di grosse dimensioni che necessitano di essere modificati in piccola parte. Nel Modello ad accesso remoto invece vi sono operazioni per aprire e chiudere i file, leggerne e scriverne parti e navigare il loro contenuto (seek). Il directory service è indipendente dal modello usato per lo storage service. 96

115 Scenari applicativi Storage per ambiente distributo Un altra caratteristica tipica dei file system distribuiti è la replicazione. Abilitare la replicazione comporta vantaggi e problemi da affrontare: se da un lato affidabilità, disponibilità e prestazioni beneficiano dall utilizzo di una strategia di diffusione di più repliche, da l altro entrano in gioco fattori difficili da gestire quali la trasparenza e la consistenza. In genere la trasparenza è soltanto per l utente e la consistenza è gestita da processi specifici. Questi aspetti quindi non comportano complicazioni particolari per gli aspetti di memorizzazione. Il nostro Storage Service ben si presta a realizzare uno Storage Service di un file system distribuito. In una soluzione basata sulle SOA, il servizio può essere affiancato da altri che gestiscono aspetti specifici come il raggruppamento in directory e la replicazione. Per un modello ad accesso remoto diventa fondamentale la necessità di accesso parziale. In figura 4.2 è illustrata la coreografia di questo scenario. Business Processes Choreography Distributed File System Orchestration Service Directory Service Replication Service Services Layer Storage Storage Interface Interface API API Storage Interface API Storage Storage Interface Interface Storage Service Service Service Figura 4.3: Ambiente SOA per File System distribuito 97

116 Scenari applicativi Memorizzazione di informazioni strutturate Ruolo di SI Implementa uno Storage Service secondo un modello upload/download o ad accesso remoto Aspetti rilevanti Accesso remoto Directory service separato da storage service Replicazione Più livelli di gestione dei nomi Conseguenze per SI Supporto per accesso a grana fine (modello accesso remoto) 4.4 Memorizzazione di informazioni strutturate Le future esigenze di memorizzazione di informazioni, con l avvento di tecnologie per l espressione di semantica per la machine-to-machine interoperability, alimentano sempre più la necessità di gestire informazioni strutturate. Nelle applicazioni le strutture dati utilizzate sono le liste (array, stack, code, linked list), alberi, grafi generici [CormenLeisersonRivest]. Questi ultimi sono i più complessi da gestire. In conseguenza della larga diffusione di XML, HTML, DOM, le strutture ad albero sono invece le più comuni, ma non hanno la stessa capacità espressiva di un qualsiasi grafo. Un caso particolare di grafi sono quelli orientati ed aciclici (DAG) 3, che sono simili ad alberi, ma ogni nodo può avere più di un padre. Quindi gli alberi sono un sottoinsieme dei DAG. Molti degli algoritmi applicabili a strutture dati ad albero possono essere estesi anche a grafi orientati aciclici, e questa proprietà li rende una alternativa interessante. 3 Direct Acyclic Graph 98

117 Scenari applicativi Memorizzazione di informazioni strutturate Dal punto di vista del nostro servizio di storage, vi sono vari approcci che si possono utilizzare per supportare strutture di dati a priori incognite. Un primo approccio, che può essere visto come l analogo del modello upload/download dei file system, prevede che il servizio fosse capace soltanto di leggere e scrivere una risorsa per intero: in tal modo la strutturazione è trasparente e non comporta ulteriori requisiti di progettazione. Un secondo approccio può utilizzare il servizio per memorizzare esclusivamente i nodi delle strutture: se da un lato questo non comporta requisiti addizionali per la memorizzazione, da un altro lato la gestione delle relazioni comporta invece la necessità di memorizzarle ed associarle alle risorse e fornire funzionalità di navigazione dei nodi. Un approccio Service Oriented Architecture potrebbe suggerire la realizzazione di due servizi distinti per assolvere questi compiti. Il servizio di Storage potrebbe assolvere a funzioni di memorizzazione di relazioni come metadati delle risorse, eventualmente adottando le specifiche RDF (vedi capitolo 3.6 a pagina 82). Un secondo specifico servizio potrebbe invece assolvere le funzioni di navigazione della struttura. In figura 4.4 si è voluto mettere in evidenza i ruoli dei servizi ipotizzati per questo caso. Una terza possibilità è integrare funzionalità di navigazione delle risorse nel servizio di storage stesso: questa possibilità presenta analogie col modello ad accesso remoto dei file system in quanto si crea la necessità di gestire con opportune primitive le operazioni di apertura e chiusura di una risorsa, accesso in lettura e scrittura dei nodi e delle relazioni, navigazione ed algoritmi di visita. Il problema principale di questo approccio è che una soluzione generale valida per ogni tipo di struttura potrebbe risultare difficilmente realizzabile: le funzionalità di navigazione generiche risulterebbero potenzialmente complesse da definire o la soluzione sarebbe di poco aiuto. Se le strutture fossero specificatamente implementate con XML (o l information model sia con esso compatibile) vi sarebbe la disponibilità di standard diffusi e conosciuti quali XPath ed XQuery, che potrebbero usati per offrire la navigazione delle strutture dati e mantenere allo stesso tempo il servizio entro i limiti della filosofia delle SOA. 99

118 Scenari applicativi Memorizzazione di informazioni strutturate Business Processes Choreography Structured Data Authoring Orchestration Service navi-gation data nodes Data Browser Service Services Layer Storage Storage Interface Interface API API Storage Interface API Storage Storage Interface Interface Storage Service Service Service relations Figura 4.4: Servizio di Storage e di Data Browsing per l authoring di informazioni strutturate Vista la diffusione di XML e derivati, un approccio misto in cui l interrogazione tramite XQuery sia attuabile a livello di Servizio di Storage qualora la risorsa sia di tipo XML (inteso come MIME type) potrebbe essere comunque sufficiente a garantire la copertura della stragrande maggioranza dei casi in cui il servizio può trovare impiego. Esistono anche metodi che generalizzano l impiego di XQuery per l accesso di informazioni non-xml [Robie07]: implementare un supporto di XQuery a livello di interfaccia del servizio apre quindi nuove strade che possono essere sufficienti ad assolvere ai requisiti richiesti ed abilitare interoperabilità con un vasto numero di sistemi Ruolo di SI In questo scenario lo Storage Service assolve il compito di memorizzare le informazioni strutturata. Sono rilevanti le differenze sulle modalità di funzionamento a seconda dell approccio che si vuole implementare. 100

119 Scenari applicativi Storage per il Web orientato ai dati In particolare in IDN è stato deciso di affrontare i problemi della strutturazione delle informazioni ad un livello superiore (nel livello di Virtual Repository) e pertanto SI segue il primo degli approcci qui presentati. Tuttavia i requisiti di SI potranno specificare come opzionali le funzionalità viste nel secondo e terzo approccio, purchè non vadano contro gli altri principi descritti Aspetti rilevanti Informazione strutturata Navigazione interna o esterna al servizio Diversi approcci per lo storaging (singoli nodi o intere strutture) Diffusione di XML e standard derivati Estensibilità di XQuery a non-xml Conseguenze per SI Accesso upload/download Soluzione con gestione di relazioni e compatibilità con RDF Soluzione con gestione di strutture e compatibilità con XML È possibile che sia necessario fornire primitive per la visita Eventuale uso di XQuery 4.5 Storage per il Web orientato ai dati Con l avvento di tecnologie orientate alla semantica ed alla interoperabilità macchina-macchina, ci stiamo spostando dal modello di Web of documents ad un modello di Web of data and programs [Bratt05]: il Web semantico ed i Web Service. In un Web non più orientato al documento, la questione cruciale per i sistemi di memorizzazione diventa la granularità con cui le informazioni diventano accessibili ed indirizzabili. 101

120 Scenari applicativi Storage per il Web orientato ai dati Nel Web un documento è indirizzato da una propria URL ma grazie all uso dei fragment, si possono indirizzare anche parti di un una pagina HTML. I metodi di accesso alle risorse però agiscono solo ad un livello più alto: HTTP traferisce infatti l intera pagina e non è possibile richiedere il traferimento di un suo frammento. Quindi nel Web si possono indirizzare risorse ad un livello più fine di quello a cui si può operare. In verità, quando una pagina contiene una immagine, questa è trasferita separatamente: una immagine è caratterizzata da un URL proprio e non da un frammento dell URL della pagina che la contiene. A differenza del frammento, l immagine può essere riutilizzata in due o più diverse pagine Web, oppure può essere considerata essa stessa come documento. Anche i frame HTML funzionano in questo modo, ma questa tecnologia ha non è stata apprezzata e non ha avuto diffusione per via di diversi problemi di compatibilità con la maggior parte dei browser 4. Si osservi inoltre che il sito Web ha un suo indirizzo e che spesso coincide con il nome dell host che lo ospita, e che la home page che viene mostrata per default in realtà ha un suo indirizzo. Quindi nel Web l indirizzamento avviene a 3 livelli: sito, pagina, frammento. In figura 4.5, lato sinistro, è mostrato come avviene l accesso e l indirizzamento di risorse nel Web. In un Web orientato ai dati potrebbe essere necessario operare più in profondità nel documento. Si pensi ad esempio a due pagine che contengono la stessa informazione, e che la si voglia riutilizzare nei due documenti come con le immagini nel Web tradizionale. È necessario individuare il giusto compromesso tra risorsa indirizzabile e risorsa accessibile ed ogni entità a cui si intende accedere deve avere un proprio URL. In figura 4.5, lato destro, è illustrato un servizio di storage che come il Web permette di operare su una risorsa soltanto in blocco. In questo caso una operazione di lettura traferirà l intera risorsa ed una operazione di modifica comporterà l invio anche delle parti che non sono state cambiate. Questo modo di funzionare è simile al modello upload/download dei file system distribuiti che è stato illustrato in 4.3. Si osservi infine che un servizio

121 Scenari applicativi Storage per il Web orientato ai dati Host name Web server HTTP Web Page Service Endpoint Storage Interface API Accessible resource GET POST PUT DELETE <html> #section Fragment read update... Addressable resource part Figura 4.5: Accesso ed indirizzamento per HTTP e per un Web Service di storage è indirizzato da un URL che specifica il suo endpoint, così come un sito web è indirizzato dal nome del dominio su cui risiede. La scelta del giusto livello di indirizzamento ed accesso ha a che fare direttamente con il tipo di risorse che il servizio di Storage Interface può trattare. Se lo si usa nel Web of Data è ovvio che non ha senso memorizzare una pagina html per intero. Tuttavia la granularità delle informazioni trasferite dipende dal contesto in cui ci troviamo: se nel Web il tipico documento traferito è una pagina HTML che può talvolta essere molto corposa, in un ambito più generico come una SOA basata sui Web Service, un documento può essere memorizzato scomposto in frammenti, i quali avranno un proprio URL, che saranno poi ricomposti da un apposito Web Service o da una Web Application. In questo modo il progettista può ottenere il livello di accesso e di indirizzamento desiderato. Il costo è che per offrire un documento classico si dovrà aggiungere uno strato tra il browser Web ed il servizio di storage. Un ulteriore passo in avanti nella formalizzazione di un meccanismo per l accesso ai dati ce lo suggerisce WebDAV. Con questo protocollo, grazie ai metodi PROPFIND e PROPPATCH, sulle proprietà si può operare 103

122 Scenari applicativi Storage per il Web orientato ai dati individualmente, senza dover trasferire l intera risorsa. Si può ad esempio leggere il contenuto di un singolo metadato con una chiamata del metodo PROPFIND alla risorsa, specificando il nome della proprietà. Quindi in WevDAV l accesso ai dati è più fine rispetto al Web tradizionale. In figura 4.6 è illustrato un servizio di storage che come WebDAV offre la possibilità di lavorare su metadati associati ad una risorsa. Service Endpoint Storage Interface API Accessible resource meta-read meta-update read update Accessible metadata Addressable resource part Figura 4.6: Accesso ed indirizzamento per metadati di una risorsa Ruolo di SI Dall analisi di questo scenario emerge che Storage Interface può a tutti gli effetti essere usato come repository per il Web of Data, e che la differenza con il Web tradizionale è il target a cui il servizio è rivolto Aspetti rilevanti Indirizzabilità ed accesso non sempre corrispondono Livelli di indirizzamento di URL: sito, documento, frammento Grana di accesso del Web of Data Layer intermedio tra Web of Data e Browser Web 104

123 Scenari applicativi Interoperabilità con sistemi legacy Livelli di accesso di WebDAV: risorsa e metadati di risorsa Conseguenze per SI Serve una operazione di ricombinazione per poter offrire una pagina HTML È necessario trovare il giusto equilibrio tra indirizzamento ed accesso Il servizio ha un suo indirizzo Le risorse hanno un indirizzo proprio L indirizzo di un dato deve essere un URL completo I browser Web non sono il target diretto di SI Si deve poter accedere ai metadati singolarmente 4.6 Interoperabilità con sistemi legacy Un aspetto importante per garantire l interoperabilità riguarda l integrazione del servizio di storage con i sistemi legacy. Per armonizzare l etereogenità dei sistemi esistenti è necessaria una interfaccia comune per il servizio di storage che possa essere costruita sopra le applicazioni esistenti. Principalmente i problemi che possono insorgere dipendono dai requisiti di memorizzazione del sistema che vogliamo interfacciare. Infatti, se il servizio di storage permette la memorizzazione di informazioni generiche, ciò non è vero per sistemi legacy che si può aver bisogno di rendere interoperabili e sorge il problema di come gestire questa discordanza tra le strutture dati. Ad esempio un database ha solitamente una struttura molto rigida ed il tipo di informazioni memorizzabili è fortemente tipizzato. Se pensiamo ad un database relazionale, su cui si realizza una interfaccia di storage legacy, è ovvio che su di esso non sarà possibile memorizzare un qualsiasi tipo MIME come nello scenario visto in 4.2. Diventa anche impossibile gestire arbitrari metadati da associare alla risorsa. 105

124 Scenari applicativi Interoperabilità con sistemi legacy Per gestire questo problema si possono pensare 3 diversi approcci. In un primo caso, si può prevedere un meccanismo di verifica della conformità delle informazioni immesse: è necessario che il servizio implementi un meccanismo per validare il tipo di risorsa che viene creata o subisce una modifica, così da rifiutare risorse che non è possibile memorizzare nel sistema sottostante. In questi casi, potrebbe essere necessario un meccanismo per informare l utilizzatore su cosa è accettato. Una prima discriminazione può essere gestita con i MIME type, tuttavia la conformità ad un tipo non ci permette di discernere tra risorse valide per una generica struttura dati. Inoltre i MIME type sono definiti e controllati in numero chiuso da IANA 5, la Internet Assigned Numbers Authority, e non rappresentano tutte le possibili strutture dati. I MIME possono essere casomai utili per sistemi legacy che memorizzano internamente un qualche tipo di file. Se la risorsa è XML potrebbe essere interessante supportare una validazione basata su XML Schema poichè permette soluzioni più articolate che in alcune situazioni possono portare a risolvere i problemi di consistenza. Ad esempio un database ha solitamente una struttura che può essere rappresentata con questo meccanismo e pertanto può essere usato per garantire la conformità con una qualche struttura dati XML. Eventualmente potrebbe essere richista una trasformazione, ad esempio con XSLT, per poter adattare le informazioni tra i due sistemi, e pertanto l implementazione potrebbe dover svolgere procedure di conversione per raggiungere questo obiettivo. Una seconda soluzione prevede che il servizio di storage si prenda carico di gestire il surplus informativo qualora questo non sia conforme. Nel caso di un di un servizio per interoperare con un database legacy, si può pensare ad affiancare un nuovo supporto di memorizzazione per abilitare la trattazione di ogni possibile risorsa immessa. In questo caso però le nuove informazioni non potranno essere consultate sui vecchi sistemi, quindi questa soluzione potrebbe essere valida soltanto per situazioni in cui si applica una migrazione morbida che porta all abbandono dei vecchi sistemi

125 Scenari applicativi Interoperabilità con sistemi legacy Infine una variante del primo caso potrebbe essere quella in cui l arbitrarietà di memorizzazione è permessa soltanto ai metadati di risorsa. In questo modo il sistema può continuare ad associare informazioni arbitrarie, ma per la risorsa rimane il vincolo di dover essere validabile e compatibile con i sistemi legacy. I tre casi sono schematizzati in figura 4.7. valid data Storage Interface API Legacy Storage Service #1 any data any data Storage Interface API Legacy Storage Service #2 valid data any meta data Storage Interface API Legacy Storage Service #3 storage old storage new storage storage metadata metadata metadata Legacy system Legacy system Legacy system Figura 4.7: Interoperabilità con sistemi legacy: possibili soluzioni implementative Il primo caso corrisponde al disegno di sinistra in figura 4.7, contrassegnato con la lettera A. Soltanto i dati validi possono entrare ed essere memorizzati poiché si usa direttamente lo storage del sistema legacy. Il secondo caso corrisponde al disegno centrale, contrassegnato con la lettera B. Questa volta è ammessa in ingresso una qualsiasi risorsa, purché conforme al modello informativo di SI. Il surplus informativo è gestito da nuove basi di dati o da file system non-legacy. Ovviamente queste informazioni non saranno disponibili per i vecchi sistemi. Il terzo caso corrisponde al disegno a destra, contrassegnato con la lettera C. Soltanto i dati validi possono entrare ma si accettano metadati arbitrari e le informazioni immesse saranno compatibili con i vecchi sistemi. I metadati 107

126 Scenari applicativi Interoperabilità con sistemi legacy possono essere usati per descrivere le nuove proprietà che i sistemi basati su SI utilizzano per il loro funzionamento. Si osservi che questi approcci offrono soluzioni quando si ha la necessità di memorizzare. Non è necessario approntare questi meccanismi (e non è necessario dover scegliere tra una delle tre possibilità) qualora si intenda usare SI per interfacciare un sistema legacy in sola lettura o si preferisca usare un normale servizio di storage a fianco di uno per i sistemi legacy per la memorizzazione. È interessante infine osservare che il solo servizio di storage potrebbe non essere sufficiente a fornire tutte le altre funzionalità necessarie per abilitare l interoperabilità con sistemi legacy. Per esempio se il nuovo sistema deve poter gestire funzioni per il lavoro collaborativo come il locking o il versioning, potrebbe essere richiesto lo studio di un sistema più complesso, in cui a fianco del servizio di storage compaiono servizi specifici per questi altri aspetti, ed ognuno ha un livello di interazione specifico con le strutture legacy. Per il controllo di versione ad esempio si rende necessario tracciare ogni modifica di una risorsa: il servizio di storage può memorizzare le varie copie, ma quando una di queste subisce una modifica è complicato recuperare lo stato precedente. Pertanto potrebbe essere necessario interfacciare i sistemi legacy anche con il servizio di versioning, in modo da copiare le risorse ogni volta che queste subiscono modifiche dall esterno. In figura 4.8 è riportato uno scenario esempio di questo tipo Ruolo di SI Si usa l interfaccia di SI per implementare servizi di storage Legacy. Qualora sia necessario accedere alle risorse in scrittura è necessario decidere come operare sui dati in ingresso. In InterDataNet si richiede quantomeno la possibilità di memorizzare metadati arbitrari, poichè anche per gestire risorse valide per i sistemi legacy, è necessario potervi associare delle proprietà che servono al sistema per la gestione di queste. Pertanto in IDN sarà usata almeno la soluzione descritta nel terzo caso. I requisiti di SI potranno specificare come opzionali le 108

127 Scenari applicativi Interoperabilità con sistemi legacy New SOA Layer Legacy Layer Orchestration Service Service for Versioning of legacy resources Service for Replication of legacy resources Storage Interface API Legacy Storage Service Legacy system metadata metadata metadata storage Figura 4.8: Interoperabilità con sistemi legacy funzionalità delle altre ipotesi, purchè non vadano contro gli altri principi descritti. L interfaccia garantisce soltanto l interoperabilità a livello di storaging e potrebbe non essere sufficiente per interfacciare completamente le vecchie risorse Aspetti rilevanti SI come API che può essere usata per interfacciare sistemi legacy Diverse possibilità di utilizzo, a seconda dei requisiti di interoperazione Esigenze diverse per interoperare con livelli superiori a seconda dei fini applicativi Metadati predefiniti per Storage Interface e per i sistemi legacy 109

128 Scenari applicativi Servire il Replica Management di IDN Conseguenze per SI I servizi di storage legacy necessitano di funzionalità non-si e non note a priori per interoperare Alcuni sistemi possono essere interfacciati soltanto se si abilita la validazione delle risorse trattate SI potrebbe dover supportare XML Schema, XSLT o altri meccanismi di validazione/trasformazione tipizzazione delle risorse di SI tramite metadati specifici 4.7 Servire il Replica Management di IDN Nella service architecture di InterDataNet è previsto che il livello più basso si occupi di questioni di storage. L informazione subisce trasformazioni nel passare dal livello applicativo ai livelli sottostanti. Il livello di Storage Interface è l ultimo, e deve poter memorizzare dati e metadati così come ricevuti dal livello di Replica Management. In figura 4.9 è mostrato l architettura IDN, in particolare è evidenziato come l informazione si trasforma nel passaggio di livello in livello. Replica Management può usare più servizi di Storage Interface per gestire le copie delle informazioni di IDN. In linea di principio, SI dovrà memorizzare una trasformazione di una primitive information unit dell Information Model che durante la discesa sarà stata arricchita di informazioni di versionamento, di naming e di localizzazione. Attraversando lo stack di IDN-SA verso il basso, ogni livello aggiungerà dei nuovi metadati di servizio con i quali svolgere le sue funzioni. In particolare ogni livello in genere arricchisce con proprie Service Metadata le User Data e la User Metadata ricevute dal livello superiore. Con User Data e Metadata si intendono le informazioni che ogni livello riceve dall alto. Con Service Metadata si intendono le informazioni che hanno origine nel livello. Nel processo inverso è molto probabile che per garantire la trasparenza questi metadati saranno rimossi. 110

129 Scenari applicativi Servire il Replica Management di IDN Application Layer Application Application Virtual Repository Layer Virtual Repository Service Information History Layer Information History Service Replica Management Layer Replica Management Service Storage Interface Layer SI API Storage Service SI API Storage Service SI API Legacy Storage Service Figura 4.9: Layered Architecture di InterDataNet Concentriamoci sul rapporto tra SI e Replica Management: in figura 4.10 è schematizzato il flusso di scambio contenuti tra i due servizi. Il servizio di gestione delle repliche avrà necessità di memorizzare varie informazioni per la copia. Ad esempio l URL della replica master, informazioni sulla scadenza, o proprietà di lettura/scrittura di questa specifica replica. Queste informazioni si aggiungono agli User Metadata ricevuti dal livello superiore Ruolo di SI Memorizza informazioni che saranno poi gestite dall architettura di IDN Aspetti rilevanti È il servizio di storage di IDN 111