InterDataNet: nuove frontiere per l integrazione e l elaborazione dei dati

Dimensione: px
Iniziare la visualizzazioe della pagina:

Download "InterDataNet: nuove frontiere per l integrazione e l elaborazione dei dati"

Transcript

1 UNIVERSITÀ DEGLI STUDI DI FIRENZE Facoltà di Ingegneria Dipartimento di Elettronica e Telecomunicazioni Dottorato di Ricerca in Telematica e Società dell Informazione - XX ciclo ING-INF/05 InterDataNet: nuove frontiere per l integrazione e l elaborazione dei dati Visione e progettazione di un modello infrastrutturale per l interdataworking Tesi di Dottorato di Ricerca di Samuele Innocenti Coordinatore Prof. Dino Giuli, Università degli Studi di Firenze Supervisori Prof. Franco Pirri, Università degli Studi di Firenze Dr Ing. Maria Chiara Pettenati, Università degli Studi di Firenze 31 dicembre 2008

2 Ringraziamenti Seduto alla mia scrivania, in questi ultimi giorni mi sono soffermato spesso a rileggere con orgoglio e soddisfazione l indice della mia tesi di dottorato, estrema sintesi di una ricerca lunga ed impegnativa. Assecondato dall atmosfera di fine anno, ho rievocato col ricordo questi anni. È stato un susseguirsi straordinario, in un così breve periodo, di tappe ed eventi, spesso inattesi, spesso positivi. La mia ricchezza è stata ed è nelle persone speciali che hanno condiviso con me queste esperienze col loro calore ed affetto, rendendomi migliore e fiero per le difficoltà superate e dei risultati raggiunti. A tutte loro va la mia profonda ricoscenza. Un ringraziamento speciale a mia moglie Donatella, per le tante qualità che ogni giorno dimostra nel realizzare i nostri progetti di vita, nel gioire per ciò che sono e per le aspirazioni che perseguo. «Ti amo» Ringrazio i miei genitori, mamma Carla e babbo Roberto, ed i miei suoceri, Renza e Valerio, per l operosità e l amore con cui contribuiscono a rendere più serena e sicura la mia famiglia, sopratutto in questo periodo di lieti eventi. Ringrazio il Prof. Dino Giuli per gli innumerevoli incoraggiamenti, l aiuto morale e materiale nei momenti in cui mi sono sentito più fragile, andando oltre il ruolo accademico che ricopre. Ringrazio il Prof. Franco Pirri, il mio Mentore, per la stima e la fiducia professionale e personale, l amicizia paterna di cui mi ha onorato, attraverso le quali ho superato molte delle mie incertezze e insicurezze. Ringrazio Dr Ing. Maria Chiara Pettenati, l amica e confidente Maria Chiara, per la massima disponibilità, il suo determinante sostegno ed i preziosi suggerimenti professionali e personali. Ringrazio l Ing. Davide Chini, un amico sincero, per l estrema collaborazione e gli innumerevoli confronti costruttivi. Ringrazio il collega Ing. Massimo Poggi, per aver creduto fin da subito nelle mie capacità e valorizzato le mie competenze, per avermi accordato la prolungata assenza da lavoro, consentendomi la stesura di questa tesi con più serenità. Ringrazio il collega Sig. Luca Capannesi, per il supporto tecnico, l efficienza e la competenza con cui amministra i sistemi di rete del Laboratorio integrato Tecnologie della Telematica & Radar e Radiocomunicazioni del Dipartimento di Elettronica e Telecomunicazioni. Ringrazio gli ex-studenti, adesso ingegneri e validi professionisti, che ho seguito come correlatore di tesi. In ordine temporale: Ing. Niccolò Francini, Ing. Fernando Franco, Ing. Marc Hausmann, nuovamente Ing. Davide Chini, Ing. iunior Stefano Cigheri, Ing. iunior Ivan Zappia, Ing. Michela Paolucci, Ing. iunior Luca Bertelli, Ing. Cristiano Costantini, Ing. Maddalena Barlotti. Firenze, 31 dicembre 2008 Samuele Innocenti

3 La sapienza mi perseguita, ma io sono più veloce. Lupo Alberto (Silver)

4 A mia moglie Donatella

5 Indice Introduzione 1 I Analisi delle architetture 6 1 Stili architetturali Service Oriented Architecture Infrastruttura Definizioni Servizi REpresentational State Transfer Sintesi delle proprietà Resource Oriented Architecture OASIS DataWeb L architettura XDI Dataweb Links Dataweb Addressing Dataweb Representation Extensible Resource Identifier Gli identificatori XRI La risoluzione XRI Collaborazione basata su File System Interfaccia e servizi offerti Spazio dei nomi e trasparenza Confronto tra server stateful e stateless Semantica della consistenza Metodi di accesso remoto e caching File Area Network Distributed Version File System Stili di autenticazione Elementi di crittografia Crittografia a chiave privata

6 Indice Crittografia a chiave pubblica Crittografia e firma digitale Funzioni hash Public Key Infrastructure Elementi costituenti una PKI Le Certification Authority Le Policy delle PKI Rilascio, gestione e revoca dei certificati OpenID Il processo di autenticazione OpenID Punti critici di OpenID Kerberos Dalle origini ai giorni nostri L autenticazione in Kerberos Terminologia e concetti Reami, nomi principali e istanze Le chiavi Key Distribution Center I Ticket Il funzionamento di Kerberos L autenticazione Intra-Realm L autenticazione Cross-Realm Analisi di sicurezza Attacchi a dizionario e a forza bruta Replay Attack Time Services non sicuri Spoofing Login Il TGS e la chiave di sessione I TGS e i Client Attacchi al meccanismo di routing fra reami Altri Attacchi Sviluppi di Kerberos Kerberos e la crittografia a chiave pubblica Kerberos e le smart card II Requisiti, metodologia e contesto 92 3 Analisi estesa dei requisiti Requisiti funzionali, R.1.* Requisiti per le risorse materiali, R.1.1.* Requisiti per la gestione dei documenti, R * Requisiti di versioning, R * Requisiti di trasparenza, R * Requisiti di indirizabilità, R * Requisiti sulla codifica degli indirizzi, R * Requisiti di contesto, R.1.2.* Requisiti di groupware, R * v

7 Indice Requisiti per le identità, R * Requisiti di awareness, R * Requisiti non funzionali, R.2.* Requisiti architetturali, R.2.1.* Requisiti di qualità dei dati, R.2.2.* Requisiti per i documenti, R.2.3.* Metodologia di progettazione Valutazione dei requisiti Principi progettuali Non limitare la vista sul problema: approccio sistemico Scomporre la complessità: stratificare Limitare la crescita della complessità Adottare uno stile chiaro e standardizzato: SOA + ReST 118 Richiami a SOA Richiami a ReST Conciliare SOA e ReST Semplicità per il deploy: plug and play Decentralizzare la sicurezza: ente pubblico autorevole Osservazioni sulla gestione delle identità Abilitare lo sviluppo aperto: free software Come nasce il Software Libero Software Libero e Open Source Una scelta consapevole Vantaggi tecnici, sociali ed economici Copyleft e licenza del Software Libero La situazione attuale Modello del contesto Modello dell ambiente Le entità Persona Group Role Role vs Group Permission Location Resource La generalizzazione in entità Il modello delle interazioni III InterDataNet: progettazione L architettura InterDataNet IDN Information Model Cosa è un Information Model Elementi strutturabili vi

8 Indice Strutturare con il principio di responsabilità Identificazione dei nodi Osservazioni sul modello IDN Service Architecture Attraversamento dei livelli Imbustamento di dati e metadati IDN Overlay Network Dall architettura dei servizi alla rete Control Plane Rete ed interoperabilità InterDataNet Information Model I nodi informativi Informazioni atomiche Informazioni primitive Relazioni strutturali tra nodi Strutturare con criteri di responsabilità Identificazione dei nodi Storico dei documenti Versioning La propagazione delle modifiche I collegamenti del modello Lo stato di un documento Lo stato delle informazioni atomiche Lo stato delle informazioni primitive Authoring concorrente Controllo delle sessioni InterDataNet Service Architecture Virtual Repository Service Resource Aggregation Service Logical Domain Name Service Identity Service Information History Service Version Traversing Algorithm Replica Management Service Replica Management Localization Service Storage Interface Service Integrazione di sistemi legacy IV InterDataNet: servizi e sottosistemi IDN Naming Service Requisiti dei nomi Requisiti per gli HFN Requisiti per gli URN vii

9 Indice Requisiti sulla codifica per HFN e URN Logical Resource Identifier (LRI) Grammatica Persistent Resource Identifier (PRI) Grammatica Il modello a tre livelli Sistemi di risoluzione Logical Domain Name System (LDNS) La risoluzione L algoritmo di risoluzione Caching Supporto alla navigazione Espansione dello spazio dei nomi Proprietà di LDNS Localization Service (LS) La risoluzione inversa Integrazione in InterDataNet Studio di fattibilità Implementazione del sistema dei nomi LDNS LS Risoluzione inversa Virtual Repository Service Richiami al modello IDN-IM La struttura dello storico Resource Aggregation Service Vista sullo storico delle informazioni Relazioni strutturali La propagazione delle modifiche Applicazione delle diramazioni e delle fusioni Branching Merging Osservazioni sugli aspetti strutturali Identity Service Identità e profilo utente Access Control List (ACL) Permessi sui nomi Permessi sulle informazioni Information History Service La navigazione nello storico Version Traversing Algorithm I parametri di versione Interfaccia Information History Data Model Descrizione dello Schema XML viii

10 Indice 12 Replica Management Service Estensioni dell applicabilità Condivisione di risorse Vincoli prestazionali Requisiti Requisiti per la gestione delle risorse Requisiti per la replicazione Gestione delle risorse Memorizzazione persistente Il servizio di risoluzione dei nomi Il servizio di replicazione Mantenimento della consistenza Posizionamento delle repliche Selezione della replica e routing delle richieste Azioni atomiche e transazioni Interfacce Interfaccia esposta da Replica Management Interfaccia esposta da Localization Service Storage Interface Service Requisiti Interfaccia Messaggi di input, output, 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 Storage Interface Data Model Messaggi Tipi predefiniti WSDL e XML Schema Storage Interface XML Schema Storage Interface Predefined Types Conclusioni 352 V Appendici 356 A ABNF 357 B Notazioni e definizioni 359 B.1 Notazioni per i requisiti B.2 Classificazione dei requisiti B.3 Definizioni ix

11 Indice B.4 Acronimi di InterDataNet C Replicazione di risorse in rete 364 C.1 Vantaggi introdotti con la replicazione C.2 Architetture dei sistemi di replicazione C.3 Modelli di consistenza delle repliche C.3.1 Modelli data-centrici C.3.2 Modelli client-centrici C.4 Protocolli di gestione della consistenza C.4.1 Metodo del sito primario C.4.2 Metodo a votazione C.4.3 Metodo dei vettori di versione C.5 Strategie di replicazione C.5.1 Posizionamento delle repliche C.5.2 Propagazione degli aggiornamenti D Versioning e collaborazione 395 D.0.3 Modelli di lavoro D.1 Il concetto di configurazione D.2 Il controllo delle versioni D.3 Modelli di sincronizzazione D.3.1 Checkout/Checkin D.3.2 Composizione D.3.3 Transazioni estese nel tempo D.3.4 Change set D.4 Modelli di versioning D.4.1 Modello intensionale D.4.2 Modello estensionale D.4.3 Valutazione dei modelli D.4.4 Una nuova alternativa: UEVM D.5 Unified Extensional Versioning Model D.5.1 Il modello Il modello del documento Esempio di documento strutturato Versioning Versioning di un singolo documento Versioning di più documenti legati fra loro D.5.2 Conclusioni UEVM dal punto di vista dell utente Gestione dell esplosione combinatoria D.6 WebDAV D.7 Revision Control System (RCS) D.8 Concurrent Versions System (CVS) D.8.1 CVS, evoluzione di RCS D.8.2 Concetti di base Revisioni, branch e configurazioni D.9 Subversion D.9.1 Concetti di base x

12 Indice Numerazione esplicita delle configurazioni D.10 L ambiente integrato COOP/Orm D.10.1 Ambienti di sviluppo integrati D.10.2 Da Orm a COOP/Orm D.11 Sistemi di versioning peer-to-peer D.12 Valutazioni comparative Bibliografia 431 xi

13 Elenco delle figure 1.1 Esempi pratici di loose coupling Lo strato Dataweb indicato come evoluzione del Web Link contracts per la condivisione dati a due vie Strato uniforme XRI Relazione tra XRI, IRI e URI XRI i-names e i-numbers come strato superiore al DNS Le 4 modalità di risoluzione dell architettura XRI Modelli upload/download e ad accesso remoto per il file service Lettura e scrittura in un sistema a singolo processore Lettura e scrittura in un sistema distribuito Luoghi dove memorizzare file Architettura di una File Area Network Formato dell albero in Wizbit Crittografia a chiave privata - cifratura Crittografia a chiave privata - decifratura Crittografia a chiave pubblica Funzioni hash - controllo di ridondanza Struttura gerarchica delle CA di una PKI Flowchart di autenticazione OpenID State diagram della procedura di autenticazione OpenID Sequence diagram per l autenticazione checkid-immediate Sequence diagram per l autenticazione checkid-setup Kerberos - Autenticazione intra-realm Kerberos - Autenticazione cross-realm Modello a quattro quadranti Interazioni tra servizi Interazioni di servizi stratificati Rappresentazione dell ambiente reale Role Based Access Control Model

14 Elenco delle figure 5.3 Classificazione delle entità Il modello di interazione Logo del progetto IDN Nomi di risorse replicate Livelli dell architettura IDN Interazione request/response applicata ad IDN Imbustamento di dati e metadati Classi di metadati in IDN Livelli e servizi dell architettura IDN Livelli, servizi e processi Scenario di cooperazione Esempio di interazione fra i servizi in organizzazioni diverse Esempio di documento patente IDN Esempio di documento IDN Esempio di relazioni tra documenti IDN-IM Stato Update delle informazioni Generazione delle revisioni Storico dell informazione in IDN-IM Stati di una informazione atomica Stati di un informazione primitiva Casi di authoring concorrente Relazione tra IDN-IM e IDN-SA Interdataworking in IDN Resource Space Names Revisioni successive di documenti UEVM Coreografia al livello di Replica Management Storage Interface e Legacy Storage Interface Albero di directory LDAP Sintassi degli LRI Sintassi dei PRI Espressione regolare per match sui PRI Modello del sistema dei nomi: LRI, PRI ed URL Esempio di risoluzione senza Look-Ahead Esempio di risoluzione con Look-Ahead Esempio di albero delle zone Richieste ricorsive per la risoluzione Rappresentazione delle zona in LDNS Esempio di LS Rappresentazione di una zona Estensione di una zona Delega della gestione di un nodo ad un altra zona Risoluzione inversa Sistema dei nomi in InterDataNet Descrittore XML relativo alla risoluzione inversa xiii

15 Elenco delle figure 10.1 Nodi di livello IH Link di strutturali e di versioning Branch in IDN-IM con un figlio condiviso Propagazione in presenza di un figlio condiviso Merge di due nodi Propagazione a seguito di un merge Gestione di due rami di sviluppo concorrente Branch di un nodo Branch di un intero documento Sintassi degli indirizzi di livello IH Esempio di elemento recente rispetto al nodo di partenza Esempi di last relativi al branch Casi d uso relativi all interfaccia mostrata da IH a Virtual Repository Albero di XML Schema: visione globale Albero di XML Schema: particolare dei link di versione XML Schema per la definizione di indirizzi PRI Espressione regolare per definire gli identificativi di versione Convenzione sui nomi dei nodi nello storico Votazione con quorum a maggioranza su due livelli Casi d uso dell interfaccia esposta da RM: operazioni CRUD Casi d uso dell interfaccia esposta da RM: operazioni Advanced Casi d uso dell interfaccia esposta da RM: operazioni Admin Casi d uso dell interfaccia esposta da RM a istanze di pari livello Casi d uso dell interfaccia esposta da Localization Service 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 di SI-R C.1 Architettura di un sistema di gestione delle repliche C.2 Organizzazione di un archivio di dati distribuito e replicato C.3 Accesso ad un sistema replicato da parte di un utente mobile C.4 Approccio del sito primario con letture sui siti di backup C.5 Approccio del sito primario con migrazione del sito primario xiv

16 Elenco delle figure C.6 Esempi di configurazione per i quorum nella votazione C.7 Esempio dell approccio dei vettori di versione C.8 Organizzazione logica dei tipi di repliche in un archivio D.1 Esempio ricorsivo della configurazione D.2 Rappresentazione della storia delle versioni D.3 Paradigma di interazione D.4 Esempi in riferimento alla grammatica D.5 Esempi di documento UEVM D.6 Altri esempi di documenti strutturati D.7 Modifiche nella stessa sessione D.8 La modifica di un link e nascita di una nuova versione D.9 Gestione delle configurazioni in RCS D.10 Evoluzione delle versioni in Subversion D.11 Topologie a stella ed albero xv

17 Elenco delle tabelle 1.1 Requisiti XDI di indirizzamento Esempi di i-number e i-names Confronto tra le architetture di risoluzione DNS e XRI Confronto tra server stateful e stateless Metodi per gestire i file condivisi in un sistema distribuito Metodi per gestire la cache dei file nel client Requisiti funzionali per le risorse materiali (gestione risorse) Requisiti funzionali per le risorse materiali (versioning) Requisiti funzionali per le risorse materiali (trasparenza) Requisiti funzionali per le risorse materiali (indirizzabilità) Requisiti funzionali per le risorse materiali (codifica) Requisiti funzionali per le risorse di contesto (groupware) Requisiti funzionali per le risorse di contesto (identità) Requisiti funzionali per le risorse di contesto (awareness) Requisiti non funzionali architetturali Requisiti non funzionali sulla qualità dei dati Requisiti non funzionali per i documenti Corrispondenza ambiente modellato - ambiente fisico Mappa per la determinazione degli stati Esempio di rappresentazione dei dati interni di un LNS radice Esempio di rappresentazione dei dati interni di un generico LNS Esempio di rappresentazione dei dati interni di un server LS radice Esempio di rappresentazione dei dati interni di un server LS Esempio di rappresentazione dei dati interni di un server LS per la risoluzione inversa

18 Elenco delle tabelle 9.6 Esempio di rappresentazione dei dati interni di un server LS per il caching relativo alla risoluzione inversa C.1 Modelli di consistenza che non usano variabili di sincronizzazione 375 C.2 Modelli di consistenza che usano variabili di sincronizzazione D.1 Struttura e dati di un documento D.2 Approcci di versioning adottati dai CM sui vari tipi di entità D.3 Grammatica che definisce la struttura del documento xvii

19 Introduzione La diffusione di Internet e delle nuove tecnologie della telematica hanno mutato e trasformato società e persone, con un percorso così dirompente da determinare la nascita di nuova scienza, la Web Science. La Scienza del Web studia, condiziona e caratterizza le evoluzioni del World Wide Web (WWW). La storia delle evoluzioni e rivoluzioni, che segnano lo sviluppo della Web Science e succedutesi dalla fine degli anni Ottanta fino ai nostri giorni, è ricca e complessa. Ai fini di quanto si discuterà in questa dissertazione, ha importanza ricordare la motivazione storica, datata 1989, agli albori del Web come applicazione: creare un sistema di gestione dell informazione adatto alla condivisione di un esteso patrimonio di relazioni, documenti e in genere di letteratura scientifica. Varie tappe dello sviluppo del Web, che non è qui sede di commentare, hanno visto attribuire etichette diverse a diversi momenti storici dell applicazione WWW. Negli ultimi due anni c è stato un largo e talvolta abusato uso del termine Web 2.0 per denotare un particolare fiorire di applicazioni che hanno ottenuto successo grazie alla imponente partecipazione di utenti, nella creazione, gestione e condivisione di contenuti informativi. Assistiamo al fenomeno etichettato con Web 2.0, dove si ricercano ancora modi nuovi e migliori per sfruttare pienamente le potenzialità offerte dal sistema socio-tecnico, che si è configurato, ma già nelle comunità della rete si parla di Web 3.0 o di Web of Data per indicare una visione del Web ancora da attuare nella prossima evoluzione, che recepisce teorie e strumenti semantici per l elaborazione delle informazioni. Indipendentemente dalle convenzioni per identificare, collocare e motivare i periodi della storia del Web, quello che è rilevante, per i contenuti presentati in questo lavoro, è la constatazione che le soluzioni del Web attuale stanno trovando larghissima diffusione perchè esiste una infrastruttura consolidata di apparati e protocolli di comunicazione, di tecnologie informatiche (sebbene frammentate) collaudate e mature e di una platea di utenti sempre più accorti e ben disposti a diventare nodi della rete. Quello che appare chiaro a questo punto è che una evoluzione verso soluzioni semantiche, rimasta visione da circa una decade, necessita per decollare di fondamenta altrettanto solide. Allora è giusto chiedersi

20 Introduzione quali dovranno essere queste fondamenta, quali funzionalità di base consolidare nella infrastruttura. Nella Web Science si identifica chiaramente oggi il principio di base largamente condiviso che ha come scopo quello di: move the intelligence out of applications, into the data (Nova Spivak), ovvero disaccoppiare le applicazioni dai dati che esse elaborano. Vari settori dell ingegneria dell informazione hanno iniziato per primi ad applicare questo principio per affrontare temi e problematiche note sotto i nomi: integrazione di sistemi, interoperabilità, riuso di dati e applicazioni, federazione di sistemi, cooperazione applicativa, collaborazione in rete, gestione distribuita di risorse materiali e computazionali, ingegnerizzazione dei processi ed oltre fino al Semantic Web e all intelligenza distribuita. I dati sono visti come patrimonio cosicchè le soluzioni e le metodologie proposte mirano a valorizzarli. Ciascuno dei problemi aperti sopra citati presenta di per sé rilevanti complicazioni socio-tecniche e difficoltà teorico-implementative, soprattutto in scenari su larga scala. Per affrontare gli stessi argomenti in modo equidistante ed omogeneo è richiesta una metodologia in grado di suggerire un modo efficace ed efficiente di analizzare il problema e di indicarne la direzione per la sua soluzione. In questo lavoro saranno affrontati i problemi precedentemente elencati, con una ricerca di base, mettendo in discussione le strategie di progettazione tradizionali, principalmente evitando la proposta di standard o tecnologie. Facendo tesoro delle motivazioni tecniche che hanno determinato il successo della suite protocollare TCP/IP e dell internetworking, applicheremo la stratificazione come principio fondante della ricerca e della progettazione, applicandolo al trattamento e alla gestione dei dati-informazioni. Indicheremo questo approccio col nome di interdataworking. L obiettivo più ambizioso di questa tesi è auspicare per l interdataworking lo stesso successo dell internetworking. Per interdataworking intendiamo l abilità di collegare, distribuire ed integrare i dati, mettendo in evidenza l obiettivo di aumentare l interoperabilità e la collaborazione tra processi connessi in rete. Gli studi eseguiti sulla stratificazione, intesa sia come stile che pattern architetturale, evidenziano un migloramento della trattabilità dei singoli problemi per mezzo della loro scomposizione, una limitazione alla crescita della complessità, la riduzione di costi di sviluppo senza diminuire la qualità, il migliore controllo granulare del sistema e una migliore comprensione del sistema. Soluzioni informatiche che perseguono parzialmente questa strada sono storicamente classificate sotto il termine middleware. Tali soluzioni tuttavia hanno rivelato svantaggi significativi dipendenti dall uso di implementazioni di tipo proprietario e/o troppo specializzate, non riusabili e non estendibili, ma sopratutto incapaci di abbattere la complessità della progettazione pur alzando il livello di astrazione della programmazione di applicazioni distribuite. In questo lavoro si presenta InterDataNet, la visione e la progettazione di un modello infrastrutturale per l interdataworking. InterDataNet (IDN) è visione perché ha l ambizione di proporsi come sistema per l interoperabilità sui dati, superando i limiti delle attuali architetture per la gestione distribuita di dati e risorse, aprendo nuove frontiere verso lo spostamento dell intelligenza dalle 2

21 Introduzione applicazioni ai dati, l auto-descrizione dei dati a supporto del loro significato, la possibilità di creare più facilmente applicazioni a valore aggiunto, una maggiore agilità nella condivisione dell informazione e nel collegamento dei dati. InterDataNet è diventato progetto, in quanto ha tradotto questa visione in una progettazione tecnica e realizzativa del modello infrastrutturale stratificato che integra funzioni di base a supporto dell elaborazione delle risorse informative, capace in ultima analisi di abilitare lo sviluppo di applicazioni per il Web del futuro, o Web Semantico. Semplificando alcuni concetti chiave di IDN è possibile affermare che InterDataNet è una applicazione estesa della definizione middleware. InterDataNet è indipendente dal contesto applicativo, sebbene affronti i requisiti della gestione collaborativa dell informazione, basandosi su un modello di riferimento, che mira a formalizzare le problematiche riguardanti la condivisione integrata dell informazione in una infrastruttura, distribuita su larga scala. InterDataNet trova le sue radici nel 2000, come framework collaborativo, ma fu indicato con nomi diversi fino al 2005, anno in cui si delineò in maniera completa e matura l obiettivo nella sua forma attuale. Inizialmente, sotto il nome Collaborative Operating System Architecture (COSA), l attenzione fu rivolta sulla comunicazione e la progettazione di protocolli di livello applicativo in grado di soddisfare i requisiti di collaborazione. La principale limitazione consisteva in una visione principalmente tecnologica. COSA fu in grado di evidenziare la necessità di un approccio interdisciplinare ai problemi di condivisione dell informazione, senza pienamente affrontarli. Questo punto di vista fu discusso dal 2003, nella mia tesi di laurea quinquennale in Ingegneria Informatica, riformulando il problema e specificando chiaramente che le risorse collaborative trattate sono rappresentabili tramite documenti. In particolare lo scenario inizialmente studiato ed utilizzato come riferimento fu quello della Pubblica Amministrazione, per successivamente generalizzare ad organizzazioni. Fu avviato il primo tentativo di modellare le risorse documentali cercando di dedurne, attraverso una loro astrazione, le caratteristiche universali, accreditate e universalmente riconosciute. Il modello dell informazione fu chiamato Distributed Delocalized Document Information Model (D3IM) e l architettura in grado di realizzarlo Collaborative Information System Architecture (CISA). Nel corso degli anni si approdò ad una piena sistematizzazione della teoria del modello dell informazione ed ai primi esperimenti implementativi. Prese più forza il concetto di una informazione sostenuta da una infrastruttura di rete capace di essere sufficientemente versatile e modulare da abilitare i benefici attesi. Nacque la visione di data over Internet come attuazione dell interdataworking. Adesso InterDataNet è descritto attraverso tre viste, in una forma che riteniamo più maneggevole rispetto a quanto suggerito in RM-ODP (Reference Model of Open Distributed Processing), che coprono gli aspetti introdotti: 1. IDN-IM (InterDataNet Information Model). È il modello dell informazione che rappresenta una generica risorsa, in maniera indipendente dallo specifico contesto e dalla tecnologia. Definisce i requisiti, le proprietà desi- 3

22 Introduzione derabili, i principi e la struttura del documento per soddisfare una efficace elaborazione collaborativa; 2. IDN-SA (InterDataNet Service Architecture). È l architettura stratificata di servizi per la gestione di risorse rispondenti al modello IDN-IM. IDN- SA definisce le funzionalità di riferimento, i sottosistemi, i protocolli e le interfacce per la realizzazione della collaborazione su un documento IDN. La stratificazione assume un ruolo determinante nella orchestrazione e coreografia dei servizi. Concilia lo stile SOA (Service Oriented Architecture), focalizzato sui servizi, con lo stile ReST (Representational State Transfer), focalizzato sulle risorse, in una rilettura meno tecnologica dell approccio ROA (Resources Oriented Architecture); 3. IDN-ON (InterDataNet Overlay Network). È l architettura di rete in cui sono collocati gli apparati di interdataworking che erogano servizi di IDN- SA. Indica il modo con cui costruire operativamente reti Overlay Network di IDN (over Internet). Le specifiche progettuali delineate da queste tre viste consentiranno di affrontare, in contesto distribuito il problema della creazione, la modifica, l integrazione e la gestione collaborativa di informazioni e dati in rete, perseguendo la flessibilità verso ogni contesto applicativo, l esposizione di servizi di base uniformi, la trasparenza dalle applicazioni, la capacità di integrare sistemi esistenti (legacy) e la scalabilità. La tesi che presento è organizzata in quattro parti. Nella prima parte si affronta l Analisi delle architetture. Il Capitolo 1 (Stili architetturali) presenta i principali stili architetturali e paradigmi infrastrutturalmente rilevanti, candidati alla realizzazione di servizi per la gestione dei dati e di informazioni con piattaforme distribuite. Il Capitolo 2 (Stili di autenticazione) fornisce una panoramica sulla autenticazione in approccio distribuito. Nella seconda parte si trattano Requisiti, Metodologie e Contesto di InterDataNet. Il Capitolo 3 (Analisi estesa dei requisiti) discute i settantatre requisiti di ordine generale che afferiscono a settori affini ad InterDataNet. Il Capitolo 4 (Metodologia di progettazione) sviluppa in maniera critica i requisiti generali e le linee guida progettuali, fornendo il primo approccio metodologico alla soluzione del problema. Il Capitolo 5 (Modello del contesto) fornisce i principi descrittivi fondanti l ambiente in cui si dovranno realizzare le interazioni tra utenti e tra utenti e risorse, così come dovrà essere recepito nella progettazione tecnica di IDN. Nella terza parte si discute la Progettazione di InterDataNet. Il Capitolo 6 (L architettura InterDataNet) definisce la teoria di IDN, con una panoramica di alto livello sulle tre viste (IDN-IM, IDN-SA, IDN-ON). Il Capitolo 7 (Inter- DataNet Information Model) entra nel dettaglio del modello dell informazione definendo i requisiti, le proprietà desiderabili, i principi e la struttura delle risorse da un punto di vista astratto. Nel Capitolo 8 (InterDataNet Service Architecture) si descrive il sistema dei servizi in maniera integrata ed unificata. 4

23 Introduzione La quarta parte, che va dal Capitolo 9 al Capitolo 13, illustra dettagliatamente ogni singolo servizio e sottosistema costituente la Service Architecture affrontando gli aspetti implementativi e tecnologici. Nelle Appendici sono riportate oltre alle notazioni e definizioni più ricorrenti, anche l analisi allo stato dell arte sui sistemi di versionig e di replicazione, come integrazione ai concetti richiamati in IDN-IM e IDN-SA. I tredici capitoli così strutturati sono funzionali a soddisfare tre diversi tipi di lettore, con l intenzione di agevolare la comprensione di un impianto così articolato e complesso, come quello qui presentato: lettore decision maker interessato alla visione ed al progetto generale ad alto livello; sequenza dei capitoli consigliata: Capitoli 4-5-6; lettore progettista e project manager interessato alla visione d insieme; sequenza dei capitoli consigliata: Capitoli ; lettore sviluppatore interessato ad implementare o potenziare specifiche parti dei sottosistemi; sequenza dei capitoli consigliata: Capitoli 6-7-8, come base a cui aggiungere uno tra i seguenti: , in funzione del compito di implementazione assegnato. 5

24 Parte I Analisi delle architetture

25 Capitolo 1 Stili architetturali Il World Wide Web è usato da milioni di utenti ogni giorno per vari scopi: , lettura news, download di musica, acquisti on-line o semplicemente per cercare informazioni. Usando un browser l utente può accedere alle informazione memorizzate su server Web dislocati nel mondo, avendo l illusione che tutte le informazioni siano locali al PC dell utente. In realtà, il Web è un esteso sistema distribuito che appare come un singolo servizio, disponibile alla portata di un click. Da questa prospettiva (applicativa) il WWW si può considerare una infrastruttura, quale insieme di impianti ed apparati che permettono l espletamento di un servizio. In questo capitolo saranno presentati stili e tecniche progettuali allo stato dell arte, per la realizzazione di servizi per la gestione dei dati e informazioni con piattaforme distribuite, cioè soluzioni orientate al Web of Data. Non si guarderà alla specifica soluzione, ma piuttosto in termini di componenti, connettori e questioni relative al controllo ed al trattamento dei dati. Verrà dato peso alle configurazioni architetturali (semantica dello stile) e alle potenzialità che possono essere attuate nello sviluppo di applicazioni per la condivisione collaborativa di informazioni. 1.1 Service Oriented Architecture Con SOA si indica Service Oriented Architecture. La definizione di questa architettura non è univoca in quanto in letteratura esistono molteplici definizioni [MLM + 06a] [Erl05] [NL05] ed ancora [Nat03], [Han07] [Arc05]. Tutte concordano sul fatto che SOA è un paradigma architetturale per una migliore flessibilità. Le SOA non sono definizioni di tecnologie o strumenti

26 Stili architetturali Service Oriented Architecture e non fanno riferimento a sistemi fisici. Si tratta di linee guida e paradigmi che rientrano nella accezione di design pattern architetturali. È un approccio, un modo di progettare che guida le decisioni quando si disegnano architetture software. 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 che prevedono la predisposizione organizzativa dei progetti, dei processi, dei ruoli delle entità coinvolte dalla progettazione alla realizzazione. Le SOA suggeriscono come affrontare questi aspetti ed in particolare le problematiche dei sistemi distribuiti, afferenti a differenti proprietari, e aiuta a sistematizzare l approccio all eterogeneità della codifica dei dati e della comunicazione. 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 [MLM + 06a]. A differenza di altri approcci ai sistemi distribuiti, le SOA si caratterizzano perché tra le assunzioni 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. Un approccio basato sullo stabilire a priori gli strumenti e le tecnologie piuttosto che le metodologie. L approccio SOA parte dal presupposto che l eterogeneità non si può eliminare, ma se poi il contesto tecnologico è omogeneo tanto meglio. Alla base delle Service Oriented Architecture ci sono tre concetti fondamentali: i servizi, l interoperabilità e il basso accoppiamento (loose coupling). In SOA il concetto di servizio si concentra sull astrazione e la modellazione dei processi del business: un servizio è l interfaccia di una rappresentazione di una qualche funzionalità reale, come ad esempio l acquisizione di un ordini di un cliente. 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, limitando che traspaiano aspetti tecnici e ciò che internamente viene elaborato. Il vantaggio è che, a patto di avere una interfaccia ben definita ed uniforme, non interessano più i dettagli dipendenti dalle specifiche piattaforme e l eterogenità non rappresenta una preoccupazione per gli utenti del servizio. Connettere sistemi eterogenei significa interoperabilità. Sistemi eterogenei sono interoperabili se possono funzionare insieme, ad esempio scambiandosi risorse o invocando funzioni remote. Una interoperabilità efficiente ed efficace si ha se viene attuata una politica di tolleranza ai guasti: se un sottosistema fondamentale per l erogazione di un servizio non è diponibile allora tutto il sistema nel suo complesso è compromesso. In SOA la chiave per raggiungere l interoperabilità è il disaccoppiamento, in quanto significa ridurre le dipendenze ai minimi termini. 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 8

27 Stili architetturali Service Oriented Architecture scalabilità. Un basso accoppiamento si ottiene aumentando la modularità del sistema e mantenendo uniformi le interfacce. Un modo per introdurre il loose coupling è evitare la centralizzazione più di quanto non sia necessario. La progettazione di architetture SOA passa dalla pratica del loose coupling: in tabella 1.1 sono elencati alcuni esempi pratici che illustrano il concetto di disaccoppiamento. 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 Figura 1.1: Esempi pratici di loose coupling Infrastruttura 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. È nelle infrastrutture che si abilita l interoperabilità. In SOA il mezzo che permette di invocare servizi tra sistemi differenti è Entrerprise Service Bus (ESB). Un ESB è uno strato software di astrazione basato su un sistema di messaggistica che è responsabile della trasformazione delle informazioni, dell instradamento dei messaggi, del monitoraggio, del logging. Influisce inoltre sulla 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 identificare e formalizzare i processi. Per 9

28 Stili architetturali Service Oriented Architecture processo si intende una generica sequenza di passi per soddisfare una necessità 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 procedimento di sistematizzare 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 ovvero di stabilire le condizioni aziendali a contorno Definizioni Prima di analizzare in dettaglio il concetto di servizio è utile fare alcuni chiarimenti sulla terminologia usata nelle Service Oriented Architecture. Si usano i termini quali provider e consumer per indicare i ruoli dei sistemi comunicanti: provider è un sistema che implementa un servizio cosicché un altro sistema lo possa invocare; consumer è un sistema che invoca un servizio. 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, arbitrando tutti i sottosistemi partecipanti Servizi Il termine servizio ha il significato di attività svolta da qualcuno per qualcun altro e nello specifico in ambito SOA un servizio è una realizzazione di una funzionalità del business con una tecnologia informatica che mette a disposizione una interfaccia specifica [OEH02]. 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 ha una interfaccia per scambiare messaggi riguardanti lo stato di una qualche entità. Da questa osservazione Yefim V. Natis afferma [Nat03]: 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 sotto la quale si costruiscono le applicazioni. 10

29 Stili architetturali Service Oriented Architecture I servizi possono essere caratterizzati da molti tipi di attributi, tuttavia non è chiaro quali siano obbligatori e quali opzionali. Si può avere a che fare con servizi auto-contenuti (indipendenza e autonomia), a alta o bassa granularità, visibili, senza stato, idempotenti, riutilizzabili e componibili. Tutte le definizioni di SOA concordano che sia una finalità di un servizio l essere auto-contenuto. Alcune dipendenze tuttavia non sono eliminabili quindi il requisito va interpretato come riduzione delle dipendenze ai minimi termini ed è quindi strettamente collegato al requisito di disaccoppiamento. L interfaccia dei servizi nasconde i dettagli implementativi all utilizzatore, per questo viene suggerita un unica chiamata al servizio che trasferisca tutte le informazioni. Una grana grossa aiuta a separare la struttura interna dei dati di un provider per servizi dalla sua interfaccia esterna, ma il problema è definire quando la grana debba essere grossa, infatti si ha spesso un elaborazione di dati che non sono necessari, con conseguente spreco di risorse e di tempo. Un altra proprietà importante è la visibilità. Prima di effettuare una chiamata ad un servizio è necessario che il servizio sia stato reso visibile e scopribile. 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 o meno non mantenere uno stato dipende dallo specifico contesto. 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ò ripetere la chiamata senza temere che questa comporti effetti indesiderati. Ci sono casi in cui ottenere l idempotenza è difficile, ma in un architettura SOA semplifica molti aspetti legati alla interazione, quindi è sempre opportuno porsi l obiettivo di realizzare servizi che possiedano questa proprietà. Un servizio SOA dovrebbe essere riutilizzabile. Evitare la ridondanza è un obiettivo generale dello sviluppo 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 equilibrio tra riutilizzo e prestazioni. Una funzionalità, quando necessario, può essere suddivisa in passi più elementari che a loro volta possono essere esposte con servizi. Questi possono quindi essere composti tra di loro. La composizione è alla base della modellazione dei processi del business. 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 post-condizioni, 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. Inoltre SOA appare una definizione orientata agli 11

30 Stili architetturali REpresentational State Transfer aspetti di produzione ed ingegneria del software, tanto che sono molteplici le associazioni con standard tecnologici come i Web Service [TP02]. 1.2 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 nel capitolo cinque della tesi di dottorato di Roy T. Fielding, pubblicata nel 2000 [Fie00]. La sopra esposta precisazione è necessaria in quanto REST è stato da molti male interpretato ed usato erroneamente generando molteplici interpretazioni, quando l unica interpretazione è quella di Fielding. Il REST è uno stile per architetture software e precisamente è lo stile del Web. È infatti è nato durante la stesura del protocollo HTTP di cui Fielding è coautore [FGM + 99]. Il REST un modello astratto, ed il Web è una architettura concreta che si basa sui principi di questo modello. Il 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 usa il la 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 Web delle origini 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. Questo principio disaccoppia le implementazioni dalle funzionalità, semplifica il sistema e migliora la visibilità delle interazioni, ma degrada l efficienza poiché le infor- 12

31 Stili architetturali REpresentational State Transfer mazioni 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. Questo principio impone altri vincoli sulle funzionalità offerte dalla interfaccia di un sistema RESTful: l 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 preesistenti. 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. Sotto questo aspetto REST può essere posto su un piano di confronto delle Service Oriented Architecture Sintesi delle proprietà Indipendentemente dalla interpretazione della definizione originale o di successive derivazioni in sintesi REST deve possedere le seguenti proprietà fondamentali: Statelessness: la comunicazione deve essere senza stato affinchè ogni richiesta dal client debba contenere tutte le informazioni necessarie al server per interpretare correttamente la richiesta. Osserviamo che il server può comunque mantenere uno stato ed utilizzare le informazioni di stato (per le istanze) per elaborare correttamente la richiesta. La questione importante è che il client non debba dipendere dal server per il contesto della richiesta. Cacheability: ogni risorsa trasferita tra client e server deve essere marcata come cacheable o altrimenti il minimo possibile non-cacheable. Uniform interface: un sistema RESTful deve possedere una interfaccia uniforme con le seguenti proprietà: 13

32 Stili architetturali Resource Oriented Architecture Identificazione delle risorse: un sistema RESTful conterrà una o più risorse ovvero il target del servizio indicato dall identificatore concettuale (Il tempo all aeroporto di Firenze; il prezzo del libro Divina Commedia, etc): Una URI nel senso di Universal Resource Indicator. Manipolazione delle risorse attraverso la rappresentazione: una rappresentazione consiste in una serie di byte (es. un numero in formato testuale della temperatura con in gradi centigradi, una immagine JPEG di una copertina di un libro, un documento XML contenente tutte le informazioni metereologiche, un frammento di XHTML di una lista di attributi di libri). Notiamo che non deve esistere una relazione biunivoca tra la rappresentazione e la risorsa e la risorsa stessa. La risorsa è disaccoppiata dalla sua rappresentazione. Self-Descriptive Messages Meta-data, pure and simple: una rappresentazione di una risorsa possiede sia dati che metadati. I metadati possono essere indipendenti dalla rappresentazione, cioè possono avere rappresentazioni alternative. Hypermedia as the engine of application state: se applicabile, dovrebbero esistere alcuni tipi di link per indicare lo stato successivo dell applicazione in riferimento alla rappresentazione corrente inviata al client. L esempio più ovvio può essere che una request POST che crea o modifica una risorsa deve ritornare un puntatore ad una rappresentazione di quella risorsa in una pagina HTML, oppure in maniera mutuamente esclusiva uno stato HTTP 302 (Found) o, più semanticamente, HTTP 303 (see Other). Layered: ogni layer di un sistema REST non può agire oltre i confini del layer a cui è connesso. Ad esempio, il cient verso il quale il servizio RESTful sta rispondendo, può non essere un client nel senso stretto del termine: può essere un altro server (es. un proxy). Un progettista di servizi RESTful non deve preoccuparsene, deve trattarlo come un client ed interpretare solamente le richieste e non chi le formula. Vincoli opzionali allo stile REST: un sistema REST può essere vincolato da code-on-demand. Significa che il codice viene scaricato ed eseguito dal client (es. Javascript, Flash, Java, etc.) come parte integrante della rappresentazione della risorsa. 1.3 Resource Oriented Architecture Nel panorama dei Web Service [Jos07], RESTful è stato usato come aggettivo per classificare una tipologia di servizi basati su un approccio che usa i metodi HTTP per eseguire operazioni remote, in contrapposizione all approccio tipico WSDL, SOAP. Questi servizi hanno riscosso un discreto interesse, soprattutto da 14

33 Stili architetturali Resource Oriented Architecture parte di sviluppatori orientati alla realizzazione di servizi di largo consumo per il Web, e quindi non interessati alla costruzione di complessi sistemi enterprise 1. L origine di questa definizione discende dalla interpretazione di HTTP, quale riferimento di interfaccia uniforme, così come richiesto dallo stile REST. Ma molti servizi etichettati come RESTful non rispettano tutti i vincoli di questo stile e così i puristi di REST filosofia non esitano a definirli servizi accidentally RESTful, servizi low REST o REST-RPC. In questo panorama confuso, si inserisce Resource Oriented Architecture (ROA). ROA, presentata in [RR07], prescrive delle linee guida per realizzare architetture RESTful. Gli autori adottano questo termine per designare architetture che rispettano i principi del REST, 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. Gli URI in questo contesto, devono essere descrittivi, ovvero deve esistere una corrispondenza intuitiva tra questi e le risorse che indirizzano, e devono possedere uno schema sintattico. 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 seguenti metodi del protocollo HTTP: HEAD e OPTIONS. Il vantaggio di questa interfaccia è che il metodo GET è safe, quindi una richiesta che utilizza questo metodo non cambia nessun stato nel server. GET, 1 È stato evidenziato un difficoltà di base nella implementazione di Web Service come riportato in Big Web Service Are Not Simple [RR07] e Am I Stupid or Is Java Web Services Really Hard? [Han07]. 15

34 Stili architetturali OASIS DataWeb PUT e DELETE godono della proprietà di idempotenza: un operazione idempotente su una risorsa non cambia lo stato della risorsa se viene ripetuta in maniera identica. 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. 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 convergenza delle due tecnologie [Vin07], in particolare le nuove specifiche dei WSDL supportano la definizione delle interfacce su HTTP in stile ROA [Chi07], e forse in futuro si potranno estendere alcuni standard dei Web Service anche ai servizi sviluppati con questo stile. 1.4 OASIS DataWeb In questa sezione verrà analizzato in dettaglio l architettura XDI/XRI, acronimi che vanno ad indicare rispettivamente l XRI Data Interchange e l extensible Resource Identifier. Tale architettura definisce una modalità modalità di identificazione e di risoluzione di nomi in rete che si pone ad un livello di astrazione più elevato rispetto al Domain Name System (DNS)[Moc87a, Moc87b], in modo tale da poter indirizzare nomi sia persistenti che non (con il termine persistente si intende che il link al nome puntato si mantiene anche nel caso in cui il target puntato si sposti, cambi nome o cambi proprietario). Questo permette di superare i limiti del Web attuale circa l interscambio di dati distribuiti con un nuovo approccio per la condivisione di dati distribuiti che abilita i principi del World Wide Web (WWW) attuale alla condivisione e collegamento di dati attraverso domini e applicazioni diverse. Il Dataweb è un progetto open iniziato nel 1995 per fornire accesso ai dati nello stesso modo in cui il Web corrente consente l accesso ai documenti. Come è indicato in figura 1.2, esso evolve naturalmente sopra il Web esistente, analogamente a come il Web stesso si è sviluppato sopra TCP/IP. Web Dataweb Internet Figura 1.2: Lo strato Dataweb indicato come evoluzione del Web 16

35 Stili architetturali OASIS DataWeb L architettura XDI XDI è un nuovo servizio generalizzato ed estendibile per la condivisione di dati distribuiti sviluppato dall OASIS XDI Technical Committee; OASIS sta per Advancement Of Structured Information Standards, ed è un organizzazione senza scopi di lucro nata per l avanzamento dei sistemi d informazione strutturati. XDI usa gli XRI[KW05], ovvero un tipo di identificatore astratto sviluppato anch esso dall OASIS. Lo scopo di XDI è abilitare i dati per l identificazione, scambio, collegamento e sincronizzazione fra sorgenti diverse, usando documenti in extensible Markup Language (XML) per il machine-readable Dataweb, analogamente a come vengono usati i documenti in Hyper Text Markup Language (HTML)[FGM + 99] per il human-readable Web. Ad oggi non è stata ancora sviluppata nessuna specifica formale, poiché per la sua realizzazione la commissione è in attesa dell approvazione a standard (documento Extensible Resource Identifier (XRI) Resolution V2.0 [WRM + 08]. Tuttavia è in corso d opera un modello basato sul Resource Description Framework (RDF) [Bec04] che definisce un formalismo per la rappresentazione di metadati, introducendo maggiore capacità espressiva in modo da strutturare l informazione contenuta nelle risorse in maniera comprensibile dalle macchine. Tale formalismo è basato sul concetto di statement (asserzioni), codificate in triple: soggetto, predicato, oggetto. L idea è quella di poter utilizzare una struttura dati organizzata secondo un grafo orientato: sui nodi sono poste le risorse (soggetto ed oggetto dello statement), mentre gli archi del grafo rappresentano le relazioni (predicato dello statement). Per la definizione tecnica del modello che utilizza RDF è stato proposto XDI RDF Model [RST08], il quale getta le basi per la specifica XDI 1.0. I punti chiave che caratterizzano XDI sono tre [RS04]: Dataweb Links: collegamenti per il controllo del flusso dei dati. Dataweb Addressing: indirizzamento tramite gli identificatori XRI. Dataweb Representation: definizione di un formato per lo scambio, link e sincronizzazione di dati codificati in XML. Dataweb Links Una delle differenze principali tra l architettura del Web e quella del Dataweb è il potenziamento del link. Nel Web i link sono soltanto handle unidirezionali tra risorse HTML che permettono ad un documento di essere indirizzato ed acceduto da un browser (pull); i link del Dataweb possono invece essere considerati come dei connettori bidirezionali che collegano risorse XML permettendo il flusso in entrambe le direzioni (push o pull). Il flusso dei dati può quindi essere controllato automaticamente da regole chiamate XDI link contracts. Questi concetti sono schematizzati in figura 1.3 [RS04]. I link contracts sono documenti Dataweb che descrivono le condizioni di autorizzazione e permesso per l interscambio di dati condivisi tra due o più soggetti XDI, proprio come nel mondo reale i contratti legali esprimono i termini di accordo tra due o più parti. 17

36 Stili architetturali OASIS DataWeb HTML HTML XML / XDI XML / XDI XDI link contract HTML HTML HTML HTML XML / XDI XML / XDI XML / XDI XML / XDI HTML HTML HTML HTML XML / XDI XML / XDI XML / XDI XML / XDI Web site A Web site B Dataweb site A Dataweb site B Figura 1.3: Link contracts per la condivisione dati a due vie Consultando [Bec04], si può vedere come gli archi (predicati) del grafo RDF, relativo all architettura XDI, rappresentino le relazioni tra nodi (risorse), utilizzando specifici identificatori XRI: $a identifica il nodo il cui arco è entrante; $has identifica il nodo il cui arco è uscente; $is identifica il nodo che ha un arco che punta a sé stesso I link contracts sono caratterizzati da: traversing bidirezionale: è la differenza principale, che è stata sopra discussa. Il Web permette solo il pull, mentre il Dataweb sia il push che il pull. persistenza: una link Web è o attivo o inattivo, quindi o fornisce una risorsa oppure produce un errore. I link contracts Dataweb usano invece identificatori XRI persistenti che permettono al link di ristabilirsi anche se il target puntato si sposta, cambia nome o cambia proprietario. controllo accesso: l accesso ad una risorsa Web è o pubblico (non controllato), o privato (protetto). Invece ogni link Dataweb ha un XDI link contract, che permette controllo globale e granulare di tutti i dati che stanno passando. I link Dataweb sono inoltre associati ai seguenti concetti: authority: permette di stabilire l entità che controlla i dati condivisi. authentication: permette alle due parti di scambiarsi informazioni inerenti la loro identità. authorization: permette di stabilire chi ha i privilegi di accesso ai dati. 18

37 Stili architetturali OASIS DataWeb privacy: stabilisce il modo in cui possono essere usati i dati e da chi. termination: stabilisce cosa accade quando la condivisione dei dati termina. In conclusione si può dire che i Dataweb link contracts permettono la mediazione dei dati distribuiti allo stesso modo in cui il Web permette l accesso ai contenuti. Si tratta quindi di una soluzione che modella e scala il mondo reale della condivisione dati Dataweb Addressing Nel Web classico si utilizzano per l indirizzamento gli Uniform Resource Identifier (URI) [BLFM05], e nel Dataweb basato su protocollo XDI/XRI si utilizzano gli identificatori XRI, un sottoinsieme di essi. Grazie agli XRI è possibile farlo per ogni singolo elemento dei dati, fino al più piccolo attributo. In tabella 1.1 [RS04] vengono comparati i requisiti di indirizzamento per la condivisione dati (Dataweb) con quelli per la condivisione dei contenuti (Web). Tra i requisiti visti in tabella, il più interessanti è la cross-references, di cui possiamo vedere le potenzialità con un esempio. Un sistema bibliotecario usa le URN (Uniform Resource Name, un particolare tipo di URI che identifica una risorsa mediante un nome in un particolare dominio di nomi), nello spazio dei nomi ISBN (International Standard Book Number) per identificare libri, e sottodomini DNS per identificare la sua collocazione; la sintassi URI HTTP non fornisce uno schema sintattico. L XRI Cross-Reference risolve questo problema, permettendo alla biblioteca di indirizzare qualunque libro alla sua collocazione. Per esempio: xri://ingegneria.biblioteca.esempio.com/(urn:isbn: ) xri://architettura.biblioteca.esempio.com/(urn:isbn: ) xri://medicina.biblioteca.esempio.com/(urn:isbn: ) Questa possibilità di creare identificatori strutturati ed autodescriventi può essere estesa a molti altri usi: per esempio, se la biblioteca vuole indicare il tipo di libro disponibile, può stabilire un semplice dizionario XRI di tipi di libri e costruire XRI che includono questi metadati: xri://ingegneria.biblioteca.esempio.com/(urn:isbn: )(+hardcover) xri://ingegneria.biblioteca.esempio.com/(urn:isbn: )(+softcover) xri://ingegneria.biblioteca.esempio.com/(urn:isbn: )(+reference) In aggiunta alle nuove capacità della sintassi XRI, XDI supporta i sinonimi XRI, cioè il modo in cui XDI può mantenere sia gli XRI riassegnabili humanfriendly (i-names), sia gli XRI persistenti machine-friendly (i-numbers) per la stessa risorsa. Per quanto riguarda i dettagli sugli i-names e gli i-numbers e la loro risoluzione si rimanda a paragrafo In conclusione si può dire che l indirizzamento Dataweb è il modo in cui XDI riesce a risolvere uno dei problemi più importanti per l integrazione delle applicazioni: mapping e condivisione dei dati tra domini diversi. 19

38 Stili architetturali OASIS DataWeb REQUISITI Web (URI) Dataweb (XRI) Persistenza Nessuna soluzione Sono supportati standard per l indirizzamento identificatori sia nel caso persistenti che di cambio locazione riassegnabili o di nome di una risorsa Contesto globale Contesto globale limitato Ci sono quattro conficatorsonale, per un identitesti globali: per- per organizzazioni, generale e speciale Cross-references Non è consentito l annidamento di URI per permettere la condivisione di identificatori tra domini diversi Self-references Non c è nessuna sintassi per riferirsi al concetto rappresentato da un identificatore Internazionalizzazione Parzialmente internazionalizzato. Le IRI (Internatio- Estensibilità nalized Resource Identifiers) [DS05] sono in via di sviluppo Estensibile attraverso nuovi schemi URI e protocolli di risoluzione Tabella 1.1: Requisiti XDI di indirizzamento Permette l annidamento di XRI (ed anche di URI) Fornisce una sintassi standard per la selfreferences È pienamente compatibile con le IRI Estensibile entro lo schema XRI e protocollo di risoluzione 20

39 Stili architetturali OASIS DataWeb Dataweb Representation Il terzo blocco chiave di XDI è l XDI Meta-schema. HTML è fondamentale per il Web in quanto fornisce un semplice formato indipendente dall applicazione, dal dominio e dal linguaggio per la rappresentazione di contenuti. Per mantenere questa importantissima caratteristica il Dataweb adotta XML. Lo scopo dell XDI Meta-schema è quello di fornire un formato semplice ed universale per lo scambio, collegamento e sincronizzazione di dati codificati in XML (oppure riferimenti ad altri dati indirizzabili tramite URI), vale a dire una Lingua Franca [BHD + 04] in cui ogni elemento dei dati è identificato con uno o più XRI e che permette quindi a persone ed organizzazioni di condividere dati. La forza di questo approccio è che le pagine Dataweb definiscono un unico formato in cui tutti i dati codificati in XML possono essere condivisi indipendentemente dall applicazione e dal dominio da cui sono stati creati. Inoltre usando i link contracts, le pagine possono essere sincronizzate e collegate persistentemente ed ciascuna può mostrare la precisa gerarchia per ogni elemento dei dati Extensible Resource Identifier XRI è uno schema ed un protocollo di risoluzione per identificatori astratti compatibile con le URI (e con le IRI), sviluppato dall OASIS XRI Technical Committee [WRM + 08]. Il suo scopo è quello di definire una sintassi standard per identificatori indipendenti dal dominio, dalla locazione, dall applicazione e dal trasporto, in modo tale da essere condivisi su qualunque dominio, directory e protocollo. Come mostrato in figura 1.4 XRI fornisce un livello uniforme di identificatori per ogni tipo di risorsa, posizionandosi sopra i sistemi di indirizzamento esistenti sia nel mondo telematico che fisico. XRI DNS IP Numeri di telefono Indirizzi postali Indirizzi futuri Risorse Web Figura 1.4: Strato uniforme XRI La specifica XRI 2.0 attualmente non è ancora considerata uno standard OA- SIS a causa della votazione sfavorevole dovuta soprattutto all intervento della World Wide Web Consortium (W3C) Techinical Architecture Group. Le URI sono stati identificatori di grande successo per Internet, ma tuttavia il recente sviluppo del Web ha portato nuove esigenze che la sintassi di quest ultime non era in grado di soddisfare. Una di queste, l internazionalizzazione, è stata ul- 21

40 Stili architetturali OASIS DataWeb timamente risolta grazie allo sviluppo delle IRI (identificatori che estendono il set di caratteri per supportare l intero range dei caratteri Unicode/ISO 10646). Con la grande crescita di XML e dei Web services, e l attuale necessità di automazione del Web verso le comunicazioni machine-to-machine, è diventato notevolmente importante essere in grado di identificare una risorsa indipendentemente dalla locazione fisica e dal protocollo, in modo da: creare identificatori indipendenti dal dominio, nello stesso modo in cui i documenti XML definiscono un formato per i dati che sia indipendente dal dominio; mantenere un link persistente alla risorsa anche nel caso in cui quest ultima cambi locazione; mappare gli identificatori usati per identificare una risorsa in un dominio, con altri sinonimi usati per identificare la stessa risorsa nello stesso dominio (o in altri domini). Questi requisiti sono stati recepiti dall OASIS Technical Committee, il cui obbiettivo è di creare un nuovo tipo di identificatori costruiti sulle specifiche delle IRI, allo stesso modo in cui esse sono costruite sulle URI (figura 1.5). XRI (Astratto) IRI (Internazionalizzato) URI (Uniforme) Estende la sintassi Estende il set di caratteri Specifica di base Figura 1.5: Relazione tra XRI, IRI e URI L OASIS XRI Technical Committee ha sviluppato anche un protocollo di risoluzione basato su Hyper Text Transfer Protocol (HTTP) e risorse chiamate extensible Resource Descriptor Sequence (XRDS). Per quanto riguarda le specifiche tecniche, ci sono tre documenti sviluppati dall OASIS che descrivono in dettaglio lo schema XRI: XRI Syntax document [RMD + 05] definisce in quattro punti la sintassi normativa con la quale gli identificatori XRI estendono la sintassi delle IRI: 1. un identificatore XRI è progettato per essere o persistente o riassegnabile, diversamente dalla normale sintassi IRI; 2. cross-references: i riferimenti XRI sono abilitati a contenere altri riferimenti XRI o IRI come sottosegmenti sintatticamente delimitati; 3. global Context Symbols (GCS): simboli che servono a definire un contesto globale astratto per un identificatore; 4. federazione standardizzata: gli identificatori federati sono quelli delegati attraverso autorità multiple, proprio come i nomi DNS. La sintassi XRI standardizza la federazione degli identificatori persistenti e riassegnabili. 22

41 Stili architetturali OASIS DataWeb XRI Resolution document [WRM + 08] definisce un protocollo di risoluzione per XRI basato su HTTP, che include sia la risoluzione generica che quella fidata. Visto che gli identificatori XRI possono essere usati in un ampia varietà di domini ed applicazioni, un singolo meccanismo di risoluzione non sarebbe appropriato. Perciò nell interesse dell interoperabilità la specifica definisce un semplice e generico formato descrittivo per la risorsa, chiamato documento XRDS. La specifica definisce inoltre un protocollo per richiedere documenti XRDS per mezzo delle primitive HTTP su risorse indicate con URI, ed infine un protocollo per la risoluzione degli XRI utilizzando documenti XRDS ed URI HTTP. XRI Metadata document [RMD + 05] definisce cinque caratteri GCS che possono essere usati per esprimere il contesto globale astratto di un identificatore. Uno di essi, $, è riservato per specificare il contesto globale, cioè per indicare che ci si sta riferendo ai metadata; gli altri GCS servono ad identificare lo specifico metadato in questione. Lo scopo di questa specifica è di definire un set di XRI che facciano da identificatori metadata, cioè attributi che possono essere usati per descrivere un identificatore. Ci sono quattro tipi di identificatori metadata: 1. Language metadata ($l) specifica il linguaggio umano nel quale un identificatore deve essere interpretato; 2. Date/time metadata ($d) specifica il momento temporale in cui l identificatore è stato creato; 3. Version metadata ($v) specifica la posizione dell identificatore in una sequenza di identificatori per la stessa risorsa logica; 4. Annotation metadata ($-) permette di aggiungere annotazioni human readable ad un XRI o ad un suo sottosegmento senza influenzare la risoluzione. Gli identificatori XRI XDI.org è un organizzazione pubblica e senza scopo di lucro che gestisce l architettura XDI/XRI, ed ha sviluppato un infrastruttura di identificatori basati proprio su essa. XRI vuole risolvere il problema di mantenere indirizzi persistenti per persone ed organizzazioni anche nel caso in cui queste cambino locazione o nome, aggiungendo un nuovo sistema di nomi che si pone sopra al DNS. Un sistema di nomi di questo tipo non è del tutto nuovo (es. URN), tuttavia ciò che rende unico lo strato XRI è che esso offre una sintassi unica ed uniforme per due diversi tipi di identificatori: i-numbers: sono identificatori machine-friendly che sono associati ad una risorsa (persona, organizzazione, file, progetto digitale, ecc.), e non riassegnabili. Ciò vuol dire che un i-number può essere sempre usato per indirizzare una risorsa per tutto il tempo in cui essa rimane disponibile da qualche parte sulla rete. Gli i-numbers sono progettati per essere processati in modo efficiente dai router di rete. 23

42 Stili architetturali OASIS DataWeb i-names: sono identificatori human-friendly che assomigliano a nomi di dominio ma sono più semplici e facili da usare per le persone. Gli i-names, proprio come i nomi di dominio, possono essere trasferiti o riassegnati dall utente verso altre risorse. Per esempio un organizzazione che necessita di cambiare il suo nome può cedere il suo vecchio i-name ad un altra organizzazione, mentre entrambe possono mantenere il loro univoco e persistente i-number. È proprio questo concetto che differenzia un i-name da un nome di dominio, ovvero la presenza di un suo sinonimo (equivalente) persistente i-number. I concetti sopra esposti sono schematizzati in figura 1.6. Nome human friendly XRI i-names XRI i-numbers Indirizzo machine friendly (persistente) Nome applicativo (riassegnabile) Indirizzo rete Nomi di dominio (DNS) Indirizzi IP Figura 1.6: XRI i-names e i-numbers come strato superiore al DNS Gli XRI sono retrocompatibili con il sistema di indirizzamento DNS e IP, cosicché sia possibile usarli con i nomi di dominio e gli indirizzi IP. Come i nomi di dominio, gli XRI possono essere annidati in profondità a livelli multipli, proprio come i nomi delle directory di un file system. Un organizzazione può registrare un i-name (top-level) per se stessa, e vari i-names (lower-level) ad esempio per le sue succursali e i suoi impiegati. XRI inoltre supporta tre caratteristiche che non sono disponibili nell indirizzamento DNS: indirizzamento non gerarchico: il modo in cui due nodi di una rete possono assegnarsi identificatori XRI l uno con l altro e implementare la risoluzione incrociata. cross-references: la capacità di un XRI di contenere altri XRI, abilitando la stessa risorsa logica ad essere identificata in altri contesti (caratteristica particolarmente rilevante per la condivisione dati tra domini diversi). global context registries: un modo sintetico e human friendly di indicare il contesto globale di un i-name o di un i-number. Ce ne sono di tre tipi, ognuno dei quali è rappresentato da un singolo simbolo, come mostrato in tabella

43 Stili architetturali OASIS DataWeb TIPO Global Simbolo i-name i-number Context Personale Individuale = =samuele.innocenti =!2D36.FA C3A Business Organizzativo @!1057.A23C.4E83.95D3 di marchio o no- me commerciale Generale Concetti, soggetti, + +animali +ani- +!3223 +!3223+!0343 argomenti mali+gatti generici Tabella 1.2: Esempi di i-number e i-names Gli identificatori i-names e i-numbers affrontare la rappresentazione di indirizzi convenzionali (come i numeri di telefono e le ): indirizzamento unificato: Poiché un i-name è astratto, esso è la prima vera online business card. Date le proprie credenziali l i-name può essere usato automaticamente per cercare qualunque altro dato necessario per poter comunicare con il suo proprietario. Non c è limite ai tipi di dati che possono essere risolti da un i-name. controllo della privacy: l uso di i-names e i-numbers dovrebbe arginare lo spam, perché non sono un tipo di canale di comunicazione diretta (come gli indirizzi , numeri di telefono o fax). Il possessore di un i-name controlla come esso è risolto, e come le regole sulla privacy devono essere osservate, già prima che venga stabilito un qualsiasi contatto o si acceda ad un dato. In pratica esiste un filtro (Privacy Barrier) tra l identificatore e le informazioni ad esso relative, così da fermare lo spam prima ancora che parta. Questo controllo della privacy viene fornito con l introduzione di un terzo attore, chiamata i-broker, il quale detiene e registra gli identificatori e la corrispondenza alla risorsa ad essi relativa. L i-broker, che rappresenta il service provider per l infrastruttura XDI ed agisce da intermediario tra due soggetti XDI. i-broker tutela quindi la privacy nell interscambio dei dati. Tra i servizi forniti dagli i-names, uno dei più importanti è quello di fornire un autenticazione sicura, di tipo single sign-on; si tratta del servizio di autenticazione OpenID, che verrà analizzato nel capitolo La risoluzione XRI La risoluzione è il processo di conversione di un identificatore in un metadato che descrive la risorsa identificata. Nella risoluzione di identificatori XRI, questo viene fatto richiedendo documenti XRDS tramite una richiesta HTTP. Un documento XRDS contiene uno o più elementi XRD (extensible Resource Descriptor); chiaramente il più semplice dei documenti XRDS ne conterrà uno soltanto. Costruire una sequenza di XRD in un documento XRDS in pratica consiste nel realizzare una catena di metadati. La specifica completa di risoluzione XRI è consultabile in [WRM + 08], nella quale sono definite inoltre sia un protocollo per richiedere documenti XRDS, sia un protocollo per la risoluzione degli XRI per mezzo di documenti XRDS e tramite richieste HTTP. Per quanto riguarda il Web attuale la risoluzione di identificatori (indirizzi 25

44 Stili architetturali OASIS DataWeb DNS XRI Identificatore Nome di dominio XRI Identificatore Network endpoint Indirizzo IP URI Protocollo di risoluzione primario UDP HTTP Risoluzione ricorsiva Name Server ricorsivi Server autoritativi ricorsivi o risolu- tori proxy Tabella 1.3: Confronto tra le architetture di risoluzione DNS e XRI di livello applicazione) si basa sul DNS, che risolve questi ultimi in indirizzi IP di livello rete. I punti principali dell architettura DNS sono i seguenti: Domain Name Space: è un database distribuito implementato in una gerarchia ad albero di Name Server. Name Server: macchine che detengono la struttura ad albero del dominio e tutte le informazioni correlate. Possono essere locali, radice e autoritativi. Resolver: sono programmi che estraggono informazioni dai Name Server in risposta alle richieste dei client. Un nome di dominio è generalmente risolto in un set di record (corrispondenza hostname-indirizzo IP) che descrivono un host, usando datagrammi UDP (User Datagram Protocol) o connessioni TCP (Transmission Control Protocol). Se il Resolver non ha la risposta registrata nella cache dei Name Server locali comincerà contattando uno dei Name Server radice conosciuti. La procedura di risoluzione per i nomi di dominio agisce da destra a sinistra e i Name Server radice riconoscono solamente i nomi di domino dei livelli superiori rispetto a quello da risolvere; quindi saranno ritornati i record dei Name Server a partire dai livelli più alti ed in seguito i risolutori ripeteranno la stessa richiesta scendendo lungo l albero finché il nome di dominio sarà risolto completamente o si incontrerà un errore. La risoluzione XRI segue la stessa architettura del DNS tranne che per il fatto che si pone ad un livello di astrazione più elevato; anziché utilizzare UDP (o TCP) come protocollo di trasporto usa HTTP ed il formato di messaggi è XRDS. Nella tabella 1.3 viene mostrata la comparazione tra le architetture di risoluzione DNS ed XRI, anche se in realtà non sarebbe lecito fare un paragone diretto fra le due infrastrutture, poiché la seconda si pone ad un livello di astrazione superiore rispetto alla prima ed offre servizi aggiuntivi in vista dell affermazione del Dataweb. L architettura di risoluzione XRI supporta sia la risoluzione ricorsiva basata sui server autoritativi, sia quella che avviene tramite proxy resolver (che è semplicemente un interfaccia HTTP verso un resolver XRI locale). Questa seconda modalità è utile per diversi motivi; per esempio, in questo modo la procedura di risoluzione è demandata al proxy resolver invece che al client locale. Inoltre il proxy resolver permette di ottimizzare la procedura di caching degli XRD. La figura 1.7 mostra 4 modi diversi in cui può essere risolto il seguente identificatore XRI: xri://(tel: )*foo*bar. Si può dedurre come 26

45 Stili architetturali OASIS DataWeb la componente autoritativa dell XRI è risolta in un documento XRDS, che descrive l autorità target. La risoluzione lavora iterativamente da sinistra a destra (diversamente dal DNS) attraverso ogni sottosegmento dell XRI. Negli XRI i sottosegmenti sono delimitati sia utilizzando specifici set di caratteri simbolici, sia parentesi. Per esempio, nell XRI xri://(tel: )*foo*bar, il sottosegmento autoritativo è (tel: ), una radice autoritativa (in questo caso una URI espressa con una cross-reference delimitata con parentesi); il primo sottosegmento è *foo, ed il secondo sottosegmento è *bar. Server autoritativo Server autoritativo Server autoritativo ricorsivo Server autoritativo (2)*bar? XRDS (3) (2) (4) (4) XRDS XRDS XRDS (1)*foo? (3)*bar? (1)*foo? Resolver locale Resolver locale A) Resolver locale che utilizza un server autoritativo non ricorsivo B) Resolver locale che utilizza un server autoritativo ricorsivo Server autoritativo Server autoritativo Server autoritativo ricorsivo Server autoritativo (3)*bar? XRDS (4) (3) XRDS (5) XRDS (5) XRDS *foo? (2) *bar? (4) Proxy Resolver *foo*bar? (2) (6) (6) Proxy Resolver (tel: ) *foo*bar? (1) (tel: ) *foo*bar? (1) C) Proxy server che utilizza un server autoritativo non ricorsivo D) Proxy server che utilizza un server autoritativo ricorsivo Figura 1.7: Le 4 modalità di risoluzione dell architettura XRI Affinché l infrastruttura XDI/XRI possa essere implementata, l organizza- 27

46 Stili architetturali Collaborazione basata su File System zione XDI.org ha sviluppato dei servizi di registrazione e risoluzione. Nella Global Services Specification V1.0 [LRC + 06] sono spiegati in dettaglio i requisiti che ognuna delle parti che compongono l infrastruttura devono assolvere. Nella specifica è spiegato come un utente o un organizzazione che volesse registrare il suo identificatore XRI, lo possa fare per mezzo di un i-broker, cioè una terza parte accreditata da XDI.org che funge da service provider. È spiegata anche la politica di gestione legale e tecnica di tutti servizi offerti. Nel caso in cui un organizzazione volesse diventare un i-broker può farlo stringendo un accordo (regolamentato in [LRC + 06]), con la Cordance Corporation ( o con Neustar ( e sotto l autorizzazione dell XDI.org, un ente che opera alla stessa maniera in cui organizzazioni come ICANN e IANA operano per il sistema DNS. Una lista di i-broker accreditati si può trovare a Nonostante siamo già stati investiti milioni di dollari nella realizzazione dell infrastruttura XDI/XRI, ad oggi la semplicità del Web attuale e la reticenza nel cambiare sistemi già funzionanti e consolidati, limita l affermarsi di questo nuovo framework. L infrastruttura XDI/XRI perciò è implementata solo parzialmente. Infatti per quanto riguarda gli aspetti relativi all autenticazione di un identificatore XRI, le specifiche dell infrastruttura XDI/XRI sono implementate con il protocollo OpenID 2.0 (che verrà analizzato nel capitolo 2). Anche per quanto riguarda i service provider (i-brokers), seppur pochi, ci sono e sono funzionali. Circa l integrazione di tutte le funzionalità offerte dalle specifiche XDI/XRI invece siamo ancora ben lontani; infatti solo per citare un esempio, per la parte relativa ai link contracts sono presenti le specifiche tecniche [RST08] e potenzialmente implementabili, ma di fatto non sono implementate in maniera concreta ma sono solo presenti dei modelli. 1.5 Collaborazione basata su File System In molti contesti aziendali, ma anche su scala globale, la condivisione e l auhtoring concorrente delle informazioni e delle risorse in rete avviene attraverso la condivisione di porzioni di file system: un servizio economico facile da realizzare. Questo paradigma consente il passaggio dei contenuti o risorse hardware tra gruppi o coppie di persone. La maturità e l efficacia del paradigma è comprovata dal supporto e largo utilizzo negli attuali i sistemi operativi di protocolli come SMB/CIFS. Osserviamo che l integrazione del file system e di un protocollo di condivisione consentono di erogare un servizio infrastrutturale. Questo approccio collaborativo è fortemente condizionato da un preventivo coordinamento tra utenti. Ad esempio è sufficiente una cancellazione, senza preavviso, o una modifica di una risorsa per impedire al destinatario di ottenerla o di valutarla nella sua evoluzione temporale. Ecco quinfi che funzionalità di versioning vengono incluse nei più diffusi tool di editing (es. Microsoft Word ed OpenOffice) Per comprendere la struttura di un file system distribuito è necessario introdurre alcuni concetti: 28

47 Stili architetturali Collaborazione basata su File System un servizio è un programma in esecuzione su una o più macchine che fornisce un tipo particolare di funzione a client sconosciuti a priori. un server è un programma di servizio in esecuzione su una singola macchina. un client è un processo che può richiedere un servizio servendosi di una serie di operazioni che costituiscono la sua interfaccia [SGG02]. Nel caso del file system, il server è nella macchina che contiene i file, e il client è nella macchina che cerca di accedervi. Solitamente il server dichiara che una risorsa è disponibile ai client, specificando esattamente quale risorsa (in questo caso, quali file) e quali client. Un server può servire più client, e un client può usare più server, a seconda dell implementazione. Le richieste di operazione sui file da parte dell utente sono inviate attraverso la rete secondo il protocollo del file system distribuito, normalmente insieme all identificatore dell utente richiedente. Il server applica i controlli di accesso per determinare se l utente ha le credenziali per accedere al file nella modalità specificata, di conseguenza la richiesta viene accettata o negata. Se viene accettata, l applicazione client può eseguire letture, scritture e altre operazioni sul file, chiudendolo quando ha completato l accesso. Molti degli aspetti dei file system distribuiti sono simili a quelli dei file system convenzionali, per cui saranno analizzati gli aspetti rilevanti e caratterizzanti per il contesto distribuito Interfaccia e servizi offerti Il servizio di archiviazione (file service) è la specifica di ciò che il file system offre agli utenti: descrive le primitive disponibili, quali parametri prendono in ingresso e quali azioni eseguono; definisce esattamente quali servizi sono disponibili agli utenti, ma non dice niente su come debbano essere implementati. In pratica, specifica l interfaccia del file system agli utenti [Tan94]. Nella maggior parte delle implementazioni si possono individuare due componenti separate: Servizio di memorizzazione (storage service). Gli utenti non hanno bisogno di conoscere le caratteristiche fisiche dei dischi, o dove sono stati memorizzati i file. Il file system possibilmente non deve perdere un file anche se ci sono guasti dell hardware o crash del software. Servizio di directory (directory service). Gli utenti possono dare nomi testuali ai file e, raggruppandoli in directory, evidenziare le relazioni tra di essi. Inoltre devono essere in grado di controllare la condivisione dei loro file con gli altri, specificando chi possa accedere ad un dato file e in che modo [BH03]. Per illustrare una tipica interazione tra il file service e l utente, si supponga che venga creato un file a cui l utente assegna un nome, detto nome testuale o simbolico. 29

48 Stili architetturali Collaborazione basata su File System Quando l utente chiama un operazione di tipo open, deve fornire come argomento il nome testuale, mentre un altro argomento specifica se vuole solo leggere il file oppure se vuole sia leggere che scrivere. Il servizio di directory esegue il controllo per assicurarsi che il file esista e che l utente sia autorizzato ad accedervi nella modalità richiesta, inoltre è responsabile della traduzione del nome dalla forma testuale alla rappresentazione interna del sistema, solitamente con codifica binaria, ossia una forma che permetta al servizio di memorizzazione di localizzare il file su disco (risoluzione dei nomi). A questo punto, il file system inserisce le informazioni sul file nelle sue tabelle in memoria principale, e restituisce all utente un identificatore che sarà usato nelle successive richieste di lettura o scrittura. Infine, il servizio di memorizzazione restituisce la porzione di file desiderata. Si noti che la richiesta iniziale deve fornire un nome che permetta al file di essere identificato univocamente nel file system. In un sistema distribuito, è importante fare distinzione tra i concetti di file service e file server. Il file server è un processo in esecuzione su qualche macchina e serve ad implementare il file service. Un sistema può avere uno o più file server; gli utenti, ovvero i client, non devono sapere quanti ce ne sono e quali sono la locazione e/o la funzione di ciascuno di essi, sanno soltanto che quando chiamano le procedure specificate nel file service, in qualche modo, il lavoro richiesto viene eseguito e viene restituito loro il risultato, ossia l esito della memorizzazione o dell accesso. Idealmente, i client non dovrebbero neanche sapere che il file service è distribuito, e dal loro punto di vista esso dovrebbe avere lo stesso aspetto di un normale file system. Poiché normalmente un file service è semplicemente un processo utente (o talvolta un processo kernel) in esecuzione su qualche macchina, un sistema può contenere più file server, e ciascuno di essi può offrire un diverso file service. Il tipo e il numero di file service disponibili può anche cambiare con l evolversi del sistema. modello upload/download 1: il file è spostato sul client client server modello ad accesso remoto il client richiede l'accesso a un file remoto client server 2: gli accessi avvengono nel client 3: dopo il file è rispostato sul server il file rimane sul server Figura 1.8: Modelli upload/download e ad accesso remoto per il file service Come illustrato nella figura 1.8, si possono distinguere due tipi di file service, a seconda del modello adottato: Modello upload/download. Il file service fornisce soltanto due operazioni principali: lettura e scrittura del file. La prima operazione trasferisce 30

49 Stili architetturali Collaborazione basata su File System un file da uno dei file server al client che lo richiede, mentre la seconda operazione lo trasferisce nella direzione opposta, dal client al server. In pratica, questo modello prevede lo spostamento dell intero file in una delle due direzioni. I programmi di applicazione prendono i file di cui hanno bisogno e poi li usano localmente, tenendoli in memoria o su un disco locale, a seconda della necessità. Quando il programma termina, qualsiasi file modificato o creato da zero viene scritto. Modello ad accesso remoto. Il servizio fornisce un grande numero di operazioni per aprire e chiudere i file, leggere e scrivere parti dei file, muoversi all interno dei file (seek), esaminare e cambiare gli attributi dei file, e così via. Il vantaggio del modello upload/download è la sua semplicità concettuale: non c è bisogno di un interfaccia complicata per il file service, e il trasferimento dei file è molto efficiente. Deve però essere disponibile abbastanza spazio nel client per memorizzare tutti i file richiesti. Inoltre, se si ha bisogno solo di una parte del file, è uno spreco spostarlo tutto. Nel modello ad accesso remoto questi due problemi non esistono, però ogni operazione richiede la comunicazione col server. La natura del servizio di directory non dipende dal tipo di modello adottato dal file service; esso definisce l alfabeto e la sintassi per comporre i nomi dei file e delle directory e fornisce le operazioni per creare e cancellare le directory oltre a rinominare, rimuovere e cercare i file in esse. Tutti i sistemi distribuiti permettono che le directory contengano sottodirectory, per far sì che gli utenti possano raggruppare insieme i file correlati. Le sottodirectory possono contenere a loro volta delle sottodirectory, e così via, portando ad un albero di directory, spesso chiamato file system gerarchico. In alcuni sistemi, è possibile creare collegamenti o puntatori ad una directory arbitraria. Questi possono essere messi in qualsiasi directory, rendendo possibile la costruzione non solo di alberi, ma di grafi di directory, che sono più espressivi nella rappresentazione delle informazioni memorizzate nel sistema. La distinzione tra alberi e grafi è particolarmente importante nei sistemi distribuiti. In una struttura gerarchica ad albero, un collegamento ad una directory può essere rimosso solo quando la directory puntata è vuota. In un grafo, è permesso rimuovere un collegamento ad una directory purché esista almeno un altro collegamento, e tenendo un contatore dei riferimenti si può determinare quando il collegamento che viene rimosso è l ultimo. Purtroppo talvolta possono presentarsi delle situazioni che rendono la directory di fatto inaccessibile, anche se il numero dei riferimenti ad essa è diverso da zero [BH03]. Questo problema esiste anche nei sistemi centralizzati, ma è più grave in quelli distribuiti. Se tutto sta su una macchina, è possibile, anche se oneroso, scoprire le directory orfane, perché tutta l informazione è nello stesso posto. Dopo aver fermato le attività sui file, si può attraversare il grafo partendo dalla radice, segnando tutte le directory raggiungibili: alla fine di questo processo, si sa che tutte le 31

50 Stili architetturali Collaborazione basata su File System directory non segnate sono irraggiungibili. In un sistema distribuito sono coinvolte più macchine e non possono essere fermate tutte le attività, perciò ottenere uno snapshot del sistema è difficile, se non impossibile. La struttura del sistema varia a seconda dell implementazione. In alcuni sistemi non c è distinzione tra client e server: su tutte le macchine gira lo stesso software, perciò ogni macchina che voglia offrire file service al pubblico può farlo, è solo una questione di esportare i nomi delle directory selezionate in modo che le altre macchine possano accedervi. Altre volte il file server e il directory server sono programmi utente, perciò il sistema può essere configurato in modo da far girare il software client e quello server sulla stessa macchina o meno, a piacere. Infine, ci sono sistemi in cui i client e i server sono in esecuzione su macchine completamente diverse, in termini di hardware o di software, o su versioni diverse del sistema operativo. Non c è motivo di preferire un approccio agli altri, ma la separazione delle funzioni è una soluzione un po più pulita. Un altra questione implementativa per cui i sistemi differiscono riguarda come sono strutturati il file service e il directory service. Si possono combinare i due in un singolo server che gestisca da sé tutte le chiamate a file e directory, oppure si può tenerli separati: in questo caso, aprire un file richiede di andare al directory server per mappare il suo nome simbolico in quello binario, e poi andare al file server con il nome binario per leggere o scrivere il file. Un argomento a favore della separazione è che le due funzioni sono del tutto scorrelate, perciò tenerle separate è più flessibile come soluzione, sia per quanto riguarda il bilanciamento del carico di lavoro che la manutenzione del software e la disponibilità del servizio; il problema è che avere due server richiede una maggiore comunicazione Spazio dei nomi e trasparenza La maggior parte dei sistemi distribuiti usa qualche forma di nominazione (naming) a due livelli. È conveniente per le persone e i programmi usare nomi simbolici per i file, ma questa rappresentazione risulta inefficiente per l elaborazione da parte dei processi che trattano i file all interno del sistema, perciò esistono i nomi binari. Le directory forniscono una mappatura tra questi due livelli di nomi. Quando un utente apre un file, o fa in qualche modo riferimento ad un nome simbolico, il sistema lo cerca immediatamente nella directory appropriata per ottenere il nome binario che sarà usato per localizzare il file. A volte i nomi binari sono visibili all utente, altre volte invece non lo sono [Tan94]. La natura di questi nomi può variare considerevolmente da un sistema all altro. In un sistema composto da più file server, ciascuno dei quali è autocontenuto, cioè non presenta nessun riferimento a directory o file su altri file server, il nome binario può essere semplicemente un numero di inode locale, come avviene nei sistemi Unix. Uno schema di nominazione più generale prevede che il nome binario indichi sia un server che uno specifico file su quel server. Questo 32

51 Stili architetturali Collaborazione basata su File System approccio permette ad una directory su un server di contenere un file che sta su un altro server. Altrimenti, un modo alternativo per fare la stessa cosa è usare un collegamento simbolico. Nella progettazione di un file system distribuito è importante decidere se tutte le macchine e i processi debbano o meno avere esattamente la stessa vista della gerarchia delle directory. In pratica, si tratta di stabilire se un nome di percorso valido su una macchina sia valido anche su tutte le altre o meno. Un problema strettamente correlato è l esistenza di una directory root globale, cioè una directory che sia riconosciuta come root da tutte le macchine. Idealmente, un file system distribuito deve apparire ai suoi utenti come un file system convenzionale, centralizzato: i client non devono essere a conoscenza della distribuzione dei file e della molteplicità dei server. Un requisito fondamentale è la trasparenza di rete o trasparenza di accesso, la quale implica che i client siano in grado di accedere ai file remoti usando lo stesso insieme di operazioni che si applica ai file locali. L interfaccia di un file system distribuito verso il client non deve perciò fare distinzione tra file locali e file remoti, e i programmi scritti per operare con i file locali devono essere in grado di accedere ai file remoti senza modifiche. È compito del file system distribuito localizzare i file e provvedere al trasporto dei dati [LS90]. La trasparenza di locazione implica che il nome di percorso non dia indizi su dove si trova fisicamente il file. I programmi client devono vedere uno spazio dei nomi dei file uniforme, in modo che i programmi utente possano vedere lo stesso spazio dei nomi ovunque siano eseguiti. Un sistema che presenta questo tipo di trasparenza assegna un nome di percorso del tipo /server1/dir1/dir2/x. Questo rende noto che x si trova su server1, ma non indica dove si trova il server, il quale è libero di muoversi ovunque voglia nella rete, senza che il nome di percorso debba cambiare. Si supponga adesso che il file x sia estremamente grande e che lo spazio su server1 sia poco, ma che ci sia molto spazio su server2: il sistema potrebbe voler spostare automaticamente x su server2. Purtroppo, quando la prima componente di tutti i nomi di percorso è il server, questo non può avvenire, perché lo spostamento automatico del file modificherebbe il suo nome di percorso da /server1/dir1/dir2/x a /server2/dir1/dir2/x, e di conseguenza tutti i programmi che hanno codificata al loro interno la prima stringa genereranno errore se il percorso cambia. Si dice che un sistema in cui i file possono essere spostati senza che i loro nomi di percorso cambino presenta indipendenza dalla locazione: questa implica la trasparenza di locazione e permette di bilanciare l occupazione dei dispositivi. Un sistema distribuito che inserisce il nome del server o della macchina nei nomi di percorso chiaramente non presenta indipendenza dalla locazione. Non la presenta neanche un sistema basato sul montaggio remoto, poiché non è possibile spostare un file da un gruppo di file (l unità di montaggio) ad un altro e continuare a usare il vecchio nome di percorso. L indipendenza dalla locazione non è facile da ottenere, ma è una proprietà auspicabile per un sistema distribuito. 33

52 Stili architetturali Collaborazione basata su File System Riassumendo, esistono tre strategie comuni di nominazione di file e directory in un sistema distribuito: Nominazione gerarchica. Un modo per avere una directory root globale è far sì che questa root contenga un elemento per ogni server, e nient altro. In questo modo, i nomi di percorso comprendono un identificatore della macchina su cui risiede il file, e assumono una forma del tipo /server/path, che oltre ad essere semplice è la stessa ovunque nel sistema. Questa forma di nominazione presenta trasparenza di locazione, ma non indipendenza da essa. Nominazione a condivisione parziale. Nei sistemi che gestiscono più file server tramite il montaggio remoto di file system nella gerarchia locale dei file, la norma è che macchine diverse abbiano diverse viste del file system. In pratica, viene aggiunta una gerarchia remota allo spazio dei nomi logici locale. Anche questa forma di nominazione presenta trasparenza di locazione, ma non indipendenza da essa. Un tale approccio è flessibile e facile da implementare, ma ha lo svantaggio di non essere equivalente ad un unico sistema a condivisione di tempo, in cui il file system appare uguale a tutti i processi. Nominazione a condivisone completa. La totale integrazione dei file system è realizzata tramite un unico spazio dei nomi che appaia uguale su tutte le macchine, in modo che tutti i client vedano la stessa struttura di nomi globale. In questo modo si ottiene indipendenza dalla locazione, la quale implica la trasparenza. I primi due approcci sono facili da implementare, specialmente per collegare sistemi esistenti che non erano stati progettati per l uso distribuito. Il terzo approccio è più difficile e richiede una progettazione accurata, ma è necessario se si vuole raggiungere lo scopo di far agire il sistema distribuito come un singolo computer. Un altro aspetto importante della trasparenza è la mobilità degli utenti, la quale implica che gli utenti possano accedere a qualsiasi macchina del sistema senza essere forzati a usarne una specifica. La trasparenza di prestazioni prevede che i programmi client continuino ad avere prestazioni soddisfacenti al variare del carico del servizio, mentre la trasparenza di scalabilità permette che il servizio venga espanso nel tempo con crescita incrementale per gestire una vasta gamma di carichi e dimensioni della rete [CDK00]. Il file service dovrebbe essere progettato in modo da soddisfare molti dei requisiti di trasparenza per i sistemi distribuiti, trovando il giusto equilibrio tra la flessibilità e la scalabilità che derivano dalla trasparenza e la complessità e le prestazioni del software. Si consideri il caso in cui file server e directory server sono separati. Il client manda un nome simbolico al directory server, il quale restituisce il nome binario comprensibile al file server. È possibile che una gerarchia di directory sia partizionata tra più server: si supponga di avere un sistema in cui la directory corrente sul server 1 contiene 34

53 Stili architetturali Collaborazione basata su File System un elemento a che corrisponde ad un altra directory sul server 2. A sua volta, questa directory contiene un elemento b che corrisponde ad una directory sul server 3. Quest ultima contiene un elemento che corrisponde al file c, insieme al suo nome binario. Per cercare a/b/c, il client manda un messaggio al server 1, che gestisce la sua directory corrente. Il server trova a, ma vede che il nome binario si riferisce ad un altro server. A questo punto può scegliere se dire al client su quale server sta b e far sì che il client si occupi di trovare b/c da solo, oppure inoltrare ciò che rimane della richiesta al server 2. Il primo schema richiede che il client sia a conoscenza di quale server tiene quale directory, e richiede più messaggi. Il secondo metodo è più efficiente, ma non può essere gestito usando le RPC 2 normali, poiché il processo a cui il client manda il messaggio non è lo stesso che manda la risposta. Cercare di continuo i nomi di percorso, soprattutto se sono coinvolti più directory server, può essere oneroso. Alcuni sistemi cercano di migliorare le prestazioni mantenendo in cache degli hint, cioè i nomi cercati di recente e i risultati di queste ricerche. Quando viene aperto un file, si controlla la cache per vedere se contiene il nome di percorso: in caso affermativo si prende l indirizzo binario da lì, altrimenti si fa la ricerca. Perché il caching dei nomi funzioni, è essenziale che quando viene usato inavvertitamente un nome binario obsoleto, il client venga in qualche modo informato, in modo che possa eseguire la ricerca per trovare il file, e aggiornare la cache. Inoltre, perché valga la pena tenere la cache degli hint, questi devono essere giusti per la maggior parte delle volte Confronto tra server stateful e stateless Se il server mantiene le informazioni sulla connessione ed i servizi che sta offrendo ai client tra una richiesta e l altra, si dice che il server è stateful. Questo comportamento è analogo a quello tradizionale dei sistemi operativi centralizzati, i quali mantengono informazioni sullo stato dei processi attivi. In un servizio con informazioni di stato, durante una sessione di file 3 esiste una connessione tra client e server [SGG02]. Quando il client esegue una chiamata open, riceve un identificatore che verrà usato nelle chiamate successive per riconoscere il file, fino al termine della sessione. Il server deve mantenere un identificatore univoco per ogni client, e delle informazioni che indichino quale client ha aperto quale file; quando riceve una richiesta, usa l identificatore del file per determinare di quale file si ha bisogno. 2 Il metodo di chiamata di procedura remota (Remote Procedure Call, in breve RPC) permette ai programmi di invocare procedure che si trovano su macchine diverse. Quando il processo sulla macchina A chiama una procedura sulla macchina B, il processo chiamante su A solitamente viene sospeso, e l esecuzione della procedura chiamata avviene su B. L informazione può essere trasportata dal processo chiamante a quello chiamato attraverso dei parametri, e tornare indietro come risultato della procedura. Il programmatore non vede nessun passaggio di messaggi [TvS01]. 3 Viene chiamata sessione di file una serie di accessi allo stesso file da parte di un client, in lettura o in scrittura, compresi tra le operazioni di open e close. 35

54 Stili architetturali Collaborazione basata su File System La tabella che mappa gli identificatori dei file nei file stessi rappresenta l informazione sullo stato [Tan94]. Questa tabella può contenere anche altre informazioni utili per il corretto funzionamento del server, come ad esempio i timestamp dell ultima modifica effettuata sul file o i diritti di accesso ad esso [LS90]. Lo spazio in memoria centrale usato per questo scopo viene liberato alla chiusura del file oppure tramite un apposito meccanismo di ripulitura (garbage collection). Uno svantaggio relativo a questo approccio è che se troppi client hanno troppi file contemporaneamente aperti la tabella può arrivare a riempirsi, provocando l impossibilità di aprire ulteriori file. Inoltre, si consideri cosa può succedere in caso di guasti. Se il server crolla, tutte le sue tabelle sono perse e al riavvio non c è più modo di sapere quali client hanno aperto quali file. Il recupero dello stato, se possibile, avviene tramite un protocollo di ripristino che sfrutta il dialogo con i client; altrimenti, tutte le operazioni in corso vengono terminate e i successivi tentativi di leggere e scrivere file aperti al momento del crollo falliranno. Anche quando è un client a crollare mentre ha un file aperto, il server si trova in difficoltà: deve liberare quella parte della memoria occupata dalle informazioni sul client perduto (rilevamento ed eliminazione degli orfani), o le sue tabelle finiranno per riempirsi. Ma se decide di dare il timeout ai file aperti inattivi, può capitare che venga negato il servizio ad un client che aspetti troppo a lungo tra una richiesta e l altra, impedendo il corretto funzionamento di alcuni programmi. D altra parte, un servizio con informazioni di stato ha prestazioni migliori, poiché l informazione sui file aperti può essere tenuta nella memoria principale finché questi non vengono chiusi. I messaggi di lettura e scrittura non devono contenere i nomi dei file, perciò sono più corti ed occupano una larghezza di banda minore nella rete. Per ridurre il ritardo si possono leggere in anticipo i blocchi, dato che la maggior parte dei file è letta sequenzialmente. Se un client va in timeout e invia la stessa richiesta due volte, in presenza di informazioni sullo stato è molto più facile accorgersene, ad esempio se si ha un numero di sequenza in ogni messaggio. Se invece il server non mantiene informazioni sul client una volta che ha finito di servire la sua richiesta, si dice che il server è stateless: significa che si limita a fornire i blocchi richiesti, senza preoccuparsi dell uso che ne sarà fatto. In altre parole, quando un client invia una richiesta al server, il server la porta a termine, invia la risposta, e poi rimuove dalle sue tabelle interne tutte le informazioni relative alla richiesta. Tra una richiesta e l altra, il server non mantiene nessuna informazione specifica sul client. In questo caso, ogni servizio è indipendente dal precedente e ogni richiesta deve esse autocontenuta, cioè deve contenere l intero nome del file e l offset all interno del file, in modo da permettere al server di eseguire il suo compito. Inoltre, c è bisogno di uno schema di nominazione uniforme di basso livello su tutto il sistema per l identificazione dei file. La maggiore lunghezza del messaggio e la necessità di tradurre i nomi remoti in locali rallentano l elaborazione delle richieste. 36

55 Stili architetturali Collaborazione basata su File System Non c è però bisogno delle chiamate open e close, il che riduce il numero dei messaggi inviati nella rete, specie nel caso assai frequente in cui l intero file è letto in un unica volta. In teoria non ci sarebbe neanche bisogno di usare spazio nel server per mantenere le tabelle, ma di solito queste vengono comunque utilizzate per motivi di efficienza. I server stateless sono intrinsecamente più tolleranti ai guasti, perché la mancanza di informazioni di stato elimina tutti i problemi visti per i server stateful. Quando viene ripristinato in seguito a un crollo, il server non ha problemi nel rispondere ad una richiesta autocontenuta. In pratica, i crolli passano quasi inosservati dal punto di vista del client, il quale continua ad inviare la sua richiesta finché non riceve una risposta, indipendentemente dal fatto che il server abbia subito un guasto o sia soltanto lento. Poiché i client ritrasmettono le richieste, bisogna assicurarsi che tutte le operazioni eseguite siano idempotenti, cioè che abbiano lo stesso effetto e diano lo stesso risultato se eseguite più volte di seguito. Gli accessi in lettura e scrittura autocontenuti sono idempotenti se usano un conteggio assoluto per indicare la posizione all interno del file, ma non se adoperano uno scostamento incrementale. Infine, è impossibile eseguire il locking dei file in un sistema del tutto stateless, perché l unico effetto del lock è l inserimento dello stato nel sistema: per i sistemi stateless sarà necessario un apposito locking server. vantaggi dei server stateful i messaggi di richiesta sono più brevi migliori prestazioni è possibile usare la tecnica read-ahead è più facile ottenere l'idempotenza è possibile mettere il lock sui file vantaggi dei server stateless tolleranza ai guasti non c'è bisogno di chiamate OPEN/CLOSE non c'è spreco di spazio nel server non c'è limite al numero di file aperti non ci sono problemi al crollo del client Tabella 1.4: Confronto tra server stateful e stateless Nella tabella 1.4 sono riassunti i principali vantaggi offerti dai due tipi di servizi appena visti. Il servizio con informazioni di stato può rivelarsi una necessità nel caso in cui i messaggi non arrivino nell ordine in cui sono stati inviati, e si voglia riordinarli sfruttando lo stato. Se poi si usa il metodo iniziato dal server per la validazione della cache, non è possibile avere un servizio senza informazioni di stato perché deve essere tenuta traccia di quali file sono tenuti in cache da quali client Semantica della consistenza Quando due o più utenti condividono lo stesso file, per evitare problemi è necessario definire la semantica di lettura e di scrittura, che specifica la proprietà delle modifiche apportate sui dati dai client e la loro visibilità ad altri client. 37

56 Stili architetturali Collaborazione basata su File System singolo processore 1: scrive c file originale A a b a b c B 2: legge abc Figura 1.9: Lettura e scrittura in un sistema a singolo processore Nei sistemi a singolo processore che permettono la condivisione dei file tra processi, come Unix, la semantica di solito stabilisce che ogni accesso in lettura al file vede gli effetti di ogni precedente scrittura, come illustrato nella figura 1.9. Ogni scrittura viene quindi resa immediatamente visibile agli altri client che stanno accedendo allo stesso file [LS90]. In pratica, il sistema applica un ordinamento di tempo assoluto a tutte le operazioni e restituisce sempre il valore più recente. Questo modello, noto come semantica Unix, porta ad un implementazione in cui ad ogni file è associata una sola immagine fisica. In un sistema distribuito, questa semantica può essere ottenuta facilmente purché ci sia un solo file server e i client non tengano copie dei file in cache. Le richieste di lettura e scrittura sono processate dal file server in ordine strettamente sequenziale, e i client possono condividere il puntatore alla posizione corrente del file. La maggior parte dei file system distribuiti cerca di emulare questa semantica per motivi di compatibilità. Un problema di questo approccio è che, a causa dei ritardi di rete, una lettura che è avvenuta un microsecondo dopo una scrittura potrebbe arrivare per prima al server, ottenendo così il valore vecchio. In pratica, comunque, le prestazioni di un sistema distribuito in cui tutte le richieste di file devono essere inviate ad un singolo server sono piuttosto scadenti [Tan94]. Questo problema di solito è risolto permettendo ai client di mantenere copie locali dei file più usati nelle loro cache private. Se però un client modifica localmente un file nella sua cache, e poco dopo un altro client legge il file dal server, il secondo client riceverà un file obsoleto, come illustrato nella figura Si potrebbe pensare allora di propagare immediatamente al server tutti i cambiamenti dei file in cache, ma nonostante sia concettualmente semplice, questo approccio risulta inefficiente. Una soluzione alternativa è quella di avere una semantica secondo la quale i cambiamenti su un file aperto inizialmente sono visibili solo al processo che ha modificato il file, o comunque soltanto ai client locali, e non ai client remoti che hanno aperto lo stesso file contemporaneamente. Quando poi il file viene chiuso, i cambiamenti saranno resi visibili agli altri nelle successive sessioni. Le 38

57 Stili architetturali Collaborazione basata su File System client 1 2: scrive c A a b 1: legge ab a b c file service a b client 2 B a b 3: legge ab Figura 1.10: Lettura e scrittura in un sistema distribuito sessioni remote attive alla chiusura non riflettono i cambiamenti e continuano ad operare su copie obsolete. Secondo questa regola, largamente implementata e conosciuta come semantica delle sessioni, un file può essere temporaneamente associato con molte immagini eventualmente diverse allo stesso tempo, e più utenti possono eseguire accessi concorrenti su di esse senza subire ritardi. Si deve però abbandonare la condivisione dei puntatori alla posizione corrente del file. L uso della semantica delle sessioni solleva la questione di cosa possa accadere quando due o più client stanno contemporaneamente tenendo in cache e modificando lo stesso file. Si può far sì che via via che ogni client chiude il file, venga inviato al server il valore aggiornato, in modo che il valore finale dipenda dall ultimo che lo chiude. Un alternativa leggermente più facile da implementare è stabilire che il valore finale sia uno dei candidati, ma senza specificare quale. Le politiche più usate comunemente sono varianti della semantica Unix e, in misura minore, della semantica delle sessioni; mettendole a confronto, emerge la necessità di raggiungere un compromesso tra la semplicità dell implementazione distribuita da una parte, e la robustezza delle garanzie fornite dalla semantica dall altra. La forza della semantica Unix sta nella garanzia che tutti gli accessi vedono la stessa versione del file, e quindi ciascun accesso è influenzato dai tutti quelli precedenti. Viceversa, la semantica delle sessioni non dà molte garanzie sull accesso concorrente ad un file, poiché accessi su macchine diverse possono osservare versioni diverse del file. Un approccio completamente diverso è la semantica dei file immutabili, secondo la quale le uniche operazioni permesse sono la creazione e la lettura; un file non può essere aperto in scrittura e il suo contenuto non può essere modifi- 39

58 Stili architetturali Collaborazione basata su File System cato. È possibile però creare un nuovo file e inserirlo nella directory con il nome di un file che esisteva in precedenza, il quale diventa così inaccessibile, per lo meno attraverso quel nome. In altre parole, i file non possono essere aggiornati, ma le directory sì. In questo modo è direttamente eliminato il problema di come gestire due processi dei quali uno sta scrivendo su un file e l altro lo sta leggendo. Rimane il problema di cosa possa accadere quando due processi provano a sostituire lo stesso file contemporaneamente: la soluzione migliore sembra essere quella già vista per la semantica delle sessioni, cioè permettere ad uno dei nuovi file di sostituire quello vecchio, sia esso l ultimo o meno. Un altro problema è cosa fare se un file viene sostituito mentre un altro processo lo sta leggendo. Una soluzione potrebbe consistere nel fare in modo che il lettore possa continuare ad usare il vecchio file, anche se non è più in nessuna directory. Un altra soluzione è accorgersi che il file è cambiato e far fallire i successivi tentativi di lettura. Un ulteriore modo di gestire i file condivisi in un sistema distribuito è quello di vedere ogni sessione di accesso ad un file come una transazione atomica, cioè usare la semantica delle transazioni. Quando un processo vuole accedere ad uno o più file, per prima cosa esegue una primitiva del tipo begin_transaction, per segnalare che ciò che segue deve essere eseguito indivisibilmente. A questo punto si possono usare le chiamate di sistema per effettuare la lettura e la scrittura, e quando il lavoro è completato, viene eseguita una primitiva del tipo end_transaction. Questa semantica è implementata mettendo il lock sul file per la durata della transazione, perciò ogni utente remoto può accedere al file solo se questo non è attualmente in uso, con conseguente limitazione del parallelismo. La proprietà chiave di questo metodo è che il sistema garantisce che tutte le chiamate contenute nella transazione saranno portate a termine in ordine, senza alcuna interferenza da parte di altre transazioni concorrenti. Se due o più transazioni iniziano nello stesso momento, il sistema fa in modo che il risultato finale sia lo stesso che si sarebbe ottenuto se fossero state eseguite in qualche ordine sequenziale non definito. semantica Unix sessioni file immutabili transazioni descrizione ogni operazione sui file è immediatamente visibile a tutti i processi nessuna modifica è visibile agli altri processi fino a quando il file non viene chiuso non è possibile eseguire modifiche tutte le modifiche avvengono in modo atomico Tabella 1.5: Metodi per gestire i file condivisi in un sistema distribuito Nella tabella 1.5 sono riassunti i metodi appena visti per gestire i file condivisi in un sistema distribuito. 40

59 Stili architetturali Collaborazione basata su File System Metodi di accesso remoto e caching Si consideri un processo client che richiede di accedere ad un file remoto, in lettura o in scrittura. Dopo che lo schema di nominazione ha localizzato il server su cui è memorizzato il file, la richiesta del client viene soddisfatta attraverso l effettivo trasferimento dei dati. Questo trasferimento può essere gestito in modi diversi, a seconda di dove sono memorizzati i dati. client server disco memoria rete memoria disco (opzionale) Figura 1.11: Luoghi dove memorizzare file Come illustrato nella figura 1.11, in un sistema client-server esistono diversi posti nei quali possono essere memorizzati i file, o parti di essi: il disco del server, la memoria principale del server, il disco del client (se disponibile) e la memoria principale del client. Secondo il meccanismo di servizio remoto, tutti i file sono memorizzati nel server, generalmente sul disco, dove c è abbondanza di spazio, in modo da essere accessibili da tutti i client. Le richieste sono inoltrate al server, il quale esegue gli accessi, e invia i risultati al client. Poiché esiste una sola copia di ciascun file, non si presentano problemi di consistenza. Il problema di questo approccio sono le prestazioni: prima che un client possa leggere un file, questo deve essere trasferito dal disco del server alla memoria principale del server, e poi di nuovo attraverso la rete alla memoria principale del client, ed entrambi i trasferimenti richiedono tempo [Tan94]. Un miglioramento considerevole delle prestazioni può essere ottenuto attraverso il caching, che consiste nel tenere nella memoria principale i file usati più recentemente. Quando un client legge un file che si trova nella cache del server, non è necessario eseguire il trasferimento dal disco, anche se dovrà esserci comunque il trasferimento attraverso la rete. Avere una cache nella memoria principale del server è una soluzione facile da realizzare e completamente trasparente ai client. Poiché il server può tenere sincronizzate le copie in memoria e quelle sul disco, dal punto di vista del client c è solo una copia di ogni file, quindi non sorgono problemi di consistenza. Anche se il caching sul server elimina il trasferimento dal disco, continua ad avere bisogno di un accesso attraverso la rete. C è una corrispondenza diretta tra gli accessi e il traffico tra client e server: le richieste di accesso sono tradotte in messaggi per il server, e le risposte del server sono messaggi inviati al client. Ogni accesso è gestito dal server e comporta del traffico nella rete [LS90]. 41

60 Stili architetturali Collaborazione basata su File System L unico modo per eliminare l accesso attraverso la rete è fare il caching sul lato client. Se i dati necessari a soddisfare la richiesta di accesso non sono presenti localmente, una copia di questi dati viene trasportata dal server al client. Gli accessi sono eseguiti sulla copia in cache sul client, di conseguenza non c è corrispondenza diretta tra gli accessi e il traffico verso il server. L idea è quella di mantenere in cache i blocchi di disco a cui si è acceduto di recente, in modo che gli accessi ripetuti alla stessa informazione possano essere gestiti localmente, senza traffico di rete aggiuntivo. Poiché la memoria principale è sempre più piccola del disco, serve qualche algoritmo per determinare quali file o parti di file debbano essere tenute in cache. La granularità dei dati in cache può variare: l unità gestita dalla cache può essere l intero file oppure il blocco del disco. Se vengono tenuti in cache interi file, questi possono essere immagazzinati in modo contiguo sul disco (o comunque in pezzi molto grandi), permettendo trasferimenti ad alta velocità tra la memoria e il disco, e di conseguenza buone prestazioni. Il caching dei blocchi di disco, però, usa la cache e lo spazio su disco in maniera più efficiente. Di solito sono tenuti in cache più dati di quanti sarebbero necessari per soddisfare una singola richiesta, in modo che molti accessi possano essere serviti dai dati in cache. Il caching ha le migliori prestazioni quando il flusso di accessi presenta località di riferimenti. Aumentare la dimensione dell unità di cache aumenta la probabilità che i dati per il prossimo accesso siano disponibili localmente, e riduce il sovraccarico della rete. D altra parte, aumentano anche il tempo richiesto per il trasferimento dei dati e la probabilità che sorgano problemi di consistenza. Inoltre, la dimensione della cache è limitata, perciò è necessario decidere cosa fare quando essa si riempie: serve una politica di sostituzione. Considerando che i riferimenti alla cache in genere sono molto meno frequenti di quelli alla memoria, si può usare un implementazione dell LRU con liste collegate. Quando si deve per forza togliere qualcosa, si sceglie il blocco più vecchio: se esiste una copia aggiornata sul disco, la copia in cache viene semplicemente eliminata, altrimenti prima bisogna aggiornare il disco. Tenere la cache nella memoria principale del server, rispetto a tenerla nel disco del client, è generalmente più veloce e comunque molto più semplice. Naturalmente, se si usano grandi quantità di dati, una cache sul disco del client potrebbe essere migliore. Quando invece si vuole decidere se tenere la cache nella memoria principale del client o nel disco del client, è necessario trovare un compromesso tra spazio e prestazioni: il disco ha più capacità e fornisce maggiore affidabilità, ma se si considera il tempo di accesso ai dati, è più lento. La maggior parte dei sistemi che fanno il caching nei client lo fanno nella memoria principale, il che permette l utilizzo di stazioni di lavoro prive di disco e rende l accesso ai dati più rapido. L approccio più semplice consiste nel fare il caching dei file direttamente all interno dello spazio di indirizzi del processo; quando questo termina, tutti i file 42

61 Stili architetturali Collaborazione basata su File System modificati vengono scritti sul server. Anche se questo schema ha un sovraccarico estremamente basso, è efficace solo se i singoli processi aprono e chiudono i file ripetutamente. Il secondo posto in cui mettere la cache è nel kernel. Lo svantaggio è che c è bisogno di una chiamata al kernel anche quando il dato richiesto è disponibile nella cache, ma ciò è compensato dal fatto che la cache sopravvive al processo. Si supponga che un compilatore a due passi venga eseguito come due processi: il primo passo scrive un file intermedio, il quale viene letto dal secondo passo. Quando il processo del primo passo termina, il file intermedio probabilmente si trova nella cache, perciò non c è bisogno di nessuna chiamata al server quando il processo del secondo passo lo legge. Altrimenti, si può avere un processo separato che gestisca la cache a livello utente. Il vantaggio di questa soluzione è che si tiene il kernel separato dal codice del file system. Il caching nel client introduce inconsistenza nel sistema. Se esistono più copie di un file nelle cache dei client, le modifiche di una cache devono essere propagate alla copia principale nel server e poi alle altre copie. Quando due client leggono contemporaneamente lo stesso file e poi lo modificano entrambi, sorgono vari problemi. Ad esempio, quando un terzo processo legge il file dal server ottiene la versione originale, non una delle due nuove. Questo problema può essere aggirato adottando la semantica delle sessioni, la quale dichiara che gli effetti della modifica di un file non devono essere visibili globalmente finché il file non è chiuso. Un altro problema è che quando i due file vegono scritti sul server, quello scritto per ultimo sovrascriverà l altro. Un modo per risolvere il problema della consistenza è usare l algoritmo di scrittura diretta (write-through). Quando viene modificato un elemento della cache, il nuovo valore viene tenuto nella cache, ma viene anche inviato immediatamente al server. Di conseguenza, quando un altro processo legge il file riceve il valore più recente. Questo approccio garantisce una buona affidabilità in caso di guasti ai client. Si supponga adesso che un processo client sulla macchina A legga un certo file. Quando il client termina, la macchina tiene il file nella sua cache. In seguito un client sulla macchina B legge lo stesso file, lo modifica e lo scrive nel server. Infine, sulla macchina A viene iniziato un nuovo processo client, che apre e legge il file: questo viene preso dalla cache, ma purtroppo quella copia adesso risulta obsoleta. Una possibile soluzione è richiedere che il gestore della cache esegua un controllo sul server prima di fornire a qualsiasi client un file preso dalla cache. Un altro problema della scrittura diretta è che, nonostante sia utile per la lettura, nel caso di un operazione di scrittura il traffico della rete è lo stesso che si avrebbe se non ci fosse nessuna cache. Invece di aggiornare la copia del server nel momento in cui viene fatta la scrittura, il client può allora semplicemente prendere nota del fatto che un file è stato modificato, e poi a intervalli regolari raccogliere tutti gli aggiornamenti e inviarli al server contemporaneamente. Questa soluzione è nota come scrittura ritardata (delayed write), e sfrutta il fatto che un unica scrittura di massa di solito è più efficiente di tante piccole scritture singole. Inoltre, molti programmi creano file temporanei, li scrivono, li 43

62 Stili architetturali Collaborazione basata su File System rileggono, poi li cancellano, e tutto ciò avviene in rapida successione. Nel caso in cui questa sequenza abbia luogo e si concluda prima che sia il momento di inviare tutti i file modificati al server, un file già cancellato non viene affatto inviato al server. Il fatto di non aver bisogno di coinvolgere il server per i file temporanei può comportare un significativo aumento di performance. Naturalmente, ritardare le scritture sporca la semantica, perché quando un altro processo legge il file, può ottenere una cosa diversa a seconda del momento in cui effettua l accesso. Perciò, posticipare le scritture è un compromesso tra avere migliori prestazioni e una semantica più pulita, che si traduce in programmazione più semplice. La scrittura ritardata introduce anche problemi di affidabilità, poiché in caso di guasto ai client, vengono persi tutti i dati non ancora inviati al server. Le varianti dell algoritmo di scrittura ritardata si differenziano a seconda del momento in cui un dato in cache che è stato modificato dal client viene inviato al server; si dice che tale dato è sporco (dirty), e l azione di scrittura è detta flushing. Un dato può essere scritto quando sta per essere eliminato dalla cache del client. Altrimenti, si può decidere di adottare la semantica delle sessioni e scrivere un file sul server solo dopo che è stato chiuso: questa variante è chiamata scrittura su chiusura (write-on-close). Si può anche aspettare un certo tempo dopo la chiusura per vedere se il file sarà cancellato. Come già visto, questa strada implica che se due file in cache sono riscritti in successione, il secondo sovrascrive il primo: è analogo a ciò che accade in un sistema a singola CPU quando due processi aprono e leggono un file, lo modificano all interno del loro spazio di indirizzi, e poi lo scrivono. Inoltre, se i file sono aperti per tempi brevi oppure sono modificati raramente, questa politica non riduce significativamente il traffico della rete. metodo write-through delayed write write-on-close proprietà funziona, ma non riduce il traffico per le scritture migliori prestazioni, ma la semantica può essere ambigua corrisponde alla semantica delle sessioni Tabella 1.6: Metodi per gestire la cache dei file nel client Nella tabella 1.6 sono riassunti i metodi appena visti per gestire la cache dei file nel client. Ogni client deve affrontare il problema di decidere se la copia di un file nella sua cache locale è consistente o meno con la copia principale sul server. Se la copia in cache è obsoleta, non può più essere utilizzata per gli accessi, e c è bisogno di ottenerne una aggiornata. Esistono due diversi approcci da utilizzare per verificare la validità dei dati nella cache. Secondo il metodo iniziato dal client, il client controlla la consistenza delle informazioni tramite una richiesta al server, che introduce un certo ritardo nelle richieste di accesso. 44

63 Stili architetturali Collaborazione basata su File System Il controllo può essere eseguito confrontando la data dell ultima modifica della versione in cache con quella della versione del server. Invece della data, si possono usare numeri di versione o checksum. Si può fare un controllo per ogni accesso alla cache, o uno solo all apertura del file, o richiederlo periodicamente. La frequenza con cui questa operazione viene ripetuta deve essere tale da evitare di creare eccessivo traffico nella rete. Secondo il metodo iniziato dal server, invece, il server tiene traccia dei file (o delle parti di file) che ciascun client tiene nella sua cache locale e se verifica situazioni di potenziale inconsistenza dei dati, richiede l aggiornamento. Se si usa la semantica delle sessioni, il server non deve essere notificato quando viene aperto un file già in cache, ma solo quando viene chiusa una sessione di scrittura. Per ogni richiesta di chiusura di un file modificato il server ordina ai client di invalidare le copie locali. Se invece si usa la semantica Unix, bisogna che il server sia notificato ogni volta che viene aperto un file, specificando la modalità desiderata, in modo che il caching di quel file possa essere disabilitato, se necessario, passando al funzionamento di servizio remoto. Un problema di questo metodo è che rovescia il modello client-server tradizionale, in cui è il client che richiede il servizio. Per riassumere l argomento caching nel suo insieme, il caching nel server è facile da fare e vale quasi sempre la pena farlo, a prescindere dalla presenza della cache nel client; esso non ha effetti sulla semantica del file system vista dai client. D altra parte, il caching nel client offre migliori prestazioni al prezzo di una maggiore complessità e possibili semantiche più confuse. C è una diretta analogia tra i metodi di accesso al disco nei file system convenzionali e i metodi di accesso remoto nei file system distribuiti. Un meccanismo di servizio remoto è analogo ad eseguire un accesso al disco per ogni richiesta. Uno schema di caching in un file system distribuito è un estensione delle tecniche di caching nei file system convenzionali: in questi ultimi lo scopo è ridurre l I/O del disco, mentre nei primi è ridurre il traffico sulla rete. Per questi motivi, il meccanismo di servizio remoto non è pratico. Molte implementazioni incorporano qualche forma di caching per migliorare le performance, e possono essere pensate come un ibrido tra caching e servizio remoto File Area Network Da un punto di vista storico il metodo più utilizzato per esporre dati ad un elevato bacino di utenza e condividerli in maniera collaborativa è stato l uso di una porzione condivisa di File System. Questa metodologia assodata anche nella prassi dell amministrazione di sistemi può essere estesa e portata nell infrastruttura IT applicando tecnologie mature e robuste. Questa soluzione ruota essenzialmente attorno alla risorsa file, quale entità a basso costo di memorizzazione e facile da trattare sia dallo specialista che dall utente medio. Attualmente, i dati non strutturati organizzati mediante file system, cioè 45

64 Stili architetturali Collaborazione basata su File System memorizzati sotto forma di file a cui le applicazioni e gli utenti possono accedere, rappresentano la maggior parte dei dati gestiti dalle organizzazioni. I dati strutturati si incontrano solo in rare eccezioni, come ad esempio nei sistemi per la gestione di database relazionali, i quali possiedono degli strumenti integrati per gestirli [Gee07]. Quando si devono spostare dei dati non strutturati, per aggiungere nuovi dispositivi di storage 4 o aggiornare quelli già esistenti, spesso è necessario interrompere l accesso da parte degli utenti e cambiare la mappatura tra la locazione fisica in cui i dati realmente risiedono e l indirizzo logico sfruttato dagli utenti per accedere ad essi. Inoltre, le organizzazioni possono voler classificare i dati a seconda dell uso che ne viene fatto, per determinare quale tipo di dispositivo di storage sia più adatto a memorizzare per quell informazione. Ad esempio, il materiale che deve essere salvato per conformità alle normative dovrà essere memorizzato persistentemente in un dispositivo più sicuro, mentre i file che non devono essere salvati e che non vengono usati regolarmente possono essere memorizzati in un dispositivo più lento e meno costoso. Negli ultimi tempi, il problema della crescita della quantità di file e della loro gestione ha assunto un importanza sempre maggiore, mettendo in discussione l adeguatezza dell approccio finora utilizzato per memorizzare i dati e accedere ad essi, poiché l incessante aumento della domanda di capacità di storage porta a infrastrutture sempre più complesse e costose [Wad07]. Questa crescente importanza ricoperta dai dati contenuti nei file ha portato alla necessità di trovare un modo migliore per eseguire il backup e lo spostamento dei dati non strutturati, e più in generale un nuovo paradigma che permetta di gestire in modo più semplice insiemi diversi di informazioni. Per questi motivi, è stato sviluppato un nuovo approccio alla gestione dei file, chiamato File Area Network (FAN). Il termine FAN sta ad indicare un architettura di riferimento, vista come modello logico per descrivere una classe emergente di tecnologie hardware e software, il cui scopo principale è quello di organizzare e gestire grandi quantità di file, senza bisogno di interrompere mai l accesso all informazione da parte degli utenti, fornendo così una piattaforma flessibile e intelligente per spostare e gestire i dati [Bur07]. In pratica, si tratta di un complemento alle infrastrutture di storage esistenti che semplifica la gestione dei dati, permettendo alle organizzazioni di gestire lo storage dei file senza un corrispondente aumento in costo e complessità. Oltre alla continua crescita dei dati non strutturati, un altro trend sta guidando l adozione delle tecnologie FAN: lo storage di rete. La memorizzazione dei dati si è evoluta da un modello in cui il dispositivo di storage era collegato ad un singolo computer oppure ad un insieme fisicamente connesso di computer contigui, ad un modello in cui lo storage è collegato attraverso la rete. Ciò ha reso più semplice e più flessibile l accesso da parte di utenti geograficamente dispersi nella rete, ed ha anche contribuito al diffondersi degli approcci basati sulla rete. 4 Con il termine storage si indicano i dispositivi hardware per l immagazzinamento di dati elettronici in modo non volatile. 46

65 Stili architetturali Collaborazione basata su File System La Storage Area Network (SAN), che divenne popolare a metà degli anni novanta, è un architettura tramite la quale i dispositivi di storage remoti sono visti come locali dal sistema operativo, il quale continua però ad usare il suo file system; è usata quando si richiede accesso ad alta velocità, a livello di blocco, ai dati memorizzati su disco. Il Network-Attached Storage (NAS), diffusosi anch esso più o meno nello stesso periodo, permette invece a molti computer di accedere tramite la rete allo stesso file system, usando appositi protocolli; in questo caso lo storage è visto come remoto, e i computer richiedono una porzione di un file anziché un blocco di disco. A differenza dei file server, i dispositivi NAS possiedono però solo il software necessario a memorizzare, accedere, e gestire i file. La maggior parte dei file server e dei dispositivi NAS utilizza uno storage SAN. Inoltre, tutti gli approcci allo storage si basano su formati di dati a blocchi, i quali sono gestiti da qualche tipo di file system o da un sistema per la gestione di database. Di conseguenza, la distinzione tra SAN e NAS sta diventando obsoleta. client WAN LAN FAN servizi di accesso e di rete ottimizzazione prestazioni controllo di accesso spazio dei nomi virtualizzazione dei file in rete file server storage storage storage Figura 1.12: Architettura di una File Area Network Come illustrato nella figura 1.12, l approccio FAN è realizzato attraverso un insieme di elementi diversi. Per abilitare la condivisione dei dati e delle risorse contenute nei file, una FAN sfrutta le infrastrutture di storage di rete esistenti, come le SAN, i file server di un file system distribuito, o i dispositivi NAS, che idealmente devono essere altamente scalabili e fornire alte prestazioni. Il concetto chiave attorno a cui ruota il funzionamento di una FAN è quello di uno spazio dei nomi unificato e globale. Sostanzialmente, uno spazio dei nomi separa la locazione logica dei file da 47

66 Stili architetturali Collaborazione basata su File System quella fisica. Una FAN avrà quindi una tabella tramite la quale sarà in grado di tracciare quali file risiedono in una certa locazione fisica, e di far corrispondere quest ultima ad una locazione logica che non cambi mai nel tempo. Lo spazio dei nomi preserva i file system fisici esistenti, permettendo l accesso ad essi come se fossero un unica entità condivisa, e può essere visto come un astrazione logica che rappresenta un singolo punto di accesso alla sottostante infrastruttura fisica di storage per i file. In questo modo si introduce una virtualizzazione dei file che, oltre a fornire l abilità di organizzare, presentare, e memorizzare i dati in essi contenuti e a semplificare i compiti di amministrazione, permette di mascherare le complessità relative alla locazione fisica dei dati nella rete, e quindi di fornire agli utenti l accesso ininterrotto alle informazioni, a prescindere dalla loro posizione e dal fatto che essa cambi. Lo spazio dei nomi delle FAN supporta piattaforme e file system diversi; in genere sono utilizzati il Common Internet File System della Microsoft oppure il Network File System della Sun, ma le FAN funzionano con altre piattaforme. Una FAN è distribuita per natura, perciò la sua realizzazione prevede un instradamento (routing) dell informazione, dirigendo le richieste di file verso le appropriate risorse, e fornendo così agli utenti e alle applicazioni dei percorsi persistenti per accedere ai dati a prescindere dalla loro locazione. Come nel caso delle funzioni di routing tradizionali, questa funzione si basa su metadati che riguardano la locazione fisica e le modalità di accesso. Inoltre, grazie alle FAN, le organizzazioni possono implementare dei servizi che forniscono una grande varietà di funzionalità, quali la migrazione, la replicazione, la classificazione e il posizionamento dei dati, il bilanciamento del carico e il controllo di accesso. Una FAN può giocare un ruolo essenziale anche nella gestione del ciclo di vita dell informazione (Information Lifecycle Management, ILM) e dei contenuti aziendali (Enterprise Content Management, ECM). Per la gestione dei file, le FAN eseguono un software che può leggere al loro interno per vedere quali informazioni contengono, e ne raccoglie e verifica i metadati, riuscendo così a posizionare i dati nel dispositivo di storage più appropriato (es. basandosi sulla sua frequenza d uso). Tra i servizi di ottimizzazione dei file c è anche l eliminazione dei dati duplicati: quando una compagnia crea una copia di un file che già possiede, la FAN può semplicemente aggiungere un puntatore, ossia un collegamento al file originale, nel server che opera la virtualizzazione e che realizza l interfaccia esposta ai client. La connessione in rete delle FAN è ottenuta tramite una LAN o una WAN. Le richieste di file possono essere ricevute in qualsiasi punto della rete ed essere trasmesse a qualsiasi altro dispositivo all interno della FAN. I client che accedono allo spazio dei nomi possono essere su qualsiasi tipo di piattaforma o dispositivo. Le FAN migliorano la connettività per gli utenti remoti, ad esempio attraverso il caching dei dati, cioè memorizzando il materiale a cui si accede frequentemente per velocizzare gli accessi stessi, o la compressione dei dati, rendendo le informazioni più veloci da comunicare. Le FAN sono in grado di eseguire il caching dei file nei siti remoti e memo- 48

67 Stili architetturali Collaborazione basata su File System rizzare una copia in una locazione centrale su cui è possibile eseguire il backup, evitando i backup remoti. Non interrompendo l accesso ai dati da parte degli utenti ed automatizzano il backup, la migrazione e la replicazione dei dati. Le FAN sono economicamente convenienti, in quanto aumentano l efficienza dei sistemi di storage e riducono la quantità di storage necessaria, eliminando la duplicazione incontrollata dei dati. L attuale mancanza di uno standard introduce il problema dell interoperabilità tra le FAN di produttori diversi. Accordandosi su un comune modello architetturale di riferimento e implementandolo, sia gli utenti che i venditori riuscirebbero ad ottenere un efficienza molto maggiore. Proprio al fine di trovare una standardizzazione, la Storage Network Industry Association (SNIA) ha formato una FAN Task Force, la quale ha provvisoriamente definito una FAN come un infrastruttura orientata alla rete, basata su uno spazio dei nomi per i file, con uno strato di disaccoppiamento che separa l accesso logico ai file dalla loro locazione fisica, permettendo di applicare ai file e ai file system una varietà di servizi, come ad esempio la migrazione e la replicazione. Oggi le FAN introducono soluzioni semplici da usare per i compiti elementari di gestione dei file, come lo spostamento e il posizionamento dei dati. In futuro, i servizi offerti dalle FAN costituiranno un ponte tra le applicazioni e le risorse memorizzate nei file, realizzando funzionalità a lungo attese come la scalabilità globale, l accesso trasparente e sicuro ai dati e la gestione efficiente e centralizzata dello storage e dei dati Distributed Version File System Da Luglio 2008 alla Codethink (nelle persone di Karl Lattimer, Rob Taylor e Mark Doffman) stanno lavorando ad un nuovo progetto chiamato Wizbit [Lat08] per implementare un file system condiviso che abbia integrato il supporto al DVCS (Distributed Version Vontrol System). Sebbene il progetto sia enormemente immaturo e al momento di scarsi risultati, si pone in una posizione innovativa interessante. Come è possibile vedere dalla wikipage del progetto, Wizbit si presenta in risposta a problemi pratici di backup, traccimento e condivisione in un contesto collaborativo. Propone quindi di: mantenere, in modo automatico, uno storico di ciò che accade ai nostri dati; gestire la condivisione tra diversi dispositivi di storage e il merge di versioni diverse; permettere accessi concorrenti risolvendo in modo trasparente eventuali conflitti; garantire la possibilità di lavorare offline. 49

68 Stili architetturali Collaborazione basata su File System Tutto questo risolverebbe gli inconvenienti che spesso si presentano attualmente: dati sparsi su dispositivi diversi che possono, tra l altro, contenere versioni differenti dello stesso file e l impossibilità di tornare a come erano i documenti nel passato o recuperarli dalla cancellazione. Con una metodologia puramente pragmatico-implementativa hanno iniziato la stesura del codice in linguaggio Python, riusando il noto version control system Git [Bau08], mantenendo per ogni file, che viene referenziato, un UUID (Universal Unique Identifier), archiviato in un distinto repository (codificando la struttura in XML). Purtroppo l elaborazione dei file con UUID in repository distinti era molto pesante. Inoltre sebbene i singoli file venissero versionati, la struttura della directory non lo era. Quindi decisero di non utilizzare direttamente il codice di Git (che tra l altro ignora il problema della sicurezza). Migrarono al riuso di Bzr (BaZaR Version Vontrol) [Can08], optando per riscrittura in linguaggio C, mantenendo i concetti alla base di Git. Del Git attualmente resta la struttura ad oggetti (blob, commit e tree), archiviati in file compressi e possono che contengono dati o metadati (i metadati allo stadio attuale vengono creati da tracker software). Nell idea iniziale i file vengono identificati tramite un identificatore universale (UUID), perciò anche il nome del file è considerato un metadato (questo apre la possibilità di salvare un file senza indicarne il nome). A differenza del Git vengono utilizzati alberi con due soli elementi blob (separando fisicamente i dati dai metadati) (figura 1.13). B C T B Figura 1.13: Formato dell albero in Wizbit Attualmente si stanno concentrando sulla creazione di un archivio di oggetti distribuito (in seguito hanno però programmato di includere come opzioni sia FUSE che GVFS in modo da renderlo un reale file system distribuito). Gli oggetti, chiamati Bit, possono contenere informazioni eterogenee (es. annotazioni, appuntamenti di un calendario, contatti); la prima versione di un oggetto è chiamata Root. Successivamente ad ogni modifica, il Bit è revisionato e viene creata una nuova versione. Ogni Bit ha una serie di Tip, cioè di puntatori alle versioni, che disegnano la sua storia. Da ogni Tip ci si può ricondurre alla radice. All apertura del file la versione visualizzata è quella più recente: il Tip che la punta è chiamato Primary Tip mentre gli altri Tip vengono chiamati Normal. Il database che contiene tutti i dati dei commit e le loro reciproche relazioni viene chiamato Commit Store. 50

69 Stili architetturali Collaborazione basata su File System Per il momento non è supportata supportata la possibilità di liberare spazio, perchè cancellare un file implicherebbe dover cancellare tutta la storia dei commit (questo fa sì, inoltre, che i file temporanei debbano essere evitati). Ultimamente i programmatori hanno deciso di smettere di programmare in C e passare a Vala (un nuovo linguaggio che permette di utilizzare tecniche di programmazione moderne per scrivere applicazioni GNOME, il compilatore Vala non crea codice eseguibile, ma traduce in linguaggio C), è stata, inoltre, implementato un tool per spostarsi (timeline) tra i vari commit. Sebbene Wizbit sia male documentato (molte informazioni sono irreperibili) e non rappresenti ancora una soluzione seriamente implementata, ha una visione innovativa e lungimirante per l integrazione di funzionalità e caratteristiche solitamente considerate pertinenti a disgiunti settori di ricerca e sviluppo. Ad esempio soluzioni industriali come Global File System (GFS)[KAJ + 99, SH02] di Red Hat, Inc. e Zettabyte File System (ZFS)[Mic08] di Sun Microsystem si limitano ai soli aspetti di file system distribuito, trascurando le problematiche di versioning. Allo stato attuale l aspetto critico del progetto è la sua immaturità, come si può evincere dalla sua evoluzione, adotta una metodologia di progettazione fortemente incentrata sul bazaar[ray02], senza beneficiare ancora dell effetto network. 51

70 Capitolo 2 Stili di autenticazione Gli accessi illegittimi ai dati memorizzati sui sistemi di elaborazione, la compromissione o il furto di questi, l intercettazione di comunicazioni con contenuti riservati, rappresentano oggi una grave minaccia, sempre più difficile da contrastare. La costante apertura di nuove reti verso Internet, unita alla rapida crescita di connessioni di tipo permanente, anche tra le utenze private, ha creato un fertile terreno per questo genere di minacce in quanto, a causa della continua immissione in rete di nuovi sistemi e servizi, sono cresciuti esponenzialmente i possibili bersagli da attaccare. I rischi legati alla comunicazione di informazioni su Web coinvolgono interessi sociali, politici ed economici. All aumentare degli interessi e del numero di partecipanti cresce anche il numero di malintenzionati che intendono trarre facilmente dei benefici in modo fraudolento o non legalmente corretto. All aumentare del rischio c è quindi una sensibilizzazione verso il concetto di sicurezza in quanto è nell indole umana attuare delle azioni a seguito di una valutazione (in modo più o meno consapevole) del rapporto benefici/rischi sui servizi usati. All aumentare del rischio il rapporto scende e questo potrebbe rallentarne notevolmente la diffusione o il successo. D altronde i benefici apportati dal Web sono sotto gli occhi di tutti anche se è stato necessario applicare tutte quelle strategie e tecnologie convenienti per rendere la sicurezza delle reti di computer accettabile 1, permettendo quindi di trasformare oppurtunità potenziali in vantaggi concreti. Alla luce di questo si rende necessario implementare efficaci politiche di sicurezza capaci di contrastare dinamicamente questi pericoli, che minano sia la 1 È doversoso sottolineare che accettabile non significa migliore possibile. Questo perché soluzioni troppo spinte tendono a risultare molto costose ed a limitare eccessivamente l utente nelle azioni che può compiere.

71 Stili di autenticazione Elementi di crittografia sicurezza del singolo utente privato, sia quella delle grandi reti informatiche aziendali. Sebbene l elevata dinamicità di questo ambiente, in continua evoluzione secondo tempistiche e modalità assolutamente imprevedibili, non consenta di essere esaustivi, si cercherà di contrastare questa limitazione mediante l esposizione dei concetti chiave alla base di ogni tecnica. Inizialmente saranno forniti alcuni cenni sulla tecnica cardine attorno al quale ruota l universo della sicurezza informatica: la crittografia. Al giorno d oggi infatti, data la semplicità con la quale risulta possibile intercettare i dati che transitano sulla rete, un qualunque sistema che si appoggia all infrastruttura di comunicazione (che intenda offrire il minimo di sicurezza accettabile anche per applicazioni non critiche) deve offrire quantomeno un canale confidenziale per lo scambio delle credenziali 2 dell utente. Verranno evidenziate le opportunità che essa offre nella sua applicazione: dalla confidenzialità al non ripudio, dall autenticazione all integrità dei dati. Ciò permetterà di valutare le principali tecnologie disponibili per la trasmissione confidenziale dei dati sulle reti di comunicazione, a garanzia che l interlocutore (in termini di sistema informativo) con il quale l utente sta comunicando sia realmente quello atteso e che solo coloro preventivamente autorizzati possano accedere ai dati riservati. Le tecnologie selezionate, PKI, OpenID e Kerberos, si evidenziano principalmente per essere soluzioni di autenticazione, con un approccio infrastrutturale distribuito. L identificare l utente ed autorizzare l utente identificato sono attività particolarmente critiche in uno scenario come quello discusso nel presente lavoro di tesi. 2.1 Elementi di crittografia La rete, per sua natura, è un mezzo che permette la trasmissione dei dati in modo non sicuro. Ovviamente occorre specificare cosa si intende con modo sicuro in quanto garanzie come quelle relative all integrità dei dati vengono offerte (nello specifico dal protocollo TCP). Normalmente infatti con canale sicuro si intende un canale che, oltre all affidabilità, offra confidenzialità nella comunicazione; e questa non è una caratteristica propria delle reti di telecomunicazioni a meno che non la si vada a ricercare esplicitamente. Un altra condizione che può essere necessario andare a soddisfare consiste nell avere una ragionevole certezza sull identità degli interlocutori: in un mondo fatto di informazioni è molto facile presentarsi con una identità non corrispondente al vero, persino rubata. Inoltre esistono tecniche che permettono di ingannare gli elementi di rete riguardo al proprio indirizzo IP o MAC. A queste, ed anche altre, problematiche si può dare risposta adottando varie tecnologie basate sull uso della crittografia. Il termine Crittografia deriva dalle parole greche kryptós, nascosto, e graphein, scrivere. La crittografia [TW97] è infatti una disciplina della matematica nata per assicurare la riservatezza nelle comunicazioni, cioè per trasformare 2 Insieme delle informazioni che permettono di identificare, con una certa affidabilità, l utente che normalmente intende accedere ad un sistema. L esempio più semplice, noto ed utilizzato è la coppia nome utente - password. 53

72 Stili di autenticazione Elementi di crittografia un messaggio da trasmettere (testo in chiaro) in qualcosa di incomprensibile a chiunque non sia il destinatario previsto (testo cifrato). Il suo scopo iniziale era dunque quello di nascondere il significato di un messaggio più che la sua esistenza. L arte di nascondere l esistenza stessa del messaggio, a chiunque tranne che al destinatario legittimo, è invece detta steganografia. La crittografia è ormai utilizzata in una grande quantità di applicazioni con le quali interagiamo ogni giorno; il commercio elettronico, i servizi bancari o la comunicazione mobile e satellitare sono solo alcuni esempi degli innumerevoli contesti in cui viene utilizzata. In particolare ha assunto un ruolo centrale in tutta la gestione della sicurezza dei sistemi informatici e nelle reti di computer; la potenza di calcolo oggi disponibile costituisce un grande supporto allo sviluppo e all utilizzo della crittografia. Il suo campo di applicazione si è espanso molto includendo tecniche atte alla gestione di tutti i problemi di sicurezza conosciuti. Questi possono essere suddivisi in quattro aree fondamentali. Confidenzialità. L informazione risulta accessibile solo a chi ha il diritto di usufruirne. Integrità dei dati. È possibile determinare se i dati siano stati manipolati senza autorizzazione. Autenticazione. entità. Permette l identificazione di un messaggio o di una Non ripudiabilità. Rende impossibile che una entità neghi di aver costruito un certo messaggio crittato. Per chiarire la terminologia adottata, si definisce algoritmo di cifratura la trasformazione matematica utilizzata per ottenere il testo cifrato e algoritmo di decifratura la trasformazione inversa utile alla ricostruzione del messaggio in chiaro. Le trasformazioni di cifratura possono essere distinte in due classi: i cifrari e i codici. Col primo termine si intendono tutte quelle trasformazioni che manipolano la codifica del testo in chiaro, bit per bit, cioé senza considerare la struttura del messaggio; il secondo termine identifica quegli algoritmi che sostituiscono ogni parola con un altra o un simbolo. I codici ormai non vengono più usati ma hanno comunque alle loro spalle un passato glorioso [Kah67]. Gli algoritmi, siano essi di cifratura che di decifratura, accettano in genere due parametri: il messaggio e la chiave; quest ultima è una stringa relativamente corta che serve a modulare il comportamento degli algoritmi: in pratica fissano una particolare trasformazione all interno dello spazio di possibilità individuato da uno specifico algoritmo. In questo modo è necessario tenere nascosta esclusivamente la chiave ed è possibile divulgare l algoritmo; cercare di tenerlo segreto, pratica definita sicurezza per occultamento, non ha mai funzionato. Inoltre rendere disponibile, e quindi studiabile, un algoritmo, di qualunque natura esso sia, è sempre positivo se non altro per via della spontanea consulenza fornita dalla comunità di esperti del settore. L idea che l algoritmo sia noto e che il 54

73 Stili di autenticazione Elementi di crittografia Figura 2.1: Crittografia a chiave privata - cifratura Figura 2.2: Crittografia a chiave privata - decifratura segreto stia esclusivamente nella chiave è detta principio di Kerckhoffs, dal nome del crittografo fiammingo Auguste Kerckhoffs che per primo lo formulò nel 1883 [Ker83]. La notazione utilizzata per trattare questo tipo di argomenti è la seguente: con C = E K (P ) si intende l operazione di cifratura del testo in chiaro P usando la chiave K ottenendo come risultato C; analogamente P = D K (C) indica l operazione di decifratura mirata all ottenimento del testo in chiaro. Da ciò segue che D K (E K (P )) = P Crittografia a chiave privata La crittografia a chiave privata, detta anche crittografia simmetrica, tratta quei metodi crittografici in cui sia il mittente che il destinatario condividono la stessa chiave o, meno comunemente, possiedono due chiavi diverse ma legate in modo semplice da un punto di vista computazionale. Fino al 1976 è stata l unica forma crittografica nota. Gli algoritmi a chiave privata possono essere suddivisi in cifrari a flusso e cifrari a blocco; i primi cifrano i bit del messaggio uno per uno mentre i secondi lavorano su insiemi di bit considerandoli come una singola unità. Questo tipo di crittografia permette di ottenere confidenzialità del messaggio: se un utente A vuole comunicare in maniera sicura con un utente B è sufficiente cifrare il messaggio con la chiave segreta. Solo chi è in possesso della chiave potrà decifrare correttamente il messaggio applicando l algoritmo di decifratura necessario. La crittografia a chiave privata non può essere utilizzata per risolvere proble- 55

74 Stili di autenticazione Elementi di crittografia mi di autenticazione e non ripudiabilità in quanto la stessa chiave è conosciuta sia dal mittente che dal destinatario di una conversazione; entrambi possono sfruttare di questo privilegio. Alcuni esempi illustri di algoritmi a chiave privata sono Twofish [Sch99], Serpent [RA98], AES [NIS01], RC6 [RRSY98], DES [NIS99] e 3DES [NB04] Crittografia a chiave pubblica Il più grande problema della crittografia a chiave privata è senza dubbio la gestione delle chiavi. Ogni coppia di interlocutori deve condividere una propria chiave segreta, portando ad un numero complessivo di chiavi che cresce col quadrato del numero di interlocutori. Inoltre è sempre presente il problema di come scambiarsi la chiave segreta quando ancora non è disponibile un canale sicuro di comunicazione. Nel 1976 è stata presentata una nuova forma di crittografia: la crittografia a chiave pubblica; questa permette a due interlocutori di comunicare in maniera sicura senza dover prima concordare una chiave segreta condivisa. Ciò è reso possibile grazie all utilizzo di una coppia di chiavi crittografiche, denominate chiave pubblica e chiave privata, legate fra loro da un rapporto di tipo matematico. Il legame deve essere tale da rendere virtualmente impossibile ottenere la chiave privata a partire da quella pubblica e viceversa. In generale gli algoritmi a chiave pubblica sono computazionalmente molto più complessi, e quindi più lenti, di quelli a chiave privata, fino a 3 ordini di grandezza, ma permettono di fornire una soluzione a una ampia varietà di problemi di sicurezza. Ogni utente dispone di una coppia di chiavi ed è sua cura generarle; la chiave pubblica può essere distribuita liberamente, e aggiunta, per esempio, ad un elenco pubblico, mentre la sua controparte privata deve restare segreta. La prima viene utilizzata tipicamente per cifrare mentre la seconda per decifrare. Questo tipo di crittografia permette di ottenere non solo confidenzialità del messaggio in modo molto flessibile, ma anche autenticazione e non-ripudiabilità. Se un utente A vuole comunicare in maniera sicura con un utente B è sufficiente cifrare il messaggio con la chiave pubblica del destinatario. In questo modo solo B sarà in grado di leggere il contenuto del messaggio utilizzando la propria chiave privata. Se poi, prima di essere inviato, il messaggio viene nuovamente cifrato ma stavolta con la chiave privata del mittente è possibile ottenere anche autenticazione e non-ripudiabilità. Infatti per ottenere il contenuto del messaggio il destinatario dovrà decifrarlo due volte, prima utilizzando la chiave pubblica del mittente e poi la propria chiave privata. Egli sarà dunque sicuro dell identità del mittente, della confidenzialità del messaggio e, in ultima istanza, il mittente non potrà non riconoscere di aver costruito il messaggio. La descrizione può essere effettuata anche esaminando il modo in cui le chiavi vengono utilizzate. Se un utente vuole ottenere confidenzialità dovrà cifrare il messaggio con la chiave pubblica del destinatario di modo che solo lui possa leggerlo, essendo in possesso della chiave segreta. Se invece volesse ottenere autenticazione e non-ripudiabilità dovrebbe cifrare il messaggio con la propria 56

75 Stili di autenticazione Elementi di crittografia Figura 2.3: Crittografia a chiave pubblica chiave privata; l identità del mittente sarebbe provata dalla corretta decifratura del messaggio a mezzo della sua chiave pubblica. L esempio più significativo, per diffusione e robustezza, di algoritmo a chiave pubblica è senza dubbio l RSA [Kal98] Crittografia e firma digitale Al di fuori del contesto informatico, per poter considerare valido un documento è necessaria la presenza di una firma autografa autorizzata che lo accompagni. È quindi necessario trovare un meccanismo equivalente per verificare la validità dei documenti elettronici. In pratica è necessario trovare un sistema col quale un utente possa inviare un messaggio firmato al destinatario alle seguenti condizioni: il destinatario può verificare l identità del mittente. In uno schema di funzionamento basato su diritti di accesso è fondamentale identificare con certezza il mittente di un messaggio, per esempio, per controllare se quella specifica identità ha diritto di richiedere un determinato servizio; il mittente non può ripudiare il contenuto del messaggio. Deve essere impossibile per il mittente negare di aver costruito e firmato un qualsiasi messaggio, la firma deve costituire prova certa del coinvolgimento del mittente nella comunicazione. Questo requisito è necessario per proteggere il destinatario; il destinatario non può falsificare i messaggi ricevuti. In questo modo non può essere attribuito al mittente un messaggio non inviato e i documenti firmati non possono essere alterati se non dall autore. Questo requisito è necessario per proteggere il mittente. 57

76 Stili di autenticazione Elementi di crittografia Anche se esistono degli schemi di firma digitale basata sulla crittografia simmetrica è la crittografia a chiave pubblica ad essere comunemente utilizzata in questo tipo di operazioni. Generalmente per utilizzare le firme digitali sono necessari tre algoritmi: un algoritmo di generazione delle chiavi; un algoritmo per firmare i documenti; un algoritmo di verifica. Se un utente A vuole inviare un messaggio ad un utente B in modo che quest ultimo sia sicuro dell identità del suo interlocutore, non dovrà far altro che allegarvi una firma digitale. Questa, generata a partire dalla chiave privata di A, non è altro che una stringa di caratteri. Una volta ricevuto il messaggio, B controllerà la genuinità della comunicazione tramite l algoritmo di verifica utilizzando la chiave pubblica di A. Se l esito è positivo, B è certo dell identità del mittente; questo perchè gli algoritmi per la firma digitale sono appositamente costruiti per rendere impraticabile, per via della complessità computazionale del problema, la costruzione di una firma per un dato messaggio senza conoscere la chiave privata. Per dare alla firma una validità legale è necessario poter associare la chiave pubblica all identità di una persona. Per fare ciò una autorità di certificazione rilascia quello che viene chiamato certificato digitale firmandolo con la propria chiave privata. In questo modo chiunque sarà in grado di verificarne la genuinità utilizzando la chiave pubblica dell ente. Esistono vari formati per i certificati a chiave pubblica ma il più usato è lo standard X.509 [HFPS99] Funzioni hash Una funzione hash è una funzione univoca e non invertibile che trasforma un testo di lunghezza arbitraria in una stringa di lunghezza fissa detta valore hash, checksum crittografico o message digest. Nel caso specifico la funzione di trasformazione opera sui bit di un qualsiasi file generando una impronta digitale dello stesso. Dato che i possibili input dell algoritmo, con dimensione finita maggiore dell hash, sono più degli hash possibili è ovvio che possano esistere messaggi diversi che vengono mappati nello stesso digest. In questo caso si parla di collisione e le funzioni devono essere costruite per minimizzarne la realizzabilità. Inoltre una funzione ritenuta sicura non dovrebbe permettere di risalire, in un tempo congruo con la dimensione dell hash, al testo da cui il digest è derivato. In crittografia le funzioni hash vengono utilizzate per verificare l integrità di un messaggio dato che anche una piccola modifica dell input genera un message digest completamente differente. È sufficiente inviare il valore hash insieme al messaggio e il destinatario sarà in grado di determinare se è stato modificato durante il trasferimento, intenzionalmente o meno. Questo tipo di operazione è definito controllo di ridondanza (figura 2.4). Sotto determinate condizioni, come la conoscenza della distribuzione delle possibili perturbazioni e l utilizzo di una funzione hash adatta, è possibile correggere gli errori. Questa classe di funzioni è chiamata codici a correzione d errore. 58

77 Stili di autenticazione Public Key Infrastructure Figura 2.4: Funzioni hash - controllo di ridondanza Le funzioni hash possono essere utilizzate per creare velocemente le firme digitali anche per file di grandi dimensioni: invece di firmare tutto il documento, operazione che richiede calcoli lunghi e complessi per via degli algoritmi di crittografia asimmetrica impiegati, risulta computazionalmente più conveniente autenticare solo il message digest dello stesso. Questo, tra le altre cose, permette anche di creare documenti di cui può essere verificata l integrità ma che non devono essere obbligatoriamente crittati: il messaggio è infatti trasmesso in chiaro ma accompagnato da una firma digitale calcolata solo sul valore hash. Alcuni esempi di algoritmi hash sono MD4 [Riv92a], MD5 [Riv92b] e SHA-1 [EJ01]. 2.2 Public Key Infrastructure Come è stato introdotto nel paragrafo 2.1, la crittografia asimmetrica offre una serie di opportunità che riguardano la confidenzialità e l integrità dei dati, l identificabilità certa dei messaggi e delle entità in gioco (autenticazione) e la non ripudiabilità. Ovviamente non è la tecnologia di per se a garantire che queste opportunità si trasformino in vantaggi concreti, ma l uso che ne viene fatto. A esempio, il fornire ad un utente una coppia di chiavi asimmetriche non garantisce che, tramite le stesse, sia possibile identificare i messaggi di posta elettronica da esso inviati: banalmente l utente potrebbe non utilizzare le chiavi per firmare le , per non parlare del più insidioso problema che nasce se esso non riesce a mantenere segreta la propria chiave privata. In quest ultimo caso infatti, potrebbe essere possibile imbattersi in un caso di sicurezza apparente: confidando sulle potenzialità della crittografia si potrebbe pensare che un 59

78 Stili di autenticazione Public Key Infrastructure certo messaggio di posta sia riconducibile ad un determinato utente quando in realtà, non essendo esso riuscito a mantenere segreta la chiave privata, chiunque (ovviamente in grado di accedere alla stessa) avrebbe potuto firmare l al posto dell utente, eventualmente ignaro della situazione, spacciandosi per esso. È chiaro quindi che la sicurezza non è un traguardo che si raggiunge esclusivamente con mezzi tecnici, ma riguarda moltissimo i processi e tutte le entità, individui compresi, che vi ruotano attorno. Per questo motivo, come sarà illustrato nel presente paragrafo, è necessario fissare tutta una serie di vincoli e procedure operative, oltre alle soluzioni prettamente tecniche, per raggiungere dei risultati in questo contesto che abbiano una qualità accettabile. Le infrastrutture a chiave pubblica (PKI, Public Key Infrasctructure) sono quindi delle soluzioni tecniche, organizzative, politiche e quant altro il cui obiettivo è quello di esprimere nel mondo reale le potenzialità della crittografia asimmetrica. Appare chiaro che una PKI non è un metodo di autenticazione [Shi04], ma un infrastruttura che, pur utilizzando i certificati digitali come metodo di autenticazione, ha lo scopo di stabilire le modalità tecniche ed i processi organizzativi necessari per il rilascio e la gestione dei certificati (con le relative chiavi) in modo efficace, sicuro ed efficiente Elementi costituenti una PKI Le PKI possono essere realizzate in contesti diversificati. Ad esempio le aziende possono realizzarsi delle PKI private per l assegnazione dei certificati validi esclusivamente all interno dell azienda stessa, come trovare realtà affermate che rilasciano certificati per l utenza Internet. Indipendentemente dal contesto, parlare di PKI significa andare a chiamare in causa una serie di entità, ognuna delle quali ha uno scopo ben preciso: almeno una certification authority (CA) per l emissione dei certificati; un insieme di politiche prestabilite per la gestione di ognuna delle possibili operazioni effettuabili dalla PKI; un insieme di certificati digitali; un insieme di applicazioni in grado di usufruire dei servizi forniti dalla PKI Le Certification Authority Le CA sono ovviamente il cuore di ogni PKI ed ogni PKI ne ha almeno una. Sono costituite da un software per la gestione di certificati (detto CPS, Cryptographic Service Provider) e da una coppia di chiavi asimmetriche di cui quella pubblica firmata digitalmente (è un certificato a tutti gli effetti). Solitamente si realizzano soluzioni con più CA organizzate gerarchicamente. In questo caso si ha almeno una root CA al livello più alto della gerarchia che viene utilizzata esclusivamente per creare e firmare i certificati propri delle CA 60

79 Stili di autenticazione Public Key Infrastructure di livello inferiore. La root CA utilizza un certificato digitale self-signed (autofirmato) in quanto è l elemento di partenza della catena di trust al quale viene fornita fiducia per definizione. Questo fa capire il motivo per il quale le root CA non dovrebbero essere utilizzate per emettere i certificati ad eccezioni di quelli per le CA di livello inferiore: è assolutamente prioritario mantenere tale categoria di CA al sicuro, in quanto la compromissione delle stesse equivale alla compromissione dell intera catena di trust ovvero di tutta la PKI. Normalmente quindi le root CA vengono mantenute al sicuro, disconnesse dalla rete e non accessibili fisicamente. L architettura più generale (aggiungere ulteriori livelli, seppur fattibile da un punto di vista pratico, non apporta ulteriori vantaggi) prevede una gerarchia a tre livelli in cui: al livello più alto si collocano le root CA; al livello intermedio le Certification Policy Certification Authority (o più brevemente Policy CA); infine al livello più basso le Issuing Certification Authority (o più brevemente Issuing CA). Root-0 CA X X Policy-0 CA X X X X X X Revoca Cert. X X X X X X Issuing-n CA Rilascio Cert. Policy-1 CA Anni Mesi Giorni/Ore Frequenza Rilasci/Revoche (ordini di grandezza a titolo esemplificativo) User Server Figura 2.5: Struttura gerarchica delle CA di una PKI. 61

80 Stili di autenticazione Public Key Infrastructure In questo scenario, figura 2.5, l unico scopo delle root CA è quello di emettere (e, qualora necessario, revocare) i certificati ed eventualmente di generare le chiavi per le Policy CA; quest ultime sono destinate a firmare (e, se necessario, revocare) i certificati ed eventualmente a generare le chiavi per le Issuing CA. Sono infine quest ultime destinate a generare le chiavi (se necessario) ed emettere (ed eventualmente revocare) i certificati degli utenti (e delle applicazioni) della PKI. Questo approccio permette di mantenere le root CA al sicuro anche in contesti fortemente distribuiti (ad esempio multinazionali con sedi dislocate in tutto il mondo) nei quali si riesce ad ottenere la sufficiente flessibilità nel rilascio e nella revoca delle Issuing CA attraverso le Policy CA. Questo perché le Issuing CA, dovendo operare quotidianamente per il rilascio e la revoca dei certificati, sono esposte a compromissioni ed in tal caso è necessario revocarle (la revoca dei certificati, e conseguentemente l invalidazione di tutto ciò che è stato firmato con gli stessi, è un argomento trattato successivamente). Viceversa le Policy CA e, a maggior ragione, le root CA entrano in gioco solo raramente e ciò consente di garantirne l integrità mantenendole in luogo sicuro disconnesse dalla rete. In ogni caso è frequente l implementazione di PKI a due soli livelli in cui le root CA emettono direttamente i certificati per le Issuing CA Le Policy delle PKI Le policy relative ad una PKI servono per definire le regole necessarie a garantire la sicurezza delle chiavi, i processi di emissione, rinnovo e revoca dei certificati, le classi dei certificati (per utenti ad uso firma posta elettronica, per utenti ad uso accesso a servizi telematici, destinati a web server, destinati a server di posta,... ) ed i relativi dettagli (come la durata temporale predefinita) e quant altro. Per quanto riguarda la realizzazione di PKI pubbliche (ad esempio come quelle create da organizzazioni a fini commerciali come VeriSign) è necessario che venga redatto uno specifico documento detto Certificate Practice Statement (CPS). Il CPS dichiara le modalità con cui le chiavi vengono generate ed archiviate, le procedure di rilascio e revoca dei certificati, eccetera. Se la PKI è di tipo privato, non è richiesto che venga pubblicato il CPS, anche se è fortemente consigliato produrre una chiara documentazione relativamente alle metodologie utilizzate per validare l identità di coloro ai quali vengono rilasciati i certificati, nella quale si vadano ad indicare chi può revocare i certificati e come viene distribuita la lista contenente i certificati revocati, con quale frequenza e con quali modalità si procede per l archiviazione dei certificati ed infine quali sono le applicazioni autorizzazione e non autorizzate all uso dei certificati Rilascio, gestione e revoca dei certificati I processi inerenti al rilascio ed alla gestione dei certificati sono abbastanza complessi. In ogni caso è possibile descrivere una sequenza di operazioni che possono essere prese a riferimento per la descrizione del ciclo di vita di un certificato. Ciò non toglie che alcuni dei passi successivamente descritti possano 62

81 Stili di autenticazione Public Key Infrastructure non essere svolti oppure essere svolti in ordine diverso; resta comunque inteso che sono presenti alcuni vincoli che non possono essere violati. Si consideri quindi la seguente sequenza temporale di azioni: 1. l utente intende dotarsi di un certificato digitale per un motivo qualunque; 2. viene generata una coppia di chiavi asimmetriche da assegnargli. Si noti che normalmente sarà la CA a fornirgli tutto quello che serve, chiavi comprese, ma questo non è necessario: la generazione delle chiavi è un operazione da effettuare a monte, del tutto scorrelata dal resto. Inoltre è frequente l utilizzo della stessa coppia di chiavi per la generazione di più certificati; 3. l utente crea il Certificate Signing Request (CSR). Il CSR è il documento che viene inviato alla CA per l emissione del certificato. Come minimo contiene la chiave pubblica dell utente e tutte le informazioni necessarie per identificarlo univocamente (nel caso dei certificati X.509 il distinguished name), ma può contenere ulteriori informazioni come l indirizzo , la nazionalità, il paese eccetera. Il CSR viene creato dall utente firmando questo insieme di informazioni con la propria chiave privata; 4. la CA valida il CSR alla luce delle proprie policy; 5. in caso di esito positivo del passo precedente, la CA firma la chiave pubblica dell utente con la propria chiave privata creando di fatto il certificato; 6. il certificato viene fornito all utente il quale, in abbinamento alla propria chiave privata, può essere utilizzato per gli scopi del passo 1. Alcune considerazioni. In tutta la procedura, grazie alle caratteristiche della crittografia asimmetrica, le uniche entità da mantenere segrete sono solo le chiavi private. Tutto il resto può essere considerato pubblico, certificato compreso. Questo spiega il motivo per il quale spesso la stessa coppia di chiavi viene utilizzata per più certificati: una delle fasi più critiche di tutto il processo, se non la più critica in assoluto, è quella di fornire la coppia di chiavi all utente. In questa fase si evidenziano infatti due importanti criticità: la prima riguarda l identificazione certa del richiedente (secondo le modalità descritte nel CPS o nella documentazione equivalente), in quanto è assolutamente necessario che le chiavi vengano davvero fornite al legittimo proprietario (si pensi al fatto che la firma digitale, intesa nell accezione del Codice dell Amministrazione Digitale, è stata equiparata a tutti gli effetti alla firma autografa). Si noti che essendo il CSR emesso dal richiedente e firmato con la propria chiave privata, la CA, nell ipotesi in cui tali chiavi siano state fornite all utente secondo le opportune modalità, ha tutti gli strumenti per verificarne l attendibilità (andando a verificare la firma utilizzando la chiave pubblica dell utente); la seconda riguarda la confidenzialità della trasmissione delle chiavi: è assolutamente necessario che, anche se l utente è davvero il legittimo proprietario delle stesse, esse vengano fornite tramite un canale sicuro. Ovviamente se le chiavi finiscono nelle mani sbagliate, lo sono a prescindere 63

82 Stili di autenticazione Public Key Infrastructure dal fatto che siano state fornite alla persona sbagliata oppure che siano state intercettate da un soggetto terzo durante la trasmissione alla persona corretta. L emissione del certificato può avvenire, ovviamente, per scopi diversi. Fermo restando la validità delle chiavi e la corretta associazione con l utente, la validità del CSR eccetera, la CA, quando emette il certificato, va a specificare nello stesso per quali applicazioni può essere utilizzato oltre ad altre informazioni quali l intervallo temporale di validità. A titolo esemplificativo possono essere citati certificati validi solo per la firma di , per l utilizzo con applicazioni lato client (ad esempio per l autenticazione a reti private virtuali), per l autenticazione via web, per l erogazione di servizi in rete eccetera. Infine, ma certamente non a causa del fatto che questo aspetto assume una minore importanza nell ambito di una PKI, resta da analizzare il processo di revoca dei certificati. La revoca di un certificato può essere effettuata per vari motivi. Il primo motivo riguarda la compromissione delle chiavi: è assolutamente necessario rendere inutilizzabile il certificato qualora la chiave privata dell utente venga violata. In questo modo, anche se le chiavi cadono nelle mani sbagliate, nel momento in cui il certificato non è più valido esse diventano inutilizzabili. Un altra causa che porta alla revoca di un certificato è legata a variazioni di stato dell utente. Ad esempio se un azienda fornisce tramite la propria PKI un certificato agli utenti per l accesso ai servizi interni, risulta ovviamente necessario attuare una revoca dei certificati per quegli utenti che lasciano l azienda prima della scadenza dei certificati stessi. Il processo di revoca avviene indirettamente e segue il principio delle blacklist: la CA genera e pubblica/distribuisce un documento, detto Certificate Revocation List (CRL), contenente la lista dei certificati revocati. Resta inteso che ogni CA può revocare solo i certificati a lei riconducibili e la garanzia di genuinità della lista è ovviamente fornita tramite un meccanismo di firma (il documento è emesso e firmato dalla CA stessa). Una difficoltà che spesso viene incontrata riguarda la difficoltà nel distribuire tempestivamente la CRL a tutte le applicazioni, in modo da inibire l uso dei certificati revocati. Si pensi ad esempio ai certificati utilizzati per l autenticazione: se il server non ha ricevuto la CRL aggiornata, ignorando quindi la revoca di alcuni certificati, continuerebbe a fornire servizi anche ad utenti che non ne avrebbero più diritto (se non addirittura in mala fede). Infine la revoca di un certificato relativo ad una CA, non solo impedisce alla CA di emettere nuovi certificati, ma invalida tutti i certificati emessi dalla CA stessa. Questo aspetto è di particolare importanza per la garantire l affidabilità dell intera PKI: se una CA viene compromessa al tempo t 1 e la scoperta della compromissione avviene al tempo t 1 +δ (ovviamente con δ > 0) è assolutamente necessario poter invalidare tutti i certificati emessi fra t 1 e t 1 + δ, certificati che potrebbero essere stati emessi dall attaccante per scopi illeciti. Anche se meno evidente è altrettanto importante l invalidazione dei certificati emessi al tempo t 0 < t 1 (quindi di tutti i certificati). Infatti, dopo la compromissione della CA, l attaccante potrebbe retrodatare l emissione di un CSR (all istante t 0), emettere un certificato a t 0 ed infine firmare un documento all istante t 0 (con t 0 < t 0 < t 0 < t 1 ). Tale documento, se non venissero invalidati tutti i 64

83 Stili di autenticazione OpenID certificati emessi dalla CA, avrebbe piena validità per la PKI in quanto non sarebbe possibile distinguere il certificato creato al tempo t 0 (compromesso) da un qualunque altro certificato valido. Ovviamente questo tipo di attacco non è attuabile per servizi come l autenticazione, nei quali è immediata (e condivisa fra le parti) la validazione dell istante temporale in cui avviene l azione. 2.3 OpenID OpenID è uno standard tecnologico aperto, non proprietario e il cui obiettivo è quello di creare uno livello di autenticazione Web assegnando all utente una singola identità digitale. Si tratta di un architettura (basata sull infrastruttura Internet già esistente) che semplifica le operazioni di login all utente, in quanto elimina la necessità di creare username multipli per accedere a diversi siti Web. Un utente che accede ad un sito che adotta OpenID, non ha bisogno di creare username e password specifici per quel sito (e quindi detenuti da esso), ma ha solo bisogno di essere registrato con un qualsiasi OpenID Identity Provider (IdP). Poiché OpenID è decentralizzato, non c è bisogno di nessuna autorità centrale che approvi o registri gli IdP ed i siti Web che adottano lo standard. Un utente può scegliere liberamente quale IdP usare e mantenere il suo identificatore qualora decidesse di cambiarlo. Ad oggi sempre più siti Web stanno adottando questo standard, infatti organizzazioni come AOL, BBC, Google, IBM, Microsoft, MySpace, Orange, VerySign, Yandex, Yahoo! sono già degli IdP e qualche migliaio di siti Web ne supportano il login. La OpenID Foundation (OIF), un organizzazione senza scopo di lucro, è stata realizzata al fine di aiutare la gestione di copyright, marchi, marketing ed altre attività inerenti la comunità OpenID, ed il suo obiettivo è tutelare OpenID Il processo di autenticazione OpenID Prima di descrivere in dettaglio il processo di autenticazione tramite OpenID, è opportuno definire il glossario di base dei termini che verranno usati. End-user: l utente che vuole autenticare la sua identità su un sito. Identificatore: la URL o l XRI scelto dall end-user come suo identificatore OpenID. OpenID Identity Provider (OP) o Identity Provider (IdP): un service provider che offre il servizio di registrazione di URL o di XRI OpenID e effettua l operazione di autenticazione OpenID. Relying Party (RP): un applicazione Web che vuole verificare l identificatore dell end-user. OP Endpoint URL: è la URL ricavata dal RP con un operazione di discovery sull identificatore fornito dall utente. User-agent: il programma (per esempio un browser) che l end-user utilizza per accedere all OP e al RP. 65

84 Stili di autenticazione OpenID Con queste keyword, è ora possibile spiegare in dettaglio il processo di autenticazione. Un sito Web RP (es. mostra un form OpenID login da qualche parte nella pagina. Diversamente da un tipico form di login con i campi di username e password, un form OpenID ha soltanto un campo per l inserimento dell identificatore OpenID (o del nome del provider) dell end-user. Va evidenziato come questo standard, in quanto aperto e non proprietario, permette ad un qualunque utente che sia proprietario di un dominio (come ad esempio un blog personale o una homepage) di usare la propria URL come identificatore OpenID inserendo tramite HTML un tag OpenID che segue le specifiche [Fit07]; oppure più semplicemente può registrare un identificatore OpenID tramite un OP, quest ultimo offre infatti la possibilità di creare un XRI o un URL (tipicamente di terzo livello) per l end-user che sarà automaticamente configurato per il servizio di autenticazione OpenID. Un end-user, che avrà quindi precedentemente registrato un identificatore OpenID (es. me.yahoo.com/a/oizlz9v.0cnd51hkeusk.kfmofiyunzzlq-- nel caso in cui l identificatore sia una URL) con un OP (es. yahoo.com), nel momento in cui visita il sito Web RP (es. digita il suo identificatore nel form OpenID login. Il sito Web RP a questo punto esegue il processo di discovery sull identificatore OpenID dell utente e quindi ottiene l OP Endpoint URL di cui l end-user si serve per l autenticazione. La discovery è infatti il processo in cui il RP usa l identificatore inserito dall utente per scoprire (discover) le informazioni necessarie per poter effettuare l autenticazione. Con OpenID 2.0 [Fit07] ci sono tre modi per effettuare la discovery: 1. Se l identificatore è un XRI sarà ottenuto un documento XRDS (extensible Resource Descriptor Sequence) [WRM + 08] contenente le informazioni necessarie. 2. Se invece l identificatore è una URL (come nell esempio visto sopra) si utilizzerà lo Yadis protocol [Mil06], per mezzo del quale si otterrà ancora un XRDS document. 3. Infine se lo Yadis protocol non è in grado di restituire un documento XRDS valido, allora le informazioni necessarie saranno ottenute grazie ad una discovery basata su HTML. A questo punto il RP può effettuare la procedura di autenticazione vera e propria, e ciò può essere fatto in due modi (vedi il flow chart di figura 2.6 e lo state diagram di figura 2.7): 1. checkid-immediate. Viene eseguita se l end-user è già loggato sull OP; viene chiesta all end-user una semplice conferma per poter accedere al RP. 2. checkid-setup. Viene eseguita se l end-user non è ancora loggato sull OP oppure nel caso in cui l autenticazione con il checkid-immediate non va a buon fine. Con questa seconda modalità, l end-user comunica con l OP direttamente, usando lo stesso browser utilizzato per accedere 66

85 Stili di autenticazione OpenID al sito del RP. Verranno quindi richieste all end-user le credenziali registrate sull OP (username e password) per verificare la reale appartenenza dell identificatore all utente che si sta collegando al RP. Opzionalmente il RP e l OP si scambiano una chiave segreta che è usata dal OP per firmare i successivi messaggi verso il RP in modo tale che quest ultimo potrà verificarne l autenticità. Per questo processo viene usato il Diffie-Hellman Key Exchange [Res99]. Dopo che l identificatore OpenID è stato identificato, l autenticazione OpenID è riuscita e l end-user è loggato sul sito Web RP con l identificatore dato. È importante notare che OpenID non dispone di un proprio sistema di autenticazione, pertanto la sicurezza dell intera operazione è strettamente legata a quella dell OP. Per comprendere al meglio il processo di autenticazione, può essere utile consultare i sequence diagram in figura 2.8 e 2.9, rispettivamente per le modalità checkid-immediate e checkid-setup. Nella figura 2.8 è possibile vedere i vari passi in cui viene effettuata la procedura di autenticazione con la modalità checkid-immediate (cioè supponendo che la fase di login con il service provider sia già stata effettuata). Le varie fasi della procedura di autenticazione si basano su messaggi HTTP, e come tali prevedono un meccanismo richiesta/risposta (client/server): la parte client esegue una richiesta e la parte server restituisce la risposta. Pertanto ogni passo consisterà in uno scambio di messaggi di questo tipo (richiesta con linea continua, risposta con linea tratteggiata). 1. L user-agent fa una richiesta GET al RP, e quest ultimo gli restituisce la pagina richiesta. L end-user si connette perciò alla homepage del RP. 2. L end-user che vuole autenticarsi sul RP accede all area Sign In sulla homepage, e il RP gli presenta il form OpenID in cui inserire i dati. 3. L end-user immette l identificatore OpenID (URL o XRI precedentemente creato sull OP) oppure il nome dell OP nell apposito form presentato dal RP. Il RP reindirizza l user-agent all OP. 4. (Opzionale) RP e OP si scambiano una chiave segreta che è usata dal OP per firmare i successivi messaggi verso il RP in modo tale che quest ultimo potrà verificarne l autenticità. 5. Procedura di checkid-immediate. L user-agent si collega all OP, e viene riconosciuto da quest ultimo (come già detto, si è assunto che la procedura di login verso l OP sia stata già effettuata). A questo punto viene creato un cookie [KM00], cioè un file che viene salvato sul disco rigido della macchina in uso per tenere traccia del login effettuato dall end-user sull OP. L OP invia all user-agent la conferma per accedere al RP. È importante notare che se l utente decidesse in questo momento di cancellare la lista dei cookie dal proprio PC, la procedura di autenticazione OpenID non potrebbe più andare a buon fine, perché l end-user non risulterebbe più loggato sull OP e quindi si renderebbe necessaria l operazione di checkid-setup. 67

86 Stili di autenticazione OpenID L'end-user vuole autenticarsi su me.yahoo.com/a/oizlz9v.0cnd51hkeusk.kfmofiyunq oppure yahoo.com L'end-user è già autenticato dal provider? No Modalità checkid_setup Si Modalità checkid_immediate Conferma L'end-user è autenticato su Figura 2.6: Flowchart di autenticazione OpenID 68

87 Stili di autenticazione OpenID enduser non autenticato su RP enduser già autenticato su OP (inserimento URL o indirizzo OP) checkid_immediate enduser non ancora autenticato su OP (inserimento URL o indirizzo OP) username e password corrette Conferma checkid_setup enduser autenticato su RP Errore nell'inserimento di username e/o password Figura 2.7: State diagram della procedura di autenticazione OpenID 6. L end-user conferma di voler accedere al RP. L OP comunica perciò al RP che l end-user è stato autenticato e perciò può farlo accedere (questo chiaramente risulta trasparente all utente); il RP risponde con un messaggio di conferma all OP, e a questo punto l OP reindirizza l user-agent al sito RP, che ora gli consentirà l accesso. 7. L end-user è ora loggato sul RP, e può interagire con esso. Da questo momento in poi tutta la comunicazione avverrà tra l end-user (autenticato) ed il RP. Finora abbiamo ipotizzato che l end-user fosse a priori loggato sull OP o che non ci fossero errori durante la procedura, per esempio cancellazioni di cookie. Se invece l utente non è ancora loggato sull OP o si verifica l errore sopra descritto, allora si renderà necessaria la modalità di checkid-setup. La procedura di autenticazione con questa modalità è mostrata in figura 2.9. Dall analisi effettuata si può notare che fino al passo 4 la procedura è praticamente identica a quella appena considerata, pertanto saranno descritte solamente le fasi successive a partire dalla Procedura di checkid-setup. L user-agent si collega all OP, e quest ultimo gli presenta il form in cui l end-user dovrà inserire username e password di accesso. 2. L end-user immette nell apposito form le proprie credenziali, ed effettua perciò il login sull OP. Anche in questo caso viene creato il cookie per tenere traccia delle informazioni relative all utente. L OP presenta all user-agent una richiesta di conferma per accedere al RP. 3. L end-user conferma di voler accedere al RP. L OP comunica perciò al RP che l end-user è stato autenticato e perciò può farlo accedere; il RP risponde con un messaggio di conferma all OP, e a questo punto l OP reindirizza l user-agent al sito RP, che ora gli consentirà l accesso. 69

88 Stili di autenticazione OpenID User-agent (Mozilla Firefox) Relying Party ( OpenID Provider (yahoo.com) 1 get 2 sign in homepage form 3 richiesta di accesso 4 scambio di chiave redirect 5 connessione a OP utente già autenticato: richiesta a procedere cookie 6 continua utente autenticato ack redirect logged-in 7 Figura 2.8: Sequence diagram per l autenticazione checkid-immediate 70

89 Stili di autenticazione OpenID User-agent (Mozilla Firefox) Relying Party ( OpenID Provider (yahoo.com) 1 get 2 sign in homepage form 3 richiesta di accesso 4 scambio di chiave redirect 5 connessione a OP form di login cookie 6 submit autenticazione utente 7 continua utente autenticato ack logged-in redirect 8 Figura 2.9: Sequence diagram per l autenticazione checkid-setup 71

90 Stili di autenticazione OpenID 4. L end-user è ora loggato sul RP, e può interagire con esso. È importante notare che la procedura di autenticazione appena mostrata nei sequence diagram, è una sorta di linea guida alla quale si devono attenere le tre parti; vale a dire che da un punto di vista logico devono essere sempre seguiti i passi sopra descritti per permettere l autenticazione dell end user sul RP, ma nell implementazione pratica le parti potrebbero agire in modo diverso. Per esempio dopo la conferma d accesso (vedi passo 7), l OP comunica al RP che l end-user è stato autenticato e perciò può farlo accedere; però se a questo punto l OP comunicasse direttamente con l end-user fornendogli l autorizzazione per l accesso al RP, si potrebbe arrivare direttamente al passo 8, senza il bisogno dei messaggi utente autenticato e ack visibili in figura 2.9. Tecnicamente l implementazione della procedura è fatta in modo diverso, ma da un punto di vista prettamente logico non cambia nulla. I vari RP e OP sono pertanto liberi riguardo all implementazione del sistema di autenticazione OpenID, purché non ne vadano a cambiare la logica Punti critici di OpenID Analizzando il funzionamento dell autenticazione OpenID si possono rilevare alcune debolezze e vulnerabilità per quanto riguarda la sicurezza, quindi potrebbe essere soggetto a vari tipi di attacchi. Attacco Eavesdropping: consiste nell intercettazione fraudolenta di dati che transitano in una rete telematica. Esistono dei software che sono in grado di intercettare la procedura di autenticazione a livello di trasporto ed effettuare uno sniffing delle informazioni necessarie al login. Queste informazioni possono essere utilizzate in seguito dall attaccante per effettuare una non lecita autenticazione. Questo tipo di attacco può essere prevenuto effettuando un trasporto criptato. Attacco Man-in-the-Middle: è un attacco nel quale l attaccante è in grado di leggere o modificare messaggi tra due parti senza che nessuna delle due si renda conto del fatto che il collegamento è stato compromesso. Un attaccante può fingersi l OP dell utente e quindi entrare in possesso delle sue credenziali senza che quest ultimo se ne accorga. Un metodo per prevenire questo tipo di attacco è usare la firma digitale e protocolli di crittografia per creare un canale sicuro per i messaggi scambiati. Attacco Denial of Service: In questo tipo di attacco si cerca di portare il funzionamento di un sistema informatico che fornisce un servizio al limite delle prestazioni, fino a renderlo non più in grado di erogare il servizio stesso. Nel protocollo OpenID non c è nessuna misura di sicurezza che permetta di capire se una richiesta di autenticazione è finalizzata a questo tipo di attacco, quindi un attaccante che si finge un RP potrebbe inviare molte richieste ad un OP, così da saturarne le risorse. Un metodo efficace che permette ad un OP di difendersi è usare tecniche di rate-limiting a livello trasporto. 72

91 Stili di autenticazione Kerberos Phishing: è un attività illegale utilizzata da un attaccante per ottenere l accesso ad informazioni personali soprattutto tramite messaggi fasulli di posta elettronica (che imitano ed esempio loghi ufficiali) o contatti telefonici. L utente viene così ingannato e portato a rivelare dati personali, codici di identificazione, ecc. Gli OP dovrebbero perciò educare i loro utenti in modo da difendersi da questo tipo di attacchi; inoltre potrebbero fornire agli utenti un plug-in per aggiungere un personale sigillo di sicurezza che appaia tutte le volte che si tenti di accedere al provider. Come detto precedentemente, OpenID è decentralizzato. Se da una parte questo rende libero l utente circa la scelta dell OP a cui affidare i suoi dati, dall altra aumenta la complessità e la vulnerabilità del sistema, infatti la responsabilità di qualità dell autenticazione è spostata verso l end-user (nella scelta dell OP). 2.4 Kerberos Kerberos [Gar03] è un servizio di autenticazione sviluppato a partire dalla metà degli anni 80 al Massachusetts Institute of Technology (MIT) come parte di un progetto più ampio denominato Project Athena [Web06]. Il suo scopo era quello di permettere ad utenti e servizi di effettuare una mutua autenticazione di tipo single sign-on in maniera rapida e sicura Dalle origini ai giorni nostri Nella mitologia greca Cerbero era il cane a tre teste messo a guardia degli Inferi. Il suo compito era quello di assicurarsi che soltanto le anime dei defunti potessero accedere al regno di Ade e Persefone. Si potrebbe dire che Cerbero autenticasse chi cercava di entrare (per stabilire se fosse vivo o meno) e, sulla base di ciò, accordasse l ingresso a chi era autorizzato. Nello stesso modo Kerberos, battezzato col nome greco dell essere mitilogico, autentica gli utenti che chiedono di accedere ai servizi forniti dalla rete che difende. Kerberos ha iniziato la sua strada come progetto di ricerca al MIT nei primi anni 80, in quei laboratori in cui fu percepito da subito l impatto che la grande diffusione dei personal computer avrebbe prodotto sull industria informatica. Nasce in seno ad un proetto, il Project Athena, incentrato sull integrazione di calcolatori collegati in rete e che ha sviluppato pacchetti come il servizio di nomi distribuito Hesiod, il sistema di amministrazione distribuita Moira e, infine, l X Windows System, tuttora alla base dell interfaccia grafica dei sistemi UNIX. Fino a quel momento l architettura di rete era conforme al modello timesharing per cui dei terminali molto limitati erano collegati, attraverso linee seriali dedicate, ad un calcolatore sul quale erano concentrati servizi e qualsiasi altro strumento di amministrazione. Risultava molto semplice percui gestire gli accessi e manutenere il sistema, e non esisteva il problema della sicurezza nelle comunicazioni essendo ognuna di esse veicolata da linee seriali dedicate. È ovvio che l avvento delle reti orientate al pacchetto avrebbe velocemente reso antiquato un simile paradigma. Il nuovo modello, definito client-server, 73

92 Stili di autenticazione Kerberos oltre ad apportare svariati benefici [TW97], che non è il caso riportare in questa sede, introduceva problematiche inedite per quanto riguarda la gestione degli accessi ai servizi di rete. La distribuzione dei servizi su più macchine portava alla necessità di configurare in maniera opportuna ogni server, per metterli in condizione di riconoscere gli utenti, e si rendeva necessario raggiungere un certo livello di sicurezza per lo scambio dei dati, visto che le comunicazioni avvenivano su canali condivisi. Proprio per risolvere questi due problemi il team del Project Athena sviluppò il protocollo di autenticazione Kerberos. Il loro obiettivo era estendere il meccanismo di autenticazione tipico delle reti a time-sharing ad una rete distribuita costituita da server e client non fidati gestiti dagli utenti. Le prime tre versioni di Kerberos sono state sviluppate ed utilizzate solo internamente al MIT a scopo di ricerca e come campo di prova per nuove funzionalità per via delle significative limitazioni di cui soffrivano ma ogni revisione ha portato grandi miglioramenti in ambito di usabilità, estensibilità e sicurezza [KNT94]. Rilasciato al pubblico il 24 Gennaio 1989, Kerberos 4 è stata la prima versione ad uscire dai laboratori del MIT. Da allora è stato adottato da vari produttori e tutti i sistemi operativi ne hanno integrato il supporto. La più recente incarnazione, Kerberos 5, ha sostituito la versione 4 ed ha introdotto nuove caratteristiche e diversi miglioramenti in ambito di sicurezza così da essere stata proposta come standard L autenticazione in Kerberos Si potrebbe definire semplicemente l autenticazione come il processo di verifica dell identità di un particolare utente. Questi deve provare la propria identità se vuole usufruire di un servizio presente in rete. Il più semplice dei tanti modi che esistono per mostrare la propria identità è farlo attraverso una password personale; il server la riconosce come prova dell identità dell utente e fornisce i servizi ai quali l utente ha diritto di accedere. Questo approccio porta facilmente a diversi inconvenienti: ogni volta che si accede ad un servizio la parola chiave deve essere digitata. Ciò può essere fastidioso specialmente se si ha a che fare con molti servizi e può portare alla tentazione di usare sempre la stessa password ed a renderla facile da digitare. Due pratiche decisamente non consigliabili se si ha a cuore la sicurezza di un sistema. A parte questi problemi tipici delle password, questo approccio mostra una grave limitazione quando applicato ad entità connesse in rete: la password deve essere trasmessa in chiaro sul canale di comunicazione. Ciò significa che può essere intercettata e usata da chi era in ascolto. Il concetto su cui è basato Kerberos è il fatto che la password, un segreto condiviso fra client e server, può essere utilizzata in maniera indiretta: basta trovare un metodo per provarne la conoscenza senza il bisogno di inviarla attraverso la rete. Ovviamente quel metodo esiste: Kerberos, così come altri protocolli simili, usa quel segreto, la password, come chiave crittografica. Nel caso più semplice l utente cripta un messaggio appena creato, come ad esempio un timestamp, con la chiave condivisa e la invia al servizio che la decripta con la stessa chiave. 74

93 Stili di autenticazione Kerberos Se non è possibile estrarre il messaggio significa che l utente non aveva usato la chiave corretta e il servizio rifiuta la richiesta di autenticazione. Kerberos utilizza questa idea come base ma risolve molti dei problemi che potrebbero derivare dall uso sic et simpliciter di questo schema. È bene precisare che da questo momento in poi, quando non esplicitamente dichiarato, si farà riferimento esclusivamente a Kerberos Terminologia e concetti Kerberos è un sistema complesso e, in quanto tale, sono molti gli elementi che lo costituiscono ed i concetti su cui è costruito. In questo paragrafo viene descritto tutto ciò che concorre al suo funzionamento in modo da semplificarne la trattazione nella sezione seguente. Reami, nomi principali e istanze Ogni installazione di Kerberos definisce un ambito amministrativo, distinto da ogni altra installazione. Questo ambito è chiamato reame. Ogni entità in una rete Kerberos sia essa un client, un utente, un servizio o la macchina che lo ospita deve avere una identità all interno del reame che, secondo la nomenclatura del protocollo, viene definita principal o nome principale. Ad ogni identità è inoltre associata una chiave a lungo termine. Ciò per permettere una mutua autenticazione in ogni connessione. Ogni nome principale è unico globalmente e, per facilitarne la gestione, è costituito da più parti secondo una struttura gerarchica molto simile a quella dei domini. Inizia con il nome utente o il nome del servizio e termina con il nome del reame a cui appartiene. Il nome del reame è introdotto dal Fra i due è presente un campo opzionale detto istanza che può essere usato in due situazioni: per creare principal speciali ad uso amministrativo o, come si vedrà più avanti, per il principal di un servizio. Questi due elementi, considerati insieme, devono essere unici all interno di un reame. Nel caso di un host il campo username viene impostato ad host. Per distinguere i principal di servizi uguali, ma su macchine differenti, viene riempito il campo istanza con l hostname della macchina che lo ospita. È bene tenere presente che lo stesso sistema Kerberos, per permettere lo svolgimento della procedura di autenticazione, deve fornire dei servizi, ognuno provvisto del proprio principal. La sintassi completa per i nomi principali è la seguente: component[/component][/component]...@realm che all atto pratico può risultare: username[/istance]...@realm service/fully-qualified-domain-name...@realm 75

94 Stili di autenticazione Kerberos Le chiavi Tutte le chiavi segrete sono condivise da almeno due entità: l utente o il servizio e il Key Distribution Center che sarà descritto in seguito. Le chiavi segrete sono però, in generale, delle stringhe alfanumeriche che devono essere trasformate per poter essere usate come chiavi crittografiche. Si utilizza quindi la funzione string2key che applica alla chiave segreta delle trasformazioni al fine di ottenere una serie di cifre. Trattandosi, nell insieme, di una trasformazione non invertibile è matematicamente impossibile risalire alla password che ha generato la chiave crittografica. La parte più importante di questa trasformazione è l aggiunta del key salt. Con questo termine si intende una sequenza di caratteri che viene concatenata alla parola chiave prima di applicare la funzione hash per rendere più particolare la stessa. In Kerberos 5 il key salt di default è rappresentato dal nome del reame. In questo modo se un utente utilizza la stessa password in due reami diversi, avrà comunque generato due chiavi crittografiche diverse. La compromissione di una delle due chiavi non porterà automaticamente alla compromissione dell altra. Dato che le entità sulla rete possono cambiare la propria password deve esistere un modo per determinare quale di queste deve essere considerata per accordare l accesso ai servizi. È stato quindi definito il Key Version Number (kvno). Quando un utente cambia la propria password il kvno viene incrementato di una unità. La stessa cosa accade, ovviamente, se è un servizio a farlo; in questo caso il kvno acquista maggiore importanza in quanto, perché i servizi riescano a interpretare i messaggi degli utenti, sia la chiave crittografica sia il kvno devono corrispondere ai valori memorizzati nel database di Kerberos. Key Distribution Center Il Key Distribution Center (KDC) consiste di tre parti logicamente distinte: un database dei principal e delle relative chiavi, l Authentication Server (AS) e il Ticket Granting Server. Questi tre elementi, pur essendo logicamente distinti sono di solito implementati nello stesso programma. Ogni reame deve avere almeno un KDC e, vista la notevole importanza che ricoprono le informazioni che conserva, è buona norma che esista nella rete una macchina esclusivamente adibita ad ospitarlo. Il KDC contiene, infatti, al suo interno un database dei principal e dei segreti delle entità del reame e, a seconda della implementazione esaminata, anche altre informazioni relative agli utenti. Queste possono venir memorizzate su un database locale nel filesystem del KDC stesso, come l implementazione del MIT ha scelto, o anche con servizi di directory 3. Kerberos permette di impostare dei KDC di tipo slave che replicano in tutto e per tutto il funzionamento del servizio master. Ciò che li differenzia sono le 3 I Servizi di Directory sono dei repository o database di informazioni. Una directory, al contrario dei normali database, è pesantemente ottimizzato per operazioni di lettura in quanto si considera che solo raramente i dati contenuti debbano essere aggiornati. In genere supportano funzioni di lettura, ricerca e consultazione. Un esempio importante di servizio di directory è senza dubbio rappresentato dal Domain Name System (DNS) che può essere definito più precisamente come servizio di directory distribuito con struttura gerarchica. Altri esempi sono LDAP [How98] e Active Directory [Mic06]. 76

95 Stili di autenticazione Kerberos operazioni che possono essere effettuate sui database degli accessi: è possibile accedere ai database dei server slave esclusivamente in sola lettura. Tutte le operazioni di modifica devono necessariamente essere svolte sul database master e, solo in un secondo momento, sarà possibile effettuarne la propagazione ai database slave. In questo modo qualora il KDC master fosse inaccessibile sarebbe sempre possibile ottenere nuovi ticket attraverso i KDC slave. Il protocollo non definisce il meccanismo di propagazione delle modifiche quindi ogni implementatore ha sviluppato soluzioni proprie. L Autentication Server rilascia un Ticket Granting Ticket (TGT) crittografato ai client che vogliono autenticarsi verso il reame Kerberos. Non è necessario che il client dimostri la sua identità all AS in quanto il TGT, essendo crittografato con la chiave segreta dell utente, risulterebbe inutilizzabile da chiunque altro. Una volta decrittato, il TGT rappresenta l elemento fondamentale per permettere un autenticazione di tipo single sign-on: non sarà infatti più necessario inserire la propria password a lungo termine fino alla scadenza del TGT in uso. Il Ticket Granting Server (TGS), invece, è un servizio che rilascia ai client dei ticket specifici per un servizio della rete, i service-ticket. Il client, quando effettua la richiesta di un servizio, deve fornire due oggetti al TGS: il principal del servizio che vuole contattare e il TGT che gli è stato fornito dall AS al momento dell autenticazione. Il TGS, una volta verificata la validità del TGT, per fare ciò è sufficiente che controlli che sia stata crittata con la chiave dell AS, risponde con il service-ticket richiesto. I Ticket Come appena visto, Kerberos introduce il concetto di ticket. Concettualmente si tratta di un dato strutturato crittografato che contiene al suo interno una chiave crittografica diversa per ogni sessione, la chiave di sessione e altri campi tra cui alcuni flag per definire la modalità di funzionamento del ticket stesso. I ticket hanno due finalità: confermare l identità degli end-point della comunicazione e fornire loro la chiave di sessione. Questa chiave ha una validità relativamente breve che viene calcolata in base al trade-of tra il danno causato da un possibile furto delle credenziali e la convenienza portata dal single sign-on. Tipicamente è impostata tra le 10 e le 24 ore. I campi più importanti che Kerberos include in un ticket sono: il principal del richiedente; il principal del servizio richiesto; la finestra temporale di validità del ticket stesso; una lista degli indirizzi IP da cui il ticket può essere utilizzato; la chiave crittografica condivisa tra utente e servizio per renderne possibile la comunicazione (la chiave di sessione). Alcuni campi, come la finestra temporale o la chiave di sessione, sono riempiti dal KDC per ovvi motivi di sicurezza; altri vengono impostati dal client per 77

96 Stili di autenticazione Kerberos esempio in relazione al servizio contattato o alle modalità con cui vuole ottenere l accesso. Ogni ticket che il KDC genera deve essere crittografato per impedire che un attaccante possa modificarlo, per esempio, per allargare la finestra di validità di un ticket rubato. Le credenziali ottenute devono ovviamente essere mantenute in una cache, chiamata indifferentemente ticket cache che credentials cache, che può essere implementata in più modi. Nella versione sviluppata dal MIT è stato scelto, per facilitare la portabilità, di salvare il contenuto dei ticket in un file sul disco fisso. Questo metodo è però poco flessibile e porta a problemi di sicurezza. Una soluzione migliore è quella di salvare le credenziali in memoria per garantire la loro distruzione al termine della sessione Kerberos. Kerberos 5 introduce funzioni avanzate che permettono agli utenti un maggior controllo sui propri ticket attraverso i seguenti flag: Forwardable ticket. Un utente può richiedere un forwardable ticket. Questo può essere inoltrato ad un altro host e risultare comunque valido. Un caso speciale è rappresentato dal TGT inoltrabile: un utente può trasferire il suo TGT valido ad un altro host e utilizzarlo anche dalla nuova locazione, senza il bisogno di inserire nuovamente i dati di login, sia per ottenere dei service-ticket che un nuovo TGT. Proxiable ticket. Questo tipo di ticket è simile nel funzionamento a quello di classe forwardable ma risulta meno potente: questo, infatti, può essere usato, una volta trasferito su un altro host, solo per richiedere nuovi service-ticket ma mai per ottenere un nuovo TGT. Renewable ticket. Quando un utente richiede un ticket con il flag renewable attivato, fa la richiesta per un ticket di cui sarà possibile estendere la finestra di validità. Per fare ciò è sufficiente rimetterlo al TGS prima della sua scadenza. Il TGS può rifiutarsi di convalidare il ticket qualora, per esempio, sia stato segnalato come compromesso; altrimenti ne invia un altro all utente. Questo procedimento può essere ripetuto fino alla fine della validità dei ticket rinnovabili. Postdated ticket. I ticket di questo tipo sono validi solo a partire dalla data riportata al loro interno. Se uno di questi viene proposto per la validazione prima del tempo previsto viene rifiutato. Sono generalmente utilizzati per lavori in sequenza o temporizzati che necessitano di autenticazione Kerberos, ma non tutte le implementazioni del protocollo li prevedono Il funzionamento di Kerberos Fin ora sono stati presentati tutti i concetti che permettono di descrivere il funzionamento di Kerberos. Varrà ora descritto nel dettaglio il funzionamento del protocollo di autenticazione. 78

97 Stili di autenticazione Kerberos L autenticazione Intra-Realm L idea alla base di Kerberos è quella di creare un infrastruttura il cui unico scopo sia l autenticazione. In questo modo i servizi non devono preoccuparsi di mantenere informazioni riguardo gli utenti e i permessi ad essi associati; sia l utente che i servizi, però, devono necessariamente fidarsi dell Authentication Server che ha il compito di presentare gli agenti l un l altro; per fare ciò sia l utente che i servizi devono condividere una chiave segreta con l AS; queste sono chiamate chiavi a lungo termine dato che hanno una validità che può arrivare a settimane o addirittura mesi. Si consideri ora la situazione in cui un client C voglia accedere ad un servizio remoto S; il processo di autenticazione può essere suddiviso in tre fasi distinte [CJ05]. Authentication Service Exchange (C AS). Questo scambio di messaggi avviene quando l utente accede per la prima volta alla rete Kerberos. Il processo client C genera un nonce 4 n 1 e lo invia all AS insieme al proprio nome e al nome del TGS. Una volta riconosciuto il client e quindi, anche se indirettamente, l utente, l AS risponde con un messaggio crittografato in due parti: il TGT, che viene memorizzato da C per essere usato durante tutta la sessione Kerberos per ottenere i service-ticket, e una seconda parte con cui l AS passa a C alcuni parametri riguardanti il ticket. Il TGT, crittografato con la chiave a lungo termine del TGS, contiene al suo interno una chiave di autenticazione AK e un timestamp t k oltre al nome di C e ad altri dati in questo momento meno importatanti. La seconda parte, crittografata stavolta con la chiave a lungo termine del client, contiene la stessa chiave di autenticazione AK che, da questo momento, verrà usata in tutte le seguenti comunicazioni con il TGS in modo da non esporre la ben più preziosa chiave a lungo termine. Il timestamp presente in entrambe le parti del messaggio assicura che il ticket sia stato generato recentemente dato che tutte le macchine della rete sono sincronizzate su un time server comune. Il nonce n 1 serve a legare la risposta dell AS con la richiesta del client. Ticket Granting Exchange (C TGS). Questo scambio di messaggi avviene quando un utente accede per la prima volta ad un servizio. C trasmette al TGS un messaggio in due parti: la prima parte contiene il TGT precedentemente memorizzato, il nome del servizio cui l utente vuole accedere e un nonce n 2 ; la seconda parte, detta authenticator, contiene il nome del client e un timestamp t c ed è crittografato con la chiave AK. L authenticator serve per provare al TGS che il client conosce la chiave di autenticazione AK. 4 In questo contesto il termine nonce sta per number used once. Si tratta, di solito, di un numero casuale o pseudo-casuale utilizzato nei protocolli di autenticazione per assicurare che vecchi messaggi non siano riutilizzati da un utente malintenzionato. 79

98 Stili di autenticazione Kerberos Una volta autenticato C e verificato il suo livello di accesso, il TGS risponde con un nuovo messaggio, sempre suddiviso in due parti: entrambe contengono il nome del client, un timestamp t T GS e una nuova chiave, creata per l imminente comunicazione tra client e server, chiamata chiave di sessione. Ciò che differenzia le due parti è la chiave crittografica usata per sigillare il messaggio: la prima parte viene crittata con la chiave a lungo termine del servizio e prende il nome di service-ticket; la seconda con la chiave di autenticazione AK. Il client memorizza il service-ticket. Client-Server Exchange (C S). Questo scambio di messaggi avviene quando il client inizia una nuova sessione con il server. A questo punto C possiede il service-ticket e può contattare S inviando tale ticket al suo interlocutore, insieme ad un authenticator costruito come quello precedentemente descritto. Entrambi sono i soli in grado di estrarre dai messaggi la chiave di sessione necessaria per comunicare in sicurezza e hanno una conferma dell identità dell interlocutore. Il server può, in base alle preferenze dell amministratore del sistema, rispondere o meno al client per esempio inviando il timestamp t C che C aveva inviato nella sua richiesta, crittografandolo con la chiave di sessione. Figura 2.10: Kerberos - Autenticazione intra-realm 80

99 Stili di autenticazione Kerberos Ora può aver inizio la comunicazione con il servizio per il quale è stato contattato il server. Come descritto poco sopra, nella prima fase del processo di autenticazione, l AS riconosce il client C esclusivamente dal nome inserito nel primo messaggio generato. Per ragioni di sicurezza che verranno analizzate in seguito è stato introdotto con Kerberos 5 un meccanismo chiamato pre-autenticazione: l utente deve in qualche modo provare la propria identità perché il KDC generi il ticket per quel particolare principal. Esistono vari tipi di pre-autenticazione ma solo il metodo denominato encrypted timestamp è implementato comunemente. La pre-autenticazione è controllata dal KDC. Se un utente cerca di ottenere un TGT, come descritto precedentemente nella fase denominata Authentication Service Exchange, e il KDC è impostato per richiedere la pre-autenticazione, quest ultimo risponderà con un messaggio di errore. Questo messaggio comunica al client che è necessario pre-autenticarsi per ottenere un ticket. Quindi la richiesta verrà ripetuta ma aggiungendo al messaggio i dati di pre-autenticazione richiesti. Nel caso menzionato (encrypted timestamp), questi consistono di un timestamp firmato con la chiave privata dell utente. Se il KDC è in grado di decifrarlo, utilizzando la chiave pubblica dell utente a lui nota, risponde al client inviandogli il TGT altrimenti invierà un nuovo messaggio di errore per comunicare all interlocutore il fallimento della pre-autenticazione. L autenticazione Cross-Realm Fino qui è stato esaminato uno scenario in cui sia presente un solo AS ed un solo TGS, che possono o meno risiedere sulla stessa macchina. Finchè il numero delle richieste si mantiene basso non c è nessun problema ma col crescere della rete, e quindi anche del numero delle richieste, il AS e il TGS diventano il collo di bottiglia nel processo di autenticazione. In breve il sistema, così come è stato descritto fin ora, non è scalabile. Per questa ragione può essere sensato suddividere la rete in aree. D altra parte una struttura simile può essere il risultato di una integrazione di reti già esistenti e separate su base organizzativa. Nella terminologia di Kerberos queste aree prendono il nome di reame. Ogni reame consiste di client, servizi e di un KDC proprio. Per permettere un autenticazione cross-realm, cioè per permettere che utenti in un certo reame possano usufruire di servizi presenti in altri reami, è necessario registrare il KDC afferente al reame del servizio come un server speciale nel reame dell utente ed usare una variante del protocollo intra-realm. In questo modo viene aggiunto un ulteriore livello di indirezione alla procedura di autenticazione. Il caso più semplice che è possibile prendere in esame coinvolge un client C nel reame R 1 e un server S nel reame R n. Il KDC di R n deve essere registrato come un server speciale in R 1. Il client ottiene un TGT in R 1, come visto precedentemente, e un service-ticket per il KDC di R n che viene visto come un servizio locale in R 1. Il service-ticket ha lo stesso formato di un TGT per i client di R n e come tale viene gestito dal KDC di R n per fornire a C un service-ticket per il servizio S. In pratica il KDC di R 1 agisce come client nei confronti del KDC del reame remoto. Questo è il massimo che può essere ottenuto con la versione 4 di Kerberos. Con la versione 5 è stata aggiunta la possibilità di orga- 81

100 Stili di autenticazione Kerberos Figura 2.11: Kerberos - Autenticazione cross-realm nizzare i reami in una vera e propria struttura gerarchica. Sarà possibile quindi che un client C nel reame R 1 voglia accedere ad un servizio S nel reame R n ma che stavolta non sia direttamente disponibile in R 1 il server di collegamento per R n descritto poco sopra. Sarà necessario quindi attraversare in successione dei reami intermedi R 2,...,R n 1 a patto però che sia stata precedentemente definita una affiliazione tra R 2 ed R 3, tra R 3 ed R 4 e così via fino ad R n. La lista dei KDC attraversati è chiamata authentication path di C per S. I reami attraversati vengono definiti transited realms e i loro nomi sono registrati nel ticket in modo da informare il servizio dei passi effettuati nella catena di autenticazione. Ciò da la possibilità al servizio di esaudire o meno le richieste in base ad una personale valutazione del grado di affidabilità dei nodi attraversati. Resta da chiarire in che modo vengano determinati gli authentication path verso i servizi remoti. Esistono due modalità: una basata sulla gerarchia dei reami e una sulla sezione capaths del file di configurazione di Kerberos. La prima modalità è abbastanza semplice da realizzare: una volta organizzati i reami secondo una struttura gerarchica, del tutto simile a quella dei domini DNS, i client sanno implicitamente quali nodi di rete attraversare per raggiungere un determinato servizio. In questo modo però non si ha nessuno strumento 82

101 Stili di autenticazione Kerberos per verificare il grado di fiducia degli host attraversati. La seconda modalità si basa sulla configurazione della sezione capaths del file krb5.conf presente su ogni macchina della rete Kerberos. Qui vengono definiti, per ogni servizio remoto, gli authentication path validi. Questi verranno utilizzati dai client per determinare il corretto percorso fino ad un certo servizio remoto e dagli application server per determinare se un dato authentication path è da considerarsi valido o meno. Dato che ogni application server verifica gli authentication path usando questa sezione del file di configurazione la semplice aggiunta di un nuovo percorso verso un reame non sottintende nessuna informazione di fiducia nei confronti degli altri. Di contro il file krb5.conf deve essere aggiornato manualmente su ogni host coinvolto Analisi di sicurezza Non è difficile capire che trattare la sicurezza di un sistema complesso come Kerberos non può ridursi al semplice fatto di proteggere il KDC ; di seguito saranno riportati i potenziali scenari di compromissione e i loro effetti sulla sicurezza del sistema nel suo insieme [BM90, CJ05, Gar03]. Compromissione dell account di root del KDC. La compromissione dell account di root di un KDC, sia esso master o slave, dà all attaccante pieno controllo su tutto il meccanismo di autenticazione. Nonostante il database sia crittografato, la chiave master di Kerberos potrebbe trovarsi sul disco per permettere un eventuale avvio automatico del KDC. In una situazione del genere tutto il database è da considerarsi compromesso. Compromissione delle credenziali di amministratore. Se un attaccante ottiene la password di un principal amministrativo, ottiene l accesso completo al database di Kerberos. Alcune implementazioni infatti permettono di effettuare il dump da remoto del database ottenendo così una copia dello stesso. Senza contare che avendo accesso completo al database, un attaccante può creare o modificare qualsiasi nome principale a piacimento. Compromissione dell account di root di un server. Se un attaccante ottiene i privilegi di root su un server ha anche accesso ai principal dei servizi residenti sulla macchina e può impersonare i servizi per decrittare le comunicazioni con i client. Compromissione dell account di root di un client. La compromissione dell accont di root di un client fornirà all attaccante l accesso alla credentials cache; dato che i ticket sono validi in una piccola finestra temporale, la loro compromissione non è così grave come quella della password utente. È però possibile per l attaccante installare sulla macchina un keylogger, percui, in uno scenario del genere, sono da considerarsi compromesse le password di tutti gli utenti che hanno utilizzato la macchina. 83

102 Stili di autenticazione Kerberos Compromissione delle credenziali di un utente. Se l attaccante riesce ad acquisire la password utente potrà accedere ai servizi fino ad una nuova modifica della stessa. Risulta chiaro che installare Kerberos in una rete non diminuisce l importanza di mantenere tutte le macchine, fino ai terminale degli utenti, sicure da attacchi esterni. Va sottolineato anche un altro aspetto: Kerberos è stato sviluppato tenendo bene in mente l ambiente in cui doveva agire e, una volta estrapolato, mostra ovviamente delle limitazioni. L ambiente del Project Athena consiste in un grande numero di workstation più o meno anonime e un piccolo numero di server. I server forniscono servizi di file storage, print spooling, , e in alcuni casi calcolo. Di solito hanno dischi locali ma lavorano in sola lettura; contengono dati utente non a lungo termine. In più non sono messi in sicurezza a livello fisico: qualcuno potrebbe rimuovere, leggere o alterare porzioni di disco senza difficoltà. All interno di questo ambiente la prima necessità è di una autenticazione di tipo utente-server. Quando un utente siede ad una workstation ha bisogno di accedere a file privati residenti su un server in quanto non presenti altrove; la workstation, ovvero il client, in sé non ha quindi necessità di autenticarsi verso il server. Questo tipo di funzionamento è in marcato contrasto con quanto avviene normalmente per un sistema composto da macchine UNIX. In questo caso le workstation hanno una identità e dei propri file oltre che un certo numero di demoni di rete in esecuzione; quando una macchina simile ha intenzione di, per esempio, salvare dei file su un server deve quantomeno dichiarare e possibilmente provare la propria identità. Nel caso del Project Athena le workstation non sono capaci e non hanno bisogno di farlo; sono più dei terminali avanzati che sistemi completi. In questo scenario Kerberos serve quindi ad autenticare l utente finale verso un certo numero di servizi; non è stato sviluppato per essere usato da un demone di rete che contatta un server. Esistono dunque alcune limitazioni del protocollo Kerberos se usato in un contesto convenzionale come descritto qui di seguito: Per prima cosa una normale workstation non ha un area sicura in cui salvare le chiavi. In Kerberos, nel primo passo dell autenticazione, per ottenere un TGT viene utilizzata una chiave in chiaro ma salvarle in un computer è solitamente una cattiva idea; se una chiave Kerberos che una macchina usa per identificare se stessa viene compromessa sarà possibile impersonare ogni utente di quella macchina. In più la chiave di sessione ottenuta in risposta non può essere salvata in maniera sicura; viene solitamente archiviata in modo da potervi accedere solo con privilegi di root ma l attaccante può comunque violare o almeno aggirare temporaneamente il meccanismo di protezione sul computer locale per ottenere, se non la chiave Kerberos, almeno le chiavi di sessione. Un altro problema sorge nel caso in cui le workstation siano gestite con ottica multiutente: se ci sono problemi di sicurezza nell host un attaccante 84

103 Stili di autenticazione Kerberos può avere accesso alle chiavi in uso. Normalmente, al logout dell utente, Kerberos distrugge le password usate impedendo un attacco di questo tipo. Un altro punto da analizzare riguarda la posizione della cache delle chiavi. Le macchine del Project Athena erano provviste di disco e salvavano la cache in /tmp ma questo è pericoloso qualora le workstation siano senza unità disco: la cache sarebbe in questo caso salvata su un server. Una possibile soluzione potrebbe essere memorizzare la cache in memoria; non c è però nessuna garanzia che la memoria non sia prima o poi paginata sul disco. Vengono a questo punto descritti uno ad uno gli attacchi che è possibile portare al protocollo di autenticazione in se. Attacchi a dizionario e a forza bruta Durante il primo passo dell autenticazione il KDC rilascia un TGT crittografato ad ogni client che lo richieda. Questo TGT è crittografato con la chiave a lungo termine dell utente. La sicurezza dell intero sistema dipende dal non poter essere in grado di decifrare questo messaggio, dato che, se un attaccante è capace di estrarne la chiave può impersonare l utente a piacere. Nonostante non ci siano modi per farlo direttamente, un attaccante può tentare di forzare il TGT tramite un attacco a dizionario offline. Durante un attacco a dizionario, un attaccante fornisce una lista di password comunemente usate, o dizionario, ad un programma di cracking. Per ogni voce nel dizionario, il software cerca di decrittare il messaggio. Quando trova una password valida il programma la riporta all attaccante. Dato che la trasformazione che porta dalla password utente alla chiave crittografica è nota, è banale per un attaccante costruire un programma che applichi al dizionario di password la trasformazione citata. Quindi l attaccante può collezionare un grande numero di TGT validi e portare l attacco offline. Il programma di cracking può accorgersi di aver trovato la password corretta grazie alla presenza all interno del TGT della stringa tgt, parte del principal del TGS, krbtgt, che viene usata come segnale per una decodifica corretta anche da Kerberos stesso. Una volta determinata la password, la finestra di validità del TGT sarà ormai chiusa ma l attaccante potrà ricevere nuovi ticket usando la combinazione username/password ottenuta. Un attacco a dizionario rappresenta il limite inferiore nella sicurezza di ogni sistema di autenticazione basato su password. Non importa che tipo di sofisticato meccanismo crittografico venga utilizzato, se la password è semplice o prevedibile soccomberà velocemente ad un attacco a dizionario. Un altro attacco, l attacco a forza bruta, rappresenta il limite superiore nella sicurezza di Kerberos. Invece di tentare di decrittare i messaggi iterando su un insieme di parole predefinito, un attacco a forza bruta, prova una ad una tutte le chiavi possibili fino all ottenimento della password. I crittosistemi sono costruiti con uno spazio delle chiavi quanto più grande possibile proprio per rendere gli attacchi a forza bruta non praticabili. Da notare il fatto che spazi di chiavi un tempo considerati sufficientemente vasti, a seguito dell avanzamento tecnologico effettuato, risultano ora alla portata di attaccanti anche solo 85

104 Stili di autenticazione Kerberos moderatamente motivati. Mentre Kerberos 4 poteva avvalersi solo dell algoritmo crittografico DES, Kerberos 5 permette l aggiunta di tecniche crittografiche sempre più robuste e, per limitare il problema di un attacco offline, introduce la pre-autenticazione. Quest ultimo espediente, tra l altro neanche obbligatorio in alcune implementazioni di Kerberos, non rappresenta però una soluzione dato che l attaccante può comunque utilizzare uno sniffer per intercettare il traffico di rete. Replay Attack Dato che tutti i protocolli sono basati sullo scambio di messaggi elettronici tra i computer della rete, un attaccante può sempre restare in ascolto memorizzando alcuni messaggi e riutilizzarli in un secondo tempo. L attaccante non ha bisogno di indovinare la password dell utente o decrittare il messaggio ma, per poter sfruttare la situazione, deve essere in grado di costruire falsi messaggi; in ogni caso è sempre possibile tentare di estrarre la password con un attacco a forza bruta sul messaggio catturato. Kerberos ha, al suo interno, alcuni meccanismi atti ad evitare proprio attacchi di questo tipo: I ticket sono provvisti di un campo indirizzo. Quando un client richiede un ticket al KDC, può esplicitare gli indirizzi di rete dai quali il ticket deve risultare valido. Ciò risolve il problema di un attaccante che cerca di usare un ticket su una macchina non presente nel campo indirizzo. In ogni modo ciò non impedisce completamente attacchi di questo tipo; in primo luogo perché il campo indirizzo non è obbligatorio, in secondo luogo perché l attaccante può trovarsi su una macchina compatibile con il ticket. Gli authenticator hanno una validità limitata nel tempo. Come abbiamo visto nel paragrafo riguardante il funzionamento del protocollo, molti dei messaggi crittografati scambiati tra i nodi della rete contengono al loro interno un timestamp; il destinatario può infatti scartare il messaggio qualora l orario ivi contenuto differisca da quello di sistema per più di 5 minuti. L intervallo di 5 minuti appena menzionato serve a garantire una certa tolleranza riguardo la sincronizzazione degli orologi sulla rete e rappresenta l impostazione di default in tutte le implementazioni. Si osservi però che anche 5 minuti possono essere sufficienti ad un attaccante, magari provvisto di un software automatico, per catturare e rispedire un messaggio. Replay caches. L ultimo meccanismo di difesa che Kerberos utilizza per contrastare i replay attack è la replay cache. Ogni servizio tiene traccia degli authenticator ricevuti per tutta la loro validità in modo da impedirne il riutilizzo. Time Services non sicuri Come abbiamo visto gli authenticator sono costruiti sulla corretta sincronizzazione degli orologi delle macchine. Se, per esempio, un host viene ingannato riguardo l ora corretta, un authenticator scaduto può essere riutilizzato 86

105 Stili di autenticazione Kerberos facilmente. Allo stato attuale questo tipo di attacco può essere realizzato con facilità dato che molto spesso non vengono utilizzate le migliori implementazioni disponibili e la stragrande maggioranza di esse non supporta alcun tipo di autenticazione. Di contro si può sostenere che costruire un qualsiasi sistema di autenticazione, come Kerberos, assumendo un già autenticato servizio sottostante sia di per sé assurdo: si tratterebbe di duplicare la stessa funzione oppure non sarebbe molto sensato costruire qualcosa di cui già si dispone; al contrario una buona soluzione potrebbe essere rendere quest ultimo esplicitamente parte del protocollo di autenticazione. Si potrebbe dire che Kerberos coinvolge, in un rapporto di mutua fiducia, quattro parti: client, server, KDC e time server. Spoofing Login In un ambiente tradizionale è abbastanza semplice sostituire il comando di login con uno che registra la password utente prima di usarla per l autenticazione Kerberos. Questo tipo di attacco annullerebbe il beneficio portato dal non comunicare le password in chiaro. Questo problema non è relativo solo a Kerberos ma il sistema in oggetto rende molto difficile la contromisura tipica per queste situazioni: le one-time password, cioè l utilizzo di password valide solo una volta. Un tipico schema di funzionamento per le one-time password impiega una chiave segreta, condivisa da utente e server, e un qualche dispositivo in dotazione all utente. Il server sceglie un numero casuale e lo trasmette all utente. Quest ultimo, aiutato dal dispositivo, cifra il numero con la chiave segreta e invia il risultato al server. Questo, se ottiene lo stesso risultato applicando la trasformazione, considera il client autenticato. Kerberos però non prevede un simile schema challenge/response al momento del login: la risposta alla richiesta di login è sempre crittata con la chiave a lungo termine dell utente. Quindi, a meno di non ricorrere all uso di una smart-card, ciò preclude l utilizzo di questa tecnica. Un alternativa richiede che il server scelga un numero R e usi la chiave a lungo termine K c per crittarlo ottenendo {R} Kc. Questo valore, invece di K c, sarà usato per crittare la risposta del server. Infine, è sempre possibile fornire una periferica di boot sicura o effettuare un boot via rete anche se, per questo secondo caso, non sono stati ancora sviluppati protocolli sicuri. Il TGS e la chiave di sessione Durante l autenticazione cross-realm tutti i TGS lungo l authentication path possono conoscere la chiave di sessione utilizzata dal client per dialogare con il server. Infatti, ogni TGS, crea e quindi conosce la chiave di autenticazione che verrà usata dal client per contattare il TGS seguente lungo la catena di autenticazione. Memorizzando ad ogni passo la chiave di autenticazione è possibile seguire tutta la catena fino ad ottenere la chiave di sessione. Ciò avviene anche in un contesto single-realm ma, in questo caso, l authentication path consiste di un solo TGS. 87

106 Stili di autenticazione Kerberos I TGS e i Client Questo attacco è realizzabile in un contesto multi-realm. Ogni TGS malintenzionato può impersonare un client C al di fuori del reame cui C stesso afferisce, anche nel caso in cui quest ultimo non abbia mai contattato il TGS. Per portare l attacco il TGS crea un ticket per un reame remoto in modo da far apparire C come il mittente della richiesta. Non è necessario che C sia coinvolto direttamente e nemmeno che avesse precedentemente contattato il server: la sua stessa esistenza non è importante ai fini dell attacco. Il TGS compromesso non può fingere di essere C nello stesso dominio del client dato che, per le autenticazioni intra-realm, non viene, ovviamente, utilizzato il protocollo cross-realm. Attacchi al meccanismo di routing fra reami Per come Kerberos funziona in un contesto multi-realm, un client è capace di conoscere l authentication path tenendo traccia dei Ticket Granting Server che incontra. Nonostante questo, però, un TGS malintenzionato può ingannare il client facendogli credere che un determinato TGS non sia sull authentication path, manipolando così il resto dell authentication path senza che C se ne accorga. Altri Attacchi Dato che Kerberos è, in fin dei conti, solo un servizio di autenticazione ci sono diverse minacce inerenti la sicurezza da cui non può proteggere la rete. Questi attacchi non sono specifici contro Kerberos ma sono comuni ad ogni servizio di autenticazione. Denial of Service. Un attacco Denial of Service può essere portato contro il KDC inondandolo di richieste di autenticazione. Il grande numero di richieste rallenta di fatto le risposte agli utenti legittimi o, in casi estremi, mandare in crash la macchina ospitante il KDC. Si può consigliare di proteggere con dei firewall la rete Kerberos o di installare dei KDC slave per limitare il problema. La talpa. Kerberos non può proteggere da utenti autorizzati che decidono di manomettere il sistema, come, ad esempio, un amministratore che decide di cancellare il database dell AS. Social Engineering e Password Exposure. Così come non può difendere il sistema da utenti che divulgano le password di accesso deliberatamente o come conseguenza di un attacco di Social Engeneering nè tantomeno dall uso delle stesse password di Kerberos con sistemi meno sicuri. In questo modo un attaccante può, con minor sforzo, attaccare un servizio meno sicuro per ottenere una coppia username/password valida anche per Kerberos. 88

107 Stili di autenticazione Kerberos Problemi del software Kerberos. È bene tenere presente, inoltre, che un sistema complesso come Kerberos può soffrire di problemi derivanti da errori di programmazione che possono palesarsi anche in un secondo tempo. Sarà buona norma quindi controllare l esistenza di aggiornamenti e patch per mantenere il sistema sempre aggiornato Sviluppi di Kerberos Anche se Kerberos ha ormai più di venti anni di vita continua ad evolversi integrando nuove tecnologie e debellando nuove minacce. Così il gruppo che sviluppa Kerberos ha rilasciato diverse estensioni che forniscono le capacità necessarie all utilizzo di questo sistema anche in futuro, come il supporto per migliori algoritmi crittografici o per tecnologie che permettano di superare alcune delle limitazioni insite nel sistema di autenticazione. Kerberos e la crittografia a chiave pubblica Come già menzionato Kerberos basa le sue comunicazioni sulla crittografia simmetrica. Il risultato è che, in primo luogo, essendo la password un segreto condiviso tra utente e KDC, è sufficiente riuscire ad ottenere la chiave per fingere di essere l utente; in secondo luogo è necessario effettuare preventivamente una registrazione presso il KDC per poter accedere alla rete Kerberos. A entrambe queste problematiche si può rimediare utilizzando la crittografia a chiave pubblica nella fase iniziale dell autenticazione [Tun05]. Quando il KDC genera la sua risposta, incapsulando la chiave di sessione per il TGT, invece di criptarla con la chiave a lungo termine, viene utilizzata una chiave casuale a sua volta criptata con chiave pubblica dell utente. Così solo l utente, in possesso della sua chiave privata, può ottenere la chiave casuale con la quale estrarre infine la chiave di sessione. Ma perché è necessario usare una chiave casuale e non è semplicemente possibile criptare la chiave di sessione con la chiave pubblica dell utente? Una ragione sta nel fatto che la crittografia a chiave pubblica è abbastanza dispendiosa da un punto di vista computazionale ed è quindi solitamente applicata su dati di piccola lunghezza come, appunto, una password: le funzioni di libreria che implementano la crittografia a chiave pubblica, a prescindere dalla lunghezza dei dati, criptano usando lo schema della chiave simmetrica con una chiave casuale e poi criptano la chiave appena generata con la chiave pubblica. In più anche se si fa riferimento alla sola chiave di sessione, Kerberos incapsula anche un certo numero di altri dati con essa e quindi le performance della crittografia a chiave pubblica diventano un fattore importatante. Esiste comunque ancora un problema. Anche se l utente e il KDC non devono condividere una chiave a lungo termine devono comunque condividere una qualche tipo di associazione. In altri termini il KDC non ha conferma del fatto che la chiave pubblica che l utente sta chiedendo di usare appartenga effettivamente a lui. Un attaccante potrebbe generare una coppia di chiavi presentarle al KDC, ed utilizzarle per impersonare un altro utente. Per impedire ciò le chiavi pubbliche devono essere certificate da una qualche autorità di certificazione (CA). 89

108 Stili di autenticazione Kerberos In realtà il CA non cripta la chiave pubblica con la propria chiave privata per lo stesso motivo per cui il KDC non cripta la chiave di sessione con la chiave pubblica dell utente. E non la cripta con una chiave casuale perché la chiave pubblica e l identità dell utente non devono restare confidenziali. Invece passa la chiave pubblica ad una funzione hash non invertibile. Il digest risultante viene criptato con la chiave privata del CA. Solo il CA avrebbe potuto legare la chiave pubblica all identità dell utente dato che non è possibile creare nessun altra stringa che dia come risultato della funzione hash gli stessi byte. Un ultimo beneficio apportato dall introduzione della crittografia a chiave pubblica è rappresentato dalla diminuzione del numero delle chiavi che devono essere memorizzate dalla rete. Infatti, in un contesto a chiavi segrete tra C client e S server, si dovrebbero memorizzare C S chiavi di sessione e C + S chiavi private condivise, mentre, sfruttando la crittografia asimmetrica, le chiavi pubbliche da memorizzare risulterebbero solo C + S. In generale, una rete di n utenti comunicanti con crittografia a chiave segreta produce un totale di n(n 1)/2 chiavi condivise mentre la stessa rete, utilizzando la crittografia a chiave pubblica, richiederebbe solo n chiavi pubbliche. Si può quindi affermare che l introduzione della crittografia a chiave pubblica porterebbe ad una migliore scalabilità del sistema. Kerberos e le smart card È tradizione che Kerberos basi il meccanismo di autenticazione esclusivamente sulla conoscenza di un segreto; questo è solo uno dei modi con cui è possibile dimostrare la propria identità; un altro metodo consiste nell essere autenticati per qualcosa che si ha. Le smart card sono basate proprio su questo concetto ed esistono implementazioni di Kerberos che contemplano proprio l utilizzo delle smart card nella fase iniziale dell autenticazione [Gar03]. L utilizzo delle smart card risolve uno dei problemi più seri di Kerberos: l impossibilità per un utente di ricordare una password molto robusta. Le chiavi a lungo termine devono infatti essere memorizzate dall utente e questo porta inevitabilmente alla scelta di stringhe con bassa entropia e vulnerabili ad attacchi a dizionario. In più viene limitata l esposizione delle chiavi crittografiche; queste sono conservate all interno della smart card in un area di memoria protetta dalla quale non possono essere estratte; non è infatti necessario portare all esterno le chiavi dato che tutte le operazioni crittografiche vengono svolte dal chip presente sulla carta. Anche se un attaccante riuscisse ad ottenere il controllo di una workstation non avrebbe quindi accesso alle chiavi necessarie per autenticarsi verso il sistema. La smart card è un dispositivo progettato per resistere agli attacchi, il che rende una eventuale operazione di cracking molto difficoltosa sebbene non impossibile: esistono tecniche per restringere il campo di ricerca di un attacco a forza bruta basate sull analisi del consumo della smart card e dei tempi di risposta che queste forniscono se sollecitata con input studiati ad-hoc. Queste tecniche hanno dato grandi risultati ma si tratta, per ora, di attacchi alla portata solo di cracker molto motivati. Quando un nuovo utente deve essere abilitato, viene prodotta una coppia di 90

109 Stili di autenticazione Kerberos chiavi asimmetriche; la parte pubblica viene firmata da una certification authority e inserita insieme al certificato all interno della smart card che viene affidata all utente. Quando quest ultimo utilizza la carta, la inserisce in un lettore di smart card connesso al computer; questo richiederà, per conto della carta, un codice PIN col quale sbloccare la porzione di memoria che contiene la coppia di chiavi. In questo modo la risposta dell AS viene decifrata direttamente sulla smart card e la coppia di chiavi non è mai accessibile al computer utilizzato dall utente. 91

110 Parte II Requisiti, metodologia e contesto

111 Capitolo 3 Analisi estesa dei requisiti I requisiti sono una parte fondamentale della progettazione in generale, tanto fondamentale che una errata identificazione dei requisiti durante questa fase rischia di portare al fallimento di un progetto, inteso sia come abbandono, sia come allungamento incontrollato dei tempi stimati per la realizzazione dello stesso. Con requisito di intende ogni informazione, ottenuta in qualche modo, circa le funzionalità, i servizi, le modalità operative e di gestione del sistema da sviluppare. Lo scopo dell analisi dei requisiti è quello di identificare ciò che il sistema deve fare e descriverlo nel linguaggio dell utente del sistema (in modo tale che sia comprensibile anche a chi non ha conoscenze di progettazione), e di assegnare ai requisiti una priorità, utile per la loro gestione. Infatti la complessità di un sistema è determinata in parte dalle sue funzionalità (functional requirements) e in parte dà dei vincoli globali che incidono sullo sviluppo del sistema; ad esempio, fattori come i costi, prestazioni, robustezza, portabilità, alle volte gravano pesantemente sulla bontà del prodotto finale 1. Tali vincoli sono spesso chiamati requisiti non-funzionali (non-functional requirements, NFR 2 ) e giocano un ruolo centrale durante tutto il processo di progettazione e poi sviluppo: una volta condotta a termine la Goal-Aanalysis (GA)[Ant96] o altre tecniche simili, è necessario compiere una scelta fra tutte le possibili soluzioni alternative tenendo conto anche dei NFR. L analisi dei NFR aiuta l analista a capire quale soluzione meglio si adatta al dominio applicativo. In sintesi definiamo: 1 In sintesi descrivono il cosa il sistema deve fare, e non il come. 2 In sintesi definiscono parzialmente il come implementare una determinata funzionalità

112 Analisi estesa dei requisiti Requisiti funzionali, R.1.* requisiti funzionali: le specifiche che il sistema dovrà implementare, ovvero ciò che questo dovrà fare (descrivono il cosa, e non il come ). requisiti non funzionali: i limiti o i vincoli di un sistema (quasi sempre non misurabili). In questo capitolo è esposta l analisi sistemica dei requisiti funzionali e non funzionali. È opportuno sottolineare che l elenco che andremo a redarre nelle seguenti pagine non deve essere interpretato come l esposizione dei requisiti integralmente recepiti, ma come stesura analitica dei requisiti per i principali domini applicativi a cui si fa riferimento in maniera diretta o diretta. Attraverso questo elenco, successivamente sarà possibile stabilire, durante la fase progettuale, quali requisiti il presente lavoro dovrà necessariamente soddisfare, quali invece dovrà abilitare oppure quali ignorare. Il concetto chiave è la chiarezza dell intero modello dei requisiti (sistema di attributi compreso) per la possibilità di poterlo gestire e tracciare nel progetto, aumentandone la comprensibilità ed abilitandone la validazione[kpsc07]. Puntualizziamo che l intento non è quello di re-ingegnerizzare i processi o le procedure esaminate, ma piuttosto si vogliono mettere in evidenza le caratteristiche tecniche di cui i sistemi esaminati dovrebbero essere dotati. Anticipiamo che tutti i campi di applicazione presi in considerazione possiedono una caratteristica ricorrente (più o meno esplicita): si interessano ad una vasta platea di utenza, su scala possibilmente globale. Per questo motivo saranno descritti i requisiti derivati dai sistemi distribuiti. Un sistema distribuito, come definito in [TW97], è un insieme di entità di elaborazione indipendenti, che appaiono come un singolo sistema coerente. Ciascuna entità di un sistema distribuito considera remote le altre entità e le rispettive risorse, mentre considera locali le proprie. Ogni entità può variare per dimensioni e funzioni e, a sua volta, può essere un sotto-sistema distribuito. In generale i sistemi distribuiti sono usati largamente poiché permettono a calcolatori autonomi, e per transitività agli utenti, di condividere risorse. Tali caratteristiche sono anche usate per sviluppare applicazioni che consentono a gruppi di persone di lavorare assieme, su un progetto o un compito, da luoghi remoti attraverso reti telematiche. 3.1 Requisiti funzionali, R.1.* I requisiti funzionali qui esposti verranno riferiti a: risorse materiali (fisiche) ovvero i documenti che fanno parte del sistema; risorse di contesto ovvero la piattaforma collaborativa entro la quale avviene la gestione dei documenti. Le organizzazioni, che basano il proprio coordinamento su un ambiente distribuito ed orientato a favorire il lavoro collaborativo si trovano necessariamente a gestire non solo risorse fisiche e tangibili, ma anche e soprattutto a lavorare con risorse che non possono essere riferite in modo diretto, ma che necessariamente prevedono sistemi ed apparati che svolgano la funzione di intermediari tra la risorsa stessa e l utente finale che deve consultarla, gestirla o modificarla. 94

113 Analisi estesa dei requisiti Requisiti funzionali, R.1.* Requisiti per le risorse materiali, R.1.1.* I requisiti funzionali relativi alle risorse materiali, che verranno esaminati requisiti direttamente riferiti alla gestione e comportamento dei documenti e requisiti riferiti alla trasparenza delle operazioni connesse alla gestione. Requisiti per la gestione dei documenti, R * I requisiti funzionali per la gestione dei documenti sono strettamente collegati a quelli che devono essere rispettati nei tradizionali sistemi di Document Management (DMS) [Gan06], I DMS vengono utilizzati all interno di organizzazioni che hanno la necessità di gestire un alto numero di documenti: oltre all amministrazione ed alla conservazione delle risorse c è infatti la necessità di archiviarle in modo che ognuna di esse possa essere trattata autonomamente. Non è tuttavia previsto l uso di collegamenti (attraverso link) fra i vari documenti archiviati, fatto che contribuisce allo scarso utilizzo di evoluti metodi di ricerca delle risorse. Inoltre i DMS sono progettati con l ottica di essere applicati ad organizzazioni strutturate in modo centralizzato. I requisiti che saranno trattati nel seguente paragrafo nascono quindi da una rielaborazione di quelli relativi ai DMS, tenendo presente che il sistema attualmente in esame deve essere applicato ad ambiti come quello della Pubblica Amministrazione ovvero, come si è già detto, di tipo distribuito e non centralizzato ed orientati al riuso non solo dei documenti ma anche dell informazione contenuta al loro interno. Si vogliono quindi individuare i requisiti di un sistema documentale informatico che sia in grado di gestire ogni aspetto dei documenti a partire dal loro ciclo di vita, dalle informazioni in essi contenute e dalle relazioni esistenti fra di essi. In tale ottica, devono essere rispettati i seguenti requisiti di base [Gan06]: R creazione (creation), il sistema deve offrire la possibilità di creare nuovi documenti; R acquisizione (capture), il sistema deve essere in grado di acquisire documenti preesistenti (anche in formato cartaceo). Questo può avvenire attraverso varie tecnologie come ad esempio la digitalizzazione delle immagini o la riproduzione tramite immissione manuale dei dati; R archiviazione (storing), il sistema deve disporre di un metodo di archiviazione efficace ed efficiente che permetta la modifica dei documenti e che sia capace di gestire un eventuale ingente crescita del volume dei dati; R indicizzazione (indexing), deve consentire la catalogazione dei documenti al fine di facilitare il recupero da parte degli utenti. Può risultare conveniente organizzare in tassonomie e/o ricorrere all indicizzazione di tutto il testo del documento archiviato tramite l uso di parole chiave definite manualmente o di identificativi calcolati automaticamente; 95

114 Analisi estesa dei requisiti Requisiti funzionali, R.1.* R recupero di documenti (retrieval), il sistema deve permettere il recupero dei documenti in base a criteri di ricerca compatibili con i criteri di indicizzazione utilizzati e con le tassonomie eventualmente definite; R accesso ai documenti (access), il sistema deve garantire, oltre alla reperibilità, anche l accessibilità ai documenti ed alle informazioni in essi contenute. L accesso ad un dato documento deve essere di tipo selettivo, ovvero deve avvenire in base ad opportune autorizzazioni di cui deve essere dotata l entità che gestisce il documento stesso; Requisiti di versioning, R * Il versionamento dell informazione è determinante per una efficace collaborazione in quanto permette di avere sotto controllo l evoluzione dei contenuti. Con versioning si indica la memorizzazione della evoluzione di una risorsa tenendo memoria delle diverse configurazioni durante il suo ciclo di vita: una volta memorizzate, divengono immutabili nel tempo, infatti ogni modifica futura genera una nuova versione della risorsa (stabilità delle versioni). Al fine di versionare un documento, devono essere tenuti in considerazione i seguenti punti [Ask02]: R utilizzare attributi da affiancare ad ogni documento, si tratta di metadati 3 che descrivono qualsiasi tipologia di risorse, come ad esempio descrizioni bibliografiche o indicazioni relative alle restrizioni o all uso. Deve essere possibile creare, modificare, cancellare, interrogare, leggere e cancellare i metadati relativi alle risorse del sistema. Gli attributi sono risorse essi stessi ed a loro volta possiedono metadati, inoltre possono influenzare le operazioni di spostamento, copia e cancellazione; R utilizzare relazioni attraverso link, servono per memorizzare la connessione tra risorse diverse, con molteplici scopi. Possono, ad esempio, stabilire un ordine nella navigazione o collegare informazioni per una corretta gestione dei documenti. Deve essere possibile creare, modificare, interrogare, leggere e cancellare le relazioni tipizzate; R applicare meccanismi di blocco o locking, necessari per risolvere il problema della perdita degli aggiornamenti e delle sovrascritture. È una tecnica di prevenzione che mantiene consistenti le informazioni condivise da più utenti, ovvero quelle coinvolte nell authoring distribuito 4. Il lock e l unlock su più risorse sono operazioni che devono avvenire nello stesso intervallo di tempo al fine di prevenire la collisione tra le 3 Come riportato in [Cam06b], i metadati sono informazioni strutturate che descrivono, esplicano, localizzano qualsiasi cosa che renda più facile recuperare, usare o gestire una risorsa informativa. Spesso vengono definiti come dati relativi ai dati o come informazioni relative alle informazioni. Un record di metadati consiste in un insieme di attributi o di elementi, necessari a descrivere la risorsa. 4 Si verificano situazioni di authoring distribuito quando più utenti hanno i permessi per gestire una risorsa comune e può essere di tipo sequenziale, parallelo o di entrambe le tipologie contemporaneamente. 96

115 Analisi estesa dei requisiti Requisiti funzionali, R.1.* modifiche. Le funzioni di lettura e scrittura devono essere indipendenti da quelle di lock e unlock: deve essere possibile bloccare una risorsa anche senza effettuare su di essa un operazione di lettura o scrittura 5 ; R consentire l uso di prenotazioni, utili nei casi di authoring concorrente in cui più utenti lavorano su una risorsa condivisa nello stesso tempo. In tali situazioni risulta di fondamentale importanza conoscere lo stato di un documento, ad esempio quante persone lo stanno leggendo o modificando. Con opportuni diritti, deve essere possibile: conoscere la coda degli utenti prenotati (reservation query); fornire la possibilità di abbandonare la coda, agli utenti che ne fanno parte (release reservation). R consentire l aggiornamento differenziale, utilizzato nei casi in cui l authoring è distribuito in vaste aree geografiche. In tali situazioni possono infatti esistere problemi relativi al mantenimento e alla qualità della connessione, fatto che inevitabilmente causa l inefficienza nell aggiornamento delle risorse. Per rendere più veloce e funzionale l attività di modifica di una risorsa, deve essere possibile scrivere solamente le variazioni subite dalla stessa rispetto alla precedente versione 6, piuttosto che trasmettere l intera risorsa; R gestire collezioni, ovvero fare uso di contenitori di risorse che possono includere anche altre collezioni. Una risorsa appartenente ad una collezione può essere inclusa direttamente o per riferimento. Se una risorsa è riferita direttamente le operazioni vengono applicate direttamente, altrimenti hanno effetto solo sul riferimento. Deve essere possibile creare nuove collezioni, ottenere le risorse, aggiungerle o rimuoverle; R fare uso di una opportuna gestione dei nomi che garantisca la corretta attuazione delle seguenti attività: copia, deve essere possibile duplicare una risorsa senza che il client 7 debba prima proteggerla e salvarla. Una modifica ad una risorsa copiata deve coinvolgere solo i suoi contenuti. La copia di una collezione comporta la copia di tutte le risorse in essa contenute e degli attributi correlati. È necessario stabilire in anticipo lo spazio sorgente e quello di destinazione; spostamento e/o ri-nominazione, spesso è necessario cambiare il nome ad una risorsa, ad esempio perché viene adottata una nuova convenzione dei nomi o perché il nome originale è errato. È 5 Quando non sono abilitati o necessari meccanismi di versioning. 6 Con il termine versione, si intende lo stato di un documento in un determinato momento temporale. Ogni modifica effettuata sul documento ne genera una versione successiva. L insieme di tutte le versioni di un documento, costituisce il ciclo di vita dello stesso. 7 In questo caso, con il termine client, si indicano tutti i computer che utilizzano il servizio fornito da un server. 97

116 Analisi estesa dei requisiti Requisiti funzionali, R.1.* preferibile introdurre una nuova operazione piuttosto che utilizzare, in sequenza, le attività di copia e cancellazione della risorsa. Deve essere possibile assegnare un nuovo nome alla risorsa senza che il client debba leggerla e risalvarla con un nome diverso; cancellazione, devono essere possibili sia la cancellazione di una risorsa, e conseguentemente delle sue copie, che la cancellazione di una relazione, ovvero l eliminazione del collegamento alla risorsa riferita. Requisiti di trasparenza, R * I seguenti requisiti possono essere riferiti a differenti ambiti e funzioni del sistema, ma nel nostro caso sono applicati alle modalità di come dovrebbe avvenire la gestione delle risorse ispirandosi a [Mea03]: R trasparenza dell accesso, nasconde i dettagli del meccanismo di accesso alle risorse, comprese la rappresentazione dei dati e le tecniche di invocazione delle operazioni; R trasparenza dei fallimenti, maschera i fallimenti e possibilmente provvede al recupero delle risorse (recovery) con una tolleranza ai guasti misurabile; R trasparenza della localizzazione, gli utenti non devono essere a conoscenza della locazione fisica delle risorse; R trasparenza della replicazione, il sistema può mantenere identiche le istanze della stessa risorsa su qualsiasi host; R trasparenza della concorrenza, un generico utente non deve essere condizionato dalle azione svolte dagli altri utilizzatori del sistema, pertanto non deve accorgersi, coerentemente con le politiche di accesso, se una risorsa viene utilizzata anche da altri. Uno dei concetti che sono stati già esaminati e che contribuisce, se richiesto, al raggiungimento di un buon livello di trasparenza nella gestione documentale è la previsione di un meccanismo di versionamento delle informazioni gestite dal sistema. In generale infatti il concetto di versioning potrebbe essere considerato completamente trasparente all utente, tuttavia quando vengono utilizzate alcune tipologie di informazioni o di documenti è necessario che gli utenti siano a conoscenza della versione di cui fanno uso. In conclusione, il requisito di trasparenza relativo al versioning, va discusso in base all ambito di applicazione del sistema stesso e quindi in base alla tipologia di informazioni gestite. Requisiti di indirizabilità, R * Il sistema dei nomi usato nel web, gli URL (Uniform Resource Locator), è strutturato in modo da rendere inscindibili contenuto informativo e locazione 98

117 Analisi estesa dei requisiti Requisiti funzionali, R.1.* fisica di una risorsa. Al contrario nell ambito dell attuale trattazione è richiesto un sistema dei nomi che permetta di identificare una risorsa indipendentemente da dove questa risiede. Inoltre si deve tenere presente che più gruppi di lavoro spesso si trovano ad utilizzare la stessa risorsa e ciascuno di essi ha l esigenza di potersi riferire ad essa con un nome adatto rispetto al proprio contesto. Possono pertanto distinguere: R un insieme di nomi capaci di indicare una risorsa in modo univoco; R un insieme di nomi che rappresenta i possibili alias di una data risorsa; R uno spazio dei nomi che indichi la locazione fisica di una risorsa. Requisiti sulla codifica degli indirizzi, R * Ogni risorsa deve poter essere individuata in modo univoco, caratteristica che può essere ottenuta grazie ad un opportuno sistema di nomi che deve rispettare i seguenti requisiti: R coerenza con altre codifiche, la codifica dei nomi deve essere il più possibile coerente con quella precedentemente adottata da altri sistemi; R semplicità del confronto, l algoritmo per confrontare i nomi tra loro deve essere semplice, locale e deterministico; R trascrivibilità da parte dell uomo, nomi devono essere facilmente trascrivibili dall uomo. In tale ottica devono essere: composti da una sequenza sufficientemente limitata di caratteri, case insensitive e non complicati dall uso di caratteri speciali; R trasportabilità, un nome deve essere identicamente trasportabile sia nei messaggi dei comuni protocolli internet sia su carta; R elaborabilità da parte delle macchine, un nome deve essere processabile dai calcolatori; R riconoscibilità, la codifica dei nomi deve essere riconoscibile durante il parsing 8 di un testo Requisiti di contesto, R.1.2.* Una volta definiti i requisiti relati alla gestione dei documenti ed alle esigenze di trasparenza, si può passare all analisi dei requisiti dei sistemi di conessi al contesto in cui le risorse sono elaborate. Tali requisiti si possono suddividere in due grandi categorie: quelli relativi alle esigenze di collaborazione tra gli utilizzatori del sistema (groupware) e quelli che riguardano la codifica dei nomi usati per identificare e gestire le risorse. 8 Il parsing è il processo di analizzare uno stream continuo di caratteri (letto per esempio da un file o una tastiera) in modo da determinare la sua struttura grammaticale grazie ad una data grammatica formale. Un parser è un programma che esegue questo compito. 99

118 Analisi estesa dei requisiti Requisiti funzionali, R.1.* Requisiti di groupware, R * I requisiti di groupware riguardano tutti gli strumenti atti a facilitare la collaborazione in un gruppo di individui. Solitamente le tecnologie groupware sono classificate in base a due principali aspetti: lo spazio e il tempo. In base a tale prospettiva di analisi e tenendo presente il noto modello Johansen [Kap97], conosciuto anche col nome di modello dei 4 quadranti (figura figura 3.1) si individuano le condizioni in cui la collaborazione si può collocare. spazio tempo stesso intervallo temporale intervalli temporali disgiunti stesso luogo (co-locazione) interazione faccia a faccia interazione asincrona luoghi diversi (a distanza) interazione sincrona distribuita interazione asincrona distribuita Figura 3.1: Modello a quattro quadranti Le tipologie di interazione tra gli individui che compongono il gruppo, o tra gruppi, sono infatti principalmente determinate dalle modalità spazio-temporali con cui vengono stabilite. Lo scopo principale dei sistemi groupware è quello di garantire o abilitare i seguenti aspetti[mo94]: R molteplici processi, i gruppi esistono, all interno di un contesto lavorativo, per svolgere molti compiti diversi e che spesso vengono ridefiniti a seguito di mutamenti socio-economici; R molteplici metodologie di lavoro, sono necessarie per rendere efficiente ed efficace la modularità. Ogni processo lavorativo può essere infatti scomposto in compiti minori, ciascuno dei quali richiede opportune ed appropriate tecniche di realizzazione. Inoltre non tutti i membri dei gruppi adottano lo stesso metodo lavorativo: alcuni possono preferire un lavoro più solitario o isolato, altri invece ricercare l influenza del gruppo a cui appartengono. I mezzi di comunicazione offrono molte soluzioni diverse in base al tipo di problema da superare e sono in continua evoluzione, pertanto risulta indispensabile progettare un sistema aperto. Anche in questo caso un approccio modulare può essere efficace nella realizzazione e nell eventuale aggiornamento del sistema; R sviluppo del gruppo, i gruppi sono influenzati dalla dinamica dell ambiente e delle interazioni tra gli individui. Si hanno variazioni a livello sociale quando si verifica l entrata o l uscita di un membro, quando si disgregano o si costruiscono relazioni all interno dell organizzazione 100

119 Analisi estesa dei requisiti Requisiti funzionali, R.1.* di cui il gruppo fa parte, in risposta a cambiamenti ambientali. Nel momento in cui un organizzazione svolge la propria attività basandosi sul lavoro di gruppo, deve tenere presente il principio di equilibrio interrotto, proposto in [MO94], secondo tale teoria il lavoro di gruppo progredisce in presenza di lunghi periodi di inerzia, interrotti da rivoluzionari e limitati periodi di piccoli mutamenti. Per consentire un buon rendimento del lavoro svolto da un gruppo è utile usare tecniche per incrementare il consenso, definire ruoli, ridistribuire il potere, incrementare l interazione, conservare memoria delle passate attività per programmare al meglio quelle future, pianificare la crescita del gruppo. Un altro aspetto fondamentale di cui si deve tenere conto è l awareness, ovvero la consapevolezza del lavoro svolto dal gruppo che consente una notevole integrazione tra membri e conseguentemente un maggiore risultato individuale; R metodi di interazione interscambiabili, la comunicazione all interno delle organizzazioni può avvenire grazie a metodi e tecnologie differenti, pertanto il sistema groupware deve essere in grado di coprire la maggior parte del modello a quattro quadranti rappresentato in figura 3.1 al fine di consentire, in modo integrato, il passaggio delle interazioni da un quadrante all altro al mutare delle condizioni ambientali; R molteplici caratteristiche comportamentali, i componenti dei gruppi assumono diversi atteggiamenti nel prendere parte all interazione e nel completare e svolgere i propri compiti. Tali comportamenti dipendono dal grado di coesione, dallo stress, dai ruoli assegnati ai singoli componenti del gruppo o al gruppo stesso. La presenza inevitabile di comportamenti diversi all interno di un gruppo o fra gruppi differenti è di fondamentale importanza nello svolgimento del lavoro, per questo motivo è necessario che l organizzazione non sottovaluti l aspetto sociale legato al groupware. A tale proposito risulta utile individuare ed analizzare i seguenti aspetti: comportamenti chiave, identificano i principali metodi comportamentali che vengono assunti, dagli individui del gruppo, nel dominio applicativo trattato; elementi catalizzanti, sono le variabili del sistema che influiscono sui comportamenti. Ad esempio il tempo disponibile ha un grosso impatto sulla concentrazione e sulla coesione tra individui. Cambiando queste variabili è possibile controllare l operatività del gruppo; prospettive dell utente, sono gli aspetti che potrebbero consentire all utente l automazione del lavoro, la modifica e/o la personalizzazione degli strumenti usati; R permeabilità alle barriere da parte del gruppo, i limiti fisici e spaziotemporali possono creare divisioni che, a loro volta, determinano differenze penalizzanti tra individui. I confini del gruppo devono essere 101

120 Analisi estesa dei requisiti Requisiti funzionali, R.1.* permeabili, nel senso che devono consentire meccanismi di scambio delle informazioni che avvengano in modo non forzato. Tale necessità è dettata da fattori economici e sociali, come ad esempio la presenza di un autorità esterna o la dipendenza da altri gruppi. Risulta quindi di fondamentale importanza stabilire e gestire i confini del gruppo in modo da risolvere il problema dell interoperabilità poiché il gruppo si dovrà confrontare e relazionare con il mondo esterno; R regolazione ed adattamento del contesto nel quale il gruppo opera, il contesto deve essere visto come un opportunità piuttosto che come un ostacolo all adattabilità del gruppo. Ogni gruppo conosce le proprie capacità e, in base ai compiti che gli vengono affidati, è capace di stabilire anche quali sono le proprie esigenze. La gestione di tali necessità può essere affidata ad un amministratore che renda possibile la personalizzazione del gruppo, favorendo una modalità di visualizzazione delle informazioni o un metodo di interazione rispetto ad altri possibili. Requisiti per le identità, R * I seguenti requisiti intendono fornire i principi di cui un sistema per la gestione delle identità dovrebbe essere dotato in uno scenario applicativo in rete al fine di ottenere successo. La formulazione dei seguenti vincoli, leggi di Metcalfe [Cam06a], è determinata dalle necessità stesse degli utenti. Per ogni utente deve essere assicurato e comunicato un trattamento etico dei loro dati. Gli utenti esigono safety e security dai servizi in rete nel momento in cui vengono richiesti dati personali e sensibili della persona. R Controllo dati utente e consenso. Il sistema di gestione delle identità deve rivelare le informazioni per le quali l utente ha espresso il consenso. R Divulgazione minima quando obbligatoria. La soluzione che divulga il minimo insieme di informazioni personali e limita il loro uso è la soluzione più stabile a lungo termine. R Organizzazioni accreditate. I sistemi di identità digitali devono essere progettati in modo che la divulgazione delle informazioni personali sia limitata a organizzazioni che abbiano una ruolo necessario e giustificabile in una data interazione. R Identificazione selettiva. Un sistema universale di identità deve supportare identificatori omnidirezionali utilizzabili da soggetti pubblici ed unidirezionali utilizzabili da soggetti privati, per facilitare rispettivamente il discovery e per impedirlo. R Pluralismo di operatori e tecnologie. Un sistema di identità universale deve abilitare e incanalare la cooperazione di molteplici tecnologie fornite da differenti e molteplici provider. 102

121 Analisi estesa dei requisiti Requisiti funzionali, R.1.* R Integrazione umana. Un sistema di identità universale deve recepire l utente come parte integrante del sistema distribuito attraverso meccanismi di comunicazione uomo-macchina non ambigui in grado di proteggerlo da attachi alla sua identità. R Esperienze consistenti attraverso contesti. I sistemi di identità devono garantire ai propri utenti la possibilità di selezionare in maniera dinamica una identità contestuale di convenienza ovvero una identità surrogato della vera identità con cui accedere ai servizi; ad esempio una per navigare, una per la collaborazione in rete, una per i servizi al cittadino, una per i servizi finanziari. Requisiti di awareness, R * I requisiti di awareness si suddividono a loro volta in due ulteriori categorie: quelli relativi alla comunicazione fisica e quelli relativi alla comunicazione logica. I requisiti di comunicazione fisica sono relativi alla necessità di avere un interconnessione delle reti di comunicazione su larga scala, necessaria per gestire un efficiente ed efficace scambio di informazioni, che sta alla base del lavoro collaborativo. Nel contesto sono pertanto di interesse minore. I requisiti di comunicazione logica, e sono i più interessanti, riguardano invece la comunicazione fra entità logiche di alto livello, come ad esempio la gestione di tutte le operazioni effettuate all interno di un gruppo di lavoro al fine di soddisfare l awareness favorendo la condivisione e lo scambio di informazioni. I requisiti che verranno evidenziati emergono a fronte delle domande che ciascun partecipante alla collaborazione potrebbe porsi durante lo svolgimento di una attività collaborativa.[gg96]. Sono parzialmente sovrapposti ai requisiti di Groupware, ma in questo caso l attenzione è completamente incentrata sull individuo. R presenza, indica chi sta partecipando alla attività; R luogo, indica dove sono svolte le attività; R operosità, indica il grado di vitalità nell ambiente; R azioni, indica cosa stanno facendo i partecipanti al gruppo; R intenzioni, indica i passi da svolgere ed in generale gli obbiettivi da raggiungere; R cambiamenti, le modifiche in corso e dove sono state effettuate; R strumenti, quali strumenti sono utilizzati dal gruppo; R visibilità, indica il grado di visibilità delle attività; R abilità, indica cosa sono in grado di fare i partecipanti al gruppo; R sfera di influenza, indica su cosa (risorsa) possono essere effettuati cambiamenti; R aspettative, indica cosa il gruppo si può aspettare da un partecipante. 103

122 Analisi estesa dei requisiti Requisiti non funzionali, R.2.* 3.2 Requisiti non funzionali, R.2.* I requisiti non funzionali sono necessari per definire le proprietà ed i vincoli del sistema e generalmente sono più critici rispetto a quelli funzionali poiché, se non vengono soddisfatti, possono rendere inutile l intero sistema. Purtroppo quasi sempre sono non misurabili e qualitativamente rilevabili a posteriori Requisiti architetturali, R.2.1.* Le organizzazioni possono realizzare un infrastruttura estesa su aree operative interconnesse fra loro. Per raggiungere tale scopo in maniera efficace ed efficiente sono suggeriti i seguenti requisiti[mbb + 03]: R accoppiamento debole, si riferisce al grado di rigidità e durata delle relazioni tra le parti in causa. Ad esempio, si ha un accoppiamento forte se un sistema deve essere monitorato da un altro in modo persistente nel tempo; al contrario, si ha un accoppiamento debole nel caso in cui tra due o più sottosistemi si verificano solo occasionali scambi di informazioni effettuati in base ad esigenze nate da necessità contingenti. La durata di un accoppiamento può essere dinamica (o transitoria) oppure a lungo termine; R contenimento dell eterogeneità, si riferisce al grado di diversità tra i sottosistemi esistenti all interno di un organizzazione. La necessità di accedere ai dati, attraverso molteplici tipologie di sistemi, comporta maggiori sforzi per realizzare la connessione ed una notevole complessità nella gestione dell informazione. Infatti, solitamente, sistemi diversi rappresentano l informazione in modo differente adottando standard incompatibili o soluzioni di opportunità; inoltre possono venire utilizzate strutture differenti rispetto alle strategie di gestione ed ai protocolli di comunicazione previsti da altri sistemi; R autonomia, si riferisce al grado di condiscendenza di un sistema locale rispetto alle regole ed alle linee guida che interessano il sistema nella sua globalità. Una completa autonomia consente di progettare e realizzare il sistema locale in modo del tutto indipendente rispetto a quello centrale, sono pertanto consentite libere scelte nella modellazione dei processi, nella rappresentazione dell informazione, nell adozione dei modelli di programmazione e comunicazione con il solo vincolo di realizzare un interfaccia per stabilire un interconnessione tra i due sistemi e il controllo remoto delle risorse. Un organizzazione di questo tipo rende i sistemi locali flessibili rispetto ad eventuali cambiamenti interni, anche se una completa ed autonoma cooperazione è spesso difficile da raggiungere; R maneggiabilità esterna, si riferisce al grado di visibilità e di semplicità nella manutenzione esterna del sistema. Affinché un processo locale sia osservabile e controllabile dall esterno, deve essere concepito in modo tale da facilitare la supervisione del proprio stato e la misurazione delle prestazioni, la predizione dello stato futuro e di quello di disponibilità. 104

123 Analisi estesa dei requisiti Requisiti non funzionali, R.2.* Devono essere presenti dei punti di misurazione e di controllo implementati con lo scopo di stabilire e controllare l affidabilità del sistema. Per svolgere correttamente questa attività di monitoraggio è necessario che, a tali strumenti, il sistema fornisca sufficienti informazioni pertinenti. Generalmente, un alta visibilità comporta complesse descrizioni dei processi che possono essere giustificate se permettono vantaggi capaci di aumentare la qualità del servizio o Quality of Service (QoS); R adattabilità, si riferisce al grado in cui il sistema è capace di adattarsi velocemente ai cambiamenti. Con la continua evoluzione della tecnologia, i sistemi operano in un ambiente altamente dinamico: nuovi servizi e risorse devono di diventare prontamente operativi oppure vecchie risorse devono essere rimosse o modificate. Un sistema si dice adattabile, se è in grado di rispondere rapidamente ai cambiamenti che generalmente non sono predicibili, ma che solitamente vengono scatenati da elementi quali il clima politico-economico e il profitto; R affidabilità, si riferisce alla capacità di rispettare le specifiche di funzionamento nel tempo; R sicurezza, si riferisce alle azioni che devono essere compiute per rendere sicuro il sistema ed aumentare così la fiducia sulle interazioni. Il sistema deve prevedere la gestione delle autorizzazioni e, se richiesto, attuare l identificazione e l autenticazione delle risorse: alcune interazioni possono avvenire basandosi su una limitata conoscenza delle entità coinvolte, altre invece necessitano di politiche di riservatezza più stringenti; R scalabilità, si riferisce alla capacità di un sistema di crescere nel tempo lungo una o più dimensioni, come ad esempio il volume dei dati accessibili, il numero di transazioni effettuate per unità di tempo o il numero di interazioni contemporanee. Non è sempre possibile ottenere il massimo grado di realizzabilità dei requisiti appena descritti, anche perchè alcuni risultano in parziale antagonismo, quindi si rende già evidente la necessità di giungere a compromessi progettuali, effettuando scelte bilanciate Requisiti di qualità dei dati, R.2.2.* Al fine di garantire la massima fruibilità dell informazione, è necessario che i dati in essa contenuti siano dotati delle seguenti caratteristiche[aip02, Nat06]: R sicurezza, i dati devono essere organizzati in modo tale che sia garantito l accesso ad essi solo a chi effettivamente ne ha il diritto; R riservatezza, i dati devono essere organizzati in modo tale che siano necessari opportuni permessi per poter accedere ai dati; R usabilità, gli utenti che hanno il diritto di accedere all informazione devono essere messi nelle condizioni di poterlo fare indipendentemente dalla condizione fisica, psichica e culturale; 105

124 Analisi estesa dei requisiti Requisiti non funzionali, R.2.* R esattezza, deve esserci una corrispondenza fidata 9 tra i dati e le caratteristiche osservate del fenomeno di interesse; R accuratezza, è il grado di conformità di un valore acquisito, misurato e calcolato, rispetto al suo attuale valore. Devono essere garantite sia l accuratezza sintattica che quella semantica, come previsto in [Nat06]. L accuratezza sintattica misura la precisione del valore di un dato rispetto ad un dominio di valori considerato sintatticamente corretto: ad esempio, si ha un basso grado di accuratezza sintattica quando il nome Maria è riportato coma Marja. L accuratezza semantica è la precisione del valore di un dato rispetto ad un dominio di valori considerato semanticamente corretto: si ha, ad esempio, un basso grado di accuratezza semantica quando il mome Maria è riportato come Francesca, che è sintatticamente accurato, perché è compreso nel dominio di riferimento di tutti i nomi propri di persona, ma è un nome diverso; R completezza, i dati rilevati devono coprire il maggior numero di caratteristiche e sfaccettature relative al fenomeno osservato. Avere a disposizione più categorie di dati consente di effettuare un analisi del fenomeno meno ristretta e limitata che potrebbe condurre a considerazioni errate; R consistenza, misura l assenza di contraddizioni tra i dati di uno stesso record o di archivi diversi. Si parla di consistenza interna se i dati confrontati appartengono ad uno stesso record: ad esempio, in un documento che riguarda l entità impiegati di un azienda, la data di nascita non può essere maggiore della data di assunzione. Si parla di consistenza esterna se i dati confrontati appartengono a due archivi diversi: sempre nel caso del documento che riguarda l entità impiegati la data di nascita contenuta nell archivio della sede centrale di un organizzazione deve essere uguale a quella contenuta nell archivio della succursale; R tempestività, i dati, nel momento in cui vengono consultati da un utente devono essere aggiornati. Le modalità di aggiornamento dei dati possono essere calibrate in base alla funzione che questi svolgono all interno dell organizzazione. La frequenza di aggiornamento di un informazione che deve essere utilizzata una volta al mese può essere minore rispetto a quella che invece viene usata giornalmente: è rilevante che al momento dell utilizzo entrambe siano aggiornate; R pertinenza e non eccedenza, i dati raccolti, creati, analizzati devono essere appropriati al contesto di analisi Requisiti per i documenti, R.2.3.* Un sistema distribuito è costituito da una serie di aree operative decentrate in grado di comunicare tra loro e, conseguentemente, di condividere risorse. Per tale motivo, spesso si ricorre all uso di ipertesti che connettono informazioni localizzate in punti diversi di uno o più documenti. Estendendo il concetto, gli 9 Nessun sistema automatico o manuale è in grado di garantire l esattezza in senso assoluto 106

125 Analisi estesa dei requisiti Requisiti non funzionali, R.2.* ipertesti possono anche connettere uno o più documenti, o parte di essi, situati in zone fisiche differenti. Gli aspetti di cui si deve tenere conto per creare ed utilizzare ipertesti, risultano i seguenti: modello temporale, descrive le dipendenze temporali tra elementi informativi. Esistono quattro categorie di modelli temporali: basato su punti temporali, ovvero su attività quali scadenze vincolanti; basato su intervalli temporali; basato su eventi, ovvero su attività quali azioni che provengono dall esterno dell organizzazione; modello spaziale, descrive le dipendenze spaziali tra elementi informativi. Esistono tre categorie di modelli spaziali: basato su posizionamento assoluto, ovvero sulla presenza di un sistema di riferimento; basato su relazioni direzionali, come ad esempio i punti cardinali; basato su relazioni topologiche, ovvero su operazioni fra insiemi quali disgiunzione, unione, sovrapposizione; Tenendo conto dei modelli appena descritti, gli ipertesti devono quindi rispettare i seguenti requisiti[bm99]: R interazione, il sistema deve mettere l utente nelle condizioni di poter sfruttare le potenzialità e le risorse del sistema. Si parla di interazione applicata ai seguenti ambiti: alla navigazione, il sistema si occupa di gestire il flusso della presentazione delle informazioni all utente; al progetto trattato, il sistema fornisce strumenti utili per la manipolazione del layout 10 sia dal lato visivo che acustico; R riusabilità, i contenuti che caratterizzano una risorsa devono essere riusabili. Il grado di riusabilità di un dato si misura le tre seguenti dimensioni: granularità del riuso, indica gli elementi che possono essere riusati. Si distinguono tre livelli di granularità di riuso: completo, di frammenti e di dati elementari contenuti nella risorsa; tipo di riuso, indica come il materiale può essere riusato nella composizione di nuove risorse. Si individuano due tipologie di riuso: identico, che permette di esportare ed importare i dati con le loro originali relazioni e con i vincoli temporali, spaziali e di interazione; strutturale, che coinvolge solo la parte strutturale (se è stata separata dal layout dei contenuti); 10 Il termine layout indica come una risorsa viene presentata all utente. In tale ottica, appare chiaro che ad un documento possono essere associati più layout diversi in base al tipo di utilizzo che ne deve essere fatto o alla persona che lo deve fruire. 107

126 Analisi estesa dei requisiti Requisiti non funzionali, R.2.* identificazione degli elementi riusabili, indica la capacità di classificare opportunamente i dati in modo che possano essere più facilmente riutilizzabili. A tal fine è necessario fare uso di metadati e meccanismi per classificare, indicizzare ed effettuare ricerche sulle risorse del sistema; R adattabilità, la presentazione di risorse multimediali deve essere adattata al contesto dell utente. L adattamento avviene sulla base degli interessi personali dell utente e delle tecnologie che esso ha a disposizione e può essere di tipo statico o dinamico. Si ha adattabilità statica quando le possibilità alternative di rappresentazione sono conosciute e riferite alla risorsa durante la creazione della stessa. Si ha adattabilità dinamica quando le alternative disponibili sono determinabili, e quindi determinate, solo quando avviene la rappresentazione; R neutrale presentazione, è auspicabile che i dati di un organizzazione non vengano condizionati da specifiche implementazioni del sistema in quanto una simile situazione potrebbe limitarne il riuso e condurre ad una scarsa adattabilità al contesto. Le informazioni devono quindi essere modellate in modo tale da risultare neutrali, ovvero indipendenti, rispetto alla contingente presentazione. Eventualmente può essere previsto un meccanismo che, nel momento in cui i dati vengono presentati all utente, utilizza dei meccanismi automatici di conversione (da dati neutrali a dati modellati in base alla visualizzazione voluta). 108

127 Capitolo 4 Metodologia di progettazione Data la complessità del problema, per non incorrere nel rischio di tralasciare aspetti determinanti è opportuno attuare una sistematizzare dei requisiti, direttamente o indierettamente connesse al problema (capitolo 3) e delle soluzioni progettuale a problemi ricorrenti (capitoli 1 e 2). Allo stato dell arte, sulla base delle tecnologie, gli stili o pattern architetturali discussi, saranno adesso riletti i requisiti di base per stabilire come dovranno essere recepiti durante la progettazione. A seguire tale valutazione saranno enunciate le linee guida progettuali, in forma di principi generali. Le scelte illustrate mirano a formulare quella che riteniamo una buona metodologia progettuale orientata ad ottenere la migliore garanzia possibile per un sistema distribuito scalabile. I concetti saranno rielaborati, contestualizzati e specializzati quando verranno affrontati i sottosistemi e servizi nella parte IV. 4.1 Valutazione dei requisiti Nel capitolo 3 sono elencati un totale di 73 requisiti di base suddivisi in 11 categorie di interesse (manifestato in maniera diretta o indiretta). Al fine di sistematizzare qualitativamente l elenco, nella presente sezione verranno riletti applicando degli attributi qualificanti. In generale gli attributi dei requisiti sono variabili in funzione di chi li scrive e del momento in cui li valuta, così un attributo a partità di importanza può assumere una priorità diversa nel tempo. Il compromesso tra priorità ed importanza può essere attuato con la classificazione MoSCoW, un acronimo comunemente usato per rappresentare quattro gruppi a priorità gerarchica[hat08]:

128 Metodologia di progettazione Principi progettuali 1. MUST have: i requisiti non sono negoziabili e l incapacità l incapacità di soddisfare tali requisiti si tradurrebbe nel fallimento di tutto il progetto; 2. SHOULD have: caratteristiche raccomandate da soddisfare se possibile; 3. COULD have: caratteristiche raccomandate da soddisfare se possibile, ma debolmente vantaggiose; 4. WON T have: requisiti che saranno completamente ignorati (almeno temporaneamente, perchè potrebbero essere reintrodotti in uno stadio successivo di progettazione). Poichè il nostro interesse è fortemente rivolto anche alle abilità sostenute dalla infrastruttura, gli attributi MoSCoW, proprio per come sono definiti, escludono la possibilità di evidenziare comportamenti di interesse che dovrebbero essere abilitati nelle applicazioni. Estendiamo i criteri MoSCoW introducendo il gruppo: 5. ENABLE: caratteristica non soddisfatta, ma di cui si auspica l abilitazione o completamento a livello applicativo, grazie a facilitazioni e funzionalità di base rese disponibili. Mutuamente esclusiva con attibuto MUST have. Con questa estensione il criterio adesso appare estremamente espressivo, orientando le caratteristiche desiderate dal sistema verso il livello applicativo. Con le tabelle 4.1(pagina 111), 4.2 (pagina 111), 4.3 (pagina 111), 4.4 (pagina 111), 4.5 (pagina 112), 4.6 (pagina 112), 4.7 (pagina 112), 4.8 (pagina 113), 4.9 (pagina 113), 4.10 (pagina 113) e 4.11 (pagina 114) è riportata la valutazione schematica di ciascun requisito. 4.2 Principi progettuali Non limitare la vista sul problema: approccio sistemico La maggior parte delle specifiche per sistemi complessi, come quello che intendiamo trattare, sono così estese che nessun singolo individuo è in grado di comprenderne a fondo tutti gli aspetti. Come consigliato in Reference Model of Open Distributed Processing (RM-ODP)[Val01, EM04, WN01] e in Unified Modeling Language (UML)[HM03, RJB99] si possono adottare viste multiple sul problema generale, al fine di separarne gli aspetti e facilitare l identificazione dei vincoli, la formulazione mirata dei requisiti per una corretta selezione delle tecniche risolutive: Punto di vista organizzativo. Focalizza l attenzione sugli intenti, sui risultati, sulle politiche del sistema. Vengono definite le politiche organizzative e sociali in termini di entità attive e passive. È una visione puramente concettuale dell architettura che stabilisce gli obiettivi generali, le finalità del progetto, le entità del dominio di interesse e i ruoli che caratterizzano le interazioni. Le entità dedotte dal contesto del problema 110

129 Metodologia di progettazione Principi progettuali Requisito Must Should Could Won t Enab creazione acquisizione archiviazione indicizzazione recupero accesso Tabella 4.1: Requisiti funzionali per le risorse materiali (gestione risorse) Requisito Must Should Could Won t Enab attributi relazioni locking prenotazione aggiornamento differenziale collezionare gestione del nome Tabella 4.2: Requisiti funzionali per le risorse materiali (versioning) Requisito Must Should Could Won t Enab dell accesso dei fallimenti della localizzazione della replicazione della concorrenza Tabella 4.3: Requisiti funzionali per le risorse materiali (trasparenza) Requisito Must Should Could Won t Enab univoca alias fisica Tabella 4.4: Requisiti funzionali per le risorse materiali (indirizzabilità) 111

130 Metodologia di progettazione Principi progettuali Requisito Must Should Could Won t Enab coerenza con altre codifiche semplicità del confronto trascrivibilità da parte dell uomo trasportabilità elaborabilità riconoscibilità Tabella 4.5: Requisiti funzionali per le risorse materiali (codifica) Requisito Must Should Could Won t Enab molteplici processi molteplici metodologie di lavoro sviluppo del gruppo metodi di interazione interscambiabili molteplici caratteristiche comportamentali permeabilità alle barriere regolazione ed adattamento del contesto Tabella 4.6: Requisiti funzionali per le risorse di contesto (groupware) Requisito Must Should Could Won t Enab controllo dati utente e consenso divulgazione minima quando obbligatoria organizzazioni accreditate identificazione selettiva pluralismo di operatori e tecnologie integrazione umana esperienze consistenti attraverso contesti Tabella 4.7: Requisiti funzionali per le risorse di contesto (identità) 112

131 Metodologia di progettazione Principi progettuali Requisito Must Should Could Won t Enab presenza luogo operosità azioni intenzioni cambiamenti strumenti visibilità abilità sfera di influenza aspettative Tabella 4.8: Requisiti funzionali per le risorse di contesto (awareness) Requisito Must Should Could Won t Enab accoppiamento debole contenimento dell eterogeneità autonomia maneggiabilità esterna adattabilità affidabilità sicurezza scalabilità Tabella 4.9: Requisiti non funzionali architetturali Requisito Must Should Could Won t Enab sicurezza riservatezza usabilità esattezza accuratezza completezza consistenza tempestività pertinenza e non eccedenza Tabella 4.10: Requisiti non funzionali sulla qualità dei dati 113

132 Metodologia di progettazione Principi progettuali Requisito Must Should Could Won t Enab interazione riusabilità adattabilità neutrale presentazione Tabella 4.11: Requisiti non funzionali per i documenti sono organizzate in gerarchie a cui sono associati dei ruoli. I ruoli sono assegnati in termini di politiche gestionali. Le politiche sono divisibili in tre principali categorie: permessi (o azioni consentite), divieti (o azioni proibite) ed obblighi (azioni da adempiere). Punto di vista informativo. Focalizza l attenzione sulla semantica dell informazione, della sua elaborazione e ciclo di vita. Descrive l informazione tratta dal sistema, la struttura e i tipi dei dati. Cattura le problematiche riguardanti la condivisione delle informazioni, modellando gli oggetti in termini di metadati, stato e struttura. La struttura può essere statica, quando riguarda una particolare istanza, dinamica, quando descrive lo stato e l evoluzione di un oggetto oppure invariante, quando rappresenta proprietà che devono rimanere costanti nel tempo. Dovranno essere definiti i modelli per rappresentare l informazione ed il suo scambio tra sottosistemi cooperanti. Punto di vista computazionale. Focalizza l attenzione sulla decomposizione funzionale del sistema con la finalità di definire le interfacce delle entità e renderne trasparente l accesso. Punto di vista ingegneristico. Focalizza l attenzione sui meccanismi necessari alla realizzazione di interazioni distribuite nel sistema. Qui deve essere affrontato e risolto il problema dell eterogeneità del sistema e della comunicazione. Punto di vista tecnologico. Focalizza l attenzione sulle scelte tecnologiche. Descrive specifici prodotti e standard per l implementazione. Vengono effettuate le scelte hardware e software capaci di rispondere ai requisiti precedentemete identificati, apportando eventuali compromessi. I punti di vista esposti risultano, nel loro complesso, complementari ed indipendenti per una ragionevole e iniziale scomposizione del problema generale. Inoltre le tecniche di rappresentazione previste in [HM03, RJB99] consentono di esprimere le viste in maniera standardizzata e largamente condivisa. È necessario comunque osservare che una vista eccessivamente estesa rischia di complicare oltremodo il problema, già per propria natura estremamente variegato e polimorfico. È consigliato un adeguato compromesso tra la complessità della rappresentazione e della sua completezza espressiva. 114

133 Metodologia di progettazione Principi progettuali Scomporre la complessità: stratificare La stratificazione come architectural style o design pattern è ormai un dato di fatto ed è vincente non solo nelle reti di telecomunicazione (ISO/OSI), ma anche nella progettazione software [FRF + 02, BMR + 96, AZ05], ma spesso nella pratica viene violata come evidenziato in [SRR06]. I vantaggi inoltre si presentano anche a lungo termine per una migliore divulgazione e comprensione [RDG94], così come nella riduzione dei costi di sviluppo a parità di qualità con altri metodologie [ZEWH95] quando si cerca una soluzione scalabile ed implementabile per parti successive incrementalmente migliorabili, promuovendo il riuso, la crescita e l interoperabilità. Il vantaggio della stratificazione si rileva anche nei costi di sviluppo e di aggiornamento, poiché l indipendenza della logica implementativa dei vari strati può essere migliorata e modificata senza ripercuotersi sugli strati adiacenti, a patto che le interfacce non subiscano modifiche. In [GKT02] viene evidenziato come la stratificazione sia vantaggiosa su larga scala non solo per l erogazione dei servizi, ma anche per la gestione ed il controllo scalabile delle risorse e dei servizi che le trattano. Viene suggerita una elevata astrazione delle entità in modo da attuare una chiara separazione tra le componenti del sistema, con una strategia dividi-e-conquista. Ovviamente la stratificazione non riduce la complessità del problema, ma aiuta a ridurre la complessità della progettazione dei singoli elementi costituenti il sistema. L orientamento verso un architettura stratificata è stato inoltre suggerito in [MD00]: viene auspicato questo paradigma progettuale per la realizzazione del web semantico. Il termine interdataworking è stato coniato in questo contesto in analogia a internetworking delle reti di calcolatori. Sebbene in [GHLL06] sia stato messo in evidenza che in generale esiste una componente impredicibilie sulle prestazioni di un sistema risultante dalla composizione di servizi, la stratificazione rappresenta la soluzione anche per la sostenibilità dei progetti e dei sistemi sia in ambito telematico che in ambito informatico. Come confermato nella pratica dall evoluzione di Internet e dei molti progetti open (es. GNU/Linux), l approccio stratificato abilita la crescita ed il miglioramento nel tempo del sistema nel suo complesso. Ricordiamo sinteticamente i principi fondanti: separation of concern: ogni livello viene definito trattando separatamente i soli problemi che riguardano il livello stesso, mettendo da parte problematiche inessenziali o che verranno trattate da altri livelli; information hiding: ogni livello espone all esterno solo l informazione indispensabile alla comunicazione con i livelli adiacenti, mantenendo interna ogni altra necessaria informazione; good enough: la progettazione deve essere sufficiente a risolvere il problema, senza pretendere il miglior risultato possibile in tutte le circostanze. Ogni livello è tenuto a rispondere in maniera corretta alle chiamate che gli competono e che verranno generate dai livelli ad esso adiacenti. La logica interna, con cui le funzioni di competenza verranno elaborate, non è visibile 115

134 Metodologia di progettazione Principi progettuali dall esterno. Naturalmente la strategia good enough risulta vincente solo se unita alla capacità del sistema di crescere e migliorarsi nel tempo. Una possibilità per ottenere questa caratteristica è rendere il progetto aperto in tutto il suo ciclo di sviluppo. Limitare la crescita della complessità Consideriamo un sistema distribuito costituito da N servizi cooperanti (lato server) che in maniera unitaria erogano un unico servizio ed una applicazione client che richiede tale servizio. Per semplicità assumiamo di avere a disposizione una sola istanza per servizio (processo) ed un solo client, quindi avremo N processi server ed 1 processo client. Analizziamo il sistema di un punto di vista puramente astratto, ragionando sulle possibili interazioni che si possono instaurare tra gli N processi lato server. Nella peggiore delle ipotesi, come mostrato in figura 4.1, ogni servizio può comunicare con tutti gli altri (compreso sè stesso). Si ottiene che ogni processo può dialogare con qualsiasi altro. Senza contare eventuali ripetizioni, le possibili comunicazioni instaurabili sono N 2 : nel loro complesso erogano un servizio. Il client può avviare al massimo N interazioni facendo salire il totale a N 2 + N, qualora non esista una buona orchestrazione infrastrutturale i-1 i i i N-2 N-1 N N Figura 4.1: Interazioni tra servizi 116

135 Metodologia di progettazione Principi progettuali Adesso vincoliamo gli N processi in un ordinamento rigido ed imponiamo il principio che un processo server può comunicare solo con i livelli superiore ed inferiore ed al più con sè stesso. Con questa condizione il numero massimo di comunicazioni instaurabili (senza ripetizioni) adesso è 3N 2. Il client è parimenti vincolato, quindi può comunicare solamente con il livello più elevato. Come si evince dalla figura 4.2 il processo 1 ed il processo N possono iniziare 2 comunicazioni, mentre i processi da 2 a N 2 possono iniziare 3 comunicazioni (sempre senza ripetizioni) i-1 i i i N-2 N-1 N N-1 N Figura 4.2: Interazioni di servizi stratificati Le considerazioni avanzate nel primo e nel secondo caso rappresentano una stima della complessità massima ottenibile, dove con complessità si indica il numero di possibili interazioni instaurabili tra processi. Un procedimento di valutazione analogo si può applicare anche nel software dove in gioco stavolta si possono considerare componenti, librerie, classi, oggetti ecc. Senza la stratificazione la complessità potenzialmente può cresce quadraticamente (O(N 2 )) al crescere del numero di processi in gioco, mentre in un sistema stratificato, al più la crescita della complessità delle relazioni è lineare (O(N)). Inoltre la complessità massima attesa per il client è abbattuta da N ad 1. Il valore N 2 rappresenta il valore peggiore, a cui però è plausibile tendere, 117

136 Metodologia di progettazione Principi progettuali là dove non vi siano dei vincoli progettuali chiari o dove nel tempo vengano introdotte per necessità o convenienza ulteriori relazioni[srr06]. L esplosione quadratica di messaggi (stavolta considerando ripetute interazioni) potrebbe divenire una inevitabile conseguenza ed impedimento alla scalabilità. Quindi, dato un insieme di N servizi, risulta strategico attuare una politica di separazione dei compiti e ordinamento, così come suggerito nella stratificazione. Certamente la stratificazione richiede una più accorta progettazione dei servizi e delle interfacce in modo da rispondere ai vincoli del livello Adottare uno stile chiaro e standardizzato: SOA + ReST Dall analisi effettuata nel capitoli 1 e 2 si evince che la composizione di servizi è un nodo centrale attorno cui ruota la progettazione. Definito un servizio, è determinante chiedersi, quali interazioni possono essere fatte da quel servizio (coreografia) e con chi (orchestrazione): Orchestrazione. L orchestrazione è un modo di aggregare i servizi relativi ai processi. A differenza della coreografia, l orchestrazione compone servizi in un novo servizio che ha un controllo complessivo su tutto il processo [Jos07]. Coreografia. La coreografia è un modo di aggregare servizi: non compone servizi in un nuovo servizio. Definisce, invece, i ruoli e le politiche che abilitano i differenti servizi a collaborare. Ogni servizio coinvolto nel processo vede e contribuisce solo ad una parte di esso [Jos07]. Richiami a SOA In riferimento a [MLM + 06b] risulta vantaggioso perseguire un approccio che risponda ai principi dell architettura orientata ai servizi (Service Oriented Architecture), per far fronte al bisogno di flessibilità nell architettura software che si desidera ottenere ed osservando che tali principi non ostacolano la stratificazione. Solitamente è tipico pensare di risolvere i problemi di compatibilità e interoperabilità tra processi semplicemente adottando una soluzione unica ed eliminando così le differenze. L approccio SOA parte invece dal presupposto che l eterogeneità non può essere eliminata [Jos07] e indicando lo sviluppo di servizi debolmente accoppiati (loosely coupled) ed interoperabili, i quali possono essere combinati in sistemi più complessi. La chiave per raggiungere l interoperabilità è nel disaccoppiamento, che consiste nel ridurre le dipendenze ai minimi termini, in modo che gli effetti di modifiche o imprevisti abbiano minore impatto negativo. Il disaccoppiamento contribuisce alla tolleranza ai guasti e alla flessibilità, e grazie ad esso la progettazione riesce ad evitare la presenza di colli di bottiglia che ostacolerebbero la scalabilità. Tuttavia, ogni forma di disaccoppiamento porta con sé delle controindicazioni, perciò questo tipo di scelte va effettuato soltanto in seguito ad un attento esame dei rischi. 118

137 Metodologia di progettazione Principi progettuali Molte definizioni di SOA comprendono il termine web service, ma in realtà i due concetti sono autonomi; i web service sono un possibile modo di realizzare delle infrastrutture e possono essere usati per creare delle SOA. Anche se i web service stanno affermandosi, le SOA si possono implementare con molte altre tecnologie (es. CORBA, WebSphere MQ e TIBCO). Richiami a ReST Per motivi di prestazioni e di scalabilità, e per permettere l indirizzabilità e l astrazione delle risorse nei sistemi distribuiti e consigliato l uso delle interfacce in stile REST (REpresentational State Transfer) [Fie00]. REST è un modello astratto per sistemi software definito da un insieme di vincoli, dedotti dall architettura Web. Innanzi tutto, l interazione tra i componenti di un architettura in stile REST deve essere di tipo client-server; ogni richiesta da parte di un client deve contenere tutte le informazioni necessarie affinché possa essere elaborata, e non può fare affidamento sullo stato interno del server. Lo stato della sessione è quindi mantenuto interamente nel client. Quest ultimo, di fronte a richieste ripetute, può servirsi di una cache in cui la risposta è stata memorizzata in precedenza, con lo scopo di migliorare l efficienza del sistema abbattendo alcune interazioni. Ciò che principalmente distingue il REST da altre architetture basate sul networking è il vincolo di interfaccia uniforme tra componenti. 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 estesa e generale, invece che in una forma specificatamente progettata per i bisogni applicativi. Lo stile REST non prevede l uso di particolari protocolli o standard e non specifica quali operazioni deve offrire una interfaccia, purché sia uniforme e orientata alle risorse. In questo contesto, una risorsa è una qualsiasi informazione dotata di nome: può essere un documento, un immagine o un oggetto software. Nell approccio REST si usano degli identificatori per riconoscere le risorse coinvolte nelle interazioni tra i componenti del sistema. La manipolazione delle risorse da parte di questi ultimi deve avvenire tramite una rappresentazione formata da una sequenza di byte più una sequenza di metadati che descrivono questi byte. Conciliare SOA e ReST SOA e ReST sono apparentemente in contraddizione quando esplicitamente implementati con tecnologie Web in cui le risorse sono indirizzate tramite URI come è stato evidenziato in [RR07]. Il punto di vista fonda una architettura orientata alle risorse (Resource Oriented Architecture, ROA) in cui sono integrati ed applicati i due stili sopratutto da un punto di vista implementativo (capitolo 1.3). 119

138 Metodologia di progettazione Principi progettuali Semplicità per il deploy: plug and play Il termine plug and play traducibile in termini tecnici in inserisci ed usa indica la possibilità di utilizzare un dispositivo non appena viene connesso al sistema. Anche se è nato riferendosi a periferiche locali direttamente connesse alla architettura del calcolatore, noi lo estendiamo al caso di sistemi di rete. Quindi ricerchiamo, per quanto possibile, la stessa semplicità con cui è possibile connettere un apparato di internetworking alla rete. Intendiamo quindi con plug and play: facilitare l installazione e la configurazione; mantenere l indipendenza dalla piattaforma hardware/software; garantire la compatibilità con il legacy; aumentare la flessibilità senza aumentare la complessità Decentralizzare la sicurezza: ente pubblico autorevole La sicurezza è affrontata livello per livello (parallelismo con i protocolli sicuri e non-sicuri in Internet): HTTPS non è un protocollo a parte ma si occupa di combinare l interazione del protocollo HTTP attraverso un meccanismo di crittografia di tipo Secure Sockets Layer (SSL) o Transport Layer Security (TLS). Il problema principale della sicurezza è che non è misurabile con uno strumento di visualizzazione immediata. Sarebbe bello poter utilizzare un unità di misura che desse un valore numerico come risultato della verifica. E necessario quindi affrontare l analisi della sicurezza aziendale e un eventuale progetto con cautela e attenzione, evitando di farsi cogliere dal panico e installare soluzioni dettate dall isterismo o dalla preoccupazione di un momento. Affrontare un progetto di sicurezza significa valutare quale sia il livello di rischio che siamo disposti ad accettare, e se consideriamo che la percezione della sicurezza è soggettiva, non si può pensare a una soluzione o a un prodotto che sia valido per ogni tipo di problematica. La sola cosa che assume valore è la conoscenza approfondita delle problematiche che permette di definire i modelli di riferimento, che possono essere poi realizzati con le soluzioni più idonee al caso specifico. In molti casi non sarà possibile affrontare un discorso di ampio respiro che possa colmare ogni lacuna, sarà quindi indispensabile stabilire delle priorità d intervento, procedendo per passi successivi. Il tema sella sicurezza deve essere affrontato lungo due direttrici principali e trasversali a qualsiasi tipo di metodologia progettuale adottata: security: riferita, con un punto di vista strettamente tecnologico, agli apparati, ai dati ed alla comunicazione quali elementi centrici e materiali per la fornitura del servizio; 120

139 Metodologia di progettazione Principi progettuali safety: riferita alla salvaguardia fisica e morale delle persone applicata alle identità digitali ed al trattamento dei dati personali e sensibili. La sicurezza da un punto di vista tecnico va affrontata livello per livello... Osservazioni sulla gestione delle identità Nel Web ogni servizio, dal sito di commercio elettronico, all instant messaging, ai forum, utilizza un proprio sistema per l identificazione e l autenticazione degli utenti. Questa situazione è determinata dalla mancanza di una piattaforma comune, condivisa da tutti i soggetti, dal fornitore di servizi all utente finale. La situazione attuale è quella di un mondo in cui la verifica di ogni transazione (con questo termine indichiamo qualsiasi rapporto online, dalla visita ad un sito web all acquisto di un prodotto) è lasciata agli stessi attori, con evidenti lacune nella sicurezza e nell affidabilità. Chi viene maggiormente penalizzato in questa situazione sono gli utenti: mentre i fornitori di servizi riescono a raggiungere il loro scopo, ovvero riconoscere gli utenti e determinare se hanno un grado di affidabilità sufficiente a procedere alle transazioni richieste, gli utenti sono totalmente esposti: per ottenere il livello di sicurezza richiesto dal fornitore del servizio è necessario esporre tutti i dati personali che vengono richiesti, senza poterne celare alcuno. Questo diventa più pericoloso se consideriamo che l affidabilità di chi richiede i dati non è in alcun modo garantita dai sistemi utilizzati. La protezione offerta agli utenti dal legislatore o dallo stesso sito, esposta nelle condizioni di utilizzo, è molto spesso troppo debole, come ben sappiamo. La prima controindicazione, ancora più evidente delle considerazioni precedenti, di un modello di identificazione totalmente basato su credenziali specifiche per ogni servizio è il proliferare di username e password, che costringe l utente a dover memorizzare una grossa mole di dati, creando un evidente problema di scomodità e, ancor più grave, di sicurezza. Un paragone col mondo reale può aiutarci a chiarire meglio la situazione: quando dobbiamo iscriverci ad una biblioteca presentiamo le nostre credenziali al gestore del servizio, sotto forma di un documento d identità. Questo documento è emesso da un autorità, lo Stato, che garantisce l affidabilità e la correttezza dei dati in esso contenuti (almeno pensando di essere in un mondo perfetto, in cui non esistano documenti contraffatti); per essere riconosciuti non è però necessario che il documento contenga tutta la conoscenza che lo Stato ha su di noi: nel caso della biblioteca (e di moltissimi altri servizi) è solitamente sufficiente rivelare il proprio nome ed il proprio indirizzo, mentre non è necessario comunicare altri dati, ad esempio il proprio reddito degli anni precedenti. L intervento dello Stato nel procedimento di identificazione ed autenticazione che ci permette di avere la tessera della biblioteca è assolutamente indiretto: i soggetti coinvolti nell operazione di iscrizione sono solamente due, che si appoggiano in maniera asimmetrica ad un autorità terza, che non partecipa, ed anzi spesso nemmeno viene a conoscenza dell utilizzo delle credenziali da essa emesse. Al centro di ogni transazione che richieda l identificazione degli utenti è posto lo stesso utente, insieme alle credenziali che gli vengono fornite da un autorità esterna, universalmente riconosciuta. La situazione attuale sulla Rete è 121

140 Metodologia di progettazione Principi progettuali drasticamente diversa: continuando a ragionare sulla scorta dell esempio appena riportato, è come se ogni sito emettesse un propria carta d identità ad ogni utente, che sarà riconosciuta solamente da chi la ha rilasciata. Abbiamo già accennato alla proliferazione di identificativi utente e password, una grossa scomodità per gli utilizzatori, ma dobbiamo concentrarci su un ulteriore livello per individuare il rischio maggiore: ogni servizio al quale ci iscriviamo richiede parecchi dati personali, senza che sia garantita l affidabilità del gestore del servizio, e quindi la correttezza nel trattare i nostri dati. Questo è necessario per poter identificare l utente e poter assicurare l affidabilità necessaria a portare a termine la transazione; ma in questo processo viene tutelato il fornitore di servizi, mentre è evidente che l utente è penalizzato, non potendo in alcun modo tutelare i propri dati e la propria affidabilità (sotto forma di reputazione, solitamente considerata un attributo dell identità stessa). La presenza di una autorità che certifichi l identità degli utenti eliminerebbe la necessità di rivelare alcuni dei nostri dati personali, aumentando allo stesso tempo sicurezza e riservatezza. Ad esempio non sarebbe più necessario rivelare ed autenticare (solitamente rispondendo ad una mail di conferma) il proprio indirizzo per accedere ad un servizio. Questa situazione ha fatto nascere l idea di un sistema di identificazione aperto ed affidabile per tutti gli utenti Internet. Un primo tentativo è stato fatto da Microsoft nel 2001, con il nome di Passport: si trattava di un sistema per gestire l autenticazione su più siti, avvalendosi di un protocollo comune. Applicazioni di questo tipo vengono dette SSO (Single Sign On), perché l autenticazione viene eseguita una sola volta ed è poi valida su tutti i siti che utilizzano lo stesso sistema. La proposta rispondeva ad una necessità effettiva degli utenti ed il sistema era estremamente avanzato dal punto di vista tecnico, ma dopo quasi cinque anni di agonia, la casa di Redmond ha annunciato la fine dell esperienza. Quali sono le ragioni di questo fallimento? La risposta a questo problema, molto sentito dagli utenti, non può venire che sotto forma di un sistema aperto e totalmente affidabile. Passport, pur essendo per tanti motivi un sistema valido, prevedeva la gestione esclusiva da parte di una sola società del protocollo e di tutta l infrastruttura di autenticazione: ovviamente questo non è tollerabile, ed è all origine del fallimento dell iniziativa. Prima di ripartire dopo l esperienza di Passport ed incorrere in giustificate obiezioni, bisogna specificare che il tentativo di introdurre queste tecnologie deve avere come unico obiettivo la protezione di tutti i soggetti, includendo sotto questo nome sia gli utilizzatori che il fornitore di servizi. L utente deve essere portato al centro e messo nella condizione di controllare totalmente la propria identità in ogni transazione cui prende parte; la necessità di questo layer aggiuntivo è innegabile, per evitare in futuro l ingigantirsi di problemi già presenti, sotto forma di phishing ed identity theft, tanto per fare un esempio. Proprio in questo momento di definizione delle tecnologie che saranno usate è importante che tutte le parti coinvolte partecipino attivamente, per assicurare il rispetto dei diritti di ognuno. Solo così si potrà scongiurare un utilizzo differente di queste tecnologie, ad esempio per controllare meglio chi usa la Rete. Creando infatti un protocollo aperto ed affidabile, la necessità di diffondere i nostri dati diminuirà, ma sarà lo stesso sistema a garantire la nostra affidabilità 122

141 Metodologia di progettazione Principi progettuali ai soggetti con cui veniamo in contatto Abilitare lo sviluppo aperto: free software Il Software Libero è un software commerciale rilasciato con licenza libera, utilizzarlo significa compiere una scelta strategica che garantisce una innumerevole serie di vantaggi, come poter disporre delle tecnologie che si impiegano, avere il pieno controllo dei propri mezzi di distribuzione e operare in un mercato intrinsecamente aperto, in cui gli attori economici si muovono su un piano di parità privo di barriere di accesso, e la competizione si gioca sulla qualità del lavoro. Il Software Libero si configura come un bene pubblico, che ciascuno può utilizzare e migliorare a beneficio di tutti. Come nasce il Software Libero La prima concettualizzazione del Software Libero risale ai primi anni 80, e lo definisce nei termini di un software la cui licenza soddisfa 4 libertà fondamentali: quelle di eseguirlo per qualsiasi scopo, di studiare come funziona adattandolo alle proprie necessità, di copiarlo e distribuirlo, e infine di migliorarlo, distribuendo pubblicamente i perfezionamenti. Chi ne usufruisce può dunque approfittare di innegabili vantaggi pratici legati alla scomparsa del costo delle licenze e della loro gestione, all impossibilità che si verifichino politiche di lock-in[sv00] e che vengano imposti vincoli, e all opportunità di investire in sviluppo e formazione. In particolare, è la libertà di copiare il software che permette gli investimenti in formazione e personalizzazione, eliminando il costo diretto delle licenze, e che garantisce flessibilità nel numero di installazioni senza costi aggiuntivi in caso di espansione di un attività; mentre è la libertà di modificare il software che permette, a tutti coloro che sono dotati di competenze sufficienti, l accesso al codice sorgente e la possibilità di adattamento (chi non è dotato di tali competenze ha comunque la possibilità di rivolgersi agli esperti, svincolandosi dalla dipendenza dal produttore in relazione ad aggiornamenti, assistenza e personalizzazioni). Software Libero e Open Source Il movimento del Software Libero e quello dell Open Source hanno obiettivi e mezzi comuni, ma differiscono sul piano filosofico. Preferiamo parlare di Software Libero perchè la disponibilità dei sorgenti che sta alla base del concetto di Open Source, senza le 4 libertà fondamentali e i vantaggi di tipo strategico che ne conseguono, non è sufficiente a garantire il libero sviluppo di un software. Il concetto di Open Source sottolinea i vantaggi di natura tecnica, tendendo a tralasciare gli aspetti etici e filosofici, legati alla libertà; al contrario, il concetto di Software Libero punta soprattutto ai vantaggi di tipo strategico e pone l accento sull aspetto filosofico e le libertà che tende a salvaguardare. Una scelta consapevole Utilizzare Software Libero, dunque, è soprattutto una scelta di natura etica, poiché il suo sviluppo si basa sugli stessi principi fondanti della comunità scientifica, senza i quali la ricerca non può progredire: il libero scambio delle 123

142 Metodologia di progettazione Principi progettuali informazioni, la condivisione di idee e risultati e il libero utilizzo del patrimonio comune delle conoscenze per un ulteriore sviluppo. Inoltre, favorisce l indipendenza tecnologica, la diffusione del sapere, l abbassamento delle barriere di accesso alla tecnologia, stimola la concorrenza e dà sostegno all economia locale. Produrre e avvalersi di Software Libero è una scelta intelligente e responsabile soprattutto nel caso delle amministrazioni pubbliche, che impiegano risorse pubbliche e devono quindi preferire l utilizzo e lo sviluppo di un software che resti a disposizione di tutti, garantendo la sua disponibilità, il suo riutilizzo, e la creazione di competenze, professionalità e valore sul territorio[cni03a]. Infine riteniamo che una amministrazione pubblica debba essere sempre in grado di mostrare e dimostrare ai cittadini il modo in cui gli strumenti informatici e telematici adottati non violino il corretto trattamento dei pubblici, personali e sensibili [AIP02, Rep05, Smi08]. Vantaggi tecnici, sociali ed economici Oltre ai vantaggi strategici relativi all indipendenza tecnologica, il Software Libero offre altre agevolazioni fondamentali. Dal punto di vista tecnico, permette la verificabilità del software: diventa possibile, quando serve, verificare o far verificare il comportamento effettivo dei programmi, intervenendo direttamente sui problemi; inoltre, consente un estrema facilità di sviluppo, dal momento che ogni nuova implementazione può basarsi sulle modifiche precedenti[cni03b]. Dal punto di vista sociale, utilizzare Software Libero riveste un grande valore culturale dovuto al carattere pubblico e alla condivisione dei risultati, e favorisce lo sviluppo professionale: basandosi su una economia dei servizi, incentiva la crescita professionale e l aumento delle competenze sul territorio[ued05]. Dal punto di vista economico, il Software Libero stimola la concorrenza e garantisce grandi possibilità di sviluppo anche nelle realtà locali. Copyleft e licenza del Software Libero Il software è un bene immateriale che può essere copiato a costo praticamente nullo e scambiato senza che la sua cessione comporti da parte di chi lo cede una diminuzione della capacità di fruirne. Il concetto di copyleft, permesso d autore, ribalta il concetto di copyright e rende inalienabili tutte le libertà garantite dal Software Libero, continuando a salvaguardare la parternità intellettuale. Mentre il copyright permette la privatizzazione di un bene, il copyleft lo mantiene libero, utilizza il copyright per trasformarlo da restrizione in garanzia assoluta di libertà, assicurando tutti i diritti agli utenti, riservandosi solo quelli necessari a mantenere tale garanzia. Soprattutto, il copyleft impedisce a chiunque di impossessarsi di un bene facendolo esclusivamente proprio per poi eventualmente negare ad altri la possibilità di accedervi. La licenza GPL (Licenza Pubblica Generica del progetto GNU) [Fou91] è alla base del Software Libero e si fonda sull idea di dare a chiunque il permesso di eseguire, copiare, modificare e distribuire nuove versioni, senza concedere la possibilità di aggiungere restrizioni. Un software rilasciato sotto GPL è libero, e tutti i software che da esso derivano saranno altrettanto liberi, perché le libertà di cui è intriso il software 124

143 Metodologia di progettazione Principi progettuali sono garantite a chiunque ne abbia una copia: il permesso d autore non sarebbe infatti efficace se anche le versioni modificate del software di riferimento non fossero libere. La situazione attuale Oggi il Software Libero riscuote un crescente interesse da parte di enti pubblici e privati: si moltiplicano le iniziative per favorirne l uso nella pubblica amministrazione, ed è uno dei pochi settori in espansione del mercato informatico. Inoltre, per le sue caratteristiche intrinseche di riutilizzabilità, facilità di estensione, aderenza agli strandard e stabilità di funzionamento, il Software Libero è il motore di gran parte dei servizi che si trovano su Internet, e l uso in espansione del sistema operativo libero GNU/Linux ne è la dimostrazione più evidente delle trasformazioni tecnico-sociali in atto. 125

144 Capitolo 5 Modello del contesto Prima di progettare una infrastruttura di rete per la collaborazione tra utenti, è necessario individuare le entità in gioco nei processi collaborativi. I processi collaborativi nelle organizzazioni sono diversificati e caratterizzati da complessi fattori sociali. Per il contesto collaborativo risulta quindi conveniente adottare un metodo top-down di analisi e sintesi, in modo da determinare una descrizione sufficientemente espressiva del contesto tale da essere codificabile nei sistemi di elaborazione. Il nostro ambiente collaborativo dovrà essere allo stesso tempo generale e semplice in modo da non precludere l inserimento delle attività collaborative al suo interno ed in modo da abilitare un efficace coinvolgimento dell utenza interessata. Nel presente capitolo e nei successivi con ambiente virtuale indicheremo il modello del contesto da un punto di vista tecnico-informatico. Un ambiente virtuale consentirà agli utenti di semplificare lo svolgimento delle loro attività. Tanto maggiore risulterà la corrispondenza fra l ambiente virtuale e l ambiente reale quanto minore sarà la difficoltà degli utenti nel comprendere ed utilizzare gli strumenti di rete collaborativi. Fissando la prospettiva dell utente si cercherà di trasporre la percezione del mondo reale circostante in termini di entità virtuali e relazioni tra di esse. Molti paradigmi di interazione uomo-macchina riproducono in maniera schematica e semplificata l ambiente fisico nelle modalità più familiari all utente. Un esempio su larga scala è rappresentato dai Windows Manager dei Sistemi Operativi (MS Windows GUI, Gnome, Kde, XFCE) che rappresentano a video il paradigma del piano della scrivania, globalmente accettato come piano di lavoro nelle attività di ufficio o in generale di lavoro. Sappiamo che le risorse sono elaborate nello spazio da uno o più utenti,

145 Modello del contesto Modello dell ambiente eventualmente organizzati in gruppo. Risulta quindi individuare nel contesto almeno le seguenti entità: persona, gruppo, risorsa, luogo. Dovranno essere codificati relazioni e paradigmi di interazione tra queste entità qualificando il contesto ed il tempo in cui si sviluppano i processi collaborativi. Se l aspetto temporale dell informazione coinvolge più propriamente il modello di documento, i concetti di spazio e di persone si possono posizionare su un piano ortogonale indipendente dal modello stesso. Quindi se l obiettivo primario è di modellare l informazione nella sua forma documentale le motivazioni per la virtualizzazione dell ambiente spingono ad inserire tali risorse in un contesto. Per gli obbiettivi espositivi della presente ricerca, molto spesso utilizzerò i termini risorsa, documento ed informazione come interscambiabili. L analogia tra i termini sarà ulteriormente chiarita, da un punto di vista strettamente tecnico-implementativo, nei successivi capitoli in cui ogni tipo di risorsa sarà istanziata e memorizzata all interno di un documento. 5.1 Modello dell ambiente L informazione è una risorsa che deve essere collocata lungo le dimensioni dello spazio e del tempo. Risulta anche necessario individuare gruppi di persone ed i permessi che possono essere assegnati per generare, produrre, possedere, modificare, leggere e condividere l informazione. Lo spazio ovvero il luogo in cui collocare una risorsa informativa è un aspetto esterno all informazione, ma una importante proprietà associata che ne qualifica il contesto. Virtualizzare lo spazio in cui risiede l informazione-risorsa permette così di delimitare il luogo in cui gli attori che vi agiscono possono incontrarsi ed interagire. Allo stesso modo in cui nella realtà fisica le persone si incontrano o frequentano un certo luogo (per varie finalità) qui si propone lo stesso paradigma attraverso la rappresentazione di un ambiente che ne riproduca le principali caratteristiche concettuali. Quando si svolge un attività collaborativa si utilizzano strumenti, si producono risultati e si scambiano informazioni. Gli strumenti, i risultati e le informazioni possono essere tutte considerate delle risorse a disposizione dell utente. Per questo motivo nell ambiente é stato definito un tipo di entità che prende il nome di Resource e rappresenta un generica risorsa a disposizione dell utente. Quindi la Resource potrà rappresentare un documento, uno strumento, un oggetto o un dispositivo. Nell ambiente reale, le risorse sono dislocate in luoghi diversi più o meno accessibili. Per rappresentare questi luoghi è stata definita l entità Location, la 127

146 Modello del contesto Modello dell ambiente Real Environment Resource / Entities Virtual Environment Figura 5.1: Rappresentazione dell ambiente reale quale può rappresentare ad esempio una stanza, un reparto, un azienda, o tutto quello che può contenere risorse. Inoltre sono stati definiti altri due tipi di entità che riguardano il modello sociale. La prima è Persona, ovvero la rappresentazione di un utente in quanto persona. La seconda è il Group, cioè la rappresentazione di un gruppo di utenti che collaborano. Come è stato evidenziato in [SCFY96] il gruppo non è sufficientemente versatile ed efficiente per la rappresentazione dei permessi di accesso. Per permettere al sistema maggiore scalabilità si introduce il ruolo (Role) come insieme di regole che determinano i permessi assumibile da un gruppo o da un utente. Il ruolo è generalmente indipendente dalle caratteristiche del gruppo e quasi sempre coinvolge solo gli aspetti funzionali delle risorse (diversamente dal concetto di gruppo che riguarda aspetti organizzativo-gerarchici tra individui). Comunque possiamo affermare che il ruolo rappresenta un generalizzazione del concetto di gruppo. Nella tabella 5.1 è riportata la convenzione sui nomi utilizzati per indicare le entità con la corrispondenza tra rappresentazione fisica e modello. 128

147 Modello del contesto Le entità Modello del contesto Ambiente fisico Location luogo, reparto, stanza, abitazione Resource informazione, documento, dispositivo, attuatore, sensore Group insieme di persone, associazione di persone Persona utente, persona fisica, persona giuridica, sistema automatico, processo Role insieme di permessi, insieme di regole Permission permessi, politiche Tabella 5.1: Corrispondenza ambiente modellato - ambiente fisico 5.2 Le entità L ambiente è costituito da Location (virtuali) organizzati gerarchicamente. Ogni Location identifica un luogo virtuale al quale corrisponde in maniera pluasibile un luogo reale (ad esempio un ufficio, un reparto, una stanza, etc.). Ciascuna Location è indirettamente abitata dagli utenti. La proiezione dell utente nella Location è indicata col nome Persona: un entità capace di esporre un sottoinsieme delle proprietà e caratteristiche dell utente. All ingresso di un utente nel luogo reale corrisponde l ingresso della Persona nella Location. Le Persona sono organizzate in gruppi (Group), comunità virtuali di individui, accomunati da un certo insieme di caratteristiche o finalità lavorative determinabili sulla base di regole intrinseche, ad esempio applicate agli attributi del profilo degli utenti (es. il gruppo maggiorenni è costituito dalle persone con età superiore a 18 anni). Persona e Group agiscono sulle risorse sulla base del Role ovvero del ruolo posseduto. Il Role identifica un insieme di permessi espressi con una serie di regole che tengono conto anche della natura delle Resource e delle Location. All interno di una Location le Persona interagiscono attraverso la condivisione delle risorse (Resource) qui localizzate nel rispetto dei Role e dei Group cui appartengono. Le Resource sono la codifica di informazioni, dispositivi, attuatori, capaci di racchiudere dati e di esporre una serie di servizi. In generale possono essere sia entità statiche che dinamiche, dotate di un comportamento legato non solo ai servizi, inerenti all informazione che rappresentano, ma anche al proprio ciclo di vita. Sono quindi entità attive Persona L Persona è l entità logica che rappresenta l utente nell ambiente. Ad ogni utente possono essere associati più Persona ciascuno dei quali esprime un profilo in un contesto. In sostanza una Persona è una rappresentazione dell utente, capace di effettuare o subire operazioni nella Location per conto del suo titolare. In generale il compito della Persona è di rappresentare l utente. Tutte le varie prospettive e sfaccettature, costituite dall insieme delle Persona relative alla stessa identità fisica, determinano il vero utente-persona nella sua globalità. Ogni Persona quindi esprime condizioni necessarie alla sua identifica- 129

148 Modello del contesto Le entità zione in un particolare Location o per l appartenenza ad un Group. Dualmente l unione di tutte le Persona relative alla stessa identità (persona reale) permette di ricostruire l utente nella sua totalità e complessità. In questo modo si tende a soddisfare sia le condizioni dettate dalle legislazioni sulla privacy sul al trattamento dei dati, sia il diritto dell utente a rendere noti dei frammenti della propria identità esponendo una Persona come surrogato di un profilo completo. La scelta di rappresentare l utente con più Persona consente di simulare ciò che accade nel mondo reale, dove un individuo viene visto in modo diverso da diversi gruppi di persone e dal sistema sociale in cui si inserisce. Infatti ciò accade anche quando lo stesso individuo fornisce parziali informazioni sulla propria identità ed interagisce in modo diverso con gli altri, in relazione al contesto. Ad esempio il profilo esposto da una persona in ambito lavorativo solitamente non è equivalente a quello in ambito familiare o comunque privato. Notiamo inoltre che l uso di più identità non è una novità negli applicativi di rete (es. chat e forum), dove il nome reale viene quasi sempre sostituito con un nickname o un alias. È opportuno osservare che la gestione contemporanea di più Persona e quindi di più operazioni sarà possibile solamente se l utente potrà agire contemporaneamente tramite Persona diverse. Un requisito la cui rilevanza varia in base al contesto, ma che in ogni caso è importante soddisfare, è certificare l associazione fra una persona e relativa Persona, dato che sarà proprio la Persona ad avviare, direttamente o indirettamente, i procedimenti e quindi agire per conto del titolare Group I Group sono associazioni di utenti accomunati da identici obiettivi o simili profili. Rappresentano una comunità collaborativa o uno status sociale e permettono di agire sulle risorse condivise in modo unitario. Una Persona, a cui è concessa l iscrizione ad un gruppo, acquisisce i diritti e i doveri del gruppo. Attraverso la transitività dei permessi, le Persona ereditano le caratteristiche comuni al gruppo. I Group sono organizzati gerarchicamente ed ordinati secondo una relazione di contenimento. È possibile rappresentare graficamente la struttura con un albero, in cui i permessi associati ai vari nodi (Group) crescono al crescere della profondità di penetrazione. I permessi dei sottogruppi (gruppi figlio) sono almeno gli stessi di quelli del gruppo che li contiene (gruppo padre). Una Persona iscritta ad un gruppo ha almeno tutti i permessi di quel gruppo. Ovviamente una Persona iscritta ad un gruppo figlio risulta iscritto anche al gruppo padre. All espulsione o alla cancellazione di una Persona da un gruppo generalmente corrisponde una diminuzione dei privilegi e permessi. Visivamente l iscrizione e la cancellazione di una Persona per un gruppo corrispondono a navigazioni indirette dell albero: si può pensare a queste due operazioni come, rispettivamente, ad azioni di discesa o di salita nella gerarchia. Ogni Group può essere vuoto o contenere un numero illimitato di Persona. Potrebbero comunque essere previste restrizioni, come ad esempio sul numero 130

149 Modello del contesto Le entità massimo dei suoi affiliati o politiche spazio-temporali sull ingresso e l uscita (es. sull età o sugli interessi) Role Un ruolo Role è un insieme di permessi che esprime varie azioni possibili sulle risorse. L utilizzo del concetto di ruolo piuttosto che di gruppo ha lo scopo di facilitare il trasferimento di compiti e responsabilità da un individuo ad un altro, riassegnando e riusando ruoli già definiti. Il ruolo in sociologia è un concetto fondamentale, poiché rappresenta l unità elementare di un sistema sociale. Esso è l insieme strutturato di aspettative e comportamenti attesi riguardanti un individuo che occupa una determinata posizione sociale (status). Il ruolo, ossia l insieme di aspettative, è sempre un prodotto sociale, è l esito della cristallizzazione delle norme e dei valori sociali che definiscono le modalità e i contenuti comportamentali di una specifica posizione sociale. Norme che possono essere sia esplicite (codici giuridici o deontologici) sia implicite (regole di un gruppo di pari, etichetta etc.). L insieme dei ruoli complementari di una data istituzione o contesto è chiamato role set (es. dottore-infermiere-paziente): il concetto di ruolo è intrinsecamente relazionale e implica che le aspettative rivolte ad uno staus siano differenti in relazione all attore sociale che concretamente le rivolge. Importando questi concetti in ambito tecnico sulla base di quanto evidenziato in [SCFY96] possiamo affermare che il ruolo riveste una componente fondamentale per l espressività delle entità in gioco nelle attività collaborative e e la cui esistenza è condizione necessaria per la scalabilità, l adattabilità e la versatilità della rappresentazione dei permessi di accesso alle risorse. Le Role sono in relazione con i permessi (Permission) ed allo stesso tempo con le Persona. Mentre i permessi sono in relazione con le Resource come esemplificato in figura 5.2. Role vs Group L introduzione dei Ruoli [SCFY96] permette una separazione completa tra le caratteristiche possedute da un soggetto ed il soggetto stesso. Questa separazione però può rendere più laborioso identificare operativamente tutte le regole per un determinato contesto. Capacità, funzione, posizione, mansione in una organizzazione sono alcuni sostantivi che possono essere utilizzati per individuare e delineare i ruoli. I gruppi quindi continuano ad essere un modo conveniente di aggregare gli utenti: infatti sono largamente usati per organizzare gli utenti nei processi e gestire i permessi. Se i gruppi sono organizzati gerarchicamente e se è possibile stabilire se un gruppo è sottoinsieme di un altro allora è possibile beneficiare della ereditarietà dei permessi e di attributi dal gruppo padre verso il gruppo figlio. In maniera informale il ruolo può essere visto come un tipo speciale di gruppo in quanto i ruoli forniscono una metodologia schematica e formale per raggruppare i permessi su un soggetto. Dualmente un gruppo può essere visto come un ruolo con minori capacità di adattamento, versatilità e dinamicità. 131

150 Modello del contesto Le entità Permesso abilita accesso su Permesso ha associato un Risorsa Ruolo ha un Persona Figura 5.2: Role Based Access Control Model Permission Un Permission è l approvazione di un particolare modalità di accesso ad una o più risorse nel sistema. In letteratura i termini autorizzazione, diritti di accesso e privilegi sono usati come sinonimi di permesso[scfy96]. I permessi sono sempre espressi in forma positiva e quando vengono assegnati conferiscono la facoltà di eseguire una certa azione nel sistema (risorsa). L approccio è analogo a white-list: se non è dichiarato il permesso l accesso è negato. Permission possono essere applicati su una sola Resource o su un insieme di Resource Location L entità Location è la rappresentazione di un luogo reale. Una Location può contenere altre Location, in modo simile al caso dei Group, e delle Resource. Ciò permette di creare una gerarchia di contesti collaborativi in cui i Persona si incontrano e partecipano in attività sincrone o asincrone, inter-personali o private. La Location di più alto livello, che contiene tutte le Location, prende il nome di Universe. Le Persona possono utilizzare questa struttura sia per rappresentare luo- 132

151 Modello del contesto La generalizzazione in entità ghi reali, sia luoghi convenzionali di ritrovo, intesi come spazi di giunzione tra Location. Persona, appartenenti a Location distinti, potrebbero avere comuni finalità progettuali per le quali è indicata la creazione di un nuovo spazio logico di incontro. L organizzazione degli spazi avviene per convenienza negli interessi di convenienza dell utente o di gruppi di utenti. Solo utenti con opportuni Role sono ammessi ad entrare nelle Location. Inoltre è possibile associare alle Location condizioni intrinseche e strutturali, come ad esempio orari di accesso e numero massimo di Persona contemporaneamente presenti Resource Resource è un aggregato di informazioni (documenti) e comportamenti (regole) dotato di un nome con il quale viene individuato. Può essere raggiungibile e si può operare su di esso con regole che ne specificano le possibili trasformazioni. Le Resource sono rappresentazioni di oggetti fisici, nell ambiente collaborativo. In generale sono Resource gli oggetti dell ambiente reale come ad esempio dispositivi, sensori, attuatori, documenti o porzioni di essi. Una Resource espone un insieme di operazioni ed ha un comportamento che è definito da eventi (esterni o interni) e dallo stato che di volta in volta viene assunto. La raccolta, l elaborazione e la presentazione delle informazioni sono i principali compiti di alto livello che una Resource deve assolvere. Le Resource non sono solamente oggetto di un insieme di azioni, ma sono anche soggetto di azioni verso Persona. Internamente all ambiente hanno la facoltà, quando necessario, di avviare in modo autonomo l interazione con le Persona, senza che da parte dell utente vi sia stata necessariamente una predeterminata propria volontà. Alcune caratteristiche delle risorse dipendono dal gioco recitato nella collaborazione: pensiamo ad esempio ad un libro di narrativa che risulta non modificabile, ma leggibile un numero indefinito di volte, oppure ad un documento di identità che dopo essere creato, può essere modificato solo attraverso una procedura di rinnovo, oppure ancora ad un insieme di appunti, sul quale c è libertà nelle scritture e letture concorrenti. Le informazioni trattate dalle Persona sono filtrate dalle Resource: un interfaccia espone le funzionalità che la Resource internamente provvede ad eseguire. In un ottica Object Oriented l istanza di una Resource è assimilabile ad un oggetto. La Resource è per definizione un entità creata dalla collaborazione di Persona, soggetta ad operazioni da parte di coloro che ne detengono i diritti (Role) ed è il risultato della elaborazione di informazioni (nuove o già esistenti). Nel caso limite è creata da una sola persona. 5.3 La generalizzazione in entità Nelle precedenti sezioni sono state illustrate le principali entità, che desideriamo trattare nel sistema, identificate in modo tale da arginare la complessità dell ambiente reale senza volerne ridurre l espressività. Con il termine entità si 133

152 Modello del contesto Il modello delle interazioni è quindi nominato tutto ciò che appartiene al contesto. Nei capitoli successivi, in alcuni casi sarà più conveniente non pensare a tipologie di entità (Persona, Group, Location, Role, Permission, Resource), ma a Resource come risorsa generica, ricorrendo al concetto di polimorfismo. La rappresentazione di una Resource avviene attraverso un documento (Document) che la descrive: in figura 5.3 è riportato il diagramma UML che mette in relazione le entità dichiarate. Resource Document Group Location Persona Role Permission Figura 5.3: Classificazione delle entità Questa generalizzazione permetterà sfruttare e ripensare l architettura per l implementazione di ogni componente informativa nel sistema. Un primo esempio del vantaggio verrà chiarito nella sezione 5.4 nella quale verrà illustrato come avvengono le interazioni. 5.4 Il modello delle interazioni All interno dell ambiente virtuale l interazione tra Persona viene filtrata dalle Resource. Le Resource costituiscono i catalizzatori e gli arbitri delle attività collaborative, in quanto oggetto e soggetto di elaborazione. Mentre Location e Group assolvono i compiti di strutturare rispettivamente lo spazio, e le gli utenti, Le Resource rappresentano il mezzo attraverso cui veicolare e controllare l informazione, con un paradigma web-based. I ragionamenti sopra esposti possono essere applicati ed estesi a qualsiasi entità del sistema: Location, Group, Persona, Role, Permission. Quindi si afferma il principio che le interazioni tra entità non avvengono mai direttamente, ma sono sempre mediate da una terza Entity. In figura 5.4 è indicato il modello delle interazioni tra Persona. Si distinguono quattro tipologie di interazione: uno a uno: l informazione è generata da un Persona che lavora autonomamente ed è indirizzata o destinata ad un altro Persona; uno a molti: l informazione è generata da un Persona che lavora autonomamente ed è indirizzata o destinata ad un Group, a cui può eventualmente appartenere; 134

153 Modello del contesto Il modello delle interazioni molti a uno: l informazione è generata da un Group in cui delle Persona lavorano in collaborazione ed è destinata ad una certa Persona; molti a molti: l informazione è generata da un Group in cui i vari Persona lavorano in collaborazione ed è destinata ad un altro Group, che eventualmente può contenere il primo o esserne un sottoinsieme. Virtual Environment Location Resource unicast operation Consumer Persona Producer Persona Location Resource multicast operation Target Group Producer Persona Location Resource unicast operation Consumer Persona Producer Group Location Resource multicast operation Target Group Producer Group Figura 5.4: Il modello di interazione L attività di una Persona è costituita da una sequenza di operazioni finalizzate a coinvolgere un solo utente o un intero gruppo. Il compito di identificare i destinatari, e quindi avviare la diffusione delle informazioni, non è totalmente 135

154 Modello del contesto Il modello delle interazioni affidato al produttore. Anche la Resource può avere un ruolo attivo. È bene ricordare che Persona e Resource sono entità dello stesso livello. Leggendo singolarmente i quattro casi di figura 5.4, da destra verso sinistra, si identificano due fasi: nella prima fase la risorsa subisce l iniziativa della Persona (o del Group) e nella seconda è prevista la consegna dei risultati elaborati ai destinatari. È facile osservare che esiste un disaccoppiamento delle Persona per mezzo delle Resource. La fase di produzione è quella più delicata in quanto coinvolge, a basso livello, operazioni di scrittura, in generale concorrenti, perciò è auspicabile che tra i Persona produttori e le Resource si realizzi un forte accoppiamento e sincronismo. Ciò non è necessario nella fase di consumo in quanto coinvolge le sole operazioni di lettura (non distruttive). Il vantaggio consiste da una parte nell aver separato le fasi critiche da quelle non critiche e dall altra nel consentire un interazione asincrona tra produttore e consumatore nelle attività collaborative. Per garantire awareness introduciamo nel sistema dei meccanismi di notifica di stato assunto dalle Resource, il quale può essere utilizzato per recuperare, quando necessario nelle attività collaborative, lo svantaggio dell assenza di sincronismo (a meno dei tempi di latenza). La notifica può essere comunicata prontamente alla Persona oppure avvenire al primo accesso alla risorsa. L importante è che la consegna sia sempre e comunque garantita. Un ulteriore osservazione riguarda l impossibilità di stabilire a priori il periodo e la scala dei tempi con cui il produttore accede alla risorsa. L architettura deve consentire sia attività periodiche che aperiodiche, sia dal lato consumatore che produttore. 136

155 Parte III InterDataNet: progettazione

156 Capitolo 6 L architettura InterDataNet IDN è una architettura per l integrazione delle risorse e delle informazioni con l obiettivo di sviluppare una infrastruttura per la cooperazione applicativa tra organizzazioni eterogenee e distribuite in grado di abilitare la collaborazione tra utenti, logo in figura 6.1. Figura 6.1: Logo del progetto IDN Risulta vantaggioso introdurre dei livelli di servizi che siano capaci di astrarre la memorizzazione, l elaborazione e la comunicazione dell informazione a livello più basso, consentendo di abbattere ed eventualmente eliminare la complessità dei processi a livello applicativo, e lasciando maggiore spazio per la realizzazione di applicazioni a valore aggiunto. Come suggerito in [Val01, EM04, WN01] verranno adottate viste multiple del problema generale, al fine di separare comportamenti e funzionalità, formulare vincoli, requisiti e soluzioni. IDN è logicamente e fisicamente descritto tramite tre viste complementari ed integrate: 1. vista sulle risorse e sull informazione,

157 L architettura InterDataNet IDN Information Model 2. vista sulla architettura dei servizi, 3. vista sulla infrastruttura di rete. Ciascuna vista pone l attenzione su aspetti critici del problema, muovendo dalla rappresentazione astratta del contesto, delle informazioni e delle esigenze, scendendo gradualmente nella rappresentazione concreta dell architettura di rete; arrivando alla descrizione degli appartati necessari alla implementazione. IDN Information Model. La prima vista prende il nome di IDN Information Model (IDN-IM). Un modello dell informazione [PS03, CT04, HS90] che intende rappresentare ogni tipo di informazione (strutturata), recependo i principi di responsabilità, paternità, storicizzazione e ciclo di vita dell informazione. Definisce quindi le proprietà di base dell informazione che dovrà essere trattata, ma volutamente non fornisce specifiche soluzioni implementative. Rappresenta quindi l informazione indipendentemente dalla tecnologia in maniera altamente strutturata, abilitando la collaborazione. IDN Service Architecture. La seconda vista prende il nome di IDN Service Architecture (IDN-SA). Definisce in maniera stratificata i servizi necessari per soddisfare il modello informativo IDN-IM, recependo i principi SOA [Jos07] e REST [Fie00]. Implementa le funzionalità definendo, sottosistemi, protocolli ed interfacce per una gestione collaborativa del documento. IDN-SA espone una IDN-API (Application Programming Interface) per lo sviluppo di applicazioni. IDN Overlay Network. L ultima vista prende il nome di IDN Overlay Network (IDN-ON). Implementa IDN-SA come sistema distribuito di apparati di rete sopra Internet in analogia alle reti Overlay Network. Gli apparati sono collocabili in seno alla infrastruttura di rete delle organizzazioni che desiderano attuare una politica collaborativa e di cooperazione applicativa, mantenendo la responsabilità solo su propri apparati. Permette di attuare politiche di separazione della responsabilità. Nel presente capitolo verrà esposta la trattazione teorica e panoramica delle tre viste sopra sintetizzate. I dettagli progettuali ed implementativi saranno affrontati nei capitoli successivi ed in particolare nella parte quarta di questa tesi. 6.1 IDN Information Model L intento di IDN-IM è quello di mettere in discussione il concetto tradizionale di documento generalmente considerato come monolitico e non strutturato, limitando le possibilità di soddisfare i requisiti di qualità del dato elettronico e la reale distribuzione dell informazione. L entità da gestire nell ambiente IDN è un documento multimediale. Risulta composto in generale da contenuti, relazioni (implicite o esplicite tra i contenuti) e metadati. 139

158 L architettura InterDataNet IDN Information Model In IDN il documento viene modellato come un aggregato di informazioni elementari; la struttura e il contenuto sono completamente separati dalla presentazione, che può anche non essere presente. Ciascun elemento informativo viene isolato rispetto agli altri secondo un principio gerarchico che si basa sull associazione ad un responsabile. Si consideri l esempio di un documento che rappresenta una patente di guida. Per ogni contenuto informativo è possibile determinare un organizzazione che detiene l informazione: per i dati anagrafici del titolare si risale al Comune, per i dati relativi alla scadenza si risale alla Motorizzazione, e così via. Il procedimento tende quindi a strutturare rigidamente il documento, seguendo semplicemente le regole che ne hanno determinato il rilascio. Non è necessario che la sorgente di informazione sia unica e unitaria; anzi, questa strutturazione trova maggior beneficio quanto più è possibile distinguere gli enti che trattano le singole informazioni, costituendo in modo naturale un sistema distribuito dal punto di vista del documento considerato. La dinamicità e la flessibilità sono ottenute grazie all elevato grado di autonomia delle singole sorgenti che, in modo collaborativo ed indiretto, partecipano alla costruzione di un documento capace di evolvere nel tempo; ogni parte del documento può infatti essere soggetta a variazioni. Inoltre, il documento è attivo, in quanto può evolvere e cambiare comportamento in dipendenza allo stato assunto ed alle relazioni espresse. Tornando all esempio della patente, se i punti vengono azzerati come effetto di una serie di contravvenzioni, il documento perde di validità e possono venire automaticamente notificati degli avvisi ad una serie di soggetti Cosa è un Information Model Si definisce Information Model una rappresentazione universale delle entità e delle loro proprietà, operazioni e relazioni, il cui scopo principale è quello di modellare gli oggetti ad un livello concettuale, indipendentemente da qualsiasi specifico repository, applicazione, protocollo o piattaforma. Esso non riguarda i dettagli, ma mira a catturare le astrazioni e i requisiti fondamentali delle entità da modellare. Un Data Model, invece, si occupa di gestire gli oggetti ad un livello di astrazione più basso, e comprende dettagli specifici dell implementazione e del protocollo, ad esempio regole che spieghino come mappare gli oggetti gestiti su costrutti protocollari di livello più basso [PS03]. Il principale vantaggio nell uso di un Information Model è la possibilità di generare, a partire da esso, più Data Model, intesi come i modelli concretamente realizzati. Questa capacità permette la scalabilità e l adattabilità del modello in contesti diversi. Un ulteriore conseguenza è la possibilità di scegliere, per la realizzazione, tra una vasta gamma di standard e tecnologie esistenti, se rispondenti alle esigenze. D altra parte, questa prospettiva rappresenta anche una forte restrizione, in quanto la sottile linea che divide il modello astratto dai relativi modelli concreti non è sempre di facile identificazione. IDN-IM è dunque una rappresentazione omogenea, astratta e consistente 140

159 L architettura InterDataNet IDN Information Model dell informazione, che ne cattura i requisiti, i principi e le proprietà desiderabili in termini assoluti, oltre a rappresentare un modello di documento universale, indipendente dal particolare contesto e da tecnologie specifiche. In base ad esso l informazione viene rimodellata partendo dalle sue caratteristiche native e globali; di conseguenza, è altamente strutturata ed è dotata di informazioni ausiliarie, ossia i metadati, per abilitare la gestione dell informazione distribuita in un ambiente di rete collaborativo [PCPP07b]. Tale modello di riferimento è stato derivato tenendo conto delle funzioni necessarie per i sistemi di gestione di documenti, come la creazione, la revisione, la pubblicazione, l accesso e l archiviazione, oltre alle funzioni telematiche per il supporto allo scambio e alla collaborazione. Lo scopo primario di un modello dell informazione (Information model, IM ) è delineare le entità informative a livello concettuale, indipendentemente da specifiche implementazioni o dai protocolli utilizzati per trasportare i dati. Un IM deve celare tutti i dettagli implementativi e di comunicazione al fine di rendere la progettazione la più chiara possibile. L altro importante compito di IM è modellare le relazioni tra le entità attraverso un linguaggio naturale o un linguaggio formale oppure con un linguaggio strutturato semi formale [PS03]. Viceversa i modelli per i dati (Data Model, DM ) sono definiti ad un livello più concreto ed includono molti dettagli con specifici costrutti. La principale conseguenza è che lo stesso IM può dare vita a più DM. In pratica però non è sempre possibile distinguere univocamente un DM dal suo IM. Esiste una zona grigia, dove IM e DM si sovrappongono parzialmente. In molti casi è veramente difficile stabilire se le astrazioni appartengono all uno o all altro. In questa sezione viene definito Information Model di IDN. L intenzione è quella di renderlo quanto più generico possibile in modo da permetterne l utilizzo in vari contesti L elaborabilità di un documento assume particolare rilievo quando esso viene rappresentato all interno di un calcolatore ed utilizzato come entità da trasmettere. Parafrasando Rein, McCue, Slein e Buckland [Buc97, RMS97], una definizione estesa e utile per gli argomenti trattati, è la seguente: un documento è la testimonianza di una evidenza fisica o intellettuale, memorizzata e strutturata in una qualsiasi forma materiale, capace di essere compresa dall uomo, trattabile dalla macchina e comunicabile. Molto spesso quando si considerano più informazioni distinte come un unica entità (raggruppate all interno di un documento) il contenuto informativo della somma è maggiore della somma delle singole informazioni. Si evidenzia come l informazione aggiuntiva sia data da correlazioni presenti fra le varie informazioni e permetta di caratterizzare il documento come un entità strutturata. Nel caso in cui questo aspetto sia trascurabile si parla di informazione non strutturata che comunque può essere vista come un caso particolare di quella strutturata. Data l importanza della tracciabilità (vedi sezione 3.1.1) delle modifiche nei contesti nei quali è previsto che il modello proposto venga applicato, la gestione dell evoluzione temporale delle informazioni (versioning) è integrata nel modello in modo nativo. 141

160 L architettura InterDataNet IDN Information Model Per rispondere a queste esigenze il modello di documento in esame, IDN (InterDataNet Information Model), è stato dotato delle seguenti caratteristiche: deve avere una struttura a DAG nella quale siano ben distinguibili e definiti come entità individuali i nodi che la costituiscono; devono esistere le seguenti tipologie di relazione fra nodi: link di riferimento e link di composizione; In questo modo il concetto di composizione è un caso particolare di quello di aggregazione, similmente alla terminologia utilizzata in UML [RJB99]. Ulteriori dettagli ed approfondimenti saranno discussi nella parte tecnica Elementi strutturabili All interno dei documenti con i quali si interagisce possono essere individuate alcune categorie di informazioni che possono essere evidenziate analizzando il documento. Tali categorie risultano le seguenti: contenuti: elementi esplicitamente fruibili dall uomo e che sono direttamente individuabili all interno del documento. Rientrano in questa categoria i testi, le immagini, le date, i nomi, i contenuti multimediali, eccetera; relazioni: legami fra contenuti che possono essere di tipo esplicito o implicito. Un esempio di legame esplicito può essere il riferimento ad una pagina o paragrafo di un libro, ad un articolo presente in una legge, eccetera. Dualmente un legame implicito può essere quello esistente fra il titolo di un capitolo di un libro e il contenuto del capitolo stesso; informazioni aggiuntive: ulteriori informazioni associate al documento e/o che possono essere date per scontate. Ad esempio l autore di un brano musicale oppure il fatto che i contenuti presenti nella prima pagina di un quotidiano rappresentano un sunto delle notizie più importanti del giornale; presentazione: informazioni necessarie per mostrare correttamente il documento all utente. Rientra a pieno titolo in questa categoria l aspetto grafico, ovvero la scelta dei caratteri, dei colori, dell impaginazione, eccetera. Questa categoria di informazioni fornisce un valore aggiunto che in particolari casi è determinante per permettere la fruibilità delle informazioni contenute nel documento. Queste categorie di informazioni sono state introdotte parlando di documento in senso astratto e/o nel senso convenzionale del termine. Nel momento in cui si intende codificare un documento per renderlo trattabile dalle macchine occorre formalizzare al meglio questi concetti al fine di poterli gestire efficacemente ed efficientemente da un punto di vista informatico. A tale scopo si può ricorrere ad opportuni linguaggi di marcatura che permettono di contrassegnare e quindi valorizzare i vari elementi contenuti nel 142

161 L architettura InterDataNet IDN Information Model documento. In questo modo si riescono a codificare tutte le categorie di informazioni e in particolare a rappresentare, esplicitamente o implicitamente, le relazioni. All interno dei documenti HTML, i link ipertestuali rappresentano delle relazioni esplicite: il link è presente ed individuabile nel documento. Viceversa la modalità implicita si presenta in uno degli esempi menzionati precedentemente, ovvero qualora si vada a contrassegnare il titolo di un capitolo come tale, in modo da evidenziarlo rispetto al testo presente nello stesso: non esiste una relazione fra titolo e contenuto del capitolo esplicitamente individuabile all interno del documento, ma tale marcatura permette di separare le due entità e considerarle, se necessario, come correlate. Da un punto di vista informatico i documenti dotati di queste caratteristiche e codificati opportunamente vengono chiamati documenti strutturati. I vantaggi riscontrati trattando documenti strutturati sono molteplici in quanto gli aspetti strutturali, oltre a fornire un contenuto informativo addizionale rispetto al caso non strutturato, permettono di garantire anche un maggior controllo dei contenuti. Inoltre tramite il riferimento ad altre informazioni è possibile realizzare vari documenti che, contenendo riferimenti alle medesime informazioni, di fatto determinano una rete di concetti Le macchine, in questo modo, diventano sistemi in grado di elaborare il contenuto informativo dei documenti e ciò permette di sfruttarne agevolmente le potenzialità in termini di velocità, memorizzazione e comunicazione per supportare efficientemente l uomo. Quindi il lavoro dell uomo risulta agevolato in quanto può essere velocizzato e facilitato nell immissione, nella ricerca, nella consultazione delle informazioni Strutturare con il principio di responsabilità Fornire delle regole non ambigue per strutturare documenti risulta un compito arduo. Allo stato attuale, molto interesse è rivolto a tecniche complesse legate a teorie semantiche ed ontologiche. Le discussioni nel panorama scientifico internazionale ed i progetti attorno al Semantic Web dimostrano come la semantica non sia ancora in grado di garantire una efficace integrazione dell informazione e una conseguente efficace collaborazione per gli attori coinvolti. Si evidenzia la necessità di condividere dati e quindi il problema risulta ancora aperto e lontano da una soluzione applicabile su larga scala. Sulla base di questo dato di fatto qui proponiamo un approccio diverso per la creazione di informazioni sufficientemente granulari da possedere le seguenti qualità (vedi sezione 3.2.2): modulari: aggregabili in maniera versatile con altre; indirizzabili: identificabili sia logicamente che per indice; semplificate: grazie alla marcatura di metadati standardizzati; riusabili: per la loro autonomia in diverse situazioni; interoperabili: indipendenti dal contesto. 143

162 L architettura InterDataNet IDN Information Model Tenendo presente le esigenze della collaborazione, in pratica proponiamo di applicare come regola strutturante il principio di responsabilità sulle parti informative che costituiscono l informazione. Principio che apre la strada alla elaborabilità in autonomia delle singole parti di cui è costituito il documento. Il responsabile è colui il quale ha la consapevolezza di dover rispondere degli effetti che possono scaturire a seguito della divulgazione dell informazione. Il responsabile può essere una persona fisica oppure giuridica che crea o modifica l informazione. Osserviamo che questa metodologia assume un valore estremamente determinante quando viene coinvolto il trattamento di informazioni sensibili ed in generale da in punto di vista giuridico. Il contesto è quello di una organizzazione. Analizziamo una informazione creata dalla collaborazione di più persone. Da un punto di vista organizzativo ciascuna persona avrà contribuito agendo su una parte e lasciando alle altre il compito di integrarla o di validare l unione. L organigramma aziendale, i ruoli ed il ciclo di vita dell informazione sono gli elementi che stabiliscono in maniera non ambigua chi è responsabile di cosa. Ciascuno deve essere abilitato ad agire sulle parti di sua competenza. Strutturare con il principio di responsabilità non presuppone la reingegnerizzazione dei processi, ma è evidente che se i processi fossero ben ingegnerizzati allora l applicazione del principio trova maggiore beneficio. Se isoliamo le parti più elementari, assicurandoci la loro riusabilità ed indirizzabilità, è possibile sfruttarle come building-block per la costruzione di nuova informazione riarrangiando, integrando e ricomponendo gli elementi disponibili. Prendiamo ad esempio un articolo: l autore è responsabile di ciò che vi ha scritto. Il direttore è responsabile della aggregazione ragionata di più articoli. Se il singolo articolo gode delle proprietà sopra esposte potrebbe essere adoperato da un altro direttore per la creazione di una pubblicazione diversa da quella per cui originariamente era stato concepito. Nel settore della Pubblica Amministrazione o comunque in tutti quei settori in cui esiste un elevato numero di elementi informativi ricorrenti e trasversali possiamo attuare una forte politica del riuso e la creazione di documenti in maniera dinamica, aumentando la qualità del dato. Il significato del singolo elemento dovrà essere comunque stabilito su larga scala, ma stavolta in aiuto intervengono normative e direttive aziendali che lasciano poco spazio alla interpretazione. Strutturare con questa tecnica significa agire su un piano trasversale ai contenuti semantici del documento, che ignoriamo a livello infrastrutturale. Su larga scala consente di realizzare in maniera automatizzata un insieme di mattoni informativi elementari che possono essere riutilizzati dalla comunità per costruire nuova informazione. Il principio di responsabilità può anche essere inteso come conseguenza naturale dei processi organizzativi e metodologici standard individuati all interno delle organizzazioni, ma sopratutto un modo relativamente più facile da automatizzare ed informatizzare che accompagna l informazione durante il suo ciclo di vita. Una importante osservazione è legata alla assegnazione selettiva dei diritti di accesso per le singole informazioni, quale condizione necessaria per poter parlare 144

163 L architettura InterDataNet IDN Information Model di responsabile. Al responsabile per esercitare il suo ruolo devono essere fornite le garanzie sulle modalità di gestione ed accesso all informazione Identificazione dei nodi Un elemento informativo per essere correttamente condiviso, divulgato e riusato necessita di possedere due proprietà fondamentali: deve essere individuabile ed accessibile. Nei sistemi telematici per individuare una risorsa si usa il suo indirizzamento e spesso l indirizzo stesso diviene anche per l accesso fisico (come nel caso degli URL 1 ). Nel modello IDN l identificazione dei nodi è una proprietà che deve essere mantenuta indipendente dai dettagli dell accesso fisico, poichè l accesso fisico non rappresenta un contesto di interesse per un Information Model. In altre parole è importante disporre di identificatori che vadano ad astrarre dalla localizzazione fisica delle risorse e siano quindi indipendenti dalla stessa. Questo è conseguenza della percezione che ha l essere umano del concetto di documento : ad esempio con categoria della patente di guida di Mario Rossi si intende un informazione ben precisa ed indipendente dal luogo e dal formato in cui viene conservata e acceduta. In pratica la categoria è la stessa informazione sia che questa venga memorizzata negli archivi elettronici della Motorizzazione Civile che stampata sul documento in formato cartaceo per il titolare della patente. L esempio relativo alla patente di guida evidenzia come l identificazione delle risorse sia un operazione concettualmente diversa dall accesso e pertanto, in generale, è opportuno che le due operazioni siano distinte per rispettare la separation-of-concern. In tal caso, una volta effettuata l identificazione in una prima fase, è possibile procedere, in una fase successiva, con l accesso. Queste ultime considerazioni hanno portato alla definizione degli URN (Uniform Resource Name) [SM94, Moa97, DvGIF99, Dan97]. Un URN è anche un URI, ma differisce da un URL per il fatto che identifica una risorsa web indipendentemente dalla sua locazione fisica in modo non ambiguo ed univoco, inoltre non contiene informazioni variabili nel tempo. Un buon esempio di URN è il codice ISBN di un libro [LPD98]: ISBN identifica un libro, ma nessuna delle sue copie. In IDN si definiscono Persistent Resource Identifier (PRI ) gli URN che identificano i nodi del documento in modo univoco, questo nome mette in evidenza la principale proprietà che caratterizza questo tipo di identificatore: la persistenza. Ulteriori dettagli relativi alla definizione ed alla gestione dei PRI verranno riportati nel capitolo 9. Poiché i PRI sono ad uso e consumo della macchina, non sono necessarie restrizioni per renderli facilmente utilizzabili e trascrivibili dall uomo, anche se ciò è comunque auspicabile. Purtroppo gli utenti hanno bisogno di assegnare nomi facilmente intellegibili e condivisibili con altri per indicare concetti e contenuti. 1 Uniform Resource Locator [BLMM94], sono gli indirizzi utilizzati nel web per identificare ed accedere alle risorse. Sono un caso particolare di URI (Uniform Resource Identifiers [BLFM98]). 145

164 L architettura InterDataNet IDN Information Model (a) URL URL URL Replica Replica Replica (b) URN URL URL URL Replica Replica Replica (c) HFN HFN URN URL URL URL Replica Replica Replica Figura 6.2: Nomi di risorse replicate Per riempire il divario tra le proprietà del PRI e le necessità umane è opportuno introdurre un nuovo tipo di URI come suggerito in [Mea02]. È definito Human Friendly Name (HFN ) un nome di alto livello progettato a misura d uomo [SM94]. A differenza degli URN gli HFN permettono l uso esplicito di nomi descrittivi. Un HFN ha bisogno di essere risolto in un PRI quando l utente vuole stabilire una convenzione univoca verso la risorsa. Per evidenziare che gli HFN assegnano un nome logico alla risorsa, nel modello IDN sono stati definiti i Logical Resource Identifier (LRI ) come sottocaso particolare. Gli LRI permettono l uso esplicito di alias, sono nomi flessibili e descrittivi e relativi ad uno specifico contesto; inoltre risultano facilmente comprensibili e interpretabili dagli utenti perché definiti e assegnati in base al paradigma di contenimento e catalogazione folder/file. A livello applicativo hanno possono avere il vantaggio di essere facilmente comunicabili a patto di scegliere una codifica efficace. 146

165 L architettura InterDataNet IDN Information Model In IDN-IM gli identificatori LRI sono gli handle di alto livello che mascherano gli identificatori di elaborazione ed accesso propriamente appartenenti ad una vista Data Model (URL). Esistono molti vantaggi con questo approccio. In primo luogo gli utenti possono assegnare in libertà nomi di convenienza alle risorse. Se una risorsa è replicata o spostata in un altra locazione, ciò non ha effetti sul nome LRI. Analogamente, se un utente decide di cambiare l LRI non si avranno effetti sulla posizione delle repliche. Inoltre un utente può scegliere di usare nomi diversi per indicare la stessa risorsa, allo stesso modo con cui vengono usati gli alias negli indirizzi di posta elettronica o nei link simbolici del file system. Ulteriori dettagli su LRI e PRI saranno trattati nel capitolo Osservazioni sul modello Sulla base dell analisi estesa dei requisiti (capitolo 3) e delle considerazioni precedentemente enunciate (sezione 6.1.3) possiamo discutere le caratteristiche che il documento definito da IDN-IM deve soddisfare. Alcuni di essi risultano vincolanti per gli obiettivi del sistema, mentre altri sono desiderabili al fine di garantire la massima applicabilità ed estensibilità del modello. Una prima caratteristica prevede che l informazione sia strutturata, il che sottintende la necessità di poter riusare ed elaborare l informazione con il minimo dispendio di risorse per la sua interpretazione. Ogni informazione deve essere strutturabile, indipendentemente dalla sua forma fisica, anche se non si è certi che la struttura sia univocamente determinabile a fronte di scelte interpretative diverse. Inoltre, l informazione deve poter essere aggregata per formare una nuova informazione. Ciò deriva dall osservazione che l unione di più informazioni ha come risultato un informazione nuova, diversa da ciascuna delle sue componenti. Viceversa, la scomposizione dell informazione in entità elementari più semplici consente di massimizzare il riuso, la trasportabilità e l autoconsistenza di ciascun aggregato. Un ulteriore vantaggio è rappresentato dalla possibilità di definire funzioni di accesso e di modifica in modo mirato. Al fine di mantenere le regole di strutturazione dell informazione indipendenti dai contenuti informativi, onde evitare il rischio di contaminare il modello con problematiche relative a specifici contesti, viene introdotto il principio di responsabilità. In modo del tutto ortogonale ai contenuti informativi, si assume che l informazione sia il risultato di produzioni iterative: ciascun passo vede un responsabile (spesso, ma non sempre, coincidente con l autore) che produce informazione a partire da informazioni già esistenti in forma più semplice. Tale assunzione è garantita dalla definizione stessa di informazione, poiché esiste sempre almeno un attore che crea e/o controlla l informazione. Assumere a priori che il modello sia strutturato sulla base di tale principio risulta coerente con le dinamiche del workflow e i modelli ad oggetti. Lo stesso principio si può riscontrare nei sistemi blog e wiki, nei quali la 147

166 L architettura InterDataNet IDN Service Architecture composizione di informazioni avviene sulla base di contributi incrementali, gestiti da autorità con responsabilità distinte, che assieme vanno a costituire un nuovo documento. L informazione deve essere indipendente dalla locazione fisica. Questo punto intende mettere in evidenza che un informazione è tale indipendentemente da dove sia fisicamente collocata. Spesso, infatti, la stessa informazione viene memorizzata in apparati fisici distinti ed eterogenei, che però non devono influire sui contenuti informativi. Questa affermazione potrebbe sembrare banale, ma agli effetti pratici la detenzione fisica dei dati da parte di una organizzazione risulta spesso essere ingessante per il sistema organizzativo ed informativo (anche internamente) che può risente delle costrizioni imposte da normative o da pratiche adottate da un nucleo ristretto di affiliati. L informazione già esistente nelle organizzazioni è distribuita per definizione, per cui questo requisito è soddisfatto a priori; il problema da affrontare è come realizzarne l acquisizione, l arricchimento e la manutenzione in modo distribuito e consistente, guardando alla distribuzione già esistente come a un vantaggio da sfruttare, e non come a uno svantaggio da azzerare. Una caratteristica che non è obbligatoria ma fortemente desiderabile, in quanto sostiene i requisiti di affidabilità e scalabilità, è che l informazione sia replicata. La replicazione introduce un certo numero di vantaggi, come l aumento della disponibilità dell informazione, garantendone il recupero a fronte di guasti, e il dimensionamento adattativo nel tempo del sistema in funzione della richiesta. È necessario che l informazione sia tracciabile, di conseguenza il sistema deve essere dotato di uno storico e di un meccanismo di versionamento (versioning) dell informazione. La sola presenza dell informazione risulta sicuramente riduttiva e inespressiva nello svolgimento delle attività collaborative all interno delle organizzazioni, le quali richiedono che sia possibile tracciare la storia dell informazione in quanto legata al workflow e all authoring concorrente e per la determinazione a posteriori delle responsabilità. È indispensabile che l informazione sia indirizzabile in modo efficace e flessibile sia sul piano telematico che come modello di supporto alle attività collaborative. La prassi di assegnare alias alla stessa informazione viene coadiuvata e formalizzata attraverso un opportuno sistema di nomi, mentre la loro gestione è delegata all architettura stessa. Infine, bisogna tenere presente che un informazione è tanto più utile quanto più è orientata alla collaborazione, ossia è stata creata con lo scopo di essere condivisa e sfruttata da più utenti, facilitandone l utilizzo su larga scala. 6.2 IDN Service Architecture Allo scopo di identificare i servizi necessari per un implementazione efficace ed efficiente di IDN-IM, è stata concepita un architettura logica stratificata, chiamata InterDataNet Service Architecture (IDN-SA), in grado di catturare i concetti del modello dell informazione e di separare la complessità del problema su più livelli (figura 6.3), in modo da stabilire le basi per l architettura di rete. 148

167 L architettura InterDataNet IDN Service Architecture crescita dell'astrazione Informazioni complesse (documenti) Informazioni elementari (nodi) Byte. (file, database) Application Layer Virtual Repository Layer Information History Layer Replica Management Layer Storage Interface Layer Figura 6.3: Livelli dell architettura IDN La definizione è top-down: si parte dal una analisi e progettazione di alto livello (logica) per arrivare ad una trattazione dei servizi di basso livello (fisici). Principalmente in IDN si applica l architectural pattern 2 della stratificazione. La struttura fisica e logica di IDN ricerca quindi una soluzione che, dal punto di vista del trattamento dell informazione, sia analoga a quella dei sistemi di comunicazione tra piattaforme eterogenee, ispirandosi al successo della suite TCP/IP. Così come Internet risolve i problemi della comunicazione per le reti interconnesse delegando a livelli diversi la cura di aspetti specifici [Bra89b], IDN propone l uso di livelli differenti per abilitare a livello globale la collaborazione tra persone, imprese ed organizzazioni. Ogni livello affronta una problematica o caratteristica propria dell informazione (documento) ponendola su un piano condiviso e collaborativo. I livelli più alti percepiscono l informazione come entità complessa sotto forma di documento. Ogni documento è costituito da una serie di informazioni elementari legate da relazioni strutturali. Spostando l attenzione verso i livelli intermedi gli aspetti strutturali dell informazione vengono meno: l informazione è vista come tante unità elementari indipendenti. Infine per i livelli più bassi l informazione è semplicemente una particolare codifica delle entità definite ai livelli superiori, in altre parole sequenze di byte (file e record di database). Con questa prospettiva, nel presente lavoro, si parla di livello (o layer) per fare riferimento ad un contenitore logico di servizi e sottosistemi indipendenti che manipolano ed effettuano specifiche operazioni sull informazione. Tali sottosistemi interagiscono fornendo o richiedendo servizi ad altri sottosistemi appartenenti allo stesso livello logico oppure ad altri livelli adiacenti. IDN-SA (figura 6.3) descrive i livelli di servizi Virtual Repository, Information History e Replica Management. Vincolare e dettagliare gli strati Application e Storage Interface, alle estremità dello stack, non risulta conveniente ai 2 Fornisce un insieme di sottosistemi predefiniti, specifica le loro rsponsabilità e le regole ed esplicita le regole e linee guida per organizzarli e relazionarli tra loro [BMR + 96]. 149

168 L architettura InterDataNet IDN Service Architecture fini, rispettivamente, della crescita del sistema e dell adattabilità verso sistemi esistenti. Per quanto concerne la crescita viene infatti lasciata la massima libertà per quel che riguarda la definizione del contesto applicativo che può essere diversificato. Analogamente non vengono fissate specifiche stringenti sul formato di storage dei dati. Quest ultimo aspetto permette quindi di diversificare anche le soluzioni di basso livello, aspetto che garantisce l adattabilità con il passato ovvero la possibilità di riutilizzare, definendo dei Storage Interface ad hoc, i sistemi legacy. Si noti come questo approccio equivalga a quello utilizzato nella definizione della pila Internet per la quale è stata lasciata la massima libertà nella definizione del livello applicativo e dei livelli inferiori a quello di rete Attraversamento dei livelli L interazione fra i livelli avviene tramite il paradigma client/server: ogni livello è client di quello inferiore (al quale richiede servizi) e server di quello superiore (al quale fornisce dei servizi). Quindi, per ogni coppia di livelli, viene definito un protocollo di comunicazione che, come HTTP (vedi [FGM + 99]), è request/response. Il paradigma convenzionale di interazione fra l utente e il sistema è di tipo pull: in seguito ad un azione dell utente la pila viene attraversata da una sequenza di request che si sviluppa dall alto verso il basso e da una sequenza corrispondente di response che la percorre in senso opposto. Ogni livello si attiva per generare la response a seguito di ogni request proveniente dal livello superiore (o da un azione dell utente per quanto riguarda il livello applicativo), eventualmente effettuando delle richieste ai livelli inferiori (come evidenziato in figura 6.4) per richiedere l espletamento di servizi necessari per il completamento dell operazione. Richiesta dell'utente Risposta all'utente Request - Response Livelli IDN Tempo Figura 6.4: Interazione request/response applicata ad IDN Un meccanismo di notifica in modalità push, risulta utile in svariate situa- 150

169 L architettura InterDataNet IDN Service Architecture zioni (ad esempio per inoltrare segnalazioni in tempo reale all utente a seguito di eventi che si sono verificati nel sistema). Si può comunque osservare che è possibile simulare la modalità push in presenza della sola modalità pull (a scapito dell efficienza operativa) tramite polling. Questo permetterà a livello implementativo di rimandare l inserimento della modalità push senza perdere in generalità nella trattazione. Nel capitolo 8 sarà fornita una panoramica complessiva e generale sui compiti di ciascun livello della architettura. Nella parte IV gli stessi livelli verranno analizzati singolarmente con maggiore dettaglio tecnico-progettuale Imbustamento di dati e metadati L attraversamento dei livelli, descritto per la modalità di interazione (paragrafo 6.2.1), ha dei risvolti di interesse anche per le modalità con cui vengono trattate le informazioni. Infatti le informazioni vengono elaborate e trattate a seguito della comunicazione fra i livelli. Da un punto di vista generale è valida la seguente affermazione: ogni livello di IDN tratta le informazioni scomponendole, con la granularità necessaria, in dati elementari ed associa alle stesse un insieme di metadati. I dati quindi, indirizzabili con granularità arbitraria, codificano le informazioni vere e proprie; in aggiunta vengono associati ad essi tutti quei metadati necessari (o opzionali) per trattare le informazioni secondo quanto previsto dal modello IDN-IM. Entrando nel dettaglio, come rappresentato in figura 6.5, si ha la seguente situazione: le IDN-Application definiscono a proprio uso e consumo le rappresentazioni opportune delle informazioni e coerentemente al modello IDN-IM (ed alla IDN-API). Virtual Repository offre alle applicazioni l opportunità (tramite la IDN-API) di gestire tali informazioni, esponendo una interfaccia uniforme di dati e metadati; Virtual Repository aggiunge tutti quei metadati (VR-META in figura 6.5) necessari alla gestione dei documenti IDN-IM: dai metadati per la gestione della struttura del documento, a quelli per l identity management, dai metadati per la gestione del modello di versioning UEVM a quelli per l indirizzamento delle risorse con nomi logici. L insieme di questi elementi, con l aggiunta del contenuto prettamente informativo, codificato in VR- DATA, viene imbustato e passato al livello Information History, che lo trattaterà come un unica entità (IH-DATA); Information History aggiunge quindi quei metadati (IH-META) necessari alla gestione del versioning delle singole entità elementari (come se fossero non strutturate) e l insieme di tali dati e metadati viene imbustato a livello Replica Management e trattato come un unica entità (RM-DATA); Replica Management aggiunge a sua volta quei metadati (RM-META) necessari alla gestione della replicazione delle singole entità elementari (come se fossero non strutturate) e tale insieme di dati e metadati viene imbustato a livello Storage Interface e trattato come un unica entità (SI-DATA); 151

170 L architettura InterDataNet IDN Service Architecture SI-DATA SI-META Storage Interface Layer RM-DATA RM-META Replica Management Layer IH-DATA IH-META Information History Layer VR-DATA VR-META Virtual Repository Layer APP-DATA Application Layer Figura 6.5: Imbustamento di dati e metadati infine Storage Interface provvede ad esporre i dati memorizzati su sistemi di storage eterogenei, associando ad essi gli opportuni metadati (SI-META). Il provedimento top-down, appena illustrato, è utile per evidenziare l applicazione in IDN del principio di information hiding. Altrettanto utile è descrivere la visione bottom-up per capire come dati ed metadati (in generale le informazioni) vengono esposte ai livelli superiori. Infatti la descrizione appena fornita non permette di capire completamente come vengono trattati i metadati. Da un punto di vista generale è possibile osservare che ogni livello espone, secondo un interfaccia uniforme, i dati ed i metadati al livello superiore. Questo significa che il livello superiore, per ogni informazione alla quale intende accedere, ha la possibilità di richiedere la gestione dell informazione stessa (il dato) ed un opportuno insieme di metadati. Tali metadati possono essere definiti dal livello inferiore ed esposti, oppure essere stati definiti dal livello stesso e fatti soltanto gestire dal livello inferiore. Quindi, alla luce di queste considerazioni, è possibile indicare per ogni livello le seguenti categorie di metadati (figura 6.6). Per semplicità fissiamo l attenzione sulla una coppia di livelli Information History (IH) e Replica Management (RM), da cui è immediato genereralizzare. i metadati definiti dal livello superiore e solamente gestiti da quello in esa- 152

171 L architettura InterDataNet IDN Service Architecture me, in termini di creazione, accesso, modifica, e cancellazione (IH-META, in figura 6.6); i metadati definiti dal livello in esame per il proprio funzionamento, ma esposti al livello superiore perché significativi per esso (in figura Exposed- META); i metadati definiti dal livello in esame per il proprio funzionamento interno e non visibili al livello superiore (in figura Internal-META). Information History Layer RM-API IH DATA RM-DATA IH META RM-META Exposed META Internal META Replica Management Layer Figura 6.6: Classi di metadati in IDN Si faccia quindi nuovamente riferimento alla figura 6.5 e si consideri il livello Replica Management. Nell insieme di informazioni classificate con RM-DATA rientrano i dati veri e propri di livello IH ed i metadati definiti da IH la cui gestione, in termini di creazione, accesso, modifica, e cancellazione, viene delegata ad RM. In figura 6.6 sono esemplificate tutte le entità: RM-DATA, IH-DATA e IH-META. Ad esempio i dati potrebbero essere il contenuto vero e proprio relativo alla versione x di una data informazione ed uno dei metadati gestiti da RM potrebbe essere proprio il numero di versione <version_id,x>. Ovviamente, il numero di versione non è un elemento che RM è in grado di interpretare, può solo prendersi cura di memorizzarlo mantenendolo associato all informazione di base ed esporlo ad IH (livello che ne ha la responsabilità). Proseguendo attraverso esempi di metadati, è possibile citare la data di creazione di un unità informativa replicata. Questo tipo di metadato viene definito e gestito a livello RM, ma può essere di interesse anche al livello superiore e quindi sarà esposto ad esso. In questo caso, in riferimento alla figura 6.6, questo tipo di metadato rientra a pieno titolo in RM-META (Exposed-META) ed RM offrirà al livello superiore l accesso allo stesso (se pur con alcune limitazioni). Questo perché, essendo tale metadato di competenza di RM, tale livello non permetterà che IH possa modificarlo senza controllo. Nell esempio specifico non permetterà affatto che IH possa modificarlo, offrendogli solo la possibilità di accedere ad esso in sola lettura. Questo perché è RM che crea (eventualmente su richiesta di IH) le unità informative replicate e sarà quindi sua cura definire il campo <creation_date,date> 3.). 3 Si noti che in questo caso il campo non sarà più aggiornato per tutto il tempo di vita 153

172 L architettura InterDataNet IDN Overlay Network Infine restano da analizzare i metadati definiti dal livello per il proprio funzionamento interno e non visibili al livello superiore (in figura 6.6 Internal META). Si pensi ad esempio all indirizzo fisico di una singola replica: questo tipo di metadato non è di interesse per il livello superiore (che vede solo entità delocalizzazione e replicate) e pertanto, pur rientrando nella classe RM-META, non viene reso visibile al livello superiore. Quest ultima classe di metadati viene memorizzata dal livello inferiore (come per il numero di versione citato in precedenza), può essere generata dinamicamente, anche da sistemi esterni. Ciò apre la possibilitò di definire un meccanismo di integrazione di metadati in maniera incrementale su informazioni provenienti da sistemi legacy. 6.3 IDN Overlay Network IDN è un architettura distribuita ovvero un insieme di entità di elaborazione cooperanti tramite una rete di comunicazione. Nell approccio IDN, i problemi di interoperabilità tra sistemi informativi eterogenei sono affrontati secondo un modello di interdataworking, nel quale è prevista la collaborazione su più livelli tra apparati, cioè macchine o dispositivi, con lo scopo di fornire servizi di base ad alto livello. Ciascuno di questi apparati opera una trasformazione intermedia, riducendo la complessità a livello applicativo e permettendo di partizionare il problema globale, rendendolo efficacemente trattabile. Si sottintende dunque un architettura implementativa coerente con i principi dell interdataworking, nella quale tra una sorgente ed una destinazione esistono dei punti intermedi, ognuno dei quali svolge determinati compiti, in analogia agli apparati di rete per l internetworking come hub, switch, router e gateway. La trasposizione architetturale IDN-SA che definisce, basandosi su IDN-IM, il modello logico e gli apparati infrastrutturali di rete, prende il nome di Inter- DataNet Overlay Network (IDN-ON), letteralmente rete di sovrapposizione, in quanto è una rete di calcolatori costruita sopra un altra rete (in questo caso, Internet). Da una prospettiva strettamente software, l archiettura è classificabile a tutti gli effetti come middleware five-tier (figura 6.7). Infatti con middleware si intende un sistema stratificato di applicazioni, eseguite su una o più macchine che interagiscono in rete per supportare l interoperabilità di architetture distribuite agendo da intermediari tra le applicazioni di alto livello e servizi di infrastruttura [TvS01]. Inoltre ricordiamo che il middleware mira a: mascherare la distribuzione. Una applicazione può essere supportata da molte parti interconnesse in locazioni distribuite; mascherare l eterogeneità di piattaforme hardware/software e protocolli; dell unità informativa. Si pensi però ad un metadato quale la data di ultimo accesso: sarà aggiornato da RM in corrispondenza di ogni richiesta di accesso all unità informativa e solo in tal caso. 154

173 L architettura InterDataNet IDN Overlay Network Application Layer Application Virtual Repository Layer IS RAS LDNS Information History Layer Information History (VTA) Control Plane Replica Management Layer Replica Management LS Storage Interface Layer Storage Interface Figura 6.7: Livelli e servizi dell architettura IDN fornire in maniera uniforme una interfaccia standardizzata ad alto livello per gli sviluppatori ed integratori di applicazioni, affinchè le applicazioni possano essere facilmente composte, riusate, portate e rese interoperabili; supportare un insieme di servizi di base per espletare funzionalità generalpurpose, al fine di evitare la duplicazione e facilitare la cooperazione applicativa. I nodi di una rete di sovrapposizione possono essere rappresentati come connessi da collegamenti virtuali o logici, ciascuno dei quali corrisponde ad un cammino, magari attraverso molti collegamenti fisici, nella rete sottostante. Ad esempio, molte reti peer-to-peer sono reti di sovrapposizione perché poste sopra Internet. IDN-ON è invece un architettura di rete in quanto: basata sul paradigma client-server; costituita da processi di livello applicativo (ISO/OSI); totalmente distribuita. Il processi applicativi interagiscono erogando servizi in maniera flessibile ed adattativa, in quanto possono essere opportunamente installati e configurati analogamente a quanto avviene con gli apparati di internetworking Dall architettura dei servizi alla rete L architettura più semplice in grado di fornire un servizio è costituita da un singolo processo ospitato in un host, ma generalmente un servizio viene fornito da un cospicuo insieme di istanze di processi distinti come in IDN. 155

174 L architettura InterDataNet IDN Overlay Network Mentre la descrizione dei servizi implica la definizione di coreografia e orchestrazione, la descrizione di rete fornisce la descrizione dei percorsi che l informazione percorre su nodi e rami della rete. La rete di comunicazione fa parte dell infrastruttura utilizzata da IDN per il proprio funzionamento, infatti ogni apparato IDN è un sistema di livello applicativo della pila ISO/OSI. Parlando di layer (o comunque livello, tier o strato) viene fatto riferimento ai livelli di servizio elencati nel paragrafo precedente: Application Layer, Virtual Repository Layer, Information History Layer, Replica Management Layer e Storage Interface Layer. In figura 6.7 sono mappati i livelli di servizi in tier. Il Control Plane introdotto ortogonalmente alla pila è una astrazione grafica che intende evidenziare come alcuni processi di controllo e monitoraggio siano collocati al margine della stratificazione per esigenze di configurazione e debugging. I livelli di IDN sono costituiti da processi, ovvero programmi in esecuzione [TW97] su host di rete (computer fisici o macchine virtuali). I processi, per poter erogare dei servizi all esterno, devono essere individuabili in rete tramite indirizzi di livello applicativo di OSI 4. In figura 6.8 vengono riportate esplicitamente le relazioni esistenti tra gli apparati che costituiscono il sistema IDN. Due processi hanno la possibilità di comunicare se i relativi servizi sono collegati tramite una freccia. In particolare la direzione della freccia indica in quale verso si sviluppa la richiesta: l elemento dal quale essa parte è il richiedente del servizio ovvero il client, mentre quello nel quale essa termina è il fornitore del servizio ovvero il server. La figura 6.8 è possibile osservare come tutti i processi in gioco rispettano i vincoli del modello stratificato presentato nel paragrafo 6.2, ad eccezione di quelli appartenenti ad un piano trasversale Control Plane (CP), per motivi di configurazione e debugging Control Plane Il piano di controllo serve ad impostare le condizioni iniziali ed a contorno dei processi dell architettura (es. file di configurazione). La possibilità di intervenire su alcuni piani in modo diretto, indipendentemente dal comportamento degli altri layer, consente attività di amministrazione, manutenzione e configurazione. Ad esempio parametri di funzionamento quali quelli relativi alle regole per la distribuzione delle repliche, al comportamento delle versioni e delle informazioni possono essere monitorati e controllati direttamente attraverso questo piano. Control Plane permette di agire e monitorare anche per finalità di debugging a vantaggio degli sviluppatori IDN nell osservazione e controllo del sistema. In altre parole gli amministratori, grazie al Control Plane, hanno una visione sulla messa in esercizio dei processi. I dispositivi appartenenti ad altre organizzazioni non rientrano, ovviamente, nel gruppo di sistemi su cui i suddetti amministratori hanno autorità. 4 In riferimento a reti basate sullo stack TCP/IP è possibile fare riferimento a coppie IP:PORTA. 156

175 L architettura InterDataNet IDN Overlay Network Application Layer Application Type 1... Application Type N Control Plane Virtual Repository Layer Resource Aggregation Service LDNS Service Identity Service Information History Layer Information History (VTA) Control Service Replica Management Layer Replica Management Service LS Service Storage Interface Layer Storage Interface Service Legenda: tipologie di processi Processo dotato di interfaccia utente Processo privo di interfaccia utente Figura 6.8: Livelli, servizi e processi Le attività evidenziate, attraverso il Control Plane sono confinate localmente all host Rete ed interoperabilità Un organizzazione che utilizza IDN dovrebbe disporre di idonea infrastruttura (hardware e software) capace di accedere alle risorse fornite dalle altre organizzazioni, oltre che esporre le sue risorse affinchè altri le usino per una piena federazione. Il modo più diretto per organizzare gli apparati è quello di predisporre uno o più server hardware e vari personal computer per i client utente interconnessi alla rete. Si può suggerire l esistenza di appositi service provider che forniscano alle 157

176 L architettura InterDataNet IDN Overlay Network organizzazioni l infrastruttura per l accesso a IDN, accollandosi l onere di amministrare e manutenere gli apparati, così come avviene attualmente, ad esempio, per i fornitori dell accesso ad Internet. Si consideri il collegamento tra un dominio A, che rappresenta un organizzazione che adotta un sistema legacy, e un dominio B, che rappresenta un organizzazione collaborativa realizzata in completo accordo alle specifiche IDN. Dal punto di vista dell architettura, il dominio A ha bisogno di essere esteso con un entità che operi in maniera trasparente, arricchendo, senza alterarli, i dati del dominio A con metadati e strutture logiche, al fine di esporli ai domini esterni. In questo caso, il dominio A deve essere esteso con un apparato di interdataworking che implementi quella parte dei servizi IDN necessaria per consentire al sistema di scambiare informazioni con altri sistemi IDN. Nella figura 6.9 è riportato uno scenario in cui i sistemi delle organizzazioni A e B sono nativi IDN e relativi a due domini indipendenti; la federazione degli apparati IDN nel dominio A e degli apparati IDN nel dominio B avviene sfruttando Internet a basso livello. Organizzazione A Organizzazione B App. App. App. Lan1 Lan VR IH LS LDNS Lan2 IH RM SI Internet VR IH LDNS LS IH RM SI Figura 6.9: Scenario di cooperazione Si presuppone che, per quanto possibile, ogni organizzazione utilizzi i servizi di IDN-SA installati internamente, in quanto l interazione tra i server presenti all interno di una rete privata garantisce un maggiore controllo di amministrazione e permette di controllare in modo più diretto ed efficace gli aspetti legati alle questioni di sicurezza e di manutenzione. Ciò non è vincolante, anzi è desiderato che esista una integrazione di servizi con apparati in modo che il volume complessivo dell informazione disponibile possa aumentare nel tempo grazie alla cooperazione cross-domain. In figura 6.10 è riportato un esempio di questo tipo di interazione. Come è possibile osservare un applicazione interna all organizzazione A intende accedere a dei dati propri dell organizzazione B. Si noti che, grazie alla delocalizzazione offerta dal middleware, l applicazione potrebbe essere del tutto all oscuro del fatto che l informazione richiesta è detenuta 158

177 L architettura InterDataNet IDN Overlay Network dall organizzazione B. Nel caso rappresentato in figura, l applicazione effettua una richiesta d accesso all unica istanza di Virtual Repository interna ad A. Tale istanza, dopo aver elaborato la richiesta, a sua volta ne effettua una nuova ad una delle due istanze di Information History interne all organizzazione, per procedere con l algoritmo di accesso verso i dati. L algoritmo prosegue verso Replica Management. In questo caso si ha un interazione cross-domain fra una delle due istanze di Replica Management interne ad A e quella interna a B la quale, infine, va a reperire il dato richiesto sull opportuno Storage Interface. Organizzazione A Organizzazione B Application Virtual Repository Information History Replica Management Storage Interface Figura 6.10: Esempio di interazione fra i servizi in organizzazioni diverse La crescita del sistema IDN è abilitata grazie alla installazione di nuovi apparati e collegamenti IDN sulla base delle necessità in maniera analoga a quanto accade per le reti locali o di area metropolitana o geografica quando vengono ridimensionate introducendo nuovi router, gateway, hub, ecc. 159

178 Capitolo 7 InterDataNet Information Model L entità gestita nell ambiente IDN è un generico (nel senso di non specializzato) documento multimediale, perciò risulta composta da contenuti, relazioni implicite o esplicite tra contenuti, metadati ed eventualmente informazioni sulla presentazione. In IDN il documento viene modellato come un aggregato di informazioni elementari; la struttura e il contenuto sono completamente separati dalla presentazione. Ciascun elemento informativo viene mantenuto isolato rispetto agli altri secondo un principio gerarchico che si basa sull associazione ad un responsabile. Si consideri l esempio semplificato di un documento che rappresenta una patente di guida. Per ogni contenuto informativo è possibile determinare un organizzazione che detiene l informazione: per i dati anagrafici del titolare si risale al Comune di nascita, per i dati della residenza si risale al Comune di residenza, per la categoria di guida al Ministero dei Trasporti, per i punti al Ministero degli Interni, per i dati relativi alla scadenza si risale nuovamente alla Motorizzazione, e così via. Il procedimento tende quindi a strutturare rigidamente il documento, seguendo le regole organizzative e procedurali che hanno contribuito alla sua formazione o rilascio. Più un documento è finemente suddiviso nei suoi elementi, più ogni sua parte, se opportunamente indicizzata e classificata, risulta riutilizzabile per la costruzione e la produzione di nuova informazione. Al fine di quantificare la riusabilità dell informazione, risulta conveniente introdurre il concetto di granularità dei componenti. Tornando all esempio del documento patente, se i punti vengono azzerati come effetto di una serie di contravvenzioni, il documento perde di validità e

179 InterDataNet Information Model I nodi informativi possono venire automaticamente notificati degli avvisi ad una serie di soggetti. Da un punto di vista formale (non giuridico) si determina la creazione automatica di una nuova patente: se cambia una parte cambia l aggregato di tutte le parti. Il documento IDN è quindi una entità attiva, in quanto può evolvere e cambiare comportamento sulla base dello stato assunto ed dalle relazioni espresse all interno per effetto del versionamento. In IDN-IM le informazioni ottenute dal procedimento esaustivo di suddivisione dei contenuti informativi sono chiamate informazioni atomiche (definizione in 7.1.1: la suddivisione termina nel momento in cui si incorre in un informazione non ulteriormente (e ragionevolmente) frazionabile, come ad esempio il nome o il cognome di una persona. Ovviamente, questo procedimento necessita di raggiungere un compromesso tra la complessità, l effettiva necessità di riuso dei contenuti informativi e l adeguatezza della granularità della rappresentazione. Per tale motivo viene introdotto il concetto di informazione primitiva (definizione in 7.1.2). Non è necessario che la sorgente di informazione sia unica e unitaria; anzi, questa strutturazione trova maggior beneficio quanto più è possibile distinguere le organizzazioni (e sotto-organizzazioni) che trattano le singole informazioni, costituendo in modo naturale un sistema distribuito, dal punto di vista dello stesso documento. La dinamicità e la flessibilità sono ottenute grazie all elevato grado di autonomia delle singole sorgenti che, in modo collaborativo ed indiretto, partecipano alla determinazione di un documento capace di evolvere nel tempo, lasciando che ogni parte del documento sia soggetta a modifiche indipendenti. 7.1 I nodi informativi La struttura del documento in IDN-IM è rappresentata da un grafo diretto aciclico (Directed Acyclic Graph, in breve DAG)[Die05]. Il vincolo principale è che non sono permessi cicli, ossia sequenze di nodi attraversando le quali a partire da un nodo qualsiasi si finisce sullo stesso nodo. Si noti che una struttura ad albero è un caso specifico del DAG, in cui ciascun nodo ha al più un genitore: le strutture DAG sono perciò capaci di modellare tutte le risorse strutturate ad albero [Die05]. Questa proprietà rappresenta un vantaggio quando si passa dal modello informativo al modello dati. In IDN quindi le relazioni tra i nodi della struttura del documento sono gerarchiche, cioè esiste una relazione di tipo padre-figlio tale che il progenitore è sempre distinguibile dal suo discendente, a differenza del caso della presenza di cicli. L approccio IDN prevede che l informazione non sia memorizzata in un documento, ma collegata nel documento e tra documenti, per cui non è necessario che venga codificata fisicamente al suo interno. Si suppone che esistano tanti collegamenti tra i nodi del documento quante sono le informazioni che vi devono essere racchiuse. I nodi principali della struttura del documento sono detti informazioni primitive (Primitive Information Unit, in breve PIU); esse sono indirizzate da un alias. Un alias è un nome, non unico, assegnato ad un nodo: uno pseudonimo in grado di individuare l informazione (l argomento sarà introdotto in 7.4). 161

180 InterDataNet Information Model I nodi informativi Tra i possibili alias esiste comunque un nome preferenziale a cui è assegnato un ruolo persistente ovvero di invariabilità nel tempo. Le relazioni introdotte tra le PIU modellano gli aspetti strutturali, introducendo un ordinamento di tipo padre-figlio. Ciascuna informazione primitiva è costituita da almeno una sottoinformazione, infatti ogni nodo può essere genitore di una serie di nodi, che sono altre informazioni primitive, e può contenere una o più informazioni atomiche. Ogni nodo del grafo che non ha figli, perciò è detto foglia, contiene almeno un informazione atomica; viceversa, ogni nodo del grafo che non è una foglia aggrega almeno un informazione primitiva. L informazione atomica, che rappresenta l entità informativa più elementare, è definita come una coppia <nome,valore> ed è indivisibile. Perché sia significativa nello spazio dei documenti definiti da IDN-IM, ogni informazione atomica deve essere contenuta in una e soltanto una informazione primitiva Informazioni atomiche Come anticipato l informazione atomica (Atomic Information Unit, AIU) è una coppia <nome,valore>. I valori che vengono memorizzati sono soggetti a verifica sintattica e di ammissibilità. Ad esempio consideriamo l informazione atomica <CAP,50100> rappresentante il Codice di Avviamento Postale italiano per la città di Firenze. Il valore numerico riportato appartiene all elenco dei CAP stabiliti dalle Poste Italiane, invece il valore FI è sintatticamente scorretto oppure è sintatticamente corretto, ma inammissibile. Per il generico utente, che inserisce il dato, la parte nome della coppia <nome,valore> ha un certo peso semantico. Non è però conveniente affidare tali controlli unicamente alle capacità di un generico utente in quanto molti controlli (tutti quelli sintattici e parte di quelli semantici) possono essere automatizzati e affrontati da elaboratori elettronici con notevoli vantaggi in termini computazionali e di precisione. Visto che il modello non è una base di dati e non è dotato di algebra relazionale sembrerebbe impossibile stabilire se il requisito di accuratezza possa essere sempre soddisfatto. La risposta al problema consiste nell ipotizzare che tutte le informazioni atomiche e primitive siano create e messe a disposizione da un entità responsabile che ne garantisce l accuratezza. La definizione esatta del significato sarà poi demandata al responsabile di quella informazione. Per quanto riguarda le informazioni atomiche questo è ottenibile, senza perdere in generalità, tramite composizione entro informazioni primitive. In altre parole ogni informazione atomica è associata ad una e una sola informazione primitiva la quale permette di proiettare la coppia <nome,valore> nello spazio dei documenti IDN. Questo è conseguenza dal fatto che ogni istanza di una qualsiasi coppia <nome,valore> non è un informazione atomica, ma può divenire tale se viene inquadrata nell ambito dei documenti IDN e l incapsulamento di cui sopra ha la finalità di svolgere questa operazione. Un esempio che permette di chiarire questo tema è relativo al concetto di 162

181 InterDataNet Information Model I nodi informativi responsabilità dell informazione appena citato: parafrasando ciò che è stato introdotto in precedenza ogni informazione presente in un qualsiasi documento IDN deve avere un responsabile, ovvero l entità che ha autorità su di essa. In questo contesto è sufficiente considerare il responsabile come una proprietà, o attributo, dell informazione. In questi termini l incapsulamento della coppia <nome,valore> all interno di un informazione primitiva permette di farle ereditare il responsabile di quest ultima, rendendola quindi dotata dell attributo necessario per poter appartenere allo spazio delle informazioni definite in IDN. In questo modo il problema della gestione delle informazioni viene semplificato: da una parte viene ricondotto verso il gestore di quella informazione, il quale ha le nozioni sufficienti a stabilire le regole sintattiche e le condizioni a contorno; dall altra l utente consumatore ha il dovere di cercare i valori e non più l onere di acquisirli nuovamente. In questo modo si tende anche a realizzare il presupposto ai requisiti di unico inserimento dei dati nel sistema, pertinenza e non eccedenza. Comunque per non rendere troppo rigido il modello dovrà essere tenuta in considerazione anche la possibilità di: inserire i dati con strategie di autonomia a responsabilità diversificata; correggerli ed arricchirli in fasi successive ed indipendenti Informazioni primitive È stato anticipato che le informazioni primitive modellano gli aspetti strutturali sfruttando il principio di aggregazione fra nodi. Ogni nodo contenente un informazione primitiva può essere genitore di una serie di nodi contenenti altre informazioni primitive. L unico vincolo esistente è che nella struttura non siano presenti cicli (ovvero ogni informazione primitiva non può essere figlia, nipote, pronipote, etc. o antenata di se stessa). A seguito del concetto di composizione le informazioni atomiche non hanno un proprio indirizzo all interno dello spazio dei nomi, ma ereditano quello dell informazione primitiva che le compone. È analogo alle ancore dei documenti HTML: fissato l indirizzo univoco dell informazione primitiva è possibile specificare, tramite un parametro addizionale, qual è l informazione atomica di interesse. In questo modo risulta possibile indirizzare univocamente anche le informazioni atomiche. La tecnica di composizione di informazioni atomiche consente una ottimizzazione, in quanto permette di contenere l esplosione del numero di indirizzi univoci presenti nello spazio dei nomi persistenti, senza perdere in generalità: in questo modo infatti le informazioni atomiche non hanno un proprio indirizzo univoco. Questo aspetto porta anche un altro vantaggio: il numero di elementi distinti che costituiscono i documenti risulta molto minore rispetto a 163

182 InterDataNet Information Model Relazioni strutturali tra nodi quello che si avrebbe assegnando una propria identità (indirizzo PRI) alle informazioni atomiche, senza rinunciare ai vantaggi della suddivisione granulare dell informazione che la soluzione proposta offre. Riassumendo, ogni informazione primitiva è quindi genitore di altre informazioni primitive ed incapsula (contiene) al proprio interno un certo numero di informazioni atomiche. Si osservi come da questo caso generale si possano definire documenti, come casi particolari, introducendo ulteriori restrizioni. Ad esempio un vincolo che può essere introdotto riguarda la mutua esclusione fra l aggregazione e la composizione: in questi termini ogni informazione primitiva aggrega altre informazioni primitive senza comporre informazioni atomiche oppure compone informazioni atomiche senza aggregare informazioni primitive. Documenti strutturati secondo questa modalità hanno le informazioni atomiche esclusivamente nelle foglie. Inoltre tutte le foglie contengono necessariamente informazioni atomiche e pertanto esiste una perfetta corrispondenza fra le foglie e le informazioni atomiche e fra gli atri nodi e le informazioni primitive. L associazione al responsabili avviene a livello di informazione primitiva: il responsabile deve garantire la correttezza della struttura (legame logico tra le parti) e, per le informazioni atomiche incapsulate, la correttezza dei dati associati alle coppie <nome,valore>. Per esempio si faccia l ipotesi che la patente di guida (semplificata) contenga i seguenti elementi (figura 7.1): anagrafica; residenza; categoria guida; punti. La Motorizzazione Civile deve garantire la correttezza delle coppie <punti,valore1> e <categoria,valore2> ; inoltre deve garantire anche la corretta aggregazione delle informazioni di anagrafica e residenza. È l anagrafe comunale del comune di nascita a garantire la correttezza delle informazioni atomiche relative ai dati anagrafici. È il comune di residenza a gartantire la correttezza dell indirizzo. Da un punto di vista astratto è possibile considerare le informazioni primitive come il punto di accesso all informazione complessiva che si sviluppa da esse fino alle foglie, come rappresentato in figura 7.2-a. 7.2 Relazioni strutturali tra nodi In IDN-IM sono definiti tre principali tipi di collegamento: Collegamenti di aggregazione. Per esprimere le relazioni genitoriali tra i nodi del grafo, all interno dello stesso documento. Ad esempio, nella figura 7.2, l informazione primitiva A è genitore dell informazione primitiva B. Collegamenti di composizione. Per definire funzioni di contenimento tra informazioni primitive e informazioni atomiche. Ad esempio, nella figura 164

183 InterDataNet Information Model Relazioni strutturali tra nodi Patente di Bruce Shark categoria A punti 9 Residenza di Bruce Shark Dati biometrici di Bruce Shark Nazione Australia firma Bruce Shark Via Oceano foto Anagrafica di Bruce Shark nome Bruce cognome Shark data nascita 2003/11/14 luogo Australia Figura 7.1: Esempio di documento patente IDN 7.2, l informazione atomica <1,w> è contenuta nell informazione primitiva A. Collegamenti di riferimento. Per esprimere relazioni tra documenti diversi, e quindi tra grafi diversi. Questo tipo di collegamento è classificato come informazione atomica e perciò è trattato come una speciale coppia <nome,valore>, dove il valore è una URI. Azzardando un confronto tra documenti IDN e documenti HTML osserviamo una forte analogia tra i collegamenti di aggregazione ed gli iframe, i collegamenti di composizione e l ancora ed infine tra i collegamenti di riferimento ed i link esterni. Si definisce il documento IDN un insieme di nodi PIU (Primitive Information Unit), uno dei quali è detto radice, messi in relazione tra di loro attraverso collegamenti di aggregazione e riferimento[ppcp07]. Applicando la definizione in modo ricorsivo, ciascun documento può essere considerato come un aggregazione di documenti. 165

184 InterDataNet Information Model Relazioni strutturali tra nodi Contrariamente a quanto avviene per le aggregazioni tra informazioni primitive, il legame tra un informazione atomica e l informazione primitiva che la contiene è per definizione inscindibile. Documento IDN a A Informazione astratta associata ad A Albero associato b A B 1 C B 1 C 2 3 D 2 3 D D 4 x 5 y 4 x 5 y 4 x 5 y Informazione astratta associata a B nome valore Associata a D Informazione Primitiva Informazione Atomica Associata a C Legenda Aggregazione Incapsulamento Figura 7.2: Esempio di documento IDN Aggregazione e composizione sono funzioni mutuamente esclusive: l informazione atomica può essere soltanto contenuta nell informazione primitiva, mentre l informazione primitiva può essere soltanto aggregata in una o più informazioni primitive. Nella figura 7.2, l informazione primitiva D è aggregata sia dall informazione primitiva B che dall informazione primitiva C. L aggregazione non è sufficiente a determinare la consistenza delle informazioni aggregate, dove con consistenza si intende che l aggregazione è costituita da informazioni correttamente relazionate. Si considerino due informazioni primitive, A e B, costituite da due informazioni atomiche ciascuna. Ammesso che l informazione A e l informazione B siano di per sè consistenti, non è detto che l aggregazione rappresentata da A + B sia vera. L aggregazione è una condizione necessaria, ma non sufficiente per la costruzione di nuove informazioni consistenti; pertanto, il modello prevede che ogni informazione sia dotata di uno stato, che rappresenti la qualità e la veridicità del risultato dell aggregazione. In sintesi, in IDN un documento è composto da informazioni atomiche, che rappresentano il contenuto, e da informazioni primitive, che rappresentano le proprietà strutturali, cioè le relazioni tra i nodi, oltre alle caratteristiche del- 166

185 InterDataNet Information Model Strutturare con criteri di responsabilità l informazione definite nel modello stesso, come ad esempio l entità responsabile del contenuto. Il documento è strutturato perché risulta dall aggregazione di informazioni elementari, le informazioni primitive, le quali a loro volta sono composte dalle informazioni atomiche. Questa struttura, determinata mediante l applicazione del principio di responsabilità, consente di introdurre una misura della granularità e dei livelli di dettaglio dell informazione, in cui ciascuna parte è complessivamente individuabile indirizzando il nodo di interesse. 7.3 Strutturare con criteri di responsabilità La responsabilità è un criterio ortogonale per definire e strutturare l informazione a prescindere dal suo contenuto, basandosi sulla gerarchia delle organizzazioni 1. In contesti specifici, come ad esempio nella Pubblica Amministrazione, per ogni nodo deve essere definita un entità responsabile (individuabile anche grazie alle normative). In IDN-IM questo attore è una persona fisica o giuridica che si occupa di garantire l accuratezza dei dati, cioè la validità delle coppie <nome,valore> relative all informazione atomica contenuta nel nodo, e la correttezza della struttura, ovvero delle relazioni logiche tra i nodi [PPC + 08]. Si noti che l autore e il responsabile di un nodo sono entità separate, e che una coppia <nome,valore> contenuta in un informazione primitiva eredita il responsabile. Ogni informazione primitiva può contenere dati specifici da usare per verificare se l utente ha i diritti per eseguire una certa operazione, ad esempio l aggiornamento, su un certo nodo. I diritti di accesso ad un particolare nodo da parte degli utenti possono essere garantiti con approccio tipo ACL (Access Control List)[Tan94]. Al fine di gestire i concetti di responsabilità e di gestione dell accesso, IDN prevede la presenza dei gruppi, i quali aggregano uno o più utenti che condividono uno scopo comune. I gruppi sono organizzati in modo gerarchico, e ciascuno di essi ha specifici diritti di accesso sui documenti. Un utente può appartenere a più gruppi, ereditandone i diritti di accesso [PCPP07a]. 7.4 Identificazione dei nodi A livello del modello IDN-IM i nodi vengono identificati per convenzione tramite un nome canonico e zero, uno o più alias, tutti LRI. La convenzione prevede che quando il nodo viene creato gli venga assegnato un LRI invariabile nel tempo che dipende dal contesto nel quale il nodo viene creato. Inoltre gli utenti possono arbitrariamente assegnare ulteriori LRI secondo le loro necessità ai singoli nodi (gli alias). Infine, come introdotto nel paragrafo 7.2 i nodi fanno parte di documenti strutturati a DAG, quindi ad essi sono costruibili ulteriori LRI determinati dalla posizione assunta nella struttura. 1 È stato spostato il problema della strutturazione su un piano organizzativo 167

186 InterDataNet Information Model Storico dei documenti Per esprimere in modo più efficace questo concetto è possibile fare riferimento ad un esempio. Nella figura 7.3 sono mostrati due documenti IDN: Doc1 contiene quattro nodi e quattro collegamenti di aggregazione di nome 1, 2, 3, e 4, mentre Doc2 contiene tre nodi e due collegamenti di aggregazione, entrambi di nome 6. Inoltre, Doc1 contiene un collegamento di riferimento a Doc2 di nome 5. Doc1 0 Doc2 nome: path/0 2 1 nome: path/0/2 5 7 nome: path/0/5 6 nome: path/0/5/6 nome: path/0/1 4 nome: path/0/5/7 3 nomi: path/0/1/3 path/0/2/4 Figura 7.3: Esempio di relazioni tra documenti IDN-IM Nella figura 7.3, il nodo path/0/1/3 ha questo nome perché è un figlio del nodo path/0/1 attraverso il collegamento di nome 3. Per lo stesso motivo, ha anche il nome path/0/2/4 perché è raggiungibile anche dal nodo path/0/2 attraverso il collegamento di nome 4. In altre parole, ogni nome ha la seguente struttura [PPC + 08]: node_parent_name + / + link_name dove: node_parent_name è il nome del nodo genitore; + è l operatore di concatenazione tra stringhe; link_name è il nome del collegamento che mette in relazione il genitore con il nodo da indirizzare. Nella figura 7.3, se si considera il nodo path/0 come radice locale, i loro successori hanno i seguenti nomi: /1, /2, /1/3 e /2/4, per i nodi in Doc1; /5, /5/6, /5/7 per i nodi in Doc Storico dei documenti Ogni documento dispone di caratteristiche atte a memorizzare la sua evoluzione temporale, chiamata storico. Tale evoluzione, sebbene sia una caratteri- 168

187 InterDataNet Information Model Storico dei documenti stica globale del documento, viene mantenuta memorizzando l evoluzione delle singole informazioni che lo costituiscono (a livello di nodo). Le evoluzioni temporali delle singole informazioni (che si ricorda essere strutturate a DAG), pur essendo mantenute separate ed associate ad esse, non sono indipendenti: una modifica effettuata ad un informazione che si trova ad un livello più basso della gerarchia si ripercuote su tutti i suoi predecessori. Questo fa sì che lo storico della radice comprenda, seppur indirettamente, l evoluzione temporale di tutto il documento. Volendo recuperare una data versione 2, è previsto un meccanismo di navigazione nello storico che, partendo dalla radice ed attraversando i vari nodi del documento, permette di ricomporlo come richiesto. È utile evidenziare come il meccanismo, basandosi su un modello estensionale, permetta, a differenza di altri modelli di versioning, di ripercorrere lo storico del documento nel modo più naturale possibile per l utente: ogni versione del documento viene ricostruita correttamente sia per quel che riguarda i dati contenuti sia per quanto riguarda gli aspetti strutturali. Per descrivere i meccanismi di gestione dello storico è utile inizialmente fare riferimento ad un documento costituito da un unico nodo e, successivamente, estendere il concetto al caso più generale. Sotto l ipotesi che ogni nodo, una volta creato, sia una grandezza immutabile nel tempo l operazione di modifica dà vita ad un nuovo nodo. Si definisce versione un informazione primitiva ottenuta modificando il contenuto informativo di un nodo esistente. Anche la nascita di una nuova informazione rientra in questa definizione considerando che tale operazione può essere vista come la modifica dell informazione nulla. Viene definito uno stato UPDATE che viene associato ad ogni informazione per determinare se è necessario generare nuove versioni oppure effettuare sovrascritture. Il valore assunto dallo stato può essere frozen o changing rispettivamente. Le transizioni avvengono tramite le operazioni di freeze e melt, figura 7.4. UPDATE melt changing frozen freeze close [in hard] Figura 7.4: Stato Update delle informazioni È opportuno chiarire cosa si intende con modifica di un informazione al variare del tipo di essa: nel caso di informazione atomica si parla di cambiamento di uno o di entrambi i campi nome o valore ; 2 In questo caso con versione si intende una ben precisa configurazione del documento. 169

188 InterDataNet Information Model Storico dei documenti nel caso di informazione primitiva si parla di cambiamento di una o più delle relazioni di aggregazione che partono dall informazione in esame o dei metadati ad essa associati. Può essere utile specificare che per quanto riguarda i link di riferimento, siccome rientrano nella prima categoria, il nodo che contiene il link si considera modificato solo se cambia il valore stesso del link. Eventuali variazioni del nodo riferito dal link non determinano variazioni dello storico del documento che lo contiene. È possibile modificare solo e soltanto l ultimo nodo creato all interno dello storico e, nel caso in cui lo stato UPDATE sia frozen, quello che si genera è un insieme ordinato di revisioni. Viceversa per modificare un nodo che non sia l ultimo occorre creare una diramazione o branch (figura 7.5). L ordinamento delle versioni nella diramazione è totale, in quanto sull insieme è ben definita la relazione di revisione ( ) con le seguenti proprietà: 1. riflessiva: per ogni versione x appartenente ad una diramazione, si ha x x; 2. antisimmetrica: per ogni versione x, y appartenenti ad una stessa diramazione, tali che x y e y x, allora x y; 3. transitiva: per ogni versione x, y, z appartenenti ad una stessa diramazione, tali che x y e y z, allora x z; 4. confronto: per ogni versione x, y appartenenti ad una stessa diramazione, si ha x y oppure y x. La creazione di una nuova diramazione avviene su esplicita richiesta dell utente. Ad esempio consideriamo il ramo x al tempo t 0 in figura 7.5. La richiesta di nascita di una diramazione a partire dalla prima versione x.0 al tempo t 1 >t 0 comporta la creazione del ramo y contenente la nuova versione y.0. Al tempo t 2 >t 1 la modifica di x.1 viene applicata nello stesso ramo con la revisione x.2. Branch x (t 0 ) Branch x (t 1 > t 0 ) Branch x (t 2 > t 1 > t 0 ) x.0 x.1 x.0 x.1 x.0 x.1 x.2 Branch y (t 1 ) Branch y (t 2 ) y.0 y.0 Figura 7.5: Generazione delle revisioni Lo storico è interrogabile esprimendo esplicitamente la versione desiderata. Comunque è possibile estendere l interrogazione anche attraverso delle proposizioni logiche: ogni versione contiene al proprio interno dei riferimenti relativi alle versioni precedenti ed a quelle successive 170

189 InterDataNet Information Model Storico dei documenti Versioning IDN-IM modella più versioni associate ad un insieme di informazioni. Il controllo di versione, usato soprattutto nello sviluppo di progetti software per controllare l evoluzione dei documenti e per organizzare il lavoro quando le specifiche del progetto dipendono da un gruppo di persone, consiste principalmente nell assegnare ai documenti un numero o un etichetta di versione, in relazione allo stato che questi assumono in seguito alle modifiche. Il mantenimento delle versioni (revisioni), dell informazione e l automazione della generazione delle stesse garantiscono la massima tracciabilità, permettendo di ricostruire l evoluzione dell informazione nel tempo a fronte delle modifiche. In IDN ogni nodo del grafo è perciò versionato, in quanto rappresenta un istanza temporale dell entità concettuale dell informazione rappresentata. Le versioni delle informazioni primitive sono esse stesse informazioni primitive, infatti qualsiasi nodo del grafo viene definito all interno dello storico dell informazione ed è parte di esso. Si noti che questa definizione è ortogonale e indipendente dalla struttura logica dell informazione nel grafo. Ogni storico possiede un indirizzo logico attraverso il quale è possibile avviare l esplorazione della sua struttura interna. Esistono diversi modelli per la gestione del controllo di versione [Ask02]; in generale essi si differenziano in base allo schema adottato per numerare le revisioni. Le tecniche più recenti permettono operazioni di branch, per portare avanti in parallelo lo sviluppo di un progetto quando due o più parti si curano dell evolvere di aspetti diversi, e di merge, per ricongiungere il lavoro svolto dai diversi gruppi. IDN segue i principi del modello UEVM (Unified Extensional Versioning Model) [ABCM99], che organizza le versioni di documenti strutturati come DAG riuscendo a versionare sia i contenuti che gli aspetti strutturali, con tecniche automatizzate. Ogni nodo del grafo può dunque essere visto come l insieme di due gruppi di relazioni, una parte delle quali è relativa al versioning, mentre l altra è composta da relazioni di aggregazione. Di conseguenza, IDN-IM introduce una tipizzazione dei collegamenti tra nodi, la cui semantica determina, oltre al verso, anche quando e come possono o devono essere attraversati. Si introduce un nuovo tipo di collegamento strutturale ed interno che agisce su un piano diverso rispetto ai già enunciati collegamenti di aggregazione e composizione: collegamenti interni allo storico, che si specializzano in (accordo alla nomenclatura classica): revisioni (revision); diramazioni (branch); convergenze (merge). I collegamenti interni allo storico esplicitano le relazioni di ordinamento mediante. I collegamenti uscenti, in accordo al modello UEVM, possono consentire o bloccare la propagazione delle versioni a fronte della modifica dei contenuti informativi del nodo. 171

190 InterDataNet Information Model Storico dei documenti storico di A nome valore nome valore nome valore informazione primitiva storico di B nome valore nome valore informazione atomica aggregazione storico di C nome valore nome valore revisione Figura 7.6: Storico dell informazione in IDN-IM Nella figura 7.6 è schematizzato un esempio che rappresenta gli storici relativi alle informazioni A, B e C. Lo storico di A contiene 3 revisioni, e ognuna di esse, oltre a contenere due informazioni atomiche, aggrega sia la prima versione dell informazione B, sia una revisione presente nello storico di C La propagazione delle modifiche Le versioni sono correlate attraverso l aggregazione e possono concorrere a formare arbitrarie strutture: se mettiamo in evidenza solo le versioni e le relazioni di aggregazione che le connettono ciò che otteniamo è un grafo orientato. La nascita di una nuova revisione scatena un meccanismo di propagazione nel grafo attraverso i cammini che si sviluppano in senso opposto rispetto alla direzione degli archi relativi ai link di composizione che partono dall ultima revisione di ogni branch. Si può osservare che la propagazione all interno della struttura del documento corrente è un caso particolare, poiché in generale coinvolge tutti quei documenti che hanno dei sotto alberi in comune legati da link di composizione. I link di riferimento permettono di creare correlazioni fra dati come avviene per i link di composizione; la differenza sostanziale è che, nel caso dei link di riferimento, non si ha la propagazione delle versioni. Durante una sessione al massimo vengono create tante versioni quanti sono i nodi coinvolti. Ripetute operazioni su un nodo sono parte integrante della stessa attività. Ripetute aggiunte, cancellazioni, e cambiamenti dei figli di un nodo genereranno una ed una sola versione relativa a quel nodo. L estensione temporale di una sessione è sfruttata per controllare la granularità del versioning. I meccanismi menzionati riflettono a pieno quelli visti in UEVM, a cui deve essere fatto riferimento per ulteriori dettagli. 172

191 InterDataNet Information Model I collegamenti del modello 7.6 I collegamenti del modello In riferimento agli aspetti comportamentali delle risorse, discussi nelle precedenti sezioni, di seguito riassumiamo in maniera sistematica tutti i collegamenti (link) caratterizzanti il modello: link strutturali; di aggregazione PIU versionate (tra informazioni primitive); di composizione PIU (interni alle informazioni primitive); di riferimento (una aggregazione debole); di propagazione modifiche/versione (duale alla aggregazione); link di versioning (in avanti e indietro nel tempo); di revisione; di diramazione; di merge. 7.7 Lo stato di un documento Per definizione in IDN lo stato di un documento è un entità che serve a quantificare la qualità dell informazione che questo contiene. Così come avviene per il versioning anche per lo stato viene fatto riferimento ai singoli nodi: le informazioni atomiche hanno uno stato che dipende direttamente dalla qualità delle coppie <nome,valore>, mentre le informazioni primitive assumono un valore di stato che dipende dalle informazioni che aggregano ed incapsulano. Quindi, anche in questo caso, si prevede un meccanismo di propagazione dello stato che, a partire dai nodi in fondo alla gerarchia, risale gli antenati (dai figli verso i genitori) fino al capostipite assegnando, man mano, lo stato ai nodi attraversati Lo stato delle informazioni atomiche Un informazione atomica può essere soggetta a modifiche oppure può essere memorizzata in modo definitivo. Ortogonalmente esistono dei parametri per stabilire la qualità dell informazione. Lo stato QUALITY indica la qualità dei dati ed è rappresentato in figura 7.7 con il formalismo delle state chart. Un informazione atomica può essere una bozza (draft), ammissibile sintatticamente (allowable) oppure accurata sintatticamente (accurate). La transizione dello stato allowable avviene quando è verificato il controllo sintattico, se poi sono verificate anche le restrizioni lo stato passa in accurate. Con restrizioni si intendono tutte quelle regole che limitano il valore ad un intervallo o ad un particolare insieme di valori. 173

192 InterDataNet Information Model Lo stato di un documento QUALITY draft write-open [in changing] syntax check [verified] write-open [in changing] accurate soft allowable set set restriction check [verified] H allowable Figura 7.7: Stati di una informazione atomica Lo stato delle informazioni primitive Come mostrato in figura 7.8, il comportamento dell informazione primitiva è un AND di stati delle informazioni aggregate a cui se ne aggiungono ulteriori due, similmente definiti a quelli di un informazione atomica, ma propri di questa informazione. La definizione delle state chart è ricorsiva e la complessità dipende dal numero di livelli della gerarchia associata al documento. Condizione necessaria e non sufficiente affinché un informazione primitiva risulti consistente è che ogni informazione aggregata (o tutte atomiche o tutte primitive) sia singolarmente accurata. Per gli altri stati le seguenti condizioni sono anche sufficienti: 1. è nello stato di bozza (draft), se almeno un informazione aggregata è nello stato di bozza; 2. è nello stato di ammissibile (allowable), se nessuna informazione aggregata è nello stato di bozza ed almeno una nello stato di ammissibile; 3. è nello stato di accurata (accurate) sintatticamente, se ogni informazione aggregata è accurata sintatticamente. In tabella 7.1 sono riportate schematicamente le regole di transizione per determinare lo stato nel caso in cui l aggregazione sia di sole due informazioni. Per N informazioni basterà applicare tali regole iterativamente a coppie di informazioni disgiunte per N-1 volte. Per le informazioni primitive è possibile un ulteriore controllo che riguarda la verifica della consistenza. Questo permette di far transitare lo stato da accurate a consistency. Con controllo della consistenza si intende la verifica della coerenza logica e/o semantica tra le informazioni aggregate. Lo stato consistency indica quindi che 174

193 InterDataNet Information Model Lo stato di un documento draft write-open [this in changing] allowable syntax check info_1... info_n write-open [this in changing] write-open [this in changing] consistency accurate set restriction check H soft hard set Figura 7.8: Stati di un informazione primitiva l informazione complessiva, costituita da una serie di informazioni più semplici, è corretta nella sua globalità. Questa è un affermazione più forte rispetto al dichiarare che tutte le informazioni più semplici, prese singolarmente, sono corrette. Si consideri ad esempio una via ed un numero civico di un indirizzo: il nome della via può essere accurato così come il numero civico, però in quella via potrebbe non esistere quel numero. L obiettivo principale di un sistema distribuito è rendere semplice per gli utenti l accesso alle risorse remote e la condivisione delle stesse con altri utenti in modo controllato. Collegare gli utenti e le risorse rende più semplice la collaborazione e lo scambio delle informazioni, come dimostrato in modo esemplare dal successo di Internet e dei suoi protocolli per lo scambio di file, mail, documenti, audio e video [TvS01]. La connettività promossa da Internet ha portato a numerose organizzazioni virtuali, in cui gruppi di utenti largamente dispersi dal punto di vista geografico lavorano insieme. Questa connettività globale rafforza il bisogno di rendere le risorse riutilizzabili tra persone, comunità ed organizzazioni sparse in tutto il mondo, e allo stesso tempo propone il problema dell authoring collaborativo, inteso come l insieme dei processi finalizzati alla creazione di un informazione. 175

194 InterDataNet Information Model Authoring concorrente Info 2 Info 1 Draft Allowable Accurate Draft Draft Draft Draft Allowable Draft Allowable Allowable Accurate Draft Allowable Accurate Tabella 7.1: Mappa per la determinazione degli stati 7.8 Authoring concorrente Consideriamo un informazione primitiva sulla quale vengono effettuate operazioni di lettura e scrittura, intendendo con scrittura anche la modifica strutturale, cioè l aggiunta o l eliminazione di nodi. Le operazioni, pur essendo rivolte verso la radice, coinvolgono tutti quei nodi del documento sui quali l utente ha i diritti per operare. In questo paragrafo, per semplicità e senza perdere in generalità, si suppone che tutti gli utenti possano accedere alle informazioni in lettura e che solo il relativo responsabile possa effettuare modifiche. Ogni operazione avviene all interno di una sessione. Si può incorrere nella concorrenza delle operazioni per due motivi: 1. è richiesta una attività di authoring parallelo sullo stesso documento (figura 7.9.a); 2. due o più documenti, che aggregano una stessa informazione primitiva, vengono aperti in intervalli di tempo sovrapposti (figura 7.9.b). Concettualmente sono attività diverse, ma in questo contesto vengono trattate in modo indistinguibile. Dato che le sessioni di lettura sono non distruttive e quindi meno critiche, non richiedono complesse tecniche di gestione, a patto di tenere presente i requisiti di awareness e la percezione dell utente. Deve esistere un opportuno sistema di accodamento delle operazioni di lettura rispetto a quelle di scrittura. Il concetto di responsabilità sui nodi consente di limitare la propagazione dell apertura delle sessioni in scrittura all interno del DAG. Ad esempio in figura 7.9.b si possono verificare 3 situazioni: 1. nessuna delle richieste è effettuata dall autorità responsabile della terza informazione (info 3 ): nessuna sessione in scrittura è possibile sui nodi che hanno info 3 (compreso) come predecessore; 2. solo una richiesta proviene dal responsabile di info 3 : solo uno può modificare info 3 ; 3. entrambe le richieste provengono dal responsabile di info 3 : è una situazione effettivamente singolare, soprattutto alla luce sulle ipotesi fatte sull unicità del responsabile, ma può presentarsi. 176

195 InterDataNet Information Model Authoring concorrente (a) Req 1 Req 2 (b) Req 1 Req 2 Info1 Info1 Info2 Info3 Figura 7.9: Casi di authoring concorrente Alla luce di queste considerazioni è indispensabile definire uno o più meccanismi necessari al controllo e alla gestione delle sessioni Controllo delle sessioni Con questa prospettiva si individuano tre politiche di apertura di una sessione in scrittura: Strong. Soft. Relaxed. La Strong blocca sia in lettura che in scrittura tutti i nodi interessati dall apertura della sessione. Ad esempio, riconsiderando la figura 7.9.b, ed ammettendo che la prima richiesta accettata sia avvenuta su info 1 con modalità Strong, successive richieste di apertura di sessione per la modifica di info 1 o semplici richieste di accesso verrebbero rifiutate. La Soft invece blocca i nodi in scrittura senza inibire l accesso in sola lettura. Nell esempio precedente verrebbero rifiutate ulteriori richieste di apertura di sessione in scrittura su info 1, ma la possibilità di accedere all informazione verrebbe comunque garantita. Queste due tipologie di blocco permettono la gestione della politica di accesso concorrente turn-taking (un singolo individuo alla volta è abilitato ad apportare cambiamenti, gli altri di fatto non possono operare). Come dimostrato in vari contesti questa politica, anche se comporta alcuni inconvenienti, può risultare utile o addirittura necessaria per certe tipologie di documenti. Ad esempio si consideri un documento costituito da un unica immagine in formato Jpeg (queste considerazioni sono valide per la maggior parte dei documenti, se non tutti, costituiti da un file in formato binario). Il formato Jpeg è tale che ad una modifica localizzata dell immagine non corrisponda una 177

196 InterDataNet Information Model Authoring concorrente modifica equivalentemente localizzata nel file. In altre parole ogni modifica, indipendentemente dalla sua entità, può portare alla variazione di tutto il file. Ipotizzando quindi che due utenti modifichino l immagine in aree non sovrapposte (ad esempio in alto a destra e in basso a sinistra) non è possibile fondere i cambiamenti in un unica immagine analizzando soltanto i file modificati senza comprenderne la codifica (in questo caso si potrebbe ipotizzare che il sistema sia in grado di decodificare le immagini, sovrapporle ricercando eventuali conflitti e poi codificare nuovamente il risultato dell operazione, ma nella pratica ciò non è possibile per innumerevoli motivi e si potrebbero comunque trovare svariati esempi per i quali tale operazione non è possibile neanche a livello concettuale). Questo inconveniente impedisce, di fatto, di individuare e risolvere i conflitti: qualora due o più utenti modificassero contemporaneamente lo stesso documento, tutti perderebbero il lavoro svolto eccetto uno (l ultimo che salva, sovrascrivendo il documento esistente). L unico modo per aggirare questo ostacolo è quello di ricorrere ad un blocco esclusivo del file facendo uso dell approccio turn-taking. L introduzione di due politiche di lock, la prima sia in lettura che in scrittura la seconda solo in scrittura, risulta necessaria per garantire la massima flessibilità del modello del documento: come noto, negli ambienti concorrenti, possono verificarsi casi in cui, all interno della finestra temporale necessaria al completamento delle operazioni di modifica di un gruppo di dati, l accesso in lettura ad essi da parte di altri utenti potrebbe portare ad ottenere risultati inconsistenti. Per garantire che non si verifichino letture inconsistenti si ricorre alla politica Strong. Quest ultima è estremamente conservativa e se è possibile non inibire l accesso in lettura in presenza di modifiche che richiedono l acquisizione esclusiva della risorsa (sia perché si riesce a garantire la consistenza dei dati letti in modo diverso oppure perché è possibile ritenere accettabile una certa probabilità di errore) si ricorre alla politica Soft che risulta essere meno conservativa e vincolante. Infine la Relaxed consente l authoring concorrente tramite l approccio copymerge: ogni soggetto ha a disposizione una copia di sulla quale operare poi ad intervalli regolari le modifihe vengono fuse. Occorre specificare che, in questo caso, si ha un conflitto qualora due o più utenti modifichino lo stesso nodo, indipendentemente dall entità della modifica. Nell esempio precedente, riferito ai file Jpeg, è stato illustrato come non sia sempre possibile individuare e risolvere i conflitti per certe tipologie di informazioni rappresentate da un unico file (e quindi che normalmente verranno codificate in un unico nodo IDN). Questo non esclude che per altre categorie di informazioni codificate all interno di un unico nodo IDN sia possibile determinare algoritmi in grado di analizzarne e comprenderne il contenuto ed agire di conseguenza per quanto riguarda la rilevazione e la gestione dei conflitti. Un esempio che può essere citato riguarda l authoring di codice sorgente: in questo caso si può modellare l ambiente inserendo il contenuto di ogni file sorgente appartenente al progetto all interno di un informazione atomica. In questo caso è abbastanza semplice comprendere come sia possibile analizzare il contenuto dell informazione atomica per stabilire se due utenti hanno modificato le medesime porzioni di codice oppure porzioni diverse in modo da applicare le politiche 178

197 InterDataNet Information Model Authoring concorrente di gestione dei conflitti in modo equivalente agli SCM (Software Configuration Management) [App08]. La modalità Relaxed è più adatta ad essere usata in contesti nei quali l accesso e la modifica dei dati avvengono da parte di più individui e pertanto, escludendo i casi particolari che devono essere gestiti ricorrendo alle politiche precedenti, è quella da utilizzarsi preferibilmente. In ogni modo ricorrere alla tipologia sessione Relaxed nelle richieste di scrittura, incrementa la consapevolezza ad alto livello in quanto permette all utente di prendere atto del fatto che il documento (o parte di esso) è in fase di aggiornamento. In realtà, come anticipato all inizio del paragrafo, il concetto di responsabilità fa sì che non tutti gli utenti possano modificare indiscriminatamente i documenti (o parti di essi) conseguentemente si ha una combinazione di modelli: splitcombine associato a turn-taking oppure a copy-merge. 179

198 Capitolo 8 InterDataNet Service Architecture Nel precedente capitolo è stato presentato il modello dell informazione IDN- IM mettendo in evidenza la rappresentazione delle risorse informative da un punto di vista teorico ed astratto. Dalla definizione di IDN-IM è necessario adesso determinare i servizi necessari per implementare tale modello. In questo capitolo sarà discussa l architettura a servizi di IDN come l insieme dei servizi necessari per qualificare operativamente IDN-IM. Questa vista del sistema prende il nome di InterDataNet Service Architecture (IDN-SA). IDN-SA si pone l obiettivo di descrivere l insieme di servizi ritenuti necessari per andare a gestire operativamente l Information Model condiviso e porre quindi fondare un architettura di riferimento in grado di offrire una soluzione a livello infrastrutturale al problema della condivisione collaborativa efficace ed efficiente dell informazione e concretamente dei dati. Le relazioni esistenti tra IDN-IM e IDN-SA sono schematicamente espresse in figura 8.1. A livello applicativo, le applicazioni devono essere in grado di accettare ed interpretare documenti IDN nello lo specifico contesto applicativo (es. fatture, moduli, testi, multimedia, ecc.). Sfruttando Application Programming Interface (API) viene agevolata l implementanzione e mascherata la complessità dell infrastruttura distribuita sottostante (costituita dai servizi IDN). I servizi sono organizzati ed ordinati in livelli. La stratificazione sarà applicata in modo da lasciare maggiore libertà implementativa agli estremi della pila: a livello più basso per abilitare e rendere flessibile l integrazione con tecnologie esistenti (tra cui legacy) ed a livello più elevato per consentire lo sviluppo di applicazioni specializzate (in analogia al livello applicativo della pila Internet) in un contesto informativo.

199 InterDataNet Service Architecture 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 8.1: Relazione tra IDN-IM e IDN-SA Sotto il livello applicativo il sistema deve essere ben orchestrato (capitolo 1) in quanto l applicazione stessa deve vedere un unico punto di accesso logico al quale interfacciarsi all architettura, indipendentemente dalla quanità e complessità dei servizi sottostanti. La stratificazione apporta considerevoli vantaggi per quanto riguarda la coreografia (capitolo 1) in quanto, imponendo dei rigidi vincoli operativi consente di ridurre il numero delle possibili interazioni fra i vari servizi che costituiscono l architettura, limitandone l esplosione della complessità. Sebbene IDN-SA ponga l attenzione sui servizi e su come essi interagiscono è importante chiarire che IDN-SA elabora risorse. IDN-SA rispetta sia i principi ispirati da SOA (capitolo 1) che da REST (capitolo 1). È opportuno sottolineare nuovamente che la definizione di SOA recepita da IDN riguarda i principi generali come evidenziati in [Jos07]. Ogni livello di IDN-SA caratterizza il comportamento delle risorse attraverso: aggregazione e indirizzamento logico ed unitaro, storicizzazione e permanente indicizzazione, replicazione e indirizzamento uniforme, memorizzazione fisica ed accesso. I servizi relativi a comportamenti fisici delle risorse sono posizionati a livello più basso e mentre i comportamenti astratti e logici (risalendo la gerarchia) sono collocati ad alto livello. In figura 8.2 è riportata la pila dei servizi: IDN-SA si compone di quattro livelli di servizi (core levels): Virtual Repository Service Layer, Information History Service Layer, Replica Managenent Service Layer e Storage Interface Service Layer. Agli estremi abbiamo tecnologie e contesti che sebbene esulino dalla specifica trattazione di IDN-SA rappresentano dei vincoli. Ciascun livello di servizi sarà di seguito introdotto e maggiori dettagli tecnici saranno evidenziati nella Parte IV. Un ultima importante osservazione sull architettura di servizi riguarda la definizione dei servizi di indirizzamento e lo schema sintattico degli indirizzi 181

200 InterDataNet Middleware InterDataNet Middleware InterDataNet Service Architecture IDN Compliant Application Virtual Repository Layer Information History Layer Replica Management Layer Storage Interface Layer Filesystem, database, etc. Generic storage architecture IDN APIs HTTP(S), SMTP(S), FTP(S), etc. Generic network communication architecture Figura 8.2: Interdataworking in IDN (handle) per le risorse. In IDN-SA il sistema di indirizzamento assume un ruolo strutturalmente portante e permeante: infatti ogni livello specializza il modo di nominare, individuare ed accedere alle risorse (dato che ad ogni livello abbiamo rappresentazioni diverse con viste diverse, analogamente ai livelli della pila Internet). L applicazione della metodologia della separazione dei compiti rendere però possibile l estrazione dei sotto-servizi dedicati ai nomi: dalla stratificazione precedentemente presentata è possibile costruire una stratificazione omologa, unicamente fondata sullo spazio di nomi, che prende il nome di IDN Naming Service. In figura 8.3 è riportata la corrispondenza tra livelli di servizi e gli associati spazi di identificatori. Sebbene nel presente capitolo il Naming Service venga trattato in modo integrato e contestuale, livello per livello, per le motivazioni evidenziate e per la complessità del sistema, risulta caratterizzante una trattazione dedicata, come argomentato nel capitolo 9. Virtual Repository Layer Information History Layer Replica Management Layer Storage Interface Layer Filesystem, database, etc. Generic storage architecture Service Layers IDN Compliant Application IDN APIs HTTP(S), SMTP(S), FTP(S), etc. Generic network communication architecture Resource Space Names IDN-IM names [+v.p.] LRIs [+v.p.] PRIs [+v.p.] PRIs URLs Platform dependent local names [+v.p.] optional version parameter Figura 8.3: Resource Space Names 182

201 InterDataNet Service Architecture Virtual Repository Service 8.1 Virtual Repository Service Il principale servizio offerto dal Virtual Repository Service (VR) è l indirizzamento delle risorse per consentirne la navigazione nello spazio delle informazioni. Attraverso la sua interfaccia è possibile indirizzare ed individuare le risorse disponibili. Una volta individuata la risorsa, questa viene analizzata ed elaborata in maniera completamente trasparente al richiedente. L elaborazione consiste principalmente nel recuperare tutte le sottoinformazioni (Primitive Information Unit, PIU) di cui è composta. Eventualmente viene anche applicata una codifica di presentazione, subito prima di essere erogata. Dato che una risorsa è il risultato della aggregazione di informazioni primitive (PIU), collegate da link, il VR dovrà essere in grado di costruire il documento seguendo i collegamenti esplicitati nel nodo. Una volta che il documento è stato costruito, dovrà essere fornito all applicazione che lo ha richiesto. L applicazione si occuperà di presentare correttamente e coerentemente la risorsa all utente. All interno di VR si individuano i seguenti sottoservizi paritari: aggregazione di Primitive Information Unit (Resource Aggregation Service, RAS); risoluzione di nomi logici e alias (Logical Domain Name Service, LDNS); controllo delle identità (Identity Service, IS). L attività complessiva è quella di fornire una rappresentazione a deposito di uno spazio di informazioni indirizzabili. Qualificare il repository come virtuale è conseguenza di due fatti: l informazione non è concretamente ed unitariamente mantenute e localizzata; il nome delle risorse è assegnabile seguendo percorsi logici personalizzabili. A questo livello appartengono le entità virtuali discusse nel capitolo 5. Ciascuna entità non è altro che una risorsa che dovrà essere elaborata dalla logica interna di VR prima di erogare il servizio richiesto Resource Aggregation Service Per esporre operativamente il compito di RAS ipotizziamo che un utente tramite la propria identità Persona indirizzi una Resource per visualizzarla. A RAS dovrà pervenire il consenso se la Persona lo può fare o con quali limiti. I controlli sulla identità sono a carico di IS. Accertato che Persona risponda ai requisiti richiesti, RAS inizia a recuperare tutti i nodi (PIU) del documento, scendendo in pronfondità nella struttura DAG. Se necessario richiede ulteriori verifiche ad IS. Una volta che RAS ha terminato di recuperare le informazioni è in grado di costruire materialmente una istanza entro-contenuta in un macro-documento aggregato. Non spetta a RAS interpretare il documento così costruito in quanto non possiede una specifica intelligenza applicativa. 183

202 InterDataNet Service Architecture Virtual Repository Service Per effettuare la corretta selezione delle versioni dei nodi, esplorando in profondità il DAG, RAS si avvale dei servizi offerti dal livello sottostante Information History Service (IH). Le modalità con cui RAS verifica se la Persona soddisfa requisiti richiesti per l accesso sono determinati dal principio di responsabile dell informazione. Il responsabile oltre a stabilire la validità e la veridicità di una informazione indica anche le regole con cui può essere acceduta e quindi le politiche di accesso in lettura e scrittura. Non è compito di RAS operare direttamente sulle versioni della risorsa, ma sarà comunque onere di questo livello richiedere al livello sottostante i servizi necessari per gestirle e relazionarle correttamente nel tempo. In maniera del tutto duale alle aggregazione il servizio RAS si occupa della propagazione delle versioni, introdotta nel capitolo 7 percorrendo i link strutturali di propagazione (delle modifiche), che concettualmente equivale a percorrere i link di aggregazione in senso contrario. 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 8.4: Revisioni successive di documenti UEVM In figura 8.4 è esemplificato quello che succede dopo una modifica di una risorsa: il nodo figlio E viene modificato e quindi verrà creata una 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. Ricordando che IDN fa riferimento quasi integralmente al modello UEVM (Unified Extensional Versioning Model) [ABCM99] per definire il controllo di versione. UEVM stabilisce che le versioni di documenti strutturati siano alberi (Direct Acyclic Graph), ma è stato esteso per essere applicato a DAG, ovvero grafi in cui si hanno archi orientati e non esistono cicli. L orientamento del collegamento tra due risorse stabilisce una relazione di padre e figlio tra di esse. 184

203 InterDataNet Service Architecture Virtual Repository Service IH possiede così la proprietà di riuscire a versionare sia l evoluzione dei contenuti che degli aspetti strutturali. È proprio questo l aspetto interessante di UEVM: permette alla sua applicazione di tenere traccia non soltanto dello storico delle singole risorse, ma anche la struttura che queste hanno assunto nel tempo Logical Domain Name Service Una medesima risorsa può essere nominata in modo diverso e collocata in contesti diversi pur mantenendosi invariabile da un punto di vista di contenuti. Ciò è realizzato assegnando a ciascuna risorsa un nome logico canonico a cui vengono aggiunti ulteriori alias, tramite il Logical Domain Name Sevice (LDNS). LDNS è sotto-servizio integrato nel livello. LDNS è in grado di determinare, attuando una risoluzione, l identificativo canonico e l identificativo e persistente avvalendosi, a partire da un qualsiasi alias. LDNS è un servizio distribuito e come tale utilizza, quando necessario, uno o più istanze di servizi per la risoluzione di un Logical Resoirce Identifier. LDNS è costituito da un vasto database di nomi distribuito, detti Logical Resource Identifier (LRI). Un LRI sintatticamente può possedere un parametro di versione per indicare quale istanza temporale deve essere selezionata. I Logical Resource Identifier sono stati introdotti per identificare all interno dell ambiente virtuale le entità logiche. Il suo formato è stato definito in modo tale da essere mnemonico, facilmente usabile e trascrivibile dall utente, riconducibile ad un contesto e completamente indipendente dalla locazione fisica delle risorse. LDNS si occupa di risolvere LRI in un identificatore invariabile nel tempo, unico e non riusabile chiamato IDN Persistent Resource Identifier (PRI) a cui viene giustapposto il parametro di versione. Per una discussione più approfondita si rimanda al capitolo Identity Service Tutti i sistemi collaborativi necessitano di un sottosistema per le gestione delle identità sopratutto quando l oggetto delle elaborazioni è costituito da risorse condivise. Quindi il layer VR assicura che: l identificazione dell utente avvenga contestualmente alla sua proiezione nel sistema, ovvero tramite la sua identità Persona; il responsabile abbia stabilito quali Persona sono autorizzati ad accedere in lettura e/o in scrittura ad una data informazione; ogni azione effettuata sulle risorse sia associata ad una Persona (eventualmente anonima). Il controllo di accesso in lettura e/o in scrittura non è effettuato esclusivamente a livello VR, ma è a questo livello in cui si ha vanno ad istanziare le entità Persona e le risorse su cui esse agiscono. Inoltre, essendo il livello più 185

204 InterDataNet Service Architecture Information History Service elevato della pila ed il punto logico di accesso al sistema, rappresenta il servizio più esposto e critico. 8.2 Information History Service Nello strato di Information History (IH) troviamo un il servizio che ha il compito del controllo di versione e di erogare il servizio di navigazione nello spazio delle versioni. Il servizio principale dà il nome al livello. Si comporta come un filtro che intercetta le operazioni che modificano le risorse, ne controlla il numero di versione e tiene traccia delle revisioni, diramazioni e merge, come nelle diffuse tecniche di versioning. Grazie ad IH è possibile richiedere una risorsa come istanza storica, in uno dei suoi stati assunti, dalla sua creazione fino al tempo attuale attuale. Come si è visto nel capitolo 7 i dati in IDN sono collegati strutturalmente con due principali tipologie di relazione: link di riferimento e link di aggregazione, ma anche storicamente. Qui si introduce l ulteriore tipologia di link, propria di questo livello: link di versioning. Per rendere possibile lo spostamento nel passato e nel futuro a partire da una data istanza, i link di versioning posso assumere due direzioni: up e down. Il documento da versionare è visto quindi come una istantanea di risorse e di relazioni di composizione che le legano. Due documenti distinti possono essere collegati soltanto da link di riferimento, come previsto in IDN-IM. Ogni risorsa di questo livello è dotata di un identificatore costituito da una parte persistente, chiamata Persistent Resource Identifier (PRI), ed un parametro di versione (PARVER) sintatticamente giustapposto (indicato opzionalmente dal livello soprastante VR). Un PRI individua in maniera univoca ed immutabile una informazione: una volta assegnato o comunque utilizzato non viene più riusato. Il sottoservizio interno al livello che rende possibile la navigazione all interno di uno storico è detto IDN Version Traversing Service (VTS). Si tratta propriamente di un algoritmo non distribuito che iterativamente scorre in avanti (up) o indietro (down) la catena delle versioni in accordo al parametro di versione indicato Version Traversing Algorithm Il livello VR, grazie alla risoluzione di LDNS, chiede al livello IH una risorsa individuata con PRI+PARVER. VTA è in grado di spostare l handle dalla versione indicata da PRI ad una diversa sulla base del parametro di versione. Il meccanismo è tutto localizzato su una istanza di servizio, diversamente da quanto avviene per LDNS distribuito. In maniera iterativa scorre la storia (storico) della informazione seguendo i link di versioning in avanti oppure indietro. Una volta determinato il PRI alla versione desiderata IH necessita di ottenere i contenuti informativi (per il momento l elaborazione è limitata al solo identificatore). Notiamo comunque che durante le interazioni è necessario leggere i metadati relativi ai link di versione del nodo correntemente selezionato contestualmente alla verifica dei diritti di accesso. 186

205 InterDataNet Service Architecture Replica Management Service A tutti gli effetti VTA effettua una trasformazione da PRI+PARVER in un PRI. Questo identificatore viene utilizzato per chiedere al livello sottostante i contenuti informativi ed eventuali metadati. 8.3 Replica Management Service Il livello Replica Management è specializzato nella gestione delle repliche delle informazioni. Replicare una informazione significa copiarla in differenti apparati e mantenere tali copie equivalenti nel tempo (a meno della latenza). Le singole repliche delle informazioni, che come insieme sono identificate attraverso un PRI, sono singolarmente indirizzate ed accedute tramite URL [BLMM94]. L uso delle URL è determinato dal fatto che la logica dello strato ha bisogno di accedere fisicamente alla risorsa. Replica Management Service eroga il servizio di valorizzazione della risorsa logica: viene ricercata e acquisita (eventualmente convertita nella codifica IDN) una istanza nell insieme di repliche disponibili. La selezione della replica avviene nella maniera migliore : sulla base delle politiche di replicazione adottate e qualità del servizio (QoS) prevista. Il secondo servizio presente nel layer VR è Localization Service (LS), il servizio di risoluzione che permette di ottenere l elenco delle URL (identificatori di basso livello) dato un PRI. Il principale compito di questo livello è principalmente la sincronizzazione delle repliche ed il mantenimento della loro consistenza nel tempo. RM decide il sito da cui prelevare o su cui scrivere le informazioni in base all URL della replica, realizzando una sorta di instradamento delle richieste provenienti dall alto. Gli obiettivi del servizio di gestione delle repliche sono riassumibili nei seguenti punti: aumentare la disponibilità delle risorse; aumentare la velocità di risposta; aumentare la tolleranza ai guasti. Per quanto riguarda gli accessi non distruttivi (di sola lettura), la gestione mira a distribuire le richieste verso le repliche in modo da ridurre i singoli carichi di elaborazione, che altrimenti sarebbero concentrati verso un esiguo gruppo di host 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 interna al livello dei servizi, il livello RM ha come protagonista il servizio stesso di Replica Management che interagisce con LS, con altri RM, con il livello sottostante di Storage Interface ed il livello soprastante di Information History. 187

206 InterDataNet Service Architecture Storage Interface Service 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 8.5: Coreografia al livello di Replica Management I legami tra i servizi sono illustrati in figura 8.5. La sequenza tipica dei messaggi si svolge in questo modo: 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; 4. RM richiede la risorsa alla istanza di servizio di storage corrispondente; 5. un messaggio di risposta viene inviato al livello superiore contenente le informazioni inizialmente richieste Localization Service Il Localization Service (LS) è un servizio distribuito analogo ad LDNS che a fronte di una richiesta di risoluzione di un PRI fornisce l elenco ordinato di risorse fisicamente accessibili (URL). Per una discussione più approfondita si rimanda al capitolo Storage Interface Service Il livello più basso di IDN è detto Storage Interface in quanto si occupa di definire l interfaccia verso i sotto-sistemi di storage esistenti. Il servizio permette quindi di memorizzare e gestire risorse sulle piattaforme sottostanti (anche eterogenee), esponendo verso il livello superiore un interfaccia uniforme, indipendentemente dalle particolarità tecnologiche mascherate. Dal punto di vista dell architettura, l accesso fisico alle risorse è effettuato a questo livello. Le risorse possono essere memorizzate su filesystem, database locali o remoti oppure generate dinamicamente da una qualunque sorgente. L interfaccia prevede indirizzamento tramite URL, tipologia di indirizzi che sono stati introdotti proprio con la finalità di identificare ed accedere entità di 188

207 InterDataNet Service Architecture Storage Interface Service livello applicativo Internet. Ogni risorsa avrà quindi un proprio URL che la identifica e ne permette l accesso. È necessaria la precisazione sul concetto stesso di risorsa : a questo livello le risorse sono definite come un insieme strutturato di dati e metadati (identificati tramite un unico URL). L uso più naturale che ne può essere fatto è quello di andare a memorizzare repliche di risorse (logiche) definite al livello superiore RM. In realtà la rappresentazione delle risorse di questo livello è del tutto generale, nel senso che rappresentano unità informative indipendentemente dal modello di InterDataNet. L interfaccia uniforme esposta da SI non può prescindere dai concetti di URL, dati e metadati e si sviluppa intorno alle operazioni base CRUD: creazione: operazione che va a sancire la nascita di una nuova risorsa, eventualmente vuota, grazie alla allocazione di spazio (fisico o logico) necessario per la memorizzazione, fornendo al livello superiore l handle per accederci; modifica: operazione che consente di aggiornare il contenuto di una risorsa già esistente; lettura: operazione che permette di ottenere il contenuto della risorsa; cancellazione: operazione che va ad eliminare una risorsa già esistente, liberando handle e spazio. Focalizzando l attenzione sui dati e dei metadati, notiamo che il livello offre un arbitraria granularità di memorizzazione ed indirizzamento Integrazione di sistemi legacy Come introdotto nel sotto paragrafo precedente, uno degli scopi di SI è quello di esporre risorse ai livelli superiori tramite un interfaccia uniforme. 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 8.6: Storage Interface e Legacy Storage Interface Realizzando una applicazione che espone tale API significa implementare un servizio di storage per IDN. Le proprietà definite dalle specifiche dell interfaccia 189

208 InterDataNet Service Architecture Storage Interface Service fanno sì che su tale applicazione si possa montare lo stack dei livelli superiori permettendo quindi, come anticipato, di andare ad utilizzare una moltitudine eterogenea di soluzioni per lo storage fisico. In figura 8.6 si può vedere una esemplificazione, dove gli strati superiori di IDN pongono le loro basi su una varietà di differenti servizi di storage, implementati con tecnologie diverse. Questo aspetto è di particolare importanza principalmente perché: la realizzazione di istanze specializzate di Storage Interface Service permette alle organizzazioni interessate di integrare i loro sistemi in IDN (es. legacy); aprire l integrazione alle nuove soluzioni per lo storage. 190

209 Parte IV InterDataNet: servizi e sottosistemi

210 Capitolo 9 IDN Naming Service Allo stato attuale, le risorse nel Web vengono indirizzate attraverso gli Uniform Resource Identifier (URI)[BLFM98]. La tipologia più diffusa ed utilizzata di URI è certamente l Uniform Resource Locator (URL) [BLMM94], che può essere utilizzata sia per identificare la risorsa che per accedere alla stessa mediante un determinato protocollo (espresso nello schema sintattico della stessa URL). Si precisa che lo schema dei nomi è un insieme di regole per la creazione ed assegnazione di URN univoci, che siano conformi ad una specifica sintassi; viceversa un sistema di risoluzione è un servizio, accessibile attraverso la rete, che conserva gli URN e li risolve in uno o più URL ad essi corrispondenti. Questa duplice natura degli URL comporta una serie di problemi. Innanzi tutto una soluzione basata sui soli URL risulta poco scalabile poichè l identificazione di una risorsa e il suo indirizzamento rispondono a requisiti diversi. In secondo luogo una tale soluzione risulta poco robusta nel caso in cui una risorsa cambi locazione all interno della rete oppure venga sostituita da un altra risorsa avente un contenuto completamente differente. Inoltre un sistema basato sui soli URL non consentirebbe di disporre di una tipologia d indirizzamento adeguata a gestire insiemi di repliche eventualmente associate ad una risorsa logica. A titolo di esempio si consideri il caso tipico in cui una pagina Web debba essere replicata al fine di aumentarne la disponibilità in rete: una soluzione in cui ad ogni replica viene assegnato un proprio URL non sarebbe sufficiente. Infatti essa non consentirebbe di nascondere l insieme di repliche alle applicazioni client, per lo sviluppo delle quali sarebbe desiderabile avere l impressione di interagire con una singola entità non replicata. In sintesi un URL consente: indirizzamento;

211 IDN Naming Service accesso. con lo svantaggio di essere vincolato a: schema sintattico; locazione fisica. Allo scopo di risolvere tali problematiche è stata introdotta un ulteriore tipologia di identificatori: l Uniform Resource Name (URN) [Mea02, SM94, ADD + 96, LPD98]. Un URN è un particolare tipo di URI che, a differenza degli URL, pur identificando una risorsa, non fornisce alcun mezzo per accedervi. Infatti un URN non contiene informazioni variabili nel tempo, come ad esempio la locazione della risorsa, ma costituisce un identificatore persistente ed univoco delle risorse presenti nel Web. In ambito editoriale un valido esempio di URN è il codice ISBN (International Standard Book Number), che viene univocamente assegnato a ciascuna edizione di ogni materiale stampato coperto da diritti d autore (attuando una astrazione). Affinchè una risorsa identificata da un URN sia effettivamente accessibile, è necessario che a partire da esso sia possibile determinare almeno un identificatore che consenta l accesso alla risorsa, ossia un URL. Il processo di determinazione degli URL di una risorsa a partire dal suo URN è detto risoluzione (analogamente al processo che determina IP da URI). L impiego combinato di URN e URL, separando le funzioni di indirizzamento ed identificazione delle risorse in due passi distinti, permette di risolvere il problema dell indirizzamento di una risorsa Web, nel suo insieme di repliche. A tal proposito l idea di fondo consiste nell utilizzare un URN, per identificare l intero insieme delle repliche di una risorsa, e più URL per identificare le locazioni in cui le varie repliche sono memorizzate. Inoltre data la natura degli identificativi persistenti e globalmente unici, gli URN permettono di spostare le risorse all interno del Web senza che tali movimenti impediscano ad un utente di accedere ad una determinata risorsa (ovviamente a patto che i corrispondenti dati della risoluzione vengano aggiornati in modo coerente alla nuova locazione della risorsa). Pur contribuendo alla soluzione delle suddette problematiche, gli URN non soddisfano i canoni di utilizzo richiesti da un utenza umana: a differenza di un calcolatore, necessita di nomi facilmente intellegibili e condivisibili per indicare concetti e contenuti. Utilizzare un directory service, come ad esempio LDAP [HM02], permetta agli utenti di ricercare la risorsa in base al valore degli attributi ad essa assegnati. In particolare si ricorda che il servizio fornito da LDAP si basa su un paradigma di tipo client-server in cui ad una richiesta effettuata dal client, il server risponde con la risorsa desiderata oppure con l indirizzo di un altro server cui girare la richiesta. In figura 9.1 è esemplificata la tipica struttura di una directory LDAP, in cui sono memorizzate alcune informazioni relative ad un organizzazione. Il principale svantaggio di questa soluzione risiede nella limitata scalabilità, esplicata dal fatto che non sono ancora stati sviluppati directory service su larga scala. Il secondo approccio, come suggerito in [Mea02], prevede l introduzione di una nuova tipologia di URI che abbiano la duplice caratteristica di essere di facile 193

212 IDN Naming Service dc=net dc=com dc=de Organizzazione dc=acme Unità organizzativa Persona ou=people ou=servers ou=john Doe Figura 9.1: Albero di directory LDAP utilizzo per l uomo e in grado di interagire con gli URN al fine di identificare le risorse. Questi identificativi di alto livello vengono tipicamente indicati come Human Friendly Name (HFN) proprio per evidenziare come essi siano stati pensati per essere a misura d uomo. Infatti a differenza degli URN, gli HFN consentono l uso esplicito di nomi descrittivi. Nel momento in cui un utente vuole accedere ad una risorsa, un HFN deve poter essere risolto in un URL. A causa dei problemi di gestione delle repliche introdotti dagli URL, non è possibile realizzare questo servizio di traduzione in maniera diretta, ma occorre suddividerlo in due fasi: nella prima si risolve l HFN in URN, mentre nella seconda l URN in URL. In sintesi si utilizza un sistema di nomi composto da tre livelli (HFN, URN ed URL), in cui un HFN è collegato ad un URN che, a sua volta viene collegato ad un opportuno URL. Quest ultimo approccio presenta molti vantaggi. In primo luogo gli utenti possono assegnare alle risorse nomi di convenienza, ovviamente rimanendo entro i limiti di ordine tecnico e tecnologico imposti dal sistema. Inoltre se una risorsa viene replicata o spostata in un altra locazione, questo non produce effetti sull HFN. Infine un utente può scegliere di utilizzare nomi diversi per la stessa risorsa, allo stesso modo con cui vengono usati gli alias negli indirizzi di posta elettronica o nei link simbolici del file system. Nel suo complesso il meccanismo di risoluzione da HFN ad URL deve essere in grado di supportare un enorme numero di risorse, eventualmente distribuite su una vasta area geografica. Il modello di risoluzione, proposto nel presente capitolo, si propone di soddisfare tale requisito utilizzando un sistema di nomi gerarchico simile a quello adottato dal DNS, essendo ampiamente provato il funzionamento di quest ultimo su larga scala. In particolare in tale modello, 194

213 IDN Naming Service Requisiti dei nomi che recepisce i principi basilari presenti negli standard DOI[BMR + 06] e XRI, si è scelto di denominare gli HFN come Logical Resource Identifier (LRI) e gli URN come Persistent Resource Identifier (PRI). La motivazione di tale scelta risiede nel fatto che LRI e PRI costituiscono una particolare specializzazione o sottocaso di HFN ed URN. Nel seguito del presente capitolo verranno analizzati dettagliatamente i vari elementi del modello a partire dalla definizione del sistema dei nomi. In secondo luogo verranno descritti i sistemi di risoluzione di un LRI in un PRI e di un PRI in un insieme di URL. Infine verrà presentato un sistema di risoluzione che a partire da un URL, relativo ad una replica di una risorsa, permette di risalire al rispettivo PRI e quindi a tutti i possibili LRI. 9.1 Requisiti dei nomi Le tipologie di nome introdotte nel paragrafo precedente (HFN, URN e URL) vengono utilizzate per finalità diverse. Mentre per URN ed URL esistono delle specifiche standardizzate, per gli HFN esiste una forte esigenza, ma nessun vincolo precisamente dichiarato. In particolare i requisiti di base degli URN coincidono con quelli degli URI (Uniform Resource Identifier), in quanto gli URN ne costituiscono un sottoinsieme. In questo paragrafo verranno formulati i requisiti degli HFN e riportati quelli degli URN al fine di delineare le principali caratteristiche e presupposti per la definizione dei rispettivi spazi di nomi. Per quanto riguarda gli URL il sistema è completamente definito in [BLMM94] Requisiti per gli HFN In riferimento a [Mea02] gli HFN devono soddisfare i seguenti requisiti: Requirement LDNS-R001 usabili. Gli HFN devono essere comprensibili e facilmente usabili dagli esseri umani per indicare concetti e contenuti di una risorsa; Requirement LDNS-R002 mnemonici. Gli HFN devono essere facilmente memorizzabili e tali da poter essere ricondotti ad un contesto ben preciso; Requirement LDNS-R003 riferiti al contesto. Gli HFN devono essere legati alla struttura del contesto relativamente al quale rappresentano i nomi delle entità. Questa proprietà è desiderabile in quanto contribuisce a rendere più semplice e familiare per gli utenti l uso degli HFN; Requirement LDNS-R004 interpretabili. Pur dovendo essere il più possibile amichevoli per l uomo, gli HFN devono anche poter essere facilmente analizzabili e interpretabili da un calcolatore poichè l indirizzamento e quindi l effettivo reperimento delle risorse dipendono direttamente da questo aspetto; 195

214 IDN Naming Service Requisiti dei nomi Requirement LDNS-R005 indipendenti dalla localizzazione fisica. Gli HFN devono essere completamente trasparenti rispetto alla locazione delle risorse fisiche cui sono associati. Una conseguenza di tutto ciò è il cosiddetto mascheramento che consiste nel nascondere la differente collocazione fisica di risorse che risultano strettamente collegate da un punto di vista concettuale; Requirement LDNS-R006 essenziali. Gli HFN devono essere sintatticamente composti da parole semplici Requisiti per gli URN Allo scopo di identificare una risorsa in modo univoco, durevole ed indipendente dalla sua effettiva dislocazione, le attività di ricerca legate ad Internet e guidate dall Internet Engineering Task Force (IETF), hanno iniziato lo sviluppo una tipologia di identificatori che prende il nome di Uniform Resource Name (URN). Nonostante queste attività di ricerca e sviluppo siano iniziate nel 1996, allo stato attuale non esiste ancora alcuna implementazione pubblica dell architettura URN, i cui requisiti funzionali sono specificati in [LPD98]. In ogni caso le linee guida su cui è stato basato finora lo sviluppo delle URN sono così sintetizzabili: Requirement LS-R007 schemi dei nomi e sistemi di risoluzione. Occorre effettuare una distinzione ben precisa tra i concetti di schema dei nomi e di sistema di risoluzione relativi agli URN. In particolare lo schema dei nomi relativo agli URN deve essere completamente indipendente da qualsiasi specifico sistema di risoluzione degli stessi. Come conseguenza di ciò si ha che ogni sistema di risoluzione deve essere potenzialmente in grado di risolvere un URN appartenente ad un qualunque schema dei nomi; Requirement LS-R008 compatibilità con tecnologie precedenti. Gli URN devono poter essere incorporati in schemi di nomi preesistenti relativi a documenti, indici, e sistemi online. In particolare se uno schema dei nomi cessa di essere supportato nella sua forma originaria, l architettura relativa agli URN deve continuare a supportare gli URN riconducibili a tale schema, mediante l impiego di sistemi di risoluzione alternativi. In questo modo gli utenti che assegnano un URN ad una risorsa online non rischiano che tale identificativo diventi obsoleto; Requirement LS-R009 registrazione. Dal momento che lo schema dei nomi e il servizio di risoluzione relativi agli URN sono indipendenti, è necessario che l applicazione che interagisce con un URN sia in grado di individuare in maniera autonoma quali sistemi risolutivi sono in grado di risolvere tale identificativo. Il procedimento con cui avviene ciò è detto registrazione e prevede l interazione tra un applicazione server, capace di memorizzare in appositi registri più servizi di risoluzione per ogni schema URN, e di un client che richiede la consultazione del registro appropriato nel momento in cui tenta di risolvere un nome. È bene osservare come l utilizzo di 196

215 IDN Naming Service Requisiti dei nomi un paradigma di tipo client-server contribuisca notevolmente al mantenimento dell indipendenza tra gli schemi dei nomi e i sistemi di risoluzione relativi alle URN. Per concludere la presente panoramica sugli URN, si riporta uno stralcio tratto da [SM94], in cui viene esposta la relazione esistente tra URL e URN: Un URN identifica una risorsa o unità informativa. Può identificare, ad esempio, un contenuto puramente logico, una particolare presentazione di un contenuto logico, o qualunque cosa un autorità di assegnazione dei nomi determini essere un entità distintamente richiamabile. La risorsa identificata da un URN può risiedere in una o più ubicazioni ad ogni istante, può muoversi, oppure può non essere disponibile. Certamente, non tutte le risorse si muoveranno durante il loro ciclo vitale, e non tutte le risorse, sebbene identificabili e identificate da un URN, saranno istanziate in ogni istante. Dal momento che un URL rappresenta il posto in cui una risorsa può risiedere, o un contenitore, questa risulta distinta dalla risorsa stessa che viene rappresentata dal URN. In ogni caso, affinchè gli URN soddisfino tutti i requisiti previsti, devono essere: Requirement LS-R010 visibili globalmente. Un URN è un nome globale, la cui portata non implica una ubicazione. Inoltre esso mantiene sempre lo stesso simbolo in qualunque contesto; Requirement LS-R011 unici globalmente. Uno stesso URN non può essere assegnato a due o più risorse differenti; Requirement LS-R012 persistenti. Dopo che un URN è stato creato, esso rimane associato ad una risorsa per almeno tutto il tempo in cui tale risorsa continua ad esistere. Infatti se la risorsa viene cancellata, il relativo URN viene mantenuto e in ogni caso non può più essere collegato a nessun altra risorsa. Quanto detto implica che un URN è globalmente unico per sempre e può essere utilizzato per riferire una risorsa oltre il suo stesso tempo di vita; Requirement LS-R013 scalabili. Gli URN possono essere assegnati a qualsiasi risorsa che deve essere mantenuta in rete per un tempo indefinito; Requirement LS-R014 integrabili con il legacy. Lo schema deve permettere il supporto a sistemi di nomi già esistenti, come ad esempio DOI (Digital Object Identifier) [BMR + 06] e ISBN; 197

216 IDN Naming Service Requisiti dei nomi Requirement LS-R015 estendibili. Lo schema relativo agli URN deve essere tale da supportare eventuali estensioni future, così da permettere la crescita dello spazio dei nomi e la sua applicabilità a contesti diversi; Requirement LS-R016 risolubili. Un URN non deve ostacolare la risoluzione (ovvero la traduzione in URL). In particolare deve esistere un meccanismo flessibile che traduca un URN in un URL. Requirement LS-R017 indipendenti. L autorità che assegna gli URN è l unica responsabile delle condizioni sull emissione dei nomi. È immediato osservare come i suddetti requisiti siano focalizzati su caratteristiche di tipo non funzionale, poichè non contengono alcuna affermazione sulle risorse identificate. Da un punto di vista funzionale va invece evidenziato come gli URN siano stati appositamente ideati allo scopo di semplificare la gestione delle repliche con particolare riguardo agli aspetti relativi alla mobilità ed evoluzione. Infine, l aver affermato che un URN è persistente 1, cioè che ha un lungo tempo di vita, comporta assumere come valide le seguenti proprietà: Requirement LS-R018 mobilità. Le repliche possono muoversi fisicamente da una macchina all altra; i responsabili possono spostarsi all interno dell organizzazione oppure le organizzazioni autoritative possono unirsi, trasformarsi o dividersi. Requirement LS-R019 evoluzione. Il sistema è continuamente in evoluzione cioè nuovi sottosistemi e protocolli possono essere creati ed i vecchi aggiornati Requisiti sulla codifica per HFN e URN In aggiunta ai precedenti requisiti ne esistono ulteriori, relativi alla codifica e valevoli sia per HFN che per URN. Pertanto entrambe le classi di nomi devono essere: Requirement LDNS+LS-R001 coerenti ad altre codifiche. La codifica deve essere (quanto più possibile) coerente con altri schemi di nomi già esistenti; Requirement LDNS+LS-R001 semplici nel confronto. L algoritmo per confrontare tra loro gli URN e gli HFN, intesi come stringhe, deve essere semplice, locale e deterministico; 1 È utile mettere in evidenza che è l assegnazione dell identificatore ad essere immutabile e persistente, in quanto la mutabilità della risorsa a cui esso si riferisce è indipendente dall identificatore stesso. 198

217 IDN Naming Service Logical Resource Identifier (LRI) Requirement LDNS+LS-R001 trascrivibili dall uomo. Per l uomo deve essere possibile trascrivere gli URN (per gli HFN tale requisito risulta particolarmente critico percui tale operazione deve risultare più semplice possibile). Per ottenere ciò è auspicabile che la codifica (in stringhe) di tali nomi sia: composta da una sequenza sufficientemente limitata di caratteri; case insensitive; non complicata dall uso di simboli speciali; Requirement LDNS+LS-R001 trasportabili. URN e HFN sono tali da essere identicamente trasportabili sia nei messaggi dei comuni protocolli Internet, sia su carta; Requirement LDNS+LS-R001 trattabili dalla macchina. URN ed HFN devono essere processabili dai calcolatori; Requirement LDNS+LS-R001 riconoscibile. La codifica di URN ed HFN deve essere riconoscibile durante il parsing di un testo che li contiene. 9.2 Logical Resource Identifier (LRI) Gli LRI sono la particolare tipologia di HFN introdotta con il presente sistema dei nomi per offrire agli utenti umani, come tale, la maggior libertà possibile nella scelta dei nomi, senza tener conto dei rigidi criteri decisionali imposti da un calcolatore. Si definisce quindi identificatore logico di una risorsa (LRI, Logical Resource Identifier) un nome HFN, appartenente all insieme degli URI, composto da più parti suddivise dal carattere / in cui ogni singola parte rappresenta un entità logica. dell ambiente virtuale. L insieme delle parti, separate da /, rappresenta il percorso. L ultima entità è quella che si vuole individuare. L intero percorso assieme all entità da individuare è il nome logico dell entità. Il formato completo è illustrato in figura 9.2 con notazione BNF (Backus-Naur Form). Si osservi che l insieme di caratteri <characters> utilizzabile per la definizione dei nomi è quello definito nel contesto degli URI [BLFM98]. Questa soluzione è stata scelta in base a quelle che sono state ritenute le esigenze attuali del progetto e può essere estesa, in modo da permettere l agevole codifica di stringhe appartenenti anche ad altri idiomi, nel momento in cui questo risulti necessario. A tal proposito è possibile fare riferimento agli Internationalized Resource Identifiers (IRI) descritti in [DS05]. A titolo di esempio si consideri il caso in cui un LRI sia utilizzato per identificare una risorsa documentale relativa ai dati anagrafici di una persona: appare evidente come tale risorsa possa essere utilizzata in contesti differenti quali la patente, la carta d identità, eccetera. Ognuno di questi contesti è strutturato secondo una gerarchia ben definita che nel caso della patente potrebbe essere la 199

218 IDN Naming Service Logical Resource Identifier (LRI) seguente: italia ministeri Ministero delle Infrastrutture e dei Trasporti Motorizzazione civile anagrafe patentati. Nell ambito di tale contesto risulta ovvio che il formato di un LRI, relativo ai dati anagrafici, dovrà rispecchiare la relazione gerarchica che intercorre tra i concetti di Ministero, Motorizzazione e di patente. In altri termini il formato degli LRI deve essere tale da poter descrivere uno spazio dei nomi gerarchico del tutto analogo a quello degli hostname che, si ricorda, è gerarchicamente suddiviso in domini. Al fine di soddisfare tutte queste proprietà, si è scelto di progettare la grammatica relativa agli LRI a partire dallo standard proposto da OASIS e concretizzatosi nello schema XRI [KW95]. Infatti tale schema, estendendo in maniera significativa la sintassi delle URI e degli IRI, consente di disporre di una serie di proprietà addizionali che ben si adattano alle principali necessità degli LRI Grammatica In questa sezione viene illustrata la sintassi relativa agli LRI, facendo riferimento ad una rappresentazione conforme alla Augmented Backus-Naur Form (la rappresentazione ABNF è descritta in appendice A). In ogni caso si premette che la sintassi LRI è stata appositamente definita nel modo più generale possibile, al fine di poterla successivamente estendere anche a contesti specifici che non costituiscono un argomento della presente trattazione. Il formato completo di un LRI è definito in figura 9.2. <lri> ::= <absolute-lri> <absolute-lri> ::= "lri://"(<authority>) <authority> ::= (<authority-subsegs>/)*<authority-subsegs> <authority-subseg> ::= <characters> <characters> ::= <uri_char> <uri_char> ::= ";" ":" "&" "=" "+" "$" "," "-" "_" "." "!" "~" "*" " " "(" ")" "a" "b" "c" "d" "e" "f" "g" "h" "i" "j" "k" "l" "m" "n" "o" "p" "q" "r" "s" "t" "u" "v" "w" "x" "y" "z" "A" "B" "C" "D" "E" "F" "G" "H" "I" "J" "K" "L" "M" "N" "O" "P" "Q" "R" "S" "T" "U" "V" "W" "X" "Y" "Z" "0" "1" "2" "3" "4" "5" "6" "7" "8" "9" Figura 9.2: Sintassi degli LRI Facendo riferimento all esempio relativo ai dati anagrafici di una persona, alcuni LRI ben formati sono: lri://it/comune/firenze/anagrafe/1997/atto3375p5si lri://it/ministero/trasporti/anagrafe_patentati/1900/fi4456k lri://istat/cittadini/fi/1980/rssmra00a01d612d 200

219 IDN Naming Service Persistent Resource Identifier (PRI) Eventualmente i client possono applicare delle semplificazioni con la finalità di rendere i nomi ancora più amichevoli: potrebbero essere previsti il completamento automatico ed i suggerimenti in linea quando una parte del nome non è coerente con la sintassi. A differenza di quanto avviene nel caso degli URI, la lettura degli LRI va eseguita procedendo da sinistra verso destra: segue che il segmento più autoritativo, a partire dal quale viene applicato il processo di risoluzione, è quello che si trova all estrema sinistra. Poiché la risoluzione di ogni segmento fornisce come risultato il contesto all interno del quale può essere risolto il segmento successivo, si ha che, procedendo iterativamente, la risoluzione dell ultimo segmento dà il contesto finale in cui si inserisce la risorsa associata all LRI. Per l assegnazione dei nomi è necessario un Authority, che eventualmente può coincidere con l utente stesso. 9.3 Persistent Resource Identifier (PRI) Equivalentemente a quanto fatto per gli LRI (paragrafo 9.2),nel presente lavoro si andrà a definire una particolare categoria di URN, detta Persistent Resource Identifier (PRI ), in modo da aver a disposizione uno spazio di nomi persistenti (e conformi sotto ogni punto di vista i requisiti previsti dagli URN) sui quali aver piena autorità Grammatica In accordo alla Augmented Backus-Naur Form, la sintassi di un PRI è definita in figura 9.3. Si osservi che la definizione prevede l uso di un set di caratteri derivato da quello ammesso per gli URI [BLFM98]. Questo però non esclude la possibilità che, in sviluppi futuri, la classe di stringhe valide per la descrizione dei PRI venga estesa. In modo equivalente, in figura 9.4 è presente un espressione regolare 2 [Goy06] in grado di identificare un PRI all interno di un generico testo. La parte <authority-number> ha un formato simile a quello delle net-loc degli URL, con la differenza che, nel caso in esame, si utilizzano nomi di tipo numerico separati dal punto. La sequenza di numeri non indica il server in cui viene prodotta l informazione, ma il server autoritativo per la risoluzione da PRI ad URL, di cui sarà affrontata la discussione più avanti nel capitolo. Ogni volta che nel sistema viene creata un entità, oltre al nome logico, viene associato anche un nome di portata locale anch esso numerico. Il valore viene assegnato automaticamente dal sistema della risoluzione dei nomi. Dalla definizione si può notare che effettivamente il PRI è completamente indipendente dal LRI e dall URL. Inoltre non è presente nessun riferimento alla locazione fisica, in quanto si assume che in generale il sistema di produzione ed il servizio di risoluzione siano mantenuti distinti. Come sarà discusso in seguito, la scelta di tale formato è stata motivata da una duplice volontà: da una parte quella di rendere più semplice ed automatizzata la gestione dei PRI da parte dei server dei nomi e dall altra quella di 2 La stringa che la rappresenta è stata suddivisa in due righe per motivi tipografici. 201

220 IDN Naming Service Il modello a tre livelli <pri> ::= "urn:"<nid>":"<nss> <nid> ::= "pri" <nss> ::= <authority-number>"/"<entity> <authority-number> ::= (dot-number)+<number> <entity> ::= (characters)+ <dot-number> ::= <number>"." <number> ::= "0" (<positive-digit>+<digit>) <positive-digit> ::= "1" "2" "3" "4" "5" "6" "7" "8" "9" <digit> ::= "0" "1" "2" "3" "4" "5" "6" "7" "8" "9" <characters> ::= <uri_char> <uri_char> ::= ";" ":" "=" "+" "$" "," "-" "_" "." "!" "~" "*" " " "(" ")" "a" "b" "c" "d" "e" "f" "g" "h" "i" "j" "k" "l" "m" "n" "o" "p" "q" "r" "s" "t" "u" "v" "w" "x" "y" "z" "A" "B" "C" "D" "E" "F" "G" "H" "I" "J" "K" "L" "M" "N" "O" "P" "Q" "R" "S" "T" "U" "V" "W" "X" "Y" "Z" "0" "1" "2" "3" "4" "5" "6" "7" "8" "9" Figura 9.3: Sintassi dei PRI urn:pri:(0\. ([1-9][0-9]*)\.)*(0 ([1-9][0-9]*)) /[0-9a-zA-Z\-_.,();:=+$!~* ]+ Figura 9.4: Espressione regolare per match sui PRI rendere più veloce ed immediata l assegnazione di un PRI ad una nuova risorsa. Alcuni esempi di PRI ben formati sono: urn:pri: /01 urn:pri:2.4/document.txt urn:pri: /image.jpg urn:pri: /aa b7b30bb0cf23a9fa5abc Da quanto detto si può notare come effettivamente i PRI siano del tutto indipendenti sia dagli LRI che dagli URL e come in essi non sia presente alcun riferimento alla locazione fisica della risorsa cui sono associati. 9.4 Il modello a tre livelli Il sistema dei nomi che è oggetto del presente lavoro si basa sulle tre tipologie di identificatori: Logical Resource Identifier (LRI), Persistent Resource Identifier 202

221 IDN Naming Service Il modello a tre livelli (PRI), Uniform Resource Locator (URL). Come mostrato in figura 9.5, è possibile associare più LRI ad uno stesso PRI. A titolo esemplificativo si riportano due LRI che individuano rispettivamente la patente e la carta d identità di una persona e che sono associati ad uno stesso PRI, relativo ai dati anagrafici della persona stessa: LRI://it/ministero/trasporti/motorizzazionecivile/patente123456/anagrafica LRI://it/comune/firenze/anagrafe/cartaidentita987654/datianagrafici La figura 9.5 mostra anche che uno stesso PRI può essere associato a più URL. Ricordando che un PRI identifica una risorsa in modo univoco e persistente e che una URL localizza una risorsa, permettendo di accedervi, è immediato comprendere come la suddetta associazione uno a molti permetta di identificare più repliche di una stessa risorsa. Questa forma di ridondanza aumenta notevolmente sia la disponibilità che l affidabilità dell intero sistema, rendendolo più robusto di fronte a guasti e/o malfunzionamenti della rete. Alle luce della relazioni esistenti tra i tre identificatori, si rende necessaria l introduzione di uno o più strumenti in grado di realizzare le traduzioni da un tipo di nomi all altro e viceversa. La descrizione di tali strumenti sarà oggetto dei paragrafi successivi Sistemi di risoluzione L architettura fin qui descritta presenta tre tipologie di identificatori, relative a livelli di astrazione differenti, che devono essere relazionate tra loro mediante due meccanismi di risoluzione: il primo si occupa di risolvere LRI in PRI, mentre il secondo di risolvere PRI in URL. Inoltre la risoluzione dei nomi deve essere possibile anche in senso inverso; ossia dato un URL di una replica, deve essere possibile risalire al rispettivo PRI e quindi a tutti i possibili LRI. LRI LRI PRI URL URL URL Figura 9.5: Modello del sistema dei nomi: LRI, PRI ed URL In analogia al DNS [Moc87a, Moc87b, Bra89a, Oht96, Vix96, VTRB97, EB97, Eas99, Vix99, GVE00, KGG + 03], nel seguito verranno presentati due sistemi di risoluzione dei nomi. Il primo è denominato Logical Domain Name System (LDNS) e si occupa della risoluzione diretta di un LRI in un PRI e 203

222 IDN Naming Service Logical Domain Name System (LDNS) della risoluzione inversa di un PRI nell insieme degli LRI ad esso associati. Il secondo prende il nome di Localization Service (LS) e si occupa sia di risolvere un PRI negli URL ad esso associati (risoluzione diretta), sia di fornire il PRI corrispondente ad un determinato URL (risoluzione inversa). Oltre alle suddette funzionalità, entrambi i sistemi implementano anche dei meccanismi che supportano l introduzione di nuovi nomi all interno del sistema in cui sono impiegati. 9.5 Logical Domain Name System (LDNS) Il LDNS è costituito da un vasto database di nomi, distribuito su un insieme di host. In analogia al sistema DNS i server, contenenti le corrispondenze tra gli LRI e i relativi URN, sono chiamati Logical Name Server (LNS). Ciascun LNS in genere è responsabile (autoritativo) di almeno una zona (anche se non è strettamente necessario). A tal proposito è opportuno effettuare alcune precisazioni sulla differente semantica assunta dai termini zona e dominio nel contesto di uno spazio dei nomi gerarchico come quello gestito dal LDNS: una zona può definire un gruppo di domini o un singolo dominio, mentre un dominio è invece un singolo nodo dello spazio dei nomi e comprende sempre tutti gli eventuali sottodomini. In questa trattazione non sono affrontate le problematiche relative all assegnamento di una o più zone ad un determinato LNS, assumendo che esistano già appositi algoritmi in grado di distribuire le zone sull insieme dei server ed eventualmente di assegnare ad un LNS più di una zona da gestire. Si evidenzia comunque che gli algoritmi di ripartizione delle zone possono riflettere le seguenti tipologie di politiche: politiche interne. Sono politiche che vengono stabilite ed attuate in maniera specifica per ogni server in base al relativo stato interno. Generalmente si tratta sia di algoritmi che, effettuando una stima del carico di lavoro di un dato server, sono in grado di stabilire se un dato server può gestire una nuova zona, sia di procedure che, sfruttando una conoscenza preliminare della topologia della rete, sono in grado di stabilire a quale server deve essere assegnata la nuova zona; politiche esterne. Sono politiche che vengono imposte dall esterno e riflettono tipicamente vincoli di tipo giuridico, legale o amministrativo La risoluzione L obiettivo primario del LDNS è quello di fornire un meccanismo in grado di risolvere un qualsiasi LRI nel corrispondente PRI, indipendentemente dal LNS di partenza utilizzato dal client LDNS. Affinché il processo di risoluzione possa essere avviato, è infatti necessario che il client sia a conoscenza di un LNS di default al quale inoltrare la richiesta di risoluzione. Questa situazione è del tutto analoga al caso del DNS in cui ciascun terminale che intende accedere al Web deve conoscere l indirizzo IP di un server DNS (tipicamente fornito dall Internet Service Provider). Nel caso specifico del LDNS si assume che l informazione relativa al primo LNS da contattare sia cablata all interno della configurazione 204

223 IDN Naming Service Logical Domain Name System (LDNS) del client: questo accorgimento permette infatti al client di individuare il proprio server di default sin dal momento dell avvio. Una volta che il programma client ha inoltrato una richiesta di risoluzione al proprio server di riferimento e si è posto in attesa di una risposta, possono verificarsi diversi scenari in gran parte dipendenti dalla modalità di funzionamento del server contattato. Infatti, conformemente allo standard XRI/XDI [KW95], ogni LNS può implementare due differenti meccanismi di risoluzione: con Look-Ahead e senza Look-Ahead. Nell ipotesi in cui la richiesta effettuata dal client sia sintatticamente corretta, verrà ora esposto il funzionamento dei suddetti meccanismi. Nel momento in cui un LNS, operante in modalità senza Look-Ahead, riceve una richiesta di risoluzione, si hanno tre possibili scenari distinti e mutuamente esclusivi: 1. il server è in grado di assolvere direttamente la richiesta; 2. il server non è in grado di assolvere la richiesta, ma conosce il successivo LNS a cui deve inoltrare la richiesta stessa; 3. il server non ha alcuna informazione relativa alla richiesta. Nel primo caso il server risponderà al client che lo ha contattato, indicando il PRI associato al LRI di cui è stata chiesta la risoluzione. Nel secondo caso il server inoltrerà la richiesta e si porrà esso stesso in attesa di una risposta da parte del successivo LNS contattato. Tale risposta potrà consistere o in un PRI o in un messaggio negativo, indicante l impossibilità di determinare quanto richiesto. A seconda del fatto che il server contattato sia autoritativo o meno sul LRI richiesto, il terzo caso si suddivide in due ulteriori sottocasi: 1. il server è autoritativo sul LRI richiesto. In questo caso il LNS dovrà inviare una risposta negativa al richiedente poichè, pur essendo autoritativo sul nome richiesto, non ha informazioni su di esso. Ovviamente questo implica la non esistenza del nome all interno del sistema; 2. il server non è autoritativo sul LRI richiesto. In questo caso il LNS dovrà inoltrare la richiesta al server radice, che è autoritativo su tutto il sistema dei nomi, e si dovrà mettere in attesa di una sua risposta. Come illustrato in figura 9.6, dove la freccia verticale sulla destra indica la linea del tempo, ogni server partecipa attivamente ad un solo passo del cammino risolutivo, il quale risulta pertanto distribuito complessivamente su più LNS. Coerentemente a ciò, anche il carico computazionale risulta distribuito tra i vari LNS coinvolti. A differenza di quanto visto finora, un server che opera in modalità con Look-Ahead può utilizzare due approcci distinti per soddisfare una richiesta di risoluzione; la scelta dell approccio da seguire avviene in base all identità del richiedente. Nel caso in cui la richiesta sia stata effettuata da un altro LNS, il server in questione avrà tre possibilità di risposta: 205

224 IDN Naming Service Logical Domain Name System (LDNS) Figura 9.6: Esempio di risoluzione senza Look-Ahead 1. assolvere direttamente la richiesta nel caso in cui sia noto il PRI associato al LRI richiesto; 2. fornire l indirizzo del successivo LNS, cui dovrà essere nuovamente inoltrata la richiesta; 3. inviare un messaggio di risposta negativo nel caso in cui il LNS in questione sia autoritativo sul LRI richiesto, ma non sia in grado di risolverlo. Si osservi come nel secondo caso il successivo LNS da contattare possa essere anche il server radice; in particolare questo si verifica se il server, oltre a non disporre di informazioni sul nome richiesto, non è autoritativo sul nome stesso. Viceversa se il server non contiene informazioni sul LRI richiesto, ma risulta autoritativo su di esso, ci si riconduce al terzo caso. Se invece un LNS, operante in modalità con Look-Ahead, riceve una richiesta direttamente da parte di un client LDNS, esso dovrà assolvere il compito di inoltrare la richiesta a tutti i successivi server presenti nel cammino risolutivo. Questo processo di inoltro continua iterativamente finché non e viene ottenuta una risposta definitiva, che può essere: 1. il PRI relativo al LRI di cui è stata chiesta la risoluzione; 2. un messaggio di risposta negativo. Da quanto detto e da quanto mostrato in figura 9.7, è evidente che nella modalità con Look-Ahead la maggior parte del carico di lavoro ricade sul primo server contattato. Viceversa nella modalità senza LookAhead, precedentemente analizzata, si ha una completa distribuzione del carico computazionale. Affinché il procedimento illustrato sia fattibile occorre che ogni LNS sia dotato di una lista di riferimenti verso altri LNS. La lista manterrà le informazioni sulle zone gestite, cioè su una porzione del Logical Name Space. Ogni LNS per ogni zona gestita deve mantenere i seguenti riferimenti: riferimento al LNS autoritativo per la zona top (radice); 206

225 IDN Naming Service Logical Domain Name System (LDNS) Figura 9.7: Esempio di risoluzione con Look-Ahead riferimento al LNS autoritativo della zona padre del LNS corrente; riferimenti ai LNS autoritativi delle zone figlio del LNS corrente L algoritmo di risoluzione L algoritmo per la risoluzione di un nome è il seguente: 1. si elimina il nome dell ultima entità presente in <authority> del LRI: partendo dalla fine del nome si eliminano verso sinistra tutti i caratteri fino ad incontrare il carattere / (compreso); 2. si effettua la nuova ricerca nella lista dei riferimenti: (a) se esiste un riferimento ad un LNS autoritativo per il LRI, viene effettuata una richiesta di risoluzione del nome di partenza (quello completo) verso tale LNS; (b) se non esiste nessun riferimento si ritorna al passo 1. Si può notare che nella iterazione al punto 1 è possibile incorrere in lri:// che rappresenta l Universe del Logical Name Space. Ogni Logical Name Server contiene nella propria lista un riferimento relativo al server autoritativo alla zona top. Per comprendere come sono strutturate le liste e l algoritmo di risoluzione è utile considerare la figura 9.8 e procedere con un esempio. Prima di tutto devono essere definite le liste in accordo alle regole precedentemente enunciate. Inoltre si supponga che: 207

226 IDN Naming Service Logical Domain Name System (LDNS) zona top W3 zona 1 zona 4 zona 5 zona 3 zona 2 Figura 9.8: Esempio di albero delle zone la zona top, la zona 1, la zona 4 e la zona 5 siano gestite da Logical Name Server distinti a cui, rispettivamente, siano assegnati i nomi di LNS-top, LNS-1, LNS-4, LNS-5; la zona 2 e la zona 3 siano gestite da un unico LNS (LNS-2,3). Per cui le liste assumono la seguente forma: 1. LNS-top. 2. LNS LNS-4. Riferimenti ai LNS autoritativi per le zone figlio: riferimento a LNS-1; riferimento a LNS-4; riferimento a LNS-5. Riferimenti ai LNS autoritativi per le zone figlio: riferimento al LNS-2,3. Riferimento al LNS autoritativo per la zona padre: riferimento al LNS-top. Riferimento al LNS autoritativo per la zona top: riferimento al LNS-top. Riferimento al LNS autoritativo per la zona padre: riferimento al LNS-top. Riferimento al LNS autoritativo per la zona top: riferimento al LNS-top. 208

227 IDN Naming Service Logical Domain Name System (LDNS) 4. LNS-5. Riferimento al LNS autoritativo per la zona padre: riferimento al LNS-top; Riferimento al LNS autoritativo per la zona top: 5. LNS-2,3. riferimento al LNS-top; Riferimento al LNS autoritativo per la zona padre: riferimento al LNS-1. Riferimento al LNS autoritativo per la zona top: riferimento al LNS-top. Si supponga che il LRI da risolvere sia: lri://world1/world4/world8.wrl e che la richiesta venga rivolta a LNS-2,3. LNS-2,3 è autoritativo delle zone 2 e 3, che ovviamente riguardano World diversi da quelli espressi nel LRI preso in esempio. Sotto queste ipotesi, LNS-2,3 verifica che lri://world1/world4 non è di sua competenza, per cui viene inviata una richiesta verso LNS-1 per risolvere lri://world1/world4/world8. Da questo punto in poi le modalità con e senza Look-Ahead procedono in modo diverso: Senza Look-Ahead. LNS-1 non è autoritativo, quindi inoltra la richiesta a LNS-top. Analogamente LNS-top richiede la risoluzione a LNS-5. LNS-5 è autoritativo sul LRI, per cui la risoluzione avviene e la risposta ripercorre il cammino inverso: LNS-5 LNS-top LNS-1 LNS-2,3 Client. Con Look-Ahead: LNS-1 non è autoritativo quindi invia a LNS-2,3 l indirizzo di LNS-top. LNS-2,3 inoltra la richiesta completa a LNS-top. LNStop non è autoritativo quindi invia a LNS-2,3 l indirizzo di LNS-5. LNS- 2,3 inoltra la richiesta completa a LNS-5 il quale è autoritativo sul LRI e fornisce a LNS-2,3 la risoluzione. In figura 9.9 sono riportati i cammini ordinati delle richieste e delle risposte nei due casi Caching Il LDNS fa ampio uso di una tecnica di caching allo scopo sia di migliorare le proprie prestazioni in termini di tempo di risposta ad una richiesta di risoluzione, sia di contenere la quantità di messaggi inoltrati in rete. In particolare la tecnica adottata prevede che ogni LNS mantenga una rappresentazione interna delle traduzioni effettuate recentemente per cui, quando 209

228 IDN Naming Service Logical Domain Name System (LDNS) LNS -top Senza Look-Ahead Richiesta Risposta Con Look-Ahead Richiesta Risposta LNS -1 LNS LNS -2,3 5 6 Figura 9.9: Richieste ricorsive per la risoluzione 210

229 IDN Naming Service Logical Domain Name System (LDNS) arriva una nuova richiesta di risoluzione su cui non è autoritativo, esso come prima cosa controlla se in tale tabella è presente la corrispondenza richiesta. In caso affermativo il server restituisce immediatamente il PRI senza ulteriori passaggi, altrimenti interpella il server successivo, che effettua le stesse operazioni. L inserimento dei nomi nella cache avviene ogni volta che un messaggio, contenente un PRI risolto, transita attraverso il server in questione prima di giungere al client che ha effettivamente originato la richiesta di risoluzione. Chiaramente i valori mantenuti in cache hanno una validità temporale limitata oltre la quale vengono eliminati per evitare risposte contenenti dati obsoleti e quindi non più validi Supporto alla navigazione Il meccanismo di risoluzione è efficace nell ipotesi in cui l utente conosca esattamente il nome della risorsa alla quale intende accedere. Questo scenario si presenta in varie circostanze considerando che è l utente ad assegnare i nomi e che può farlo seguendo delle proprie convenzioni che possono essere applicate in qualunque momento anche per risalire al nome della risorsa voluta. Allo stesso modo niente vieta di ipotizzare che l utente salvi i nomi delle risorse di suo interesse. Affidare all utente l onere della completa gestione dei nomi però può risultare un operazione complessa e oltretutto non permette di sfruttare al meglio le capacità del sistema gerarchico dei nomi logici. Per supportare l utente nella navigazione dello spazio dei nomi, il sistema fornisce la possibilità di effettuare una richiesta di appartenenza a su un LRI che non rappresenta una foglia del Logical Name Space. Come risultato il sistema fornisce la lista di tutti gli elementi in esso contenuti. Con questo meccanismo la navigazione nello spazio dei nomi logici risulta del tutto equivalente a quella su file system. Si osservi che la complessità di questo tipo di richiesta è poco superiore a quella di una richiesta di risoluzione. Una volta effettuata la richiesta ad un server qualunque, l algoritmo di ricerca del server autoritativo relativo all elemento in questione è lo stesso rispetto al caso della risoluzione. Tale server memorizza per ipotesi la lista degli indirizzi relativi a tutti i figli dell elemento in esame e può fornirla al richiedente come avviene per la risposta ad una generica richiesta di risoluzione. In realtà, anche se il costo dell algoritmo di risoluzione non cambia, potrebbero esserci delle difficoltà nella gestione e nel trasferimento della lista contenente tutti i riferimenti in quanto non sono state fatte ipotesi sul numero di elementi che questa può contenere (ogni genitore del Logical Name Space può avere un numero arbitrario di figli). In ogni caso possono essere previsti dei meccanismi finalizzati a limitare la dimensione della lista che i vari server devono manipolare e/o trasferire Espansione dello spazio dei nomi Mentre nelle sezioni precedenti è stato presentato il processo di risoluzione di nomi di alto livello, in questo paragrafo verranno discussi i meccanismi che 211

230 IDN Naming Service Logical Domain Name System (LDNS) regolano l inserimento di nuovi nomi nel sistema, permettendo così di espandere lo spazio dei nomi gestito dal LDNS. A tal proposito va detto che ciò che contraddistingue questi meccanismi risiede nella possibilità, per chiunque ne sia autorizzato, di aggiornare il sistema dei nomi senza dover richiedere alcun intervento da parte dell amministratore del servizio. Per realizzare tutto ciò, è stato definito un apposita primitiva basata sull attuazione del paradigma client-server. Il meccanismo in questione si svolge secondo i seguenti passi: 1. dopo essersi autenticato, il client effettua una richiesta di inserimento di un nuovo nome ad un server qualsiasi del sistema di risoluzione; 2. il server contattato esegue una procedura in grado di determinare quale LNS dovrà farsi effettivamente carico della gestione dell inserimento del nuovo nome; 3. il primo server contattato inoltra la richiesta di inserimento ricevuta dal client al LNS determinato al passo precedente; 4. il nuovo server contattato verifica le credenziali dell utente che ha effettuato la richiesta; se la verifica fallisce viene generato un messaggio d errore e si ha la terminazione dell algoritmo; 5. il server in questione applica delle politiche atte a stabilire se deve gestire esso stesso il nome, mediante un opportuna estensione dell insieme di zone di sua competenza, oppure delegare la gestione del nome ad un LNS di livello inferiore; 6. il server prescelto al passo precedente crea una voce relativa al nuovo nome all interno della propria struttura dati. Oltre alla corrispondenza LRI-PRI, tale voce conterrà anche un riferimento all utente che ha effettuato la richiesta di inserimento e che detiene i diritti sul nome inserito. Nel caso in cui questo passo vada a buon fine si ha la generazione di un messaggio di avvenuto inserimento, che viene inviato in risposta all utente, e la conseguente terminazione dell algoritmo. Il punto cruciale del meccanismo è sicuramente la modalità con cui al passo 5 un LNS determina se farsi carico esso stesso del nuovo nome oppure delegare la gestione del nome ad un altro server. Data l importanza dell argomento, è opportuno descrivere la questione tramite un esempio grafico. In figura 9.10 sono mostrate sei zone: coerentemente a quanto detto la zona-1, costituita dalla successione di nodi w2/w5/w9, è gestita da un unico server, così come un unico server si occupa della zona-top, per la successione w1/w4 ed un altro ancora per la zona-4 con la successione w3/w7. Osserviamo che w6,w8,w10, hanno ciascuno rispettivamente un server dedicato. Nel momento in cui, per effetto di una richiesta di inserimento, si rende necessaria la creazione di un nuovo nodo w4, il server in questione ha due possibilità: estensione della zona. Il server estende la zona w1/w2/w3 di propria competenza, gestendo esso stesso il nuovo nodo w4. 212

231 IDN Naming Service Logical Domain Name System (LDNS) W1 zona top zona 1 W3 W2 W3 W4 W3 W5 W6 W7 W8 zona 2 zona 4 zona 5 W3 W9 zona 3 W10 Figura 9.10: Rappresentazione delle zona in LDNS gestione delegata ad un altro server. La zona di competenza del server non viene ampliata e la gestione del nuovo nodo w4 viene delegata ad un altro server del sistema, posto ad un livello gerarchico inferiore. La scelta tra le suddette possibilità può essere svolta secondo diverse politiche come ad esempio: soglia di carico. Questa politica prevede che ogni server sia caratterizzato da un coefficiente di carico, definito in base al numero di server di nomi indirizzabili dal server stesso, alle caratteristiche e alle prestazioni dei suoi componenti hardware (hard disk, processore, memoria, etc.), alla disponibilità di banda dei collegamenti ed altri parametri vincolanti per un espletamento efficiente del servizio di risoluzione. In particolare si ha che il coefficiente di carico è dato dalla combinazione lineare dei suddetti parametri, opportunamente pesati in base alla loro rilevanza. Nel momento in cui il valore di tale coefficiente supera una data soglia, la gestione del nuovo nodo viene delegata ad un altro server. profilo dell utente. Questa politica prevede che il profilo dell utente, che ha effettuato la richiesta di inserimento, specifichi un LNS di riferimento che dovrà essere autoritativo su tutti i nomi che vengono creati tramite tale profilo. L utente può ottenere i permessi necessari all esecuzione di tale operazione direttamente dal proprio Internet Service Provider Proprietà di LDNS Il Logical Domain Name System, per come è stato definito e per la forte analogia con il DNS, può vantare le seguenti proprietà: garantisce la risoluzione di tutto il Logical Name Space; 213

232 IDN Naming Service Localization Service (LS) è facilmente estendibile; è scalabile; è facilmente aggiornabile; è rapido nelle modifiche al LNS. Alle precedenti proprietà si può aggiungere la tolleranza ai guasti ridondando gli apparati costituenti il sistema. Si possono introdurre, così come avviene per il DNS, dei server LNS secondari. In questo modo i server si classificano non solo in base al livello a cui appartengono, ma anche alla distinzione tra server primari e secondari. È importante osservare che la scalabilità di LDNS è di minore portata rispetto a quella del DNS, in quanto il primo permette una totale libertà nella creazione dei nodi già a partire dal primo livello. Si ricorda che nel DNS i nodi di primo livello sono prefissati e limitati nel numero. Tale libertà potrebbe portare ad una crescita non efficiente dell albero, ma d altra parte è un eventuale rischio che vale la pena correre per consentire una gestione più rapida nella creazione e nella modifica del LNS. 9.6 Localization Service (LS) Mentre nel precedente paragrafo è stato affrontato il problema della risoluzione di un LRI in PRI, ora si definisce il servizio che consente la risoluzione di PRI in URL: il Localization Service. Al fine di comprendere nel dettaglio la struttura gerarchica di LS, è opportuno tener ben presente il formato dei PRI così come esso è stato definito nel paragrafo 9.3. Per comodità si ricorda che un PRI è fondamentalmente costituito da due parti: il authority-number, che è costituito da una sequenza di cifre separate da un punto. Esso individua il server autoritativo per la risoluzione da PRI ad URL e permette di definire una relazione gerarchica tra i vari spazi di nomi. È attraverso questo segmento del nome che è possibile associare il compito della risoluzione di un gruppo di PRI ad un unico server LS; l entity, che è costituito da una stringa alfanumerica. In combinazione con l authority-number, essa consente di identificare univocamente una risorsa in modo del tutto indipendente sia da LRI che da URL. Dunque ogni server LS è autoritativo su tutti i PRI che hanno come parte <authority-number> la stringa numerica che identifica il server stesso. La prima cifra a partire da destra rappresenta la radice (server-top) della gerarchia di server LS, mentre le cifre successive nella loro sequenza completa (letta da destra verso sinistra) indicano i server di livello inferiore. In figura 9.11 vengono mostrate due gerarchie di server LS: quella a sinistra ha radice 0 e presenta più server di livello inferiore, mentre quella a destra ha radice 1 e presenta un solo server di livello inferire (0.1). Il formato prescelto consente pertanto di organizzare il servizio LS secondo una struttura ad albero, garantendo così 214

233 IDN Naming Service Localization Service (LS) Figura 9.11: Esempio di LS ottimi risultati in termini di espandibilità, scalabilità e distribuzione del carico di lavoro. Tali aspetti saranno comunque messi in evidenza in seguito. Analogamente al LDNS, anche per il Localization Service si assume che le richieste di risoluzione possano essere inoltrate a qualunque server LS, garantendo così una molteplicità di punti d accesso al servizio. L informazione relativa al primo server da contattare è cablata nella configurazione di ogni client in modo tale da poter essere reperita in modo semplice ed altamente performante. Questa soluzione permette infatti di assicurare al sistema una buona flessibilità e fa si che il client, subito dopo essere stato avviato, sia già in grado di comunicare con il server senza ulteriori fasi di setup. In conformità allo standard XDI/XRI, ogni server LS implementa due differenti meccanismi di risoluzione: con Look-Ahead e senza Look-Ahead. Il funzionamento di tali meccanismi è del tutto analogo a quanto progettato per LDNS. In particolare anche in questo caso si ha che con la prima modalità il carico computazionale ricade in larga parte sul server di default contattato dal client LS, il quale ha il compito di inoltrare la richiesta di risoluzione a tutti i successivi server presenti nel cammino risolutivo. Viceversa con la seconda modalità il carico di lavoro viene distribuito in maniera equa tra tutti i server coinvolti, ognuno dei quali partecipa ad un solo passo del cammino risolutivo (eccetto, ovviamente, l ultimo che effettua la risoluzione). Ogni server LS è dotato di un meccanismo di caching del tutto simile a quello di LDNS. In particolare ogni server LS mantiene nella propria cache tutte le corrispondenze PRI-URL risolte recentemente per cui, quando arriva una nuova richiesta di risoluzione su cui non è autoritativo, esso controlla se nella cache è presente la corrispondenza richiesta e in caso affermativo restituisce immediatamente gli URL senza ulteriori passaggi. Ovviamente nel caso in cui la cache non sia in grado di assolvere la richiesta di risoluzione, viene interpellato un successivo server LS. L inserimento dei nomi nella cache avviene ogni volta che un messaggio, contenente uno o più URL risolti, transita attraverso il server in questione prima di giungere al client che ha effettivamente originato la richiesta di risoluzione. Anche in questo caso la validità delle voci in cache ha una durata limitata nel tempo per evitare risposte con dati obsoleti. 215

234 IDN Naming Service Localization Service (LS) Come detto in precedenza, lo spazio dei nomi gestito da LS è gerarchico e risulta suddiviso in più zone, ognuna delle quali può essere gestita da uno stesso server LS. I meccanismi che regolano l inserimento di nuovi nomi nel sistema, permettendo di estendere tale spazio dei nomi, sono assai simili a quelli esaminati nel paragrafo dedicato a LDNS. In particolare una volta determinato il server che deve prendere effettivamente in carico l inserimento del nuovo nome, anche in questo caso il passo chiave dell algoritmo di inserimento è la modalità con cui il server in questione determina se farsi carico esso stesso del nuovo nome oppure delegare la gestione del nome ad un altro server. A titolo di esempio si consideri la figura 9.12 che mostra una zona rappresentata dalla successione di nodi Figura 9.12: Rappresentazione di una zona Se per effetto di una richiesta di inserimento si rende necessaria la creazione di un nuovo nodo 13, il server autoritativo sulla zona in questione ha due possibilità: gestire esso stesso il nuovo nodo, estendendo così la zona di propria competenza, oppure delegare la gestione del nodo ad un altro server, posto ad un livello inferiore della gerarchia LS. In quest ultimo caso il server delegato può essere preimpostato nella configurazione del server precedente, oppure può essere specificato dall utente al momento di effettuare la richiesta di inserimento. Le due soluzioni sono illustrate rispettivamente in figura 9.13 e In generale è preferibile adottare la prima soluzione in quanto assicura al sistema un buon livello di flessibilità e non richiede alcun intervento da parte dell utente. Sulla base di quanto detto finora, si possono evidenziare le seguenti caratteristiche di LS: garantisce la risoluzione dell intero spazio dei nomi a partire da qualunque punto d accesso al servizio; 216

235 IDN Naming Service Localization Service (LS) Figura 9.13: Estensione di una zona Figura 9.14: Delega della gestione di un nodo ad un altra zona consente una facile estendibilità dello spazio dei nomi mediante l aggiunta di nuovi nodi (server) nella gerarchia; è altamente scalabile in quanto derivato dal DNS; gestisce gli aggiornamenti in modo rapido ed efficace. 217

236 IDN Naming Service Localization Service (LS) Alle suddette proprietà si può aggiungere la tolleranza ai guasti, se il sistema viene ridondato. Infatti analogamente al DNS si possono introdurre dei server LS secondari che possono essere impiegati come riserva calda nel caso in cui uno dei server primari si guasti. Se viene adottata quest ultima soluzione, i server LS si distingueranno pertanto in primari e secondari, oltre che per il livello gerarchico a cui appartengono La risoluzione inversa. In questo paragrafo verrà presentato un sistema di risoluzione che a partire da un URL, relativo ad una replica di una risorsa, permette di risalire al rispettivo PRI e quindi a tutti i possibili LRI. Tale servizio, detto di risoluzione inversa, è del tutto speculare a quello di risoluzione diretta e per questo motivo è possibile ipotizzare la risoluzione inversa come un servizio a se stante svincolato dai precedenti, a tal punto da poter essere implementato mediante un sistema di server indipendenti da LDNS e LS. Indipendentemente da questo aspetto, come illustrato in figura 9.15, il meccanismo di risoluzione inversa risulta suddiviso in due stadi: 1. risoluzione inversa da URL a PRI; 2. risoluzione inversa da PRI a LRI. In questo lavoro non sono affrontate le problematiche relative al primo passo, assumendo che esista un apposita procedura in grado di effettuare la risoluzione inversa da URL a PRI. Nello specifico, dato che ogni singolo URL rappresenta una replica della risorsa logica identificata dal PRI, è possibile ipotizzare che il PRI stesso sia memorizzato come metadato all interno della replica, rendendo superfluo qualsiasi meccanismo di risoluzione inversa implementato nel sistema dei nomi. In ogni caso si può sempre introdurre, qualora l ipotesi appena citata non sia applicabile, un meccanismo di risoluzione inversa simile al reverse lookup del DNS. Per quanto concerne il secondo passo si ha che il meccanismo di risoluzione da PRI a LRI può essere descritto nel modo seguente: il client effettua una richiesta di risoluzione inversa di un PRI al proprio server LS di default; il server contattato, sfruttando l infrastruttura utilizzata per la risoluzione diretta, individua il server autoritativo sul PRI di cui è stata richiesta la risoluzione. In particolare si evidenzia che per la determinazione del server autoritativo possono essere impiegati entrambi i meccanismi: con Look-Ahead e senza Look-Ahead; dopo aver ricevuto la richiesta di risoluzione ed aver esaminato la propria struttura dati interna relativa alla risoluzione inversa, il server autoritativo sul PRI invia una risposta contenente gli LRI risolti. Anche per la risoluzione inversa è stato previsto un meccanismo di caching del tutto simile a quello della risoluzione diretta. In particolare ogni server LS 218

237 IDN Naming Service Localization Service (LS) LRI LRI PRI URL URL URL Figura 9.15: Risoluzione inversa mantiene nella propria cache tutte le corrispondenze PRI-LRI risolte recentemente per cui, quando arriva una nuova richiesta di risoluzione inversa per un PRI su cui non è autoritativo, esso controlla se nella cache è presente la corrispondenza richiesta e in caso affermativo restituisce immediatamente gli URL senza ulteriori passaggi. Nel caso in cui la cache non sia in grado di assolvere la richiesta di risoluzione, viene interpellato un successivo server LS. L inserimento dei nomi nella cache avviene ogni volta che un messaggio, contenente uno o più LRI risolti, transita attraverso il server in questione prima di giungere al client che ha effettivamente originato la richiesta di risoluzione. Ovviamente, come per i casi precedenti, la validità della cache ha una durata temporale limitata. Nell ambito della risoluzione inversa un aspetto importante riguarda la consistenza delle informazioni necessarie all espletamento del servizio rispetto allo spazio dei nomi gestito dal sistema. In altri termini non si deve verificare una situazione in cui esista un LRI che faccia riferimento ad un dato PRI e, contemporaneamente, il server autoritativo su tale PRI non contenga alcuna informazione che permetta di risalire al LRI. Affinché il meccanismo di inserimento di nuovi nomi nel sistema sia tale da garantire questa proprietà, è necessario che l inserimento di un nuovo LRI sia obbligatoriamente seguito da un operazione di aggiornamento del server LS che è autoritativo sul PRI cui esso si riferisce. Il sistema di risoluzione inversa appena descritto è necessario quando si vuole risalire da un PRI ad un nome logico e può essere utile in vari contesti. A titolo di esempio si possono considerare alcune questioni inerenti la salvaguardia della privacy e il trattamento dei dati personali. Infatti nell ipotesi che un PRI identifichi in modo unico e persistente dei dati confidenziali, sensibili e riservati relativi ad una data organizzazione o persona, il meccanismo di risoluzione inversa permetterà di risalire a tutte le entità che hanno creato un link a tali dati nel proprio spazio virtuale mediante la creazione di un LRI. Da quanto detto segue che i dati in questione possono essere acceduti ed utilizzati finché esiste tale LRI. Inoltre correlando alla risoluzione inversa un meccanismo di sicurezza, è possibile limitare l accesso ai dati alle sole entità che ne hanno diritto. Ad esempio al fine di realizzare un meccanismo automatico che garantisca una certa 219

238 InterDataNet Middleware IDN Naming Service Integrazione in InterDataNet forma di controllo sulla creazione di link verso un PRI, potrebbe essere previsto una verifica periodica della struttura dati relativa alla risoluzione inversa, in modo da determinare le entità che hanno fatto riferimento al PRI in questione, e la creazione di una tabella contenente le entità autorizzate. 9.7 Integrazione in InterDataNet Il sistema dei nomi descritto in questo capitolo è stato progettato con il fine di risolvere il problema dell indirizzabilità in ambiente distribuito. Per come è stato illustrato e per le proprietà che possiede, risulta valido ed applicabile al di fuori del middleware InterDataNet. In ogni caso il sistema di nomi è il sistema portante di InterDataNet: è integrato nella Service Architecture (IDN- SA, capitolo 8) in modo naturale, semplicemente applicando correttamente la stratificazione. La suddivisione a tre livelli è stata utile e vantaggiosa per semplificarne la trattabilità e l esposizione, ma per rigorosità devono essere eseguita una opportuna estensione e precisazione per mappature i livelli di IDN nei livelli del sistema dei nomi. In figura 9.16 è schematizzato sulla destra il sistema di nomi a tre livelli (partendo dall alto HFN, URN, URL) e sulla sinistra i layer dei servizi IDN su cinque livelli (partendo dall alto IDN Application, Virtual Repository, Information History, Replica Management ed infine Storage Interface) introdotti nel paragrafo 6.2. IDN Compliant Application Virtual Repository Layer Information History Layer Replica Management Layer Storage Interface Layer Filesystem, database, etc. Generic storage architecture IDN APIs HTTP(S), SMTP(S), FTP(S), etc. Generic network communication architecture IDN-IM names [+v.p.] LRIs [+v.p.] PRIs [+v.p.] PRIs URLs Platform dependent local names LDNS LS HFN URN URL Three layers IDN naming system [+v.p.] Optional version parameter Figura 9.16: Sistema dei nomi in InterDataNet Il fatto che l architettura sia a cinque livelli mentre il sistema di nomi a tre potrebbe sembrare un incongruenza, ricordando che in ogni architettura stratificata è opportuno che sia definito uno spazio di indirizzamento per ogni livello. La figura 9.16 intende esprimere ed evidenziare l inconsistenza della incongruen- 220

239 IDN Naming Service Integrazione in InterDataNet za: alcuni livelli utilizzano nomi della stessa classe, seppur specializzati per l indirizzamento proprio del livello. In particolare: IDN Application e Virtual Repository utilizzano nomi della classe HFN: rispettivamente gli IDN-IM names (con parametro di versione opzionale) introdotti nel paragrafo 7.4 e gli LRI introdotti nel paragrafo 9.2; Information History e Replica Management utilizzano nomi della stessa classe URN: rispettivamente i PRI, introdotti nel paragrafo 9.3, con parametro di versione (opzionale) ed i PRI senza parametro di versione; infine Storage Interface utilizza direttamente gli URL (che eventualmente internamente rimappa sullo spazio di nomi proprio della piattaforma di storage: per esempio nomi di file nel caso di file system oppure query SQL nel caso di database relazionali). Descriviamo adesso i meccanismi utilizzati per il passare da uno spazio di nomi di un livello ad un altro, operazione che viene effettuata regolarmente durante l attraversamento dei livelli, come previsto dall architettura (paragrafo 6.2.1). Partendo dal livello più alto: nel caso in cui le IDN Application introduchino in proprio modo di nominare ed indirizzare le risorse, tali applicazioni devono adattare i propri nomi ad LRI per poter interfacciarsi correttamente alla IDN-API (esposta da Virtual Repository). Si noti che InterDataNet non pone vincoli relativamente al modo con cui le applicazioni debbano rappresentare al loro interno di dati, tanto meno i nomi. Per questo motivo non è possibile stabilire un meccanismo generale; Virtual Repository si trova a dover convertire LRI (HFN) in PRI (URN) e per questo si avvale direttamente di LDNS; Information History deve risolvere la coppia PRI + parametro di versione nel PRI dell elemento corrispondente 3. Ad esempio se la versione n e la versione n + 1 di una data informazione hanno come PRI urn:pri: /12345 e urn:pri:8.5.34/76 rispettivamente, il nome urn:pri: /12345[next] (dove [NEXT] è il parametro di versione che indica la versione successiva) viene risolto da Information History in urn:pri:8.5.34/76. Questo tipo di risoluzione, necessario per la navigazione nello storico, viene svolto in Information History in modo algoritmico, come sarà descritto nel capitolo 11; Replica Management si trova a dover convertire PRI (URN) in URL e per questo si avvale direttamente di LS; infine Storage Interface, come già anticipato, rimappa gli URL sullo spazio di nomi proprio della piattaforma di storage. Anche in questo caso, pur 3 Nel caso particolare in cui il parametro di versione non sia presente, la funzione di conversione è l identità, ma dal punto di vista concettuale è ancora una risoluzione si tratta (intesa come il passaggio da uno spazio di nomi all altro). 221

240 IDN Naming Service Studio di fattibilità potendo citare vari esempi, non è possibile determinare regole generali in quanto Storage Interface è stato progettato proprio per abilitare lo sviluppo di adattatori verso qualsiasi tecnologie di storage per la memorizzazione persistente. 9.8 Studio di fattibilità Al fine di effettuare uno studio applicativo, i risolutori LDNS e LS sono stati implementati in forma dimostrativa. Avendo seguito un approccio aperto sin dalle prime fasi di progettazione, lo sviluppo non poteva prescindere dall uso di strumenti e piattaforme libere. La motivazione di questa scelta è condizionata da un lato dai numerosi vantaggi che si hanno con l adozione di licenze open source. In particolare è stato fatto riferimento a: JAVA, come il linguaggio di programmazione con cui sono state implementate le classi che realizzano l architettura del sistema dei nomi; GNU/Linux, come piattaforma di riferimento per sviluppo, test e deploy; MySQL, database relazionale utilizzato come back-end per la memorizzazione delle strutture dati interne; XML (extensible Markup Language), come metalinguaggio utilizzato, in accordo allo standard XDI/XRI 1.4, per definire il formato dei messaggi descrittori, scambiati tra host durante la risoluzione o l inserimento di un nome; HTTP [BLFF96, FGM + 99], come protocollo di livello applicativo utilizzato per la comunicazione tra i vari server. In particolare all interno dei pacchetti HTTP vengono incapsulati i descrittori XML tramite cui i server si scambiano le informazioni necessarie all espletamento dei loro compiti Implementazione del sistema dei nomi Nel presente paragrafo verranno descritti LDNS, LS ed il servizio di risoluzione inversa. Per ognuno di essi verranno introdotti i descrittori, la rappresentazione interna dei dati e gli algoritmi sia di risoluzione che per l inserimento di un nuovo nome. LDNS I descrittori. In analogia allo standard XDI/XRI, la risposta ad una richiesta di risoluzione di un segmento è costituita da un descrittore in formato XML che conterrà necessariamente il PRI risolto oppure le informazioni relative all autorità alla quale inoltrare successivamente la richiesta. La forma di base di un messaggio descrittore contenente il PRI risolto è la seguente: 222

241 IDN Naming Service Studio di fattibilità <LRIDescriptor> <Resolved> urn:pri: /01 </Resolved> </LRIDescriptor> LRI PRI NextStep Attribute Authority * localhost w5 pri: /01 12/11/05 Ing1 w1 Tabella 9.1: Esempio di rappresentazione dei dati interni di un LNS radice LRI PRI NextStep Attribute Authority w1/w2 pri: /15 12/11/05 Ing1 w1/* localhost Tabella 9.2: Esempio di rappresentazione dei dati interni di un generico LNS La forma di base di un messaggio descrittore, contenente le informazioni relative all autorità alla quale inoltrare la richiesta di risoluzione, è invece: <LRIDescriptor> <NextAuthority> <URI> nextstep.det.unifi.it </URI> </NextAuthority> </LRIDescriptor> Naturalmente, il set di informazioni contenute all interno di un descrittore, potrà essere ampliato con ulteriori metadati, relativi all autorità descritta, che agevolino il processo di risoluzione. Rappresentazione interna dei dati. Al fine di assolvere operativamente il processo di risoluzione, i Logical Name Server (LNS) dovranno essere caratterizzati da una struttura dati interna in grado di rappresentare le corrispondenze tra LRI e PRI. In particolare è necessario che ciascun LNS mantenga al suo interno, mascherata dall interfaccia, i dati relativi alla porzione di struttura gerarchica nella quale è situato. Come illustrato nella tabelle 2.1 e 2.2, è stata adottata una rappresentazione in forma tabellare in grado di mantenere al proprio interno le relazioni tra i nodi della gerarchia LDNS. Ogni tabella risulta suddivisa in cinque campi, corrispondenti alle informazioni necessarie affinché un server possa espletare il servizio di risoluzione. La semantica relativa a tali campi è la seguente: LRI: chiave primaria della tabella che rappresenta l LRI da risolvere; 223

242 IDN Naming Service Studio di fattibilità PRI: il PRI corrispondente al LRI da risolvere; NextStep: campo contenente l URI del successivo server da contattare per la richiesta di risoluzione di un dato PRI; Authority: campo che rappresenta l autorità relativa al LRI a cui si riferisce la entry nella tabella; Attribute: campo contenente gli attributi che caratterizzano l LRI; esempi tipici di attributi sono data e ora relativi alla creazione del LRI, oppure informazioni riguardanti le politiche di accesso. Andando ad analizzare i dati presenti nelle due tabelle, occorre innanzi tutto dire che la struttura dati in tabella 2.1 fa riferimento al caso di un server radice. Infatti la contemporanea presenza del valore * nel campo LRI e del valore localhost nel campo NextStep corrisponde a tale situazione. Pertanto se al server in questione viene richiesta la risoluzione del LRI w5, esso risponderà con il PRI contenuta in tabella, mentre nel caso in cui venga richiesta la risoluzione di un LRI il cui segmento iniziale sia w1, la struttura dati interna indicherà il successivo server da contattare (e cioè Se invece al server viene richiesta la risoluzione del LRI w7, esso risponderà con un messaggio di risposta negativo poiché è autoritativo su tutti i nomi del sistema. In tabella 2.2 è mostrata invece una possibile struttura dati interna per il server indicato come passo successivo nell esempio precedente: ciò è deducibile dalla presenza dei valori w1/* e localhost nei campi PRI e NextStep, indicante che il server in questione è autoritativo su tutti gli LRI inizianti con il segmento w1. In particolare se al server in questione viene chiesta la risoluzione del LRI w1/w2, esso risponderà con il PRI contenuto in tabella. Gli algoritmi. Il requisito fondamentale affinchè un client LDNS possa avviare il processo di risoluzione di un LRI in un PRI, è la conoscenza di un punto di partenza dal quale poter accedere al sistema per poi inoltrare la richiesta di risoluzione. L informazione relativa al primo server da contattare è stata cablata all interno di ogni terminale client mediante un file di configurazione a cui il client accede al momento dell esecuzione. In particolare all interno del file di configurazione è contenuta anche la porta a cui il server in questione è in ascolto in attesa di espletare i propri compiti. Una volta che ha determinato quale server contattare, il client può inoltrare la propria richiesta di risoluzione: a tale scopo esso formula la richiesta sottoforma di messaggio HTTP, apre una socket TCP attraverso cui inoltra la richiesta e si pone in attesa di una risposta. La richiesta di risoluzione viene formulata utilizzando il metodo GET. Nonostante da un punto di vista semantico tale metodo indichi una richiesta d accesso ad una risorsa, è stato deciso di utilizzarlo al fine di rimanere conformi allo standard XRI/XDI [KW95]. Omettendo le linee d intestazione non strettamente correlate con il sistema di risoluzione, il formato di una generica richiesta di risoluzione è il seguente: GET un/qualsiasi/lri HTTP/1.1 User-Agent : ldns

243 IDN Naming Service Studio di fattibilità Oltre al metodo utilizzato ed al nome di cui si richiede la risoluzione, la prima riga contiene anche un indicazione relativa alla versione del protocollo HTTP utilizzata. La riga successiva contiene invece l header User-Agent che in questo caso identifica il tipo di agente del sistema di risoluzione che ha effettuato la richiesta e la relativa versione. In particolare come verrà approfondito in seguito, tale header permette di distinguere il client che ha effettivamente originato la richiesta di risoluzione dagli altri server che entrano in gioco durante l esecuzione dell algoritmo. Come descritto nel paragrafo 9.5, un server LDNS può funzionare funzionare secondo due modalità distinte: con Look-Ahead e senza Look-Ahead. L informazione relativa alla modalità di funzionamento è stata cablata all interno di ogni server mediante un file di configurazione a cui il server accede al momento dell avvio. Tale file contiene anche altre informazioni utili tra cui la porta su cui il server è in ascolto e la URI di un server radice autoritativo sull intero spazio dei nomi. Ovviamente nel caso in cui l amministratore di sistema cambi alcune impostazioni del file di configurazione, il server dovrà essere riavviato in modo tale da poter mettere in pratica i nuovi settaggi. Nel momento in cui un server, operante in modalità senza Look-Ahead, riceve una richiesta di risoluzione, si hanno tre possibili scenari distinti e mutuamente esclusivi: 1. il server è in grado di assolvere direttamente la richiesta; 2. il server non è in grado di assolvere la richiesta, ma conosce il successivo LNS a cui deve inoltrare la richiesta stessa; 3. il server non ha alcuna informazione relativa alla richiesta. Per determinare in quale delle tre situazioni si trova, un server LDNS accede ad un database relazionale che viene sfruttato come storage system al posto del file system per motivi di comodità di interrogazione della struttura dati tabellare. In primo luogo il server esegue una ricerca relativa al LRI completo: se esso è presente, il server si troverà nel primo caso. Se ciò non si verifica, vengono ricercati nel database sotto-segmenti del LRI richiesto: nel caso in cui uno di questi sia presente nel database il server si troverà nel secondo caso, altrimenti si troverà nel terzo caso. A titolo di esempio si ipotizzi che ad un server giunga una richiesta relativa al LRI w1/w2/w3: se l intero nome è contenuto nel database il server si trova nel primo caso, altrimenti esso esegue una ricerca relativa a w1/w2 ed eventualmente a w1. Se uno dei due è contenuto nel database il caso in questione è il secondo, altrimenti è il terzo. Nel primo caso il server risponde al client che lo ha contattato con un messaggio di risposta HTTP indicante il PRI associato al LRI. Conformemente allo standard XDI/XRI, il formato generale dell header del messaggio è: HTTP/ OK Server: ldnsd 1.0 Oltre alla versione del protocollo utilizzata, la prima riga contiene il codice 200 OK, indicante che la richiesta è stata processata con successo; la seconda linea d intestazione specifica invece il tipo di server in questione e la relativa versione. Il body del messaggio HTTP contiene invece il descrittore in formato 225

244 IDN Naming Service Studio di fattibilità XML al cui interno è posto il PRI risolto. La forma di base di un messaggio descrittore contenente il PRI risolto è stata riportata precedentemente in questo paragrafo. Nel secondo caso il server inoltra la richiesta al nodo successivo, ponendosi in attesa di una risposta che potrà essere un messaggio contenente il PRI risolto oppure un messaggio indicante l assenza del nome all interno del sistema. A tal proposito il server attiva un client LDNS che apre una socket TCP, attraverso cui inoltra la richiesta, e si pone in attesa di una risposta. La richiesta che viene formulata è analoga a quella vista in precedenza, con la sola differenza che il campo User-Agent ha valore ldnsd 1.0 anzichè ldns 1.0 per indicare che la richiesta giunge da parte di un server di risoluzione. Nel terzo caso si hanno in realtà due possibili situazioni a seconda del fatto che il server contattato sia autoritativo o meno sul LRI di cui è stata chiesta la risoluzione. A tal proposito è stata adottata la convenzione seguente: si ricercano nella base di dati dei sottosegmenti del LRI richiesto che contengano come ultimo segmento il carattere * e che abbiano nel campo NextStep il valore localhost. Se l esito della ricerca è positivo, allora il server è autoritativo sul nome logico. Ad esempio un server LDNS è autoritativo sul LRI w1/w2/w3/w4 nel caso in cui nel campo LRI della base di dati sia presente uno dei seguenti valori: *, w1/*, w1/w2/*, w1/w2/w3/*. Se il server è autoritativo sul LRI e non ha informazioni su di esso, allora deve inviare al client che lo ha contattato un messaggio di risposta negativo, indicante l assenza del nome all interno del sistema. In conformità allo standard HTTP, il formato generale dell header del messaggio è: HTTP/ Not Found Server: ldnsd 1.0 In questo caso la prima riga dell header contiene il codice 404 Not Found, indicante appunto che il nome richiesto non esiste nel sistema; la semantica delle altre parti del messaggio è analoga a quanto discusso in precedenza per una risposta positiva. Se invece il server non è autoritativo sul LRI, allora la richiesta viene inoltrata al server radice che è autoritativo su tutto lo spazio dei nomi. Come detto in precedenza, ogni server LDNS ha cablato nel proprio file di configurazione la URI di un server radice. A differenza di quanto visto finora, un server che opera in modalità con a Look-Ahead può agire secondo due approcci distinti che dipendono dall identità del richiedente. Tale informazione viene specificata in ogni messaggio HTTP di richiesta mediante la linea d intestazione User-Agent che può assumere i valori ldnsc o ldnsd. Se il valore è ldnsc, allora il richiedente è il client che ha effettivamente originato la richiesta di risoluzione, altrimenti la richiesta proviene dal lato client di un server LDNS. Nel caso in cui la richiesta sia stata effettuata da un altro server LDNS, si possono verificare tre situazioni distinte: 1. il server può assolvere la richiesta in quanto contiene nel proprio database la corrispondenza LRI-PRI cercata. Analogamente al caso senza Look- Ahead la risposta è costituita da un messaggio HTTP che contiene nel body il descrittore XML indicante il PRI risolto; 2. il server fornisce l indirizzo del successivo server LDNS, cui dovrà essere nuovamente inoltrata la richiesta. In questo caso la risposta è costituita 226

245 IDN Naming Service Studio di fattibilità da messaggio HTTP che contiene un descrittore XML indicante la URI del successivo nodo del cammino di risoluzione. La forma di base di tale descrittore è stata riportata precedentemente in questo paragrafo; 3. il server fornisce un messaggio di risposta negativo in quanto è autoritativo sul LRI richiesto, ma non è in grado di risolverlo. Il formato del messaggio è identico a quello esaminato nel caso senza Look-Ahead. Se invece la richiesta è stata effettuata dal primo client, il server in questione dovrà assolvere il compito di inoltrare la richiesta a tutti i successivi server presenti nel cammino risolutivo, finchè non viene ottenuta una risposta definitiva che può essere: 1. un messaggio HTTP che contiene nel body il descrittore XML indicante il PRI risolto; 2. un messaggio di risposta negativo. Quanto detto finora non ha toccato un importante caratteristica di LDNS: il caching. Infatti nel momento in cui un server LDNS riceve una richiesta di risoluzione su cui non è autoritativo, esso accede ad un apposita tabella del proprio database in cui sono presenti tutte le traduzioni effettuate recentemente e ricerca al suo interno il nome da risolvere. Se tale LRI è presente nella tabella, allora il server può fornire il PRI risolto. Anche in questo caso la risposta è costituita da un messaggio HTTP che contiene nel body il descrittore XML con il PRI risolto. Per effettuare la manutenzione della tabella relativa al caching, è stato scelto di utilizzare un apposito thread che scandisce quotidianamente la tabella ed elimina tutte le voci la cui scadenza è anteriore alla data odierna. La data di scadenza dei nomi contenuti nella cache viene determinata al momento del loro inserimento in tabella aggiungendo alla data corrente un numero predefinito di giorni e/o ore. Tale parametro è cablato nel file di configurazione di ogni server e può essere variato dall amministratore di sistema. Il meccanismo utilizzato per l inserimento di un nuovo nome è simile a quello esaminato per la risoluzione. Infatti un client LDNS può avanzare la propria richiesta di inserimento ad un qualsiasi server di default, specificato nel proprio file di configurazione. Una volta contattato, tale server sfrutta l infrastruttura utilizzata per la risoluzione in modo da determinare il server LDNS autoritativo sul PRI in questione e da inoltrargli la richiesta di inserimento. Analogamente a quanto detto in precedenza, tutti i server coinvolti possono funzionare sia in modalità con Look-Ahead che senza Look-Ahead. Le differenze più rilevanti tra la risoluzione e l inserimento di un nome consistono nel formato dei messaggi HTTP di richiesta e di risposta. In primo luogo le richieste di inserimento vengono formulate utilizzando il metodo PUT. In realtà da un punto di vista semantico tale metodo viene impiegato per richiedere ad un server web di memorizzare la risorsa contenuta nel body del messaggio, associandogli la URI specificata nella linea di richiesta; nonostante ciò in questo caso è stato deciso di utilizzare il metodo PUT al fine di rimanere conformi allo standard XRI/XDI. Il formato di una generica richiesta di inserimento è il seguente: PUT un/qualsiasi/lri HTTP/

246 IDN Naming Service Studio di fattibilità User-Agent : ldns 1.0 Content-Location : un/qualsiasi/pri Oltre alla versione del protocollo HTTP ed al metodo utilizzato, la prima riga contiene anche il LRI che permette di determinare il server autoritativo sul nome da inserire, sfruttando l infrastruttura usata per la risoluzione. La linea d intestazione Content-Location è stata appositamente introdotta allo scopo di specificare il PRI di cui si richiede l inserimento. Per quanto riguarda la risposta ad una richiesta di inserimento, vanno invece distinti due casi a seconda del fatto che la richiesta sia andata a buon fine o meno. Nella prima eventualità il formato generale della risposta è il seguente: HTTP/ OK Server: ldnsd 1.0 Come si può vedere il formato del messaggio è analogo a quello esaminato per la risoluzione; l unica differenza risiede nel fatto che questa volta nel descrittore XML, contenuto nel body del messaggio, è specificato il PRI inserito. Nella seconda eventualità il formato generale della risposta è invece il seguente: HTTP/ Conflict Server: ldnsd 1.0 In questo caso la prima riga dell header contiene il codice 409 Conflict, indicante appunto che la richiesta di inserimento non è stata portata a termine; la semantica delle altre parti del messaggio è quella discussa in precedenza per una risposta positiva. LS I descrittori. Anche nel caso del Localization Service la risposta alla richiesta di risoluzione di un nome è costituita da un descrittore in formato XML, contenente gli URL risolti oppure le informazioni relative al successivo server a cui inoltrare la richiesta. Questa volta però, essendo il servizio di risoluzione del tipo uno a molti, il formato del messaggio descrittore in risposta dovrà essere opportunamente modificato in modo da includere tutti i possibili URL associati allo stesso PRI. Ad esempio, nel caso in cui ad uno stesso PRI corrispondano tre URL, il formato del messaggio descrittore risulta dunque il seguente: <PRIDescriptor> <Resolved> <Resolution> </Resolution> <Resolution> achille.det.unifi.url </Resolution> <Resolution> radar.det.unifi.url </Resolution> </Resolved> </PRIDescriptor> La forma di base di un messaggio descrittore, contenente le informazioni relative all autorità alla quale inoltrare la richiesta di risoluzione, è invece ad esempio: 228

247 IDN Naming Service Studio di fattibilità <PRIDescriptor> <NextAuthority> <URI> radar.det.unifi.it </URI> </NextAuthority> </PRIDescriptor> PRI URL NextStep Attribute Authority * localhost 40.* localhost Tabella 9.3: Esempio di rappresentazione dei dati interni di un server LS radice PRI URL NextStep Attribute Authority * localhost 40.37/ / Tabella 9.4: Esempio di rappresentazione dei dati interni di un server LS Rappresentazione interna dei dati. In analogia a LDNS, anche per il Localization Service è stata adottata una semplice modalità di rappresentazione interna dei dati in forma tabellare attraverso la quale memorizzare le corrispondenze uno a molti tra PRI ed URL. Come illustrato nelle tabelle 9.3 e 9.4, ogni tabella risulta strutturata in cinque campi, corrispondenti alle informazioni necessarie affinché un server possa espletare il servizio di risoluzione. La semantica dei vari campi è simile a quella esaminata per LDNS; la differenza principale risiede nel ruolo svolto dal campo PRI, che in questo caso svolge la funzione di chiave primaria, e nell introduzione del campo URL contenente gli URL corrispondenti al PRI da risolvere. In altri termini si ha che tutte le righe della tabella, che sono caratterizzate dalla presenza della stessa voce nel campo PRI, conterranno un URL che andrà nel messaggio descrittore inviato dal server LS in risposta ad una richiesta di risoluzione. Andando ad analizzare i dati presenti nelle due tabelle, risulta evidente come la struttura dati in tabella 9.3 si riferisca ad un server LS radice, in quanto contiene una voce caratterizzata dal valore * nel campo LRI e dal valore localhost nel campo NextStep. La tabella 9.4 si riferisce invece ad un server LS autoritativo su tutti i PRI che iniziano con 40.37; in particolare si può osservare come esso contenga due URL 229

248 IDN Naming Service Studio di fattibilità distinte ( e ing.unifi.it) associate ad uno stesso PRI (40.37/01), individuando così dueı repliche distinte di una stessa risorsa logica. Gli algoritmi. Le specifiche tecniche del Localization Service ricalcano fedelmente quanto appena descritto per LDNS. In particolare le caratteristiche principali di LS possono essere sintetizzate nei punti seguenti: all interno di ogni client LDNS è presente un file di configurazione in cui sono cablate alcune informazioni indispensabili all avvio del processo di risoluzione, quali la URI del primo server da contattare e la porta a cui esso è in ascolto; le richieste di risoluzione sono formulate mediante dei messaggi HTTP di richiesta che, in conformità allo standard XDI/XRI, utilizzano il metodo GET. In particolare ogni messaggio contiene la linea d intestazione User- Agent che specifica l identità del richiedente, permettendo di distinguere tra il client che ha effettivamente originato la richiesta di risoluzione e il lato client di un server LS; la risposta ad una richiesta di risoluzione è costituita da un messaggio HTTP il cui codice a tre cifre è 200 OK nel caso in cui il nome sia stato effettivamente risolto, oppure 404 Not Found se il nome non esiste all interno del sistema. Inoltre se il PRI è stato risolto, nel body del messaggio è presente il descrittore XML che contiene le URL associate ad esso; ogni server ha due possibili modalità di funzionamento: con LookAhead e senza Look-Ahead. L informazione relativa alla modalità di funzionamento è stata cablata all interno di ogni server mediante un file di configurazione che viene acceduto al momento dell avvio. Tale file contiene anche altre informazioni utili al corretto funzionamento del server tra cui la porta a cui esso è in ascolto e la URI di un server radice autoritativo sull intero spazio dei nomi. Ovviamente nel caso in cui l amministratore di sistema cambi alcune impostazioni del file di configurazione, il server dovrà essere riavviato in modo tale da poter mettere in pratica i nuovi settaggi; per la rappresentazione interna dei dati di ogni server viene utilizzato un database relazionale che viene sfruttato come storage system al posto del file system per motivi di comodità di interrogazione della struttura dati tabellare; LS è dotato di un meccanismo di caching del tutto analogo a quello di LDNS. In particolare la manutenzione della tabella relativa al caching viene effettuata da un apposito thread che scandisce quotidianamente la tabella ed elimina tutte le voci la cui scadenza è anteriore alla data odierna. La data di scadenza dei nomi contenuti nella cache viene determinata al momento del loro inserimento in tabella aggiungendo alla data corrente un numero predefinito di giorni e/o ore. Tale parametro è cablato nel file di configurazione di ogni server e può essere variato dall amministratore di sistema; 230

249 IDN Naming Service Studio di fattibilità le richieste di inserimento di un nuovo nome sono formulate mediante dei messaggi HTTP di richiesta che utilizzano il metodo PUT. In particolare ogni messaggio contiene la linea d intestazione Content-Location che specifica la URL, associata al PRI di cui si richiede l inserimento; la risposta ad una richiesta di risoluzione presenta un formato identico a quello esaminato per LDNS. In particolare la linea di stato del messaggio contiene il codice 200 OK se la risposta è positiva e 409 Conflict se la risposta è negativa. Risoluzione inversa I descrittori. Analogamente a quanto visto per la risoluzione diretta, la risposta è costituita da un descrittore in formato XML come quello mostrato in figura Dal momento che anche la risoluzione inversa offre un servizio di traduzione da uno a molti, pure in questo caso il formato del messaggio descrittore è stato modificato con l aggiunta di un nuovo tag in modo da includere tutti i possibili LRI che fanno riferimento ad un dato PRI. <PRIDescriptor> <Resolved> <Resolution> lri://it/regione/toscana/atto3375q9 </Resolution> <Resolution> lri://istat/cittadini/fi/rssmra03 </Resolution> <Resolution> lri://it/ministero/interni/atto498p </Resolution> </Resolved> </PRIDescriptor> Figura 9.17: Descrittore XML relativo alla risoluzione inversa Rappresentazione interna dei dati. In analogia alla risoluzione diretta, anche per quella inversa è stata adottata una semplice modalità di rappresentazione interna dei dati in forma tabellare attraverso la quale memorizzare le corrispondenze uno a molti tra PRI e LRI. Come illustrato nella tabella 2.7, ogni tabella risulta strutturata in tre campi, corrispondenti alle informazioni necessarie affinché un server possa espletare il servizio di risoluzione inversa. La semantica relativa a tali campi è la seguente: PRI: chiave primaria della tabella che rappresenta l LRI di cui si chiede la risoluzione inversa; LRI: il LRI corrispondente al PRI da risolvere; Authority: campo che rappresenta l autorità relativa al PRI a cui si riferisce la entry nella tabella. Da quanto detto è pertanto evidente che ogni riga della tabella, caratterizzata dalla presenza di una stessa voce nel campo PRI, conterrà un LRI che andrà 231

250 IDN Naming Service Studio di fattibilità nel messaggio descrittore inviato dal server LS in risposta ad una richiesta di risoluzione inversa. PRI LRI Authority /01 lri://w1/w2/w /01 lri://w5/w /01 lri://w12 Tabella 9.5: Esempio di rappresentazione dei dati interni di un server LS per la risoluzione inversa PRI LRI TTL /01 lri://w1/w2/w3 Ing /01 lri://w5/w6 Ing /01 lri://w12 Ing1 Tabella 9.6: Esempio di rappresentazione dei dati interni di un server LS per il caching relativo alla risoluzione inversa Gli algoritmi. Il servizio di risoluzione inversa permette di risalire a tutti i nomi logici che fanno riferimento ad uno stesso PRI. Essendo speculare ai precedenti, la risoluzione inversa è stata pensata come un servizio a se stante rispetto a LDNS e LS tanto da poter essere implementata mediante un sistema di server indipendenti. Per poter avviare un processo di risoluzione inversa, è necessario che il client abbia a disposizione un server di default al quale inoltrare la richiesta di risoluzione. Analogamente a quanto visto nel caso di LDNS e LS, l informazione relativa al primo server da contattare è stata cablata all interno del client sottoforma di un file di configurazione che viene acceduto dal client al momento dell esecuzione. Le richieste di risoluzione vengono formulate tramite un messaggio HTTP il cui formato generico è: GET un/qualsiasi/pri HTTP/1.1 User-Agent : lsrev 1.0 Il formato della richiesta è uguale a quello esaminato per LDNS e LS; l unica differenza risiede nel fatto che in questo caso la prima riga contiene il PRI di cui si richiede la risoluzione inversa. Come al solito, la linea d intestazione User-Agent specifica l identità del richiedente, permettendo di distinguere tra il client che ha effettivamente originato la richiesta di risoluzione e il lato client di un server della catena di risoluzione. A questo punto il server contattato, sfruttando la stessa infrastruttura descritta per la risoluzione diretta, individua il server autoritativo sul PRI di cui è stata richiesta la risoluzione. Ciò è necessario poichè è tale server che nella propria struttura dati interna, relativa alla risoluzione inversa, detiene i nomi logici che fanno riferimento al PRI. In particolare si evidenzia che per la determinazione del server autoritativo possono essere impiegati entrambi i meccanismi: con Look-Ahead e senza Look-Ahead. 232

251 IDN Naming Service Studio di fattibilità Anche in questo caso l informazione relativa alla modalità di funzionamento è stata cablata all interno di ogni server mediante un file di configurazione che viene acceduto al momento dell avvio. Ovviamente se l amministratore di sistema cambia alcune impostazioni del file di configurazione, il server deve essere riavviato. La risposta ad una richiesta di risoluzione è costituita da un messaggio HTTP nella cui linea di stato è presente un codice a tre cifre, indicante l esito con cui la richiesta è stata processata. Se il PRI è stato risolto con successo, il formato generico dell header del messaggio è: HTTP/ OK Server: ldrev 1.0 I nomi logici associati al PRI sono contenuti in un descrittore XML posto nel body del messaggio. Viceversa se il PRI non è stato risolto, il formato generico del messaggio è: HTTP/ Not Found Server: ldrev 1.0 Anche il servizio di risoluzione inversa è dotato di un meccanismo di caching del tutto analogo a quello di LDNS e LS. L inserimento dei nomi nella cache avviene ogni volta che un messaggio, contenente uno o più LRI risolti, transita attraverso il server in questione prima di giungere al client che ha effettivamente originato la richiesta di risoluzione. Per la manutenzione della tabella relativa al caching è stato scelto di impiegare un apposito thread che scandisce periodicamente la tabella, eliminando tutte le voci la cui scadenza è anteriore alla data odierna. La data di scadenza dei nomi contenuti nella cache viene determinata al momento del loro inserimento in tabella aggiungendo alla data corrente un numero predefinito di giorni e/o ore. Tale parametro è preimpostato nel file di configurazione di ogni server e può essere variato dall amministratore di sistema. Per quanto riguarda l inserimento di un nuovo nome, va detto che il meccanismo utilizzato è simile a quello esaminato per la risoluzione. Infatti un client può avanzare la propria richiesta di inserimento ad un qualsiasi server del sistema, la cui URI è specificata nel proprio file di configurazione. Una volta contattato, tale server sfrutta l infrastruttura utilizzata per la risoluzione in modo da determinare il server autoritativo sul PRI in questione e da inoltrargli la richiesta di inserimento. Analogamente a quanto detto in precedenza, tutti i server coinvolti possono funzionare sia in modalità con Look-Ahead che senza Look-Ahead. Le richieste di inserimento vengono formulate tramite un messaggio HTTP con metodo PUT, il cui formato generico è: PUT un/qualsiasi/pri HTTP/1.1 User-Agent : ldns 1.0 Content-Location : un/qualsiasi/lri Come si può vedere, la prima riga contiene il PRI che permette di determinare il server autoritativo sul LRI da inserire, mentre la linea d intestazione Content-Location specifica il nome logico di cui si richiede l inserimento. La risposta ad una richiesta di inserimento è costituita da un messaggio HTTP nella cui linea di stato è presente un codice a tre cifre, indicante se la richiesta è stata soddisfatta o meno. Nella primo caso il formato generale della risposta è il seguente: 233

252 IDN Naming Service Studio di fattibilità HTTP/ OK Server: ldrev 1.0 Evidentemente il formato del messaggio è analogo a quello esaminato per la risoluzione; l unica differenza risiede nel fatto che questa volta nel descrittore XML, posto all interno del body del messaggio, è specificato il nome logico inserito. Nella seconda eventualità il formato generale della risposta è invece il seguente: HTTP/ Conflict Server: ldnsd

253 Capitolo 10 Virtual Repository Service Il principale servizio di Virtual Repository (VR) è fornire a livello applicativo la navigazione nello spazio delle informazioni in maniera logica ed uniforme. Virtual Repository è responsabile della gestione degli aspetti strutturali dei documenti. Per espletare questo compito, si avvale di tre sottoservizi indipendenti, visibili e raggiungibili dal livello applicativo: Resource Aggregation Service (RAS); Logical Domain Name Service (LDNS); Identity Service (IS); LDNS è trattato ampiamente nel capitolo 9, pertanto nelle prossime pagine saranno discussi principalmente RAS e IS, già brevemente introdotti nel capitolo 8. La logica interna a Resource Aggregation Service assume un ruolo centrale nella orchestrazione dei compiti del livello ed integrazione dei servizi. RAS tratta le informazioni da un punto di vista strettamente strutturale: in maniera conforme ad IDN-IM gestisce le relazioni di aggregazioni ed attua i meccanismi previsti dal modello, sfruttando di servizi di pari livello o forniti dal sottostante Information History Service (IH). Per compiti del livello VR verrà fatto più volte riferimento ai concetti legati al versioning, nonostante VR si occupi degli aspetti strutturali. È importante precisare la differenza tra i meccanismi propri del versioning e la sua gestione. Come affermato nel capitolo 8 il versioning è completamente trattato nel livello inferiore IH, ma è a questo livello che si attua la gestione orchestrata delle versioni, assegnando la semantica alle funzionalità invocate verso il basso.

254 Virtual Repository Service Richiami al modello IDN-IM In sostanza si distingue tra le operazioni propriamente legate al versionamento (relative alla gestione dei link di versioning di livello IH) e la gestione del versionamento (ovvero dei link di propagazione di livello VR). La strutturazione granulare delle informazioni versionate, in tutte le componenti di dati e metadati, richiede molteplici richiami al modello di versioning ed ai servizi fondamentali offerti da IH. Si cercherà pertanto di evidenziare come sia determinante la sinergia tra VR ed IH, mantenendo il minimo accoppiamento tra i due servizi e sempre tenendo in considerazione che VR si occupa dei soli aspetti strutturali. Identity Service rappresenta il servizio che approva o nega l esecuzione dei meccanismi internamente a VR a fronte delle richieste provenienti dal livello applicativo. La sua natura estremamente specializzata e rivolta alla sicurezza di sistema verrà trattata separatamente al fine di non rendere l esposizione di RAS troppo complessa, oscurandone il vero compito. Notiamo che l importanza di VR, quale livello più elevato della pila IDN-SA, è determinata anche dal costituire il punto di accesso logico al sistema su cui convergono le principali convenzioni previste da IDN-IM. Le applicazioni potranno trarre il massimo vantaggio dai servizi esposti da VR, solamente recependo il modello IDN-IM Richiami al modello IDN-IM Il modello dell informazione IDN-IM è stato progettato ispirandosi al modello di documento di UEVM [ABCM99] e con la finalità di applicare gli stessi principi al versioning delle informazioni. Nel modello IDN-IM le informazioni atomiche costituiscono l insieme dei dati contenuti nel documento. Essendo il documento strutturato, tali dati sono messi in relazione tramite le informazioni primitive. La struttura è gerarchica: i nodi che si trovano ai livelli più alti della gerarchia rappresentano, da un punto di vista concettuale, il punto d accesso all informazione strutturata che si sviluppa da essi fino alle foglie. Modificare uno qualunque dei nodi appartenenti a tale gerarchia significa modificare l informazione complessiva. UEVM è un modello che permette di gestire le versioni di documenti strutturati ad albero con la particolarità di riuscire a versionare anche gli aspetti strutturali. In altre parole il documento è tracciato nelle modifiche del contenuto e delle relazioni esistenti fra contenuti. Il fatto che UEVM si limiti a gestire documenti strutturati ad albero deriva dal considerare l informazione come entità individuale: il documento. In UEVM due documenti diversi sono entità distinte e completamente scorrelate. In IDN-IM viceversa l informazione è distribuita e una delle caratteristiche di maggior rilievo del modello è proprio la sua condivisione documenti e soggetti diversi. Il documento in IDN-IM è considerato come l aggregazione di informazioni distribuite. Questo porta ad una struttura più generale rispetto a quella ad albero in quanto la condivisione di un informazione fra due documenti distinti genera un DAG: si hanno due alberi parzialmente sovrapposti e l intersezione è data 236

255 Virtual Repository Service Richiami al modello IDN-IM esattamente dal sotto albero che rappresenta l informazione condivisa. Generalizzando, lo stesso risultato si ottiene anche nel caso della condivisione di un informazione da parte di N documenti, con N arbitrario. Da questa considerazione si deduce che le gelazioni generiche fra nodi IDN-IM portano ad avere un DAG. Per questo motivo, e comunque per avere maggiore flessibilità nella modellazione dell informazione, in IDN-IM si parla di DAG anche limitatamente al contesto del singolo documento. IDN-IM è un modello strutturato e prevede l esistenza di due tipologie di informazioni (vedi capitolo 7): primitive (Primitive Information Unit, PIU); atomiche (Atomic, Information Unit, AIU). Le informazioni atomiche vengono incapsulate in informazioni primitive: solo queste ultime hanno un indirizzo univoco (PRI), ottenuto da LDNS, e possono essere associate ai nodi del DAG relativo al documento. Tali nodi contengono quindi: le informazioni atomiche costituite da coppie <nome,valore>, i dati veri e propri definiti nei livelli superiori; i metadati definiti nei livelli superiori; le relazioni verso altri nodi, proprie delle informazioni primitive. Per il livello VR esistono quindi nodi al cui interno è possibile individuare due sezioni distinte, che nascono a seguito del principio di imbustamento presente in IDN-SA, come architettura stratificata. Tali nodi, rappresentati schematicamente in figura 10.1, sono costituiti da: un header, che contiene tutti i metadati necessari al mantenimento delle relazioni definite a livello VR; un body, nel quale VR imbusta tutti i dati e i metadati che non sono di sua competenza (di competenza del livello applicativo). Indirizzamento PRI Header Dati e metadati di competenza di Structure Body Dati e metadati di competenza dei livelli superiori Figura 10.1: Nodi di livello IH 237

256 Virtual Repository Service Resource Aggregation Service La struttura dello storico Prima di entrare nel merito di come il layer VR implementa le specifiche dettate dal modello IDN-IM è utile ricordare brevemente le notazioni, le definizioni e i principi generali utilizzati nell ambito del versioning. Una configurazione è una istanza del documento ad un certo istante di tempo. Il paradigma di versioning utilizzato in IDN si applica alle configurazioni: ogni modifica (tempo discreta) alla configurazione genera una nuova revisione del documento. Con modifica si intende un operazione che comprende una o più variazioni all interno della configurazione durante un intervallo di tempo stabilito dall inizio e la fine della sessione di lavoro. L entità della modifica nel suo complesso è misurabile dall utente che in modo automatico dal sistema e dipende dall entità e dal numero delle singole variazioni elementari che la costituiscono. L insieme delle revisioni è una codifica dell evoluzione temporale delle configurazioni ed è quindi un insieme nel quale esiste un ordinamento totale: date due revisioni r a e r b si ha che r a < r b oppure r b < r a oppure r a e r b sono la stessa configurazione, dove con il simbolo < si indica l operatore meno aggiornato di. Lo storico di un documento descritto in questi termini è lineare ed è costituito dall insieme delle sole revisioni. Uno storico di questo tipo può essere sufficiente a modellare l evoluzione temporale di un informazione, ma può non essere abbastanza flessibile da favorire la cooperazione fra più utenti e, in generale, l authoring concorrente. Per avere la flessibilità necessaria occorre poter creare esplicitamente delle diramazioni (branch) all interno dello storico per permettere lo sviluppo concorrente (quindi in parallelo) su due o più rami indipendenti. Creare branch all interno di uno storico lineare porta ad avere una struttura dello storico ad albero. In questo caso con revisione si intende una nuova versione di un elemento presente in un determinato branch. Infine può risultare necessario far convergere (operazione di merge) due rami distinti su un unico ramo e così la struttura complessiva che si ottiene è un DAG. Il DAG permette quindi di rappresentare le relazioni fra un qualunque insieme di versioni di un informazione Resource Aggregation Service La logica interna di RAS è in grado di seguire i link associati ai nodi delle risorse PIU. Se la direzione seguita è verso le foglie del DAG allora si parla di aggregazione di PIU (per costruire un documenti), se invece è nel senso opposto si parla di propagazione delle versioni ai nodi aggreganti. L aggregazione prevede un meccanismo elementare che interessa solo gli aspetti strutturali, e proprio per questo più semplice da comprendere. Viceversa la propagazione delle versioni coinvolge sia concetti strutturali che di versionamento, pur lavorando operativamente sulla struttura. 238

257 Virtual Repository Service Resource Aggregation Service Vista sullo storico delle informazioni Il servizio di gestione del versioning (e non il versioning) di un documento viene fornito integralmente ed esclusivamente dal layer VR secondo le specifiche stabilite nel modello IDN-IM. Per discutere in dettaglio il servizio fornito da VR, e come questo sia conforme alle specifiche formulate in IDN-IM, è necessario evidenziare i seguenti aspetti sono tra loro indipendenti: la gestione dello storico del documento ovvero la direzione e l arbitraggio sulla creazione, l aggiornamento e il mantenimento della consistenza delle informazioni. Sebbene le operazioni elementari di versioning siano realizzate a livello sottostante (IH), spetta a VR stabilire la sequenza operativa della loro esecuzione, coinvolgendo i sottoservizi necessari; la navigazione nello storico del documento ovvero l insieme di tutti quei meccanismi finalizzati a fornire il servizio di indirizzamento all informazione versionata, in quanto deve essere possibile navigare nello spazio delle versioni dal livello superiore Relazioni strutturali Il DAG definito per il modello IDN-IM è ottenuto andando a considerare le informazioni atomiche, le informazioni primitive e i link di composizione. Si ricorda che IDN-IM definisce anche un altro tipo di relazione fra nodi che è rappresentata dai link di riferimento, ma tali link non hanno nessun legame con la gestione delle versioni, essendo informazioni atomiche (confronta 7.5.2). In riferimento al modello IDN-IM, in corrispondenza dei link di composizione, è necessario prevedere un meccanismo che permetta di propagare le modifiche dei figli verso i genitori. Tale algoritmo rientra a pieno titolo fra le mansioni legate alla gestione dello storico e pertanto deve essere definito ed applicato nel contesto del layer VR. VR deve quindi prevedere un secondo tipo di link, detto link di propagazione, che permetta di risalire nella gerarchia dei nodi presenti nel dominio del documento come richiesto dal modello IDN-IM. In corrispondenza di tutti i link di aggregazione esistono i duali link di propagazione che hanno verso opposto ai precedenti. I link di propagazione completano la vista strutturale sulle informazioni. Per chiarire questo concetto si faccia riferimento alla figura 10.2 nella quale il documento al tempo t 0 è costituito da una radice X1 che aggrega due figli Y1 e Z1 tramite opportuni link di composizione, rispettivamente C1 e C2. Esistendo una sola revisione di ogni nodo a tali link di composizione vengono associati i link di propagazione P1 e P2. Il documento al tempo t 1 appare dopo una modifica (in conformità al meccanismo previsto in IDN-IM) relativa a Y e propagata alla radice X. In questo caso i link di propagazione P1 e P2 sono stati rimossi e sono stati inseriti P3 e P4 in corrispondenza dei link di composizione C3 e C4 presenti nell ultima revisione della radice X. Per completezza espositiva osserviamo in figura 10.2 un terzo tipo di link, detto link di versione, che permette di rappresentare le relazioni presenti fra nodi ad istanti diversi. Fanno parte di questa categoria i legami esistenti fra una 239

258 Virtual Repository Service Resource Aggregation Service Documento al tempo t 0 Documento al tempo t 1 X1 X1 V2 X2 Y1 P1 C1 C2 P2 Z1 Y1 C1 V1 C2 P3 Y2 C3 C4 P4 Z1 Legenda: tipologie di link Link di Propagazione Link di Aggregazione Link di Versione Figura 10.2: Link di strutturali e di versioning revisione e la successiva, una revisione e la precedente etc. (tutte le tipologie di link che rientrano in questa categoria verranno introdotte dettagliatamente nel paragrafo 11.3 a pagina 262). La gestione integrale dei link di versione è indubbiamente di competenza del livello IH. In figura 10.2 è presente un esempio nel quale si ipotizza l esistenza dei soli link di versione presenti dalla revisione precedente a quella successiva. VR attua la propagazione delle versioni dai figli verso i genitori seguendo i link di propagazione. Prendendo l esempio precedente (figura 10.2), la nascita di una nuova versione del figlio (Y2) determina, tramite il meccanismo di propagazione, una nuova versione del genitore (X2) che deve essere connessa, tramite un link di composizione (C3), alla nuova versione del figlio. La creazione della nuova versione del genitore è a carico del layer IH il quale, su richiesta di VR. È VR a connettere tale elemento alla nuova versione del figlio manipolando i link di aggregazione (nell esempio si tratta di creare C3 e C4). Si osservi non esiste violazione della separation of concern tra VR e IH. È infatti sufficiente affidare a IH l onere di definire ed implementare le operazioni elementari per le versioni. In altre parole i link di versioning vengono gestiti esclusivamente da IH e mantenuti all interno dell header del nodo definito a questo livello. Però è necessario corredare l interfaccia, fornita a Virtual Repository, di opportune primitive e/o definire il formato dei messaggi scambiati fra i due livelli in modo da permettere a Virtual Repository di agire, secondo le proprie necessità e competenze, sugli aspetti strutturali del documento. Questo permette a Virtual Repository di inserire, modificare ed eliminare i link di 240

259 Virtual Repository Service Resource Aggregation Service composizione in base alle proprie esigenze e navigare nello spazio del documento. Questo approccio è simile a quello proposto da DOM [ABC + 04]: l interfaccia messa a disposizione permette di creare, modificare, cancellare e navigare fra i nodi dell albero del documento, lasciando alla applicazione (nel nostro caso VR) l invocazione delle funzionalità, l implementanzione del DOM ha l onere di attuare le funzionalità La propagazione delle modifiche Consideriamo l esempio di un libro costituito da capitoli, suddivisi a loro volta in paragrafi ed in ultima istanza da frasi. Modificare una frase significa modificare il paragrafo che la contiene, ma anche il capitolo contenente il paragrafo e quindi tutto il libro, sancendone quella che in termini tipografici viene detta nuova edizione. IDN-IM permette di modellare il comportamento descritto tramite il concetto di propagazione che viene applicato sui genitori in corrispondenza della nascita di una nuova revisione dei figli all interno del DAG. Si osservi che la richiesta di salvataggio di una variazione del contenuto di un nodo non genera necessariamente una nuova revisione (che dipende dallo stato iniziale in cui si trova il nodo): A riguardo si possono presentare due casi: frozen: il sistema crea una nuova revisione del nodo ed avvia il meccanismo di propagazione (viene creata una nuova revisione in quanto il nodo di partenza è congelato e non può essere modificato); changing: il sistema sovrascrive il contenuto del nodo e non attua nessuna propagazione. Nel seguito di questa trattazione, se non espressamente specificato, si assume che il caso frozen. Il motivo è dovuto al fatto che in corrispondenza della nascita di una nuova revisione occorre comunque apportare alcune variazioni (sovrascritture) alle strutture dati, interne al nodo di partenza. Nel caso di frozen il salvataggio è infatti costituito dalle seguenti fasi: 1. richiesta a IH della creazione della nuova revisione; 2. copia dei contenuti dalla informazione iniziale alla nuova revisione; 3. modifica del contenuto informativo della revisione; 4. esecuzione dell algoritmo di propagazione verso i genitori. Si noti, come osservato in precedenza, che in questa sede, a differenza del caso preso in esame in UEVM, la struttura di riferimento è un DAG e quindi ogni nodo può avere zero, uno o più genitori (mentre in UEVM può avere al massimo un genitore in quanto la struttura è un albero). Questo aspetto è ininfluente ai fini dell algoritmo di propagazione a patto di applicarlo a tutti i genitori presenti (senza ripetizioni). 241

260 Virtual Repository Service Resource Aggregation Service Applicazione delle diramazioni e delle fusioni Le operazioni di branching e di merging sono legate alla gestione dello storico di un documento. Nel momento in cui si crea un branch la gestione dell evoluzione temporale al suo interno risulta essere del tutto indipendente rispetto a quella relativa al documento di provenienza. Generare un branch equivale a creare un nuovo documento (duplicato) che abbia in comune con quello di partenza almeno un nodo dello storico. In conclusione all interno di ogni branch esiste un ordinamento totale delle revisioni che modella l evoluzione temporale del documento (relativo a quel branch), inoltre non esiste nessuna correlazione fra revisioni appartenenti a branch diversi, se non quella di avere predecessori (nello storico) comuni. L equivalenza a cui è stato appena fatto riferimento fra branch e nuovo documento non è soltanto concettuale, ma è stata sfruttata ampiamente nella pratica in molti SCM (Software Configuration Management), fra i quali il CVS [FB03] e Subversion [CSFP04]. È comunque utile riferirsi a Subversion come sistema di paragone in quanto utilizza il modello di versioning UEVM[Ask02]. Branching In Subversion creare un branch di un informazione primitiva significa creare, ricorsivamente, un branch di ogni nodo dell albero di cui essa è radice. Questo comportamento in IDN viene ottenuto richiedendo il branching dei nodi di interesse a Virtual Repository in quanto è un operazione applicata al documento come entità strutturata. Questa scelta permette di ottenere anche una maggiore flessibilità rispetto a quella di Subversion in quanto permette di ipotizzare l esistenza di diramazioni nelle quali non viene effettuato il branch di ogni nodo dell albero lasciando uno o più nodi in comune fra il branch e il ramo principale. Quest ultimo caso è messo in evidenza in figura 10.3 nella quale la radice G ha due figli: F e F. Il branch del documento è stato effettuato creando un branch della radice e del figlio F mentre il figlio F non è stato duplicato. Questo permette di propagare le modifiche di F in entrambi i rami di sviluppo (il ramo principale, che si sviluppa creando una nuova revisione di G2, e del branch che si sviluppa creando una nuova revisione di G2.1). In figura 10.4 è presente l effetto della propagazione. L azione scatenante è la modifica di F 2 che, al tempo T, genera la revisione F 3 e la propagazione avviene su entrambi i branch dando vita alle revisioni G3 nel ramo principale e G2.2 nel branch. Per semplicità il figlio F, presente in figura 10.3, non è stato riportato in quanto non viene modificato durante la propagazione: G3 continua ad aggregare F 2 come G2 e G2.2 continua ad aggregare F 2.1 come G2.1. Merging L operazione complementare al branching è il merging. Da un punto di vista operativo effettuare un merge significa integrare le modifiche presenti su un branch in un altro branch. L operazione può essere effettuata secondo modalità diverse che variano con il contesto. 242

261 Virtual Repository Service Resource Aggregation Service G1 G2 Radice G G2.1 F''1 F''2 Figlio F'' F'1 F'2 Figlio F' F'2.1 Figura 10.3: Branch in IDN-IM con un figlio condiviso G1 G2 G3 Radice G Legenda Tempo t < T Tempo t T F''1 F''2 G2.1 G2.2 F''3 T = istante della nascita del nodo F''3 Relazioni Nodi Abc Abc Figlio F'' Figura 10.4: Propagazione in presenza di un figlio condiviso Supponendo quindi di operare con documenti IDN occorre stabilire cosa significhi fondere informazioni atomiche e informazioni primitive, elementi che costituiscono i documenti presenti nei due branch di interesse. In realtà si ricorda che le informazioni atomiche sono incapsulate all interno di quelle primitive. È possibile definire un operazione di confronto fra due informazioni atomiche (che dipende dal tipo di informazione atomica trattata e quindi, in ultima analisi, dal contesto) che ne determina l uguaglianza o la differenza. Nel primo caso il merge è banale e il risultato è l informazione stessa; altrimenti l operazione di confronto può permettere di stabilire l entità della differenza e si possono presentare le seguenti situazioni: il contesto permette al sistema di scegliere una delle due informazioni automaticamente, scartando l altra; il contesto non permette al sistema di effettuare una scelta, in tal caso è l utente a dover prendere una decisione; 243

262 Virtual Repository Service Resource Aggregation Service le informazioni sono diverse, ma confrontabili nei contenuti: il sistema, automaticamente o sotto la supervisione dell utente, genera una terza informazione atomica sulla base di convenzioni prefissate. L ultimo caso è interessante perché è quello relativo all esempio, introdotto precedentemente, di Subversion: le informazioni atomiche sono rappresentate dal contenuto di file (molto probabilmente codice sorgente scritto in formato testuale); quindi è possibile applicare un confronto riga per riga, operazione che permette di integrare le differenze nel caso in cui non siano presenti conflitti (il sistema genera automaticamente la nuova versione) oppure è in grado di rilevarli e permette all utente di intervenire (il sistema genera la nuova versione sotto la supervisione dell utente). Per quanto riguarda le informazioni primitive, occorre specificare cosa si intende per uguaglianza tra di esse. Da un punto di vista astratto è possibile considerarle come il punto di accesso all informazione complessiva che si sviluppa da esse fino alle foglie, come evidenziato nel paragrafo Questo porta alla conclusione che il concetto di uguaglianza fra informazioni primitive non è esprimibile esclusivamente sulla base del confronto del contenuto informativo dei nodi che le rappresentano, ma in generale occorre andare a considerare e confrontare ricorsivamente i nodi che tali informazioni primitive aggregano. Dato che questo compito spetta ai livelli superiori occorre delegare a loro anche la scelta dei criteri finalizzati alla valutazione dell uguaglianza o meno tra informazioni di questo tipo. A seguito di questa considerazione è possibile concludere che IH deve fornire un supporto per il merging che permetta a VR di coprire tutte gli scenari possibili. In riferimento alla figura 10.5 la seguente definizione di merging, valida al livello VR, permette di ottenere questo risultato: fondere (merge) due elementi A e B (nodi IDN-IM) appartenenti a branch diversi dello stesso storico, significa generare un terzo elemento C ottenuto da essi a seguito dell esecuzione di un determinato algoritmo. Il nuovo elemento C figura nello storico come successore sia di A che di B e, per convenzione, appartiene al ramo di A. La definizione e l esecuzione dell algoritmo di generazione vengono lasciate al livello applicativo e possono essere quindi diversificate in base al contesto. Si osservi che, in questi termini, il merge è un operazione definita fra due branch che fonde il secondo sul primo. Questo si nota anche osservando che A e B devono essere l ultima revisione nel relativo branch, come mostrato in figura. L operatore di merge non è quindi commutativo: fondere A e B su C è diverso da fondere B e A su C. Nel primo caso C appartiene al ramo di A mentre nel secondo al ramo di B. Il fatto che l elemento C sia il successore di entrambi gli elementi si evidenzia considerando che, a seguito di un operazione di merge, viene attuata la propagazione delle versioni in modo equivalente su entrambi i branch di origine. Facendo riferimento alla figura 10.6 G 7, prima del merge, aggrega per composizione A mentre G 4 aggrega B. L operazione di merge ha come risultato C. La nascita di C avvia il processo di propagazione dando vita a G 8 e a G 5. Si osservi che effettuare il merge di un ramo su un altro è un operazione che determina, per convenzione, il raggiungimento della fine del branch; dopo aver 244

263 Virtual Repository Service Resource Aggregation Service Storico dell'elemento A C B Fusione o Merge A,B in C. Figura 10.5: Merge di due nodi G'7 G'8 G''4 G''5 A C B Nuove relazioni Vecchie relazioni Abc Abc Nuovi nodi Vecchi nodi Figura 10.6: Propagazione a seguito di un merge effettuato il merge non risulta più possibile generare nuove revisioni a partire dai nodi fusi l uno con l altro, i nodi A e B dell esempio precedente. Questa limitazione è soltanto apparente in quanto è possibile generare nuovi branch partendo da essi. In questo modo si può comunque simulare la strategia di lavoro che consiste nel portare avanti lo sviluppo su due branch separati integrando, quando necessario, le modifiche di uno nell altro. Infatti si può pensare che C appartenga ad uno dei due branch di partenza (ad esempio quello nel quale si trova A) mentre a partire dall altro (B) viene generato un nuovo branch 245

264 Virtual Repository Service Resource Aggregation Service sul quale continuare lo sviluppo. Un esempio relativo a questo caso è riportato in figura 10.7.a. In particolare A, B e C sono i nodi che in figura sono stati creati rispettivamente al tempo 1, 2 e 3. Lo sviluppo vuole essere portato avanti anche su un ramo secondario e per questo motivo viene creato, al tempo 4, un nuovo branch. Successivamente viene effettuato il merge con il ramo di sviluppo principale; si osservi che non è obbligatorio effettuare questa operazione immediatamente in quanto è possibile creare un numero arbitrario intermedio di nuove revisioni. Storico dell'elemento Storico dell'elemento Tempo Ramo Principale Merge Merge Branch 4 Ramo Secondario Branch 6 Tempo Ramo Principale Integrazione Integrazione Ramo Secondario a) Sequenze di branch e di merge. b) Integrazioni a livello applicativo. Figura 10.7: Gestione di due rami di sviluppo concorrente Un altra strategia possibile consiste nel definire un merge di livello applicativo che, a partire da B, integri le modifiche in A generando C, senza rendere B antenato di C a livello IH. In questo modo, partendo da B, è possibile continuare lo sviluppo generando nuove revisioni. Un esempio relativo a quest ultimo caso è riportato in figura 10.7.b, come in precedenza, i nodi A, B e C corrispondono rispettivamente a quelli creati al tempo 1, 2 e Osservazioni sugli aspetti strutturali Il branching e il merging sono stati definiti e discussi in riferimento ad un singolo nodo oppure in riferimento al caso di un nodo aggregato per composizione da altri nodi. Per quanto riguarda le relazioni figlio-genitori, necessarie per la gestione della propagazione delle modifiche, l aver considerato soltanto due livelli della gerarchia nella struttura del documento non è limitativo. Tutti i ragionamenti effettuati, possono essere estesi ricorsivamente permettendo quindi di risalire, livello dopo livello, la struttura di un qualunque documento, indipendentemente dalla sua profondità di albero. Al contrario le relazioni inverse, quelle genitore-figli, necessarie per modellare la struttura del documento, non vengono gestite dal livello IH e pertanto, 246

265 Virtual Repository Service Identity Service in questo contesto, non risulta strettamente necessario discutere come devono essere trattate in riferimento al branching e al merging. In ogni caso il branching e il merging di un documento, visto nella sua globalità, sono strettamente legati al versioning e risulta quindi interessante presentare alcuni possibili scenari nei quali si mostra come possono essere applicati in contesti reali. Si considerino, ad esempio, dei documenti (costituiti da un numero arbitrario di nodi) che devono essere trattati nei branch come un unica entità. Questo è esattamente il caso gestito da Subversion in quanto la copia del ramo principale in un branch è ricorsiva e si sviluppa dalla radice fino alle foglie dell albero, comprendendo tutti gli elementi. Per quanto riguarda IDN-IM questo significa creare un branch di ogni nodo secondo le modalità esposte in precedenza e connettere il nodo che si ottiene a seguito del branch di ogni genitore al nodo ottenuto dal branch dei figli come indicato in figura 10.8 per una sola informazione ed ulteriormente evidenziato in figura 10.9 per un intero documento. Storico dell'elemento genitore G1 G2 G2.1 Link di Composizione F1 F2 Link di Revisione F2.1 Link di Branch Storico dell'elemento figlio Figura 10.8: Branch di un nodo La fase di merging viene trattata in modo duale andando ad applicare opportuni algoritmi di confronto e generando una nuova versione per ogni coppia di nodi che vengono fusi. Si osservi che, in questo esempio, è necessario fondere tutti i nodi degli alberi relativi ai documenti D1 e D2 per ottenere un terzo documento che concettualmente rappresenta il risultato dell operazione Identity Service Identity Service (IS) è il servizio di autenticazione degli utenti che accedono al livello VR e delle richieste che sottopongono al sistema nel suo complesso. Anche se è logicamente localizzato nel livello più elevato di IDN, assume un ruolo 247

266 Virtual Repository Service Identity Service G Branch del documento Branch F1 F2 Doc. D1 G.1 Branch Branch F1.1 F2.1 D2 = branch di D1 Figura 10.9: Branch di un intero documento di servizio trasversale poichè per una larga parte della sua definizione si sfrutta e riusa la stessa infrastruttura IDN. Infatti è possibile rispondere alle seguenti domande facendo riferimento alle funzionalità di base offerte dal sistema: come sono rappresentati i dati delle Persona? dove risiedono i dati delle Persona? i permessi di accesso alle risorse (Access Control List, ACL) come sono rappresentati? dove sono memorizzate le ACL? chi valorizza le ACL? I dati personali sono rappresentati nel profilo utente: la risorsa Persona aggrega, in un documento IDN, le informazioni (dati e metadati) sufficienti e necessarie per identificare e autenticare l utente. Il luogo (sito) dove fisicamente queste informazioni sono memorizzate è un dettaglio che dipende dai livelli più bassi di IDN che attuano la replicazione (che in questa fase non è di necessario interesse). La verifica delle credenziali viene effettuata ricorrendo a tecniche crittografiche come suggerito dai principali standard analizzati nel capitolo 2. Per le ACL, create ed assegnate dal responsabile dell informazione, si adotta una rappresentazione anch essa memorizzata in un documento IDN Identità e profilo utente Il concetto di identità digitale e gli aspetti della sua gestione sono un punto fondamentale dei servizi messi a disposizione in rete. L identità rappresenta il 248

267 Virtual Repository Service Identity Service modo in cui l utente viene riconosciuto o si fa riconoscere nel sistema. La creazione dell identità generalmente prevede, nella sua forma essenziale, la creazione di credenziali. Senza entrare nel dettaglio delle scelte tecniche di come generare le credenziali, risulta evidente che è necessario fornire, agli interessati, un certo insieme di dati personali atti a farsi riconoscere. Ad esempio si potrebbe inserire nel documento IDN che rappresenta il profilo il certificato digitale dell utente ed utilizzare i meccanismi previsti nelle PKI (capitolo 2) per creare (in modo sicuro) l associazione fra la persona fisica che sta tentando di accedere al sistema ed il profilo stesso. Più un utente si fa riconoscere dal sistema, più il sistema è in grado di erogare dei servizi a valore aggiunto, personalizzati ai suoi bisogni. Dualmente più una organizzazione riesce a conoscere i tratti qualificanti dei propri utenti/clienti più ha probabilità di soddisfarne i desideri e necessità (perseguendo il proprio profitto). Ecco perchè molte aziende trovano conveniente la profilazione dei propri utenti e clienti (a volte anche in derogao violazione a normative e leggi [Inf08]). Possiamo classificare due tipologie di profilo: 1. limitato: insieme di informazioni personali categorizzate a priori e staticamente predefinite in quantità e tipo di dato; 2. dinamico: insieme di informazioni incrementabili nel tempo e senza limitazioni di quantità e tipo di dato. Osserviamo che non è possibile stabilire a priori gli attributi di cui deve essere dotato un profilo di un identità digitale Persona poichè sono infinite i possibili ruoli assunti (dall ambito personale a quello professionale, da quello lavorativo a quello istituzionale). Sebbene esistano degli attributi di base, verosimilmente comuni a tutte le persone, è riduttivo ingessare il profilo di un utente ad un insieme limitato di dati e contemporaneamente pretendere che il profilo sia scalabile e riusabile in tutti i contesti ed applicazioni. Se volessimo costruire un profilo utente scalabile, riusabile, qualificabile e quantificabile nel tempo, allora è possibile affermare che IDN-IM risponde alla esigenze evidenziate. Si pensi ad un profilo composto da un insieme minimo di dati (nome, cognome, data di nascita, luogo di nascita o poco più) e di poterlo incrementare ed aggiornare nel tempo aggiungendo o rimuovendo altre informazioni, ora di ambito lavorativo ora di ambito personale. Per raggiungere questo obiettivo è possibile sfruttare la struttura a DAG e le aggregazioni del documento IDN per costruire profili utente dinamici. Partendo dalle informazioni di base (quelle essenziali alla identificazione) è possibile aggregarne ulteriori in modo completamente personalizzabile. Per costruzione, versatilità ed adattabilità sono le caratteristiche principali di questo profilo, che attraverso il versionamento, consente anche di costruire e ricostruire la storia di una Persona. Il principio di responsabilità è inoltre a garanzia della privacy purchè le ACL siano ben definite: la persona è proprietaria delle proprie informazioni; 249

268 Virtual Repository Service Identity Service la persona può verificare chi le ha aggregate e/o arricchite (risoluzione diretta ed inversa di LS-LDNS). Un profilo così strutturato comporta le seguenti notevoli implicazioni: dal punto di vista della persona: rispetto delle normative e controllo completo delle proprie informazioni, con possibilità di verificare eventuali abusi; dal punto di vista dell erogatore dei servizi: incremento personalizzato di informazioni senza limitazioni Access Control List (ACL) L accesso ad ogni elemento definito nel contesto del sistema IDN viene concesso a fronte di una verifica di opportune liste di accesso, basate sull approccio white-list. Con elemento si intende una qualsiasi inforamzione-dato o processo che rientra nel contesto del sistema, a partire dalle informazioni primitive e dai nomi LRI per finire ai nomi PRI e le istanze dei livelli che erogano i servizi. In questo paragrafo verranno presi in esame solo informazioni primitive ed gli LRI perché è su di essi che vengono verificate le ACL sulla base della Persona che sta accedendo al sistema. Le altre entità, seppur tenute in considerazione (eventualmente anche sulla base della Persona che sta accedendo al sistema), entrano in gioco indirettamente e pertanto non verranno esaminate in questa sede. Con accesso si intende la richiesta di una qualche operazione sull entità: ad esempio una richiesta di lettura, di modifica, di creazione oppure (in esclusivo riferimento agli LRI) di risoluzione. Con verifica si intende un procedimento algoritmico che, date tutte le variabili di interesse, fornisce un risultato che può essere: accesso consentito: in questo caso il sistema è autorizzato ad espletare l operazione richiesta per conto dell utente; accesso negato: in questo caso il sistema non è autorizzato ad espletare (e quindi non effettuerà) l operazione richiesta. Ad esempio per l accesso in lettura ad una informazione primitiva, i dati e le relazioni da valutare e verificare sono (nella formulazione più elementare): le credenziali dell utente; i gruppi/ruoli a cui appartiene; l identificatore dell informazione primitiva. Le condizioni in gioco posso comunque essere estese aggiungendo vincoli di tipo temporale per permettere l accesso (o meno) sulla base dell istante in cui l utente effettua le richiesta. Con approccio white-list si intende che l algoritmo di verifica opera seguendo la direttiva che tutto è negato, salvo ciò che è stato esplicitamente dichiarato come permesso. 250

269 Virtual Repository Service Identity Service Permessi sui nomi Le informazioni primitive sono dotate di LRI che possono essere canonical name (assimilabili al record A nel DNS) oppure alias (assimilabili al record CNAME del DNS). Per ogni risorsa esiste sempre uno ed un solo LRI canonico, determinato alla prima creazione. Zero o uno o più alias possono essere creati in tempi successivi. Ai singoli LRI sono associati i metadati per la gestione delle ACL che, nel caso specifico, permettono di abilitare le seguenti operazioni (si ricorda che le voci nella ACL servono per fornire dei diritti, ciò che non è elencato, ovvero autorizzato, non è permesso): risoluzione: è possibile richiedere la risoluzione da LRI in PRI; accesso al nome: è possibile richiedere l esistenza del nome. Permette all utente di stabilire se il nome esiste o meno. Inoltre entra in gioco nel supporto alla navigazione (paragrafo 9.5.4): le liste fornite a seguito delle richieste di appartenenza a contengono solo gli elementi per i quali il richiedente ha diritto di accesso; eliminazione del nome. È possibile eliminare il nome (si noti che gli utenti del sistema non potranno avere il diritto di cancellare dei nomi canonici che, per definizione, restano immutati per tutto il ciclo di vita dell informazioni a cui fanno riferimento; viceversa possono essere autorizzati ad eliminare alias); aggiunta di alias. È possibile creare un nuovo alias del nome per il quale è stato autorizzato questo tipo di operazione. Permessi sulle informazioni Per quanto riguarda le informazioni primitive la gestione dei diritti di accesso è più articolata. Fermo restando l approccio a white-list, è infatti necessario discriminare fra operazioni che possono essere svolte sull informazione nel suo complesso e quelle sulle singole entità (dati e metadati) in essa contenuti. Le operazioni che possono essere svolte sulle informazioni primitive (PIU) sono le seguenti: accedere: è possibile stabilire se la PIU esiste oppure no; elencare contenuti: è possibile visualizzare l elenco dei dati e dei metadati, sui quali si ha diritto di accesso (che la PIU contiene); aggiungere informazioni: è possibile aggiungere dati e metadati alla PIU; rimuovere elementi: è possibile rimuovere dati e metadati dalla PIU; cancellare: è possibile poter rimuovere la PIU permanentemente dal sistema (si noti che ciò non significa che sia necessariamente assegnato questo diritto agli utenti del sistema). 251

270 Virtual Repository Service Identity Service Di seguito invece vengono elencate le operazioni che possono essere svolte sui singoli elementi (dati e metadati) contenuti all interno delle PIU: accedere: è possibile stabilire se l elemento esiste o meno; leggere: è possibile accedere per la lettura all elemento in questione; modificare: è possibile accedere per la modifica all elemento in questione. Se un utente non dispone del diritto di accesso, la risposta sarà come se l informazione non esistesse. Il diritto di elencare i contenuti di una informazione primitiva (accedere alla lista dei dati e dei metadati in essa contentuti) discende dal fatto che sia possibile accedere a ciò che contiene. Ovviamente tale lista sarà costituita esclusivamente dai dati e dai metadati per i quali l utente ha i diritti di accesso. Se un utente non dispone del diritto di elencare viene negata la possibilità di navigare nello spazio dell informazione. Il diritto di aggiungere o rimuovere elementi significa disporre della facoltà di inserire nuovi dati o metadati all interno della PIU oppure di rimuoverne alcuni coerentemente con i vincoli imposti dalla ACL. 252

271 Capitolo 11 Information History Service IDN Information History Service (IH) implementa l insieme dei servizi necessari per il versionamento delle informazioni, agendo come se fossero strutturate. Tale insieme è rappresentato come un livello che si colloca tra il Virtual Repository Service ed il Replica Management Service nella architettura IDN-SA. Internamente al livello viene implementato il Version Traversing Algorithm (VTA) che consente di spostare l handle alla versione corrente ad un altra sulla indicazione del parametro di versione che gli viene fornito. Nel presente capitolo saranno definiti il data model per la rappresentazione delle informazioni, i servizi offerti e l interfaccia La navigazione nello storico Il layer IH gestisce l evoluzione temporale dei documenti e si attiva a seguito di richieste che nascono ai livelli superiori. La gestione interna dello storico è necessaria, ma affinché sia efficace, occorre che questo livello fornisca anche dei metodi per la navigazione all interno dell insieme storico di dati (la rappresentazione delle versioni per la medesima informazione). Si ricorda che due versioni diverse della stessa informazione sono codificate all interno di due nodi distinti di livello IH i quali hanno un proprio indirizzo univoco (PRI) che li identifica. Tali elementi possono essere messi in relazione tramite link di versione, ma focalizzando l attenzione sull entità nodo, senza analizzare il suo contenuto, non è possibile distinguere se questo contiene una determinata versione di una certa informazione oppure un altra informazione. In questi termini quindi due versioni differenti sono considerate due informazioni distinte come nel caso di un informazione primitiva che aggrega, per composizio-

272 Information History Service La navigazione nello storico ne, un altra informazione primitiva oppure di due informazioni che non hanno nessun legame fra loro. Alla luce di questa considerazione è possibile evidenziare come, senza aggiungere ulteriori condizioni, il livello Virtual Repository possa accedere ad ogni elemento dello storico di una data informazione semplicemente conoscendone l indirizzo univoco PRI. Ovviamente un meccanismo di indirizzamento di questo genere, che si basa su indirizzamento assoluto, non è sufficiente ad una gestione flessibile dello storico. La scelta effettuata consiste nell introdurre un meccanismo di navigazione relativo all interno dello spazio delle versioni. L accesso ai nodi informativi avviene tramite l indirizzo persistente del nodo al quale può essere aggiunto un parametro di versione. Il parametro di versione è opzionale per permettere la navigazione anche in termini assoluti. L uso del parametro di versione in abbinamento ai PRI permette di introdurre una definizione formale degli indirizzi relativi al livello IH. Tali indirizzi sono definiti con la sintassi esposta in in figura 11.1 con notazione BNF. <hist-address> ::= <pri>"#"<vers_param> <vers_param> ::= "R_NEXT" "R_PREV" "H_ROOT" "B_ROOT" "T_ABSLAST" "T_RELATLAST" "B_LAST" "H_GRAPH" <pri> ::= definizione nel capitolo 9 Figura 11.1: Sintassi degli indirizzi di livello IH Version Traversing Algorithm Il raggiungimento di una versione avviene attraversando lo storico (navigazione) per passi iterativi iniziando da uno degli elementi il cui indirizzo persistente è noto ai livelli superiori. Prendendo come riferimento il nodo in questione viene richiesto, secondo un indirizzo relativo, un altro nodo presente nello storico della stessa informazione. L esempio più semplice che può essere menzionato riguarda la navigazione fra una revisione e la successiva o la precedente. Partendo, ad esempio, dall elemento N 0 è possibile procedere in avanti nelle revisioni operando nel modo seguente: N 1 richiedi(n 0,rev_successiva) N 2 richiedi(n 1,rev_successiva) N 3 richiedi(n 2,rev_successiva)... richiedi(a,b) 1 è un metodo che permette a Virtual Repository di richiede- 1 È un GET in cui i parametri sono codificati nell indirizzo della risorsa 254

273 Information History Service La navigazione nello storico re il nodo che partendo da A è raggiungibile tramite il parametro di versione B I parametri di versione In questo sotto paragrafo vengono descritti i parametri di versione che sono stati individuati e ritenuti utili nella fase di analisi. Nella definizione è stata usata la seguente convenzione: il nome del parametro è diviso, tramite il simbolo, in due parti: la prima è una singola lettera e serve per identificare l ambito in cui opera (i valori ammessi sono: R per revision, H per history, B per branch ed infine T per time), la seconda è una stringa che definisce una relazione all interno del contesto in cui il parametro è definito. I parametri, riportati di seguito, sono accompagnati da una breve descrizione: R_NEXT: Revision, Next. Si riferisce alla revisione successiva del nodo corrente. Si osservi che, a seguito di una richiesta con tale parametro di versione, possono presentarsi i seguenti casi: non esiste la revisione successiva: la risposta è quindi negativa. Questo è il caso dell ultimo elemento presente nel ramo; esiste la revisione successiva: la risposta fornisce il nodo che la contiene; ortogonalmente il nodo può essere radice di un branch, in questo caso la risposta contiene, se esiste, il nodo relativo alla revisione successiva e l indirizzo univoco (PRI) del primo elemento del branch. In questo modo viene soddisfatta la richiesta relativa alla revisione successiva e i livelli superiori vengono messi a conoscenza dell esistenza del branch con la possibilità di indirizzarli. R_PREV: Revision, Previous. Si riferisce alla revisione precedente del nodo corrente. In modo duale a R_NEXT possono presentarsi i seguenti casi: non esiste la revisione precedente: la risposta è quindi negativa. Ciò si verifica solo per la radice dello storico; esiste la revisione precedente: la risposta fornisce il nodo che la contiene. il nodo può essere stato creato come nuova revisione o in seguito ad un operazione di merge. In quest ultimo caso, similmente a quanto è stato definito per le diramazioni, nella risposta sono presenti il nodo che contiene la revisione precedente (che si trova sullo stesso ramo del nodo di partenza) e l indirizzo univoco (PRI) dell elemento precedente presente nell altro branch. H_ROOT: History, Root. Questo parametro di versione si riferisce alla radice dello storico ovvero al primo elemento che è stato creato. B_ROOT: Branch, Root. Si riferisce alla radice del branch ovvero all elemento che è stato preso come riferimento per creare il branch. Si osservi 255

274 Information History Service La navigazione nello storico che per quanto riguarda i nodi appartenenti al ramo principale B_ROOT coincide con H_ROOT. T_ABSLAST: Time, Absolute Last. Elemento dello storico più recente (da un punto di vista temporale). T_RELATLAST: Time, Relative Last. Elemento più recente presente nello storico, relativamente al nodo di partenza ovvero per il quale tale nodo figura fra gli antenati. Equivale al T_ABSLAST dello storico ipotetico ottenuto considerando tutti i nodi dello storico iniziale a partire dal nodo in esame (tale nodo rappresenta quindi la radice dello storico ipotetico). Storico completo dell'elemento T_ABSLAST H_ROOT B_ROOT 4 6 R_NEXT B_LAST Il numero rappresenta l'istante t di creazione della versione. R_PREV Elemento di riferimento T_RELATLAST Storico ipotetico relativo all'elemento creato al tempo t=7 Figura 11.2: Esempio di elemento recente rispetto al nodo di partenza In figura 11.2 è riportato un esempio: il nodo preso come riferimento è quello creato al tempo t=7. L elemento T_ABSLAST relativo ad un qualunque elemento dello storico, e quindi anche al nodo creato al tempo t=7, è il nodo creato al tempo t=16. La risoluzione dell elemento T_RELATLAST, ovvero quello più recente relativamente al nodo creato a t=7, è il T_ABSLAST dello storico ipotetico di cui il nodo creato a t=7 è la radice e, nel caso specifico, è rappresentato dall elemento creato al tempo t=12. B_LAST: Branch, Last. Ultima revisione del branch. In riferimento al caso riportato in figura 11.3 il B_LAST relativo ai nodi A, C, E ed F è F, mentre quello relativo ai nodi B e D è D. H_GRAPH: La struttura dello storico. Quest ultimo parametro di versione si differenzia dagli altri in quanto non è utilizzato per ottenere una particolare versione di N all interno dello storico, ma per permettere a Virtual Repository e/o Application di avere una visione globale dello storico stesso. La struttura viene fornita, opportunamente codificata all interno di un documento IDN-IM, sotto forma di DAG nel quale ogni elemento contiene l indirizzo univoco (PRI) del corrispondente nodo nello storico ed eventualmente altri metadati di interesse. La struttura può essere completa o 256

275 Information History Service Interfaccia Ramo Principale A C E F B Branch D B_LAST sul ramo principale B_LAST sul branch Figura 11.3: Esempi di last relativi al branch parziale (ad esempio localizzata nell intorno del nodo di riferimento) e questo aspetto viene gestito tramite un opportuno attributo specificato nella richiesta. Si osservi che lo stesso risultato che si ottiene tramite questo parametro di versione può essere raggiunto, a livello Virtual Repository, visitando tutto il grafo relativo allo storico dell informazione di interesse tramite l uso degli altri parametri di versione che IH mette a disposizione. H_GRAPH non è da considerarsi quindi utile nell ottica dell efficacia del sistema, ma in quella dell efficienza. I benefici di questa soluzione sono evidenti facendo in modo che IH codifichi (e mantenga aggiornato) il grafo associato allo storico su un opportuna struttura dati e che quindi riesca a soddisfare la richiesta senza effettuare la visita (al posto di Virtual Repository) di tutto lo storico. Considerando che i nodi dello storico sono, per definizione, non eliminabili, la struttura può solo crescere nel tempo. Questo vincolo permette tuttavia di ideare soluzioni per la sua memorizzazione e gestione che scalino, senza difficoltà, all aumentare della dimensione ricorrendo ad opportune tecniche di partizionamento. La definizione e l introduzione effettiva di questa primitiva vengono lasciate a sviluppi futuri Interfaccia La finalità del layer IH è quella di fornire al layer Virtual Repository il servizio di mantenimento e memorizzazione dell evoluzione temporale dell informazione attraverso la definizione e gestione del relativo storico e della navigazione all interno di esso. Per Virtual Repository il layer IH è quindi un entità remota alla quale effettuare richieste di servizio. Per raggiungere questo risultato occorre definire un protocollo di comunicazione che permetta alle due entità di interagire. Nel paragrafo verrà definita l interfaccia secondo il formalismo dei diagrammi dei casi d uso di UML. La finalità è quella di presentare i vari tipi di richieste che possono essere effettuate ad alto livello a IH dando, allo stesso tempo, una breve descrizione delle azioni che vengono svolte dal layer. 257

276 Information History Service Interfaccia Successivamente viene introdotta, con la stessa modalità, l interfaccia vista da IH messa a disposizione da Replica Management. Questo è utile per evidenziare come IH si avvalga del livello Replica Management per soddisfare le richieste effettuate da Virtual Repository. Per convenzione è stato scelto di assegnare i nomi ai casi d uso nel modo seguente: identificativo sistema.identificativo contesto.numero. L identificativo del sistema permette di associare il caso d uso ad un sistema specifico, in questo caso IH corrisponde a Information History e Rep a Replica Management. L identificativo del contesto specifica a quale entità del sistema il caso d uso si riferisce, ad esempio Int è l interfaccia. Infine il numero sequenziale permette di creare un nome univoco per ogni caso d uso come richiesto per rispettare le specifiche dettate da UML. Nella descrizione che segue con sistema si intende il layer IH, principale soggetto dell interazione. In figura 11.4 è riportato il diagramma dei casi d uso che permette di riassumere graficamente le primitive che IH espone a Virtual Repository. Information History IH.int.GET IH.int.CREATE IH.int.MARK Virtual Repository IH.int.COMMIT IH.int.BRANCH IH.int.MERGE Figura 11.4: Repository Casi d uso relativi all interfaccia mostrata da IH a Virtual Caso d uso: IH.Int.GET ID: UC.IH.Int.1 Attori: Virtual Repository. 258

277 Information History Service Interfaccia Precondizioni: 1. Deve essere noto il PRI del nodo N. Sequenza degli eventi: 1. Il caso d uso inizia quando il Virtual Repository ha la necessità di accedere ad un elemento presente nello storico di N ed effettua la richiesta di accesso specificando il PRI di N e il parametro di versione. Il parametro di versione può essere (si ricorda che la definizione dei parametri di versione è presente nel sotto paragrafo a pagina 255): nessuno: per richiedere la versione corrente (esattamente il nodo N); R_NEXT: per richiedere la versione successiva; R_PREV: per richiedere la versione precedente; H_ROOT: per richiedere la prima versione del nodo; B_ROOT: per richiedere la radice del branch (nel caso in cui il nodo appartenga al ramo principale B_ROOT coincide con H_ROOT); T_ABSLAST: per richiedere l ultima versione creata (più recente da un punto di vista temporale) presente all interno dello storico completo; T_RELATLAST: per richiedere l ultima versione creata (più recente da un punto di vista temporale) che ha il nodo di partenza fra gli antenati nello storico; B_LAST: per richiedere l ultima versione presente nel branch corrente; H_GRAPH: per richiedere il DAG che rappresenta lo storico del nodo N. 2. Il sistema, partendo da N, richiede a Replica Management tutti i nodi necessari al raggiungimento di N x (nodo richiesto tramite il parametro di versione). 3. Il sistema restituisce il nodo N x a Virtual Repository oppure un messaggio di errore. Scenari secondari: 1. Se viene richiesta la versione R_NEXT di un nodo nel quale hanno origine uno o più branch, il sistema risponde fornendo la nuova revisione (se esiste) e la lista di indirizzi del primo elemento di ogni branch. Questo permette al Virtual Repository di creare una nuova richiesta sul branch di interesse. 2. Se viene richiesta la versione R_PREV di un nodo ottenuto tramite un operazione di merge il sistema risponde fornendo la revisione precedente e l indirizzo del genitore presente nell altro branch. Caso d uso: IH.Int.COMMIT 259

278 Information History Service Interfaccia ID: UC.IH.Int.2 Attori: Virtual Repository. Precondizioni: 1. I nodi interessati devono esistere 2 ed essere stati precedentemente marcati come RELAXED, LOCKED STRONG o LOCKED SOFT dal richiedente del COMMIT, caso d uso UC.IH.Int.5. Sequenza degli eventi: 1. Il caso d uso inizia quando il Virtual Repository ha la necessità di salvare un documento o parte di esso ed effettua la richiesta di commit specificando quali nodi sono stati modificati. 2. Il sistema sovrascrive o crea nuove versioni di tali nodi in base alla politica di gestione esistente (legata allo stato UPDATE). 3. Vengono eseguiti gli algoritmi di propagazione delle versioni. 4. Il sistema restituisce un messaggio al Virtual Repository che può essere positivo o di errore. Caso d uso: IH.Int.CREATE ID: UC.IH.Int.3 Attori: Virtual Repository. Sequenza degli eventi: 1. Il caso d uso inizia quando Virtual Repository ha la necessità di creare un nuovo documento o di aggiungere nuovi elementi ad un documento esistente; in entrambi i casi effettua una richiesta di creazione di nuovi nodi. 2. Il sistema effettua una richiesta di creazione a Replica Management per ogni nodo da creare. 3. Il sistema restituisce un messaggio al Virtual Repository che può essere positivo (in tal caso contiene il PRI del nuovo nodo) o di errore. Caso d uso: IH.Int.BRANCH 2 Per inserire nuovi elementi occorre fare riferimento al caso d uso UC.IH.Int.3 260

279 Information History Service Interfaccia ID: UC.IH.Int.4 Attori: Virtual Repository. Precondizioni: 1. I nodi di partenza devono esistere. Sequenza degli eventi: 1. Il caso d uso inizia quando Virtual Repository ha la necessità di creare un branch nello storico di uno o più nodi. 2. Il sistema crea un nuovo nodo (riferimento ad UC.IH.Int.3) e copia in esso il contenuto della versione indicata del nodo di partenza oppure, se specificato da Virtual Repository, direttamente il nuovo valore che il nodo deve assumere. 3. Il sistema inserisce nell elemento di partenza le informazioni necessarie per accedere al nuovo branch nella fase di navigazione dello storico. 4. Il sistema restituisce un messaggio a Virtual Repository che può essere positivo (in tal caso contiene il PRI del nuovo nodo, radice del branch) o di errore. Caso d uso: IH.Int.MARK ID: UC.IH.Int.5 Attori: Virtual Repository. Precondizioni: 1. I nodi di interesse devono esistere. 2. Il nodo non deve avere nuove versioni ovvero deve essere l elemento più recente del branch affinché le etichette RELAXED, LOCKED STRONG o LOCKED SOFT possano essere applicate. Sequenza degli eventi: 1. Il caso d uso inizia quando Virtual Repository ha la necessità di marcare una lista di nodi e per farlo utilizza i seguenti parametri (i primi due possono essere applicati contemporaneamente): OBSERVED, per mettere i nodi sotto osservazione; RELAXED, per indicare che l utente è interessato alla modifica dei nodi (con il fine di applicare una strategia di aggiornamento ottimistica massimizzando l awareness di alto livello); 261

280 Information History Service Information History Data Model LOCKED_STRONG, per acquisire il lock Strong (sia in lettura che in scrittura, vedi il sotto paragrafo 7.8.1) sui nodi; LOCKED_SOFT, per acquisire il lock Soft (solo in scrittura, vedi il sotto paragrafo 7.8.1) sui nodi; NULL, per indicare che si intendono rimuovere tutte le etichette. 2. Il sistema accede ai vari nodi ed assegna gli identificativi in modo atomico. 3. Nel caso in cui tale operazione risulti possibile restituisce un messaggio positivo, altrimenti di errore. Caso d uso: IH.Int.MERGE ID: UC.IH.Int.6 Attori: Virtual Repository. Precondizioni: 1. Devono esistere due nodi N b1 e N b2 che rappresentato l ultima revisione presente nei branch distinti b 1 e b 2 appartenenti allo stesso storico. Sequenza degli eventi: 1. Il caso d uso inizia quando Virtual Repository ha la necessità di fondere i due branch b 1 e b 2 su un unico ramo e specifica i PRI di N b1 e N b2 e il nodo (nuovo) N succ creato dall unione di N b1 e N b2. 2. Il sistema crea un nuovo nodo, inserisce in esso N succ, lo rende successore di N b1 ed N b2 ed appartenente al ramo di N b1. 3. Il sistema restituisce un messaggio a Virtual Repository che può essere positivo o di errore Information History Data Model In questo paragrafo viene introdotta la struttura dati necessaria per definire, gestire e mantenere lo storico di un informazione che, in questo caso, è da considerarsi come nodo del layer IH. La struttura viene definita tramite un XML Schema, standard preso come riferimento in IDN per la modellazione dei dati, del formato dei messaggi dei protocolli, eccetera 3. Viene riportato lo XML Schema che permette di descrivere i nodi del modello IDN-IM a livello IH sia in formato testuale che in formato grafico nelle 3 La scelta di XML per la modellazione dei dati è stata dettata dalla flessibilità, compatibilità e portabilità che questo standard offre. 262

281 Information History Service Information History Data Model figure 11.5 e Tali figure evidenziano la struttura, i dati e i metadati presenti in un nodo senza entrare nel dettaglio della sintassi degli XML Schema. In particolare la prima rappresenta una visione generale della struttura tralasciando i link di versione (ovvero i link che permettono di generare le relazioni fra nodi all interno dello storico), la seconda rappresenta proprio tali link. Lo Schema non è stato commentato in quanto, in caso contrario, sarebbe risultato eccessivamente dispersivo. Un accurata descrizione di esso è comunque presente nel sotto paragrafo successivo; gli elementi vengono descritti nello stesso ordine con il quale compaiono nello Schema. Lo Schema è il seguente: <?xml version="1.0" encoding="utf-8"?> <xs:schema xmlns:xs=" <! > <xs:annotation> <xs:documentation> XML Schema - Definizione nodi IDN-IM a livello IH Author: Davide Chini & Samuele Innocenti Date: 07/12/2008 Revision: 0.2 </xs:documentation> </xs:annotation> <! > <xs:include schemalocation="pri.xsd" /> <xs:complextype name="sign"> <xs:sequence> <xs:element name="datetime" type="xs:datetime" /> <xs:element name="author" type="pri" /> <xs:element name="ihprocessid" type="xs:anytype" /> </xs:sequence> </xs:complextype> <xs:simpletype name="updatestateenum"> <xs:restriction base="xs:nmtoken"> <xs:enumeration value="changing" /> <xs:enumeration value="frozen" /> </xs:restriction> </xs:simpletype> <xs:element name="node"> <xs:complextype> <xs:sequence> <xs:element name="header"> <xs:complextype> <xs:sequence> <xs:element name="nodeid" type="pri" /> <xs:element name="concurrency"> <xs:complextype> 263

282 Information History Service Information History Data Model <xs:sequence> <xs:element name="observed" type="pri" minoccurs="0" maxoccurs="unbounded" /> <xs:element name="relaxed" type="pri" minoccurs="0" maxoccurs="unbounded" /> <xs:choice> <xs:element name="lockstrong" type="pri" /> <xs:element name="locksoft" type="pri" /> </xs:choice> </xs:sequence> </xs:complextype> </xs:element> <xs:element name="ih"> <xs:complextype> <xs:sequence> <xs:element name="child" type="pri" minoccurs="0" maxoccurs="unbounded" /> <xs:element name="parent" minoccurs="0" maxoccurs="unbounded"> <xs:complextype> <xs:simplecontent> <xs:extension base="pri"> <xs:attribute name="backpropagation" type="xs:boolean" /> </xs:extension> </xs:simplecontent> </xs:complextype> </xs:element> </xs:sequence> </xs:complextype> </xs:element> <xs:element name="history"> <xs:complextype> <xs:sequence> <xs:element name="historyid" type="pri" /> <xs:element name="versionid"> <xs:simpletype> <xs:restriction base="xs:string"> <xs:pattern value="([1-9][0-9]*\.[1-9][0-9]*\.)*[1-9][0-9]*" /> </xs:restriction> </xs:simpletype> </xs:element> <xs:element name="created" type="sign" /> <xs:element name="modified" type="sign" /> <xs:element name="update" 264

283 Information History Service Information History Data Model type="updatestateenum" /> <xs:element name="versionlinks"> <xs:complextype> <xs:sequence> <xs:element name="revisionnext" type="pri" minoccurs="0" maxoccurs="1" /> <xs:element name="branch" minoccurs="0" maxoccurs="unbounded"> <xs:complextype> <xs:sequence> <xs:element name="firstrevision" type="pri" /> <xs:element name="branchlast" type="pri"/> </xs:sequence> </xs:complextype> </xs:element> <xs:element name="revisionprevious" type="pri" minoccurs="0" maxoccurs="2" /> <xs:element name="branchroot" type="pri" minoccurs="0" maxoccurs="1" /> <xs:element name="historyroot" type="pri" /> <xs:element name="timelast" type="pri" minoccurs="0" maxoccurs="1" /> </xs:sequence> </xs:complextype> </xs:element> </xs:sequence> </xs:complextype> </xs:element> </xs:sequence> </xs:complextype> </xs:element> <xs:element name="body" type="xs:anytype" /> </xs:sequence> </xs:complextype> </xs:element> </xs:schema> Descrizione dello Schema XML La prima entità (<xs:include schemalocation=pri.xsd />) serve per includere un altro Schema, per la precisione pri.xsd, che contiene la definizione 265

284 Information History Service Information History Data Model nodeid 0..* observed concurrency 0..* relaxed lockstrong locksoft header structure 0..* child node 0..* parent historyid history versionid created + modified + update versionlinks + anytype body 0..* anyelement Figura 11.5: Albero di XML Schema: visione globale degli indirizzi univoci e persistenti (PRI) definiti in IDN-IM (evidenziata in figura 11.7). Si ricorda che che nel paragrafo 9.3 è riportata un descrizione dettagliata degli indirizzi PRI e una loro definizione formale sia tramite espressione regolare (presente all interno del tag xs:pattern in figura 11.7) che notazione BNF. Le entità successive definiscono sign e updatestateenum. Il primo di essi contiene la firma che IH applica al nodo in fase di creazione e/o di modifica e contiene tutti i parametri ritenuti utili per l identificazione dell operazione. Si osservi che la definizione di tale elemento può essere estesa e/o modificata. L elemento ihprocessid rappresenta l identificativo univoco 266

285 Information History Service Information History Data Model histotyid history versionid created + modified revisionnext update 0..* branch firstrevision versionlinks 0..2 revisionprevious branchlast 0..1 branchroot historyroot 0..1 timelast Figura 11.6: Albero di XML Schema: particolare dei link di versione <xs:simpletype name="pri"> <xs:restriction base="xs:anyuri"> <xs:pattern> <!-- la regex è su due righe per motivi tipografici --> value="urn:pri:(0\. ([1-9][0-9]*)\.)*(0 ([1-9][0-9]*)) /[0-9a-zA-Z\-_.,();:=+$!~* ]+" </xs:pattern> </xs:restriction> </xs:simpletype> Figura 11.7: XML Schema per la definizione di indirizzi PRI del processo di livello IH che ha effettuato l operazione (di creazione e/o modifica); occorre definire un meccanismo che permetta di assegnare dei nomi univoci ai processi che implementano i servizi di IDN (è opportuno che tale meccanismo sia unificato all interno di tutta l architettura). Una possibile soluzione è quella di proiettare i singoli processi all interno dello dei spazio dei nomi di IDN; è possibile ottenere questo risultato assegnando ad essi alcuni nomi logici, un nome univoco (il cui valore sarebbe quello da inserire nell elemento ihprocessid in esame) e un URL (che permette l individuazione e quindi l accesso del processo in rete) esattamente come avviene per le informazioni primitive. Un altra soluzione potrebbe prevedere l uso di nomi di dominio gestiti dal convenzionale DNS. 267

286 Information History Service Information History Data Model Il secondo, updatestateenum, rappresenta l enumerazione dei possibili stati assunti da UPDATE: FROZEN e CHANGING. L elemento successivo, node, definisce formalmente il nodo nel contesto del layer IH. Tale elemento, come evidenziato in figura 11.5, è suddiviso in due sezioni: header e body. All interno dell elemento body viene infatti inserita la codifica del nodo definita a livello Virtual Repository senza che IH (information hiding) sia interessato ad interpretarne il contenuto. L elemento header contiene invece tutti i dati e metadati di competenza del layer IH e quindi definiti in questo contesto. Sono presenti quattro gruppi di elementi: nodeid: non è un vero e proprio gruppo, in quanto è un unico elemento e rappresenta l indirizzo univoco del nodo (PRI); concurrency: gruppo che contiene le informazioni necessarie per la gestione della concorrenza negli accessi; history: gruppo che contiene tutti gli elementi necessari alla gestione e al mantenimento dello storico. Per quanto riguarda nodeid non occorre specificare altro. Il gruppo concurrency contiene le etichette, introdotte con il caso d uso UC.IH.Int.5, per la gestione della concorrenza. In particolare ad ogni nodo può essere applicato un numero arbitrario di etichette observed e relaxed ed una etichetta a scelta tra lockstrong e locksoft. Ogni etichetta è un elemento di tipo pri e tale indirizzo serve ad identificare l entità (Persona dell utente) che l ha creata. Il gruppo history contiene vari elementi, descritti di seguito: historyid: identificativo dello storico. Per convenzione è stato scelto di utilizzare il PRI del nodo radice dello storico, indirizzo univoco per definizione; versionid: identificativo della versione all interno dello storico. La sintassi è definita tramite l espressione regolare [Goy06] riportata in figura ([1-9][0-9]+\.[1-9][0-9]*\.)*[1-9][0-9]* Figura 11.8: Espressione regolare per definire gli identificativi di versione Tale espressione regolare permette di rappresentare la categoria delle stringhe contenenti un numero arbitrario positivo di elementi costituiti da cifre terminanti con un punto e una sequenza terminale di cifre. Le sequenze di cifre rappresentano numeri interi e non possono iniziare con 0. Il numero di caratteri. deve essere pari, vale a dire che la quantità di sequenze di 268

287 Information History Service Information History Data Model cifre presenti è sempre dispari. Il motivo di questo vincolo sarà chiarito più avanti. Ad esempio, appartengono a questa classe le seguenti stringhe: 21, , eccetera. Non appartengono a questa classe le seguenti stringhe: 7.,.12, 01.3, Ver=1.4, , eccetera. In particolare l ultima mostrata non è valida in quanto è presente una quantità pari (non dispari) di sequenze di cifre. Identificatore assoluto del branch Identificatore della revisione N 1.N N n.b id.r id Identificatore della radice del branch Identificatore relativo del branch Figura 11.9: Convenzione sui nomi dei nodi nello storico La struttura dell identificativo è riportata in figura Tale rappresentazione permette di individuare univocamente le versioni all interno dello storico e il branch di appartenenza. Per convenzione le prime N 1 cifre rappresentano l identificatore assoluto del branch all interno dello storico. Questo identificatore si ottiene aggiungendo al nome del nodo dal quale il branch è stato creato una cifra sequenziale, l identificatore relativo del branch. In questo modo il primo branch del nodo X.Y.Z è X.Y.Z.1, il secondo branch è X.Y.Z.2, eccetera. In ogni branch è presente almeno un nodo e l ultima cifra del nome identifica la revisione relativamente al branch. In riferimento all esempio precedente la prima revisione nel primo branch è X.Y.Z.1.1, la seconda revisione nel primo branch è X.Y.Z.1.2, la n-esima revisione nel m-esimo branch è X.Y.Z.m.n ; created: rappresenta la data e l ora di creazione dell elemento e contiene l identificativo del processo di livello IH che lo ha creato. Inoltre, nell ipotesi in cui ogni azione che si sviluppa nel sistema sia riconducibile ad un Persona, contiene anche l identificativo (PRI) di tale Persona; modified: contiene le medesime informazioni del parametro created con la differenza che viene aggiornato ad ogni modifica di un qualunque elemento presente nel nodo (sia nel caso di sovrascritture dei contenuti che di aggiornamento dei metadati, ad esempio a seguito dell aggiunta del link di versione verso la revisione successiva); update: rappresenta lo stato che stabilisce la politica di gestione del nodo. I valori ammessi sono changing e frozen: nel primo caso le richieste di 269

288 Information History Service Information History Data Model aggiornamento vengono gestite con sovrascrittura, nel secondo tramite la nascita di nuove revisioni (e la relativa propagazione); versionlinks: gruppo di elementi che serve per codificare i link di versione verso gli altri nodi. Tali elementi sono: revisionnext: indirizzo del nodo che rappresenta la nuova revisione; branch: elemento complesso che contiene i dati relativi al branch radicato nel nodo. Tali dati sono: firstrevision: indirizzo del nodo che rappresenta la prima revisione del branch; branchlast: indirizzo dell ultimo nodo presente nel branch. Per motivi di efficienza questo campo è presente solo nella radice del branch. A seguito di una richiesta di accesso al branchlast l algoritmo viene eseguito in due passi: nel primo si accede alla radice del branch e nel secondo all elemento richiesto. I vantaggi di questa soluzione sono evidenti nel caso di nascita di una nuova revisione. Se ogni nodo del ramo possedesse l indirizzo del branchlast, il tempo necessario per la nascita di una nuova revisione scalerebbe linearmente con il numero di revisioni del branch (tutti i riferimenti andrebbero aggiornati). Al contrario, la modalità attuata, permette di aggiornare soltanto l elemento radice (operazione che avviene in tempo costante rispetto agli elementi nello storico) senza penalizzare eccessivamente la fase accesso; revisionprevious: indirizzo del nodo che rappresenta la revisione precedente rispetto alla corrente; branchroot: indirizzo del nodo che rappresenta la radice del branch; historyroot: indirizzo del nodo radice dello storico, secondo le convenzioni utilizzate è il nodo con identificativo 1 ; timelast: indirizzo del nodo che, considerando l intero storico, è stato introdotto più recentemente. Questo campo, per motivi di efficienza, è presente solo nella radice di ogni branch e valgono tutte le considerazioni riportate per il caso del branchlast. In particolare deve memorizzare l indirizzo dell ultimo elemento inserito nel ramo principale oppure in uno dei branch di cui il nodo è radice. Si osservi che nella radice dello storico il campo timelast assume il significato dell elemento inserito più recentemente in assoluto ed è il valore a cui occorre fare riferimento per la risoluzione del parametro di versione T_ABSLAST. I valori timelast presenti nelle radici dei vari branch servono per risolvere le richieste relative al parametro T_RELATLAST come sarà più chiaro in seguito. 270

289 Capitolo 12 Replica Management Service Secondo l approccio stratificato di IDN il livello Replica Management si colloca in una posizione appena superiore a Storage Interface ed inferiore a Information History. L interazione in questo caso consiste nell invio di richieste verso RM da parte di IH, che rappresenta l utente del sistema 1. Innanzi tutto, RM dovrà essere in grado di memorizzare dati e metadati ricevuti dal livello superiore e, su richiesta, restituirli ad esso. La memorizzazione avviene attuando una replicazione (ridondanza) su più locazioni (siti) fisiche indipendenti avvalendosi dei servizi sottostanti. Poiché il livello IH si occupa dello storico dell informazione, tutte le richieste che arrivano ad RM si riferiscono sempre ad una data versione di una data informazione primitiva: tale versione rappresenta l oggetto logico gestito dal sistema di Replica Management. Quando l utente di RM, ossia il livello IH, interagisce con il sistema richiedendo una qualche operazione, deve essere in grado di identificare la risorsa di interesse a prescindere dalla sua locazione fisica. Tra le caratteristiche principali di RM si evidenzia dunque l indipendenza dalla locazione dello spazio dei nomi delle risorse, la quale è attuata mediante l utilizzo dei nomi di tipo URN Estensioni dell applicabilità Per diversi motivi, l utente può avere necessità di ottenere risposta più o meno velocemente dal sistema, a prescindere dalle condizioni della rete e relativamente all importanza della risorsa in questione o dell azione da effettuare su di essa. 1 Nel seguito, si farà riferimento all utente del sistema come all entità che può inviare richieste al Replica Management, che è da non confondersi con l utente del livello applicativo IDN.

290 Replica Management Service Si identificano così quelle esigenze di disponibilità, affidabilità e prestazioni che inducono alla replicazione delle risorse, la quale rappresenta l altra funzionalità principale realizzata dal livello RM. Fuori dal contesto IDN, esistono altre situazioni più generali nelle quali può risultare utile l inserimento di un sistema di Replica Management che presenti le caratteristiche appena descritte, pur sempre affiancato da un servizio di storage analogo a quello fornito in IDN da SI. Si consideri ad esempio uno scenario in cui un generico utente, utilizzando dispositivi e postazioni diverse, ha la necessità di lavorare nel sistema operativo a lui più familiare, interagendo con svariate applicazioni che operano su dati memorizzati in file e organizzati mediante directory. L utente avrà bisogno di vedere la directory nella quale salva i dati sempre aggiornata e come se fosse locale al dispositivo che sta usando. Il sistema di Replica Management può concorrere alla realizzazione di soluzioni per questo scenario, quali ad esempio un file system distribuito o una FAN [Wad07] che possono sfruttare a proprio vantaggio le funzionalità di replicazione e di indipendenza dalla locazione. Altre applicazioni del sistema di Replica Management possono essere a supporto della condivisione di risorse mediante reti peer-to-peer [ATS04] o delle reti per la consegna dei contenuti (Content Delivery Network, in breve CDN) [PB07]. Questo tipo di infrastrutture, evolutesi negli ultimi anni, può beneficiare dei meccanismi di posizionamento dei dati e di instradamento delle richieste realizzati dal sistema, oltre che dell aumento in disponibilità e prestazioni offerto dalla replicazione. Visto come middleware per la replicazione dei dati, infine, il Replica Management può essere utilizzato anche come componente di applicazioni quali database distribuiti o sistemi publish-subscribe Condivisione di risorse Il principale scenario applicativo di IDN riguarda la condivisione di risorse tra più organizzazioni. Si consideri una generica situazione in cui sono presenti tre organizzazioni chiamate A, B e C. Quando l organizzazione A vuole condividere parte delle informazioni di sua competenza con le organizzazioni B e C, dovrà permettere che esse accedano ai dati relativi a tali informazioni. A può decidere di condividere alcune delle sue informazioni con B, e altre con C. Per alleggerire il carico sui server di A, e per aumentare le prestazioni in lettura viste dai client di B e C, A può permettere che B e C mantengano sui propri server una replica dei dati a cui accedono più spesso. In generale, quando B o C richiedono un dato ad A, non è sempre detto che A permetta che essi creino una replica di quel dato sui loro server, ad esempio per problemi legati alla competenza. Inoltre, ogni volta che un server crea una replica di un dato, si impegna a tenerla aggiornata, e ciò richiede carico computazionale, per cui se tutte le organizzazioni tenessero una replica di tutte le risorse a cui accedono, il traffico generato nel propagare gli aggiornamenti 272

291 Replica Management Service potrebbe portare al congestionamento della rete. Comunque, può risultare utile avere a portata di mano un dato a cui si ha bisogno di accedere spesso, perciò in alcuni casi è opportuno creare una replica di un certo dato. In seguito all aggiornamento di una risorsa su un server, le modifiche applicate ad essa dovranno essere inoltrate agli altri server che ne mantengono una replica, in modo che i loro client possano vedere la versione più recente del dato. Un possibile contesto applicativo di tale scenario riguarda le Pubbliche Amministrazioni. Ad esempio l anagrafe è l organizzazione con diritti di proprietà sulle informazioni come il nome, il cognome, la data e il luogo di nascita e la residenza dei cittadini del Comune. Altre organizzazioni possono avere necessità di accedere a queste informazioni: ad esempio, la Motorizzazione ha bisogno dei dati anagrafici per il rilascio della patente, e così anche la questura per il rilascio del passaporto. Nel caso in cui il passaporto del genitore abbia funzione di documento per l espatrio anche per i figli, la questura avrà quindi bisogno di accedere ai dati anagrafici di questi ultimi, mentre alla Motorizzazione non interessa mai conoscere le relazioni di parentela tra i cittadini. Da questo scenario si possono dedurre i seguenti vincoli di contesto: controllo di accesso, per verificare i permessi su ciascuna risorsa; capacità di replicare le risorse in modo individuale ed indipendente; capacità da parte del server che ha eseguito la modifica sulla risorsa di iniziare la propagazione degli aggiornamenti verso le altre repliche; autenticazione dei client e trasmissione sicura degli aggiornamenti Vincoli prestazionali In un ambiente distribuito, può capitare che le connessioni tra i server che mantengono una replica della stessa risorsa abbiano caratteristiche e prestazioni diverse. Ad esempio, se la replica sul server di B è gestita attraverso un collegamento telefonico di tipo dial-up verso il server di A, la connessione tra i due server potrebbe non essere sempre disponibile. Oppure, una replica che risiede su un computer portatile potrebbe proseguire l esecuzione in modalità disconnessa per un certo periodo di tempo; alla riconnessione, inizierà il processo di sincronizzazione per aggiornare i suoi dati all ultima versione disponibile. Questo scenario permette di individuare i seguenti requisiti: capacità di inviare solo le parti della risorsa che sono state modificate; capacità da parte del server che vuole ricevere i dati di iniziare la sincronizzazione con uno dei server che può inviarglieli; la sincronizzazione deve poter avvenire in qualsiasi momento. Ancora in riferimento all esempio delle Pubbliche Amministrazioni, né la Motorizzazione né la Questura hanno il diritto di modificare i dati anagrafici, poiché non sono di loro competenza. 273

292 Replica Management Service Se A è l unico responsabile delle informazioni condivise, tutte le richieste di modifica sui dati dovranno essere inoltrate ai suoi server, i quali possono tenere una o più repliche delle risorse di competenza di A nel caso in cui A lo permetta. Quando A possiede una sola replica della risorsa su cui detiene i diritti di proprietario, essa è l unica modificabile. Di conseguenza, se il server su cui si trova tale replica è guasto, le richieste di aggiornamento sono costrette ad attendere fino al suo ripristino. In presenza di partizionamenti della rete, può succedere che A, B e C non riescano a comunicare per un certo periodo di tempo. Allora diventa possibile che, durante il periodo di disconnessione, gli aggiornamenti effettuati su una risorsa in A non riescano ad essere propagati a tutte le sue repliche; ciascun server deve comunque continuare a rispondere alle richieste dei client, fornendo la versione più recente del dato a sua disposizione. Le repliche sui server di B e C non possono iniziare ad eseguire modifiche, perché non sono proprietari di quella risorsa. Oltre ai requisiti dello scenario principale, che continuano a rimanere validi, si possono individuare i seguenti: presenza di una sola replica modificabile; replicazione asincrona, perché l esecuzione delle modifiche in A si conclude senza aspettare la propagazione delle stesse a tutte le repliche; possibilità di ritentare la sincronizzazione, immediatamente oppure in un momento successivo; la replica modificabile non può essere sostituita in modo automatico da una qualsiasi delle altre. Può però essere utile che una risorsa sia replicata su più server appartenenti ad A e dislocati in sedi diverse, per evitare la situazione di single point of failure, ovvero per motivi di affidabilità e disponibilità oltre che per le prestazioni. Ad esempio, l organizzazione A potrebbe comprendere più sedi in locazioni fisicamente distanti l una dall altra. Tra gli uffici del comune di una grande città possono esserci più sedi dell anagrafe, di conseguenza i dati anagrafici potrebbero essere distribuiti tra i server delle varie sedi. Allora, poiché tutte le sedi appartengono all organizzazione A, possiedono tutte i diritti di proprietario sulle informazioni di sua competenza. Si consideri il caso in cui A mantiene più repliche della risorsa su cui detiene i diritti di proprietario, ed una sola di esse è aggiornabile. Può accadere che, in seguito ad esempio ad un trasferimento, venga chiusa la sede dove si trova l unica replica modificabile della risorsa. Le informazioni contenute in tale risorsa devono continuare ad essere aggiornabili, perciò diventa necessario scegliere, tra le restanti repliche della risorsa, una che diventi modificabile al posto dell altra. Da questo scenario si può ricavare un ulteriore requisito: capacità di sostituire la replica modificabile con una delle repliche appartenenti ad A, senza che ciò comporti l indisponibilità del servizio per un tempo significativo. 274

293 Replica Management Service Si consideri adesso il caso in cui A mantiene più repliche della risorsa su cui detiene i diritti di proprietario, e più di una di esse è aggiornabile. Una situazione di questo tipo si può presentare anche quando due organizzazioni che collaborano, magari condividendo lo spazio dei nomi, hanno bisogno entrambe di possedere diritti amministrativi sui dati messi in comune. Dal punto di vista dell utente, il comportamento del sistema deve essere ancora quello descritto negli scenari precedenti. Una risorsa deve continuare ad essere disponibile e modificabile anche quando uno dei server su cui risiede una sua replica è disconnesso dalla rete; in particolare, non devono presentarsi situazioni in cui una delle repliche modificabili esegue una richiesta di aggiornamento senza prima aver ricevuto tutte le modifiche eseguite sulle altre repliche della stessa risorsa fino a quel momento. I requisiti individuabili mediante questo scenario sono i seguenti: presenza di più repliche modificabili; assenza di situazioni di conflitto; indipendenza dalla locazione, per realizzare lo spazio dei nomi a condivisione completa. Si consideri infine un organizzazione che accede frequentemente in lettura ad una risorsa di cui però non può mantenere una replica. Questo può accadere sia perché il proprietario della risorsa non glielo concede, sia perché ha valutato che non risulterebbe vantaggioso prendersi l impegno di effettuare regolarmente la sincronizzazione. L organizzazione potrebbe allora decidere di effettuare il caching in locale di quella risorsa, in modo da essere in grado di portare a termine le letture su di essa anziché inviare una richiesta e attendere la risposta ogni volta che ha bisogno di leggerla. All interno di un organizzazione, i dati possono assumere un importanza diversa sia in relazione al loro contenuto che col passare del tempo. Ad esempio, i pattern di lettura e scrittura relativi a dati diversi possono essere diversi. Il grado di replicazione associato ad ogni risorsa deve essere ottimizzato in modo da riflettere queste differenze: se un dato è di sola lettura, converrà replicarlo il più possibile, se invece viene scritto spesso, il meno possibile. Inoltre, tali pattern di lettura e scrittura possono cambiare nel tempo. Per un certo periodo può essere necessario che una risorsa venga replicata il più possibile e che tutti coloro che vi accedono ne possiedano una replica; in seguito, ciò può non essere più necessario. Deve essere possibile cambiare il grado di replicazione di ciascuna risorsa, aggiungendo e rimuovendo repliche secondo le esigenze. In generale, deve essere possibile cambiare la configurazione di ciascuna risorsa ai fini della replicazione. Un organizzazione inizialmente piccola, che comprende un unica sede e gestisce i suoi dati mantenendo una sola replica modificabile, potrebbe in seguito venire fusa con un altra organizzazione, oppure espandersi fino a comprendere più sedi: la presenza di più repliche modificabili potrebbe allora rivelarsi più consona alla nuova situazione. 275

294 Replica Management Service Requisiti Si può pensare di mettere a disposizione dell utente un indice di affidabilità associato ad ogni risorsa, che rappresenti, ad esempio, la frequenza attesa di letture e scritture, e in base al quale il sistema di replicazione sia in grado di decidere automaticamente quale configurazione associare alla risorsa e i relativi parametri. Si possono dunque individuare i seguenti requisiti: strategia di replicazione dinamica, perché il numero di repliche associate ad una risorsa può variare nel tempo (ovviamente, l aggiunta e la rimozione di repliche non deve interrompere l attività del sistema); capacità di modificare la configurazione di una risorsa, cambiando il numero di repliche aggiornabili associate ad essa; esposizione all utente di primitive per la configurazione della replicazione Requisiti Di seguito sono enunciati i requisiti del sistema di Replica Management, in lingua inglese 2 e con relativa traduzione in italiano. Ogni requisito è identificato da un codice di riferimento unico del tipo RM- RXXX, dove alle X si sostituisce un codice numerico di 3 cifre, il quale è assegnato progressivamente, in ordine cronologico. I codici dei requisiti rifiutati non sono stati riutilizzati, rendendo in questo modo univoca l identificazione di ogni requisito. Requisiti per la gestione delle risorse I seguenti requisiti formalizzano la specifica di RM in qualità di sistema in grado di gestire le risorse ed accedere ad esse. Requirement RM-R001 (Functional Requirement) RM SHALL provide a service for managing and accessing resources. Il sistema di Replica Management fornisce un servizio per gestire le risorse e accedere ad esse. Requirement RM-R002 (Functional Requirement) RM SHALL handle resources made up of data and metadata. Le risorse di cui si occupa RM sono composte da dati e metadati. Requirement RM-R003 (Functional Requirement) Arbitrary metadata MUST be supported. Deve essere possibile associare alle risorse metadati a piacere, a seconda delle esigenze. 2 Nell enunciato in lingua inglese, le parole MUST, MUST NOT, REQUIRED, SHALL, SHALL NOT, SHOULD, SHOULD NOT, RECOMMENDED, MAY, e OPTIONAL sono da interpretarsi come descritto in [Bra97]. 276

295 Replica Management Service Requisiti Requirement RM-R004 (Functional Requirement) Metadata SHOULD be univocally identified through a qualified name. Ogni metadato dovrebbe avere un nome che lo identifichi a livello globale. Requirement RM-R005 (Functional Requirement) Metadata value SHOULD have a type defined by the qualified name. Il nome di un metadato appartiene ad uno spazio dei nomi che individua la sintassi e la semantica del suo valore, la cui conformità può essere verificata mediante un meccanismo di validazione. Requirement RM-R006 (Functional Requirement) Data and metadata MUST be hierarchically subordinated to the resource. I dati e i metadati sono contenuti nella risorsa e ne sono figli. Requirement RM-R007 (Functional Requirement) Direct access to metadata MUST be allowed. Il valore di un metadato deve poter essere ottenuto tramite indirizzamento diretto, che può essere realizzato combinando il nome del metadato con quello della risorsa. Requirement RM-R008 (Standard Compliance) XML representation of resources MUST be allowed. Deve essere permessa la rappresentazione delle risorse tramite XML. Requirement RM-R009 (Functional Requirement) Resources handled by RM MUST be globally and univocally identified through a name. Le risorse di cui si occupa RM devono essere identificate univocamente a livello globale tramite un nome. Requirement RM-R010 (Design Constraint) Resource names used by RM MUST exhibit location independence. Lo spazio dei nomi usato per identificare le risorse di cui si occupa RM deve presentare indipendenza dalla locazione. Requirement RM-R011 (Design Constraint) Access to resources MUST NOT be related to resource names. L accesso alle risorse deve essere indipendente dai nomi delle stesse. Requirement RM-R012 (Standard Compliance) Resources handled by RM MUST be identified through URN. Le risorse di cui si occupa RM devono essere identificate tramite URN. Requirement RM-R013 (Functional Requirement) RM SHALL provide CRUD functionality on resources. È necessario che RM fornisca le quattro operazioni di base della memorizzazione persistente. 277

296 Replica Management Service Requisiti Requirement RM-R014 (Functional Requirement) Operations different from the basic CRUD MUST be optional in specific implementations. Deve essere sufficiente che un implementazione del sistema di Replica Management realizzi soltanto le operazioni CRUD. Requirement RM-R015 (Functional Requirement) Locking and unlocking of resources MAY be allowed. È possibile definire delle operazioni che permettono di bloccare l accesso alle risorse mentre queste stanno venendo modificate, e sbloccarlo in seguito. Requirement RM-R016 (Functional Requirement) Specific operations for management or performance enhancement MAY be supported. È possibile definire altre operazioni allo scopo di potenziare la gestione delle risorse o impostare le prestazioni del sistema. Ad esempio, potrebbe risultare utile una primitiva per la creazione di duplicati di una risorsa. Requirement RM-R017 (Functional Requirement) Partial access to data and metadata MAY be supported. È possibile che sia permesso accedere a parti dei dati o a singoli metadati, ad esempio per effettuare su di essi le operazioni CRUD. Requirement RM-R018 (Functional Requirement) Resource validation MAY be provided upon resource creation or update, or upon explicit request. Il servizio può offrire funzionalità di validazione delle risorse, ovvero deve essere possibile l uso di procedure generiche che restituiscano informazioni relativamente alla conformità di una risorsa rispetto ai tipi dichiarati. In particolare, possono essere previsti meccanismi di validazione delle risorse memorizzate in occasione della creazione o dell aggiornamento delle stesse, oppure su richiesta esplicita. Requirement RM-R019 (Security) RM SHALL handle access control on resources. È necessario che RM si occupi del controllo di accesso sulle risorse. Perciò, le operazioni devono prevedere il trasporto di credenziali, in modo che un utente che vuole svolgere un operazione su una risorsa possa ottenere l autorizzazione ad accedere ad essa. Requirement RM-R020 (Security) Different authentication/authorization/audit systems MUST be supported. Deve essere possibile implementare RM con diversi meccanismi di protezione, in cui si prevede anche la delega dell autorizzazione tra le entità. In generale, sarà necessario essere in grado di gestire l autorizzazione basandosi sulle entità in gioco, come ad esempio il detentore dei diritti sulla risorsa, 278

297 Replica Management Service Requisiti il richiedente dell operazione di accesso, il sistema di accesso e lo stesso servizio di Replica Management. Requirement RM-R021 (Design Constraint) The service provided by RM MUST be delivered through a globally addressable interface. Il servizio fornito da RM deve essere fruibile mediante un interfaccia indirizzabile a livello globale. Requirement RM-R022 (Design Constraint) The interface exposed by RM MUST be RESTful. L interfaccia esposta da RM deve essere progettata in stile REST. Requirement RM-R023 (Design Constraint) The interface exposed by RM MUST be abstract. L interfaccia esposta da RM deve essere astratta. Le operazioni e i messaggi devono essere descritti senza fare riferimento a protocolli o linguaggi di programmazione specifici dell implementazione. Requirement RM-R024 (Standard Compliance) WSDL SHOULD be used for the definition of the abstract interface. La descrizione standardizzata dell interfaccia astratta di RM dovrebbe essere fornita utilizzando WSDL, in modo da offrire maggiore interoperabilità. Requirement RM-R025 (Design Constraint) The interface exposed by RM MUST be implementable using different programming languages. L interfaccia esposta da RM deve essere implementabile mediante linguaggi di programmazione diversi. Requirement RM-R026 (Standard Compliance) WSDL MAY be used to describe interface implementations. È possibile utilizzare WSDL per descrivere le implementazioni dell interfaccia, grazie alle estensioni per HTTP e SOAP. In particolare, potrebbe essere utile definire una nuova estensione di WSDL per descrivere interfacce che usino altri protocolli, come ad esempio TCP. Requirement RM-R027 (Design Constraint) RM MUST support synchronous and asynchronous interaction. Le specifiche dell interfaccia non devono impedire la possibilità di implementazioni con un meccanismo asincrono. Requirement RM-R028 (Functional Requirement) RM SHOULD be implemented according to ROA principles. Il sistema di Replica Management dovrebbe essere implementato secondo i principi delle ROA. 279

298 Replica Management Service Requisiti Requirement RM-R029 (Portability) Protocols other than HTTP MAY be supported. È possibile pensare ad un implementazione di RM basata su protocolli diversi da HTTP, per motivi di flessibilità. Requirement RM-R030 (Portability) Other architectural solutions MAY be used for implementation. Il sistema di Replica Management può essere implementato utilizzando altre soluzioni architetturali. Requisiti per la replicazione I seguenti requisiti formalizzano la specifica di RM in qualità di sistema in grado di realizzare e gestire la replicazione delle risorse. Requirement RM-R031 (Functional Requirement) RM SHALL handle multiple replicas of a resource. Il sistema di Replica Management deve essere in grado di gestire più repliche di una risorsa. Requirement RM-R032 (Functional Requirement) The replication system SHALL manage replica configuration individually for each resource. Ogni risorsa deve essere replicata indipendentemente dalle altre. Requirement RM-R033 (Functional Requirement) The replication system MUST allow replica configuration of a resource to be modified over time. La configurazione delle repliche associate ad una data risorsa deve essere modificabile nel tempo. Requirement RM-R034 (Performance Requirement) Changes in replica configuration of a resource MUST NOT introduce significant downtime in the system. La modifica della configurazione delle repliche associate ad una risorsa non deve comportare l indisponibilità del servizio per un tempo significativo. Requirement RM-R036 (Functional Requirement) The replication system MUST support transparently splitting a resource into multiple resources for performance enhancement. Al fine di migliorare le prestazioni, il sistema deve essere in grado di dividere una risorsa in più parti. Internamente al sistema, ciascuna di queste parti verrà considerata come una risorsa separata, che di conseguenza potrà essere configurata indipendentemente. Questa suddivisione dovrà però risultare trasparente all esterno del sistema, il quale ha il compito di mascherarla. 280

299 Replica Management Service Requisiti Requirement RM-R037 (Functional Requirement) The replication system MUST be asynchronous. Al fine di continuare l esecuzione anche in presenza del fallimento di uno o più server o di partizionamenti della rete, la replicazione delle risorse deve seguire l approccio asincrono. Requirement RM-R038 (Functional Requirement) Data and metadata content in a replica MUST eventually converge to the same value in every replica of the same resource. Il contenuto dei dati e dei metadati di ogni replica di una stessa risorsa deve convergere nel tempo allo stesso valore. In altre parole, deve essere mantenuta la consistenza tra tutte le repliche della stessa risorsa. Requirement RM-R039 (Functional Requirement) The replication system MUST enforce sequential consistency. Il sistema di replicazione deve garantire la consistenza sequenziale, descritta nel paragrafo C.3.1. Requirement RM-R042 (Functional Requirement) The replication system MUST avoid conflicts. Il sistema di replicazione deve essere tale che non si presentino conflitti. Requirement RM-R043 (Design Constraint) Metadata pertaining to replication MUST be accessible. I metadati riguardanti la replicazione devono essere accessibili. Ciò implica l esposizione, tramite un apposita interfaccia di amministrazione, di appropriate funzioni atte alla gestione dei metadati di livello RM. Requirement RM-R044 (Design Constraint) Except for administrative tasks, the interface exposed by RM MUST exhibit replication transparency. L interfaccia esposta dal sistema deve essere quanto più trasparente possibile alla replicazione, pur permettendo l amministrazione del sistema. L utente del sistema di Replica Management deve poter operare sulle risorse come se non fossero replicate. Requirement RM-R045 (Functional Requirement) The replication protocol MUST allow any replica to initiate the synchronization process. Il processo di sincronizzazione deve poter essere inizializzato sia da una replica su un server che ha eseguito una modifica della risorsa e vuole propagarlo alle altre repliche, sia da una replica su un server che è rimasto disconnesso e vuole aggiornarsi all ultima versione della risorsa. 281

300 Replica Management Service Requisiti Requirement RM-R046 (Functional Requirement) The replication protocol MUST provide for recovery and rescheduling of a synchronization session. Il protocollo di replicazione deve fornire il recupero e la riprogrammazione di una sessione di sincronizzazione, ad esempio quando una replica è irraggiungibile a causa della perdita della connessione. Requirement RM-R047 (Functional Requirement) The model MUST support the following triggers for initiation of the synchronization process: a configurable set of scheduled times; periodically, with a configurable period; a configurable maximum amount of time since the last synchronization session; a configurable number of accumulated changes; as the result of an automatic rescheduling; an application on-demand event, such as an access request. Il processo di sincronizzazione deve poter essere innescato: in un insieme configurabile di istanti prefissati; periodicamente, con periodo configurabile; allo scadere di una quantità massima configurabile di tempo dall ultima sincronizzazione; dopo un numero configurabile di modifiche accumulate; in seguito a riprogrammazione automatica; in seguito ad un evento esterno, come una richiesta di accesso. Requirement RM-R048 (Performance Requirement) Caching of data SHOULD be enabled. Il sistema dovrebbe abilitare il caching dei dati. Si noti che ciò è facilmente realizzabile quando si decide di seguire un approccio di tipo REST. Requirement RM-R049 (Performance Requirement) Replication SHOULD have minimal impact on system performance. La replicazione dovrebbe avere impatto minimo sulle prestazioni del sistema, ovvero ostacolare il meno possibile lo svolgimento delle altre funzioni. 282

301 Replica Management Service Requisiti Requirement RM-R051 (Performance Requirement) The replication system SHOULD limit impact on the network by minimizing the number of messages and the amount of traffic sent. Il sistema di replicazione dovrebbe limitare l impatto sulla rete, minimizzando il numero di messaggi e la quantità di traffico immessi. Requirement RM-R052 (Functional Requirement) Incremental update propagation MUST be allowed. Nella propagazione degli aggiornamenti deve essere possibile inviare soltanto le parti della risorsa che sono state modificate. Requirement RM-R053 (Functional Requirement) The capability to check the differences between two replicas for the same resource SHOULD be provided. Dovrebbe essere fornita la capacità di controllare le differenze tra due repliche della stessa risorsa. Requirement RM-R054 (Security) The replication protocol MUST support mutual authentication of replica servers during initialization of a synchronization session. Il protocollo di replicazione deve permettere la mutua autenticazione tra i server durante l inizializzazione di una sessione di sincronizzazione. Requirement RM-R055 (Security) The replication protocol MUST support the initialization of anonymous synchronization sessions. Il protocollo di replicazione deve permettere l inizializzazione di sessioni di sincronizzazione anonime. Requirement RM-R056 (Security) The replication protocol MUST support transfer of data with data integrity and data confidentiality. Il protocollo di replicazione deve essere in grado di mantenere l integrità e la confidenzialità dei dati durante il loro trasferimento. Requirement RM-R057 (Security) The replication protocol MUST support the ability during initialization of a synchronization session for the authenticated replica servers to mutually decide to disable data integrity and data confidentiality within the context of and for the duration of that particular session. Durante l inizializzazione di una sessione di sincronizzazione, due server autenticati devono poter decidere, di comune accordo, di disabilitare l integrità e la confidenzialità dei dati per quella particolare sessione. 283

302 Replica Management Service Gestione delle risorse Requirement RM-R058 (Security) The transport for administrative access MUST permit assurance of the integrity and confidentiality of all data transferred. Durante l accesso da parte dell utente per l amministrazione del sistema, deve essere possibile avere la garanzia dell integrità e della confidenzialità di tutti i dati trasferiti Gestione delle risorse Esistono dei servizi che il sistema di Replica Management deve essere in grado di fornire per la gestione delle risorse e l accesso ad esse, in accordo al requisito RM-R001, e indipendentemente dal fatto che esse siano o meno replicate. Infatti, anche in uno scenario in cui la replicazione delle risorse non è richiesta e dunque può non essere realizzata, l utente ha comunque bisogno di poter sfruttare le funzionalità di memorizzazione persistente e di poter identificare le risorse indipendentemente dalla loro locazione fisica. Laddove la replicazione non si renda necessaria, è possibile pensare ad un implementazione del sistema di Replica Management che fornisca soltanto tali servizi Memorizzazione persistente Per le funzionalità relative alla memorizzazione persistente, il sistema di Replica Management si avvale del servizio offerto da Storage Interface, la cui progettazione e realizzazione sarà affrontata nel capitolo 13. Secondo il modello dell informazione definito, ogni risorsa è vista come una rappresentazione dei dati che contiene. I metadati associati sono le proprietà di tale rappresentazione; ciascuno di essi ha un nome di tipo URI che lo identifica univocamente nell ambito di una stessa risorsa, e ne identifica universalmente il tipo e la semantica. Ogni risorsa inoltre possiede un identificatore, il quale la individua univocamente all interno del servizio di storage sui cui è mantenuta, e che, composto con l indirizzo (il cosiddetto endpoint) di quest ultimo, costituisce un URL che permette l accesso alla risorsa stessa. Il valore di un metadato è indirizzato mediante la combinazione dell URL della risorsa con il nome del metadato stesso. Si osservi che, dal punto di vista del sistema di Replica Management, ogni risorsa di livello SI rappresenta una particolare replica (che può anche essere l unica esistente) dell informazione gestita. In un modello stratificato come quello dell architettura IDN, un livello è detto consumer in quanto sfrutta i servizi offerti dal livello inferiore, detto provider. L interfaccia di SI espone delle operazioni per la gestione delle risorse che possiede, ossia le singole repliche dell informazione gestita dal Replica Management. Ciascuna di queste operazioni realizza una determinata funzionalità mediante lo scambio di messaggi tra il consumer, che in questo caso è il livello RM, e il provider, ovvero SI stesso. Un implementazione di Storage Interface dovrà necessariamente realizzare le 284

303 Replica Management Service Gestione delle risorse operazioni di base della memorizzazione persistente, ossia le quattro operazioni indicate dall acronimo CRUD (capitolo 13). Possono inoltre essere realizzate ulteriori operazioni ausiliarie, definite in base a considerazioni di carattere pratico, come ad esempio la creazione di un duplicato di una risorsa, oppure l elenco degli identificatori delle risorse presenti in un certo servizio di storage o dei nomi dei metadati associati ad una certa risorsa. Altre funzionalità atte a soddisfare requisiti opzionali del servizio comprendono operazioni specializzate per la lettura e la modifica diretta dei dati e dei metadati contenuti in una risorsa, la validazione ossia il controllo della conformità di una risorsa ai suoi tipi, il locking e la verifica di una condizione su una risorsa. Sono infine disponibili anche funzionalità di gestione della sottoscrizione e della notifica di eventi. Quando il sistema di Replica Management invia una richiesta ad un servizio di storage, in essa deve specificare l endpoint del servizio e l identificatore della risorsa di livello SI sulla quale richiede l operazione, oltre ad eventuali altri parametri necessari per la specifica funzionalità. Se il servizio che riceve la richiesta non possiede la risorsa di livello SI specificata, restituirà indietro un messaggio di errore. In IDN, ogni risorsa di livello SI possiede un proprietario, identificato nell istanza di livello RM che ne ha richiesto la creazione. Ciascuna istanza di livello RM è autoritativa su un certo numero variabile di istanze di livello SI: significa che può comunicare direttamente con esse e richiedere le varie operazioni sulle risorse di livello SI contenute di cui è proprietaria. Più istanze di livello RM possono essere autoritative su una stessa istanza di livello SI e richiedere la creazione di nuove repliche su di essa. Viceversa, la lettura, la scrittura e la rimozione di una risorsa di livello SI esistente possono essere effettuate soltanto dal suo proprietario. Quando un istanza di livello RM ha bisogno di eseguire un operazione su una risorsa di cui non è proprietaria, dovrà inoltrare la richiesta all istanza proprietaria Il servizio di risoluzione dei nomi Allo scopo di realizzare, secondo il requisito RM-R010, l indipendenza dalla locazione nell identificazione delle risorse gestite, il sistema di Replica Management utilizza i nomi di tipo URN, come specificato dal requisito RM-R012. Un URN (Uniform Resource Name) ha il compito di identificare una risorsa vista come oggetto logico gestito dal sistema, la quale può essere rappresentata fisicamente da un insieme di repliche. L obiettivo è quello di fornire un identificatore persistente e unico a livello globale da associare ad ogni risorsa, come affermato dal requisito RM-R Il servizio di replicazione In accordo al requisito RM-R031, il sistema di Replica Management deve essere in grado di gestire una situazione in cui uno stesso oggetto logico è fisicamente rappresentato da un insieme di risorse di livello SI, le quali ne costituiscono le varie repliche. 285

304 Replica Management Service Gestione delle risorse Devono essere perciò affrontati i seguenti problemi inerenti al servizio di replicazione: come garantire la consistenza di tutte le repliche di un dato oggetto; dove posizionare fisicamente le repliche di un dato oggetto; come scegliere la replica di un dato oggetto più appropriata a servire le richieste dei client. Ciascuno di questi problemi, affrontati rispettivamente nei paragrafi , e , è in gran parte indipendente dagli altri; considerati nel loro insieme, essi vanno a coprire i principali aspetti necessari per la costituzione di un sistema di replicazione. Un altro dei problemi da affrontare separatamente riguarda la granularità della replicazione, e consiste nella scelta degli oggetti da replicare. Secondo il requisito RM-R032, il sistema di Replica Management deve essere in grado di configurare la replicazione di ogni risorsa indipendentemente. In generale, perciò, ogni risorsa gestita dal sistema sarà un potenziale oggetto da replicare. Nel contesto IDN, ad esempio, le risorse rappresentano le diverse versioni di un documento, mentre nel caso di un file system o di una FAN le risorse sono i file. Il requisito RM-R036 afferma inoltre che, al fine di migliorare le prestazioni, il sistema deve essere in grado di dividere una risorsa in più parti, così che, internamente al sistema, ciascuna di queste parti possa essere considerata come una risorsa separata, e di conseguenza possa essere configurata indipendentemente: si prevede dunque l esistenza di un tipo di risorsa che rappresenta l aggregato di più parti, delle quali contiene al suo interno i PRI. In questo caso, la replicazione ha una granularità maggiore. In pratica, il livello di granularità con cui il contenuto di una risorsa è replicato risulta determinato in base all utilizzo che viene fatto della risorsa stessa, in modo da ottimizzare le prestazioni nella lettura e scrittura delle sue varie parti. In generale, se una risorsa è richiesta frequentemente dai client di una data istanza di livello RM, sarebbe opportuno che fosse possibile ottenere il contenuto di tale risorsa da una replica di cui quell istanza è proprietaria, in modo da evitare di dover contattare ogni volta un altra istanza di pari livello RM, operazione che introduce sovraccarico nel sistema. La soluzione di posizionare una replica della risorsa presso una delle istanze di livello SI su cui quell istanza è autoritativa può però non essere sempre fattibile. Il sistema di Replica Management può allora decidere, come suggerito dal requisito RM-R048, di creare una copia cache del contenuto di tale risorsa. Così, alle successive richieste di lettura per quella risorsa da parte di un client, quell istanza è in grado di restituirne il contenuto senza bisogno di contattare nessuna altra istanza di pari livello RM. In seguito a tale decisione, i dati ottenuti contattando una delle istanze di pari livello RM vengono utilizzati per creare una risorsa di livello SI a cui il sistema può accedere direttamente. È comunque possibile che il proprietario della risorsa, intesa come oggetto logico gestito dal sistema, non permetta di effettuarne il caching. 286

305 Replica Management Service Gestione delle risorse Il funzionamento di un entità di livello RM che tiene una copia cache di una risorsa in pratica è analogo a quello di un server proxy. Quando un server proxy riceve una richiesta da un client per una certa risorsa, chiede al server HTTP di effettuare la validazione della copia cache di quella risorsa, ossia chiede di controllare se la risorsa è stata modificata dopo che è stata memorizzata la copia cache; in caso negativo, invia il contenuto della copia cache al client. Si consideri un server utilizzato da molti client: quando uno di essi richiede una risorsa che era già stata richiesta in precedenza, da lui stesso o da un altro client, il proxy è in grado di rispondere inviando la copia cache, senza doversi collegare al sito che possiede la copia originale. In questo modo si evita di sovraccaricare sia il sito che possiede la copia originale della risorsa sia la rete, migliorando le prestazioni del sistema anche per quelle richieste che devono necessariamente essere inoltrate al sito che possiede la copia originale. È possibile anche utilizzare un meccanismo di scadenza a tempo, come quello adottato dal DNS, secondo il quale una copia cache continua ad essere utilizzata finché non è scaduta, senza bisogno che il suo contenuto venga validato ogni volta. Una copia cache è visibile soltanto all istanza di livello RM che l ha creata; è quest ultima, e non LS, che si occupa di mantenere in locale l associazione tra l URL della copia cache e il PRI della relativa risorsa. LS non viene mai a conoscenza dell URL della copia cache e non sarà quindi in grado di fornirla in seguito al lookup del PRI della risorsa. Un sistema come quello considerato dovrebbe cercare di fornire ai suoi client le migliori prestazioni con il minor sovraccarico possibile. Di fatto, il progetto di un sistema di replicazione risulta dal compromesso tra i requisiti funzionali e quelli relativi alle prestazioni e al costo; ad esempio, aumentare il numero dei server che mantengono una copia di una risorsa può servire a diminuire la latenza percepita dai client, ma dover propagare gli aggiornamenti ad ognuna di esse introduce un aumento nel costo operazionale del sistema. Poiché le prestazioni del sistema possono subire variazioni in relazione ai pattern di accesso dei client e alle condizioni della rete, è opportuno che il sistema sia capace di adattare automaticamente la sua configurazione. In altre parole, deve essere possibile utilizzare una strategia di replicazione dinamica, la quale, come visto nel paragrafo C.5, sia capace di adattarsi ai cambiamenti in modo da mantenere il livello desiderato di prestazioni, pur continuando a osservare i vincoli applicativi con costo minimo. Il processo di adattamento consiste in una serie di modifiche nelle decisioni prese per il mantenimento della consistenza e per il posizionamento e la selezione delle repliche. Perché l adattamento della configurazione possa essere innescato automaticamente, è necessario che il sistema sia in grado di accorgersi del fatto che le prestazioni si stanno allontanando dall intervallo dei valori accettabili. A seconda dei criteri di ottimizzazione, sarà necessario scegliere attentamente dei parametri che riflettano accuratamente il comportamento del sistema, e dei meccanismi per stimarne i valori. 287

306 Replica Management Service Gestione delle risorse Mantenimento della consistenza Il problema del mantenimento della consistenza riguarda la scelta di un modello di consistenza e la sua realizzazione tramite appositi protocolli, i quali possono impiegare diversi meccanismi per la propagazione degli aggiornamenti. I modelli di consistenza, descritti nel paragrafo C.3, possono essere visti come un contratto, stipulato tra il sistema di replicazione e i suoi client, che detta le proprietà relative alla consistenza delle risorse gestite dal sistema. Il requisito RM-R039 afferma che il sistema di Replica Management considerato deve osservare la consistenza sequenziale; essa può essere garantita soltanto se i processi che eseguono le operazioni sui dati condivisi utilizzano le transazioni e i meccanismi di locking [TvS01]. Ad ogni risorsa gestita dal sistema di replicazione è associato un protocollo che, come visto nel paragrafo C.4, ha il compito di garantire che essa aderisca al modello di consistenza definito. Si noti che uno stesso modello può essere rispettato utilizzando protocolli diversi. Il requisito RM-R042 afferma che non devono presentarsi conflitti; di conseguenza, per il sistema considerato si rende necessario l utilizzo di protocolli pessimistici. In particolare, per le risorse il cui contenuto si prevede che non cambi nel tempo, è sufficiente l esistenza di un unica replica modificabile, per cui si adotta l approccio del sito primario, mentre per i dati che vengono spesso aggiornati è opportuno permettere l esistenza di un insieme di repliche modificabili, e quindi si adotta l approccio a votazione. Quando si utilizza l approccio del sito primario, è possibile portare a termine le operazioni di lettura sui siti di backup oppure sulle copie cache senza violare la consistenza sequenziale, come visto nel paragrafo C.4.1. Anche quando si utilizza l approccio a votazione è possibile che una richiesta di lettura venga servita da una copia cache (a cui sono sempre assegnati zero voti) senza incorrere in alcuna violazione del modello di consistenza; ciò è utile, ad esempio, per rendere le risorse disponibili in lettura qualora non si riesca ad ottenere il quorum nel modo visto nel paragrafo C.4.2. Si osservi che, se le operazioni di aggiornamento sono viste come atomiche, non c è bisogno di mettere il lock sulla replica che serve una richiesta di lettura, poiché tale operazione può soltanto vedere o il valore precedente o quello seguente ad una modifica eseguita sulla stessa risorsa, ma mai uno stato intermedio non valido [RL05]. Come espresso dal requisito RM-R037, la replicazione deve essere asincrona. Pertanto, un operazione di scrittura può considerarsi conclusa quando è stata eseguita, a seconda del tipo di approccio in uso, o sulla replica nel sito primario o su un numero di repliche pari al quorum di scrittura, e comunque sempre senza attendere che gli aggiornamenti siano propagati a tutte le restanti repliche. Ciò permette la scalabilità del sistema. Di conseguenza, se si desidera per una risorsa un determinato grado di affidabilità, l approccio a votazione permette di garantire che per ogni operazione di scrittura sarà sicuramente aggiornato almeno un numero di repliche pari al quorum di scrittura. Come previsto dal requisito RM-R033, la configurazione di una risorsa può cambiare nel tempo. 288

307 Replica Management Service Gestione delle risorse Soltanto il proprietario della risorsa può decidere riguardo l unicità o meno della replica modificabile e, di conseguenza, il tipo di approccio da utilizzare per il mantenimento della consistenza. Quando si utilizza l approccio del sito primario, la modifica della configurazione può consistere nella variazione del numero dei siti di backup, la quale può essere innescata su richiesta esplicita dell utente o in base alle condizioni del sistema, come descritto più avanti nel paragrafo Potrebbe anche essere necessario affidare il ruolo di sito primario ad un sito che precedentemente non lo era: è importante che il processo di elezione del nuovo primario non sia innescato automaticamente dal sistema, in modo da impedire che, in caso di partizionamenti della rete, non venga eletto un primario diverso in ogni partizione. Quando invece si utilizza l approccio a votazione, la modifica della configurazione può riguardare anche la variazione dei valori dei quorum o la riassegnazione dei voti. Quest ultima, in particolare, si rende necessaria ogni volta che si aggiunge o si rimuove una replica; alla creazione, ad ogni replica si possono assegnare zero voti, e la riassegnazione può avvenire in un momento successivo, mentre l eliminazione di una replica con voti diversi da zero richiede necessariamente l innesco della riassegnazione. Alcuni metodi per l assegnazione dei voti sono illustrati in [Jal94]. A prescindere dal tipo di operazione da effettuare su una risorsa, è sempre desiderabile minimizzare la complessità di comunicazione del protocollo di gestione delle repliche, intesa come il numero di repliche da contattare per portare a termine ogni operazione. Risulta dunque opportuno che, in generale, le dimensioni dei quorum di lettura e scrittura siano inversamente proporzionali alle frequenze delle corrispondenti operazioni. Lo svantaggio principale nell uso dell approccio a votazione consiste proprio nel fatto che il numero delle repliche da contattare per ottenere un quorum cresce linearmente con il numero totale di repliche associate alla risorsa. Ciò costituisce un ostacolo alla scalabilità del sistema: si può allora pensare di adottare una soluzione che preveda la costruzione di un quorum a più livelli, mappato sulla gerarchia della rete sottostante. L idea è quella di organizzare i nodi della rete in una gerarchia logica che può essere anche indipendente dalla topologia fisica della rete. Le foglie della gerarchia, ossia i nodi al livello più basso, sono i nodi fisici, e tutti i nodi ai livelli superiori sono entità logiche che agiscono per conto dei loro successori. Al livello più alto, il nodo radice rappresenta l intera rete. Quando si vuole eseguire un operazione, si attraversa l albero partendo dalla radice fino alle foglie; per ciascun livello della gerarchia tranne il più basso si devono ottenere dei quorum, che possono essere configurati in modo diverso, raccogliendo i voti necessari dai nodi figli, ossia quelli del livello appena inferiore 3 [FKT91]. Un possibile scenario di interconnessione tra le organizzazioni che utilizzano IDN è illustrato nel paragrafo 6.3. Tale scenario realizza una gerarchia a due livelli, in cui il livello inferiore è composto dai server collegati mediante LAN 3 Si suppone che ogni nodo fisico sia in grado di eseguire le azioni di un qualsiasi nodo logico nella gerarchia. 289

308 Replica Management Service Gestione delle risorse all interno delle organizzazioni, mentre il livello superiore è composto da più organizzazioni che comunicano tra loro sfruttando Internet. Si può dunque pensare di costruire un quorum che preveda di ottenere, ad esempio, la maggioranza tra le LAN su cui la risorsa è replicata, e poi in ciascuna di queste LAN la maggioranza tra i server che tengono una replica della risorsa. Questa soluzione garantisce che, comunque presi, due quorum abbiano sempre almeno un nodo nell intersezione, pur mantenendo più piccola possibile la dimensione di quest ultima. Organizzando le repliche secondo la gerarchia, si ha come risultato una suddivisione delle stesse che permette di costruire quorum di dimensione minore. Ottenere la maggioranza al livello superiore della gerarchia permette di scegliere le LAN che si trovano più vicine a qualsiasi client dato, garantendo così un tempo di accesso ottimale. Al livello inferiore si può scegliere nuovamente di ottenere la maggioranza perché, nella pratica, in ogni LAN il numero di server su cui è presente una replica non supera qualche unità, perciò sarebbe superfluo ricorrere a costruzioni più complesse [BBB + 04]. rete LAN 1 LAN 2 LAN Figura 12.1: Votazione con quorum a maggioranza su due livelli Nella figura 12.1 è mostrato un esempio in cui le repliche sono posizionate sui server 11 e 13 della LAN1, sui server 21, 22 e 23 della LAN2, e sul server 33 della LAN3. Un quorum che comprende le LAN 1 e 2 è formato dalle repliche sui server 11, 13, 21 e 22. Un quorum che comprende le LAN 2 e 3 è formato dalle repliche sui server 22, 23 e 33. Questi due quorum si intersecano nel server 22. Altrimenti, nel caso in cui si vogliano mantenere bassi i costi delle operazioni di lettura senza aumentare troppo quelli delle operazioni di scrittura, si può considerare la configurazione di tipo read-one-write-all per il quorum al livello superiore. Quando il sistema gestisce risorse di tipo IDN, potrebbe essere opportuno riuscire a selezionare sempre un quorum che comprenda almeno una tra le LAN dell organizzazione proprietaria della risorsa su cui si vuole effettuare l operazione. Il sito che serve un operazione di scrittura su una risorsa è incaricato di comunicare, al termine dell operazione e se essa ha avuto successo, l avvenuta modifica alle altre istanze di livello RM che possiedono una replica della stessa risorsa, delle quali viene a conoscenza tramite LS. I meccanismi per la propagazione degli aggiornamenti, descritti nel paragrafo 290

309 Replica Management Service Gestione delle risorse C.5.2, definiscono il modo in cui i server si scambiano gli aggiornamenti e in che forma questi debbano essere trasferiti, oltre a chi inizializza il trasferimento e quando esso debba avvenire. In generale, è opportuno scegliere la forma di aggiornamento che minimizza il sovraccarico totale nella comunicazione. Nel sistema di Replica Management considerato, l avvenuta modifica di una risorsa è notificata tramite l invio di un invalidazione, in modo da minimizzare il numero dei messaggi e la quantità di traffico immessi nella rete, come richiesto dal requisito RM-R051. In pratica, si adotta un meccanismo di tipo push che vada ad innescare la richiesta dei dati modificati con un meccanismo di tipo pull. Il requisito RM-R047 specifica le diverse situazioni in cui può essere innescato il processo di sincronizzazione. Nonostante il sito in cui ha avuto origine la modifica possa effettuare il rescheduling dell invio dell invalidazione, deve comunque essere sempre possibile richiedere gli aggiornamenti con un meccanismo di tipo pull, ad esempio per sincronizzare una replica che è rimasta a lungo disconnessa, oppure quando un nodo, in seguito al recupero da un crollo, ha la necessità di controllare la presenza di nuove versioni per le risorse a cui i suoi client vogliono accedere. Un istanza di livello RM che tiene una copia cache di una risorsa non può ricevere gli aggiornamenti relativi ad essa con un meccanismo di tipo push; infatti, le altre istanze di pari livello RM che eseguono modifiche sulle altre repliche della relativa risorsa non sono neanche a conoscenza dell esistenza della copia cache, perché il suo URL non è restituito da LS in seguito all operazione di lookup. L aggiornamento di una copia cache deve necessariamente avvenire con un meccanismo di tipo pull, innescato quando il sistema si accorge, in seguito alla validazione, che è disponibile una versione più recente del contenuto della relativa risorsa. Se si utilizza il meccanismo di scadenza a tempo, conviene che il valore dell intervallo di tempo per il quale la copia cache può essere utilizzata senza bisogno di validarne il contenuto sia grande se la risorsa riceve pochi aggiornamenti, e piccolo in caso contrario. Il requisito RM-R052 afferma che deve essere possibile, nella propagazione degli aggiornamenti, inviare soltanto le parti della risorsa che sono state modificate. A supporto di ciò deve essere fornito un metodo per controllare le differenze tra due repliche di una stessa risorsa, come espresso dal requisito RM-R053. Si suppone che ogni server mantenga un numero arbitrario di differenze tra le versioni di ogni risorsa di cui possiede una replica. Quando riceve una richiesta di sincronizzazione per una certa risorsa, il server confronta il numero di versione della replica che possiede con quello del server richiedente: se la differenza è disponibile può inviarla, riducendo il traffico immesso nella rete, altrimenti deve procedere all invio dell intero contenuto della versione che possiede. Quando si deve mantenere la consistenza di un grande numero di repliche, inviare gli stessi aggiornamenti (che nel sistema di Replica Management con- 291

310 Replica Management Service Gestione delle risorse siderato sono messaggi di invalidazione) a repliche diverse usando connessioni separate può comportare un traffico di rete eccessivo, oltre ad introdurre un sovraccarico considerevole anche sul server in cui la modifica ha avuto origine. Può allora risultare utile impiegare il modello di propagazione epidemico, il quale si occupa di propagare gli aggiornamenti a tutte le repliche con il minor numero di messaggi possibili, ed ha nella scalabilità uno dei suoi principali vantaggi [TvS01]. In un sistema che usa la propagazione epidemica, un sito non deve necessariamente ricevere l aggiornamento dal sito in cui ha avuto origine la modifica, ma la propagazione può passare attraverso dei siti intermedi; perciò, questo modello fornisce la tolleranza ai fallimenti dei link di comunicazione. In generale, quando due siti comunicano, l uno invia all altro gli aggiornamenti di cui non è a conoscenza. Nei sistemi di area geografica, per ottenere risultati migliori può essere utile prendere in considerazione la topologia della rete: ad esempio, si può fare in modo che i siti che sono connessi solo con alcuni degli altri vengano contattati con una probabilità relativamente alta, in quanto rappresentano un ponte verso le altre parti della rete, e perciò conviene che siano contattati il prima possibile. Questo modello di propagazione degli aggiornamenti può essere utilizzato con la semantica delle transazioni, eventualmente affiancato dall approccio a votazione in modo da tollerare sia i fallimenti dei link di comunicazione che quelli dei nodi, come descritto in [HSAA03] Posizionamento delle repliche Il problema del posizionamento può essere suddiviso in due sottoproblemi distinti: il posizionamento dei server e il posizionamento dei contenuti [SSPvS04]. Il primo sottoproblema consiste nel decidere dove posizionare i server che andranno a contenere le repliche, e riguarda quindi la scelta di locazioni adatte a tenere repliche di molte risorse. Anche se in generale la qualità del servizio percepita dai client è un fattore importante per le decisioni relative al posizionamento, di fatto la scelta dei server è legata a vincoli di tipo amministrativo e geografico, come ad esempio i costi economici e la disponibilità del sito fisico. Nel posizionare i server si cerca di immaginare quali possano essere le locazioni più interessanti a prescindere dalle esigenze di breve termine, basando le decisioni sulla topologia generale della rete. Nel contesto IDN, le istanze di livello SI che forniscono il servizio di memorizzazione persistente costituiscono i server sui quali risiedono fisicamente le repliche delle risorse gestite dal Replica Management; il loro posizionamento è legato alle caratteristiche delle infrastrutture di proprietà delle organizzazioni che decidono di usufruire dei servizi di IDN-SA. Il secondo sottoproblema consiste invece nel decidere quali dei server esistenti usare per contenere le diverse repliche di una certa informazione, al fine di migliorare la qualità del servizio fornito ai client e bilanciare il carico. Una classificazione degli algoritmi di posizionamento delle repliche (Replica 292

311 Replica Management Service Gestione delle risorse Placement Algorithm, in breve RPA) esistenti in letteratura e un confronto tra di essi in base alle loro prestazioni si trovano in [WCL + 03]. Nel sistema di Replica Management considerato, la creazione e la rimozione di una replica possono essere innescate internamente oppure richieste esplicitamente dall utente di un istanza di livello RM. Per queste operazioni, il sistema si interfaccia con il servizio di memorizzazione persistente offerto da SI, e parallelamente si occupa di comunicare a LS l inserimento o la rimozione dell associazione tra l URL della replica e il PRI della risorsa. Si consideri cosa accade quando un istanza di livello RM riceve una richiesta di creazione per una nuova risorsa. Nella richiesta può essere specificato, tramite appositi parametri, il livello di affidabilità o di prestazioni atteso per la risorsa, in base al quale il sistema decide il numero k di repliche da creare. A questo punto si presenta il problema di scegliere le istanze di livello SI sulle quali creare le repliche. Ogni istanza di livello RM mantiene in locale un elenco di n istanze di livello SI, con n variabile nel tempo, perciò il problema del posizionamento consiste nello scegliere k su n servizi di storage sui quali creare una replica della risorsa. Nell elenco, le istanze di livello SI sono raggruppate per istanza di livello RM autoritativa e ordinate per priorità, la quale dipende da fattori quali le caratteristiche di affidabilità e la capacità di storage dei dispositivi, e viene aggiornata dinamicamente in base alle condizioni di carico. A parità di priorità, la scelta dell istanza di livello SI su cui effettuare il posizionamento della replica può avvenire con una politica di tipo round-robin che selezioni uno dopo l altro tutti server disponibili, bilanciando così il carico tra di essi. Se il risultato dell algoritmo di posizionamento indica un istanza di livello SI su cui l istanza di livello RM che aveva ricevuto la richiesta da parte dell utente è autoritativa, quest ultima può direttamente procedere alla creazione della replica. Altrimenti, è necessario contattare l istanza di pari livello RM autoritativa, la quale provvederà alla creazione della replica sull istanza di livello SI scelta dall algoritmo di posizionamento, se specificata, oppure su una qualsiasi tra le istanze di livello SI sulle quali è autoritativa. In seguito a variazioni nel tasso delle richieste effettuate dai client, potrebbe essere opportuno innescare il posizionamento delle repliche allo scopo di adattare il sistema alle nuove condizioni. Ad esempio, se il sistema è in grado di identificare una situazione in cui il numero di richieste per uno stesso oggetto logico aumenta considerevolmente, può reagire aumentando il numero delle repliche ad esso associate, per evitare che i client percepiscano una latenza eccessiva. Nel sistema considerato, ogni istanza di livello RM può decidere autonomamente, in base ai pattern di richiesta da parte dei client, se creare una replica di una risorsa, una volta ottenuto il permesso dal proprietario di quest ultima. Ciascun server calcola periodicamente il tasso di richieste per una data risorsa, e decide di creare una replica locale se esso supera una certa soglia; decide invece di rimuovere la replica quando gli accessi calano. In riferimento al paragrafo C.5.1, tali repliche si identificano con quelle create su iniziativa del server. Si presume che il costo relativo alla creazione o alla rimozione delle repliche nei server esistenti è relativamente basso, gli algoritmi di posizionamento dei 293

312 Replica Management Service Gestione delle risorse contenuti possono essere eseguiti spesso, in modo da seguire il più possibile le variazioni del carico. In relazione al livello di affidabilità richiesto per la risorsa, il sistema deve fare in modo che il numero totale delle sue repliche non scenda oltre un limite prestabilito. Per quanto riguarda le copie cache, infine, la decisione in merito alla loro creazione nasce per motivi legati esclusivamente all ottimizzazione delle prestazioni, qualora non si voglia creare una replica dell informazione o il proprietario della stessa non lo conceda. Una copia cache viene creata e rimossa da un servizio di storage con il medesimo criterio di posizionamento usato per le repliche. L unica differenza è la mancata associazione in LS tra URL e PRI; sta a ciascuna istanza di livello RM mantenere in un catalogo locale tale associazione per ognuna delle copie cache che possiede Selezione della replica e routing delle richieste Posizionare le repliche attentamente è utile soltanto se poi i client sono in grado di accedere veramente alla replica più vicina. Il problema della selezione della replica consiste nel decidere quale tra le repliche di una stessa risorsa sia più adatta a servire la richiesta di un client: questa scelta è difficile, perché le condizioni del sistema quali il carico dei server, la congestione dei collegamenti e, di conseguenza, la latenza della rete cambiano continuamente. La variabilità delle condizioni può portare a scegliere repliche diverse a seconda del momento e del client che ha effettuato la richiesta. Ad esempio, una replica che appare ottimale per per un dato client non necessariamente rimane sempre ottimale per quello stesso client; analogamente, quando due client richiedono la stessa risorsa contemporaneamente, possono essere serviti da repliche diverse. Nel sistema di Replica Management considerato, quando un istanza di livello RM riceve una richiesta di accesso ad una risorsa da parte di un client, per prima cosa controlla nel catalogo locale se il PRI della risorsa corrisponde ad una delle copie cache che possiede: in caso affermativo, e se la copia cache è ancora valida, la utilizza per servire la richiesta. Altrimenti viene contattato LS, il quale restituisce una lista di URL corrispondenti alle varie repliche della risorsa, raggruppati per istanza di livello RM proprietaria. Si noti che in LS la lista di URL è contenuta in una risorsa che si compone di più parti, ciascuna delle quali è sottoposta ai diritti di accesso. Di conseguenza, la lista restituita all istanza di livello RM che ha chiesto il lookup del PRI potrebbe non comprendere gli URL di tutte le repliche esistenti nel sistema. A questo punto, viene invocato un algoritmo che sceglie una tra le repliche con URL nella lista restituita da LS. Tale algoritmo si avvale di un meccanismo che ad ogni istanza di livello SI associa un peso, il quale può essere calcolato in base a dei parametri che riflettano le condizioni del sistema. Quando si adotta l approccio a votazione per 294

313 Replica Management Service Gestione delle risorse il mantenimento della consistenza, il peso associato ad ogni servizio di storage è strettamente correlato ai voti che possiede la replica presente su quel servizio; con una certa frequenza, i server inviano informazioni sulle loro condizioni di carico, in base alle quali è effettuata la riassegnazione dei voti. In generale, se esiste una replica di cui l istanza di livello RM che ha ricevuto la richiesta è proprietaria, si accederà a quella. In caso contrario, la richiesta viene inoltrata ad una delle istanze di pari livello RM proprietarie di una replica, e il problema diventa analogo a quello dell instradamento (routing). Il client non viene informato della scelta della replica, e si limita ad attendere la risposta da parte dell istanza di livello RM. Si noti che, per come è stato definito finora, il sistema di Replica Management permette che in alcuni casi i client osservino violazioni della consistenza sequenziale. Infatti, quando un client accede più volte ad una risorsa, può succedere che le sue richieste siano servite prima da una replica e poi da una diversa, a seconda del risultato della selezione. Ad esempio, si considerino due repliche A e B di una stessa risorsa. Si supponga che la replica A abbia ricevuto un aggiornamento che la replica B non ha ancora ricevuto: se un client accede prima ad A e poi a B, può darsi che osservi in B dei valori che sono inconsistenti con la consistenza sequenziale. Perciò, è opportuno che la selezione della replica faccia in modo che un dato client sia servito dalla stessa replica per lunghi periodi di tempo. Questo inconveniente può essere risolto come suggerito in [NDI03]: ogni server che mantiene una replica inserisce nelle risposte che invia ai client un cookie HTTP che indica l ultima versione della risorsa osservata da quel client. Successivamente, questo cookie viene controllato ogni volta che il client invia una richiesta per quella stessa risorsa. Se un server riceve una richiesta da parte di un client che ha osservato per ultima una certa versione della risorsa specificata nella richiesta, e la replica sul server contiene una versione precedente, allora il server innesca la sincronizzazione in modo da ottenere l ultima versione disponibile prima di processare la richiesta Azioni atomiche e transazioni In generale, ogni operazione richiesta dall utente sulle risorse gestite dal sistema si compone di più passi, ossia operazioni primitive eseguite indivisibilmente da parte dell hardware, in una certa sequenza, e in modo che una nuova operazione possa iniziare solo dopo che la precedente è terminata. In altre parole, queste operazioni primitive godono dei benefici di indivisibilità, sequenzialità e non interferenza correlati all atomicità, e perciò sono considerate azioni atomiche. Nessuno degli stati interni, ma soltanto lo stato iniziale e lo stato finale dell azione rispetto alla sua esecuzione sono visibili: è la cosiddetta proprietà tutto o niente, la quale implica che un azione atomica o viene portata a termine completamente, e con successo, oppure deve apparire come se non fosse stata eseguita affatto [Jal94]. Perché la consistenza delle risorse gestite dal sistema di Replica Management sia garantita, è necessario che le operazioni che l utente può richiedere su di esse 295

314 Replica Management Service Gestione delle risorse siano azioni atomiche, cioè siano eseguite nello stesso modo in cui l hardware esegue le sue istruzioni. Adottando la terminologia in uso nel contesto dei database, un azione da eseguire in modo atomico che rappresenta l unità logica fondamentale di computazione è detta transazione. Una transazione è portata a termine in modo affidabile se la sua esecuzione presenta le seguenti proprietà (test ACID) [BN97]: Atomicità. Una transazione non può essere eseguita soltanto in parte: o viene eseguita completamente, o non viene eseguita affatto. Questa proprietà è garantita mediante appositi protocolli, descritti nel seguito. Consistenza. Quando una transazione inizia e termina l accesso ai dati, il sistema si trova sempre in uno stato consistente. Questa proprietà è garantita dal controllo della concorrenza. Isolamento. Il risultato di una transazione non è visibile alle altre transazioni fino a quando essa non è stata completata. Anche questa proprietà è garantita dal controllo della concorrenza. Durevolezza. Quando una transazione è stata portata a termine con successo, le modifiche apportate da essa sui dati diventano permanenti. Nel sistema considerato, questa proprietà è garantita dal livello SI. Nel sistema di Replica Management considerato, il controllo della concorrenza può essere realizzato utilizzando dei protocolli come il two-phase locking (2PL), in modo da garantire la serializzabilità delle transazioni 4 [CDK00]. Come accennato nel paragrafo 1.5.4, una transazione può essere vista come una sequenza di azioni compresa tra un comando begin_transaction e un comando end_transaction. Quest ultimo spesso è preceduto da un comando di commit, il cui scopo è assicurare che il risultato della transazione non venga annullato in futuro. In un sistema centralizzato, prima che venga effettuato il commit della transazione, viene scritto il log di redo, in modo che, se in seguito il nodo fallisce, nel log siano disponibili abbastanza dati per ripetere tale transazione, ormai considerata come committed. In un sistema distribuito, la situazione è più complessa, perché le operazioni di una transazione possono essere eseguite su nodi diversi. Può succedere che un nodo decida di interrompere l esecuzione di quella parte della transazione che viene eseguita in quel nodo, o perché esso fallisce, o perché, per qualche motivo, non è in grado di eseguire l operazione richiesta. Se ciò accade, anche se gli altri nodi sono in grado di eseguire le loro parti della transazione, l intera transazione deve essere interrotta, cioè terminare come aborted. 4 Si osservi che le considerazioni esposte si riferiscono al livello Replica Management di IDN, il quale gestisce risorse che rappresentano una data versione di una data informazione primitiva. Sarà compito dei livelli superiori occuparsi di gestire il controllo della concorrenza su ognuno dei nodi che costituiscono il documento IDN, in modo da impedire che più utenti di livello applicativo modifichino contemporaneamente un informazione primitiva aggregata da più documenti. 296

315 Replica Management Service Interfacce Infatti, se alcune parti della transazione non possono essere eseguite, allora tutte le sue attività dovranno essere annullate, perché l effetto deve essere lo stesso che si sarebbe avuto se la transazione non fosse mai iniziata. Soltanto nel caso in cui tutti i nodi che prendono parte alla transazione sono disponibili ad eseguirne il commit, essa può terminare come committed. Un protocollo di commit (Atomic Commit Protocol, in breve ACP) garantisce l atomicità in quanto si occupa di assicurare che sia mantenuta la proprietà tutto o niente. Un ACP utilizzato spesso in ambienti distribuiti, quando una transazione coinvolge più siti, è il two-phase commit (2PC). Quando il sistema di Replica Management considerato utilizza l approccio a votazione per il mantenimento della consistenza, si serve di un protocollo di questo tipo ogni volta che raccoglie i voti per ottenere un quorum di lettura o di scrittura oppure esegue la modifica di una risorsa aggiornando un numero di repliche pari al quorum di scrittura. Infine, bisogna che l atomicità delle operazioni eseguite dall utente sia preservata anche in presenza di fallimenti. Si rendono necessari dei protocolli per assicurare che una transazione venga completata, cioè sia committed o aborted, anche quando si verificano dei guasti. Un protocollo di termination, in particolare, viene utilizzato per gestire il guasto, mentre un protocollo di recovery serve ad assicurare che una replica guasta, una volta che è stata ripristinata, assuma uno stato consistente. Quando non c è modo di determinare se una replica è guasta, il protocollo di termination non può essere invocato, e non resta che aspettare che le repliche guaste siano ripristinate. Ciò può capitare nel caso in cui la comunicazione avvenga con modelli di interazione debolmente accoppiati, come ad esempio POP3 e SMTP nel caso della posta elettronica Interfacce La finalità del sistema di Replica Management è quella di fornire all utente un servizio di gestione di risorse replicate in modo trasparente ai livelli superiori. Dal punto di vista dell utente, il Replica Management è un entità remota alla quale effettuare richieste di servizio. L interazione è basata sul paradigma client-server: nel contesto IDN, il client è rappresentato dal livello Information History, il quale sfrutta il servizio fornito da Replica Management, il server. In questi termini, IH agisce da attore 5 nei confronti di RM, il quale mette a disposizione un interfaccia attraverso cui interagire. Quando procede ad inviare una richiesta, il client può specificare alcuni parametri, che possono essere obbligatori oppure opzionali a seconda dell operazione. Un parametro può servire a specificare la politica di accesso in lettura, la quale indica il tipo di semantica attesa in risposta dal sistema; in altre parole, mediante questo parametro è possibile indicare se si desidera ricevere necessariamente l ultima versione disponibile del dato. Esisteranno inoltre dei parametri tramite i quali l utente ha la facoltà di controllare le caratteristiche della risorsa relativamente alla tolleranza ai guasti, 5 Con attore si intende un entità esterna rispetto al sistema in esame, che scambia con esso messaggi in ingresso e/o in uscita. Il contesto è relativo ai diagrammi UML [RJB99]. 297

316 Replica Management Service Interfacce all affidabilità, alla disponibilità e alle prestazioni in lettura e scrittura attese per quel dato. Questi parametri sono esposti all utente ma non sono memorizzati direttamente dal sistema, il quale si occupa di tradurli opportunamente e, di conseguenza, aggiornare i metadati di livello RM relativi a quella particolare risorsa. Ad esempio, se attraverso gli appositi parametri l utente richiede per una risorsa un grado elevato di tolleranza ai guasti, il sistema può impostare un certo numero minimo di repliche esistenti e decidere di utilizzare l approccio a votazione per il mantenimento della consistenza, in modo che ad ogni operazione di scrittura venga obbligatoriamente aggiornata una quantità di repliche pari al quorum di scrittura. Nel seguito è dunque introdotta, secondo il formalismo dei diagrammi dei casi d uso di UML, l interfaccia esposta da Replica Management. La finalità è quella di presentare i vari tipi di richieste che possono essere inviate a RM, dando, allo stesso tempo, una descrizione delle azioni svolte dal sistema. Più avanti sarà introdotta, con la stessa modalità, anche l interfaccia messa a disposizione da Localization Service, allo scopo di evidenziare come RM si avvalga di LS per soddisfare le richieste dei livelli superiori. Per convenzione, ad ogni caso d uso è assegnato un nome del tipo: identificativo_sistema.identificativo_contesto.numero dove: identificativo_sistema è l identificativo del sistema che permette di associare il caso d uso ad un sistema specifico. Ad esempio, RM è Replica Management e LS è Localization Service. identificativo_contesto è l identificativo del contesto che specifica a quale entità del sistema si riferisce il caso d uso. Ad esempio, Int corrisponde all interfaccia. numero è il numero sequenziale che permette di assegnare ad ogni caso d uso un nome univoco, come richiesto dalle specifiche UML Interfaccia esposta da Replica Management Nella descrizione che segue, con sistema si intende il livello Replica Management, principale soggetto dell interazione. Nelle figure 12.2, 12.3 e 12.4 sono riportati i diagrammi dei casi d uso che riassumono graficamente le primitive esposte da Replica Management, raggruppate con nomi diversi a seconda del tipo di funzionalità che offrono. In genere, queste operazioni sono richieste dal livello superiore, ossia Information History, ma possono esserlo anche da istanze di pari livello che, non possedendo i diritti per eseguirle direttamente, procedono all inoltro verso l istanza proprietaria della risorsa. Le operazioni raggruppate col nome Admin realizzano delle funzionalità che violano la trasparenza della replicazione, e possono essere eseguite solo dagli amministratori del sistema. Nella figura 12.5 è riportato il diagramma dei casi d uso che riassume graficamente le primitive esposte da Replica Management esclusivamente alle istanze 298

317 Replica Management Service Interfacce di pari livello: sono operazioni che si occupano della propagazione degli aggiornamenti tra le diverse repliche di una stessa risorsa, e in quanto tali non sono esposte ai livelli superiori. Replica Management RM.int.CREATE RM.int.READ RM.int.UPDATE RM.int.DELETE RM.int.PROBEMETA client RM.int.READMETA RM.int.UPDATEMETA RM.int.READDATA RM.int.UPDATEDATA Figura 12.2: Casi d uso dell interfaccia esposta da RM: operazioni CRUD Caso d uso: RM.Int.CREATE ID: UC.RM.Int.1 Attori: Information History. Sequenza degli eventi: 1. Il caso d uso inizia quando l utente ha la necessità di creare una nuova risorsa di livello RM, ed invia al sistema la richiesta insieme ai dati e ai metadati che ne costituiranno il contenuto. 299

318 Replica Management Service Interfacce L utente può inoltre specificare eventuali parametri relativi alle caratteristiche desiderate per la nuova risorsa, che altrimenti saranno generati automaticamente dal sistema. 2. Il sistema richiede a LS la creazione di un nuovo PRI 6 (si faccia riferimento al caso d uso UC.LS.Int.1). 3. Il sistema decide, in base ai parametri forniti dall utente o generati automaticamente, quante repliche creare per la nuova risorsa, ed effettua il posizionamento delle stesse richiedendone a SI la creazione mediante l invio dei dati e dei metadati forniti dall utente. 4. Il sistema aggiorna le informazioni relative al nuovo PRI contenute in LS (si faccia riferimento al caso d uso UC.LS.Int.3). In particolare, inserisce l associazione tra il PRI della nuova risorsa e gli URL delle sue repliche e aggiorna, in base ai parametri relativi alle caratteristiche della nuova risorsa, i metadati riguardanti, ad esempio, la politica per il mantenimento della consistenza e/o il numero di repliche esistenti. 5. Il sistema restituisce all utente il PRI della nuova risorsa, se l operazione è avvenuta con successo, oppure un messaggio di errore, in caso contrario. Scenari secondari: Se il posizionamento indica la creazione di una replica su un servizio di storage sul quale l istanza di livello RM contattata dall utente non è autoritativa, la richiesta dovrà essere inoltrata ad un istanza di pari livello RM autoritativa su quel servizio (si faccia riferimento al caso d uso UC.RM.Int.16). Si suppone che ciò avvenga soltanto in seguito alla creazione di almeno una replica su uno dei servizi di storage sui quali l istanza di livello RM contattata dall utente è autoritativa, e all inserimento dell URL di tale replica in LS. In questo modo si garantisce che esista almeno un URL associato al PRI della risorsa. Caso d uso: RM.Int.READ ID: UC.RM.Int.2 Attori: Information History. Precondizioni: Deve essere noto il PRI della risorsa di livello RM. 6 La creazione delle repliche deve avvenire in seguito alla creazione del PRI, poiché quest ultimo deve essere inserito nelle prime come metadato. Finché non è stata creata almeno un associazione tra il PRI e un URL in LS, la risorsa però non è accessibile. 300

319 Replica Management Service Interfacce Sequenza degli eventi: 1. Il caso d uso inizia quando l utente ha la necessità di accedere in lettura ad una risorsa, ed invia al sistema la richiesta insieme al PRI della risorsa. L utente può inoltre specificare eventuali parametri relativi alla politica di accesso. 2. Il sistema richiede a LS la risoluzione del PRI e le relative informazioni (si faccia riferimento al caso d uso UC.LS.Int.2). 3. Il sistema effettua la selezione della replica, scegliendo uno tra gli URL restituiti da LS. 4. Il sistema richiede a SI la lettura della replica con l URL scelto. 5. Il sistema restituisce all utente il contenuto della risorsa, se l operazione è avvenuta con successo, oppure un messaggio di errore, in caso contrario. Scenari secondari: Se la politica di accesso specificata dall utente lo permette, prima di richiedere a LS la risoluzione del PRI il sistema controlla se è in possesso di una copia cache della risorsa. In caso affermativo, ne richiede a SI la lettura, altrimenti procede a contattare LS. Se il sistema si accorge che la replica con l URL scelto ha ricevuto l invalidazione del contenuto, prima di restituirlo all utente ne invoca l aggiornamento (si faccia riferimento al caso d uso UC.RM.Int.21). Se la replica selezionata non è di proprietà dell istanza di livello RM contattata dall utente, la richiesta di lettura deve essere inoltrata all istanza di pari livello RM che ne è proprietaria. Se la politica per il mantenimento della consistenza in uso per la risorsa segue l approccio del sito primario, e se la politica di accesso specificata dall utente lo richiede, deve essere selezionata la replica primaria. Se la politica per il mantenimento della consistenza in uso per la risorsa segue l approccio a votazione, e se la politica di accesso specificata dall utente lo richiede, deve essere selezionato un numero di repliche tali che la somma dei loro voti sia pari al quorum di lettura. Il sistema chiede a tali repliche di inviare il loro voto e il numero di versione che possiedono. In seguito, il sistema richiede a SI la lettura di una qualsiasi tra le repliche con il numero di versione più alto disponibile. Caso d uso: RM.Int.UPDATE ID: UC.RM.Int.3 301

320 Replica Management Service Interfacce Attori: Information History. Precondizioni: Deve essere noto il PRI della risorsa di livello RM. Sequenza degli eventi: 1. Il caso d uso inizia quando l utente ha la necessità di accedere in scrittura ad una risorsa, ed invia al sistema la richiesta insieme al PRI della risorsa e ai dati e ai metadati che ne costituiranno il nuovo contenuto. 2. Il sistema richiede a LS la risoluzione del PRI e le relative informazioni (si faccia riferimento al caso d uso UC.LS.Int.2). 3. Il sistema effettua la selezione della replica tra gli URL restituiti da LS. 4. Il sistema richiede a SI l aggiornamento della replica con l URL scelto. 5. Il sistema restituisce all utente un messaggio di conferma, se l operazione è avvenuta con successo, oppure di errore, in caso contrario. 6. Il sistema invia l invalidazione a tutte le istanze di pari livello RM che sono proprietarie di una replica della risorsa (si faccia riferimento al caso d uso UC.RM.Int.20). Scenari secondari: Se la replica selezionata non è di proprietà dell istanza di livello RM contattata dall utente, la richiesta di scrittura deve essere inoltrata all istanza di pari livello RM che ne è proprietaria. Se la politica per il mantenimento della consistenza in uso per la risorsa segue l approccio del sito primario, deve essere selezionata la replica primaria. Se la politica per il mantenimento della consistenza in uso per la risorsa segue l approccio a votazione, deve essere selezionato un numero di repliche tali che la somma dei loro voti sia pari al quorum di scrittura. Il sistema chiede a tali repliche di inviare il loro voto e in seguito richiede la scrittura di ognuna di esse. Caso d uso: RM.Int.DELETE ID: UC.RM.Int.4 Attori: Information History. Precondizioni: 302

321 Replica Management Service Interfacce Deve essere noto il PRI della risorsa di livello RM. Sequenza degli eventi: 1. Il caso d uso inizia quando l utente ha la necessità di eliminare una risorsa di livello RM, ed invia al sistema la richiesta insieme al PRI della risorsa. 2. Il sistema richiede a LS la risoluzione del PRI (si faccia riferimento al caso d uso UC.LS.Int.2). 3. Il sistema richiede a SI l eliminazione di tutte le repliche con URL restituito da LS. 4. Il sistema richiede a LS l eliminazione del PRI (si faccia riferimento al caso d uso UC.LS.Int.4). 5. Il sistema restituisce all utente un messaggio di conferma, se l operazione è avvenuta con successo, oppure di errore, in caso contrario. Scenari secondari: Se una delle repliche non è di proprietà dell istanza di livello RM contattata dall utente, la richiesta di rimozione deve essere inoltrata all istanza di pari livello RM che ne è proprietaria. Caso d uso: RM.Int.PROBEMETA ID: UC.RM.Int.5 Attori: Information History. Precondizioni: Deve essere noto il PRI della risorsa di livello RM. Sequenza degli eventi: 1. Il caso d uso inizia quando l utente ha la necessità di conoscere quali metadati sono associati ad una risorsa di livello RM, ed invia al sistema la richiesta insieme al PRI della risorsa. L utente può inoltre specificare eventuali parametri relativi alla politica di accesso. 2. Il sistema esegue la lettura della risorsa con PRI fornito dall utente (si faccia riferimento al caso d uso UC.RM.Int.2). 3. Il sistema restituisce all utente i nomi dei metadati associati alla risorsa, se l operazione è avvenuta con successo, oppure un messaggio di errore, in caso contrario. 303

322 Replica Management Service Interfacce Caso d uso: RM.Int.READMETA ID: UC.RM.Int.6 Attori: Information History. Precondizioni: Deve essere noto il PRI della risorsa di livello RM. Sequenza degli eventi: 1. Il caso d uso inizia quando l utente ha la necessità di accedere in lettura ad un metadato di una risorsa di livello RM, ed invia al sistema la richiesta insieme al PRI della risorsa e al nome del metadato. L utente può inoltre specificare eventuali parametri relativi alla politica di accesso. 2. Il sistema esegue la lettura della risorsa con PRI fornito dall utente (si faccia riferimento al caso d uso UC.RM.Int.2). 3. Il sistema restituisce all utente il valore del metadato, se l operazione è avvenuta con successo, oppure un messaggio di errore, in caso contrario. Caso d uso: RM.Int.UPDATEMETA ID: UC.RM.Int.7 Attori: Information History. Precondizioni: Deve essere noto il PRI della risorsa di livello RM. Sequenza degli eventi: 1. Il caso d uso inizia quando l utente ha la necessità di accedere in scrittura ad un metadato di una risorsa di livello RM, ed invia al sistema la richiesta insieme al PRI della risorsa e al nome e al nuovo valore del metadato. 2. Il sistema esegue la scrittura della risorsa con PRI fornito dall utente (si faccia riferimento al caso d uso UC.RM.Int.3). 3. Il sistema restituisce all utente un messaggio di conferma, se l operazione è avvenuta con successo, oppure di errore, in caso contrario. 304

323 Replica Management Service Interfacce Caso d uso: RM.Int.READDATA ID: UC.RM.Int.8 Attori: Information History. Precondizioni: Deve essere noto il PRI della risorsa di livello RM. Sequenza degli eventi: 1. Il caso d uso inizia quando l utente ha la necessità di accedere in lettura ai dati di una risorsa di livello RM, ed invia al sistema la richiesta insieme al PRI della risorsa. 2. Il sistema esegue la lettura della risorsa con PRI fornito dall utente (si faccia riferimento al caso d uso UC.RM.Int.2). 3. Il sistema restituisce all utente i dati contenuti nella risorsa, se l operazione è avvenuta con successo, oppure un messaggio di errore, in caso contrario. Caso d uso: RM.Int.UPDATEDATA ID: UC.RM.Int.9 Attori: Information History. Precondizioni: Deve essere noto il PRI della risorsa di livello RM. Sequenza degli eventi: 1. Il caso d uso inizia quando l utente ha la necessità di accedere in scrittura ai dati di una risorsa di livello RM, ed invia al sistema la richiesta insieme al PRI della risorsa e ai dati che ne costituiranno il nuovo contenuto. 2. Il sistema esegue la scrittura della risorsa con PRI fornito dall utente (si faccia riferimento al caso d uso UC.RM.Int.3). 3. Il sistema restituisce all utente un messaggio di conferma, se l operazione è avvenuta con successo, oppure di errore, in caso contrario. 305

324 Replica Management Service Interfacce Replica Management RM.int.GETPOLICY RM.int.SETPOLICY RM.int.DUPLICATE client RM.int.CHECK RM.int.LOCK Figura 12.3: Casi d uso dell interfaccia esposta da RM: operazioni Advanced Caso d uso: RM.Int.GETPOLICY ID: UC.RM.Int.10 Attori: Information History. Precondizioni: Deve essere noto il PRI della risorsa di livello RM. Sequenza degli eventi: 1. Il caso d uso inizia quando l utente ha la necessità di accedere in lettura alle caratteristiche impostate per una risorsa, ed invia al sistema la richiesta insieme al PRI della risorsa. 2. Il sistema richiede a LS le informazioni relative al PRI (si faccia riferimento al caso d uso UC.LS.Int.2). 3. Il sistema restituisce all utente i parametri che descrivono le caratteristiche della risorsa, se l operazione ha avuto successo, oppure un messaggio di errore, in caso contrario. Caso d uso: RM.Int.SETPOLICY 306

325 Replica Management Service Interfacce ID: UC.RM.Int.11 Attori: Information History. Precondizioni: Deve essere noto il PRI della risorsa di livello RM. Sequenza degli eventi: 1. Il caso d uso inizia quando l utente ha la necessità di accedere in scrittura alle caratteristiche impostate per una risorsa, ed invia al sistema la richiesta insieme ai relativi parametri e al PRI della risorsa. 2. Il sistema aggiorna le informazioni relative al PRI contenute in LS (si faccia riferimento al caso d uso UC.LS.Int.3). Ad esempio, possono essere modificati, in base ai parametri forniti dall utente, i metadati riguardanti la politica per il mantenimento della consistenza e/o il numero di repliche esistenti. 3. Il sistema restituisce all utente un messaggio di conferma, se l operazione è avvenuta con successo, oppure di errore, in caso contrario. Scenari secondari: Se l aggiornamento riguarda il numero di repliche esistenti, il sistema può innescare il posizionamento richiedendo a SI la creazione o l eliminazione di un certo numero di repliche (si faccia riferimento ai casi d uso UC.RM.Int.16 e UC.RM.Int.17). Caso d uso: RM.Int.DUPLICATE ID: UC.RM.Int.12 Attori: Information History. Precondizioni: Deve essere noto il PRI della risorsa di livello RM. Sequenza degli eventi: 1. Il caso d uso inizia quando l utente ha la necessità di creare una nuova risorsa di livello RM con lo stesso contenuto di un altra risorsa di livello RM esistente, ed invia al sistema la richiesta insieme al PRI di quest ultima. L utente può inoltre specificare eventuali parametri relativi alle caratteristiche desiderate per la nuova risorsa, che altrimenti saranno generati automaticamente dal sistema. 307

326 Replica Management Service Interfacce 2. Il sistema ottiene i dati e i metadati contenuti nella risorsa identificata dal PRI fornito dall utente (si faccia riferimento al caso d uso UC.RM.Int.2). 3. Il sistema esegue la creazione di una nuova risorsa contenente i dati e i metadati appena ottenuti (si faccia riferimento al caso d uso UC.RM.Int.1). 4. Il sistema restituisce all utente il PRI della nuova risorsa, se l operazione è avvenuta con successo, oppure un messaggio di errore, in caso contrario. Caso d uso: RM.Int.CHECK ID: UC.RM.Int.13 Attori: Information History. Precondizioni: Deve essere noto il PRI della risorsa di livello RM. Sequenza degli eventi: 1. Il caso d uso inizia quando l utente ha la necessità controllare la validità del contenuto di una risorsa di livello RM, ed invia al sistema la richiesta insieme al PRI della risorsa. 2. Il sistema esegue la lettura della risorsa con PRI fornito dall utente (si faccia riferimento al caso d uso UC.RM.Int.2). 3. Il sistema verifica la validità per ogni tipo a cui la risorsa appartiene. 4. Il sistema restituisce all utente il risultato della validazione, se l operazione è avvenuta con successo, oppure di errore, in caso contrario. Caso d uso: RM.Int.LOCK ID: UC.RM.Int.14 Attori: Information History. Precondizioni: Deve essere noto il PRI della risorsa di livello RM. Sequenza degli eventi: 308

327 Replica Management Service Interfacce 1. Il caso d uso inizia quando l utente ha la necessità di bloccare o sbloccare l accesso ad una risorsa di livello RM, ed invia al sistema la richiesta insieme al PRI della risorsa. 2. Il sistema assegna o rimuove il lock alla risorsa seguendo la politica di locking (si faccia riferimento al caso d uso UC.RM.Int.3). 3. Il sistema restituisce all utente un messaggio di conferma, se l operazione è avvenuta con successo, oppure di errore, in caso contrario. Replica Management RM.int.LISTREPLICAS RM.int.CREATEREPLICA RM.int.DELETEREPLICA client RM.int.READREPLICA RM.int.FORCESYNC Figura 12.4: Casi d uso dell interfaccia esposta da RM: operazioni Admin Caso d uso: RM.Int.LISTREPLICAS ID: UC.RM.Int.15 Attori: Information History. Precondizioni: Deve essere noto il PRI della risorsa di livello RM. Sequenza degli eventi: 1. Il caso d uso inizia quando l utente ha la necessità di conoscere quali repliche sono associate ad una risorsa di livello RM, ed invia al sistema la richiesta insieme al PRI della risorsa. 2. Il sistema richiede a LS la risoluzione del PRI (si faccia riferimento al caso d uso UC.LS.Int.2). 309

328 Replica Management Service Interfacce 3. Il sistema restituisce all utente tutti gli URL restituiti da LS, se l operazione è avvenuta con successo, oppure un messaggio di errore, in caso contrario. Caso d uso: RM.Int.CREATEREPLICA ID: UC.RM.Int.16 Attori: Information History. Precondizioni: Deve essere noto il PRI della risorsa di livello RM. Sequenza degli eventi: 1. Il caso d uso inizia quando l utente ha la necessità di creare una replica associata ad una risorsa di livello RM, ed invia al sistema la richiesta insieme al PRI della risorsa. L utente può inoltre specificare il servizio di storage sul quale creare la replica, che altrimenti sarà scelto automaticamente dal sistema. 2. Il sistema ottiene i dati e i metadati contenuti nella risorsa identificata dal PRI fornito dall utente eseguendone la lettura (si faccia riferimento al caso d uso UC.RM.Int.2). 3. Il sistema richiede a SI la creazione della replica mediante l invio dei dati e dei metadati appena ottenuti. 4. Il sistema aggiorna le informazioni relative al PRI fornito dall utente contenute in LS (si faccia riferimento al caso d uso UC.LS.Int.3). In particolare, inserisce l associazione tra il PRI fornito dall utente e l URL della nuova replica e aggiorna i metadati riguardanti, ad esempio, la politica per il mantenimento della consistenza e/o il numero di repliche esistenti. 5. Il sistema restituisce all utente un messaggio di conferma, se l operazione è avvenuta con successo, oppure di errore, in caso contrario. Scenari secondari: Se la risorsa di cui si intende creare una replica non possiede nessuna URL associata al PRI in LS, l operazione restituisce un messaggio di errore. Se la politica per il mantenimento della consistenza in uso per la risorsa segue l approccio a votazione, la creazione di una nuova replica può innescare la riassegnazione dei voti. 310

329 Replica Management Service Interfacce Caso d uso: RM.Int.DELETEREPLICA ID: UC.RM.Int.17 Attori: Information History. Precondizioni: Deve essere noto l URL della replica. Sequenza degli eventi: 1. Il caso d uso inizia quando l utente ha la necessità di eliminare una replica associata ad una risorsa di livello RM, ed invia al sistema la richiesta insieme all URL della replica. 2. Il sistema richiede a SI la rimozione della replica con URL fornito dall utente. 3. Il sistema aggiorna le informazioni relative al PRI della risorsa alla quale è associata la replica con l URL fornito dall utente contenute in LS (si faccia riferimento al caso d uso UC.LS.Int.3). In particolare, rimuove l associazione tra l URL fornito dall utente e il PRI della risorsa alla quale la replica è associata e aggiorna i metadati riguardanti, ad esempio, la politica per il mantenimento della consistenza e/o il numero di repliche esistenti. 4. Il sistema restituisce all utente un messaggio di conferma, se l operazione è avvenuta con successo, oppure di errore, in caso contrario. Scenari secondari: Se la politica per il mantenimento della consistenza in uso per la risorsa segue l approccio a votazione, la rimozione di una replica può innescare la riassegnazione dei voti. Caso d uso: RM.Int.READREPLICA ID: UC.RM.Int.18 Attori: Information History. Precondizioni: Deve essere noto l URL della replica. Sequenza degli eventi: 311

330 Replica Management Service Interfacce 1. Il caso d uso inizia quando l utente ha la necessità di accedere in lettura ad una replica di una risorsa di livello RM, ed invia al sistema la richiesta insieme all URL della risorsa. 2. Il sistema richiede a SI la lettura della replica con l URL fornito dall utente. 3. Il sistema restituisce all utente il contenuto della replica, se l operazione è avvenuta con successo, oppure un messaggio di errore, in caso contrario. Scenari secondari: Se la replica non è di proprietà dell istanza di livello RM contattata dall utente, la richiesta deve essere inoltrata all istanza di pari livello RM che ne è proprietaria. Caso d uso: RM.Int.FORCESYNC ID: UC.RM.Int.19 Attori: Information History. Precondizioni: Deve essere noto l URL della replica. Sequenza degli eventi: 1. Il caso d uso inizia quando l utente ha la necessità di sincronizzare all ultima versione disponibile una replica di una risorsa di livello RM, ed invia al sistema la richiesta insieme all URL della risorsa. 2. Il sistema richiede la sincronizzazione della replica con l URL fornito dall utente (si faccia riferimento al caso d uso UC.RM.Int.21). 3. Il sistema restituisce all utente un messaggio di conferma, se l operazione è avvenuta con successo, oppure di errore, in caso contrario. Caso d uso: RM.Int.INVALIDATE ID: UC.RM.Int.20 Attori: Replica Management. Precondizioni: 312

331 Replica Management Service Interfacce Replica Management RM.int.INVALIDATE client RM.int.REQUESTSYNC Figura 12.5: Casi d uso dell interfaccia esposta da RM a istanze di pari livello Deve essere noto l URL della replica. Sequenza degli eventi: 1. Il caso d uso inizia quando l istanza di livello RM che ha eseguito una modifica su una risorsa ha la necessità di comunicare ad un altra replica l avvenuto aggiornamento, ed invia all istanza di pari livello RM che la possiede la notifica insieme all URL della replica. L istanza che richiede l operazione può inoltre specificare il PRI della risorsa. 2. L istanza di pari livello RM applica l invalidazione alla replica con l URL fornito dall utente. 3. L istanza di pari livello RM restituisce un messaggio di conferma, se l operazione è avvenuta con successo, oppure di errore, in caso contrario. Caso d uso: RM.Int.REQUESTSYNC ID: UC.RM.Int.21 Attori: Replica Management. Precondizioni: Deve essere noto l URL della replica. Sequenza degli eventi: 1. Il caso d uso inizia quando l istanza di livello RM ha la necessità di sincronizzare all ultima versione disponibile una replica di una risorsa di livello RM, ed invia all istanza di pari livello RM la richiesta insieme al PRI della risorsa e al numero di versione della replica che possiede. 2. L istanza di pari livello RM confronta il numero di versione fornito dall utente con quello della replica che possiede. 313

332 Replica Management Service Interfacce 3. L istanza di pari livello RM restituisce la differenza tra le versioni del contenuto della risorsa, se possibile, oppure l intero contenuto, in caso contrario Interfaccia esposta da Localization Service La definizione dell interfaccia esposta da Localization Service assume particolare importanza perché il sistema dei nomi gioca un ruolo fondamentale in IDN. In questo caso, l attore principale (il client) è Replica Management, il quale richiede l espletamento di alcuni servizi a Localization Service (il server). Nella descrizione che segue, quindi, con sistema si intende LS, principale soggetto dell interazione. Localization Service LS.int.CREATE LS.int.READ Replica Management LS.int.UPDATE LS.int.DELETE Figura 12.6: Casi d uso dell interfaccia esposta da Localization Service Nella figura 12.6 è riportato il diagramma dei casi d uso che riassume graficamente le primitive che LS fornisce a RM. Caso d uso: LS.Int.CREATE ID: UC.LS.Int.1 Attori: Replica Management. Sequenza degli eventi: 1. Il caso d uso inizia quando l utente ha la necessità di assegnare un identificatore univoco e persistente ad una nuova risorsa di livello RM, ed invia al sistema la richiesta. 2. Il sistema genera un nuovo identificatore di tipo PRI. 314

333 Replica Management Service Interfacce 3. Il sistema restituisce all utente il nuovo PRI, se l operazione è avvenuta con successo, oppure un messaggio di errore, in caso contrario. Caso d uso: LS.Int.READ ID: UC.LS.Int.2 Attori: Replica Management. Precondizioni: Deve essere noto il PRI della risorsa di livello RM. Sequenza degli eventi: 1. Il caso d uso inizia quando l utente ha la necessità di tradurre il PRI relativo ad una risorsa di livello RM negli URL delle sue repliche e/o di accedere in lettura ai metadati associati, ed invia al sistema la richiesta insieme al PRI della risorsa. 2. Il sistema recupera le informazioni relative al PRI fornito dall utente. 3. Il sistema restituisce all utente gli URL delle repliche della risorsa di livello RM identificata dal PRI e i metadati associati, se l operazione è avvenuta con successo, oppure un messaggio di errore, in caso contrario. Caso d uso: LS.Int.UPDATE ID: UC.LS.Int.3 Attori: Replica Management. Precondizioni: Deve essere noto il PRI della risorsa di livello RM. Sequenza degli eventi: 1. Il caso d uso inizia quando l utente ha la necessità di aggiungere o rimuovere l associazione tra il PRI relativo ad una risorsa di livello RM e gli URL di una o più delle sue repliche e/o di accedere in scrittura ai metadati associati, ed invia al sistema la richiesta insieme al PRI della risorsa. 315

334 Replica Management Service Interfacce 2. Il sistema aggiorna le informazioni relative al PRI fornito dall utente. 3. Il sistema restituisce all utente un messaggio di conferma, se l operazione è avvenuta con successo, oppure di errore, in caso contrario. Caso d uso: LS.Int.DELETE ID: UC.LS.Int.4 Attori: Replica Management. Precondizioni: Deve essere noto il PRI della risorsa di livello RM. Sequenza degli eventi: 1. Il caso d uso inizia quando l utente ha la necessità di eliminare il PRI relativo ad una risorsa di livello RM, ed invia al sistema la richiesta insieme al PRI della risorsa. 2. Il sistema elimina il PRI fornito dall utente e tutte le relative informazioni. 3. Il sistema restituisce all utente un messaggio di conferma, se l operazione è avvenuta con successo, oppure di errore, in caso contrario. 316

335 Capitolo 13 Storage Interface Service Storage Interface si presenta come un servizio la cui interfaccia espone operazioni per la gestione della memorizzazione persistente di risorse. In questo capitolo sarà fornita la specifica delle operazioni, il modello dati (formalizzato in WSDL) ed i protocolli per la comunicazione. L interfaccia del servizio scambia messaggi che trasportando informazioni, permettono il trattamento delle risorse definite in questa specifica. Il servizio offre delle specifiche funzioni per poter gestire queste risorse. Una determinata funzionalità del servizio è realizzata da una operazione. Durante l esecuzione di una operazione, avviene lo scambio di messaggi tra consumer e provider del servizio. I messaggi sono classificati in messaggi di input, output o fault e raggruppati in base alle funzionalità che offrono. Nella prima sezione verrà presentato l information model della risorsa, l information model dei messaggi e la specifica delle operazioni. Saranno inoltre presentati i metadati predefiniti, che assolvono a funzioni nate dalla specifica dei requisiti Requisiti Si riporta la stesura dei requisiti del servizio di Storage Interface. Ogni requisito è descritto da: Codice identificativo Classificazione del requisito Testo del requisito Eventuale descrizione in italiano

336 Storage Interface Service Requisiti Ogni requisito ha un codice identificativo del tipo RXXX dove alle X si sostituisce un codice numerico di 3 cifre. Il codice è assegnato al requisito progressivamente in ordine cronologico. I codici dei requisiti rifiutati non sono stati riutilizzati, rendendo in questo modo univoca l identificazione di ogni requisito. La descrizione è da considerarsi normativa la dove ambiguità possano insorgere nell interpretazione del requisito. Requirement R001 Functional Requirement SI MUST manage Resources made of Data and Metadata La funzionalità principale di SI è definita da questo requisito: il Storage Interface deve permettere di utilizzare risorse composte da un dato, e di poter gestire dei metadati che sono associati a questi dati. Requirement R002 Functional Requirement SI MUST provide a Service for managing resources Questo requisito specifica che SI deve essere un Servizio e che deve offrire funzionalità di gestione di Risorse. Requirement R003 Functional Requirement SI MUST provide CRUD functionality on Resources Il servizio deve offrire le quattro funzionalità dello storage persistente: Create. Crea una nuova risorsa di livello SI nel servizio di storage a cui sono inviati i dati e i metadati che andranno a costituirla. Read. Restituisce al consumer un messaggio che contiene i dati e i metadati della risorsa di livello SI specificata. Update. Modifica la risorsa di livello SI specificata attuando la memorizzazione dei dati e metadati inviati. Delete. Rimuove dal servizio di storage la risorsa di livello SI specificata, rendendo non più valido il relativo identificatore e quindi l URL. Requirement R004 Design Constraint The Service MUST be globally addressable 318

337 Storage Interface Service Requisiti Il servizio deve avere un nome che ne specifica il punto di accesso, in altre parole il suo endpoint Requirement R005 Functional Requirement A Resource MUST be identified and addressed Quindi una risorsa deve avere un nome che ne specifica il punto di accesso ed identità. Requirement R006 Standard Compliance A Resource MUST be identified and addressed using URLs Si richiede che adottati Uniform Resource Locator (URL) come sistema di nomi per identificare ed indirizzare le risorse. Requirement R008 Design Constraint SI s interface MUST be abstract L interfaccia definita dalla specifica di SI deve essere astratta, ovvero si richiede che le operazioni ed i messaggi siano descritti senza riferimenti a protocolli o linguaggi di programmazione specifici. Requirement R009 Design Constraint SI s interface MUST be RESTful L interfaccia deve essere progettata secondo lo stile dei sistemi REST[Fie00]. Requirement R010 Functional Requirement SI SHOULD be implemented as a ROA Requirement R011 Portability SI MAY support other protocol than HTTP 319

338 Storage Interface Service Requisiti Visto che l interfaccia di SI deve essere astratta, è possibile pensare ad una sua implementazione basata su altri protocolli di trasporto per fini di flessibilità. Requirement R012 Portability SI MAY be implemented using other architectural solution Requirement R013 Design Constraint SI s MUST be implementable using different programming languages Requirement R015 Security SI MUST handle access control on Resources L interfaccia deve quindi essere progettata seguendo criteri che permettano di controllare l accesso di una risorsa, e pertanto le operazione devono prevedere il trasporto di credenziali per l autorizzazione di accesso ad una risorsa, per una determinata entità, svolgendo una determinata operazione. Requirement R016 Security SI MUST support different authentication/authorization/audit systems Deve essere possibile per SI l implementazione con diversi meccanismi di protezione, in cui si prevede anche la delega di autorizzazione tra entità. In generale, sarà necessario supportare criteri che gestiscano l autorizzazione basandosi sulle entità in gioco quali: detentore dei diritti sulla risorsa, richiedente dell operazione di accesso, sistema di accesso e lo stesso servizio di Storage Interface. Requirement R021 Functional Requirement SI MUST support notification messages to designed recipients in result of events generated by operations on Resources In particolare si richiede che l interfaccia definita abbia il supporto per la comunicazione di notifiche ad entità autorizzate qualora un evento su una risorsa debba essere tracciato, per fini di manutenzione o altri scopi. 320

339 Storage Interface Service Requisiti Requirement R022 Functional Requirement SI MAY support notification messages to designed recipients in result of generic events Messaggi di notifica possono originare da eventi non conseguenti ad operazioni su risorse, ad esempio eventi pianificati. Requirement R023 Design Constraint SI MUST be able to expose the Data from Legacy Sources as Resources Il servizio deve essere progettato applicando tutti quei criteri che possono semplificare l adattamento a sistemi di storage pre-esistenti. Requirement R024 Functional Requirement SI MAY validate the stored Resources and Resources after creation or update or an explicit request Il servizio può offrire funzionalità di validazione delle risorse, ovvero deve essere possibile l uso di procedure generiche che restituiscano informazioni su una risorsa. In particolare possono essere previsti meccanismi di validazione di risorse memorizzate, di risorse nuove durante la loro creazione o di risorse modificate durante l operazione di aggiornamento. Requirement R025 Standard Compliance SI SHOULD use WSDL for the definition of the Abstract Interface Per offrire una migliore interoperabilità, se possibile, dovrebbe essere offerta una descrizione dell interfaccia astratta di SI tramite le specifiche di WSDL. Requirement R036 Standard Compliance SI MAY use WSDL for the describing Interface implementations Le implementazioni dell interfaccia di SI potrebbero essere descritte con WSDL grazie alle sue estensioni per HTTP e SOAP. In particolare potrebbe essere utile definire una nuova estensione di WSDL per descrivere interfacce che usano altri protocolli, ad esempio TCP. 321

340 Storage Interface Service Requisiti Requirement R026 Standard Compliance Resources SHOULD be compatible with RDF information model Il modello con cui RDF descrive i metadati dovrebbe essere compatibile con i metadati di SI in modo da poter offrire tramite RDF i metadati associati ai dati di una risorsa. Requirement R027 Standard Compliance Resources SHOULD be compatible with RDF Schema type system Dovrebbe poter essere possibile usare RDF Schema per definire le classi a cui una risorsa appartiene. Requirement R028 Functional Requirement SI MAY support specific operations for management or for performance improvements Si possono definire altre operazioni sulle risorse, ad esempio per la creazione di duplicati, o per recuperare l elenco di risorse presenti in un determinato storage. Requirement R037 Functional Requirement Operations different from the basic CRUD MUST be optional in specific implementations Per implementare un servizio di Storage Interface deve essere sufficiente supportare le quattro operazioni di creazione, lettura, modifica e cancellazione, quindi ogni requisito funzionale obbligatorio deve essere offerto attraverso queste quattro operazioni. Requirement R029 Functional Requirement SI MAY allow Locking and Unlocking of Resources Si possono definire operazioni che permettono di bloccare l accesso alle risorse durante la loro modifica. 322

341 Storage Interface Service Requisiti Requirement R030 Standard Compliance SI MUST allow XML representation of Resources Requirement R031 Design Constraint SI MUST support synchronous and asynchronous interaction Le specifiche dell interfaccia non devono impedire la possibilità di implementazioni con un meccanismo asincrono. Requirement R033 Functional Requirement SI MUST support arbitrary Metadata on resources Deve essere possibile memorizzare per una determinata risorsa, metadati di tipo sconosciuto. Requirement R034 Functional Requirement Metadata SHOULD be univocally identified by a qualified name Ogni metadato in una risorsa deve avere un nome che lo identifica e questo nome deve avere validità globale perchè ad esempio appartiene ad un namespace definito con URI. Requirement R035 Functional Requirement Metadata value SHOULD have a type defined by the qualified name Il nome specificato per la risorsa implica che il valore del metadato abbia un tipo la cui sintassi e semantica siano individuati dal nome e namespace a cui esso appartiene. Un meccanismo di validazione può ad esempio curarsi della verifica che questi valori siano conformi. Requirement R036 Functional Requirement Data and Metadata MUST be hierarchically subordinated to the resource I dati ed i metadati sono contenuti nella risorsa e ne sono figli. 323

342 Storage Interface Service Interfaccia Requirement R037 Functional Requirement SI MUST allow direct access to Metadata Deve essere possibile ottenere il valore di un metadato tramite indirizzamento diretto, ad esempio combinando il nome del metadato con l URL della risorsa Interfaccia Le operazioni ed i messaggi dell interfaccia sono formulati sulla base dei requisiti R002, R003, R009, R015, R016, R021, R022, R024, R028, R029 ed R037. Le operazioni sono raggruppate in cinque gruppi: CRUD: si compone delle quattro operazioni dei sistemi di memorizzazione persistente, e permette di operare sul servizio creando, leggendo, modificando e cancellando le risorse. Il requisito R003 è l origine di questo gruppo. Plus: si compone di tre operazioni che forniscono operazioni ausiliarie per la gestione di risorse, quali la duplicazione diretta, l elenco delle risorse di un servizio e l elenco dei nomi dei metadati di una specifica risorsa. Questo gruppo non nasce da requisiti specifici, ma è permesso da R028. Le funzionalità sono state dedotte da considerazioni di carattere pratico emerse nell analisi degli scenari. Specialized: si compone di quattro operazioni per la lettura e la modifica diretta dei dati e dei metadati. Le operazioni sui metadati sono conseguenza del requisito R037, le operazioni sui dati nascono da considerazioni pratiche e sono permesse dal requisito R028. Functional: si compone di tre operazioni che offrono funzioni atte a soddisfare requisiti opzionali del servizio. La funzionalità di Locking è offerta sulla base del requisito R029, la funzionalità di validazione sulla base di R024. La funzionalità di verifica di condizione nasce da considerazioni pratiche ed è permessa da R028 Event: Sulla base dei requisiti R021 ed R022, si offrono le funzionalità di gestione di sottoscrizione e di notifica di eventi. Durante le chiamate di operazioni si ha uno scambio di messaggi tra le entità in gioco. Un messaggio è essenzialmente una informazione che viene trasmessa al provider (messaggio di input) o dal provider (messaggio di output). Alcuni messaggi trasportano informazioni, altri segnalano errori (messaggi di fault). La principale tipologia di messaggi è quella che contiene dati o metadati di SI-R, ad esempio il messaggio di output di una operazione di lettura oppure il messaggio di input di una operazione di modifica. 324

343 Storage Interface Service Interfaccia Messaggi di input, output, fault e generalità I messaggi delle operazioni sul servizio sono classificati in messaggi di input, messaggi di output o messaggi di fault. Questa classificazione segue il punto di vista del provider del servizio, per il quale un messaggio di input è un messaggio che proviene dall esterno (da consumer a provider) ed un messaggio di output è diretto verso l esterno (da provider a consumer). I messaggi di fault, sono usati per comunicare un qualche inconveniente avvenuto durante la chiamata di una operazione, e in questi casi si sostituiscono al messaggio di risposta. Sulla base dei requisiti e su considerazioni pratiche, i messaggi di input presentano delle caratteristiche comuni per ogni operazione. Il requisito R015 ed R016 richiedono che le informazioni di autenticazione siano trasmesse insieme ad un messaggio di input. Considerazioni pratiche derivate dallo studio degli scenari hanno suggerito di aggiungere informazioni di controllo che permettono il management ed il debug del servizio. Per questo, un messaggio di input trasporta opzionalmente: Informazioni di autenticazione che permettono l attuazione del controllo degli accessi. Informazioni sull agente utilizzato dal consumer, in modo da identificare specifici problemi applicativi o di compatibilità tra implementazioni di servizi e implementazioni di client. Informazioni sull origine del messaggio di input, in modo da ottimizzare le performance di memorizzazione e la tracciabilità delle risorse memorizzate. Informazioni per tracciare i messaggi, ad esempio in cui si è formulato l invio o una chiave univoca del messaggio. Le informazioni per la tracciabilità sono trasportate anche nei messaggi di output. In figura 13.1 è rappresentato il modello dei messaggi su cui ogni input ed output si basa auth input 0..1 agent output 0..1 trace 0..1 origin 0..1 trace Figura 13.1: Information Model dei messaggi di input e di output Si definiscono sei messaggi di tipo fault: 325

344 Storage Interface Service Interfaccia Generic fault: descrive un errore generico per il quale non si è potuto rispondere ad una richiesta (ad esempio per via di un timeout) Condition fault: è fallita la verifica di una condizione specificata dalla richiesta Unsupported fault: la richiesta ha chiamato una qualche funzionalità non supportata dalla specifica implementazione del servizio Unauthorized fault: la richiesta ha fallito la verifica delle autorizzazioni necessarie al suo espletamento Internal Error: si è verificato un errore interno al servizio e la richiesta non può essere portata a termine Input Error: il messaggio di input non è valido e la richiesta non può essere portata a termine generic unsupported internalerror condition unauthorized inputerror Figura 13.2: Tipi di messaggi di fault Alcuni messaggi di input specificano una query sui dati, una query sui metadati o una condizione. Le query sono delle informazioni testuali passate al servizio, il cui effetto è la restituzione di dati o di metadati in genere differenti da quelli esattamente memorizzati nella risorsa. L interpretazione delle query e l azione da intraprendere dipendono dalla implementazione del servizio. I dati e i metadati trasformati sono restituiti con informazioni che dichiarano la trasformazione che è stata effettuata. Ad esempio, un servizio può implementare l accesso parziale ai dati di SI-R grazie alle query, e i dati restituiti saranno accompagnati da informazioni che descrivono il range di dati restituito. Le condizioni pongono un vincolo sull espletamento della chiamata all operazione. I servizi che supportano le condizioni, dovranno portare avanti il processo innescato dall operazione soltanto se la condizione è verificata. In caso contrario, la risposta deve essere un messaggio di condition fault. L implementazione di queste funzionalità non è obbligatoria, e un servizio potrà rispondere con un messaggio di errore di tipo unsupported fault a chiamate di operazioni che contengono condizioni o query. Ogni operazione è condizionata alle autorizzazioni in possesso al chiamante. Nella descrizione delle operazioni seguenti, è sempre possibile che in caso di diritti insufficienti sia inviato un messaggio di errore di tipo unauthorized fault. 326

345 Storage Interface Service Interfaccia Operazioni base dello storage persistente L operazione Create si usa per creare una nuova risorsa. La chiamata da origine alla seguente interazione: In Input, è opzionale l invio dei dati della risorsa e di zero o più metadati. La chiamata causa la creazione di una nuova risorsa nel servizio di storage che contiene una copia dei dati e dei metadati inviati. In output, viene restituito l identificatore della nuova risorsa. L operazione Read si usa per leggere una risorsa memorizzata. La chiamata da origine alla seguente interazione: In Input, si invia l identificatore della risorsa di cui si vuole leggere dati e metadati. Sono supportati query su dati, metadati e condizioni di esecuzione. L operazione è safe, ovvero la chiamata non è causa di azioni che modificano lo stato della risorsa. In output, viene restituito un messaggio che contiene i dati ed i metadati della risorsa. L operazione Update si usa per apportare una modifica ad una risorsa. chiamata da origine alla seguente interazione: La In Input, si invia l identificatore della risorsa che si vuole modificare, insieme ai dati ed ai metadati, così come li si vuole memorizzare. È supportata l esecuzione sottoposta a condizione. La chiamata causa la memorizzazione dei dati e dei metadati ricevuti nella risorsa specificata dall identificatore. Il non invio dei dati, o il non invio dei metadati non comporta la loro cancellazione. L operazione è idempotente, ovvero il risultato non cambia ripetendo più volte la chiamata con gli stessi parametri di input. In output, in caso l esecuzione proceda regolarmente, viene restituito un messaggio senza nessuna ulteriore informazione. Un errore comporta l invio di un messaggio di fault appropriato. L operazione Delete rimuove una risorsa dal servizio. La chiamata da origine alla seguente interazione: In Input, si invia l identificatore della risorsa che si desidera rimuovere. È supportata l esecuzione sottoposta a condizione. La chiamata causa la rimozione della risorsa dal servizio di storage. L identificatore e quindi l URL della risorsa non sono più validi, e una successiva richiesta sulla risorsa fornirà un errore. L operazione è idempotente, ovvero il risultato non cambia ripetendo più volte la chiamata con gli stessi parametri di input. 327

346 Storage Interface Service Interfaccia In output, in caso l esecuzione proceda regolarmente, viene restituito un messaggio senza nessuna ulteriore informazione. Un errore comporta l invio di un messaggio di fault appropriato. In figura 13.3 è riportato lo schema del modello di queste operazioni insieme ai messaggi scambiati. Create createin Input messages 0..* 0..1 name meta data mime? encoding? Output messages createout 1 resid Read readin * 0..1 resid querydata querymeta condition readout 0..* 0..1 name path? meta data mime? encoding? range? unit? Update 1 resid updatein 0..* name path? meta data mime? encoding? range? unit? condition updateout Delete deletein resid condition deleteout Figura 13.3: Information Model dei messaggi e delle operazioni base per la memorizzazione persistente Operazioni per funzionalità di performance L operazione Duplicate crea un duplicato di una risorsa specificata. chiamata da origine alla seguente interazione: La 328

347 Storage Interface Service Interfaccia In Input, si invia l identificatore della risorsa che si desidera duplicare. È supportata l esecuzione sottoposta a condizione. La chiamata causa la creazione di una nuova risorsa che è una copia della risorsa di cui si è passato l identificatore in input. In output, viene restituito l identificatore della nuova risorsa. L operazione List fornisce un elenco degli identificatori delle risorse presenti nel servizio. La chiamata da origine alla seguente interazione: Non ci sono parametri richiesti in input oltre a quelli comuni a tutti i messaggi (autorizzazione, traccia, etc.). L operazione è safe, ovvero la chiamata non è causa di azioni che modificano lo stato della risorsa. In output, viene restituito l elenco degli identificatori delle risorse memorizzate nel servizio. L operazione ProbeMeta fornisce l elenco dei nomi dei metadati che sono stati associati ad una risorsa. La chiamata da origine alla seguente interazione: In Input, si invia l identificatore della risorsa che si desidera duplicare. L operazione è safe, ovvero la chiamata non è causa di azioni che modificano lo stato della risorsa. In output, viene restituito l elenco dei nomi dei metadati memorizzati nella risorsa. In figura 13.4 è riportato lo schema del modello di queste operazioni insieme ai messaggi scambiati Operazioni specializzate per dati e metadati L operazione ReadData recupera soltanto il dato della risorsa. La chiamata da origine alla seguente interazione: In Input, si invia l identificatore della risorsa di cui si vuole leggere i dati. Sono supportati query su dati e condizioni di esecuzione. L operazione è safe, ovvero la chiamata non è causa di azioni che modificano lo stato della risorsa. In output, viene restituito un messaggio che contiene i dati della risorsa. L operazione ReadMeta fornisce la lettura di un singolo metadato associato alla risorsa. La chiamata da origine alla seguente interazione: In Input, si invia l identificatore della risorsa ed il nome del metadato che si vuole leggere. Sono supportati query su metadati e condizioni di esecuzione. 329

348 Storage Interface Service Interfaccia Input messages Duplicate duplicatein 1 resid 0..1 condition Output messages duplicateout 1 resid List listin listout 0..* resid ProbeMeta probemetain 1 resid probemetaout 0..* metaname Figura 13.4: Information model dei messaggi e delle operazioni per funzionalità duplicazione, lista di risorse e lista di metadati L operazione è safe, ovvero la chiamata non è causa di azioni che modificano lo stato della risorsa. In output, viene restituito un messaggio che contiene il metadato richiesto. L operazione UpdateData permette la modifica dei soli dati della risorsa. La chiamata da origine alla seguente interazione: In Input, si invia l identificatore della risorsa che si vuole modificare, insieme ai dati, così come li si vuole memorizzare. È supportata l esecuzione sottoposta a condizione. La chiamata causa la memorizzazione dei dati ricevuti nella risorsa specificata dall identificatore. L operazione è idempotente, ovvero il risultato non cambia ripetendo più volte la chiamata con gli stessi parametri di input. In output, in caso l esecuzione proceda regolarmente, viene restituito un messaggio senza nessuna ulteriore informazione. Un errore comporta l invio di un messaggio di fault appropriato. L operazione UpdateMeta permette la modifica di un singolo metadato associato alla risorsa. La chiamata da origine alla seguente interazione: In Input, si invia l identificatore della risorsa e il nome del metadato che si vuole modificare, insieme al valore del metadato così come lo si vuole memorizzare. È supportata l esecuzione sottoposta a condizione. La chiamata causa la memorizzazione del metadato ricevuto nella risorsa specificata dall identificatore. L operazione è idempotente, ovvero il risultato non cambia ripetendo più volte la chiamata con gli stessi parametri di input. 330

349 Storage Interface Service Interfaccia In output, in caso l esecuzione proceda regolarmente, viene restituito un messaggio senza nessuna ulteriore informazione. Un errore comporta l invio di un messaggio di fault appropriato. In figura 13.5 è riportato lo schema del modello di queste operazioni insieme ai messaggi scambiati. Input messages ReadData 1 resid 0..1 readdatain querydata 0..1 condition Output messages readdataout 0..1 data mime? encoding? range? unit? ReadMeta readmetain 1 resid 0 metaname 0..1 querymeta 0..1 condition readmetaout 0..1 name path? meta UpdateData updatedatain UpdateMeta updatemetain resid data mime? encoding? range? unit? condition path? resid metaname meta condition updatedataout updatemetaout Figura 13.5: Information model dei messaggi e delle operazioni di memorizzazione di singoli dati o singoli metadati Operazioni per funzionalità specifiche L operazione Lock previene la scrittura o la lettura di una risorsa. chiamata da origine alla seguente interazione: La 331

350 Storage Interface Service Interfaccia In Input, si inviano l identificatore della risorsa e le informazioni sul lock da applicare. È supportata l esecuzione sottoposta a condizione. La chiamata causa l assegnazione o la rimozione di un lock alla risorsa. Una successiva operazione sulla stessa risorsa, è sottoposta alla verifica della condizione di locking. L operazione è idempotente, ovvero il risultato non cambia ripetendo più volte la chiamata con gli stessi parametri di input. In output, in caso l esecuzione proceda regolarmente, viene restituito un messaggio senza nessuna ulteriore informazione. Un errore comporta l invio di un messaggio di fault appropriato. L operazione Verify permette la verifica di una condizione su una risorsa. La chiamata da origine alla seguente interazione: In Input, è inviato l identificatore della risorsa e la condizione. L operazione è safe, ovvero la chiamata non è causa di azioni che modificano lo stato della risorsa. In output, il risultato un booleano che specifica l esito della verifica della condizione. L operazione Validate restituisce informazioni sulla conformità della risorsa sulla base dei tipi per cui è stata definita. La chiamata da origine alla seguente interazione: In Input, è inviato l identificatore della risorsa. L operazione è safe, ovvero la chiamata non è causa di azioni che modificano lo stato della risorsa. In output, viene restituito un elenco di associazioni tra tipo e risultato della validazione. Per ogni tipo a cui la risorsa appartiene è verificata la validità. In figura 13.6 è riportato lo schema del modello di queste operazioni insieme ai messaggi scambiati Operazioni per la gestione degli eventi L operazione Subscrive specifica l intenzione di sottoscrivere a notifiche di eventi di una risorsa. La chiamata da origine alla seguente interazione: In Input, è inviato l id della risorsa e il nome dell evento a cui ci si intende sottoscrivere, congiuntamente al punto di accesso a cui inviare le notifiche qualora disponibile. La chiamata causa l iscrizione (o la sua revoca) alla lista dei destinatari di notifiche in seguito ad eventi per la risorsa specificata. L operazione è idempotente, ovvero il risultato non cambia ripetendo più volte la chiamata con gli stessi parametri di input. 332

351 Storage Interface Service Interfaccia Input messages Lock lockin 1 resid 1 lockinfo 0..1 condition Output messages lockout Verify verifyin 1 1 resid condition verifyout 1 result Validate validatein 1 resid validateout 0..* validity type result Figura 13.6: Information model dei messaggi e delle operazioni per funzionalità di locking e validazione In output, in caso l esecuzione proceda regolarmente, viene restituito un messaggio senza nessuna ulteriore informazione. Un errore comporta l invio di un messaggio di fault appropriato. L operazione Poll restituisce l elenco di risorse sulla quale si è verificato un evento a cui il consumer si è sottoscritto. La verifica dell identità del consumer avviene tramite l invio delle informazioni di autenticazione. Il servizio può usare questo meccanismo per notificare eventi qualora il consumer non abbia un proprio endpoint al quale inviare messaggi. Questo meccanismo è alternativo all invio diretto di notifiche, qualora un consumer abbia un punto di accesso. Nel prossimo paragrafo sarà trattato questo aspetto più dettagliatamente. La chiamata da origine alla seguente interazione: Non ci sono parametri richiesti in input oltre a quelli comuni a tutti i messaggi (autorizzazione, traccia, etc.). L operazione è safe, ovvero la chiamata non è causa di azioni che modificano lo stato della risorsa. In output, è restituita la lista degli eventi a cui l identità autenticata risulta sottoscritta. In figura 13.7 è riportato lo schema del modello di queste operazioni insieme ai messaggi scambiati. 333

352 Storage Interface Service Storage Interface Data Model Input messages Subscribe 1 subscribein resid 0..1 subscriber 1 eventname Output messages subscribeout Poll notifyin notifyout 0..* event resid eventname time? Figura 13.7: Information model dei messaggi e delle operazioni a supporto della notifica di eventi Interfaccia delle notifiche I requisiti R021 e R022 specificano che Storage Interface deve supportare la notifica di eventi tramite messaggi a destinatari designati. L operazione Notify è quindi un operazione che dal punto di vista del provider, trasmette un messaggio output, poiché è dal servizio che è avviata la chiamata. Le specifiche di Storage Interface definiscono l interfaccia delle notifiche un punto di accesso implementato sul consumer che permette l invio di messaggi di tipo notifyout in conseguenza di eventi. Tuttavia l invio di un messaggio prevede che il destinatario fornisca un punto di accesso cui spedire la notifica e che quindi implementi l interfaccia di cui sopra, ma non tutti i consumer ne sono dotati. Per questo motivo è possibile utilizzare l operazione di polling descritta nell ultimo paragrafo della precedente sezione. L operazione Notify invia un messaggio unico col quale si informa un evento avvenuto su una risorsa. L interazione di una operazione di notifica è la seguente: Un evento su una risorsa per il quale esista una entità sottoscritta con punto di accesso causa l emissione del messaggio di notifica. In output, è inviata una lista di uno o più eventi che sono avvenuti ed ai quali il destinatario risulta sottoscritto. In figura 13.8 è riportato lo schema del modello di questa operazione e del messaggio. Si noti che si tratta dello stesso messaggio di output visto nella operazione di Poll Storage Interface Data Model Nei paragrafi di questa sezione saranno riportate le specifiche e le proprietà dei modelli informativi per le risorse e per i messaggi. Le scelte si fondano sulla specifica dei requisiti esposti e sullo studio casi applicativi. 334

353 Storage Interface Service Storage Interface Data Model Output messages Notify notifyout 1..* event resid eventname time? Figura 13.8: Interfaccia per le notifiche Per i modelli presentati saranno richiamati, ed eventualmente discussi, i requisiti che hanno motivato le scelte di progettazione. Si definisce Storage Interface Resource e si indica con l acronimo SI-R l entità trattata dal servizio di storage. Sulla base dei requisiti R001, R005, R006, R026, R027, R033, R034, R035, R036 e R037, sono state formulate le seguenti proprietà per il modello della risorsa: SI-R contiene dati e metadati, ovvero informazioni in formato adatto agli elaboratori e ulteriori informazioni che forniscono una descrizione dei dati. La risorsa è una rappresentazione dei dati che essa contiene. I metadati sono proprietà di questa rappresentazione. Ogni risorsa ha un identificatore, che lo identifica univocamente sul servizio di storage su cui è mantenuta. L identificatore, composto con l indirizzo del servizio, fornisce un URL che permette l accesso alla risorsa Tra servizi di storage differenti, si usano gli URL per indirizzare e identificare globalmente le risorse in modo univoco Ogni metadato ha un nome ed è usato per associare una proprietà ad una risorsa Il nome identifica il metadato nell ambito della risorsa, quindi per ogni risorsa può esistere un solo metadato con quel nome Il nome di un metadato identifica universalmente il suo tipo e la sua semantica. Il nome di un metadato è un URI ed è possibile adottare il meccanismo dei Namespace XML per l identificazione del nome tramite prefisso Il valore di un metadato è indirizzato dalla combinazione dell URL della risorsa e del nome del metadato. Il disegno in figura 13.9 rappresenta la struttura della risorsa. 335

354 Storage Interface Service Storage Interface Data Model SI-Resource-Model resid serviceendpoint 0..* 0..1 resid? name readonly? resid? mime? encoding? readonly? meta data Figura 13.9: Information Model di SI-R Il requisito R030 richiede che l information model utilizzato per le risorse e i messaggi di Storage Interface, illustrato in sezione 13.1, possa essere rappresentato con XML. Tuttavia i requisiti R025 e R036 raccomandano l impiego di WSDL per descrivere l interfaccia del servizio e poichè WSDL si basa su tipi di dati XML, è stato realizzato un documento XML Schema ( vedi [TBMM04] e [PVB04]) che formalizza il data model XML del modello dell informazione. Il risultato è stato suddiviso in due schema: idn-storage-interface.xsd, sono formalizzati in XML messaggi scambiati dall interfaccia idn-storage-interface-ext.xsd, sono formalizzati i metadati predefiniti di SI-R Questi file saranno direttamente importati nei documenti WSDL che definiscono il servizio, ed in particolare gli stessi file.xsd sono riutilizzabili per le interfacce descritte con WSDL 2.0 o WSDL 1.1. Tali documenti saranno brevemente illustrati in questa sezione ed a seguire integralmente riportati Messaggi Il documento idn-storage-interface.xsd definisce la sintassi XML dei messaggi dell interfaccia e dichiara i tipi fondamentali su cui essa si basa per il funzionamento. I messaggi sono rappresentati con elementi (xsd:element) ed i tipi sono sia xsd:complextype che xsd:simpletype. Inoltre è definito come elemento lo schema di SI-R: <xsd:element name= SI-Resource-Model >. I tipi più importanti sono quelli che rappresentano gli elementi fondamentali che compongono SI-R e i tipi base da cui derivano i messaggi. <xsd:simpletype name= resid />: rappresenta l identifier delle risorse, ed è derivato da xsd:anyuri (si ricorda che SI-R è identificata da URL). <xsd:complextype name= data... />: rappresenta il nucleo dell informazione di una risorsa. Si tratta di un elemento che contiene una sequenza di caratteri, byte o XML. 336

355 Storage Interface Service Storage Interface Data Model <xsd:complextype name= meta... />: rappresenta una informazione che descrive la risorsa. In XML un metadato ha obbligatoriamente un attributo di nome name che definisce il nome del metadato e ne identifica il suo tipo grazie ad un URI. Tutti i messaggi derivano dai seguenti tipi base: <xsd:complextype name= input... /> <xsd:complextype name= output... /> <xsd:complextype name= fault... /> La sintassi dei messaggi è formalizzata da istanze di elementi. Per ogni tipo di messaggio esiste un elemento che lo rappresenta in XML. Alcuni esempi sono: <xsd:element name= createin > rappresenta un messaggio di input dell operazione di creazione. <xsd:element name= readin > rappresenta un messaggio di input dell operazione di lettura. <xsd:element name= readout > rappresenta un messaggio di output dell operazione di lettura. <xsd:element name= notifyout > rappresenta un messaggio di notifica inviato dal servizio. <xsd:element name= unauthorizedfault > rappresenta un messaggio di errore che viene trasmesso qualora l operazione richiesta non possa essere portata a termine per diritti insufficienti. Il targetnamespace di questo schema è l indirizzo al quale è associato il prefisso locale idnsi. Nel seguente listato è riportato l inizio del documento, nel quale si può vedere l elemento radice della definizione dello schema con gli attributi che contiene: <xsd:schema xmlns:xsd=" xmlns:idnsi=" targetnamespace=" elementformdefault="qualified"> 337

356 Storage Interface Service Storage Interface Data Model Tipi predefiniti Il documento idn-storage-interface-ext.xsd definisce la sintassi XML dei metadati predefiniti di una SI-R. Questi estensione di idnsi:meta, definito dal documento visto nel precedente paragrafo, e rappresentano i metadati per il tipo della risorsa, i namespace utilizzati, lo stato del lock. Si indicano con: idnsix:types idnsix:lock idnsix:namespaces I nomi estesi con l URI espresso completamente sono i seguenti Un metadato di una SI-R il cui nome corrisponde ad uno dei tre visti qui sopra, deve rispettare la sintassi del tipo. Il seguente esempio mostra un metadato di una SI-R che memorizza informazioni sul locking. <idnsix:meta name="idnsix:lock"> <idnsix:owner>cristiano</idnsix:owner> <idnsix:creation> t11:13:10</idnsix:creation> </idnsix:meta> Il prefisso locale idnsix è associato al targetnamespace di questo schema, Nel seguente listato è riportato l inizio del documento, nel quale si può vedere l elemento radice della definizione dello schema con gli attributi che contiene: <xsd:schema xmlns:xsd=" xmlns:idnsi=" xmlns:idnsix=" targetnamespace=" elementformdefault="qualified"> 338

357 Storage Interface Service Storage Interface Data Model WSDL e XML Schema Storage Interface XML Schema Il seguente listato presenta lo schema XML dei messaggi e dei data type di Storage Interface. <xsd:schema xmlns:xsd=" xmlns:idnsi=" targetnamespace=" elementformdefault="qualified"> <!--***** main types *****--> <xsd:simpletype name="resid"> <xsd:restriction base="xsd:anyuri"/> </xsd:simpletype> <xsd:complextype name="data" abstract="false" mixed="true"> <xsd:sequence> <xsd:any processcontents="lax" minoccurs="0" maxoccurs="unbounded"/> </xsd:sequence> <xsd:attribute name="resid" type="idnsi:resid"/> <xsd:attribute name="mime" type="xsd:anysimpletype"/> <xsd:attribute name="range" type="xsd:anysimpletype"/> <xsd:attribute name="unit" type="xsd:anysimpletype"/> <xsd:attribute name="encoding" type="xsd:anysimpletype"/> <xsd:attribute name="readonly" type="xsd:boolean" default="false"/> </xsd:complextype> <xsd:complextype name="meta" abstract="false" mixed="true"> <xsd:sequence> <xsd:any processcontents="lax" minoccurs="0" maxoccurs="unbounded"/> </xsd:sequence> <xsd:attribute name="name" type="idnsi:metaname" use="required"/> <xsd:attribute name="resid" type="idnsi:resid"/> <xsd:attribute name="path" type="xsd:anysimpletype"/> <xsd:attribute name="readonly" type="xsd:boolean" default="false"/> </xsd:complextype> <xsd:element name="si-resource-model"> <xsd:complextype> <xsd:sequence> <xsd:element name="meta" type="idnsi:meta" minoccurs="0" maxoccurs="unbounded"/> <xsd:element name="data" type="idnsi:data" minoccurs="0"/> </xsd:sequence> <xsd:attribute name="resid" type="idnsi:resid" use="required"/> <xsd:attribute name="erviceendpoint" type="xsd:anyuri" use="required"/> </xsd:complextype> </xsd:element> <!--***** derived types *****--> <xsd:complextype name="emptydata"> 339

358 Storage Interface Service Storage Interface Data Model <xsd:complexcontent> <xsd:restriction base="idnsi:data"/> </xsd:complexcontent> </xsd:complextype> <xsd:complextype name="xmldata"> <xsd:complexcontent> <xsd:restriction base="idnsi:data"> <xsd:sequence> <xsd:any processcontents="lax" minoccurs="0" maxoccurs="unbounded"/> </xsd:sequence> </xsd:restriction> </xsd:complexcontent> </xsd:complextype> <xsd:complextype name="binaryhexdata"> <xsd:simplecontent> <xsd:restriction base="idnsi:data"> <xsd:simpletype> <xsd:restriction base="xsd:hexbinary"/> </xsd:simpletype> </xsd:restriction> </xsd:simplecontent> </xsd:complextype> <xsd:complextype name="binary64data"> <xsd:simplecontent> <xsd:restriction base="idnsi:data"> <xsd:simpletype> <xsd:restriction base="xsd:base64binary"/> </xsd:simpletype> </xsd:restriction> </xsd:simplecontent> </xsd:complextype> <xsd:complextype name="stringdata"> <xsd:simplecontent> <xsd:restriction base="idnsi:data"> <xsd:simpletype> <xsd:restriction base="xsd:string"/> </xsd:simpletype> </xsd:restriction> </xsd:simplecontent> </xsd:complextype> <xsd:complextype name="xmlmeta"> <xsd:complexcontent> <xsd:restriction base="idnsi:meta"> <xsd:sequence> <xsd:any processcontents="lax" minoccurs="0" maxoccurs="unbounded"/> </xsd:sequence> </xsd:restriction> </xsd:complexcontent> </xsd:complextype> <xsd:complextype name="stringmeta"> <xsd:simplecontent> <xsd:restriction base="idnsi:meta"> <xsd:simpletype> <xsd:restriction base="xsd:string"/> </xsd:simpletype> </xsd:restriction> </xsd:simplecontent> 340

359 Storage Interface Service Storage Interface Data Model </xsd:complextype> <!--***** support types *****--> <xsd:simpletype name="metaname"> <xsd:restriction base="xsd:anyuri"/> </xsd:simpletype> <xsd:simpletype name="eventname"> <xsd:restriction base="xsd:anyuri"/> </xsd:simpletype> <xsd:simpletype name="origin"> <xsd:restriction base="xsd:string"/> </xsd:simpletype> <xsd:simpletype name="trace"> <xsd:restriction base="xsd:string"/> </xsd:simpletype> <xsd:simpletype name="agent"> <xsd:restriction base="xsd:string"/> </xsd:simpletype> <xsd:simpletype name="subscriber"> <xsd:restriction base="xsd:anyuri"/> </xsd:simpletype> <xsd:simpletype name="querydata"> <xsd:restriction base="xsd:string"/> </xsd:simpletype> <xsd:simpletype name="querymeta"> <xsd:restriction base="xsd:string"/> </xsd:simpletype> <xsd:simpletype name="auth"> <xsd:restriction base="xsd:string"/> </xsd:simpletype> <xsd:simpletype name="condition"> <xsd:restriction base="xsd:string"/> </xsd:simpletype> <xsd:simpletype name="lockinfo"> <xsd:restriction base="xsd:string"/> </xsd:simpletype> <!--***** base ******--> <xsd:complextype name="input"> <xsd:sequence> <xsd:element name="origin" type="idnsi:origin" minoccurs="0"/> <xsd:element name="agent" type="idnsi:agent" minoccurs="0"/> <xsd:element name="auth" type="idnsi:auth" minoccurs="0"/> <xsd:element name="trace" type="idnsi:trace" minoccurs="0"/> </xsd:sequence> </xsd:complextype> <xsd:complextype name="output"> <xsd:sequence> <xsd:element name="trace" type="idnsi:trace" minoccurs="0"/> </xsd:sequence> </xsd:complextype> <!--***** input CRUD ******--> <xsd:element name="createin"> 341

360 Storage Interface Service Storage Interface Data Model <xsd:complextype> <xsd:complexcontent> <xsd:extension base="idnsi:input"> <xsd:sequence> <xsd:element name="meta" type="idnsi:meta" minoccurs="0" maxoccurs="unbounded"/> <xsd:element name="data" type="idnsi:data" minoccurs="0"/> </xsd:sequence> </xsd:extension> </xsd:complexcontent> </xsd:complextype> </xsd:element> <xsd:element name="readin"> <xsd:complextype> <xsd:complexcontent> <xsd:extension base="idnsi:input"> <xsd:sequence> <xsd:element name="resid" type="idnsi:resid"/> <xsd:element name="querymeta" type="idnsi:querymeta" minoccurs="0" maxoccurs="unbounded"/> <xsd:element name="querydata" type="idnsi:querydata" minoccurs="0"/> <xsd:element name="condition" type="idnsi:condition" minoccurs="0"/> </xsd:sequence> </xsd:extension> </xsd:complexcontent> </xsd:complextype> </xsd:element> <xsd:element name="updatein"> <xsd:complextype> <xsd:complexcontent> <xsd:extension base="idnsi:input"> <xsd:sequence> <xsd:element name="resid" type="idnsi:resid"/> <xsd:element name="meta" type="idnsi:meta" minoccurs="0" maxoccurs="unbounded"/> <xsd:element name="data" type="idnsi:data" minoccurs="0"/> <xsd:element name="condition" type="idnsi:condition" minoccurs="0" maxoccurs="unbounded"/> </xsd:sequence> </xsd:extension> </xsd:complexcontent> </xsd:complextype> </xsd:element> <xsd:element name="deletein"> <xsd:complextype> <xsd:complexcontent> <xsd:extension base="idnsi:input"> <xsd:sequence> <xsd:element name="resid" type="idnsi:resid"/> <xsd:element name="condition" type="idnsi:condition" minoccurs="0" maxoccurs="unbounded"/> </xsd:sequence> </xsd:extension> </xsd:complexcontent> </xsd:complextype> 342

361 Storage Interface Service Storage Interface Data Model </xsd:element> <!--***** output CRUD ******--> <xsd:element name="createout"> <xsd:complextype> <xsd:complexcontent> <xsd:extension base="idnsi:output"> <xsd:sequence> <xsd:element name="resid" type="idnsi:resid"/> </xsd:sequence> </xsd:extension> </xsd:complexcontent> </xsd:complextype> </xsd:element> <xsd:element name="readout"> <xsd:complextype> <xsd:complexcontent> <xsd:extension base="idnsi:output"> <xsd:sequence> <xsd:element name="meta" type="idnsi:meta" minoccurs="0" maxoccurs="unbounded"/> <xsd:element name="data" type="idnsi:data" minoccurs="0"/> </xsd:sequence> </xsd:extension> </xsd:complexcontent> </xsd:complextype> </xsd:element> <xsd:element name="updateout"> <xsd:complextype> <xsd:complexcontent> <xsd:extension base="idnsi:output"/> </xsd:complexcontent> </xsd:complextype> </xsd:element> <xsd:element name="deleteout"> <xsd:complextype> <xsd:complexcontent> <xsd:extension base="idnsi:output"/> </xsd:complexcontent> </xsd:complextype> </xsd:element> <!--***** list / copy ******--> <xsd:element name="duplicatein"> <xsd:complextype> <xsd:complexcontent> <xsd:extension base="idnsi:input"> <xsd:sequence> <xsd:element name="resid" type="idnsi:resid"/> <xsd:element name="condition" type="idnsi:condition" minoccurs="0" maxoccurs="unbounded"/> </xsd:sequence> </xsd:extension> </xsd:complexcontent> </xsd:complextype> </xsd:element> <xsd:element name="duplicateout"> <xsd:complextype> 343

362 Storage Interface Service Storage Interface Data Model <xsd:complexcontent> <xsd:extension base="idnsi:output"> <xsd:sequence> <xsd:element name="resid" type="idnsi:resid"/> </xsd:sequence> </xsd:extension> </xsd:complexcontent> </xsd:complextype> </xsd:element> <xsd:element name="listin"> <xsd:complextype> <xsd:complexcontent> <xsd:extension base="idnsi:input"/> </xsd:complexcontent> </xsd:complextype> </xsd:element> <xsd:element name="listout"> <xsd:complextype> <xsd:complexcontent> <xsd:extension base="idnsi:output"> <xsd:sequence> <xsd:element name="resid" type="idnsi:resid" minoccurs="0" maxoccurs="unbounded"/> </xsd:sequence> </xsd:extension> </xsd:complexcontent> </xsd:complextype> </xsd:element> <xsd:element name="probemetain"> <xsd:complextype> <xsd:complexcontent> <xsd:extension base="idnsi:input"> <xsd:sequence> <xsd:element name="resid" type="idnsi:resid"/> </xsd:sequence> </xsd:extension> </xsd:complexcontent> </xsd:complextype> </xsd:element> <xsd:element name="probemetaout"> <xsd:complextype> <xsd:complexcontent> <xsd:extension base="idnsi:output"> <xsd:sequence> <xsd:element name="metaname" type="idnsi:metaname" minoccurs="0" maxoccurs="unbounded"/> </xsd:sequence> </xsd:extension> </xsd:complexcontent> </xsd:complextype> </xsd:element> <!--***** specialized operation ******--> <xsd:element name="readdatain"> <xsd:complextype> <xsd:complexcontent> <xsd:extension base="idnsi:input"> <xsd:sequence> <xsd:element name="resid" type="idnsi:resid"/> 344

363 Storage Interface Service Storage Interface Data Model <xsd:element name="querydata" type="idnsi:querydata" minoccurs="0"/> <xsd:element name="condition" type="idnsi:condition" minoccurs="0"/> </xsd:sequence> </xsd:extension> </xsd:complexcontent> </xsd:complextype> </xsd:element> <xsd:element name="readdataout"> <xsd:complextype> <xsd:complexcontent> <xsd:extension base="idnsi:output"> <xsd:sequence> <xsd:element name="data" type="idnsi:data" minoccurs="0"/> </xsd:sequence> </xsd:extension> </xsd:complexcontent> </xsd:complextype> </xsd:element> <xsd:element name="readmetain"> <xsd:complextype> <xsd:complexcontent> <xsd:extension base="idnsi:input"> <xsd:sequence> <xsd:element name="resid" type="idnsi:resid"/> <xsd:element name="metaname" type="idnsi:metaname"/> <xsd:element name="querymeta" type="idnsi:querymeta" minoccurs="0" maxoccurs="unbounded"/> <xsd:element name="condition" type="idnsi:condition" minoccurs="0"/> </xsd:sequence> </xsd:extension> </xsd:complexcontent> </xsd:complextype> </xsd:element> <xsd:element name="readmetaout"> <xsd:complextype> <xsd:complexcontent> <xsd:extension base="idnsi:output"> <xsd:sequence> <xsd:element name="meta" type="idnsi:meta" minoccurs="0"/> </xsd:sequence> </xsd:extension> </xsd:complexcontent> </xsd:complextype> </xsd:element> <xsd:element name="updatedatain"> <xsd:complextype> <xsd:complexcontent> <xsd:extension base="idnsi:input"> <xsd:sequence> <xsd:element name="resid" type="idnsi:resid"/> <xsd:element name="data" type="idnsi:data" minoccurs="0"/> <xsd:element name="condition" type="idnsi:condition" minoccurs="0" maxoccurs="unbounded"/> 345

364 Storage Interface Service Storage Interface Data Model </xsd:sequence> </xsd:extension> </xsd:complexcontent> </xsd:complextype> </xsd:element> <xsd:element name="updatedataout"> <xsd:complextype> <xsd:complexcontent> <xsd:extension base="idnsi:output"/> </xsd:complexcontent> </xsd:complextype> </xsd:element> <xsd:element name="updatemetain"> <xsd:complextype> <xsd:complexcontent> <xsd:extension base="idnsi:input"> <xsd:sequence> <xsd:element name="resid" type="idnsi:resid"/> <xsd:element name="metaname" type="idnsi:metaname"/> <xsd:element name="meta" type="idnsi:meta" minoccurs="0"/> <xsd:element name="condition" type="idnsi:condition" minoccurs="0" maxoccurs="unbounded"/> </xsd:sequence> </xsd:extension> </xsd:complexcontent> </xsd:complextype> </xsd:element> <xsd:element name="updatemetaout"> <xsd:complextype> <xsd:complexcontent> <xsd:extension base="idnsi:output"/> </xsd:complexcontent> </xsd:complextype> </xsd:element> <!--***** altre ******--> <xsd:element name="lockin"> <xsd:complextype> <xsd:complexcontent> <xsd:extension base="idnsi:input"> <xsd:sequence> <xsd:element name="resid" type="idnsi:resid"/> <xsd:element name="lockinfo" type="idnsi:lockinfo"/> <xsd:element name="condition" type="idnsi:condition" minoccurs="0" maxoccurs="unbounded"/> </xsd:sequence> </xsd:extension> </xsd:complexcontent> </xsd:complextype> </xsd:element> <xsd:element name="lockout"> <xsd:complextype> <xsd:complexcontent> <xsd:extension base="idnsi:output"/> </xsd:complexcontent> </xsd:complextype> </xsd:element> <xsd:element name="verifyin"> 346

365 Storage Interface Service Storage Interface Data Model <xsd:complextype> <xsd:complexcontent> <xsd:extension base="idnsi:input"> <xsd:sequence> <xsd:element name="resid" type="idnsi:resid"/> <xsd:element name="condition" type="idnsi:condition" minoccurs="0" maxoccurs="unbounded"/> </xsd:sequence> </xsd:extension> </xsd:complexcontent> </xsd:complextype> </xsd:element> <xsd:element name="verifyout"> <xsd:complextype> <xsd:complexcontent> <xsd:extension base="idnsi:output"> <xsd:sequence> <xsd:element name="result" type="xsd:boolean"/> </xsd:sequence> </xsd:extension> </xsd:complexcontent> </xsd:complextype> </xsd:element> <xsd:element name="validatein"> <xsd:complextype> <xsd:complexcontent> <xsd:extension base="idnsi:input"> <xsd:sequence> <xsd:element name="resid" type="idnsi:resid"/> </xsd:sequence> </xsd:extension> </xsd:complexcontent> </xsd:complextype> </xsd:element> <xsd:element name="validateout"> <xsd:complextype> <xsd:complexcontent> <xsd:extension base="idnsi:output"> <xsd:sequence> <xsd:element name="validity" minoccurs="0" maxoccurs="unbounded"> <xsd:complextype> <xsd:simplecontent> <xsd:extension base="xsd:boolean"> <xsd:attribute name="type" use="required"/> </xsd:extension> </xsd:simplecontent> </xsd:complextype> </xsd:element> </xsd:sequence> </xsd:extension> </xsd:complexcontent> </xsd:complextype> </xsd:element> <xsd:element name="subscribein"> <xsd:complextype> <xsd:complexcontent> <xsd:extension base="idnsi:input"> 347

366 Storage Interface Service Storage Interface Data Model <xsd:sequence> <xsd:element name="resid" type="idnsi:resid"/> <xsd:element name="subscriber" type="idnsi:subscriber"/> <xsd:element name="eventname" type="idnsi:eventname"/> <xsd:element name="condition" type="idnsi:condition" minoccurs="0" maxoccurs="unbounded"/> </xsd:sequence> </xsd:extension> </xsd:complexcontent> </xsd:complextype> </xsd:element> <xsd:element name="subscribeout" type="idnsi:output"/> <xsd:element name="notifyin"> <xsd:complextype> <xsd:complexcontent> <xsd:extension base="idnsi:input"/> </xsd:complexcontent> </xsd:complextype> </xsd:element> <xsd:element name="notifyout"> <xsd:complextype> <xsd:complexcontent> <xsd:extension base="idnsi:output"> <xsd:sequence> <xsd:element name="event" minoccurs="0" maxoccurs="unbounded"> <xsd:complextype> <xsd:attribute name="resid" type="idnsi:resid" use="required"/> <xsd:attribute name="eventname" type="idnsi:eventname" use="required"/> <xsd:attribute name="time" type="xsd:datetime"/> </xsd:complextype> </xsd:element> </xsd:sequence> </xsd:extension> </xsd:complexcontent> </xsd:complextype> </xsd:element> <!--***** fault ******--> <xsd:complextype name="fault"> <xsd:sequence> <xsd:element name="trace" type="idnsi:trace" minoccurs="0"/> </xsd:sequence> </xsd:complextype> <xsd:element name="genericfault"> <xsd:complextype> <xsd:complexcontent> <xsd:extension base="idnsi:fault"/> </xsd:complexcontent> </xsd:complextype> </xsd:element> <xsd:element name="conditionfault"> <xsd:complextype> <xsd:complexcontent> 348

367 Storage Interface Service Storage Interface Data Model <xsd:extension base="idnsi:fault"/> </xsd:complexcontent> </xsd:complextype> </xsd:element> <xsd:element name="unsupportedfault"> <xsd:complextype> <xsd:complexcontent> <xsd:extension base="idnsi:fault"/> </xsd:complexcontent> </xsd:complextype> </xsd:element> <xsd:element name="unauthorizedfault"> <xsd:complextype> <xsd:complexcontent> <xsd:extension base="idnsi:fault"/> </xsd:complexcontent> </xsd:complextype> </xsd:element> <xsd:element name="internalerrorfault"> <xsd:complextype> <xsd:complexcontent> <xsd:extension base="idnsi:fault"/> </xsd:complexcontent> </xsd:complextype> </xsd:element> <xsd:element name="inputerrorfault"> <xsd:complextype> <xsd:complexcontent> <xsd:extension base="idnsi:fault"/> </xsd:complexcontent> </xsd:complextype> </xsd:element> </xsd:schema> Storage Interface Predefined Types Il seguente listato presenta lo schema XML tipi predefiniti di Storage Interface. <xsd:schema xmlns:xsd=" xmlns:idnsi=" xmlns:idnsix=" xmlns:rdf=" targetnamespace=" elementformdefault="qualified"> <xsd:import namespace=" schemalocation=" StorageInterface/idn-storage-interface.xsd"/> <!--***** types *****--> <xsd:complextype name="types"> 349

368 Storage Interface Service Storage Interface Data Model <xsd:simplecontent> <xsd:restriction base="idnsi:meta"> <xsd:simpletype> <xsd:list itemtype="rdf:type"/> </xsd:simpletype> <xsd:attribute name="name" use="required" fixed=" <xsd:simpletype> <xsd:restriction base="idnsi:metaname"/> </xsd:simpletype> </xsd:attribute> </xsd:restriction> </xsd:simplecontent> </xsd:complextype> <!--***** lock *****--> <xsd:complextype name="lock"> <xsd:complexcontent> <xsd:restriction base="idnsi:meta"> <xsd:sequence> <xsd:element name="owner" type="xsd:string"/> <xsd:element name="creation" type="xsd:datetime"/> </xsd:sequence> <xsd:attribute name="name" use="required" fixed=" <xsd:simpletype> <xsd:restriction base="idnsi:metaname"/> </xsd:simpletype> </xsd:attribute> </xsd:restriction> </xsd:complexcontent> </xsd:complextype> <!--***** namespaces *****--> <xsd:complextype name="namespaces"> <xsd:complexcontent> <xsd:restriction base="idnsi:meta"> <xsd:sequence> <xsd:element name="ns" minoccurs="0" maxoccurs="unbounded"> <xsd:complextype> <xsd:attribute name="uri" type="xsd:anyuri" use="required"/> <xsd:attribute name="prefix" type="xsd:string" use="required"/> </xsd:complextype> </xsd:element> </xsd:sequence> <xsd:attribute name="name" use="required" fixed=" <xsd:simpletype> <xsd:restriction base="idnsi:metaname"/> </xsd:simpletype> </xsd:attribute> </xsd:restriction> </xsd:complexcontent> </xsd:complextype> </xsd:schema> 350

369 Storage Interface Service Storage Interface Data Model 351

370 Conclusioni Le soluzioni di interdataworking si pongono l obiettivo di collegare, distribuire ed integrare i dati aumentando l interoperabilità e la collaborazione tra processi connessi in rete. Nei tredici capitoli che compongono questa tesi ho presentato InterDataNet (IDN): una architettura innovativa che intende risolvere a livello infrastrutturale i problemi relativi alla distribuzione fisica e logica di risorse ed utenti in rete, ridefinendo e rileggendo i comportamenti delle risorse in gioco a vantaggio delle attività collaborative. IDN determina una soluzione formale riutilizzabile ad un problema contestualizzato che descrive il modello, le intenzioni, le motivazioni, i campi applicativi, le conseguenze, la struttura ed una implementazione di riferimento. I principi fondanti di InterDataNet esprimono ed acquisiscono l esperienza ed il valore dei risultati vincenti dell internetworking, applicandoli all interdataworking. Infatti è stata adottata la stratificazione quale principio guida nella ricerca e nella progettazione, attuando una estensione dal settore delle telecomunicazioni al trattamento e gestione dell informazione, perseguendo la scalabilità e l inclusione di dati esistenti (in sistemi legacy). L interoperabilità dei dati, viene così portata nell infrastruttura, prefigurando un ambiente integrato ed aperto, capace di distribuire ed arricchire la conoscenza basata sui dati. Tale ambiente viene concretamente realizzato grazie ad apparati di interdataworking, che implementano specifiche funzionalità in livelli diversi dell architettura IDN, lasciando spazio allo sviluppo di applicazioni a valore aggiunto. L applicazione dell internetworking all interdataworking agevola così IDN a candidarsi a modello di riferimento, adottabile liberamente da persone, imprese ed organizzazioni. Nella tesi si presentano e si discutono i principi concettuali e tecnologici di InterDataNet: IDN è un middleware stratificato secondo un approccio SOA (Service Oriented Architecture) in grado di consentire lo sviluppo di servizi interoperabili e debolmente accoppiati che possono essere combinati in sistemi più complessi. L approccio stratificato consente di abbattere la comples-

371 Conclusioni sità del sistema applicando i principi di information hiding, separation of concern e good enough ; IDN adotta il paradigma REST (Representational State Tranfer) per realizzare una interfaccia uniforme di interazione con le risorse (URI, Uniform Resource Identifier) in grado di assicurare contemporaneamente prestazioni, scalabilità e sufficiente astrazione in sistemi distribuiti composti da risorse eterogenee; IDN è descritto attraverso tre viste che coprono gli aspetti introdotti: IDN-IM (Information Model), IDN-SA (Service Architecture), IDN-ON (Overlay Network); IDN-IM (InterDataNet Information Model). È il modello di informazioni che rappresenta un generico documento/dato in maniera indipendente dallo specifico contesto e dalla tecnologia. Definisce i requisiti, le proprietà desiderabili, i principi e la struttura del documento che deve essere gestito da IDN. In IDN-IM, l informazione è strutturata e dotata di specifici metadati. Il modello illustra come la composizione degli elementi informativi costituenti il documento sia realizzata per costruire entità informative più complesse al fine di servire le necessità di una gestione collaborativa dell informazione; IDN-SA (InterDataNet Service Architecture). È il modello architetturale Service Oriented che descrive i servizi per la gestione di documenti IDN. IDN-SA definisce le funzionalità di riferimento, i sottosistemi, i protocolli e le interfacce per la gestione collaborativa di un documento IDN. La stratificazione assume un ruolo importante nella orchestrazione dei servizi che viene determinata in maniera naturale proprio dalla gerarchia dei livelli; IDN-ON (InterDataNet Overlay Network). È l architettura di rete in cui sono collocati gli apparati di rete interdataworking. Rappresenta il modello con cui costruire reti Overlay Network di IDN. L insieme delle tre viste di InterDataNet caratterizza il sistema nel suo complesso e sistematizza la soluzione qui discussa verso ogni contesto applicativo, mirando ad erogare alle applicazioni servizi di base uniformi e trasparenti. Il mio contributo al progetto InterDataNet Questa tesi è redatta al fine di inquadrare il risultato principale di questa ricerca, ovvero la progettazione dettagliata di InterDataNet, in un contesto di comprensione che faciliti il proseguimento del progetto stesso. Come si è già detto, InterDataNet non può costituire lo sforzo di un singolo, ma fin dalla sua nascita rappresenta una visione e un progetto portati avanti da un gruppo di ricerca composto da vari membri. Se dunque i capitoli che compongono questo documento hanno lo scopo di ordinare tutta la conoscenza su InterDataNet, è anche opportuno mettere in evidenza qual è stato il mio specifico contributo all avanzamento del progetto. 353

372 Conclusioni Il mio lavoro su IDN è cominciato nel 2003 con la tesi di laurea quinquennale in Ingegneria Informatica ed è proseguito negli anni successivi e durante il dottorato di ricerca. In questo percorso ho assunto il ruolo di supervisore, progettista ed implementatore, svolgendo in particolare le seguenti attività: indicare e definire le linee guida, gli strumenti, le tecniche, le metodologie e le tecnologie di progetto; coordinare, durante il tutoraggio di laureandi, l analisi del contesto e lo sviluppo dei livelli di IDN: sistema di nomi LS e LDNS, Virtual Repository, Information History, Replica Management, Storage Interface, protocolli di comunicazione con delega, applicabilità al sistema informativo del Comune di Firenze, sicurezza in sistemi distribuiti, gestione di documenti giuridici; suggerire nuove prospettive ed approcci sistemici al problema in ambito civile (sociale, giuridico, Pubblica Amministrazione), civile e militare (reti di sensori); migliorare e sviluppare i sottosistemi; promuovere e supervisionare elaborati su IDN nell ambito del corso universitario Telematica al secondo anno di laurea specialistica in Ingegneria Informatica e delle Telecomunicazioni; divulgare i risultati e produrre articoli scientifici. Applicazioni pratiche, implicazioni e ricerca futura Quello che resta da fare in IDN è molto, il risultato di questa tesi e il riscontro positivo ottenuto nelle pubblicazioni fornisce per la prima volta un background progettuale solido perchè la vision IDN possa maturare e il progetto IDN possa evolvere oltre. È certo prevedere per IDN delle applicazioni concrete nel campo delle CSCA (Computer Supported Collaborative Applications). Queste applicazioni possono essere costruite sopra il middleware IDN senza la necessità di riscrivere funzionalità di base, trovando maggiore spazio per l implementazione di serivizi a valore aggiunto. InterDataNet diventerebbe così framework per l evolversi di applicazioni distribuite nella produzione di contenuti e di documenti, nella gestione del workflow e delle versioni, nella integrazione di sistemi groupware e di collaborazione. Applicazioni test sono state ipotizzate o parzialmente documentate nella letteratura di IDN; ad esempio il file system distribuito basato su IDN e l editor collaborativo (plugin per word-processor e browser). Sono stati a lungo studiate anche soluzioni ed applicazioni nel settore e-government e dell informatica giuridica per la gestione dei flussi documentali. Come si è messo in evidenza nell Introduzione, InterDataNet si pone in conformità e coerenza con gli obiettivi della Web Science: InterDataNet è allineato con la visione evolutiva del Web dal Web of Document al Web of Data. Infatti IDN sposta l intelligenza dall applicazione ai dati, per abilitare nuove frontiere nelle applicazioni, rendendosi così di supporto alla realizzazione del Web 354

373 Conclusioni Semantico. Più specificamente, InterDataNet, in un percorso indipendente ed originale, è arrivato a formulare e recepire il Linked Data, passaggio intermedio tra il Web of Document ed il Semantic Web. Nella prosecuzione del progetto IDN si prevedono a medio termine l ulteriore selezione e affinamento degli standard tecnologici e la promozione da applicazione dimostrativa ad applicazione stabile: estremizzando l attenzione ai singoli livelli è già in atto la definizione di sottoprogetti a valore indipendente. Infine, per potere aprire la visione IDN verso nuove frontiere di ricerca si prevedono degli approfondimenti teorici che permettano di evolvere la visione IDN in armonia con i principi del Web Semantico. In particolare si mira a mappare l isomorfismo fra IDN-IM ed RDF per sviluppare applicazioni semantiche su IDN. Concludendo questa sezione con un apertura verso una utopia possibile, l ambizione della visione di InterDataNet è quella di guadagnarsi un successo analogo a quello dell internetworking. Parafrasando le parole di Tim Berners Lee, se il TCP/IP è da considerare una pretty general internetworking facility mi piacerebbe poter considerare InterDataNet come una pretty general interdataworking facility. La larga adozione del middleware IDN potrebbe aggiungere alle soluzioni Internet la capacità di interdataworking, e il suo approccio potrebbe finire per diventare standard di fatto, se venisse superata la massa critica di utenti. Perchè ciò avvenga è necessario che la ricerca su InterDataNet si estenda da livello team a livello Web-community ed in particolare prenda spazio nelle comunità di sviluppatori open source. Solo così si potrà sperare nell effetto network capace di rendere IDN la nuova interdataworking facility. 355

374 Parte V Appendici

375 Appendice A ABNF La ABNF (Augmented Backus-Naur form) è una metasintassi, ovvero un linguaggio formale attraverso il quale è possibile descrivere la sintassi di linguaggi formali. Si tratta di uno strumento ideale per descrivere, in modo preciso e non ambiguo, la sintassi di linguaggi di programmazione, protocolli di rete, e così via benché non manchino, in letteratura, esempi di sue applicazioni a contesti anche non informatici e addirittura non tecnologici. Attraverso la BNF si può descrivere la sintassi di un qualunque linguaggio formale, a patto che tale sintassi corrisponda a quella che i teorici chiamano una grammatica context-free o grammatica libera dal contesto. La BNF è molto utilizzata in informatica; la maggior parte dei programmatori, in particolare, ne conosce almeno le linee essenziali. Fu inventata da John Backus per documentare formalmente la sintassi del linguaggio Algol 60. Su suggerimento di Donald Knuth, l acronimo fu in seguito riletto come Backus-Naur form in onore di Peter Naur che insieme a Backus fu uno dei più grandi pionieri nella storia dei linguaggi di programmazione e dei compilatori. Una specifica BNF è un insieme di regole di derivazione della forma: <simbolo> ::= <espressione> dove <simbolo> viene detto un simbolo nonterminale ed <espressione> è costituita da una o più sequenze di simboli (terminali, vedi sotto, o nonterminali) separate dalla barra verticale. La regola esprime il fatto che il nonterminale alla sua sinistra può essere sostituito da una qualsiasi delle sequenze indicate sulla destra (come sarà chiarito a breve). In una sequenza alcuni simboli o sottosequenze possono essere indicati come opzionali racchiudendoli fra parentesi quadre. I simboli che non appaiono mai a sinistra di una regola di derivazione sono detti terminali. I terminali sono in un certo senso il punto di arrivo, perché rappresentano elementi che si troveranno effettivamente in un testo scritto

376 ABNF secondo le regole sintattiche che la specifica BNF descrive. Viceversa i non terminali sono strumenti utilizzati esclusivamente dalla BNF; si può dire che essi rappresentano gli elementi astratti della grammatica. 358

377 Appendice B Notazioni e definizioni In questa appendice sono sinteticamente elencate le notazioni, le definizioni ed i principali acronimi più utilizzati nei capitoli della tesi. B.1 Notazioni per i requisiti In questo lavoro sono state usate le seguenti terminologia e convenzioni tipografiche: Le keyword MUST, MUST NOT, REQUIRED, SHALL, SHALL NOT, SHOULD, SHOULD NOT, RECOMMENDED, MAY ed OP- TIONAL usate in questo documento devono essere interpretate come descritto in [Bra97]. MUST, REQUIRED, SHALL. Il requisito è assoluto deve essere soddisfatto. SHOULD, RECOMMENDED. Possono esistere alcune ragioni per le quali il requisito sia ignorato, tuttavia è richiesta una valida motivazione comprensibile del motivo del rifiuto. MAY, OPTIONAL. Il requisito è opzionale, e può essere ignorato per motivi di tempismo o semplificazione. Ogni requisito è classificato secondo una classificazione derivata dallo standard [Boa98], in particolare: Functional: il requisito descrive una funzione, una azione fondamentale che deve essere svolta durante l esecuzione del software accettando o processando l input o processando e generando l output.

378 Notazioni e definizioni Classificazione dei requisiti Performance: il requisito definisce dei vincoli da rispettare sulle prestazione durante l esecuzione delle sue funzioni. Design Constraints: il requisito definisce un vincolo di progettazione che può essere imposto da altri standard, limiti hardware, etc. Standard Compliance: il requisito specifica uno standard al quale aderire, eventualmente esplicitando gli aspetti specifici. Software System Attributes: il requisito specifica un attributo richiesto al software. Reliability: il requisito specifica fattori richiesti per stabilire l affidabilità del sistema a conslusione del suo sviluppo. Availability: il requisito specifica fattori per definire il livello di disponibilità (on-time, recupero e backup dei dati) che il sistema deve garantire. Security: il requisito specifica fattori di protezione da adottare contro utilizzi accidentali o malevoli. Maintainability: il requisito specifica attributi relativi alle necessità di manutenzione del sistema. Portability: il requisito specifica attributi relativi alla migrazione del sistema su piattaforme differenti. B.2 Classificazione dei requisiti Ogni requisito è classificato secondo la seguente nomenclatura, derivata dallo standard IEEE/ANSI [IEE98]: Functional requirement. Requisito funzionale, che definisce le azioni fondamentali da svolgersi durante l esecuzione del software, accettando e processando l input, o processando e generando l output. Performance requirement. Vincolo sulle prestazioni da rispettare durante l esecuzione del software. Design constraint. Vincolo di progettazione imposto da uno standard, da limitazioni dell hardware, ecc. Standard compliance. Requisito che specifica uno standard a cui aderire, eventualmente esplicitando gli aspetti specifici. Software system attribute. Requisito che specifica un attributo richiesto al software, in modo da poter verificare oggettivamente il loro raggiungimento. Reliability. Requisito che specifica dei fattori necessari per stabilire l affidabilità del sistema a conclusione del suo sviluppo. 360

379 Notazioni e definizioni Definizioni Availability. Requisito che specifica dei fattori necessari per garantire il livello di disponibilità definito per il sistema. Security. Requisito che specifica dei fattori necessari per proteggere il software dall utilizzo, l accesso, la modifica e la distruzione accidentali o malevoli. Maintainability. Attributo del software relativo alla facilità di manutenzione del sistema. Portability. Attributo del software relativo alla facilità di portabilità verso altre macchine e/o sistemi operativi. B.3 Definizioni Le seguenti definizioni esplicitano il significato di alcuni dei termini e abbreviazioni utilizzate nella descrizione tecnica. Caching. Il processo con cui è duplicato in locale un insieme di dati a cui si accede frequentemente, e il loro valore è memorizzato in un area di storage temporanea, detta cache, per ridurre il costo nell accesso. Configuration (Configurazione). L insieme dei metadati che descrivono il numero di repliche esistenti per una risorsa e il loro ruolo ai fini del mantenimento della consistenza. Conflict (Conflitto). Una situazione che si presenta quando due repliche di una stessa risorsa vengono aggiornate indipendentemente e in modo inconsistente. CRUD. Acronimo di Create-Read-Update-Delete. Le quattro operazioni fondamentali della memorizzazione persistente: creazione, lettura, modifica e cancellazione. DAG. Acronimo di Direct Aciclic Graph. Data (Dato). Un informazione rappresentata mediante un formato adatto agli elaboratori. Data integrity (Integrità dei dati). La proprietà che garantisce che i dati non siano stati modificati, distrutti o persi in modo accidentale o senza autorizzazione [Shi07]. Data confidentiality (Confidenzialità dei dati). La proprietà che garantisce che i dati non siano resi disponibili o rivelati ad individui, entità o processi non autorizzati [Shi07]. HTTP. Acronimo di HyperText Transfer Protocol. Il principale protocollo usato per la trasmissione di informazioni sul Web. Interface (Interfaccia). Un insieme di primitive, riunite allo scopo di formare un gruppo di strumenti specifici per un determinato compito. 361

380 Notazioni e definizioni Acronimi di InterDataNet Metadata (Metadato). Un dato che serve a descrivere un altro dato. PKI Acronimo di Public Key Infrastructure. Replica. Ciascuna delle copie fisiche in cui è memorizzato il contenuto di una risorsa, o parte di esso. Resource (Risorsa). Ciascuno degli oggetti logici di cui si occupa il sistema di Replica Management. REST. Acronimo di REpresentational State Transfer. Un modello astratto per i sistemi software, i cui principi sono seguiti in modo esemplare dall architettura del Web. RESTful. Un sistema progettato in accordo ai principi dello stile REST. ROA. Acronimo di Resource Oriented Architecture. Un tipo di architettura in stile REST, implementata su HTTP. Service (Servizio). Nel contesto SOA indica una rappresentazione di una qualche funzionalità reale. SOA. Acronimo di Service Oriented Architecture. Un paradigma per l organizzazione e l utilizzazione di risorse distribuite che possono essere sotto il controllo di domini di proprietà differenti [MLM + 06b]. UEVM Acronimo di Unified Extensional Versioning Model.[ABCM99] URI. Acronimo di Uniform Resource Identifier. Un tipo di nome che permette di identificare una risorsa, come descritto in [BLFM98]. URN. Acronimo di Uniform Resource Name. Un sottoinsieme dei nomi URI, il quale comprende nomi che rimangono unici a livello globale e persistenti anche quando la risorsa cessa di esistere oppure non è disponibile [BLFM98]. Validation (Validazione). Un controllo da effettuare sui dati affinché soddisfino un formato predeterminato o siano conformi ad altri criteri. WSDL. Acronimo di Web Services Description Language. Un linguaggio formale, in formato XML, utilizzato per la descrizione di web service. XML. Acronimo di extensible Markup Language. Un linguaggio estensibile realizzato per poter utilizzare in modo semplice i documenti strutturati. B.4 Acronimi di InterDataNet IDN. InterDataNet IDN-IM. InterDataNet Information Model IDN-SA. InterDataNet Service Architecture IDN-ON. InterDataNet Overlay Network 362

381 Notazioni e definizioni Acronimi di InterDataNet PIU. Primitive Information Unit AIU. Atomic Information Unit VR. InterDataNet Virtual Repository Service LDNS. Logical Domain Name System RAS. Resource Aggregation Service IS. Identity Service IH. Information History VTA. Version Traversing Algorithm RM. Replica Management LS. Localization Service IDN-SI. Storage Interface 363

382 Appendice C Replicazione di risorse in rete La replicazione è una tecnologia per i servizi distribuiti che consiste nel mantenere più copie dei dati in siti diversi. Nei sistemi distribuiti, la migrazione di un file consiste nel creare una copia del file su un sito diverso, e poi cancellare la copia nel sito originale. La replicazione di un file crea una nuova immagine del file su un altro sito, quindi ha come risultato la migrazione di un file senza però che la sua copia originale sia rimossa [HY96]. Ad esempio, nel caso di un file system replicato, i file sono memorizzati in modo ridondante, e le loro copie sono distribuite tra un certo numero di server. In generale, in un sistema replicato i dati sono composti da un insieme di elementi che rappresentano l unità minima di replicazione, detta oggetto. Ognuno di questi oggetti logici è implementato da un insieme di copie fisiche: viene detta replica ciascuna copia di un oggetto memorizzata in un sito diverso. Ogni sito può memorizzare repliche di più oggetti. Le repliche di un oggetto non sono necessariamente tutte identiche in nessun particolare istante nel tempo; come spesso accade, alcune possono riflettere degli aggiornamenti che altre non hanno ancora ricevuto. La replicazione trova un limite nella dimensione dei dispositivi di storage presenti nei diversi siti e nella larghezza di banda disponibile tra di essi. Un sistema di gestione delle repliche (replica management system) assicura l accesso ai dati mentre gestisce i dispositivi di storage sottostanti, inoltre permette agli utenti di creare e trattare le repliche secondo strategie che possono tenere conto di fattori come la domanda dei dati, la località delle richieste, e la capacità di storage del mezzo di memorizzazione di massa [VBR06]. Un requisito comune in presenza di dati replicati è la trasparenza. Normal-

383 Replicazione di risorse in rete Vantaggi introdotti con la replicazione mente, i client non devono essere a conoscenza del fatto che esistono più copie fisiche dei dati, ma vederli soltanto come oggetti logici. Ogni volta che vuole effettuare un operazione su un oggetto replicato, l utente deve essere in grado di richiederla identificando un singolo oggetto logico, anche se poi l operazione potrà essere eseguita su una qualsiasi delle sue copie fisiche [CDK00]. C.1 Vantaggi introdotti con la replicazione Le motivazioni per la replicazione sono tese al miglioramento dei servizi. In genere, si vogliono ottenere migliori prestazioni e maggiore disponibilità e affidabilità nell accesso ai dati, nonché tolleranza ai vari tipi di guasti a cui può essere soggetto il sistema. Quando un sito crolla, i dati che vi risiedono diventano temporaneamente o permanentemente inaccessibili. Il resto della rete rimane connesso, e le altre repliche dei dati continuano ad essere disponibili, ma se un dato risiede in un solo nodo, un operazione che lo richiede non può essere completata con successo se a fallire è proprio quel nodo. Di conseguenza, i dati hanno bisogno di essere replicati su molti nodi, in modo che il fallimento di alcuni di essi non renda certi dati inaccessibili [Jal94]. Il fallimento di un server può essere di tipo fail-stop, nel qual caso vengono completamente fermati tutti i processi, ma fino al momento del fallimento il server continua ad eseguire correttamente tutte le operazioni, generando solo messaggi validi. Se invece un sito subisce un fallimento bizantino, si comporta in modo impredicibile e può darsi che produca messaggi illegali o non corretti, oppure che distrugga i contenuti della memoria o del disco. Il fallimento del disco di un server è un caso particolare, in quanto il server può informare gli altri del problema prima di essere rimosso dal servizio [TN97]. Un diverso guasto del sistema è rappresentato dall interruzione dei link di comunicazione, che può essere un effetto collaterale della mobilità degli utenti, ed ha come risultato la perdita di messaggi. I fallimenti di comunicazione transitori possono essere nascosti da protocolli di livello inferiore, ma i fallimenti più prolungati possono causare partizionamenti della rete. In questo caso, i nodi di ciascun gruppo o partizione possono comunicare l uno con l altro, ma non possono comunicare con i nodi degli altri gruppi. Questo tipo di fallimento viene individuato quando un sito che ha inviato un messaggio non riceve risposta entro un certo tempo. L assenza di una risposta può indicare che il messaggio originale è stato perso, che la risposta è andata persa, che il destinatario è crollato, o semplicemente che il destinatario è lento a rispondere [Her87]. Spesso gli utenti richiedono che i servizi siano altamente disponibili, cioè che la percentuale di tempo per cui possono usufruire del servizio con tempi di risposta ragionevoli sia vicina al 100%. Nel contesto dei file system, il termine disponibilità (availability) si riferisce all accessibilità dei file. Se un client richiede l accesso ad un file, ma pur aven- 365

384 Replicazione di risorse in rete Vantaggi introdotti con la replicazione done diritto non riesce ad accedervi, allora si dice che quel file è indisponibile. La frazione di tempo nella quale possono essere eseguite operazioni legali su un file da parte di un client definisce la disponibilità di quel file. I fallimenti o le restrizioni imposte dal file system possono rendere un file disponibile per alcuni client ma non per altri. Si dice che un file a cui hanno accesso n client ha una disponibilità minore rispetto ad uno a cui possono accedere m client se m > n. In un sistema privo di fallimenti, si dovrebbe sempre permettere ad un client l accesso ad un file, a meno che un applicazione non ne abbia eseguito il locking o che il client non sia privo dei privilegi richiesti. Se non si considera la mancanza di disponibilità dovuta al locking o alla mancanza dei privilegi da parte dell utente, la disponibilità è una misura dell abilità del file system nel servire le richieste in presenza di fallimenti. La replicazione può essere vista come una tecnica per mantenere automaticamente la disponibilità dei dati nonostante i fallimenti dei server: infatti, se i dati sono replicati su due o più server, i client sono in grado di accedere ai dati su un server alternativo anche nel caso in cui quello di default dovesse fallire o diventare irraggiungibile. Replicando i dati si può quindi migliorare la percentuale di tempo durante il quale il servizio di accesso è disponibile. Una differenza importante tra i sistemi di caching e la replicazione è che nelle cache non sono tenuti necessariamente insiemi di oggetti, ad esempio file, nella loro interezza, e quindi il caching non aumenta la disponibilità a livello applicativo [CDK00]. I dati altamente disponibili non sono necessariamente dati corretti: possono essere non aggiornati, oppure può darsi che due utenti in partizioni diverse della rete abbiano fatto degli aggiornamenti che sono in conflitto e hanno bisogno di essere risolti. Un servizio tollerante ai guasti deve garantire sempre un comportamento corretto, a prescindere dal numero e dal tipo di guasti. Il sistema deve gestire la coordinazione dei suoi componenti in modo da mantenere le garanzie di correttezza in presenza di fallimenti, i quali possono avvenire in qualsiasi istante. La correttezza riguarda lo stato di aggiornamento dei dati forniti al client e gli effetti che le operazioni del client hanno sui dati; a volte riguarda anche la puntualità delle risposte del server. La tecnica di replicare i dati tra più siti è applicabile anche per ottenere la tolleranza ai guasti. In teoria, se fino a f di f + 1 server crollano, ne rimane almeno uno che può fornire il servizio; analogamente, se fino a f server possono presentare guasti bizantini, un gruppo di 2f + 1 server può fornire un servizio corretto se i server corretti vincono per maggioranza di voti su quelli guasti che possono fornire valori contraffatti. I dati possono essere replicati per aumentare l affidabilità del sistema: mantenendo più repliche, diventa possibile fornire una protezione migliore contro la corruzione dei dati. Ad esempio, si immagini di avere tre repliche di un file, e che ciascuna operazione di lettura e scrittura sia eseguita su ogni replica: ci si può proteggere 366

385 Replicazione di risorse in rete Vantaggi introdotti con la replicazione dal fallimento di una singola operazione di scrittura considerando come corretto il valore restituito da almeno due repliche [TvS01]. Inoltre, la distribuzione e la replicazione dei dati offrono l opportunità di migliorare le prestazioni, aumentando la località dei dati e permettendo l esecuzione in parallelo e il bilanciamento del carico. Negli ambienti di area locale, le prestazioni del file system vengono migliorate usando tecniche di caching per la gestione dei dati. Poiché un file system distribuito è sostanzialmente un mezzo per la condivisione delle risorse, ci si può aspettare che al crescere dei sistemi distribuiti cresca anche la quantità dei dati in condivisione. Ciò comporta un grande sovraccarico sulle risorse critiche come i file server e le reti di interconnessione. Di conseguenza, per le prestazioni dei file system distribuiti sono essenziali dei meccanismi efficienti per la condivisione dei dati [SZ92]. In generale, in un sistema replicato, per ottenere la massima efficienza è necessario sfruttare al massimo la località dei riferimenti ed incorporarla con la località spaziale della architettura di rete sottostante. L idea è che, posizionando una replica dei dati in prossimità del processo che li usa, il tempo di accesso ad essi diminuisce, di conseguenza il processo percepisce un aumento delle prestazioni. Ad esempio, se in qualche punto del sistema vengono emesse molte richieste di lettura per un certo dato, è consigliabile copiare tale dato in quel punto. Questa scelta però deve essere fatta considerando il costo dello spostamento dell intero dato in confronto a quello del trasferimento dei byte che devono essere letti. Se invece il dato viene scritto frequentemente, è consigliabile rimuovere tutte le repliche tranne una, e localizzare quest ultima vicino al punto in cui vengono emesse le richieste di scrittura [ABF93]. Esistono comunque dei limiti all efficacia della replicazione come tecnica di miglioramento delle prestazioni, e i suoi benefici risultano difficili da valutare. Infatti, anche se un client percepisce prestazioni migliori, può darsi che in questo modo venga consumata più banda nella rete per tenere le repliche aggiornate. La replicazione di dati immutabili aumenta le prestazioni con un piccolo costo per il sistema, ma la replicazione di dati che cambiano introduce un sovraccarico dovuto ai protocolli progettati per assicurare che i client ricevano dati aggiornati. Si consideri un processo p che accede ad una replica locale n volte al secondo, mentre la replica viene aggiornata m volte al secondo. Se n m, cioè il rapporto tra accessi e aggiornamenti è molto basso, ci si trova in una situazione in cui p non accederà mai a molte delle versioni aggiornate della replica locale, rendendo inutile la comunicazione di rete per quelle versioni. In questo caso, sarebbe forse meglio non mettere una replica locale vicino a p, oppure applicare una strategia diversa per l aggiornamento. Il successo dei sistemi distribuiti nelle reti di area locale li ha portati ad imporsi anche in ambienti di larga scala che comprendono da centinaia a migliaia di host. La replicazione è largamente applicata come tecnica per ottenere la scalabilità del sistema, perché i problemi di scalabilità spesso compaiono sotto forma di problemi di prestazioni. 367

386 Replicazione di risorse in rete Architetture dei sistemi di replicazione Si consideri un sistema distribuito che ha bisogno di scalare, ad esempio perché un numero crescente di processi ha bisogno di accedere a dei dati che sono gestiti da un singolo server. In questo caso, le prestazioni possono essere migliorate replicando il server e successivamente suddividendo il lavoro. I file system attuali come l NFS [Tan94] non sono in grado di affrontare adeguatamente la scalabilità, perché fanno affidamento su meccanismi di sincronizzazione e di caching in cui il client deve contattare il server, all apertura di un file, per controllare la validità dei dati nella sua cache. Tali tecniche generano un traffico di rete non necessario e sovraccaricano i server anche quando un file non è stato aggiornato dall ultima apertura da parte del client, perciò la loro scalabilità è limitata. Un approccio alla scalabilità nei file system è quello proposto dall AFS [IBM08] che elimina il problema della validazione della cache facendo uso di un meccanismo di callback, secondo il quale è responsabilità del server notificare i client ogni volta che un file cambia; in questo modo sono eliminate tutte le comunicazioni non necessarie tra il client e il file server. Inoltre, l AFS esegue il caching degli interi file sul disco dei client, e fornisce un meccanismo per la replicazione in sola lettura. L approccio dell AFS può fornire scalabilità a centinaia di stazioni di lavoro all interno dell ambiente accademico in cui è stato sviluppato, il cui bisogno principale è fornire un accesso ai file trasparente ed efficiente agli utenti che si muovono da una locazione all altra del sistema. C.2 Architetture dei sistemi di replicazione Esistono approcci non distribuiti e distribuiti per la replicazione dei dati. Negli approcci non distribuiti, un singolo nodo può impiegare tecniche di mirroring su dischi che si trovano in prossimità l uno dell altro, utilizzando uno storage dual-copy. I dati vengono scritti sequenzialmente su entrambe le repliche, ma lette da una sola. In questo modo, se un nodo crolla, l altro acquisisce il controllo dello storage. Le tecniche di replicazione distribuita, invece, fanno uso di un insieme di nodi che cooperano per memorizzare le repliche dei dati. Molte di queste tecniche forniscono maggiore affidabilità e disponibilità rispetto al mirroring, anche se generalmente comportano un sovraccarico e una complessità maggiore. Ad esempio, un oggetto replicato col mirroring non sopravvive ad un disastro fisico che distrugga entrambe le repliche, mentre le tecniche di replicazione che impiegano la distribuzione geografica sopravviverebbero [BDS87]. Si consideri un ambiente composto da applicazioni che producono, manipolano o analizzano dati della dimensione dal megabyte al petabyte e oltre, organizzati come un archivio e memorizzati su sistemi di storage. Gli utenti accedono all archivio da diverse locazioni e possono creare copie locali o repliche dei dati, le quali possono essere complete o parziali rispetto all archivio originale. Un sistema di gestione delle repliche, come illustrato nella figura C.1, è composto da nodi di storage collegati tra loro tramite protocolli di trasferimento dei dati. Sono detti replica manager quei componenti del sistema che dirigono 368

387 Replicazione di risorse in rete Architetture dei sistemi di replicazione replica manager catalogo storage protocollo di trasferimento dei dati storage Figura C.1: Architettura di un sistema di gestione delle repliche la creazione e la gestione delle repliche a seconda delle richieste degli utenti e della disponibilità dello storage. I replica manager forniscono ai client un servizio di accesso agli oggetti replicati del sistema. Ciascun client può richiedere una combinazione di letture e aggiornamenti degli oggetti. Le operazioni che non coinvolgono aggiornamenti sono dette richieste di sola lettura (read-only); quelle che modificano un oggetto, ma possono comunque comprendere anche delle letture, sono dette richieste di aggiornamento. L insieme dei replica manager presenti nel sistema può o meno variare nel tempo. In un sistema dinamico, un replica manager può aggiungersi al sistema o lasciarlo; se un replica manager crolla, viene considerato come se avesse lasciato la rete. In un sistema statico, non è permesso che i replica manager compaiano o scompaiano; perciò di fatto essi non crollano mai, in quanto il crollo implica che non sarà mai eseguito un altro passo nell esecuzione, anche se possono smettere di operare per un periodo indefinito [CDK00]. I nodi del sistema possono essere organizzati in vari modi. Le topologie gerarchiche hanno una struttura ad albero in cui gli aggiornamenti sono propagati attraverso dei percorsi ben definiti. Le repliche sono organizzate in una gerarchia in cui ciascuna scambia gli aggiornamenti solo con il proprio genitore o figlio. A causa del loro pattern di comunicazione semplificato, questi schemi riescono a mantenere più facilmente informazioni accurate sullo stato delle repliche con cui scambiano gli aggiornamenti [PST + 97]. Un sistema centralizzato presenta una replica master sulla quale vengono effettuate tutte le modifiche che in seguito saranno propagate anche agli altri nodi. Questo scenario asimmetrico è un modello semplificato della architettura client-server e fornisce un controllo maggiore sulla replicazione. Un particolare sito (il server) fornisce lo storage per tutti i dati del sistema, mentre i siti che accedono ad essi (i client) hanno capacità di storage limitate e possono memorizzare qualsiasi sottoinsieme dei dati in locale. I client possono così effettuare la replicazione in modo molto più efficiente, in quanto riducono lo spazio occupato sul disco locale e il carico della comunicazione rispettivamente memorizzando 369

388 Replicazione di risorse in rete Architetture dei sistemi di replicazione e trasferendo solo i dati di interesse, e il carico computazionale mantenendo la consistenza solo dei dati che vengono usati [RRPG99]. Le topologie piatte si trovano nei sistemi decentralizzati o peer-to-peer (P2P), composti da molte repliche che devono essere sincronizzate tra di loro, in cui la progressione degli aggiornamenti è interamente dipendente dagli accordi tra i peer. Questo scenario simmetrico è un modello astratto in cui tutti i peer memorizzano lo stesso insieme di dati, e ciascun nodo si comporta sia da server per lo storage che da client per l accesso ai dati. Qualsiasi replica può comunicare con qualsiasi altra, e questa possibilità di comunicazione any-to-any, oltre ad essere estremamente importante per la mobilità degli utenti, fornisce vantaggi anche in quegli ambienti in cui la topologia della rete è spesso variabile o impredicibile: le repliche possono comunicare, scambiarsi gli aggiornamenti, e sincronizzarsi con chiunque sia disponibile, invece di dover aspettare che uno specifico server diventi accessibile. Quando esiste una relazione di tipo client-server o primario-secondario tra le repliche, l aggiunta di nuovi client o secondari al sistema può avvenire semplicemente contattando il primario, mentre nei sistemi P2P aggiungere o rimuovere le repliche può richiedere un operazione che coinvolge tutti i peer. Le situazioni in cui ci sono gerarchie con connessioni tra peer a diversi livelli rappresentano le topologie ibride. Lo scenario del file system AFS, ad esempio, è composto da alcuni cluster collegati tra di loro da una rete backbone: ogni cluster ha un certo numero di stazioni di lavoro e un file server, che sta all intersezione tra il cluster e la rete backbone. Questo scenario è ibrido, perché i server collegati dalla rete backbone formano uno scenario simmetrico, mentre ogni cluster è asimmetrico [RT87]. Per gli utenti diventa difficile, se non impossibile, identificare dei particolari dati su centinaia e migliaia che possono essere presenti nell archivio di un grande sistema distribuito. Da questo punto di vista, avere dei metadati per i dati replicati aiuta gli utenti, permettendo loro di effettuare richieste basandosi sugli attributi. I metadati sono informazioni che descrivono l archivio, e sono formati da attributi come il nome o la data dell ultima modifica, ma possono anche contenere informazioni specifiche come i dettagli del processo che ha prodotto i dati. I metadati possono essere di due tipi: metadati che dipendono dal sistema, i quali consistono in attributi dei file come la data di creazione, la dimensione su disco e la locazione fisica (o le locazioni fisiche), oppure metadati definiti dall utente, i quali consistono in proprietà che dipendono dalle esigenze dell utente [VBR06]. Un catalogo contiene le informazioni necessarie a tenere traccia delle repliche e della loro locazione, e può essere interrogato dalle applicazioni usando gli attributi dei metadati per condurre varie operazioni, come ad esempio la localizzazione della replica più vicina di un particolare dato, o per scoprire il numero e la locazione di tutte le repliche disponibili di tale dato. Il catalogo può essere organizzato ad albero, come nel caso dei cataloghi basati su LDAP (Lightweight Directory Access Protocol) [KWG + 98], oppure i dati possono essere catalogati in base agli hash dei documenti, come avviene nelle 370

389 Replicazione di risorse in rete Modelli di consistenza delle repliche reti peer-to-peer. Si può anche seguire l approccio di memorizzare il catalogo in un database. In alcuni sistemi, il replica manager e il catalogo possono essere fusi in un unica entità. I metadati possono essere aggiornati attivamente dal sistema di gestione delle repliche oppure passivamente dagli utenti ogni volta che creano nuove repliche, modificano quelle esistenti, o aggiungono un nuovo file al catalogo. C.3 Modelli di consistenza delle repliche Intuitivamente, un insieme di repliche è consistente quando esse sono tutte uguali tra loro. Ciò significa che un operazione di lettura eseguita su qualsiasi replica restituirà sempre lo stesso risultato. Il problema della replicazione è che il fatto di avere più copie dei dati genera inconsistenza: ogni volta che una replica viene modificata, essa diventa diversa dalle altre. Spesso non è accettabile che client diversi, che usano diverse copie fisiche dei dati, ottengano risultati inconsistenti quando fanno delle richieste che riguardano gli stessi oggetti logici, cioè risultati che non corrispondono ai criteri di correttezza definiti dall applicazione. Per far sì che le repliche siano consistenti tra loro, quando una replica viene aggiornata bisogna assicurarsi che le modifiche siano propagate a tutte le altre repliche dello stesso dato. La consistenza è un requisito generale per i dati replicati che può variare di grado a seconda delle applicazioni; si occupa di garantire che le operazioni eseguite su un insieme di oggetti replicati producano dei risultati che corrispondono alle specifiche di correttezza per quegli oggetti [CDK00]. Il grado in cui la consistenza può essere allentata dipende principalmente dai pattern di accesso e di modifica dei dati replicati, oltre allo scopo per cui sono usati. Il prezzo da pagare per l indebolimento dei vincoli di consistenza sta nel fatto che le repliche possono risultare non sempre tutte uguali ovunque nel sistema. C.3.1 Modelli data-centrici Tradizionalmente, la consistenza è stata discussa nel contesto di operazioni di lettura e scrittura 1 su dati condivisi, a cui si accede da più di un sito durante il loro tempo di vita, e che sono resi disponibili, ad esempio, per mezzo di un file system distribuito. I modelli di consistenza data-centrici mirano a fornire a tutto il sistema una vista consistente dei dati, supponendo che i processi concorrenti possano aggiornarli contemporaneamente. Si consideri un archivio di dati, che può essere fisicamente distribuito su più macchine. In particolare, si supponga che ciascun processo che può accedere ai dati abbia a disposizione una replica locale dell intero archivio, e che le operazioni di scrittura eseguite su una replica vengano propagate alle altre, come illustrato nella figura C.2. 1 Un operazione sui dati viene considerata come una scrittura quando li modifica, altrimenti viene considerata come una lettura. 371

390 Replicazione di risorse in rete Modelli di consistenza delle repliche processo processo processo replica locale archivio di dati distribuito Figura C.2: Organizzazione di un archivio di dati distribuito e replicato Un modello di consistenza è essenzialmente un contratto tra i processi e l archivio di dati, tale che se i processi sono d accordo nell obbedire a certe regole, l archivio funziona correttamente [TvS01]. In genere, ci si aspetta che un processo che esegue un operazione di lettura su un dato restituisca un valore che rifletta i risultati dell operazione di scrittura più recente eseguita su quel dato. Implicitamente, si suppone dunque l esistenza di un tempo globale assoluto, in modo che si possa determinare senza ambiguità cosa significhi più recente. In assenza di un clock globale, è difficile definire precisamente quale operazione di scrittura sia l ultima; bisogna allora fornire altre definizioni, che portano ad una gamma di modelli di consistenza, ciascuno dei quali comporta una restrizione sui valori che un operazione di lettura su un dato può restituire. Come si può intuire, i modelli con minori restrizioni sono facili da usare, mentre quelli con restrizioni più pesanti possono essere difficili. Ovviamente, le prestazioni dei modelli semplici da usare sono peggiori rispetto a quelli difficili. Il modello di consistenza più forte è chiamato consistenza stretta (strict consistency), ed è definito dalla seguente condizione: Qualsiasi lettura su un dato x restituisce un valore corrispondente al risultato della scrittura più recente su x. Significa che tutte le scritture sono istantaneamente visibili a tutti i processi; se un dato viene cambiato, tutte le successive letture eseguite su quel dato restituiscono il nuovo valore, non importa quanto poco dopo la modifica sono fatte le letture, ed a prescindere da quali processi stanno leggendo e da dove sono localizzati. Analogamente, se viene fatta una lettura, essa riceve il valore corrente in quel momento, a prescindere da quanto poco dopo viene eseguita la successiva scrittura. I sistemi a singolo processore riescono ad osservare la consistenza stretta, ma in un sistema in cui i dati sono distribuiti su varie macchine, e si può accedere ad essi da diversi processi, le cose sono più complicate. Si supponga che x sia un dato memorizzato solo sulla macchina B. Si immagini che un processo sulla macchina A legga x al tempo t 1, e quindi che venga inviato un messaggio a B per ottenere x. Poco dopo, al tempo t 2, un processo su B esegue una scrittura su x. Se vale la consistenza stretta, la lettura deve sempre restituire il vecchio 372

391 Replicazione di risorse in rete Modelli di consistenza delle repliche valore, a prescindere da dove si trovano le macchine e da quanto t 2 e t 1 sono vicini tra loro. Se t 2 t 1 è, ad esempio, un nanosecondo, e le macchine distano 3 metri, per propagare la richiesta di lettura da A a B in modo da arrivare prima della scrittura il segnale dovrebbe viaggiare ad una velocità dieci volte maggiore di quella della luce. La consistenza stretta è il modello di consistenza ideale, ma siccome la sua implementazione in un sistema distribuito di fatto è impossibile, non è mai usata. Il problema sta nel fatto che è impossibile assegnare a ciascuna operazione un timestamp unico che corrisponda al tempo globale assoluto. Si può rilassare questa situazione dividendo il tempo in una serie di intervalli consecutivi, se si suppone che ciascuna operazione abbia luogo entro un intervallo e riceva un timestamp corrispondente. Un modello di consistenza più debole della consistenza stretta è la linearizzabilità. In questo modello, si assume che le operazioni ricevano un timestamp usando un clock globalmente disponibile, che però ha precisione finita. Sia ts o (x) il timestamp assegnato all operazione o eseguita sul dato x, dove o può essere una lettura o una scrittura. Si dice che un archivio di dati è linearizzabile quando ciascuna operazione riceve un timestamp e valgono le seguenti condizioni: Il risultato di qualsiasi esecuzione è lo stesso che si avrebbe se le operazioni di lettura e scrittura da parte di tutti i processi sull archivio di dati fossero eseguite in qualche ordine sequenziale e le operazioni di ciascun processo compaiono in questa sequenza nell ordine specificato dal suo programma. Inoltre, se ts o1 (x) < ts o2 (x), allora l operazione o 1 (x) deve precedere o 2 (x) in questa sequenza. Anche la consistenza sequenziale è un modello di consistenza più debole rispetto alla consistenza stretta. La sua definizione è identica a quella della linearizzabilità, esclusa la condizione sui timestamp. In generale, si dice che un archivio di dati osserva la consistenza sequenziale quando: Il risultato di qualsiasi esecuzione è lo stesso che si avrebbe se le operazioni di lettura e scrittura sull archivio di dati ad opera di tutti i processi fossero eseguite in qualche ordine sequenziale, e in tale sequenza le operazioni di ciascun processo compaiono nell ordine specificato dal relativo programma. Il criterio di correttezza per gli oggetti replicati è definito facendo riferimento ad un interleaving 2 virtuale delle operazioni dei client, che può non realizzarsi fisicamente in nessuna replica, ma che stabilisce la correttezza dell esecuzione: quando dei processi sono in esecuzione in modo concorrente, è accettabile qualsiasi interleaving delle operazioni di lettura e scrittura, purché tutti i processi vedano lo stesso interleaving di operazioni. Si noti che non viene detto niente a proposito del tempo, e che non compare nessun ordinamento totale delle operazioni; non c è nessun riferimento all operazione di scrittura più recente effettuata su un oggetto. L unica nozione di ordinamento rilevante è l ordine degli eventi in ciascun client, ossia l ordine del programma. L interleaving delle operazioni può mescolare la sequenza di operazioni di 2 L interleaving è un processo che dispone in maniera apparentemente disordinata un certo numero di oggetti ordinati. 373

392 Replicazione di risorse in rete Modelli di consistenza delle repliche un insieme di client in qualsiasi ordine, purché non sia violato l ordine di ciascun client e il risultato di ciascuna operazione sia consistente, in termini delle specifiche dell oggetto, con le operazioni che l hanno preceduta [CDK00]. La consistenza sequenziale può essere paragonata alla serializzabilità nel caso delle transazioni. Si dice che un insieme di transazioni eseguite in modo concorrente è serializzabile se il risultato finale è uguale a quello che si sarebbe ottenuto eseguendo le transazioni una dopo l altra in qualche ordine sequenziale. La differenza principale sta nella granularità: la consistenza sequenziale è definita in termini di operazioni di lettura e scrittura, mentre la serializzabilità è definita in termini di transazioni, le quali aggregano tali operazioni. Si noti che un archivio dati linearizzabile osserva anche la consistenza sequenziale, ma non viceversa. Il vincolo aggiuntivo che debba essere preservato l ordinamento secondo i timestamp rende la linearizzabilità più costosa da implementare rispetto alla consistenza sequenziale. Quest ultima ha dimostrato di essere fattibile ed è largamente usata, ma ha scarse prestazioni: si può dimostrare che se il tempo di lettura è r, il tempo di scrittura è w, e il tempo minimo di trasferimento di un pacchetto tra i nodi è t, è sempre vero che r + w > t. Quindi cambiare il protocollo per migliorare le prestazioni in lettura peggiora le prestazioni in scrittura, e viceversa. Esistono dei rilassamenti della consistenza sequenziale, come i seguenti due modelli, in cui non si ha più un accordo globale su quali operazioni avvengono in quale ordine, ma processi diversi possono vedere sequenze diverse di operazioni; essi differiscono in termini di quali sequenze sono permesse. Il modello di consistenza causale distingue gli eventi che potenzialmente sono causalmente correlati da quelli che non lo sono. Se l evento B è causato o influenzato da un precedente evento A, la causalità richiede che tutti vedano prima A e poi B. Se due processi scrivono contemporaneamente due dati diversi, allora non sono causalmente correlati. Quando però si ha una lettura seguita da una scrittura, i due eventi potenzialmente sono causalmente correlati. Analogamente, una lettura è causalmente correlata alla scrittura che fornisce i dati da leggere. Le operazioni che non sono causalmente correlate sono concorrenti. Un archivio di dati osserva la consistenza causale se rispetta la seguente condizione: Le scritture che potenzialmente sono causalmente correlate devono essere viste da tutti i processi nello stesso ordine, mentre le scritture concorrenti possono essere viste in un ordine diverso su macchine diverse. Implementare la consistenza causale richiede che si tenga traccia di quali processi hanno visto quali scritture; ciò significa che deve essere costruito e mantenuto un grafo che indichi quale operazione dipende da quale altra. La consistenza FIFO, invece, è soggetta alla seguente condizione: Le scritture eseguite da un singolo processo sono viste da tutti gli altri processi nell ordine in cui sono state emesse, ma le scritture da parte di processi diversi possono essere viste in un ordine diverso da processi diversi. In pratica, in questo modello tutte le scritture generate da processi diversi sono concorrenti. Anche se la consistenza FIFO può presentare prestazioni 374

393 Replicazione di risorse in rete Modelli di consistenza delle repliche migliori rispetto ai modelli di consistenza più forti, risulta sempre troppo restrittiva per quelle applicazioni che non hanno necessità di vedere tutte le scritture, tanto meno vederle in ordine. Nella tabella C.1 sono riassunti i modelli di consistenza visti finora, in ordine di restrittività decrescente. consistenza stretta descrizione ordinamento temporale assoluto di tutti gli accessi condivisi linearizzabilità tutti i processi vedono gli accessi condivisi nello stesso ordine; gli accessi sono ordinati secondo un timestamp globale sequenziale causale FIFO tutti i processi vedono gli accessi condivisi nello stesso ordine; gli accessi non sono ordinati nel tempo tutti i processi vedono nello stesso ordine gli accessi condivisi che sono causalmente correlati le scritture di un processo sono viste nell'ordine in cui sono emesse; le scritture da parte di processi diversi possono essere viste in un ordine diverso da processi diversi Tabella C.1: Modelli di consistenza che non usano variabili di sincronizzazione Un approccio diverso consiste nell introdurre variabili di sincronizzazione esplicite, come fanno la consistenza debole (weak consistency), la consistenza release e la consistenza entry. Quando un processo esegue un operazione su un dato condiviso, non ci sono garanzie su quando le modifiche saranno visibili agli altri processi, perché esse vengono propagate soltanto in seguito ad un operazione esplicita di sincronizzazione. consistenza debole release entry descrizione i dati condivisi possono essere considerati consistenti soltanto dopo la sincronizzazione i dati condivisi sono resi consistenti all'uscita dalla regione critica i dati condivisi che riguardano una regione critica sono resi consistenti all'entrata nella regione critica Tabella C.2: Modelli di consistenza che usano variabili di sincronizzazione I tre modelli, riassunti nella tabella C.2, differiscono per come funziona la sincronizzazione, ma in tutti i casi un processo può eseguire più letture e scritture in una sezione critica senza invocare alcun trasferimento di dati. Quando la sezione critica è stata completata, il risultato finale è propagato agli altri processi, oppure è comunque pronto per essere propagato nel momento in cui qualche altro processo richiede quei dati. In linea di principio, questi modelli che usano la sincronizzazione esplicita dovrebbero essere in grado di fornire le prestazioni migliori, ma è probabile che applicazioni diverse producano risultati piuttosto diversi. 375

394 Replicazione di risorse in rete Modelli di consistenza delle repliche C.3.2 Modelli client-centrici Il grado in cui i processi realmente operano in maniera concorrente, e in cui la consistenza deve essere garantita, può variare. Ci sono molti casi in cui la concorrenza si presenta solo in forma ristretta perché normalmente soltanto uno, o comunque pochissimi processi eseguono operazioni di aggiornamento. Di conseguenza, non si presentano mai conflitti 3 risultanti da due operazioni che vogliono eseguire entrambe un aggiornamento sugli stessi dati, cioè conflitti di tipo write-write; bisogna soltanto occuparsi dei conflitti di tipo read-write. In tali casi, spesso è accettabile propagare gli aggiornamenti in maniera lazy, nel senso che un processo in lettura li vedrà solo dopo che è passato un certo tempo da quando sono avvenuti. Così il problema diventa decidere quanto velocemente devono essere resi disponibili gli aggiornamenti ai processi di sola lettura [TvS01]. Si consideri una particolare classe di archivi di dati distribuiti, caratterizzati dalla mancanza di aggiornamenti simultanei, o comunque tali che quando vengono eseguite delle modifiche, queste possono essere facilmente risolte, e la maggior parte delle operazioni riguarda la lettura dei dati. Questi archivi di dati tollerano un grado relativamente alto di inconsistenza, perciò seguono un modello di consistenza molto debole, detto consistenza finale (eventual consistency), il quale essenzialmente richiede soltanto la garanzia che gli aggiornamenti siano propagati a tutte le repliche. Se non avvengono aggiornamenti per lungo tempo, infatti, tutte le repliche gradualmente diventeranno consistenti. Supponendo che solo un piccolo gruppo di processi possa eseguire gli aggiornamenti, i conflitti di tipo write-write sono facili da risolvere, perciò implementare la consistenza finale è poco costoso. La consistenza finale funziona bene purché i client accedano sempre alla stessa replica, ma sorgono dei problemi quando si accede a repliche diverse. Si consideri un utente mobile che accede ad un sistema distribuito, come mostrato nella figura C.3. L utente accede al sistema collegandosi ad una delle repliche in modo trasparente, cioè l applicazione in esecuzione sul computer portatile dell utente non sa su quale replica stia realmente operando. Si supponga che l utente esegua varie operazioni di aggiornamento e poi si disconnetta; in seguito accederà ancora al sistema, magari dopo essersi spostato in una locazione diversa, oppure usando un dispositivo diverso per l accesso. A quel punto, l utente potrebbe essere connesso ad una replica diversa da quella di prima, e se questa non ha ancora ricevuto gli aggiornamenti eseguiti in precedenza, l utente noterà un comportamento inconsistente, perché si aspetterebbe di vedere tutti i cambiamenti fatti fino ad allora, ma invece gli apparirà come se non fossero mai stati eseguiti. Questo problema può essere alleviato introducendo i modelli di consistenza client-centrici, cioè fornendo ad un singolo client garanzie sulla consistenza degli accessi ad un archivio di dati da parte di quel client, senza però fornire garanzie riguardo agli accessi concorrenti da parte di client diversi. 3 Si dice che due operazioni sono in conflitto se operano sugli stessi dati e una di esse è un operazione di scrittura. 376

395 Replicazione di risorse in rete Modelli di consistenza delle repliche il client spostandosi si collega a un'altra replica archivio di dati distribuito replica replica rete replica replica operazioni di lettura e scrittura replica computer portatile Figura C.3: Accesso ad un sistema replicato da parte di un utente mobile Si consideri di nuovo un archivio di dati fisicamente distribuito su più macchine. Quando un processo accede all archivio, generalmente si collega alla replica disponibile in locale o comunque a quella più vicina, anche se, in linea di principio, qualsiasi replica andrebbe bene. Tutte le operazioni di scrittura e lettura sono eseguite su quella replica, e alla fine gli aggiornamenti sono propagati alle altre. Per semplificare le cose, si suppone che ciascun dato abbia associato un proprietario che è l unico processo a cui è permesso modificare quel dato, in modo da evitare i conflitti di tipo write-write. Un archivio di dati osserva il modello di consistenza monotonic-reads se vale la seguente condizione: Se un processo legge il valore di un dato x, qualsiasi successiva operazione su x da parte di quel processo restituirà sempre quello stesso valore o un valore più recente. In pratica, si garantisce che se un processo ha visto un certo valore di x al tempo t, non vedrà mai una versione più vecchia di x in futuro. In molte situazioni è importante che le operazioni di scrittura siano propagate nell ordine giusto a tutte le repliche dell archivio. In un archivio che osserva la consistenza monotonic-writes, vale la seguente condizione: Un operazione di scrittura da parte di un processo su un dato x viene completata prima di qualsiasi successiva operazione di scrittura su x da parte dello stesso processo. In altre parole, un operazione di scrittura su una replica di x è eseguita solo se quella replica è stata aggiornata ricevendo tutte le scritture che sono avvenute in precedenza su altre repliche di x. Si noti che la consistenza monotonic-writes ricorda la consistenza FIFO datacentrica, la quale prevede che le operazioni di scrittura da parte dello stesso processo siano eseguite ovunque nell ordine giusto. Questo vincolo di ordinamento si applica anche alla consistenza monotonic-writes, solo che in questo caso si 377

396 Replicazione di risorse in rete Protocolli di gestione della consistenza considera la consistenza solo per un singolo processo invece che per un insieme di processi concorrenti. Secondo una forma un po più debole di consistenza monotonic-writes, gli effetti di una scrittura sono visibili soltanto se tutte le scritture precedenti sono state terminate, ma non necessariamente nell ordine in cui erano state originariamente emesse. Questo modello è applicabile quando le operazioni di scrittura sono commutative, e l ordinamento non è necessario. Un modello di consistenza client-centrico strettamente correlato a quello monotonic-writes è il modello di consistenza read-your-writes, definito dalla seguente condizione: L effetto di una operazione di scrittura da parte di un processo su un dato x sarà sempre visto da una successiva operazione di lettura su x da parte dello stesso processo. In questo caso, una scrittura è sempre completata prima di una successiva lettura da parte dello stesso processo, a prescindere da dove avviene quest ultima. L ultimo modello di consistenza client-centrico è la consistenza writes-followreads, che viene osservata se: È garantito che un operazione di scrittura da parte di un processo su un dato x che segue una precedente operazione di lettura su x da parte dello stesso processo avviene su un valore di x uguale o più recente di quello che era stato letto. In altre parole, qualsiasi operazione di scrittura da parte di un processo su un dato x sarà eseguita su una replica di x che è aggiornata al valore letto più recentemente da quel processo. C.4 Protocolli di gestione della consistenza I protocolli di gestione delle repliche devono assicurare che, anche se un sito crolla rendendo alcune repliche di qualche dato indisponibili, le operazioni sui dati logici possano comunque essere eseguite, e il criterio di consistenza sia soddisfatto [Jal94]. Dal punto di vista dell usabilità, la replicazione è guidata da due metriche: Obiettivo punto di recupero. La situazione di consistenza a cui i dati possono essere riportati dopo un fallimento. Obiettivo tempo di recupero. Il tempo necessario per riportare i dati ad una situazione di consistenza in seguito ad un fallimento. Si è visto che, quando un dato replicato viene aggiornato in un sito, le modifiche devono essere propagate al resto delle repliche: questo può avvenire in modo sincrono o asincrono [VBR06]. Secondo la replicazione sincrona, ciascun dato che viene scritto su un sistema di storage locale viene replicato anche nelle sue locazioni remote prima che l operazione di scrittura locale ritorni. Stando alle metriche descritte in precedenza, la replicazione sincrona appare il meccanismo ideale per entrambi gli aspetti. Per quanto riguarda l obiettivo punto di recupero, nella replicazione sincrona i sistemi di storage remoto e locale vanno di pari passo, perciò è garantito che 378

397 Replicazione di risorse in rete Protocolli di gestione della consistenza i dati scritti su disco saranno sempre disponibili su entrambi. Analogamente per l obiettivo tempo di recupero, poiché il sistema locale e quello remoto sono sincronizzati, non sono richieste lunghe procedure per portare il sistema remoto in uno stato consistente in caso di fallimento di quello locale. Per questi motivi, la replicazione sincrona di solito è raccomandata per quelle applicazioni in cui la consistenza tra i sistemi di storage locale e remoto ha alta priorità. La replicazione sincrona richiede costosi protocolli di locking e frequenti movimenti di grandi quantità di dati; inoltre ha un impatto diretto sulle prestazioni del sistema locale, dato che la latenza sul percorso tra il sistema primario e quello remoto viene riflessa nel tempo necessario a completare la scrittura sul disco locale. La penalità dovuta alla latenza della rete nella replicazione sincrona di solito è tollerabile solo quando la distanza tra il sito primario e il secondario è limitata. Secondo la replicazione asincrona, i sistemi di storage locale e remoto possono presentare un certo grado di divergenza, che di solito è limitato da una certa quantità di dati o da un certo lasso di tempo. Di conseguenza, la replicazione asincrona comporta sempre qualche perdita di dati in caso di fallimento del sito primario. D altra parte, poiché le operazioni di scrittura possono essere eseguite in modalità batch, un sistema di replicazione asincrona riesce ad utilizzare appieno la capacità della rete tra i siti locale e remoto, senza preoccuparsi della latenza tra di essi. In termini di trasferimento dei dati, i sistemi di replicazione asincrona spostano i dati in modo molto più efficiente rispetto a quelli di replicazione sincrona [LNS + 06]. I protocolli di replicazione tradizionali cercano di dare all utente l illusione di avere un singola copia dei dati, coordinando in modo sincrono le repliche durante gli accessi. Questo scopo può essere ottenuto in molti modi, ma il concetto alla base rimane lo stesso: viene bloccato l accesso ad una replica da parte degli altri utenti durante gli aggiornamenti. Per questo motivo, tali protocolli tradizionali vengono chiamati protocolli pessimistici. Essi funzionano bene in reti di area locale, in cui le latenze sono piccole e i fallimenti rari. Se però si volesse provare ad applicarli in scenari più ampi, non ci si possono aspettare buone prestazioni. Mentre internet rimane lento e inaffidabile, e la sua disponibilità e latenza di comunicazione non sembrano migliorare, i computer portatili con connettività intermittente stanno diventando sempre più diffusi. Un protocollo di replicazione pessimistico, cercando di sincronizzarsi con un sito non disponibile, si bloccherebbe indefinitamente. I protocolli pessimistici scalano male: è difficile costruire un sistema grande e replicato in modo pessimistico con aggiornamenti frequenti, perché al crescere del numero dei siti la disponibilità diventa un problema. Ci sono poi alcune attività che richiedono un tipo diverso di condivisione dei dati. Ad esempio, lo sviluppo di software spesso richiede che le persone lavorino in relativo isolamento; in questo caso, è meglio permettere che i dati siano aggiornati indipendentemente e risolvere gli eventuali conflitti dopo che 379

398 Replicazione di risorse in rete Protocolli di gestione della consistenza sono avvenuti, piuttosto che eseguire il locking dei dati mentre qualcuno li sta modificando [SS05]. La caratteristica chiave dei protocolli ottimistici è il loro approccio al controllo della concorrenza. Tali protocolli permettono di accedere ai dati senza la sincronizzazione a priori, basandosi sul presupposto che i conflitti si presentano solo raramente. Gli aggiornamenti sono propagati in background, e gli eventuali conflitti sono risolti, non prevenuti. I protocolli ottimistici offrono molti vantaggi. Innanzi tutto, aumentano l affidabilità: le applicazioni possono procedere anche quando i link di comunicazione e i siti sono inaffidabili. Inoltre, possono scalare fino ad un grande numero di repliche, perché richiedono poca sincronizzazione, permettendo ai siti e agli utenti di rimanere autonomi. Secondo la replicazione ottimistica, tutte le repliche accessibili devono essere disponibili per qualsiasi uso, compreso l aggiornamento, perciò il servizio che essa fornisce è un servizio altamente disponibile [RRPG99]. Questi benefici, comunque, hanno un costo che si materializza nel compromesso tra la disponibilità e la consistenza affrontato da ogni sistema distribuito. In confronto alle tradizionali tecniche pessimistiche, la replicazione ottimistica offre migliori prestazioni e maggiore disponibilità, ma è utilizzabile solo con applicazioni che possono tollerare eventuali conflitti e dati inconsistenti. Fortunatamente, in molti sistemi del mondo reale, specie i file system, i conflitti sono piuttosto rari, grazie al partizionamento dei dati e alla regolazione degli accessi che naturalmente avvengono tra gli utenti. C.4.1 Metodo del sito primario L approccio del sito primario è un protocollo pessimistico che ha lo scopo di continuare a fornire l accesso ai dati anche in presenza di fallimenti di nodi o di link nel sistema. Si supponga, per il momento, che nel sistema possano avvenire solo fallimenti di nodi, e che i nodi in funzione rimangano connessi. Si vuole garantire la possibilità di eseguire le operazioni sui dati anche se fino a k nodi falliscono. A tale scopo, i dati vengono replicati su almeno k + 1 nodi del sistema. Ciascun dato dell archivio ha associato un sito primario, che è il responsabile della gestione di tutti gli accessi a quel particolare dato [SS05]. In ogni istante, uno solo tra i nodi che contengono quel dato ha il ruolo di sito primario, mentre gli altri sono visti come siti di backup. Nella versione più semplice di questo approccio, un processo che vuole eseguire una qualsiasi operazione, di lettura o di scrittura, su un certo dato, dovrà sempre inoltrare tale operazione al server primario per quel dato. Se l operazione richiesta è una lettura, allora il primario semplicemente la esegue e restituisce il risultato al processo che l aveva richiesta. Se l operazione è un aggiornamento, il primario la esegue sulla sua replica locale del dato, e poi la inoltra ad almeno k siti di backup. Se l aggiornamento è visto come un operazione bloccante, il primario restituisce la chiamata al processo che aveva richiesto l operazione solo quando ha 380

399 Replicazione di risorse in rete Protocolli di gestione della consistenza ricevuto la notifica che tutti i siti di backup hanno aggiornato con successo la loro replica locale. Il problema è che può essere necessario un tempo relativamente lungo prima che il processo che aveva richiesto l aggiornamento abbia il permesso di procedere. In alternativa, il primario può restituire la chiamata appena ha aggiornato la sua replica locale del dato, e in seguito ordinare ai server di backup di eseguire anche loro l aggiornamento. Il problema principale dell approccio non bloccante riguarda la tolleranza ai guasti, perché in questo caso il client non può avere la certezza che l operazione di aggiornamento sia stata effettivamente eseguita anche negli altri server [TvS01]. Si consideri cosa accade in seguito al fallimento di uno o più nodi del sistema. Se più di k siti crollano quasi contemporaneamente, allora non c è niente da fare, poiché il grado di replicazione è soltanto k + 1. Se però il numero totale di fallimenti è minore di k, allora si riesce a mascherarli. Nel caso in cui i nodi crollati sono siti di backup, il servizio non viene interrotto, perché l utente può ricevere la risposta dal primario. Se invece a fallire è il sito primario, ne dovrà essere eletto uno nuovo che da quel momento in poi sia responsabile dell esecuzione delle operazioni. Esistono vari modi in cui si può scegliere di promuovere un sito di backup al ruolo di primario. Ad esempio, se i nodi sono logicamente organizzati come una lista lineare in cui il primario è il primo nodo, si può stabilire che a diventare il nuovo primario sarà il primo nodo ancora in funzione che si incontra nella lista. Il nuovo primario può iniziare ad eseguire le richieste dell utente solo dopo aver completato tutte le operazioni ad esso inoltrate da parte del precedente primario [Jal94]. Si considerino adesso i fallimenti che causano i partizionamenti della rete. In questo caso, solo la partizione che comprende il sito primario può funzionare; infatti, il primario può servire le richieste che hanno origine nella partizione a cui esso appartiene, ma quelle che hanno origine nelle altre partizioni non possono essergli inoltrate, e quindi non possono essere servite. Poiché il metodo del sito primario utilizza due diversi approcci per la gestione dei fallimenti a seconda del loro tipo, esso può funzionare soltanto se un nodo che non è in grado di comunicare con il sito primario riesce a determinare se ciò sia dovuto al fallimento di un nodo o ad un partizionamento della rete. Nel primo caso si terrà l elezione del nuovo primario, nel secondo il nodo dovrà semplicemente aspettare finché non sarà di nuovo in grado di comunicare con il primario al ricongiungimento delle partizioni. Si noti che un tale sistema di replicazione non riesce a tollerare i guasti bizantini, e che per ottenere la tolleranza ai guasti, i client devono essere in grado di trovare il nuovo primario quando quello corrente non risponde. Si è visto che tutte le richieste arrivano prima al sito primario, il quale poi le inoltra agli altri. Di conseguenza, tutti i siti di backup ricevono le richieste nello stesso ordine in cui le riceve il primario, purché il canale di comunicazione sia affidabile e preservi l ordinamento. Se il primario ha un comportamento corretto, allora il sistema implementa la linearizzabilità. Quando il primario crolla, il sistema continua ad osservare la linearizzabilità se sono soddisfatte due condizioni. 381

400 Replicazione di risorse in rete Protocolli di gestione della consistenza Innanzi tutto, il primario deve essere sostituito da un singolo sito di backup, perché se due client iniziassero ad usarne due diversi, il sistema potrebbe comportarsi in modo non corretto. Inoltre, i nodi in funzione devono essere in accordo su quali operazioni sono state eseguite fino al momento in cui il nuovo primario inizia a lavorare, cioè il sistema deve riprendere esattamente da dove si era interrotto [CDK00]. client client W1 W5 R1 R2 backup W4 W3 W2 primario W4 W3 backup W3 W4 backup W1: richiesta di scrittura W2: inoltro al primario W3: inoltro ai siti di backup W4: notifica della modifica W5: notifica della scrittura R1: richiesta di lettura R2: risposta alla lettura Figura C.4: Approccio del sito primario con letture sui siti di backup W1: richiesta di scrittura client client W2: spostamento primario R1 R2 backup W4 vecchio primario W5 W4 W2 W1 W3 nuovo primario W5 W4 W5 backup W3: notifica della scrittura W4: inoltro della modifica W5: notifica della modifica R1: richiesta di lettura R2: risposta alla lettura Figura C.5: Approccio del sito primario con migrazione del sito primario In una variante di questo approccio, illustrata nella figura C.4, i client possono inviare le richieste di lettura ai siti di backup, alleggerendo così il carico di lavoro del primario. In questo modo si perde la garanzia della linearizzabilità, comunque i client ricevono un servizio che osserva la consistenza sequenziale. Infatti, dato che il primario ordina tutte le scritture, ciascun processo le vedrà sempre tutte nello stesso ordine, a prescindere da quale server di backup usi per eseguire le letture. Inoltre, se viene seguito l approccio bloccante, i processi vedranno sempre gli effetti della loro operazione di scrittura più recente. Un ulteriore variante prevede che la replica primaria possa migrare tra i processi che vogliono eseguire un operazione di scrittura. Ogni volta che un processo vuole aggiornare un certo dato, ne localizza la replica primaria e poi la sposta nella propria locazione, come mostrato nella figura C.5. Il principale vantaggio di questo approccio è che più operazioni 382

401 Replicazione di risorse in rete Protocolli di gestione della consistenza successive di scrittura possono essere portate a termine localmente, mentre i processi in lettura possono ancora accedere alla loro replica locale. Comunque, ciò può avvenire solo se viene seguito un approccio non bloccante. C.4.2 Metodo a votazione Un altro tipo di protocollo pessimistico prevede che i client, prima di eseguire un operazione su un dato replicato, debbano richiedere ed acquisire il permesso da parte di più server attraverso una votazione. Questo approccio garantisce che le operazioni in conflitto non siano eseguite in modo concorrente. Nella votazione pesata, a ciascuna replica fisica di uno stesso dato logico, che consiste in una replica in un nodo del sistema, viene assegnato un peso, rappresentato da un certo numero di voti. Ogni nodo che voglia eseguire un operazione di lettura sul dato deve ottenere almeno r voti dai nodi del sistema prima di poterlo leggere; analogamente, prima di poterlo aggiornare deve ottenere almeno w voti. Il numero delle repliche, il loro peso e la loro locazione, e i voti richiesti per le operazioni di lettura e scrittura rappresentano la configurazione di un dato [RT87]. Sia v il numero totale dei voti, cioè la somma dei voti associati a tutte le repliche di un dato. I valori r e w sono chiamati rispettivamente quorum di lettura e quorum di scrittura, e devono soddisfare due condizioni: r + w > v w > v 2 La prima condizione garantisce che il quorum di lettura e scrittura associati ad ogni dato abbiano un intersezione non vuota: ciò assicura che ogni quorum di lettura comprenda una replica con la versione più recente del dato, ossia una versione che rifletta l ultimo aggiornamento eseguito su di esso, realizzando la consistenza sequenziale [RL05]. Inoltre, garantisce che un operazione di lettura e una di scrittura non possano essere eseguite contemporaneamente sullo stesso dato, evitando i conflitti di tipo read-write [TvS01]. La seconda condizione garantisce che due quorum di scrittura abbiano un intersezione non vuota, in modo da impedire i conflitti di tipo write-write. Così se il sistema viene partizionato in due gruppi, una scrittura su un dato può essere eseguita in al più un gruppo. In pratica, il quorum di scrittura per ogni dato deve avere un intersezione non vuota con qualsiasi altro quorum di lettura o di scrittura per lo stesso dato. Si noti che due quorum di lettura non hanno bisogno di avere l intersezione non vuota, poiché non esistono conflitti di tipo read-read. Per determinare se le repliche sono aggiornate si possono associare ad esse dei numeri di versione o dei timestamp. Se si usano i numeri di versione, inizialmente ogni replica avrà un numero di versione pari a zero, che sarà aumentato in seguito ad ogni aggiornamento. Ciascuna replica ha un numero di versione, ma solo le repliche aggiornate hanno il numero di versione attuale, mentre quelle non aggiornate avranno numeri 383

402 Replicazione di risorse in rete Protocolli di gestione della consistenza precedenti. Le operazioni devono essere eseguite soltanto sulle repliche con numeri di versione attuali. Quando viene richiesta un operazione di lettura e scrittura su un dato replicato, per prima cosa vengono contattati tutti i nodi che contengono una replica del dato, i quali rispondono inviando il numero di versione della loro replica e il numero di voti che possiedono. Il nodo che ha emesso la richiesta può eseguire l operazione solo dopo aver acquisito il quorum, ossia solo quando ha ricevuto dai nodi contattati un numero di voti maggiore o uguale a quello stabilito per il quorum. In un operazione di lettura, la richiesta preliminare dei numeri di versione per ottenere il quorum di lettura fa sì che vengano imposti dei lock ad ogni nodo contattato. Il nodo che ha richiesto l operazione controlla il numero di versione di tutte le repliche nel quorum ottenuto: non tutte queste repliche saranno aggiornate, ma poiché comunque presi i quorum di lettura e scrittura hanno sempre un intersezione non vuota, almeno una di esse sarà la più aggiornata, e avrà il numero di versione più alto. Il nodo allora legge i dati da uno dei nodi del quorum che hanno il numero di versione più alto. Anche in un operazione di scrittura viene imposto un lock ad ogni nodo coinvolto. In questo caso, il nodo che richiede l operazione deve assicurarsi che tutti i nodi nel quorum di scrittura ottenuto siano aggiornati al valore più recente. Se le repliche aggiornate sono in numero insufficiente, prima di eseguire l operazione, per raggiungere il quorum sarà necessario sostituire ogni eventuale replica non aggiornata con una aggiornata. Ciò può richiedere la lettura del valore di alcuni nodi nel quorum e la scrittura su di essi. A questo punto, gli aggiornamenti specificati nell operazione di scrittura possono essere applicati a ciascun nodo nel quorum; il relativo numero di versione viene incrementato, e al client viene notificato il completamento dell operazione. Quando l aggiornamento è stato portato a termine, tutte le repliche nel quorum di scrittura avranno la versione più recente dei dati. I file nei restanti nodi disponibili sono poi aggiornati eseguendo l operazione di scrittura in background. Qualsiasi nodo la cui replica del dato ha un numero di versione più vecchio di quello usato dal quorum di scrittura lo aggiorna sostituendo l intero dato con la versione ottenuta da un nodo aggiornato. Se un nodo non è in grado di ottenere il quorum, allora non può eseguire l operazione, a prescindere dal fatto che non sia stato in grado di ottenerlo a causa del crollo di un nodo o di un partizionamento della rete. In seguito a fallimenti dei nodi ma non dei link di comunicazione, le operazioni di lettura e scrittura possono essere eseguite se l insieme dei nodi connessi ancora in funzione ha un totale di voti maggiore di w. Se il numero di voti è minore di w, ma maggiore di r, allora possono essere eseguite solo operazioni di lettura. Se sono meno anche di r, non possono essere eseguite neanche le letture. Si supponga adesso che il sistema venga partizionato in due insiemi di nodi. Poiché w > v 2, al più un gruppo può avere il quorum di scrittura, per cui gli aggiornamenti possono essere eseguiti in al più una partizione. Nella partizione 384

403 Replicazione di risorse in rete Protocolli di gestione della consistenza che ha w voti possono essere eseguite anche le operazioni di lettura, dato che r < w. L altra partizione invece non avrà neanche un quorum di lettura, poiché r + w > v. Questo garantisce che siano permesse soltanto quelle operazioni di lettura che possono accedere alla versione più recente dei dati. In pratica, la votazione pesata mantiene la consistenza disabilitando le situazioni in cui possono sorgere le inconsistenze. Il vantaggio è che si riescono a mascherare sia i fallimenti dei nodi che quelli delle comunicazioni, senza bisogno di essere in grado di distinguere tra i due tipi di fallimenti [Jal94]. Un importante proprietà del protocollo a votazione pesata è che i gruppi di nodi possono essere configurati in modo tale da fornire prestazioni e caratteristiche di affidabilità diverse. Una volta che l affidabilità generale e le prestazioni di un gruppo di nodi sono stabilite dalla sua configurazione di votazione, l affidabilità e le prestazioni delle operazioni di lettura e scrittura possono essere aumentate rispettivamente diminuendo w e r. In generale, le prestazioni possono variare in relazione a fattori come l assegnamento dei voti, i quorum di lettura e scrittura o il rapporto tra letture e scritture. Per velocizzare le letture, il protocollo può anche permettere l uso delle copie dei file sui dischi locali dei client oltre che in quelli dei server. Per garantire che non siano incluse in nessun quorum, alle copie dei file nelle macchine client vengono sempre assegnati zero voti. Dopo che il quorum di lettura è stato ottenuto, l operazione può essere eseguita su qualsiasi replica aggiornata, perciò anche sulla copia locale del file, se è aggiornata [CDK00]. Se si suppone che ad ogni nodo sia assegnato un solo voto, esistono due estremi per la scelta del quorum. Nell approccio read-one-write-all, qualsiasi nodo può essere usato per la lettura, mentre l aggiornamento deve essere fatto su tutti i nodi del sistema: r = 1, di conseguenza w = v, in modo da soddisfare la prima condizione. Il problema è che se anche un solo nodo crolla, le operazioni di aggiornamento non possono più essere eseguite. Se si procedesse con gli aggiornamenti mentre un nodo sta subendo un fallimento, in seguito quel nodo, dopo aver recuperato dal crollo, potrebbe venire usato per eseguire un operazione di lettura, dato che r = 1; ma poiché tale nodo era crollato al momento dell aggiornamento, fornirebbe al client un dato non aggiornato. L approccio opposto è la votazione a maggioranza, nella quale sia r che w sono uguali alla maggioranza dei voti totali, ossia v 2. In questo caso, sia per le letture che per le scritture serve la maggioranza dei nodi. In presenza di partizionamenti della rete, se esistono gruppi di maggioranza, tali gruppi funzioneranno, mentre gli altri no. Come semplice esempio, si consideri un file system distribuito, e si supponga che un file sia replicato su un certo numero di server. Per aggiornare il file, un client deve prima contattare almeno la metà dei server più uno, cioè la maggioranza, e farli accordare riguardo l operazione di aggiornamento. Una volta trovato l accordo, il file viene cambiato, e ad esso viene associato un nuovo numero di versione. Anche per effettuare una lettura un client deve contattare almeno la metà 385

404 Replicazione di risorse in rete Protocolli di gestione della consistenza dei server più uno, e chiedere loro di mandargli i numeri di versione associati al file. Se tutti i numeri di versione sono in accordo, allora quella corrispondente dev essere la versione più recente del file, visto che un tentativo di aggiornare soltanto i rimanenti server fallirebbe, non essendo essi in numero sufficiente. (a) A B C D E F G H I J K L r=3 w=10 (b) A B C D E F G H I J K L r=6 w=7 (c) A B C D E F G H I J K L r=1 w=12 Figura C.6: Esempi di configurazione per i quorum nella votazione Per capire come funziona l approccio a votazione nel caso in cui ad ogni nodo è assegnato un voto, si considerino gli esempi di configurazione per i quorum illustrati nella figura C.6. Nell esempio (a) si ha r = 3 e w = 10. Se l operazione di scrittura più recente ha ottenuto il quorum composto dall insieme dei 10 server da C a L, ognuno di essi possiede la versione del dato più recente. Qualsiasi successiva operazione di lettura deve ottenere un quorum composto da 3 server, che quindi comprende sicuramente uno dei server dell insieme precedente; di conseguenza, confrontando i numeri di versione, il client può scoprire qual è il dato più recente, ed eseguire la lettura su di esso. Nell esempio (b) si ha r = 7 e w = 6. In questo caso è possibile che si presentino situazioni di conflitto, perché essendo v = 12 è violata la condizione w < v 2. Ad esempio, se un client ottiene il quorum di scrittura composto dai server {A, B, C, E, F, G} e un altro lo ottiene composto dai server {D, H, I, J, K, L}, i due aggiornamenti sono entrambi eseguiti senza che il conflitto venga rilevato. Nell esempio (c) si ha infine la configurazione read-one-write-all, in cui è sufficiente eseguire la lettura su una singola replica, ma è necessario eseguire la scrittura su tutte. Il problema principale dell approccio di votazione pesata è che il numero di nodi nel quorum richiesto per poter eseguire un operazione aumenta linearmente con il numero delle repliche. Una generalizzazione di questo approccio che riduce il sovraccarico nella comunicazione è la votazione gerarchica, descritta in dettaglio più avanti, nel paragrafo ; l idea consiste nell organizzare logicamente i nodi secondo una gerarchia ed ottenere il quorum ad ogni livello. Esistono anche dei protocolli di votazione con approccio dinamico, in cui l assegnazione dei voti, i requisiti di quorum, il numero totale di repliche o altre informazioni sul sistema possono cambiare nel tempo, in modo da adattarsi ai suoi cambiamenti. Permettendo ai quorum di essere modificati dinamicamente, ad esempio, migliora la disponibilità [PLG88]. In presenza di un partizionamento, si può decidere che la partizione di maggioranza debba essere considerata come il nuovo sistema; in questo modo, un operazione è permessa se ha un quorum di maggioranza in quella che in preceden- 386

405 Replicazione di risorse in rete Protocolli di gestione della consistenza za era la partizione di maggioranza. In caso di fallimento di un nodo, l effetto del crollo può essere compensato effettuando un riassegnamento dinamico dei suoi voti. C.4.3 Metodo dei vettori di versione Idealmente, un protocollo di gestione delle repliche dovrebbe continuare ad osservare il relativo criterio di consistenza anche di fronte a partizionamenti della rete. Si è visto che un tradizionale protocollo pessimistico impedisce il sorgere di inconsistenze limitando l accesso ai dati, mentre un protocollo ottimistico non pone nessun vincolo al procedere dell esecuzione, nella speranza che le operazioni eseguite sulle diverse partizioni non siano in conflitto. Durante un partizionamento della rete, se le operazioni continuano ad essere eseguite indipendentemente in ciascuna partizione, le repliche dei dati nelle diverse partizioni possono risultare inconsistenti. Quando le diverse partizioni si sono riunite e sono nuovamente in grado di comunicare l una con l altra, i protocolli di replicazione ottimistici devono individuare i conflitti in modo affidabile, e cercare di risolverli prima che riprenda la normale attività sui dati interessati. Questi protocolli si differenziano proprio per il modo in cui individuano e risolvono le inconsistenze, dato che in realtà non hanno molto altro da fare durante l esecuzione [Jal94]. Un approccio che può essere usato per questo scopo è quello dei vettori di versione, il quale considera i file come unità di replicazione. Si supponga che un file f possa avere molte repliche, ciascuna su un nodo diverso. Si dice che un aggiornamento ha origine nel nodo i se la richiesta dell utente arriva al nodo i. Ogni volta che viene eseguita una modifica su f, vengono aggiornate tutte le repliche di f che sono accessibili dal nodo in cui ha avuto origine la richiesta. Ad ogni replica del file viene associato un vettore di versione di dimensione n, dove n è il numero di siti in cui è memorizzato il file. Il vettore di versione v di una replica del file f rappresenta il numero di aggiornamenti, con origine in diversi nodi, che sono stati eseguiti su questa replica. Nel nodo j, l i-mo elemento del vettore, v i, rende conto del numero degli aggiornamenti con origine nel sito i che sono stati eseguiti sulla replica di f tenuta nel nodo j. Se la rete è totalmente connessa, allora ogni aggiornamento sarà eseguito su ogni replica del file, e i vettori di versione di tutte le repliche saranno uguali. Se però avviene un partizionamento, allora i vettori di versione delle varie repliche possono divergere, a seconda della natura delle operazioni eseguite nelle diverse partizioni. Si dice che un vettore v di una replica del file domina un altro vettore v di un altra replica dello stesso file se v i > v i per ogni i = 1,..., n. Se un vettore v domina v, significa che per ogni nodo j sono state eseguiti più aggiornamenti da parte di j sulla replica associata a v rispetto a quella associata a v. In pratica, gli aggiornamenti visti dalla replica associata v sono 387

406 Replicazione di risorse in rete Protocolli di gestione della consistenza un sottoinsieme di quelli visti dalla replica associata a v. Si dice che due vettori sono in conflitto se nessuno dei due domina l altro. Quando due partizioni si riuniscono e possono di nuovo comunicare tra loro, vengono confrontati i vettori. Se il vettore di una partizione domina l altro, nonostante le due repliche non siano uguali, si può facilmente eliminare l inconsistenza copiando i dati indicati come più recenti dal vettore di versione su quelli meno recenti. Se invece i vettori sono in conflitto, non c è un modo semplice per risolvere la situazione di inconsistenza, e sarà necessario intervenire manualmente. A B <0,0,0> <0,0,0> <0,0,0> C A <0,0,0> B <0,0,0> C <0,0,0> A <2,0,0> B <2,0,0> C <0,0,0> A <3,0,0> B <2,0,0> C <2,0,0> A <3,0,0> B <2,0,1> C <2,0,1> A B C conflitto dei vettori di versione Figura C.7: Esempio dell approccio dei vettori di versione Si consideri l esempio illustrato nella figura C.7, in cui i tre nodi A, B e C possiedono ognuno una replica di un certo dato. Inizialmente, i vettori di versione relativi al dato posseduti dai nodi sono identici, con tutti gli elementi pari a 0. Ad un certo punto si vengono a creare due partizioni nella rete: una contiene i nodi A e B, e l altra contiene il nodo C. Quando A ha eseguito due aggiornamenti sul dato, poiché A e B sono connessi, i loro vettori di versione sono diventati <2,0,0>, mentre il vettore posseduto da C è rimasto <0,0,0>. In seguito, B si separa da A e si unisce a C. Poiché il vettore di versione posseduto da B domina quello di C, il conflitto viene risolto copiando il dato e il vettore da B a C. Si consideri adesso cosa accade se A e C eseguono contemporaneamente una scrittura sul dato. Il vettore di versione del nodo A diventa <3,0,0>, poiché l aggiornamento eseguito da C non ha alcun effetto su di esso. 388

407 Replicazione di risorse in rete Strategie di replicazione I vettori di versione dei nodi B e C diventano entrambi <2,0,1>. Quando le due partizioni si riuniscono, i vettori di versione sono in conflitto, poiché nessuno domina l altro, e la situazione deve essere risolta con intervento manuale. C.5 Strategie di replicazione Le strategie di replicazione determinano quando e dove replicare, quali dati replicare e in che grado, basandosi su fattori quali la richiesta dei dati, le condizioni della rete e il costo del trasferimento. Per ogni decisione presa in merito a ciascuno di questi problemi si ha una diversa strategia, perciò il numero complessivo delle potenziali strategie è alto, avendo molte variabili in gioco. I principali obiettivi di una strategia di replicazione sono massimizzare la località, minimizzare i costi di aggiornamento e assicurarsi che la propagazione delle modifiche sia efficace. La granularità di una strategia di replicazione si riferisce al livello di suddivisione dei dati con cui essa lavora; se si trattano più file allo stesso tempo, la strategia lavora alla granularità degli archivi, altrimenti può lavorare al livello dei singoli file, e ci sono anche strategie che gestiscono suddivisioni più piccole, come i frammenti di file [VBR06]. In pratica, una strategia di replicazione determina quante repliche di un certo oggetto vengono create, e su quali nodi del sistema queste repliche vengono allocate. Questa scelta influenza le prestazioni del sistema distribuito, perché leggere un dato localmente è più veloce e meno costoso rispetto a leggerlo da un processore remoto; per questo motivo, il rapporto tra letture e scritture di un dato è un fattore chiave nell individuazione dello schema ottimale [WJH97]. Se le operazioni di lettura su un oggetto sono la maggioranza, conviene effettuare una replicazione largamente distribuita di quell oggetto, in modo da aumentare il numero delle letture locali e diminuire il carico del server centrale. Viceversa, se l aggiornamento di un oggetto viene scritto su tutte le repliche, o sulla maggioranza di esse, una distribuzione larga rallenta tutte le scritture e aumenta i costi di comunicazione, perciò conviene effettuare una replicazione strettamente distribuita. Altre due proprietà delle sequenze di accesso ai dati hanno un effetto significativo: Località degli accessi. Quando un certo sito richiede un dato, è probabile che il prossimo sito a richiedere quel dato sarà ancora lo stesso. Parzialità o bias degli accessi. Spesso un unico sito è il responsabile di una grande percentuale di tutti gli accessi ad un certo dato [RT87]. Esistono due tipi di strategie di replicazione: una strategia statica prevede che ciascun dato abbia un numero fisso di repliche in ogni momento, cioè che il grado di replicazione sia costante; una strategia dinamica, invece, permette che il grado di replicazione vari col tempo. Oltre ai problemi visti, una strategia 389

408 Replicazione di risorse in rete Strategie di replicazione dinamica deve perciò affrontarne altrettanti che riguardano la rimozione delle repliche. Se i pattern di lettura e scrittura sono fissati e conosciuti a priori, è ragionevole usare una strategia statica. Se però i pattern di lettura e scrittura cambiano dinamicamente, in modo impredicibile, una strategia statica può introdurre seri problemi di prestazioni. Le strategie dinamiche si adattano ai cambiamenti di richiesta, larghezza di banda e disponibilità di storage, inoltre sono in grado di recuperare dai fallimenti, ad esempio i partizionamenti della rete. D altra parte, esse introducono un sovraccarico dovuto al grande numero di operazioni eseguite, dato che i cambiamenti vengono eseguiti ad intervalli regolari oppure in seguito ad eventi particolari come l aumento della domanda per un particolare file. Tali strategie hanno come risultato trasferimenti frequenti di grandi quantità di dati che possono portare ad uno sforzo delle risorse di rete. Se le condizioni delle risorse sono per lo più stabili per un lungo periodo di tempo, può esserci poco da guadagnare nell uso delle strategie dinamiche, perciò in tali casi è più opportuno applicare delle strategie statiche [HY96]. C.5.1 Posizionamento delle repliche Uno dei problemi principali nella progettazione degli archivi di dati distribuiti è decidere dove, quando e da chi devono essere posizionate le repliche dell archivio. Nella figura C.8 è illustrata l organizzazione logica dei tre tipi di repliche che possono essere presenti nell archivio. repliche permanenti repliche create su iniziativa dei server repliche create su iniziativa dei client client replicazione su iniziativa del server replicazione su iniziativa del client Figura C.8: Organizzazione logica dei tipi di repliche in un archivio Le repliche permanenti possono essere considerate l insieme iniziale di repliche che costituiscono un archivio. In molti casi, il numero di tali repliche è piccolo. Può essere conveniente installare un certo numero di repliche temporanee nelle zone da cui provengono le richieste, cioè replicare dinamicamente i dati 390

409 Replicazione di risorse in rete Strategie di replicazione presso i server che ne hanno bisogno, vicino ai client che li richiedono. Queste repliche create su iniziativa dei server sono dunque repliche che servono a migliorare le prestazioni [TvS01]. Si noti che, finché è garantito che ciascun dato viene ospitato da almeno un server, può essere sufficiente usare soltanto la replicazione su iniziativa dei server senza avere alcuna replica permanente. Ciò nonostante, le repliche permanenti spesso sono utili come mezzo di backup, o per essere usate come uniche repliche che è permesso cambiare al fine di garantire la consistenza. In questo caso, le repliche create su iniziativa dei server sono usate per posizionare delle repliche di sola lettura vicino ai client. Nel decidere esattamente dove e quando le repliche server debbano essere create o eliminate, una strategia dinamica deve tenere conto di due aspetti. Per prima cosa, la replicazione può servire a ridurre il carico di un server. Inoltre, può essere conveniente effettuare la migrazione o la replicazione di determinati dati da un server ad altri posizionati in prossimità dei client che li richiedono più spesso. Anche le repliche create su iniziativa dei client sono importanti. In linea di principio, la gestione della cache viene lasciata interamente al client, e l archivio non ha niente a che fare con la consistenza dei dati in essa contenuti. Esistono però molte situazioni in cui il client può fare affidamento sulla collaborazione dell archivio, poiché esso lo informa quando i dati nella sua cache sono diventati non più aggiornati. Le cache nei client sono utilizzate per migliorare i tempi di accesso ai dati. Di solito, quando un client vuole accedere a qualche dato, si collega alla replica più vicina dell archivio ed ottiene da essa i dati che vuole leggere, o scrive su di essa i dati che ha appena modificato. Se la maggior parte delle operazioni riguarda soltanto la lettura dei dati, le prestazioni possono essere migliorate permettendo al client di memorizzare i dati richiesti in una cache vicina, così la volta seguente che devono essere letti gli stessi dati, il client può ottenerli da essa. Ovviamente, questo schema funziona bene purché i dati richiesti non siano stati modificati nel frattempo. Il posizionamento delle cache dei client è relativamente semplice: di solito viene posizionata una cache sulla stessa macchina del client, oppure su una macchina diversa, nel caso di una cache condivisa da più client, nella stessa rete di area locale. Si suppone infatti che una richiesta di dati da parte del client C 1 possa essere utile anche per una richiesta da parte di un altro client C 2 vicino, benché ciò sia vero soltanto per certi tipi di archivi di dati. Nei file system tradizionali, ad esempio, i file sono raramente condivisi, perciò una cache condivisa risulta abbastanza inutile. Un altro approccio consiste nel posizionare dei cache server in punti specifici della rete, e lasciare che sia il client a localizzare il più vicino. Di solito, comunque, i dati sono tenuti in cache per un tempo limitato, per impedire che vengano usati dei dati non aggiornati, oppure semplicemente per lasciare spazio ad altri dati. 391

410 Replicazione di risorse in rete Strategie di replicazione C.5.2 Propagazione degli aggiornamenti In genere le operazioni di aggiornamento su un archivio di dati distribuito e replicato vengono iniziate da un client. In seguito, l aggiornamento deve essere propagato alle altre repliche. Esistono diversi modi di propagare, ossia distribuire, gli aggiornamenti alle repliche, indipendentemente dal modello di consistenza da osservare, a seconda di come vengono affrontati alcuni problemi nella progettazione del sistema [TvS01]. Un primo importante problema riguarda cosa debba essere veramente propagato. Una possibilità consiste nel propagare solamente una notifica dell aggiornamento: è quello che fanno i cosiddetti protocolli di invalidazione. Questi protocolli si limitano a informare le altre repliche del fatto che è avvenuta una modifica e che i dati che esse contengono non sono più validi. L invalidazione può specificare quale parte dell archivio è stata aggiornata, in modo che venga invalidata solo parte della replica. Poiché non viene propagato niente più che una notifica, a seconda dello specifico modello di consistenza da osservare, ogni volta che viene richiesta un operazione su una replica invalidata tale replica deve prima essere aggiornata. Il vantaggio principale dei protocolli di invalidazione è che usano poca banda nella rete, visto che l unica informazione da trasferire è la specifica di quali dati non sono più validi. Tali protocolli in genere lavorano meglio in presenza di molte operazioni di aggiornamento, ossia quando il rapporto tra letture e scritture è basso. Esistono però degli inconvenienti relativi a questo metodo. Per prima cosa, richiedere che le repliche ricevano gli aggiornamenti su richiesta porta ad una maggiore latenza nell accesso ai dati; in secondo luogo, è ovvio che le possibilità di perdere dati sono più alte con l invalidazione, poiché usando questa tecnica è possibile che esista una sola replica del dato in un certo istante [SZ92]. Un alternativa, utile quando il rapporto tra letture e scritture invece è relativamente alto, è trasferire i dati modificati da una replica all altra. In questo caso, la probabilità che un aggiornamento sia efficace, cioè che i dati modificati saranno letti prima del prossimo aggiornamento, è alta. L inconveniente di questa tecnica è il potenziale numero di aggiornamenti sprecati, perché può darsi che le repliche vengano aggiornate molte volte prima di essere realmente usate da parte di un altro sito. Invece di propagare i dati modificati, è possibile anche tenere un log dei cambiamenti e trasferire solo quelli in modo da risparmiare banda. Inoltre, spesso i trasferimenti vengono aggregati, cioè vengono raggruppate più modifiche in un singolo messaggio, riducendo in questo modo il sovraccarico nella comunicazione. Un altro approccio è quello di propagare alle altre repliche l operazione di aggiornamento da eseguire. Si suppone che ciascuna replica sia rappresentata da un processo capace di mantenere aggiornati i dati ad esso associati eseguendo le operazioni. Il beneficio principale di questo tipo di replicazione è che gli aggiornamenti possono essere propagati con costi di banda minimi, purché la dimensione dei 392

411 Replicazione di risorse in rete Strategie di replicazione parametri associati ad un operazione sia piccola. D altra parte, può esserci bisogno di una capacità di esecuzione maggiore da parte di ciascuna replica, specialmente quando le operazioni sono relativamente complesse. Un ulteriore problema riguarda se gli aggiornamenti debbano essere di tipo pull o push. In un approccio di tipo push, chiamato anche protocollo basato sui server, gli aggiornamenti sono propagati alle altre repliche senza che esse li abbiano mai richiesti. Questi approcci spesso sono usati tra le repliche permanenti e quelle create su iniziativa dei server, ma possono essere usati anche per propagare gli aggiornamenti alle cache dei client. In generale, i protocolli basati sui server sono applicati quando le repliche hanno bisogno di mantenere un grado di consistenza relativamente alto. Le repliche permanenti e quelle iniziate dal server, così come le grandi cache condivise, spesso sono condivise tra molti client che eseguono principalmente operazioni di lettura. Di conseguenza, il rapporto tra letture e scritture in ogni replica è relativamente alto. In questi casi, gli approcci di tipo push sono efficienti, in quanto ci si può aspettare che ciascun aggiornamento risulti utile per uno o più lettori. Un problema importante è che nei protocolli di tipo push il server deve tenere traccia di tutte le cache dei client. A parte il fatto che i server stateful di solito sono meno tolleranti ai guasti, tenere traccia di tutte le cache dei client può introdurre un sovraccarico considerevole nel server. Per quanto riguarda i messaggi inviati tra client e server, in un approccio di tipo push l unica comunicazione avviene quando il server invia gli aggiornamenti a ciascun client. Ma se gli aggiornamenti in realtà sono soltanto invalidazioni, c è bisogno di un ulteriore comunicazione quando il client vuole ottenere i dati modificati. Viceversa, in un approccio di tipo pull, chiamato anche protocollo basato sui client, un server o un client deve interrogare un altro server per vedere se è necessario un aggiornamento, e in caso affermativo richiedergli di inviarglielo. Un tale approccio è efficiente quando il rapporto tra letture e scritture è relativamente basso, come spesso accade nelle cache dei client non condivise. Comunque, anche quando una cache è condivisa da molti client un approccio di tipo pull può essere efficiente se i dati in cache sono condivisi raramente. Il principale svantaggio di una strategia di questo tipo è che il tempo di risposta aumenta nel caso in cui il dato richiesto non sia presente nella cache. Quando un server di tipo push propaga i dati modificati alle cache dei client, il tempo di risposta visto dal lato client è zero; se invece propaga le invalidazioni, il tempo di risposta è lo stesso che si ha nell approccio di tipo pull, ed è determinato dal tempo che ci vuole per ottenere i dati modificati dal server. Esiste anche una forma ibrida di propagazione degli aggiornamenti, basata sui prestiti, che fornisce un meccanismo per passare dinamicamente da una strategia di tipo push ad una di tipo pull. Un prestito (lease) è una promessa fatta dal server che propaga gli aggiornamenti ai client per un certo tempo secondo l approccio di tipo push. Quando il prestito scade, il client può richiederne uno nuovo, oppure seguire un approccio 393

412 Replicazione di risorse in rete Strategie di replicazione di tipo pull e interrogare il server per ricevere gli aggiornamenti e, se necessario, i dati modificati. La durata del prestito può variare dinamicamente a seconda dei criteri adottati. In relazione al tipo di approccio pull o push, si decide se propagare gli aggiornamenti in unicast o in multicast. Nella comunicazione unicast, quando un server che fa parte dell archivio invia i suoi aggiornamenti ad n altri server, lo fa inviando n diversi messaggi, uno per ogni server. Con il multicast, la rete sottostante si occupa di mandare un messaggio in modo efficiente a più ricevitori. Il multicast spesso può essere combinato efficientemente con un approccio di tipo push, in modo che un server che decida di propagare i suoi aggiornamenti ad un certo numero di altri server può farlo semplicemente usando un singolo gruppo multicast. Perciò, in molti casi è più economico usare le strutture multicast disponibili. D altra parte, con un approccio di tipo pull, generalmente un solo client o server per volta richiede che la sua replica venga aggiornata, perciò in questo caso l unicast può essere la soluzione più efficiente. 394

413 Appendice D Versioning e collaborazione La gestione delle versioni riguarda un sottoinsieme delle attività previste nell ambito del Document Management. Nello sviluppo del software, il versioning diviene un argomento centrale, indipendentemente dalla strategia adottata. Per questo motivo molti modelli, sistemi e applicazioni sono stati pensati e realizzati per coordinare la produzione del codice sorgente, dei binari e il rilascio dei pacchetti. La gestione automatizzata delle versioni aiuta nello sviluppo e nella manutenzione dei dati, incrementando la qualità dei processi. Se il processo è efficace, allora permette benefici nel lavoro collaborativo, assicurando fiducia nel conseguire le finalità. Nelle organizzazioni la rilevanza del problema si ripropone con le stesse caratteristiche, ma con maggiore gravità. Non solo c è bisogno di mantenere un accurata storia dei documenti, per adempiere agli obblighi amministrativi, ma anche per poter rintracciare ed ottenere, con il minimo errore, i dati più recenti o relativi ad un preciso periodo storico. È facile comprendere che l authoring concorrente, e volendo generalizzare il Document Management, risultano essere strettamente correlati alla gestione delle versioni. In origine si assumeva implicitamente che le persone, così come le risorse, fossero localizzate nello stesso sito geografico. Con il successo di Internet, l authoring è divenuto un attività distribuita. Oggi esiste il bisogno di sviluppare nuovi strumenti, capaci di agevolare i processi da luoghi geograficamente dispersi. In questo capitolo vengono introdotti i concetti legati alla gestione delle versioni, viene discusso dettagliatamente il modello UEVM e vengono descritte, in ordine cronologico di introduzione, alcune delle applicazioni più note per la gestione delle versioni nell ambito dello sviluppo del software:

414 Versioning e collaborazione RCS (paragrafo D.7); CVS (paragrafo D.8); Subversion (paragrafo D.9). Dall evoluzione di tali applicazioni si capisce che il mercato si sta dirigendo verso soluzioni che facilitano sempre più il lavoro collaborativo, questo perché lo sviluppo di software è un attività complessa che normalmente viene effettuata da un numero più o meno elevato di persone. Attualmente infatti stanno nascendo ambienti di sviluppo integrati (IDE) che non si limitano ad agevolare il lavoro del singolo programmatore o ad integrare plugin per interfacciarsi a sistemi di versioning come quelli menzionati, ma che mettono a disposizione dei tool specifici per la collaborazione (come l interazione asincrona/sincrona e la gestione integrata delle versioni): COOP/Orm (paragrafo D.10). Infine vengono introdotti alcuni sistemi che non basano il proprio principio di funzionamento sul paradigma client/server, ma su quello peer-to-peer: BitKeeper, Git, Svk. (paragrafo D.11). D.0.3 Modelli di lavoro Quando più persone operano contemporaneamente sullo stesso sistema devono sincronizzare il loro lavoro. Normalmente si ha una suddivisione dei compiti fra i vari soggetti, questa operazione può essere ricorsiva per organizzazioni strutturate in modo gerarchico (per esempio: l organizzazione divide il lavoro fra le varie sedi, ogni sede divide la parte di propria competenza fra i gruppi ivi locati infine ogni gruppo suddivide le mansioni fra i vari membri di appartenenza). Durante il processo di sviluppo del sistema è necessario ricombinare le varie parti almeno una volta, per creare il prodotto finito; molto probabilmente però, questa operazione sarà effettuata più volte (nel complesso o per assemblare sottosistemi più grandi delle singole parti) per ottenere le pietre miliari ed i prodotti semi-lavorati previsti dai convenzionali processi di sviluppo. Esistono due approcci diversi per effettuare la suddivisione: architetturale: si effettua una divisione fisica del sistema da sviluppare in sottosistemi o moduli separati e si assegna un responsabile ad ognuno di essi. Soltanto il responsabile ha la possibilità di operare sulla risorsa; anatomico: si dividono le mansioni sulla base dei risultati (o funzionalità) che si intendono ottenere, lasciando la possibilità a tutti i soggetti di operare su ogni parte del sistema. Durante le prime fasi di sviluppo l approccio architetturale è quello maggiormente usato. Si dimostra però eccessivamente statico nelle fasi finali, fasi nelle quali si uniscono sottosistemi distinti in un prodotto unico, quello finale. Per risolvere eventuali problemi che sorgono in questa fase è probabile che sia necessario intervenire su più sottosistemi, rendendo l approccio anatomico più conveniente. Il 396

415 Versioning e collaborazione rovescio della medaglia è che sono richiesti sforzi supplementari per garantire la consistenza del progetto. È necessario che le unità di lavoro siano correttamente ordinate ed analizzate affinché possano essere effettuate in concorrenza. Un altra terminologia utilizzata per i modelli di lavoro prevede la definizione di tre tipi di coordinamento: turn-taking: un singolo individuo alla volta è abilitato ad apportare cambiamenti al progetto, gli altri, di fatto, non possono operare; split-combine: il progetto è partizionato ed ogni individuo è abilitato ad operare sulla parte di sua competenza (equivalente ad architetturale), tale approccio potrebbe risultare eccessivamente statico; copy-merge: ogni soggetto ha a disposizione una copia di tutto il progetto sulla quale operare e, di tanto in tanto, le modifiche vengono fuse insieme (equivalente ad anatomico). Per la gestione delle fusione delle modifiche occorrono meccanismi complessi, che, in base al contesto, potrebbero non riuscire nei loro intenti lasciando il sistema in uno stato inconsistente (nel tal caso risulta necessario intervenire manualmente). Nel caso in cui la compagnia sia organizzata in modo gerarchico è usuale ricorrere a combinazione di modelli. Ad esempio è comune uno scenario in cui agli alti livelli si ricorre al tipo split-combine, in quanto si hanno vari gruppi responsabili di sottosistemi distinti, mentre all interno dei singoli gruppi si usa il tipo copy-merge. In generale la scelta della strategia deve tenere presente due direttive, in sostanza contraddittorie. Da una parte esiste la necessità di integrare il più velocemente possibile le modifiche e le correzioni, dall altra è preferibile fornire agli utenti un ambiente di lavoro il più stabile possibile, affinché ogni utente non venga esageratamente disturbato dalle attività degli altri. Le strategie del primo tipo sono dette ottimistiche e le seconde conservative. Le strategie di aggiornamento riguardano le modalità con cui le nuove informazioni sono messe a disposizione del gruppo di lavoro e quando devono essere recepite ed usate dagli altri. Una strategia di aggiornamento ottimistica consiste nel pubblicare immediatamente tutte le modifiche, per consentirne un uso immediato. Questo significa che il problema dell integrazione dovrà essere risolto in tempi brevi. Nella strategia di aggiornamento conservativo le modifiche non hanno effetti immediati; in altre parole vuol dire ritardare la pubblicazione. La scelta della strategia si riflette nell approccio con cui viene gestito il lavoro concorrente. Per principio una strategia conservativa non consente modifiche concorrenti allo stesso documento, mentre una strategia ottimistica ammette una pianificata integrazione dei dati, con tempi più o meno rigidi. Per impedire modifiche concorrenti il sistema blocca la risorsa in esame permettendo al solo utente che l ha bloccata di effettuare modifiche. In questo caso si parla di blocco (o lock) conservativo o pessimistico. Nei sistemi in cui viene attuata la strategia ottimistica, per analogia, si parla di blocco (o lock) ottimistico. In questo caso il sistema non attua un blocco vero e proprio della risorsa, ma tiene traccia degli autori che la stanno modificando in concorrenza in modo da permettere un integrazione controllata delle modifiche. In questo caso gli utenti devono 397

416 Versioning e collaborazione Il concetto di configurazione interpretare il blocco come stato in cui la risorsa è in fase di aggiornamento da parte di altri; la percezione che essi hanno del blocco e cosa questo comporti all atto pratico, varia molto al variare del contesto. D.1 Il concetto di configurazione Nel tempo non variano solamente i contenuti di un documento, ma anche la relativa struttura. Se la medesima struttura è comune a molti documenti, definisce una tipologia (per i certificati, per documenti di identità, per i referti, per i verbali, etc.). La modifica di una tipologia comporta la modifica di ciascuno dei documenti associati. Per esempio, in riferimento al linguaggio comune, la patente di Mario Rossi è il documento rappresentato dall insieme di informazioni riportate in tabella D.1. Tipo di dato Valore Nome Mario Cognome Data e Luogo di Nascita Etc. Rossi 20/10/1971 Firenze (FI) Etc. Tabella D.1: Struttura e dati di un documento Esistono informazioni necessarie per descrivere il documento in quanto tale e altre che sono i dati che questo contiene. Le informazioni appartenenti alla prima categoria sono dette metadati associati al documento e, in riferimento all esempio riportato in tabella D.1, sono le informazioni presenti nella colonna di sinistra. I metadati consentono la gestione dei documenti e, a loro volta, sono rappresentati tramite uno o più documenti oggetto di authoring. Una configurazione (configuration) è l insieme dei metadati che definiscono la struttura, il workflow, il comportamento e lo stato interno del documento. In alcuni contesti questo concetto viene esteso fino a comprendere il documento stesso e, di conseguenza, reso più generico. Un ulteriore generalizzazione è quella di considerare prodotti e sistemi oltre a documenti e definire configurazione una istantanea del sistema (documento o prodotto) al tempo corrente t 0. Con istantanea si intendono tutte le informazioni necessarie per poter ricreare il sistema (documento o prodotto) esattamente come si presenta al tempo t 0, nello stesso o in un altro 398

417 Versioning e collaborazione Il concetto di configurazione luogo, in un momento t 1 t 0. Infine è utile menzionare la seguente definizione ricorsiva: una configurazione è un insieme di entità atomiche e di altre configurazioni. È possibile associare varie interpretazioni a questa definizione, alcune delle quali permettono di mettere in relazione i contenuti (entità atomiche) con gli aspetti strutturali. Supponendo che l insieme sia ordinato e che ogni entità atomica abbia come figli tutte le entità atomiche contenute nella configurazione che precede, applicando la definizione ricorsiva si ottiene un albero. Passo 1 Passo 2 Passo 3 Configurazione iniziale C1 C2 C3 Entità atomiche Configurazioni Figura D.1: Esempio ricorsivo della configurazione In figura D.1 è presente un esempio nel quale la configurazione iniziale è costituita da una entità atomica seguita da una configurazione. Espandendo la configurazione C1 (Passo 1), la radice acquisisce due figli. Al primo di essi è associata una nuova configurazione (C2) la quale, a sua volta, contiene due entità atomiche e una terza configurazione (C3). Ripetendo l algoritmo ricorsivo (Passi 2 e 3) si ottiene l albero riportato nell ultimo riquadro a destra della figura. Non esiste una definizione univoca di configurazione e pertanto, parlando di gestione di configurazioni, è possibile intendere cose diverse. In letteratura, a riguardo, è possibile trovare molte definizioni (vedi [App08]) e una fra quelle coerenti con la definizione più generale data di configurazione è la seguente: con CM (Configuration Management) si intendono tutti quei processi atti a gestire lo sviluppo e le modifiche di sistemi, prodotti o documenti durante il loro intero ciclo di vita. I sistemi finalizzati al CM (chiamati anche Configuration Management Systems, CMS) permettono quindi di controllare l evoluzione temporale delle configurazioni per garantire la loro integrità nel tempo e la tracciabilità delle modifiche. In riferimento ai Content Management Systems è possibile osservare che esiste una similitudine nella definizione di questi ultimi e dei Configuration Management Systems. La differenza sostanziale consiste nel fatto che i primi sono maggiormente orientati alla gestione del workflow dell informazione mettendo a disposizione molte funzionalità avanzate per questo scopo, i secondi sono maggiormente orientati al tracciamento dell evoluzione temporale della configurazione (dell informazione) mettendo a disposizione strumenti sofisticati e specifici per il controllo e la gestione delle versioni. 399

418 Versioning e collaborazione Il concetto di configurazione Data la sua diffusione è utile ricordare che con Software Configuration Management (SCM ) si intendono tutti quei processi atti a gestire lo sviluppo e le modifiche di codice sorgente durante il suo intero ciclo di vita. È utile sottolineare che, anche in questo caso, tale definizione non è la sola esistente. Per quanto riguarda i requisiti che devono essere soddisfatti è possibile individuare due macrocategorie, una che comprende gli aspetti relativi alla gestione, l altra allo sviluppo delle configurazioni. Prospettiva della gestione. Assumendo il punto di vista della gestione delle configurazioni si possono identificare quattro aree di interesse: identificazione, controllo, accounting e verifica. Identificazione. Comprende le attività che determinano una configurazione, la relativa selezione, le caratteristiche funzionali, l assegnazione degli identificativi e le relazioni con altri documenti. Controllo. Comprende le attività di controllo dell aggiornamento delle configurazioni. Il controllo include anche la validazione, la coordinazione degli utenti, l approvazione e il rilascio. Accounting. Consiste nel memorizzare e riferire le configurazioni, lo storico e le modifiche approvate. Lo storico deve tracciare tutta la storia di un documento (prodotto o sistema), comprensiva delle eventuali deviazioni subite nel tempo. Verifica. Consiste nel determinare quando una configurazione è ben formata e valida rispetto ad un modello di riferimento. Prospettiva dello sviluppo. Assumendo il punto di vista dello sviluppo distribuito si possono identificare sette aree di interesse: controllo delle versioni, selezione della configurazione, controllo della concorrenza, tracciabilità dello sviluppo, rilascio dei documenti (prodotti o sistemi, di seguito è sottinteso), gestione dell ambiente di lavoro e gestione delle modifiche. Controllo delle versioni. Deve essere possibile memorizzare differenti versioni e varianti di un documento e conseguentemente essere capaci di ottenerle e confrontarle tra loro. Selezione della configurazione. Devono essere create e/o selezionate le configurazioni appropriate alle versioni. È una attività che definisce e assegna i tipi di documento. Controllo della concorrenza. L accesso simultaneo al documento da parte di più utenti deve essere o prevenuto o coordinato. Tracciabilità dello sviluppo. È necessario rappresentare le informazioni relative agli autori del documento ed a coloro che hanno introdotto note e/o apportato modifiche alla configurazione. Rilascio dei documenti. Deve essere tenuta memoria dei documenti che lasciano il sistema o che comunque vengono comunicati all esterno. 400

419 Versioning e collaborazione Il controllo delle versioni Gestione dell ambiente di lavoro. Deve essere possibile svolgere le attività lavorative sia in modo individuale che collettivo. Gestione delle modifiche. Le modifiche devono essere applicate secondo criteri prestabiliti o eventualmente selezionabili tra quelli disponibili. D.2 Il controllo delle versioni La possibilità di memorizzare, creare e registrare la storia di un documento è la caratteristica fondamentale di un sistema per la gestione delle versioni. Tra una modifica e la successiva, l entità assume un certo stato, il quale viene identificato con una versione. La versione di un entità rimane immutabile nel tempo, dato che non può essere ulteriormente modificata. Se l authoring avviene in sequenza, l organizzazione delle versioni è sequenziale, in questo caso si parla di revisioni. Invece se l authoring avviene in parallelo, si parla di diramazioni o branch. Ogni diramazione può convergere verso una nuova versione, la quale ha due o più predecessori (merge). Nel caso in cui una diramazione non converga mai, si dice che ha originato una variante (figura D.2). Revisione 1 2 Revisione Diramazione Variante 3 Diramazione 5 Convergenza 6 Convergenza Revisione Revisione A B C Figura D.2: Rappresentazione della storia delle versioni Solitamente le revisioni sono create dallo stesso autore, mentre le diramazioni avvengono quando l editing è concorrente. Le diramazioni sono necessarie almeno per consentire una temporanea elaborazione locale. Una diramazione consiste in una serie di revisioni che a loro volta possono originare diramazioni. D.3 Modelli di sincronizzazione Le attività concorrenti degli utenti coinvolgono la modifica delle configurazioni. Dovrà quindi esistere un meccanismo di sincronizzazione delle risorse capace di garantirne la consistenza e di dare una visione il più possibile unificata e coerente, valida per tutti gli utenti. I possibili modelli di sincronizzazione, 401

420 Versioning e collaborazione Modelli di sincronizzazione descritti in [Fei91], sono: checkout/checkin, composizione, lunghe transazioni e change set. D.3.1 Checkout/Checkin I documenti sono memorizzati sotto forma di file in un repository. I file non sono leggibili o modificabili direttamente, se non prima che il checkout venga applicato. Effettuare il checkout significa che i file vengono copiati nell area di lavoro dell utente (directory locale) e che gli originali nel repository vengono posti in stato di lock. Il lock previene il checkout di altri utenti. Quando il file subisce il checkin le modifiche apportate in locale vengono integrate nel repository generando una nuova versione, inoltre viene rilasciato il lock sul documento di origine. Il tagging è l operazione che serve per etichettare, con un nome simbolico, le versioni dei file appartenenti ad una data configurazione. Questo permette, successivamente, l operazione di recupero delle versioni dei file associate a tale configurazione. Sarà possibile trovare ulteriori dettagli su questo meccanismo in seguito, dove verrà descritto il sistema RCS (paragrafo D.7). Uno dei vantaggi di questo modello è che risulta estremamente semplice sia da implementare in sistemi di vario tipo che da capire da parte dell utilizzatore. Il principale rovescio della medaglia è che il meccanismo di locking penalizza il lavoro a più mani implementando il paradigma turn-taking (paragrafo D.0.3, pagina 397). D.3.2 Composizione La composizione è una estensione del modello checkout/checkin rispetto al quale aggiunge il supporto esplicito alla gestione delle configurazioni, che, in questo caso, sono entità note al sistema di gestione delle versioni. Per quanto riguarda la gestione del repository, delle fasi di checkout e di checkin, del concetto di directory di lavoro locale e del concetto di sincronizzazione tramite locking, il modello è del tutto simile a quello precedente. La necessità di introdurre un modello più evoluto del checkout/checkin è dettata dal fatto che il tagging può non essere sufficiente per recuperare una configurazione. Questo perché le configurazioni hanno natura dinamica in quanto la loro struttura può variare nel tempo. Inoltre l utente potrebbe essere interessato ad accedere ad un sottoinsieme del sistema, operazione possibile solo se il modello è in grado di stabilire se una data entità appartiene o meno al sottoinsieme di interesse, il che equivale a richiedere che esso sia in grado di comprendere la struttura del sistema. In questo caso, fissato l insieme dei file presi in carico dal sistema di versioning (tutti i file che sono stati interessati da una o più operazioni di checkin), occorre definire un meccanismo che permetta, per prima cosa, di selezionare quali file appartengono alla configurazione di interesse e, successivamente, in quale versione. Considerando che un sistema può essere definito come un insieme di sottosistemi, i quali a loro volta possono essere scomposti fino al raggiungimento di entità non ulteriormente divisibili, è semplice descrivere tale meccanismo in termini ricorsivi. La definizione di una configurazione, pertanto, avviene in due passi: 402

421 Versioning e collaborazione Modelli di sincronizzazione 1. tramite un opportuno modello del sistema vengono selezionati i documenti che devono essere inclusi nella configurazione; 2. vengono stabilite le regole per determinare la versione di ogni documento incluso. D.3.3 Transazioni estese nel tempo Questo modello si presta ad essere adottato quando lo sviluppo dell intero sistema coinvolge molti utenti e procede per integrazione di modifiche che possono essere anche di grande entità. Ogni utente dispone di un area di lavoro personale per creare le proprie modifiche e solo ad operazioni concluse provvede ad aggiornare l area di lavoro comune. Area di lavoro condivisa Area di lavoro personale A Area di lavoro personale B Figura D.3: Paradigma di interazione I singoli file possono essere gestiti con il modello checkout/checkin e il ciclo canonico di lavoro prevede la copia, la modifica e l aggiornamento dei dati. Cicli di questo tipo, nel contesto dei database, sono noti con il nome di lunga transazione e questo fatto ha dato origine al nome del modello. In figura D.3 è riportato uno scenario, abbastanza generico, che può presentarsi durante l uso di CM che basano il loro principio di funzionamento su questo modello (ad esempio CVS e Subversion descritti, rispettivamente, nel paragrafo D.8 e nel paragrafo D.9). Gli utenti A e B aggiornano il proprio ambiente di lavoro locale (fasi 1 e 2). A apporta nel proprio ambiente di lavoro modifiche che, a loro volta, possono essere gestite tramite un CM locale e B fa altrettanto. Quindi A decide di aggiornare l ambiente di lavoro condiviso: siccome l ultima versione presente nell area condivisa coincide con quella che l utente A ha utilizzato per apportare le modifiche, l integrazione è immediata (passo 3). L utente B decide di integrare le proprie modifiche (passo 4). Il sistema rileva che la copia presente nell area comune e quella utilizzata da B come base di partenza per le proprie modifiche differiscono, conseguentemente il sistema impedisce a B di portare a termine l operazione. L utente B è obbligato ad aggiornare la propria copia locale per integrare le modifiche più recenti apportate al sistema, in questo caso quelle apportate da A (passo 5). In questa fase B deve, nel caso 403

422 Versioning e collaborazione Modelli di sincronizzazione si fossero presentati, risolvere i conflitti, ovvero aggiornare le eventuali parti del sistema modificate sia da lui che da altri sviluppatori. Solo a questo punto B potrà integrare le proprie modifiche nella copia condivisa (passo 6). Il modello è da considerarsi ottimistico in quanto non prevede mai il blocco del lavoro concorrente. È sempre possibile creare nuovi ambienti di sviluppo personali (paralleli a quelli esistenti) sui quali non è possibile evitare, preventivamente, la nascita di conflitti. Fortunatamente i dati derivanti da vari anni di esperienza nel settore dei CM evidenziano che i casi in cui la risoluzione dei conflitti è difficoltosa risultano molto rari. Il modello può essere generalizzato per prevedere che l area di lavoro locale possa essere utilizzata contemporaneamente da più sviluppatori e, in tal caso, occorre gestirne l accesso concorrente con un CM specifico. D.3.4 Change set Questo modello permette di gestire i cambiamenti logici del documento. Ad esempio, nello sviluppo di software, un cambiamento logico potrebbe essere la correzione di un bug oppure l aggiunta di una nuova funzionalità nel programma. Queste operazioni richiedono la modifica di alcuni file ed eventualmente varie modifiche, in sezioni diverse, dello stesso file. È importante mantenere l informazione che tutte le modifiche sono correlate e finalizzate al raggiungimento del medesimo cambiamento logico. Il mantenimento di tali corrispondenze è alla base del modello (la filosofia è la stessa dell approccio anatomico descritto nel paragrafo D.0.3 a pagina 396). In questo modello le versioni sono organizzate partendo da un insieme di configurazioni predeterminate, utilizzate come base di partenza, rispetto alle quali vengono aggiunti un certo numero di cambiamenti logici non correlati. Ogni aggiunta genera una nuova configurazione. Il meccanismo che gestisce l aggiunta dei cambiamenti logici fa sì che due cambiamenti logici mutuamente esclusivi non vengano applicati contemporaneamente oppure che, qualora alcuni cambiamenti ne richiedano altri, questi ultimi debbano essere applicati per primi. Questo modello viene tipicamente utilizzato nella fase di manutenzione dei sistemi operativi che sono organizzati in release con un largo numero di patch. Il modello incoraggia una strategia conservativa di integrazione delle modifiche e, in ogni caso, non ottimistica nel senso che forza l integrazione solo quando è realmente necessaria. Sotto certi punti di vista il modello change set è simile al modello basato sulle transazioni estese nel tempo. La differenza sostanziale è che nel modello basato sulle transazioni estese nel tempo la sequenza con cui vengono integrate le modifiche è la stessa sequenza con cui vengono effettuate le transazioni. Nel modello change set questo vincolo è meno rigido in quanto è possibile integrare le modifiche in qualunque ordine (a patto di rispettare gli eventuali vincoli). Il modello change set è vantaggioso nella gestione di sistemi con un grande numero di varianti (come i già citati sistemi operativi) in quanto garantisce una maggiore flessibilità permettendo di creare tutte le permutazioni possibili 404

423 Versioning e collaborazione Modelli di versioning di configurazioni (vincoli permettendo). Lo svantaggio è che può essere difficile distinguere quali sono le configurazioni realmente utili dalle altre. D.4 Modelli di versioning Un modello per il configuration management (paragrafo D.1 a pagina 399) definisce gli oggetti che devono essere trattati, il loro identificativo, la loro organizzazione, le operazioni per creare nuove versioni e riceverle. Molti modelli assumono che esista una netta separazione fra come essi gestiscono le informazioni atomiche (o elementari, che non possono essere ulteriormente scisse) e l eventuale concetto di composizione che può esistere fra le stesse. In questi modelli le informazioni atomiche vengono versionate individualmente e, andando a considerare tutte le informazioni contemporaneamente, il numero delle possibili combinazioni delle versioni e/o varianti è solitamente molto elevato e, normalmente, non tutte le combinazioni sono significative. Uno dei problemi fondamentali che si incontra quando si ha a che fare con le configurazioni è che, anche in presenza di un limitato numero di componenti, ognuna con le proprie versioni e varianti, il numero di combinazioni possibili (e quindi il numero di configurazioni possibili) può essere molto grande. Da un punto di vista matematico cresce esponenzialmente con il numero delle componenti e delle versioni e, nei reali contesti applicativi, risulta impossibile gestire le configurazioni manualmente. Questo obbliga ogni modello a dover affrontare tale problema. Esistono due categorie di modelli di versioning: versioning intensionale e versioning estensionale. D.4.1 Modello intensionale Molti modelli e CM attuali si basano su un sistema che viene chiamato versioning intensionale delle relazioni strutturali per tenere sotto controllo il problema dell esplosione esponenziale della complessità. Questo approccio si basa sulla formulazione di regole di selezione che vengono usate per scegliere la particolare variante o versione di una determinata informazione atomica. Spesso queste regole vengono calcolate su richiesta, quando sorge la necessità di accedere all informazione atomica per la visualizzazione o la modifica. Sebbene questo approccio permetta di ridurre la complessità del problema di selezione delle varie versioni, ha alcuni inconvenienti: la rappresentazione della struttura è indiretta, impressa nella definizione delle regole stesse. Per scoprire quali informazioni atomiche, e in quali versioni, costituiscono una certa entità, non c è altra strada se non quella di applicare tutte le regole necessarie ed analizzare il risultato ottenuto; è molto complesso confrontare entità diverse in base alle informazioni atomiche che le costituiscono ed alle versioni in cui compaiono. Questo perché occorre applicare tutte le regole necessarie per entrambe le entità e confrontare i risultati ottenuti; 405

424 Versioning e collaborazione Modelli di versioning la consistenza è difficile da garantire perché alcuni errori nelle regole potrebbero rimanere latenti per molto tempo e manifestarsi solo con la creazione di una nuova versione di qualche informazione atomica che genera una struttura non valida. Come conseguenza non c è la garanzia che un dato insieme di regole permetta di ottenere lo stesso insieme di informazioni atomiche, nelle stesse versioni se applicate in istanti di tempo diversi. Questo inconveniente è reale e noto, tanto è vero che nello sviluppo del software è uso comune salvare i sorgenti relativi a versioni di particolare importanza (come le major release) al di fuori del sistema di versioning per essere certi che in qualunque istante futuro possa essere possibile ottenere i sorgenti corretti relativi alla versione di interesse con probabilità di errore nulla; il tagging prevede l uso di etichette da applicare individualmente ad ogni file per la memorizzazione della relativa versione. Sfortunatamente questo è un meccanismo primitivo in quanto non c è nessuna garanzia che queste etichette non vengano modificate per errore (o in modo fraudolento). Questo non permette di mettere direttamente in relazione versioni diverse l una con l altra oppure di calcolare le differenze fra di esse; le regole possono includere facilitazioni per l accesso a particolari versioni di un informazione atomica come la Ultima (che cambia ogni volta). Regole come questa generano ogni volta risultati diversi. Questo meccanismo può essere visto come un modo per limitare gli effetti legati al problema della crescita esponenziale della complessità, ma rende più difficoltosa la tracciabilità in quanto è impossibile garantire che lo stesso risultato venga ottenuto applicando le stesse regole in istanti di tempo diversi. D.4.2 Modello estensionale Nel versioning estensionale tutte le versioni della stessa entità sono singolarmente identificabili ed appartengono ad un insieme numerabile. L utente ottiene la versione V j, effettua le modifiche e condivide con gli altri la nuova versione V j+1. Tra V j e V j+1 esiste una relazione di derivazione. Una data versione può essere recuperata in tempi successivi, in modo identico a come è stata creata. Le versioni della stessa entità possono essere confrontate e relazionate attraverso l ordinamento parziale della relazione di derivazione. Le versioni e le relazioni sono tipicamente rappresentate con un grafo simile al quello di figura D.2 (a pagina 401). D.4.3 Valutazione dei modelli Si chiamano sistemi basati sulle variazioni quelli che si focalizzano sulle differenze fra due versioni diverse di una data informazione invece che sulle versioni stesse. Un vantaggio di questo meccanismo è che le differenze possono essere combinate anche in molti modi che non corrispondono alle versioni dei sistemi basati sullo stato (nei quali l attenzione viene concentrata proprio sulle singole versioni e non sulle differenze fra le stesse) in quanto è possibile scegliere anche 406

425 Versioning e collaborazione Modelli di versioning modi non previsti durante la fase di creazione delle singole differenze. Le combinazioni ammissibili non sono tutte quelle possibili (alcune differenze possono essere legate ad altre), ma la differenza rispetto ai sistemi basati sullo stato è comunque notevole (vedi il modello Change set, paragrafo D.3.4). Questo perché tutte le versioni distinte discriminate dai sistemi basati sullo stato, possono essere ottenute attraverso un banale meccanismo di fusione fra la versione iniziale e la sequenza ordinata di differenze prese in esame in questi sitemi che è solo una delle possibili permutazioni. Una specifica versione di una informazione atomica viene generata attraverso il meccanismo di fusione, appena citato, ogni volta che serve. Nei sistemi basati sulle variazioni questa operazione viene effettuata attraverso regole ben precise ovvero viene usato versioning intensionale anche per le entità atomiche. Nei sistemi basati sulle variazioni il numero di possibili versioni di ogni entità atomica è elevato e, conseguentemente, il numero delle combinazioni possibili fra le varie versioni delle varie entità che possono dar vita a configurazioni è enorme. Il problema della complessità è ancora più evidente in questi sistemi. Nei sistemi esistenti viene affrontato tramite versioning intensionale e in generale valgono tutte le considerazioni riportate precedentemente. Si chiamano sistemi basati sullo stato quelli che usano versioning estensionale quando hanno a che fare con entità atomiche, pertanto, per queste ultime, tutte le possibili versioni vengono rappresentate esplicitamente. Tali versioni possono, per esempio, essere rappresentate in un grafo e una data versione può essere individuata univocamente in ogni momento una volta fissato il cammino nel grafo. Le versioni delle entità possono essere confrontate e messe in relazione le une con le altre grazie ad una relazione parziale di derivazione. I problemi relativi all uso del versioning intensionale, in questo caso, non si verificano per le entità atomiche in quanto per esse viene utilizzato il versioning estensionale. Una critica fondamentale ai sistemi basati sullo stato è che questi offrono meccanismi molto diversi per trattare le entità atomiche e le relazioni strutturali. Sfortunatamente questo porta ad una proliferazione di concetti senza risolvere i problemi del versioning intensionale in quanto lo si ritrova per la gestione degli aspetti strutturali. D.4.4 Una nuova alternativa: UEVM I sistemi tradizionali, sia basati sullo stato che sulle variazioni, si comportano in modo simile (versioning intensionale) per la gestione degli aspetti strutturali. Nel paragrafo successivo verrà descritto il modello Unified Extensional Versioning Model (UEVM ). Questo modello rappresenta un nuovo approccio che permette di utilizzare versioning esplicito anche per le relazioni strutturali. Viene mostrato come viene minimizzato il problema dell esplosione della complessità e come risolve i problemi relativi al versioning intensionale per le relazioni strutturali. Infine ha il vantaggio di offrire un approccio unificato sia per il versioning delle entità atomiche che per le relazioni strutturali. 407

426 Versioning e collaborazione Unified Extensional Versioning Model Versioning Intensionale Versioning Estensionale Entità atomiche (file) Sistemi basati sulle variazioni Sistemi basati sullo stato o su UEVM Configurazioni Sistemi basati sulle variazioni o sullo stato Sistemi basati su UEVM Tabella D.2: Approcci di versioning adottati dai CM sui vari tipi di entità D.5 Unified Extensional Versioning Model Unified Extensional Versioning Model (UEVM) è un nuovo approccio che tratta allo stesso modo i documenti e le configurazioni. Nell ambito della ricerca sono state realizzate alcune implementazioni parziali e/o prototipi basati su tale modello: COOP/Orm: ambiente di programmazione multiutente; CoEd: editor collaborativo; Ragnarok: tool per lo sviluppo di architetture software. UEVM definisce un proprio modello per il documento sul quale stabilisce i criteri per il versioning. Nella paragrafo successivo verrà descritto il modello adottato [ABCM99]. D.5.1 Il modello Il modello del documento Il documento è un entità strutturata la cui struttura può essere definita, in modo molto conveniente, con la grammatica riportata in tabella D.3. Sostanzialmente il documento è una struttura gerarchica, ad albero. Eventuali legami fra documenti distinti vengono modellati tramite il concetto di link. Il termine documento è da intendersi nel senso più generale possibile: può essere un file, un dataset contenente qualunque tipo di informazione, un testo in italiano, in inglese, eccetera. Di seguito viene introdotto il significato che ha ogni nodo del modello UEVM, in relazione alla struttura del documento: D: rappresentazione astratta del documento. È il simbolo iniziale della grammatica (assioma). A: albero. È un simbolo astratto, non terminale, che quindi non compare nella stringa dei terminali che rappresenta il documento. Il nome del simbolo non è stato scelto casualmente in quanto, a partire da ogni nodo di tipo A, la grammatica produce un albero che, oltre ad essere proprio della sequenza delle produzioni, modella anche la struttura del documento. 408

427 Versioning e collaborazione Unified Extensional Versioning Model D ::= A A ::= C L N C ::= A*[ dati ] L ::= nome - ver. N ::= dati D: documento. Nodo astratto non terminale. A: albero. Nodo astratto non terminale. C: composizione. Nodo concreto, produzione. L: link. Nodo concreto, produzione. N: informazione atomica. Nodo concreto, produzione. Tabella D.3: Grammatica che definisce la struttura del documento N: nodi concreti, terminali, nei quali avviene l archiviazione delle informazioni proprie del documento. Possono contenere codice sorgente, pagine web, immagini, filmati, file eseguibili oppure qualunque altra informazione che non abbia a che fare con il modello del documento. Nodi differenti possono contenere informazioni di tipo diverso: il modello supporta nativamente documenti costituiti da informazioni di tipo eterogeneo. L: link, rappresentano relazioni arbitrarie fra documenti o parti di essi. Il nome è l informazione che serve per identificare univocamente il documento e ver. è la particolare versione dello stesso alla quale il link si riferisce. Si pensi, per esempio, ad un riferimento bibliografico. Il nome potrebbe essere l insieme delle informazioni: nome e cognome dell autore; titolo dell opera; casa editrice. La versione potrebbe essere rappresentata dall edizione. Un link con queste caratteristiche permette di identificare univocamente la risorsa di interesse lasciando le due entità (documento nel quale compare la voce in bibliografia e libro a cui fa riferimento) del tutto indipendenti. Il libro può essere aggiornato (nuove edizioni) senza pregiudicare la comprensione del documento che lo riferisce. Questo perché il lettore può comunque accedere alla versione esatta del libro che l autore del documento ha utilizzato per la stesura dello stesso. L autore del documento può, a sua volta, aggiornarlo e, se lo ritiene opportuno, modificare la bibliografia in modo da riferire l ultima versione del libro, come una qualunque altra. C: relazioni di composizione fra l intero documento e le parti di esso. Il concetto di composizione è quello che dà vita alle relazioni genitore-figlio nell albero del documento. Si pensi alle relazioni che si hanno fra un libro e l insieme dei capitoli che lo costituiscono, fra un capitolo e l insieme di paragrafi che lo costituiscono, eccetera. Queste relazioni trasformano un insieme piatto 1 di informazioni in un entità strutturata. In un libro, se cambia una frase, cambia il paragrafo che la contiene e cambia anche 1 La struttura gerarchica libro capitoli paragrafi..., è astratta e prettamente di convenienza, il libro, di fatto, è una successione di parole. 409

428 Versioning e collaborazione Unified Extensional Versioning Model il capitolo contenente il paragrafo. In ultima analisi cambia tutto il libro. Questo tipo di relazione è ben diverso dal collegamento modellato attraverso i nodi di tipo L descritto in precedenza. D D A D A C D A [data] A A D A A C [data] A N D A [data] D [data] A A N [data] A L A N N [data] L N Figura D.4: Esempi in riferimento alla grammatica Documenti di tipo tradizionale, ovvero che non supportano internamente informazioni strutturate e collegamenti verso altri documenti, possono essere inquadrati nel modello: sono schematizzabili tramite un unico nodo di tipo N. Un esempio di applicazione della grammatica, che permette di vedere come questa generi un documento strutturato ad albero, è riportato in figura D.4: l assioma della grammatica è D, il documento; la prima produzione genera A: questo risultato sottolinea il fatto che il documento è strutturato come un albero; la seconda produzione, a partire da A, genera C (avrebbe potuto generare anche un nodo di tipo N oppure L): l entità astratta albero ha C come radice; la produzione seguente, applicata a C, permette, opzionalmente 2, di associargli dei dati ed un numero di figli che va da zero a infinito 3. I figli, a loro volta, sono strutturati ad albero e, nell esempio, sono due; le produzioni associate a tali alberi generano un nodo C ed un nodo N; 2 L opzionalità è indicata tramite parentesi quadre. 3 Come per le espressioni regolari: il simbolo asterisco indica una qualunque quantità fra zero ed infinito, estremi inclusi. 410

B.P.S. Business Process Server ALLEGATO C10

B.P.S. Business Process Server ALLEGATO C10 B.P.S. Business Process Server ALLEGATO C10 REGIONE BASILICATA DIPARTIMENTO PRESIDENZA DELLA GIUNTA REGIONALE UFFICIO SISTEMA INFORMATIVO REGIONALE E STATISTICA Via V. Verrastro, n. 4 85100 Potenza tel

Dettagli

Indice generale. OOA Analisi Orientata agli Oggetti. Introduzione. Analisi

Indice generale. OOA Analisi Orientata agli Oggetti. Introduzione. Analisi Indice generale OOA Analisi Orientata agli Oggetti Introduzione Analisi Metodi d' analisi Analisi funzionale Analisi del flusso dei dati Analisi delle informazioni Analisi Orientata agli Oggetti (OOA)

Dettagli

Presentazione di Cedac Software

Presentazione di Cedac Software Agenda Presentazione di Cedac Software SOA ed ESB Analisi di un caso studio Esempi Q&A Presentazione di Cedac Software 1 2 Presentazione di Cedac Software S.r.l. Divisione Software Azienda nata nel 1994

Dettagli

E.S.B. Enterprise Service Bus ALLEGATO C11

E.S.B. Enterprise Service Bus ALLEGATO C11 E.S.B. Enterprise Service Bus ALLEGATO C11 REGIONE BASILICATA DIPARTIMENTO PRESIDENZA DELLA GIUNTA REGIONALE UFFICIO SISTEMA INFORMATIVO REGIONALE E STATISTICA Via V. Verrastro, n. 4 85100 Potenza tel

Dettagli

Università degli Studi di Napoli Federico II Facoltà di Ingegneria Corso di Laurea Specialistica in Ingegneria Informatica.

Università degli Studi di Napoli Federico II Facoltà di Ingegneria Corso di Laurea Specialistica in Ingegneria Informatica. Università degli Studi di Napoli Federico II Facoltà di Ingegneria Corso di Laurea Specialistica in Ingegneria Informatica Corso di Sistemi Distribuiti Prof. Stefano Russo Caratterizzazionedei SistemiDistribuiti

Dettagli

SISTEMI E RETI 4(2) 4(2) 4(2) caratteristiche funzionali

SISTEMI E RETI 4(2) 4(2) 4(2) caratteristiche funzionali CL AS SE INFORMATICA 6(3) 6(4) - 6(4) SISTEMI E RETI 4(2) 4(2) 4(2) TECNOLOGIE E PROGETTAZIONE DI SISTEMI INFORMATICI E DI TELECOMUNICAZIONI COMPETENZE 3 Essere in grado di sviluppare semplici applicazioni

Dettagli

Università Politecnica delle Marche. Progetto Didattico

Università Politecnica delle Marche. Progetto Didattico Università Politecnica delle Marche Facoltà di Ingegneria Corso di Laurea in Ingegneria Informatica e dell Automazione Sede di Ancona Anno Accademico 2011-2012 Corso di Tecnologie WEB Docente prof. Alessandro

Dettagli

Reingegnerizzazione di un Content Management System verso l accessibilità secondo la normativa italiana

Reingegnerizzazione di un Content Management System verso l accessibilità secondo la normativa italiana Università degli Studi di Bologna Sede di Cesena FACOLTÀ À DI SCIENZE MATEMATICHE FISICHE E NATURALI Corso di Laurea in Scienze dell Informazione Reingegnerizzazione di un Content Management System verso

Dettagli

SIRED Sistema informativo di raccolta ed elaborazione dati sul movimento turistico

SIRED Sistema informativo di raccolta ed elaborazione dati sul movimento turistico SIRED Sistema informativo di raccolta ed elaborazione dati sul movimento turistico Il sistema della Regione Autonoma della Sardegna per la raccolta, gestione ed elaborazione di dati statistici sul turismo

Dettagli

Le fattispecie di riuso

Le fattispecie di riuso Le fattispecie di riuso Indice 1. PREMESSA...3 2. RIUSO IN CESSIONE SEMPLICE...4 3. RIUSO CON GESTIONE A CARICO DEL CEDENTE...5 4. RIUSO IN FACILITY MANAGEMENT...6 5. RIUSO IN ASP...7 1. Premessa Poiché

Dettagli

Politica per la Sicurezza

Politica per la Sicurezza Codice CODIN-ISO27001-POL-01-B Tipo Politica Progetto Certificazione ISO 27001 Cliente CODIN S.p.A. Autore Direttore Tecnico Data 14 ottobre 2014 Revisione Resp. SGSI Approvazione Direttore Generale Stato

Dettagli

Concetti di base di ingegneria del software

Concetti di base di ingegneria del software Concetti di base di ingegneria del software [Dalle dispense del corso «Ingegneria del software» del prof. A. Furfaro (UNICAL)] Principali qualità del software Correttezza Affidabilità Robustezza Efficienza

Dettagli

PROGRAMMAZIONE E GESTIONE DI UN PROGETTO DI SERVIZIO SOCIALE

PROGRAMMAZIONE E GESTIONE DI UN PROGETTO DI SERVIZIO SOCIALE PROGRAMMAZIONE E GESTIONE DI UN PROGETTO DI SERVIZIO SOCIALE A.S. Dott.ssa Carmen Prizzon Il progetto Operazione complessa unica e di durata limitata rivolta a produrre un risultato specifico attraverso

Dettagli

2. Correttezza degli algoritmi e complessità computazionale.

2. Correttezza degli algoritmi e complessità computazionale. TEMI DI INFORMATICA GIURIDICA (attenzione: l elenco di domande non pretende di essere esaustivo!) L informatica giuridica 1. Illustrare i principali ambiti di applicazione dell informatica giuridica. 2.

Dettagli

Progetto Atipico. Partners

Progetto Atipico. Partners Progetto Atipico Partners Imprese Arancia-ICT Arancia-ICT è una giovane società che nasce nel 2007 grazie ad un gruppo di professionisti che ha voluto capitalizzare le competenze multidisciplinari acquisite

Dettagli

Infrastruttura di produzione INFN-GRID

Infrastruttura di produzione INFN-GRID Infrastruttura di produzione INFN-GRID Introduzione Infrastruttura condivisa Multi-VO Modello Organizzativo Conclusioni 1 Introduzione Dopo circa tre anni dall inizio dei progetti GRID, lo stato del middleware

Dettagli

Telerilevamento e GIS Prof. Ing. Giuseppe Mussumeci

Telerilevamento e GIS Prof. Ing. Giuseppe Mussumeci Corso di Laurea Magistrale in Ingegneria per l Ambiente e il Territorio A.A. 2014-2015 Telerilevamento e GIS Prof. Ing. Giuseppe Mussumeci Strutture di dati: DB e DBMS DATO E INFORMAZIONE Dato: insieme

Dettagli

Considera tutti i requisiti funzionali (use cases) NON deve necessariamente modellare i requisiti non funzionali

Considera tutti i requisiti funzionali (use cases) NON deve necessariamente modellare i requisiti non funzionali Corso di Laurea Specialistica in Ingegneria Informatica Corso di Ingegneria del Software A. A. 2008 - Progettazione OO E. TINELLI Punto di Partenza Il modello di analisi E una rappresentazione minima del

Dettagli

Riepilogo delle modifiche di PA-DSS dalla versione 2.0 alla 3.0

Riepilogo delle modifiche di PA-DSS dalla versione 2.0 alla 3.0 Settore delle carte di pagamento (PCI) Standard di protezione dei dati per le applicazioni di pagamento () Riepilogo delle modifiche di dalla versione 2.0 alla 3.0 Novembre 2013 Introduzione Il presente

Dettagli

FORMAZIONE AVANZATA IL CONSERVATORE DEI DOCUMENTI DIGITALI

FORMAZIONE AVANZATA IL CONSERVATORE DEI DOCUMENTI DIGITALI FORMAZIONE AVANZATA IL CONSERVATORE DEI DOCUMENTI DIGITALI 1. Premessa Con raccomandazione del 27/10/2011 - digitalizzazione e accessibilità dei contenuti culturali e sulla conservazione digitale - la

Dettagli

Software per Helpdesk

Software per Helpdesk Software per Helpdesk Padova - maggio 2010 Antonio Dalvit - www.antoniodalvit.com Cosa è un helpdesk? Un help desk è un servizio che fornisce informazioni e assistenza ad utenti che hanno problemi nella

Dettagli

Reti di Telecomunicazione Lezione 6

Reti di Telecomunicazione Lezione 6 Reti di Telecomunicazione Lezione 6 Marco Benini Corso di Laurea in Informatica marco.benini@uninsubria.it Lo strato di applicazione protocolli Programma della lezione Applicazioni di rete client - server

Dettagli

Sistemi informativi secondo prospettive combinate

Sistemi informativi secondo prospettive combinate Sistemi informativi secondo prospettive combinate direz acquisti direz produz. direz vendite processo acquisti produzione vendite INTEGRAZIONE TRA PROSPETTIVE Informazioni e attività sono condivise da

Dettagli

Situation AWare Security Operations Center (SAWSOC) Topic SEC-2012.2.5-1 Convergence of physical and cyber security. Relatore: Alberto Bianchi

Situation AWare Security Operations Center (SAWSOC) Topic SEC-2012.2.5-1 Convergence of physical and cyber security. Relatore: Alberto Bianchi Situation AWare Security Operations Center (SAWSOC) Relatore: Alberto Bianchi Topic SEC-2012.2.5-1 Convergence of physical and cyber security Coordinatrice di Progetto: Anna Maria Colla annamaria.colla@selexelsag.com

Dettagli

Un approccio innovativo per il delivery di servizi in infrastrutture di nomadic computing

Un approccio innovativo per il delivery di servizi in infrastrutture di nomadic computing Un approccio innovativo per il delivery di servizi in infrastrutture di nomadic computing Relatore Prof. Ing. Stefano Russo Correlatore Ing. Domenico Cotroneo Candidato Armando Migliaccio matr. 41/2784

Dettagli

Come leggere ed interpretare la letteratura scientifica e fornire al pubblico informazioni appropriate sui farmaci

Come leggere ed interpretare la letteratura scientifica e fornire al pubblico informazioni appropriate sui farmaci Come leggere ed interpretare la letteratura scientifica e fornire al pubblico informazioni appropriate sui farmaci I motori di ricerca in internet: cosa sono e come funzionano Roberto Ricci, Servizio Sistema

Dettagli

La gestione di un calcolatore. Sistemi Operativi primo modulo Introduzione. Sistema operativo (2) Sistema operativo (1)

La gestione di un calcolatore. Sistemi Operativi primo modulo Introduzione. Sistema operativo (2) Sistema operativo (1) La gestione di un calcolatore Sistemi Operativi primo modulo Introduzione Augusto Celentano Università Ca Foscari Venezia Corso di Laurea in Informatica Un calcolatore (sistema di elaborazione) è un sistema

Dettagli

Introduzione alle basi di dati. Gestione delle informazioni. Gestione delle informazioni. Sistema informatico

Introduzione alle basi di dati. Gestione delle informazioni. Gestione delle informazioni. Sistema informatico Introduzione alle basi di dati Introduzione alle basi di dati Gestione delle informazioni Base di dati Modello dei dati Indipendenza dei dati Accesso ai dati Vantaggi e svantaggi dei DBMS Gestione delle

Dettagli

IT Cloud Service. Semplice - accessibile - sicuro - economico

IT Cloud Service. Semplice - accessibile - sicuro - economico IT Cloud Service Semplice - accessibile - sicuro - economico IT Cloud Service - Cos è IT Cloud Service è una soluzione flessibile per la sincronizzazione dei file e la loro condivisione. Sia che si utilizzi

Dettagli

7. Architetture Software

7. Architetture Software 7. Architetture Software progettare la struttura Andrea Polini Ingegneria del Software Corso di Laurea in Informatica (Ingegneria del Software) 7. Architetture Software 1 / 20 Scopo della fase di design

Dettagli

Generazione Automatica di Asserzioni da Modelli di Specifica

Generazione Automatica di Asserzioni da Modelli di Specifica UNIVERSITÀ DEGLI STUDI DI MILANO BICOCCA FACOLTÀ DI SCIENZE MATEMATICHE FISICHE E NATURALI Corso di Laurea Magistrale in Informatica Generazione Automatica di Asserzioni da Modelli di Specifica Relatore:

Dettagli

Strategie di system integration per l interoperabilità di sistemi eterogenei di Fascicolo Sanitario Elettronico

Strategie di system integration per l interoperabilità di sistemi eterogenei di Fascicolo Sanitario Elettronico Consiglio Nazionale delle Ricerche Istituto di Calcolo e Reti ad Alte Prestazioni Strategie di system integration per l interoperabilità di sistemi eterogenei di Fascicolo Sanitario Elettronico Mario Ciampi

Dettagli

esales Forza Ordini per Abbigliamento

esales Forza Ordini per Abbigliamento esales Rel. 2012 Forza Ordini per Abbigliamento Scopo di questo documento è fornire la descrizione di una piattaforma di Raccolta Ordini via Web e la successiva loro elaborazione in ambiente ERP Aziendale.

Dettagli

Università degli Studi di Parma Facoltà di Scienze MM. FF. NN. Corso di Laurea in Informatica. Ingegneria del Software. La fase di Analisi

Università degli Studi di Parma Facoltà di Scienze MM. FF. NN. Corso di Laurea in Informatica. Ingegneria del Software. La fase di Analisi Università degli Studi di Parma Facoltà di Scienze MM. FF. NN. Corso di Laurea in Informatica Ingegneria del Software La fase di Analisi Giulio Destri Ing. del software: Analisi - 1 Scopo del modulo Definire

Dettagli

Business Process Management

Business Process Management Corso di Eccellenza in Business Process Management edizione 2010 Con il patrocinio e la supervisione scientifica del Dipartimento di Informatica dell Università degli Studi di Torino Responsabile scientifico

Dettagli

Addition X DataNet S.r.l. www.xdatanet.com www.xdatanet.com

Addition X DataNet S.r.l. www.xdatanet.com www.xdatanet.com Addition è un applicativo Web che sfrutta le potenzialità offerte da IBM Lotus Domino per gestire documenti e processi aziendali in modo collaborativo, integrato e sicuro. www.xdatanet.com Personalizzazione,

Dettagli

3. Introduzione all'internetworking

3. Introduzione all'internetworking 3. Introduzione all'internetworking Abbiamo visto i dettagli di due reti di comunicazione: ma ce ne sono decine di tipo diverso! Occorre poter far comunicare calcolatori che si trovano su reti di tecnologia

Dettagli

Il glossario della Posta Elettronica Certificata (PEC) Diamo una definizione ai termini tecnici relativi al mondo della PEC.

Il glossario della Posta Elettronica Certificata (PEC) Diamo una definizione ai termini tecnici relativi al mondo della PEC. Il glossario della Posta Elettronica Certificata (PEC) Diamo una definizione ai termini tecnici relativi al mondo della PEC. Avviso di mancata consegna L avviso, emesso dal sistema, per indicare l anomalia

Dettagli

Database. Si ringrazia Marco Bertini per le slides

Database. Si ringrazia Marco Bertini per le slides Database Si ringrazia Marco Bertini per le slides Obiettivo Concetti base dati e informazioni cos è un database terminologia Modelli organizzativi flat file database relazionali Principi e linee guida

Dettagli

Base di dati e sistemi informativi

Base di dati e sistemi informativi Base di dati e sistemi informativi Una base di dati è un insieme organizzato di dati opportunamente strutturato per lo svolgimento di determinate attività La base di dati è un elemento fondamentale per

Dettagli

MANUALE DELLA QUALITA Revisione: Sezione 4 SISTEMA DI GESTIONE PER LA QUALITA

MANUALE DELLA QUALITA Revisione: Sezione 4 SISTEMA DI GESTIONE PER LA QUALITA Pagina: 1 di 5 SISTEMA DI GESTIONE PER LA QUALITA 4.0 SCOPO DELLA SEZIONE Illustrare la struttura del Sistema di Gestione Qualità SGQ dell Istituto. Per gli aspetti di dettaglio, la Procedura di riferimento

Dettagli

Lezione 1. Introduzione e Modellazione Concettuale

Lezione 1. Introduzione e Modellazione Concettuale Lezione 1 Introduzione e Modellazione Concettuale 1 Tipi di Database ed Applicazioni Database Numerici e Testuali Database Multimediali Geographic Information Systems (GIS) Data Warehouses Real-time and

Dettagli

Automazione Industriale (scheduling+mms) scheduling+mms. adacher@dia.uniroma3.it

Automazione Industriale (scheduling+mms) scheduling+mms. adacher@dia.uniroma3.it Automazione Industriale (scheduling+mms) scheduling+mms adacher@dia.uniroma3.it Introduzione Sistemi e Modelli Lo studio e l analisi di sistemi tramite una rappresentazione astratta o una sua formalizzazione

Dettagli

Costruire il futuro il valore delle scelte tecnologiche

Costruire il futuro il valore delle scelte tecnologiche Franco Lenzi Costruire il futuro il valore delle scelte tecnologiche 7 e 8 maggio 2010, Venezia, Hotel Hilton Molino Stucky 1 La strategia tecnologica Gli obiettivi espressi dalle scelta di strategia e

Dettagli

lem logic enterprise manager

lem logic enterprise manager logic enterprise manager lem lem Logic Enterprise Manager Grazie all esperienza decennale in sistemi gestionali, Logic offre una soluzione modulare altamente configurabile pensata per la gestione delle

Dettagli

Una piattaforma per la negoziazione di servizi business to business attraverso la rete Internet

Una piattaforma per la negoziazione di servizi business to business attraverso la rete Internet Università degli Studi di Napoli Federico II Facoltà di Ingegneria Corso di Laurea in Ingegneria Gestionale della Logistica e della Produzione Una piattaforma per la negoziazione di servizi business to

Dettagli

Identificazione documento. Approvazioni. Variazioni DEGLI STUDI DI NAPOLI FEDERICO II. Centro di Ateneo per i Servizi Informativi

Identificazione documento. Approvazioni. Variazioni DEGLI STUDI DI NAPOLI FEDERICO II. Centro di Ateneo per i Servizi Informativi Identificazione documento Titolo Tipo Nome file Livelli di servizio Documentazione SIS_sla_v2 Approvazioni Nome Data Firma Redatto da Pollio 25/11/2010 Revisionato da Barone 14/01/2011 Approvato da Barone

Dettagli

Linux hands-on & hands-off Workshop

Linux hands-on & hands-off Workshop Linux hands-on & hands-off Workshop I workshop Linux hands-on & hands-off sono sessioni di una giornata che distinguono per il taglio volutamente operativo, pensati per mostrare le basi relative al setup

Dettagli

La Pubblica Amministrazione consumatore di software Open Source

La Pubblica Amministrazione consumatore di software Open Source La Pubblica Amministrazione consumatore di software Open Source Dipartimento per l Innovazione e le Tecnologie Paola Tarquini Sommario Iniziative in atto Una possibile strategia per la diffusione del Software

Dettagli

Il modello di gestione delle identità digitali in SPCoop

Il modello di gestione delle identità digitali in SPCoop Il modello di gestione delle identità digitali in SPCoop Francesco Tortorelli Il quadro normativo e regolatorio di riferimento 2 Il codice dell amministrazione digitale (CAD) CAD Servizi Access di services

Dettagli

La piattaforma di lettura targhe intelligente ed innovativa in grado di offrire servizi completi e personalizzati

La piattaforma di lettura targhe intelligente ed innovativa in grado di offrire servizi completi e personalizzati La piattaforma di lettura targhe intelligente ed innovativa in grado di offrire servizi completi e personalizzati Affidabilità nel servizio precisione negli strumenti Chanda LPR Chanda LPR è una piattaforma

Dettagli

EXPLOit Content Management Data Base per documenti SGML/XML

EXPLOit Content Management Data Base per documenti SGML/XML EXPLOit Content Management Data Base per documenti SGML/XML Introduzione L applicazione EXPLOit gestisce i contenuti dei documenti strutturati in SGML o XML, utilizzando il prodotto Adobe FrameMaker per

Dettagli

L archivio di impresa

L archivio di impresa L archivio di impresa Mariella Guercio Università degli studi di Urbino m.guercio@mclink.it Politecnico di Torino, 25 novembre 2011 premessa L archivistica è una disciplina della complessità, aperta, basata

Dettagli

IL MANAGER COACH: MODA O REQUISITO DI EFFICACIA. Nelle organizzazioni la gestione e lo sviluppo dei collaboratori hanno una importanza fondamentale.

IL MANAGER COACH: MODA O REQUISITO DI EFFICACIA. Nelle organizzazioni la gestione e lo sviluppo dei collaboratori hanno una importanza fondamentale. IL MANAGER COACH: MODA O REQUISITO DI EFFICACIA Nelle organizzazioni la gestione e lo sviluppo dei collaboratori hanno una importanza fondamentale. Gestione e sviluppo richiedono oggi comportamenti diversi

Dettagli

Architetture Informatiche. Dal Mainframe al Personal Computer

Architetture Informatiche. Dal Mainframe al Personal Computer Architetture Informatiche Dal Mainframe al Personal Computer Architetture Le architetture informatiche definiscono le modalità secondo le quali sono collegati tra di loro i diversi sistemi ( livello fisico

Dettagli

La Leadership efficace

La Leadership efficace La Leadership efficace 1 La Leadership: definizione e principi 3 2 Le pre-condizioni della Leadership 3 3 Le qualità del Leader 4 3.1 Comunicazione... 4 3.1.1 Visione... 4 3.1.2 Relazione... 4 pagina 2

Dettagli

03. Il Modello Gestionale per Processi

03. Il Modello Gestionale per Processi 03. Il Modello Gestionale per Processi Gli aspetti strutturali (vale a dire l organigramma e la descrizione delle funzioni, ruoli e responsabilità) da soli non bastano per gestire la performance; l organigramma

Dettagli

Prodotto <ADAM DASHBOARD> Release <1.0> Gennaio 2015

Prodotto <ADAM DASHBOARD> Release <1.0> Gennaio 2015 Prodotto Release Gennaio 2015 Il presente documento e' stato redatto in coerenza con il Codice Etico e i Principi Generali del Controllo Interno Sommario Sommario... 2 Introduzione...

Dettagli

Sicurezza nei Web Services: Migrazione dell autenticazone di Web Services da ticket di sessione a WS-Security con token SAML

Sicurezza nei Web Services: Migrazione dell autenticazone di Web Services da ticket di sessione a WS-Security con token SAML Master Universitario di II livello in Interoperabilità Per la Pubblica Amministrazione e Le Imprese Sicurezza nei Web Services: Migrazione dell autenticazone di Web Services da ticket di sessione a WS-Security

Dettagli

Sicurezza dei dati in EGRID

Sicurezza dei dati in EGRID Sicurezza dei dati in EGRID Riccardo Murri riccardo.murri@ictp.trieste.it The Abdus Salam ICTP - p. 1 Cosa intendiamo per sicurezza Sicurezza dei dati è la possibilità di decidere chi legge quali dati

Dettagli

Trasparenza e Tracciabilità

Trasparenza e Tracciabilità Trasparenza e Tracciabilità Il punto di vista delle stazioni appaltanti e le tipologie di strumenti informatici di supporto Dott. Ing. Paolo Mezzetti Ferrara 8 Maggio 2015 Contenuti I Profilo STEP II Il

Dettagli

Progettaz. e sviluppo Data Base

Progettaz. e sviluppo Data Base Progettaz. e sviluppo Data Base! Introduzione ai Database! Tipologie di DB (gerarchici, reticolari, relazionali, oodb) Introduzione ai database Cos è un Database Cos e un Data Base Management System (DBMS)

Dettagli

LA SOLUZIONE. EVOLUTION, con la E LA TECNOLOGIA TRASPARENTE IL SOFTWARE INVISIBILE INVISIBILE ANCHE NEL PREZZO R.O.I. IMMEDIATO OFFERTA IN PROVA

LA SOLUZIONE. EVOLUTION, con la E LA TECNOLOGIA TRASPARENTE IL SOFTWARE INVISIBILE INVISIBILE ANCHE NEL PREZZO R.O.I. IMMEDIATO OFFERTA IN PROVA LE NUOVE ESIGENZE PROLIFERAZIONE DI DOCUMENTI ELETTRONICI / PRATICHE / FASCICOLI ELETTR. DAL WEB DOCUMENTI ATTIVI DOCUMENTI PASSIVI DOCUMENTI OFFICE,FAX,E-MAIL DOCUMENTI PESANTI PROCESSI PESANTI LE NUOVE

Dettagli

Sistemi Operativi II Corso di Laurea in Ingegneria Informatica

Sistemi Operativi II Corso di Laurea in Ingegneria Informatica www.dis.uniroma1.it/~midlab Sistemi Operativi II Corso di Laurea in Ingegneria Informatica Prof. Roberto Baldoni Introduzione OS=Astrazione Dare l illusione all applicazione di memoria infinita, CPU infinita,unico

Dettagli

Basi di dati. Corso di Laurea in Ingegneria Informatica Canale di Ingegneria delle Reti e dei Sistemi Informatici - Polo di Rieti

Basi di dati. Corso di Laurea in Ingegneria Informatica Canale di Ingegneria delle Reti e dei Sistemi Informatici - Polo di Rieti Basi di dati Corso di Laurea in Ingegneria Informatica Canale di Ingegneria delle Reti e dei Sistemi Informatici - Polo di Rieti Anno Accademico 2008/2009 Introduzione alle basi di dati Docente Pierangelo

Dettagli

Turismo Virtual Turismo Virtual Turismo Virtual

Turismo Virtual Turismo Virtual Turismo Virtual Da una collaborazione nata all inizio del 2011 tra le società Annoluce di Torino e Ideavity di Porto (PT), giovani e dinamiche realtà ICT, grazie al supporto della Camera di Commercio di Torino, nasce

Dettagli

Riconoscibilità dei siti pubblici: i domini della Pa e le regole di.gov.it

Riconoscibilità dei siti pubblici: i domini della Pa e le regole di.gov.it Riconoscibilità dei siti pubblici: i domini della Pa e le regole di.gov.it Gabriella Calderisi - DigitPA 2 dicembre 2010 Dicembre 2010 Dominio.gov.it Cos è un dominio? Se Internet è una grande città, i

Dettagli

La Metodologia adottata nel Corso

La Metodologia adottata nel Corso La Metodologia adottata nel Corso 1 Mission Statement + Glossario + Lista Funzionalià 3 Descrizione 6 Funzionalità 2 Schema 4 Schema 5 concettuale Logico EA Relazionale Codice Transazioni In PL/SQL Schema

Dettagli

CHI SIAMO. BeOn è una società di consulenza italiana ad alta specializzazione in ambito di valutazione, sviluppo e formazione delle risorse umane.

CHI SIAMO. BeOn è una società di consulenza italiana ad alta specializzazione in ambito di valutazione, sviluppo e formazione delle risorse umane. www.beon-dp.com Operiamo in ambito di: Sviluppo Assessment e development Center Valutazione e feedback a 360 Formazione Coaching CHI SIAMO BeOn è una società di consulenza italiana ad alta specializzazione

Dettagli

Allegato 2 Modello offerta tecnica

Allegato 2 Modello offerta tecnica Allegato 2 Modello offerta tecnica Allegato 2 Pagina 1 Sommario 1 PREMESSA... 3 1.1 Scopo del documento... 3 2 Architettura del nuovo sistema (Paragrafo 5 del capitolato)... 3 2.1 Requisiti generali della

Dettagli

Fattura elettronica e conservazione

Fattura elettronica e conservazione Fattura elettronica e conservazione Maria Pia Giovannini Responsabile Area Regole, standard e guide tecniche Agenzia per l Italia Digitale Torino, 22 novembre 2013 1 Il contesto di riferimento Agenda digitale

Dettagli

Comune di San Martino Buon Albergo

Comune di San Martino Buon Albergo Comune di San Martino Buon Albergo Provincia di Verona - C.A.P. 37036 SISTEMA DI VALUTAZIONE DELLE POSIZIONI DIRIGENZIALI Approvato dalla Giunta Comunale il 31.07.2012 INDICE PREMESSA A) LA VALUTAZIONE

Dettagli

Appunti di Sistemi Distribuiti

Appunti di Sistemi Distribuiti Appunti di Sistemi Distribuiti Matteo Gianello 27 settembre 2013 1 Indice 1 Introduzione 3 1.1 Definizione di sistema distribuito........................... 3 1.2 Obiettivi.........................................

Dettagli

S i s t e m a d i v a l u t a z i o n e d e l l e p r e s t a z i o n i d e i d i p e n d e n t i

S i s t e m a d i v a l u t a z i o n e d e l l e p r e s t a z i o n i d e i d i p e n d e n t i S i s t e m a d i v a l u t a z i o n e d e l l e p r e s t a z i o n i d e i d i p e n d e n t i P r o d o t t o d a A l b e r t o P a o l i n i G r o s s e t o P a r c h e g g i s r l V e n g o n o p

Dettagli

Architetture Informatiche. Dal Mainframe al Personal Computer

Architetture Informatiche. Dal Mainframe al Personal Computer Architetture Informatiche Dal Mainframe al Personal Computer Architetture Le architetture informatiche definiscono le modalità secondo le quali sono collegati tra di loro i diversi sistemi ( livello fisico

Dettagli

Il servizio di registrazione contabile. che consente di azzerare i tempi di registrazione delle fatture e dei relativi movimenti contabili

Il servizio di registrazione contabile. che consente di azzerare i tempi di registrazione delle fatture e dei relativi movimenti contabili Il servizio di registrazione contabile che consente di azzerare i tempi di registrazione delle fatture e dei relativi movimenti contabili Chi siamo Imprese giovani e dinamiche ITCluster nasce a Torino

Dettagli

Ipertesti e Internet. Ipertesto. Ipertesto. Prof.ssa E. Gentile. a.a. 2011-2012

Ipertesti e Internet. Ipertesto. Ipertesto. Prof.ssa E. Gentile. a.a. 2011-2012 Corso di Laurea Magistrale in Scienze dell Informazione Editoriale, Pubblica e Sociale Ipertesti e Internet Prof.ssa E. Gentile a.a. 2011-2012 Ipertesto Qualsiasi forma di testualità parole, immagini,

Dettagli

Liceo Tecnologico. Indirizzo Informatico e Comunicazione. Indicazioni nazionali per Piani di Studi Personalizzati

Liceo Tecnologico. Indirizzo Informatico e Comunicazione. Indicazioni nazionali per Piani di Studi Personalizzati Indirizzo Informatico e Comunicazione Indicazioni nazionali per Piani di Studi Personalizzati Indirizzo Informatico e Comunicazione Discipline con attività di laboratorio 3 4 5 Fisica 132 Gestione di progetto

Dettagli

Introduzione all Information Retrieval

Introduzione all Information Retrieval Introduzione all Information Retrieval Argomenti della lezione Definizione di Information Retrieval. Information Retrieval vs Data Retrieval. Indicizzazione di collezioni e ricerca. Modelli per Information

Dettagli

Agenti Mobili Intelligenti e Sicurezza Informatica Utilizzare un nuovo paradigma applicativo per la realizzazione di sistemi informatici sicuri.

Agenti Mobili Intelligenti e Sicurezza Informatica Utilizzare un nuovo paradigma applicativo per la realizzazione di sistemi informatici sicuri. Agenti Mobili Intelligenti e Sicurezza Informatica Utilizzare un nuovo paradigma applicativo per la realizzazione di sistemi informatici sicuri. Roma, 25 ottobre 2010 Ing. Antonio Salomè Ing. Luca Lezzerini

Dettagli

Modellazione dei dati in UML

Modellazione dei dati in UML Corso di Basi di Dati e Sistemi Informativi Modellazione dei dati in UML Angelo Montanari Dipartimento di Matematica e Informatica Università degli Studi di Udine Introduzione UML (Unified Modeling Language):

Dettagli

LA FORMAZIONE E LA CONSERVAZIONE DELLA MEMORIA DIGITALE

LA FORMAZIONE E LA CONSERVAZIONE DELLA MEMORIA DIGITALE Prof. Stefano Pigliapoco LA FORMAZIONE E LA CONSERVAZIONE DELLA MEMORIA DIGITALE ANAI, Cagliari 6 marzo 2006 s.pigliapoco@fastnet.it L Amministrazione Pubblica Digitale Il complesso delle norme di recente

Dettagli

Strumenti di modellazione. Gabriella Trucco

Strumenti di modellazione. Gabriella Trucco Strumenti di modellazione Gabriella Trucco Linguaggio di modellazione Linguaggio formale che può essere utilizzato per descrivere (modellare) un sistema Il concetto trova applicazione soprattutto nell

Dettagli

INGEGNERIA DEL SOFTWARE. Prof. Paolo Salvaneschi

INGEGNERIA DEL SOFTWARE. Prof. Paolo Salvaneschi Università di Bergamo Facoltà di Ingegneria Corso di Laurea in Ingegneria Informatica INGEGNERIA DEL SOFTWARE Prof. Paolo Salvaneschi 1 Obiettivi Scopi del corso: - Fornire gli elementi di base della disciplina,

Dettagli

Programma del Corso. Dati e DBMS SQL. Progettazione di una. Normalizzazione

Programma del Corso. Dati e DBMS SQL. Progettazione di una. Normalizzazione Programma del Corso Dati e DBMS DBMS relazionali SQL Progettazione di una base di dati Normalizzazione (I prova scritta) (II prova scritta) Interazione fra linguaggi di programmazione e basi di dati Cenni

Dettagli

CONTENT MANAGEMENT SYSTEM

CONTENT MANAGEMENT SYSTEM CONTENT MANAGEMENT SYSTEM P-2 PARLARE IN MULTICANALE Creare un portale complesso e ricco di informazioni continuamente aggiornate, disponibile su più canali (web, mobile, iphone, ipad) richiede competenze

Dettagli

Allegato 3 Sistema per l interscambio dei dati (SID)

Allegato 3 Sistema per l interscambio dei dati (SID) Sistema per l interscambio dei dati (SID) Specifiche dell infrastruttura per la trasmissione delle Comunicazioni previste dall art. 11 comma 2 del decreto legge 6 dicembre 2011 n.201 Sommario Introduzione...

Dettagli

Applicazioni per l autenticazione Sicurezza nelle reti di TLC - Prof. Marco Listanti - A.A. 2008/2009

Applicazioni per l autenticazione Sicurezza nelle reti di TLC - Prof. Marco Listanti - A.A. 2008/2009 Applicazioni per l autenticazione Kerberos Kerberos Servizio di autenticazione sviluppato dal MIT Fornisce un server di autenticazione centralizzato Basato su crittografia simmetrica (chiave privata) Permette

Dettagli

URI. Introduzione. Pag. 1

URI. Introduzione. Pag. 1 URI Introduzione Gli URI (Universal Resource Indentifier) sono una sintassi usata in WWW per definire i nomi e gli indirizzi di oggetti (risorse) su Internet. Questi oggetti sono considerati accessibili

Dettagli

BASI DI DATI per la gestione dell informazione. Angelo Chianese Vincenzo Moscato Antonio Picariello Lucio Sansone

BASI DI DATI per la gestione dell informazione. Angelo Chianese Vincenzo Moscato Antonio Picariello Lucio Sansone BASI DI DATI per la gestione dell informazione Angelo Chianese Vincenzo Moscato Antonio Picariello Lucio Sansone Libro di Testo 22 Chianese, Moscato, Picariello e Sansone BASI DI DATI per la Gestione dell

Dettagli

Ministero dell istruzione, dell università e della ricerca. Liceo Tecnologico. Indirizzo Informatico, Grafico e Comunicazione

Ministero dell istruzione, dell università e della ricerca. Liceo Tecnologico. Indirizzo Informatico, Grafico e Comunicazione Ministero dell istruzione, dell università e della ricerca Liceo Tecnologico Indirizzo Informatico, Grafico e Comunicazione Percorso Informatico e Comunicazione Indicazioni nazionali per i Piani di Studio

Dettagli

L o. Walter Ambu http://www.japsportal.org. japs: una soluzione agile (www.japsportal.org)

L o. Walter Ambu http://www.japsportal.org. japs: una soluzione agile (www.japsportal.org) L o JAPS: una soluzione Agile Walter Ambu http://www.japsportal.org 1 Lo sviluppo del software Mercato fortemente competitivo ed in continua evoluzione (velocità di Internet) Clienti sempre più esigenti

Dettagli

Università degli Studi "Roma Tre" Dipartimento di Informatica ed automazione. Facoltà di Ingegneria

Università degli Studi Roma Tre Dipartimento di Informatica ed automazione. Facoltà di Ingegneria Università degli Studi "Roma Tre" Dipartimento di Informatica ed automazione Facoltà di Ingegneria Corso di Laurea in Ingegneria Informatica Tesi di Laurea AUTENTICAZIONE PER APPLICAZIONI WEB Relatore

Dettagli

Appendice III. Competenza e definizione della competenza

Appendice III. Competenza e definizione della competenza Appendice III. Competenza e definizione della competenza Competenze degli psicologi Lo scopo complessivo dell esercizio della professione di psicologo è di sviluppare e applicare i principi, le conoscenze,

Dettagli

Piano di gestione della qualità

Piano di gestione della qualità Piano di gestione della qualità Pianificazione della qualità Politica ed obiettivi della qualità Riferimento ad un eventuale modello di qualità adottato Controllo della qualità Procedure di controllo.

Dettagli

Lextel Servizi Telematici per l Avvocatura

Lextel Servizi Telematici per l Avvocatura Lextel Servizi Telematici per l Avvocatura IL PROGETTO 2 Più di un anno fa LEXTEL riceve l incarico da parte della Cassa Nazionale di Previdenza ed Assistenza Forense di iniziare lo studio progettuale

Dettagli

Introduzione all Architettura del DBMS

Introduzione all Architettura del DBMS Introduzione all Architettura del DBMS Data Base Management System (DBMS) Un DBMS è uno strumento per la creazione e la gestione efficiente di grandi quantità di dati che consente di conservarli in modo

Dettagli

WorkFLow (Gestione del flusso pratiche)

WorkFLow (Gestione del flusso pratiche) WorkFLow (Gestione del flusso pratiche) Il workflow è l'automazione di una parte o dell'intero processo aziendale dove documenti, informazioni e compiti vengono passati da un partecipante ad un altro al

Dettagli

QUESTIONARIO 3: MATURITA ORGANIZZATIVA

QUESTIONARIO 3: MATURITA ORGANIZZATIVA QUESTIONARIO 3: MATURITA ORGANIZZATIVA Caratteristiche generali 0 I R M 1 Leadership e coerenza degli obiettivi 2. Orientamento ai risultati I manager elaborano e formulano una chiara mission. Es.: I manager

Dettagli