12.07.2015 Views

InterDataNet: nuove frontiere per l'integrazione e l'elaborazione dei ...

InterDataNet: nuove frontiere per l'integrazione e l'elaborazione dei ...

InterDataNet: nuove frontiere per l'integrazione e l'elaborazione dei ...

SHOW MORE
SHOW LESS

Create successful ePaper yourself

Turn your PDF publications into a flip-book with our unique Google optimized e-Paper software.

UNIVERSITÀ DEGLI STUDI DI FIRENZEFacoltà di IngegneriaDipartimento di Elettronica e TelecomunicazioniDottorato di Ricerca inTelematica e Società dell’Informazione - XX cicloING-INF/05<strong>InterDataNet</strong>: <strong>nuove</strong> <strong>frontiere</strong> <strong>per</strong>l’integrazione e l’elaborazione <strong>dei</strong> datiVisione e progettazione di un modelloinfrastrutturale <strong>per</strong> l’interdataworkingTesi di Dottorato di Ricerca diSamuele InnocentiCoordinatoreProf. Dino Giuli,Università degli Studi di FirenzeSu<strong>per</strong>visoriProf. Franco Pirri,Università degli Studi di FirenzeDr Ing. Maria Chiara Pettenati,Università degli Studi di Firenze31 dicembre 2008


RingraziamentiSeduto alla mia scrivania, in questi ultimi giorni mi sono soffermato spesso arileggere con orgoglio e soddisfazione l’indice della mia tesi di dottorato, estremasintesi 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 <strong>per</strong>iodo, di tappe ed eventi,spesso inattesi, spesso positivi. La mia ricchezza è stata ed è nelle <strong>per</strong>sonespeciali che hanno condiviso con me queste es<strong>per</strong>ienze col loro calore ed affetto,rendendomi migliore e fiero <strong>per</strong> le difficoltà su<strong>per</strong>ate e <strong>dei</strong> risultati raggiunti. Atutte loro va la mia profonda ricoscenza.Un ringraziamento speciale a mia moglie Donatella, <strong>per</strong> le tante qualità cheogni giorno dimostra nel realizzare i nostri progetti di vita, nel gioire <strong>per</strong> ciò chesono e <strong>per</strong> le aspirazioni che <strong>per</strong>seguo. «Ti amo»Ringrazio i miei genitori, mamma Carla e babbo Roberto, ed i miei suoceri,Renza e Valerio, <strong>per</strong> l’o<strong>per</strong>osità e l’amore con cui contribuiscono a rendere piùserena e sicura la mia famiglia, sopratutto in questo <strong>per</strong>iodo di lieti eventi.Ringrazio il Prof. Dino Giuli <strong>per</strong> gli innumerevoli incoraggiamenti, l’aiutomorale e materiale nei momenti in cui mi sono sentito più fragile, andando oltreil ruolo accademico che ricopre.Ringrazio il Prof. Franco Pirri, il mio Mentore, <strong>per</strong> la stima e la fiduciaprofessionale e <strong>per</strong>sonale, l’amicizia paterna di cui mi ha onorato, attraverso lequali ho su<strong>per</strong>ato molte delle mie incertezze e insicurezze.Ringrazio Dr Ing. Maria Chiara Pettenati, l’amica e confidente Maria Chiara,<strong>per</strong> la massima disponibilità, il suo determinante sostegno ed i preziosisuggerimenti professionali e <strong>per</strong>sonali.Ringrazio l’Ing. Davide Chini, un amico sincero, <strong>per</strong> l’estrema collaborazionee gli innumerevoli confronti costruttivi.Ringrazio il collega Ing. Massimo Poggi, <strong>per</strong> aver creduto fin da subito nellemie capacità e valorizzato le mie competenze, <strong>per</strong> avermi accordato la prolungataassenza da lavoro, consentendomi la stesura di questa tesi con più serenità.Ringrazio il collega Sig. Luca Capannesi, <strong>per</strong> il supporto tecnico, l’efficienzae la competenza con cui amministra i sistemi di rete del Laboratorio integrato“Tecnologie della Telematica & Radar e Radiocomunicazioni” del Dipartimentodi Elettronica e Telecomunicazioni.Ringrazio gli ex-studenti, adesso ingegneri e validi professionisti, che ho seguitocome 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 2008Samuele Innocenti


La sapienza mi <strong>per</strong>seguita, ma io sono più veloce.Lupo Alberto (Silver)


A mia moglie Donatella


IndiceIntroduzione 1I Analisi delle architetture 61 Stili architetturali 71.1 Service Oriented Architecture . . . . . . . . . . . . . . . . . . . . 71.1.1 Infrastruttura . . . . . . . . . . . . . . . . . . . . . . . . . 91.1.2 Definizioni . . . . . . . . . . . . . . . . . . . . . . . . . . . 101.1.3 Servizi . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 101.2 REpresentational State Transfer . . . . . . . . . . . . . . . . . . 121.2.1 Sintesi delle proprietà . . . . . . . . . . . . . . . . . . . . 131.3 Resource Oriented Architecture . . . . . . . . . . . . . . . . . . . 141.4 OASIS DataWeb . . . . . . . . . . . . . . . . . . . . . . . . . . . 161.4.1 L’architettura XDI . . . . . . . . . . . . . . . . . . . . . . 17Dataweb Links . . . . . . . . . . . . . . . . . . . . . . . . 171.4.2 Dataweb Addressing . . . . . . . . . . . . . . . . . . . . . 19Dataweb Representation . . . . . . . . . . . . . . . . . . . 211.4.3 Extensible Resource Identifier . . . . . . . . . . . . . . . . 21Gli identificatori XRI . . . . . . . . . . . . . . . . . . . . 231.4.4 La risoluzione XRI . . . . . . . . . . . . . . . . . . . . . . 251.5 Collaborazione basata su File System . . . . . . . . . . . . . . . . 281.5.1 Interfaccia e servizi offerti . . . . . . . . . . . . . . . . . . 291.5.2 Spazio <strong>dei</strong> nomi e trasparenza . . . . . . . . . . . . . . . . 321.5.3 Confronto tra server stateful e stateless . . . . . . . . . . 351.5.4 Semantica della consistenza . . . . . . . . . . . . . . . . . 371.5.5 Metodi di accesso remoto e caching . . . . . . . . . . . . . 411.5.6 File Area Network . . . . . . . . . . . . . . . . . . . . . . 451.5.7 Distributed Version File System . . . . . . . . . . . . . . 492 Stili di autenticazione 522.1 Elementi di crittografia . . . . . . . . . . . . . . . . . . . . . . . 532.1.1 Crittografia a chiave privata . . . . . . . . . . . . . . . . . 55


Indice2.1.2 Crittografia a chiave pubblica . . . . . . . . . . . . . . . . 562.1.3 Crittografia e firma digitale . . . . . . . . . . . . . . . . . 572.1.4 Funzioni hash . . . . . . . . . . . . . . . . . . . . . . . . . 582.2 Public Key Infrastructure . . . . . . . . . . . . . . . . . . . . . . 592.2.1 Elementi costituenti una PKI . . . . . . . . . . . . . . . . 602.2.2 Le Certification Authority . . . . . . . . . . . . . . . . . . 602.2.3 Le Policy delle PKI . . . . . . . . . . . . . . . . . . . . . 622.2.4 Rilascio, gestione e revoca <strong>dei</strong> certificati . . . . . . . . . . 622.3 OpenID . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 652.3.1 Il processo di autenticazione OpenID . . . . . . . . . . . . 652.3.2 Punti critici di OpenID . . . . . . . . . . . . . . . . . . . 722.4 Kerberos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 732.4.1 Dalle origini ai giorni nostri . . . . . . . . . . . . . . . . . 732.4.2 L’autenticazione in Kerberos . . . . . . . . . . . . . . . . 742.4.3 Terminologia e concetti . . . . . . . . . . . . . . . . . . . 75Reami, nomi principali e istanze . . . . . . . . . . . . . . 75Le chiavi . . . . . . . . . . . . . . . . . . . . . . . . . . . 76Key Distribution Center . . . . . . . . . . . . . . . . . . . 76I Ticket . . . . . . . . . . . . . . . . . . . . . . . . . . . . 772.4.4 Il funzionamento di Kerberos . . . . . . . . . . . . . . . . 78L’autenticazione Intra-Realm . . . . . . . . . . . . . . . . 79L’autenticazione Cross-Realm . . . . . . . . . . . . . . . . 812.4.5 Analisi di sicurezza . . . . . . . . . . . . . . . . . . . . . . 83Attacchi a dizionario e a forza bruta . . . . . . . . . . . . 85Replay Attack . . . . . . . . . . . . . . . . . . . . . . . . 86Time Services non sicuri . . . . . . . . . . . . . . . . . . . 86Spoofing Login . . . . . . . . . . . . . . . . . . . . . . . . 87Il TGS e la chiave di sessione . . . . . . . . . . . . . . . . 87I TGS e i Client . . . . . . . . . . . . . . . . . . . . . . . 88Attacchi al meccanismo di routing fra reami . . . . . . . . 88Altri Attacchi . . . . . . . . . . . . . . . . . . . . . . . . . 882.4.6 Sviluppi di Kerberos . . . . . . . . . . . . . . . . . . . . . 89Kerberos e la crittografia a chiave pubblica . . . . . . . . 89Kerberos e le smart card . . . . . . . . . . . . . . . . . . . 90II Requisiti, metodologia e contesto 923 Analisi estesa <strong>dei</strong> requisiti 933.1 Requisiti funzionali, R.1.* . . . . . . . . . . . . . . . . . . . . . . 943.1.1 Requisiti <strong>per</strong> le risorse materiali, R.1.1.* . . . . . . . . . . 95Requisiti <strong>per</strong> la gestione <strong>dei</strong> documenti, R.1.1.1.* . . . . . 95Requisiti di versioning, R.1.1.2.* . . . . . . . . . . . . . . 96Requisiti di trasparenza, R.1.1.3.* . . . . . . . . . . . . . 98Requisiti di indirizabilità, R.1.1.4.* . . . . . . . . . . . . . 98Requisiti sulla codifica degli indirizzi, R.1.1.5.* . . . . . . 993.1.2 Requisiti di contesto, R.1.2.* . . . . . . . . . . . . . . . . 99Requisiti di groupware, R.1.2.1.* . . . . . . . . . . . . . . 100v


IndiceRequisiti <strong>per</strong> le identità, R.1.2.2.* . . . . . . . . . . . . . 102Requisiti di awareness, R.1.2.3.* . . . . . . . . . . . . . . 1033.2 Requisiti non funzionali, R.2.* . . . . . . . . . . . . . . . . . . . 1043.2.1 Requisiti architetturali, R.2.1.* . . . . . . . . . . . . . . . 1043.2.2 Requisiti di qualità <strong>dei</strong> dati, R.2.2.* . . . . . . . . . . . . 1053.2.3 Requisiti <strong>per</strong> i documenti, R.2.3.* . . . . . . . . . . . . . 1064 Metodologia di progettazione 1094.1 Valutazione <strong>dei</strong> requisiti . . . . . . . . . . . . . . . . . . . . . . . 1094.2 Principi progettuali . . . . . . . . . . . . . . . . . . . . . . . . . . 1104.2.1 Non limitare la vista sul problema: approccio sistemico . 1104.2.2 Scomporre la complessità: stratificare . . . . . . . . . . . 115Limitare la crescita della complessità . . . . . . . . . . . . 1164.2.3 Adottare uno stile chiaro e standardizzato: SOA + ReST 118Richiami a SOA . . . . . . . . . . . . . . . . . . . . . . . 118Richiami a ReST . . . . . . . . . . . . . . . . . . . . . . . 119Conciliare SOA e ReST . . . . . . . . . . . . . . . . . . . 1194.2.4 Semplicità <strong>per</strong> il deploy: plug and play . . . . . . . . . . . 1204.2.5 Decentralizzare la sicurezza: ente pubblico autorevole . . 120Osservazioni sulla gestione delle identità . . . . . . . . . . 1214.2.6 Abilitare lo sviluppo a<strong>per</strong>to: free software . . . . . . . . . 123Come nasce il Software Libero . . . . . . . . . . . . . . . 123Software Libero e Open Source . . . . . . . . . . . . . . . 123Una scelta consapevole . . . . . . . . . . . . . . . . . . . . 123Vantaggi tecnici, sociali ed economici . . . . . . . . . . . . 124Copyleft e licenza del Software Libero . . . . . . . . . . . 124La situazione attuale . . . . . . . . . . . . . . . . . . . . . 1255 Modello del contesto 1265.1 Modello dell’ambiente . . . . . . . . . . . . . . . . . . . . . . . . 1275.2 Le entità . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1295.2.1 Persona . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1295.2.2 Group . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1305.2.3 Role . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 131Role vs Group . . . . . . . . . . . . . . . . . . . . . . . . 1315.2.4 Permission . . . . . . . . . . . . . . . . . . . . . . . . . . 1325.2.5 Location . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1325.2.6 Resource . . . . . . . . . . . . . . . . . . . . . . . . . . . 1335.3 La generalizzazione in entità . . . . . . . . . . . . . . . . . . . . . 1335.4 Il modello delle interazioni . . . . . . . . . . . . . . . . . . . . . . 134III <strong>InterDataNet</strong>: progettazione 1376 L’architettura <strong>InterDataNet</strong> 1386.1 IDN Information Model . . . . . . . . . . . . . . . . . . . . . . . 1396.1.1 Cosa è un Information Model . . . . . . . . . . . . . . . . 1406.1.2 Elementi strutturabili . . . . . . . . . . . . . . . . . . . . 142vi


Indice6.1.3 Strutturare con il principio di responsabilità . . . . . . . . 1436.1.4 Identificazione <strong>dei</strong> nodi . . . . . . . . . . . . . . . . . . . 1456.1.5 Osservazioni sul modello . . . . . . . . . . . . . . . . . . . 1476.2 IDN Service Architecture . . . . . . . . . . . . . . . . . . . . . . 1486.2.1 Attraversamento <strong>dei</strong> livelli . . . . . . . . . . . . . . . . . . 1506.2.2 Imbustamento di dati e metadati . . . . . . . . . . . . . . 1516.3 IDN Overlay Network . . . . . . . . . . . . . . . . . . . . . . . . 1546.3.1 Dall’architettura <strong>dei</strong> servizi alla rete . . . . . . . . . . . . 1556.3.2 Control Plane . . . . . . . . . . . . . . . . . . . . . . . . . 1566.3.3 Rete ed intero<strong>per</strong>abilità . . . . . . . . . . . . . . . . . . . 1577 <strong>InterDataNet</strong> Information Model 1607.1 I nodi informativi . . . . . . . . . . . . . . . . . . . . . . . . . . . 1617.1.1 Informazioni atomiche . . . . . . . . . . . . . . . . . . . . 1627.1.2 Informazioni primitive . . . . . . . . . . . . . . . . . . . . 1637.2 Relazioni strutturali tra nodi . . . . . . . . . . . . . . . . . . . . 1647.3 Strutturare con criteri di responsabilità . . . . . . . . . . . . . . 1677.4 Identificazione <strong>dei</strong> nodi . . . . . . . . . . . . . . . . . . . . . . . . 1677.5 Storico <strong>dei</strong> documenti . . . . . . . . . . . . . . . . . . . . . . . . 1687.5.1 Versioning . . . . . . . . . . . . . . . . . . . . . . . . . . . 1717.5.2 La propagazione delle modifiche . . . . . . . . . . . . . . 1727.6 I collegamenti del modello . . . . . . . . . . . . . . . . . . . . . . 1737.7 Lo stato di un documento . . . . . . . . . . . . . . . . . . . . . . 1737.7.1 Lo stato delle informazioni atomiche . . . . . . . . . . . . 1737.7.2 Lo stato delle informazioni primitive . . . . . . . . . . . . 1747.8 Authoring concorrente . . . . . . . . . . . . . . . . . . . . . . . . 1767.8.1 Controllo delle sessioni . . . . . . . . . . . . . . . . . . . . 1778 <strong>InterDataNet</strong> Service Architecture 1808.1 Virtual Repository Service . . . . . . . . . . . . . . . . . . . . . . 1838.1.1 Resource Aggregation Service . . . . . . . . . . . . . . . . 1838.1.2 Logical Domain Name Service . . . . . . . . . . . . . . . . 1858.1.3 Identity Service . . . . . . . . . . . . . . . . . . . . . . . . 1858.2 Information History Service . . . . . . . . . . . . . . . . . . . . . 1868.2.1 Version Traversing Algorithm . . . . . . . . . . . . . . . . 1868.3 Replica Management Service . . . . . . . . . . . . . . . . . . . . 1878.3.1 Replica Management . . . . . . . . . . . . . . . . . . . . . 1878.3.2 Localization Service . . . . . . . . . . . . . . . . . . . . . 1888.4 Storage Interface Service . . . . . . . . . . . . . . . . . . . . . . . 1888.4.1 Integrazione di sistemi legacy . . . . . . . . . . . . . . . . 189IV <strong>InterDataNet</strong>: servizi e sottosistemi 1919 IDN Naming Service 1929.1 Requisiti <strong>dei</strong> nomi . . . . . . . . . . . . . . . . . . . . . . . . . . 1959.1.1 Requisiti <strong>per</strong> gli HFN . . . . . . . . . . . . . . . . . . . . 1959.1.2 Requisiti <strong>per</strong> gli URN . . . . . . . . . . . . . . . . . . . . 196vii


Indice9.1.3 Requisiti sulla codifica <strong>per</strong> HFN e URN . . . . . . . . . . 1989.2 Logical Resource Identifier (LRI) . . . . . . . . . . . . . . . . . . 1999.2.1 Grammatica . . . . . . . . . . . . . . . . . . . . . . . . . 2009.3 Persistent Resource Identifier (PRI) . . . . . . . . . . . . . . . . 2019.3.1 Grammatica . . . . . . . . . . . . . . . . . . . . . . . . . 2019.4 Il modello a tre livelli . . . . . . . . . . . . . . . . . . . . . . . . 2029.4.1 Sistemi di risoluzione . . . . . . . . . . . . . . . . . . . . . 2039.5 Logical Domain Name System (LDNS) . . . . . . . . . . . . . . . 2049.5.1 La risoluzione . . . . . . . . . . . . . . . . . . . . . . . . . 2049.5.2 L’algoritmo di risoluzione . . . . . . . . . . . . . . . . . . 2079.5.3 Caching . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2099.5.4 Supporto alla navigazione . . . . . . . . . . . . . . . . . . 2119.5.5 Espansione dello spazio <strong>dei</strong> nomi . . . . . . . . . . . . . . 2119.5.6 Proprietà di LDNS . . . . . . . . . . . . . . . . . . . . . . 2139.6 Localization Service (LS) . . . . . . . . . . . . . . . . . . . . . . 2149.6.1 La risoluzione inversa. . . . . . . . . . . . . . . . . . . . . 2189.7 Integrazione in <strong>InterDataNet</strong> . . . . . . . . . . . . . . . . . . . . 2209.8 Studio di fattibilità . . . . . . . . . . . . . . . . . . . . . . . . . . 2229.8.1 Implementazione del sistema <strong>dei</strong> nomi . . . . . . . . . . . 222LDNS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 222LS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 228Risoluzione inversa . . . . . . . . . . . . . . . . . . . . . . 23110 Virtual Repository Service 23510.1 Richiami al modello IDN-IM . . . . . . . . . . . . . . . . . . . . 23610.1.1 La struttura dello storico . . . . . . . . . . . . . . . . . . 23810.2 Resource Aggregation Service . . . . . . . . . . . . . . . . . . . . 23810.2.1 Vista sullo storico delle informazioni . . . . . . . . . . . . 23910.2.2 Relazioni strutturali . . . . . . . . . . . . . . . . . . . . . 23910.2.3 La propagazione delle modifiche . . . . . . . . . . . . . . 24110.2.4 Applicazione delle diramazioni e delle fusioni . . . . . . . 242Branching . . . . . . . . . . . . . . . . . . . . . . . . . . . 242Merging . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24210.2.5 Osservazioni sugli aspetti strutturali . . . . . . . . . . . . 24610.3 Identity Service . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24710.3.1 Identità e profilo utente . . . . . . . . . . . . . . . . . . . 24810.3.2 Access Control List (ACL) . . . . . . . . . . . . . . . . . 250Permessi sui nomi . . . . . . . . . . . . . . . . . . . . . . 251Permessi sulle informazioni . . . . . . . . . . . . . . . . . 25111 Information History Service 25311.1 La navigazione nello storico . . . . . . . . . . . . . . . . . . . . . 25311.1.1 Version Traversing Algorithm . . . . . . . . . . . . . . . . 25411.1.2 I parametri di versione . . . . . . . . . . . . . . . . . . . . 25511.2 Interfaccia . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25711.3 Information History Data Model . . . . . . . . . . . . . . . . . . 26211.3.1 Descrizione dello Schema XML . . . . . . . . . . . . . . . 265viii


Indice12 Replica Management Service 27112.0.2 Estensioni dell’applicabilità . . . . . . . . . . . . . . . . . 27112.0.3 Condivisione di risorse . . . . . . . . . . . . . . . . . . . . 27212.0.4 Vincoli prestazionali . . . . . . . . . . . . . . . . . . . . . 27312.1 Requisiti . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 276Requisiti <strong>per</strong> la gestione delle risorse . . . . . . . . . . . . 276Requisiti <strong>per</strong> la replicazione . . . . . . . . . . . . . . . . . 28012.2 Gestione delle risorse . . . . . . . . . . . . . . . . . . . . . . . . . 28412.2.1 Memorizzazione <strong>per</strong>sistente . . . . . . . . . . . . . . . . . 28412.2.2 Il servizio di risoluzione <strong>dei</strong> nomi . . . . . . . . . . . . . . 28512.2.3 Il servizio di replicazione . . . . . . . . . . . . . . . . . . . 28512.2.4 Mantenimento della consistenza . . . . . . . . . . . . . . . 28812.2.5 Posizionamento delle repliche . . . . . . . . . . . . . . . . 29212.2.6 Selezione della replica e routing delle richieste . . . . . . . 29412.2.7 Azioni atomiche e transazioni . . . . . . . . . . . . . . . . 29512.3 Interfacce . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29712.3.1 Interfaccia esposta da Replica Management . . . . . . . . 29812.3.2 Interfaccia esposta da Localization Service . . . . . . . . . 31413 Storage Interface Service 31713.1 Requisiti . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31713.2 Interfaccia . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32413.2.1 Messaggi di input, output, fault e generalità . . . . . . . . 32513.2.2 O<strong>per</strong>azioni base dello storage <strong>per</strong>sistente . . . . . . . . . . 32713.2.3 O<strong>per</strong>azioni <strong>per</strong> funzionalità di <strong>per</strong>formance . . . . . . . . 32813.2.4 O<strong>per</strong>azioni specializzate <strong>per</strong> dati e metadati . . . . . . . . 32913.2.5 O<strong>per</strong>azioni <strong>per</strong> funzionalità specifiche . . . . . . . . . . . 33113.2.6 O<strong>per</strong>azioni <strong>per</strong> la gestione degli eventi . . . . . . . . . . . 33213.2.7 Interfaccia delle notifiche . . . . . . . . . . . . . . . . . . 33413.3 Storage Interface Data Model . . . . . . . . . . . . . . . . . . . . 33413.3.1 Messaggi . . . . . . . . . . . . . . . . . . . . . . . . . . . 33613.3.2 Tipi predefiniti . . . . . . . . . . . . . . . . . . . . . . . . 33813.3.3 WSDL e XML Schema . . . . . . . . . . . . . . . . . . . . 339Storage Interface XML Schema . . . . . . . . . . . . . . . 339Storage Interface Predefined Types . . . . . . . . . . . . . 349Conclusioni 352V Appendici 356A ABNF 357B Notazioni e definizioni 359B.1 Notazioni <strong>per</strong> i requisiti . . . . . . . . . . . . . . . . . . . . . . . 359B.2 Classificazione <strong>dei</strong> requisiti . . . . . . . . . . . . . . . . . . . . . 360B.3 Definizioni . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 361ix


IndiceB.4 Acronimi di <strong>InterDataNet</strong> . . . . . . . . . . . . . . . . . . . . . . 362C Replicazione di risorse in rete 364C.1 Vantaggi introdotti con la replicazione . . . . . . . . . . . . . . . 365C.2 Architetture <strong>dei</strong> sistemi di replicazione . . . . . . . . . . . . . . . 368C.3 Modelli di consistenza delle repliche . . . . . . . . . . . . . . . . 371C.3.1 Modelli data-centrici . . . . . . . . . . . . . . . . . . . . . 371C.3.2 Modelli client-centrici . . . . . . . . . . . . . . . . . . . . 376C.4 Protocolli di gestione della consistenza . . . . . . . . . . . . . . . 378C.4.1 Metodo del sito primario . . . . . . . . . . . . . . . . . . 380C.4.2 Metodo a votazione . . . . . . . . . . . . . . . . . . . . . 383C.4.3 Metodo <strong>dei</strong> vettori di versione . . . . . . . . . . . . . . . . 387C.5 Strategie di replicazione . . . . . . . . . . . . . . . . . . . . . . . 389C.5.1 Posizionamento delle repliche . . . . . . . . . . . . . . . . 390C.5.2 Propagazione degli aggiornamenti . . . . . . . . . . . . . 392D Versioning e collaborazione 395D.0.3 Modelli di lavoro . . . . . . . . . . . . . . . . . . . . . . . 396D.1 Il concetto di configurazione . . . . . . . . . . . . . . . . . . . . . 398D.2 Il controllo delle versioni . . . . . . . . . . . . . . . . . . . . . . . 401D.3 Modelli di sincronizzazione . . . . . . . . . . . . . . . . . . . . . 401D.3.1 Checkout/Checkin . . . . . . . . . . . . . . . . . . . . . . 402D.3.2 Composizione . . . . . . . . . . . . . . . . . . . . . . . . . 402D.3.3 Transazioni estese nel tempo . . . . . . . . . . . . . . . . 403D.3.4 Change set . . . . . . . . . . . . . . . . . . . . . . . . . . 404D.4 Modelli di versioning . . . . . . . . . . . . . . . . . . . . . . . . . 405D.4.1 Modello intensionale . . . . . . . . . . . . . . . . . . . . . 405D.4.2 Modello estensionale . . . . . . . . . . . . . . . . . . . . . 406D.4.3 Valutazione <strong>dei</strong> modelli . . . . . . . . . . . . . . . . . . . 406D.4.4 Una nuova alternativa: UEVM . . . . . . . . . . . . . . . 407D.5 Unified Extensional Versioning Model . . . . . . . . . . . . . . . 408D.5.1 Il modello . . . . . . . . . . . . . . . . . . . . . . . . . . . 408Il modello del documento . . . . . . . . . . . . . . . . . . 408Esempio di documento strutturato . . . . . . . . . . . . . 411Versioning . . . . . . . . . . . . . . . . . . . . . . . . . . . 412Versioning di un singolo documento . . . . . . . . . . . . 414Versioning di più documenti legati fra loro . . . . . . . . . 414D.5.2 Conclusioni . . . . . . . . . . . . . . . . . . . . . . . . . . 415UEVM dal punto di vista dell’utente . . . . . . . . . . . . 415Gestione dell’esplosione combinatoria . . . . . . . . . . . 415D.6 WebDAV . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 416D.7 Revision Control System (RCS) . . . . . . . . . . . . . . . . . . . 417D.8 Concurrent Versions System (CVS) . . . . . . . . . . . . . . . . . 420D.8.1 CVS, evoluzione di RCS . . . . . . . . . . . . . . . . . . . 420D.8.2 Concetti di base . . . . . . . . . . . . . . . . . . . . . . . 420Revisioni, branch e configurazioni . . . . . . . . . . . . . . 422D.9 Subversion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 423D.9.1 Concetti di base . . . . . . . . . . . . . . . . . . . . . . . 424x


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


Elenco delle figure1.1 Esempi pratici di loose coupling . . . . . . . . . . . . . . . . . . . 91.2 Lo strato Dataweb indicato come evoluzione del Web . . . . . . . 161.3 Link contracts <strong>per</strong> la condivisione dati a due vie . . . . . . . . . 181.4 Strato uniforme XRI . . . . . . . . . . . . . . . . . . . . . . . . . 211.5 Relazione tra XRI, IRI e URI . . . . . . . . . . . . . . . . . . . . 221.6 XRI i-names e i-numbers come strato su<strong>per</strong>iore al DNS . . . . . 241.7 Le 4 modalità di risoluzione dell’architettura XRI . . . . . . . . . 271.8 Modelli upload/download e ad accesso remoto <strong>per</strong> il file service . 301.9 Lettura e scrittura in un sistema a singolo processore . . . . . . . 381.10 Lettura e scrittura in un sistema distribuito . . . . . . . . . . . . 391.11 Luoghi dove memorizzare file . . . . . . . . . . . . . . . . . . . . 411.12 Architettura di una File Area Network . . . . . . . . . . . . . . . 471.13 Formato dell’albero in Wizbit . . . . . . . . . . . . . . . . . . . . 502.1 Crittografia a chiave privata - cifratura . . . . . . . . . . . . . . . 552.2 Crittografia a chiave privata - decifratura . . . . . . . . . . . . . 552.3 Crittografia a chiave pubblica . . . . . . . . . . . . . . . . . . . . 572.4 Funzioni hash - controllo di ridondanza . . . . . . . . . . . . . . 592.5 Struttura gerarchica delle CA di una PKI. . . . . . . . . . . . . . 612.6 Flowchart di autenticazione OpenID . . . . . . . . . . . . . . . . 682.7 State diagram della procedura di autenticazione OpenID . . . . . 692.8 Sequence diagram <strong>per</strong> l’autenticazione checkid-immediate . . . . 702.9 Sequence diagram <strong>per</strong> l’autenticazione checkid-setup . . . . . . . 712.10 Kerberos - Autenticazione intra-realm . . . . . . . . . . . . . . . 802.11 Kerberos - Autenticazione cross-realm . . . . . . . . . . . . . . . 823.1 Modello a quattro quadranti . . . . . . . . . . . . . . . . . . . . . 1004.1 Interazioni tra servizi . . . . . . . . . . . . . . . . . . . . . . . . . 1164.2 Interazioni di servizi stratificati . . . . . . . . . . . . . . . . . . . 1175.1 Rappresentazione dell’ambiente reale . . . . . . . . . . . . . . . . 1285.2 Role Based Access Control Model . . . . . . . . . . . . . . . . . . 132


Elenco delle figure5.3 Classificazione delle entità . . . . . . . . . . . . . . . . . . . . . . 1345.4 Il modello di interazione . . . . . . . . . . . . . . . . . . . . . . . 1356.1 Logo del progetto IDN . . . . . . . . . . . . . . . . . . . . . . . . 1386.2 Nomi di risorse replicate . . . . . . . . . . . . . . . . . . . . . . . 1466.3 Livelli dell’architettura IDN . . . . . . . . . . . . . . . . . . . . . 1496.4 Interazione request/response applicata ad IDN . . . . . . . . . . 1506.5 Imbustamento di dati e metadati . . . . . . . . . . . . . . . . . . 1526.6 Classi di metadati in IDN . . . . . . . . . . . . . . . . . . . . . . 1536.7 Livelli e servizi dell’architettura IDN . . . . . . . . . . . . . . . . 1556.8 Livelli, servizi e processi . . . . . . . . . . . . . . . . . . . . . . . 1576.9 Scenario di coo<strong>per</strong>azione . . . . . . . . . . . . . . . . . . . . . . . 1586.10 Esempio di interazione fra i servizi in organizzazioni diverse . . . 1597.1 Esempio di documento patente IDN . . . . . . . . . . . . . . . . 1657.2 Esempio di documento IDN . . . . . . . . . . . . . . . . . . . . . 1667.3 Esempio di relazioni tra documenti IDN-IM . . . . . . . . . . . . 1687.4 Stato Update delle informazioni . . . . . . . . . . . . . . . . . . . 1697.5 Generazione delle revisioni . . . . . . . . . . . . . . . . . . . . . . 1707.6 Storico dell’informazione in IDN-IM . . . . . . . . . . . . . . . . 1727.7 Stati di una informazione atomica . . . . . . . . . . . . . . . . . 1747.8 Stati di un’informazione primitiva . . . . . . . . . . . . . . . . . 1757.9 Casi di authoring concorrente . . . . . . . . . . . . . . . . . . . . 1778.1 Relazione tra IDN-IM e IDN-SA . . . . . . . . . . . . . . . . . . 1818.2 Interdataworking in IDN . . . . . . . . . . . . . . . . . . . . . . . 1828.3 Resource Space Names . . . . . . . . . . . . . . . . . . . . . . . . 1828.4 Revisioni successive di documenti UEVM . . . . . . . . . . . . . 1848.5 Coreografia al livello di Replica Management . . . . . . . . . . . 1888.6 Storage Interface e Legacy Storage Interface . . . . . . . . . . . . 1899.1 Albero di directory LDAP . . . . . . . . . . . . . . . . . . . . . . 1949.2 Sintassi degli LRI . . . . . . . . . . . . . . . . . . . . . . . . . . . 2009.3 Sintassi <strong>dei</strong> PRI . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2029.4 Espressione regolare <strong>per</strong> “match” sui PRI . . . . . . . . . . . . . 2029.5 Modello del sistema <strong>dei</strong> nomi: LRI, PRI ed URL . . . . . . . . . 2039.6 Esempio di risoluzione senza Look-Ahead . . . . . . . . . . . . . 2069.7 Esempio di risoluzione con Look-Ahead . . . . . . . . . . . . . . 2079.8 Esempio di albero delle zone . . . . . . . . . . . . . . . . . . . . . 2089.9 Richieste ricorsive <strong>per</strong> la risoluzione . . . . . . . . . . . . . . . . 2109.10 Rappresentazione delle zona in LDNS . . . . . . . . . . . . . . . 2139.11 Esempio di LS . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2159.12 Rappresentazione di una zona . . . . . . . . . . . . . . . . . . . . 2169.13 Estensione di una zona . . . . . . . . . . . . . . . . . . . . . . . . 2179.14 Delega della gestione di un nodo ad un’altra zona . . . . . . . . . 2179.15 Risoluzione inversa . . . . . . . . . . . . . . . . . . . . . . . . . . 2199.16 Sistema <strong>dei</strong> nomi in <strong>InterDataNet</strong> . . . . . . . . . . . . . . . . . . 2209.17 Descrittore XML relativo alla risoluzione inversa . . . . . . . . . 231xiii


Elenco delle figure10.1 Nodi di livello IH . . . . . . . . . . . . . . . . . . . . . . . . . . . 23710.2 Link di strutturali e di versioning . . . . . . . . . . . . . . . . . . 24010.3 Branch in IDN-IM con un figlio condiviso . . . . . . . . . . . . . 24310.4 Propagazione in presenza di un figlio condiviso . . . . . . . . . . 24310.5 Merge di due nodi . . . . . . . . . . . . . . . . . . . . . . . . . . 24510.6 Propagazione a seguito di un merge . . . . . . . . . . . . . . . . . 24510.7 Gestione di due rami di sviluppo concorrente . . . . . . . . . . . 24610.8 Branch di un nodo . . . . . . . . . . . . . . . . . . . . . . . . . . 24710.9 Branch di un intero documento . . . . . . . . . . . . . . . . . . . 24811.1 Sintassi degli indirizzi di livello IH . . . . . . . . . . . . . . . . . 25411.2 Esempio di elemento recente rispetto al nodo di partenza . . . . 25611.3 Esempi di “last” relativi al branch . . . . . . . . . . . . . . . . . . 25711.4 Casi d’uso relativi all’interfaccia mostrata da IH a Virtual Repository. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25811.5 Albero di XML Schema: visione globale . . . . . . . . . . . . . . 26611.6 Albero di XML Schema: particolare <strong>dei</strong> link di versione . . . . . 26711.7 XML Schema <strong>per</strong> la definizione di indirizzi PRI . . . . . . . . . . 26711.8 Espressione regolare <strong>per</strong> definire gli identificativi di versione . . . 26811.9 Convenzione sui nomi <strong>dei</strong> nodi nello storico . . . . . . . . . . . . 26912.1 Votazione con quorum a maggioranza su due livelli . . . . . . . . 29012.2 Casi d’uso dell’interfaccia esposta da RM: o<strong>per</strong>azioni “CRUD” . . 29912.3 Casi d’uso dell’interfaccia esposta da RM: o<strong>per</strong>azioni “Advanced” 30612.4 Casi d’uso dell’interfaccia esposta da RM: o<strong>per</strong>azioni “Admin” . . 30912.5 Casi d’uso dell’interfaccia esposta da RM a istanze di pari livello 31312.6 Casi d’uso dell’interfaccia esposta da Localization Service . . . . 31413.1 Information Model <strong>dei</strong> messaggi di input e di output . . . . . . . 32513.2 Tipi di messaggi di fault . . . . . . . . . . . . . . . . . . . . . . . 32613.3 Information Model <strong>dei</strong> messaggi e delle o<strong>per</strong>azioni base <strong>per</strong> lamemorizzazione <strong>per</strong>sistente . . . . . . . . . . . . . . . . . . . . . 32813.4 Information model <strong>dei</strong> messaggi e delle o<strong>per</strong>azioni <strong>per</strong> funzionalitàduplicazione, lista di risorse e lista di metadati . . . . . . . . 33013.5 Information model <strong>dei</strong> messaggi e delle o<strong>per</strong>azioni di memorizzazionedi singoli dati o singoli metadati . . . . . . . . . . . . . . . 33113.6 Information model <strong>dei</strong> messaggi e delle o<strong>per</strong>azioni <strong>per</strong> funzionalitàdi locking e validazione . . . . . . . . . . . . . . . . . . . . . 33313.7 Information model <strong>dei</strong> messaggi e delle o<strong>per</strong>azioni a supportodella notifica di eventi . . . . . . . . . . . . . . . . . . . . . . . . 33413.8 Interfaccia <strong>per</strong> le notifiche . . . . . . . . . . . . . . . . . . . . . . 33513.9 Information Model di SI-R . . . . . . . . . . . . . . . . . . . . . . 336C.1 Architettura di un sistema di gestione delle repliche . . . . . . . 369C.2 Organizzazione di un archivio di dati distribuito e replicato . . . 372C.3 Accesso ad un sistema replicato da parte di un utente mobile . . 377C.4 Approccio del sito primario con letture sui siti di backup . . . . . 382C.5 Approccio del sito primario con migrazione del sito primario . . . 382xiv


Elenco delle figureC.6 Esempi di configurazione <strong>per</strong> i quorum nella votazione . . . . . . 386C.7 Esempio dell’approccio <strong>dei</strong> vettori di versione . . . . . . . . . . . 388C.8 Organizzazione logica <strong>dei</strong> tipi di repliche in un archivio . . . . . . 390D.1 Esempio ricorsivo della configurazione . . . . . . . . . . . . . . . 399D.2 Rappresentazione della storia delle versioni . . . . . . . . . . . . 401D.3 Paradigma di interazione . . . . . . . . . . . . . . . . . . . . . . . 403D.4 Esempi in riferimento alla grammatica . . . . . . . . . . . . . . . 410D.5 Esempi di documento UEVM . . . . . . . . . . . . . . . . . . . . 411D.6 Altri esempi di documenti strutturati . . . . . . . . . . . . . . . . 412D.7 Modifiche nella stessa sessione . . . . . . . . . . . . . . . . . . . . 414D.8 La modifica di un link e nascita di una nuova versione . . . . . . 415D.9 Gestione delle configurazioni in RCS . . . . . . . . . . . . . . . . 419D.10 Evoluzione delle versioni in Subversion . . . . . . . . . . . . . . . 425D.11 Topologie a stella ed albero . . . . . . . . . . . . . . . . . . . . . 428xv


Elenco delletabelle1.1 Requisiti XDI di indirizzamento . . . . . . . . . . . . . . . . . . . 201.2 Esempi di i-number e i-names . . . . . . . . . . . . . . . . . . . . 251.3 Confronto tra le architetture di risoluzione DNS e XRI . . . . . . 261.4 Confronto tra server stateful e stateless . . . . . . . . . . . . . . 371.5 Metodi <strong>per</strong> gestire i file condivisi in un sistema distribuito . . . . 401.6 Metodi <strong>per</strong> gestire la cache <strong>dei</strong> file nel client . . . . . . . . . . . . 444.1 Requisiti funzionali <strong>per</strong> le risorse materiali (gestione risorse) . . . 1114.2 Requisiti funzionali <strong>per</strong> le risorse materiali (versioning) . . . . . . 1114.3 Requisiti funzionali <strong>per</strong> le risorse materiali (trasparenza) . . . . . 1114.4 Requisiti funzionali <strong>per</strong> le risorse materiali (indirizzabilità) . . . . 1114.5 Requisiti funzionali <strong>per</strong> le risorse materiali (codifica) . . . . . . . 1124.6 Requisiti funzionali <strong>per</strong> le risorse di contesto (groupware) . . . . 1124.7 Requisiti funzionali <strong>per</strong> le risorse di contesto (identità) . . . . . . 1124.8 Requisiti funzionali <strong>per</strong> le risorse di contesto (awareness) . . . . . 1134.9 Requisiti non funzionali architetturali . . . . . . . . . . . . . . . 1134.10 Requisiti non funzionali sulla qualità <strong>dei</strong> dati . . . . . . . . . . . 1134.11 Requisiti non funzionali <strong>per</strong> i documenti . . . . . . . . . . . . . . 1145.1 Corrispondenza ambiente modellato - ambiente fisico . . . . . . . 1297.1 Mappa <strong>per</strong> la determinazione degli stati . . . . . . . . . . . . . . 1769.1 Esempio di rappresentazione <strong>dei</strong> dati interni di un LNS radice . . 2239.2 Esempio di rappresentazione <strong>dei</strong> dati interni di un generico LNS 2239.3 Esempio di rappresentazione <strong>dei</strong> dati interni di un server LS radice2299.4 Esempio di rappresentazione <strong>dei</strong> dati interni di un server LS . . . 2299.5 Esempio di rappresentazione <strong>dei</strong> dati interni di un server LS <strong>per</strong>la risoluzione inversa . . . . . . . . . . . . . . . . . . . . . . . . . 232


Elenco delle tabelle9.6 Esempio di rappresentazione <strong>dei</strong> dati interni di un server LS <strong>per</strong>il caching relativo alla risoluzione inversa . . . . . . . . . . . . . . 232C.1 Modelli di consistenza che non usano variabili di sincronizzazione 375C.2 Modelli di consistenza che usano variabili di sincronizzazione . . 375D.1 Struttura e dati di un documento . . . . . . . . . . . . . . . . . . 398D.2 Approcci di versioning adottati dai CM sui vari tipi di entità . . 408D.3 Grammatica che definisce la struttura del documento . . . . . . . 409xvii


IntroduzioneLa diffusione di Internet e delle <strong>nuove</strong> tecnologie della telematica hannomutato e trasformato società e <strong>per</strong>sone, con un <strong>per</strong>corso così dirompente dadeterminare la nascita di nuova scienza, la Web Science. La Scienza del Webstudia, condiziona e caratterizza le evoluzioni del World Wide Web (WWW).La storia delle evoluzioni e rivoluzioni, che segnano lo sviluppo della WebScience e succedutesi dalla fine degli anni Ottanta fino ai nostri giorni, è riccae complessa. Ai fini di quanto si discuterà in questa dissertazione, ha importanzaricordare la motivazione storica, datata 1989, agli albori del Web comeapplicazione: creare un sistema di gestione dell’informazione adatto alla condivisionedi un esteso patrimonio di relazioni, documenti e in genere di letteraturascientifica.Varie tappe dello sviluppo del Web, che non è qui sede di commentare, hannovisto attribuire etichette diverse a diversi momenti storici dell’applicazioneWWW. Negli ultimi due anni c’è stato un largo e talvolta abusato uso deltermine “Web 2.0” <strong>per</strong> denotare un particolare fiorire di applicazioni che hannoottenuto 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 ancoramodi nuovi e migliori <strong>per</strong> sfruttare pienamente le potenzialità offerte dal sistemasocio-tecnico, che si è configurato, ma già nelle comunità della rete si parla di“Web 3.0” o di “Web of Data” <strong>per</strong> indicare una visione del Web ancora daattuare nella prossima evoluzione, che recepisce teorie e strumenti semantici <strong>per</strong>l’elaborazione delle informazioni.Indipendentemente dalle convenzioni <strong>per</strong> identificare, collocare e motivare i<strong>per</strong>iodi della storia del Web, quello che è rilevante, <strong>per</strong> i contenuti presentati inquesto lavoro, è la constatazione che le soluzioni del Web attuale stanno trovandolarghissima diffusione <strong>per</strong>chè esiste una infrastruttura consolidata di apparati eprotocolli di comunicazione, di tecnologie informatiche (sebbene frammentate)collaudate e mature e di una platea di utenti sempre più accorti e ben dispostia diventare nodi della rete. Quello che appare chiaro a questo punto è cheuna evoluzione verso soluzioni semantiche, rimasta visione da circa una decade,necessita <strong>per</strong> decollare di fondamenta altrettanto solide. Allora è giusto chiedersi


Introduzionequali dovranno essere queste fondamenta, quali funzionalità di base consolidarenella infrastruttura.Nella Web Science si identifica chiaramente oggi il principio di base largamentecondiviso che ha come scopo quello di: move the “intelligence” out ofapplications, into the data (Nova Spivak), ovvero disaccoppiare le applicazionidai dati che esse elaborano.Vari settori dell’ingegneria dell’informazione hanno iniziato <strong>per</strong> primi ad applicarequesto principio <strong>per</strong> affrontare temi e problematiche note sotto i nomi:integrazione di sistemi, intero<strong>per</strong>abilità, riuso di dati e applicazioni, federazionedi sistemi, coo<strong>per</strong>azione applicativa, collaborazione in rete, gestione distribuitadi risorse materiali e computazionali, ingegnerizzazione <strong>dei</strong> processi ed oltre finoal Semantic Web e all’intelligenza distribuita. I dati sono visti come patrimoniocosicchè le soluzioni e le metodologie proposte mirano a valorizzarli.Ciascuno <strong>dei</strong> problemi a<strong>per</strong>ti sopra citati presenta di <strong>per</strong> sé rilevanti complicazionisocio-tecniche e difficoltà teorico-implementative, soprattutto in scenarisu larga scala. Per affrontare gli stessi argomenti in modo equidistante edomogeneo è richiesta una metodologia in grado di suggerire un modo efficace edefficiente di analizzare il problema e di indicarne la direzione <strong>per</strong> la sua soluzione.In questo lavoro saranno affrontati i problemi precedentemente elencati, conuna ricerca di base, mettendo in discussione le strategie di progettazione tradizionali,principalmente evitando la proposta di standard o tecnologie. Facendotesoro delle motivazioni tecniche che hanno determinato il successo della suiteprotocollare TCP/IP e dell’internetworking, applicheremo la stratificazionecome principio fondante della ricerca e della progettazione, applicandolo al trattamentoe alla gestione <strong>dei</strong> dati-informazioni. Indicheremo questo approccio colnome di interdataworking. L’obiettivo più ambizioso di questa tesi è auspicare<strong>per</strong> l’interdataworking lo stesso successo dell’internetworking.Per interdataworking intendiamo l’abilità di collegare, distribuire ed integrarei dati, mettendo in evidenza l’obiettivo di aumentare l’intero<strong>per</strong>abilità e lacollaborazione tra processi connessi in rete.Gli studi eseguiti sulla stratificazione, intesa sia come stile che pattern architetturale,evidenziano un migloramento della trattabilità <strong>dei</strong> singoli problemi <strong>per</strong>mezzo della loro scomposizione, una limitazione alla crescita della complessità,la riduzione di costi di sviluppo senza diminuire la qualità, il migliore controllogranulare del sistema e una migliore comprensione del sistema.Soluzioni informatiche che <strong>per</strong>seguono parzialmente questa strada sono storicamenteclassificate sotto il termine “middleware”. Tali soluzioni tuttavia hannorivelato svantaggi significativi dipendenti dall’uso di implementazioni di tipoproprietario e/o troppo specializzate, non riusabili e non estendibili, ma sopratuttoincapaci di abbattere la complessità della progettazione pur alzando illivello di astrazione della programmazione di applicazioni distribuite.In questo lavoro si presenta <strong>InterDataNet</strong>, la visione e la progettazione di unmodello infrastrutturale <strong>per</strong> l’interdataworking. <strong>InterDataNet</strong> (IDN) è “visione”<strong>per</strong>ché ha l’ambizione di proporsi come sistema <strong>per</strong> l’intero<strong>per</strong>abilità sui dati,su<strong>per</strong>ando i limiti delle attuali architetture <strong>per</strong> la gestione distribuita di datie risorse, aprendo <strong>nuove</strong> <strong>frontiere</strong> verso lo spostamento dell’intelligenza dalle2


Introduzioneapplicazioni ai dati, l’auto-descrizione <strong>dei</strong> dati a supporto del loro significato, lapossibilità di creare più facilmente applicazioni a valore aggiunto, una maggioreagilità nella condivisione dell’informazione e nel collegamento <strong>dei</strong> dati.<strong>InterDataNet</strong> è diventato progetto, in quanto ha tradotto questa visione inuna progettazione tecnica e realizzativa del modello infrastrutturale stratificatoche integra funzioni di base a supporto dell’elaborazione delle risorse informative,capace in ultima analisi di abilitare lo sviluppo di applicazioni <strong>per</strong> il Webdel futuro, o Web Semantico. Semplificando alcuni concetti chiave di IDN èpossibile affermare che <strong>InterDataNet</strong> è una applicazione estesa della definizionemiddleware.<strong>InterDataNet</strong> è indipendente dal contesto applicativo, sebbene affronti i requisitidella gestione collaborativa dell’informazione, basandosi su un modello diriferimento, che mira a formalizzare le problematiche riguardanti la condivisioneintegrata dell’informazione in una infrastruttura, distribuita su larga scala.<strong>InterDataNet</strong> trova le sue radici nel 2000, come framework collaborativo,ma fu indicato con nomi diversi fino al 2005, anno in cui si delineò in manieracompleta e matura l’obiettivo nella sua forma attuale.Inizialmente, sotto il nome Collaborative O<strong>per</strong>ating System Architecture(COSA), l’attenzione fu rivolta sulla comunicazione e la progettazione di protocollidi livello applicativo in grado di soddisfare i requisiti di collaborazione. Laprincipale limitazione consisteva in una visione principalmente tecnologica.COSA fu in grado di evidenziare la necessità di un approccio interdisciplinareai problemi di condivisione dell’informazione, senza pienamente affrontarli.Questo punto di vista fu discusso dal 2003, nella mia tesi di laurea quinquennalein Ingegneria Informatica, riformulando il problema e specificando chiaramenteche le risorse collaborative trattate sono rappresentabili tramite documenti.In particolare lo scenario inizialmente studiato ed utilizzato come riferimentofu quello della Pubblica Amministrazione, <strong>per</strong> successivamente generalizzare adorganizzazioni.Fu avviato il primo tentativo di modellare le risorse documentali cercandodi dedurne, attraverso una loro astrazione, le caratteristiche universali, accreditatee universalmente riconosciute. Il modello dell’informazione fu chiamatoDistributed Delocalized Document Information Model (D3IM) e l’architetturain grado di realizzarlo Collaborative Information System Architecture (CISA).Nel corso degli anni 2006-2007 si approdò ad una piena sistematizzazione dellateoria del modello dell’informazione ed ai primi es<strong>per</strong>imenti implementativi.Prese più forza il concetto di una informazione sostenuta da una infrastrutturadi rete capace di essere sufficientemente versatile e modulare da abilitarei benefici attesi. Nacque la visione di data over Internet come attuazionedell’interdataworking.Adesso <strong>InterDataNet</strong> è descritto attraverso tre viste, in una forma che riteniamopiù maneggevole rispetto a quanto suggerito in RM-ODP (ReferenceModel of Open Distributed Processing), che coprono gli aspetti introdotti:1. IDN-IM (<strong>InterDataNet</strong> Information Model). È il modello dell’informazioneche rappresenta una generica risorsa, in maniera indipendente dallospecifico contesto e dalla tecnologia. Definisce i requisiti, le proprietà desi-3


Introduzionederabili, i principi e la struttura del documento <strong>per</strong> soddisfare una efficaceelaborazione collaborativa;2. IDN-SA (<strong>InterDataNet</strong> Service Architecture). È l’architettura stratificatadi servizi <strong>per</strong> la gestione di risorse rispondenti al modello IDN-IM. IDN-SA definisce le funzionalità di riferimento, i sottosistemi, i protocolli e leinterfacce <strong>per</strong> la realizzazione della collaborazione su un documento IDN.La stratificazione assume un ruolo determinante nella orchestrazione e coreografia<strong>dei</strong> 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’approccioROA (Resources Oriented Architecture);3. IDN-ON (<strong>InterDataNet</strong> Overlay Network). È l’architettura di rete in cuisono collocati gli apparati di interdataworking che erogano servizi di IDN-SA. Indica il modo con cui costruire o<strong>per</strong>ativamente reti Overlay Networkdi IDN (over Internet).Le specifiche progettuali delineate da queste tre viste consentiranno di affrontare,in contesto distribuito il problema della creazione, la modifica, l’integrazionee la gestione collaborativa di informazioni e dati in rete, <strong>per</strong>seguendola 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 (Stiliarchitetturali) presenta i principali stili architetturali e paradigmi infrastrutturalmenterilevanti, candidati alla realizzazione di servizi <strong>per</strong> la gestione <strong>dei</strong> datie 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 <strong>InterDataNet</strong>.Il Capitolo 3 (Analisi estesa <strong>dei</strong> requisiti) discute i settantatre requisitidi ordine generale che afferiscono a settori affini ad <strong>InterDataNet</strong>. Il Capitolo 4(Metodologia di progettazione) sviluppa in maniera critica i requisiti generali e lelinee guida progettuali, fornendo il primo approccio metodologico alla soluzionedel problema. Il Capitolo 5 (Modello del contesto) fornisce i principi descrittivifondanti l’ambiente in cui si dovranno realizzare le interazioni tra utenti e trautenti e risorse, così come dovrà essere recepito nella progettazione tecnica diIDN.Nella terza parte si discute la Progettazione di <strong>InterDataNet</strong>. Il Capitolo 6(L’architettura <strong>InterDataNet</strong>) definisce la teoria di IDN, con una panoramicadi alto livello sulle tre viste (IDN-IM, IDN-SA, IDN-ON). Il Capitolo 7 (Inter-DataNet Information Model) entra nel dettaglio del modello dell’informazionedefinendo i requisiti, le proprietà desiderabili, i principi e la struttura dellerisorse da un punto di vista astratto. Nel Capitolo 8 (<strong>InterDataNet</strong> ServiceArchitecture) si descrive il sistema <strong>dei</strong> servizi in maniera integrata ed unificata.4


IntroduzioneLa quarta parte, che va dal Capitolo 9 al Capitolo 13, illustra dettagliatamenteogni singolo servizio e sottosistema costituente la Service Architectureaffrontando 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, comeintegrazione ai concetti richiamati in IDN-IM e IDN-SA.I tredici capitoli così strutturati sono funzionali a soddisfare tre diversi tipidi 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 adalto livello; sequenza <strong>dei</strong> capitoli consigliata: Capitoli 4-5-6;• lettore “progettista e project manager” interessato alla visione d’insieme;sequenza <strong>dei</strong> capitoli consigliata: Capitoli 1-2-3-4-5-6-7-8;• lettore “sviluppatore” interessato ad implementare o potenziare specificheparti <strong>dei</strong> sottosistemi; sequenza <strong>dei</strong> capitoli consigliata: Capitoli 6-7-8,come base a cui aggiungere uno tra i seguenti: 9-10-11-12-13, in funzionedel compito di implementazione assegnato.5


Parte IAnalisi delle architetture


Capitolo1Stili architetturaliIl World Wide Web è usato da milioni di utenti ogni giorno <strong>per</strong> vari scopi:e-mail, lettura news, download di musica, acquisti on-line o semplicemente <strong>per</strong>cercare informazioni. Usando un browser l’utente può accedere alle informazionememorizzate su server Web dislocati nel mondo, avendo l’illusione che tutte leinformazioni siano locali al PC dell’utente.In realtà, il Web è un esteso sistema distribuito che appare come un singoloservizio, disponibile alla portata di un click. Da questa prospettiva (applicativa)il WWW si può considerare una infrastruttura, quale insieme di impianti edapparati che <strong>per</strong>mettono l’espletamento di un servizio.In questo capitolo saranno presentati stili e tecniche progettuali allo statodell’arte, <strong>per</strong> la realizzazione di servizi <strong>per</strong> la gestione <strong>dei</strong> dati e informazionicon 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 <strong>dei</strong> dati.Verrà dato peso alle configurazioni architetturali (semantica dello stile) e allepotenzialità che possono essere attuate nello sviluppo di applicazioni <strong>per</strong> lacondivisione collaborativa di informazioni.1.1 Service Oriented ArchitectureCon SOA si indica Service Oriented Architecture. La definizione di questaarchitettura non è univoca in quanto in letteratura esistono molteplici definizioni[MLM + 06a] [Erl05] [NL05] ed ancora http://www.wikipedia.org [Nat03],[Han07] [Arc05].Tutte concordano sul fatto che SOA è un paradigma architetturale <strong>per</strong> unamigliore flessibilità. Le SOA non sono definizioni di tecnologie o strumenti


Stili architetturaliService Oriented Architecturee non fanno riferimento a sistemi fisici. Si tratta di linee guida e paradigmiche rientrano nella accezione di design pattern architetturali. È un approccio,un modo di progettare che guida le decisioni quando si disegnano architetturesoftware.SOA nasce <strong>per</strong> far fronte alla necessità di flessibilità nelle moderne architetturesoftware. La flessibilità è necessaria <strong>per</strong> mantenere soluzioni di qualitàe rispettare i tempi del mercato che prevedono la predisposizione organizzativa<strong>dei</strong> progetti, <strong>dei</strong> processi, <strong>dei</strong> ruoli delle entità coinvolte dalla progettazione allarealizzazione.Le SOA suggeriscono come affrontare questi aspetti ed in particolare leproblematiche <strong>dei</strong> sistemi distribuiti, afferenti a differenti proprietari, e aiutaa sistematizzare l’approccio all’eterogeneità della codifica <strong>dei</strong> dati e dellacomunicazione.I grandi sistemi infatti usano piattaforme e linguaggi di programmazionedifferenti, girano su network che non sono controllati da un singolo responsabilee utilizzano ed organizzano capacità distribuite [MLM + 06a].A differenza di altri approcci ai sistemi distribuiti, le SOA si caratterizzano<strong>per</strong>ché tra le assunzioni di progettazione si accetta l’eterogeneità. Solitamentefino ad ora era tipico pensare di risolvere i problemi di compatibilità e d’intero<strong>per</strong>abilitàtra sistemi e applicazioni semplicemente adottando un’unica soluzioneed eliminando le differenze. Un approccio basato sullo stabilire a priori glistrumenti 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’intero<strong>per</strong>abilità e il basso accoppiamento (loose coupling).In SOA il concetto di servizio si concentra sull’astrazione e la modellazione<strong>dei</strong> processi del business: un servizio è l’interfaccia di una rappresentazione diuna qualche funzionalità reale, come ad esempio l’acquisizione di un ordini diun cliente.Conseguentemente a questo, un servizio deve essere progettato in modo chele sue interfacce possano essere comprese da chi le utilizza, dagli utenti finali, dainon addetti al settore, limitando che traspaiano aspetti tecnici e ciò che internamenteviene elaborato. Il vantaggio è che, a patto di avere una interfaccia bendefinita ed uniforme, non interessano più i dettagli dipendenti dalle specifichepiattaforme e l’eterogenità non rappresenta una preoccupazione <strong>per</strong> gli utentidel servizio.Connettere sistemi eterogenei significa intero<strong>per</strong>abilità. Sistemi eterogeneisono intero<strong>per</strong>abili se possono funzionare insieme, ad esempio scambiandosirisorse o invocando funzioni remote.Una intero<strong>per</strong>abilità efficiente ed efficace si ha se viene attuata una politicadi tolleranza ai guasti: se un sottosistema fondamentale <strong>per</strong> l’erogazione di unservizio non è diponibile allora tutto il sistema nel suo complesso è compromesso.In SOA la chiave <strong>per</strong> raggiungere l’intero<strong>per</strong>abilità è il disaccoppiamento,in quanto significa ridurre le dipendenze ai minimi termini. Il loose couplingcontribuisce alla tolleranza ai guasti e alla flessibilità, e grazie ad esso la progettazioneprende strade che evitano colli di bottiglia che ostacolerebbero la8


Stili architetturaliService Oriented Architecturescalabilità. Un basso accoppiamento si ottiene aumentando la modularità delsistema e mantenendo uniformi le interfacce.Un modo <strong>per</strong> introdurre il loose coupling è evitare la centralizzazione più diquanto 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 didisaccoppiamento.Accoppiamento StrettoConnessioni fisiche Punto-Punto Tramite mediatoreStile di Comunicazione Sincrono AsincronoData ModelTipi complessi comuniTipizzazione del sistema Forte DebolePattern di interazioneControllo della logica <strong>dei</strong>processiBindingPiattaformaTransazioniDeploymentVersionamentoNavigazione attraverso oggettiad albero complessiCentraleStaticoForti dipendenze dapiattaformaCommit in due fasiSimultaneoAggiornamenti esplicitiLoose coplingSolo tipi sempliciIncentrata sui dati, messaggiautocontenutiDistribuitoDinamicoIndipendente dalla piattaformaCompensazioneIn tempi differentiAggiornamenti ImplicitiFigura 1.1: Esempi pratici di loose coupling1.1.1 InfrastrutturaPer stabilire una SOA non è sufficiente introdurre servizi, intero<strong>per</strong>abilità edisaccoppiamento nella nostra architettura. È necessario trovare anche il giustogrado di centralità, aver cura <strong>dei</strong> processi, e progettare le infrastrutture.È nelle infrastrutture che si abilita l’intero<strong>per</strong>abilità. In SOA il mezzo che<strong>per</strong>mette di invocare servizi tra sistemi differenti è Entrerprise Service Bus(ESB). Un ESB è uno strato software di astrazione basato su un sistema dimessaggistica che è responsabile della trasformazione delle informazioni, dell’instradamento<strong>dei</strong> messaggi, del monitoraggio, del logging. Influisce inoltresulla sicurezza, l’affidabilità, l’amministrazione <strong>dei</strong> servizi e spesso anche contecnologie di workflow e business process modeling <strong>per</strong> l’integrazione <strong>dei</strong> flussiaziendali.Tutte le possibilità offerte dalle SOA si concretizzano nelle architetture, lequali formano un sistema funzionante e manutenibile. Per formalizzare un’architetturasi deve classificare i differenti tipi di servizi, decidere la quantità didisaccoppiamento, limitare il data model delle interfacce ai servizi, definire politiche,regole e pattern, chiarire ruoli e responsabilità, decidere l’infrastrutturatecnologica e quali standard usare.Nelle architetture è necessario identificare e formalizzare i processi. Per9


Stili architetturaliService Oriented Architectureprocesso si intende una generica sequenza di passi <strong>per</strong> soddisfare una necessitào raggiungere un qualche obiettivo.Ci sono diversi processi che entrano in gioco quando si progetta e si realizzauna SOA: i processi che modellano la business logic (BPM, Business ProcessModeling), i processi che definiscono il ciclo di vita di un servizio (Service Lifecycle)e quelli che determinano la produzione del software <strong>per</strong> i modelli ipotizzati(MDSD, Model-driven Software Development). Inoltre il procedimento di sistematizzaretutti i processi prende il nome di governance. Con questo termine cisi riferisce anche alle attività di ricerca di <strong>per</strong>sonale <strong>per</strong> lo sviluppo, <strong>dei</strong> sistemistiche si occu<strong>per</strong>anno della manutenzione delle macchine, <strong>dei</strong> responsabili del<strong>per</strong>sonale ovvero di stabilire le condizioni aziendali a contorno.1.1.2 DefinizioniPrima di analizzare in dettaglio il concetto di servizio è utile fare alcunichiarimenti sulla terminologia usata nelle Service Oriented Architecture.Si usano i termini quali provider e consumer <strong>per</strong> indicare i ruoli <strong>dei</strong> sistemicomunicanti:• provider è un sistema che implementa un servizio cosicché un altro sistemalo possa invocare;• consumer è un sistema che invoca un servizio.Per choreography si intende l’aggregare i servizi <strong>per</strong> formare processi cheimplementano la business-logic. La choreography definisce le regole e le politicheche <strong>per</strong>mettono ai servizi di collaborare. Ogni servizio coinvolto vede econtribuisce solo a una parte del processo.Per orchestration si intende il comporre più servizi in uno nuovo con un controllocentrale sull’intero processo, arbitrando tutti i sottosistemi partecipanti.1.1.3 ServiziIl termine servizio ha il significato di“attività svolta da qualcuno <strong>per</strong> qualcunaltro” e nello specifico in ambito SOA un servizio è una realizzazione di unafunzionalità del business con una tecnologia informatica che mette a disposizioneuna interfaccia specifica [OEH02].Il fine primario di un servizio è rappresentare un passo di una funzione delbusiness <strong>per</strong> il mondo reale, in altre parole i non addetti ai lavori devono esserecapaci di capire il suo compito e gli aspetti tecnici dovrebbero rimanere trasparenti.Esistono comunque servizi, classificati come tecnici, che non rispettanoquesto principio.Da un punto di vista applicativo un servizio ha una interfaccia <strong>per</strong> scambiaremessaggi riguardanti lo stato di una qualche entità. Da questa osservazioneYefim V. Natis afferma [Nat03]: “Un nome migliore <strong>per</strong> le SOA sarebbe InterfaceOriented Architecture”.Spesso la creazione di un’architettura software basata su SOA comincia dalladefinizione di un’interfaccia sotto la quale si costruiscono le applicazioni.10


Stili architetturaliService Oriented ArchitectureI servizi possono essere caratterizzati da molti tipi di attributi, tuttavia nonè chiaro quali siano obbligatori e quali opzionali. Si può avere a che fare conservizi 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 serviziol’essere auto-contenuto. Alcune dipendenze tuttavia non sono eliminabili quindiil requisito va interpretato come riduzione delle dipendenze ai minimi terminied è quindi strettamente collegato al requisito di disaccoppiamento.L’interfaccia <strong>dei</strong> servizi nasconde i dettagli implementativi all’utilizzatore,<strong>per</strong> questo viene suggerita un’unica chiamata al servizio che trasferisca tutte leinformazioni. Una grana grossa aiuta a separare la struttura interna <strong>dei</strong> dati diun provider <strong>per</strong> servizi dalla sua interfaccia esterna, ma il problema è definirequando la grana debba essere grossa, infatti si ha spesso un’elaborazione di datiche non sono necessari, con conseguente spreco di risorse e di tempo.Un’altra proprietà importante è la visibilità. Prima di effettuare una chiamataad un servizio è necessario che il servizio sia stato reso visibile e scopribile.Un servizio stateless non mantiene traccia tra una chiamata e un’altra. Unservizio può avere uno stato dal punto di vista tecnico e dal punto di vista delbusiness. Se i servizi debbano o meno non mantenere uno stato dipende dallospecifico contesto.L’idempotenza è l’abilità di rieseguire un’o<strong>per</strong>azione se non siete sicuri chequesta sia stata completata. Se il servizio è idempotente, dopo una richiesta allaquale non si è ricevuto risposta di conferma, si può ripetere la chiamata senzatemere che questa comporti effetti indesiderati.Ci sono casi in cui ottenere l’idempotenza è difficile, ma in un’architetturaSOA semplifica molti aspetti legati alla interazione, quindi è sempre opportunoporsi l’obiettivo di realizzare servizi che possiedano questa proprietà.Un servizio SOA dovrebbe essere riutilizzabile. Evitare la ridondanza è unobiettivo generale dello sviluppo software. Idealmente ogni funzionalità dovrebbeessere implementata una sola volta. Un caso tipico di riutilizzo in ambitoSOA è quando tutti i sistemi chiamano lo stesso servizio <strong>per</strong> una certa funzione.Ci sono <strong>dei</strong> limiti a quest’approccio che principalmente dipendono dalle esigenzedi <strong>per</strong>formance e quindi è opportuno individuare il giusto equilibrio tra riutilizzoe prestazioni.Una funzionalità, quando necessario, può essere suddivisa in passi più elementariche a loro volta possono essere esposte con servizi. Questi possono quindiessere composti tra di loro. La composizione è alla base della modellazione<strong>dei</strong> processi del business.Inoltre, i servizi possono essere caratterizzati da attributi non funzionalicome la Quality of Service (QoS), le condizioni di utilizzo possono essere vincolateda un Service Level Agreement (SLA) e possono avere un comportamentosemantico 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 appartenentia organizzazioni diverse, altrimenti la complessità aggiunta potrebbecomportare un costo inutile. Inoltre SOA appare una definizione orientata agli11


Stili architetturaliREpresentational State Transferaspetti di produzione ed ingegneria del software, tanto che sono molteplici leassociazioni con standard tecnologici come i Web Service [TP02].1.2 REpresentational State TransferDiversamente a quanto avviene <strong>per</strong> il termine SOA ed il termine Web ofData, il Representional State Transfer, a cui ci si riferisce con l’acronimo REST,ha una origine ed una definizione riconosciuta e legittimata nel capitolo cinquedella tesi di dottorato di Roy T. Fielding, pubblicata nel 2000 [Fie00].La sopra esposta precisazione è necessaria in quanto REST è stato da moltimale interpretato ed usato erroneamente generando molteplici interpretazioni,quando l’unica interpretazione è quella di Fielding.Il REST è uno stile <strong>per</strong> architetture software e precisamente è lo stile delWeb. È infatti è nato durante la stesura del protocollo HTTP di cui Fielding ècoautore [FGM + 99]. Il REST un modello astratto, ed il Web è una architetturaconcreta che si basa sui principi di questo modello. Il modello è definito da uninsieme di vincoli architetturali, che applicati ad un sistema lo rendono RESTful:il Web è RESTful non soltanto <strong>per</strong>ché rispetta questi vincoli, ma <strong>per</strong>ché è il casospecifico dal quale sono stati dedotti i principi <strong>per</strong> definire il modello.Il primo vincolo che una architettura RESTful deve rispettare è l’interazionetra componenti di tipo client-server. Il sistema è fatto di componenti classificaticome server, che offrono servizi e rimangono in ascolto di richieste, oppure client,i quali fruiscono <strong>dei</strong> servizi e utilizzano un connettore <strong>per</strong> inviare richieste. Ilconcetto di connettore in REST è un elemento che incapsula le attività di accessoalle 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 risorsapossono avere uno stato, ma il REST pone questo vincolo specificatamentesulla comunicazione: ogni richiesta da parte di un client deve contenere tuttele informazioni necessarie affinché possa essere compresa, e non può trarrevantaggio da contenuti memorizzati nel server. Lo stato della sessione è quindimantenuto interamente nel client. L’applicazione di questo principio migliorala visibilità, poiché una interazione che contiene tutte le informazioni può esserepiù facilmente monitorata, ed incrementa l’affidabilità e la scalabilità delsistema. L’overhead introdotto dalla ripetizione <strong>dei</strong> dati può <strong>per</strong>ò portare adun peggioramento delle prestazioni.Per migliorare l’efficienza <strong>dei</strong> sistemi, in REST si usa il la cache, ovvero unclient, <strong>per</strong> richieste ripetute, può usare una risposta memorizzata in precedenza,eliminando così la necessità di alcune interazioni. Questo vincolo richiedeche 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 basatesul networking, è il vincolo di interfaccia uniforme tra componenti. Questoprincipio disaccoppia le implementazioni dalle funzionalità, semplifica il sistemae migliora la visibilità delle interazioni, ma degrada l’efficienza poiché le infor-12


Stili architetturaliREpresentational State Transfermazioni sono trasferite in una forma generalizzata piuttosto che in una formaspecificatamente progettata <strong>per</strong> i bisogni applicativi.Una interfaccia uniforme è efficiente <strong>per</strong> la trasmissione di i<strong>per</strong>media. Questoprincipio impone altri vincoli sulle funzionalità offerte dalla interfaccia diun sistema RESTful: l’identificazione delle risorse e la loro manipolazione deveavvenire tramite una rappresentazione. Una risorsa è una qualsiasi informazionedotata di nome: un documento, un’immagine, un oggetto non virtuale(una <strong>per</strong>sona, un animale, una città). In REST si usano resource identifier <strong>per</strong>identificare particolari risorse coinvolte nelle interazioni tra i componenti delsistema, i quali compiono azioni su di esse usando una resource representation<strong>per</strong> catturarne lo stato. Una rappresentazione in REST è una sequenza di bytepiù una sequenza di metadati che descrivono questi byte.Un’architettura REST è stratificata. Questo <strong>per</strong>mette di adattare i sistemiai requisiti di scalabilità <strong>dei</strong> grandi network come Internet. La stratificazione<strong>per</strong>mette alle architetture di essere composte di layer gerarchici, così da disaccoppiarnei componenti e promuovere l’indipendenza tra stati non adiacenti, ed ivari strati possono incapsulare servizi legacy od offrire nuovi servizi ai client preesistenti.D’altro canto, la stratificazione incrementa la complessità <strong>dei</strong> sistemi,aggiunge overhead ed aumenta la latenza nell’elaborazione <strong>dei</strong> dati.L’ultimo vincolo che Fielding aggiunge al ad un sistema REST deriva dallostile “code-on-demand”, <strong>per</strong> il quale un sistema RESTful <strong>per</strong>mette di estenderele funzionalità scaricando ed eseguendo <strong>nuove</strong> istruzioni in forma di applet oscript. Questo vincolo è opzionale, <strong>per</strong>ché <strong>per</strong>mette di estendere le funzionalitàlimitate dal vincolo di interfaccia uniforme, ma riduce la visibilità del sistema.Questo termine è stato usato spesso <strong>per</strong> descrivere una tipologia di serviziWeb non basati su SOAP, ma come abbiamo visto il REST non prescrive l’usodi particolari protocolli o standard e non specifica quali o<strong>per</strong>azioni deve offrireuna interfaccia, purché questa sia uniforme e sia orientata alle risorse. Sottoquesto aspetto REST può essere posto su un piano di confronto delle ServiceOriented Architecture.1.2.1 Sintesi delle proprietàIndipendentemente dalla interpretazione della definizione originale o di successivederivazioni in sintesi REST deve possedere le seguenti proprietà fondamentali:• Statelessness: la comunicazione deve essere senza stato affinchè ogni richiestadal client debba contenere tutte le informazioni necessarie al server <strong>per</strong>interpretare correttamente la richiesta. Osserviamo che il server può comunquemantenere uno stato ed utilizzare le informazioni di stato (<strong>per</strong> leistanze) <strong>per</strong> elaborare correttamente la richiesta. La questione importanteè che il client non debba dipendere dal server <strong>per</strong> il contesto della richiesta.• Cacheability: ogni risorsa trasferita tra client e server deve essere marcatacome cacheable o altrimenti il minimo possibile non-cacheable.• Uniform interface: un sistema RESTful deve possedere una interfacciauniforme con le seguenti proprietà:13


Stili architetturaliResource 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 “DivinaCommedia”, etc): Una URI nel senso di “Universal ResourceIndicator”.– Manipolazione delle risorse attraverso la rappresentazione: una rappresentazioneconsiste in una serie di byte (es. un numero in formatotestuale della tem<strong>per</strong>atura con in gradi centigradi, una immagineJPEG di una co<strong>per</strong>tina di un libro, un documento XML contenentetutte le informazioni metereologiche, un frammento di XHTML diuna lista di attributi di libri). Notiamo che non deve esistere unarelazione biunivoca tra la rappresentazione e la risorsa e la risorsastessa. La risorsa è disaccoppiata dalla sua rappresentazione.– Self-Descriptive Messages Meta-data, pure and simple: una rappresentazionedi una risorsa possiede sia dati che metadati. I metadatipossono essere indipendenti dalla rappresentazione, cioè possonoavere rappresentazioni alternative.– Hy<strong>per</strong>media as the engine of application state: se applicabile, dovrebberoesistere alcuni tipi di link <strong>per</strong> indicare lo stato successivodell’applicazione in riferimento alla rappresentazione corrente inviataal client. L’esempio più ovvio può essere che una request POSTche crea o modifica una risorsa deve ritornare un puntatore ad unarappresentazione di quella risorsa in una pagina HTML, oppure inmaniera 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 confinidel layer a cui è connesso. Ad esempio, il cient verso il quale il servizioRESTful sta rispondendo, può non essere un client nel senso stretto deltermine: può essere un altro server (es. un proxy). Un progettista diservizi RESTful non deve preoccuparsene, deve trattarlo come un cliented interpretare solamente le richieste e non chi le formula.• Vincoli opzionali allo stile REST: un sistema REST può essere vincolatoda code-on-demand. Significa che il codice viene scaricato ed eseguitodal client (es. Javascript, Flash, Java, etc.) come parte integrante dellarappresentazione della risorsa.1.3 Resource Oriented ArchitectureNel panorama <strong>dei</strong> Web Service [Jos07], RESTful è stato usato come aggettivo<strong>per</strong> classificare una tipologia di servizi basati su un approccio che usa i metodiHTTP <strong>per</strong> eseguire o<strong>per</strong>azioni remote, in contrapposizione all’approccio tipicoWSDL, SOAP. Questi servizi hanno riscosso un discreto interesse, soprattutto da14


Stili architetturaliResource Oriented Architectureparte di sviluppatori orientati alla realizzazione di servizi di largo consumo <strong>per</strong>il Web, e quindi non interessati alla costruzione di complessi sistemi enterprise 1 .L’origine di questa definizione discende dalla interpretazione di HTTP, qualeriferimento di interfaccia uniforme, così come richiesto dallo stile REST. Mamolti servizi etichettati come RESTful non rispettano tutti i vincoli di questostile e così i puristi di REST filosofia non esitano a definirli servizi “accidentallyRESTful”, servizi “low REST” o “REST-RPC”.In questo panorama confuso, si inserisce Resource Oriented Architecture(ROA). ROA, presentata in [RR07], prescrive delle linee guida <strong>per</strong> realizzarearchitetture RESTful. Gli autori adottano questo termine <strong>per</strong> designare architettureche rispettano i principi del REST, ma mentre quest’ultimo specifica solocriteri di progettazione generici, le Resource Oriented Architecture sono esplicitamentelegate alle tecnologie del Web. Nelle ROA le risorse sono indirizzateda URI e l’interfaccia uniforme utilizzata è HTTP.Gli URI in questo contesto, devono essere descrittivi, ovvero deve esistereuna corrispondenza intuitiva tra questi e le risorse che indirizzano, e devonopossedere uno schema sintattico. La strutturazione <strong>dei</strong> nomi <strong>per</strong>mette ai clientdi costruire gli indirizzi delle risorse alle quali desiderano accedere. Ci sono treregole base <strong>per</strong> progettare gli URI:• si usa il path <strong>per</strong> codificare la gerarchia(es. /parent/child);• quando non esiste gerarchia si usa la punteggiatura(es. //parent/child1;child2);• si utilizzano le query <strong>per</strong> le variabili che rappresentano l’input di unalgoritmo(es. /search?q=jellyfish&start=20).Nelle ROA ci sono solo poche o<strong>per</strong>azione base che si possono eseguire su unarisorsa, e queste sono definite dal protocollo HTTP:• con HTTP GET si recu<strong>per</strong>a la rappresentazione di una risorsa;• HTTP POST serve <strong>per</strong> creare <strong>nuove</strong> risorse;• si modificano le risorse utilizzando HTTP PUT;• HTTP DELETE cancella le risorse.Le ROA considerano parte dell’interfaccia uniforme anche i seguenti metodidel protocollo HTTP: HEAD e OPTIONS.Il vantaggio di questa interfaccia è che il metodo GET è safe, quindi unarichiesta che utilizza questo metodo non cambia nessun stato nel server. GET,1 È stato evidenziato un difficoltà di base nella implementazione di Web Service comeriportato in “Big Web Service Are Not Simple” [RR07] e “Am I Stupid or Is Java Web ServicesReally Hard?” [Han07].15


Stili architetturaliOASIS DataWebPUT e DELETE godono della proprietà di idempotenza: un o<strong>per</strong>azione idempotentesu una risorsa non cambia lo stato della risorsa se viene ripetuta in manieraidentica. La seconda richiesta e le seguenti lasceranno la risorsa esattamentenello stato in cui lo ha lasciato la prima.La safety e l’idempotenza sono importanti <strong>per</strong>chè <strong>per</strong>mettono ai client difare 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ù complessiWeb Service basati su SOAP, ma le funzionalità offerte coprono tutti gli aspettinecessari 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 <strong>nuove</strong> specifiche <strong>dei</strong> WSDL supportano la definizione delle interfaccesu HTTP in stile ROA [Chi07], e forse in futuro si potranno estenderealcuni standard <strong>dei</strong> Web Service anche ai servizi sviluppati con questo stile.1.4 OASIS DataWebIn questa sezione verrà analizzato in dettaglio l’architettura XDI/XRI, acronimiche vanno ad indicare rispettivamente l’XRI Data Interchange e l’eXtensibleResource Identifier. Tale architettura definisce una modalità modalità diidentificazione e di risoluzione di nomi in rete che si pone ad un livello di astrazionepiù elevato rispetto al Domain Name System (DNS)[Moc87a, Moc87b], inmodo tale da poter indirizzare nomi sia <strong>per</strong>sistenti che non (con il termine ’<strong>per</strong>sistente’si intende che il link al nome puntato si mantiene anche nel caso in cuiil target puntato si sposti, cambi nome o cambi proprietario). Questo <strong>per</strong>mettedi su<strong>per</strong>are i limiti del Web attuale circa l’interscambio di dati distribuiti conun nuovo approccio <strong>per</strong> la condivisione di dati distribuiti che abilita i principidel World Wide Web (WWW) attuale alla condivisione e collegamento di datiattraverso domini e applicazioni diverse.Il Dataweb è un progetto open iniziato nel 1995 <strong>per</strong> fornire accesso ai datinello 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.WebDatawebInternetFigura 1.2: Lo strato Dataweb indicato come evoluzione del Web16


Stili architetturaliOASIS DataWeb1.4.1 L’architettura XDIXDI è un nuovo servizio generalizzato ed estendibile <strong>per</strong> la condivisione didati distribuiti sviluppato dall’OASIS XDI Technical Committee; OASIS sta <strong>per</strong>Advancement Of Structured Information Standards, ed è un’organizzazione senzascopi di lucro nata <strong>per</strong> l’avanzamento <strong>dei</strong> sistemi d’informazione strutturati.XDI usa gli XRI[KW05], ovvero un tipo di identificatore astratto sviluppato anch’essodall’OASIS. Lo scopo di XDI è abilitare i dati <strong>per</strong> l’identificazione, scambio,collegamento e sincronizzazione fra sorgenti diverse, usando documenti ineXtensible Markup Language (XML) <strong>per</strong> il “machine-readable” Dataweb, analogamentea come vengono usati i documenti in Hy<strong>per</strong> Text Markup Language(HTML)[FGM + 99] <strong>per</strong> il “human-readable” Web.Ad oggi non è stata ancora sviluppata nessuna specifica formale, poiché <strong>per</strong>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’o<strong>per</strong>a un modello basato sul Resource Description Framework(RDF) [Bec04] che definisce un formalismo <strong>per</strong> la rappresentazione dimetadati, introducendo maggiore capacità espressiva in modo da strutturarel’informazione contenuta nelle risorse in maniera comprensibile dalle macchine.Tale formalismo è basato sul concetto di “statement” (asserzioni), codificate intriple: soggetto, predicato, oggetto. L’idea è quella di poter utilizzare una strutturadati organizzata secondo un grafo orientato: sui nodi sono poste le risorse(soggetto ed oggetto dello statement), mentre gli archi del grafo rappresentanole relazioni (predicato dello statement).Per la definizione tecnica del modello che utilizza RDF è stato proposto XDIRDF Model [RST08], il quale getta le basi <strong>per</strong> la specifica XDI 1.0. I puntichiave che caratterizzano XDI sono tre [RS04]:• Dataweb Links: collegamenti <strong>per</strong> il controllo del flusso <strong>dei</strong> dati.• Dataweb Addressing: indirizzamento tramite gli identificatori XRI.• Dataweb Representation: definizione di un formato <strong>per</strong> lo scambio, link esincronizzazione di dati codificati in XML.Dataweb LinksUna delle differenze principali tra l’architettura del Web e quella del Datawebè il potenziamento del link. Nel Web i link sono soltanto “handle” unidirezionalitra risorse HTML che <strong>per</strong>mettono ad un documento di essere indirizzato edacceduto da un browser (pull); i link del Dataweb possono invece essere consideraticome <strong>dei</strong> connettori bidirezionali che collegano risorse XML <strong>per</strong>mettendoil flusso in entrambe le direzioni (push o pull). Il flusso <strong>dei</strong> dati può quindi esserecontrollato automaticamente da regole chiamate XDI link contracts. Questiconcetti sono schematizzati in figura 1.3 [RS04].I link contracts sono documenti Dataweb che descrivono le condizioni diautorizzazione e <strong>per</strong>messo <strong>per</strong> l’interscambio di dati condivisi tra due o piùsoggetti XDI, proprio come nel mondo reale i contratti legali esprimono i terminidi accordo tra due o più parti.17


Stili architetturaliOASIS DataWebHTMLHTMLXML /XDIXML /XDIXDI linkcontractHTML HTML HTML HTMLXML /XDIXML /XDIXML /XDIXML /XDIHTML HTML HTML HTMLXML /XDIXML /XDIXML /XDIXML /XDIWeb site A Web site B Dataweb site A Dataweb site BFigura 1.3: Link contracts <strong>per</strong> la condivisione dati a due vieConsultando [Bec04], si può vedere come gli archi (predicati) del grafo RDF,relativo all’architettura XDI, rappresentino le relazioni tra nodi (risorse), utilizzandospecifici 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é stessoI link contracts sono caratterizzati da:• traversing bidirezionale: è la differenza principale, che è stata sopra discussa.Il Web <strong>per</strong>mette solo il pull, mentre il Dataweb sia il push che ilpull.• <strong>per</strong>sistenza: una link Web è o attivo o inattivo, quindi o fornisce unarisorsa oppure produce un errore. I link contracts Dataweb usano inveceidentificatori XRI <strong>per</strong>sistenti che <strong>per</strong>mettono al link di ristabilirsi anchese 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 linkcontract, che <strong>per</strong>mette controllo globale e granulare di tutti i dati chestanno passando.I link Dataweb sono inoltre associati ai seguenti concetti:• authority: <strong>per</strong>mette di stabilire l’entità che controlla i dati condivisi.• authentication: <strong>per</strong>mette alle due parti di scambiarsi informazioni inerentila loro identità.• authorization: <strong>per</strong>mette di stabilire chi ha i privilegi di accesso ai dati.18


Stili architetturaliOASIS DataWeb• privacy: stabilisce il modo in cui possono essere usati i dati e da chi.• termination: stabilisce cosa accade quando la condivisione <strong>dei</strong> dati termina.In conclusione si può dire che i Dataweb link contracts <strong>per</strong>mettono la mediazione<strong>dei</strong> dati distribuiti allo stesso modo in cui il Web <strong>per</strong>mette l’accesso aicontenuti. Si tratta quindi di una soluzione che modella e scala il mondo realedella condivisione dati.1.4.2 Dataweb AddressingNel Web classico si utilizzano <strong>per</strong> l’indirizzamento gli Uniform Resource Identifier(URI) [BLFM05], e nel Dataweb basato su protocollo XDI/XRI si utilizzanogli identificatori XRI, un sottoinsieme di essi. Grazie agli XRI è possibilefarlo <strong>per</strong> ogni singolo elemento <strong>dei</strong> dati, fino al più piccolo attributo. In tabella1.1 [RS04] vengono comparati i requisiti di indirizzamento <strong>per</strong> la condivisionedati (Dataweb) con quelli <strong>per</strong> la condivisione <strong>dei</strong> contenuti (Web).Tra i requisiti visti in tabella, il più interessanti è la cross-references, di cuipossiamo vedere le potenzialità con un esempio. Un sistema bibliotecario usale URN (Uniform Resource Name, un particolare tipo di URI che identificauna risorsa mediante un nome in un particolare dominio di nomi), nello spazio<strong>dei</strong> nomi ISBN (International Standard Book Number) <strong>per</strong> identificare libri, esottodomini DNS <strong>per</strong> identificare la sua collocazione; la sintassi URI HTTP nonfornisce uno schema sintattico. L’XRI Cross-Reference risolve questo problema,<strong>per</strong>mettendo alla biblioteca di indirizzare qualunque libro alla sua collocazione.Per esempio:xri://ingegneria.biblioteca.esempio.com/(urn:isbn:0-395-36341-1)xri://architettura.biblioteca.esempio.com/(urn:isbn:0-395-36341-1)xri://medicina.biblioteca.esempio.com/(urn:isbn:0-395-36341-1)Questa possibilità di creare identificatori strutturati ed autodescriventi puòessere estesa a molti altri usi: <strong>per</strong> esempio, se la biblioteca vuole indicare il tipodi libro disponibile, può stabilire un semplice dizionario XRI di tipi di libri ecostruire XRI che includono questi metadati:xri://ingegneria.biblioteca.esempio.com/(urn:isbn:0-395-36341-1)(+hardcover)xri://ingegneria.biblioteca.esempio.com/(urn:isbn:0-395-36341-1)(+softcover)xri://ingegneria.biblioteca.esempio.com/(urn:isbn:0-395-36341-1)(+reference)In aggiunta alle <strong>nuove</strong> capacità della sintassi XRI, XDI supporta i sinonimiXRI, cioè il modo in cui XDI può mantenere sia gli XRI riassegnabili humanfriendly(i-names), sia gli XRI <strong>per</strong>sistenti machine-friendly (i-numbers) <strong>per</strong> lastessa risorsa. Per quanto riguarda i dettagli sugli i-names e gli i-numbers ela loro risoluzione si rimanda a paragrafo 1.4.3. In conclusione si può dire chel’indirizzamento Dataweb è il modo in cui XDI riesce a risolvere uno <strong>dei</strong> problemipiù importanti <strong>per</strong> l’integrazione delle applicazioni: mapping e condivisione <strong>dei</strong>dati tra domini diversi.19


Stili architetturaliOASIS DataWebREQUISITI Web (URI) Dataweb (XRI)Persistenza Nessuna soluzione Sono supportatistandard <strong>per</strong> l’indirizzamentoidentificatori sianel caso <strong>per</strong>sistenti chedi cambio locazione riassegnabilio di nome di unarisorsaContesto globale Contesto globale limitatoCi sono quattro conficatorsonale,<strong>per</strong> un identitestiglobali: <strong>per</strong>-<strong>per</strong> organizzazioni,generale especialeCross-references Non è consentitol’annidamento diURI <strong>per</strong> <strong>per</strong>metterela condivisione diidentificatori tradomini diversiSelf-references Non c’è nessuna sintassi<strong>per</strong> riferirsi alconcetto rappresentatoda un identificatoreInternazionalizzazione Parzialmente internazionalizzato.Le IRI (Internatio-Estensibilitànalized ResourceIdentifiers) [DS05]sono in via disviluppoEstensibile attraversonuovi schemi URIe protocolli di risoluzioneTabella 1.1: Requisiti XDI di indirizzamentoPermette l’annidamentodi XRI (edanche di URI)Fornisce una sintassistandard <strong>per</strong> la selfreferencesÈ pienamente compatibilecon le IRIEstensibile entro loschema XRI e protocollodi risoluzione20


Stili architetturaliOASIS DataWebDataweb RepresentationIl terzo blocco chiave di XDI è l’XDI Meta-schema. HTML è fondamentale<strong>per</strong> il Web in quanto fornisce un semplice formato indipendente dall’applicazione,dal dominio e dal linguaggio <strong>per</strong> la rappresentazione di contenuti. Permantenere questa importantissima caratteristica il Dataweb adotta XML. Loscopo dell’XDI Meta-schema è quello di fornire un formato semplice ed universale<strong>per</strong> lo scambio, collegamento e sincronizzazione di dati codificati in XML(oppure riferimenti ad altri dati indirizzabili tramite URI), vale a dire una LinguaFranca [BHD + 04] in cui ogni elemento <strong>dei</strong> dati è identificato con uno o piùXRI e che <strong>per</strong>mette quindi a <strong>per</strong>sone ed organizzazioni di condividere dati.La forza di questo approccio è che le pagine Dataweb definiscono un unicoformato in cui tutti i dati codificati in XML possono essere condivisi indipendentementedall’applicazione e dal dominio da cui sono stati creati. Inoltreusando i link contracts, le pagine possono essere sincronizzate e collegate <strong>per</strong>sistentementeed ciascuna può mostrare la precisa gerarchia <strong>per</strong> ogni elemento<strong>dei</strong> dati.1.4.3 Extensible Resource IdentifierXRI è uno schema ed un protocollo di risoluzione <strong>per</strong> identificatori astratticompatibile con le URI (e con le IRI), sviluppato dall’OASIS XRI TechnicalCommittee [WRM + 08]. Il suo scopo è quello di definire una sintassi standard<strong>per</strong> identificatori indipendenti dal dominio, dalla locazione, dall’applicazione edal trasporto, in modo tale da essere condivisi su qualunque dominio, directory eprotocollo. Come mostrato in figura 1.4 XRI fornisce un livello uniforme di identificatori<strong>per</strong> ogni tipo di risorsa, posizionandosi sopra i sistemi di indirizzamentoesistenti sia nel mondo telematico che fisico.XRIDNSIPNumeri ditelefonoIndirizzipostaliIndirizzifuturiRisorse WebFigura 1.4: Strato uniforme XRILa specifica XRI 2.0 attualmente non è ancora considerata uno standard OA-SIS a causa della votazione sfavorevole dovuta soprattutto all’intervento dellaWorld Wide Web Consortium (W3C) Techinical Architecture Group. Le URIsono stati identificatori di grande successo <strong>per</strong> Internet, ma tuttavia il recentesviluppo del Web ha portato <strong>nuove</strong> esigenze che la sintassi di quest’ultime nonera in grado di soddisfare. Una di queste, l’internazionalizzazione, è stata ul-21


Stili architetturaliOASIS DataWebtimamente risolta grazie allo sviluppo delle IRI (identificatori che estendono ilset di caratteri <strong>per</strong> supportare l’intero range <strong>dei</strong> caratteri Unicode/ISO 10646).Con la grande crescita di XML e <strong>dei</strong> Web services, e l’attuale necessitàdi automazione del Web verso le comunicazioni machine-to-machine, è diventatonotevolmente importante essere in grado di identificare una risorsaindipendentemente dalla locazione fisica e dal protocollo, in modo da:• creare identificatori indipendenti dal dominio, nello stesso modo in cui idocumenti XML definiscono un formato <strong>per</strong> i dati che sia indipendentedal dominio;• mantenere un link <strong>per</strong>sistente alla risorsa anche nel caso in cui quest’ultimacambi locazione;• mappare gli identificatori usati <strong>per</strong> identificare una risorsa in un dominio,con altri sinonimi usati <strong>per</strong> identificare la stessa risorsa nello stesso dominio(o in altri domini).Questi requisiti sono stati recepiti dall’OASIS Technical Committee, il cuiobbiettivo è di creare un nuovo tipo di identificatori costruiti sulle specifichedelle IRI, allo stesso modo in cui esse sono costruite sulle URI (figura 1.5).XRI (Astratto)IRI (Internazionalizzato)URI (Uniforme)Estende la sintassiEstende il set di caratteriSpecifica di baseFigura 1.5: Relazione tra XRI, IRI e URIL’OASIS XRI Technical Committee ha sviluppato anche un protocollo dirisoluzione basato su Hy<strong>per</strong> Text Transfer Protocol (HTTP) e risorse chiamateeXtensible Resource Descriptor Sequence (XRDS). Per quanto riguarda le specifichetecniche, ci sono tre documenti sviluppati dall’OASIS che descrivono indettaglio lo schema XRI:• XRI Syntax document [RMD + 05] definisce in quattro punti la sintassinormativa con la quale gli identificatori XRI estendono la sintassi delleIRI:1. un identificatore XRI è progettato <strong>per</strong> essere o <strong>per</strong>sistente o riassegnabile,diversamente dalla normale sintassi IRI;2. cross-references: i riferimenti XRI sono abilitati a contenere altririferimenti XRI o IRI come sottosegmenti sintatticamente delimitati;3. global Context Symbols (GCS): simboli che servono a definire uncontesto globale astratto <strong>per</strong> un identificatore;4. federazione standardizzata: gli identificatori federati sono quelli delegatiattraverso autorità multiple, proprio come i nomi DNS. La sintassiXRI standardizza la federazione degli identificatori <strong>per</strong>sistenti eriassegnabili.22


Stili architetturaliOASIS DataWeb• XRI Resolution document [WRM + 08] definisce un protocollo di risoluzione<strong>per</strong> XRI basato su HTTP, che include sia la risoluzione genericache quella fidata. Visto che gli identificatori XRI possono essere usatiin un’ampia varietà di domini ed applicazioni, un singolo meccanismo dirisoluzione non sarebbe appropriato. Perciò nell’interesse dell’intero<strong>per</strong>abilitàla specifica definisce un semplice e generico formato descrittivo <strong>per</strong> larisorsa, chiamato documento XRDS. La specifica definisce inoltre un protocollo<strong>per</strong> richiedere documenti XRDS <strong>per</strong> mezzo delle primitive HTTPsu risorse indicate con URI, ed infine un protocollo <strong>per</strong> la risoluzione degliXRI utilizzando documenti XRDS ed URI HTTP.• XRI Metadata document [RMD + 05] definisce cinque caratteri GCS chepossono essere usati <strong>per</strong> esprimere il contesto globale astratto di un identificatore.Uno di essi, “$”, è riservato <strong>per</strong> specificare il contesto globale,cioè <strong>per</strong> indicare che ci si sta riferendo ai metadata; gli altri GCS servonoad 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 <strong>per</strong> descrivere un identificatore. Cisono quattro tipi di identificatori metadata:1. Language metadata ($l) specifica il linguaggio umano nel quale unidentificatore 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 unasequenza di identificatori <strong>per</strong> la stessa risorsa logica;4. Annotation metadata ($-) <strong>per</strong>mette di aggiungere annotazioni humanreadable ad un XRI o ad un suo sottosegmento senza influenzare larisoluzione.Gli identificatori XRIXDI.org è un’organizzazione pubblica e senza scopo di lucro che gestisce l’architetturaXDI/XRI, ed ha sviluppato un’infrastruttura di identificatori basatiproprio su essa. XRI vuole risolvere il problema di mantenere indirizzi <strong>per</strong>sistenti<strong>per</strong> <strong>per</strong>sone ed organizzazioni anche nel caso in cui queste cambino locazioneo 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), tuttaviaciò che rende unico lo strato XRI è che esso offre una sintassi unica ed uniforme<strong>per</strong> due diversi tipi di identificatori:• i-numbers: sono identificatori machine-friendly che sono associati ad unarisorsa (<strong>per</strong>sona, organizzazione, file, progetto digitale, ecc.), e non riassegnabili.Ciò vuol dire che un i-number può essere sempre usato <strong>per</strong>indirizzare una risorsa <strong>per</strong> tutto il tempo in cui essa rimane disponibileda qualche parte sulla rete. Gli i-numbers sono progettati <strong>per</strong> essereprocessati in modo efficiente dai router di rete.23


Stili architetturaliOASIS DataWeb• i-names: sono identificatori human-friendly che assomigliano a nomi didominio ma sono più semplici e facili da usare <strong>per</strong> le <strong>per</strong>sone. Gli i-names,proprio come i nomi di dominio, possono essere trasferiti o riassegnatidall’utente verso altre risorse. Per esempio un’organizzazione che necessitadi cambiare il suo nome può cedere il suo vecchio i-name ad un’altraorganizzazione, mentre entrambe possono mantenere il loro univoco e <strong>per</strong>sistentei-number. È proprio questo concetto che differenzia un i-name daun nome di dominio, ovvero la presenza di un suo sinonimo (equivalente)<strong>per</strong>sistente i-number.I concetti sopra esposti sono schematizzati in figura 1.6.Nome human friendlyXRI i-namesXRI i-numbersIndirizzo machinefriendly(<strong>per</strong>sistente)Nome applicativo(riassegnabile)Indirizzo reteNomi di dominio (DNS)Indirizzi IPFigura 1.6: XRI i-names e i-numbers come strato su<strong>per</strong>iore al DNSGli 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 didominio, gli XRI possono essere annidati in profondità a livelli multipli, propriocome i nomi delle directory di un file system. Un’organizzazione può registrareun i-name (top-level) <strong>per</strong> se stessa, e vari i-names (lower-level) ad esempio <strong>per</strong>le sue succursali e i suoi impiegati. XRI inoltre supporta tre caratteristiche chenon sono disponibili nell’indirizzamento DNS:• indirizzamento non gerarchico: il modo in cui due nodi di una rete possonoassegnarsi identificatori XRI l’uno con l’altro e implementare la risoluzioneincrociata.• cross-references: la capacità di un XRI di contenere altri XRI, abilitandola stessa risorsa logica ad essere identificata in altri contesti (caratteristicaparticolarmente rilevante <strong>per</strong> la condivisione dati tra domini diversi).• global context registries: un modo sintetico e human friendly di indicareil contesto globale di un i-name o di un i-number. Ce ne sono di tre tipi,ognuno <strong>dei</strong> quali è rappresentato da un singolo simbolo, come mostrato intabella 1.2.24


Stili architetturaliOASIS DataWebTIPOGlobalSimbolo i-name i-numberContextPersonale Individuale = =samuele.innocenti =!2D36.FA65.4565.6C3ABusiness OrganizzativoQualunque tipo @ @Sam.Corp @!1057.A23C.4E83.95D3di marchio o no-me commercialeGenerale Concetti, soggetti,+ +animali — +ani-+!3223 — +!3223+!0343argomentimali+gattigenericiTabella 1.2: Esempi di i-number e i-namesGli identificatori i-names e i-numbers affrontare la rappresentazione di indirizziconvenzionali (come i numeri di telefono e le e-mail):• indirizzamento unificato: Poiché un i-name è astratto, esso è la prima vera“online business card”. Date le proprie credenziali l’i-name può essereusato automaticamente <strong>per</strong> cercare qualunque altro dato necessario <strong>per</strong>poter comunicare con il suo proprietario. Non c’è limite ai tipi di dati chepossono essere risolti da un i-name.• controllo della privacy: l’uso di i-names e i-numbers dovrebbe arginare lospam, <strong>per</strong>ché non sono un tipo di canale di comunicazione diretta (comegli indirizzi e-mail, numeri di telefono o fax). Il possessore di un i-namecontrolla come esso è risolto, e come le regole sulla privacy devono essereosservate, già prima che venga stabilito un qualsiasi contatto o si accedaad un dato. In pratica esiste un filtro (Privacy Barrier) tra l’identificatoree le informazioni ad esso relative, così da fermare lo spam prima ancora cheparta. Questo controllo della privacy viene fornito con l’introduzione di unterzo attore, chiamata i-broker, il quale detiene e registra gli identificatorie la corrispondenza alla risorsa ad essi relativa. L’i-broker, che rappresentail service provider <strong>per</strong> l’infrastruttura XDI ed agisce da intermediario tradue soggetti XDI. i-broker tutela quindi la privacy nell’interscambio <strong>dei</strong>dati. Tra i servizi forniti dagli i-names, uno <strong>dei</strong> più importanti è quello difornire un’autenticazione sicura, di tipo single sign-on; si tratta del serviziodi autenticazione OpenID, che verrà analizzato nel capitolo 2.1.4.4 La risoluzione XRILa risoluzione è il processo di conversione di un identificatore in un metadatoche 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 ResourceDescriptor); chiaramente il più semplice <strong>dei</strong> documenti XRDS ne conterrà unosoltanto. Costruire una sequenza di XRD in un documento XRDS in praticaconsiste nel realizzare una “catena” di metadati. La specifica completa di risoluzioneXRI è consultabile in [WRM + 08], nella quale sono definite inoltre sia unprotocollo <strong>per</strong> richiedere documenti XRDS, sia un protocollo <strong>per</strong> la risoluzionedegli XRI <strong>per</strong> mezzo di documenti XRDS e tramite richieste HTTP.Per quanto riguarda il Web attuale la risoluzione di identificatori (indirizzi25


Stili architetturaliOASIS DataWebDNSXRIIdentificatore Nome di dominio XRIIdentificatore Network endpoint Indirizzo IP URIProtocollo di risoluzione primario UDP HTTPRisoluzione ricorsiva Name Server ricorsiviServer autoritativiricorsivi o risolu-tori proxyTabella 1.3: Confronto tra le architetture di risoluzione DNS e XRIdi livello applicazione) si basa sul DNS, che risolve questi ultimi in indirizzi IPdi livello rete. I punti principali dell’architettura DNS sono i seguenti:• Domain Name Space: è un database distribuito implementato in unagerarchia ad albero di Name Server.• Name Server: macchine che detengono la struttura ad albero del dominio etutte le informazioni correlate. Possono essere locali, radice e autoritativi.• Resolver: sono programmi che estraggono informazioni dai Name Serverin risposta alle richieste <strong>dei</strong> client.Un nome di dominio è generalmente risolto in un set di record (corrispondenzahostname-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 <strong>dei</strong> Name Server localicomincerà contattando uno <strong>dei</strong> Name Server radice conosciuti. La procedura dirisoluzione <strong>per</strong> i nomi di dominio agisce da destra a sinistra e i Name Serverradice riconoscono solamente i nomi di domino <strong>dei</strong> livelli su<strong>per</strong>iori rispetto aquello da risolvere; quindi saranno ritornati i record <strong>dei</strong> Name Server a partiredai livelli più alti ed in seguito i risolutori ripeteranno la stessa richiesta scendendolungo l’albero finché il nome di dominio sarà risolto completamente o siincontrerà un errore.La risoluzione XRI segue la stessa architettura del DNS tranne che <strong>per</strong> il fattoche si pone ad un livello di astrazione più elevato; anziché utilizzare UDP (oTCP) come protocollo di trasporto usa HTTP ed il formato di messaggi è XRDS.Nella tabella 1.3 viene mostrata la comparazione tra le architetture di risoluzioneDNS ed XRI, anche se in realtà non sarebbe lecito fare un paragone direttofra le due infrastrutture, poiché la seconda si pone ad un livello di astrazionesu<strong>per</strong>iore rispetto alla prima ed offre servizi aggiuntivi in vista dell’affermazionedel Dataweb.L’architettura di risoluzione XRI supporta sia la risoluzione ricorsiva basatasui server autoritativi, sia quella che avviene tramite proxy resolver (che è semplicementeun’interfaccia HTTP verso un resolver XRI locale). Questa secondamodalità è utile <strong>per</strong> diversi motivi; <strong>per</strong> esempio, in questo modo la proceduradi risoluzione è demandata al proxy resolver invece che al client locale. Inoltreil proxy resolver <strong>per</strong>mette di ottimizzare la procedura di caching degli XRD.La figura 1.7 mostra 4 modi diversi in cui può essere risolto il seguenteidentificatore XRI: xri://(tel:+1-201-555-0123)*foo*bar. Si può dedurre come26


Stili architetturaliOASIS DataWebla componente autoritativa dell’XRI è risolta in un documento XRDS, che descrivel’autorità target. La risoluzione lavora iterativamente da sinistra a destra(diversamente dal DNS) attraverso ogni sottosegmento dell’XRI. Negli XRI isottosegmenti sono delimitati sia utilizzando specifici set di caratteri simbolici,sia parentesi. Per esempio, nell’XRI xri://(tel:+1-201-555-0123)*foo*bar, ilsottosegmento autoritativo è (tel:+1-201-555-0123), una radice autoritativa (inquesto caso una URI espressa con una cross-reference delimitata con parentesi);il primo sottosegmento è *foo, ed il secondo sottosegmento è *bar.ServerautoritativoServerautoritativoServerautoritativoricorsivoServerautoritativo(2)*bar?XRDS(3)(2) (4)(4)XRDSXRDSXRDS(1)*foo?(3)*bar?(1)*foo?ResolverlocaleResolverlocaleA) Resolver locale che utilizza unserver autoritativo non ricorsivoB) Resolver locale che utilizza unserver autoritativo ricorsivoServerautoritativoServerautoritativoServerautoritativoricorsivoServerautoritativo(3)*bar?XRDS(4)(3)XRDS(5)XRDS(5)XRDS*foo?(2)*bar?(4)ProxyResolver*foo*bar?(2)(6) (6)ProxyResolver(tel:+1-201-555-0123)*foo*bar?(1)(tel:+1-201-555-0123)*foo*bar? (1)C) Proxy server che utilizza un serverautoritativo non ricorsivoD) Proxy server che utilizza un serverautoritativo ricorsivoFigura 1.7: Le 4 modalità di risoluzione dell’architettura XRIAffinché l’infrastruttura XDI/XRI possa essere implementata, l’organizza-27


Stili architetturaliCollaborazione basata su File Systemzione XDI.org ha sviluppato <strong>dei</strong> servizi di registrazione e risoluzione. Nella GlobalServices Specification V1.0 [LRC + 06] sono spiegati in dettaglio i requisitiche ognuna delle parti che compongono l’infrastruttura devono assolvere. Nellaspecifica è spiegato come un utente o un’organizzazione che volesse registrare ilsuo identificatore XRI, lo possa fare <strong>per</strong> mezzo di un i-broker, cioè una terzaparte accreditata da XDI.org che funge da service provider. È spiegata anchela politica di gestione legale e tecnica di tutti servizi offerti. Nel caso in cuiun’organizzazione volesse diventare un i-broker può farlo stringendo un accordo(regolamentato in [LRC + 06]), con la Cordance Corporation (www.cordance.net)o con Neustar (www.neustar.biz), e sotto l’autorizzazione dell’XDI.org, un enteche o<strong>per</strong>a alla stessa maniera in cui organizzazioni come ICANN e IANAo<strong>per</strong>ano <strong>per</strong> il sistema DNS. Una lista di i-broker accreditati si può trovare ahttp://inames.net/register.html.Nonostante siamo già stati investiti milioni di dollari nella realizzazione dell’infrastrutturaXDI/XRI, ad oggi la semplicità del Web attuale e la reticenzanel cambiare sistemi già funzionanti e consolidati, limita l’affermarsi di questonuovo framework.L’infrastruttura XDI/XRI <strong>per</strong>ciò è implementata solo parzialmente. Infatti<strong>per</strong> quanto riguarda gli aspetti relativi all’autenticazione di un identificatoreXRI, le specifiche dell’infrastruttura XDI/XRI sono implementate con il protocolloOpenID 2.0 (che verrà analizzato nel capitolo 2). Anche <strong>per</strong> quantoriguarda i service provider (i-brokers), seppur pochi, ci sono e sono funzionali.Circa l’integrazione di tutte le funzionalità offerte dalle specifiche XDI/XRI invecesiamo ancora ben lontani; infatti solo <strong>per</strong> citare un esempio, <strong>per</strong> la parterelativa ai link contracts sono presenti le specifiche tecniche [RST08] e potenzialmenteimplementabili, ma di fatto non sono implementate in maniera concretama sono solo presenti <strong>dei</strong> modelli.1.5 Collaborazione basata su File SystemIn molti contesti aziendali, ma anche su scala globale, la condivisione e l’auhtoringconcorrente delle informazioni e delle risorse in rete avviene attraverso lacondivisione di porzioni di file system: un servizio economico facile da realizzare.Questo paradigma consente il “passaggio” <strong>dei</strong> contenuti o risorse hardware tragruppi o coppie di <strong>per</strong>sone. La maturità e l’efficacia del paradigma è comprovatadal supporto e largo utilizzo negli attuali i sistemi o<strong>per</strong>ativi di protocolli comeSMB/CIFS. Osserviamo che l’integrazione del file system e di un protocollo dicondivisione consentono di erogare un servizio infrastrutturale.Questo approccio collaborativo è fortemente condizionato da un preventivocoordinamento tra utenti. Ad esempio è sufficiente una cancellazione, senzapreavviso, o una modifica di una risorsa <strong>per</strong> impedire al destinatario di ottenerlao di valutarla nella sua evoluzione temporale. Ecco quinfi che funzionalità diversioning vengono incluse nei più diffusi tool di editing (es. Microsoft Word edOpenOffice)Per comprendere la struttura di un file system distribuito è necessario introdurrealcuni concetti:28


Stili architetturaliCollaborazione basata su File System• un servizio è “un programma in esecuzione su una o più macchine chefornisce 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 unaserie di o<strong>per</strong>azioni che costituiscono la sua interfaccia” [SGG02].Nel caso del file system, il server è nella macchina che contiene i file, e ilclient è nella macchina che cerca di accedervi. Solitamente il server dichiarache una risorsa è disponibile ai client, specificando esattamente quale risorsa (inquesto caso, quali file) e quali client. Un server può servire più client, e un clientpuò usare più server, a seconda dell’implementazione.Le richieste di o<strong>per</strong>azione sui file da parte dell’utente sono inviate attraversola rete secondo il protocollo del file system distribuito, normalmente insiemeall’identificatore dell’utente richiedente. Il server applica i controlli di accesso<strong>per</strong> determinare se l’utente ha le credenziali <strong>per</strong> 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 o<strong>per</strong>azioni sulfile, chiudendolo quando ha completato l’accesso.Molti degli aspetti <strong>dei</strong> file system distribuiti sono simili a quelli <strong>dei</strong> file systemconvenzionali, <strong>per</strong> cui saranno analizzati gli aspetti rilevanti e caratterizzanti <strong>per</strong>il contesto distribuito.1.5.1 Interfaccia e servizi offertiIl servizio di archiviazione (file service) è la specifica di ciò che il file systemoffre agli utenti: descrive le primitive disponibili, quali parametri prendono iningresso e quali azioni eseguono; definisce esattamente quali servizi sono disponibiliagli utenti, ma non dice niente su come debbano essere implementati. Inpratica, specifica l’interfaccia del file system agli utenti [Tan94].Nella maggior parte delle implementazioni si possono individuare due componentiseparate:• Servizio di memorizzazione (storage service). Gli utenti non hanno bisognodi conoscere le caratteristiche fisiche <strong>dei</strong> dischi, o dove sono statimemorizzati i file. Il file system possibilmente non deve <strong>per</strong>dere un fileanche se ci sono guasti dell’hardware o crash del software.• Servizio di directory (directory service). Gli utenti possono dare nomitestuali ai file e, raggruppandoli in directory, evidenziare le relazioni tradi essi. Inoltre devono essere in grado di controllare la condivisione <strong>dei</strong>loro file con gli altri, specificando chi possa accedere ad un dato file e inche modo [BH03].Per illustrare una tipica interazione tra il file service e l’utente, si suppongache venga creato un file a cui l’utente assegna un nome, detto nome testuale osimbolico.29


Stili architetturaliCollaborazione basata su File SystemQuando l’utente chiama un’o<strong>per</strong>azione di tipo open, deve fornire come argomentoil nome testuale, mentre un altro argomento specifica se vuole sololeggere il file oppure se vuole sia leggere che scrivere. Il servizio di directoryesegue il controllo <strong>per</strong> assicurarsi che il file esista e che l’utente sia autorizzatoad accedervi nella modalità richiesta, inoltre è responsabile della traduzione delnome dalla forma testuale alla rappresentazione interna del sistema, solitamentecon codifica binaria, ossia una forma che <strong>per</strong>metta al servizio di memorizzazionedi localizzare il file su disco (risoluzione <strong>dei</strong> nomi).A questo punto, il file system inserisce le informazioni sul file nelle sue tabellein memoria principale, e restituisce all’utente un identificatore che sarà usatonelle successive richieste di lettura o scrittura. Infine, il servizio di memorizzazionerestituisce la porzione di file desiderata. Si noti che la richiesta inizialedeve fornire un nome che <strong>per</strong>metta al file di essere identificato univocamente nelfile system.In un sistema distribuito, è importante fare distinzione tra i concetti di fileservice e file server.Il file server è un processo in esecuzione su qualche macchina e serve adimplementare il file service. Un sistema può avere uno o più file server; gli utenti,ovvero i client, non devono sa<strong>per</strong>e quanti ce ne sono e quali sono la locazione e/ola funzione di ciascuno di essi, sanno soltanto che quando chiamano le procedurespecificate nel file service, in qualche modo, il lavoro richiesto viene eseguito eviene restituito loro il risultato, ossia l’esito della memorizzazione o dell’accesso.Idealmente, i client non dovrebbero neanche sa<strong>per</strong>e che il file service è distribuito,e dal loro punto di vista esso dovrebbe avere lo stesso aspetto di unnormale file system.Poiché normalmente un file service è semplicemente un processo utente (otalvolta 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. Iltipo e il numero di file service disponibili può anche cambiare con l’evolversi delsistema.modello upload/download1: il file è spostato sul clientclientservermodello ad accesso remotoil client richiede l'accesso a un file remotoclientserver2: gli accessi avvengono nel client3: dopo il file è rispostato sul serveril file rimane sul serverFigura 1.8: Modelli upload/download e ad accesso remoto <strong>per</strong> il file serviceCome 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 o<strong>per</strong>azioniprincipali: lettura e scrittura del file. La prima o<strong>per</strong>azione trasferisce30


Stili architetturaliCollaborazione basata su File Systemun file da uno <strong>dei</strong> file server al client che lo richiede, mentre la secondao<strong>per</strong>azione lo trasferisce nella direzione opposta, dal client al server.In pratica, questo modello prevede lo spostamento dell’intero file in unadelle due direzioni. I programmi di applicazione prendono i file di cuihanno bisogno e poi li usano localmente, tenendoli in memoria o su undisco 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 o<strong>per</strong>azioni<strong>per</strong> aprire e chiudere i file, leggere e scrivere parti <strong>dei</strong> file, muoversiall’interno <strong>dei</strong> file (seek), esaminare e cambiare gli attributi <strong>dei</strong> file, e cosìvia.Il vantaggio del modello upload/download è la sua semplicità concettuale:non c’è bisogno di un’interfaccia complicata <strong>per</strong> il file service, e il trasferimento<strong>dei</strong> file è molto efficiente. Deve <strong>per</strong>ò essere disponibile abbastanza spazio nelclient <strong>per</strong> memorizzare tutti i file richiesti. Inoltre, se si ha bisogno solo di unaparte del file, è uno spreco spostarlo tutto.Nel modello ad accesso remoto questi due problemi non esistono, <strong>per</strong>ò ognio<strong>per</strong>azione richiede la comunicazione col server.La natura del servizio di directory non dipende dal tipo di modello adottatodal file service; esso definisce l’alfabeto e la sintassi <strong>per</strong> comporre i nomi <strong>dei</strong> filee delle directory e fornisce le o<strong>per</strong>azioni <strong>per</strong> creare e cancellare le directory oltrea rinominare, rimuovere e cercare i file in esse.Tutti i sistemi distribuiti <strong>per</strong>mettono che le directory contengano sottodirectory,<strong>per</strong> far sì che gli utenti possano raggruppare insieme i file correlati. Lesottodirectory 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 directoryarbitraria. Questi possono essere messi in qualsiasi directory, rendendo possibilela costruzione non solo di alberi, ma di grafi di directory, che sono più espressivinella rappresentazione delle informazioni memorizzate nel sistema.La distinzione tra alberi e grafi è particolarmente importante nei sistemidistribuiti. In una struttura gerarchica ad albero, un collegamento ad una directorypuò essere rimosso solo quando la directory puntata è vuota. In un grafo,è <strong>per</strong>messo rimuovere un collegamento ad una directory purché esista almenoun altro collegamento, e tenendo un contatore <strong>dei</strong> riferimenti si può determinarequando il collegamento che viene rimosso è l’ultimo.Purtroppo talvolta possono presentarsi delle situazioni che rendono la directorydi fatto inaccessibile, anche se il numero <strong>dei</strong> riferimenti ad essa è diversoda zero [BH03].Questo problema esiste anche nei sistemi centralizzati, ma è più grave inquelli distribuiti.Se tutto sta su una macchina, è possibile, anche se oneroso, scoprire le directoryorfane, <strong>per</strong>ché tutta l’informazione è nello stesso posto. Dopo aver fermatole attività sui file, si può attraversare il grafo partendo dalla radice, segnandotutte le directory raggiungibili: alla fine di questo processo, si sa che tutte le31


Stili architetturaliCollaborazione basata su File Systemdirectory non segnate sono irraggiungibili. In un sistema distribuito sono coinvoltepiù macchine e non possono essere fermate tutte le attività, <strong>per</strong>ciò ottenereuno “snapshot” del sistema è difficile, se non impossibile.La struttura del sistema varia a seconda dell’implementazione. In alcunisistemi non c’è distinzione tra client e server: su tutte le macchine gira lo stessosoftware, <strong>per</strong>ciò ogni macchina che voglia offrire file service al pubblico può farlo,è solo una questione di esportare i nomi delle directory selezionate in modo chele altre macchine possano accedervi. Altre volte il file server e il directory serversono programmi utente, <strong>per</strong>ciò il sistema può essere configurato in modo da fargirare 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 macchinecompletamente diverse, in termini di hardware o di software, o su versioni diversedel sistema o<strong>per</strong>ativo.Non c’è motivo di preferire un approccio agli altri, ma la separazione dellefunzioni è una soluzione un po’ più pulita.Un’altra questione implementativa <strong>per</strong> cui i sistemi differiscono riguardacome sono strutturati il file service e il directory service.Si possono combinare i due in un singolo server che gestisca da sé tutte lechiamate a file e directory, oppure si può tenerli separati: in questo caso, aprireun file richiede di andare al directory server <strong>per</strong> mappare il suo nome simbolicoin quello binario, e poi andare al file server con il nome binario <strong>per</strong> leggere oscrivere il file.Un argomento a favore della separazione è che le due funzioni sono del tuttoscorrelate, <strong>per</strong>ciò tenerle separate è più flessibile come soluzione, sia <strong>per</strong> quantoriguarda il bilanciamento del carico di lavoro che la manutenzione del softwaree la disponibilità del servizio; il problema è che avere due server richiede unamaggiore comunicazione.1.5.2 Spazio <strong>dei</strong> nomi e trasparenzaLa maggior parte <strong>dei</strong> sistemi distribuiti usa qualche forma di nominazione(naming) a due livelli.È conveniente <strong>per</strong> le <strong>per</strong>sone e i programmi usare nomi simbolici <strong>per</strong> i file,ma questa rappresentazione risulta inefficiente <strong>per</strong> l’elaborazione da parte <strong>dei</strong>processi che trattano i file all’interno del sistema, <strong>per</strong>ciò 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 nomesimbolico, il sistema lo cerca immediatamente nella directory appropriata <strong>per</strong>ottenere il nome binario che sarà usato <strong>per</strong> 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 <strong>dei</strong> 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 avvienenei sistemi Unix. Uno schema di nominazione più generale prevede che ilnome binario indichi sia un server che uno specifico file su quel server. Questo32


Stili architetturaliCollaborazione basata su File Systemapproccio <strong>per</strong>mette ad una directory su un server di contenere un file che sta suun altro server. Altrimenti, un modo alternativo <strong>per</strong> fare la stessa cosa è usareun collegamento simbolico.Nella progettazione di un file system distribuito è importante decidere setutte le macchine e i processi debbano o meno avere esattamente la stessa vistadella gerarchia delle directory. In pratica, si tratta di stabilire se un nome di<strong>per</strong>corso 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 unfile system convenzionale, centralizzato: i client non devono essere a conoscenzadella distribuzione <strong>dei</strong> file e della molteplicità <strong>dei</strong> 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 lostesso insieme di o<strong>per</strong>azioni che si applica ai file locali.L’interfaccia di un file system distribuito verso il client non deve <strong>per</strong>ciò faredistinzione tra file locali e file remoti, e i programmi scritti <strong>per</strong> o<strong>per</strong>are con ifile locali devono essere in grado di accedere ai file remoti senza modifiche. Ècompito del file system distribuito localizzare i file e provvedere al trasporto <strong>dei</strong>dati [LS90].La trasparenza di locazione implica che il nome di <strong>per</strong>corso non dia indizi sudove si trova fisicamente il file.I programmi client devono vedere uno spazio <strong>dei</strong> nomi <strong>dei</strong> file uniforme, inmodo che i programmi utente possano vedere lo stesso spazio <strong>dei</strong> nomi ovunquesiano eseguiti.Un sistema che presenta questo tipo di trasparenza assegna un nome di<strong>per</strong>corso del tipo /server1/dir1/dir2/x. Questo rende noto che x si trova suserver1, ma non indica dove si trova il server, il quale è libero di muoversiovunque voglia nella rete, senza che il nome di <strong>per</strong>corso debba cambiare.Si supponga adesso che il file x sia estremamente grande e che lo spazio suserver1 sia poco, ma che ci sia molto spazio su server2: il sistema potrebbevoler spostare automaticamente x su server2.Purtroppo, quando la prima componente di tutti i nomi di <strong>per</strong>corso è ilserver, questo non può avvenire, <strong>per</strong>ché lo spostamento automatico del filemodificherebbe il suo nome di <strong>per</strong>corso da /server1/dir1/dir2/x a /server2/dir1/dir2/x,e di conseguenza tutti i programmi che hanno codificata alloro interno la prima stringa genereranno errore se il <strong>per</strong>corso cambia.Si dice che un sistema in cui i file possono essere spostati senza che i loronomi di <strong>per</strong>corso cambino presenta indipendenza dalla locazione: questa implicala trasparenza di locazione e <strong>per</strong>mette di bilanciare l’occupazione <strong>dei</strong> dispositivi.Un sistema distribuito che inserisce il nome del server o della macchina neinomi di <strong>per</strong>corso chiaramente non presenta indipendenza dalla locazione. Nonla 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 altroe continuare a usare il vecchio nome di <strong>per</strong>corso.L’indipendenza dalla locazione non è facile da ottenere, ma è una proprietàauspicabile <strong>per</strong> un sistema distribuito.33


Stili architetturaliCollaborazione basata su File SystemRiassumendo, esistono tre strategie comuni di nominazione di file e directoryin un sistema distribuito:• Nominazione gerarchica. Un modo <strong>per</strong> avere una directory root globaleè far sì che questa root contenga un elemento <strong>per</strong> ogni server, e nient’altro.In questo modo, i nomi di <strong>per</strong>corso comprendono un identificatoredella 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 nonindipendenza da essa.• Nominazione a condivisione parziale. Nei sistemi che gestiscono più fileserver tramite il montaggio remoto di file system nella gerarchia locale <strong>dei</strong>file, la norma è che macchine diverse abbiano diverse viste del file system.In pratica, viene aggiunta una gerarchia remota allo spazio <strong>dei</strong> nomi logicilocale. Anche questa forma di nominazione presenta trasparenza dilocazione, ma non indipendenza da essa. Un tale approccio è flessibilee facile da implementare, ma ha lo svantaggio di non essere equivalentead un unico sistema a condivisione di tempo, in cui il file system appareuguale a tutti i processi.• Nominazione a condivisone completa. La totale integrazione <strong>dei</strong> file systemè realizzata tramite un unico spazio <strong>dei</strong> nomi che appaia uguale su tuttele macchine, in modo che tutti i client vedano la stessa struttura di nomiglobale. In questo modo si ottiene indipendenza dalla locazione, la qualeimplica la trasparenza.I primi due approcci sono facili da implementare, specialmente <strong>per</strong> collegaresistemi esistenti che non erano stati progettati <strong>per</strong> l’uso distribuito. Il terzoapproccio è più difficile e richiede una progettazione accurata, ma è necessariose si vuole raggiungere lo scopo di far agire il sistema distribuito come un singolocomputer.Un altro aspetto importante della trasparenza è la mobilità degli utenti, laquale implica che gli utenti possano accedere a qualsiasi macchina del sistemasenza essere forzati a usarne una specifica.La trasparenza di prestazioni prevede che i programmi client continuino adavere prestazioni soddisfacenti al variare del carico del servizio, mentre la trasparenzadi scalabilità <strong>per</strong>mette che il servizio venga espanso nel tempo concrescita incrementale <strong>per</strong> gestire una vasta gamma di carichi e dimensioni dellarete [CDK00].Il file service dovrebbe essere progettato in modo da soddisfare molti <strong>dei</strong>requisiti di trasparenza <strong>per</strong> i sistemi distribuiti, trovando il giusto equilibrio trala flessibilità e la scalabilità che derivano dalla trasparenza e la complessità e leprestazioni del software.Si consideri il caso in cui file server e directory server sono separati. Il clientmanda un nome simbolico al directory server, il quale restituisce il nome binariocomprensibile al file server.È possibile che una gerarchia di directory sia partizionata tra più server: sisupponga di avere un sistema in cui la directory corrente sul server 1 contiene34


Stili architetturaliCollaborazione basata su File Systemun 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 sulserver 3. Quest’ultima contiene un elemento che corrisponde al file c, insiemeal suo nome binario.Per cercare a/b/c, il client manda un messaggio al server 1, che gestisce lasua 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ì cheil client si occupi di trovare b/c da solo, oppure inoltrare ciò che rimane dellarichiesta al server 2.Il primo schema richiede che il client sia a conoscenza di quale server tienequale directory, e richiede più messaggi. Il secondo metodo è più efficiente, manon può essere gestito usando le RPC 2 normali, poiché il processo a cui il clientmanda il messaggio non è lo stesso che manda la risposta.Cercare di continuo i nomi di <strong>per</strong>corso, soprattutto se sono coinvolti piùdirectory server, può essere oneroso. Alcuni sistemi cercano di migliorare leprestazioni mantenendo in cache degli hint, cioè i nomi cercati di recente e irisultati di queste ricerche. Quando viene a<strong>per</strong>to un file, si controlla la cache <strong>per</strong>vedere se contiene il nome di <strong>per</strong>corso: in caso affermativo si prende l’indirizzobinario da lì, altrimenti si fa la ricerca.Perché il caching <strong>dei</strong> nomi funzioni, è essenziale che quando viene usatoinavvertitamente un nome binario obsoleto, il client venga in qualche modoinformato, in modo che possa eseguire la ricerca <strong>per</strong> trovare il file, e aggiornarela cache. Inoltre, <strong>per</strong>ché valga la pena tenere la cache degli hint, questi devonoessere giusti <strong>per</strong> la maggior parte delle volte.1.5.3 Confronto tra server stateful e statelessSe il server mantiene le informazioni sulla connessione ed i servizi che staoffrendo ai client tra una richiesta e l’altra, si dice che il server è stateful.Questo comportamento è analogo a quello tradizionale <strong>dei</strong> sistemi o<strong>per</strong>ativicentralizzati, i quali mantengono informazioni sullo stato <strong>dei</strong> processi attivi.In un servizio con informazioni di stato, durante una sessione di file 3 esisteuna connessione tra client e server [SGG02].Quando il client esegue una chiamata open, riceve un identificatore che verràusato nelle chiamate successive <strong>per</strong> riconoscere il file, fino al termine della sessione.Il server deve mantenere un identificatore univoco <strong>per</strong> ogni client, e delleinformazioni che indichino quale client ha a<strong>per</strong>to quale file; quando riceve unarichiesta, usa l’identificatore del file <strong>per</strong> determinare di quale file si ha bisogno.2 Il metodo di chiamata di procedura remota (Remote Procedure Call, in breve RPC) <strong>per</strong>metteai programmi di invocare procedure che si trovano su macchine diverse. Quando ilprocesso sulla macchina A chiama una procedura sulla macchina B, il processo chiamantesu A solitamente viene sospeso, e l’esecuzione della procedura chiamata avviene su B. L’informazionepuò essere trasportata dal processo chiamante a quello chiamato attraverso <strong>dei</strong>parametri, e tornare indietro come risultato della procedura. Il programmatore non vedenessun passaggio di messaggi [TvS01].3 Viene chiamata sessione di file una serie di accessi allo stesso file da parte di un client, inlettura o in scrittura, compresi tra le o<strong>per</strong>azioni di open e close.35


Stili architetturaliCollaborazione basata su File SystemLa tabella che mappa gli identificatori <strong>dei</strong> file nei file stessi rappresental’informazione sullo stato [Tan94].Questa tabella può contenere anche altre informazioni utili <strong>per</strong> il correttofunzionamento del server, come ad esempio i timestamp dell’ultima modificaeffettuata sul file o i diritti di accesso ad esso [LS90]. Lo spazio in memoria centraleusato <strong>per</strong> questo scopo viene liberato alla chiusura del file oppure tramiteun apposito meccanismo di “ripulitura” (garbage collection).Uno svantaggio relativo a questo approccio è che se troppi client hanno troppifile contemporaneamente a<strong>per</strong>ti la tabella può arrivare a riempirsi, provocandol’impossibilità di aprire ulteriori file.Inoltre, si consideri cosa può succedere in caso di guasti. Se il server crolla,tutte le sue tabelle sono <strong>per</strong>se e al riavvio non c’è più modo di sa<strong>per</strong>e quali clienthanno a<strong>per</strong>to quali file. Il recu<strong>per</strong>o dello stato, se possibile, avviene tramiteun protocollo di ripristino che sfrutta il dialogo con i client; altrimenti, tutte leo<strong>per</strong>azioni in corso vengono terminate e i successivi tentativi di leggere e scriverefile a<strong>per</strong>ti al momento del crollo falliranno.Anche quando è un client a crollare mentre ha un file a<strong>per</strong>to, il server sitrova in difficoltà: deve liberare quella parte della memoria occupata dalle informazionisul client <strong>per</strong>duto (rilevamento ed eliminazione degli orfani), o lesue tabelle finiranno <strong>per</strong> riempirsi. Ma se decide di dare il timeout ai file a<strong>per</strong>tiinattivi, può capitare che venga negato il servizio ad un client che aspetti troppoa lungo tra una richiesta e l’altra, impedendo il corretto funzionamento di alcuniprogrammi.D’altra parte, un servizio con informazioni di stato ha prestazioni migliori,poiché l’informazione sui file a<strong>per</strong>ti può essere tenuta nella memoria principalefinché questi non vengono chiusi.I messaggi di lettura e scrittura non devono contenere i nomi <strong>dei</strong> file, <strong>per</strong>ciò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 lamaggior parte <strong>dei</strong> file è letta sequenzialmente.Se un client va in timeout e invia la stessa richiesta due volte, in presenza diinformazioni sullo stato è molto più facile accorgersene, ad esempio se si ha unnumero di sequenza in ogni messaggio.Se invece il server non mantiene informazioni sul client una volta che hafinito di servire la sua richiesta, si dice che il server è stateless: significa che silimita 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 laporta a termine, invia la risposta, e poi rimuove dalle sue tabelle interne tuttele informazioni relative alla richiesta. Tra una richiesta e l’altra, il server nonmantiene nessuna informazione specifica sul client.In questo caso, ogni servizio è indipendente dal precedente e ogni richiestadeve esse autocontenuta, cioè deve contenere l’intero nome del file e l’offsetall’interno del file, in modo da <strong>per</strong>mettere al server di eseguire il suo compito.Inoltre, c’è bisogno di uno schema di nominazione uniforme di basso livello sututto il sistema <strong>per</strong> l’identificazione <strong>dei</strong> file.La maggiore lunghezza del messaggio e la necessità di tradurre i nomi remotiin locali rallentano l’elaborazione delle richieste.36


Stili architetturaliCollaborazione basata su File SystemNon c’è <strong>per</strong>ò bisogno delle chiamate open e close, il che riduce il numero<strong>dei</strong> 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 <strong>per</strong> mantenerele tabelle, ma di solito queste vengono comunque utilizzate <strong>per</strong> motivi diefficienza.I server stateless sono intrinsecamente più tolleranti ai guasti, <strong>per</strong>ché lamancanza di informazioni di stato elimina tutti i problemi visti <strong>per</strong> i serverstateful. Quando viene ripristinato in seguito a un crollo, il server non haproblemi 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, indipendentementedal fatto che il server abbia subito un guasto o sia soltantolento.Poiché i client ritrasmettono le richieste, bisogna assicurarsi che tutte leo<strong>per</strong>azioni eseguite siano idempotenti, cioè che abbiano lo stesso effetto e dianolo stesso risultato se eseguite più volte di seguito.Gli accessi in lettura e scrittura autocontenuti sono idempotenti se usanoun conteggio assoluto <strong>per</strong> indicare la posizione all’interno del file, ma non seado<strong>per</strong>ano uno scostamento incrementale.Infine, è impossibile eseguire il locking <strong>dei</strong> file in un sistema del tutto stateless,<strong>per</strong>ché l’unico effetto del lock è l’inserimento dello stato nel sistema: <strong>per</strong> isistemi stateless sarà necessario un apposito locking server.vantaggi <strong>dei</strong> server statefuli messaggi di richiesta sono più brevimigliori prestazioniè possibile usare la tecnica read-aheadè più facile ottenere l'idempotenzaè possibile mettere il lock sui filevantaggi <strong>dei</strong> server statelesstolleranza ai guastinon c'è bisogno di chiamate OPEN/CLOSEnon c'è spreco di spazio nel servernon c'è limite al numero di file a<strong>per</strong>tinon ci sono problemi al crollo del clientTabella 1.4: Confronto tra server stateful e statelessNella tabella 1.4 sono riassunti i principali vantaggi offerti dai due tipi diservizi appena visti.Il servizio con informazioni di stato può rivelarsi una necessità nel caso in cuii messaggi non arrivino nell’ordine in cui sono stati inviati, e si voglia riordinarlisfruttando lo stato.Se poi si usa il metodo iniziato dal server <strong>per</strong> la validazione della cache, non èpossibile avere un servizio senza informazioni di stato <strong>per</strong>ché deve essere tenutatraccia di quali file sono tenuti in cache da quali client.1.5.4 Semantica della consistenzaQuando due o più utenti condividono lo stesso file, <strong>per</strong> 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


Stili architetturaliCollaborazione basata su File Systemsingolo processore1: scrive “c”file originaleAababcB2: legge “abc”Figura 1.9: Lettura e scrittura in un sistema a singolo processoreNei sistemi a singolo processore che <strong>per</strong>mettono la condivisione <strong>dei</strong> file traprocessi, come Unix, la semantica di solito stabilisce che ogni accesso in letturaal file vede gli effetti di ogni precedente scrittura, come illustrato nella figura1.9. Ogni scrittura viene quindi resa immediatamente visibile agli altri clientche stanno accedendo allo stesso file [LS90]. In pratica, il sistema applica unordinamento di tempo assoluto a tutte le o<strong>per</strong>azioni e restituisce sempre il valorepiù recente.Questo modello, noto come semantica Unix, porta ad un’implementazionein cui ad ogni file è associata una sola immagine fisica.In un sistema distribuito, questa semantica può essere ottenuta facilmentepurché ci sia un solo file server e i client non tengano copie <strong>dei</strong> file in cache.Le richieste di lettura e scrittura sono processate dal file server in ordine strettamentesequenziale, e i client possono condividere il puntatore alla posizionecorrente del file.La maggior parte <strong>dei</strong> file system distribuiti cerca di emulare questa semantica<strong>per</strong> motivi di compatibilità.Un problema di questo approccio è che, a causa <strong>dei</strong> ritardi di rete, una letturache è avvenuta un microsecondo dopo una scrittura potrebbe arrivare <strong>per</strong> primaal server, ottenendo così il valore vecchio.In pratica, comunque, le prestazioni di un sistema distribuito in cui tutte lerichieste di file devono essere inviate ad un singolo server sono piuttosto scadenti[Tan94].Questo problema di solito è risolto <strong>per</strong>mettendo ai client di mantenere copielocali <strong>dei</strong> file più usati nelle loro cache private. Se <strong>per</strong>ò un client modificalocalmente un file nella sua cache, e poco dopo un altro client legge il file dalserver, il secondo client riceverà un file obsoleto, come illustrato nella figura1.10.Si potrebbe pensare allora di propagare immediatamente al server tutti icambiamenti <strong>dei</strong> file in cache, ma nonostante sia concettualmente semplice,questo approccio risulta inefficiente.Una soluzione alternativa è quella di avere una semantica secondo la qualei cambiamenti su un file a<strong>per</strong>to inizialmente sono visibili solo al processo cheha modificato il file, o comunque soltanto ai client locali, e non ai client remotiche hanno a<strong>per</strong>to lo stesso file contemporaneamente. Quando poi il file vienechiuso, i cambiamenti saranno resi visibili agli altri nelle successive sessioni. Le38


Stili architetturaliCollaborazione basata su File Systemclient 12: scrive “c”Aab1: legge “ab”abcfile serviceabclient 2Bab3: legge “ab”Figura 1.10: Lettura e scrittura in un sistema distribuitosessioni remote attive alla chiusura non riflettono i cambiamenti e continuanoad o<strong>per</strong>are su copie obsolete.Secondo questa regola, largamente implementata e conosciuta come semanticadelle sessioni, un file può essere temporaneamente associato con molte immaginieventualmente diverse allo stesso tempo, e più utenti possono eseguireaccessi concorrenti su di esse senza subire ritardi.Si deve <strong>per</strong>ò abbandonare la condivisione <strong>dei</strong> puntatori alla posizione correntedel file.L’uso della semantica delle sessioni solleva la questione di cosa possa accaderequando due o più client stanno contemporaneamente tenendo in cache emodificando lo stesso file.Si può far sì che via via che ogni client chiude il file, venga inviato al server ilvalore aggiornato, in modo che il valore finale dipenda dall’ultimo che lo chiude.Un’alternativa leggermente più facile da implementare è stabilire che il valorefinale sia uno <strong>dei</strong> candidati, ma senza specificare quale.Le politiche più usate comunemente sono varianti della semantica Unix e, inmisura minore, della semantica delle sessioni; mettendole a confronto, emerge lanecessità di raggiungere un compromesso tra la semplicità dell’implementazionedistribuita da una parte, e la robustezza delle garanzie fornite dalla semanticadall’altra.La forza della semantica Unix sta nella garanzia che tutti gli accessi vedonola stessa versione del file, e quindi ciascun accesso è influenzato dai tutti quelliprecedenti.Viceversa, la semantica delle sessioni non dà molte garanzie sull’accesso concorrentead un file, poiché accessi su macchine diverse possono osservare versionidiverse del file.Un approccio completamente diverso è la semantica <strong>dei</strong> file immutabili, secondola quale le uniche o<strong>per</strong>azioni <strong>per</strong>messe sono la creazione e la lettura; unfile non può essere a<strong>per</strong>to in scrittura e il suo contenuto non può essere modifi-39


Stili architetturaliCollaborazione basata su File Systemcato. È possibile <strong>per</strong>ò creare un nuovo file e inserirlo nella directory con il nomedi un file che esisteva in precedenza, il quale diventa così inaccessibile, <strong>per</strong> lomeno 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 dueprocessi <strong>dei</strong> quali uno sta scrivendo su un file e l’altro lo sta leggendo.Rimane il problema di cosa possa accadere quando due processi provano asostituire lo stesso file contemporaneamente: la soluzione migliore sembra esserequella già vista <strong>per</strong> la semantica delle sessioni, cioè <strong>per</strong>mettere ad uno <strong>dei</strong> nuovifile di sostituire quello vecchio, sia esso l’ultimo o meno.Un altro problema è cosa fare se un file viene sostituito mentre un altroprocesso lo sta leggendo.Una soluzione potrebbe consistere nel fare in modo che il lettore possa continuaread usare il vecchio file, anche se non è più in nessuna directory. Un’altrasoluzione è accorgersi che il file è cambiato e far fallire i successivi tentativi dilettura.Un ulteriore modo di gestire i file condivisi in un sistema distribuito è quellodi 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, <strong>per</strong> prima cosa esegueuna primitiva del tipo begin_transaction, <strong>per</strong> segnalare che ciò che segue deveessere eseguito indivisibilmente. A questo punto si possono usare le chiamate disistema <strong>per</strong> 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 <strong>per</strong> la durata dellatransazione, <strong>per</strong>ciò 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 tuttele 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 risultatofinale sia lo stesso che si sarebbe ottenuto se fossero state eseguite in qualcheordine sequenziale non definito.semanticaUnixsessionifile immutabilitransazionidescrizioneogni o<strong>per</strong>azione sui file è immediatamente visibile a tutti i processinessuna modifica è visibile agli altri processi fino a quando il file nonviene chiusonon è possibile eseguire modifichetutte le modifiche avvengono in modo atomicoTabella 1.5: Metodi <strong>per</strong> gestire i file condivisi in un sistema distribuitoNella tabella 1.5 sono riassunti i metodi appena visti <strong>per</strong> gestire i file condivisiin un sistema distribuito.40


Stili architetturaliCollaborazione basata su File System1.5.5 Metodi di accesso remoto e cachingSi consideri un processo client che richiede di accedere ad un file remoto, inlettura o in scrittura. Dopo che lo schema di nominazione ha localizzato il serversu cui è memorizzato il file, la richiesta del client viene soddisfatta attraversol’effettivo trasferimento <strong>dei</strong> dati.Questo trasferimento può essere gestito in modi diversi, a seconda di dovesono memorizzati i dati.clientserverdiscomemoriaretememoriadisco(opzionale)Figura 1.11: Luoghi dove memorizzare fileCome illustrato nella figura 1.11, in un sistema client-server esistono diversiposti nei quali possono essere memorizzati i file, o parti di essi: il disco delserver, la memoria principale del server, il disco del client (se disponibile) e lamemoria principale del client.Secondo il meccanismo di servizio remoto, tutti i file sono memorizzati nelserver, generalmente sul disco, dove c’è abbondanza di spazio, in modo da essereaccessibili da tutti i client. Le richieste sono inoltrate al server, il quale eseguegli accessi, e invia i risultati al client.Poiché esiste una sola copia di ciascun file, non si presentano problemi diconsistenza.Il problema di questo approccio sono le prestazioni: prima che un client possaleggere un file, questo deve essere trasferito dal disco del server alla memoriaprincipale del server, e poi di nuovo attraverso la rete alla memoria principaledel client, ed entrambi i trasferimenti richiedono tempo [Tan94].Un miglioramento considerevole delle prestazioni può essere ottenuto attraversoil 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 comunqueil trasferimento attraverso la rete.Avere una cache nella memoria principale del server è una soluzione facileda realizzare e completamente trasparente ai client. Poiché il server può teneresincronizzate le copie in memoria e quelle sul disco, dal punto di vista del clientc’è solo una copia di ogni file, quindi non sorgono problemi di consistenza.Anche se il caching sul server elimina il trasferimento dal disco, continua adavere bisogno di un accesso attraverso la rete. C’è una corrispondenza direttatra gli accessi e il traffico tra client e server: le richieste di accesso sono tradottein messaggi <strong>per</strong> 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


Stili architetturaliCollaborazione basata su File SystemL’unico modo <strong>per</strong> eliminare l’accesso attraverso la rete è fare il caching sullato 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. Gliaccessi 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 direcente, in modo che gli accessi ripetuti alla stessa informazione possano esseregestiti localmente, senza traffico di rete aggiuntivo.Poiché la memoria principale è sempre più piccola del disco, serve qualchealgoritmo <strong>per</strong> determinare quali file o parti di file debbano essere tenute in cache.La granularità <strong>dei</strong> 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 immagazzinatiin modo contiguo sul disco (o comunque in pezzi molto grandi), <strong>per</strong>mettendotrasferimenti ad alta velocità tra la memoria e il disco, e di conseguenza buoneprestazioni. Il caching <strong>dei</strong> blocchi di disco, <strong>per</strong>ò, usa la cache e lo spazio su discoin maniera più efficiente.Di solito sono tenuti in cache più dati di quanti sarebbero necessari <strong>per</strong>soddisfare una singola richiesta, in modo che molti accessi possano essere servitidai 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 laprobabilità che i dati <strong>per</strong> il prossimo accesso siano disponibili localmente, e riduceil sovraccarico della rete. D’altra parte, aumentano anche il tempo richiesto<strong>per</strong> il trasferimento <strong>dei</strong> dati e la probabilità che sorgano problemi di consistenza.Inoltre, la dimensione della cache è limitata, <strong>per</strong>ciò è necessario decidere cosafare quando essa si riempie: serve una politica di sostituzione.Considerando che i riferimenti alla cache in genere sono molto meno frequentidi quelli alla memoria, si può usare un’implementazione dell’LRU con listecollegate.Quando si deve <strong>per</strong> forza togliere qualcosa, si sceglie il blocco più vecchio:se esiste una copia aggiornata sul disco, la copia in cache viene semplicementeeliminata, altrimenti prima bisogna aggiornare il disco.Tenere la cache nella memoria principale del server, rispetto a tenerla neldisco del client, è generalmente più veloce e comunque molto più semplice. Naturalmente,se si usano grandi quantità di dati, una cache sul disco del clientpotrebbe essere migliore.Quando invece si vuole decidere se tenere la cache nella memoria principaledel client o nel disco del client, è necessario trovare un compromesso tra spazioe prestazioni: il disco ha più capacità e fornisce maggiore affidabilità, ma se siconsidera il tempo di accesso ai dati, è più lento.La maggior parte <strong>dei</strong> sistemi che fanno il caching nei client lo fanno nellamemoria principale, il che <strong>per</strong>mette l’utilizzo di stazioni di lavoro prive di discoe rende l’accesso ai dati più rapido.L’approccio più semplice consiste nel fare il caching <strong>dei</strong> file direttamente all’internodello spazio di indirizzi del processo; quando questo termina, tutti i file42


Stili architetturaliCollaborazione basata su File Systemmodificati vengono scritti sul server. Anche se questo schema ha un sovraccaricoestremamente basso, è efficace solo se i singoli processi aprono e chiudono i fileripetutamente.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 è disponibilenella 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 sitrova nella cache, <strong>per</strong>ciò non c’è bisogno di nessuna chiamata al server quandoil processo del secondo passo lo legge.Altrimenti, si può avere un processo separato che gestisca la cache a livelloutente. Il vantaggio di questa soluzione è che si tiene il kernel separato dalcodice del file system.Il caching nel client introduce inconsistenza nel sistema. Se esistono piùcopie di un file nelle cache <strong>dei</strong> client, le modifiche di una cache devono esserepropagate alla copia principale nel server e poi alle altre copie. Quando dueclient leggono contemporaneamente lo stesso file e poi lo modificano entrambi,sorgono vari problemi. Ad esempio, quando un terzo processo legge il file dalserver ottiene la versione originale, non una delle due <strong>nuove</strong>.Questo problema può essere aggirato adottando la semantica delle sessioni,la quale dichiara che gli effetti della modifica di un file non devono essere visibiliglobalmente finché il file non è chiuso. Un altro problema è che quando i duefile vegono scritti sul server, quello scritto <strong>per</strong> ultimo sovrascriverà l’altro.Un modo <strong>per</strong> risolvere il problema della consistenza è usare l’algoritmo discrittura diretta (write-through).Quando viene modificato un elemento della cache, il nuovo valore viene tenutonella cache, ma viene anche inviato immediatamente al server. Di conseguenza,quando un altro processo legge il file riceve il valore più recente. Questoapproccio garantisce una buona affidabilità in caso di guasti ai client.Si supponga adesso che un processo client sulla macchina A legga un certofile. Quando il client termina, la macchina tiene il file nella sua cache. In seguitoun 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 leggeil file: questo viene preso dalla cache, ma purtroppo quella copia adesso risultaobsoleta. Una possibile soluzione è richiedere che il gestore della cache eseguaun controllo sul server prima di fornire a qualsiasi client un file preso dalla cache.Un altro problema della scrittura diretta è che, nonostante sia utile <strong>per</strong> lalettura, nel caso di un’o<strong>per</strong>azione di scrittura il traffico della rete è lo stesso chesi avrebbe se non ci fosse nessuna cache.Invece di aggiornare la copia del server nel momento in cui viene fatta lascrittura, il client può allora semplicemente prendere nota del fatto che un fileè stato modificato, e poi a intervalli regolari raccogliere tutti gli aggiornamentie inviarli al server contemporaneamente.Questa soluzione è nota come scrittura ritardata (delayed write), e sfruttail fatto che un’unica scrittura di massa di solito è più efficiente di tante piccolescritture singole. Inoltre, molti programmi creano file temporanei, li scrivono, li43


Stili architetturaliCollaborazione basata su File Systemrileggono, poi li cancellano, e tutto ciò avviene in rapida successione. Nel casoin cui questa sequenza abbia luogo e si concluda prima che sia il momento diinviare tutti i file modificati al server, un file già cancellato non viene affattoinviato al server.Il fatto di non aver bisogno di coinvolgere il server <strong>per</strong> i file temporanei puòcomportare un significativo aumento di <strong>per</strong>formance.Naturalmente, ritardare le scritture sporca la semantica, <strong>per</strong>ché quando unaltro processo legge il file, può ottenere una cosa diversa a seconda del momentoin cui effettua l’accesso. Perciò, posticipare le scritture è un compromessotra avere migliori prestazioni e una semantica più pulita, che si traduce inprogrammazione più semplice.La scrittura ritardata introduce anche problemi di affidabilità, poiché in casodi guasto ai client, vengono <strong>per</strong>si tutti i dati non ancora inviati al server.Le varianti dell’algoritmo di scrittura ritardata si differenziano a seconda delmomento in cui un dato in cache che è stato modificato dal client viene inviatoal server; si dice che tale dato è sporco (dirty), e l’azione di scrittura è dettaflushing.Un dato può essere scritto quando sta <strong>per</strong> essere eliminato dalla cache delclient. Altrimenti, si può decidere di adottare la semantica delle sessioni escrivere un file sul server solo dopo che è stato chiuso: questa variante è chiamatascrittura su chiusura (write-on-close).Si può anche aspettare un certo tempo dopo la chiusura <strong>per</strong> vedere se il filesarà cancellato. Come già visto, questa strada implica che se due file in cachesono riscritti in successione, il secondo sovrascrive il primo: è analogo a ciòche accade in un sistema a singola CPU quando due processi aprono e leggonoun file, lo modificano all’interno del loro spazio di indirizzi, e poi lo scrivono.Inoltre, se i file sono a<strong>per</strong>ti <strong>per</strong> tempi brevi oppure sono modificati raramente,questa politica non riduce significativamente il traffico della rete.metodowrite-throughdelayed writewrite-on-closeproprietàfunziona, ma non riduce il traffico <strong>per</strong> le scritturemigliori prestazioni, ma la semantica può essere ambiguacorrisponde alla semantica delle sessioniTabella 1.6: Metodi <strong>per</strong> gestire la cache <strong>dei</strong> file nel clientNella tabella 1.6 sono riassunti i metodi appena visti <strong>per</strong> gestire la cache <strong>dei</strong>file nel client.Ogni client deve affrontare il problema di decidere se la copia di un file nellasua cache locale è consistente o meno con la copia principale sul server. Se lacopia in cache è obsoleta, non può più essere utilizzata <strong>per</strong> gli accessi, e c’èbisogno di ottenerne una aggiornata.Esistono due diversi approcci da utilizzare <strong>per</strong> verificare la validità <strong>dei</strong> datinella cache.Secondo il metodo iniziato dal client, il client controlla la consistenza delleinformazioni tramite una richiesta al server, che introduce un certo ritardo nellerichieste di accesso.44


Stili architetturaliCollaborazione basata su File SystemIl controllo può essere eseguito confrontando la data dell’ultima modificadella versione in cache con quella della versione del server. Invece della data, sipossono usare numeri di versione o checksum.Si può fare un controllo <strong>per</strong> ogni accesso alla cache, o uno solo all’a<strong>per</strong>turadel file, o richiederlo <strong>per</strong>iodicamente. La frequenza con cui questa o<strong>per</strong>azioneviene ripetuta deve essere tale da evitare di creare eccessivo traffico nella rete.Secondo il metodo iniziato dal server, invece, il server tiene traccia <strong>dei</strong> file(o delle parti di file) che ciascun client tiene nella sua cache locale e se verificasituazioni di potenziale inconsistenza <strong>dei</strong> dati, richiede l’aggiornamento.Se si usa la semantica delle sessioni, il server non deve essere notificatoquando viene a<strong>per</strong>to un file già in cache, ma solo quando viene chiusa unasessione di scrittura. Per ogni richiesta di chiusura di un file modificato il serverordina ai client di invalidare le copie locali.Se invece si usa la semantica Unix, bisogna che il server sia notificato ognivolta che viene a<strong>per</strong>to un file, specificando la modalità desiderata, in modoche il caching di quel file possa essere disabilitato, se necessario, passando alfunzionamento 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 presenzadella cache nel client; esso non ha effetti sulla semantica del file system vista daiclient.D’altra parte, il caching nel client offre migliori prestazioni al prezzo di unamaggiore complessità e possibili semantiche più confuse.C’è una diretta analogia tra i metodi di accesso al disco nei file systemconvenzionali e i metodi di accesso remoto nei file system distribuiti.Un meccanismo di servizio remoto è analogo ad eseguire un accesso al disco<strong>per</strong> ogni richiesta. Uno schema di caching in un file system distribuito è un’estensionedelle tecniche di caching nei file system convenzionali: in questi ultimilo 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 <strong>per</strong> migliorarele <strong>per</strong>formance, e possono essere pensate come un ibrido tra caching e servizioremoto.1.5.6 File Area NetworkDa un punto di vista storico il metodo più utilizzato <strong>per</strong> esporre dati adun elevato bacino di utenza e condividerli in maniera collaborativa è stato l’usodi una porzione condivisa di File System. Questa metodologia assodataanche nella prassi dell’amministrazione di sistemi può essere estesa e portatanell’infrastruttura IT applicando tecnologie mature e robuste. Questa soluzioneruota essenzialmente attorno alla risorsa file, quale entità a basso costo dimemorizzazione e facile da trattare sia dallo specialista che dall’utente medio.Attualmente, i dati non strutturati organizzati mediante file system, cioè45


Stili architetturaliCollaborazione basata su File Systemmemorizzati sotto forma di file a cui le applicazioni e gli utenti possono accedere,rappresentano la maggior parte <strong>dei</strong> dati gestiti dalle organizzazioni.I dati strutturati si incontrano solo in rare eccezioni, come ad esempio neisistemi <strong>per</strong> la gestione di database relazionali, i quali possiedono degli strumentiintegrati <strong>per</strong> gestirli [Gee07].Quando si devono spostare <strong>dei</strong> dati non strutturati, <strong>per</strong> aggiungere nuovidispositivi di storage 4 o aggiornare quelli già esistenti, spesso è necessario interrom<strong>per</strong>el’accesso da parte degli utenti e cambiare la mappatura tra la locazionefisica in cui i dati realmente risiedono e l’indirizzo logico sfruttato dagli utenti<strong>per</strong> accedere ad essi.Inoltre, le organizzazioni possono voler classificare i dati a seconda dell’usoche ne viene fatto, <strong>per</strong> determinare quale tipo di dispositivo di storage sia piùadatto a memorizzare <strong>per</strong> quell’informazione.Ad esempio, il materiale che deve essere salvato <strong>per</strong> conformità alle normativedovrà essere memorizzato <strong>per</strong>sistentemente in un dispositivo più sicuro, mentrei file che non devono essere salvati e che non vengono usati regolarmente possonoessere memorizzati in un dispositivo più lento e meno costoso.Negli ultimi tempi, il problema della crescita della quantità di file e della lorogestione ha assunto un’importanza sempre maggiore, mettendo in discussionel’adeguatezza dell’approccio finora utilizzato <strong>per</strong> memorizzare i dati e accederead essi, poiché l’incessante aumento della domanda di capacità di storage portaa infrastrutture sempre più complesse e costose [Wad07].Questa crescente importanza rico<strong>per</strong>ta dai dati contenuti nei file ha portatoalla necessità di trovare un modo migliore <strong>per</strong> eseguire il backup e lo spostamento<strong>dei</strong> dati non strutturati, e più in generale un nuovo paradigma che <strong>per</strong>metta digestire in modo più semplice insiemi diversi di informazioni.Per questi motivi, è stato sviluppato un nuovo approccio alla gestione <strong>dei</strong>file, chiamato File Area Network (FAN).Il termine FAN sta ad indicare un’architettura di riferimento, vista comemodello logico <strong>per</strong> descrivere una classe emergente di tecnologie hardware esoftware, il cui scopo principale è quello di organizzare e gestire grandi quantitàdi file, senza bisogno di interrom<strong>per</strong>e mai l’accesso all’informazione da partedegli utenti, fornendo così una piattaforma flessibile e intelligente <strong>per</strong> spostaree gestire i dati [Bur07].In pratica, si tratta di un complemento alle infrastrutture di storage esistentiche semplifica la gestione <strong>dei</strong> dati, <strong>per</strong>mettendo alle organizzazioni di gestire lostorage <strong>dei</strong> file senza un corrispondente aumento in costo e complessità.Oltre alla continua crescita <strong>dei</strong> dati non strutturati, un altro trend staguidando l’adozione delle tecnologie FAN: lo storage di rete.La memorizzazione <strong>dei</strong> dati si è evoluta da un modello in cui il dispositivo distorage era collegato ad un singolo computer oppure ad un insieme fisicamenteconnesso di computer contigui, ad un modello in cui lo storage è collegato attraversola rete. Ciò ha reso più semplice e più flessibile l’accesso da parte diutenti geograficamente dis<strong>per</strong>si nella rete, ed ha anche contribuito al diffondersidegli approcci basati sulla rete.4 Con il termine “storage” si indicano i dispositivi hardware <strong>per</strong> l’immagazzinamento di datielettronici in modo non volatile.46


Stili architetturaliCollaborazione basata su File SystemLa Storage Area Network (SAN), che divenne popolare a metà degli anninovanta, è un’architettura tramite la quale i dispositivi di storage remoti sonovisti come locali dal sistema o<strong>per</strong>ativo, il quale continua <strong>per</strong>ò ad usare il suo filesystem; è 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 nellostesso <strong>per</strong>iodo, <strong>per</strong>mette invece a molti computer di accedere tramite la reteallo stesso file system, usando appositi protocolli; in questo caso lo storage èvisto come remoto, e i computer richiedono una porzione di un file anziché unblocco di disco. A differenza <strong>dei</strong> file server, i dispositivi NAS possiedono <strong>per</strong>òsolo il software necessario a memorizzare, accedere, e gestire i file.La maggior parte <strong>dei</strong> file server e <strong>dei</strong> dispositivi NAS utilizza uno storageSAN. 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 <strong>per</strong> la gestionedi database. Di conseguenza, la distinzione tra SAN e NAS sta diventandoobsoleta.clientWANLANFANservizi di accesso e di reteottimizzazioneprestazionicontrollo di accessospazio <strong>dei</strong> nomivirtualizzazione<strong>dei</strong> file in retefile serverstoragestoragestorageFigura 1.12: Architettura di una File Area NetworkCome illustrato nella figura 1.12, l’approccio FAN è realizzato attraverso uninsieme di elementi diversi.Per abilitare la condivisione <strong>dei</strong> dati e delle risorse contenute nei file, unaFAN sfrutta le infrastrutture di storage di rete esistenti, come le SAN, i fileserver di un file system distribuito, o i dispositivi NAS, che idealmente devonoessere altamente scalabili e fornire alte prestazioni.Il concetto chiave attorno a cui ruota il funzionamento di una FAN è quellodi uno spazio <strong>dei</strong> nomi unificato e globale.Sostanzialmente, uno spazio <strong>dei</strong> nomi separa la locazione logica <strong>dei</strong> file da47


Stili architetturaliCollaborazione basata su File Systemquella fisica. Una FAN avrà quindi una tabella tramite la quale sarà in grado ditracciare quali file risiedono in una certa locazione fisica, e di far corrisponderequest’ultima ad una locazione logica che non cambi mai nel tempo.Lo spazio <strong>dei</strong> nomi preserva i file system fisici esistenti, <strong>per</strong>mettendo l’accessoad essi come se fossero un’unica entità condivisa, e può essere visto comeun’astrazione logica che rappresenta un singolo punto di accesso alla sottostanteinfrastruttura fisica di storage <strong>per</strong> i file.In questo modo si introduce una virtualizzazione <strong>dei</strong> file che, oltre a fornirel’abilità di organizzare, presentare, e memorizzare i dati in essi contenuti e asemplificare i compiti di amministrazione, <strong>per</strong>mette di mascherare le complessitàrelative alla locazione fisica <strong>dei</strong> dati nella rete, e quindi di fornire agli utentil’accesso ininterrotto alle informazioni, a prescindere dalla loro posizione e dalfatto che essa cambi.Lo spazio <strong>dei</strong> nomi delle FAN supporta piattaforme e file system diversi; ingenere sono utilizzati il Common Internet File System della Microsoft oppure ilNetwork File System della Sun, ma le FAN funzionano con altre piattaforme.Una FAN è distribuita <strong>per</strong> natura, <strong>per</strong>ciò la sua realizzazione prevede un’instradamento(routing) dell’informazione, dirigendo le richieste di file verso leappropriate risorse, e fornendo così agli utenti e alle applicazioni <strong>dei</strong> <strong>per</strong>corsi<strong>per</strong>sistenti <strong>per</strong> accedere ai dati a prescindere dalla loro locazione. Come nel casodelle funzioni di routing tradizionali, questa funzione si basa su metadati cheriguardano la locazione fisica e le modalità di accesso.Inoltre, grazie alle FAN, le organizzazioni possono implementare <strong>dei</strong> serviziche forniscono una grande varietà di funzionalità, quali la migrazione, la replicazione,la classificazione e il posizionamento <strong>dei</strong> dati, il bilanciamento del caricoe il controllo di accesso. Una FAN può giocare un ruolo essenziale anche nellagestione del ciclo di vita dell’informazione (Information Lifecycle Management,ILM) e <strong>dei</strong> contenuti aziendali (Enterprise Content Management, ECM).Per la gestione <strong>dei</strong> file, le FAN eseguono un software che può leggere al lorointerno <strong>per</strong> vedere quali informazioni contengono, e ne raccoglie e verifica imetadati, riuscendo così a posizionare i dati nel dispositivo di storage più appropriato(es. basandosi sulla sua frequenza d’uso). Tra i servizi di ottimizzazione<strong>dei</strong> file c’è anche l’eliminazione <strong>dei</strong> dati duplicati: quando una compagnia creauna copia di un file che già possiede, la FAN può semplicemente aggiungereun puntatore, ossia un collegamento al file originale, nel server che o<strong>per</strong>a lavirtualizzazione 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 esseretrasmesse a qualsiasi altro dispositivo all’interno della FAN.I client che accedono allo spazio <strong>dei</strong> nomi possono essere su qualsiasi tipo dipiattaforma o dispositivo.Le FAN migliorano la connettività <strong>per</strong> gli utenti remoti, ad esempio attraversoil caching <strong>dei</strong> dati, cioè memorizzando il materiale a cui si accede frequentemente<strong>per</strong> velocizzare gli accessi stessi, o la compressione <strong>dei</strong> dati, rendendole informazioni più veloci da comunicare.Le FAN sono in grado di eseguire il caching <strong>dei</strong> file nei siti remoti e memo-48


Stili architetturaliCollaborazione basata su File Systemrizzare 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 automatizzanoil backup, la migrazione e la replicazione <strong>dei</strong> dati. Le FAN sono economicamenteconvenienti, in quanto aumentano l’efficienza <strong>dei</strong> sistemi di storage e riduconola quantità di storage necessaria, eliminando la duplicazione incontrollata <strong>dei</strong>dati.L’attuale mancanza di uno standard introduce il problema dell’intero<strong>per</strong>abilitàtra le FAN di produttori diversi. Accordandosi su un comune modelloarchitetturale di riferimento e implementandolo, sia gli utenti che i venditoririuscirebbero ad ottenere un’efficienza molto maggiore.Proprio al fine di trovare una standardizzazione, la Storage Network IndustryAssociation (SNIA) ha formato una FAN Task Force, la quale ha provvisoriamentedefinito una FAN come “un’infrastruttura orientata alla rete, basata suuno spazio <strong>dei</strong> nomi <strong>per</strong> i file, con uno strato di disaccoppiamento che separal’accesso logico ai file dalla loro locazione fisica, <strong>per</strong>mettendo di applicare ai filee ai file system una varietà di servizi, come ad esempio la migrazione e lareplicazione”.Oggi le FAN introducono soluzioni semplici da usare <strong>per</strong> i compiti elementaridi gestione <strong>dei</strong> file, come lo spostamento e il posizionamento <strong>dei</strong> dati.In futuro, i servizi offerti dalle FAN costituiranno un ponte tra le applicazionie le risorse memorizzate nei file, realizzando funzionalità a lungo attese come lascalabilità globale, l’accesso trasparente e sicuro ai dati e la gestione efficiente ecentralizzata dello storage e <strong>dei</strong> dati.1.5.7 Distributed Version File SystemDa Luglio 2008 alla Codethink (nelle <strong>per</strong>sone di Karl Lattimer, Rob Taylore Mark Doffman) stanno lavorando ad un nuovo progetto chiamato Wizbit[Lat08] <strong>per</strong> implementare un file system condiviso che abbia integrato il supportoal DVCS (Distributed Version Vontrol System). Sebbene il progetto siaenormemente immaturo e al momento di scarsi risultati, si pone in una posizioneinnovativa interessante.Come è possibile vedere dalla wikipage del progetto, Wizbit si presenta inrisposta a problemi pratici di backup, traccimento e condivisione in un contestocollaborativo. Propone quindi di:• mantenere, in modo automatico, uno storico di ciò che accade ai nostridati;• gestire la condivisione tra diversi dispositivi di storage e il merge di versionidiverse;• <strong>per</strong>mettere accessi concorrenti risolvendo in modo trasparente eventualiconflitti;• garantire la possibilità di lavorare offline.49


Stili architetturaliCollaborazione basata su File SystemTutto questo risolverebbe gli inconvenienti che spesso si presentano attualmente:dati sparsi su dispositivi diversi che possono, tra l’altro, contenere versionidifferenti dello stesso file e l’impossibilità di tornare a come erano i documentinel passato o recu<strong>per</strong>arli dalla cancellazione.Con una metodologia puramente pragmatico-implementativa hanno iniziatola stesura del codice in linguaggio Python, riusando il noto version control systemGit [Bau08], mantenendo <strong>per</strong> ogni file, che viene referenziato, un UUID(Universal Unique Identifier), archiviato in un distinto repository (codificandola struttura in XML).Purtroppo l’elaborazione <strong>dei</strong> file con UUID in repository distinti era moltopesante. Inoltre sebbene i singoli file venissero versionati, la struttura delladirectory non lo era. Quindi decisero di non utilizzare direttamente il codice diGit (che tra l’altro ignora il problema della sicurezza).Migrarono al riuso di Bzr (BaZaR Version Vontrol) [Can08], optando <strong>per</strong>riscrittura in linguaggio C, mantenendo i concetti alla base di Git. Del Gitattualmente resta la struttura ad oggetti (blob, commit e tree), archiviati infile compressi e possono che contengono dati o metadati (i metadati allo stadioattuale vengono creati da tracker software).Nell’idea iniziale i file vengono identificati tramite un identificatore universale(UUID), <strong>per</strong>ciò anche il nome del file è considerato un metadato (questo aprela possibilità di salvare un file senza indicarne il nome). A differenza del Gitvengono utilizzati alberi con due soli elementi blob (separando fisicamente i datidai metadati) (figura 1.13).BCTBFigura 1.13: Formato dell’albero in WizbitAttualmente si stanno concentrando sulla creazione di un archivio di oggettidistribuito (in seguito hanno <strong>per</strong>ò programmato di includere come opzioni siaFUSE che GVFS in modo da renderlo un reale file system distribuito). Glioggetti, 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 vienecreata una nuova versione. Ogni Bit ha una serie di Tip, cioè di puntatori alleversioni, che disegnano la sua storia. Da ogni Tip ci si può ricondurre alla radice.All’a<strong>per</strong>tura del file la versione visualizzata è quella più recente: il Tip che lapunta è chiamato Primary Tip mentre gli altri Tip vengono chiamati Normal. Ildatabase che contiene tutti i dati <strong>dei</strong> commit e le loro reciproche relazioni vienechiamato Commit Store.50


Stili architetturaliCollaborazione basata su File SystemPer il momento non è supportata supportata la possibilità di liberare spazio,<strong>per</strong>chè cancellare un file implicherebbe dover cancellare tutta la storia <strong>dei</strong>commit (questo fa sì, inoltre, che i file temporanei debbano essere evitati).Ultimamente i programmatori hanno deciso di smettere di programmare inC e passare a Vala (un nuovo linguaggio che <strong>per</strong>mette di utilizzare tecnichedi programmazione moderne <strong>per</strong> scrivere applicazioni GNOME, il compilatoreVala non crea codice eseguibile, ma traduce in linguaggio C), è stata, inoltre,implementato un tool <strong>per</strong> spostarsi (timeline) tra i vari commit.Sebbene Wizbit sia male documentato (molte informazioni sono irre<strong>per</strong>ibili)e non rappresenti ancora una soluzione seriamente implementata, ha una visioneinnovativa e lungimirante <strong>per</strong> l’integrazione di funzionalità e caratteristichesolitamente considerate <strong>per</strong>tinenti a disgiunti settori di ricerca e sviluppo. Adesempio soluzioni industriali come Global File System (GFS)[KAJ + 99, SH02]di Red Hat, Inc. e Zettabyte File System (ZFS)[Mic08] di Sun Microsystem silimitano ai soli aspetti di file system distribuito, trascurando le problematichedi versioning.Allo stato attuale l’aspetto critico del progetto è la sua immaturità, comesi può evincere dalla sua evoluzione, adotta una metodologia di progettazionefortemente incentrata sul bazaar[Ray02], senza beneficiare ancora dell’effettonetwork.51


Capitolo2Stili di autenticazioneGli accessi illegittimi ai dati memorizzati sui sistemi di elaborazione, la compromissioneo il furto di questi, l’intercettazione di comunicazioni con contenutiriservati, rappresentano oggi una grave minaccia, sempre più difficile da contrastare.La costante a<strong>per</strong>tura di <strong>nuove</strong> reti verso Internet, unita alla rapidacrescita di connessioni di tipo <strong>per</strong>manente, anche tra le utenze private, ha creatoun fertile terreno <strong>per</strong> questo genere di minacce in quanto, a causa della continuaimmissione in rete di nuovi sistemi e servizi, sono cresciuti esponenzialmente ipossibili bersagli da attaccare.I rischi legati alla comunicazione di informazioni su Web coinvolgono interessisociali, politici ed economici. All’aumentare degli interessi e del numerodi partecipanti cresce anche il numero di malintenzionati che intendono trarrefacilmente <strong>dei</strong> benefici in modo fraudolento o non legalmente corretto.All’aumentare del rischio c’è quindi una sensibilizzazione verso il concettodi “sicurezza” in quanto è nell’indole umana attuare delle azioni a seguito diuna valutazione (in modo più o meno consapevole) del rapporto benefici/rischisui servizi usati. All’aumentare del rischio il rapporto scende e questo potrebberallentarne notevolmente la diffusione o il successo.D’altronde i benefici apportati dal Web sono sotto gli occhi di tutti anchese è stato necessario applicare tutte quelle strategie e tecnologie convenienti <strong>per</strong>rendere la sicurezza delle reti di computer “accettabile” 1 , <strong>per</strong>mettendo quindi ditrasformare oppurtunità potenziali in vantaggi concreti.Alla luce di questo si rende necessario implementare efficaci politiche di sicurezzacapaci di contrastare dinamicamente questi <strong>per</strong>icoli, che minano sia la1 È doversoso sottolineare che “accettabile” non significa “migliore possibile”. Questo <strong>per</strong>chésoluzioni troppo spinte tendono a risultare molto costose ed a limitare eccessivamente l’utentenelle azioni che può compiere.


Stili di autenticazioneElementi di crittografiasicurezza del singolo utente privato, sia quella delle grandi reti informaticheaziendali. Sebbene l’elevata dinamicità di questo ambiente, in continua evoluzionesecondo tempistiche e modalità assolutamente imprevedibili, non consentadi essere esaustivi, si cercherà di contrastare questa limitazione mediantel’esposizione <strong>dei</strong> concetti chiave alla base di ogni tecnica.Inizialmente saranno forniti alcuni cenni sulla tecnica cardine attorno al qualeruota l’universo della sicurezza informatica: la crittografia. Al giorno d’oggiinfatti, data la semplicità con la quale risulta possibile intercettare i dati chetransitano sulla rete, un qualunque sistema che si appoggia all’infrastrutturadi comunicazione (che intenda offrire il minimo di sicurezza accettabile anche<strong>per</strong> applicazioni non critiche) deve offrire quantomeno un canale confidenziale<strong>per</strong> 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à <strong>dei</strong> dati.Ciò <strong>per</strong>metterà di valutare le principali tecnologie disponibili <strong>per</strong> la trasmissioneconfidenziale <strong>dei</strong> dati sulle reti di comunicazione, a garanzia che l’interlocutore(in termini di sistema informativo) con il quale l’utente sta comunicandosia realmente quello atteso e che solo coloro preventivamente autorizzati possanoaccedere ai dati riservati.Le tecnologie selezionate, PKI, OpenID e Kerberos, si evidenziano principalmente<strong>per</strong> essere soluzioni di autenticazione, con un approccio infrastrutturaledistribuito. L’identificare l’utente ed autorizzare l’utente identificato sono attivitàparticolarmente critiche in uno scenario come quello discusso nel presentelavoro di tesi.2.1 Elementi di crittografiaLa rete, <strong>per</strong> sua natura, è un mezzo che <strong>per</strong>mette la trasmissione <strong>dei</strong> dati inmodo non “sicuro”. Ovviamente occorre specificare cosa si intende con “modosicuro” in quanto garanzie come quelle relative all’integrità <strong>dei</strong> dati vengono offerte(nello specifico dal protocollo TCP). Normalmente infatti con canale sicurosi intende un canale che, oltre all’affidabilità, offra confidenzialità nella comunicazione;e questa non è una caratteristica propria delle reti di telecomunicazionia meno che non la si vada a ricercare esplicitamente.Un’altra condizione che può essere necessario andare a soddisfare consistenell’avere una ragionevole certezza sull’identità degli interlocutori: in un mondofatto di informazioni è molto facile presentarsi con una identità non corrispondenteal vero, <strong>per</strong>sino rubata. Inoltre esistono tecniche che <strong>per</strong>mettono diingannare gli elementi di rete riguardo al proprio indirizzo IP o MAC.A queste, ed anche altre, problematiche si può dare risposta adottando varietecnologie 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 matematicanata <strong>per</strong> assicurare la riservatezza nelle comunicazioni, cioè <strong>per</strong> trasformare2 Insieme delle informazioni che <strong>per</strong>mettono di identificare, con una certa affidabilità, l’utenteche normalmente intende accedere ad un sistema. L’esempio più semplice, noto edutilizzato è la coppia “nome utente - password”.53


Stili di autenticazioneElementi di crittografiaun messaggio da trasmettere (testo in chiaro) in qualcosa di incomprensibile achiunque non sia il destinatario previsto (testo cifrato). Il suo scopo iniziale eradunque 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 cheal destinatario legittimo, è invece detta steganografia.La crittografia è ormai utilizzata in una grande quantità di applicazioni conle quali interagiamo ogni giorno; il commercio elettronico, i servizi bancari o lacomunicazione mobile e satellitare sono solo alcuni esempi degli innumerevolicontesti in cui viene utilizzata.In particolare ha assunto un ruolo centrale in tutta la gestione della sicurezza<strong>dei</strong> sistemi informatici e nelle reti di computer; la potenza di calcolo oggidisponibile costituisce un grande supporto allo sviluppo e all’utilizzo della crittografia.Il suo campo di applicazione si è espanso molto includendo tecnicheatte alla gestione di tutti i problemi di sicurezza conosciuti. Questi possonoessere suddivisi in quattro aree fondamentali.• Confidenzialità. L’informazione risulta accessibile solo a chi ha il dirittodi usufruirne.• Integrità <strong>dei</strong> dati. È possibile determinare se i dati siano stati manipolatisenza autorizzazione.• Autenticazione.entità.Permette l’identificazione di un messaggio o di una• Non ripudiabilità. Rende impossibile che una entità neghi di avercostruito un certo messaggio crittato.Per chiarire la terminologia adottata, si definisce algoritmo di cifratura latrasformazione matematica utilizzata <strong>per</strong> ottenere il testo cifrato e algoritmodi decifratura la trasformazione inversa utile alla ricostruzione del messaggio inchiaro.Le trasformazioni di cifratura possono essere distinte in due classi: i cifrarie i codici. Col primo termine si intendono tutte quelle trasformazioni che manipolanola codifica del testo in chiaro, bit <strong>per</strong> bit, cioé senza considerare lastruttura del messaggio; il secondo termine identifica quegli algoritmi che sostituisconoogni 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 generedue parametri: il messaggio e la chiave; quest’ultima è una stringa relativamentecorta che serve a modulare il comportamento degli algoritmi: in pratica fissanouna particolare trasformazione all’interno dello spazio di possibilità individuatoda uno specifico algoritmo. In questo modo è necessario tenere nascosta esclusivamentela chiave ed è possibile divulgare l’algoritmo; cercare di tenerlo segreto,pratica definita sicurezza <strong>per</strong> occultamento, non ha mai funzionato. Inoltre renderedisponibile, e quindi studiabile, un algoritmo, di qualunque natura essosia, è sempre positivo se non altro <strong>per</strong> via della spontanea “consulenza” fornitadalla comunità di es<strong>per</strong>ti del settore. L’idea che l’algoritmo sia noto e che il54


Stili di autenticazioneElementi di crittografiaFigura 2.1: Crittografia a chiave privata - cifraturaFigura 2.2: Crittografia a chiave privata - decifraturasegreto stia esclusivamente nella chiave è detta principio di Kerckhoffs, dal nomedel crittografo fiammingo Auguste Kerckhoffs che <strong>per</strong> primo lo formulò nel1883 [Ker83].La notazione utilizzata <strong>per</strong> trattare questo tipo di argomenti è la seguente:con C = E K (P ) si intende l’o<strong>per</strong>azione di cifratura del testo in chiaro P usandola chiave K ottenendo come risultato C; analogamente P = D K (C) indical’o<strong>per</strong>azione di decifratura mirata all’ottenimento del testo in chiaro. Da ciòsegue che D K (E K (P )) = P .2.1.1 Crittografia a chiave privataLa crittografia a chiave privata, detta anche crittografia simmetrica, trattaquei metodi crittografici in cui sia il mittente che il destinatario condividono lastessa chiave o, meno comunemente, possiedono due chiavi diverse ma legatein modo semplice da un punto di vista computazionale. Fino al 1976 è statal’unica forma crittografica nota.Gli algoritmi a chiave privata possono essere suddivisi in cifrari a flusso ecifrari a blocco; i primi cifrano i bit del messaggio uno <strong>per</strong> uno mentre i secondilavorano su insiemi di bit considerandoli come una singola unità.Questo tipo di crittografia <strong>per</strong>mette di ottenere confidenzialità del messaggio:se un utente A vuole comunicare in maniera sicura con un utente B è sufficientecifrare il messaggio con la chiave segreta. Solo chi è in possesso della chiavepotrà decifrare correttamente il messaggio applicando l’algoritmo di decifraturanecessario.La crittografia a chiave privata non può essere utilizzata <strong>per</strong> risolvere proble-55


Stili di autenticazioneElementi di crittografiami di autenticazione e non ripudiabilità in quanto la stessa chiave è conosciutasia dal mittente che dal destinatario di una conversazione; entrambi possonosfruttare 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].2.1.2 Crittografia a chiave pubblicaIl più grande problema della crittografia a chiave privata è senza dubbio lagestione delle chiavi. Ogni coppia di interlocutori deve condividere una propriachiave segreta, portando ad un numero complessivo di chiavi che cresce colquadrato del numero di interlocutori. Inoltre è sempre presente il problema dicome scambiarsi la chiave segreta quando ancora non è disponibile un canalesicuro di comunicazione.Nel 1976 è stata presentata una nuova forma di crittografia: la crittografia achiave pubblica; questa <strong>per</strong>mette a due interlocutori di comunicare in manierasicura senza dover prima concordare una chiave segreta condivisa. Ciò è resopossibile grazie all’utilizzo di una coppia di chiavi crittografiche, denominatechiave pubblica e chiave privata, legate fra loro da un rapporto di tipo matematico.Il legame deve essere tale da rendere virtualmente impossibile ottenere lachiave privata a partire da quella pubblica e viceversa.In generale gli algoritmi a chiave pubblica sono computazionalmente moltopiù complessi, e quindi più lenti, di quelli a chiave privata, fino a 3 ordinidi grandezza, ma <strong>per</strong>mettono di fornire una soluzione a una ampia varietà diproblemi di sicurezza.Ogni utente dispone di una coppia di chiavi ed è sua cura generarle; lachiave pubblica può essere distribuita liberamente, e aggiunta, <strong>per</strong> esempio, adun elenco pubblico, mentre la sua controparte privata deve restare segreta. Laprima viene utilizzata tipicamente <strong>per</strong> cifrare mentre la seconda <strong>per</strong> decifrare.Questo tipo di crittografia <strong>per</strong>mette di ottenere non solo confidenzialità delmessaggio in modo molto flessibile, ma anche autenticazione e non-ripudiabilità.Se un utente A vuole comunicare in maniera sicura con un utente B è sufficientecifrare il messaggio con la chiave pubblica del destinatario. In questo modo soloB sarà in grado di leggere il contenuto del messaggio utilizzando la propriachiave privata.Se poi, prima di essere inviato, il messaggio viene nuovamente cifrato mastavolta con la chiave privata del mittente è possibile ottenere anche autenticazionee non-ripudiabilità. Infatti <strong>per</strong> ottenere il contenuto del messaggio ildestinatario dovrà decifrarlo due volte, prima utilizzando la chiave pubblica delmittente e poi la propria chiave privata. Egli sarà dunque sicuro dell’identitàdel mittente, della confidenzialità del messaggio e, in ultima istanza, il mittentenon potrà non riconoscere di aver costruito il messaggio.La descrizione può essere effettuata anche esaminando il modo in cui le chiavivengono utilizzate. Se un utente vuole ottenere confidenzialità dovrà cifrare ilmessaggio con la chiave pubblica del destinatario di modo che solo lui possaleggerlo, essendo in possesso della chiave segreta. Se invece volesse ottenereautenticazione e non-ripudiabilità dovrebbe cifrare il messaggio con la propria56


Stili di autenticazioneElementi di crittografiaFigura 2.3: Crittografia a chiave pubblicachiave privata; l’identità del mittente sarebbe provata dalla corretta decifraturadel messaggio a mezzo della sua chiave pubblica.L’esempio più significativo, <strong>per</strong> diffusione e robustezza, di algoritmo a chiavepubblica è senza dubbio l’RSA [Kal98].2.1.3 Crittografia e firma digitaleAl di fuori del contesto informatico, <strong>per</strong> poter considerare valido un documentoè necessaria la presenza di una firma autografa autorizzata che lo accompagni.È quindi necessario trovare un meccanismo equivalente <strong>per</strong> verificare lavalidità <strong>dei</strong> documenti elettronici. In pratica è necessario trovare un sistema colquale un utente possa inviare un messaggio firmato al destinatario alle seguenticondizioni:• il destinatario può verificare l’identità del mittente. In uno schema difunzionamento basato su diritti di accesso è fondamentale identificare concertezza il mittente di un messaggio, <strong>per</strong> esempio, <strong>per</strong> controllare se quellaspecifica identità ha diritto di richiedere un determinato servizio;• il mittente non può ripudiare il contenuto del messaggio. Deve essere impossibile<strong>per</strong> il mittente negare di aver costruito e firmato un qualsiasimessaggio, la firma deve costituire prova certa del coinvolgimento del mittentenella comunicazione. Questo requisito è necessario <strong>per</strong> proteggere ildestinatario;• il destinatario non può falsificare i messaggi ricevuti. In questo modo nonpuò essere attribuito al mittente un messaggio non inviato e i documentifirmati non possono essere alterati se non dall’autore. Questo requisito ènecessario <strong>per</strong> proteggere il mittente.57


Stili di autenticazioneElementi di crittografiaAnche se esistono degli schemi di firma digitale basata sulla crittografia simmetricaè la crittografia a chiave pubblica ad essere comunemente utilizzata inquesto tipo di o<strong>per</strong>azioni.Generalmente <strong>per</strong> utilizzare le firme digitali sono necessari tre algoritmi:• un algoritmo di generazione delle chiavi;• un algoritmo <strong>per</strong> firmare i documenti;• un algoritmo di verifica.Se un utente A vuole inviare un messaggio ad un utente B in modo chequest’ultimo sia sicuro dell’identità del suo interlocutore, non dovrà far altroche allegarvi una firma digitale. Questa, generata a partire dalla chiave privatadi A, non è altro che una stringa di caratteri. Una volta ricevuto il messaggio,B controllerà la genuinità della comunicazione tramite l’algoritmo di verificautilizzando la chiave pubblica di A. Se l’esito è positivo, B è certo dell’identitàdel mittente; questo <strong>per</strong>chè gli algoritmi <strong>per</strong> la firma digitale sono appositamentecostruiti <strong>per</strong> rendere impraticabile, <strong>per</strong> via della complessità computazionale delproblema, la costruzione di una firma <strong>per</strong> un dato messaggio senza conoscere lachiave privata.Per dare alla firma una validità legale è necessario poter associare la chiavepubblica all’identità di una <strong>per</strong>sona. Per fare ciò una autorità di certificazionerilascia quello che viene chiamato certificato digitale firmandolo con la propriachiave privata. In questo modo chiunque sarà in grado di verificarne la genuinitàutilizzando la chiave pubblica dell’ente. Esistono vari formati <strong>per</strong> i certificati achiave pubblica ma il più usato è lo standard X.509 [HFPS99].2.1.4 Funzioni hashUna funzione hash è una funzione univoca e non invertibile che trasformaun testo di lunghezza arbitraria in una stringa di lunghezza fissa detta valorehash, checksum crittografico o message digest. Nel caso specifico la funzione ditrasformazione o<strong>per</strong>a sui bit di un qualsiasi file generando una impronta digitaledello stesso.Dato che i possibili input dell’algoritmo, con dimensione finita maggioredell’hash, sono più degli hash possibili è ovvio che possano esistere messaggidiversi che vengono mappati nello stesso digest. In questo caso si parla dicollisione e le funzioni devono essere costruite <strong>per</strong> minimizzarne la realizzabilità.Inoltre una funzione ritenuta sicura non dovrebbe <strong>per</strong>mettere di risalire, in untempo congruo con la dimensione dell’hash, al testo da cui il digest è derivato.In crittografia le funzioni hash vengono utilizzate <strong>per</strong> verificare l’integrità diun messaggio dato che anche una piccola modifica dell’input genera un messagedigest completamente differente. È sufficiente inviare il valore hash insieme almessaggio e il destinatario sarà in grado di determinare se è stato modificatodurante il trasferimento, intenzionalmente o meno. Questo tipo di o<strong>per</strong>azioneè definito controllo di ridondanza (figura 2.4). Sotto determinate condizioni,come la conoscenza della distribuzione delle possibili <strong>per</strong>turbazioni e l’utilizzodi una funzione hash adatta, è possibile correggere gli errori. Questa classe difunzioni è chiamata codici a correzione d’errore.58


Stili di autenticazionePublic Key InfrastructureFigura 2.4: Funzioni hash - controllo di ridondanzaLe funzioni hash possono essere utilizzate <strong>per</strong> creare velocemente le firmedigitali anche <strong>per</strong> file di grandi dimensioni: invece di firmare tutto il documento,o<strong>per</strong>azione che richiede calcoli lunghi e complessi <strong>per</strong> via degli algoritmi dicrittografia asimmetrica impiegati, risulta computazionalmente più convenienteautenticare solo il message digest dello stesso. Questo, tra le altre cose, <strong>per</strong>metteanche di creare documenti di cui può essere verificata l’integrità ma chenon devono essere obbligatoriamente crittati: il messaggio è infatti trasmesso inchiaro 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 InfrastructureCome è stato introdotto nel paragrafo 2.1, la crittografia asimmetrica offreuna serie di opportunità che riguardano la confidenzialità e l’integrità <strong>dei</strong> dati,l’identificabilità certa <strong>dei</strong> messaggi e delle entità in gioco (autenticazione) e lanon ripudiabilità. Ovviamente non è la tecnologia di <strong>per</strong> se a garantire chequeste opportunità si trasformino in vantaggi concreti, ma l’uso che ne vienefatto. A esempio, il fornire ad un utente una coppia di chiavi asimmetriche nongarantisce che, tramite le stesse, sia possibile identificare i messaggi di postaelettronica da esso inviati: banalmente l’utente potrebbe non utilizzare le chiavi<strong>per</strong> firmare le email, <strong>per</strong> non parlare del più insidioso problema che nasce seesso non riesce a mantenere segreta la propria chiave privata. In quest’ultimocaso infatti, potrebbe essere possibile imbattersi in un caso di sicurezza apparente:confidando sulle potenzialità della crittografia si potrebbe pensare che un59


Stili di autenticazionePublic Key Infrastructurecerto messaggio di posta sia riconducibile ad un determinato utente quando inrealtà, non essendo esso riuscito a mantenere segreta la chiave privata, chiunque(ovviamente in grado di accedere alla stessa) avrebbe potuto firmare l’email alposto dell’utente, eventualmente ignaro della situazione, spacciandosi <strong>per</strong> esso.È chiaro quindi che la sicurezza non è un traguardo che si raggiunge esclusivamentecon 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, è necessariofissare tutta una serie di vincoli e procedure o<strong>per</strong>ative, oltre alle soluzioni prettamentetecniche, <strong>per</strong> raggiungere <strong>dei</strong> risultati in questo contesto che abbianouna qualità accettabile. Le infrastrutture a chiave pubblica (PKI, Public KeyInfrasctructure) sono quindi delle soluzioni tecniche, organizzative, politiche equant’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], maun’infrastruttura che, pur utilizzando i certificati digitali come metodo di autenticazione,ha lo scopo di stabilire le modalità tecniche ed i processi organizzativinecessari <strong>per</strong> il rilascio e la gestione <strong>dei</strong> certificati (con le relative chiavi) in modoefficace, sicuro ed efficiente.2.2.1 Elementi costituenti una PKILe PKI possono essere realizzate in contesti diversificati. Ad esempio leaziende possono realizzarsi delle PKI private <strong>per</strong> l’assegnazione <strong>dei</strong> certificativalidi esclusivamente all’interno dell’azienda stessa, come trovare realtà affermateche rilasciano certificati <strong>per</strong> l’utenza Internet. Indipendentemente dalcontesto, 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) <strong>per</strong> l’emissione <strong>dei</strong> certificati;• un insieme di politiche prestabilite <strong>per</strong> la gestione di ognuna delle possibilio<strong>per</strong>azioni effettuabili dalla PKI;• un insieme di certificati digitali;• un insieme di applicazioni in grado di usufruire <strong>dei</strong> servizi forniti dallaPKI.2.2.2 Le Certification AuthorityLe CA sono ovviamente il cuore di ogni PKI ed ogni PKI ne ha almenouna. Sono costituite da un software <strong>per</strong> la gestione di certificati (detto CPS,Cryptographic Service Provider) e da una coppia di chiavi asimmetriche di cuiquella 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 cheviene utilizzata esclusivamente <strong>per</strong> creare e firmare i certificati propri delle CA60


Stili di autenticazionePublic Key Infrastructuredi livello inferiore. La root CA utilizza un certificato digitale self-signed (autofirmato)in quanto è l’elemento di partenza della catena di trust al quale vienefornita fiducia <strong>per</strong> definizione. Questo fa capire il motivo <strong>per</strong> il quale le rootCA non dovrebbero essere utilizzate <strong>per</strong> emettere i certificati ad eccezioni diquelli <strong>per</strong> le CA di livello inferiore: è assolutamente prioritario mantenere talecategoria di CA al sicuro, in quanto la compromissione delle stesse equivale allacompromissione dell’intera catena di trust ovvero di tutta la PKI. Normalmentequindi le root CA vengono mantenute al sicuro, disconnesse dalla rete e nonaccessibili fisicamente.L’architettura più generale (aggiungere ulteriori livelli, seppur fattibile daun punto di vista pratico, non apporta ulteriori vantaggi) prevede una gerarchiaa 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ù brevementeIssuing CA).Root-0 CAX XPolicy-0 CAX XX XX XRevoca Cert.X XX XX XIssuing-n CARilascio Cert.Policy-1 CAAnniMesiGiorni/OreFrequenza Rilasci/Revoche(ordini di grandezza a titolo esemplificativo)UserServerFigura 2.5: Struttura gerarchica delle CA di una PKI.61


Stili di autenticazionePublic Key InfrastructureIn questo scenario, figura 2.5, l’unico scopo delle root CA è quello di emettere(e, qualora necessario, revocare) i certificati ed eventualmente di generare lechiavi <strong>per</strong> le Policy CA; quest’ultime sono destinate a firmare (e, se necessario,revocare) i certificati ed eventualmente a generare le chiavi <strong>per</strong> 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) dellaPKI.Questo approccio <strong>per</strong>mette di mantenere le root CA al sicuro anche in contestifortemente distribuiti (ad esempio multinazionali con sedi dislocate in tuttoil mondo) nei quali si riesce ad ottenere la sufficiente flessibilità nel rilascio enella revoca delle Issuing CA attraverso le Policy CA. Questo <strong>per</strong>ché le IssuingCA, dovendo o<strong>per</strong>are quotidianamente <strong>per</strong> il rilascio e la revoca <strong>dei</strong> certificati,sono esposte a compromissioni ed in tal caso è necessario revocarle (la revoca<strong>dei</strong> certificati, e conseguentemente l’invalidazione di tutto ciò che è stato firmatocon gli stessi, è un argomento trattato successivamente). Viceversa le Policy CAe, a maggior ragione, le root CA entrano in gioco solo raramente e ciò consentedi garantirne l’integrità mantenendole in luogo sicuro disconnesse dalla rete.In ogni caso è frequente l’implementazione di PKI a due soli livelli in cui leroot CA emettono direttamente i certificati <strong>per</strong> le Issuing CA.2.2.3 Le Policy delle PKILe policy relative ad una PKI servono <strong>per</strong> definire le regole necessarie agarantire la sicurezza delle chiavi, i processi di emissione, rinnovo e revoca <strong>dei</strong>certificati, le classi <strong>dei</strong> certificati (<strong>per</strong> utenti ad uso firma posta elettronica,<strong>per</strong> utenti ad uso accesso a servizi telematici, destinati a web server, destinati aserver di posta, . . . ) ed i relativi dettagli (come la durata temporale predefinita)e quant’altro.Per quanto riguarda la realizzazione di PKI pubbliche (ad esempio comequelle create da organizzazioni a fini commerciali come VeriSign) è necessarioche 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 <strong>dei</strong> certificati, eccetera. Se la PKI è ditipo privato, non è richiesto che venga pubblicato il CPS, anche se è fortementeconsigliato produrre una chiara documentazione relativamente alle metodologieutilizzate <strong>per</strong> validare l’identità di coloro ai quali vengono rilasciati i certificati,nella quale si vadano ad indicare chi può revocare i certificati e come vienedistribuita la lista contenente i certificati revocati, con quale frequenza e conquali modalità si procede <strong>per</strong> l’archiviazione <strong>dei</strong> certificati ed infine quali sonole applicazioni autorizzazione e non autorizzate all’uso <strong>dei</strong> certificati.2.2.4 Rilascio, gestione e revoca <strong>dei</strong> certificatiI processi inerenti al rilascio ed alla gestione <strong>dei</strong> certificati sono abbastanzacomplessi. In ogni caso è possibile descrivere una sequenza di o<strong>per</strong>azioni chepossono essere prese a riferimento <strong>per</strong> la descrizione del ciclo di vita di uncertificato. Ciò non toglie che alcuni <strong>dei</strong> passi successivamente descritti possano62


Stili di autenticazionePublic Key Infrastructurenon essere svolti oppure essere svolti in ordine diverso; resta comunque intesoche 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 <strong>per</strong> un motivo qualunque;2. viene generata una coppia di chiavi asimmetriche da assegnargli. Si notiche normalmente sarà la CA a fornirgli tutto quello che serve, chiavicomprese, ma questo non è necessario: la generazione delle chiavi è un’o<strong>per</strong>azioneda effettuare a monte, del tutto scorrelata dal resto. Inoltre èfrequente l’utilizzo della stessa coppia di chiavi <strong>per</strong> la generazione di piùcertificati;3. l’utente crea il Certificate Signing Request (CSR). Il CSR è il documentoche viene inviato alla CA <strong>per</strong> l’emissione del certificato. Come minimocontiene la chiave pubblica dell’utente e tutte le informazioni necessarie <strong>per</strong>identificarlo univocamente (nel caso <strong>dei</strong> certificati X.509 il distinguishedname), ma può contenere ulteriori informazioni come l’indirizzo email, lanazionalità, il paese eccetera. Il CSR viene creato dall’utente firmandoquesto 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 pubblicadell’utente con la propria chiave privata creando di fatto il certificato;6. il certificato viene fornito all’utente il quale, in abbinamento alla propriachiave privata, può essere utilizzato <strong>per</strong> gli scopi del passo 1.Alcune considerazioni. In tutta la procedura, grazie alle caratteristiche dellacrittografia asimmetrica, le uniche entità da mantenere segrete sono solo le chiaviprivate. Tutto il resto può essere considerato pubblico, certificato compreso.Questo spiega il motivo <strong>per</strong> il quale spesso la stessa coppia di chiavi viene utilizzata<strong>per</strong> più certificati: una delle fasi più critiche di tutto il processo, se nonla più critica in assoluto, è quella di fornire la coppia di chiavi all’utente. Inquesta 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 legittimoproprietario (si pensi al fatto che la firma digitale, intesa nell’accezione delCodice dell’Amministrazione Digitale, è stata equiparata a tutti gli effettialla firma autografa). Si noti che essendo il CSR emesso dal richiedente efirmato con la propria chiave privata, la CA, nell’ipotesi in cui tali chiavisiano state fornite all’utente secondo le opportune modalità, ha tuttigli strumenti <strong>per</strong> verificarne l’attendibilità (andando a verificare la firmautilizzando la chiave pubblica dell’utente);• la seconda riguarda la confidenzialità della trasmissione delle chiavi: èassolutamente necessario che, anche se l’utente è davvero il legittimo proprietariodelle stesse, esse vengano fornite tramite un canale sicuro. Ovviamentese le chiavi finiscono nelle mani sbagliate, lo sono a prescindere63


Stili di autenticazionePublic Key Infrastructuredal fatto che siano state fornite alla <strong>per</strong>sona sbagliata oppure che sianostate intercettate da un soggetto terzo durante la trasmissione alla <strong>per</strong>sonacorretta.L’emissione del certificato può avvenire, ovviamente, <strong>per</strong> scopi diversi. Fermorestando la validità delle chiavi e la corretta associazione con l’utente, lavalidità del CSR eccetera, la CA, quando emette il certificato, va a specificarenello stesso <strong>per</strong> quali applicazioni può essere utilizzato oltre ad altre informazioniquali l’intervallo temporale di validità. A titolo esemplificativo possonoessere citati certificati validi solo <strong>per</strong> la firma di email, <strong>per</strong> l’utilizzo con applicazionilato client (ad esempio <strong>per</strong> l’autenticazione a reti private virtuali), <strong>per</strong>l’autenticazione via web, <strong>per</strong> l’erogazione di servizi in rete eccetera.Infine, ma certamente non a causa del fatto che questo aspetto assume unaminore importanza nell’ambito di una PKI, resta da analizzare il processo direvoca <strong>dei</strong> certificati. La revoca di un certificato può essere effettuata <strong>per</strong> varimotivi. Il primo motivo riguarda la compromissione delle chiavi: è assolutamentenecessario rendere inutilizzabile il certificato qualora la chiave privatadell’utente venga violata. In questo modo, anche se le chiavi cadono nelle manisbagliate, nel momento in cui il certificato non è più valido esse diventanoinutilizzabili. Un’altra causa che porta alla revoca di un certificato è legataa variazioni di stato dell’utente. Ad esempio se un’azienda fornisce tramitela propria PKI un certificato agli utenti <strong>per</strong> l’accesso ai servizi interni, risultaovviamente necessario attuare una revoca <strong>dei</strong> certificati <strong>per</strong> quegli utenti chelasciano l’azienda prima della scadenza <strong>dei</strong> certificati stessi.Il processo di revoca avviene indirettamente e segue il principio delle blacklist:la CA genera e pubblica/distribuisce un documento, detto Certificate RevocationList (CRL), contenente la lista <strong>dei</strong> certificati revocati. Resta intesoche ogni CA può revocare solo i certificati a lei riconducibili e la garanzia digenuinità della lista è ovviamente fornita tramite un meccanismo di firma (ildocumento è emesso e firmato dalla CA stessa). Una difficoltà che spesso vieneincontrata riguarda la difficoltà nel distribuire tempestivamente la CRL a tuttele applicazioni, in modo da inibire l’uso <strong>dei</strong> certificati revocati. Si pensi adesempio ai certificati utilizzati <strong>per</strong> l’autenticazione: se il server non ha ricevutola CRL aggiornata, ignorando quindi la revoca di alcuni certificati, continuerebbea fornire servizi anche ad utenti che non ne avrebbero più diritto (se nonaddirittura in mala fede).Infine la revoca di un certificato relativo ad una CA, non solo impedisce allaCA di emettere nuovi certificati, ma invalida tutti i certificati emessi dalla CAstessa. Questo aspetto è di particolare importanza <strong>per</strong> la garantire l’affidabilitàdell’intera PKI: se una CA viene compromessa al tempo t 1 e la sco<strong>per</strong>ta dellacompromissione avviene al tempo t 1 +δ (ovviamente con δ > 0) è assolutamentenecessario poter invalidare tutti i certificati emessi fra t 1 e t 1 + δ, certificatiche potrebbero essere stati emessi dall’attaccante <strong>per</strong> scopi illeciti. Anche semeno evidente è altrettanto importante l’invalidazione <strong>dei</strong> certificati emessi altempo t 0 < t 1 (quindi di tutti i certificati). Infatti, dopo la compromissionedella CA, l’attaccante potrebbe retrodatare l’emissione di un CSR (all’istantet ′ 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 i64


Stili di autenticazioneOpenIDcertificati emessi dalla CA, avrebbe piena validità <strong>per</strong> la PKI in quanto nonsarebbe possibile distinguere il certificato creato al tempo t ′′0 (compromesso) daun qualunque altro certificato valido. Ovviamente questo tipo di attacco non èattuabile <strong>per</strong> servizi come l’autenticazione, nei quali è immediata (e condivisafra le parti) la validazione dell’istante temporale in cui avviene l’azione.2.3 OpenIDOpenID è uno standard tecnologico a<strong>per</strong>to, non proprietario e il cui obiettivoè quello di creare uno livello di autenticazione Web assegnando all’utente unasingola identità digitale. Si tratta di un’architettura (basata sull’infrastrutturaInternet già esistente) che semplifica le o<strong>per</strong>azioni di login all’utente, in quantoelimina la necessità di creare username multipli <strong>per</strong> accedere a diversi siti Web.Un utente che accede ad un sito che adotta OpenID, non ha bisogno di creareusername e password specifici <strong>per</strong> quel sito (e quindi detenuti da esso), ma ha solobisogno di essere registrato con un qualsiasi OpenID Identity Provider (IdP).Poiché OpenID è decentralizzato, non c’è bisogno di nessuna autorità centraleche approvi o registri gli IdP ed i siti Web che adottano lo standard. Un utentepuò scegliere liberamente quale IdP usare e mantenere il suo identificatorequalora decidesse di cambiarlo. Ad oggi sempre più siti Web stanno adottandoquesto standard, infatti organizzazioni come AOL, BBC, Google, IBM, Microsoft,MySpace, Orange, VerySign, Yandex, Yahoo! sono già degli IdP e qualchemigliaio di siti Web ne supportano il login. La OpenID Foundation (OIF),un’organizzazione senza scopo di lucro, è stata realizzata al fine di aiutare lagestione di copyright, marchi, marketing ed altre attività inerenti la comunitàOpenID, ed il suo obiettivo è tutelare OpenID.2.3.1 Il processo di autenticazione OpenIDPrima di descrivere in dettaglio il processo di autenticazione tramite OpenID,è opportuno definire il glossario di base <strong>dei</strong> 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 identificatoreOpenID.• OpenID Identity Provider (OP) o Identity Provider (IdP): un service providerche offre il servizio di registrazione di URL o di XRI OpenID eeffettua l’o<strong>per</strong>azione di autenticazione OpenID.• Relying Party (RP): un’applicazione Web che vuole verificare l’identificatoredell’end-user.• OP Endpoint URL: è la URL ricavata dal RP con un o<strong>per</strong>azione di“discovery” sull’identificatore fornito dall’utente.• User-agent: il programma (<strong>per</strong> esempio un browser) che l’end-user utilizza<strong>per</strong> accedere all’OP e al RP.65


Stili di autenticazioneOpenIDCon queste keyword, è ora possibile spiegare in dettaglio il processo di autenticazione.Un sito Web RP (es. www.wishlistr.com) mostra un form OpenIDlogin da qualche parte nella pagina. Diversamente da un tipico form dilogin con i campi di username e password, un form OpenID ha soltanto uncampo <strong>per</strong> l’inserimento dell’identificatore OpenID (o del nome del provider)dell’end-user. Va evidenziato come questo standard, in quanto a<strong>per</strong>to e nonproprietario, <strong>per</strong>mette ad un qualunque utente che sia proprietario di un dominio(come ad esempio un blog <strong>per</strong>sonale o una homepage) di usare la propriaURL come identificatore OpenID inserendo tramite HTML un tag OpenID chesegue le specifiche [Fit07]; oppure più semplicemente può registrare un identificatoreOpenID tramite un OP, quest’ultimo offre infatti la possibilità dicreare un XRI o un URL (tipicamente di terzo livello) <strong>per</strong> l’end-user che saràautomaticamente configurato <strong>per</strong> il servizio di autenticazione OpenID. Unend-user, che avrà quindi precedentemente registrato un identificatore OpenID(es. me.yahoo.com/a/OIzLz9V.0cnD51hKEuSK.kFMofiyuNZZlQ-- nel caso incui l’identificatore sia una URL) con un OP (es. yahoo.com), nel momento incui visita il sito Web RP (es. www.wishlistr.com) digita il suo identificatorenel form OpenID login. Il sito Web RP a questo punto esegue il processo didiscovery sull’identificatore OpenID dell’utente e quindi ottiene l’OP EndpointURL di cui l’end-user si serve <strong>per</strong> l’autenticazione. La discovery è infatti il processoin cui il RP usa l’identificatore inserito dall’utente <strong>per</strong> scoprire (discover)le informazioni necessarie <strong>per</strong> poter effettuare l’autenticazione. Con OpenID 2.0[Fit07] ci sono tre modi <strong>per</strong> effettuare la discovery:1. Se l’identificatore è un XRI sarà ottenuto un documento XRDS (eXtensibleResource Descriptor Sequence) [WRM + 08] contenente le informazioninecessarie.2. Se invece l’identificatore è una URL (come nell’esempio visto sopra) siutilizzerà lo Yadis protocol [Mil06], <strong>per</strong> mezzo del quale si otterrà ancoraun XRDS document.3. Infine se lo Yadis protocol non è in grado di restituire un documentoXRDS valido, allora le informazioni necessarie saranno ottenute grazie aduna discovery basata su HTML.A questo punto il RP può effettuare la procedura di autenticazione vera epropria, e ciò può essere fatto in due modi (vedi il flow chart di figura 2.6 e lostate 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 <strong>per</strong> poter accedere alRP.2. checkid-setup. Viene eseguita se l’end-user non è ancora loggato sull’OPoppure nel caso in cui l’autenticazione con il checkid-immediatenon va a buon fine. Con questa seconda modalità, l’end-user comunicacon l’OP direttamente, usando lo stesso browser utilizzato <strong>per</strong> accedere66


Stili di autenticazioneOpenIDal sito del RP. Verranno quindi richieste all’end-user le credenziali registratesull’OP (username e password) <strong>per</strong> verificare la reale appartenenzadell’identificatore all’utente che si sta collegando al RP.Opzionalmente il RP e l’OP si scambiano una chiave segreta che è usata dalOP <strong>per</strong> firmare i successivi messaggi verso il RP in modo tale che quest’ultimopotrà verificarne l’autenticità. Per questo processo viene usato il Diffie-HellmanKey Exchange [Res99]. Dopo che l’identificatore OpenID è stato identificato,l’autenticazione OpenID è riuscita e l’end-user è loggato sul sito Web RP conl’identificatore dato. È importante notare che OpenID non dispone di un propriosistema di autenticazione, <strong>per</strong>tanto la sicurezza dell’intera o<strong>per</strong>azione èstrettamente legata a quella dell’OP.Per comprendere al meglio il processo di autenticazione, può essere utileconsultare i sequence diagram in figura 2.8 e 2.9, rispettivamente <strong>per</strong> le modalitàcheckid-immediate e checkid-setup.Nella figura 2.8 è possibile vedere i vari “passi” in cui viene effettuata la proceduradi autenticazione con la modalità checkid-immediate (cioè supponendoche la fase di login con il service provider sia già stata effettuata). Le varie fasidella procedura di autenticazione si basano su messaggi HTTP, e come tali prevedonoun meccanismo richiesta/risposta (client/server): la parte client esegueuna 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 lapagina richiesta. L’end-user si connette <strong>per</strong>ciò alla homepage del RP.2. L’end-user che vuole autenticarsi sul RP accede all’area Sign In sullahomepage, e il RP gli presenta il form OpenID in cui inserire i dati.3. L’end-user immette l’identificatore OpenID (URL o XRI precedentementecreato sull’OP) oppure il nome dell’OP nell’apposito form presentato dalRP. Il RP reindirizza l’user-agent all’OP.4. (Opzionale) RP e OP si scambiano una chiave segreta che è usata dal OP<strong>per</strong> firmare i successivi messaggi verso il RP in modo tale che quest’ultimopotrà verificarne l’autenticità.5. Procedura di checkid-immediate. L’user-agent si collega all’OP, e vienericonosciuto da quest’ultimo (come già detto, si è assunto che la proceduradi login verso l’OP sia stata già effettuata). A questo punto viene creato uncookie [KM00], cioè un file che viene salvato sul disco rigido della macchinain uso <strong>per</strong> tenere traccia del login effettuato dall’end-user sull’OP. L’OPinvia all’user-agent la conferma <strong>per</strong> accedere al RP. È importante notareche se l’utente decidesse in questo momento di cancellare la lista <strong>dei</strong> cookiedal proprio PC, la procedura di autenticazione OpenID non potrebbe piùandare a buon fine, <strong>per</strong>ché l’end-user non risulterebbe più loggato sull’OPe quindi si renderebbe necessaria l’o<strong>per</strong>azione di checkid-setup.67


Stili di autenticazioneOpenIDL'end-user vuole autenticarsisu www.whishlistr.comme.yahoo.com/a/OIzLz9V.0cnD51hKEuSK.kFMofiyuNQoppure yahoo.comL'end-user è giàautenticatodal provider?NoModalitàcheckid_setupSiModalitàcheckid_immediateConfermaL'end-user èautenticato suwww.wishlistr.comFigura 2.6: Flowchart di autenticazione OpenID68


Stili di autenticazioneOpenIDendusernon autenticatosu RPenduser già autenticato su OP(inserimento URL o indirizzo OP)checkid_immediateenduser non ancoraautenticato su OP(inserimento URL o indirizzo OP)usernamee passwordcorretteConfermacheckid_setupenduserautenticatosu RPErrore nell'inserimento diusername e/o passwordFigura 2.7: State diagram della procedura di autenticazione OpenID6. L’end-user conferma di voler accedere al RP. L’OP comunica <strong>per</strong>ciò al RPche l’end-user è stato autenticato e <strong>per</strong>ciò può farlo accedere (questo chiaramenterisulta trasparente all’utente); il RP risponde con un messaggiodi conferma all’OP, e a questo punto l’OP reindirizza l’user-agent al sitoRP, che ora gli consentirà l’accesso.7. L’end-user è ora loggato sul RP, e può interagire con esso. Da questomomento 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 oche non ci fossero errori durante la procedura, <strong>per</strong> esempio cancellazioni dicookie. Se invece l’utente non è ancora loggato sull’OP o si verifica l’erroresopra descritto, allora si renderà necessaria la modalità di checkid-setup. Laprocedura di autenticazione con questa modalità è mostrata in figura 2.9.Dall’analisi effettuata si può notare che fino al passo 4 la procedura è praticamenteidentica a quella appena considerata, <strong>per</strong>tanto saranno descritte solamentele fasi successive a partire dalla 5.1. Procedura di checkid-setup. L’user-agent si collega all’OP, e quest’ultimogli presenta il form in cui l’end-user dovrà inserire username e passworddi accesso.2. L’end-user immette nell’apposito form le proprie credenziali, ed effettua<strong>per</strong>ciò il login sull’OP. Anche in questo caso viene creato il cookie<strong>per</strong> tenere traccia delle informazioni relative all’utente. L’OP presentaall’user-agent una richiesta di conferma <strong>per</strong> accedere al RP.3. L’end-user conferma di voler accedere al RP. L’OP comunica <strong>per</strong>ciò alRP che l’end-user è stato autenticato e <strong>per</strong>ciò può farlo accedere; il RPrisponde con un messaggio di conferma all’OP, e a questo punto l’OPreindirizza l’user-agent al sito RP, che ora gli consentirà l’accesso.69


Stili di autenticazioneOpenIDUser-agent(Mozilla Firefox)Relying Party(www.wishlistr.com)OpenID Provider(yahoo.com)1 – get2 – sign inhomepageform3 – richiesta di accesso4 – scambio di chiaveredirect5 – connessione a OPutente già autenticato:richiesta a procederecookie6 – continuautente autenticatoackredirectlogged-in7Figura 2.8: Sequence diagram <strong>per</strong> l’autenticazione checkid-immediate70


Stili di autenticazioneOpenIDUser-agent(Mozilla Firefox)Relying Party(www.wishlistr.com)OpenID Provider(yahoo.com)1 – get2 – sign inhomepageform3 – richiesta di accesso4 – scambio di chiaveredirect5 – connessione a OPform di logincookie6 – submitautenticazione utente7 – continuautente autenticatoacklogged-inredirect8Figura 2.9: Sequence diagram <strong>per</strong> l’autenticazione checkid-setup71


Stili di autenticazioneOpenID4. L’end-user è ora loggato sul RP, e può interagire con esso.È importante notare che la procedura di autenticazione appena mostratanei sequence diagram, è una sorta di “linea guida” alla quale si devono attenerele tre parti; vale a dire che da un punto di vista logico devono essere sempreseguiti i passi sopra descritti <strong>per</strong> <strong>per</strong>mettere l’autenticazione dell’end user sulRP, 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 chel’end-user è stato autenticato e <strong>per</strong>ciò può farlo accedere; <strong>per</strong>ò se a questo puntol’OP comunicasse direttamente con l’end-user fornendogli l’autorizzazione <strong>per</strong>l’accesso al RP, si potrebbe arrivare direttamente al passo 8, senza il bisogno<strong>dei</strong> messaggi “utente autenticato” e “ack” visibili in figura 2.9. Tecnicamentel’implementazione della procedura è fatta in modo diverso, ma da un punto divista prettamente logico non cambia nulla. I vari RP e OP sono <strong>per</strong>tanto libeririguardo all’implementazione del sistema di autenticazione OpenID, purché nonne vadano a cambiare la logica.2.3.2 Punti critici di OpenIDAnalizzando il funzionamento dell’autenticazione OpenID si possono rilevarealcune debolezze e vulnerabilità <strong>per</strong> quanto riguarda la sicurezza, quindipotrebbe essere soggetto a vari tipi di attacchi.• Attacco Eavesdropping: consiste nell’intercettazione fraudolenta di datiche transitano in una rete telematica. Esistono <strong>dei</strong> software che sono ingrado di intercettare la procedura di autenticazione a livello di trasportoed effettuare uno sniffing delle informazioni necessarie al login. Questeinformazioni possono essere utilizzate in seguito dall’attaccante <strong>per</strong> effettuareuna non lecita autenticazione. Questo tipo di attacco può essereprevenuto effettuando un trasporto criptato.• Attacco Man-in-the-Middle: è un attacco nel quale l’attaccante è ingrado di leggere o modificare messaggi tra due parti senza che nessunadelle due si renda conto del fatto che il collegamento è stato compromesso.Un attaccante può fingersi l’OP dell’utente e quindi entrare in possessodelle sue credenziali senza che quest’ultimo se ne accorga. Un metodo <strong>per</strong>prevenire questo tipo di attacco è usare la firma digitale e protocolli dicrittografia <strong>per</strong> creare un canale sicuro <strong>per</strong> i messaggi scambiati.• Attacco Denial of Service: In questo tipo di attacco si cerca di portareil funzionamento di un sistema informatico che fornisce un servizio al limitedelle prestazioni, fino a renderlo non più in grado di erogare il serviziostesso. Nel protocollo OpenID non c’è nessuna misura di sicurezza che<strong>per</strong>metta di capire se una richiesta di autenticazione è finalizzata a questotipo di attacco, quindi un attaccante che si finge un RP potrebbe inviaremolte richieste ad un OP, così da saturarne le risorse. Un metodo efficaceche <strong>per</strong>mette ad un OP di difendersi è usare tecniche di rate-limiting alivello trasporto.72


Stili di autenticazioneKerberos• Phishing: è un’attività illegale utilizzata da un’attaccante <strong>per</strong> ottenerel’accesso ad informazioni <strong>per</strong>sonali soprattutto tramite messaggi fasulli diposta elettronica (che imitano ed esempio loghi ufficiali) o contatti telefonici.L’utente viene così ingannato e portato a rivelare dati <strong>per</strong>sonali, codicidi identificazione, ecc. Gli OP dovrebbero <strong>per</strong>ciò educare i loro utenti inmodo da difendersi da questo tipo di attacchi; inoltre potrebbero fornireagli utenti un plug-in <strong>per</strong> aggiungere un <strong>per</strong>sonale sigillo di sicurezza cheappaia tutte le volte che si tenti di accedere al provider.Come detto precedentemente, OpenID è decentralizzato. Se da una partequesto 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 (nellascelta dell’OP).2.4 KerberosKerberos [Gar03] è un servizio di autenticazione sviluppato a partire dallametà degli anni ’80 al Massachusetts Institute of Technology (MIT) come partedi un progetto più ampio denominato Project Athena [Web06]. Il suo scopo eraquello di <strong>per</strong>mettere ad utenti e servizi di effettuare una mutua autenticazionedi tipo single sign-on in maniera rapida e sicura.2.4.1 Dalle origini ai giorni nostriNella mitologia greca Cerbero era il cane a tre teste messo a guardia degliInferi. Il suo compito era quello di assicurarsi che soltanto le anime <strong>dei</strong> defuntipotessero accedere al regno di Ade e Persefone. Si potrebbe dire che Cerberoautenticasse chi cercava di entrare (<strong>per</strong> stabilire se fosse vivo o meno) e, sullabase di ciò, accordasse l’ingresso a chi era autorizzato. Nello stesso modo Kerberos,battezzato col nome greco dell’essere mitilogico, autentica gli utenti chechiedono di accedere ai servizi forniti dalla rete che difende.Kerberos ha iniziato la sua strada come progetto di ricerca al MIT nei primianni ’80, in quei laboratori in cui fu <strong>per</strong>cepito da subito l’impatto che la grandediffusione <strong>dei</strong> <strong>per</strong>sonal computer avrebbe prodotto sull’industria informatica.Nasce in seno ad un proetto, il Project Athena, incentrato sull’integrazione dicalcolatori collegati in rete e che ha sviluppato pacchetti come il servizio di nomidistribuito Hesiod, il sistema di amministrazione distribuita Moira e, infine, l’XWindows System, tuttora alla base dell’interfaccia grafica <strong>dei</strong> sistemi UNIX.Fino a quel momento l’architettura di rete era conforme al modello timesharing<strong>per</strong> cui <strong>dei</strong> terminali molto limitati erano collegati, attraverso lineeseriali dedicate, ad un calcolatore sul quale erano concentrati servizi e qualsiasialtro strumento di amministrazione. Risultava molto semplice <strong>per</strong>cui gestire gliaccessi e manutenere il sistema, e non esisteva il problema della sicurezza nellecomunicazioni essendo ognuna di esse veicolata da linee seriali dedicate.È ovvio che l’avvento delle reti orientate al pacchetto avrebbe velocementereso antiquato un simile paradigma. Il nuovo modello, definito client-server,73


Stili di autenticazioneKerberosoltre ad apportare svariati benefici [TW97], che non è il caso riportare in questasede, introduceva problematiche inedite <strong>per</strong> quanto riguarda la gestione degliaccessi ai servizi di rete. La distribuzione <strong>dei</strong> servizi su più macchine portavaalla necessità di configurare in maniera opportuna ogni server, <strong>per</strong> metterli incondizione di riconoscere gli utenti, e si rendeva necessario raggiungere un certolivello di sicurezza <strong>per</strong> lo scambio <strong>dei</strong> dati, visto che le comunicazioni avvenivanosu canali condivisi.Proprio <strong>per</strong> risolvere questi due problemi il team del Project Athena sviluppòil protocollo di autenticazione Kerberos. Il loro obiettivo era estendere il meccanismodi autenticazione tipico delle reti a time-sharing ad una rete distribuitacostituita da server e client non fidati gestiti dagli utenti.Le prime tre versioni di Kerberos sono state sviluppate ed utilizzate solointernamente al MIT a scopo di ricerca e come campo di prova <strong>per</strong> <strong>nuove</strong> funzionalità<strong>per</strong> via delle significative limitazioni di cui soffrivano ma ogni revisioneha portato grandi miglioramenti in ambito di usabilità, estensibilità e sicurezza[KNT94]. Rilasciato al pubblico il 24 Gennaio 1989, Kerberos 4 è stata la primaversione ad uscire dai laboratori del MIT. Da allora è stato adottato da variproduttori e tutti i sistemi o<strong>per</strong>ativi ne hanno integrato il supporto.La più recente incarnazione, Kerberos 5, ha sostituito la versione 4 ed haintrodotto <strong>nuove</strong> caratteristiche e diversi miglioramenti in ambito di sicurezzacosì da essere stata proposta come standard.2.4.2 L’autenticazione in KerberosSi potrebbe definire semplicemente l’autenticazione come il processo di verificadell’identità di un particolare utente. Questi deve provare la propria identitàse vuole usufruire di un servizio presente in rete. Il più semplice <strong>dei</strong> tanti modiche esistono <strong>per</strong> mostrare la propria identità è farlo attraverso una password<strong>per</strong>sonale; il server la riconosce come prova dell’identità dell’utente e fornisce iservizi ai quali l’utente ha diritto di accedere.Questo approccio porta facilmente a diversi inconvenienti: ogni volta chesi accede ad un servizio la parola chiave deve essere digitata. Ciò può esserefastidioso specialmente se si ha a che fare con molti servizi e può portare allatentazione 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 unsistema.A parte questi problemi tipici delle password, questo approccio mostra unagrave limitazione quando applicato ad entità connesse in rete: la password deveessere 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 condivisofra client e server, può essere utilizzata in maniera indiretta: basta trovareun metodo <strong>per</strong> provarne la conoscenza senza il bisogno di inviarla attraverso larete. Ovviamente quel metodo esiste: Kerberos, così come altri protocolli simili,usa quel segreto, la password, come chiave crittografica. Nel caso più semplicel’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


Stili di autenticazioneKerberosSe non è possibile estrarre il messaggio significa che l’utente non aveva usato lachiave corretta e il servizio rifiuta la richiesta di autenticazione.Kerberos utilizza questa idea come base ma risolve molti <strong>dei</strong> problemi chepotrebbero derivare dall’uso sic et simpliciter di questo schema.È bene precisare che da questo momento in poi, quando non esplicitamentedichiarato, si farà riferimento esclusivamente a Kerberos 5.2.4.3 Terminologia e concettiKerberos è un sistema complesso e, in quanto tale, sono molti gli elementiche lo costituiscono ed i concetti su cui è costruito. In questo paragrafo vienedescritto tutto ciò che concorre al suo funzionamento in modo da semplificarnela trattazione nella sezione seguente.Reami, nomi principali e istanzeOgni installazione di Kerberos definisce un ambito amministrativo, distintoda ogni altra installazione. Questo ambito è chiamato reame.Ogni entità in una rete Kerberos sia essa un client, un utente, un servizio o lamacchina che lo ospita deve avere una identità all’interno del reame che, secondola nomenclatura del protocollo, viene definita principal o nome principale. Adogni identità è inoltre associata una chiave a lungo termine. Ciò <strong>per</strong> <strong>per</strong>mettereuna mutua autenticazione in ogni connessione. Ogni nome principale è unicoglobalmente e, <strong>per</strong> facilitarne la gestione, è costituito da più parti secondo unastruttura gerarchica molto simile a quella <strong>dei</strong> domini. Inizia con il nome utenteo il nome del servizio e termina con il nome del reame a cui appartiene. Il nomedel reame è introdotto dal simbolo “@”. Fra i due è presente un campo opzionaledetto istanza che può essere usato in due situazioni: <strong>per</strong> creare principal specialiad uso amministrativo o, come si vedrà più avanti, <strong>per</strong> il principal di un servizio.Questi due elementi, considerati insieme, devono essere unici all’interno di unreame.Nel caso di un host il campo username viene impostato ad “host”.Per distinguere i principal di servizi uguali, ma su macchine differenti, vieneriempito il campo istanza con l’hostname della macchina che lo ospita.È bene tenere presente che lo stesso sistema Kerberos, <strong>per</strong> <strong>per</strong>mettere losvolgimento della procedura di autenticazione, deve fornire <strong>dei</strong> servizi, ognunoprovvisto del proprio principal.La sintassi completa <strong>per</strong> i nomi principali è la seguente:component[/component][/component]...@REALMche all’atto pratico può risultare:username[/istance]...@REALMservice/fully-qualified-domain-name...@REALM75


Stili di autenticazioneKerberosLe chiaviTutte le chiavi segrete sono condivise da almeno due entità: l’utente o ilservizio e il Key Distribution Center che sarà descritto in seguito. Le chiavisegrete sono <strong>per</strong>ò, in generale, delle stringhe alfanumeriche che devono esseretrasformate <strong>per</strong> poter essere usate come chiavi crittografiche. Si utilizza quindila funzione string2key che applica alla chiave segreta delle trasformazioni al finedi ottenere una serie di cifre. Trattandosi, nell’insieme, di una trasformazionenon invertibile è matematicamente impossibile risalire alla password che hagenerato la chiave crittografica. La parte più importante di questa trasformazioneè l’aggiunta del “key salt”. Con questo termine si intende una sequenzadi caratteri che viene concatenata alla parola chiave prima di applicare la funzionehash <strong>per</strong> rendere più particolare la stessa. In Kerberos 5 il key salt didefault è rappresentato dal nome del reame. In questo modo se un utente utilizzala stessa password in due reami diversi, avrà comunque generato due chiavicrittografiche 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 deveesistere un modo <strong>per</strong> determinare quale di queste deve essere considerata <strong>per</strong>accordare l’accesso ai servizi. È stato quindi definito il Key Version Number(kvno). Quando un utente cambia la propria password il kvno viene incrementatodi una unità. La stessa cosa accade, ovviamente, se è un servizio a farlo;in questo caso il kvno acquista maggiore importanza in quanto, <strong>per</strong>ché i serviziriescano a interpretare i messaggi degli utenti, sia la chiave crittografica sia ilkvno devono corrispondere ai valori memorizzati nel database di Kerberos.Key Distribution CenterIl Key Distribution Center (KDC) consiste di tre parti logicamente distinte:un database <strong>dei</strong> principal e delle relative chiavi, l’Authentication Server (AS) eil Ticket Granting Server. Questi tre elementi, pur essendo logicamente distintisono di solito implementati nello stesso programma.Ogni reame deve avere almeno un KDC e, vista la notevole importanzache ricoprono le informazioni che conserva, è buona norma che esista nella reteuna macchina esclusivamente adibita ad ospitarlo. Il KDC contiene, infatti, alsuo interno un database <strong>dei</strong> principal e <strong>dei</strong> segreti delle entità del reame e, aseconda della implementazione esaminata, anche altre informazioni relative agliutenti. Queste possono venir memorizzate su un database locale nel filesystemdel KDC stesso, come l’implementazione del MIT ha scelto, o anche con servizidi directory 3 .Kerberos <strong>per</strong>mette di impostare <strong>dei</strong> KDC di tipo slave che replicano in tuttoe <strong>per</strong> tutto il funzionamento del servizio master. Ciò che li differenzia sono le3 I Servizi di Directory sono <strong>dei</strong> repository o database di informazioni. Una directory,al contrario <strong>dei</strong> normali database, è pesantemente ottimizzato <strong>per</strong> o<strong>per</strong>azioni di lettura inquanto si considera che solo raramente i dati contenuti debbano essere aggiornati. In generesupportano funzioni di lettura, ricerca e consultazione. Un esempio importante di serviziodi directory è senza dubbio rappresentato dal Domain Name System (DNS) che può esseredefinito più precisamente come servizio di directory distribuito con struttura gerarchica. Altriesempi sono LDAP [How98] e Active Directory [Mic06].76


Stili di autenticazioneKerberoso<strong>per</strong>azioni che possono essere effettuate sui database degli accessi: è possibileaccedere ai database <strong>dei</strong> server slave esclusivamente in sola lettura. Tutte leo<strong>per</strong>azioni di modifica devono necessariamente essere svolte sul database mastere, solo in un secondo momento, sarà possibile effettuarne la propagazioneai database slave. In questo modo qualora il KDC master fosse inaccessibilesarebbe sempre possibile ottenere nuovi ticket attraverso i KDC slave. Il protocollonon definisce il meccanismo di propagazione delle modifiche quindi ogniimplementatore ha sviluppato soluzioni proprie.L’Autentication Server rilascia un Ticket Granting Ticket (TGT) crittografatoai client che vogliono autenticarsi verso il reame Kerberos. Non è necessarioche il client dimostri la sua identità all’AS in quanto il TGT, essendo crittografatocon la chiave segreta dell’utente, risulterebbe inutilizzabile da chiunquealtro. Una volta decrittato, il TGT rappresenta l’elemento fondamentale <strong>per</strong><strong>per</strong>mettere un’autenticazione di tipo single sign-on: non sarà infatti più necessarioinserire la propria password a lungo termine fino alla scadenza del TGTin uso.Il Ticket Granting Server (TGS), invece, è un servizio che rilascia ai client<strong>dei</strong> ticket specifici <strong>per</strong> un servizio della rete, i service-ticket. Il client, quandoeffettua la richiesta di un servizio, deve fornire due oggetti al TGS: il principaldel servizio che vuole contattare e il TGT che gli è stato fornito dall’AS almomento dell’autenticazione. Il TGS, una volta verificata la validità del TGT,<strong>per</strong> fare ciò è sufficiente che controlli che sia stata crittata con la chiave dell’AS,risponde con il service-ticket richiesto.I TicketCome appena visto, Kerberos introduce il concetto di ticket. Concettualmentesi tratta di un dato strutturato crittografato che contiene al suo internouna chiave crittografica diversa <strong>per</strong> ogni sessione, la chiave di sessione e altricampi tra cui alcuni flag <strong>per</strong> definire la modalità di funzionamento del ticketstesso. I ticket hanno due finalità: confermare l’identità degli end-point dellacomunicazione 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 causatoda 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 <strong>per</strong> renderne possibilela comunicazione (la chiave di sessione).Alcuni campi, come la finestra temporale o la chiave di sessione, sono riempitidal KDC <strong>per</strong> ovvi motivi di sicurezza; altri vengono impostati dal client <strong>per</strong>77


Stili di autenticazioneKerberosesempio in relazione al servizio contattato o alle modalità con cui vuole ottenerel’accesso.Ogni ticket che il KDC genera deve essere crittografato <strong>per</strong> impedire che unattaccante possa modificarlo, <strong>per</strong> esempio, <strong>per</strong> allargare la finestra di validità diun ticket rubato.Le credenziali ottenute devono ovviamente essere mantenute in una cache,chiamata indifferentemente ticket cache che credentials cache, che può essereimplementata in più modi. Nella versione sviluppata dal MIT è stato scelto,<strong>per</strong> facilitare la portabilità, di salvare il contenuto <strong>dei</strong> ticket in un file sul discofisso. Questo metodo è <strong>per</strong>ò poco flessibile e porta a problemi di sicurezza. Unasoluzione migliore è quella di salvare le credenziali in memoria <strong>per</strong> garantire laloro distruzione al termine della sessione Kerberos.Kerberos 5 introduce funzioni avanzate che <strong>per</strong>mettono agli utenti un maggiorcontrollo sui propri ticket attraverso i seguenti flag:• Forwardable ticket. Un utente può richiedere un forwardable ticket. Questopuò essere inoltrato ad un altro host e risultare comunque valido. Uncaso speciale è rappresentato dal TGT inoltrabile: un utente può trasferireil suo TGT valido ad un altro host e utilizzarlo anche dalla nuovalocazione, senza il bisogno di inserire nuovamente i dati di login, sia <strong>per</strong>ottenere <strong>dei</strong> service-ticket che un nuovo TGT.• Proxiable ticket. Questo tipo di ticket è simile nel funzionamento a quellodi classe forwardable ma risulta meno potente: questo, infatti, può essereusato, una volta trasferito su un altro host, solo <strong>per</strong> richiedere nuoviservice-ticket ma mai <strong>per</strong> ottenere un nuovo TGT.• Renewable ticket. Quando un utente richiede un ticket con il flag renewableattivato, fa la richiesta <strong>per</strong> un ticket di cui sarà possibile estendere lafinestra di validità. Per fare ciò è sufficiente rimetterlo al TGS primadella sua scadenza. Il TGS può rifiutarsi di convalidare il ticket qualora,<strong>per</strong> esempio, sia stato segnalato come compromesso; altrimenti ne inviaun’altro all’utente. Questo procedimento può essere ripetuto fino alla finedella validità <strong>dei</strong> ticket rinnovabili.• Postdated ticket. I ticket di questo tipo sono validi solo a partire dalla datariportata al loro interno. Se uno di questi viene proposto <strong>per</strong> la validazioneprima del tempo previsto viene rifiutato. Sono generalmente utilizzati<strong>per</strong> lavori in sequenza o temporizzati che necessitano di autenticazioneKerberos, ma non tutte le implementazioni del protocollo li prevedono.2.4.4 Il funzionamento di KerberosFin ora sono stati presentati tutti i concetti che <strong>per</strong>mettono di descrivere ilfunzionamento di Kerberos. Varrà ora descritto nel dettaglio il funzionamentodel protocollo di autenticazione.78


Stili di autenticazioneKerberosL’autenticazione Intra-RealmL’idea alla base di Kerberos è quella di creare un’infrastruttura il cui unicoscopo sia l’autenticazione. In questo modo i servizi non devono preoccuparsidi mantenere informazioni riguardo gli utenti e i <strong>per</strong>messi ad essi associati; sial’utente che i servizi, <strong>per</strong>ò, devono necessariamente fidarsi dell’AuthenticationServer che ha il compito di “presentare” gli agenti l’un l’altro; <strong>per</strong> fare ciò sial’utente che i servizi devono condividere una chiave segreta con l’AS; queste sonochiamate chiavi a lungo termine dato che hanno una validità che può arrivare asettimane o addirittura mesi.Si consideri ora la situazione in cui un client C voglia accedere ad un servizioremoto S; il processo di autenticazione può essere suddiviso in tre fasi distinte[CJ05].• Authentication Service Exchange (C ⇐⇒ AS). Questo scambiodi messaggi avviene quando l’utente accede <strong>per</strong> la prima volta alla reteKerberos.Il processo client C genera un nonce 4 n 1 e lo invia all’AS insieme al proprionome e al nome del TGS. Una volta riconosciuto il client e quindi, anche seindirettamente, l’utente, l’AS risponde con un messaggio crittografato indue parti: il TGT, che viene memorizzato da C <strong>per</strong> essere usato durantetutta la sessione Kerberos <strong>per</strong> ottenere i service-ticket, e una seconda partecon cui l’AS passa a C alcuni parametri riguardanti il ticket.Il TGT, crittografato con la chiave a lungo termine del TGS, contiene alsuo interno una chiave di autenticazione AK e un timestamp t k oltre alnome di C e ad altri dati in questo momento meno importatanti.La seconda parte, crittografata stavolta con la chiave a lungo terminedel client, contiene la stessa chiave di autenticazione AK che, da questomomento, verrà usata in tutte le seguenti comunicazioni con il TGS inmodo da non esporre la ben più preziosa chiave a lungo termine.Il timestamp presente in entrambe le parti del messaggio assicura che ilticket sia stato generato recentemente dato che tutte le macchine della retesono sincronizzate su un time server comune. Il nonce n 1 serve a legare larisposta dell’AS con la richiesta del client.• Ticket Granting Exchange (C ⇐⇒ TGS). Questo scambio di messaggiavviene quando un utente accede <strong>per</strong> la prima volta ad un servizio.C trasmette al TGS un messaggio in due parti: la prima parte contiene ilTGT precedentemente memorizzato, il nome del servizio cui l’utente vuoleaccedere e un nonce n 2 ; la seconda parte, detta authenticator, contiene ilnome del client e un timestamp t c ed è crittografato con la chiave AK.L’authenticator serve <strong>per</strong> provare al TGS che il client conosce la chiave diautenticazione AK.4 In questo contesto il termine nonce sta <strong>per</strong> “number used once”. Si tratta, di solito, di unnumero casuale o pseudo-casuale utilizzato nei protocolli di autenticazione <strong>per</strong> assicurare chevecchi messaggi non siano riutilizzati da un utente malintenzionato.79


Stili di autenticazioneKerberosUna volta autenticato C e verificato il suo livello di accesso, il TGS rispondecon un nuovo messaggio, sempre suddiviso in due parti: entrambecontengono il nome del client, un timestamp t T GS e una nuova chiave,creata <strong>per</strong> l’imminente comunicazione tra client e server, chiamata chiavedi sessione. Ciò che differenzia le due parti è la chiave crittografica usata<strong>per</strong> “sigillare” il messaggio: la prima parte viene crittata con la chiave alungo termine del servizio e prende il nome di service-ticket; la secondacon la chiave di autenticazione AK.Il client memorizza il service-ticket.• Client-Server Exchange (C ⇐⇒ S). Questo scambio di messaggiavviene quando il client inizia una nuova sessione con il server.A questo punto C possiede il service-ticket e può contattare S inviandotale ticket al suo interlocutore, insieme ad un authenticator costruito comequello precedentemente descritto. Entrambi sono i soli in grado di estrarredai messaggi la chiave di sessione necessaria <strong>per</strong> comunicare in sicurezzae hanno una conferma dell’identità dell’interlocutore.Il server può, in base alle preferenze dell’amministratore del sistema, rispondereo meno al client <strong>per</strong> esempio inviando il timestamp t ′ C che Caveva inviato nella sua richiesta, crittografandolo con la chiave di sessione.Figura 2.10: Kerberos - Autenticazione intra-realm80


Stili di autenticazioneKerberosOra può aver inizio la comunicazione con il servizio <strong>per</strong> il quale è statocontattato 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 messaggiogenerato. Per ragioni di sicurezza che verranno analizzate in seguito è statointrodotto con Kerberos 5 un meccanismo chiamato pre-autenticazione: l’utentedeve in qualche modo provare la propria identità <strong>per</strong>ché il KDC generi il ticket<strong>per</strong> quel particolare principal. Esistono vari tipi di pre-autenticazione ma soloil metodo denominato encrypted timestamp è implementato comunemente.La pre-autenticazione è controllata dal KDC. Se un utente cerca di ottenereun TGT, come descritto precedentemente nella fase denominata“AuthenticationService Exchange”, e il KDC è impostato <strong>per</strong> richiedere la pre-autenticazione,quest’ultimo risponderà con un messaggio di errore. Questo messaggio comunicaal client che è necessario pre-autenticarsi <strong>per</strong> ottenere un ticket. Quindi larichiesta verrà ripetuta ma aggiungendo al messaggio i dati di pre-autenticazionerichiesti. Nel caso menzionato (encrypted timestamp), questi consistono di untimestamp firmato con la chiave privata dell’utente. Se il KDC è in gradodi decifrarlo, utilizzando la chiave pubblica dell’utente a lui nota, risponde alclient inviandogli il TGT altrimenti invierà un nuovo messaggio di errore <strong>per</strong>comunicare all’interlocutore il fallimento della pre-autenticazione.L’autenticazione Cross-RealmFino qui è stato esaminato uno scenario in cui sia presente un solo AS ed unsolo TGS, che possono o meno risiedere sulla stessa macchina. Finchè il numerodelle richieste si mantiene basso non c’è nessun problema ma col crescere dellarete, e quindi anche del numero delle richieste, il AS e il TGS diventano il collodi bottiglia nel processo di autenticazione. In breve il sistema, così come èstato descritto fin ora, non è scalabile. Per questa ragione può essere sensatosuddividere la rete in aree. D’altra parte una struttura simile può essere ilrisultato di una integrazione di reti già esistenti e separate su base organizzativa.Nella terminologia di Kerberos queste aree prendono il nome di reame. Ognireame consiste di client, servizi e di un KDC proprio.Per <strong>per</strong>mettere un’autenticazione cross-realm, cioè <strong>per</strong> <strong>per</strong>mettere che utentiin un certo reame possano usufruire di servizi presenti in altri reami, è necessarioregistrare il KDC afferente al reame del servizio come un server specialenel reame dell’utente ed usare una variante del protocollo intra-realm. In questomodo viene aggiunto un ulteriore livello di indirezione alla procedura diautenticazione.Il caso più semplice che è possibile prendere in esame coinvolge un client Cnel reame R 1 e un server S nel reame R n . Il KDC di R n deve essere registratocome un server speciale in R 1 . Il client ottiene un TGT in R 1 , come vistoprecedentemente, e un service-ticket <strong>per</strong> il KDC di R n che viene visto come unservizio locale in R 1 . Il service-ticket ha lo stesso formato di un TGT <strong>per</strong> i clientdi R n e come tale viene gestito dal KDC di R n <strong>per</strong> fornire a C un service-ticket<strong>per</strong> il servizio S. In pratica il KDC di R 1 agisce come client nei confronti delKDC del reame remoto. Questo è il massimo che può essere ottenuto con laversione 4 di Kerberos. Con la versione 5 è stata aggiunta la possibilità di orga-81


Stili di autenticazioneKerberosFigura 2.11: Kerberos - Autenticazione cross-realmnizzare i reami in una vera e propria struttura gerarchica. Sarà possibile quindiche un client C nel reame R 1 voglia accedere ad un servizio S nel reame R n mache stavolta non sia direttamente disponibile in R 1 il server “di collegamento”<strong>per</strong> R n descritto poco sopra. Sarà necessario quindi attraversare in successione<strong>dei</strong> reami intermedi R 2 ,...,R n−1 a patto <strong>per</strong>ò che sia stata precedentementedefinita una affiliazione tra R 2 ed R 3 , tra R 3 ed R 4 e così via fino ad R n .La lista <strong>dei</strong> KDC attraversati è chiamata authentication path di C <strong>per</strong> S. Ireami attraversati vengono definiti transited realms e i loro nomi sono registratinel ticket in modo da informare il servizio <strong>dei</strong> passi effettuati nella catena diautenticazione. Ciò da la possibilità al servizio di esaudire o meno le richieste inbase ad una <strong>per</strong>sonale valutazione del grado di affidabilità <strong>dei</strong> nodi attraversati.Resta da chiarire in che modo vengano determinati gli authentication pathverso i servizi remoti. Esistono due modalità: una basata sulla gerarchia <strong>dei</strong>reami e una sulla sezione capaths del file di configurazione di Kerberos.La prima modalità è abbastanza semplice da realizzare: una volta organizzatii reami secondo una struttura gerarchica, del tutto simile a quella <strong>dei</strong> dominiDNS, i client sanno implicitamente quali nodi di rete attraversare <strong>per</strong> raggiungereun determinato servizio. In questo modo <strong>per</strong>ò non si ha nessuno strumento82


Stili di autenticazioneKerberos<strong>per</strong> verificare il grado di fiducia degli host attraversati.La seconda modalità si basa sulla configurazione della sezione capaths delfile krb5.conf presente su ogni macchina della rete Kerberos. Qui vengono definiti,<strong>per</strong> ogni servizio remoto, gli authentication path validi. Questi verrannoutilizzati dai client <strong>per</strong> determinare il corretto <strong>per</strong>corso fino ad un certo servizioremoto e dagli application server <strong>per</strong> determinare se un dato authentication pathè da considerarsi valido o meno. Dato che ogni application server verifica gliauthentication path usando questa sezione del file di configurazione la sempliceaggiunta di un nuovo <strong>per</strong>corso verso un reame non sottintende nessuna informazionedi fiducia nei confronti degli altri. Di contro il file krb5.conf deve essereaggiornato manualmente su ogni host coinvolto.2.4.5 Analisi di sicurezzaNon è difficile capire che trattare la sicurezza di un sistema complesso comeKerberos non può ridursi al semplice fatto di “proteggere il KDC”; di seguitosaranno riportati i potenziali scenari di compromissione e i loro effetti sullasicurezza del sistema nel suo insieme [BM90, CJ05, Gar03].• Compromissione dell’account di root del KDC. La compromissionedell’account di root di un KDC, sia esso master o slave, dà all’attaccantepieno controllo su tutto il meccanismo di autenticazione. Nonostante ildatabase sia crittografato, la chiave master di Kerberos potrebbe trovarsisul disco <strong>per</strong> <strong>per</strong>mettere un eventuale avvio automatico del KDC. In unasituazione del genere tutto il database è da considerarsi compromesso.• Compromissione delle credenziali di amministratore. Se un attaccanteottiene la password di un principal amministrativo, ottiene l’accessocompleto al database di Kerberos. Alcune implementazioni infatti <strong>per</strong>mettonodi effettuare il dump da remoto del database ottenendo così unacopia dello stesso. Senza contare che avendo accesso completo al database,un attaccante può creare o modificare qualsiasi nome principale apiacimento.• Compromissione dell’account di root di un server. Se un attaccanteottiene i privilegi di root su un server ha anche accesso ai principal <strong>dei</strong>servizi residenti sulla macchina e può im<strong>per</strong>sonare i servizi <strong>per</strong> decrittarele comunicazioni con i client.• Compromissione dell’account di root di un client. La compromissionedell’accont di root di un client fornirà all’attaccante l’accessoalla credentials cache; dato che i ticket sono validi in una piccola finestratemporale, la loro compromissione non è così grave come quella dellapassword utente. È <strong>per</strong>ò possibile <strong>per</strong> l’attaccante installare sulla macchinaun keylogger, <strong>per</strong>cui, in uno scenario del genere, sono da considerarsicompromesse le password di tutti gli utenti che hanno utilizzato lamacchina.83


Stili di autenticazioneKerberos• Compromissione delle credenziali di un utente. Se l’attaccanteriesce ad acquisire la password utente potrà accedere ai servizi fino ad unanuova modifica della stessa.Risulta chiaro che installare Kerberos in una rete non diminuisce l’importanzadi mantenere tutte le macchine, fino ai terminale degli utenti, sicure daattacchi esterni.Va sottolineato anche un altro aspetto: Kerberos è stato sviluppato tenendobene in mente l’ambiente in cui doveva agire e, una volta estrapolato, mostraovviamente delle limitazioni. L’ambiente del Project Athena consiste in ungrande numero di workstation più o meno anonime e un piccolo numero diserver. I server forniscono servizi di file storage, print spooling, e-mail, e inalcuni 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 sicurezzaa livello fisico: qualcuno potrebbe rimuovere, leggere o alterare porzioni di discosenza difficoltà.All’interno di questo ambiente la prima necessità è di una autenticazione ditipo utente-server. Quando un utente siede ad una workstation ha bisogno diaccedere a file privati residenti su un server in quanto non presenti altrove; laworkstation, ovvero il client, in sé non ha quindi necessità di autenticarsi versoil server.Questo tipo di funzionamento è in marcato contrasto con quanto avvienenormalmente <strong>per</strong> un sistema composto da macchine UNIX. In questo caso leworkstation hanno una identità e <strong>dei</strong> propri file oltre che un certo numero didemoni di rete in esecuzione; quando una macchina simile ha intenzione di, <strong>per</strong>esempio, salvare <strong>dei</strong> file su un server deve quantomeno dichiarare e possibilmenteprovare la propria identità. Nel caso del Project Athena le workstation non sonocapaci e non hanno bisogno di farlo; sono più <strong>dei</strong> terminali avanzati che sistemicompleti. In questo scenario Kerberos serve quindi ad autenticare l’utente finaleverso un certo numero di servizi; non è stato sviluppato <strong>per</strong> essere usato da undemone di rete che contatta un server.Esistono dunque alcune limitazioni del protocollo Kerberos se usato in uncontesto convenzionale come descritto qui di seguito:• Per prima cosa una normale workstation non ha un’area sicura in cuisalvare le chiavi. In Kerberos, nel primo passo dell’autenticazione, <strong>per</strong>ottenere un TGT viene utilizzata una chiave in chiaro ma salvarle in uncomputer è solitamente una cattiva idea; se una chiave Kerberos che unamacchina usa <strong>per</strong> identificare se stessa viene compromessa sarà possibileim<strong>per</strong>sonare ogni utente di quella macchina. In più la chiave di sessioneottenuta in risposta non può essere salvata in maniera sicura; viene solitamentearchiviata in modo da potervi accedere solo con privilegi di rootma l’attaccante può comunque violare o almeno aggirare temporaneamenteil meccanismo di protezione sul computer locale <strong>per</strong> ottenere, se non lachiave Kerberos, almeno le chiavi di sessione.• Un altro problema sorge nel caso in cui le workstation siano gestite conottica multiutente: se ci sono problemi di sicurezza nell’host un attaccante84


Stili di autenticazioneKerberospuò 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 lacache in /tmp ma questo è <strong>per</strong>icoloso qualora le workstation siano senzaunità disco: la cache sarebbe in questo caso salvata su un server. Unapossibile soluzione potrebbe essere memorizzare la cache in memoria; nonc’è <strong>per</strong>ò nessuna garanzia che la memoria non sia prima o poi paginata suldisco.Vengono a questo punto descritti uno ad uno gli attacchi che è possibileportare al protocollo di autenticazione in se.Attacchi a dizionario e a forza brutaDurante il primo passo dell’autenticazione il KDC rilascia un TGT crittografatoad ogni client che lo richieda. Questo TGT è crittografato con la chiavea lungo termine dell’utente. La sicurezza dell’intero sistema dipende dal nonpoter essere in grado di decifrare questo messaggio, dato che, se un attaccanteè capace di estrarne la chiave può im<strong>per</strong>sonare l’utente a piacere.Nonostante non ci siano modi <strong>per</strong> farlo direttamente, un attaccante puòtentare di forzare il TGT tramite un attacco a dizionario offline. Durante unattacco a dizionario, un attaccante fornisce una lista di password comunementeusate, o dizionario, ad un programma di cracking. Per ogni voce nel dizionario,il software cerca di decrittare il messaggio. Quando trova una password valida ilprogramma la riporta all’attaccante. Dato che la trasformazione che porta dallapassword utente alla chiave crittografica è nota, è banale <strong>per</strong> un attaccante costruireun programma che applichi al dizionario di password la trasformazionecitata. Quindi l’attaccante può collezionare un grande numero di TGT validi eportare l’attacco offline. Il programma di cracking può accorgersi di aver trovatola password corretta grazie alla presenza all’interno del TGT della stringa“tgt”, parte del principal del TGS, “krbtgt”, che viene usata come segnale <strong>per</strong>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. Unattacco a dizionario rappresenta il limite inferiore nella sicurezza di ogni sistemadi autenticazione basato su password. Non importa che tipo di sofisticato meccanismocrittografico venga utilizzato, se la password è semplice o prevedibilesoccomberà velocemente ad un attacco a dizionario.Un altro attacco, l’attacco a forza bruta, rappresenta il limite su<strong>per</strong>iore nellasicurezza di Kerberos. Invece di tentare di decrittare i messaggi iterando suun insieme di parole predefinito, un attacco a forza bruta, prova una ad unatutte le chiavi possibili fino all’ottenimento della password. I crittosistemi sonocostruiti con uno spazio delle chiavi quanto più grande possibile proprio <strong>per</strong>rendere gli attacchi a forza bruta non praticabili. Da notare il fatto che spazidi chiavi un tempo considerati sufficientemente vasti, a seguito dell’avanzamentotecnologico effettuato, risultano ora alla portata di attaccanti anche solo85


Stili di autenticazioneKerberosmoderatamente motivati. Mentre Kerberos 4 poteva avvalersi solo dell’algoritmocrittografico DES, Kerberos 5 <strong>per</strong>mette l’aggiunta di tecniche crittografichesempre più robuste e, <strong>per</strong> limitare il problema di un attacco offline, introduce lapre-autenticazione. Quest’ultimo espediente, tra l’altro neanche obbligatorio inalcune implementazioni di Kerberos, non rappresenta <strong>per</strong>ò una soluzione datoche l’attaccante può comunque utilizzare uno “sniffer” <strong>per</strong> intercettare il trafficodi rete.Replay AttackDato che tutti i protocolli sono basati sullo scambio di messaggi elettronicitra i computer della rete, un attaccante può sempre restare in ascolto memorizzandoalcuni messaggi e riutilizzarli in un secondo tempo. L’attaccante non habisogno di indovinare la password dell’utente o decrittare il messaggio ma, <strong>per</strong>poter sfruttare la situazione, deve essere in grado di costruire falsi messaggi; inogni caso è sempre possibile tentare di estrarre la password con un attacco aforza bruta sul messaggio catturato.Kerberos ha, al suo interno, alcuni meccanismi atti ad evitare proprio attacchidi questo tipo:• I ticket sono provvisti di un campo indirizzo. Quando un client richiedeun ticket al KDC, può esplicitare gli indirizzi di rete dai quali il ticketdeve risultare valido. Ciò risolve il problema di un attaccante che cerca diusare un ticket su una macchina non presente nel campo indirizzo. In ognimodo ciò non impedisce completamente attacchi di questo tipo; in primoluogo <strong>per</strong>ché il campo indirizzo non è obbligatorio, in secondo luogo <strong>per</strong>chél’attaccante può trovarsi su una macchina “compatibile” con il ticket.• Gli authenticator hanno una validità limitata nel tempo. Come abbiamovisto nel paragrafo riguardante il funzionamento del protocollo, molti <strong>dei</strong>messaggi crittografati scambiati tra i nodi della rete contengono al lorointerno un timestamp; il destinatario può infatti scartare il messaggioqualora l’orario ivi contenuto differisca da quello di sistema <strong>per</strong> più di5 minuti. L’intervallo di 5 minuti appena menzionato serve a garantireuna certa tolleranza riguardo la sincronizzazione degli orologi sulla retee rappresenta l’impostazione di default in tutte le implementazioni. Siosservi <strong>per</strong>ò che anche 5 minuti possono essere sufficienti ad un attaccante,magari provvisto di un software automatico, <strong>per</strong> catturare e rispedire unmessaggio.• Replay caches. L’ultimo meccanismo di difesa che Kerberos utilizza <strong>per</strong>contrastare i replay attack è la replay cache. Ogni servizio tiene tracciadegli authenticator ricevuti <strong>per</strong> tutta la loro validità in modo da impedirneil riutilizzo.Time Services non sicuriCome abbiamo visto gli authenticator sono costruiti sulla corretta sincronizzazionedegli orologi delle macchine. Se, <strong>per</strong> esempio, un host viene ingannatoriguardo l’ora corretta, un authenticator scaduto può essere riutilizzato86


Stili di autenticazioneKerberosfacilmente. Allo stato attuale questo tipo di attacco può essere realizzato confacilità dato che molto spesso non vengono utilizzate le migliori implementazionidisponibili e la stragrande maggioranza di esse non supporta alcun tipodi autenticazione. Di contro si può sostenere che costruire un qualsiasi sistemadi autenticazione, come Kerberos, assumendo un già autenticato servizio sottostantesia di <strong>per</strong> sé assurdo: si tratterebbe di duplicare la stessa funzione oppurenon sarebbe molto sensato costruire qualcosa di cui già si dispone; al contrariouna buona soluzione potrebbe essere rendere quest’ultimo esplicitamente partedel protocollo di autenticazione.Si potrebbe dire che Kerberos coinvolge, in un rapporto di mutua fiducia,quattro parti: client, server, KDC e time server.Spoofing LoginIn un ambiente tradizionale è abbastanza semplice sostituire il comando dilogin con uno che registra la password utente prima di usarla <strong>per</strong> l’autenticazioneKerberos. Questo tipo di attacco annullerebbe il beneficio portato dalnon comunicare le password in chiaro. Questo problema non è relativo solo aKerberos ma il sistema in oggetto rende molto difficile la contromisura tipica<strong>per</strong> queste situazioni: le one-time password, cioè l’utilizzo di password validesolo una volta.Un tipico schema di funzionamento <strong>per</strong> le one-time password impiega unachiave segreta, condivisa da utente e server, e un qualche dispositivo in dotazioneall’utente. Il server sceglie un numero casuale e lo trasmette all’utente.Quest’ultimo, aiutato dal dispositivo, cifra il numero con la chiave segreta einvia il risultato al server. Questo, se ottiene lo stesso risultato applicando latrasformazione, considera il client autenticato.Kerberos <strong>per</strong>ò non prevede un simile schema challenge/response al momentodel login: la risposta alla richiesta di login è sempre crittata con la chiave a lungotermine 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 alungo termine K c <strong>per</strong> crittarlo ottenendo {R} Kc . Questo valore, invece di K c ,sarà usato <strong>per</strong> crittare la risposta del server.Infine, è sempre possibile fornire una <strong>per</strong>iferica di boot sicura o effettuare unboot via rete anche se, <strong>per</strong> questo secondo caso, non sono stati ancora sviluppatiprotocolli sicuri.Il TGS e la chiave di sessioneDurante l’autenticazione cross-realm tutti i TGS lungo l’authentication pathpossono conoscere la chiave di sessione utilizzata dal client <strong>per</strong> dialogare con ilserver. Infatti, ogni TGS, crea e quindi conosce la chiave di autenticazione cheverrà usata dal client <strong>per</strong> contattare il TGS seguente lungo la catena di autenticazione.Memorizzando ad ogni passo la chiave di autenticazione è possibileseguire tutta la catena fino ad ottenere la chiave di sessione.Ciò avviene anche in un contesto single-realm ma, in questo caso, l’authenticationpath consiste di un solo TGS.87


Stili di autenticazioneKerberosI TGS e i ClientQuesto attacco è realizzabile in un contesto multi-realm. Ogni TGS malintenzionatopuò im<strong>per</strong>sonare un client C al di fuori del reame cui C stessoafferisce, anche nel caso in cui quest’ultimo non abbia mai contattato il TGS.Per portare l’attacco il TGS crea un ticket <strong>per</strong> un reame remoto in modo da farapparire C come il mittente della richiesta.Non è necessario che C sia coinvolto direttamente e nemmeno che avesseprecedentemente contattato il server: la sua stessa esistenza non è importanteai fini dell’attacco.Il TGS compromesso non può fingere di essere C nello stesso dominio delclient dato che, <strong>per</strong> le autenticazioni intra-realm, non viene, ovviamente, utilizzatoil protocollo cross-realm.Attacchi al meccanismo di routing fra reamiPer come Kerberos funziona in un contesto multi-realm, un client è capacedi conoscere l’authentication path tenendo traccia <strong>dei</strong> Ticket Granting Serverche incontra. Nonostante questo, <strong>per</strong>ò, un TGS malintenzionato può ingannareil client facendogli credere che un determinato TGS non sia sull’authenticationpath, manipolando così il resto dell’authentication path senza che C se neaccorga.Altri AttacchiDato che Kerberos è, in fin <strong>dei</strong> conti, solo un servizio di autenticazione ci sonodiverse minacce inerenti la sicurezza da cui non può proteggere la rete. Questiattacchi non sono specifici contro Kerberos ma sono comuni ad ogni servizio diautenticazione.• Denial of Service. Un attacco Denial of Service può essere portato controil KDC inondandolo di richieste di autenticazione. Il grande numero dirichieste rallenta di fatto le risposte agli utenti legittimi o, in casi estremi,mandare in crash la macchina ospitante il KDC. Si può consigliare diproteggere con <strong>dei</strong> firewall la rete Kerberos o di installare <strong>dei</strong> KDC slave<strong>per</strong> limitare il problema.• La “talpa”. Kerberos non può proteggere da utenti autorizzati che decidonodi manomettere il sistema, come, ad esempio, un amministratore chedecide di cancellare il database dell’ AS .• Social Engineering e Password Exposure. Così come non può difendere ilsistema da utenti che divulgano le password di accesso deliberatamenteo come conseguenza di un attacco di Social Engeneering nè tantomenodall’uso delle stesse password di Kerberos con sistemi meno sicuri. Inquesto modo un attaccante può, con minor sforzo, attaccare un serviziomeno sicuro <strong>per</strong> ottenere una coppia username/password valida anche <strong>per</strong>Kerberos.88


Stili di autenticazioneKerberos• Problemi del software Kerberos. È bene tenere presente, inoltre, che unsistema complesso come Kerberos può soffrire di problemi derivanti da erroridi programmazione che possono palesarsi anche in un secondo tempo.Sarà buona norma quindi controllare l’esistenza di aggiornamenti e patch<strong>per</strong> mantenere il sistema sempre aggiornato.2.4.6 Sviluppi di KerberosAnche se Kerberos ha ormai più di venti anni di vita continua ad evolversiintegrando <strong>nuove</strong> tecnologie e debellando <strong>nuove</strong> minacce. Così il gruppoche sviluppa Kerberos ha rilasciato diverse estensioni che forniscono le capacitànecessarie all’utilizzo di questo sistema anche in futuro, come il supporto<strong>per</strong> migliori algoritmi crittografici o <strong>per</strong> tecnologie che <strong>per</strong>mettano di su<strong>per</strong>arealcune delle limitazioni insite nel sistema di autenticazione.Kerberos e la crittografia a chiave pubblicaCome già menzionato Kerberos basa le sue comunicazioni sulla crittografiasimmetrica. Il risultato è che, in primo luogo, essendo la password un segretocondiviso tra utente e KDC, è sufficiente riuscire ad ottenere la chiave <strong>per</strong> fingeredi essere l’utente; in secondo luogo è necessario effettuare preventivamente unaregistrazione presso il KDC <strong>per</strong> poter accedere alla rete Kerberos.A entrambe queste problematiche si può rimediare utilizzando la crittografiaa chiave pubblica nella fase iniziale dell’autenticazione [Tun05]. Quando il KDCgenera la sua risposta, incapsulando la chiave di sessione <strong>per</strong> il TGT , invece dicriptarla con la chiave a lungo termine, viene utilizzata una chiave casuale a suavolta criptata con chiave pubblica dell’utente. Così solo l’utente, in possessodella sua chiave privata, può ottenere la chiave casuale con la quale estrarreinfine la chiave di sessione.Ma <strong>per</strong>ché è necessario usare una chiave casuale e non è semplicemente possibilecriptare la chiave di sessione con la chiave pubblica dell’utente? Una ragionesta nel fatto che la crittografia a chiave pubblica è abbastanza dispendiosa daun punto di vista computazionale ed è quindi solitamente applicata su dati dipiccola lunghezza come, appunto, una password: le funzioni di libreria che implementanola crittografia a chiave pubblica, a prescindere dalla lunghezza <strong>dei</strong>dati, criptano usando lo schema della chiave simmetrica con una chiave casualee poi criptano la chiave appena generata con la chiave pubblica.In più anche se si fa riferimento alla sola chiave di sessione, Kerberos incapsulaanche un certo numero di altri dati con essa e quindi le <strong>per</strong>formance dellacrittografia a chiave pubblica diventano un fattore importatante.Esiste comunque ancora un problema. Anche se l’utente e il KDC non devonocondividere una chiave a lungo termine devono comunque condividere unaqualche tipo di associazione. In altri termini il KDC non ha conferma del fattoche la chiave pubblica che l’utente sta chiedendo di usare appartenga effettivamentea lui. Un attaccante potrebbe generare una coppia di chiavi presentarleal KDC, ed utilizzarle <strong>per</strong> im<strong>per</strong>sonare un altro utente. Per impedire ciò le chiavipubbliche devono essere certificate da una qualche autorità di certificazione(CA).89


Stili di autenticazioneKerberosIn realtà il CA non cripta la chiave pubblica con la propria chiave privata<strong>per</strong> lo stesso motivo <strong>per</strong> cui il KDC non cripta la chiave di sessione con la chiavepubblica dell’utente. E non la cripta con una chiave casuale <strong>per</strong>ché la chiavepubblica e l’identità dell’utente non devono restare confidenziali. Invece passala chiave pubblica ad una funzione hash non invertibile. Il digest risultanteviene criptato con la chiave privata del CA. Solo il CA avrebbe potuto legarela chiave pubblica all’identità dell’utente dato che non è possibile creare nessunaltra stringa che dia come risultato della funzione hash gli stessi byte.Un ultimo beneficio apportato dall’introduzione della crittografia a chiavepubblica è rappresentato dalla diminuzione del numero delle chiavi che devonoessere memorizzate dalla rete. Infatti, in un contesto a chiavi segrete tra Cclient e S server, si dovrebbero memorizzare C ∗ S chiavi di sessione e C + Schiavi private condivise, mentre, sfruttando la crittografia asimmetrica, le chiavipubbliche da memorizzare risulterebbero solo C + S. In generale, una retedi n utenti comunicanti con crittografia a chiave segreta produce un totale din(n − 1)/2 chiavi condivise mentre la stessa rete, utilizzando la crittografia achiave pubblica, richiederebbe solo n chiavi pubbliche. Si può quindi affermareche l’introduzione della crittografia a chiave pubblica porterebbe ad una migliorescalabilità del sistema.Kerberos e le smart cardÈ tradizione che Kerberos basi il meccanismo di autenticazione esclusivamentesulla conoscenza di un segreto; questo è solo uno <strong>dei</strong> modi con cui è possibiledimostrare la propria identità; un’altro metodo consiste nell’essere autenticati<strong>per</strong> qualcosa che si ha. Le smart card sono basate proprio su questo concetto edesistono implementazioni di Kerberos che contemplano proprio l’utilizzo dellesmart card nella fase iniziale dell’autenticazione [Gar03].L’utilizzo delle smart card risolve uno <strong>dei</strong> problemi più seri di Kerberos: l’impossibilità<strong>per</strong> un utente di ricordare una password molto robusta. Le chiavi alungo termine devono infatti essere memorizzate dall’utente e questo porta inevitabilmentealla scelta di stringhe con bassa entropia e vulnerabili ad attacchia dizionario.In più viene limitata l’esposizione delle chiavi crittografiche; queste sonoconservate all’interno della smart card in un’area di memoria protetta dallaquale non possono essere estratte; non è infatti necessario portare all’esterno lechiavi dato che tutte le o<strong>per</strong>azioni crittografiche vengono svolte dal chip presentesulla carta. Anche se un attaccante riuscisse ad ottenere il controllo di unaworkstation non avrebbe quindi accesso alle chiavi necessarie <strong>per</strong> autenticarsiverso il sistema.La smart card è un dispositivo progettato <strong>per</strong> resistere agli attacchi, il cherende una eventuale o<strong>per</strong>azione di cracking molto difficoltosa sebbene non impossibile:esistono tecniche <strong>per</strong> restringere il campo di ricerca di un attaccoa forza bruta basate sull’analisi del consumo della smart card e <strong>dei</strong> tempi dirisposta che queste forniscono se sollecitata con input studiati ad-hoc. Questetecniche hanno dato grandi risultati ma si tratta, <strong>per</strong> ora, di attacchi allaportata solo di cracker molto motivati.Quando un nuovo utente deve essere abilitato, viene prodotta una coppia di90


Stili di autenticazioneKerberoschiavi asimmetriche; la parte pubblica viene firmata da una certification authoritye inserita insieme al certificato all’interno della smart card che viene affidataall’utente. Quando quest’ultimo utilizza la carta, la inserisce in un lettore dismart card connesso al computer; questo richiederà, <strong>per</strong> conto della carta, uncodice PIN col quale sbloccare la porzione di memoria che contiene la coppiadi chiavi. In questo modo la risposta dell’AS viene decifrata direttamente sullasmart card e la coppia di chiavi non è mai accessibile al computer utilizzatodall’utente.91


Parte IIRequisiti, metodologia econtesto


Capitolo3Analisi estesa <strong>dei</strong> requisitiI requisiti sono una parte fondamentale della progettazione in generale, tantofondamentale che una errata identificazione <strong>dei</strong> requisiti durante questa faserischia di portare al fallimento di un progetto, inteso sia come abbandono, siacome allungamento incontrollato <strong>dei</strong> tempi stimati <strong>per</strong> la realizzazione dellostesso.Con requisito di intende “ogni informazione, ottenuta in qualche modo, circale funzionalità, i servizi, le modalità o<strong>per</strong>ative e di gestione del sistema dasviluppare”.Lo scopo dell’analisi <strong>dei</strong> requisiti è quello di identificare ciò che il sistemadeve fare e descriverlo nel linguaggio dell’utente del sistema (in modo tale chesia comprensibile anche a chi non ha conoscenze di progettazione), e di assegnareai requisiti una priorità, utile <strong>per</strong> la loro gestione.Infatti la complessità di un sistema è determinata in parte dalle sue funzionalità(functional requirements) e in parte dà <strong>dei</strong> vincoli globali che incidonosullo sviluppo del sistema; ad esempio, fattori come i costi, prestazioni, robustezza,portabilità, alle volte gravano pesantemente sulla bontà del prodotto finale1 . Tali vincoli sono spesso chiamati requisiti non-funzionali (non-functionalrequirements, NFR 2 ) e giocano un ruolo centrale durante tutto il processo diprogettazione e poi sviluppo: una volta condotta a termine la Goal-Aanalysis(GA)[Ant96] o altre tecniche simili, è necessario compiere una scelta fra tutte lepossibili soluzioni alternative tenendo conto anche <strong>dei</strong> NFR. L’analisi <strong>dei</strong> NFRaiuta 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à


Analisi estesa <strong>dei</strong> requisitiRequisiti funzionali, R.1.*• requisiti funzionali: le specifiche che il sistema dovrà implementare, ovverociò che questo dovrà fare (descrivono il “cosa”, e non il “come”).• requisiti non funzionali: i limiti o i vincoli di un sistema (quasi semprenon misurabili).In questo capitolo è esposta l’analisi sistemica <strong>dei</strong> requisiti funzionali e nonfunzionali. È opportuno sottolineare che l’elenco che andremo a redarre nelleseguenti pagine non deve essere interpretato come l’esposizione <strong>dei</strong> requisitiintegralmente recepiti, ma come stesura analitica <strong>dei</strong> requisiti <strong>per</strong> i principalidomini applicativi a cui si fa riferimento in maniera diretta o diretta. Attraversoquesto elenco, successivamente sarà possibile stabilire, durante la fase progettuale,quali requisiti il presente lavoro dovrà necessariamente soddisfare, qualiinvece dovrà abilitare oppure quali ignorare.Il concetto chiave è la chiarezza dell’intero modello <strong>dei</strong> requisiti (sistema diattributi compreso) <strong>per</strong> 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 leprocedure esaminate, ma piuttosto si vogliono mettere in evidenza le caratteristichetecniche di cui i sistemi esaminati dovrebbero essere dotati. Anticipiamoche tutti i campi di applicazione presi in considerazione possiedono una caratteristicaricorrente (più o meno esplicita): si interessano ad una vasta platea diutenza, 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 elaborazioneindipendenti, che appaiono come un singolo sistema coerente. Ciascunaentità di un sistema distribuito considera remote le altre entità e le rispettive risorse,mentre considera locali le proprie. Ogni entità può variare <strong>per</strong> dimensionie funzioni e, a sua volta, può essere un sotto-sistema distribuito.In generale i sistemi distribuiti sono usati largamente poiché <strong>per</strong>mettono acalcolatori autonomi, e <strong>per</strong> transitività agli utenti, di condividere risorse. Talicaratteristiche sono anche usate <strong>per</strong> sviluppare applicazioni che consentono agruppi di <strong>per</strong>sone di lavorare assieme, su un progetto o un compito, da luoghiremoti 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 avvienela gestione <strong>dei</strong> documenti.Le organizzazioni, che basano il proprio coordinamento su un ambiente distribuitoed orientato a favorire il lavoro collaborativo si trovano necessariamentea gestire non solo risorse fisiche e tangibili, ma anche e soprattutto a lavorarecon risorse che non possono essere riferite in modo diretto, ma che necessariamenteprevedono sistemi ed apparati che svolgano la funzione di intermediaritra la risorsa stessa e l’utente finale che deve consultarla, gestirla o modificarla.94


Analisi estesa <strong>dei</strong> requisitiRequisiti funzionali, R.1.*3.1.1 Requisiti <strong>per</strong> le risorse materiali, R.1.1.*I requisiti funzionali relativi alle risorse materiali, che verranno esaminatirequisiti direttamente riferiti alla gestione e comportamento <strong>dei</strong> documenti erequisiti riferiti alla trasparenza delle o<strong>per</strong>azioni connesse alla gestione.Requisiti <strong>per</strong> la gestione <strong>dei</strong> documenti, R.1.1.1.*I requisiti funzionali <strong>per</strong> la gestione <strong>dei</strong> documenti sono strettamente collegatia quelli che devono essere rispettati nei tradizionali sistemi di DocumentManagement (DMS) [Gan06], I DMS vengono utilizzati all’interno di organizzazioniche hanno la necessità di gestire un alto numero di documenti: oltreall’amministrazione ed alla conservazione delle risorse c’è infatti la necessità diarchiviarle in modo che ognuna di esse possa essere trattata autonomamente.Non è tuttavia previsto l’uso di collegamenti (attraverso link) fra i vari documentiarchiviati, fatto che contribuisce allo scarso utilizzo di evoluti metodi diricerca delle risorse. Inoltre i DMS sono progettati con l’ottica di essere applicatiad organizzazioni strutturate in modo centralizzato.I requisiti che saranno trattati nel seguente paragrafo nascono quindi dauna rielaborazione di quelli relativi ai DMS, tenendo presente che il sistema attualmentein esame deve essere applicato ad ambiti come quello della PubblicaAmministrazione ovvero, come si è già detto, di tipo distribuito e non centralizzatoed orientati al riuso non solo <strong>dei</strong> documenti ma anche dell’informazionecontenuta al loro interno.Si vogliono quindi individuare i requisiti di un sistema documentale informaticoche sia in grado di gestire ogni aspetto <strong>dei</strong> documenti a partire dal lorociclo di vita, dalle informazioni in essi contenute e dalle relazioni esistenti fra diessi.In tale ottica, devono essere rispettati i seguenti requisiti di base [Gan06]:R.1.1.1.1 creazione (creation), il sistema deve offrire la possibilità di crearenuovi documenti;R.1.1.1.2 acquisizione (capture), il sistema deve essere in grado di acquisire documentipreesistenti (anche in formato cartaceo). Questo può avvenireattraverso varie tecnologie come ad esempio la digitalizzazione delleimmagini o la riproduzione tramite immissione manuale <strong>dei</strong> dati;R.1.1.1.3 archiviazione (storing), il sistema deve disporre di un metodo di archiviazioneefficace ed efficiente che <strong>per</strong>metta la modifica <strong>dei</strong> documentie che sia capace di gestire un’eventuale ingente crescita del volume <strong>dei</strong>dati;R.1.1.1.4 indicizzazione (indexing), deve consentire la catalogazione <strong>dei</strong> documential fine di facilitare il recu<strong>per</strong>o da parte degli utenti. Puòrisultare conveniente organizzare in tassonomie e/o ricorrere all’indicizzazionedi tutto il testo del documento archiviato tramite l’usodi parole chiave definite manualmente o di identificativi calcolatiautomaticamente;95


Analisi estesa <strong>dei</strong> requisitiRequisiti funzionali, R.1.*R.1.1.1.5 recu<strong>per</strong>o di documenti (retrieval), il sistema deve <strong>per</strong>mettere il recu<strong>per</strong>o<strong>dei</strong> documenti in base a criteri di ricerca compatibili con i criteridi indicizzazione utilizzati e con le tassonomie eventualmente definite;R.1.1.1.6 accesso ai documenti (access), il sistema deve garantire, oltre allare<strong>per</strong>ibilità, anche l’accessibilità ai documenti ed alle informazioni inessi contenute. L’accesso ad un dato documento deve essere di tiposelettivo, ovvero deve avvenire in base ad opportune autorizzazioni dicui deve essere dotata l’entità che gestisce il documento stesso;Requisiti di versioning, R.1.1.2.*Il versionamento dell’informazione è determinante <strong>per</strong> una efficace collaborazionein quanto <strong>per</strong>mette di avere sotto controllo l’evoluzione <strong>dei</strong> contenuti. Conversioning si indica la memorizzazione della evoluzione di una risorsa tenendomemoria delle diverse configurazioni durante il suo ciclo di vita: una volta memorizzate,divengono immutabili nel tempo, infatti ogni modifica futura generauna nuova versione della risorsa (stabilità delle versioni).Al fine di versionare un documento, devono essere tenuti in considerazione iseguenti punti [Ask02]:R.1.1.2.1 utilizzare attributi da affiancare ad ogni documento, si tratta di metadati3 che descrivono qualsiasi tipologia di risorse, come ad esempiodescrizioni 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. Gliattributi sono risorse essi stessi ed a loro volta possiedono metadati,inoltre possono influenzare le o<strong>per</strong>azioni di spostamento, copia ecancellazione;R.1.1.2.2 utilizzare relazioni attraverso link, servono <strong>per</strong> memorizzare la connessionetra risorse diverse, con molteplici scopi. Possono, ad esempio,stabilire un ordine nella navigazione o collegare informazioni <strong>per</strong>una corretta gestione <strong>dei</strong> documenti. Deve essere possibile creare,modificare, interrogare, leggere e cancellare le relazioni tipizzate;R.1.1.2.3 applicare meccanismi di blocco o locking, necessari <strong>per</strong> risolvere il problemadella <strong>per</strong>dita degli aggiornamenti e delle sovrascritture. È unatecnica di prevenzione che mantiene consistenti le informazioni condiviseda più utenti, ovvero quelle coinvolte nell’authoring distribuito 4 .Il lock e l’unlock su più risorse sono o<strong>per</strong>azioni che devono avvenirenello stesso intervallo di tempo al fine di prevenire la collisione tra le3 Come riportato in [Cam06b], i metadati sono “informazioni strutturate che descrivono,esplicano, localizzano qualsiasi cosa che renda più facile recu<strong>per</strong>are, usare o gestire una risorsainformativa. Spesso vengono definiti come dati relativi ai dati o come informazioni relativealle 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 <strong>per</strong>messi <strong>per</strong>gestire una risorsa comune e può essere di tipo sequenziale, parallelo o di entrambe le tipologiecontemporaneamente.96


Analisi estesa <strong>dei</strong> requisitiRequisiti funzionali, R.1.*modifiche. Le funzioni di lettura e scrittura devono essere indipendentida quelle di lock e unlock: deve essere possibile bloccare una risorsaanche senza effettuare su di essa un’o<strong>per</strong>azione di lettura o scrittura 5 ;R.1.1.2.4 consentire l’uso di prenotazioni, utili nei casi di authoring concorrentein cui più utenti lavorano su una risorsa condivisa nello stesso tempo.In tali situazioni risulta di fondamentale importanza conoscere lo statodi un documento, ad esempio quante <strong>per</strong>sone lo stanno leggendo omodificando. Con opportuni diritti, deve essere possibile:• conoscere la coda degli utenti prenotati (reservation query);• fornire la possibilità di abbandonare la coda, agli utenti che nefanno parte (release reservation).R.1.1.2.5 consentire l’aggiornamento differenziale, utilizzato nei casi in cui l’authoringè distribuito in vaste aree geografiche. In tali situazioni possonoinfatti esistere problemi relativi al mantenimento e alla qualitàdella connessione, fatto che inevitabilmente causa l’inefficienzanell’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 stessarispetto alla precedente versione 6 , piuttosto che trasmettere l’interarisorsa;R.1.1.2.6 gestire collezioni, ovvero fare uso di contenitori di risorse che possonoincludere anche altre collezioni. Una risorsa appartenente ad una collezionepuò essere inclusa direttamente o <strong>per</strong> riferimento. Se una risorsaè riferita direttamente le o<strong>per</strong>azioni vengono applicate direttamente,altrimenti hanno effetto solo sul riferimento. Deve essere possibilecreare <strong>nuove</strong> collezioni, ottenere le risorse, aggiungerle o rimuoverle;R.1.1.2.7 fare uso di una opportuna gestione <strong>dei</strong> nomi che garantisca la correttaattuazione delle seguenti attività:• copia, deve essere possibile duplicare una risorsa senza che ilclient 7 debba prima proteggerla e salvarla. Una modifica ad unarisorsa copiata deve coinvolgere solo i suoi contenuti. La copiadi una collezione comporta la copia di tutte le risorse in essacontenute e degli attributi correlati. È necessario stabilire inanticipo lo spazio sorgente e quello di destinazione;• spostamento e/o ri-nominazione, spesso è necessario cambiare ilnome ad una risorsa, ad esempio <strong>per</strong>ché viene adottata una nuovaconvenzione <strong>dei</strong> nomi o <strong>per</strong>ché 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 momentotemporale. 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 serviziofornito da un server.97


Analisi estesa <strong>dei</strong> requisitiRequisiti funzionali, R.1.*preferibile introdurre una nuova o<strong>per</strong>azione piuttosto che utilizzare,in sequenza, le attività di copia e cancellazione della risorsa.Deve essere possibile assegnare un nuovo nome alla risorsa senzache il client debba leggerla e risalvarla con un nome diverso;• cancellazione, devono essere possibili sia la cancellazione di unarisorsa, e conseguentemente delle sue copie, che la cancellazionedi una relazione, ovvero l’eliminazione del collegamento allarisorsa riferita.Requisiti di trasparenza, R.1.1.3.*I seguenti requisiti possono essere riferiti a differenti ambiti e funzioni del sistema,ma nel nostro caso sono applicati alle modalità di come dovrebbe avvenirela gestione delle risorse ispirandosi a [Mea03]:R.1.1.3.1 trasparenza dell’accesso, nasconde i dettagli del meccanismo di accessoalle risorse, comprese la rappresentazione <strong>dei</strong> dati e le tecniche diinvocazione delle o<strong>per</strong>azioni;R.1.1.3.2 trasparenza <strong>dei</strong> fallimenti, maschera i fallimenti e possibilmente provvedeal recu<strong>per</strong>o delle risorse (recovery) con una tolleranza ai guastimisurabile;R.1.1.3.3 trasparenza della localizzazione, gli utenti non devono essere a conoscenzadella locazione fisica delle risorse;R.1.1.3.4 trasparenza della replicazione, il sistema può mantenere identiche leistanze della stessa risorsa su qualsiasi host;R.1.1.3.5 trasparenza della concorrenza, un generico utente non deve essere condizionatodalle azione svolte dagli altri utilizzatori del sistema, <strong>per</strong>tantonon deve accorgersi, coerentemente con le politiche di accesso,se una risorsa viene utilizzata anche da altri.Uno <strong>dei</strong> 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 dalsistema.In generale infatti il concetto di versioning potrebbe essere considerato completamentetrasparente all’utente, tuttavia quando vengono utilizzate alcunetipologie di informazioni o di documenti è necessario che gli utenti siano aconoscenza della versione di cui fanno uso.In conclusione, il requisito di trasparenza relativo al versioning, va discusso inbase all’ambito di applicazione del sistema stesso e quindi in base alla tipologiadi informazioni gestite.Requisiti di indirizabilità, R.1.1.4.*Il sistema <strong>dei</strong> nomi usato nel web, gli URL (Uniform Resource Locator), èstrutturato in modo da rendere inscindibili contenuto informativo e locazione98


Analisi estesa <strong>dei</strong> requisitiRequisiti funzionali, R.1.*fisica di una risorsa. Al contrario nell’ambito dell’attuale trattazione è richiestoun sistema <strong>dei</strong> nomi che <strong>per</strong>metta di identificare una risorsa indipendentementeda dove questa risiede. Inoltre si deve tenere presente che più gruppi di lavorospesso si trovano ad utilizzare la stessa risorsa e ciascuno di essi ha l’esigenza dipotersi riferire ad essa con un nome adatto rispetto al proprio contesto.Possono <strong>per</strong>tanto distinguere:R.1.1.4.1 un insieme di nomi capaci di indicare una risorsa in modo univoco;R.1.1.4.2 un insieme di nomi che rappresenta i possibili alias di una data risorsa;R.1.1.4.3 uno spazio <strong>dei</strong> nomi che indichi la locazione fisica di una risorsa.Requisiti sulla codifica degli indirizzi, R.1.1.5.*Ogni risorsa deve poter essere individuata in modo univoco, caratteristica chepuò essere ottenuta grazie ad un opportuno sistema di nomi che deve rispettarei seguenti requisiti:R.1.1.5.1 coerenza con altre codifiche, la codifica <strong>dei</strong> nomi deve essere il più possibilecoerente con quella precedentemente adottata da altri sistemi;R.1.1.5.2 semplicità del confronto, l’algoritmo <strong>per</strong> confrontare i nomi tra lorodeve essere semplice, locale e deterministico;R.1.1.5.3 trascrivibilità da parte dell’uomo, nomi devono essere facilmente trascrivibilidall’uomo. In tale ottica devono essere: composti da unasequenza sufficientemente limitata di caratteri, case insensitive e noncomplicati dall’uso di caratteri speciali;R.1.1.5.4 trasportabilità, un nome deve essere identicamente trasportabile sianei messaggi <strong>dei</strong> comuni protocolli internet sia su carta;R.1.1.5.5 elaborabilità da parte delle macchine, un nome deve essere processabiledai calcolatori;R.1.1.5.6 riconoscibilità, la codifica <strong>dei</strong> nomi deve essere riconoscibile duranteil parsing 8 di un testo.3.1.2 Requisiti di contesto, R.1.2.*Una volta definiti i requisiti relati alla gestione <strong>dei</strong> documenti ed alle esigenzedi trasparenza, si può passare all’analisi <strong>dei</strong> requisiti <strong>dei</strong> sistemi di conessi alcontesto in cui le risorse sono elaborate. Tali requisiti si possono suddividerein due grandi categorie: quelli relativi alle esigenze di collaborazione tra gliutilizzatori del sistema (groupware) e quelli che riguardano la codifica <strong>dei</strong> nomiusati <strong>per</strong> identificare e gestire le risorse.8 Il parsing è il processo di analizzare uno stream continuo di caratteri (letto <strong>per</strong> esempioda un file o una tastiera) in modo da determinare la sua struttura grammaticale grazie ad unadata grammatica formale. Un parser è un programma che esegue questo compito.99


Analisi estesa <strong>dei</strong> requisitiRequisiti funzionali, R.1.*Requisiti di groupware, R.1.2.1.*I requisiti di groupware riguardano tutti gli strumenti atti a facilitare lacollaborazione in un gruppo di individui. Solitamente le tecnologie groupwaresono 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 <strong>dei</strong> 4 quadranti (figurafigura 3.1) si individuano le condizioni in cui la collaborazione si può collocare.spaziotempostesso intervallotemporaleintervalli temporalidisgiuntistesso luogo(co-locazione)interazionefaccia a facciainterazioneasincronaluoghi diversi(a distanza)interazionesincrona distribuitainterazioneasincrona distribuitaFigura 3.1: Modello a quattro quadrantiLe tipologie di interazione tra gli individui che compongono il gruppo, o tragruppi, sono infatti principalmente determinate dalle modalità spazio-temporalicon cui vengono stabilite.Lo scopo principale <strong>dei</strong> sistemi groupware è quello di garantire o abilitare iseguenti aspetti[MO94]:R.1.2.1.1 molteplici processi, i gruppi esistono, all’interno di un contesto lavorativo,<strong>per</strong> svolgere molti compiti diversi e che spesso vengono ridefinitia seguito di mutamenti socio-economici;R.1.2.1.2 molteplici metodologie di lavoro, sono necessarie <strong>per</strong> rendere efficienteed efficace la modularità. Ogni processo lavorativo può essere infattiscomposto in compiti minori, ciascuno <strong>dei</strong> quali richiede opportune edappropriate tecniche di realizzazione. Inoltre non tutti i membri <strong>dei</strong>gruppi adottano lo stesso metodo lavorativo: alcuni possono preferireun lavoro più solitario o isolato, altri invece ricercare l’influenza delgruppo a cui appartengono. I mezzi di comunicazione offrono moltesoluzioni diverse in base al tipo di problema da su<strong>per</strong>are e sono incontinua evoluzione, <strong>per</strong>tanto risulta indispensabile progettare un sistemaa<strong>per</strong>to. Anche in questo caso un approccio modulare può essereefficace nella realizzazione e nell’eventuale aggiornamento del sistema;R.1.2.1.3 sviluppo del gruppo, i gruppi sono influenzati dalla dinamica dell’ambientee delle interazioni tra gli individui. Si hanno variazioni a livellosociale quando si verifica l’entrata o l’uscita di un membro, quandosi disgregano o si costruiscono relazioni all’interno dell’organizzazione100


Analisi estesa <strong>dei</strong> requisitiRequisiti funzionali, R.1.*di cui il gruppo fa parte, in risposta a cambiamenti ambientali. Nelmomento in cui un’organizzazione svolge la propria attività basandosisul lavoro di gruppo, deve tenere presente il principio di equilibriointerrotto, proposto in [MO94], secondo tale teoria il lavoro di gruppoprogredisce in presenza di lunghi <strong>per</strong>iodi di inerzia, interrotti da rivoluzionarie limitati <strong>per</strong>iodi di piccoli mutamenti. Per consentire unbuon rendimento del lavoro svolto da un gruppo è utile usare tecniche<strong>per</strong> incrementare il consenso, definire ruoli, ridistribuire il potere,incrementare l’interazione, conservare memoria delle passate attività<strong>per</strong> programmare al meglio quelle future, pianificare la crescita delgruppo. Un altro aspetto fondamentale di cui si deve tenere conto èl’awareness, ovvero la consapevolezza del lavoro svolto dal gruppo checonsente una notevole integrazione tra membri e conseguentementeun maggiore risultato individuale;R.1.2.1.4 metodi di interazione interscambiabili, la comunicazione all’internodelle organizzazioni può avvenire grazie a metodi e tecnologie differenti,<strong>per</strong>tanto il sistema groupware deve essere in grado di coprire la maggiorparte del modello a quattro quadranti rappresentato in figura 3.1al fine di consentire, in modo integrato, il passaggio delle interazionida un quadrante all’altro al mutare delle condizioni ambientali;R.1.2.1.5 molteplici caratteristiche comportamentali, i componenti <strong>dei</strong> gruppiassumono diversi atteggiamenti nel prendere parte all’interazione enel completare e svolgere i propri compiti. Tali comportamenti dipendonodal grado di coesione, dallo stress, dai ruoli assegnati ai singolicomponenti del gruppo o al gruppo stesso. La presenza inevitabile dicomportamenti diversi all’interno di un gruppo o fra gruppi differentiè di fondamentale importanza nello svolgimento del lavoro, <strong>per</strong> questomotivo è necessario che l’organizzazione non sottovaluti l’aspettosociale legato al groupware. A tale proposito risulta utile individuareed analizzare i seguenti aspetti:• comportamenti chiave, identificano i principali metodi comportamentaliche vengono assunti, dagli individui del gruppo, neldominio applicativo trattato;• elementi catalizzanti, sono le variabili del sistema che influisconosui comportamenti. Ad esempio il tempo disponibile ha un grossoimpatto sulla concentrazione e sulla coesione tra individui.Cambiando queste variabili è possibile controllare l’o<strong>per</strong>ativitàdel gruppo;• prospettive dell’utente, sono gli aspetti che potrebbero consentireall’utente l’automazione del lavoro, la modifica e/o la <strong>per</strong>sonalizzazionedegli strumenti usati;R.1.2.1.6 <strong>per</strong>meabilità alle barriere da parte del gruppo, i limiti fisici e spaziotemporalipossono creare divisioni che, a loro volta, determinano differenzepenalizzanti tra individui. I confini del gruppo devono essere101


Analisi estesa <strong>dei</strong> requisitiRequisiti funzionali, R.1.*<strong>per</strong>meabili, nel senso che devono consentire meccanismi di scambiodelle informazioni che avvengano in modo non forzato. Tale necessitàè dettata da fattori economici e sociali, come ad esempio la presenzadi un’autorità esterna o la dipendenza da altri gruppi. Risulta quindidi fondamentale importanza stabilire e gestire i confini del gruppo inmodo da risolvere il problema dell’intero<strong>per</strong>abilità poiché il gruppo sidovrà confrontare e relazionare con il mondo esterno;R.1.2.1.7 regolazione ed adattamento del contesto nel quale il gruppo o<strong>per</strong>a, ilcontesto deve essere visto come un’opportunità piuttosto che come unostacolo all’adattabilità del gruppo. Ogni gruppo conosce le propriecapacità e, in base ai compiti che gli vengono affidati, è capace distabilire anche quali sono le proprie esigenze. La gestione di tali necessitàpuò essere affidata ad un amministratore che renda possibilela <strong>per</strong>sonalizzazione del gruppo, favorendo una modalità di visualizzazionedelle informazioni o un metodo di interazione rispetto ad altripossibili.Requisiti <strong>per</strong> le identità, R.1.2.2.*I seguenti requisiti intendono fornire i principi di cui un sistema <strong>per</strong> la gestionedelle identità dovrebbe essere dotato in uno scenario applicativo in rete alfine di ottenere successo. La formulazione <strong>dei</strong> seguenti vincoli, leggi di Metcalfe[Cam06a], è determinata dalle necessità stesse degli utenti. Per ogni utente deveessere assicurato e comunicato un trattamento etico <strong>dei</strong> loro dati. Gli utentiesigono safety e security dai servizi in rete nel momento in cui vengono richiestidati <strong>per</strong>sonali e sensibili della <strong>per</strong>sona.R.1.2.2.1 Controllo dati utente e consenso. Il sistema di gestione delle identitàdeve rivelare le informazioni <strong>per</strong> le quali l’utente ha espresso ilconsenso.R.1.2.2.2 Divulgazione minima quando obbligatoria. La soluzione che divulgail minimo insieme di informazioni <strong>per</strong>sonali e limita il loro uso è lasoluzione più stabile a lungo termine.R.1.2.2.3 Organizzazioni accreditate. I sistemi di identità digitali devono essereprogettati in modo che la divulgazione delle informazioni <strong>per</strong>sonalisia limitata a organizzazioni che abbiano una ruolo necessario egiustificabile in una data interazione.R.1.2.2.4 Identificazione selettiva. Un sistema universale di identità deve supportareidentificatori omnidirezionali utilizzabili da soggetti pubblicied unidirezionali utilizzabili da soggetti privati, <strong>per</strong> facilitare rispettivamenteil discovery e <strong>per</strong> impedirlo.R.1.2.2.5 Pluralismo di o<strong>per</strong>atori e tecnologie. Un sistema di identità universaledeve abilitare e incanalare la coo<strong>per</strong>azione di molteplici tecnologiefornite da differenti e molteplici provider.102


Analisi estesa <strong>dei</strong> requisitiRequisiti funzionali, R.1.*R.1.2.2.6 Integrazione “umana”. Un sistema di identità universale deve recepirel’utente come parte integrante del sistema distribuito attraversomeccanismi di comunicazione uomo-macchina non ambigui in gradodi proteggerlo da attachi alla sua identità.R.1.2.2.7 Es<strong>per</strong>ienze consistenti attraverso contesti. I sistemi di identità devonogarantire ai propri utenti la possibilità di selezionare in manieradinamica una identità contestuale di convenienza ovvero una identità“surrogato della vera identità” con cui accedere ai servizi; ad esempiouna <strong>per</strong> navigare, una <strong>per</strong> la collaborazione in rete, una <strong>per</strong> i servizial cittadino, una <strong>per</strong> i servizi finanziari.Requisiti di awareness, R.1.2.3.*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’interconnessionedelle reti di comunicazione su larga scala, necessaria <strong>per</strong> gestireun efficiente ed efficace scambio di informazioni, che sta alla base del lavorocollaborativo. Nel contesto sono <strong>per</strong>tanto di interesse minore.I requisiti di comunicazione logica, e sono i più interessanti, riguardano invecela comunicazione fra entità logiche di alto livello, come ad esempio la gestionedi tutte le o<strong>per</strong>azioni effettuate all’interno di un gruppo di lavoro al fine disoddisfare l’awareness favorendo la condivisione e lo scambio di informazioni.I requisiti che verranno evidenziati emergono a fronte delle domande checiascun partecipante alla collaborazione potrebbe porsi durante lo svolgimentodi una attività collaborativa.[GG96]. Sono parzialmente sovrapposti ai requisitidi Groupware, ma in questo caso l’attenzione è completamente incentratasull’individuo.R.1.2.3.1 presenza, indica chi sta partecipando alla attività;R.1.2.3.2 luogo, indica dove sono svolte le attività;R.1.2.3.3 o<strong>per</strong>osità, indica il grado di vitalità nell’ambiente;R.1.2.3.4 azioni, indica cosa stanno facendo i partecipanti al gruppo;R.1.2.3.5 intenzioni, indica i passi da svolgere ed in generale gli obbiettivi daraggiungere;R.1.2.3.6 cambiamenti, le modifiche in corso e dove sono state effettuate;R.1.2.3.7 strumenti, quali strumenti sono utilizzati dal gruppo;R.1.2.3.8 visibilità, indica il grado di visibilità delle attività;R.1.2.3.9 abilità, indica cosa sono in grado di fare i partecipanti al gruppo;R.1.2.3.10 sfera di influenza, indica su cosa (risorsa) possono essere effettuaticambiamenti;R.1.2.3.11 aspettative, indica cosa il gruppo si può aspettare da un partecipante.103


Analisi estesa <strong>dei</strong> requisitiRequisiti non funzionali, R.2.*3.2 Requisiti non funzionali, R.2.*I requisiti non funzionali sono necessari <strong>per</strong> definire le proprietà ed i vincolidel sistema e generalmente sono più critici rispetto a quelli funzionali poiché,se non vengono soddisfatti, possono rendere inutile l’intero sistema. Purtroppoquasi sempre sono non misurabili e qualitativamente rilevabili a posteriori.3.2.1 Requisiti architetturali, R.2.1.*Le organizzazioni possono realizzare un’infrastruttura estesa su aree o<strong>per</strong>ativeinterconnesse fra loro. Per raggiungere tale scopo in maniera efficace edefficiente sono suggeriti i seguenti requisiti[MBB + 03]:R.2.1.1 accoppiamento debole, si riferisce al grado di rigidità e durata delle relazionitra le parti in causa. Ad esempio, si ha un accoppiamento fortese un sistema deve essere monitorato da un altro in modo <strong>per</strong>sistentenel tempo; al contrario, si ha un accoppiamento debole nel caso in cuitra due o più sottosistemi si verificano solo occasionali scambi di informazionieffettuati in base ad esigenze nate da necessità contingenti. Ladurata di un accoppiamento può essere dinamica (o transitoria) oppurea lungo termine;R.2.1.2 contenimento dell’eterogeneità, si riferisce al grado di diversità tra isottosistemi esistenti all’interno di un’organizzazione. La necessità diaccedere ai dati, attraverso molteplici tipologie di sistemi, comportamaggiori sforzi <strong>per</strong> realizzare la connessione ed una notevole complessitànella gestione dell’informazione. Infatti, solitamente, sistemi diversirappresentano l’informazione in modo differente adottando standard incompatibilio soluzioni di opportunità; inoltre possono venire utilizzatestrutture differenti rispetto alle strategie di gestione ed ai protocolli dicomunicazione previsti da altri sistemi;R.2.1.3 autonomia, si riferisce al grado di condiscendenza di un sistema localerispetto alle regole ed alle linee guida che interessano il sistema nella suaglobalità. Una completa autonomia consente di progettare e realizzareil sistema locale in modo del tutto indipendente rispetto a quello centrale,sono <strong>per</strong>tanto consentite libere scelte nella modellazione <strong>dei</strong> processi,nella rappresentazione dell’informazione, nell’adozione <strong>dei</strong> modelli diprogrammazione e comunicazione con il solo vincolo di realizzare un’interfaccia<strong>per</strong> stabilire un’interconnessione tra i due sistemi e il controlloremoto delle risorse. Un’organizzazione di questo tipo rende i sistemilocali flessibili rispetto ad eventuali cambiamenti interni, anche se unacompleta ed autonoma coo<strong>per</strong>azione è spesso difficile da raggiungere;R.2.1.4 maneggiabilità esterna, si riferisce al grado di visibilità e di semplicitànella manutenzione esterna del sistema. Affinché un processo locale siaosservabile e controllabile dall’esterno, deve essere concepito in modotale da facilitare la su<strong>per</strong>visione del proprio stato e la misurazione delleprestazioni, la predizione dello stato futuro e di quello di disponibilità.104


Analisi estesa <strong>dei</strong> requisitiRequisiti non funzionali, R.2.*Devono essere presenti <strong>dei</strong> punti di misurazione e di controllo implementaticon lo scopo di stabilire e controllare l’affidabilità del sistema.Per svolgere correttamente questa attività di monitoraggio è necessarioche, a tali strumenti, il sistema fornisca sufficienti informazioni <strong>per</strong>tinenti.Generalmente, un’alta visibilità comporta complesse descrizioni <strong>dei</strong>processi che possono essere giustificate se <strong>per</strong>mettono vantaggi capacidi aumentare la qualità del servizio o Quality of Service (QoS);R.2.1.5 adattabilità, si riferisce al grado in cui il sistema è capace di adattarsi velocementeai cambiamenti. Con la continua evoluzione della tecnologia,i sistemi o<strong>per</strong>ano in un ambiente altamente dinamico: nuovi servizi erisorse devono di diventare prontamente o<strong>per</strong>ativi oppure vecchie risorsedevono essere rimosse o modificate. Un sistema si dice adattabile, seè in grado di rispondere rapidamente ai cambiamenti che generalmentenon sono predicibili, ma che solitamente vengono scatenati da elementiquali il clima politico-economico e il profitto;R.2.1.6 affidabilità, si riferisce alla capacità di rispettare le specifiche di funzionamentonel tempo;R.2.1.7 sicurezza, si riferisce alle azioni che devono essere compiute <strong>per</strong> renderesicuro il sistema ed aumentare così la fiducia sulle interazioni. Il sistemadeve prevedere la gestione delle autorizzazioni e, se richiesto, attuarel’identificazione e l’autenticazione delle risorse: alcune interazioni possonoavvenire basandosi su una limitata conoscenza delle entità coinvolte,altre invece necessitano di politiche di riservatezza più stringenti;R.2.1.8 scalabilità, si riferisce alla capacità di un sistema di crescere nel tempolungo una o più dimensioni, come ad esempio il volume <strong>dei</strong> dati accessibili,il numero di transazioni effettuate <strong>per</strong> unità di tempo o il numerodi interazioni contemporanee.Non è sempre possibile ottenere il massimo grado di realizzabilità <strong>dei</strong> requisitiappena descritti, anche <strong>per</strong>chè alcuni risultano in parziale antagonismo,quindi si rende già evidente la necessità di giungere a compromessi progettuali,effettuando scelte bilanciate.3.2.2 Requisiti di qualità <strong>dei</strong> dati, R.2.2.*Al fine di garantire la massima fruibilità dell’informazione, è necessario che idati in essa contenuti siano dotati delle seguenti caratteristiche[AIP02, Nat06]:R.2.2.1 sicurezza, i dati devono essere organizzati in modo tale che sia garantitol’accesso ad essi solo a chi effettivamente ne ha il diritto;R.2.2.2 riservatezza, i dati devono essere organizzati in modo tale che sianonecessari opportuni <strong>per</strong>messi <strong>per</strong> poter accedere ai dati;R.2.2.3 usabilità, gli utenti che hanno il diritto di accedere all’informazione devonoessere messi nelle condizioni di poterlo fare indipendentementedalla condizione fisica, psichica e culturale;105


Analisi estesa <strong>dei</strong> requisitiRequisiti non funzionali, R.2.*R.2.2.4 esattezza, deve esserci una corrispondenza fidata 9 tra i dati e le caratteristicheosservate del fenomeno di interesse;R.2.2.5 accuratezza, è il grado di conformità di un valore acquisito, misuratoe calcolato, rispetto al suo attuale valore. Devono essere garantite sial’accuratezza sintattica che quella semantica, come previsto in [Nat06].L’accuratezza sintattica misura la precisione del valore di un dato rispettoad un dominio di valori considerato sintatticamente corretto: adesempio, si ha un basso grado di accuratezza sintattica quando il nomeMaria è riportato coma Marja. L’accuratezza semantica è la precisionedel valore di un dato rispetto ad un dominio di valori considerato semanticamentecorretto: si ha, ad esempio, un basso grado di accuratezzasemantica quando il mome Maria è riportato come Francesca, che èsintatticamente accurato, <strong>per</strong>ché è compreso nel dominio di riferimentodi “tutti i nomi propri di <strong>per</strong>sona”, ma è un nome diverso;R.2.2.6 completezza, i dati rilevati devono coprire il maggior numero di caratteristichee sfaccettature relative al fenomeno osservato. Avere a disposizionepiù categorie di dati consente di effettuare un’analisi del fenomenomeno ristretta e limitata che potrebbe condurre a considerazioni errate;R.2.2.7 consistenza, misura l’assenza di contraddizioni tra i dati di uno stessorecord o di archivi diversi. Si parla di consistenza interna se i daticonfrontati appartengono ad uno stesso record: ad esempio, in un documentoche riguarda l’entità “impiegati” di un’azienda, la data di nascitanon può essere maggiore della data di assunzione. Si parla di consistenzaesterna se i dati confrontati appartengono a due archivi diversi: semprenel caso del documento che riguarda l’entità “impiegati” la data dinascita contenuta nell’archivio della sede centrale di un’organizzazionedeve essere uguale a quella contenuta nell’archivio della succursale;R.2.2.8 tempestività, i dati, nel momento in cui vengono consultati da un utentedevono essere aggiornati. Le modalità di aggiornamento <strong>dei</strong> dati possonoessere calibrate in base alla funzione che questi svolgono all’internodell’organizzazione. La frequenza di aggiornamento di un’informazioneche deve essere utilizzata una volta al mese può essere minore rispetto aquella che invece viene usata giornalmente: è rilevante che al momentodell’utilizzo entrambe siano aggiornate;R.2.2.9 <strong>per</strong>tinenza e non eccedenza, i dati raccolti, creati, analizzati devonoessere appropriati al contesto di analisi.3.2.3 Requisiti <strong>per</strong> i documenti, R.2.3.*Un sistema distribuito è costituito da una serie di aree o<strong>per</strong>ative decentratein grado di comunicare tra loro e, conseguentemente, di condividere risorse. Pertale motivo, spesso si ricorre all’uso di i<strong>per</strong>testi che connettono informazionilocalizzate in punti diversi di uno o più documenti. Estendendo il concetto, gli9 Nessun sistema automatico o manuale è in grado di garantire l’esattezza in senso assoluto106


Analisi estesa <strong>dei</strong> requisitiRequisiti non funzionali, R.2.*i<strong>per</strong>testi possono anche connettere uno o più documenti, o parte di essi, situatiin zone fisiche differenti.Gli aspetti di cui si deve tenere conto <strong>per</strong> creare ed utilizzare i<strong>per</strong>testi,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’esternodell’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 sistemadi riferimento;– basato su relazioni direzionali, come ad esempio i punti cardinali;– basato su relazioni topologiche, ovvero su o<strong>per</strong>azioni fra insiemi qualidisgiunzione, unione, sovrapposizione;Tenendo conto <strong>dei</strong> modelli appena descritti, gli i<strong>per</strong>testi devono quindi rispettarei seguenti requisiti[BM99]:R.2.3.1 interazione, il sistema deve mettere l’utente nelle condizioni di potersfruttare le potenzialità e le risorse del sistema. Si parla di interazioneapplicata ai seguenti ambiti:• alla navigazione, il sistema si occupa di gestire il flusso della presentazionedelle informazioni all’utente;• al progetto trattato, il sistema fornisce strumenti utili <strong>per</strong> la manipolazionedel layout 10 sia dal lato visivo che acustico;R.2.3.2 riusabilità, i contenuti che caratterizzano una risorsa devono essereriusabili. Il grado di riusabilità di un dato si misura le tre seguentidimensioni:• granularità del riuso, indica gli elementi che possono essere riusati.Si distinguono tre livelli di granularità di riuso: completo, diframmenti e di dati elementari contenuti nella risorsa;• tipo di riuso, indica come il materiale può essere riusato nella composizionedi <strong>nuove</strong> risorse. Si individuano due tipologie di riuso:identico, che <strong>per</strong>mette di esportare ed importare i dati con le lorooriginali relazioni e con i vincoli temporali, spaziali e di interazione;strutturale, che coinvolge solo la parte strutturale (se è stataseparata dal layout <strong>dei</strong> contenuti);10 Il termine layout indica come una risorsa viene presentata all’utente. In tale ottica, apparechiaro che ad un documento possono essere associati più layout diversi in base al tipo di utilizzoche ne deve essere fatto o alla <strong>per</strong>sona che lo deve fruire.107


Analisi estesa <strong>dei</strong> requisitiRequisiti non funzionali, R.2.*• identificazione degli elementi riusabili, indica la capacità di classificareopportunamente i dati in modo che possano essere più facilmenteriutilizzabili. A tal fine è necessario fare uso di metadati emeccanismi <strong>per</strong> classificare, indicizzare ed effettuare ricerche sullerisorse del sistema;R.2.3.3 adattabilità, la presentazione di risorse multimediali deve essere adattataal contesto dell’utente. L’adattamento avviene sulla base degliinteressi <strong>per</strong>sonali dell’utente e delle tecnologie che esso ha a disposizionee può essere di tipo statico o dinamico. Si ha adattabilità staticaquando le possibilità alternative di rappresentazione sono conosciute eriferite alla risorsa durante la creazione della stessa. Si ha adattabilitàdinamica quando le alternative disponibili sono determinabili, e quindideterminate, solo quando avviene la rappresentazione;R.2.3.4 neutrale presentazione, è auspicabile che i dati di un’organizzazione nonvengano condizionati da specifiche implementazioni del sistema in quantouna simile situazione potrebbe limitarne il riuso e condurre ad unascarsa adattabilità al contesto. Le informazioni devono quindi esseremodellate in modo tale da risultare neutrali, ovvero indipendenti,rispetto alla contingente presentazione. Eventualmente può essere previstoun meccanismo che, nel momento in cui i dati vengono presentatiall’utente, utilizza <strong>dei</strong> meccanismi automatici di conversione (da datineutrali a dati modellati in base alla visualizzazione voluta).108


Capitolo4Metodologia di progettazioneData la complessità del problema, <strong>per</strong> non incorrere nel rischio di tralasciareaspetti determinanti è opportuno attuare una sistematizzare <strong>dei</strong> requisiti, direttamenteo indierettamente connesse al problema (capitolo 3) e delle soluzioniprogettuale a problemi ricorrenti (capitoli 1 e 2).Allo stato dell’arte, sulla base delle tecnologie, gli stili o pattern architetturalidiscussi, saranno adesso riletti i requisiti di base <strong>per</strong> stabilire come dovrannoessere recepiti durante la progettazione. A seguire tale valutazione sarannoenunciate le linee guida progettuali, in forma di principi generali.Le scelte illustrate mirano a formulare quella che riteniamo una buona metodologiaprogettuale orientata ad ottenere la migliore garanzia possibile <strong>per</strong> unsistema distribuito scalabile.I concetti saranno rielaborati, contestualizzati e specializzati quando verrannoaffrontati i sottosistemi e servizi nella parte IV.4.1 Valutazione <strong>dei</strong> requisitiNel capitolo 3 sono elencati un totale di 73 requisiti di base suddivisi in 11categorie di interesse (manifestato in maniera diretta o indiretta). Al fine disistematizzare qualitativamente l’elenco, nella presente sezione verranno rilettiapplicando degli attributi qualificanti.In generale gli attributi <strong>dei</strong> requisiti sono variabili in funzione di chi li scrive edel momento in cui li valuta, così un attributo a partità di importanza può assumereuna priorità diversa nel tempo. Il compromesso tra priorità ed importanzapuò essere attuato con la classificazione MoSCoW, un acronimo comunementeusato <strong>per</strong> rappresentare quattro gruppi a priorità gerarchica[Hat08]:


Metodologia di progettazionePrincipi progettuali1. MUST have: i requisiti non sono negoziabili e l’incapacità l’incapacità disoddisfare 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, madebolmente vantaggiose;4. WON’T have: requisiti che saranno completamente ignorati (almeno temporaneamente,<strong>per</strong>chè potrebbero essere reintrodotti in uno stadio successivodi progettazione).Poichè il nostro interesse è fortemente rivolto anche alle abilità sostenute dallainfrastruttura, gli attributi MoSCoW, proprio <strong>per</strong> come sono definiti, escludonola possibilità di evidenziare comportamenti di interesse che dovrebberoessere abilitati nelle applicazioni.Estendiamo i criteri MoSCoW introducendo il gruppo:5. ENABLE: caratteristica non soddisfatta, ma di cui si auspica l’abilitazioneo 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 (pagina111), 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 valutazioneschematica di ciascun requisito.4.2 Principi progettuali4.2.1 Non limitare la vista sul problema: approccio sistemicoLa maggior parte delle specifiche <strong>per</strong> sistemi complessi, come quello cheintendiamo trattare, sono così estese che nessun singolo individuo è in grado dicomprenderne a fondo tutti gli aspetti. Come consigliato in Reference Modelof Open Distributed Processing (RM-ODP)[Val01, EM04, WN01] e in UnifiedModeling Language (UML)[HM03, RJB99] si possono adottare viste multiplesul problema generale, al fine di separarne gli aspetti e facilitare l’identificazione<strong>dei</strong> vincoli, la formulazione mirata <strong>dei</strong> requisiti <strong>per</strong> una corretta selezione delletecniche risolutive:• Punto di vista organizzativo. Focalizza l’attenzione sugli intenti, suirisultati, sulle politiche del sistema. Vengono definite le politiche organizzativee sociali in termini di entità attive e passive. È una visionepuramente concettuale dell’architettura che stabilisce gli obiettivi generali,le finalità del progetto, le entità del dominio di interesse e i ruoli checaratterizzano le interazioni. Le entità dedotte dal contesto del problema110


Metodologia di progettazionePrincipi progettualiRequisito Must Should Could Won’t Enab.1.1.1.1 creazione ̌1.1.1.2 acquisizione ̌ ̌1.1.1.3 archiviazione ̌1.1.1.4 indicizzazione ̌ ̌1.1.1.5 recu<strong>per</strong>o ̌ ̌1.1.1.6 accesso ̌Tabella 4.1: Requisiti funzionali <strong>per</strong> le risorse materiali (gestione risorse)Requisito Must Should Could Won’t Enab.1.1.2.1 attributi ̌1.1.2.2 relazioni ̌1.1.2.3 locking ̌1.1.2.4 prenotazione ̌1.1.2.5 aggiornamento differenzialě1.1.2.6 collezionare ̌1.1.2.7 gestione del nome ̌Tabella 4.2: Requisiti funzionali <strong>per</strong> le risorse materiali (versioning)Requisito Must Should Could Won’t Enab.1.1.3.1 dell’accesso ̌1.1.3.2 <strong>dei</strong> fallimenti ̌1.1.3.3 della localizzazione ̌1.1.3.4 della replicazione ̌1.1.3.5 della concorrenza ̌Tabella 4.3: Requisiti funzionali <strong>per</strong> le risorse materiali (trasparenza)Requisito Must Should Could Won’t Enab.1.1.4.1 univoca ̌1.1.4.2 alias ̌1.1.4.3 fisica ̌Tabella 4.4: Requisiti funzionali <strong>per</strong> le risorse materiali (indirizzabilità)111


Metodologia di progettazionePrincipi progettualiRequisito Must Should Could Won’t Enab.1.1.5.1 coerenza con altrě̌codifiche1.1.5.2 semplicità del confrontǒ̌1.1.5.3 trascrivibilità dǎ̌parte dell’uomo1.1.5.4 trasportabilità ̌1.1.5.5 elaborabilità ̌1.1.5.6 riconoscibilità ̌ ̌Tabella 4.5: Requisiti funzionali <strong>per</strong> le risorse materiali (codifica)Requisito Must Should Could Won’t Enab.1.2.1.1 molteplici processi ̌ ̌1.2.1.2 molteplici metodologiě ̌di lavoro1.2.1.3 sviluppo del gruppǒ̌1.2.1.4 metodi di interazioně̌interscambiabili1.2.1.5 molteplici caratteristichě ̌comportamentali1.2.1.6 <strong>per</strong>meabilità allě̌barriere1.2.1.7 regolazione eď ̌adattamento del contestoTabella 4.6: Requisiti funzionali <strong>per</strong> le risorse di contesto (groupware)Requisito Must Should Could Won’t Enab.1.2.2.1 controllo dati utentěe consenso1.2.2.2 divulgazione minimǎquando obbligatoria1.2.2.3 organizzazioni accreditatě1.2.2.4 identificazione selettivǎ̌1.2.2.5 pluralismo di o<strong>per</strong>atorǐ̌e tecnologie1.2.2.6 integrazione umanǎ1.2.2.7 es<strong>per</strong>ienze consistentǐattraversocontestiTabella 4.7: Requisiti funzionali <strong>per</strong> le risorse di contesto (identità)112


Metodologia di progettazionePrincipi progettualiRequisito Must Should Could Won’t Enab.1.2.3.1 presenza ̌ ̌1.2.3.2 luogo ̌ ̌1.2.3.3 o<strong>per</strong>osità ̌ ̌1.2.3.4 azioni ̌ ̌1.2.3.5 intenzioni ̌1.2.3.6 cambiamenti ̌1.2.3.7 strumenti ̌ ̌1.2.3.8 visibilità ̌ ̌1.2.3.9 abilità ̌ ̌1.2.3.10 sfera di influenza ̌ ̌1.2.3.11 aspettative ̌ ̌Tabella 4.8: Requisiti funzionali <strong>per</strong> le risorse di contesto (awareness)Requisito Must Should Could Won’t Enab.2.1.1 accoppiamento debolě2.1.2 contenimento dell’eterogeneità̌2.1.3 autonomia ̌2.1.4 maneggiabilità esternǎ̌2.1.5 adattabilità ̌2.1.6 affidabilità ̌2.1.7 sicurezza ̌2.1.8 scalabilità ̌Tabella 4.9: Requisiti non funzionali architetturaliRequisito Must Should Could Won’t Enab.2.2.1 sicurezza ̌2.2.2 riservatezza ̌2.2.3 usabilità ̌ ̌2.2.4 esattezza ̌2.2.5 accuratezza ̌2.2.6 completezza ̌2.2.7 consistenza ̌2.2.8 tempestività ̌2.2.9 <strong>per</strong>tinenza e noň̌eccedenzaTabella 4.10: Requisiti non funzionali sulla qualità <strong>dei</strong> dati113


Metodologia di progettazionePrincipi progettualiRequisito Must Should Could Won’t Enab.2.3.1 interazione ̌2.3.2 riusabilità ̌2.3.3 adattabilità ̌2.3.4 neutrale presentazioněTabella 4.11: Requisiti non funzionali <strong>per</strong> i documentisono organizzate in gerarchie a cui sono associati <strong>dei</strong> ruoli. I ruoli sonoassegnati in termini di politiche gestionali. Le politiche sono divisibili intre principali categorie: <strong>per</strong>messi (o azioni consentite), divieti (o azioniproibite) ed obblighi (azioni da adempiere).• Punto di vista informativo. Focalizza l’attenzione sulla semanticadell’informazione, della sua elaborazione e ciclo di vita. Descrive l’informazionetratta dal sistema, la struttura e i tipi <strong>dei</strong> dati. Cattura leproblematiche riguardanti la condivisione delle informazioni, modellandogli oggetti in termini di metadati, stato e struttura. La struttura puòessere statica, quando riguarda una particolare istanza, dinamica, quandodescrive lo stato e l’evoluzione di un oggetto oppure invariante, quandorappresenta proprietà che devono rimanere costanti nel tempo. Dovrannoessere definiti i modelli <strong>per</strong> rappresentare l’informazione ed il suo scambiotra sottosistemi coo<strong>per</strong>anti.• Punto di vista computazionale. Focalizza l’attenzione sulla decomposizionefunzionale del sistema con la finalità di definire le interfacce delleentità e renderne trasparente l’accesso.• Punto di vista ingegneristico. Focalizza l’attenzione sui meccanisminecessari alla realizzazione di interazioni distribuite nel sistema. Qui deveessere affrontato e risolto il problema dell’eterogeneità del sistema e dellacomunicazione.• Punto di vista tecnologico. Focalizza l’attenzione sulle scelte tecnologiche.Descrive specifici prodotti e standard <strong>per</strong> l’implementazione. Vengonoeffettuate le scelte hardware e software capaci di rispondere ai requisitiprecedentemete identificati, apportando eventuali compromessi.I punti di vista esposti risultano, nel loro complesso, complementari ed indipendenti<strong>per</strong> una ragionevole e iniziale scomposizione del problema generale.Inoltre le tecniche di rappresentazione previste in [HM03, RJB99] consentono diesprimere le viste in maniera standardizzata e largamente condivisa.È necessario comunque osservare che una vista eccessivamente estesa rischiadi complicare oltremodo il problema, già <strong>per</strong> propria natura estremamente variegatoe polimorfico. È consigliato un adeguato compromesso tra la complessitàdella rappresentazione e della sua completezza espressiva.114


Metodologia di progettazionePrincipi progettuali4.2.2 Scomporre la complessità: stratificareLa stratificazione come architectural style o design pattern è ormai un datodi fatto ed è vincente non solo nelle reti di telecomunicazione (ISO/OSI), maanche nella progettazione software [FRF + 02, BMR + 96, AZ05], ma spesso nellapratica viene violata come evidenziato in [SRR06].I vantaggi inoltre si presentano anche a lungo termine <strong>per</strong> una migliore divulgazionee comprensione [RDG94], così come nella riduzione <strong>dei</strong> costi di sviluppoa parità di qualità con altri metodologie [ZEWH95] quando si cerca una soluzionescalabile ed implementabile <strong>per</strong> parti successive incrementalmente migliorabili,promuovendo il riuso, la crescita e l’intero<strong>per</strong>abilità.Il vantaggio della stratificazione si rileva anche nei costi di sviluppo e diaggiornamento, poiché l’indipendenza della logica implementativa <strong>dei</strong> vari stratipuò essere migliorata e modificata senza ri<strong>per</strong>cuotersi sugli strati adiacenti, apatto che le interfacce non subiscano modifiche.In [GKT02] viene evidenziato come la stratificazione sia vantaggiosa su largascala non solo <strong>per</strong> l’erogazione <strong>dei</strong> servizi, ma anche <strong>per</strong> la gestione ed il controlloscalabile delle risorse e <strong>dei</strong> servizi che le trattano. Viene suggerita unaelevata astrazione delle entità in modo da attuare una chiara separazione trale componenti del sistema, con una strategia dividi-e-conquista. Ovviamentela stratificazione non riduce la complessità del problema, ma aiuta a ridurre lacomplessità della progettazione <strong>dei</strong> singoli elementi costituenti il sistema.L’orientamento verso un’architettura stratificata è stato inoltre suggerito in[MD00]: viene auspicato questo paradigma progettuale <strong>per</strong> la realizzazione delweb semantico. Il termine interdataworking è stato coniato in questo contestoin analogia a internetworking delle reti di calcolatori.Sebbene in [GHLL06] sia stato messo in evidenza che in generale esiste unacomponente impredicibilie sulle prestazioni di un sistema risultante dalla composizionedi servizi, la stratificazione rappresenta la soluzione anche <strong>per</strong> la sostenibilità<strong>dei</strong> progetti e <strong>dei</strong> sistemi sia in ambito telematico che in ambitoinformatico. Come confermato nella pratica dall’evoluzione di Internet e <strong>dei</strong>molti progetti open (es. GNU/Linux), l’approccio stratificato abilita la crescitaed il miglioramento nel tempo del sistema nel suo complesso.Ricordiamo sinteticamente i principi fondanti:• separation of concern: ogni livello viene definito trattando separatamentei soli problemi che riguardano il livello stesso, mettendo da parte problematicheinessenziali o che verranno trattate da altri livelli;• information hiding: ogni livello espone all’esterno solo l’informazione indispensabilealla comunicazione con i livelli adiacenti, mantenendo internaogni 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 chegli competono e che verranno generate dai livelli ad esso adiacenti. La logicainterna, con cui le funzioni di competenza verranno elaborate, non è visibile115


Metodologia di progettazionePrincipi progettualidall’esterno. Naturalmente la strategia good enough risulta vincente solo se unitaalla capacità del sistema di crescere e migliorarsi nel tempo. Una possibilità <strong>per</strong>ottenere questa caratteristica è rendere il progetto a<strong>per</strong>to in tutto il suo ciclo disviluppo.Limitare la crescita della complessitàConsideriamo un sistema distribuito costituito da N servizi coo<strong>per</strong>anti (latoserver) che in maniera unitaria erogano un unico servizio ed una applicazioneclient che richiede tale servizio. Per semplicità assumiamo di avere a disposizioneuna sola istanza <strong>per</strong> servizio (processo) ed un solo client, quindi avremo Nprocessi server ed 1 processo client.Analizziamo il sistema di un punto di vista puramente astratto, ragionandosulle 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 processopuò dialogare con qualsiasi altro. Senza contare eventuali ripetizioni, le possibilicomunicazioni instaurabili sono N 2 : nel loro complesso erogano un servizio. Ilclient può avviare al massimo N interazioni facendo salire il totale a N 2 + N,qualora non esista una buona orchestrazione infrastrutturale.1123... ...i-1iii+1... ...N-2N-1NNFigura 4.1: Interazioni tra servizi116


Metodologia di progettazionePrincipi progettualiAdesso vincoliamo gli N processi in un ordinamento rigido ed imponiamoil principio che un processo server può comunicare solo con i livelli su<strong>per</strong>ioreed inferiore ed al più con sè stesso. Con questa condizione il numero massimodi 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 iniziare2 comunicazioni, mentre i processi da 2 a N −2 possono iniziare 3 comunicazioni(sempre senza ripetizioni).12123... ...i-1iii+1... ...N-2N-1NN-1NFigura 4.2: Interazioni di servizi stratificatiLe considerazioni avanzate nel primo e nel secondo caso rappresentano unastima della complessità massima ottenibile, dove con complessità si indica ilnumero di possibili interazioni instaurabili tra processi.Un procedimento di valutazione analogo si può applicare anche nel softwaredove in gioco stavolta si possono considerare componenti, librerie, classi, oggettiecc.Senza la stratificazione la complessità potenzialmente può cresce quadraticamente(O(N 2 )) al crescere del numero di processi in gioco, mentre in un sistemastratificato, al più la crescita della complessità delle relazioni è lineare (O(N)).Inoltre la complessità massima attesa <strong>per</strong> il client è abbattuta da N ad 1.Il valore N 2 rappresenta il valore peggiore, a cui <strong>per</strong>ò è plausibile tendere,117


Metodologia di progettazionePrincipi progettualilà dove non vi siano <strong>dei</strong> vincoli progettuali chiari o dove nel tempo venganointrodotte <strong>per</strong> necessità o convenienza ulteriori relazioni[SRR06]. L’esplosionequadratica di messaggi (stavolta considerando ripetute interazioni) potrebbedivenire una inevitabile conseguenza ed impedimento alla scalabilità.Quindi, dato un insieme di N servizi, risulta strategico attuare una politica diseparazione <strong>dei</strong> compiti e ordinamento, così come suggerito nella stratificazione.Certamente la stratificazione richiede una più accorta progettazione <strong>dei</strong> servizie delle interfacce in modo da rispondere ai vincoli del livello.4.2.3 Adottare uno stile chiaro e standardizzato: SOA +ReSTDall’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 relativiai processi. A differenza della coreografia, l’orchestrazione componeservizi in un novo servizio che ha un controllo complessivo su tutto ilprocesso [Jos07].• Coreografia. La coreografia è un modo di aggregare servizi: non componeservizi in un nuovo servizio. Definisce, invece, i ruoli e le politiche che abilitanoi differenti servizi a collaborare. Ogni servizio coinvolto nel processovede e contribuisce solo ad una parte di esso [Jos07].Richiami a SOAIn riferimento a [MLM + 06b] risulta vantaggioso <strong>per</strong>seguire un approccioche risponda ai principi dell’architettura orientata ai servizi (Service OrientedArchitecture), <strong>per</strong> far fronte al bisogno di flessibilità nell’architettura softwareche si desidera ottenere ed osservando che tali principi non ostacolano lastratificazione.Solitamente è tipico pensare di risolvere i problemi di compatibilità e intero<strong>per</strong>abilitàtra processi semplicemente adottando una soluzione unica ed eliminandocosì le differenze. L’approccio SOA parte invece dal presupposto chel’eterogeneità non può essere eliminata [Jos07] e indicando lo sviluppo di servizidebolmente accoppiati (loosely coupled) ed intero<strong>per</strong>abili, i quali possono esserecombinati in sistemi più complessi.La chiave <strong>per</strong> raggiungere l’intero<strong>per</strong>abilità è nel disaccoppiamento, che consistenel ridurre le dipendenze ai minimi termini, in modo che gli effetti dimodifiche o imprevisti abbiano minore impatto negativo. Il disaccoppiamentocontribuisce alla tolleranza ai guasti e alla flessibilità, e grazie ad esso la progettazioneriesce ad evitare la presenza di colli di bottiglia che ostacolerebberola scalabilità.Tuttavia, ogni forma di disaccoppiamento porta con sé delle controindicazioni,<strong>per</strong>ciò questo tipo di scelte va effettuato soltanto in seguito ad un attentoesame <strong>dei</strong> rischi.118


Metodologia di progettazionePrincipi progettualiMolte definizioni di SOA comprendono il termine “web service”, ma in realtài due concetti sono autonomi; i web service sono un possibile modo di realizzaredelle infrastrutture e possono essere usati <strong>per</strong> creare delle SOA. Anche se i webservice stanno affermandosi, le SOA si possono implementare con molte altretecnologie (es. CORBA, WebSphere MQ e TIBCO).Richiami a ReSTPer motivi di prestazioni e di scalabilità, e <strong>per</strong> <strong>per</strong>mettere l’indirizzabilità el’astrazione delle risorse nei sistemi distribuiti e consigliato l’uso delle interfaccein stile REST (REpresentational State Transfer) [Fie00].REST è un modello astratto <strong>per</strong> sistemi software definito da un insieme divincoli, dedotti dall’architettura Web. Innanzi tutto, l’interazione tra i componentidi un’architettura in stile REST deve essere di tipo client-server; ognirichiesta da parte di un client deve contenere tutte le informazioni necessarieaffinché possa essere elaborata, e non può fare affidamento sullo stato internodel 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 delsistema abbattendo alcune interazioni.Ciò che principalmente distingue il REST da altre architetture basate sulnetworking è il vincolo di interfaccia uniforme tra componenti.Questo principio disaccoppia le implementazioni dalle funzionalità, semplificail sistema e migliora la visibilità delle interazioni, ma degrada l’efficienzapoiché le informazioni sono trasferite in una forma estesa e generale, invece chein una forma specificatamente progettata <strong>per</strong> i bisogni applicativi.Lo stile REST non prevede l’uso di particolari protocolli o standard e nonspecifica quali o<strong>per</strong>azioni deve offrire una interfaccia, purché sia uniforme eorientata alle risorse. In questo contesto, una risorsa è una qualsiasi informazionedotata di nome: può essere un documento, un’immagine o un oggettosoftware.Nell’approccio REST si usano degli identificatori <strong>per</strong> riconoscere le risorsecoinvolte nelle interazioni tra i componenti del sistema. La manipolazione dellerisorse da parte di questi ultimi deve avvenire tramite una rappresentazioneformata da una sequenza di byte più una sequenza di metadati che descrivonoquesti byte.Conciliare SOA e ReSTSOA e ReST sono apparentemente in contraddizione quando esplicitamenteimplementati con tecnologie Web in cui le risorse sono indirizzate tramite URIcome è stato evidenziato in [RR07]. Il punto di vista fonda una architetturaorientata alle risorse (Resource Oriented Architecture, ROA) in cui sono integratied applicati i due stili sopratutto da un punto di vista implementativo(capitolo 1.3).119


Metodologia di progettazionePrincipi progettuali4.2.4 Semplicità <strong>per</strong> il deploy: plug and playIl termine plug and play traducibile in termini tecnici in “inserisci ed usa”indica la possibilità di utilizzare un dispositivo non appena viene connesso alsistema. Anche se è nato riferendosi a <strong>per</strong>iferiche locali direttamente connessealla architettura del calcolatore, noi lo estendiamo al caso di sistemi di rete.Quindi ricerchiamo, <strong>per</strong> 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à.4.2.5 Decentralizzare la sicurezza: ente pubblico autorevoleLa sicurezza è affrontata livello <strong>per</strong> livello (parallelismo con i protocolli sicurie non-sicuri in Internet): HTTPS non è un protocollo a parte ma si occupadi combinare l’interazione del protocollo HTTP attraverso un meccanismodi crittografia di tipo Secure Sockets Layer (SSL) o Transport Layer Security(TLS).Il problema principale della sicurezza è che non è misurabile con uno strumentodi visualizzazione immediata. Sarebbe bello poter utilizzare un’unità dimisura che desse un valore numerico come risultato della verifica.E’ necessario quindi affrontare l’analisi della sicurezza aziendale e un eventualeprogetto con cautela e attenzione, evitando di farsi cogliere dal panico einstallare soluzioni dettate dall’isterismo o dalla preoccupazione di un momento.Affrontare un progetto di sicurezza significa valutare quale sia il livello dirischio che siamo disposti ad accettare, e se consideriamo che la <strong>per</strong>cezione dellasicurezza è soggettiva, non si può pensare a una soluzione o a un prodotto chesia valido <strong>per</strong> ogni tipo di problematica. La sola cosa che assume valore è laconoscenza approfondita delle problematiche che <strong>per</strong>mette di definire i modellidi riferimento, che possono essere poi realizzati con le soluzioni più idonee alcaso specifico.In molti casi non sarà possibile affrontare un discorso di ampio respiro chepossa colmare ogni lacuna, sarà quindi indispensabile stabilire delle prioritàd’intervento, procedendo <strong>per</strong> passi successivi.Il tema sella sicurezza deve essere affrontato lungo due direttrici principali etrasversali a qualsiasi tipo di metodologia progettuale adottata:• security: riferita, con un punto di vista strettamente tecnologico, agliapparati, ai dati ed alla comunicazione quali elementi centrici e materiali<strong>per</strong> la fornitura del servizio;120


Metodologia di progettazionePrincipi progettuali• safety: riferita alla salvaguardia fisica e morale delle <strong>per</strong>sone applicata alleidentità digitali ed al trattamento <strong>dei</strong> dati <strong>per</strong>sonali e sensibili.La sicurezza da un punto di vista tecnico va affrontata livello <strong>per</strong> livello. . .Osservazioni sulla gestione delle identitàNel Web ogni servizio, dal sito di commercio elettronico, all’instant messaging,ai forum, utilizza un proprio sistema <strong>per</strong> l’identificazione e l’autenticazionedegli utenti. Questa situazione è determinata dalla mancanza di una piattaformacomune, 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 adun sito web all’acquisto di un prodotto) è lasciata agli stessi attori, con evidentilacune nella sicurezza e nell’affidabilità. Chi viene maggiormente penalizzato inquesta situazione sono gli utenti: mentre i fornitori di servizi riescono a raggiungereil loro scopo, ovvero riconoscere gli utenti e determinare se hanno un gradodi affidabilità sufficiente a procedere alle transazioni richieste, gli utenti sonototalmente esposti: <strong>per</strong> ottenere il livello di sicurezza richiesto dal fornitore delservizio è necessario esporre tutti i dati <strong>per</strong>sonali che vengono richiesti, senzapoterne celare alcuno.Questo diventa più <strong>per</strong>icoloso se consideriamo che l’affidabilità di chi richie<strong>dei</strong> dati non è in alcun modo garantita dai sistemi utilizzati. La protezioneofferta agli utenti dal legislatore o dallo stesso sito, esposta nelle condizioni diutilizzo, è molto spesso troppo debole, come ben sappiamo. La prima controindicazione,ancora più evidente delle considerazioni precedenti, di un modello diidentificazione totalmente basato su credenziali specifiche <strong>per</strong> ogni servizio è ilproliferare di username e password, che costringe l’utente a dover memorizzareuna grossa mole di dati, creando un evidente problema di scomodità e, ancorpiù 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 algestore del servizio, sotto forma di un documento d’identità. Questo documentoè emesso da un’autorità, lo Stato, che garantisce l’affidabilità e la correttezza<strong>dei</strong> dati in esso contenuti (almeno pensando di essere in un mondo <strong>per</strong>fetto,in cui non esistano documenti contraffatti); <strong>per</strong> essere riconosciuti non è <strong>per</strong>ònecessario che il documento contenga tutta la conoscenza che lo Stato ha sudi noi: nel caso della biblioteca (e di moltissimi altri servizi) è solitamentesufficiente rivelare il proprio nome ed il proprio indirizzo, mentre non è necessariocomunicare altri dati, ad esempio il proprio reddito degli anni precedenti.L’intervento dello Stato nel procedimento di identificazione ed autenticazioneche ci <strong>per</strong>mette di avere la tessera della biblioteca è assolutamente indiretto:i soggetti coinvolti nell’o<strong>per</strong>azione di iscrizione sono solamente due, che si appoggianoin maniera asimmetrica ad un autorità terza, che non partecipa, edanzi spesso nemmeno viene a conoscenza dell’utilizzo delle credenziali da essaemesse. 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


Metodologia di progettazionePrincipi progettualidrasticamente diversa: continuando a ragionare sulla scorta dell’esempio appenariportato, è come se ogni sito emettesse un propria carta d’identità ad ogniutente, che sarà riconosciuta solamente da chi la ha rilasciata.Abbiamo già accennato alla proliferazione di identificativi utente e password,una grossa scomodità <strong>per</strong> gli utilizzatori, ma dobbiamo concentrarci su un ulteriorelivello <strong>per</strong> individuare il rischio maggiore: ogni servizio al quale ci iscriviamorichiede parecchi dati <strong>per</strong>sonali, senza che sia garantita l’affidabilità delgestore del servizio, e quindi la correttezza nel trattare i nostri dati. Questo ènecessario <strong>per</strong> poter identificare l’utente e poter assicurare l’affidabilità necessariaa portare a termine la transazione; ma in questo processo viene tutelatoil fornitore di servizi, mentre è evidente che l’utente è penalizzato, non potendoin alcun modo tutelare i propri dati e la propria affidabilità (sotto forma direputazione, solitamente considerata un attributo dell’identità stessa).La presenza di una autorità che certifichi l’identità degli utenti eliminerebbela necessità di rivelare alcuni <strong>dei</strong> nostri dati <strong>per</strong>sonali, aumentando allo stessotempo sicurezza e riservatezza. Ad esempio non sarebbe più necessario rivelareed autenticare (solitamente rispondendo ad una mail di conferma) il proprioindirizzo e-mail <strong>per</strong> accedere ad un servizio.Questa situazione ha fatto nascere l’idea di un sistema di identificazione a<strong>per</strong>toed affidabile <strong>per</strong> tutti gli utenti Internet. Un primo tentativo è stato fatto daMicrosoft nel 2001, con il nome di Passport: si trattava di un sistema <strong>per</strong> gestirel’autenticazione su più siti, avvalendosi di un protocollo comune. Applicazionidi questo tipo vengono dette SSO (Single Sign On), <strong>per</strong>ché l’autenticazione vieneeseguita una sola volta ed è poi valida su tutti i siti che utilizzano lo stessosistema. La proposta rispondeva ad una necessità effettiva degli utenti ed ilsistema era estremamente avanzato dal punto di vista tecnico, ma dopo quasicinque anni di agonia, la casa di Redmond ha annunciato la fine dell’es<strong>per</strong>ienza.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 a<strong>per</strong>to etotalmente affidabile. Passport, pur essendo <strong>per</strong> tanti motivi un sistema valido,prevedeva la gestione esclusiva da parte di una sola società del protocollo e ditutta l’infrastruttura di autenticazione: ovviamente questo non è tollerabile, edè all’origine del fallimento dell’iniziativa.Prima di ripartire dopo l’es<strong>per</strong>ienza di Passport ed incorrere in giustificateobiezioni, bisogna specificare che il tentativo di introdurre queste tecnologiedeve avere come unico obiettivo la protezione di tutti i soggetti, includendosotto questo nome sia gli utilizzatori che il fornitore di servizi. L’utente deveessere portato al centro e messo nella condizione di controllare totalmente lapropria identità in ogni transazione cui prende parte; la necessità di questolayer aggiuntivo è innegabile, <strong>per</strong> evitare in futuro l’ingigantirsi di problemi giàpresenti, sotto forma di phishing ed identity theft, tanto <strong>per</strong> fare un esempio.Proprio in questo momento di definizione delle tecnologie che saranno usate èimportante che tutte le parti coinvolte partecipino attivamente, <strong>per</strong> assicurare ilrispetto <strong>dei</strong> diritti di ognuno. Solo così si potrà scongiurare un utilizzo differentedi queste tecnologie, ad esempio <strong>per</strong> controllare meglio chi usa la Rete.Creando infatti un protocollo a<strong>per</strong>to ed affidabile, la necessità di diffondere inostri dati diminuirà, ma sarà lo stesso sistema a garantire la nostra affidabilità122


Metodologia di progettazionePrincipi progettualiai soggetti con cui veniamo in contatto.4.2.6 Abilitare lo sviluppo a<strong>per</strong>to: free softwareIl Software Libero è un software commerciale rilasciato con licenza libera,utilizzarlo significa compiere una scelta strategica che garantisce una innumerevoleserie di vantaggi, come poter disporre delle tecnologie che si impiegano,avere il pieno controllo <strong>dei</strong> propri mezzi di distribuzione e o<strong>per</strong>are in un mercatointrinsecamente a<strong>per</strong>to, in cui gli attori economici si muovono su un piano diparità privo di barriere di accesso, e la competizione si gioca sulla qualità dellavoro. Il Software Libero si configura come un bene pubblico, che ciascuno puòutilizzare e migliorare a beneficio di tutti.Come nasce il Software LiberoLa prima concettualizzazione del Software Libero risale ai primi anni ’80, e lodefinisce nei termini di un software la cui licenza soddisfa 4 libertà fondamentali:quelle di eseguirlo <strong>per</strong> qualsiasi scopo, di studiare come funziona adattandolo alleproprie necessità, di copiarlo e distribuirlo, e infine di migliorarlo, distribuendopubblicamente i <strong>per</strong>fezionamenti. Chi ne usufruisce può dunque approfittare diinnegabili vantaggi pratici legati alla scomparsa del costo delle licenze e dellaloro gestione, all’impossibilità che si verifichino politiche di lock-in[SV00] e chevengano imposti vincoli, e all’opportunità di investire in sviluppo e formazione.In particolare, è la libertà di copiare il software che <strong>per</strong>mette gli investimenti informazione e <strong>per</strong>sonalizzazione, eliminando il costo diretto delle licenze, e chegarantisce flessibilità nel numero di installazioni senza costi aggiuntivi in caso diespansione di un’attività; mentre è la libertà di modificare il software che <strong>per</strong>mette,a tutti coloro che sono dotati di competenze sufficienti, l’accesso al codicesorgente e la possibilità di adattamento (chi non è dotato di tali competenze hacomunque la possibilità di rivolgersi agli es<strong>per</strong>ti, svincolandosi dalla dipendenzadal produttore in relazione ad aggiornamenti, assistenza e <strong>per</strong>sonalizzazioni).Software Libero e Open SourceIl movimento del Software Libero e quello dell’Open Source hanno obiettivie mezzi comuni, ma differiscono sul piano filosofico. Preferiamo parlare di SoftwareLibero <strong>per</strong>chè la disponibilità <strong>dei</strong> sorgenti che sta alla base del concetto diOpen Source, senza le 4 libertà fondamentali e i vantaggi di tipo strategico chene conseguono, non è sufficiente a garantire il libero sviluppo di un software.Il concetto di Open Source sottolinea i vantaggi di natura tecnica, tendendo atralasciare gli aspetti etici e filosofici, legati alla libertà; al contrario, il concettodi Software Libero punta soprattutto ai vantaggi di tipo strategico e ponel’accento sull’aspetto filosofico e le libertà che tende a salvaguardare.Una scelta consapevoleUtilizzare 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 delle123


Metodologia di progettazionePrincipi progettualiinformazioni, la condivisione di idee e risultati e il libero utilizzo del patrimoniocomune delle conoscenze <strong>per</strong> un ulteriore sviluppo. Inoltre, favorisce l’indipendenzatecnologica, la diffusione del sa<strong>per</strong>e, l’abbassamento delle barriere diaccesso alla tecnologia, stimola la concorrenza e dà sostegno all’economia locale.Produrre e avvalersi di Software Libero è una scelta intelligente e responsabilesoprattutto nel caso delle amministrazioni pubbliche, che impiegano risorsepubbliche e devono quindi preferire l’utilizzo e lo sviluppo di un software cheresti a disposizione di tutti, garantendo la sua disponibilità, il suo riutilizzo, ela creazione di competenze, professionalità e valore sul territorio[CNI03a].Infine riteniamo che una amministrazione pubblica debba essere sempre ingrado di mostrare e dimostrare ai cittadini il modo in cui gli strumenti informaticie telematici adottati non violino il corretto trattamento <strong>dei</strong> pubblici,<strong>per</strong>sonali e sensibili [AIP02, Rep05, Smi08].Vantaggi tecnici, sociali ed economiciOltre ai vantaggi strategici relativi all’indipendenza tecnologica, il SoftwareLibero offre altre agevolazioni fondamentali. Dal punto di vista tecnico, <strong>per</strong>mettela verificabilità del software: diventa possibile, quando serve, verificare o farverificare il comportamento effettivo <strong>dei</strong> programmi, intervenendo direttamentesui problemi; inoltre, consente un’estrema facilità di sviluppo, dal momentoche ogni nuova implementazione può basarsi sulle modifiche precedenti[CNI03b].Dal punto di vista sociale, utilizzare Software Libero riveste un grande valoreculturale dovuto al carattere pubblico e alla condivisione <strong>dei</strong> risultati, e favoriscelo sviluppo professionale: basandosi su una economia <strong>dei</strong> servizi, incentivala crescita professionale e l’aumento delle competenze sul territorio[Ued05]. Dalpunto di vista economico, il Software Libero stimola la concorrenza e garantiscegrandi possibilità di sviluppo anche nelle realtà locali.Copyleft e licenza del Software LiberoIl software è un bene immateriale che può essere copiato a costo praticamentenullo e scambiato senza che la sua cessione comporti da parte di chi locede una diminuzione della capacità di fruirne. Il concetto di copyleft, <strong>per</strong>messod’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 <strong>per</strong>mette la privatizzazione di un bene, il copyleftlo mantiene libero, utilizza il copyright <strong>per</strong> trasformarlo da restrizione in garanziaassoluta di libertà, assicurando tutti i diritti agli utenti, riservandosi soloquelli necessari a mantenere tale garanzia. Soprattutto, il copyleft impedisce achiunque di impossessarsi di un bene facendolo esclusivamente proprio <strong>per</strong> poieventualmente negare ad altri la possibilità di accedervi. La licenza GPL (LicenzaPubblica Generica del progetto GNU) [Fou91] è alla base del Software Liberoe si fonda sull’idea di dare a chiunque il <strong>per</strong>messo di eseguire, copiare, modificaree distribuire <strong>nuove</strong> versioni, senza concedere la possibilità di aggiungererestrizioni.Un software rilasciato sotto GPL è libero, e tutti i software che da essoderivano saranno altrettanto liberi, <strong>per</strong>ché le libertà di cui è intriso il software124


Metodologia di progettazionePrincipi progettualisono garantite a chiunque ne abbia una copia: il <strong>per</strong>messo d’autore non sarebbeinfatti efficace se anche le versioni modificate del software di riferimento nonfossero libere.La situazione attualeOggi il Software Libero riscuote un crescente interesse da parte di enti pubblicie privati: si moltiplicano le iniziative <strong>per</strong> favorirne l’uso nella pubblicaamministrazione, ed è uno <strong>dei</strong> pochi settori in espansione del mercato informatico.Inoltre, <strong>per</strong> le sue caratteristiche intrinseche di riutilizzabilità, facilitàdi estensione, aderenza agli strandard e stabilità di funzionamento, il SoftwareLibero è il motore di gran parte <strong>dei</strong> servizi che si trovano su Internet, e l’uso inespansione del sistema o<strong>per</strong>ativo libero GNU/Linux ne è la dimostrazione piùevidente delle trasformazioni tecnico-sociali in atto.125


Capitolo5Modello del contestoPrima di progettare una infrastruttura di rete <strong>per</strong> la collaborazione tra utenti,è necessario individuare le entità in gioco nei processi collaborativi. I processicollaborativi nelle organizzazioni sono diversificati e caratterizzati da complessifattori sociali. Per il contesto collaborativo risulta quindi conveniente adottareun metodo top-down di analisi e sintesi, in modo da determinare una descrizionesufficientemente espressiva del contesto tale da essere codificabile nei sistemi dielaborazione.Il nostro ambiente collaborativo dovrà essere allo stesso tempo generale esemplice in modo da non precludere l’inserimento delle attività collaborativeal suo interno ed in modo da abilitare un efficace coinvolgimento dell’utenzainteressata.Nel presente capitolo e nei successivi con ambiente virtuale indicheremo ilmodello del contesto da un punto di vista tecnico-informatico. Un ambientevirtuale consentirà agli utenti di semplificare lo svolgimento delle loro attività.Tanto maggiore risulterà la corrispondenza fra l’ambiente virtuale e l’ambientereale quanto minore sarà la difficoltà degli utenti nel comprendere ed utilizzaregli strumenti di rete collaborativi. Fissando la prospettiva dell’utente si cercheràdi trasporre la <strong>per</strong>cezione del mondo reale circostante in termini di entità virtualie relazioni tra di esse.Molti paradigmi di interazione uomo-macchina riproducono in maniera schematicae semplificata l’ambiente fisico nelle modalità più familiari all’utente. Unesempio su larga scala è rappresentato dai Windows Manager <strong>dei</strong> Sistemi O<strong>per</strong>ativi(MS Windows GUI, Gnome, Kde, XFCE) che rappresentano a video ilparadigma del piano della scrivania, globalmente accettato come piano di lavoronelle attività di ufficio o in generale di lavoro.Sappiamo che le risorse sono elaborate nello spazio da uno o più utenti,


Modello del contestoModello dell’ambienteeventualmente organizzati in gruppo. Risulta quindi individuare nel contestoalmeno le seguenti entità:• <strong>per</strong>sona,• gruppo,• risorsa,• luogo.Dovranno essere codificati relazioni e paradigmi di interazione tra questeentità qualificando il contesto ed il tempo in cui si sviluppano i processi collaborativi.Se l’aspetto temporale dell’informazione coinvolge più propriamente il modellodi documento, i concetti di spazio e di <strong>per</strong>sone si possono posizionare su unpiano ortogonale indipendente dal modello stesso. Quindi se l’obiettivo primarioè di modellare l’informazione nella sua forma documentale le motivazioni <strong>per</strong> lavirtualizzazione dell’ambiente spingono ad inserire tali risorse in un contesto.Per gli obbiettivi espositivi della presente ricerca, molto spesso utilizzerò itermini risorsa, documento ed informazione come interscambiabili. L’analogiatra i termini sarà ulteriormente chiarita, da un punto di vista strettamentetecnico-implementativo, nei successivi capitoli in cui ogni tipo di risorsa saràistanziata e memorizzata all’interno di un documento.5.1 Modello dell’ambienteL’informazione è una risorsa che deve essere collocata lungo le dimensionidello spazio e del tempo. Risulta anche necessario individuare gruppi di <strong>per</strong>soneed i <strong>per</strong>messi che possono essere assegnati <strong>per</strong> generare, produrre, possedere,modificare, leggere e condividere l’informazione.Lo spazio ovvero il luogo in cui collocare una risorsa informativa è un aspettoesterno all’informazione, ma una importante proprietà associata che ne qualificail contesto. Virtualizzare lo spazio in cui risiede l’informazione-risorsa <strong>per</strong>mettecosì di delimitare il luogo in cui gli attori che vi agiscono possono incontrarsi edinteragire.Allo stesso modo in cui nella realtà fisica le <strong>per</strong>sone si incontrano o frequentanoun certo luogo (<strong>per</strong> varie finalità) qui si propone lo stesso paradigmaattraverso la rappresentazione di un ambiente che ne riproduca le principalicaratteristiche concettuali.Quando si svolge un’attività collaborativa si utilizzano strumenti, si produconorisultati e si scambiano informazioni. Gli strumenti, i risultati e le informazionipossono essere tutte considerate delle risorse a disposizione dell’utente.Per questo motivo nell’ambiente é stato definito un tipo di entità che pren<strong>dei</strong>l nome di Resource e rappresenta un generica risorsa a disposizione dell’utente.Quindi la Resource potrà rappresentare un documento, uno strumento, unoggetto o un dispositivo.Nell’ambiente reale, le risorse sono dislocate in luoghi diversi più o menoaccessibili. Per rappresentare questi luoghi è stata definita l’entità Location, la127


Modello del contestoModello dell’ambienteReal EnvironmentResource / EntitiesVirtualEnvironmentFigura 5.1: Rappresentazione dell’ambiente realequale può rappresentare ad esempio una stanza, un reparto, un’azienda, o tuttoquello che può contenere risorse.Inoltre sono stati definiti altri due tipi di entità che riguardano il modellosociale. La prima è Persona, ovvero la rappresentazione di un utente in quanto<strong>per</strong>sona. La seconda è il Group, cioè la rappresentazione di un gruppo di utentiche collaborano.Come è stato evidenziato in [SCFY96] il gruppo non è sufficientemente versatileed efficiente <strong>per</strong> la rappresentazione <strong>dei</strong> <strong>per</strong>messi di accesso. Per <strong>per</strong>mettereal sistema maggiore scalabilità si introduce il ruolo (Role) come insieme di regoleche determinano i <strong>per</strong>messi assumibile da un gruppo o da un utente. Il ruoloè generalmente indipendente dalle caratteristiche del gruppo e quasi semprecoinvolge solo gli aspetti funzionali delle risorse (diversamente dal concetto digruppo che riguarda aspetti organizzativo-gerarchici tra individui). Comunquepossiamo affermare che il ruolo rappresenta un generalizzazione del concetto digruppo.Nella tabella 5.1 è riportata la convenzione sui nomi utilizzati <strong>per</strong> indicarele entità con la corrispondenza tra rappresentazione fisica e modello.128


Modello del contestoLe entitàModello del contestoAmbiente fisicoLocationluogo, reparto, stanza, abitazioneResourceinformazione, documento, dispositivo, attuatore,sensoreGroupinsieme di <strong>per</strong>sone, associazione di <strong>per</strong>sonePersona utente, <strong>per</strong>sona fisica, <strong>per</strong>sona giuridica,sistema automatico, processoRoleinsieme di <strong>per</strong>messi, insieme di regolePermission<strong>per</strong>messi, politicheTabella 5.1: Corrispondenza ambiente modellato - ambiente fisico5.2 Le entitàL’ambiente è costituito da Location (virtuali) organizzati gerarchicamente.Ogni Location identifica un luogo virtuale al quale corrisponde in manierapluasibile un luogo reale (ad esempio un ufficio, un reparto, una stanza, etc.).Ciascuna Location è indirettamente abitata dagli utenti. La proiezione dell’utentenella Location è indicata col nome Persona: un’entità capace di esporreun sottoinsieme delle proprietà e caratteristiche dell’utente. All’ingresso di unutente 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à lavorativedeterminabili sulla base di regole intrinseche, ad esempio applicate agli attributidel profilo degli utenti (es. il gruppo maggiorenni è costituito dalle <strong>per</strong>sonecon età su<strong>per</strong>iore a 18 anni).Persona e Group agiscono sulle risorse sulla base del Role ovvero del ruoloposseduto. Il Role identifica un insieme di <strong>per</strong>messi espressi con una serie diregole che tengono conto anche della natura delle Resource e delle Location.All’interno di una Location le Persona interagiscono attraverso la condivisionedelle risorse (Resource) qui localizzate nel rispetto <strong>dei</strong> Role e <strong>dei</strong> Groupcui appartengono. Le Resource sono la codifica di informazioni, dispositivi, attuatori,capaci di racchiudere dati e di esporre una serie di servizi. In generalepossono essere sia entità statiche che dinamiche, dotate di un comportamentolegato non solo ai servizi, inerenti all’informazione che rappresentano, ma ancheal proprio ciclo di vita. Sono quindi entità attive.5.2.1 PersonaL’Persona è l’entità logica che rappresenta l’utente nell’ambiente. Ad ogniutente possono essere associati più Persona ciascuno <strong>dei</strong> quali esprime un profiloin un contesto. In sostanza una Persona è una rappresentazione dell’utente,capace di effettuare o subire o<strong>per</strong>azioni nella Location <strong>per</strong> conto del suo titolare.In generale il compito della Persona è di rappresentare l’utente.Tutte le varie prospettive e sfaccettature, costituite dall’insieme delle Personarelative alla stessa identità fisica, determinano il vero utente-<strong>per</strong>sona nella suaglobalità. Ogni Persona quindi esprime condizioni necessarie alla sua identifica-129


Modello del contestoLe entitàzione in un particolare Location o <strong>per</strong> l’appartenenza ad un Group. Dualmentel’unione di tutte le Persona relative alla stessa identità (<strong>per</strong>sona reale) <strong>per</strong>mettedi ricostruire l’utente nella sua totalità e complessità. In questo modo si tendea soddisfare sia le condizioni dettate dalle legislazioni sulla privacy sul al trattamento<strong>dei</strong> dati, sia il diritto dell’utente a rendere noti <strong>dei</strong> frammenti dellapropria 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 diversoda diversi gruppi di <strong>per</strong>sone e dal sistema sociale in cui si inserisce. Infatticiò accade anche quando lo stesso individuo fornisce parziali informazioni sullapropria identità ed interagisce in modo diverso con gli altri, in relazione alcontesto. Ad esempio il profilo esposto da una <strong>per</strong>sona in ambito lavorativosolitamente non è equivalente a quello in ambito familiare o comunque privato.Notiamo inoltre che l’uso di più identità non è una novità negli applicativi direte (es. chat e forum), dove il nome reale viene quasi sempre sostituito con unnickname o un alias.È opportuno osservare che la gestione contemporanea di più Persona e quindidi più o<strong>per</strong>azioni sarà possibile solamente se l’utente potrà agire contemporaneamentetramite Persona diverse.Un requisito la cui rilevanza varia in base al contesto, ma che in ogni caso èimportante soddisfare, è certificare l’associazione fra una <strong>per</strong>sona e relativa Persona,dato che sarà proprio la Persona ad avviare, direttamente o indirettamente,i procedimenti e quindi agire <strong>per</strong> conto del titolare.5.2.2 GroupI Group sono associazioni di utenti accomunati da identici obiettivi o similiprofili. Rappresentano una comunità collaborativa o uno status sociale e<strong>per</strong>mettono di agire sulle risorse condivise in modo unitario.Una Persona, a cui è concessa l’iscrizione ad un gruppo, acquisisce i diritti ei doveri del gruppo. Attraverso la transitività <strong>dei</strong> <strong>per</strong>messi, le Persona ereditanole caratteristiche comuni al gruppo.I Group sono organizzati gerarchicamente ed ordinati secondo una relazionedi contenimento. È possibile rappresentare graficamente la struttura con unalbero, in cui i <strong>per</strong>messi associati ai vari nodi (Group) crescono al crescere dellaprofondità di penetrazione.I <strong>per</strong>messi <strong>dei</strong> sottogruppi (gruppi figlio) sono almeno gli stessi di quelli delgruppo che li contiene (gruppo padre). Una Persona iscritta ad un gruppo haalmeno tutti i <strong>per</strong>messi di quel gruppo. Ovviamente una Persona iscritta ad ungruppo figlio risulta iscritto anche al gruppo padre.All’espulsione o alla cancellazione di una Persona da un gruppo generalmentecorrisponde una diminuzione <strong>dei</strong> privilegi e <strong>per</strong>messi.Visivamente l’iscrizione e la cancellazione di una Persona <strong>per</strong> un gruppocorrispondono a navigazioni indirette dell’albero: si può pensare a queste dueo<strong>per</strong>azioni 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 numero130


Modello del contestoLe entitàmassimo <strong>dei</strong> suoi affiliati o politiche spazio-temporali sull’ingresso e l’uscita (es.sull’età o sugli interessi).5.2.3 RoleUn ruolo Role è un insieme di <strong>per</strong>messi che esprime varie azioni possibilisulle risorse. L’utilizzo del concetto di ruolo piuttosto che di gruppo ha lo scopodi facilitare il trasferimento di compiti e responsabilità da un individuo ad unaltro, 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 aspettativee comportamenti attesi riguardanti un individuo che occupa una determinataposizione sociale (status). Il ruolo, ossia l’insieme di aspettative, è sempre unprodotto sociale, è l’esito della cristallizzazione delle norme e <strong>dei</strong> valori sociali chedefiniscono le modalità e i contenuti comportamentali di una specifica posizionesociale. Norme che possono essere sia esplicite (codici giuridici o deontologici)sia implicite (regole di un gruppo di pari, etichetta etc.).L’insieme <strong>dei</strong> ruoli complementari di una data istituzione o contesto è chiamatorole set (es. dottore-infermiere-paziente): il concetto di ruolo è intrinsecamenterelazionale e implica che le aspettative rivolte ad uno staus siano differentiin relazione all’attore sociale che concretamente le rivolge.Importando questi concetti in ambito tecnico sulla base di quanto evidenziatoin [SCFY96] possiamo affermare che il ruolo riveste una componente fondamentale<strong>per</strong> l’espressività delle entità in gioco nelle attività collaborative e e la cuiesistenza è condizione necessaria <strong>per</strong> la scalabilità, l’adattabilità e la versatilitàdella rappresentazione <strong>dei</strong> <strong>per</strong>messi di accesso alle risorse.Le Role sono in relazione con i <strong>per</strong>messi (Permission) ed allo stesso tempocon le Persona. Mentre i <strong>per</strong>messi sono in relazione con le Resource comeesemplificato in figura 5.2.Role vs GroupL’introduzione <strong>dei</strong> Ruoli [SCFY96] <strong>per</strong>mette una separazione completa trale caratteristiche possedute da un soggetto ed il soggetto stesso. Questa separazione<strong>per</strong>ò può rendere più laborioso identificare o<strong>per</strong>ativamente tutte le regole<strong>per</strong> un determinato contesto. “Capacità”, “funzione”, “posizione”, “mansione”in una organizzazione sono alcuni sostantivi che possono essere utilizzati <strong>per</strong>individuare e delineare i ruoli.I gruppi quindi continuano ad essere un modo conveniente di aggregare gliutenti: infatti sono largamente usati <strong>per</strong> organizzare gli utenti nei processi egestire i <strong>per</strong>messi. Se i gruppi sono organizzati gerarchicamente e se è possibilestabilire se un gruppo è sottoinsieme di un altro allora è possibile beneficiaredella ereditarietà <strong>dei</strong> <strong>per</strong>messi e di attributi dal gruppo “padre” verso il gruppo“figlio”.In maniera informale il ruolo può essere visto come un tipo speciale di gruppoin quanto i ruoli forniscono una metodologia schematica e formale <strong>per</strong> raggrupparei <strong>per</strong>messi su un soggetto. Dualmente un gruppo può essere visto come unruolo con minori capacità di adattamento, versatilità e dinamicità.131


Modello del contestoLe entitàPermessoabilitaaccesso suPermessohaassociatounRisorsaRuoloha unPersonaFigura 5.2: Role Based Access Control Model5.2.4 PermissionUn Permission è l’approvazione di un particolare modalità di accesso ad una opiù risorse nel sistema. In letteratura i termini autorizzazione, diritti di accessoe privilegi sono usati come sinonimi di <strong>per</strong>messo[SCFY96]. I <strong>per</strong>messi sonosempre espressi in forma positiva e quando vengono assegnati conferiscono lafacoltà di eseguire una certa azione nel sistema (risorsa). L’approccio è analogoa white-list: se non è dichiarato il <strong>per</strong>messo l’accesso è negato. Permissionpossono essere applicati su una sola Resource o su un insieme di Resource.5.2.5 LocationL’entità Location è la rappresentazione di un luogo reale. Una Location puòcontenere altre Location, in modo simile al caso <strong>dei</strong> Group, e delle Resource.Ciò <strong>per</strong>mette di creare una gerarchia di contesti collaborativi in cui i Personasi incontrano e partecipano in attività sincrone o asincrone, inter-<strong>per</strong>sonali oprivate. La Location di più alto livello, che contiene tutte le Location, pren<strong>dei</strong>l nome di Universe.Le Persona possono utilizzare questa struttura sia <strong>per</strong> rappresentare luo-132


Modello del contestoLa generalizzazione in entitàghi reali, sia luoghi convenzionali di ritrovo, intesi come spazi di giunzione traLocation. Persona, appartenenti a Location distinti, potrebbero avere comunifinalità progettuali <strong>per</strong> le quali è indicata la creazione di un nuovo spazio logicodi incontro. L’organizzazione degli spazi avviene <strong>per</strong> convenienza negli interessidi 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, comead esempio orari di accesso e numero massimo di Persona contemporaneamentepresenti.5.2.6 ResourceResource è un aggregato di informazioni (documenti) e comportamenti (regole)dotato di un nome con il quale viene individuato. Può essere raggiungibile esi può o<strong>per</strong>are 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 esempiodispositivi, sensori, attuatori, documenti o porzioni di essi.Una Resource espone un insieme di o<strong>per</strong>azioni ed ha un comportamento cheè definito da eventi (esterni o interni) e dallo stato che di volta in volta vieneassunto.La raccolta, l’elaborazione e la presentazione delle informazioni sono i principalicompiti di alto livello che una Resource deve assolvere. Le Resource nonsono solamente oggetto di un insieme di azioni, ma sono anche soggetto di azioniverso Persona. Internamente all’ambiente hanno la facoltà, quando necessario,di avviare in modo autonomo l’interazione con le Persona, senza che da partedell’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 diidentità che dopo essere creato, può essere modificato solo attraverso una proceduradi 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’interfacciaespone le funzionalità che la Resource internamente provvede ad eseguire.In un’ottica Object Oriented l’istanza di una Resource è assimilabile ad unoggetto.La Resource è <strong>per</strong> definizione un’entità creata dalla collaborazione di Persona,soggetta ad o<strong>per</strong>azioni da parte di coloro che ne detengono i diritti (Role)ed è il risultato della elaborazione di informazioni (<strong>nuove</strong> o già esistenti). Nelcaso limite è creata da una sola <strong>per</strong>sona.5.3 La generalizzazione in entitàNelle precedenti sezioni sono state illustrate le principali entità, che desideriamotrattare nel sistema, identificate in modo tale da arginare la complessitàdell’ambiente reale senza volerne ridurre l’espressività. Con il termine entità si133


Modello del contestoIl 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 risorsagenerica, ricorrendo al concetto di polimorfismo. La rappresentazione di una Resourceavviene attraverso un documento (Document) che la descrive: in figura5.3 è riportato il diagramma UML che mette in relazione le entità dichiarate.ResourceDocumentGroupLocationPersona Role PermissionFigura 5.3: Classificazione delle entitàQuesta generalizzazione <strong>per</strong>metterà sfruttare e ripensare l’architettura <strong>per</strong>l’implementazione di ogni componente informativa nel sistema. Un primo esempiodel vantaggio verrà chiarito nella sezione 5.4 nella quale verrà illustrato comeavvengono le interazioni.5.4 Il modello delle interazioniAll’interno dell’ambiente virtuale l’interazione tra Persona viene filtrata dalleResource. Le Resource costituiscono i catalizzatori e gli arbitri delle attivitàcollaborative, in quanto oggetto e soggetto di elaborazione. Mentre Locatione Group assolvono i compiti di strutturare rispettivamente lo spazio, e le gliutenti, Le Resource rappresentano il mezzo attraverso cui veicolare e controllarel’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 affermail principio che le interazioni tra entità non avvengono mai direttamente, masono sempre mediate da una terza Entity.In figura 5.4 è indicato il modello delle interazioni tra Persona. Si distinguonoquattro tipologie di interazione:• uno a uno: l’informazione è generata da un Persona che lavora autonomamenteed è indirizzata o destinata ad un altro Persona;• uno a molti: l’informazione è generata da un Persona che lavora autonomamenteed è indirizzata o destinata ad un Group, a cui può eventualmenteappartenere;134


Modello del contestoIl modello delle interazioni• molti a uno: l’informazione è generata da un Group in cui delle Personalavorano in collaborazione ed è destinata ad una certa Persona;• molti a molti: l’informazione è generata da un Group in cui i vari Personalavorano in collaborazione ed è destinata ad un altro Group, cheeventualmente può contenere il primo o esserne un sottoinsieme.Virtual EnvironmentLocationResourceunicasto<strong>per</strong>ationConsumerPersonaProducerPersonaLocationResourcemulticasto<strong>per</strong>ationTargetGroupProducerPersonaLocationResourceunicasto<strong>per</strong>ationConsumerPersonaProducerGroupLocationResourcemulticasto<strong>per</strong>ationTargetGroupProducerGroupFigura 5.4: Il modello di interazioneL’attività di una Persona è costituita da una sequenza di o<strong>per</strong>azioni finalizzatea coinvolgere un solo utente o un intero gruppo. Il compito di identificarei destinatari, e quindi avviare la diffusione delle informazioni, non è totalmente135


Modello del contestoIl modello delle interazioniaffidato al produttore. Anche la Resource può avere un ruolo attivo. È benericordare che Persona e Resource sono entità dello stesso livello.Leggendo singolarmente i quattro casi di figura 5.4, da destra verso sinistra, siidentificano due fasi: nella prima fase la risorsa subisce l’iniziativa della Persona(o del Group) e nella seconda è prevista la consegna <strong>dei</strong> risultati elaborati aidestinatari.È facile osservare che esiste un disaccoppiamento delle Persona <strong>per</strong> mezzodelle Resource. La fase di produzione è quella più delicata in quanto coinvolge, abasso livello, o<strong>per</strong>azioni di scrittura, in generale concorrenti, <strong>per</strong>ciò è auspicabileche tra i Persona produttori e le Resource si realizzi un forte accoppiamento esincronismo. Ciò non è necessario nella fase di consumo in quanto coinvolgele sole o<strong>per</strong>azioni di lettura (non distruttive). Il vantaggio consiste da unaparte nell’aver separato le fasi critiche da quelle non critiche e dall’altra nelconsentire un’interazione asincrona tra produttore e consumatore nelle attivitàcollaborative.Per garantire awareness introduciamo nel sistema <strong>dei</strong> meccanismi di notificadi stato assunto dalle Resource, il quale può essere utilizzato <strong>per</strong> recu<strong>per</strong>are,quando necessario nelle attività collaborative, lo svantaggio dell’assenzadi sincronismo (a meno <strong>dei</strong> tempi di latenza). La notifica può essere comunicataprontamente 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 <strong>per</strong>iodoe la scala <strong>dei</strong> tempi con cui il produttore accede alla risorsa. L’architetturadeve consentire sia attività <strong>per</strong>iodiche che a<strong>per</strong>iodiche, sia dal lato consumatoreche produttore.136


Parte III<strong>InterDataNet</strong>:progettazione


Capitolo6L’architettura <strong>InterDataNet</strong>IDN è una architettura <strong>per</strong> l’integrazione delle risorse e delle informazionicon l’obiettivo di sviluppare una infrastruttura <strong>per</strong> la coo<strong>per</strong>azione applicativatra organizzazioni eterogenee e distribuite in grado di abilitare la collaborazionetra utenti, logo in figura 6.1.Figura 6.1: Logo del progetto IDNRisulta vantaggioso introdurre <strong>dei</strong> livelli di servizi che siano capaci di astrarrela memorizzazione, l’elaborazione e la comunicazione dell’informazione a livellopiù basso, consentendo di abbattere ed eventualmente eliminare la complessità<strong>dei</strong> processi a livello applicativo, e lasciando maggiore spazio <strong>per</strong> la realizzazionedi applicazioni a valore aggiunto.Come suggerito in [Val01, EM04, WN01] verranno adottate viste multiple delproblema generale, al fine di separare comportamenti e funzionalità, formularevincoli, requisiti e soluzioni.IDN è logicamente e fisicamente descritto tramite tre viste complementaried integrate:1. vista sulle risorse e sull’informazione,


L’architettura <strong>InterDataNet</strong>IDN Information Model2. vista sulla architettura <strong>dei</strong> servizi,3. vista sulla infrastruttura di rete.Ciascuna vista pone l’attenzione su aspetti critici del problema, muovendo dallarappresentazione astratta del contesto, delle informazioni e delle esigenze, scendendogradualmente 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 InformationModel (IDN-IM). Un modello dell’informazione [PS03, CT04, HS90] cheintende rappresentare ogni tipo di informazione (strutturata), recependo i principidi 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. Rappresentaquindi l’informazione indipendentemente dalla tecnologia in maniera altamentestrutturata, abilitando la collaborazione.IDN Service Architecture. La seconda vista prende il nome di IDN ServiceArchitecture (IDN-SA). Definisce in maniera stratificata i servizi necessari <strong>per</strong>soddisfare il modello informativo IDN-IM, recependo i principi SOA [Jos07] eREST [Fie00]. Implementa le funzionalità definendo, sottosistemi, protocolli edinterfacce <strong>per</strong> una gestione collaborativa del documento. IDN-SA espone unaIDN-API (Application Programming Interface) <strong>per</strong> 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 direte sopra Internet in analogia alle reti Overlay Network. Gli apparati sonocollocabili in seno alla infrastruttura di rete delle organizzazioni che desideranoattuare una politica collaborativa e di coo<strong>per</strong>azione applicativa, mantenendola responsabilità solo su propri apparati. Permette di attuare politiche diseparazione della responsabilità.Nel presente capitolo verrà esposta la trattazione teorica e panoramica delletre viste sopra sintetizzate. I dettagli progettuali ed implementativi sarannoaffrontati nei capitoli successivi ed in particolare nella parte quarta di questatesi.6.1 IDN Information ModelL’intento di IDN-IM è quello di mettere in discussione il concetto tradizionaledi documento generalmente considerato come monolitico e non strutturato,limitando le possibilità di soddisfare i requisiti di qualità del dato elettronico ela reale distribuzione dell’informazione.L’entità da gestire nell’ambiente IDN è un documento multimediale. Risultacomposto in generale da contenuti, relazioni (implicite o esplicite tra i contenuti)e metadati.139


L’architettura <strong>InterDataNet</strong>IDN Information ModelIn IDN il documento viene modellato come un aggregato di informazionielementari; la struttura e il contenuto sono completamente separati dalla presentazione,che può anche non essere presente. Ciascun elemento informativoviene isolato rispetto agli altri secondo un principio gerarchico che si basasull’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 chedetiene l’informazione: <strong>per</strong> i dati anagrafici del titolare si risale al Comune,<strong>per</strong> i dati relativi alla scadenza si risale alla Motorizzazione, e così via. Ilprocedimento tende quindi a strutturare rigidamente il documento, seguendosemplicemente 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 distingueregli enti che trattano le singole informazioni, costituendo in modo naturale unsistema distribuito dal punto di vista del documento considerato. La dinamicitàe la flessibilità sono ottenute grazie all’elevato grado di autonomia delle singolesorgenti che, in modo collaborativo ed indiretto, partecipano alla costruzionedi 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 comportamentoin dipendenza allo stato assunto ed alle relazioni espresse. Tornando all’esempiodella patente, se i punti vengono azzerati come effetto di una serie di contravvenzioni,il documento <strong>per</strong>de di validità e possono venire automaticamentenotificati degli avvisi ad una serie di soggetti.6.1.1 Cosa è un Information ModelSi definisce Information Model una rappresentazione universale delle entitàe delle loro proprietà, o<strong>per</strong>azioni e relazioni, il cui scopo principale è quello dimodellare gli oggetti ad un livello concettuale, indipendentemente da qualsiasispecifico repository, applicazione, protocollo o piattaforma. Esso non riguarda idettagli, 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 astrazionepiù basso, e comprende dettagli specifici dell’implementazione e del protocollo,ad esempio regole che spieghino come mappare gli oggetti gestiti sucostrutti protocollari di livello più basso [PS03].Il principale vantaggio nell’uso di un Information Model è la possibilità digenerare, a partire da esso, più Data Model, intesi come i modelli concretamenterealizzati. Questa capacità <strong>per</strong>mette la scalabilità e l’adattabilità del modelloin contesti diversi.Un’ulteriore conseguenza è la possibilità di scegliere, <strong>per</strong> la realizzazione, trauna vasta gamma di standard e tecnologie esistenti, se rispondenti alle esigenze.D’altra parte, questa prospettiva rappresenta anche una forte restrizione, inquanto la sottile linea che divide il modello astratto dai relativi modelli concretinon è sempre di facile identificazione.IDN-IM è dunque una rappresentazione omogenea, astratta e consistente140


L’architettura <strong>InterDataNet</strong>IDN Information Modeldell’informazione, che ne cattura i requisiti, i principi e le proprietà desiderabiliin 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 caratteristichenative e globali; di conseguenza, è altamente strutturata ed è dotata di informazioniausiliarie, ossia i metadati, <strong>per</strong> abilitare la gestione dell’informazionedistribuita in un ambiente di rete collaborativo [PCPP07b].Tale modello di riferimento è stato derivato tenendo conto delle funzioninecessarie <strong>per</strong> i sistemi di gestione di documenti, come la creazione, la revisione,la pubblicazione, l’accesso e l’archiviazione, oltre alle funzioni telematiche <strong>per</strong> ilsupporto allo scambio e alla collaborazione.Lo scopo primario di un modello dell’informazione (Information model, IM )è delineare le entità informative a livello concettuale, indipendentemente daspecifiche implementazioni o dai protocolli utilizzati <strong>per</strong> trasportare i dati. UnIM deve celare tutti i dettagli implementativi e di comunicazione al fine direndere la progettazione la più chiara possibile. L’altro importante compito diIM è modellare le relazioni tra le entità attraverso un linguaggio naturale o unlinguaggio formale oppure con un linguaggio strutturato semi formale [PS03].Viceversa i modelli <strong>per</strong> i dati (Data Model, DM ) sono definiti ad un livellopiù concreto ed includono molti dettagli con specifici costrutti. La principaleconseguenza è che lo stesso IM può dare vita a più DM. In pratica <strong>per</strong>ò non èsempre possibile distinguere univocamente un DM dal suo IM. Esiste una “zonagrigia”, dove IM e DM si sovrappongono parzialmente. In molti casi è veramentedifficile 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 <strong>per</strong>metterne l’utilizzoin vari contestiL’elaborabilità di un documento assume particolare rilievo quando esso vienerappresentato all’interno di un calcolatore ed utilizzato come entità da trasmettere.Parafrasando Rein, McCue, Slein e Buckland [Buc97, RMS97], unadefinizione estesa e utile <strong>per</strong> gli argomenti trattati, è la seguente: un documentoè la testimonianza di una evidenza fisica o intellettuale, memorizzata e strutturatain 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’unicaentità (raggruppate all’interno di un documento) il contenuto informativodella somma è maggiore della somma delle singole informazioni. Si evidenziacome l’informazione aggiuntiva sia data da correlazioni presenti fra levarie informazioni e <strong>per</strong>metta di caratterizzare il documento come un’entitàstrutturata.Nel caso in cui questo aspetto sia trascurabile si parla di informazione nonstrutturata che comunque può essere vista come un caso particolare di quellastrutturata.Data l’importanza della tracciabilità (vedi sezione 3.1.1) delle modifiche neicontesti nei quali è previsto che il modello proposto venga applicato, la gestionedell’evoluzione temporale delle informazioni (versioning) è integrata nel modelloin modo nativo.141


L’architettura <strong>InterDataNet</strong>IDN Information ModelPer rispondere a queste esigenze il modello di documento in esame, IDN(<strong>InterDataNet</strong> Information Model), è stato dotato delle seguenti caratteristiche:• deve avere una struttura a DAG nella quale siano ben distinguibili e definiticome entità individuali i nodi che la costituiscono;• devono esistere le seguenti tipologie di relazione fra nodi: link di riferimentoe link di composizione; In questo modo il concetto di composizione èun caso particolare di quello di aggregazione, similmente alla terminologiautilizzata in UML [RJB99].Ulteriori dettagli ed approfondimenti saranno discussi nella parte tecnica.6.1.2 Elementi strutturabiliAll’interno <strong>dei</strong> documenti con i quali si interagisce possono essere individuatealcune categorie di informazioni che possono essere evidenziate analizzando ildocumento. Tali categorie risultano le seguenti:• contenuti: elementi esplicitamente fruibili dall’uomo e che sono direttamenteindividuabili all’interno del documento. Rientrano in questa categoriai 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 unapagina o paragrafo di un libro, ad un articolo presente in una legge, eccetera.Dualmente un legame implicito può essere quello esistente fra iltitolo di un capitolo di un libro e il contenuto del capitolo stesso;• informazioni aggiuntive: ulteriori informazioni associate al documento e/oche possono essere date <strong>per</strong> scontate. Ad esempio l’autore di un branomusicale oppure il fatto che i contenuti presenti nella prima pagina diun quotidiano rappresentano un sunto delle notizie più importanti delgiornale;• presentazione: informazioni necessarie <strong>per</strong> mostrare correttamente il documentoall’utente. Rientra a pieno titolo in questa categoria l’aspetto grafico,ovvero la scelta <strong>dei</strong> caratteri, <strong>dei</strong> colori, dell’impaginazione, eccetera.Questa categoria di informazioni fornisce un valore aggiunto che in particolaricasi è determinante <strong>per</strong> <strong>per</strong>mettere la fruibilità delle informazionicontenute nel documento.Queste categorie di informazioni sono state introdotte parlando di documentoin senso astratto e/o nel senso convenzionale del termine. Nel momento in cuisi intende codificare un documento <strong>per</strong> renderlo trattabile dalle macchine occorreformalizzare al meglio questi concetti al fine di poterli gestire efficacementeed efficientemente da un punto di vista informatico.A tale scopo si può ricorrere ad opportuni linguaggi di marcatura che <strong>per</strong>mettonodi contrassegnare e quindi valorizzare i vari elementi contenuti nel142


L’architettura <strong>InterDataNet</strong>IDN Information Modeldocumento. In questo modo si riescono a codificare tutte le categorie di informazionie in particolare a rappresentare, esplicitamente o implicitamente, lerelazioni.All’interno <strong>dei</strong> documenti HTML, i link i<strong>per</strong>testuali rappresentano delle relazioniesplicite: il link è presente ed individuabile nel documento. Viceversa lamodalità 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 unarelazione fra titolo e contenuto del capitolo esplicitamente individuabile all’internodel documento, ma tale marcatura <strong>per</strong>mette di separare le due entità econsiderarle, se necessario, come correlate.Da un punto di vista informatico i documenti dotati di queste caratteristichee codificati opportunamente vengono chiamati documenti strutturati.I vantaggi riscontrati trattando documenti strutturati sono molteplici inquanto gli aspetti strutturali, oltre a fornire un contenuto informativo addizionalerispetto al caso non strutturato, <strong>per</strong>mettono di garantire anche un maggiorcontrollo <strong>dei</strong> contenuti.Inoltre tramite il riferimento ad altre informazioni è possibile realizzare varidocumenti che, contenendo riferimenti alle medesime informazioni, di fattodeterminano una rete di concettiLe macchine, in questo modo, diventano sistemi in grado di elaborare ilcontenuto informativo <strong>dei</strong> documenti e ciò <strong>per</strong>mette di sfruttarne agevolmentele potenzialità in termini di velocità, memorizzazione e comunicazione <strong>per</strong>supportare efficientemente l’uomo.Quindi il lavoro dell’uomo risulta agevolato in quanto può essere velocizzatoe facilitato nell’immissione, nella ricerca, nella consultazione delle informazioni.6.1.3 Strutturare con il principio di responsabilitàFornire delle regole non ambigue <strong>per</strong> strutturare documenti risulta un compitoarduo. Allo stato attuale, molto interesse è rivolto a tecniche complesselegate a teorie semantiche ed ontologiche. Le discussioni nel panorama scientificointernazionale ed i progetti attorno al Semantic Web dimostrano come lasemantica non sia ancora in grado di garantire una efficace integrazione dell’informazionee una conseguente efficace collaborazione <strong>per</strong> gli attori coinvolti. Sievidenzia la necessità di condividere dati e quindi il problema risulta ancoraa<strong>per</strong>to e lontano da una soluzione applicabile su larga scala.Sulla base di questo dato di fatto qui proponiamo un approccio diverso <strong>per</strong>la creazione di informazioni sufficientemente granulari da possedere le seguentiqualità (vedi sezione 3.2.2):• modulari: aggregabili in maniera versatile con altre;• indirizzabili: identificabili sia logicamente che <strong>per</strong> indice;• semplificate: grazie alla marcatura di metadati standardizzati;• riusabili: <strong>per</strong> la loro autonomia in diverse situazioni;• intero<strong>per</strong>abili: indipendenti dal contesto.143


L’architettura <strong>InterDataNet</strong>IDN Information ModelTenendo presente le esigenze della collaborazione, in pratica proponiamodi applicare come regola strutturante il principio di responsabilità sulle partiinformative che costituiscono l’informazione. Principio che apre la strada allaelaborabilità in autonomia delle singole parti di cui è costituito il documento.Il responsabile è colui il quale ha la consapevolezza di dover rispondere deglieffetti che possono scaturire a seguito della divulgazione dell’informazione. Ilresponsabile può essere una <strong>per</strong>sona fisica oppure giuridica che crea o modifical’informazione. Osserviamo che questa metodologia assume un valore estremamentedeterminante quando viene coinvolto il trattamento di informazionisensibili ed in generale da in punto di vista giuridico.Il contesto è quello di una organizzazione. Analizziamo una informazionecreata dalla collaborazione di più <strong>per</strong>sone. Da un punto di vista organizzativociascuna <strong>per</strong>sona avrà contribuito agendo su una parte e lasciando alle altre ilcompito di integrarla o di validare l’unione. L’organigramma aziendale, i ruolied il ciclo di vita dell’informazione sono gli elementi che stabiliscono in manieranon ambigua chi è responsabile di cosa. Ciascuno deve essere abilitato ad agiresulle parti di sua competenza.Strutturare con il principio di responsabilità non presuppone la reingegnerizzazione<strong>dei</strong> processi, ma è evidente che se i processi fossero ben ingegnerizzatiallora l’applicazione del principio trova maggiore beneficio.Se isoliamo le parti più elementari, assicurandoci la loro riusabilità ed indirizzabilità,è possibile sfruttarle come building-block <strong>per</strong> la costruzione di nuovainformazione riarrangiando, integrando e ricomponendo gli elementi disponibili.Prendiamo ad esempio un articolo: l’autore è responsabile di ciò che vi hascritto. Il direttore è responsabile della aggregazione ragionata di più articoli. Seil singolo articolo gode delle proprietà sopra esposte potrebbe essere ado<strong>per</strong>atoda un altro direttore <strong>per</strong> la creazione di una pubblicazione diversa da quella <strong>per</strong>cui originariamente era stato concepito.Nel settore della Pubblica Amministrazione o comunque in tutti quei settoriin cui esiste un elevato numero di elementi informativi ricorrenti e trasversalipossiamo attuare una forte politica del riuso e la creazione di documenti inmaniera dinamica, aumentando la qualità del dato. Il significato del singoloelemento dovrà essere comunque stabilito su larga scala, ma stavolta in aiutointervengono normative e direttive aziendali che lasciano poco spazio allainterpretazione.Strutturare con questa tecnica significa agire su un piano trasversale ai contenutisemantici del documento, che ignoriamo a livello infrastrutturale. Sularga scala consente di realizzare in maniera automatizzata un insieme di mattoniinformativi elementari che possono essere riutilizzati dalla comunità <strong>per</strong>costruire nuova informazione.Il principio di responsabilità può anche essere inteso come conseguenza naturale<strong>dei</strong> processi organizzativi e metodologici standard individuati all’internodelle organizzazioni, ma sopratutto un modo relativamente più facile da automatizzareed informatizzare che accompagna l’informazione durante il suo ciclodi vita.Una importante osservazione è legata alla assegnazione selettiva <strong>dei</strong> diritti diaccesso <strong>per</strong> le singole informazioni, quale condizione necessaria <strong>per</strong> poter parlare144


L’architettura <strong>InterDataNet</strong>IDN Information Modeldi responsabile. Al responsabile <strong>per</strong> esercitare il suo ruolo devono essere fornitele garanzie sulle modalità di gestione ed accesso all’informazione.6.1.4 Identificazione <strong>dei</strong> nodiUn elemento informativo <strong>per</strong> essere correttamente condiviso, divulgato e riusatonecessita di possedere due proprietà fondamentali: deve essere individuabileed accessibile.Nei sistemi telematici <strong>per</strong> individuare una risorsa si usa il suo indirizzamentoe spesso l’indirizzo stesso diviene anche <strong>per</strong> l’accesso fisico (come nel caso degliURL 1 ).Nel modello IDN l’identificazione <strong>dei</strong> nodi è una proprietà che deve esseremantenuta indipendente dai dettagli dell’accesso fisico, poichè l’accesso fisiconon rappresenta un contesto di interesse <strong>per</strong> un Information Model. In altreparole è importante disporre di identificatori che vadano ad astrarre dallalocalizzazione fisica delle risorse e siano quindi indipendenti dalla stessa.Questo è conseguenza della <strong>per</strong>cezione che ha l’essere umano del concettodi “documento”: ad esempio con “categoria della patente di guida di MarioRossi” si intende un’informazione ben precisa ed indipendente dal luogo e dalformato in cui viene conservata e acceduta. In pratica la categoria è la stessainformazione sia che questa venga memorizzata negli archivi elettronici dellaMotorizzazione Civile che stampata sul documento in formato cartaceo <strong>per</strong> iltitolare della patente.L’esempio relativo alla patente di guida evidenzia come l’identificazione dellerisorse sia un’o<strong>per</strong>azione concettualmente diversa dall’accesso e <strong>per</strong>tanto, ingenerale, è opportuno che le due o<strong>per</strong>azioni siano distinte <strong>per</strong> rispettare laseparation-of-concern. In tal caso, una volta effettuata l’identificazione in unaprima fase, è possibile procedere, in una fase successiva, con l’accesso.Queste ultime considerazioni hanno portato alla definizione degli URN (UniformResource Name) [SM94, Moa97, DvGIF99, Dan97]. Un URN è anche unURI, ma differisce da un URL <strong>per</strong> il fatto che identifica una risorsa web indipendentementedalla sua locazione fisica in modo non ambiguo ed univoco, inoltrenon contiene informazioni variabili nel tempo. Un buon esempio di URN è ilcodice ISBN di un libro [LPD98]: ISBN identifica un libro, ma nessuna dellesue copie.In IDN si definiscono Persistent Resource Identifier (PRI ) gli URN che identificanoi nodi del documento in modo univoco, questo nome mette in evidenzala principale proprietà che caratterizza questo tipo di identificatore: la <strong>per</strong>sistenza.Ulteriori dettagli relativi alla definizione ed alla gestione <strong>dei</strong> PRI verrannoriportati nel capitolo 9.Poiché i PRI sono ad uso e consumo della macchina, non sono necessarie restrizioni<strong>per</strong> renderli facilmente utilizzabili e trascrivibili dall’uomo, anche se ciòè comunque auspicabile. Purtroppo gli utenti hanno bisogno di assegnare nomifacilmente intellegibili e condivisibili con altri <strong>per</strong> indicare concetti e contenuti.1 Uniform Resource Locator [BLMM94], sono gli indirizzi utilizzati nel web <strong>per</strong> identificareed accedere alle risorse. Sono un caso particolare di URI (Uniform ResourceIdentifiers [BLFM98]).145


L’architettura <strong>InterDataNet</strong>IDN Information Model(a)URLURLURLReplicaReplicaReplica(b)URNURLURLURLReplicaReplicaReplica(c)HFNHFNURNURLURLURLReplicaReplicaReplicaFigura 6.2: Nomi di risorse replicatePer riempire il divario tra le proprietà del PRI e le necessità umane è opportunointrodurre un nuovo tipo di URI come suggerito in [Mea02]. È definitoHuman Friendly Name (HFN ) un nome di alto livello progettato a misura d’uomo[SM94]. A differenza degli URN gli HFN <strong>per</strong>mettono l’uso esplicito di nomidescrittivi. Un HFN ha bisogno di essere risolto in un PRI quando l’utentevuole stabilire una convenzione univoca verso la risorsa. Per evidenziare che gliHFN assegnano un nome logico alla risorsa, nel modello IDN sono stati definitii Logical Resource Identifier (LRI ) come sottocaso particolare.Gli LRI <strong>per</strong>mettono l’uso esplicito di alias, sono nomi flessibili e descrittivie relativi ad uno specifico contesto; inoltre risultano facilmente comprensibilie interpretabili dagli utenti <strong>per</strong>ché definiti e assegnati in base al paradigma dicontenimento e catalogazione “folder/file”. A livello applicativo hanno possonoavere il vantaggio di essere facilmente comunicabili a patto di scegliere unacodifica efficace.146


L’architettura <strong>InterDataNet</strong>IDN Information ModelIn IDN-IM gli identificatori LRI sono gli handle di alto livello che mascheranogli identificatori di elaborazione ed accesso propriamente appartenenti ad unavista Data Model (URL).Esistono molti vantaggi con questo approccio. In primo luogo gli utentipossono 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 effettisulla posizione delle repliche. Inoltre un utente può scegliere di usare nomidiversi <strong>per</strong> indicare la stessa risorsa, allo stesso modo con cui vengono usati glialias negli indirizzi di posta elettronica o nei link simbolici del file system.Ulteriori dettagli su LRI e PRI saranno trattati nel capitolo 9.6.1.5 Osservazioni sul modelloSulla base dell’analisi estesa <strong>dei</strong> requisiti (capitolo 3) e delle considerazioniprecedentemente enunciate (sezione 6.1.3) possiamo discutere le caratteristicheche il documento definito da IDN-IM deve soddisfare.Alcuni di essi risultano vincolanti <strong>per</strong> gli obiettivi del sistema, mentre altrisono desiderabili al fine di garantire la massima applicabilità ed estensibilità delmodello.Una prima caratteristica prevede che l’informazione sia strutturata, il chesottintende la necessità di poter riusare ed elaborare l’informazione con il minimodispendio di risorse <strong>per</strong> la sua interpretazione.Ogni informazione deve essere strutturabile, indipendentemente dalla suaforma fisica, anche se non si è certi che la struttura sia univocamente determinabilea fronte di scelte interpretative diverse.Inoltre, l’informazione deve poter essere aggregata <strong>per</strong> formare una nuovainformazione.Ciò deriva dall’osservazione che l’unione di più informazioni ha come risultatoun’informazione nuova, diversa da ciascuna delle sue componenti. Viceversa,la scomposizione dell’informazione in entità elementari più semplici consente dimassimizzare il riuso, la trasportabilità e l’autoconsistenza di ciascun aggregato.Un ulteriore vantaggio è rappresentato dalla possibilità di definire funzioni diaccesso e di modifica in modo mirato.Al fine di mantenere le regole di strutturazione dell’informazione indipendentidai contenuti informativi, onde evitare il rischio di contaminare il modellocon problematiche relative a specifici contesti, viene introdotto il “principio diresponsabilità”.In modo del tutto ortogonale ai contenuti informativi, si assume che l’informazionesia il risultato di produzioni iterative: ciascun passo vede un responsabile(spesso, ma non sempre, coincidente con l’autore) che produce informazionea partire da informazioni già esistenti in forma più semplice. Tale assunzione ègarantita dalla definizione stessa di informazione, poiché esiste sempre almenoun attore che crea e/o controlla l’informazione. Assumere a priori che il modellosia strutturato sulla base di tale principio risulta coerente con le dinamiche delworkflow e i modelli ad oggetti.Lo stesso principio si può riscontrare nei sistemi blog e wiki, nei quali la147


L’architettura <strong>InterDataNet</strong>IDN Service Architecturecomposizione di informazioni avviene sulla base di contributi incrementali, gestitida autorità con responsabilità distinte, che assieme vanno a costituire unnuovo documento.L’informazione deve essere indipendente dalla locazione fisica. Questo puntointende mettere in evidenza che un’informazione è tale indipendentemente dadove sia fisicamente collocata. Spesso, infatti, la stessa informazione viene memorizzatain apparati fisici distinti ed eterogenei, che <strong>per</strong>ò non devono influiresui contenuti informativi. Questa affermazione potrebbe sembrare banale, maagli effetti pratici la detenzione fisica <strong>dei</strong> dati da parte di una organizzazionerisulta spesso essere ingessante <strong>per</strong> il sistema organizzativo ed informativo (ancheinternamente) che può risente delle costrizioni imposte da normative o dapratiche adottate da un nucleo ristretto di affiliati.L’informazione già esistente nelle organizzazioni è distribuita <strong>per</strong> definizione,<strong>per</strong> cui questo requisito è soddisfatto a priori; il problema da affrontare è comerealizzarne l’acquisizione, l’arricchimento e la manutenzione in modo distribuitoe consistente, guardando alla distribuzione già esistente come a un vantaggio dasfruttare, e non come a uno svantaggio da azzerare.Una caratteristica che non è obbligatoria ma fortemente desiderabile, inquanto sostiene i requisiti di affidabilità e scalabilità, è che l’informazione siareplicata. La replicazione introduce un certo numero di vantaggi, come l’aumentodella disponibilità dell’informazione, garantendone il recu<strong>per</strong>o a fronte diguasti, e il dimensionamento adattativo nel tempo del sistema in funzione dellarichiesta.È necessario che l’informazione sia tracciabile, di conseguenza il sistema deveessere dotato di uno storico e di un meccanismo di versionamento (versioning)dell’informazione. La sola presenza dell’informazione risulta sicuramente riduttivae inespressiva nello svolgimento delle attività collaborative all’interno delleorganizzazioni, le quali richiedono che sia possibile tracciare la storia dell’informazionein quanto legata al workflow e all’authoring concorrente e <strong>per</strong> ladeterminazione a posteriori delle responsabilità.È indispensabile che l’informazione sia indirizzabile in modo efficace e flessibilesia sul piano telematico che come modello di supporto alle attività collaborative.La prassi di assegnare alias alla stessa informazione viene coadiuvata eformalizzata attraverso un opportuno sistema di nomi, mentre la loro gestioneè delegata all’architettura stessa.Infine, bisogna tenere presente che un’informazione è tanto più utile quantopiù è orientata alla collaborazione, ossia è stata creata con lo scopo di esserecondivisa e sfruttata da più utenti, facilitandone l’utilizzo su larga scala.6.2 IDN Service ArchitectureAllo scopo di identificare i servizi necessari <strong>per</strong> un’implementazione efficaceed efficiente di IDN-IM, è stata concepita un’architettura logica stratificata,chiamata <strong>InterDataNet</strong> Service Architecture (IDN-SA), in grado di catturare iconcetti del modello dell’informazione e di separare la complessità del problemasu più livelli (figura 6.3), in modo da stabilire le basi <strong>per</strong> l’architettura di rete.148


L’architettura <strong>InterDataNet</strong>IDN Service Architecturecrescita dell'astrazioneInformazionicomplesse(documenti)Informazionielementari(nodi)Byte.(file, database)ApplicationLayerVirtual RepositoryLayerInformation HistoryLayerReplica ManagementLayerStorage InterfaceLayerFigura 6.3: Livelli dell’architettura IDNLa definizione è top-down: si parte dal una analisi e progettazione di altolivello (logica) <strong>per</strong> arrivare ad una trattazione <strong>dei</strong> 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, dalpunto di vista del trattamento dell’informazione, sia analoga a quella <strong>dei</strong> sistemidi comunicazione tra piattaforme eterogenee, ispirandosi al successo della suiteTCP/IP.Così come Internet risolve i problemi della comunicazione <strong>per</strong> le reti interconnessedelegando a livelli diversi la cura di aspetti specifici [Bra89b], IDNpropone l’uso di livelli differenti <strong>per</strong> abilitare a livello globale la collaborazionetra <strong>per</strong>sone, imprese ed organizzazioni. Ogni livello affronta una problematicao caratteristica propria dell’informazione (documento) ponendola su un pianocondiviso e collaborativo.I livelli più alti <strong>per</strong>cepiscono l’informazione come entità complessa sotto formadi documento. Ogni documento è costituito da una serie di informazionielementari legate da relazioni strutturali.Spostando l’attenzione verso i livelli intermedi gli aspetti strutturali dell’informazionevengono meno: l’informazione è vista come tante unità elementariindipendenti.Infine <strong>per</strong> i livelli più bassi l’informazione è semplicemente una particolarecodifica delle entità definite ai livelli su<strong>per</strong>iori, in altre parole “sequenze di byte”(file e record di database).Con questa prospettiva, nel presente lavoro, si parla di livello (o layer) <strong>per</strong>fare riferimento ad un contenitore logico di servizi e sottosistemi indipendentiche manipolano ed effettuano specifiche o<strong>per</strong>azioni sull’informazione. Talisottosistemi interagiscono fornendo o richiedendo servizi ad altri sottosistemiappartenenti allo stesso livello logico oppure ad altri livelli adiacenti.IDN-SA (figura 6.3) descrive i livelli di servizi Virtual Repository, InformationHistory e Replica Management. Vincolare e dettagliare gli strati Applicatione Storage Interface, alle estremità dello stack, non risulta conveniente ai2 Fornisce un insieme di sottosistemi predefiniti, specifica le loro rsponsabilità e le regole edesplicita le regole e linee guida <strong>per</strong> organizzarli e relazionarli tra loro [BMR + 96].149


L’architettura <strong>InterDataNet</strong>IDN Service Architecturefini, rispettivamente, della crescita del sistema e dell’adattabilità verso sistemiesistenti.Per quanto concerne la crescita viene infatti lasciata la massima libertà <strong>per</strong>quel che riguarda la definizione del contesto applicativo che può essere diversificato.Analogamente non vengono fissate specifiche stringenti sul formato distorage <strong>dei</strong> dati. Quest’ultimo aspetto <strong>per</strong>mette quindi di diversificare anchele soluzioni di basso livello, aspetto che garantisce l’adattabilità con il passatoovvero la possibilità di riutilizzare, definendo <strong>dei</strong> Storage Interface ad hoc, isistemi legacy.Si noti come questo approccio equivalga a quello utilizzato nella definizionedella pila Internet <strong>per</strong> la quale è stata lasciata la massima libertà nella definizionedel livello applicativo e <strong>dei</strong> livelli inferiori a quello di rete.6.2.1 Attraversamento <strong>dei</strong> livelliL’interazione fra i livelli avviene tramite il paradigma client/server: ognilivello è client di quello inferiore (al quale richiede servizi) e server di quellosu<strong>per</strong>iore (al quale fornisce <strong>dei</strong> servizi). Quindi, <strong>per</strong> ogni coppia di livelli, vienedefinito un protocollo di comunicazione che, come HTTP (vedi [FGM + 99]),è request/response. Il paradigma convenzionale di interazione fra l’utente e ilsistema è di tipo pull: in seguito ad un’azione dell’utente la pila viene attraversatada una sequenza di request che si sviluppa dall’alto verso il basso e dauna sequenza corrispondente di response che la <strong>per</strong>corre in senso opposto. Ognilivello si attiva <strong>per</strong> generare la response a seguito di ogni request provenientedal livello su<strong>per</strong>iore (o da un’azione dell’utente <strong>per</strong> quanto riguarda il livelloapplicativo), eventualmente effettuando delle richieste ai livelli inferiori (comeevidenziato in figura 6.4) <strong>per</strong> richiedere l’espletamento di servizi necessari <strong>per</strong> ilcompletamento dell’o<strong>per</strong>azione.Richiesta dell'utenteRisposta all'utenteRequest - ResponseLivelli IDNTempoFigura 6.4: Interazione request/response applicata ad IDNUn meccanismo di notifica in modalità push, risulta utile in svariate situa-150


L’architettura <strong>InterDataNet</strong>IDN Service Architecturezioni (ad esempio <strong>per</strong> inoltrare segnalazioni in tempo reale all’utente a seguitodi eventi che si sono verificati nel sistema). Si può comunque osservare cheè possibile simulare la modalità push in presenza della sola modalità pull (ascapito dell’efficienza o<strong>per</strong>ativa) tramite polling. Questo <strong>per</strong>metterà a livelloimplementativo di rimandare l’inserimento della modalità push senza <strong>per</strong>dere ingeneralità nella trattazione.Nel capitolo 8 sarà fornita una panoramica complessiva e generale sui compitidi ciascun livello della architettura. Nella parte IV gli stessi livelli verrannoanalizzati singolarmente con maggiore dettaglio tecnico-progettuale.6.2.2 Imbustamento di dati e metadatiL’attraversamento <strong>dei</strong> livelli, descritto <strong>per</strong> la modalità di interazione (paragrafo6.2.1), ha <strong>dei</strong> risvolti di interesse anche <strong>per</strong> le modalità con cui vengonotrattate le informazioni. Infatti le informazioni vengono elaborate e trattate aseguito della comunicazione fra i livelli.Da un punto di vista generale è valida la seguente affermazione: ogni livellodi IDN tratta le informazioni scomponendole, con la granularità necessaria, indati 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)<strong>per</strong> trattare le informazioni secondo quanto previsto dal modello IDN-IM.Entrando nel dettaglio, come rappresentato in figura 6.5, si ha la seguentesituazione:• le IDN-Application definiscono a proprio uso e consumo le rappresentazioniopportune delle informazioni e coerentemente al modello IDN-IM (ed allaIDN-API). Virtual Repository offre alle applicazioni l’opportunità (tramitela IDN-API) di gestire tali informazioni, esponendo una interfacciauniforme di dati e metadati;• Virtual Repository aggiunge tutti quei metadati (VR-META in figura 6.5)necessari alla gestione <strong>dei</strong> documenti IDN-IM: dai metadati <strong>per</strong> la gestionedella struttura del documento, a quelli <strong>per</strong> l’identity management, daimetadati <strong>per</strong> la gestione del modello di versioning UEVM a quelli <strong>per</strong>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 lotrattaterà come un’unica entità (IH-DATA);• Information History aggiunge quindi quei metadati (IH-META) necessarialla gestione del versioning delle singole entità elementari (come se fosseronon strutturate) e l’insieme di tali dati e metadati viene imbustato a livelloReplica Management e trattato come un’unica entità (RM-DATA);• Replica Management aggiunge a sua volta quei metadati (RM-META) necessarialla gestione della replicazione delle singole entità elementari (comese fossero non strutturate) e tale insieme di dati e metadati viene imbustatoa livello Storage Interface e trattato come un’unica entità (SI-DATA);151


L’architettura <strong>InterDataNet</strong>IDN Service ArchitectureSI-DATASI-METAStorageInterfaceLayerRM-DATARM-METAReplicaManagementLayerIH-DATAIH-METAInformationHistoryLayerVR-DATAVR-METAVirtualRepositoryLayerAPP-DATAApplicationLayerFigura 6.5: Imbustamento di dati e metadati• infine Storage Interface provvede ad esporre i dati memorizzati su sistemidi storage eterogenei, associando ad essi gli opportuni metadati(SI-META).Il provedimento top-down, appena illustrato, è utile <strong>per</strong> evidenziare l’applicazionein IDN del principio di information hiding. Altrettanto utile è descriverela visione bottom-up <strong>per</strong> capire come dati ed metadati (in generale le informazioni)vengono esposte ai livelli su<strong>per</strong>iori. Infatti la descrizione appena fornitanon <strong>per</strong>mette 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 su<strong>per</strong>iore. Questosignifica che il livello su<strong>per</strong>iore, <strong>per</strong> 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 dallivello inferiore ed esposti, oppure essere stati definiti dal livello stesso e fattisoltanto gestire dal livello inferiore.Quindi, alla luce di queste considerazioni, è possibile indicare <strong>per</strong> ogni livellole seguenti categorie di metadati (figura 6.6). Per semplicità fissiamo l’attenzionesulla una coppia di livelli Information History (IH) e Replica Management (RM),da cui è immediato genereralizzare.• i metadati definiti dal livello su<strong>per</strong>iore e solamente gestiti da quello in esa-152


L’architettura <strong>InterDataNet</strong>IDN Service Architectureme, in termini di creazione, accesso, modifica, e cancellazione (IH-META,in figura 6.6);• i metadati definiti dal livello in esame <strong>per</strong> il proprio funzionamento, maesposti al livello su<strong>per</strong>iore <strong>per</strong>ché significativi <strong>per</strong> esso (in figura Exposed-META);• i metadati definiti dal livello in esame <strong>per</strong> il proprio funzionamento internoe non visibili al livello su<strong>per</strong>iore (in figura Internal-META).InformationHistoryLayerRM-APIIHDATARM-DATAIHMETARM-METAExposedMETAInternalMETAReplicaManagementLayerFigura 6.6: Classi di metadati in IDNSi faccia quindi nuovamente riferimento alla figura 6.5 e si consideri il livelloReplica Management. Nell’insieme di informazioni classificate con RM-DATArientrano 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 delegataad RM. In figura 6.6 sono esemplificate tutte le entità: RM-DATA, IH-DATA eIH-META. Ad esempio i dati potrebbero essere il contenuto vero e proprio relativoalla versione x di una data informazione ed uno <strong>dei</strong> metadati gestiti da RMpotrebbe essere proprio il numero di versione . Ovviamente, ilnumero di versione non è un elemento che RM è in grado di interpretare, puòsolo prendersi cura di memorizzarlo mantenendolo associato all’informazione dibase ed esporlo ad IH (livello che ne ha la responsabilità).Proseguendo attraverso esempi di metadati, è possibile citare la data di creazionedi un’unità informativa replicata. Questo tipo di metadato viene definito egestito a livello RM, ma può essere di interesse anche al livello su<strong>per</strong>iore e quindisarà esposto ad esso. In questo caso, in riferimento alla figura 6.6, questo tipodi metadato rientra a pieno titolo in RM-META (Exposed-META) ed RM offriràal livello su<strong>per</strong>iore l’accesso allo stesso (se pur con alcune limitazioni). Questo<strong>per</strong>ché, essendo tale metadato di competenza di RM, tale livello non <strong>per</strong>metteràche IH possa modificarlo senza controllo. Nell’esempio specifico non <strong>per</strong>metteràaffatto che IH possa modificarlo, offrendogli solo la possibilità di accedere adesso in sola lettura. Questo <strong>per</strong>ché è RM che crea (eventualmente su richiestadi IH) le unità informative replicate e sarà quindi sua cura definire il campo 3 .).3 Si noti che in questo caso il campo non sarà più aggiornato <strong>per</strong> tutto il tempo di vita153


L’architettura <strong>InterDataNet</strong>IDN Overlay NetworkInfine restano da analizzare i metadati definiti dal livello <strong>per</strong> il proprio funzionamentointerno e non visibili al livello su<strong>per</strong>iore (in figura 6.6 Internal META).Si pensi ad esempio all’indirizzo fisico di una singola replica: questo tipo dimetadato non è di interesse <strong>per</strong> il livello su<strong>per</strong>iore (che “vede” solo entità delocalizzazionee replicate) e <strong>per</strong>tanto, pur rientrando nella classe RM-META, nonviene reso visibile al livello su<strong>per</strong>iore.Quest’ultima classe di metadati viene memorizzata dal livello inferiore (come<strong>per</strong> il numero di versione citato in precedenza), può essere generata dinamicamente,anche da sistemi esterni. Ciò apre la possibilitò di definire un meccanismodi integrazione di metadati in maniera incrementale su informazioni provenientida sistemi legacy.6.3 IDN Overlay NetworkIDN è un’architettura distribuita ovvero un insieme di entità di elaborazionecoo<strong>per</strong>anti tramite una rete di comunicazione.Nell’approccio IDN, i problemi di intero<strong>per</strong>abilità tra sistemi informativieterogenei 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 o<strong>per</strong>a una trasformazione intermedia, riducendola complessità a livello applicativo e <strong>per</strong>mettendo di partizionare il problemaglobale, rendendolo efficacemente trattabile.Si sottintende dunque un’architettura implementativa coerente con i principidell’interdataworking, nella quale tra una sorgente ed una destinazione esistono<strong>dei</strong> punti intermedi, ognuno <strong>dei</strong> quali svolge determinati compiti, in analogiaagli apparati di rete <strong>per</strong> 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 tuttigli effetti come middleware five-tier (figura 6.7). Infatti con middleware siintende un sistema stratificato di applicazioni, eseguite su una o più macchineche interagiscono in rete <strong>per</strong> supportare l’intero<strong>per</strong>abilità di architetture distribuiteagendo da intermediari tra le applicazioni di alto livello e servizi diinfrastruttura [TvS01].Inoltre ricordiamo che il middleware mira a:• mascherare la distribuzione. Una applicazione può essere supportata damolte parti interconnesse in locazioni distribuite;• mascherare l’eterogeneità di piattaforme hardware/software e protocolli;dell’unità informativa. Si pensi <strong>per</strong>ò ad un metadato quale la data di ultimo accesso: saràaggiornato da RM in corrispondenza di ogni richiesta di accesso all’unità informativa e soloin tal caso.154


L’architettura <strong>InterDataNet</strong>IDN Overlay NetworkApplicationLayerApplicationVirtual RepositoryLayerISRASLDNSInformation HistoryLayerInformation History(VTA)Control PlaneReplica ManagementLayerReplicaManagementLSStorage InterfaceLayerStorage InterfaceFigura 6.7: Livelli e servizi dell’architettura IDN• fornire in maniera uniforme una interfaccia standardizzata ad alto livello<strong>per</strong> gli sviluppatori ed integratori di applicazioni, affinchè le applicazionipossano essere facilmente composte, riusate, portate e rese intero<strong>per</strong>abili;• supportare un insieme di servizi di base <strong>per</strong> espletare funzionalità generalpurpose,al fine di evitare la duplicazione e facilitare la coo<strong>per</strong>azioneapplicativa.I nodi di una rete di sovrapposizione possono essere rappresentati come connessida collegamenti virtuali o logici, ciascuno <strong>dei</strong> quali corrisponde ad uncammino, magari attraverso molti collegamenti fisici, nella rete sottostante. Adesempio, molte reti peer-to-peer sono reti di sovrapposizione <strong>per</strong>ché poste sopraInternet.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 edadattativa, in quanto possono essere opportunamente installati e configuratianalogamente a quanto avviene con gli apparati di internetworking.6.3.1 Dall’architettura <strong>dei</strong> servizi alla reteL’architettura più semplice in grado di fornire un servizio è costituita da unsingolo processo ospitato in un host, ma generalmente un servizio viene fornitoda un cospicuo insieme di istanze di processi distinti come in IDN.155


L’architettura <strong>InterDataNet</strong>IDN Overlay NetworkMentre la descrizione <strong>dei</strong> servizi implica la definizione di coreografia e orchestrazione,la descrizione di rete fornisce la descrizione <strong>dei</strong> <strong>per</strong>corsi che l’informazione<strong>per</strong>corre su nodi e rami della rete.La rete di comunicazione fa parte dell’infrastruttura utilizzata da IDN <strong>per</strong>il proprio funzionamento, infatti ogni apparato IDN è un sistema di livelloapplicativo della pila ISO/OSI.Parlando di layer (o comunque livello, tier o strato) viene fatto riferimentoai livelli di servizio elencati nel paragrafo precedente: Application Layer, VirtualRepository Layer, Information History Layer, Replica Management Layere Storage Interface Layer. In figura 6.7 sono mappati i livelli di servizi in tier.Il Control Plane introdotto ortogonalmente alla pila è una astrazione graficache intende evidenziare come alcuni processi di controllo e monitoraggiosiano collocati al margine della stratificazione <strong>per</strong> esigenze di configurazione edebugging.I livelli di IDN sono costituiti da processi, ovvero programmi in esecuzione[TW97] su host di rete (computer fisici o macchine virtuali). I processi, <strong>per</strong>poter erogare <strong>dei</strong> servizi all’esterno, devono essere individuabili in rete tramiteindirizzi di livello applicativo di OSI 4 .In figura 6.8 vengono riportate esplicitamente le relazioni esistenti tra gliapparati che costituiscono il sistema IDN. Due processi hanno la possibilità dicomunicare se i relativi servizi sono collegati tramite una freccia. In particolarela direzione della freccia indica in quale verso si sviluppa la richiesta: l’elementodal quale essa parte è il richiedente del servizio ovvero il client, mentre quellonel quale essa termina è il fornitore del servizio ovvero il server.La figura 6.8 è possibile osservare come tutti i processi in gioco rispettanoi vincoli del modello stratificato presentato nel paragrafo 6.2, ad eccezione diquelli appartenenti ad un piano trasversale Control Plane (CP), <strong>per</strong> motivi diconfigurazione e debugging.6.3.2 Control PlaneIl piano di controllo serve ad impostare le condizioni iniziali ed a contorno<strong>dei</strong> processi dell’architettura (es. file di configurazione).La possibilità di intervenire su alcuni piani in modo diretto, indipendentementedal comportamento degli altri layer, consente attività di amministrazione,manutenzione e configurazione. Ad esempio parametri di funzionamentoquali quelli relativi alle regole <strong>per</strong> la distribuzione delle repliche, al comportamentodelle versioni e delle informazioni possono essere monitorati e controllatidirettamente attraverso questo piano.Control Plane <strong>per</strong>mette di agire e monitorare anche <strong>per</strong> finalità di debugginga vantaggio degli sviluppatori IDN nell’osservazione e controllo del sistema. Inaltre parole gli amministratori, grazie al Control Plane, hanno una visione sullamessa in esercizio <strong>dei</strong> 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


L’architettura <strong>InterDataNet</strong>IDN Overlay NetworkApplicationLayerApplicationType 1...ApplicationType NControlPlaneVirtualRepositoryLayerResourceAggregationServiceLDNSServiceIdentityServiceInformationHistoryLayerInformationHistory(VTA)ControlServiceReplicaManagementLayerReplicaManagementServiceLSServiceStorageInterfaceLayerStorageInterfaceServiceLegenda: tipologie di processiProcesso dotato diinterfaccia utenteProcesso privo diinterfaccia utenteFigura 6.8: Livelli, servizi e processiLe attività evidenziate, attraverso il Control Plane sono confinate localmenteall’host.6.3.3 Rete ed intero<strong>per</strong>abilitàUn’organizzazione che utilizza IDN dovrebbe disporre di idonea infrastruttura(hardware e software) capace di accedere alle risorse fornite dalle altreorganizzazioni, oltre che esporre le sue risorse affinchè altri le usino <strong>per</strong> unapiena federazione.Il modo più diretto <strong>per</strong> organizzare gli apparati è quello di predisporre unoo più server hardware e vari <strong>per</strong>sonal computer <strong>per</strong> i client utente interconnessialla rete.Si può suggerire l’esistenza di appositi service provider che forniscano alle157


L’architettura <strong>InterDataNet</strong>IDN Overlay Networkorganizzazioni l’infrastruttura <strong>per</strong> l’accesso a IDN, accollandosi l’onere di amministraree manutenere gli apparati, così come avviene attualmente, ad esempio,<strong>per</strong> i fornitori dell’accesso ad Internet.Si consideri il collegamento tra un dominio A, che rappresenta un’organizzazioneche adotta un sistema legacy, e un dominio B, che rappresenta un’organizzazionecollaborativa realizzata in completo accordo alle specifiche IDN.Dal punto di vista dell’architettura, il dominio A ha bisogno di essere estesocon un’entità che o<strong>per</strong>i in maniera trasparente, arricchendo, senza alterarli, idati del dominio A con metadati e strutture logiche, al fine di esporli ai dominiesterni. In questo caso, il dominio A deve essere esteso con un apparato diinterdataworking che implementi quella parte <strong>dei</strong> servizi IDN necessaria <strong>per</strong>consentire al sistema di scambiare informazioni con altri sistemi IDN.Nella figura 6.9 è riportato uno scenario in cui i sistemi delle organizzazioniA e B sono nativi IDN e relativi a due domini indipendenti; la federazionedegli apparati IDN nel dominio A e degli apparati IDN nel dominio B avvienesfruttando Internet a basso livello.Organizzazione AOrganizzazione BApp.App.App.Lan1LanVRIHLSLDNSLan2IHRMSIInternetVRIHLDNSLSIHRMSIFigura 6.9: Scenario di coo<strong>per</strong>azioneSi presuppone che, <strong>per</strong> quanto possibile, ogni organizzazione utilizzi i servizidi IDN-SA installati internamente, in quanto l’interazione tra i server presentiall’interno di una rete privata garantisce un maggiore controllo di amministrazionee <strong>per</strong>mette di controllare in modo più diretto ed efficace gli aspetti legatialle questioni di sicurezza e di manutenzione. Ciò non è vincolante, anzi è desideratoche esista una integrazione di servizi con apparati in modo che il volumecomplessivo dell’informazione disponibile possa aumentare nel tempo grazie allacoo<strong>per</strong>azione cross-domain. In figura 6.10 è riportato un esempio di questotipo di interazione. Come è possibile osservare un’applicazione interna all’organizzazioneA intende accedere a <strong>dei</strong> dati propri dell’organizzazione B. Si notiche, grazie alla delocalizzazione offerta dal middleware, l’applicazione potrebbeessere del tutto all’oscuro del fatto che l’informazione richiesta è detenuta158


L’architettura <strong>InterDataNet</strong>IDN Overlay Networkdall’organizzazione B. Nel caso rappresentato in figura, l’applicazione effettuauna richiesta d’accesso all’unica istanza di Virtual Repository interna ad A. Taleistanza, dopo aver elaborato la richiesta, a sua volta ne effettua una nuovaad una delle due istanze di Information History interne all’organizzazione, <strong>per</strong>procedere con l’algoritmo di accesso verso i dati. L’algoritmo prosegue versoReplica Management. In questo caso si ha un’interazione cross-domain fra unadelle due istanze di Replica Management interne ad A e quella interna a B laquale, infine, va a re<strong>per</strong>ire il dato richiesto sull’opportuno Storage Interface.Organizzazione AOrganizzazione BApplicationVirtualRepositoryInformationHistoryReplicaManagementStorageInterfaceFigura 6.10: Esempio di interazione fra i servizi in organizzazioni diverseLa crescita del sistema IDN è abilitata grazie alla installazione di nuoviapparati e collegamenti IDN sulla base delle necessità in maniera analoga aquanto accade <strong>per</strong> le reti locali o di area metropolitana o geografica quandovengono ridimensionate introducendo nuovi router, gateway, hub, ecc.159


Capitolo7<strong>InterDataNet</strong> InformationModelL’entità gestita nell’ambiente IDN è un generico (nel senso di non specializzato)documento multimediale, <strong>per</strong>ciò risulta composta da contenuti, relazioniimplicite o esplicite tra contenuti, metadati ed eventualmente informazioni sullapresentazione.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 altrisecondo un principio gerarchico che si basa sull’associazione ad un responsabile.Si consideri l’esempio semplificato di un documento che rappresenta unapatente di guida. Per ogni contenuto informativo è possibile determinare un’organizzazioneche detiene l’informazione: <strong>per</strong> i dati anagrafici del titolare si risaleal Comune di nascita, <strong>per</strong> i dati della residenza si risale al Comune di residenza,<strong>per</strong> la categoria di guida al Ministero <strong>dei</strong> Trasporti, <strong>per</strong> i punti al Ministero degliInterni, <strong>per</strong> 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 suaformazione o rilascio.Più un documento è finemente suddiviso nei suoi elementi, più ogni sua parte,se opportunamente indicizzata e classificata, risulta riutilizzabile <strong>per</strong> la costruzionee la produzione di nuova informazione. Al fine di quantificare la riusabilitàdell’informazione, risulta conveniente introdurre il concetto di granularità <strong>dei</strong>componenti.Tornando all’esempio del documento patente, se i punti vengono azzeraticome effetto di una serie di contravvenzioni, il documento <strong>per</strong>de di validità e


<strong>InterDataNet</strong> Information ModelI nodi informativipossono venire automaticamente notificati degli avvisi ad una serie di soggetti.Da un punto di vista formale (non giuridico) si determina la creazione automaticadi una nuova patente: “se cambia una parte cambia l’aggregato di tuttele parti”. Il documento IDN è quindi una entità attiva, in quanto può evolveree cambiare comportamento sulla base dello stato assunto ed dalle relazioniespresse all’interno <strong>per</strong> effetto del versionamento.In IDN-IM le informazioni ottenute dal procedimento esaustivo di suddivisione<strong>dei</strong> contenuti informativi sono chiamate informazioni atomiche (definizionein 7.1.1: la suddivisione termina nel momento in cui si incorre in un’informazionenon ulteriormente (e ragionevolmente) frazionabile, come ad esempio il nomeo il cognome di una <strong>per</strong>sona.Ovviamente, questo procedimento necessita di raggiungere un compromessotra la complessità, l’effettiva necessità di riuso <strong>dei</strong> contenuti informativi el’adeguatezza della granularità della rappresentazione. Per tale motivo vieneintrodotto 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 distinguerele organizzazioni (e sotto-organizzazioni) che trattano le singole informazioni,costituendo in modo naturale un sistema distribuito, dal punto di vista dellostesso documento. La dinamicità e la flessibilità sono ottenute grazie all’elevatogrado 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 informativiLa struttura del documento in IDN-IM è rappresentata da un grafo direttoaciclico (Directed Acyclic Graph, in breve DAG)[Die05].Il vincolo principale è che non sono <strong>per</strong>messi cicli, ossia sequenze di nodiattraversando 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 ciascunnodo ha al più un genitore: le strutture DAG sono <strong>per</strong>ciò capaci di modellaretutte le risorse strutturate ad albero [Die05]. Questa proprietà rappresenta unvantaggio quando si passa dal modello informativo al modello dati.In IDN quindi le relazioni tra i nodi della struttura del documento sonogerarchiche, cioè esiste una relazione di tipo padre-figlio tale che il progenitoreè sempre distinguibile dal suo discendente, a differenza del caso della presenzadi cicli.L’approccio IDN prevede che l’informazione non sia memorizzata in un documento,ma collegata nel documento e tra documenti, <strong>per</strong> cui non è necessarioche venga codificata “fisicamente” al suo interno.Si suppone che esistano tanti collegamenti tra i nodi del documento quantesono 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 unalias. 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


<strong>InterDataNet</strong> Information ModelI nodi informativiTra i possibili alias esiste comunque un nome preferenziale a cui è assegnato unruolo <strong>per</strong>sistente ovvero di invariabilità nel tempo. Le relazioni introdotte trale PIU modellano gli aspetti strutturali, introducendo un ordinamento di tipopadre-figlio.Ciascuna informazione primitiva è costituita da almeno una sottoinformazione,infatti ogni nodo può essere genitore di una serie di nodi, che sono altreinformazioni primitive, e può contenere una o più informazioni atomiche.Ogni nodo del grafo che non ha figli, <strong>per</strong>ciò è detto foglia, contiene almenoun’informazione atomica; viceversa, ogni nodo del grafo che non è una fogliaaggrega almeno un’informazione primitiva.L’informazione atomica, che rappresenta l’entità informativa più elementare,è definita come una coppia ed è indivisibile.Perché sia significativa nello spazio <strong>dei</strong> documenti definiti da IDN-IM, ogniinformazione atomica deve essere contenuta in una e soltanto una informazioneprimitiva.7.1.1 Informazioni atomicheCome anticipato l’informazione atomica (Atomic Information Unit, AIU) èuna coppia “”. I valori che vengono memorizzati sono soggetti averifica sintattica e di ammissibilità.Ad esempio consideriamo l’informazione atomica “” rappresentanteil Codice di Avviamento Postale italiano <strong>per</strong> la città di Firenze. Ilvalore numerico riportato appartiene all’elenco <strong>dei</strong> CAP stabiliti dalle PosteItaliane, invece il valore “FI-50100” è sintatticamente scorretto oppure “01234”è sintatticamente corretto, ma inammissibile.Per il generico utente, che inserisce il dato, la parte nome della coppia “”ha un certo peso semantico. Non è <strong>per</strong>ò conveniente affidare talicontrolli unicamente alle capacità di un generico utente in quanto molti controlli(tutti quelli sintattici e parte di quelli semantici) possono essere automatizzatie affrontati da elaboratori elettronici con notevoli vantaggi in terminicomputazionali e di precisione.Visto che il modello non è una base di dati e non è dotato di algebra relazionalesembrerebbe impossibile stabilire se il requisito di accuratezza possaessere sempre soddisfatto. La risposta al problema consiste nell’ipotizzare chetutte le informazioni atomiche e primitive siano create e messe a disposizioneda un’entità responsabile che ne garantisce l’accuratezza. La definizione esattadel significato sarà poi demandata al responsabile di quella informazione.Per quanto riguarda le informazioni atomiche questo è ottenibile, senza <strong>per</strong>derein generalità, tramite composizione entro informazioni primitive. In altreparole ogni informazione atomica è associata ad una e una sola informazione primitivala quale <strong>per</strong>mette di proiettare la coppia “” nello spazio<strong>dei</strong> documenti IDN. Questo è conseguenza dal fatto che ogni istanza di una qualsiasicoppia “” non è un’informazione atomica, ma può diveniretale se viene “inquadrata” nell’ambito <strong>dei</strong> documenti IDN e l’incapsulamento dicui sopra ha la finalità di svolgere questa o<strong>per</strong>azione.Un esempio che <strong>per</strong>mette di chiarire questo tema è relativo al concetto di162


<strong>InterDataNet</strong> Information ModelI nodi informativiresponsabilità dell’informazione appena citato: parafrasando ciò che è stato introdottoin precedenza ogni informazione presente in un qualsiasi documentoIDN deve avere un responsabile, ovvero l’entità che ha autorità su di essa. Inquesto contesto è sufficiente considerare il responsabile come una proprietà, oattributo, dell’informazione. In questi termini l’incapsulamento della coppia“” all’interno di un’informazione primitiva <strong>per</strong>mette di farle ereditareil responsabile di quest’ultima, rendendola quindi dotata dell’attributonecessario <strong>per</strong> 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, ilquale ha le nozioni sufficienti a stabilire le regole sintattiche e le condizionia 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 unicoinserimento <strong>dei</strong> dati nel sistema, <strong>per</strong>tinenza e non eccedenza. Comunque <strong>per</strong>non rendere troppo rigido il modello dovrà essere tenuta in considerazione anchela possibilità di:• inserire i dati con strategie di autonomia a responsabilità diversificata;• correggerli ed arricchirli in fasi successive ed indipendenti.7.1.2 Informazioni primitiveÈ stato anticipato che le informazioni primitive modellano gli aspetti strutturalisfruttando il principio di aggregazione fra nodi. Ogni nodo contenenteun’informazione primitiva può essere genitore di una serie di nodi contenentialtre informazioni primitive. L’unico vincolo esistente è che nella struttura nonsiano 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 hannoun proprio indirizzo all’interno dello spazio <strong>dei</strong> nomi, ma ereditano quellodell’informazione primitiva che le compone. È analogo alle ancore <strong>dei</strong> documentiHTML: fissato l’indirizzo univoco dell’informazione primitiva è possibilespecificare, tramite un parametro addizionale, qual è l’informazione atomica diinteresse. In questo modo risulta possibile indirizzare univocamente anche leinformazioni atomiche.La tecnica di composizione di informazioni atomiche consente una ottimizzazione,in quanto <strong>per</strong>mette di contenere l’esplosione del numero di indirizziunivoci presenti nello spazio <strong>dei</strong> nomi <strong>per</strong>sistenti, senza <strong>per</strong>dere in generalità:in questo modo infatti le informazioni atomiche non hanno un proprio indirizzounivoco. Questo aspetto porta anche un altro vantaggio: il numero dielementi distinti che costituiscono i documenti risulta molto minore rispetto a163


<strong>InterDataNet</strong> Information ModelRelazioni strutturali tra nodiquello che si avrebbe assegnando una propria identità (indirizzo PRI) alle informazioniatomiche, senza rinunciare ai vantaggi della suddivisione granularedell’informazione che la soluzione proposta offre.Riassumendo, ogni informazione primitiva è quindi genitore di altre informazioniprimitive ed incapsula (contiene) al proprio interno un certo numerodi informazioni atomiche. Si osservi come da questo caso generale si possanodefinire documenti, come casi particolari, introducendo ulteriori restrizioni.Ad esempio un vincolo che può essere introdotto riguarda la mutua esclusionefra l’aggregazione e la composizione: in questi termini ogni informazione primitivaaggrega altre informazioni primitive senza comporre informazioni atomicheoppure compone informazioni atomiche senza aggregare informazioni primitive.Documenti strutturati secondo questa modalità hanno le informazioni atomicheesclusivamente nelle foglie. Inoltre tutte le foglie contengono necessariamenteinformazioni atomiche e <strong>per</strong>tanto esiste una <strong>per</strong>fetta corrispondenza fra le fogliee 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 trale parti) e, <strong>per</strong> le informazioni atomiche incapsulate, la correttezza <strong>dei</strong> datiassociati alle coppie “”.Per esempio si faccia l’ipotesi che la patente di guida (semplificata) contengai seguenti elementi (figura 7.1):• anagrafica;• residenza;• categoria guida;• punti.La Motorizzazione Civile deve garantire la correttezza delle coppie “”e “”; inoltre deve garantire anche la correttaaggregazione delle informazioni di anagrafica e residenza. È l’anagrafe comunaledel comune di nascita a garantire la correttezza delle informazioni atomicherelative ai dati anagrafici. È il comune di residenza a gartantire la correttezzadell’indirizzo.Da un punto di vista astratto è possibile considerare le informazioni primitivecome il punto di accesso all’informazione complessiva che si sviluppa da esse finoalle foglie, come rappresentato in figura 7.2-a.7.2 Relazioni strutturali tra nodiIn IDN-IM sono definiti tre principali tipi di collegamento:• Collegamenti di aggregazione. Per esprimere le relazioni genitoriali tra inodi del grafo, all’interno dello stesso documento. Ad esempio, nella figura7.2, l’informazione primitiva A è genitore dell’informazione primitiva B.• Collegamenti di composizione. Per definire funzioni di contenimento trainformazioni primitive e informazioni atomiche. Ad esempio, nella figura164


<strong>InterDataNet</strong> Information ModelRelazioni strutturali tra nodiPatente di Bruce SharkcategoriaApunti 9Residenza di Bruce SharkDati biometrici di Bruce SharkNazione“Australia”firmaBruce SharkVia“Oceano”fotoAnagrafica di Bruce Sharknome“Bruce”cognome“Shark”datanascita2003/11/14luogo“Australia”Figura 7.1: Esempio di documento patente IDN7.2, l’informazione atomica è contenuta nell’informazione primitivaA.• Collegamenti di riferimento. Per esprimere relazioni tra documenti diversi,e quindi tra grafi diversi. Questo tipo di collegamento è classificatocome informazione atomica e <strong>per</strong>ciò è trattato come una speciale coppia, dove il valore è una URI.Azzardando un confronto tra documenti IDN e documenti HTML osserviamouna forte analogia tra i collegamenti di aggregazione ed gli iframe, i collegamentidi composizione e l’ancora ed infine tra i collegamenti di riferimento ed i linkesterni.Si definisce il documento IDN un insieme di nodi PIU (Primitive InformationUnit), uno <strong>dei</strong> quali è detto radice, messi in relazione tra di loro attraverso collegamentidi aggregazione e riferimento[PPCP07]. Applicando la definizione inmodo ricorsivo, ciascun documento può essere considerato come un’aggregazionedi documenti.165


<strong>InterDataNet</strong> Information ModelRelazioni strutturali tra nodiContrariamente a quanto avviene <strong>per</strong> le aggregazioni tra informazioni primitive,il legame tra un’informazione atomica e l’informazione primitiva che lacontiene è <strong>per</strong> definizione inscindibile.DocumentoIDNaAInformazione astrattaassociata ad AAlberoassociatobAB1CB1C2 3D2 3D D4x5y4x5y4x5yInformazione astrattaassociata a BnomevaloreAssociataa DInformazionePrimitivaInformazioneAtomicaAssociataa CLegendaAggregazioneIncapsulamentoFigura 7.2: Esempio di documento IDNAggregazione e composizione sono funzioni mutuamente esclusive: l’informazioneatomica può essere soltanto contenuta nell’informazione primitiva, mentrel’informazione primitiva può essere soltanto aggregata in una o più informazioniprimitive.Nella figura 7.2, l’informazione primitiva D è aggregata sia dall’informazioneprimitiva B che dall’informazione primitiva C.L’aggregazione non è sufficiente a determinare la consistenza delle informazioniaggregate, dove con consistenza si intende che l’aggregazione è costituitada informazioni correttamente relazionate. Si considerino due informazioni primitive,A e B, costituite da due informazioni atomiche ciascuna. Ammesso chel’informazione A e l’informazione B siano di <strong>per</strong> sè consistenti, non è detto chel’aggregazione rappresentata da A + B sia “vera”. L’aggregazione è una condizionenecessaria, ma non sufficiente <strong>per</strong> la costruzione di <strong>nuove</strong> informazioniconsistenti; <strong>per</strong>tanto, il modello prevede che ogni informazione sia dotata di unostato, che rappresenti la qualità e la “veridicità” del risultato dell’aggregazione.In sintesi, in IDN un documento è composto da informazioni atomiche, cherappresentano il contenuto, e da informazioni primitive, che rappresentano leproprietà strutturali, cioè le relazioni tra i nodi, oltre alle caratteristiche del-166


<strong>InterDataNet</strong> Information ModelStrutturare con criteri di responsabilitàl’informazione definite nel modello stesso, come ad esempio l’entità responsabiledel contenuto.Il documento è strutturato <strong>per</strong>ché risulta dall’aggregazione di informazionielementari, le informazioni primitive, le quali a loro volta sono compostedalle informazioni atomiche. Questa struttura, determinata mediante l’applicazionedel principio di responsabilità, consente di introdurre una misura dellagranularità e <strong>dei</strong> 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 <strong>per</strong> definire e strutturare l’informazionea prescindere dal suo contenuto, basandosi sulla gerarchia delleorganizzazioni 1 .In contesti specifici, come ad esempio nella Pubblica Amministrazione, <strong>per</strong>ogni nodo deve essere definita un’entità responsabile (individuabile anche graziealle normative). In IDN-IM questo attore è una <strong>per</strong>sona fisica o giuridica chesi occupa di garantire l’accuratezza <strong>dei</strong> dati, cioè la validità delle coppie relative all’informazione atomica contenuta nel nodo, e la correttezzadella struttura, ovvero delle relazioni logiche tra i nodi [PPC + 08]. Si notiche l’autore e il responsabile di un nodo sono entità separate, e che una coppia contenuta in un’informazione primitiva eredita il responsabile.Ogni informazione primitiva può contenere dati specifici da usare <strong>per</strong> verificarese l’utente ha i diritti <strong>per</strong> eseguire una certa o<strong>per</strong>azione, ad esempiol’aggiornamento, su un certo nodo. I diritti di accesso ad un particolare nododa parte degli utenti possono essere garantiti con approccio tipo ACL (AccessControl List)[Tan94].Al fine di gestire i concetti di responsabilità e di gestione dell’accesso, IDNprevede la presenza <strong>dei</strong> gruppi, i quali aggregano uno o più utenti che condividonouno scopo comune. I gruppi sono organizzati in modo gerarchico, e ciascunodi essi ha specifici diritti di accesso sui documenti. Un utente può appartenerea più gruppi, ereditandone i diritti di accesso [PCPP07a].7.4 Identificazione <strong>dei</strong> nodiA livello del modello IDN-IM i nodi vengono identificati <strong>per</strong> convenzionetramite un nome canonico e zero, uno o più alias, tutti LRI. La convenzioneprevede che quando il nodo viene creato gli venga assegnato un LRI invariabilenel tempo che dipende dal contesto nel quale il nodo viene creato.Inoltre gli utenti possono arbitrariamente assegnare ulteriori LRI secondo leloro necessità ai singoli nodi (gli alias).Infine, come introdotto nel paragrafo 7.2 i nodi fanno parte di documentistrutturati a DAG, quindi ad essi sono costruibili ulteriori LRI determinati dallaposizione assunta nella struttura.1 È stato spostato il problema della strutturazione su un piano organizzativo167


<strong>InterDataNet</strong> Information ModelStorico <strong>dei</strong> documentiPer esprimere in modo più efficace questo concetto è possibile fare riferimentoad un esempio. Nella figura 7.3 sono mostrati due documenti IDN: Doc1 contienequattro nodi e quattro collegamenti di aggregazione di nome 1, 2, 3, e 4, mentreDoc2 contiene tre nodi e due collegamenti di aggregazione, entrambi di nome 6.Inoltre, Doc1 contiene un collegamento di riferimento a Doc2 di nome 5.Doc10Doc2nome: path/021 nome: path/0/257nome: path/0/56nome: path/0/5/6nome: path/0/14nome: path/0/5/73nomi:path/0/1/3path/0/2/4Figura 7.3: Esempio di relazioni tra documenti IDN-IMNella figura 7.3, il nodo path/0/1/3 ha questo nome <strong>per</strong>ché è un figlio delnodo path/0/1 attraverso il collegamento di nome 3. Per lo stesso motivo,ha anche il nome path/0/2/4 <strong>per</strong>ché è raggiungibile anche dal nodo path/0/2attraverso il collegamento di nome 4.In altre parole, ogni nome ha la seguente struttura [PPC + 08]:node_parent_name + / + link_namedove:• node_parent_name è il nome del nodo genitore;• + è l’o<strong>per</strong>atore di concatenazione tra stringhe;• link_name è il nome del collegamento che mette in relazione il genitorecon il nodo da indirizzare.Nella figura 7.3, se si considera il nodo path/0 come radice locale, i lorosuccessori hanno i seguenti nomi: /1, /2, /1/3 e /2/4, <strong>per</strong> i nodi in Doc1; /5,/5/6, /5/7 <strong>per</strong> i nodi in Doc2.7.5 Storico <strong>dei</strong> documentiOgni documento dispone di caratteristiche atte a memorizzare la sua evoluzionetemporale, chiamata storico. Tale evoluzione, sebbene sia una caratteri-168


<strong>InterDataNet</strong> Information ModelStorico <strong>dei</strong> documentistica globale del documento, viene mantenuta memorizzando l’evoluzione dellesingole informazioni che lo costituiscono (a livello di nodo).Le evoluzioni temporali delle singole informazioni (che si ricorda essere strutturatea DAG), pur essendo mantenute separate ed associate ad esse, non sonoindipendenti: una modifica effettuata ad un’informazione che si trova ad un livellopiù basso della gerarchia si ri<strong>per</strong>cuote su tutti i suoi predecessori. Questofa sì che lo storico della radice “comprenda”, seppur indirettamente, l’evoluzionetemporale di tutto il documento. Volendo recu<strong>per</strong>are una data versione 2 , è previstoun meccanismo di navigazione nello storico che, partendo dalla radice edattraversando i vari nodi del documento, <strong>per</strong>mette di ricomporlo come richiesto.È utile evidenziare come il meccanismo, basandosi su un modello estensionale,<strong>per</strong>metta, a differenza di altri modelli di versioning, di ri<strong>per</strong>correre lo storico deldocumento nel modo più naturale possibile <strong>per</strong> l’utente: ogni versione del documentoviene ricostruita correttamente sia <strong>per</strong> quel che riguarda i dati contenutisia <strong>per</strong> quanto riguarda gli aspetti strutturali.Per descrivere i meccanismi di gestione dello storico è utile inizialmente fareriferimento 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 immutabilenel tempo l’o<strong>per</strong>azione di modifica dà vita ad un nuovo nodo. Si definisce versioneun’informazione primitiva ottenuta modificando il contenuto informativo diun nodo esistente. Anche la nascita di una nuova informazione rientra in questadefinizione considerando che tale o<strong>per</strong>azione può essere vista come la modificadell’informazione nulla. Viene definito uno stato UPDATE che viene associatoad ogni informazione <strong>per</strong> determinare se è necessario generare <strong>nuove</strong> versionioppure effettuare sovrascritture. Il valore assunto dallo stato può essere frozeno changing rispettivamente. Le transizioni avvengono tramite le o<strong>per</strong>azioni difreeze e melt, figura 7.4.UPDATEmeltchangingfrozenfreezeclose [in hard]Figura 7.4: Stato Update delle informazioniÈ opportuno chiarire cosa si intende con “modifica” di un’informazione alvariare del tipo di essa:• nel caso di informazione atomica si parla di cambiamento di uno o dientrambi i campi “nome” o “valore”;2 In questo caso con versione si intende una ben precisa configurazione del documento.169


<strong>InterDataNet</strong> Information ModelStorico <strong>dei</strong> 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<strong>dei</strong> metadati ad essa associati.Può essere utile specificare che <strong>per</strong> quanto riguarda i link di riferimento, siccomerientrano nella prima categoria, il nodo che contiene il link si consideramodificato solo se cambia il valore stesso del link. Eventuali variazioni del nodoriferito dal link non determinano variazioni dello storico del documento che locontiene.È possibile modificare solo e soltanto l’ultimo nodo creato all’interno dellostorico e, nel caso in cui lo stato UPDATE sia frozen, quello che si genera èun insieme ordinato di revisioni. Viceversa <strong>per</strong> modificare un nodo che non sial’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: <strong>per</strong> ogni versione x appartenente ad una diramazione, si hax−→x;2. antisimmetrica: <strong>per</strong> ogni versione x, y appartenenti ad una stessa diramazione,tali che x−→y e y−→x, allora x≡y;3. transitiva: <strong>per</strong> ogni versione x, y, z appartenenti ad una stessa diramazione,tali che x−→y e y−→z, allora x−→z;4. confronto: <strong>per</strong> 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 richiestadi nascita di una diramazione a partire dalla prima versione x.0 al tempo t 1 >t 0comporta la creazione del ramo y contenente la nuova versione y.0. Al tempot 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.2Branch y (t 1 ) Branch y (t 2 )y.0 y.0Figura 7.5: Generazione delle revisioniLo storico è interrogabile esprimendo esplicitamente la versione desiderata.Comunque è possibile estendere l’interrogazione anche attraverso delle proposizionilogiche: ogni versione contiene al proprio interno <strong>dei</strong> riferimenti relativialle versioni precedenti ed a quelle successive170


<strong>InterDataNet</strong> Information ModelStorico <strong>dei</strong> documenti7.5.1 VersioningIDN-IM modella più versioni associate ad un insieme di informazioni. Ilcontrollo di versione, usato soprattutto nello sviluppo di progetti software <strong>per</strong>controllare l’evoluzione <strong>dei</strong> documenti e <strong>per</strong> organizzare il lavoro quando le specifichedel progetto dipendono da un gruppo di <strong>per</strong>sone, consiste principalmentenell’assegnare ai documenti un numero o un’etichetta di versione, in relazioneallo stato che questi assumono in seguito alle modifiche.Il mantenimento delle versioni (revisioni), dell’informazione e l’automazionedella generazione delle stesse garantiscono la massima tracciabilità, <strong>per</strong>mettendodi ricostruire l’evoluzione dell’informazione nel tempo a fronte delle modifiche.In IDN ogni nodo del grafo è <strong>per</strong>ciò versionato, in quanto rappresenta un’istanzatemporale dell’entità concettuale dell’informazione rappresentata. Leversioni delle informazioni primitive sono esse stesse informazioni primitive, infattiqualsiasi nodo del grafo viene definito all’interno dello storico dell’informazioneed è parte di esso.Si noti che questa definizione è ortogonale e indipendente dalla strutturalogica dell’informazione nel grafo.Ogni storico possiede un indirizzo logico attraverso il quale è possibile avviarel’esplorazione della sua struttura interna.Esistono diversi modelli <strong>per</strong> la gestione del controllo di versione [Ask02];in generale essi si differenziano in base allo schema adottato <strong>per</strong> numerare lerevisioni. Le tecniche più recenti <strong>per</strong>mettono o<strong>per</strong>azioni di branch, <strong>per</strong> portareavanti in parallelo lo sviluppo di un progetto quando due o più parti si curanodell’evolvere di aspetti diversi, e di merge, <strong>per</strong> ricongiungere il lavoro svolto daidiversi gruppi.IDN segue i principi del modello UEVM (Unified Extensional VersioningModel) [ABCM99], che organizza le versioni di documenti strutturati come DAGriuscendo a versionare sia i contenuti che gli aspetti strutturali, con tecnicheautomatizzate.Ogni nodo del grafo può dunque essere visto come l’insieme di due gruppi direlazioni, una parte delle quali è relativa al versioning, mentre l’altra è compostada relazioni di aggregazione. Di conseguenza, IDN-IM introduce una tipizzazione<strong>dei</strong> collegamenti tra nodi, la cui semantica determina, oltre al verso, anchequando e come possono o devono essere attraversati.Si introduce un nuovo tipo di collegamento strutturale ed interno che agiscesu un piano diverso rispetto ai già enunciati collegamenti di aggregazione ecomposizione: collegamenti interni allo storico, che si specializzano in (accordoalla 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 consentireo bloccare la propagazione delle versioni a fronte della modifica <strong>dei</strong> contenutiinformativi del nodo.171


<strong>InterDataNet</strong> Information ModelStorico <strong>dei</strong> documentistorico di Anomevalorenomevalorenomevaloreinformazione primitivastorico di Bnomevalorenomevaloreinformazione atomicaaggregazionestorico di CnomevalorenomevalorerevisioneFigura 7.6: Storico dell’informazione in IDN-IMNella figura 7.6 è schematizzato un esempio che rappresenta gli storici relativialle informazioni A, B e C. Lo storico di A contiene 3 revisioni, e ognuna diesse, oltre a contenere due informazioni atomiche, aggrega sia la prima versionedell’informazione B, sia una revisione presente nello storico di C.7.5.2 La propagazione delle modificheLe versioni sono correlate attraverso l’aggregazione e possono concorrere aformare arbitrarie strutture: se mettiamo in evidenza solo le versioni e le relazionidi aggregazione che le connettono ciò che otteniamo è un grafo orientato. Lanascita di una nuova revisione scatena un meccanismo di propagazione nel grafoattraverso i cammini che si sviluppano in senso opposto rispetto alla direzionedegli archi relativi ai link di composizione che partono dall’ultima revisione diogni branch.Si può osservare che la propagazione all’interno della struttura del documentocorrente è un caso particolare, poiché in generale coinvolge tutti quei documentiche hanno <strong>dei</strong> sotto alberi in comune legati da link di composizione.I link di riferimento <strong>per</strong>mettono di creare correlazioni fra dati come avviene<strong>per</strong> i link di composizione; la differenza sostanziale è che, nel caso <strong>dei</strong> link diriferimento, non si ha la propagazione delle versioni.Durante una sessione al massimo vengono create tante versioni quanti sonoi nodi coinvolti. Ripetute o<strong>per</strong>azioni su un nodo sono parte integrante dellastessa attività. Ripetute aggiunte, cancellazioni, e cambiamenti <strong>dei</strong> figli di unnodo genereranno una ed una sola versione relativa a quel nodo. L’estensionetemporale di una sessione è sfruttata <strong>per</strong> controllare la granularità del versioning.I meccanismi menzionati riflettono a pieno quelli visti in UEVM, a cui deveessere fatto riferimento <strong>per</strong> ulteriori dettagli.172


<strong>InterDataNet</strong> Information ModelI collegamenti del modello7.6 I collegamenti del modelloIn riferimento agli aspetti comportamentali delle risorse, discussi nelle precedentisezioni, 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 documentoPer definizione in IDN lo stato di un documento è un’entità che serve aquantificare la qualità dell’informazione che questo contiene. Così come avviene<strong>per</strong> il versioning anche <strong>per</strong> lo stato viene fatto riferimento ai singoli nodi: leinformazioni atomiche hanno uno stato che dipende direttamente dalla qualitàdelle coppie “”, mentre le informazioni primitive assumono unvalore di stato che dipende dalle informazioni che aggregano ed incapsulano.Quindi, anche in questo caso, si prevede un meccanismo di propagazione dellostato che, a partire dai nodi in fondo alla gerarchia, risale gli antenati (daifigli verso i genitori) fino al capostipite assegnando, man mano, lo stato ai nodiattraversati.7.7.1 Lo stato delle informazioni atomicheUn’informazione atomica può essere soggetta a modifiche oppure può esserememorizzata in modo definitivo. Ortogonalmente esistono <strong>dei</strong> parametri <strong>per</strong>stabilire la qualità dell’informazione. Lo stato QUALITY indica la qualità <strong>dei</strong>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 transizionedello stato allowable avviene quando è verificato il controllo sintattico, se poisono verificate anche le restrizioni lo stato passa in accurate. Con restrizionisi intendono tutte quelle regole che limitano il valore ad un intervallo o ad unparticolare insieme di valori.173


<strong>InterDataNet</strong> Information ModelLo stato di un documentoQUALITYdraftwrite-open[in changing]syntax check[verified]write-open[in changing]accuratesoftallowablesetsetrestriction check[verified]HallowableFigura 7.7: Stati di una informazione atomica7.7.2 Lo stato delle informazioni primitiveCome mostrato in figura 7.8, il comportamento dell’informazione primitivaè un AND di stati delle informazioni aggregate a cui se ne aggiungono ulterioridue, similmente definiti a quelli di un’informazione atomica, ma propri di questainformazione. La definizione delle state chart è ricorsiva e la complessità dipendedal numero di livelli della gerarchia associata al documento.Condizione necessaria e non sufficiente affinché un’informazione primitivarisulti consistente è che ogni informazione aggregata (o tutte atomiche o tutteprimitive) sia singolarmente accurata. Per gli altri stati le seguenti condizionisono anche sufficienti:1. è nello stato di bozza (draft), se almeno un’informazione aggregata è nellostato 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 informazioneaggregata è accurata sintatticamente.In tabella 7.1 sono riportate schematicamente le regole di transizione <strong>per</strong> determinarelo stato nel caso in cui l’aggregazione sia di sole due informazioni. Per Ninformazioni basterà applicare tali regole iterativamente a coppie di informazionidisgiunte <strong>per</strong> N-1 volte.Per le informazioni primitive è possibile un ulteriore controllo che riguarda laverifica della consistenza. Questo <strong>per</strong>mette di far transitare lo stato da accuratea consistency.Con controllo della consistenza si intende la verifica della coerenza logica e/osemantica tra le informazioni aggregate. Lo stato consistency indica quindi che174


<strong>InterDataNet</strong> Information ModelLo stato di un documentodraftwrite-open[this inchanging]allowablesyntax checkinfo_1...info_Nwrite-open[this inchanging]write-open[this inchanging]consistencyaccuratesetrestrictioncheckHsofthardsetFigura 7.8: Stati di un’informazione primitival’informazione complessiva, costituita da una serie di informazioni più semplici,è corretta nella sua globalità. Questa è un’affermazione più forte rispettoal dichiarare che tutte le informazioni più semplici, prese singolarmente, sonocorrette. 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, <strong>per</strong>ò in quellavia potrebbe non esistere quel numero.L’obiettivo principale di un sistema distribuito è rendere semplice <strong>per</strong> gliutenti l’accesso alle risorse remote e la condivisione delle stesse con altri utentiin modo controllato.Collegare gli utenti e le risorse rende più semplice la collaborazione e loscambio delle informazioni, come dimostrato in modo esemplare dal successo diInternet e <strong>dei</strong> suoi protocolli <strong>per</strong> lo scambio di file, mail, documenti, audio evideo [TvS01].La connettività promossa da Internet ha portato a numerose organizzazionivirtuali, in cui gruppi di utenti largamente dis<strong>per</strong>si dal punto di vista geograficolavorano insieme. Questa connettività globale rafforza il bisogno di rendere lerisorse riutilizzabili tra <strong>per</strong>sone, comunità ed organizzazioni sparse in tutto ilmondo, e allo stesso tempo propone il problema dell’authoring collaborativo,inteso come l’insieme <strong>dei</strong> processi finalizzati alla creazione di un’informazione.175


<strong>InterDataNet</strong> Information ModelAuthoring concorrenteInfo 2Info 1DraftAllowableAccurateDraftDraftDraftDraftAllowable Draft AllowableAllowableAccurate Draft AllowableAccurateTabella 7.1: Mappa <strong>per</strong> la determinazione degli stati7.8 Authoring concorrenteConsideriamo un’informazione primitiva sulla quale vengono effettuate o<strong>per</strong>azionidi lettura e scrittura, intendendo con scrittura anche la modifica strutturale,cioè l’aggiunta o l’eliminazione di nodi. Le o<strong>per</strong>azioni, pur essendo rivolteverso la radice, coinvolgono tutti quei nodi del documento sui quali l’utenteha i diritti <strong>per</strong> o<strong>per</strong>are. In questo paragrafo, <strong>per</strong> semplicità e senza <strong>per</strong>derein generalità, si suppone che tutti gli utenti possano accedere alle informazioniin lettura e che solo il relativo responsabile possa effettuare modifiche. Ognio<strong>per</strong>azione avviene all’interno di una sessione.Si può incorrere nella concorrenza delle o<strong>per</strong>azioni <strong>per</strong> due motivi:1. è richiesta una attività di authoring parallelo sullo stesso documento (figura7.9.a);2. due o più documenti, che aggregano una stessa informazione primitiva,vengono a<strong>per</strong>ti in intervalli di tempo sovrapposti (figura 7.9.b).Concettualmente sono attività diverse, ma in questo contesto vengono trattatein modo indistinguibile.Dato che le sessioni di lettura sono non distruttive e quindi meno critiche, nonrichiedono complesse tecniche di gestione, a patto di tenere presente i requisitidi awareness e la <strong>per</strong>cezione dell’utente. Deve esistere un opportuno sistema diaccodamento delle o<strong>per</strong>azioni di lettura rispetto a quelle di scrittura.Il concetto di responsabilità sui nodi consente di limitare la propagazionedell’a<strong>per</strong>tura delle sessioni in scrittura all’interno del DAG. Ad esempio infigura 7.9.b si possono verificare 3 situazioni:1. nessuna delle richieste è effettuata dall’autorità responsabile della terzainformazione (info 3 ): nessuna sessione in scrittura è possibile sui nodi chehanno info 3 (compreso) come predecessore;2. solo una richiesta proviene dal responsabile di info 3 : solo uno può modificareinfo 3 ;3. entrambe le richieste provengono dal responsabile di info 3 : è una situazioneeffettivamente singolare, soprattutto alla luce sulle ipotesi fatte sull’unicitàdel responsabile, ma può presentarsi.176


<strong>InterDataNet</strong> Information ModelAuthoring concorrente(a)Req 1 Req 2(b)Req 1 Req 2Info1Info1Info2Info3Figura 7.9: Casi di authoring concorrenteAlla luce di queste considerazioni è indispensabile definire uno o più meccanisminecessari al controllo e alla gestione delle sessioni.7.8.1 Controllo delle sessioniCon questa prospettiva si individuano tre politiche di a<strong>per</strong>tura di una sessionein scrittura:• Strong.• Soft.• Relaxed.La Strong blocca sia in lettura che in scrittura tutti i nodi interessati dall’a<strong>per</strong>turadella sessione. Ad esempio, riconsiderando la figura 7.9.b, ed ammettendoche la prima richiesta accettata sia avvenuta su info 1 con modalità Strong,successive richieste di a<strong>per</strong>tura di sessione <strong>per</strong> la modifica di info 1 o semplicirichieste 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 a<strong>per</strong>turadi sessione in scrittura su info 1 , ma la possibilità di accedere all’informazioneverrebbe comunque garantita.Queste due tipologie di blocco <strong>per</strong>mettono la gestione della politica di accessoconcorrente turn-taking (un singolo individuo alla volta è abilitato ad apportarecambiamenti, gli altri di fatto non possono o<strong>per</strong>are). Come dimostrato in varicontesti questa politica, anche se comporta alcuni inconvenienti, può risultareutile o addirittura necessaria <strong>per</strong> certe tipologie di documenti.Ad esempio si consideri un documento costituito da un’unica immagine informato Jpeg (queste considerazioni sono valide <strong>per</strong> la maggior parte <strong>dei</strong> documenti,se non tutti, costituiti da un file in formato binario). Il formatoJpeg è tale che ad una modifica localizzata dell’immagine non corrisponda una177


<strong>InterDataNet</strong> Information ModelAuthoring concorrentemodifica 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 fonderei cambiamenti in un’unica immagine analizzando soltanto i file modificati senzacomprenderne la codifica (in questo caso si potrebbe ipotizzare che il sistema siain grado di decodificare le immagini, sovrapporle ricercando eventuali conflitti epoi codificare nuovamente il risultato dell’o<strong>per</strong>azione, ma nella pratica ciò nonè possibile <strong>per</strong> innumerevoli motivi e si potrebbero comunque trovare svariatiesempi <strong>per</strong> i quali tale o<strong>per</strong>azione 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 <strong>per</strong>derebbero il lavoro svolto eccetto uno (l’ultimo che “salva”, sovrascrivendoil documento esistente). L’unico modo <strong>per</strong> aggirare questo ostacoloè quello di ricorrere ad un blocco esclusivo del file facendo uso dell’approccioturn-taking.L’introduzione di due politiche di lock, la prima sia in lettura che in scritturala seconda solo in scrittura, risulta necessaria <strong>per</strong> garantire la massima flessibilitàdel modello del documento: come noto, negli ambienti concorrenti, possonoverificarsi casi in cui, all’interno della finestra temporale necessaria al completamentodelle o<strong>per</strong>azioni di modifica di un gruppo di dati, l’accesso in lettura adessi da parte di altri utenti potrebbe portare ad ottenere risultati inconsistenti.Per garantire che non si verifichino letture inconsistenti si ricorre alla politicaStrong. Quest’ultima è estremamente conservativa e se è possibile non inibirel’accesso in lettura in presenza di modifiche che richiedono l’acquisizione esclusivadella risorsa (sia <strong>per</strong>ché si riesce a garantire la consistenza <strong>dei</strong> dati letti inmodo diverso oppure <strong>per</strong>ché è possibile ritenere accettabile una certa probabilitàdi errore) si ricorre alla politica Soft che risulta essere meno conservativa evincolante.Infine la Relaxed consente l’authoring concorrente tramite l’approccio copymerge:ogni soggetto ha a disposizione una copia di sulla quale o<strong>per</strong>are poi adintervalli regolari le modifihe vengono fuse. Occorre specificare che, in questocaso, 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 nonsia sempre possibile individuare e risolvere i conflitti <strong>per</strong> certe tipologie di informazionirappresentate da un unico file (e quindi che normalmente verrannocodificate in un unico nodo IDN). Questo non esclude che <strong>per</strong> altre categorie diinformazioni codificate all’interno di un unico nodo IDN sia possibile determinarealgoritmi in grado di analizzarne e comprenderne il contenuto ed agire diconseguenza <strong>per</strong> quanto riguarda la rilevazione e la gestione <strong>dei</strong> conflitti. Unesempio che può essere citato riguarda l’authoring di codice sorgente: in questocaso si può modellare l’ambiente inserendo il contenuto di ogni file sorgenteappartenente al progetto all’interno di un’informazione atomica. In questo casoè abbastanza semplice comprendere come sia possibile analizzare il contenutodell’informazione atomica <strong>per</strong> stabilire se due utenti hanno modificato le medesimeporzioni di codice oppure porzioni diverse in modo da applicare le politiche178


<strong>InterDataNet</strong> Information ModelAuthoring concorrentedi gestione <strong>dei</strong> conflitti in modo equivalente agli SCM (Software ConfigurationManagement) [App08].La modalità Relaxed è più adatta ad essere usata in contesti nei quali l’accessoe la modifica <strong>dei</strong> dati avvengono da parte di più individui e <strong>per</strong>tanto,escludendo i casi particolari che devono essere gestiti ricorrendo alle politicheprecedenti, è quella da utilizzarsi preferibilmente.In ogni modo ricorrere alla tipologia “sessione Relaxed” nelle richieste discrittura, incrementa la consapevolezza ad alto livello in quanto <strong>per</strong>mette all’utentedi prendere atto del fatto che il documento (o parte di esso) è in fase diaggiornamento.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: splitcombineassociato a turn-taking oppure a copy-merge.179


Capitolo8<strong>InterDataNet</strong> ServiceArchitectureNel precedente capitolo è stato presentato il modello dell’informazione IDN-IM mettendo in evidenza la rappresentazione delle risorse informative da unpunto di vista teorico ed astratto. Dalla definizione di IDN-IM è necessarioadesso determinare i servizi necessari <strong>per</strong> implementare tale modello. In questocapitolo sarà discussa l’architettura a servizi di IDN come l’insieme <strong>dei</strong> servizinecessari <strong>per</strong> qualificare o<strong>per</strong>ativamente IDN-IM. Questa vista del sistemaprende il nome di <strong>InterDataNet</strong> Service Architecture (IDN-SA).IDN-SA si pone l’obiettivo di descrivere l’insieme di servizi ritenuti necessari<strong>per</strong> andare a gestire o<strong>per</strong>ativamente l’Information Model condiviso e porrequindi fondare un’architettura di riferimento in grado di offrire una soluzionea livello infrastrutturale al problema della condivisione collaborativa efficace edefficiente dell’informazione e concretamente <strong>dei</strong> dati.Le relazioni esistenti tra IDN-IM e IDN-SA sono schematicamente espressein figura 8.1. A livello applicativo, le applicazioni devono essere in grado di accettareed interpretare documenti IDN nello lo specifico contesto applicativo (es.fatture, moduli, testi, multimedia, ecc.). Sfruttando Application ProgrammingInterface (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à applicatain modo da lasciare maggiore libertà implementativa agli estremi della pila:a livello più basso <strong>per</strong> abilitare e rendere flessibile l’integrazione con tecnologieesistenti (tra cui legacy) ed a livello più elevato <strong>per</strong> consentire lo sviluppo diapplicazioni specializzate (in analogia al livello applicativo della pila Internet)in un contesto informativo.


<strong>InterDataNet</strong> Service ArchitectureApplications use IDN-IM to representpieces of information and documentsIDN Compliant ApplicationIDN APIsApplications interactwith IDN-IMthrough IDN-APIsIDN-IMIDN Service Architecture (IDN-SA)IDN-SA implements IDN-IMNetwork communicationand storage architectureFigura 8.1: Relazione tra IDN-IM e IDN-SASotto il livello applicativo il sistema deve essere ben orchestrato (capitolo1) in quanto l’applicazione stessa deve vedere un unico punto di accessologico al quale interfacciarsi all’architettura, indipendentemente dalla quanità ecomplessità <strong>dei</strong> servizi sottostanti.La stratificazione apporta considerevoli vantaggi <strong>per</strong> quanto riguarda la coreografia(capitolo 1) in quanto, imponendo <strong>dei</strong> rigidi vincoli o<strong>per</strong>ativi consentedi ridurre il numero delle possibili interazioni fra i vari servizi che costituisconol’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 principiispirati da SOA (capitolo 1) che da REST (capitolo 1). È opportuno sottolinearenuovamente che la definizione di SOA recepita da IDN riguarda i principigenerali come evidenziati in [Jos07].Ogni livello di IDN-SA caratterizza il comportamento delle risorse attraverso:• aggregazione e indirizzamento logico ed unitaro,• storicizzazione e <strong>per</strong>manente indicizzazione,• replicazione e indirizzamento uniforme,• memorizzazione fisica ed accesso.I servizi relativi a comportamenti fisici delle risorse sono posizionati a livellopiù basso e mentre i comportamenti astratti e logici (risalendo la gerarchia) sonocollocati ad alto livello.In figura 8.2 è riportata la pila <strong>dei</strong> servizi: IDN-SA si compone di quattrolivelli di servizi (core levels): Virtual Repository Service Layer, InformationHistory Service Layer, Replica Managenent Service Layer e Storage InterfaceService Layer. Agli estremi abbiamo tecnologie e contesti che sebbene esulinodalla specifica trattazione di IDN-SA rappresentano <strong>dei</strong> vincoli.Ciascun livello di servizi sarà di seguito introdotto e maggiori dettagli tecnicisaranno evidenziati nella Parte IV.Un’ultima importante osservazione sull’architettura di servizi riguarda ladefinizione <strong>dei</strong> servizi di indirizzamento e lo schema sintattico degli indirizzi181


<strong>InterDataNet</strong>Middleware<strong>InterDataNet</strong>Middleware<strong>InterDataNet</strong> Service ArchitectureIDN Compliant ApplicationVirtual Repository LayerInformation History LayerReplica Management LayerStorage Interface LayerFilesystem,database, etc.Generic storagearchitectureIDN APIsHTTP(S), SMTP(S),FTP(S), etc.Generic networkcommunication architectureFigura 8.2: Interdataworking in IDN(handle) <strong>per</strong> le risorse. In IDN-SA il sistema di indirizzamento assume unruolo strutturalmente portante e <strong>per</strong>meante: infatti ogni livello specializza ilmodo di nominare, individuare ed accedere alle risorse (dato che ad ogni livelloabbiamo rappresentazioni diverse con viste diverse, analogamente ai livelli dellapila Internet).L’applicazione della metodologia della separazione <strong>dei</strong> compiti rendere <strong>per</strong>òpossibile l’estrazione <strong>dei</strong> sotto-servizi dedicati ai nomi: dalla stratificazioneprecedentemente presentata è possibile costruire una stratificazione omologa,unicamente fondata sullo spazio di nomi, che prende il nome di IDN NamingService. In figura 8.3 è riportata la corrispondenza tra livelli di servizi e gliassociati spazi di identificatori. Sebbene nel presente capitolo il Naming Servicevenga trattato in modo integrato e contestuale, livello <strong>per</strong> livello, <strong>per</strong> le motivazionievidenziate e <strong>per</strong> la complessità del sistema, risulta caratterizzante unatrattazione dedicata, come argomentato nel capitolo 9.Virtual Repository LayerInformation History LayerReplica Management LayerStorage Interface LayerFilesystem,database, etc.Generic storagearchitectureService LayersIDN Compliant ApplicationIDN APIsHTTP(S), SMTP(S),FTP(S), etc.Generic networkcommunication architectureResource SpaceNamesIDN-IMnames [+v.p.]LRIs [+v.p.]PRIs [+v.p.]PRIsURLsPlatformdependentlocal names[+v.p.]optionalversionparameterFigura 8.3: Resource Space Names182


<strong>InterDataNet</strong> Service ArchitectureVirtual Repository Service8.1 Virtual Repository ServiceIl principale servizio offerto dal Virtual Repository Service (VR) è l’indirizzamentodelle risorse <strong>per</strong> consentirne la navigazione nello spazio delle informazioni.Attraverso la sua interfaccia è possibile indirizzare ed individuare lerisorse disponibili.Una volta individuata la risorsa, questa viene analizzata ed elaborata in manieracompletamente trasparente al richiedente. L’elaborazione consiste principalmentenel recu<strong>per</strong>are tutte le sottoinformazioni (Primitive Information Unit,PIU) di cui è composta. Eventualmente viene anche applicata una codifica dipresentazione, 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 documentoseguendo i collegamenti esplicitati nel nodo. Una volta che il documento è statocostruito, dovrà essere fornito all’applicazione che lo ha richiesto. L’applicazionesi occu<strong>per</strong>à 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”diuno 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 <strong>per</strong>corsi logici <strong>per</strong>sonalizzabili.A questo livello appartengono le entità virtuali discusse nel capitolo 5. Ciascunaentità non è altro che una risorsa che dovrà essere elaborata dalla logicainterna di VR prima di erogare il servizio richiesto.8.1.1 Resource Aggregation ServicePer esporre o<strong>per</strong>ativamente il compito di RAS ipotizziamo che un utentetramite la propria identità Persona indirizzi una Resource <strong>per</strong> visualizzarla. ARAS dovrà <strong>per</strong>venire il consenso se la Persona lo può fare o con quali limiti. Icontrolli sulla identità sono a carico di IS. Accertato che Persona risponda airequisiti richiesti, RAS inizia a recu<strong>per</strong>are tutti i nodi (PIU) del documento,scendendo in pronfondità nella struttura DAG. Se necessario richiede ulterioriverifiche ad IS.Una volta che RAS ha terminato di recu<strong>per</strong>are le informazioni è in gradodi costruire materialmente una istanza entro-contenuta in un macro-documentoaggregato. Non spetta a RAS interpretare il documento così costruito in quantonon possiede una specifica intelligenza applicativa.183


<strong>InterDataNet</strong> Service ArchitectureVirtual Repository ServicePer effettuare la corretta selezione delle versioni <strong>dei</strong> nodi, esplorando in profonditàil DAG, RAS si avvale <strong>dei</strong> servizi offerti dal livello sottostante InformationHistory Service (IH).Le modalità con cui RAS verifica se la Persona soddisfa requisiti richiesti<strong>per</strong> l’accesso sono determinati dal principio di responsabile dell’informazione. Ilresponsabile oltre a stabilire la validità e la veridicità di una informazione indicaanche le regole con cui può essere acceduta e quindi le politiche di accesso inlettura e scrittura.Non è compito di RAS o<strong>per</strong>are direttamente sulle versioni della risorsa, masarà comunque onere di questo livello richiedere al livello sottostante i servizinecessari <strong>per</strong> gestirle e relazionarle correttamente nel tempo.In maniera del tutto duale alle aggregazione il servizio RAS si occupa dellapropagazione delle versioni, introdotta nel capitolo 7 <strong>per</strong>correndo i link strutturalidi propagazione (delle modifiche), che concettualmente equivale a <strong>per</strong>correrei link di aggregazione in senso contrario.La modifica di una risorsa prevede la propagazione dell’aggiornamento delnumero di versione ai padri del nodo, quindi la propagazione risale ricorsivamentefino alla radice del documento.Revision 1 Revision 2Av1A Av1 v2Bv1Cv1B Bv2 v2Cv1Dv1Ev1Update on achild resourceDv1E Ev1 v2Figura 8.4: Revisioni successive di documenti UEVMIn figura 8.4 è esemplificato quello che succede dopo una modifica di unarisorsa: il nodo figlio “E” viene modificato e quindi verrà creata una nuova versionedella 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 è <strong>per</strong> questo motivo che è necessarioversionare 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 “Ev2”.Ricordando che IDN fa riferimento quasi integralmente al modello UEVM(Unified Extensional Versioning Model) [ABCM99] <strong>per</strong> definire il controllo diversione. UEVM stabilisce che le versioni di documenti strutturati siano alberi(Direct Acyclic Graph), ma è stato esteso <strong>per</strong> essere applicato a DAG, ovverografi in cui si hanno archi orientati e non esistono cicli. L’orientamento delcollegamento tra due risorse stabilisce una relazione di padre e figlio tra di esse.184


<strong>InterDataNet</strong> Service ArchitectureVirtual Repository ServiceIH possiede così la proprietà di riuscire a versionare sia l’evoluzione <strong>dei</strong> contenutiche degli aspetti strutturali.È proprio questo l’aspetto interessante di UEVM: <strong>per</strong>mette alla sua applicazionedi tenere traccia non soltanto dello storico delle singole risorse, ma anchela struttura che queste hanno assunto nel tempo.8.1.2 Logical Domain Name ServiceUna medesima risorsa può essere nominata in modo diverso e collocata incontesti diversi pur mantenendosi invariabile da un punto di vista di contenuti.Ciò è realizzato assegnando a ciascuna risorsa un nome logico canonico a cuivengono 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’identificativocanonico e l’identificativo e <strong>per</strong>sistente avvalendosi, a partire da un qualsiasialias. LDNS è un servizio distribuito e come tale utilizza, quando necessario,uno o più istanze di servizi <strong>per</strong> la risoluzione di un Logical Resoirce Identifier.LDNS è costituito da un vasto database di nomi distribuito, detti LogicalResource Identifier (LRI). Un LRI sintatticamente può possedere un parametrodi versione <strong>per</strong> indicare quale istanza temporale deve essere selezionata.I Logical Resource Identifier sono stati introdotti <strong>per</strong> identificare all’internodell’ambiente virtuale le entità logiche. Il suo formato è stato definito in modotale da essere mnemonico, facilmente usabile e trascrivibile dall’utente, riconducibilead un contesto e completamente indipendente dalla locazione fisica dellerisorse.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 9.8.1.3 Identity ServiceTutti i sistemi collaborativi necessitano di un sottosistema <strong>per</strong> le gestionedelle identità sopratutto quando l’oggetto delle elaborazioni è costituito darisorse condivise.Quindi il layer VR assicura che:• l’identificazione dell’utente avvenga contestualmente alla sua proiezionenel sistema, ovvero tramite la sua identità Persona;• il responsabile abbia stabilito quali Persona sono autorizzati ad accederein lettura e/o in scrittura ad una data informazione;• ogni azione effettuata sulle risorse sia associata ad una Persona (eventualmenteanonima).Il controllo di accesso in lettura e/o in scrittura non è effettuato esclusivamentea livello VR, ma è a questo livello in cui si ha vanno ad istanziare leentità Persona e le risorse su cui esse agiscono. Inoltre, essendo il livello più185


<strong>InterDataNet</strong> Service ArchitectureInformation History Serviceelevato della pila ed il punto logico di accesso al sistema, rappresenta il serviziopiù esposto e critico.8.2 Information History ServiceNello strato di Information History (IH) troviamo un il servizio che ha ilcompito del controllo di versione e di erogare il servizio di navigazione nellospazio delle versioni. Il servizio principale dà il nome al livello.Si comporta come un filtro che intercetta le o<strong>per</strong>azioni che modificano lerisorse, ne controlla il numero di versione e tiene traccia delle revisioni, diramazionie merge, come nelle diffuse tecniche di versioning. Grazie ad IH è possibilerichiedere una risorsa come istanza storica, in uno <strong>dei</strong> suoi stati assunti, dallasua creazione fino al tempo attuale attuale.Come si è visto nel capitolo 7 i dati in IDN sono collegati strutturalmente condue principali tipologie di relazione: link di riferimento e link di aggregazione,ma anche storicamente. Qui si introduce l’ulteriore tipologia di link, propriadi questo livello: link di versioning. Per rendere possibile lo spostamento nelpassato e nel futuro a partire da una data istanza, i link di versioning possoassumere due direzioni: up e down.Il documento da versionare è visto quindi come una istantanea di risorse e direlazioni di composizione che le legano. Due documenti distinti possono esserecollegati soltanto da link di riferimento, come previsto in IDN-IM.Ogni risorsa di questo livello è dotata di un identificatore costituito da unaparte <strong>per</strong>sistente, chiamata Persistent Resource Identifier (PRI), ed un parametrodi versione (PARVER) sintatticamente giustapposto (indicato opzionalmentedal livello soprastante VR). Un PRI individua in maniera univoca ed immutabileuna informazione: una volta assegnato o comunque utilizzato non viene piùriusato.Il sottoservizio interno al livello che rende possibile la navigazione all’internodi uno storico è detto IDN Version Traversing Service (VTS). Si tratta propriamentedi un algoritmo non distribuito che iterativamente scorre in avanti (up)o indietro (down) la catena delle versioni in accordo al parametro di versioneindicato.8.2.1 Version Traversing AlgorithmIl livello VR, grazie alla risoluzione di LDNS, chiede al livello IH una risorsaindividuata con PRI+PARVER. VTA è in grado di spostare l’handle dallaversione indicata da PRI ad una diversa sulla base del parametro di versione. Ilmeccanismo è tutto localizzato su una istanza di servizio, diversamente da quantoavviene <strong>per</strong> 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 ottenerei contenuti informativi (<strong>per</strong> il momento l’elaborazione è limitata al soloidentificatore). Notiamo comunque che durante le interazioni è necessario leggerei metadati relativi ai link di versione del nodo correntemente selezionatocontestualmente alla verifica <strong>dei</strong> diritti di accesso.186


<strong>InterDataNet</strong> Service ArchitectureReplica Management ServiceA tutti gli effetti VTA effettua una trasformazione da PRI+PARVER in unPRI. Questo identificatore viene utilizzato <strong>per</strong> chiedere al livello sottostante icontenuti informativi ed eventuali metadati.8.3 Replica Management ServiceIl livello Replica Management è specializzato nella gestione delle replichedelle informazioni. Replicare una informazione significa copiarla in differentiapparati e mantenere tali copie equivalenti nel tempo (a meno della latenza). Lesingole repliche delle informazioni, che come insieme sono identificate attraversoun PRI, sono singolarmente indirizzate ed accedute tramite URL [BLMM94].L’uso delle URL è determinato dal fatto che la logica dello strato ha bisogno diaccedere fisicamente alla risorsa.Replica Management Service eroga il servizio di “valorizzazione” della risorsalogica: viene ricercata e acquisita (eventualmente convertita nella codifica IDN)una istanza nell’insieme di repliche disponibili. La selezione della replica avvienenella maniera “migliore”: sulla base delle politiche di replicazione adottate equalità del servizio (QoS) prevista.Il secondo servizio presente nel layer VR è Localization Service (LS), il serviziodi risoluzione che <strong>per</strong>mette di ottenere l’elenco delle URL (identificatori dibasso livello) dato un PRI.Il principale compito di questo livello è principalmente la sincronizzazionedelle repliche ed il mantenimento della loro consistenza nel tempo.RM decide il sito da cui prelevare o su cui scrivere le informazioni in baseall’URL della replica, realizzando una sorta di instradamento delle richiesteprovenienti dall’alto.Gli obiettivi del servizio di gestione delle repliche sono riassumibili nei seguentipunti:• 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 gestionemira a distribuire le richieste verso le repliche in modo da ridurre i singoli carichidi elaborazione, che altrimenti sarebbero concentrati verso un esiguo gruppo dihost.8.3.1 Replica ManagementLe istanze <strong>dei</strong> servizi di replica management hanno l’incarico di gestire l’accessoconcorrente alle risorse e fornire un sistema efficace di replicazione dellestesse.Da un punto di vista di coreografia interna al livello <strong>dei</strong> servizi, il livello RMha come protagonista il servizio stesso di Replica Management che interagiscecon LS, con altri RM, con il livello sottostante di Storage Interface ed il livellosoprastante di Information History.187


<strong>InterDataNet</strong> Service ArchitectureStorage Interface ServiceInformation HistoryLayerInformation HistoryServiceReplica Management LayerLocalizationServiceReplica ManagementServiceReplica ManagementServiceStorage Interface LayerStorage InterfaceServiceStorage InterfaceServiceStorage InterfaceServiceFigura 8.5: Coreografia al livello di Replica ManagementI legami tra i servizi sono illustrati in figura 8.5.La sequenza tipica <strong>dei</strong> messaggi si svolge in questo modo:1. il livello su<strong>per</strong>iore 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 su<strong>per</strong>iore contenente leinformazioni inizialmente richieste.8.3.2 Localization ServiceIl Localization Service (LS) è un servizio distribuito analogo ad LDNS chea fronte di una richiesta di risoluzione di un PRI fornisce l’elenco ordinato dirisorse fisicamente accessibili (URL).Per una discussione più approfondita si rimanda al capitolo 9.8.4 Storage Interface ServiceIl livello più basso di IDN è detto Storage Interface in quanto si occupa didefinire l’interfaccia verso i sotto-sistemi di storage esistenti. Il servizio <strong>per</strong>mettequindi di memorizzare e gestire risorse sulle piattaforme sottostanti (ancheeterogenee), esponendo verso il livello su<strong>per</strong>iore un’interfaccia uniforme,indipendentemente dalle particolarità tecnologiche mascherate.Dal punto di vista dell’architettura, l’accesso fisico alle risorse è effettuatoa questo livello. Le risorse possono essere memorizzate su filesystem, databaselocali o remoti oppure generate dinamicamente da una qualunque sorgente.L’interfaccia prevede indirizzamento tramite URL, tipologia di indirizzi chesono stati introdotti proprio con la finalità di identificare ed accedere entità di188


<strong>InterDataNet</strong> Service ArchitectureStorage Interface Servicelivello applicativo Internet. Ogni risorsa avrà quindi un proprio URL che laidentifica e ne <strong>per</strong>mette l’accesso.È necessaria la precisazione sul concetto stesso di “risorsa”: a questo livellole risorse sono definite come un insieme strutturato di dati e metadati (identificatitramite un unico URL). L’uso più naturale che ne può essere fatto è quellodi andare a memorizzare repliche di risorse (logiche) definite al livello su<strong>per</strong>ioreRM. In realtà la rappresentazione delle risorse di questo livello è del tuttogenerale, nel senso che rappresentano unità informative indipendentemente dalmodello di <strong>InterDataNet</strong>.L’interfaccia uniforme esposta da SI non può prescindere dai concetti diURL, dati e metadati e si sviluppa intorno alle o<strong>per</strong>azioni base CRUD:• creazione: o<strong>per</strong>azione che va a sancire la nascita di una nuova risorsa,eventualmente vuota, grazie alla allocazione di spazio (fisico o logico) necessario<strong>per</strong> la memorizzazione, fornendo al livello su<strong>per</strong>iore l’handle <strong>per</strong>accederci;• modifica: o<strong>per</strong>azione che consente di aggiornare il contenuto di una risorsagià esistente;• lettura: o<strong>per</strong>azione che <strong>per</strong>mette di ottenere il contenuto della risorsa;• cancellazione: o<strong>per</strong>azione che va ad eliminare una risorsa già esistente,“liberando” handle e spazio.Focalizzando l’attenzione sui dati e <strong>dei</strong> metadati, notiamo che il livello offreun arbitraria granularità di memorizzazione ed indirizzamento.8.4.1 Integrazione di sistemi legacyCome introdotto nel sotto paragrafo precedente, uno degli scopi di SI è quellodi esporre risorse ai livelli su<strong>per</strong>iori tramite un’interfaccia uniforme.Virtual Repository LayerInformation History LayerReplica Management LayerSI APIStorageServiceSI API SI API SI API SI APIStorageServiceEnterpriseInformationServiceMediaStorageServiceSocialNetworkServiceSQLdatabasefile systemEnterprise EnterpriseDatabaseEnterpriseDatabase DatabaseFlickrYouTubesocial networkFigura 8.6: Storage Interface e Legacy Storage InterfaceRealizzando una applicazione che espone tale API significa implementare unservizio di storage <strong>per</strong> IDN. Le proprietà definite dalle specifiche dell’interfaccia189


<strong>InterDataNet</strong> Service ArchitectureStorage Interface Servicefanno sì che su tale applicazione si possa montare lo stack <strong>dei</strong> livelli su<strong>per</strong>iori<strong>per</strong>mettendo quindi, come anticipato, di andare ad utilizzare una moltitudineeterogenea di soluzioni <strong>per</strong> lo storage fisico.In figura 8.6 si può vedere una esemplificazione, dove gli strati su<strong>per</strong>ioridi IDN pongono le loro basi su una varietà di differenti servizi di storage,implementati con tecnologie diverse.Questo aspetto è di particolare importanza principalmente <strong>per</strong>ché:• la realizzazione di istanze specializzate di Storage Interface Service <strong>per</strong>mettealle organizzazioni interessate di integrare i loro sistemi in IDN (es.legacy);• aprire l’integrazione alle <strong>nuove</strong> soluzioni <strong>per</strong> lo storage.190


Parte IV<strong>InterDataNet</strong>: servizi esottosistemi


Capitolo9IDN Naming ServiceAllo stato attuale, le risorse nel Web vengono indirizzate attraverso gli UniformResource Identifier (URI)[BLFM98]. La tipologia più diffusa ed utilizzatadi URI è certamente l’Uniform Resource Locator (URL) [BLMM94], che puòessere utilizzata sia <strong>per</strong> identificare la risorsa che <strong>per</strong> accedere alla stessa medianteun determinato protocollo (espresso nello schema sintattico della stessaURL).Si precisa che lo schema <strong>dei</strong> nomi è un insieme di regole <strong>per</strong> la creazioneed 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. Innanzitutto una soluzione basata sui soli URL risulta poco scalabile poichè l’identificazionedi una risorsa e il suo indirizzamento rispondono a requisiti diversi. Insecondo luogo una tale soluzione risulta poco robusta nel caso in cui una risorsacambi locazione all’interno della rete oppure venga sostituita da un’altra risorsaavente un contenuto completamente differente. Inoltre un sistema basato sui soliURL non consentirebbe di disporre di una tipologia d’indirizzamento adeguataa gestire insiemi di repliche eventualmente associate ad una risorsa logica. Atitolo di esempio si consideri il caso tipico in cui una pagina Web debba esserereplicata al fine di aumentarne la disponibilità in rete: una soluzione in cui adogni replica viene assegnato un proprio URL non sarebbe sufficiente. Infatti essanon consentirebbe di nascondere l’insieme di repliche alle applicazioni client,<strong>per</strong> lo sviluppo delle quali sarebbe desiderabile avere l’impressione di interagirecon una singola entità non replicata.In sintesi un URL consente:• indirizzamento;


IDN Naming Service• accesso.con lo svantaggio di essere vincolato a:• schema sintattico;• locazione fisica.Allo scopo di risolvere tali problematiche è stata introdotta un’ulterioretipologia di identificatori: l’Uniform Resource Name (URN) [Mea02, SM94,ADD + 96, LPD98]. Un URN è un particolare tipo di URI che, a differenzadegli URL, pur identificando una risorsa, non fornisce alcun mezzo <strong>per</strong> accedervi.Infatti un URN non contiene informazioni variabili nel tempo, come adesempio la locazione della risorsa, ma costituisce un identificatore <strong>per</strong>sistente edunivoco delle risorse presenti nel Web. In ambito editoriale un valido esempiodi URN è il codice ISBN (International Standard Book Number), che viene univocamenteassegnato a ciascuna edizione di ogni materiale stampato co<strong>per</strong>to dadiritti 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 identificatoreche consenta l’accesso alla risorsa, ossia un URL. Il processo di determinazionedegli URL di una risorsa a partire dal suo URN è detto risoluzione (analogamenteal processo che determina IP da URI). L’impiego combinato di URN eURL, separando le funzioni di indirizzamento ed identificazione delle risorse indue passi distinti, <strong>per</strong>mette di risolvere il problema dell’indirizzamento di unarisorsa Web, nel suo insieme di repliche. A tal proposito l’idea di fondo consistenell’utilizzare un URN, <strong>per</strong> identificare l’intero insieme delle repliche diuna risorsa, e più URL <strong>per</strong> identificare le locazioni in cui le varie repliche sonomemorizzate. Inoltre data la natura degli identificativi <strong>per</strong>sistenti e globalmenteunici, gli URN <strong>per</strong>mettono di spostare le risorse all’interno del Web senzache tali movimenti impediscano ad un utente di accedere ad una determinatarisorsa (ovviamente a patto che i corrispondenti dati della risoluzione venganoaggiornati in modo coerente alla nuova locazione della risorsa).Pur contribuendo alla soluzione delle suddette problematiche, gli URN nonsoddisfano i canoni di utilizzo richiesti da un’utenza umana: a differenza di uncalcolatore, necessita di nomi facilmente intellegibili e condivisibili <strong>per</strong> indicareconcetti e contenuti.Utilizzare un directory service, come ad esempio LDAP [HM02], <strong>per</strong>mettaagli 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 paradigmadi tipo client-server in cui ad una richiesta effettuata dal client, il server rispondecon la risorsa desiderata oppure con l’indirizzo di un altro server cui girare larichiesta.In figura 9.1 è esemplificata la tipica struttura di una directory LDAP, in cuisono memorizzate alcune informazioni relative ad un’organizzazione. Il principalesvantaggio di questa soluzione risiede nella limitata scalabilità, esplicatadal fatto che non sono ancora stati sviluppati directory service su larga scala.Il secondo approccio, come suggerito in [Mea02], prevede l’introduzione diuna nuova tipologia di URI che abbiano la duplice caratteristica di essere di facile193


IDN Naming Servicedc=net dc=com dc=DEOrganizzazionedc=AcmeUnità organizzativaPersonaou=Peopleou=Serversou=John DoeFigura 9.1: Albero di directory LDAPutilizzo <strong>per</strong> l’uomo e in grado di interagire con gli URN al fine di identificarele risorse. Questi identificativi di alto livello vengono tipicamente indicati comeHuman Friendly Name (HFN) proprio <strong>per</strong> evidenziare come essi siano statipensati <strong>per</strong> essere a misura d’uomo. Infatti a differenza degli URN, gli HFNconsentono l’uso esplicito di nomi descrittivi.Nel momento in cui un utente vuole accedere ad una risorsa, un HFN devepoter essere risolto in un URL. A causa <strong>dei</strong> problemi di gestione delle replicheintrodotti dagli URL, non è possibile realizzare questo servizio di traduzionein maniera diretta, ma occorre suddividerlo in due fasi: nella prima si risolvel’HFN in URN, mentre nella seconda l’URN in URL. In sintesi si utilizza unsistema 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 utentipossono assegnare alle risorse nomi di convenienza, ovviamente rimanendo entroi limiti di ordine tecnico e tecnologico imposti dal sistema. Inoltre se una risorsaviene replicata o spostata in un’altra locazione, questo non produce effettisull’HFN. Infine un utente può scegliere di utilizzare nomi diversi <strong>per</strong> la stessarisorsa, allo stesso modo con cui vengono usati gli alias negli indirizzi di postaelettronica o nei link simbolici del file system.Nel suo complesso il meccanismo di risoluzione da HFN ad URL deve esserein grado di supportare un enorme numero di risorse, eventualmente distribuitesu una vasta area geografica. Il modello di risoluzione, proposto nel presentecapitolo, si propone di soddisfare tale requisito utilizzando un sistema di nomigerarchico simile a quello adottato dal DNS, essendo ampiamente provatoil funzionamento di quest’ultimo su larga scala. In particolare in tale modello,194


IDN Naming ServiceRequisiti <strong>dei</strong> nomiche recepisce i principi basilari presenti negli standard DOI[BMR + 06] e XRI,si è scelto di denominare gli HFN come Logical Resource Identifier (LRI) e gliURN come Persistent Resource Identifier (PRI). La motivazione di tale sceltarisiede nel fatto che LRI e PRI costituiscono una particolare specializzazione osottocaso di HFN ed URN. Nel seguito del presente capitolo verranno analizzatidettagliatamente i vari elementi del modello a partire dalla definizione delsistema <strong>dei</strong> nomi. In secondo luogo verranno descritti i sistemi di risoluzione diun LRI in un PRI e di un PRI in un insieme di URL. Infine verrà presentato unsistema di risoluzione che a partire da un URL, relativo ad una replica di unarisorsa, <strong>per</strong>mette di risalire al rispettivo PRI e quindi a tutti i possibili LRI.9.1 Requisiti <strong>dei</strong> nomiLe tipologie di nome introdotte nel paragrafo precedente (HFN, URN e URL)vengono utilizzate <strong>per</strong> finalità diverse. Mentre <strong>per</strong> URN ed URL esistono dellespecifiche standardizzate, <strong>per</strong> gli HFN esiste una forte esigenza, ma nessunvincolo precisamente dichiarato. In particolare i requisiti di base degli URNcoincidono con quelli degli URI (Uniform Resource Identifier), in quanto gliURN ne costituiscono un sottoinsieme.In questo paragrafo verranno formulati i requisiti degli HFN e riportati quellidegli URN al fine di delineare le principali caratteristiche e presupposti <strong>per</strong> ladefinizione <strong>dei</strong> rispettivi spazi di nomi. Per quanto riguarda gli URL il sistemaè completamente definito in [BLMM94].9.1.1 Requisiti <strong>per</strong> gli HFNIn 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<strong>per</strong> indicare concetti e contenuti di una risorsa;Requirement LDNS-R002 mnemonici.Gli HFN devono essere facilmente memorizzabili e tali da poter essere ricondottiad un contesto ben preciso;Requirement LDNS-R003 riferiti al contesto.Gli HFN devono essere legati alla struttura del contesto relativamente alquale rappresentano i nomi delle entità. Questa proprietà è desiderabile inquanto contribuisce a rendere più semplice e familiare <strong>per</strong> gli utenti l’uso degliHFN;Requirement LDNS-R004 interpretabili.Pur dovendo essere il più possibile amichevoli <strong>per</strong> l’uomo, gli HFN devonoanche poter essere facilmente analizzabili e interpretabili da un calcolatorepoichè l’indirizzamento e quindi l’effettivo re<strong>per</strong>imento delle risorse dipendonodirettamente da questo aspetto;195


IDN Naming ServiceRequisiti <strong>dei</strong> nomiRequirement LDNS-R005 indipendenti dalla localizzazione fisica.Gli HFN devono essere completamente trasparenti rispetto alla locazionedelle risorse fisiche cui sono associati. Una conseguenza di tutto ciò è il cosiddettomascheramento che consiste nel nascondere la differente collocazione fisicadi risorse che risultano strettamente collegate da un punto di vista concettuale;Requirement LDNS-R006 essenziali.Gli HFN devono essere sintatticamente composti da parole semplici.9.1.2 Requisiti <strong>per</strong> gli URNAllo scopo di identificare una risorsa in modo univoco, durevole ed indipendentedalla sua effettiva dislocazione, le attività di ricerca legate ad Internet eguidate dall’Internet Engineering Task Force (IETF), hanno iniziato lo sviluppouna 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’architetturaURN, i cui requisiti funzionali sono specificati in [LPD98]. In ognicaso le linee guida su cui è stato basato finora lo sviluppo delle URN sono cosìsintetizzabili:Requirement LS-R007 schemi <strong>dei</strong> nomi e sistemi di risoluzione.Occorre effettuare una distinzione ben precisa tra i concetti di schema <strong>dei</strong>nomi e di sistema di risoluzione relativi agli URN. In particolare lo schema <strong>dei</strong>nomi relativo agli URN deve essere completamente indipendente da qualsiasispecifico sistema di risoluzione degli stessi. Come conseguenza di ciò si ha cheogni sistema di risoluzione deve essere potenzialmente in grado di risolvere unURN appartenente ad un qualunque schema <strong>dei</strong> nomi;Requirement LS-R008 compatibilità con tecnologie precedenti.Gli URN devono poter essere incorporati in schemi di nomi preesistenti relativia documenti, indici, e sistemi online. In particolare se uno schema <strong>dei</strong> nomicessa di essere supportato nella sua forma originaria, l’architettura relativa agliURN deve continuare a supportare gli URN riconducibili a tale schema, mediantel’impiego di sistemi di risoluzione alternativi. In questo modo gli utenti cheassegnano un URN ad una risorsa online non rischiano che tale identificativodiventi obsoleto;Requirement LS-R009 registrazione.Dal momento che lo schema <strong>dei</strong> nomi e il servizio di risoluzione relativi agliURN sono indipendenti, è necessario che l’applicazione che interagisce con unURN sia in grado di individuare in maniera autonoma quali sistemi risolutivisono in grado di risolvere tale identificativo. Il procedimento con cui avviene ciòè detto registrazione e prevede l’interazione tra un applicazione server, capacedi memorizzare in appositi registri più servizi di risoluzione <strong>per</strong> ogni schemaURN, e di un client che richiede la consultazione del registro appropriato nelmomento in cui tenta di risolvere un nome. È bene osservare come l’utilizzo di196


IDN Naming ServiceRequisiti <strong>dei</strong> nomiun paradigma di tipo client-server contribuisca notevolmente al mantenimentodell’indipendenza tra gli schemi <strong>dei</strong> nomi e i sistemi di risoluzione relativi alleURN.Per concludere la presente panoramica sugli URN, si riporta uno stralciotratto 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 particolarepresentazione di un contenuto logico, o qualunque cosa un’autoritàdi assegnazione <strong>dei</strong> nomi determini essere un’entità distintamenterichiamabile. La risorsa identificata da un URN può risiedere inuna o più ubicazioni ad ogni istante, può muoversi, oppure può nonessere disponibile. Certamente, non tutte le risorse si muoverannodurante il loro ciclo vitale, e non tutte le risorse, sebbene identificabilie identificate da un URN, saranno istanziate in ogni istante.Dal momento che un URL rappresenta il posto in cui una risorsapuò risiedere, o un contenitore, questa risulta distinta dalla risorsastessa che viene rappresentata dal URN.In ogni caso, affinchè gli URN soddisfino tutti i requisiti previsti, devonoessere: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 <strong>per</strong>sistenti.Dopo che un URN è stato creato, esso rimane associato ad una risorsa <strong>per</strong>almeno tutto il tempo in cui tale risorsa continua ad esistere. Infatti se la risorsaviene 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 <strong>per</strong> sempre e può essere utilizzato <strong>per</strong> riferire una risorsaoltre il suo stesso tempo di vita;Requirement LS-R013 scalabili.Gli URN possono essere assegnati a qualsiasi risorsa che deve essere mantenutain rete <strong>per</strong> un tempo indefinito;Requirement LS-R014 integrabili con il legacy.Lo schema deve <strong>per</strong>mettere il supporto a sistemi di nomi già esistenti, comead esempio DOI (Digital Object Identifier) [BMR + 06] e ISBN;197


IDN Naming ServiceRequisiti <strong>dei</strong> nomiRequirement LS-R015 estendibili.Lo schema relativo agli URN deve essere tale da supportare eventuali estensionifuture, così da <strong>per</strong>mettere la crescita dello spazio <strong>dei</strong> 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 unURL.Requirement LS-R017 indipendenti.L’autorità che assegna gli URN è l’unica responsabile delle condizioni sull’emissione<strong>dei</strong> nomi.È immediato osservare come i suddetti requisiti siano focalizzati su caratteristichedi tipo non funzionale, poichè non contengono alcuna affermazione sullerisorse identificate. Da un punto di vista funzionale va invece evidenziato comegli URN siano stati appositamente ideati allo scopo di semplificare la gestionedelle repliche con particolare riguardo agli aspetti relativi alla mobilità edevoluzione.Infine, l’aver affermato che un URN è <strong>per</strong>sistente 1 , cioè che ha un lungotempo di vita, comporta assumere come valide le seguenti proprietà:Requirement LS-R018 mobilità.Le repliche possono muoversi fisicamente da una macchina all’altra; i responsabilipossono spostarsi all’interno dell’organizzazione oppure le organizzazioniautoritative possono unirsi, trasformarsi o dividersi.Requirement LS-R019 evoluzione.Il sistema è continuamente in evoluzione cioè nuovi sottosistemi e protocollipossono essere creati ed i vecchi aggiornati.9.1.3 Requisiti sulla codifica <strong>per</strong> HFN e URNIn aggiunta ai precedenti requisiti ne esistono ulteriori, relativi alla codificae valevoli sia <strong>per</strong> HFN che <strong>per</strong> URN. Pertanto entrambe le classi di nomi devonoessere:Requirement LDNS+LS-R001 coerenti ad altre codifiche.La codifica deve essere (quanto più possibile) coerente con altri schemi dinomi già esistenti;Requirement LDNS+LS-R001 semplici nel confronto.L’algoritmo <strong>per</strong> 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 immutabilee <strong>per</strong>sistente, in quanto la mutabilità della risorsa a cui esso si riferisce è indipendentedall’identificatore stesso.198


IDN Naming ServiceLogical Resource Identifier (LRI)Requirement LDNS+LS-R001 trascrivibili dall’uomo.Per l’uomo deve essere possibile trascrivere gli URN (<strong>per</strong> gli HFN tale requisitorisulta particolarmente critico <strong>per</strong>cui tale o<strong>per</strong>azione 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 essereidenticamente trasportabili sia nei messaggi <strong>dei</strong> 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 diun testo che li contiene.9.2 Logical Resource Identifier (LRI)Gli LRI sono la particolare tipologia di HFN introdotta con il presente sistema<strong>dei</strong> nomi <strong>per</strong> offrire agli utenti umani, come tale, la maggior libertà possibilenella scelta <strong>dei</strong> nomi, senza tener conto <strong>dei</strong> rigidi criteri decisionali imposti daun calcolatore.Si definisce quindi identificatore logico di una risorsa (LRI, Logical ResourceIdentifier) 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“/”, rappresentail <strong>per</strong>corso. L’ultima entità è quella che si vuole individuare. L’intero <strong>per</strong>corsoassieme 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 utilizzabile <strong>per</strong> la definizione<strong>dei</strong> nomi è quello definito nel contesto degli URI [BLFM98].Questa soluzione è stata scelta in base a quelle che sono state ritenute leesigenze attuali del progetto e può essere estesa, in modo da <strong>per</strong>mettere l’agevolecodifica di stringhe appartenenti anche ad altri idiomi, nel momento incui questo risulti necessario. A tal proposito è possibile fare riferimento agliInternationalized Resource Identifiers (IRI) descritti in [DS05].A titolo di esempio si consideri il caso in cui un LRI sia utilizzato <strong>per</strong> identificareuna risorsa documentale relativa ai dati anagrafici di una <strong>per</strong>sona: appareevidente come tale risorsa possa essere utilizzata in contesti differenti quali lapatente, la carta d’identità, eccetera. Ognuno di questi contesti è strutturatosecondo una gerarchia ben definita che nel caso della patente potrebbe essere la199


IDN Naming ServiceLogical Resource Identifier (LRI)seguente: italia → ministeri → Ministero delle Infrastrutture e <strong>dei</strong> Trasporti →Motorizzazione civile → anagrafe patentati. Nell’ambito di tale contesto risultaovvio che il formato di un LRI, relativo ai dati anagrafici, dovrà rispecchiare larelazione gerarchica che intercorre tra i concetti di Ministero, Motorizzazione edi patente. In altri termini il formato degli LRI deve essere tale da poter descrivereuno spazio <strong>dei</strong> nomi gerarchico del tutto analogo a quello degli hostnameche, si ricorda, è gerarchicamente suddiviso in domini.Al fine di soddisfare tutte queste proprietà, si è scelto di progettare la grammaticarelativa agli LRI a partire dallo standard proposto da OASIS e concretizzatosinello schema XRI [KW95]. Infatti tale schema, estendendo in manierasignificativa la sintassi delle URI e degli IRI, consente di disporre di una seriedi proprietà addizionali che ben si adattano alle principali necessità degli LRI.9.2.1 GrammaticaIn questa sezione viene illustrata la sintassi relativa agli LRI, facendo riferimentoad una rappresentazione conforme alla Augmented Backus-Naur Form(la rappresentazione ABNF è descritta in appendice A). In ogni caso si premetteche la sintassi LRI è stata appositamente definita nel modo più generale possibile,al fine di poterla successivamente estendere anche a contesti specifici chenon costituiscono un argomento della presente trattazione. Il formato completodi un LRI è definito in figura 9.2.::= ::= "lri://"() ::= (/)* ::= ::= ::= ";" | ":" | "&" | "=" | "+" | "$" | "," |"-" | "_" | "." | "!" | "~" | "*" | "’" |"(" | ")" | "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 LRIFacendo riferimento all’esempio relativo ai dati anagrafici di una <strong>per</strong>sona,alcuni LRI ben formati sono:lri://it/comune/firenze/anagrafe/1997/atto3375p5sIlri://it/ministero/trasporti/anagrafe_patentati/1900/FI4456K18.12.1920lri://istat/cittadini/FI/1980/RSSMRA00A01D612D200


IDN Naming ServicePersistent Resource Identifier (PRI)Eventualmente i client possono applicare delle semplificazioni con la finalitàdi rendere i nomi ancora più amichevoli: potrebbero essere previsti il completamentoautomatico 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 vaeseguita procedendo da sinistra verso destra: segue che il segmento più autoritativo,a partire dal quale viene applicato il processo di risoluzione, è quello che sitrova all’estrema sinistra. Poiché la risoluzione di ogni segmento fornisce comerisultato 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 <strong>dei</strong> nomi è necessario un Authority, che eventualmentepuò coincidere con l’utente stesso.9.3 Persistent Resource Identifier (PRI)Equivalentemente a quanto fatto <strong>per</strong> gli LRI (paragrafo 9.2),nel presentelavoro si andrà a definire una particolare categoria di URN, detta PersistentResource Identifier (PRI ), in modo da aver a disposizione uno spazio di nomi<strong>per</strong>sistenti (e conformi sotto ogni punto di vista i requisiti previsti dagli URN)sui quali aver piena autorità.9.3.1 GrammaticaIn accordo alla Augmented Backus-Naur Form, la sintassi di un PRI è definitain figura 9.3. Si osservi che la definizione prevede l’uso di un set di caratteriderivato da quello ammesso <strong>per</strong> gli URI [BLFM98]. Questo <strong>per</strong>ò non esclude lapossibilità che, in sviluppi futuri, la classe di stringhe valide <strong>per</strong> la descrizione<strong>dei</strong> 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 ha un formato simile a quello delle net-locdegli URL, con la differenza che, nel caso in esame, si utilizzano nomi di tiponumerico separati dal punto. La sequenza di numeri non indica il server in cuiviene prodotta l’informazione, ma il server autoritativo <strong>per</strong> la risoluzione daPRI 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, vieneassociato anche un nome di portata locale anch’esso numerico. Il valore vieneassegnato automaticamente dal sistema della risoluzione <strong>dei</strong> nomi.Dalla definizione si può notare che effettivamente il PRI è completamenteindipendente dal LRI e dall’URL. Inoltre non è presente nessun riferimento allalocazione fisica, in quanto si assume che in generale il sistema di produzione edil servizio di risoluzione siano mantenuti distinti.Come sarà discusso in seguito, la scelta di tale formato è stata motivata dauna duplice volontà: da una parte quella di rendere più semplice ed automatizzatala gestione <strong>dei</strong> PRI da parte <strong>dei</strong> server <strong>dei</strong> nomi e dall’altra quella di2 La stringa che la rappresenta è stata suddivisa in due righe <strong>per</strong> motivi tipografici.201


IDN Naming ServiceIl modello a tre livelli::= "urn:"":"::= "pri"::= "/" ::= (dot-number)+::= (characters)+ ::= "."::= "0" | (+) ::= "1" | "2" | "3" | "4" | "5" |"6" | "7" | "8" | "9" ::= "0" | "1" | "2" | "3" | "4" |"5" | "6" | "7" | "8" | "9" ::= ::= ";" | ":" | "=" | "+" | "$" | "," | "-" |"_" | "." | "!" | "~" | "*" | "’" | "(" |")" | "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 <strong>dei</strong> PRIurn:pri:(0\.|([1-9][0-9]*)\.)*(0|([1-9][0-9]*))/[0-9a-zA-Z\-_.,();:=+$!~*’]+Figura 9.4: Espressione regolare <strong>per</strong> “match” sui PRIrendere più veloce ed immediata l’assegnazione di un PRI ad una nuova risorsa.Alcuni esempi di PRI ben formati sono:urn:pri:10.15.70/01urn:pri:2.4/document.txturn:pri:12.67.89.45/image.jpgurn:pri:27.28.29/aa7229830893b7b30bb0cf23a9fa5abcDa quanto detto si può notare come effettivamente i PRI siano del tuttoindipendenti sia dagli LRI che dagli URL e come in essi non sia presente alcunriferimento alla locazione fisica della risorsa cui sono associati.9.4 Il modello a tre livelliIl sistema <strong>dei</strong> nomi che è oggetto del presente lavoro si basa sulle tre tipologiedi identificatori: Logical Resource Identifier (LRI), Persistent Resource Identifier202


IDN Naming ServiceIl 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 rispettivamentela patente e la carta d’identità di una <strong>per</strong>sona e che sono associati ad uno stessoPRI, relativo ai dati anagrafici della <strong>per</strong>sona stessa:LRI://it/ministero/trasporti/motorizzazionecivile/patente123456/anagraficaLRI://it/comune/firenze/anagrafe/cartaidentita987654/datianagraficiLa 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 <strong>per</strong>sistentee che una URL localizza una risorsa, <strong>per</strong>mettendo di accedervi, è immediatocomprendere come la suddetta associazione “uno a molti” <strong>per</strong>metta di identificarepiù repliche di una stessa risorsa. Questa forma di ridondanza aumentanotevolmente sia la disponibilità che l’affidabilità dell’intero sistema, rendendolopiù robusto di fronte a guasti e/o malfunzionamenti della rete.Alle luce della relazioni esistenti tra i tre identificatori, si rende necessarial’introduzione di uno o più strumenti in grado di realizzare le traduzioni da untipo di nomi all’altro e viceversa. La descrizione di tali strumenti sarà oggetto<strong>dei</strong> paragrafi successivi.9.4.1 Sistemi di risoluzioneL’architettura fin qui descritta presenta tre tipologie di identificatori, relativea livelli di astrazione differenti, che devono essere relazionate tra loro mediantedue meccanismi di risoluzione: il primo si occupa di risolvere LRI in PRI, mentreil secondo di risolvere PRI in URL. Inoltre la risoluzione <strong>dei</strong> nomi deve esserepossibile anche in senso inverso; ossia dato un URL di una replica, deve esserepossibile risalire al rispettivo PRI e quindi a tutti i possibili LRI.LRILRIPRIURL URL URLFigura 9.5: Modello del sistema <strong>dei</strong> nomi: LRI, PRI ed URLIn analogia al DNS [Moc87a, Moc87b, Bra89a, Oht96, Vix96, VTRB97,EB97, Eas99, Vix99, GVE00, KGG + 03], nel seguito verranno presentati duesistemi di risoluzione <strong>dei</strong> nomi. Il primo è denominato Logical Domain NameSystem (LDNS) e si occupa della risoluzione diretta di un LRI in un PRI e203


IDN Naming ServiceLogical Domain Name System (LDNS)della risoluzione inversa di un PRI nell’insieme degli LRI ad esso associati. Ilsecondo prende il nome di Localization Service (LS) e si occupa sia di risolvereun PRI negli URL ad esso associati (risoluzione diretta), sia di fornire ilPRI corrispondente ad un determinato URL (risoluzione inversa). Oltre allesuddette funzionalità, entrambi i sistemi implementano anche <strong>dei</strong> meccanismiche supportano l’introduzione di nuovi nomi all’interno del sistema in cui sonoimpiegati.9.5 Logical Domain Name System (LDNS)Il LDNS è costituito da un vasto database di nomi, distribuito su un insiemedi host. In analogia al sistema DNS i server, contenenti le corrispondenze tragli LRI e i relativi URN, sono chiamati Logical Name Server (LNS). CiascunLNS in genere è responsabile (autoritativo) di almeno una zona (anche se non èstrettamente necessario). A tal proposito è opportuno effettuare alcune precisazionisulla differente semantica assunta dai termini zona e dominio nel contestodi uno spazio <strong>dei</strong> nomi gerarchico come quello gestito dal LDNS: una zona puòdefinire un gruppo di domini o un singolo dominio, mentre un dominio è inveceun singolo nodo dello spazio <strong>dei</strong> nomi e comprende sempre tutti gli eventualisottodomini. In questa trattazione non sono affrontate le problematiche relativeall’assegnamento di una o più zone ad un determinato LNS, assumendo cheesistano già appositi algoritmi in grado di distribuire le zone sull’insieme <strong>dei</strong>server ed eventualmente di assegnare ad un LNS più di una zona da gestire. Sievidenzia comunque che gli algoritmi di ripartizione delle zone possono rifletterele seguenti tipologie di politiche:• politiche interne. Sono politiche che vengono stabilite ed attuate in manieraspecifica <strong>per</strong> ogni server in base al relativo stato interno. Generalmentesi tratta sia di algoritmi che, effettuando una stima del carico di lavoro diun dato server, sono in grado di stabilire se un dato server può gestire unanuova zona, sia di procedure che, sfruttando una conoscenza preliminaredella topologia della rete, sono in grado di stabilire a quale server deveessere assegnata la nuova zona;• politiche esterne. Sono politiche che vengono imposte dall’esterno e riflettonotipicamente vincoli di tipo giuridico, legale o amministrativo.9.5.1 La risoluzioneL’obiettivo primario del LDNS è quello di fornire un meccanismo in grado dirisolvere un qualsiasi LRI nel corrispondente PRI, indipendentemente dal LNSdi partenza utilizzato dal client LDNS. Affinché il processo di risoluzione possaessere avviato, è infatti necessario che il client sia a conoscenza di un LNS didefault al quale inoltrare la richiesta di risoluzione. Questa situazione è del tuttoanaloga al caso del DNS in cui ciascun terminale che intende accedere al Webdeve conoscere l’indirizzo IP di un server DNS (tipicamente fornito dall’InternetService Provider). Nel caso specifico del LDNS si assume che l’informazionerelativa al primo LNS da contattare sia cablata all’interno della configurazione204


IDN Naming ServiceLogical Domain Name System (LDNS)del client: questo accorgimento <strong>per</strong>mette infatti al client di individuare il proprioserver di default sin dal momento dell’avvio.Una volta che il programma client ha inoltrato una richiesta di risoluzioneal proprio server di riferimento e si è posto in attesa di una risposta, possonoverificarsi diversi scenari in gran parte dipendenti dalla modalità di funzionamentodel 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 effettuatadal client sia sintatticamente corretta, verrà ora esposto il funzionamento <strong>dei</strong>suddetti meccanismi.Nel momento in cui un LNS, o<strong>per</strong>ante in modalità senza Look-Ahead, riceveuna richiesta di risoluzione, si hanno tre possibili scenari distinti e mutuamenteesclusivi:1. il server è in grado di assolvere direttamente la richiesta;2. il server non è in grado di assolvere la richiesta, ma conosce il successivoLNS 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, indicandoil PRI associato al LRI di cui è stata chiesta la risoluzione.Nel secondo caso il server inoltrerà la richiesta e si porrà esso stesso in attesadi una risposta da parte del successivo LNS contattato. Tale risposta potràconsistere o in un PRI o in un messaggio negativo, indicante l’impossibilità dideterminare quanto richiesto.A seconda del fatto che il server contattato sia autoritativo o meno sul LRIrichiesto, il terzo caso si suddivide in due ulteriori sottocasi:1. il server è autoritativo sul LRI richiesto. In questo caso il LNS dovrà inviareuna risposta negativa al richiedente poichè, pur essendo autoritativosul nome richiesto, non ha informazioni su di esso. Ovviamente questoimplica 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<strong>dei</strong> nomi, e si dovrà mettere in attesa di una sua risposta.Come illustrato in figura 9.6, dove la freccia verticale sulla destra indica lalinea del tempo, ogni server partecipa attivamente ad un solo passo del camminorisolutivo, il quale risulta <strong>per</strong>tanto distribuito complessivamente su più LNS.Coerentemente a ciò, anche il carico computazionale risulta distribuito tra i variLNS coinvolti.A differenza di quanto visto finora, un server che o<strong>per</strong>a in modalità conLook-Ahead può utilizzare due approcci distinti <strong>per</strong> soddisfare una richiesta dirisoluzione; la scelta dell’approccio da seguire avviene in base all’identità delrichiedente.Nel caso in cui la richiesta sia stata effettuata da un altro LNS, il server inquestione avrà tre possibilità di risposta:205


IDN Naming ServiceLogical Domain Name System (LDNS)Figura 9.6: Esempio di risoluzione senza Look-Ahead1. assolvere direttamente la richiesta nel caso in cui sia noto il PRI associatoal LRI richiesto;2. fornire l’indirizzo del successivo LNS, cui dovrà essere nuovamente inoltratala richiesta;3. inviare un messaggio di risposta negativo nel caso in cui il LNS in questionesia autoritativo sul LRI richiesto, ma non sia in grado di risolverlo.Si osservi come nel secondo caso il successivo LNS da contattare possa essereanche il server radice; in particolare questo si verifica se il server, oltre a nondisporre di informazioni sul nome richiesto, non è autoritativo sul nome stesso.Viceversa se il server non contiene informazioni sul LRI richiesto, ma risultaautoritativo su di esso, ci si riconduce al terzo caso.Se invece un LNS, o<strong>per</strong>ante in modalità con Look-Ahead, riceve una richiestadirettamente da parte di un client LDNS, esso dovrà assolvere il compito diinoltrare la richiesta a tutti i successivi server presenti nel cammino risolutivo.Questo processo di inoltro continua iterativamente finché non e viene ottenutauna 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 nellamodalità con Look-Ahead la maggior parte del carico di lavoro ricade sul primoserver contattato. Viceversa nella modalità senza LookAhead, precedentementeanalizzata, si ha una completa distribuzione del carico computazionale.Affinché il procedimento illustrato sia fattibile occorre che ogni LNS sia dotatodi una lista di riferimenti verso altri LNS. La lista manterrà le informazionisulle zone gestite, cioè su una porzione del Logical Name Space. Ogni LNS <strong>per</strong>ogni zona gestita deve mantenere i seguenti riferimenti:• riferimento al LNS autoritativo <strong>per</strong> la zona top (radice);206


IDN Naming ServiceLogical 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.9.5.2 L’algoritmo di risoluzioneL’algoritmo <strong>per</strong> la risoluzione di un nome è il seguente:1. si elimina il nome dell’ultima entità presente in del LRI:partendo dalla fine del nome si eliminano verso sinistra tutti i caratterifino ad incontrare il carattere “/” (compreso);2. si effettua la nuova ricerca nella lista <strong>dei</strong> riferimenti:(a) se esiste un riferimento ad un LNS autoritativo <strong>per</strong> il LRI, vieneeffettuata una richiesta di risoluzione del nome di partenza (quellocompleto) 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 Servercontiene nella propria lista un riferimento relativo al server autoritativo allazona 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 tuttodevono essere definite le liste in accordo alle regole precedentemente enunciate.Inoltre si supponga che:207


IDN Naming ServiceLogical Domain Name System (LDNS)zona topW3zona 1 zona 4 zona 5zona 3 zona 2Figura 9.8: Esempio di albero delle zone• la zona top, la zona 1, la zona 4 e la zona 5 siano gestite da Logical NameServer 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-1.3. LNS-4.• Riferimenti ai LNS autoritativi <strong>per</strong> le zone figlio:– riferimento a LNS-1;– riferimento a LNS-4;– riferimento a LNS-5.• Riferimenti ai LNS autoritativi <strong>per</strong> le zone figlio:– riferimento al LNS-2,3.• Riferimento al LNS autoritativo <strong>per</strong> la zona padre:– riferimento al LNS-top.• Riferimento al LNS autoritativo <strong>per</strong> la zona top:– riferimento al LNS-top.• Riferimento al LNS autoritativo <strong>per</strong> la zona padre:– riferimento al LNS-top.• Riferimento al LNS autoritativo <strong>per</strong> la zona top:– riferimento al LNS-top.208


IDN Naming ServiceLogical Domain Name System (LDNS)4. LNS-5.• Riferimento al LNS autoritativo <strong>per</strong> la zona padre:– riferimento al LNS-top;• Riferimento al LNS autoritativo <strong>per</strong> la zona top:5. LNS-2,3.– riferimento al LNS-top;• Riferimento al LNS autoritativo <strong>per</strong> la zona padre:– riferimento al LNS-1.• Riferimento al LNS autoritativo <strong>per</strong> la zona top:– riferimento al LNS-top.Si supponga che il LRI da risolvere sia:lri://world1/world4/world8.wrle che la richiesta venga rivolta a LNS-2,3. LNS-2,3 è autoritativo delle zone 2 e3, che ovviamente riguardano World diversi da quelli espressi nel LRI preso inesempio.Sotto queste ipotesi, LNS-2,3 verifica che lri://world1/world4 non è disua competenza, <strong>per</strong> cui viene inviata una richiesta verso LNS-1 <strong>per</strong> risolverelri://world1/world4/world8.Da questo punto in poi le modalità con e senza Look-Ahead procedono inmodo diverso:• Senza Look-Ahead. LNS-1 non è autoritativo, quindi inoltra la richiesta aLNS-top. Analogamente LNS-top richiede la risoluzione a LNS-5. LNS-5 èautoritativo sul LRI, <strong>per</strong> cui la risoluzione avviene e la risposta ri<strong>per</strong>correil 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’indirizzodi LNS-top. LNS-2,3 inoltra la richiesta completa a LNS-top. LNStopnon è 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 efornisce a LNS-2,3 la risoluzione.In figura 9.9 sono riportati i cammini ordinati delle richieste e delle rispostenei due casi.9.5.3 CachingIl LDNS fa ampio uso di una tecnica di caching allo scopo sia di migliorare leproprie 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 rappresentazioneinterna delle traduzioni effettuate recentemente <strong>per</strong> cui, quando209


IDN Naming ServiceLogical Domain Name System (LDNS)LNS -topSenza Look-AheadRichiestaRispostaCon Look-AheadRichiestaRisposta2 354LNS -1 LNS -5342116LNS -2,356Figura 9.9: Richieste ricorsive <strong>per</strong> la risoluzione210


IDN Naming ServiceLogical Domain Name System (LDNS)arriva una nuova richiesta di risoluzione su cui non è autoritativo, esso comeprima cosa controlla se in tale tabella è presente la corrispondenza richiesta.In caso affermativo il server restituisce immediatamente il PRI senza ulterioripassaggi, altrimenti interpella il server successivo, che effettua le stesse o<strong>per</strong>azioni.L’inserimento <strong>dei</strong> nomi nella cache avviene ogni volta che un messaggio,contenente un PRI risolto, transita attraverso il server in questione prima digiungere al client che ha effettivamente originato la richiesta di risoluzione.Chiaramente i valori mantenuti in cache hanno una validità temporale limitataoltre la quale vengono eliminati <strong>per</strong> evitare risposte contenenti dati obsoletie quindi non più validi.9.5.4 Supporto alla navigazioneIl meccanismo di risoluzione è efficace nell’ipotesi in cui l’utente conoscaesattamente il nome della risorsa alla quale intende accedere. Questo scenariosi presenta in varie circostanze considerando che è l’utente ad assegnare i nomie che può farlo seguendo delle proprie convenzioni che possono essere applicatein qualunque momento anche <strong>per</strong> risalire al nome della risorsa voluta. Allostesso modo niente vieta di ipotizzare che l’utente salvi i nomi delle risorse disuo interesse. Affidare all’utente l’onere della completa gestione <strong>dei</strong> nomi <strong>per</strong>òpuò risultare un’o<strong>per</strong>azione complessa e oltretutto non <strong>per</strong>mette di sfruttare almeglio le capacità del sistema gerarchico <strong>dei</strong> nomi logici.Per supportare l’utente nella navigazione dello spazio <strong>dei</strong> nomi, il sistema forniscela possibilità di effettuare una richiesta di “appartenenza a” su un LRI chenon rappresenta una foglia del Logical Name Space. Come risultato il sistemafornisce la lista di tutti gli elementi in esso contenuti. Con questo meccanismola navigazione nello spazio <strong>dei</strong> nomi logici risulta del tutto equivalente a quellasu file system.Si osservi che la complessità di questo tipo di richiesta è poco su<strong>per</strong>iore aquella di una richiesta di risoluzione. Una volta effettuata la richiesta ad un serverqualunque, l’algoritmo di ricerca del server autoritativo relativo all’elementoin questione è lo stesso rispetto al caso della risoluzione. Tale server memorizza<strong>per</strong> ipotesi la lista degli indirizzi relativi a tutti i figli dell’elemento in esame epuò fornirla al richiedente come avviene <strong>per</strong> la risposta ad una generica richiestadi risoluzione.In realtà, anche se il costo dell’algoritmo di risoluzione non cambia, potrebberoesserci delle difficoltà nella gestione e nel trasferimento della lista contenentetutti i riferimenti in quanto non sono state fatte ipotesi sul numero di elementiche questa può contenere (ogni genitore del Logical Name Space può avere unnumero arbitrario di figli). In ogni caso possono essere previsti <strong>dei</strong> meccanismifinalizzati a limitare la dimensione della lista che i vari server devono manipolaree/o trasferire.9.5.5 Espansione dello spazio <strong>dei</strong> nomiMentre nelle sezioni precedenti è stato presentato il processo di risoluzionedi nomi di alto livello, in questo paragrafo verranno discussi i meccanismi che211


IDN Naming ServiceLogical Domain Name System (LDNS)regolano l’inserimento di nuovi nomi nel sistema, <strong>per</strong>mettendo così di espanderelo spazio <strong>dei</strong> nomi gestito dal LDNS. A tal proposito va detto che ciòche contraddistingue questi meccanismi risiede nella possibilità, <strong>per</strong> chiunquene sia autorizzato, di aggiornare il sistema <strong>dei</strong> nomi senza dover richiedere alcunintervento da parte dell’amministratore del servizio. Per realizzare tuttociò, è stato definito un’apposita primitiva basata sull’attuazione del paradigmaclient-server. Il meccanismo in questione si svolge secondo i seguenti passi:1. dopo essersi autenticato, il client effettua una richiesta di inserimento diun nuovo nome ad un server qualsiasi del sistema di risoluzione;2. il server contattato esegue una procedura in grado di determinare qualeLNS dovrà farsi effettivamente carico della gestione dell’inserimento delnuovo nome;3. il primo server contattato inoltra la richiesta di inserimento ricevuta dalclient al LNS determinato al passo precedente;4. il nuovo server contattato verifica le credenziali dell’utente che ha effettuatola richiesta; se la verifica fallisce viene generato un messaggio d’erroree si ha la terminazione dell’algoritmo;5. il server in questione applica delle politiche atte a stabilire se deve gestireesso stesso il nome, mediante un’opportuna estensione dell’insieme di zonedi sua competenza, oppure delegare la gestione del nome ad un LNS dilivello inferiore;6. il server prescelto al passo precedente crea una voce relativa al nuovonome all’interno della propria struttura dati. Oltre alla corrispondenzaLRI-PRI, tale voce conterrà anche un riferimento all’utente che ha effettuatola 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 unmessaggio 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 passo5 un LNS determina se farsi carico esso stesso del nuovo nome oppure delegarela gestione del nome ad un altro server. Data l’importanza dell’argomento, èopportuno descrivere la questione tramite un esempio grafico. In figura 9.10sono mostrate sei zone: coerentemente a quanto detto la zona-1, costituita dallasuccessione di nodi w2/w5/w9, è gestita da un unico server, così come un unicoserver si occupa della zona-top, <strong>per</strong> la successione w1/w4 ed un altro ancora <strong>per</strong>la zona-4 con la successione w3/w7. Osserviamo che w6,w8,w10, hanno ciascunorispettivamente un server dedicato.Nel momento in cui, <strong>per</strong> effetto di una richiesta di inserimento, si rendenecessaria la creazione di un nuovo nodo w4, il server in questione ha duepossibilità:• estensione della zona. Il server estende la zona w1/w2/w3 di propriacompetenza, gestendo esso stesso il nuovo nodo w4.212


IDN Naming ServiceLogical Domain Name System (LDNS)W1zona topzona 1W3 W2W3W4W3 W5 W6W7 W8zona 2zona 4 zona 5W3 W9zona 3W10Figura 9.10: Rappresentazione delle zona in LDNS• gestione delegata ad un altro server. La zona di competenza delserver non viene ampliata e la gestione del nuovo nodo w4 viene delegataad un altro server del sistema, posto ad un livello gerarchico inferiore.La scelta tra le suddette possibilità può essere svolta secondo diverse politichecome ad esempio:• soglia di carico. Questa politica prevede che ogni server sia caratterizzatoda un coefficiente di carico, definito in base al numero di server dinomi indirizzabili dal server stesso, alle caratteristiche e alle prestazioni<strong>dei</strong> suoi componenti hardware (hard disk, processore, memoria, etc.), alladisponibilità di banda <strong>dei</strong> collegamenti ed altri parametri vincolanti <strong>per</strong>un espletamento efficiente del servizio di risoluzione. In particolare si hache il coefficiente di carico è dato dalla combinazione lineare <strong>dei</strong> suddettiparametri, opportunamente pesati in base alla loro rilevanza. Nel momentoin cui il valore di tale coefficiente su<strong>per</strong>a una data soglia, la gestionedel nuovo nodo viene delegata ad un altro server.• profilo dell’utente. Questa politica prevede che il profilo dell’utente, cheha effettuato la richiesta di inserimento, specifichi un LNS di riferimentoche dovrà essere autoritativo su tutti i nomi che vengono creati tramitetale profilo. L’utente può ottenere i <strong>per</strong>messi necessari all’esecuzione ditale o<strong>per</strong>azione direttamente dal proprio Internet Service Provider.9.5.6 Proprietà di LDNSIl Logical Domain Name System, <strong>per</strong> come è stato definito e <strong>per</strong> la forteanalogia con il DNS, può vantare le seguenti proprietà:• garantisce la risoluzione di tutto il Logical Name Space;213


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


IDN Naming ServiceLocalization Service (LS)010.0 1.00.10.0.00.1.0Figura 9.11: Esempio di LSottimi risultati in termini di espandibilità, scalabilità e distribuzione del caricodi lavoro. Tali aspetti saranno comunque messi in evidenza in seguito.Analogamente al LDNS, anche <strong>per</strong> il Localization Service si assume che lerichieste di risoluzione possano essere inoltrate a qualunque server LS, garantendocosì una molteplicità di punti d’accesso al servizio. L’informazione relativa alprimo server da contattare è cablata nella configurazione di ogni client in modotale da poter essere re<strong>per</strong>ita in modo semplice ed altamente <strong>per</strong>formante. Questasoluzione <strong>per</strong>mette infatti di assicurare al sistema una buona flessibilità e fasi che il client, subito dopo essere stato avviato, sia già in grado di comunicarecon il server senza ulteriori fasi di setup.In conformità allo standard XDI/XRI, ogni server LS implementa due differentimeccanismi di risoluzione: con Look-Ahead e senza Look-Ahead. Ilfunzionamento di tali meccanismi è del tutto analogo a quanto progettato <strong>per</strong>LDNS. In particolare anche in questo caso si ha che con la prima modalità ilcarico computazionale ricade in larga parte sul server di default contattato dalclient LS, il quale ha il compito di inoltrare la richiesta di risoluzione a tuttii successivi server presenti nel cammino risolutivo. Viceversa con la secondamodalità il carico di lavoro viene distribuito in maniera equa tra tutti i servercoinvolti, ognuno <strong>dei</strong> 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 aquello di LDNS. In particolare ogni server LS mantiene nella propria cachetutte le corrispondenze PRI-URL risolte recentemente <strong>per</strong> cui, quando arrivauna nuova richiesta di risoluzione su cui non è autoritativo, esso controlla senella cache è presente la corrispondenza richiesta e in caso affermativo restituisceimmediatamente gli URL senza ulteriori passaggi. Ovviamente nel caso in cui lacache non sia in grado di assolvere la richiesta di risoluzione, viene interpellato unsuccessivo server LS. L’inserimento <strong>dei</strong> nomi nella cache avviene ogni volta cheun messaggio, contenente uno o più URL risolti, transita attraverso il server inquestione prima di giungere al client che ha effettivamente originato la richiestadi risoluzione. Anche in questo caso la validità delle voci in cache ha una duratalimitata nel tempo <strong>per</strong> evitare risposte con dati obsoleti.215


IDN Naming ServiceLocalization Service (LS)Come detto in precedenza, lo spazio <strong>dei</strong> nomi gestito da LS è gerarchico erisulta suddiviso in più zone, ognuna delle quali può essere gestita da uno stessoserver LS. I meccanismi che regolano l’inserimento di nuovi nomi nel sistema,<strong>per</strong>mettendo di estendere tale spazio <strong>dei</strong> nomi, sono assai simili a quelli esaminatinel paragrafo dedicato a LDNS. In particolare una volta determinato il serverche deve prendere effettivamente in carico l’inserimento del nuovo nome, anchein questo caso il passo chiave dell’algoritmo di inserimento è la modalità concui il server in questione determina se farsi carico esso stesso del nuovo nomeoppure delegare la gestione del nome ad un altro server. A titolo di esempio siconsideri la figura 9.12 che mostra una zona rappresentata dalla successione dinodi 10.11.12.101112Figura 9.12: Rappresentazione di una zonaSe <strong>per</strong> effetto di una richiesta di inserimento si rende necessaria la creazionedi un nuovo nodo 13, il server autoritativo sulla zona in questione ha duepossibilità: gestire esso stesso il nuovo nodo, estendendo così la zona di propriacompetenza, oppure delegare la gestione del nodo ad un altro server, posto adun livello inferiore della gerarchia LS. In quest’ultimo caso il server delegato puòessere preimpostato nella configurazione del server precedente, oppure può esserespecificato dall’utente al momento di effettuare la richiesta di inserimento.Le due soluzioni sono illustrate rispettivamente in figura 9.13 e 9.14. In generaleè preferibile adottare la prima soluzione in quanto assicura al sistema un buonlivello di flessibilità e non richiede alcun intervento da parte dell’utente.Sulla base di quanto detto finora, si possono evidenziare le seguenti caratteristichedi LS:• garantisce la risoluzione dell’intero spazio <strong>dei</strong> nomi a partire da qualunquepunto d’accesso al servizio;216


IDN Naming ServiceLocalization Service (LS)10111213Figura 9.13: Estensione di una zona10111213Figura 9.14: Delega della gestione di un nodo ad un’altra zona• consente una facile estendibilità dello spazio <strong>dei</strong> nomi mediante l’aggiuntadi nuovi nodi (server) nella gerarchia;• è altamente scalabile in quanto “derivato” dal DNS;• gestisce gli aggiornamenti in modo rapido ed efficace.217


IDN Naming ServiceLocalization Service (LS)Alle suddette proprietà si può aggiungere la tolleranza ai guasti, se il sistemaviene ridondato. Infatti analogamente al DNS si possono introdurre <strong>dei</strong> serverLS secondari che possono essere impiegati come “riserva calda” nel caso in cuiuno <strong>dei</strong> server primari si guasti. Se viene adottata quest’ultima soluzione, iserver LS si distingueranno <strong>per</strong>tanto in primari e secondari, oltre che <strong>per</strong> illivello gerarchico a cui appartengono.9.6.1 La risoluzione inversa.In questo paragrafo verrà presentato un sistema di risoluzione che a partireda un URL, relativo ad una replica di una risorsa, <strong>per</strong>mette di risalire al rispettivoPRI e quindi a tutti i possibili LRI. Tale servizio, detto di risoluzioneinversa, è del tutto speculare a quello di risoluzione diretta e <strong>per</strong> questo motivo èpossibile ipotizzare la risoluzione inversa come un servizio a se stante svincolatodai precedenti, a tal punto da poter essere implementato mediante un sistemadi server indipendenti da LDNS e LS.Indipendentemente da questo aspetto, come illustrato in figura 9.15, il meccanismodi 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 risoluzioneinversa da URL a PRI. Nello specifico, dato che ogni singolo URL rappresentauna replica della risorsa logica identificata dal PRI, è possibile ipotizzare che ilPRI stesso sia memorizzato come metadato all’interno della replica, rendendosu<strong>per</strong>fluo qualsiasi meccanismo di risoluzione inversa implementato nel sistema<strong>dei</strong> nomi. In ogni caso si può sempre introdurre, qualora l’ipotesi appena citatanon sia applicabile, un meccanismo di risoluzione inversa simile al reverse lookupdel DNS.Per quanto concerne il secondo passo si ha che il meccanismo di risoluzioneda PRI a LRI può essere descritto nel modo seguente:• il client effettua una richiesta di risoluzione inversa di un PRI al proprioserver LS di default;• il server contattato, sfruttando l’infrastruttura utilizzata <strong>per</strong> la risoluzionediretta, individua il server autoritativo sul PRI di cui è stata richiestala risoluzione. In particolare si evidenzia che <strong>per</strong> la determinazione delserver autoritativo possono essere impiegati entrambi i meccanismi: conLook-Ahead e senza Look-Ahead;• dopo aver ricevuto la richiesta di risoluzione ed aver esaminato la propriastruttura dati interna relativa alla risoluzione inversa, il server autoritativosul PRI invia una risposta contenente gli LRI risolti.Anche <strong>per</strong> la risoluzione inversa è stato previsto un meccanismo di cachingdel tutto simile a quello della risoluzione diretta. In particolare ogni server LS218


IDN Naming ServiceLocalization Service (LS)LRILRIPRIURL URL URLFigura 9.15: Risoluzione inversamantiene nella propria cache tutte le corrispondenze PRI-LRI risolte recentemente<strong>per</strong> cui, quando arriva una nuova richiesta di risoluzione inversa <strong>per</strong> unPRI su cui non è autoritativo, esso controlla se nella cache è presente la corrispondenzarichiesta e in caso affermativo restituisce immediatamente gli URLsenza ulteriori passaggi. Nel caso in cui la cache non sia in grado di assolvere larichiesta di risoluzione, viene interpellato un successivo server LS.L’inserimento <strong>dei</strong> nomi nella cache avviene ogni volta che un messaggio,contenente uno o più LRI risolti, transita attraverso il server in questione primadi giungere al client che ha effettivamente originato la richiesta di risoluzione.Ovviamente, come <strong>per</strong> i casi precedenti, la validità della cache ha una duratatemporale limitata.Nell’ambito della risoluzione inversa un’aspetto importante riguarda la consistenzadelle informazioni necessarie all’espletamento del servizio rispetto allospazio <strong>dei</strong> nomi gestito dal sistema. In altri termini non si deve verificare unasituazione in cui esista un LRI che faccia riferimento ad un dato PRI e, contemporaneamente,il server autoritativo su tale PRI non contenga alcuna informazioneche <strong>per</strong>metta di risalire al LRI. Affinché il meccanismo di inserimento dinuovi nomi nel sistema sia tale da garantire questa proprietà, è necessario chel’inserimento di un nuovo LRI sia obbligatoriamente seguito da un’o<strong>per</strong>azionedi aggiornamento del server LS che è autoritativo sul PRI cui esso si riferisce.Il sistema di risoluzione inversa appena descritto è necessario quando si vuolerisalire da un PRI ad un nome logico e può essere utile in vari contesti. Atitolo di esempio si possono considerare alcune questioni inerenti la salvaguardiadella privacy e il trattamento <strong>dei</strong> dati <strong>per</strong>sonali. Infatti nell’ipotesi che un PRIidentifichi in modo unico e <strong>per</strong>sistente <strong>dei</strong> dati confidenziali, sensibili e riservatirelativi ad una data organizzazione o <strong>per</strong>sona, il meccanismo di risoluzione inversa<strong>per</strong>metterà di risalire a tutte le entità che hanno creato un link a tali datinel proprio spazio virtuale mediante la creazione di un LRI. Da quanto dettosegue che i dati in questione possono essere acceduti ed utilizzati finché esistetale LRI. Inoltre correlando alla risoluzione inversa un meccanismo di sicurezza,è possibile limitare l’accesso ai dati alle sole entità che ne hanno diritto. Adesempio al fine di realizzare un meccanismo automatico che garantisca una certa219


<strong>InterDataNet</strong>MiddlewareIDN Naming ServiceIntegrazione in <strong>InterDataNet</strong>forma di controllo sulla creazione di link verso un PRI, potrebbe essere previstouna verifica <strong>per</strong>iodica della struttura dati relativa alla risoluzione inversa, inmodo 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 <strong>InterDataNet</strong>Il sistema <strong>dei</strong> nomi descritto in questo capitolo è stato progettato con il finedi risolvere il problema dell’indirizzabilità in ambiente distribuito. Per comeè stato illustrato e <strong>per</strong> le proprietà che possiede, risulta valido ed applicabileal di fuori del middleware <strong>InterDataNet</strong>. In ogni caso il sistema di nomi è ilsistema portante di <strong>InterDataNet</strong>: è integrato nella Service Architecture (IDN-SA, capitolo 8) in modo naturale, semplicemente applicando correttamente lastratificazione.La suddivisione a tre livelli è stata utile e vantaggiosa <strong>per</strong> semplificarne latrattabilità e l’esposizione, ma <strong>per</strong> rigorosità devono essere eseguita una opportunaestensione e precisazione <strong>per</strong> mappature i livelli di IDN nei livelli delsistema <strong>dei</strong> 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 <strong>dei</strong> servizi IDNsu cinque livelli (partendo dall’alto IDN Application, Virtual Repository, InformationHistory, Replica Management ed infine Storage Interface) introdotti nelparagrafo 6.2.IDN Compliant ApplicationVirtual Repository LayerInformation History LayerReplica Management LayerStorage Interface LayerFilesystem,database, etc.Generic storagearchitectureIDN APIsHTTP(S), SMTP(S),FTP(S), etc.Generic networkcommunication architectureIDN-IMnames [+v.p.]LRIs [+v.p.]PRIs [+v.p.]PRIsURLsPlatformdependentlocal namesLDNSLSHFNURNURLThree layersIDN naming system[+v.p.] →OptionalversionparameterFigura 9.16: Sistema <strong>dei</strong> nomi in <strong>InterDataNet</strong>Il fatto che l’architettura sia a cinque livelli mentre il sistema di nomi a trepotrebbe sembrare un’incongruenza, ricordando che in ogni architettura stratificataè opportuno che sia definito uno spazio di indirizzamento <strong>per</strong> ogni livello.La figura 9.16 intende esprimere ed evidenziare l’inconsistenza della incongruen-220


IDN Naming ServiceIntegrazione in <strong>InterDataNet</strong>za: alcuni livelli utilizzano nomi della stessa classe, seppur specializzati <strong>per</strong>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 stessaclasse URN: rispettivamente i PRI, introdotti nel paragrafo 9.3, conparametro di versione (opzionale) ed i PRI senza parametro di versione;• infine Storage Interface utilizza direttamente gli URL (che eventualmenteinternamente rimappa sullo spazio di nomi proprio della piattaforma distorage: <strong>per</strong> esempio nomi di file nel caso di file system oppure query SQLnel caso di database relazionali).Descriviamo adesso i meccanismi utilizzati <strong>per</strong> il passare da uno spazio di nomidi un livello ad un’altro, o<strong>per</strong>azione che viene effettuata regolarmente durantel’attraversamento <strong>dei</strong> 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 nominareed indirizzare le risorse, tali applicazioni devono adattare i proprinomi ad LRI <strong>per</strong> poter interfacciarsi correttamente alla IDN-API (espostada Virtual Repository). Si noti che <strong>InterDataNet</strong> non pone vincoli relativamenteal modo con cui le applicazioni debbano rappresentare al lorointerno di dati, tanto meno i nomi. Per questo motivo non è possibilestabilire un meccanismo generale;• Virtual Repository si trova a dover convertire LRI (HFN) in PRI (URN)e <strong>per</strong> questo si avvale direttamente di LDNS;• Information History deve risolvere la coppia PRI + parametro di versionenel PRI dell’elemento corrispondente 3 . Ad esempio se la versionen e la versione n + 1 di una data informazione hanno come PRIurn:pri:10.15.70/12345 e urn:pri:8.5.34/76 rispettivamente, il nomeurn:pri:10.15.70/12345[NEXT] (dove [NEXT] è il parametro di versioneche indica la versione successiva) viene risolto da Information Historyin urn:pri:8.5.34/76. Questo tipo di risoluzione, necessario <strong>per</strong>la navigazione nello storico, viene svolto in Information History in modoalgoritmico, come sarà descritto nel capitolo 11;• Replica Management si trova a dover convertire PRI (URN) in URL e <strong>per</strong>questo si avvale direttamente di LS;• infine Storage Interface, come già anticipato, rimappa gli URL sullo spaziodi nomi proprio della piattaforma di storage. Anche in questo caso, pur3 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 (intesacome il passaggio da uno spazio di nomi all’altro).221


IDN Naming ServiceStudio di fattibilitàpotendo citare vari esempi, non è possibile determinare regole generali inquanto Storage Interface è stato progettato proprio <strong>per</strong> abilitare lo sviluppodi adattatori verso qualsiasi tecnologie di storage <strong>per</strong> la memorizzazione<strong>per</strong>sistente.9.8 Studio di fattibilitàAl fine di effettuare uno studio applicativo, i risolutori LDNS e LS sono statiimplementati in forma dimostrativa.Avendo seguito un approccio a<strong>per</strong>to sin dalle prime fasi di progettazione, losviluppo non poteva prescindere dall’uso di strumenti e piattaforme libere. Lamotivazione di questa scelta è condizionata da un lato dai numerosi vantaggiche 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 implementatele classi che realizzano l’architettura del sistema <strong>dei</strong> nomi;• GNU/Linux, come piattaforma di riferimento <strong>per</strong> sviluppo, test e deploy;• MySQL, database relazionale utilizzato come back-end <strong>per</strong> la memorizzazionedelle strutture dati interne;• XML (eXtensible Markup Language), come metalinguaggio utilizzato, inaccordo allo standard XDI/XRI 1.4, <strong>per</strong> definire il formato <strong>dei</strong> messaggidescrittori, scambiati tra host durante la risoluzione o l’inserimento di unnome;• HTTP [BLFF96, FGM + 99], come protocollo di livello applicativo utilizzato<strong>per</strong> la comunicazione tra i vari server. In particolare all’interno <strong>dei</strong>pacchetti HTTP vengono incapsulati i descrittori XML tramite cui i serversi scambiano le informazioni necessarie all’espletamento <strong>dei</strong> loro compiti.9.8.1 Implementazione del sistema <strong>dei</strong> nomiNel presente paragrafo verranno descritti LDNS, LS ed il servizio di risoluzioneinversa. Per ognuno di essi verranno introdotti i descrittori, la rappresentazioneinterna <strong>dei</strong> dati e gli algoritmi sia di risoluzione che <strong>per</strong> l’inserimento diun nuovo nome.LDNSI descrittori. In analogia allo standard XDI/XRI, la risposta ad una richiestadi risoluzione di un segmento è costituita da un descrittore in formato XML checonterrà necessariamente il PRI risolto oppure le informazioni relative all’autoritàalla quale inoltrare successivamente la richiesta. La forma di base di unmessaggio descrittore contenente il PRI risolto è la seguente:222


IDN Naming ServiceStudio di fattibilitàurn:pri:10.70.15/01LRI PRI NextStep Attribute Authority* localhostw5 pri:10.70.15.73/01 12/11/05 Ing1w1www.det.unifi.itTabella 9.1: Esempio di rappresentazione <strong>dei</strong> dati interni di un LNS radiceLRI PRI NextStep Attribute Authorityw1/w2 pri:12.55.33/15 12/11/05 Ing1w1/*localhostTabella 9.2: Esempio di rappresentazione <strong>dei</strong> dati interni di un generico LNSLa forma di base di un messaggio descrittore, contenente le informazionirelative all’autorità alla quale inoltrare la richiesta di risoluzione, è invece:nextstep.det.unifi.itNaturalmente, il set di informazioni contenute all’interno di un descrittore,potrà essere ampliato con ulteriori metadati, relativi all’autorità descritta, cheagevolino il processo di risoluzione.Rappresentazione interna <strong>dei</strong> dati. Al fine di assolvere o<strong>per</strong>ativamente ilprocesso di risoluzione, i Logical Name Server (LNS) dovranno essere caratterizzatida una struttura dati interna in grado di rappresentare le corrispondenze traLRI e PRI. In particolare è necessario che ciascun LNS mantenga al suo interno,mascherata dall’interfaccia, i dati relativi alla porzione di struttura gerarchicanella quale è situato. Come illustrato nella tabelle 2.1 e 2.2, è stata adottata unarappresentazione in forma tabellare in grado di mantenere al proprio interno lerelazioni tra i nodi della gerarchia LDNS.Ogni tabella risulta suddivisa in cinque campi, corrispondenti alle informazioninecessarie affinché un server possa espletare il servizio di risoluzione. Lasemantica relativa a tali campi è la seguente:• LRI: chiave primaria della tabella che rappresenta l’LRI da risolvere;223


IDN Naming ServiceStudio di fattibilità• PRI: il PRI corrispondente al LRI da risolvere;• NextStep: campo contenente l’URI del successivo server da contattare <strong>per</strong>la richiesta di risoluzione di un dato PRI;• Authority: campo che rappresenta l’autorità relativa al LRI a cui siriferisce la entry nella tabella;• Attribute: campo contenente gli attributi che caratterizzano l’LRI; esempitipici di attributi sono data e ora relativi alla creazione del LRI, oppureinformazioni riguardanti le politiche di accesso.Andando ad analizzare i dati presenti nelle due tabelle, occorre innanzi tuttodire 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 valorelocalhost nel campo NextStep corrisponde a tale situazione. Pertanto se alserver in questione viene richiesta la risoluzione del LRI w5, esso risponderà conil PRI contenuta in tabella, mentre nel caso in cui venga richiesta la risoluzionedi un LRI il cui segmento iniziale sia w1, la struttura dati interna indicherà ilsuccessivo server da contattare (e cioè www.det.unifi.it). Se invece al serverviene richiesta la risoluzione del LRI w7, esso risponderà con un messaggio dirisposta negativo poiché è autoritativo su tutti i nomi del sistema. In tabella2.2 è mostrata invece una possibile struttura dati interna <strong>per</strong> il server indicatocome passo successivo nell’esempio precedente: ciò è deducibile dalla presenza<strong>dei</strong> valori w1/* e localhost nei campi PRI e NextStep, indicante che il serverin questione è autoritativo su tutti gli LRI inizianti con il segmento w1. In particolarese al server in questione viene chiesta la risoluzione del LRI w1/w2, essorisponderà con il PRI contenuto in tabella.Gli algoritmi. Il requisito fondamentale affinchè un client LDNS possa avviareil processo di risoluzione di un LRI in un PRI, è la conoscenza di un puntodi partenza dal quale poter accedere al sistema <strong>per</strong> poi inoltrare la richiesta dirisoluzione. L’informazione relativa al primo server da contattare è stata cablataall’interno di ogni terminale client mediante un file di configurazione a cuiil client accede al momento dell’esecuzione. In particolare all’interno del file diconfigurazione è contenuta anche la porta a cui il server in questione è in ascoltoin attesa di espletare i propri compiti. Una volta che ha determinato qualeserver contattare, il client può inoltrare la propria richiesta di risoluzione: a talescopo esso formula la richiesta sottoforma di messaggio HTTP, apre una socketTCP attraverso cui inoltra la richiesta e si pone in attesa di una risposta. Larichiesta di risoluzione viene formulata utilizzando il metodo GET. Nonostante daun punto di vista semantico tale metodo indichi una richiesta d’accesso ad unarisorsa, è stato deciso di utilizzarlo al fine di rimanere conformi allo standardXRI/XDI [KW95]. Omettendo le linee d’intestazione non strettamente correlatecon il sistema di risoluzione, il formato di una generica richiesta di risoluzioneè il seguente:GET un/qualsiasi/LRI HTTP/1.1User-Agent : ldns 1.0224


IDN Naming ServiceStudio di fattibilitàOltre al metodo utilizzato ed al nome di cui si richiede la risoluzione, laprima riga contiene anche un’indicazione relativa alla versione del protocolloHTTP utilizzata. La riga successiva contiene invece l’header User-Agent che inquesto caso identifica il tipo di agente del sistema di risoluzione che ha effettuatola richiesta e la relativa versione. In particolare come verrà approfondito inseguito, tale header <strong>per</strong>mette di distinguere il client che ha effettivamente originatola richiesta di risoluzione dagli altri server che entrano in gioco durantel’esecuzione dell’algoritmo. Come descritto nel paragrafo 9.5, un server LDNSpuò funzionare funzionare secondo due modalità distinte: con Look-Ahead esenza Look-Ahead. L’informazione relativa alla modalità di funzionamento èstata cablata all’interno di ogni server mediante un file di configurazione a cui ilserver accede al momento dell’avvio. Tale file contiene anche altre informazioniutili tra cui la porta su cui il server è in ascolto e la URI di un server radiceautoritativo sull’intero spazio <strong>dei</strong> nomi. Ovviamente nel caso in cui l’amministratoredi sistema cambi alcune impostazioni del file di configurazione, il serverdovrà essere riavviato in modo tale da poter mettere in pratica i nuovi settaggi.Nel momento in cui un server, o<strong>per</strong>ante in modalità senza Look-Ahead, riceveuna richiesta di risoluzione, si hanno tre possibili scenari distinti e mutuamenteesclusivi:1. il server è in grado di assolvere direttamente la richiesta;2. il server non è in grado di assolvere la richiesta, ma conosce il successivoLNS 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 accedead un database relazionale che viene sfruttato come storage system al postodel file system <strong>per</strong> motivi di comodità di interrogazione della struttura datitabellare. In primo luogo il server esegue una ricerca relativa al LRI completo: seesso è presente, il server si troverà nel primo caso. Se ciò non si verifica, vengonoricercati nel database sotto-segmenti del LRI richiesto: nel caso in cui uno diquesti sia presente nel database il server si troverà nel secondo caso, altrimenti sitroverà nel terzo caso. A titolo di esempio si ipotizzi che ad un server giunga unarichiesta relativa al LRI w1/w2/w3: se l’intero nome è contenuto nel databaseil server si trova nel primo caso, altrimenti esso esegue una ricerca relativa aw1/w2 ed eventualmente a w1. Se uno <strong>dei</strong> due è contenuto nel database il casoin questione è il secondo, altrimenti è il terzo. Nel primo caso il server risponde alclient che lo ha contattato con un messaggio di risposta HTTP indicante il PRIassociato al LRI. Conformemente allo standard XDI/XRI, il formato generaledell’header del messaggio è:HTTP/1.1 200 OKServer: ldnsd 1.0Oltre alla versione del protocollo utilizzata, la prima riga contiene il codice200 OK, indicante che la richiesta è stata processata con successo; la secondalinea d’intestazione specifica invece il tipo di server in questione e la relativaversione. Il body del messaggio HTTP contiene invece il descrittore in formato225


IDN Naming ServiceStudio di fattibilitàXML al cui interno è posto il PRI risolto. La forma di base di un messaggiodescrittore contenente il PRI risolto è stata riportata precedentemente in questoparagrafo. Nel secondo caso il server inoltra la richiesta al nodo successivo,ponendosi in attesa di una risposta che potrà essere un messaggio contenenteil PRI risolto oppure un messaggio indicante l’assenza del nome all’interno delsistema. A tal proposito il server attiva un client LDNS che apre una socketTCP, attraverso cui inoltra la richiesta, e si pone in attesa di una risposta. Larichiesta che viene formulata è analoga a quella vista in precedenza, con la soladifferenza che il campo User-Agent ha valore ldnsd 1.0 anzichè ldns 1.0 <strong>per</strong>indicare che la richiesta giunge da parte di un server di risoluzione. Nel terzocaso si hanno in realtà due possibili situazioni a seconda del fatto che il servercontattato sia autoritativo o meno sul LRI di cui è stata chiesta la risoluzione. Atal proposito è stata adottata la convenzione seguente: si ricercano nella base didati <strong>dei</strong> sottosegmenti del LRI richiesto che contengano come ultimo segmentoil carattere ‘*’ e che abbiano nel campo NextStep il valore localhost. Se l’esitodella ricerca è positivo, allora il server è autoritativo sul nome logico. Ad esempioun server LDNS è autoritativo sul LRI w1/w2/w3/w4 nel caso in cui nel campoLRI della base di dati sia presente uno <strong>dei</strong> seguenti valori: *, w1/*, w1/w2/*,w1/w2/w3/*. Se il server è autoritativo sul LRI e non ha informazioni su diesso, allora deve inviare al client che lo ha contattato un messaggio di rispostanegativo, indicante l’assenza del nome all’interno del sistema. In conformità allostandard HTTP, il formato generale dell’header del messaggio è:HTTP/1.1 404 Not FoundServer: ldnsd 1.0In questo caso la prima riga dell’header contiene il codice 404 Not Found,indicante appunto che il nome richiesto non esiste nel sistema; la semanticadelle altre parti del messaggio è analoga a quanto discusso in precedenza <strong>per</strong>una risposta positiva. Se invece il server non è autoritativo sul LRI, allora larichiesta viene inoltrata al server radice che è autoritativo su tutto lo spazio <strong>dei</strong>nomi. Come detto in precedenza, ogni server LDNS ha cablato nel proprio file diconfigurazione la URI di un server radice. A differenza di quanto visto finora, unserver che o<strong>per</strong>a in modalità con a Look-Ahead può agire secondo due approccidistinti che dipendono dall’identità del richiedente. Tale informazione vienespecificata in ogni messaggio HTTP di richiesta mediante la linea d’intestazioneUser-Agent che può assumere i valori ldnsc o ldnsd. Se il valore è ldnsc, allorail 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 cuila richiesta sia stata effettuata da un altro server LDNS, si possono verificaretre situazioni distinte:1. il server può assolvere la richiesta in quanto contiene nel proprio databasela corrispondenza LRI-PRI cercata. Analogamente al caso senza Look-Ahead la risposta è costituita da un messaggio HTTP che contiene nelbody il descrittore XML indicante il PRI risolto;2. il server fornisce l’indirizzo del successivo server LDNS, cui dovrà esserenuovamente inoltrata la richiesta. In questo caso la risposta è costituita226


IDN Naming ServiceStudio di fattibilitàda messaggio HTTP che contiene un descrittore XML indicante la URIdel successivo nodo del cammino di risoluzione. La forma di base di taledescrittore è stata riportata precedentemente in questo paragrafo;3. il server fornisce un messaggio di risposta negativo in quanto è autoritativosul 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 questionedovrà assolvere il compito di inoltrare la richiesta a tutti i successivi serverpresenti nel cammino risolutivo, finchè non viene ottenuta una risposta definitivache può essere:1. un messaggio HTTP che contiene nel body il descrittore XML indicanteil 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 dirisoluzione su cui non è autoritativo, esso accede ad un’apposita tabella del propriodatabase in cui sono presenti tutte le traduzioni effettuate recentemente ericerca 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 conil PRI risolto. Per effettuare la manutenzione della tabella relativa al caching,è stato scelto di utilizzare un’apposito thread che scandisce quotidianamente latabella ed elimina tutte le voci la cui scadenza è anteriore alla data odierna. Ladata di scadenza <strong>dei</strong> nomi contenuti nella cache viene determinata al momentodel loro inserimento in tabella aggiungendo alla data corrente un numero predefinitodi giorni e/o ore. Tale parametro è cablato nel file di configurazionedi ogni server e può essere variato dall’amministratore di sistema. Il meccanismoutilizzato <strong>per</strong> l’inserimento di un nuovo nome è simile a quello esaminato<strong>per</strong> la risoluzione. Infatti un client LDNS può avanzare la propria richiesta diinserimento ad un qualsiasi server di default, specificato nel proprio file di configurazione.Una volta contattato, tale server sfrutta l’infrastruttura utilizzata<strong>per</strong> la risoluzione in modo da determinare il server LDNS autoritativo sul PRIin questione e da inoltrargli la richiesta di inserimento. Analogamente a quantodetto in precedenza, tutti i server coinvolti possono funzionare sia in modalitàcon Look-Ahead che senza Look-Ahead. Le differenze più rilevanti tra la risoluzionee l’inserimento di un nome consistono nel formato <strong>dei</strong> messaggi HTTPdi richiesta e di risposta. In primo luogo le richieste di inserimento vengonoformulate utilizzando il metodo PUT. In realtà da un punto di vista semanticotale metodo viene impiegato <strong>per</strong> richiedere ad un server web di memorizzare larisorsa contenuta nel body del messaggio, associandogli la URI specificata nellalinea di richiesta; nonostante ciò in questo caso è stato deciso di utilizzare ilmetodo PUT al fine di rimanere conformi allo standard XRI/XDI. Il formato diuna generica richiesta di inserimento è il seguente:PUT un/qualsiasi/LRI HTTP/1.1227


IDN Naming ServiceStudio di fattibilitàUser-Agent : ldns 1.0Content-Location : un/qualsiasi/PRIOltre alla versione del protocollo HTTP ed al metodo utilizzato, la primariga contiene anche il LRI che <strong>per</strong>mette di determinare il server autoritativo sulnome da inserire, sfruttando l’infrastruttura usata <strong>per</strong> la risoluzione. La linead’intestazione Content-Location è stata appositamente introdotta allo scopo dispecificare il PRI di cui si richiede l’inserimento. Per quanto riguarda la rispostaad una richiesta di inserimento, vanno invece distinti due casi a seconda del fattoche la richiesta sia andata a buon fine o meno. Nella prima eventualità il formatogenerale della risposta è il seguente:HTTP/1.1 200 OKServer: ldnsd 1.0Come si può vedere il formato del messaggio è analogo a quello esaminato <strong>per</strong>la risoluzione; l’unica differenza risiede nel fatto che questa volta nel descrittoreXML, contenuto nel body del messaggio, è specificato il PRI inserito. Nellaseconda eventualità il formato generale della risposta è invece il seguente:HTTP/1.1 409 ConflictServer: ldnsd 1.0In 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 <strong>per</strong>una risposta positiva.LSI descrittori. Anche nel caso del Localization Service la risposta alla richiestadi risoluzione di un nome è costituita da un descrittore in formato XML,contenente gli URL risolti oppure le informazioni relative al successivo server acui inoltrare la richiesta. Questa volta <strong>per</strong>ò, essendo il servizio di risoluzione deltipo “uno a molti”, il formato del messaggio descrittore in risposta dovrà essereopportunamente modificato in modo da includere tutti i possibili URL associatiallo stesso PRI. Ad esempio, nel caso in cui ad uno stesso PRI corrispondanotre URL, il formato del messaggio descrittore risulta dunque il seguente: www.det.unifi.url achille.det.unifi.url radar.det.unifi.url La forma di base di un messaggio descrittore, contenente le informazionirelative all’autorità alla quale inoltrare la richiesta di risoluzione, è invece adesempio:228


IDN Naming ServiceStudio di fattibilitàradar.det.unifi.itPRI URL NextStep Attribute Authority* localhost40.* localhost40.37 www.telemat.det.unifi.itTabella 9.3: Esempio di rappresentazione <strong>dei</strong> dati interni di un server LS radicePRI URL NextStep Attribute Authority40.37.* localhost40.37/01 www.ing.unifi.it40.37/01 www.bl.uk40.37.24 www.web.mit.eduTabella 9.4: Esempio di rappresentazione <strong>dei</strong> dati interni di un server LSRappresentazione interna <strong>dei</strong> dati. In analogia a LDNS, anche <strong>per</strong> il LocalizationService è stata adottata una semplice modalità di rappresentazione interna<strong>dei</strong> 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 cinquecampi, corrispondenti alle informazioni necessarie affinché un server possaespletare il servizio di risoluzione. La semantica <strong>dei</strong> vari campi è simile a quellaesaminata <strong>per</strong> LDNS; la differenza principale risiede nel ruolo svolto dal campoPRI, che in questo caso svolge la funzione di chiave primaria, e nell’introduzionedel campo URL contenente gli URL corrispondenti al PRI da risolvere.In altri termini si ha che tutte le righe della tabella, che sono caratterizzatedalla presenza della stessa voce nel campo PRI, conterranno un URL che andrànel messaggio descrittore inviato dal server LS in risposta ad una richiesta dirisoluzione.Andando ad analizzare i dati presenti nelle due tabelle, risulta evidente comela struttura dati in tabella 9.3 si riferisca ad un server LS radice, in quanto contieneuna voce caratterizzata dal valore * nel campo LRI e dal valore localhostnel campo NextStep.La tabella 9.4 si riferisce invece ad un server LS autoritativo su tutti i PRI cheiniziano con 40.37; in particolare si può osservare come esso contenga due URL229


IDN Naming ServiceStudio di fattibilitàdistinte (www.bl.uk 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 fedelmentequanto appena descritto <strong>per</strong> LDNS. In particolare le caratteristicheprincipali di LS possono essere sintetizzate nei punti seguenti:• all’interno di ogni client LDNS è presente un file di configurazione in cuisono cablate alcune informazioni indispensabili all’avvio del processo dirisoluzione, quali la URI del primo server da contattare e la porta a cuiesso è in ascolto;• le richieste di risoluzione sono formulate mediante <strong>dei</strong> messaggi HTTP dirichiesta che, in conformità allo standard XDI/XRI, utilizzano il metodoGET. In particolare ogni messaggio contiene la linea d’intestazione User-Agent che specifica l’identità del richiedente, <strong>per</strong>mettendo di distingueretra il client che ha effettivamente originato la richiesta di risoluzione e illato client di un server LS;• la risposta ad una richiesta di risoluzione è costituita da un messaggioHTTP il cui codice a tre cifre è 200 OK nel caso in cui il nome sia statoeffettivamente risolto, oppure 404 Not Found se il nome non esiste all’internodel 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 LookAheade senza Look-Ahead. L’informazione relativa alla modalità di funzionamentoè stata cablata all’interno di ogni server mediante un file di configurazioneche viene acceduto al momento dell’avvio. Tale file contieneanche altre informazioni utili al corretto funzionamento del server tra cuila porta a cui esso è in ascolto e la URI di un server radice autoritativosull’intero spazio <strong>dei</strong> nomi. Ovviamente nel caso in cui l’amministratoredi sistema cambi alcune impostazioni del file di configurazione, il serverdovrà essere riavviato in modo tale da poter mettere in pratica i nuovisettaggi;• <strong>per</strong> la rappresentazione interna <strong>dei</strong> dati di ogni server viene utilizzato undatabase relazionale che viene sfruttato come storage system al posto delfile system <strong>per</strong> motivi di comodità di interrogazione della struttura datitabellare;• LS è dotato di un meccanismo di caching del tutto analogo a quello diLDNS. In particolare la manutenzione della tabella relativa al cachingviene effettuata da un’apposito thread che scandisce quotidianamente latabella ed elimina tutte le voci la cui scadenza è anteriore alla data odierna.La data di scadenza <strong>dei</strong> nomi contenuti nella cache viene determinata almomento del loro inserimento in tabella aggiungendo alla data correnteun numero predefinito di giorni e/o ore. Tale parametro è cablato nel filedi configurazione di ogni server e può essere variato dall’amministratoredi sistema;230


IDN Naming ServiceStudio di fattibilità• le richieste di inserimento di un nuovo nome sono formulate mediante <strong>dei</strong>messaggi HTTP di richiesta che utilizzano il metodo PUT. In particolareogni messaggio contiene la linea d’intestazione Content-Location chespecifica la URL, associata al PRI di cui si richiede l’inserimento;• la risposta ad una richiesta di risoluzione presenta un formato identico aquello esaminato <strong>per</strong> LDNS. In particolare la linea di stato del messaggiocontiene il codice 200 OK se la risposta è positiva e 409 Conflict se larisposta è negativa.Risoluzione inversaI descrittori. Analogamente a quanto visto <strong>per</strong> la risoluzione diretta, la rispostaè costituita da un descrittore in formato XML come quello mostrato infigura 9.17. Dal momento che anche la risoluzione inversa offre un servizio ditraduzione 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 includeretutti i possibili LRI che fanno riferimento ad un dato PRI. lri://it/regione/toscana/atto3375q9 lri://istat/cittadini/fi/RSSMRA03 lri://it/ministero/interni/atto498p Figura 9.17: Descrittore XML relativo alla risoluzione inversaRappresentazione interna <strong>dei</strong> dati. In analogia alla risoluzione diretta,anche <strong>per</strong> quella inversa è stata adottata una semplice modalità di rappresentazioneinterna <strong>dei</strong> dati in forma tabellare attraverso la quale memorizzare lecorrispondenze “uno a molti” tra PRI e LRI. Come illustrato nella tabella 2.7,ogni tabella risulta strutturata in tre campi, corrispondenti alle informazioninecessarie affinché un server possa espletare il servizio di risoluzione inversa. Lasemantica relativa a tali campi è la seguente:• PRI: chiave primaria della tabella che rappresenta l’LRI di cui si chiede larisoluzione inversa;• LRI: il LRI corrispondente al PRI da risolvere;• Authority: campo che rappresenta l’autorità relativa al PRI a cui siriferisce la entry nella tabella.Da quanto detto è <strong>per</strong>tanto evidente che ogni riga della tabella, caratterizzatadalla presenza di una stessa voce nel campo PRI, conterrà un LRI che andrà231


IDN Naming ServiceStudio di fattibilitànel messaggio descrittore inviato dal server LS in risposta ad una richiesta dirisoluzione inversa.PRI LRI Authority25.26.27/01 lri://w1/w2/w325.26.27/01 lri://w5/w625.26.27/01 lri://w12Tabella 9.5: Esempio di rappresentazione <strong>dei</strong> dati interni di un server LS <strong>per</strong> larisoluzione inversaPRI LRI TTL25.26.27/01 lri://w1/w2/w3 Ing125.26.27/01 lri://w5/w6 Ing225.26.27/01 lri://w12 Ing1Tabella 9.6: Esempio di rappresentazione <strong>dei</strong> dati interni di un server LS <strong>per</strong> ilcaching relativo alla risoluzione inversaGli algoritmi. Il servizio di risoluzione inversa <strong>per</strong>mette di risalire a tuttii nomi logici che fanno riferimento ad uno stesso PRI. Essendo speculare aiprecedenti, la risoluzione inversa è stata pensata come un servizio a se stanterispetto a LDNS e LS tanto da poter essere implementata mediante un sistemadi server indipendenti. Per poter avviare un processo di risoluzione inversa, ènecessario che il client abbia a disposizione un server di default al quale inoltrarela richiesta di risoluzione. Analogamente a quanto visto nel caso di LDNS e LS,l’informazione relativa al primo server da contattare è stata cablata all’internodel client sottoforma di un file di configurazione che viene acceduto dal client almomento dell’esecuzione. Le richieste di risoluzione vengono formulate tramiteun messaggio HTTP il cui formato generico è:GET un/qualsiasi/PRI HTTP/1.1User-Agent : lsRev 1.0Il formato della richiesta è uguale a quello esaminato <strong>per</strong> LDNS e LS; l’unicadifferenza risiede nel fatto che in questo caso la prima riga contiene il PRIdi cui si richiede la risoluzione inversa. Come al solito, la linea d’intestazioneUser-Agent specifica l’identità del richiedente, <strong>per</strong>mettendo di distinguere trail client che ha effettivamente originato la richiesta di risoluzione e il lato clientdi un server della catena di risoluzione. A questo punto il server contattato,sfruttando la stessa infrastruttura descritta <strong>per</strong> la risoluzione diretta, individuail server autoritativo sul PRI di cui è stata richiesta la risoluzione. Ciò è necessariopoichè è tale server che nella propria struttura dati interna, relativa allarisoluzione inversa, detiene i nomi logici che fanno riferimento al PRI. In particolaresi evidenzia che <strong>per</strong> la determinazione del server autoritativo possonoessere impiegati entrambi i meccanismi: con Look-Ahead e senza Look-Ahead.232


IDN Naming ServiceStudio 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 vieneacceduto al momento dell’avvio. Ovviamente se l’amministratore di sistemacambia alcune impostazioni del file di configurazione, il server deve essere riavviato.La risposta ad una richiesta di risoluzione è costituita da un messaggioHTTP nella cui linea di stato è presente un codice a tre cifre, indicante l’esitocon cui la richiesta è stata processata. Se il PRI è stato risolto con successo, ilformato generico dell’header del messaggio è:HTTP/1.1 200 OKServer: ldRev 1.0I nomi logici associati al PRI sono contenuti in un descrittore XML posto nelbody del messaggio. Viceversa se il PRI non è stato risolto, il formato genericodel messaggio è:HTTP/1.1 404 Not FoundServer: ldRev 1.0Anche il servizio di risoluzione inversa è dotato di un meccanismo di cachingdel tutto analogo a quello di LDNS e LS. L’inserimento <strong>dei</strong> nomi nella cacheavviene ogni volta che un messaggio, contenente uno o più LRI risolti, transitaattraverso il server in questione prima di giungere al client che ha effettivamenteoriginato la richiesta di risoluzione. Per la manutenzione della tabella relativaal caching è stato scelto di impiegare un’apposito thread che scandisce <strong>per</strong>iodicamentela tabella, eliminando tutte le voci la cui scadenza è anteriore alla dataodierna. La data di scadenza <strong>dei</strong> nomi contenuti nella cache viene determinataal momento del loro inserimento in tabella aggiungendo alla data corrente unnumero predefinito di giorni e/o ore. Tale parametro è preimpostato nel file diconfigurazione di ogni server e può essere variato dall’amministratore di sistema.Per quanto riguarda l’inserimento di un nuovo nome, va detto che il meccanismoutilizzato è simile a quello esaminato <strong>per</strong> 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 <strong>per</strong> la risoluzione in modo da determinareil server autoritativo sul PRI in questione e da inoltrargli la richiesta diinserimento. Analogamente a quanto detto in precedenza, tutti i server coinvoltipossono funzionare sia in modalità con Look-Ahead che senza Look-Ahead.Le richieste di inserimento vengono formulate tramite un messaggio HTTP conmetodo PUT, il cui formato generico è:PUT un/qualsiasi/PRI HTTP/1.1User-Agent : ldns 1.0Content-Location : un/qualsiasi/LRICome si può vedere, la prima riga contiene il PRI che <strong>per</strong>mette di determinareil server autoritativo sul LRI da inserire, mentre la linea d’intestazioneContent-Location specifica il nome logico di cui si richiede l’inserimento. Larisposta ad una richiesta di inserimento è costituita da un messaggio HTTPnella 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


IDN Naming ServiceStudio di fattibilitàHTTP/1.1 200 OKServer: ldRev 1.0Evidentemente il formato del messaggio è analogo a quello esaminato <strong>per</strong> larisoluzione; l’unica differenza risiede nel fatto che questa volta nel descrittoreXML, posto all’interno del body del messaggio, è specificato il nome logicoinserito. Nella seconda eventualità il formato generale della risposta è invece ilseguente:HTTP/1.1 409 ConflictServer: ldnsd 1.0234


Capitolo10Virtual Repository ServiceIl principale servizio di Virtual Repository (VR) è fornire a livello applicativola navigazione nello spazio delle informazioni in maniera logica ed uniforme.Virtual Repository è responsabile della gestione degli aspetti strutturali <strong>dei</strong> 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, <strong>per</strong>tanto nelle prossime paginesaranno discussi principalmente RAS e IS, già brevemente introdotti nelcapitolo 8.La logica interna a Resource Aggregation Service assume un ruolo centralenella orchestrazione <strong>dei</strong> compiti del livello ed integrazione <strong>dei</strong> servizi. RAStratta le informazioni da un punto di vista strettamente strutturale: in manieraconforme ad IDN-IM gestisce le relazioni di aggregazioni ed attua i meccanismiprevisti dal modello, sfruttando di servizi di pari livello o forniti dal sottostanteInformation History Service (IH).Per compiti del livello VR verrà fatto più volte riferimento ai concetti legatial versioning, nonostante VR si occupi degli aspetti strutturali. È importanteprecisare la differenza tra i meccanismi propri del versioning e la sua gestione.Come affermato nel capitolo 8 il versioning è completamente trattato nellivello inferiore IH, ma è a questo livello che si attua la gestione orchestrata delleversioni, assegnando la “semantica” alle funzionalità invocate verso il basso.


Virtual Repository ServiceRichiami al modello IDN-IMIn sostanza si distingue tra le o<strong>per</strong>azioni propriamente legate al versionamento(relative alla gestione <strong>dei</strong> link di versioning di livello IH) e la gestione delversionamento (ovvero <strong>dei</strong> link di propagazione di livello VR).La strutturazione granulare delle informazioni versionate, in tutte le componentidi dati e metadati, richiede molteplici richiami al modello di versioning edai servizi fondamentali offerti da IH. Si cercherà <strong>per</strong>tanto di evidenziare come siadeterminante la sinergia tra VR ed IH, mantenendo il minimo accoppiamentotra i due servizi e sempre tenendo in considerazione che VR si occupa <strong>dei</strong> soliaspetti strutturali.Identity Service rappresenta il servizio che approva o nega l’esecuzione <strong>dei</strong>meccanismi internamente a VR a fronte delle richieste provenienti dal livelloapplicativo. La sua natura estremamente specializzata e rivolta alla sicurezzadi sistema verrà trattata separatamente al fine di non rendere l’esposizione diRAS 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 convergonole principali convenzioni previste da IDN-IM. Le applicazioni potrannotrarre il massimo vantaggio dai servizi esposti da VR, solamente recependo ilmodello IDN-IM.10.1 Richiami al modello IDN-IMIl modello dell’informazione IDN-IM è stato progettato ispirandosi al modellodi documento di UEVM [ABCM99] e con la finalità di applicare gli stessi principial versioning delle informazioni.Nel modello IDN-IM le informazioni atomiche costituiscono l’insieme <strong>dei</strong> daticontenuti nel documento. Essendo il documento strutturato, tali dati sono messiin relazione tramite le informazioni primitive. La struttura è gerarchica: i nodiche si trovano ai livelli più alti della gerarchia rappresentano, da un punto divista concettuale, il punto d’accesso all’informazione strutturata che si sviluppada essi fino alle foglie. Modificare uno qualunque <strong>dei</strong> nodi appartenenti a talegerarchia significa modificare l’informazione complessiva.UEVM è un modello che <strong>per</strong>mette di gestire le versioni di documenti strutturatiad albero con la particolarità di riuscire a versionare anche gli aspetti strutturali.In altre parole il documento è tracciato nelle modifiche del contenuto edelle relazioni esistenti fra contenuti.Il fatto che UEVM si limiti a gestire documenti strutturati ad albero derivadal considerare l’informazione come entità individuale: il documento. In UEVMdue documenti diversi sono entità distinte e completamente scorrelate.In IDN-IM viceversa l’informazione è distribuita e una delle caratteristichedi maggior rilievo del modello è proprio la sua condivisione documenti e soggettidiversi. Il documento in IDN-IM è considerato come l’aggregazione diinformazioni distribuite.Questo porta ad una struttura più generale rispetto a quella ad albero inquanto la condivisione di un’informazione fra due documenti distinti generaun DAG: si hanno due alberi parzialmente sovrapposti e l’intersezione è data236


Virtual Repository ServiceRichiami al modello IDN-IMesattamente dal sotto albero che rappresenta l’informazione condivisa. Generalizzando,lo stesso risultato si ottiene anche nel caso della condivisione diun’informazione da parte di N documenti, con N arbitrario.Da questa considerazione si deduce che le gelazioni generiche fra nodi IDN-IMportano ad avere un DAG. Per questo motivo, e comunque <strong>per</strong> avere maggioreflessibilità nella modellazione dell’informazione, in IDN-IM si parla di DAGanche limitatamente al contesto del singolo documento.IDN-IM è un modello strutturato e prevede l’esistenza di due tipologie diinformazioni (vedi capitolo 7):• primitive (Primitive Information Unit, PIU);• atomiche (Atomic, Information Unit, AIU).Le informazioni atomiche vengono incapsulate in informazioni primitive: soloqueste ultime hanno un indirizzo univoco (PRI), ottenuto da LDNS, e possonoessere associate ai nodi del DAG relativo al documento. Tali nodi contengonoquindi:• le informazioni atomiche costituite da coppie “”, i dati verie propri definiti nei livelli su<strong>per</strong>iori;• i metadati definiti nei livelli su<strong>per</strong>iori;• le relazioni verso altri nodi, proprie delle informazioni primitive.Per il livello VR esistono quindi nodi al cui interno è possibile individuare duesezioni distinte, che nascono a seguito del principio di imbustamento presentein 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 dellerelazioni definite a livello VR;• un body, nel quale VR imbusta tutti i dati e i metadati che non sono disua competenza (di competenza del livello applicativo).IndirizzamentoPRIHeaderDati e metadati dicompetenza di StructureBodyDati e metadati di competenza<strong>dei</strong> livelli su<strong>per</strong>ioriFigura 10.1: Nodi di livello IH237


Virtual Repository ServiceResource Aggregation Service10.1.1 La struttura dello storicoPrima di entrare nel merito di come il layer VR implementa le specifiche dettatedal modello IDN-IM è utile ricordare brevemente le notazioni, le definizionie 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 revisionedel documento. Con modifica si intende un’o<strong>per</strong>azione che comprende una opiù variazioni all’interno della configurazione durante un intervallo di tempostabilito dall’inizio e la fine della sessione di lavoro.L’entità della modifica nel suo complesso è misurabile dall’utente che inmodo automatico dal sistema e dipende dall’entità e dal numero delle singolevariazioni elementari che la costituiscono.L’insieme delle revisioni è una codifica dell’evoluzione temporale delle configurazionied è quindi un insieme nel quale esiste un ordinamento totale: datedue 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 lastessa configurazione, dove con il simbolo < si indica l’o<strong>per</strong>atore “meno aggiornatodi”. 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 temporaledi un’informazione, ma può non essere abbastanza flessibile da favorirela coo<strong>per</strong>azione fra più utenti e, in generale, l’authoring concorrente.Per avere la flessibilità necessaria occorre poter creare esplicitamente dellediramazioni (branch) all’interno dello storico <strong>per</strong> <strong>per</strong>mettere lo sviluppo concorrente(quindi in parallelo) su due o più rami indipendenti. Creare branchall’interno di uno storico lineare porta ad avere una struttura dello storico adalbero. In questo caso con revisione si intende una nuova versione di un elementopresente in un determinato branch.Infine può risultare necessario far convergere (o<strong>per</strong>azione di merge) due ramidistinti su un unico ramo e così la struttura complessiva che si ottiene è un DAG.Il DAG <strong>per</strong>mette quindi di rappresentare le relazioni fra un qualunque insiemedi versioni di un’informazione.10.2 Resource Aggregation ServiceLa logica interna di RAS è in grado di seguire i link associati ai nodi dellerisorse PIU. Se la direzione seguita è verso le foglie del DAG allora si parla diaggregazione di PIU (<strong>per</strong> costruire un documenti), se invece è nel senso oppostosi parla di propagazione delle versioni ai nodi aggreganti.L’aggregazione prevede un meccanismo elementare che interessa solo gliaspetti strutturali, e proprio <strong>per</strong> questo più semplice da comprendere. Viceversala propagazione delle versioni coinvolge sia concetti strutturali che diversionamento, pur lavorando o<strong>per</strong>ativamente sulla struttura.238


Virtual Repository ServiceResource Aggregation Service10.2.1 Vista sullo storico delle informazioniIl servizio di gestione del versioning (e non il versioning) di un documentoviene fornito integralmente ed esclusivamente dal layer VR secondo le specifichestabilite nel modello IDN-IM.Per discutere in dettaglio il servizio fornito da VR, e come questo sia conformealle specifiche formulate in IDN-IM, è necessario evidenziare i seguentiaspetti sono tra loro indipendenti:• la gestione dello storico del documento ovvero la direzione e l’arbitraggiosulla creazione, l’aggiornamento e il mantenimento della consistenza delleinformazioni. Sebbene le o<strong>per</strong>azioni elementari di versioning siano realizzatea livello sottostante (IH), spetta a VR stabilire la sequenza o<strong>per</strong>ativadella loro esecuzione, coinvolgendo i sottoservizi necessari;• la navigazione nello storico del documento ovvero l’insieme di tutti queimeccanismi finalizzati a fornire il servizio di indirizzamento all’informazioneversionata, in quanto deve essere possibile navigare nello spazio delleversioni dal livello su<strong>per</strong>iore.10.2.2 Relazioni strutturaliIl DAG definito <strong>per</strong> il modello IDN-IM è ottenuto andando a considerare leinformazioni 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 legamecon la gestione delle versioni, essendo informazioni atomiche (confronta 7.5.2).In riferimento al modello IDN-IM, in corrispondenza <strong>dei</strong> link di composizione,è necessario prevedere un meccanismo che <strong>per</strong>metta di propagare le modifiche<strong>dei</strong> figli verso i genitori. Tale algoritmo rientra a pieno titolo fra le mansionilegate alla gestione dello storico e <strong>per</strong>tanto deve essere definito ed applicato nelcontesto del layer VR. VR deve quindi prevedere un secondo tipo di link, dettolink di propagazione, che <strong>per</strong>metta di risalire nella gerarchia <strong>dei</strong> nodi presentinel dominio del documento come richiesto dal modello IDN-IM.In corrispondenza di tutti i link di aggregazione esistono i duali link dipropagazione che hanno verso opposto ai precedenti. I link di propagazionecompletano la vista strutturale sulle informazioni.Per chiarire questo concetto si faccia riferimento alla figura 10.2 nella qualeil documento al tempo t 0 è costituito da una radice X1 che aggrega due figli Y1 eZ1 tramite opportuni link di composizione, rispettivamente C1 e C2. Esistendouna sola revisione di ogni nodo a tali link di composizione vengono associati i linkdi 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 allaradice X. In questo caso i link di propagazione P1 e P2 sono stati rimossi e sonostati inseriti P3 e P4 in corrispondenza <strong>dei</strong> link di composizione C3 e C4 presentinell’ultima revisione della radice X.Per completezza espositiva osserviamo in figura 10.2 un terzo tipo di link,detto link di versione, che <strong>per</strong>mette di rappresentare le relazioni presenti franodi ad istanti diversi. Fanno parte di questa categoria i legami esistenti fra una239


Virtual Repository ServiceResource Aggregation ServiceDocumento al tempo t 0 Documento al tempo t 1X1X1V2X2Y1P1C1C2P2Z1Y1C1V1C2P3Y2C3 C4P4Z1Legenda: tipologie di linkLink di PropagazioneLink di AggregazioneLink di VersioneFigura 10.2: Link di strutturali e di versioningrevisione e la successiva, una revisione e la precedente etc. (tutte le tipologiedi link che rientrano in questa categoria verranno introdotte dettagliatamentenel paragrafo 11.3 a pagina 262). La gestione integrale <strong>dei</strong> link di versione èindubbiamente di competenza del livello IH. In figura 10.2 è presente un esempionel quale si ipotizza l’esistenza <strong>dei</strong> soli link di versione presenti dalla revisioneprecedente a quella successiva.VR attua la propagazione delle versioni dai figli verso i genitori seguendo ilink di propagazione. Prendendo l’esempio precedente (figura 10.2), la nascitadi una nuova versione del figlio (Y2) determina, tramite il meccanismo di propagazione,una nuova versione del genitore (X2) che deve essere connessa, tramiteun 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 delfiglio manipolando i link di aggregazione (nell’esempio si tratta di creare C3 eC4).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 o<strong>per</strong>azionielementari <strong>per</strong> le versioni. In altre parole i link di versioning vengono gestitiesclusivamente da IH e mantenuti all’interno dell’header del nodo definito aquesto livello. Però è necessario corredare l’interfaccia, fornita a Virtual Repository,di opportune primitive e/o definire il formato <strong>dei</strong> messaggi scambiati frai due livelli in modo da <strong>per</strong>mettere a Virtual Repository di agire, secondo leproprie necessità e competenze, sugli aspetti strutturali del documento. Questo<strong>per</strong>mette a Virtual Repository di inserire, modificare ed eliminare i link di240


Virtual Repository ServiceResource Aggregation Servicecomposizione in base alle proprie esigenze e navigare nello spazio del documento.Questo approccio è simile a quello proposto da DOM [ABC + 04]: l’interfacciamessa a disposizione <strong>per</strong>mette di creare, modificare, cancellare e navigare frai nodi dell’albero del documento, lasciando alla applicazione (nel nostro casoVR) l’invocazione delle funzionalità, l’implementanzione del DOM ha l’onere diattuare le funzionalità.10.2.3 La propagazione delle modificheConsideriamo l’esempio di un libro costituito da capitoli, suddivisi a lorovolta in paragrafi ed in ultima istanza da frasi. Modificare una frase significamodificare il paragrafo che la contiene, ma anche il capitolo contenente il paragrafoe quindi tutto il libro, sancendone quella che in termini tipografici vienedetta nuova edizione.IDN-IM <strong>per</strong>mette di modellare il comportamento descritto tramite il concettodi propagazione che viene applicato sui genitori in corrispondenza dellanascita di una nuova revisione <strong>dei</strong> figli all’interno del DAG.Si osservi che la richiesta di salvataggio di una variazione del contenuto di unnodo non genera necessariamente una nuova revisione (che dipende dallo statoiniziale 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 meccanismodi propagazione (viene creata una nuova revisione in quanto il nodo dipartenza è “congelato” e non può essere modificato);• changing: il sistema sovrascrive il contenuto del nodo e non attua nessunapropagazione.Nel seguito di questa trattazione, se non espressamente specificato, si assumeche il caso “frozen”. Il motivo è dovuto al fatto che in corrispondenza dellanascita 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 <strong>dei</strong> 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 delcaso preso in esame in UEVM, la struttura di riferimento è un DAG e quindiogni nodo può avere zero, uno o più genitori (mentre in UEVM può avere almassimo un genitore in quanto la struttura è un albero). Questo aspetto èininfluente ai fini dell’algoritmo di propagazione a patto di applicarlo a tutti igenitori presenti (senza ripetizioni).241


Virtual Repository ServiceResource Aggregation Service10.2.4 Applicazione delle diramazioni e delle fusioniLe o<strong>per</strong>azioni di branching e di merging sono legate alla gestione dello storicodi un documento. Nel momento in cui si crea un branch la gestione dell’evoluzionetemporale al suo interno risulta essere del tutto indipendente rispetto aquella relativa al documento di provenienza.Generare un branch equivale a creare un nuovo documento (duplicato) cheabbia in comune con quello di partenza almeno un nodo dello storico. In conclusioneall’interno di ogni branch esiste un ordinamento totale delle revisioni chemodella l’evoluzione temporale del documento (relativo a quel branch), inoltrenon esiste nessuna correlazione fra revisioni appartenenti a branch diversi, senon quella di avere predecessori (nello storico) comuni.L’equivalenza a cui è stato appena fatto riferimento fra branch e nuovo documentonon è soltanto concettuale, ma è stata sfruttata ampiamente nella praticain molti SCM (Software Configuration Management), fra i quali il CVS [FB03]e Subversion [CSFP04].È comunque utile riferirsi a Subversion come sistema di paragone in quantoutilizza il modello di versioning UEVM[Ask02].BranchingIn 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 <strong>dei</strong>nodi di interesse a Virtual Repository in quanto è un’o<strong>per</strong>azione applicata aldocumento come entità strutturata. Questa scelta <strong>per</strong>mette di ottenere ancheuna maggiore flessibilità rispetto a quella di Subversion in quanto <strong>per</strong>mette diipotizzare l’esistenza di diramazioni nelle quali non viene effettuato il branch diogni nodo dell’albero lasciando uno o più nodi in comune fra il branch e il ramoprincipale.Quest’ultimo caso è messo in evidenza in figura 10.3 nella quale la radiceG ha due figli: F’ e F”. Il branch del documento è stato effettuato creando unbranch della radice e del figlio F’ mentre il figlio F”non è stato duplicato. Questo<strong>per</strong>mette di propagare le modifiche di F”in entrambi i rami di sviluppo (il ramoprincipale, che si sviluppa creando una nuova revisione di G2, e del branch chesi 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 propagazioneavviene su entrambi i branch dando vita alle revisioni G3 nel ramo principale eG2.2 nel branch. Per semplicità il figlio F’, presente in figura 10.3, non è statoriportato in quanto non viene modificato durante la propagazione: G3 continuaad aggregare F’2 come G2 e G2.2 continua ad aggregare F’2.1 come G2.1.MergingL’o<strong>per</strong>azione complementare al branching è il merging. Da un punto di vistao<strong>per</strong>ativo effettuare un merge significa integrare le modifiche presenti su unbranch in un altro branch. L’o<strong>per</strong>azione può essere effettuata secondo modalitàdiverse che variano con il contesto.242


Virtual Repository ServiceResource Aggregation ServiceG1G2Radice GG2.1F''1F''2Figlio F''F'1F'2Figlio F'F'2.1Figura 10.3: Branch in IDN-IM con un figlio condivisoG1G2G3Radice GLegendaTempo t < TTempo t ≥ TF''1F''2G2.1 G2.2F''3T = istantedella nascitadel nodo F''3RelazioniNodiAbcAbcFiglio F''Figura 10.4: Propagazione in presenza di un figlio condivisoSupponendo quindi di o<strong>per</strong>are con documenti IDN occorre stabilire cosasignifichi fondere informazioni atomiche e informazioni primitive, elementi checostituiscono i documenti presenti nei due branch di interesse. In realtà si ricordache le informazioni atomiche sono incapsulate all’interno di quelle primitive.È possibile definire un’o<strong>per</strong>azione 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 casoil merge è banale e il risultato è l’informazione stessa; altrimenti l’o<strong>per</strong>azionedi confronto può <strong>per</strong>mettere di stabilire l’entità della differenza e si possonopresentare le seguenti situazioni:• il contesto <strong>per</strong>mette al sistema di scegliere una delle due informazioniautomaticamente, scartando l’altra;• il contesto non <strong>per</strong>mette al sistema di effettuare una scelta, in tal caso èl’utente a dover prendere una decisione;243


Virtual Repository ServiceResource Aggregation Service• le informazioni sono diverse, ma confrontabili nei contenuti: il sistema,automaticamente o sotto la su<strong>per</strong>visione dell’utente, genera una terzainformazione atomica sulla base di convenzioni prefissate.L’ultimo caso è interessante <strong>per</strong>ché è quello relativo all’esempio, introdottoprecedentemente, di Subversion: le informazioni atomiche sono rappresentatedal contenuto di file (molto probabilmente codice sorgente scritto in formatotestuale); quindi è possibile applicare un confronto riga <strong>per</strong> riga, o<strong>per</strong>azione che<strong>per</strong>mette di integrare le differenze nel caso in cui non siano presenti conflitti (ilsistema genera automaticamente la nuova versione) oppure è in grado di rilevarlie <strong>per</strong>mette all’utente di intervenire (il sistema genera la nuova versione sotto lasu<strong>per</strong>visione dell’utente).Per quanto riguarda le informazioni primitive, occorre specificare cosa si intende<strong>per</strong> uguaglianza tra di esse. Da un punto di vista astratto è possibileconsiderarle come il punto di accesso all’informazione complessiva che si sviluppada esse fino alle foglie, come evidenziato nel paragrafo 7.1.2. Questo portaalla conclusione che il concetto di uguaglianza fra informazioni primitive nonè esprimibile esclusivamente sulla base del confronto del contenuto informativo<strong>dei</strong> nodi che le rappresentano, ma in generale occorre andare a consideraree confrontare ricorsivamente i nodi che tali informazioni primitive aggregano.Dato che questo compito spetta ai livelli su<strong>per</strong>iori occorre delegare a loro anchela scelta <strong>dei</strong> criteri finalizzati alla valutazione dell’uguaglianza o meno trainformazioni di questo tipo.A seguito di questa considerazione è possibile concludere che IH deve fornireun supporto <strong>per</strong> il merging che <strong>per</strong>metta a VR di coprire tutte gli scenaripossibili.In riferimento alla figura 10.5 la seguente definizione di merging, valida allivello VR, <strong>per</strong>mette di ottenere questo risultato: fondere (merge) due elementiA e B (nodi IDN-IM) appartenenti a branch diversi dello stesso storico, significagenerare un terzo elemento C ottenuto da essi a seguito dell’esecuzione di undeterminato algoritmo. Il nuovo elemento C figura nello storico come successoresia di A che di B e, <strong>per</strong> convenzione, appartiene al ramo di A. La definizione el’esecuzione dell’algoritmo di generazione vengono lasciate al livello applicativoe possono essere quindi diversificate in base al contesto.Si osservi che, in questi termini, il merge è un’o<strong>per</strong>azione definita fra duebranch che fonde il secondo sul primo. Questo si nota anche osservando che A eB devono essere l’ultima revisione nel relativo branch, come mostrato in figura.L’o<strong>per</strong>atore di “merge” non è quindi commutativo: fondere A e B su C è diversoda fondere B e A su C. Nel primo caso C appartiene al ramo di A mentre nelsecondo al ramo di B.Il fatto che l’elemento C sia il successore di entrambi gli elementi si evidenziaconsiderando che, a seguito di un’o<strong>per</strong>azione di merge, viene attuata lapropagazione delle versioni in modo equivalente su entrambi i branch di origine.Facendo riferimento alla figura 10.6 G’7, prima del merge, aggrega <strong>per</strong> composizioneA mentre G”4 aggrega B. L’o<strong>per</strong>azione 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’o<strong>per</strong>azione chedetermina, <strong>per</strong> convenzione, il raggiungimento della fine del branch; dopo aver244


Virtual Repository ServiceResource Aggregation ServiceStorico dell'elementoACBFusione o MergeA,B in C.Figura 10.5: Merge di due nodiG'7G'8G''4G''5ACBNuove relazioniVecchie relazioniAbcAbcNuovi nodiVecchi nodiFigura 10.6: Propagazione a seguito di un mergeeffettuato il merge non risulta più possibile generare <strong>nuove</strong> revisioni a partiredai nodi fusi l’uno con l’altro, i nodi A e B dell’esempio precedente. Questalimitazione è soltanto apparente in quanto è possibile generare nuovi branchpartendo da essi. In questo modo si può comunque “simulare” la strategia dilavoro che consiste nel portare avanti lo sviluppo su due branch separati integrando,quando necessario, le modifiche di uno nell’altro. Infatti si può pensareche C appartenga ad uno <strong>dei</strong> due branch di partenza (ad esempio quello nelquale si trova A) mentre a partire dall’altro (B) viene generato un nuovo branch245


Virtual Repository ServiceResource Aggregation Servicesul quale continuare lo sviluppo.Un esempio relativo a questo caso è riportato in figura 10.7.a. In particolareA, 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<strong>per</strong> questo motivo viene creato, al tempo 4, un nuovo branch. Successivamenteviene effettuato il merge con il ramo di sviluppo principale; si osservi che non èobbligatorio effettuare questa o<strong>per</strong>azione immediatamente in quanto è possibilecreare un numero arbitrario intermedio di <strong>nuove</strong> revisioni.Storico dell'elementoStorico dell'elementoTempo Ramo Principale1 352MergeMergeBranch4Ramo SecondarioBranch6Tempo Ramo Principale1 3 5IntegrazioneIntegrazione2 4 6Ramo Secondarioa) Sequenze di branche di merge.b) Integrazioni a livelloapplicativo.Figura 10.7: Gestione di due rami di sviluppo concorrenteUn’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 Bantenato di C a livello IH. In questo modo, partendo da B, è possibile continuarelo sviluppo generando <strong>nuove</strong> revisioni. Un esempio relativo a quest’ultimo casoè riportato in figura 10.7.b, come in precedenza, i nodi A, B e C corrispondonorispettivamente a quelli creati al tempo 1, 2 e 3.10.2.5 Osservazioni sugli aspetti strutturaliIl branching e il merging sono stati definiti e discussi in riferimento ad unsingolo nodo oppure in riferimento al caso di un nodo aggregato <strong>per</strong> composizioneda altri nodi.Per quanto riguarda le relazioni “figlio-genitori”, necessarie <strong>per</strong> la gestionedella propagazione delle modifiche, l’aver considerato soltanto due livelli dellagerarchia nella struttura del documento non è limitativo. Tutti i ragionamentieffettuati, possono essere estesi ricorsivamente <strong>per</strong>mettendo quindi di risalire,livello dopo livello, la struttura di un qualunque documento, indipendentementedalla sua profondità di albero.Al contrario le relazioni inverse, quelle “genitore-figli”, necessarie <strong>per</strong> modellarela struttura del documento, non vengono gestite dal livello IH e <strong>per</strong>tanto,246


Virtual Repository ServiceIdentity Servicein questo contesto, non risulta strettamente necessario discutere come devonoessere 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 presentarealcuni possibili scenari nei quali si mostra come possono essere applicatiin contesti reali.Si considerino, ad esempio, <strong>dei</strong> documenti (costituiti da un numero arbitrariodi nodi) che devono essere trattati nei branch come un’unica entità. Questo èesattamente il caso gestito da Subversion in quanto la copia del ramo principalein 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 nodosecondo le modalità esposte in precedenza e connettere il nodo che si ottiene aseguito del branch di ogni genitore al nodo ottenuto dal branch <strong>dei</strong> figli comeindicato in figura 10.8 <strong>per</strong> una sola informazione ed ulteriormente evidenziatoin figura 10.9 <strong>per</strong> un intero documento.Storico dell'elemento genitoreG1G2G2.1Link diComposizioneF1F2Link di RevisioneF2.1Link di BranchStorico dell'elemento figlioFigura 10.8: Branch di un nodoLa fase di merging viene trattata in modo duale andando ad applicare opportunialgoritmi di confronto e generando una nuova versione <strong>per</strong> ogni coppiadi nodi che vengono fusi. Si osservi che, in questo esempio, è necessario fonderetutti i nodi degli alberi relativi ai documenti D1 e D2 <strong>per</strong> ottenere un terzodocumento che concettualmente rappresenta il risultato dell’o<strong>per</strong>azione.10.3 Identity ServiceIdentity Service (IS) è il servizio di autenticazione degli utenti che accedonoal livello VR e delle richieste che sottopongono al sistema nel suo complesso.Anche se è logicamente localizzato nel livello più elevato di IDN, assume un ruolo247


Virtual Repository ServiceIdentity ServiceGBranch deldocumentoBranchF1F2Doc. D1G.1BranchBranchF1.1 F2.1D2 = branch di D1Figura 10.9: Branch di un intero documentodi servizio trasversale poichè <strong>per</strong> una larga parte della sua definizione si sfruttae riusa la stessa infrastruttura IDN. Infatti è possibile rispondere alle seguentidomande facendo riferimento alle funzionalità di base offerte dal sistema:• come sono rappresentati i dati delle Persona?• dove risiedono i dati delle Persona?• i <strong>per</strong>messi di accesso alle risorse (Access Control List, ACL) come sonorappresentati?• dove sono memorizzate le ACL?• chi valorizza le ACL?I dati <strong>per</strong>sonali sono rappresentati nel profilo utente: la risorsa Personaaggrega, in un documento IDN, le informazioni (dati e metadati) sufficienti enecessarie <strong>per</strong> identificare e autenticare l’utente. Il luogo (sito) dove fisicamentequeste informazioni sono memorizzate è un dettaglio che dipende dai livelli piùbassi di IDN che attuano la replicazione (che in questa fase non è di necessariointeresse).La verifica delle credenziali viene effettuata ricorrendo a tecniche crittografichecome suggerito dai principali standard analizzati nel capitolo 2.Per le ACL, create ed assegnate dal responsabile dell’informazione, si adottauna rappresentazione anch’essa memorizzata in un documento IDN.10.3.1 Identità e profilo utenteIl concetto di identità digitale e gli aspetti della sua gestione sono un puntofondamentale <strong>dei</strong> servizi messi a disposizione in rete. L’identità rappresenta il248


Virtual Repository ServiceIdentity Servicemodo in cui l’utente viene riconosciuto o si fa riconoscere nel sistema. La creazionedell’identità generalmente prevede, nella sua forma essenziale, la creazionedi credenziali. Senza entrare nel dettaglio delle scelte tecniche di come generarele credenziali, risulta evidente che è necessario fornire, agli interessati, un certoinsieme di dati <strong>per</strong>sonali atti a farsi riconoscere. Ad esempio si potrebbe inserirenel documento IDN che rappresenta il profilo il certificato digitale dell’utenteed utilizzare i meccanismi previsti nelle PKI (capitolo 2) <strong>per</strong> creare (in modosicuro) l’associazione fra la <strong>per</strong>sona fisica che sta tentando di accedere al sistemaed il profilo stesso.Più un utente si fa “riconoscere” dal sistema, più il sistema è in grado dierogare <strong>dei</strong> servizi a valore aggiunto, <strong>per</strong>sonalizzati ai suoi bisogni. Dualmentepiù una organizzazione riesce a conoscere i tratti qualificanti <strong>dei</strong> propri utenti/clientipiù ha probabilità di soddisfarne i desideri e necessità (<strong>per</strong>seguendo ilproprio profitto). Ecco <strong>per</strong>chè molte aziende trovano conveniente la profilazione<strong>dei</strong> propri utenti e clienti (a volte anche in derogao violazione a normative eleggi [Inf08]).Possiamo classificare due tipologie di profilo:1. limitato: insieme di informazioni <strong>per</strong>sonali categorizzate a priori e staticamentepredefinite in quantità e tipo di dato;2. dinamico: insieme di informazioni incrementabili nel tempo e senza limitazionidi quantità e tipo di dato.Osserviamo che non è possibile stabilire a priori gli attributi di cui deve esseredotato un profilo di un’identità digitale Persona poichè sono infinite i possibiliruoli assunti (dall’ambito <strong>per</strong>sonale a quello professionale, da quello lavorativoa quello istituzionale).Sebbene esistano degli attributi di base, verosimilmente comuni a tutte le<strong>per</strong>sone, è riduttivo ingessare il profilo di un utente ad un insieme limitato didati e contemporaneamente pretendere che il profilo sia scalabile e riusabile intutti i contesti ed applicazioni.Se volessimo costruire un profilo utente scalabile, riusabile, qualificabile equantificabile nel tempo, allora è possibile affermare che IDN-IM risponde allaesigenze evidenziate. Si pensi ad un profilo composto da un insieme minimodi dati (nome, cognome, data di nascita, luogo di nascita o poco più) e dipoterlo incrementare ed aggiornare nel tempo aggiungendo o rimuovendo altreinformazioni, ora di ambito lavorativo ora di ambito <strong>per</strong>sonale.Per raggiungere questo obiettivo è possibile sfruttare la struttura a DAG e leaggregazioni del documento IDN <strong>per</strong> costruire profili utente dinamici. Partendodalle informazioni di base (quelle essenziali alla identificazione) è possibileaggregarne ulteriori in modo completamente <strong>per</strong>sonalizzabile.Per costruzione, versatilità ed adattabilità sono le caratteristiche principalidi questo profilo, che attraverso il versionamento, consente anche di costruire ericostruire la storia di una Persona.Il principio di responsabilità è inoltre a garanzia della privacy purchè le ACLsiano ben definite:• la <strong>per</strong>sona è proprietaria delle proprie informazioni;249


Virtual Repository ServiceIdentity Service• la <strong>per</strong>sona può verificare chi le ha aggregate e/o arricchite (risoluzionediretta ed inversa di LS-LDNS).Un profilo così strutturato comporta le seguenti notevoli implicazioni:• dal punto di vista della <strong>per</strong>sona: rispetto delle normative e controllocompleto delle proprie informazioni, con possibilità di verificare eventualiabusi;• dal punto di vista dell’erogatore <strong>dei</strong> servizi: incremento <strong>per</strong>sonalizzato diinformazioni senza limitazioni.10.3.2 Access Control List (ACL)L’accesso ad ogni “elemento” definito nel contesto del sistema IDN viene concessoa fronte di una verifica di opportune liste di accesso, basate sull’approcciowhite-list. Con “elemento” si intende una qualsiasi inforamzione-dato o processoche rientra nel contesto del sistema, a partire dalle informazioni primitive e dainomi LRI <strong>per</strong> finire ai nomi PRI e le istanze <strong>dei</strong> livelli che erogano i servizi.In questo paragrafo verranno presi in esame solo informazioni primitive edgli LRI <strong>per</strong>ché è su di essi che vengono verificate le ACL sulla base della Personache 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 <strong>per</strong>tanto non verranno esaminate in questasede.Con “accesso” si intende la richiesta di una qualche o<strong>per</strong>azione sull’entità: adesempio una richiesta di lettura, di modifica, di creazione oppure (in esclusivoriferimento agli LRI) di risoluzione.Con “verifica” si intende un procedimento algoritmico che, date tutte levariabili di interesse, fornisce un risultato che può essere:• accesso consentito: in questo caso il sistema è autorizzato ad espletarel’o<strong>per</strong>azione richiesta <strong>per</strong> conto dell’utente;• accesso negato: in questo caso il sistema non è autorizzato ad espletare (equindi non effettuerà) l’o<strong>per</strong>azione richiesta.Ad esempio <strong>per</strong> l’accesso in lettura ad una informazione primitiva, i dati ele 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 ditipo temporale <strong>per</strong> <strong>per</strong>mettere l’accesso (o meno) sulla base dell’istante in cuil’utente effettua le richiesta.Con “approccio white-list” si intende che l’algoritmo di verifica o<strong>per</strong>a seguendola direttiva che tutto è negato, salvo ciò che è stato esplicitamente dichiaratocome <strong>per</strong>messo.250


Virtual Repository ServiceIdentity ServicePermessi sui nomiLe informazioni primitive sono dotate di LRI che possono essere “canonicalname” (assimilabili al record A nel DNS) oppure “alias” (assimilabili al recordCNAME 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 creatiin tempi successivi.Ai singoli LRI sono associati i metadati <strong>per</strong> la gestione delle ACL che, nelcaso specifico, <strong>per</strong>mettono di abilitare le seguenti o<strong>per</strong>azioni (si ricorda che levoci nella ACL servono <strong>per</strong> fornire <strong>dei</strong> diritti, ciò che non è elencato, ovveroautorizzato, non è <strong>per</strong>messo):• risoluzione: è possibile richiedere la risoluzione da LRI in PRI;• accesso al nome: è possibile richiedere l’esistenza del nome. Permetteall’utente di stabilire se il nome esiste o meno. Inoltre entra in gioco nelsupporto alla navigazione (paragrafo 9.5.4): le liste fornite a seguito dellerichieste di “appartenenza a” contengono solo gli elementi <strong>per</strong> i quali ilrichiedente ha diritto di accesso;• eliminazione del nome. È possibile eliminare il nome (si noti che gli utentidel sistema non potranno avere il diritto di cancellare <strong>dei</strong> nomi canoniciche, <strong>per</strong> definizione, restano immutati <strong>per</strong> tutto il ciclo di vita dell’informazionia cui fanno riferimento; viceversa possono essere autorizzati adeliminare alias);• aggiunta di alias. È possibile creare un nuovo alias del nome <strong>per</strong> il qualeè stato autorizzato questo tipo di o<strong>per</strong>azione.Permessi sulle informazioniPer quanto riguarda le informazioni primitive la gestione <strong>dei</strong> diritti di accessoè più articolata. Fermo restando l’approccio a white-list, è infatti necessariodiscriminare fra o<strong>per</strong>azioni che possono essere svolte sull’informazione nel suocomplesso e quelle sulle singole entità (dati e metadati) in essa contenuti.Le o<strong>per</strong>azioni 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 <strong>dei</strong> dati e <strong>dei</strong> 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 <strong>per</strong>manentemente dal sistema(si noti che ciò non significa che sia necessariamente assegnato questodiritto agli utenti del sistema).251


Virtual Repository ServiceIdentity ServiceDi seguito invece vengono elencate le o<strong>per</strong>azioni che possono essere svoltesui singoli elementi (dati e metadati) contenuti all’interno delle PIU:• accedere: è possibile stabilire se l’elemento esiste o meno;• leggere: è possibile accedere <strong>per</strong> la lettura all’elemento in questione;• modificare: è possibile accedere <strong>per</strong> la modifica all’elemento in questione.Se un utente non dispone del diritto di accesso, la risposta sarà come sel’informazione non esistesse.Il diritto di elencare i contenuti di una informazione primitiva (accedere allalista <strong>dei</strong> dati e <strong>dei</strong> metadati in essa contentuti) discende dal fatto che sia possibileaccedere a ciò che contiene.Ovviamente tale lista sarà costituita esclusivamente dai dati e dai metadati<strong>per</strong> i quali l’utente ha i diritti di accesso. Se un utente non dispone del dirittodi elencare viene negata la possibilità di navigare nello spazio dell’informazione.Il diritto di aggiungere o rimuovere elementi significa disporre della facoltà diinserire nuovi dati o metadati all’interno della PIU oppure di rimuoverne alcunicoerentemente con i vincoli imposti dalla ACL.252


Capitolo11Information History ServiceIDN Information History Service (IH) implementa l’insieme <strong>dei</strong> servizi necessari<strong>per</strong> il versionamento delle informazioni, agendo come se fossero strutturate.Tale insieme è rappresentato come un livello che si colloca tra il VirtualRepository 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 sullaindicazione del parametro di versione che gli viene fornito.Nel presente capitolo saranno definiti il data model <strong>per</strong> la rappresentazionedelle informazioni, i servizi offerti e l’interfaccia.11.1 La navigazione nello storicoIl layer IH gestisce l’evoluzione temporale <strong>dei</strong> documenti e si attiva a seguitodi richieste che nascono ai livelli su<strong>per</strong>iori. La gestione interna dello storicoè necessaria, ma affinché sia efficace, occorre che questo livello forniscaanche <strong>dei</strong> metodi <strong>per</strong> la navigazione all’interno dell’insieme storico di dati (larappresentazione delle versioni <strong>per</strong> la medesima informazione).Si ricorda che due versioni diverse della stessa informazione sono codificateall’interno di due nodi distinti di livello IH i quali hanno un proprio indirizzounivoco (PRI) che li identifica. Tali elementi possono essere messi in relazionetramite link di versione, ma focalizzando l’attenzione sull’entità nodo, senzaanalizzare il suo contenuto, non è possibile distinguere se questo contiene unadeterminata versione di una certa informazione oppure un’altra informazione.In questi termini quindi due versioni differenti sono considerate due informazionidistinte come nel caso di un’informazione primitiva che aggrega, <strong>per</strong> composizio-


Information History ServiceLa navigazione nello storicone, un’altra informazione primitiva oppure di due informazioni che non hannonessun legame fra loro.Alla luce di questa considerazione è possibile evidenziare come, senza aggiungereulteriori condizioni, il livello Virtual Repository possa accedere ad ognielemento dello storico di una data informazione semplicemente conoscendonel’indirizzo univoco PRI.Ovviamente un meccanismo di indirizzamento di questo genere, che si basa suindirizzamento assoluto, non è sufficiente ad una gestione flessibile dello storico.La scelta effettuata consiste nell’introdurre un meccanismo di navigazionerelativo all’interno dello spazio delle versioni.L’accesso ai nodi informativi avviene tramite l’indirizzo <strong>per</strong>sistente del nodoal quale può essere aggiunto un parametro di versione. Il parametro di versioneè opzionale <strong>per</strong> <strong>per</strong>mettere la navigazione anche in termini assoluti.L’uso del parametro di versione in abbinamento ai PRI <strong>per</strong>mette di introdurreuna definizione formale degli indirizzi relativi al livello IH. Tali indirizzisono definiti con la sintassi esposta in in figura 11.1 con notazione BNF.::= "#" ::= "R_NEXT" | "R_PREV" | "H_ROOT" |"B_ROOT" | "T_ABSLAST" | "T_RELATLAST"|"B_LAST" | "H_GRAPH" ::= definizione nel capitolo 9Figura 11.1: Sintassi degli indirizzi di livello IH11.1.1 Version Traversing AlgorithmIl raggiungimento di una versione avviene attraversando lo storico (navigazione)<strong>per</strong> passi iterativi iniziando da uno degli elementi il cui indirizzo <strong>per</strong>sistenteè noto ai livelli su<strong>per</strong>iori. Prendendo come riferimento il nodo in questioneviene richiesto, secondo un indirizzo relativo, un altro nodo presente nello storicodella stessa informazione. L’esempio più semplice che può essere menzionatoriguarda la navigazione fra una revisione e la successiva o la precedente.Partendo, ad esempio, dall’elemento N 0 è possibile procedere in avanti nellerevisioni o<strong>per</strong>ando 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 <strong>per</strong>mette a Virtual Repository di richiede-1 È un GET in cui i parametri sono codificati nell’indirizzo della risorsa254


Information History ServiceLa navigazione nello storicore il nodo che partendo da A è raggiungibile tramite il parametro di versioneB.11.1.2 I parametri di versioneIn questo sotto paragrafo vengono descritti i parametri di versione che sonostati 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 eserve <strong>per</strong> identificare l’ambito in cui o<strong>per</strong>a (i valori ammessi sono: R <strong>per</strong> revision,H <strong>per</strong> history, B <strong>per</strong> branch ed infine T <strong>per</strong> time), la seconda è una stringa chedefinisce 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 diversione, 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 casola risposta contiene, se esiste, il nodo relativo alla revisione successivae l’indirizzo univoco (PRI) del primo elemento del branch. In questomodo viene soddisfatta la richiesta relativa alla revisione successiva ei livelli su<strong>per</strong>iori vengono messi a conoscenza dell’esistenza del branchcon la possibilità di indirizzarli.• R_PREV: Revision, Previous. Si riferisce alla revisione precedente del nodocorrente. In modo duale a R_NEXT possono presentarsi i seguenti casi:– non esiste la revisione precedente: la risposta è quindi negativa. Ciòsi verifica solo <strong>per</strong> la radice dello storico;– esiste la revisione precedente: la risposta fornisce il nodo che lacontiene.– il nodo può essere stato creato come nuova revisione o in seguito adun’o<strong>per</strong>azione di merge. In quest’ultimo caso, similmente a quantoè stato definito <strong>per</strong> le diramazioni, nella risposta sono presenti ilnodo che contiene la revisione precedente (che si trova sullo stessoramo del nodo di partenza) e l’indirizzo univoco (PRI) dell’elementoprecedente presente nell’altro branch.• H_ROOT: History, Root. Questo parametro di versione si riferisce alla radicedello storico ovvero al primo elemento che è stato creato.• B_ROOT: Branch, Root. Si riferisce alla radice del branch ovvero all’elementoche è stato preso come riferimento <strong>per</strong> creare il branch. Si osservi255


Information History ServiceLa navigazione nello storicoche <strong>per</strong> quanto riguarda i nodi appartenenti al ramo principale B_ROOTcoincide con H_ROOT.• T_ABSLAST: Time, Absolute Last. Elemento dello storico più recente (daun punto di vista temporale).• T_RELATLAST: Time, Relative Last. Elemento più recente presente nellostorico, relativamente al nodo di partenza ovvero <strong>per</strong> il quale tale nodofigura fra gli antenati. Equivale al T_ABSLAST dello storico ipotetico ottenutoconsiderando tutti i nodi dello storico iniziale a partire dal nodo inesame (tale nodo rappresenta quindi la radice dello storico ipotetico).Storico completo dell'elemento1 2 3 1314 15 16T_ABSLASTH_ROOTB_ROOT4 6R_NEXTB_LASTIl numerorappresental'istante t dicreazionedella versione.R_PREVElemento diriferimento5 7 8 10T_RELATLASTStorico9 11 12ipotetico relativoall'elemento creato al tempo t=7Figura 11.2: Esempio di elemento recente rispetto al nodo di partenzaIn figura 11.2 è riportato un esempio: il nodo preso come riferimento èquello creato al tempo t=7. L’elemento T_ABSLAST relativo ad un qualunqueelemento dello storico, e quindi anche al nodo creato al tempo t=7, è ilnodo creato al tempo t=16. La risoluzione dell’elemento T_RELATLAST, ovveroquello più recente relativamente al nodo creato a t=7, è il T_ABSLASTdello storico ipotetico di cui il nodo creato a t=7 è la radice e, nel casospecifico, è rappresentato dall’elemento creato al tempo t=12.• B_LAST: Branch, Last. Ultima revisione del branch. In riferimento al casoriportato in figura 11.3 il B_LAST relativo ai nodi A, C, E ed F è F, mentrequello relativo ai nodi B e D è D.• H_GRAPH: La struttura dello storico. Quest’ultimo parametro di versionesi differenzia dagli altri in quanto non è utilizzato <strong>per</strong> ottenere una particolareversione di N all’interno dello storico, ma <strong>per</strong> <strong>per</strong>mettere a VirtualRepository e/o Application di avere una visione globale dello storico stesso.La struttura viene fornita, opportunamente codificata all’interno di undocumento IDN-IM, sotto forma di DAG nel quale ogni elemento contienel’indirizzo univoco (PRI) del corrispondente nodo nello storico ed eventualmentealtri metadati di interesse. La struttura può essere completa o256


Information History ServiceInterfacciaRamo PrincipaleACEFBBranchDB_LAST sulramo principaleB_LAST sul branchFigura 11.3: Esempi di “last” relativi al branchparziale (ad esempio localizzata nell’intorno del nodo di riferimento) e questoaspetto viene gestito tramite un opportuno attributo specificato nellarichiesta. Si osservi che lo stesso risultato che si ottiene tramite questoparametro di versione può essere raggiunto, a livello Virtual Repository,visitando tutto il grafo relativo allo storico dell’informazione di interessetramite l’uso degli altri parametri di versione che IH mette a disposizione.H_GRAPH non è da considerarsi quindi utile nell’ottica dell’efficaciadel sistema, ma in quella dell’efficienza. I benefici di questa soluzione sonoevidenti facendo in modo che IH codifichi (e mantenga aggiornato) ilgrafo associato allo storico su un’opportuna struttura dati e che quindiriesca a soddisfare la richiesta senza effettuare la visita (al posto di VirtualRepository) di tutto lo storico. Considerando che i nodi dello storicosono, <strong>per</strong> definizione, non eliminabili, la struttura può solo crescere neltempo. Questo vincolo <strong>per</strong>mette tuttavia di ideare soluzioni <strong>per</strong> la suamemorizzazione e gestione che scalino, senza difficoltà, all’aumentare delladimensione ricorrendo ad opportune tecniche di partizionamento. Ladefinizione e l’introduzione effettiva di questa primitiva vengono lasciatea sviluppi futuri.11.2 InterfacciaLa finalità del layer IH è quella di fornire al layer Virtual Repository il serviziodi mantenimento e memorizzazione dell’evoluzione temporale dell’informazioneattraverso la definizione e gestione del relativo storico e della navigazioneall’interno di esso.Per Virtual Repository il layer IH è quindi un’entità remota alla quale effettuarerichieste di servizio. Per raggiungere questo risultato occorre definire unprotocollo di comunicazione che <strong>per</strong>metta alle due entità di interagire.Nel paragrafo verrà definita l’interfaccia secondo il formalismo <strong>dei</strong> diagrammi<strong>dei</strong> casi d’uso di UML. La finalità è quella di presentare i vari tipi di richiesteche possono essere effettuate ad alto livello a IH dando, allo stesso tempo, unabreve descrizione delle azioni che vengono svolte dal layer.257


Information History ServiceInterfacciaSuccessivamente viene introdotta, con la stessa modalità, l’interfaccia vistada IH messa a disposizione da Replica Management. Questo è utile <strong>per</strong> evidenziarecome IH si avvalga del livello Replica Management <strong>per</strong> soddisfare lerichieste effettuate da Virtual Repository.Per convenzione è stato scelto di assegnare i nomi ai casi d’uso nel modoseguente: identificativo sistema.identificativo contesto.numero. L’identificativodel sistema <strong>per</strong>mette di associare il caso d’uso ad un sistema specifico, in questocaso “IH” corrisponde a Information History e “Rep” a Replica Management.L’identificativo del contesto specifica a quale entità del sistema il caso d’uso siriferisce, ad esempio “Int” è l’interfaccia. Infine il numero sequenziale <strong>per</strong>mettedi creare un nome univoco <strong>per</strong> ogni caso d’uso come richiesto <strong>per</strong> rispettare lespecifiche dettate da UML.Nella descrizione che segue con sistema si intende il layer IH, principalesoggetto dell’interazione.In figura 11.4 è riportato il diagramma <strong>dei</strong> casi d’uso che <strong>per</strong>mette di riassumeregraficamente le primitive che IH espone a Virtual Repository.Information HistoryIH.int.GETIH.int.CREATEIH.int.MARKVirtualRepositoryIH.int.COMMITIH.int.BRANCHIH.int.MERGEFigura 11.4:RepositoryCasi d’uso relativi all’interfaccia mostrata da IH a VirtualCaso d’uso: IH.Int.GETID: UC.IH.Int.1Attori: Virtual Repository.258


Information History ServiceInterfacciaPrecondizioni: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 accederead un elemento presente nello storico di N ed effettua la richiesta di accessospecificando il PRI di N e il parametro di versione.Il parametro di versione può essere (si ricorda che la definizione <strong>dei</strong> parametridi versione è presente nel sotto paragrafo 11.1.2 a pagina 255):• nessuno: <strong>per</strong> richiedere la versione corrente (esattamente il nodo N);• R_NEXT: <strong>per</strong> richiedere la versione successiva;• R_PREV: <strong>per</strong> richiedere la versione precedente;• H_ROOT: <strong>per</strong> richiedere la prima versione del nodo;• B_ROOT: <strong>per</strong> richiedere la radice del branch (nel caso in cui il nodoappartenga al ramo principale B_ROOT coincide con H_ROOT);• T_ABSLAST: <strong>per</strong> richiedere l’ultima versione creata (più recente da unpunto di vista temporale) presente all’interno dello storico completo;• T_RELATLAST: <strong>per</strong> richiedere l’ultima versione creata (più recente da unpunto di vista temporale) che ha il nodo di partenza fra gli antenatinello storico;• B_LAST: <strong>per</strong> richiedere l’ultima versione presente nel branch corrente;• H_GRAPH: <strong>per</strong> richiedere il DAG che rappresenta lo storico del nodo N.2. Il sistema, partendo da N, richiede a Replica Management tutti i nodinecessari al raggiungimento di N x (nodo richiesto tramite il parametro diversione).3. Il sistema restituisce il nodo N x a Virtual Repository oppure un messaggiodi errore.Scenari secondari:1. Se viene richiesta la versione R_NEXT di un nodo nel quale hanno origine unoo più branch, il sistema risponde fornendo la nuova revisione (se esiste) ela lista di indirizzi del primo elemento di ogni branch. Questo <strong>per</strong>mette alVirtual Repository di creare una nuova richiesta sul branch di interesse.2. Se viene richiesta la versione R_PREV di un nodo ottenuto tramite un’o<strong>per</strong>azionedi merge il sistema risponde fornendo la revisione precedente el’indirizzo del genitore presente nell’altro branch.Caso d’uso: IH.Int.COMMIT259


Information History ServiceInterfacciaID: UC.IH.Int.2Attori: Virtual Repository.Precondizioni:1. I nodi interessati devono esistere 2 ed essere stati precedentemente marcaticome RELAXED, LOCKED STRONG o LOCKED SOFT dal richiedentedel 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 salvareun documento o parte di esso ed effettua la richiesta di commit specificandoquali nodi sono stati modificati.2. Il sistema sovrascrive o crea <strong>nuove</strong> versioni di tali nodi in base alla politicadi 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ò esserepositivo o di errore.Caso d’uso: IH.Int.CREATEID: UC.IH.Int.3Attori: Virtual Repository.Sequenza degli eventi:1. Il caso d’uso inizia quando Virtual Repository ha la necessità di creare unnuovo 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 <strong>per</strong> ogninodo da creare.3. Il sistema restituisce un messaggio al Virtual Repository che può esserepositivo (in tal caso contiene il PRI del nuovo nodo) o di errore.Caso d’uso: IH.Int.BRANCH2 Per inserire nuovi elementi occorre fare riferimento al caso d’uso UC.IH.Int.3260


Information History ServiceInterfacciaID: UC.IH.Int.4Attori: 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 unbranch nello storico di uno o più nodi.2. Il sistema crea un nuovo nodo (riferimento ad UC.IH.Int.3) e copia in essoil contenuto della versione indicata del nodo di partenza oppure, se specificatoda Virtual Repository, direttamente il nuovo valore che il nodo deveassumere.3. Il sistema inserisce nell’elemento di partenza le informazioni necessarie <strong>per</strong>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 dierrore.Caso d’uso: IH.Int.MARKID: UC.IH.Int.5Attori: Virtual Repository.Precondizioni:1. I nodi di interesse devono esistere.2. Il nodo non deve avere <strong>nuove</strong> versioni ovvero deve essere l’elemento piùrecente del branch affinché le etichette RELAXED, LOCKED STRONG oLOCKED SOFT possano essere applicate.Sequenza degli eventi:1. Il caso d’uso inizia quando Virtual Repository ha la necessità di marcareuna lista di nodi e <strong>per</strong> farlo utilizza i seguenti parametri (i primi due possonoessere applicati contemporaneamente):• OBSERVED, <strong>per</strong> mettere i nodi sotto osservazione;• RELAXED, <strong>per</strong> indicare che l’utente è interessato alla modifica <strong>dei</strong> nodi(con il fine di applicare una strategia di aggiornamento ottimisticamassimizzando l’awareness di alto livello);261


Information History ServiceInformation History Data Model• LOCKED_STRONG, <strong>per</strong> acquisire il lock Strong (sia in lettura che in scrittura,vedi il sotto paragrafo 7.8.1) sui nodi;• LOCKED_SOFT, <strong>per</strong> acquisire il lock Soft (solo in scrittura, vedi il sottoparagrafo 7.8.1) sui nodi;• NULL, <strong>per</strong> 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 o<strong>per</strong>azione risulti possibile restituisce un messaggiopositivo, altrimenti di errore.Caso d’uso: IH.Int.MERGEID: UC.IH.Int.6Attori: Virtual Repository.Precondizioni:1. Devono esistere due nodi N b1 e N b2 che rappresentato l’ultima revisionepresente 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 idue 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 successoredi N b1 ed N b2 ed appartenente al ramo di N b1 .3. Il sistema restituisce un messaggio a Virtual Repository che può esserepositivo o di errore.11.3 Information History Data ModelIn questo paragrafo viene introdotta la struttura dati necessaria <strong>per</strong> definire,gestire e mantenere lo storico di un’informazione che, in questo caso, è daconsiderarsi come nodo del layer IH.La struttura viene definita tramite un XML Schema, standard preso comeriferimento in IDN <strong>per</strong> la modellazione <strong>dei</strong> dati, del formato <strong>dei</strong> messaggi <strong>dei</strong>protocolli, eccetera 3 .Viene riportato lo XML Schema che <strong>per</strong>mette di descrivere i nodi del modelloIDN-IM a livello IH sia in formato testuale che in formato grafico nelle3 La scelta di XML <strong>per</strong> la modellazione <strong>dei</strong> dati è stata dettata dalla flessibilità,compatibilità e portabilità che questo standard offre.262


Information History ServiceInformation History Data Modelfigure 11.5 e 11.6. Tali figure evidenziano la struttura, i dati e i metadati presentiin un nodo senza entrare nel dettaglio della sintassi degli XML Schema.In particolare la prima rappresenta una visione generale della struttura tralasciandoi link di versione (ovvero i link che <strong>per</strong>mettono di generare le relazionifra nodi all’interno dello storico), la seconda rappresenta proprio tali link.Lo Schema non è stato commentato in quanto, in caso contrario, sarebberisultato eccessivamente dis<strong>per</strong>sivo. Un’accurata descrizione di esso è comunquepresente nel sotto paragrafo successivo; gli elementi vengono descritti nello stessoordine con il quale compaiono nello Schema.Lo Schema è il seguente:XML Schema - Definizione nodi IDN-IM a livello IHAuthor: Davide Chini & Samuele InnocentiDate: 07/12/2008Revision: 0.2263


Information History ServiceInformation History Data Model


Information History ServiceInformation History Data Modeltype="updateStateEnum" />11.3.1 Descrizione dello Schema XMLLa prima entità () serve <strong>per</strong> includereun altro Schema, <strong>per</strong> la precisione pri.xsd, che contiene la definizione265


Information History ServiceInformation History Data ModelnodeId0..*observedconcurrency0..*relaxedlockStronglockSoftheaderstructure0..*childnode0..*parenthistoryIdhistoryversionIdcreated+modified+updateversionLinks+anyTypebody0..*anyElementFigura 11.5: Albero di XML Schema: visione globaledegli indirizzi univoci e <strong>per</strong>sistenti (PRI) definiti in IDN-IM (evidenziata infigura 11.7).Si ricorda che che nel paragrafo 9.3 è riportata un descrizione dettagliatadegli 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 creazionee/o di modifica e contiene tutti i parametri ritenuti utili <strong>per</strong> l’identificazionedell’o<strong>per</strong>azione. Si osservi che la definizione di tale elemento può essere estesae/o modificata. L’elemento ihProcessId rappresenta l’identificativo univoco266


Information History ServiceInformation History Data ModelhistotyIdhistoryversionIdcreated+modified+0..1revisionNextupdate0..*branchfirstRevisionversionLinks0..2revisionPreviousbranchLast0..1branchRoothistoryRoot0..1timeLastFigura 11.6: Albero di XML Schema: particolare <strong>dei</strong> link di versione value="urn:pri:(0\.|([1-9][0-9]*)\.)*(0|([1-9][0-9]*))/[0-9a-zA-Z\-_.,();:=+$!~*’]+"Figura 11.7: XML Schema <strong>per</strong> la definizione di indirizzi PRIdel processo di livello IH che ha effettuato l’o<strong>per</strong>azione (di creazione e/o modifica);occorre definire un meccanismo che <strong>per</strong>metta di assegnare <strong>dei</strong> nomi univociai processi che implementano i servizi di IDN (è opportuno che tale meccanismosia unificato all’interno di tutta l’architettura). Una possibile soluzione è quelladi proiettare i singoli processi all’interno dello <strong>dei</strong> spazio <strong>dei</strong> nomi di IDN; èpossibile ottenere questo risultato assegnando ad essi alcuni nomi logici, un nomeunivoco (il cui valore sarebbe quello da inserire nell’elemento ihProcessIdin esame) e un URL (che <strong>per</strong>mette l’individuazione e quindi l’accesso del processoin rete) esattamente come avviene <strong>per</strong> le informazioni primitive. Un’altrasoluzione potrebbe prevedere l’uso di nomi di dominio gestiti dal convenzionaleDNS.267


Information History ServiceInformation History Data ModelIl secondo, updateStateEnum, rappresenta l’enumerazione <strong>dei</strong> possibili statiassunti da UPDATE: FROZEN e CHANGING.L’elemento successivo, node, definisce formalmente il nodo nel contesto dellayer IH. Tale elemento, come evidenziato in figura 11.5, è suddiviso in duesezioni: header e body.All’interno dell’elemento body viene infatti inserita la codifica del nodo definitaa livello Virtual Repository senza che IH (information hiding) sia interessatoad interpretarne il contenuto.L’elemento header contiene invece tutti i dati e metadati di competenza dellayer IH e quindi definiti in questo contesto. Sono presenti quattro gruppi dielementi:• nodeId: non è un vero e proprio gruppo, in quanto è un unico elemento erappresenta l’indirizzo univoco del nodo (PRI);• concurrency: gruppo che contiene le informazioni necessarie <strong>per</strong> la gestionedella concorrenza negli accessi;• history: gruppo che contiene tutti gli elementi necessari alla gestione eal mantenimento dello storico.Per quanto riguarda nodeId non occorre specificare altro.Il gruppo concurrency contiene le etichette, introdotte con il caso d’usoUC.IH.Int.5, <strong>per</strong> la gestione della concorrenza. In particolare ad ogni nodo puòessere applicato un numero arbitrario di etichette observed e relaxed ed unaetichetta a scelta tra lockStrong e lockSoft. Ogni etichetta è un elemento ditipo pri e tale indirizzo serve ad identificare l’entità (Persona dell’utente) chel’ha creata.Il gruppo history contiene vari elementi, descritti di seguito:• historyId: identificativo dello storico. Per convenzione è stato sceltodi utilizzare il PRI del nodo radice dello storico, indirizzo univoco <strong>per</strong>definizione;• versionId: identificativo della versione all’interno dello storico. La sintassiè definita tramite l’espressione regolare [Goy06] riportata in figura 11.8.([1-9][0-9]+\.[1-9][0-9]*\.)*[1-9][0-9]*Figura 11.8: Espressione regolare <strong>per</strong> definire gli identificativi di versioneTale espressione regolare <strong>per</strong>mette di rappresentare la categoria delle stringhecontenenti un numero arbitrario positivo di elementi costituiti da cifreterminanti con un punto e una sequenza terminale di cifre. Le sequenze dicifre rappresentano numeri interi e non possono iniziare con “0”. Il numerodi caratteri “.” deve essere pari, vale a dire che la quantità di sequenze di268


Information History ServiceInformation History Data Modelcifre presenti è sempre dispari. Il motivo di questo vincolo sarà chiaritopiù avanti.Ad esempio, appartengono a questa classe le seguenti stringhe: “21”,“8.9.12”, eccetera. Non appartengono a questa classe le seguenti stringhe:“7.”, “.12”, “01.3”, “Ver=1.4”, “8.9.12.4”, eccetera. In particolarel’ultima mostrata non è valida in quanto è presente una quantità pari (nondispari) di sequenze di cifre.Identificatoreassoluto del branchIdentificatoredella revisioneN 1 .N 2 . ... .N n .B id .R idIdentificatoredella radicedel branchIdentificatorerelativo delbranchFigura 11.9: Convenzione sui nomi <strong>dei</strong> nodi nello storicoLa struttura dell’identificativo è riportata in figura 11.9.Tale rappresentazione <strong>per</strong>mette di individuare univocamente le versioniall’interno dello storico e il branch di appartenenza.Per convenzione le prime N − 1 cifre rappresentano l’identificatore assolutodel branch all’interno dello storico. Questo identificatore si ottieneaggiungendo al nome del nodo dal quale il branch è stato creato una cifrasequenziale, l’identificatore relativo del branch. In questo modo il primobranch 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 identificala revisione relativamente al branch. In riferimento all’esempio precedentela prima revisione nel primo branch è “X.Y.Z.1.1”, la seconda revisionenel primo branch è “X.Y.Z.1.2”, la n-esima revisione nel m-esimobranch è “X.Y.Z.m.n”;• created: rappresenta la data e l’ora di creazione dell’elemento e contienel’identificativo del processo di livello IH che lo ha creato. Inoltre, nell’ipotesiin cui ogni azione che si sviluppa nel sistema sia riconducibile ad unPersona, contiene anche l’identificativo (PRI) di tale Persona;• modified: contiene le medesime informazioni del parametro created conla differenza che viene aggiornato ad ogni modifica di un qualunque elementopresente nel nodo (sia nel caso di sovrascritture <strong>dei</strong> contenuti chedi aggiornamento <strong>dei</strong> metadati, ad esempio a seguito dell’aggiunta del linkdi 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 di269


Information History ServiceInformation History Data Modelaggiornamento vengono gestite con sovrascrittura, nel secondo tramite lanascita di <strong>nuove</strong> revisioni (e la relativa propagazione);• versionLinks: gruppo di elementi che serve <strong>per</strong> codificare i link di versioneverso gli altri nodi. Tali elementi sono:– revisionNext: indirizzo del nodo che rappresenta la nuova revisione;– branch: elemento complesso che contiene i dati relativi al branchradicato nel nodo. Tali dati sono:∗ firstRevision: indirizzo del nodo che rappresenta la primarevisione del branch;∗ branchLast: indirizzo dell’ultimo nodo presente nel branch. Permotivi di efficienza questo campo è presente solo nella radicedel branch. A seguito di una richiesta di accesso al branchLastl’algoritmo viene eseguito in due passi: nel primo si accede allaradice del branch e nel secondo all’elemento richiesto. I vantaggidi questa soluzione sono evidenti nel caso di nascita di unanuova revisione. Se ogni nodo del ramo possedesse l’indirizzodel branchLast, il tempo necessario <strong>per</strong> la nascita di una nuovarevisione scalerebbe linearmente con il numero di revisioni delbranch (tutti i riferimenti andrebbero aggiornati). Al contrario,la modalità attuata, <strong>per</strong>mette di aggiornare soltanto l’elementoradice (o<strong>per</strong>azione che avviene in tempo costante rispetto aglielementi nello storico) senza penalizzare eccessivamente la faseaccesso;– revisionPrevious: indirizzo del nodo che rappresenta la revisioneprecedente rispetto alla corrente;– branchRoot: indirizzo del nodo che rappresenta la radice del branch;– historyRoot: indirizzo del nodo radice dello storico, secondo leconvenzioni utilizzate è il nodo con identificativo “1”;– timeLast: indirizzo del nodo che, considerando l’intero storico, èstato introdotto più recentemente. Questo campo, <strong>per</strong> motivi di efficienza,è presente solo nella radice di ogni branch e valgono tuttele considerazioni riportate <strong>per</strong> il caso del branchLast. In particolaredeve memorizzare l’indirizzo dell’ultimo elemento inserito nel ramoprincipale oppure in uno <strong>dei</strong> branch di cui il nodo è radice. Si osserviche nella radice dello storico il campo timeLast assume il significatodell’elemento inserito più recentemente in assoluto ed è il valore a cuioccorre fare riferimento <strong>per</strong> la risoluzione del parametro di versioneT_ABSLAST. I valori timeLast presenti nelle radici <strong>dei</strong> vari branchservono <strong>per</strong> risolvere le richieste relative al parametro T_RELATLASTcome sarà più chiaro in seguito.270


Capitolo12Replica Management ServiceSecondo l’approccio stratificato di IDN il livello Replica Management si collocain una posizione appena su<strong>per</strong>iore a Storage Interface ed inferiore a InformationHistory. L’interazione in questo caso consiste nell’invio di richieste versoRM da parte di IH, che rappresenta l’utente del sistema 1 .Innanzi tutto, RM dovrà essere in grado di memorizzare dati e metadatiricevuti dal livello su<strong>per</strong>iore e, su richiesta, restituirli ad esso. La memorizzazioneavviene attuando una replicazione (ridondanza) su più locazioni (siti) fisicheindipendenti avvalendosi <strong>dei</strong> servizi sottostanti.Poiché il livello IH si occupa dello storico dell’informazione, tutte le richiesteche arrivano ad RM si riferiscono sempre ad una data versione di una datainformazione primitiva: tale versione rappresenta l’oggetto logico gestito dalsistema di Replica Management.Quando l’utente di RM, ossia il livello IH, interagisce con il sistema richiedendouna qualche o<strong>per</strong>azione, deve essere in grado di identificare la risorsa diinteresse a prescindere dalla sua locazione fisica. Tra le caratteristiche principalidi RM si evidenzia dunque l’indipendenza dalla locazione dello spazio <strong>dei</strong> nomidelle risorse, la quale è attuata mediante l’utilizzo <strong>dei</strong> nomi di tipo URN.12.0.2 Estensioni dell’applicabilitàPer diversi motivi, l’utente può avere necessità di ottenere risposta più omeno velocemente dal sistema, a prescindere dalle condizioni della rete e relativamenteall’importanza della risorsa in questione o dell’azione da effettuare sudi essa.1 Nel seguito, si farà riferimento all’utente del sistema come all’entità che può inviare richiesteal Replica Management, che è da non confondersi con l’utente del livello applicativoIDN.


Replica Management ServiceSi identificano così quelle esigenze di disponibilità, affidabilità e prestazioniche inducono alla replicazione delle risorse, la quale rappresenta l’altrafunzionalità 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 lecaratteristiche appena descritte, pur sempre affiancato da un servizio di storageanalogo a quello fornito in IDN da SI.Si consideri ad esempio uno scenario in cui un generico utente, utilizzandodispositivi e postazioni diverse, ha la necessità di lavorare nel sistema o<strong>per</strong>ativoa lui più familiare, interagendo con svariate applicazioni che o<strong>per</strong>ano su datimemorizzati in file e organizzati mediante directory. L’utente avrà bisogno divedere la directory nella quale salva i dati sempre aggiornata e come se fosselocale al dispositivo che sta usando.Il sistema di Replica Management può concorrere alla realizzazione di soluzioni<strong>per</strong> questo scenario, quali ad esempio un file system distribuito o unaFAN [Wad07] che possono sfruttare a proprio vantaggio le funzionalità di replicazionee di indipendenza dalla locazione.Altre applicazioni del sistema di Replica Management possono essere a supportodella condivisione di risorse mediante reti peer-to-peer [ATS04] o dellereti <strong>per</strong> la consegna <strong>dei</strong> contenuti (Content Delivery Network, in breve CDN)[PB07].Questo tipo di infrastrutture, evolutesi negli ultimi anni, può beneficiare<strong>dei</strong> meccanismi di posizionamento <strong>dei</strong> dati e di instradamento delle richiesterealizzati dal sistema, oltre che dell’aumento in disponibilità e prestazioni offertodalla replicazione.Visto come middleware <strong>per</strong> la replicazione <strong>dei</strong> dati, infine, il Replica Managementpuò essere utilizzato anche come componente di applicazioni qualidatabase distribuiti o sistemi publish-subscribe.12.0.3 Condivisione di risorseIl principale scenario applicativo di IDN riguarda la condivisione di risorsetra più organizzazioni.Si consideri una generica situazione in cui sono presenti tre organizzazionichiamate A, B e C. Quando l’organizzazione A vuole condividere parte delleinformazioni di sua competenza con le organizzazioni B e C, dovrà <strong>per</strong>mettereche esse accedano ai dati relativi a tali informazioni.A può decidere di condividere alcune delle sue informazioni con B, e altrecon C. Per alleggerire il carico sui server di A, e <strong>per</strong> aumentare le prestazioni inlettura viste dai client di B e C, A può <strong>per</strong>mettere che B e C mantengano suipropri server una replica <strong>dei</strong> dati a cui accedono più spesso.In generale, quando B o C richiedono un dato ad A, non è sempre detto cheA <strong>per</strong>metta che essi creino una replica di quel dato sui loro server, ad esempio<strong>per</strong> problemi legati alla competenza. Inoltre, ogni volta che un server creauna replica di un dato, si impegna a tenerla aggiornata, e ciò richiede caricocomputazionale, <strong>per</strong> cui se tutte le organizzazioni tenessero una replica di tuttele risorse a cui accedono, il traffico generato nel propagare gli aggiornamenti272


Replica Management Servicepotrebbe portare al congestionamento della rete. Comunque, può risultare utileavere a portata di mano un dato a cui si ha bisogno di accedere spesso, <strong>per</strong>ciòin alcuni casi è opportuno creare una replica di un certo dato.In seguito all’aggiornamento di una risorsa su un server, le modifiche applicatead essa dovranno essere inoltrate agli altri server che ne mantengono unareplica, 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 laresidenza <strong>dei</strong> cittadini del Comune. Altre organizzazioni possono avere necessitàdi accedere a queste informazioni: ad esempio, la Motorizzazione ha bisogno<strong>dei</strong> dati anagrafici <strong>per</strong> il rilascio della patente, e così anche la questura <strong>per</strong> ilrilascio del passaporto. Nel caso in cui il passaporto del genitore abbia funzionedi documento <strong>per</strong> l’espatrio anche <strong>per</strong> i figli, la questura avrà quindi bisognodi accedere ai dati anagrafici di questi ultimi, mentre alla Motorizzazione noninteressa mai conoscere le relazioni di parentela tra i cittadini.Da questo scenario si possono dedurre i seguenti vincoli di contesto:• controllo di accesso, <strong>per</strong> verificare i <strong>per</strong>messi 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 diiniziare la propagazione degli aggiornamenti verso le altre repliche;• autenticazione <strong>dei</strong> client e trasmissione sicura degli aggiornamenti.12.0.4 Vincoli prestazionaliIn un ambiente distribuito, può capitare che le connessioni tra i server chemantengono una replica della stessa risorsa abbiano caratteristiche e prestazionidiverse.Ad esempio, se la replica sul server di B è gestita attraverso un collegamentotelefonico di tipo dial-up verso il server di A, la connessione tra i due serverpotrebbe non essere sempre disponibile.Oppure, una replica che risiede su un computer portatile potrebbe proseguirel’esecuzione in modalità disconnessa <strong>per</strong> un certo <strong>per</strong>iodo di tempo; allariconnessione, inizierà il processo di sincronizzazione <strong>per</strong> aggiornare i suoi datiall’ultima versione disponibile.Questo scenario <strong>per</strong>mette 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 sincronizzazionecon uno <strong>dei</strong> server che può inviarglieli;• la sincronizzazione deve poter avvenire in qualsiasi momento.Ancora in riferimento all’esempio delle Pubbliche Amministrazioni, né laMotorizzazione né la Questura hanno il diritto di modificare i dati anagrafici,poiché non sono di loro competenza.273


Replica Management ServiceSe A è l’unico responsabile delle informazioni condivise, tutte le richieste dimodifica sui dati dovranno essere inoltrate ai suoi server, i quali possono tenereuna o più repliche delle risorse di competenza di A nel caso in cui A lo <strong>per</strong>metta.Quando A possiede una sola replica della risorsa su cui detiene i diritti diproprietario, essa è l’unica modificabile. Di conseguenza, se il server su cuisi trova tale replica è guasto, le richieste di aggiornamento sono costrette adattendere fino al suo ripristino.In presenza di partizionamenti della rete, può succedere che A, B e C nonriescano a comunicare <strong>per</strong> un certo <strong>per</strong>iodo di tempo. Allora diventa possibileche, durante il <strong>per</strong>iodo di disconnessione, gli aggiornamenti effettuati su unarisorsa in A non riescano ad essere propagati a tutte le sue repliche; ciascunserver deve comunque continuare a rispondere alle richieste <strong>dei</strong> client, fornendola versione più recente del dato a sua disposizione. Le repliche sui server di Be C non possono iniziare ad eseguire modifiche, <strong>per</strong>ché non sono proprietari diquella 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, <strong>per</strong>ché l’esecuzione delle modifiche in A si concludesenza aspettare la propagazione delle stesse a tutte le repliche;• possibilità di ritentare la sincronizzazione, immediatamente oppure in unmomento successivo;• la replica modificabile non può essere sostituita in modo automatico dauna qualsiasi delle altre.Può <strong>per</strong>ò essere utile che una risorsa sia replicata su più server appartenentiad A e dislocati in sedi diverse, <strong>per</strong> evitare la situazione di “single pointof failure”, ovvero <strong>per</strong> motivi di affidabilità e disponibilità oltre che <strong>per</strong> leprestazioni.Ad esempio, l’organizzazione A potrebbe comprendere più sedi in locazionifisicamente distanti l’una dall’altra. Tra gli uffici del comune di una grandecittà possono esserci più sedi dell’anagrafe, di conseguenza i dati anagrafici potrebberoessere distribuiti tra i server delle varie sedi. Allora, poiché tutte lesedi appartengono all’organizzazione A, possiedono tutte i diritti di proprietariosulle informazioni di sua competenza.Si consideri il caso in cui A mantiene più repliche della risorsa su cui detienei diritti di proprietario, ed una sola di esse è aggiornabile.Può accadere che, in seguito ad esempio ad un trasferimento, venga chiusala sede dove si trova l’unica replica modificabile della risorsa. Le informazionicontenute in tale risorsa devono continuare ad essere aggiornabili, <strong>per</strong>ciò diventanecessario scegliere, tra le restanti repliche della risorsa, una che diventimodificabile al posto dell’altra.Da questo scenario si può ricavare un ulteriore requisito:• capacità di sostituire la replica modificabile con una delle repliche appartenentiad A, senza che ciò comporti l’indisponibilità del servizio <strong>per</strong> untempo significativo.274


Replica Management ServiceSi consideri adesso il caso in cui A mantiene più repliche della risorsa sucui detiene i diritti di proprietario, e più di una di esse è aggiornabile. Unasituazione di questo tipo si può presentare anche quando due organizzazioni checollaborano, magari condividendo lo spazio <strong>dei</strong> nomi, hanno bisogno entrambedi possedere diritti amministrativi sui dati messi in comune.Dal punto di vista dell’utente, il comportamento del sistema deve essere ancoraquello descritto negli scenari precedenti. Una risorsa deve continuare adessere disponibile e modificabile anche quando uno <strong>dei</strong> server su cui risiede unasua replica è disconnesso dalla rete; in particolare, non devono presentarsi situazioniin cui una delle repliche modificabili esegue una richiesta di aggiornamentosenza prima aver ricevuto tutte le modifiche eseguite sulle altre repliche dellastessa 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, <strong>per</strong> realizzare lo spazio <strong>dei</strong> nomi a condivisionecompleta.Si consideri infine un’organizzazione che accede frequentemente in lettura aduna risorsa di cui <strong>per</strong>ò non può mantenere una replica. Questo può accaderesia <strong>per</strong>ché il proprietario della risorsa non glielo concede, sia <strong>per</strong>ché ha valutatoche non risulterebbe vantaggioso prendersi l’impegno di effettuare regolarmentela sincronizzazione.L’organizzazione potrebbe allora decidere di effettuare il caching in localedi quella risorsa, in modo da essere in grado di portare a termine le letture sudi essa anziché inviare una richiesta e attendere la risposta ogni volta che habisogno di leggerla.All’interno di un’organizzazione, i dati possono assumere un’importanzadiversa sia in relazione al loro contenuto che col passare del tempo.Ad esempio, i pattern di lettura e scrittura relativi a dati diversi possonoessere diversi. Il grado di replicazione associato ad ogni risorsa deve essereottimizzato in modo da riflettere queste differenze: se un dato è di sola lettura,converrà replicarlo il più possibile, se invece viene scritto spesso, il menopossibile.Inoltre, tali pattern di lettura e scrittura possono cambiare nel tempo. Per uncerto <strong>per</strong>iodo può essere necessario che una risorsa venga replicata il più possibilee 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 replicazionedi ciascuna risorsa, aggiungendo e rimuovendo repliche secondo le esigenze.In generale, deve essere possibile cambiare la configurazione di ciascunarisorsa ai fini della replicazione.Un’organizzazione inizialmente piccola, che comprende un’unica sede e gestiscei suoi dati mantenendo una sola replica modificabile, potrebbe in seguitovenire fusa con un’altra organizzazione, oppure espandersi fino a comprenderepiù sedi: la presenza di più repliche modificabili potrebbe allora rivelarsi piùconsona alla nuova situazione.275


Replica Management ServiceRequisitiSi può pensare di mettere a disposizione dell’utente un indice di affidabilitàassociato ad ogni risorsa, che rappresenti, ad esempio, la frequenza attesa diletture e scritture, e in base al quale il sistema di replicazione sia in grado didecidere automaticamente quale configurazione associare alla risorsa e i relativiparametri.Si possono dunque individuare i seguenti requisiti:• strategia di replicazione dinamica, <strong>per</strong>ché il numero di repliche associate aduna risorsa può variare nel tempo (ovviamente, l’aggiunta e la rimozionedi repliche non deve interrom<strong>per</strong>e l’attività del sistema);• capacità di modificare la configurazione di una risorsa, cambiando il numerodi repliche aggiornabili associate ad essa;• esposizione all’utente di primitive <strong>per</strong> la configurazione della replicazione.12.1 RequisitiDi seguito sono enunciati i requisiti del sistema di Replica Management, inlingua 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 <strong>dei</strong> requisiti rifiutatinon sono stati riutilizzati, rendendo in questo modo univoca l’identificazione diogni requisito.Requisiti <strong>per</strong> la gestione delle risorseI seguenti requisiti formalizzano la specifica di RM in qualità di sistema ingrado 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 <strong>per</strong> gestire le risorsee 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 delleesigenze.2 Nell’enunciato in lingua inglese, le parole MUST, MUST NOT, REQUIRED, SHALL,SHALL NOT, SHOULD, SHOULD NOT, RECOMMENDED, MAY, e OPTIONAL sono dainterpretarsi come descritto in [Bra97].276


Replica Management ServiceRequisitiRequirement 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 <strong>dei</strong> nomi che individuala sintassi e la semantica del suo valore, la cui conformità può essere verificatamediante 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 indirizzamentodiretto, che può essere realizzato combinando il nome del metadato con quellodella risorsa.Requirement RM-R008 (Standard Compliance)XML representation of resources MUST be allowed.Deve essere <strong>per</strong>messa la rappresentazione delle risorse tramite XML.Requirement RM-R009 (Functional Requirement)Resources handled by RM MUST be globally and univocally identified through aname.Le risorse di cui si occupa RM devono essere identificate univocamente alivello globale tramite un nome.Requirement RM-R010 (Design Constraint)Resource names used by RM MUST exhibit location independence.Lo spazio <strong>dei</strong> nomi usato <strong>per</strong> identificare le risorse di cui si occupa RM devepresentare 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 o<strong>per</strong>azioni di base della memorizzazione<strong>per</strong>sistente.277


Replica Management ServiceRequisitiRequirement RM-R014 (Functional Requirement)O<strong>per</strong>ations different from the basic CRUD MUST be optional in specific implementations.Deve essere sufficiente che un’implementazione del sistema di Replica Managementrealizzi soltanto le o<strong>per</strong>azioni CRUD.Requirement RM-R015 (Functional Requirement)Locking and unlocking of resources MAY be allowed.È possibile definire delle o<strong>per</strong>azioni che <strong>per</strong>mettono di bloccare l’accesso allerisorse mentre queste stanno venendo modificate, e sbloccarlo in seguito.Requirement RM-R016 (Functional Requirement)Specific o<strong>per</strong>ations for management or <strong>per</strong>formance enhancement MAY be supported.È possibile definire altre o<strong>per</strong>azioni allo scopo di potenziare la gestione dellerisorse o impostare le prestazioni del sistema. Ad esempio, potrebbe risultareutile una primitiva <strong>per</strong> la creazione di duplicati di una risorsa.Requirement RM-R017 (Functional Requirement)Partial access to data and metadata MAY be supported.È possibile che sia <strong>per</strong>messo accedere a parti <strong>dei</strong> dati o a singoli metadati,ad esempio <strong>per</strong> effettuare su di essi le o<strong>per</strong>azioni CRUD.Requirement RM-R018 (Functional Requirement)Resource validation MAY be provided upon resource creation or update, or uponexplicit request.Il servizio può offrire funzionalità di validazione delle risorse, ovvero deveessere possibile l’uso di procedure generiche che restituiscano informazionirelativamente alla conformità di una risorsa rispetto ai tipi dichiarati.In particolare, possono essere previsti meccanismi di validazione delle risorsememorizzate 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 o<strong>per</strong>azioni devono prevedere il trasporto di credenziali, in modo che un utenteche vuole svolgere un’o<strong>per</strong>azione su una risorsa possa ottenere l’autorizzazionead 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 basandosisulle entità in gioco, come ad esempio il detentore <strong>dei</strong> diritti sulla risorsa,278


Replica Management ServiceRequisitiil richiedente dell’o<strong>per</strong>azione di accesso, il sistema di accesso e lo stesso serviziodi Replica Management.Requirement RM-R021 (Design Constraint)The service provided by RM MUST be delivered through a globally addressableinterface.Il servizio fornito da RM deve essere fruibile mediante un’interfaccia indirizzabilea 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 o<strong>per</strong>azioni e i messaggidevono essere descritti senza fare riferimento a protocolli o linguaggi diprogrammazione 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 esserefornita utilizzando WSDL, in modo da offrire maggiore intero<strong>per</strong>abilità.Requirement RM-R025 (Design Constraint)The interface exposed by RM MUST be implementable using different programminglanguages.L’interfaccia esposta da RM deve essere implementabile mediante linguaggidi programmazione diversi.Requirement RM-R026 (Standard Compliance)WSDL MAY be used to describe interface implementations.È possibile utilizzare WSDL <strong>per</strong> descrivere le implementazioni dell’interfaccia,grazie alle estensioni <strong>per</strong> HTTP e SOAP.In particolare, potrebbe essere utile definire una nuova estensione di WSDL<strong>per</strong> 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 implementazionicon 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 iprincipi delle ROA.279


Replica Management ServiceRequisitiRequirement RM-R029 (Portability)Protocols other than HTTP MAY be supported.È possibile pensare ad un’implementazione di RM basata su protocolli diversida HTTP, <strong>per</strong> motivi di flessibilità.Requirement RM-R030 (Portability)Other architectural solutions MAY be used for implementation.Il sistema di Replica Management può essere implementato utilizzando altresoluzioni architetturali.Requisiti <strong>per</strong> la replicazioneI seguenti requisiti formalizzano la specifica di RM in qualità di sistema ingrado 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ù replichedi una risorsa.Requirement RM-R032 (Functional Requirement)The replication system SHALL manage replica configuration individually foreach 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 bemodified over time.La configurazione delle repliche associate ad una data risorsa deve esseremodificabile nel tempo.Requirement RM-R034 (Performance Requirement)Changes in replica configuration of a resource MUST NOT introduce significantdowntime in the system.La modifica della configurazione delle repliche associate ad una risorsa nondeve comportare l’indisponibilità del servizio <strong>per</strong> un tempo significativo.Requirement RM-R036 (Functional Requirement)The replication system MUST support transparently splitting a resource intomultiple resources for <strong>per</strong>formance enhancement.Al fine di migliorare le prestazioni, il sistema deve essere in grado di dividereuna risorsa in più parti.Internamente al sistema, ciascuna di queste parti verrà considerata come unarisorsa separata, che di conseguenza potrà essere configurata indipendentemente.Questa suddivisione dovrà <strong>per</strong>ò risultare trasparente all’esterno del sistema, ilquale ha il compito di mascherarla.280


Replica Management ServiceRequisitiRequirement RM-R037 (Functional Requirement)The replication system MUST be asynchronous.Al fine di continuare l’esecuzione anche in presenza del fallimento di unoo più server o di partizionamenti della rete, la replicazione delle risorse deveseguire l’approccio asincrono.Requirement RM-R038 (Functional Requirement)Data and metadata content in a replica MUST eventually converge to the samevalue in every replica of the same resource.Il contenuto <strong>dei</strong> dati e <strong>dei</strong> metadati di ogni replica di una stessa risorsa deveconvergere nel tempo allo stesso valore. In altre parole, deve essere mantenutala 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, descrittanel 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 <strong>per</strong>taining to replication MUST be accessible.I metadati riguardanti la replicazione devono essere accessibili. Ciò implical’esposizione, tramite un’apposita interfaccia di amministrazione, di appropriatefunzioni atte alla gestione <strong>dei</strong> metadati di livello RM.Requirement RM-R044 (Design Constraint)Except for administrative tasks, the interface exposed by RM MUST exhibitreplication transparency.L’interfaccia esposta dal sistema deve essere quanto più trasparente possibilealla replicazione, pur <strong>per</strong>mettendo l’amministrazione del sistema.L’utente del sistema di Replica Management deve poter o<strong>per</strong>are sulle risorsecome se non fossero replicate.Requirement RM-R045 (Functional Requirement)The replication protocol MUST allow any replica to initiate the synchronizationprocess.Il processo di sincronizzazione deve poter essere inizializzato sia da una replicasu un server che ha eseguito una modifica della risorsa e vuole propagarloalle altre repliche, sia da una replica su un server che è rimasto disconnesso evuole aggiornarsi all’ultima versione della risorsa.281


Replica Management ServiceRequisitiRequirement RM-R046 (Functional Requirement)The replication protocol MUST provide for recovery and rescheduling of a synchronizationsession.Il protocollo di replicazione deve fornire il recu<strong>per</strong>o e la riprogrammazione diuna sessione di sincronizzazione, ad esempio quando una replica è irraggiungibilea causa della <strong>per</strong>dita della connessione.Requirement RM-R047 (Functional Requirement)The model MUST support the following triggers for initiation of the synchronizationprocess:• a configurable set of scheduled times;• <strong>per</strong>iodically, with a configurable <strong>per</strong>iod;• a configurable maximum amount of time since the last synchronizationsession;• 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;• <strong>per</strong>iodicamente, con <strong>per</strong>iodo configurabile;• allo scadere di una quantità massima configurabile di tempo dall’ultimasincronizzazione;• 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 <strong>dei</strong> dati. Si noti che ciò è facilmenterealizzabile quando si decide di seguire un approccio di tipo REST.Requirement RM-R049 (Performance Requirement)Replication SHOULD have minimal impact on system <strong>per</strong>formance.La replicazione dovrebbe avere impatto minimo sulle prestazioni del sistema,ovvero ostacolare il meno possibile lo svolgimento delle altre funzioni.282


Replica Management ServiceRequisitiRequirement RM-R051 (Performance Requirement)The replication system SHOULD limit impact on the network by minimizing thenumber of messages and the amount of traffic sent.Il sistema di replicazione dovrebbe limitare l’impatto sulla rete, minimizzandoil 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 soltantole parti della risorsa che sono state modificate.Requirement RM-R053 (Functional Requirement)The capability to check the differences between two replicas for the same resourceSHOULD be provided.Dovrebbe essere fornita la capacità di controllare le differenze tra due replichedella stessa risorsa.Requirement RM-R054 (Security)The replication protocol MUST support mutual authentication of replica serversduring initialization of a synchronization session.Il protocollo di replicazione deve <strong>per</strong>mettere la mutua autenticazione tra iserver durante l’inizializzazione di una sessione di sincronizzazione.Requirement RM-R055 (Security)The replication protocol MUST support the initialization of anonymous synchronizationsessions.Il protocollo di replicazione deve <strong>per</strong>mettere l’inizializzazione di sessioni disincronizzazione anonime.Requirement RM-R056 (Security)The replication protocol MUST support transfer of data with data integrity anddata confidentiality.Il protocollo di replicazione deve essere in grado di mantenere l’integrità ela confidenzialità <strong>dei</strong> dati durante il loro trasferimento.Requirement RM-R057 (Security)The replication protocol MUST support the ability during initialization of a synchronizationsession for the authenticated replica servers to mutually decide todisable data integrity and data confidentiality within the context of and for theduration of that particular session.Durante l’inizializzazione di una sessione di sincronizzazione, due server autenticatidevono poter decidere, di comune accordo, di disabilitare l’integrità ela confidenzialità <strong>dei</strong> dati <strong>per</strong> quella particolare sessione.283


Replica Management ServiceGestione delle risorseRequirement RM-R058 (Security)The transport for administrative access MUST <strong>per</strong>mit assurance of the integrityand confidentiality of all data transferred.Durante l’accesso da parte dell’utente <strong>per</strong> l’amministrazione del sistema,deve essere possibile avere la garanzia dell’integrità e della confidenzialità ditutti i dati trasferiti.12.2 Gestione delle risorseEsistono <strong>dei</strong> servizi che il sistema di Replica Management deve essere in gradodi fornire <strong>per</strong> la gestione delle risorse e l’accesso ad esse, in accordo al requisitoRM-R001, e indipendentemente dal fatto che esse siano o meno replicate.Infatti, anche in uno scenario in cui la replicazione delle risorse non è richiestae dunque può non essere realizzata, l’utente ha comunque bisogno di potersfruttare le funzionalità di memorizzazione <strong>per</strong>sistente e di poter identificarele risorse indipendentemente dalla loro locazione fisica. Laddove la replicazionenon si renda necessaria, è possibile pensare ad un’implementazione del sistemadi Replica Management che fornisca soltanto tali servizi.12.2.1 Memorizzazione <strong>per</strong>sistentePer le funzionalità relative alla memorizzazione <strong>per</strong>sistente, il sistema diReplica Management si avvale del servizio offerto da Storage Interface, la cuiprogettazione e realizzazione sarà affrontata nel capitolo 13.Secondo il modello dell’informazione definito, ogni risorsa è vista come unarappresentazione <strong>dei</strong> dati che contiene. I metadati associati sono le proprietà ditale rappresentazione; ciascuno di essi ha un nome di tipo URI che lo identificaunivocamente nell’ambito di una stessa risorsa, e ne identifica universalmente iltipo e la semantica.Ogni risorsa inoltre possiede un identificatore, il quale la individua univocamenteall’interno del servizio di storage sui cui è mantenuta, e che, compostocon l’indirizzo (il cosiddetto endpoint) di quest’ultimo, costituisce un URLche <strong>per</strong>mette l’accesso alla risorsa stessa. Il valore di un metadato è indirizzatomediante la combinazione dell’URL della risorsa con il nome del metadatostesso.Si osservi che, dal punto di vista del sistema di Replica Management, ognirisorsa di livello SI rappresenta una particolare replica (che può anche esserel’unica esistente) dell’informazione gestita.In un modello stratificato come quello dell’architettura IDN, un livello è dettoconsumer in quanto sfrutta i servizi offerti dal livello inferiore, detto provider.L’interfaccia di SI espone delle o<strong>per</strong>azioni <strong>per</strong> la gestione delle risorse chepossiede, ossia le singole repliche dell’informazione gestita dal Replica Management.Ciascuna di queste o<strong>per</strong>azioni realizza una determinata funzionalitàmediante lo scambio di messaggi tra il consumer, che in questo caso è il livelloRM, e il provider, ovvero SI stesso.Un’implementazione di Storage Interface dovrà necessariamente realizzare le284


Replica Management ServiceGestione delle risorseo<strong>per</strong>azioni di base della memorizzazione <strong>per</strong>sistente, ossia le quattro o<strong>per</strong>azioniindicate dall’acronimo “CRUD” (capitolo 13).Possono inoltre essere realizzate ulteriori o<strong>per</strong>azioni ausiliarie, definite inbase a considerazioni di carattere pratico, come ad esempio la creazione di unduplicato di una risorsa, oppure l’elenco degli identificatori delle risorse presentiin un certo servizio di storage o <strong>dei</strong> nomi <strong>dei</strong> metadati associati ad una certarisorsa.Altre funzionalità atte a soddisfare requisiti opzionali del servizio comprendonoo<strong>per</strong>azioni specializzate <strong>per</strong> la lettura e la modifica diretta <strong>dei</strong> dati e <strong>dei</strong>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 unarisorsa. Sono infine disponibili anche funzionalità di gestione della sottoscrizionee della notifica di eventi.Quando il sistema di Replica Management invia una richiesta ad un serviziodi storage, in essa deve specificare l’endpoint del servizio e l’identificatore dellarisorsa di livello SI sulla quale richiede l’o<strong>per</strong>azione, oltre ad eventuali altriparametri necessari <strong>per</strong> la specifica funzionalità. Se il servizio che riceve larichiesta non possiede la risorsa di livello SI specificata, restituirà indietro unmessaggio di errore.In IDN, ogni risorsa di livello SI possiede un proprietario, identificato nell’istanzadi livello RM che ne ha richiesto la creazione.Ciascuna istanza di livello RM è autoritativa su un certo numero variabile diistanze di livello SI: significa che può comunicare direttamente con esse e richiederele varie o<strong>per</strong>azioni sulle risorse di livello SI contenute di cui è proprietaria.Più istanze di livello RM possono essere autoritative su una stessa istanza dilivello SI e richiedere la creazione di <strong>nuove</strong> repliche su di essa.Viceversa, la lettura, la scrittura e la rimozione di una risorsa di livelloSI esistente possono essere effettuate soltanto dal suo proprietario. Quandoun’istanza di livello RM ha bisogno di eseguire un’o<strong>per</strong>azione su una risorsa dicui non è proprietaria, dovrà inoltrare la richiesta all’istanza proprietaria.12.2.2 Il servizio di risoluzione <strong>dei</strong> nomiAllo scopo di realizzare, secondo il requisito RM-R010, l’indipendenza dallalocazione nell’identificazione delle risorse gestite, il sistema di Replica Managementutilizza i nomi di tipo URN, come specificato dal requisito RM-R012.Un URN (Uniform Resource Name) ha il compito di identificare una risorsavista come oggetto logico gestito dal sistema, la quale può essere rappresentatafisicamente da un insieme di repliche. L’obiettivo è quello di fornire un identificatore<strong>per</strong>sistente e unico a livello globale da associare ad ogni risorsa, comeaffermato dal requisito RM-R009.12.2.3 Il servizio di replicazioneIn accordo al requisito RM-R031, il sistema di Replica Management deveessere in grado di gestire una situazione in cui uno stesso oggetto logicoè fisicamente rappresentato da un insieme di risorse di livello SI, le quali necostituiscono le varie repliche.285


Replica Management ServiceGestione delle risorseDevono essere <strong>per</strong>ciò affrontati i seguenti problemi inerenti al servizio direplicazione:• 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 lerichieste <strong>dei</strong> client.Ciascuno di questi problemi, affrontati rispettivamente nei paragrafi 12.2.4,12.2.5 e 12.2.6, è in gran parte indipendente dagli altri; considerati nel loroinsieme, essi vanno a coprire i principali aspetti necessari <strong>per</strong> la costituzione diun sistema di replicazione.Un altro <strong>dei</strong> 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 esserein grado di configurare la replicazione di ogni risorsa indipendentemente. Ingenerale, <strong>per</strong>ciò, ogni risorsa gestita dal sistema sarà un potenziale oggetto dareplicare. Nel contesto IDN, ad esempio, le risorse rappresentano le diverseversioni di un documento, mentre nel caso di un file system o di una FAN lerisorse 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, internamenteal sistema, ciascuna di queste parti possa essere considerata come unarisorsa separata, e di conseguenza possa essere configurata indipendentemente:si prevede dunque l’esistenza di un tipo di risorsa che rappresenta l’aggregato dipiù parti, delle quali contiene al suo interno i PRI. In questo caso, la replicazioneha una granularità maggiore.In pratica, il livello di granularità con cui il contenuto di una risorsa è replicatorisulta determinato in base all’utilizzo che viene fatto della risorsa stessa,in modo da ottimizzare le prestazioni nella lettura e scrittura delle sue varieparti.In generale, se una risorsa è richiesta frequentemente dai client di una dataistanza di livello RM, sarebbe opportuno che fosse possibile ottenere il contenutodi tale risorsa da una replica di cui quell’istanza è proprietaria, in mododa evitare di dover contattare ogni volta un’altra istanza di pari livello RM,o<strong>per</strong>azione che introduce sovraccarico nel sistema.La soluzione di posizionare una replica della risorsa presso una delle istanze dilivello SI su cui quell’istanza è autoritativa può <strong>per</strong>ò non essere sempre fattibile.Il sistema di Replica Management può allora decidere, come suggerito dalrequisito RM-R048, di creare una copia cache del contenuto di tale risorsa.Così, alle successive richieste di lettura <strong>per</strong> quella risorsa da parte di un client,quell’istanza è in grado di restituirne il contenuto senza bisogno di contattarenessuna altra istanza di pari livello RM. In seguito a tale decisione, i dati ottenuticontattando una delle istanze di pari livello RM vengono utilizzati <strong>per</strong> creareuna risorsa di livello SI a cui il sistema può accedere direttamente. È comunquepossibile che il proprietario della risorsa, intesa come oggetto logico gestito dalsistema, non <strong>per</strong>metta di effettuarne il caching.286


Replica Management ServiceGestione delle risorseIl funzionamento di un’entità di livello RM che tiene una copia cache di unarisorsa in pratica è analogo a quello di un server proxy.Quando un server proxy riceve una richiesta da un client <strong>per</strong> una certarisorsa, chiede al server HTTP di effettuare la validazione della copia cache diquella risorsa, ossia chiede di controllare se la risorsa è stata modificata dopoche è stata memorizzata la copia cache; in caso negativo, invia il contenuto dellacopia cache al client.Si consideri un server utilizzato da molti client: quando uno di essi richiedeuna risorsa che era già stata richiesta in precedenza, da lui stesso o da un altroclient, il proxy è in grado di rispondere inviando la copia cache, senza doversicollegare al sito che possiede la copia originale. In questo modo si evita disovraccaricare sia il sito che possiede la copia originale della risorsa sia la rete,migliorando le prestazioni del sistema anche <strong>per</strong> quelle richieste che devononecessariamente essere inoltrate al sito che possiede la copia originale.È possibile anche utilizzare un meccanismo di scadenza a tempo, come quelloadottato dal DNS, secondo il quale una copia cache continua ad essere utilizzatafinché non è scaduta, senza bisogno che il suo contenuto venga validato ognivolta.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’associazionetra l’URL della copia cache e il PRI della relativa risorsa. LS non viene mai aconoscenza dell’URL della copia cache e non sarà quindi in grado di fornirla inseguito al lookup del PRI della risorsa.Un sistema come quello considerato dovrebbe cercare di fornire ai suoi clientle migliori prestazioni con il minor sovraccarico possibile.Di fatto, il progetto di un sistema di replicazione risulta dal compromessotra i requisiti funzionali e quelli relativi alle prestazioni e al costo; ad esempio,aumentare il numero <strong>dei</strong> server che mantengono una copia di una risorsa puòservire a diminuire la latenza <strong>per</strong>cepita dai client, ma dover propagare gli aggiornamentiad ognuna di esse introduce un aumento nel costo o<strong>per</strong>azionale delsistema.Poiché le prestazioni del sistema possono subire variazioni in relazione aipattern di accesso <strong>dei</strong> client e alle condizioni della rete, è opportuno che ilsistema sia capace di adattare automaticamente la sua configurazione. In altreparole, deve essere possibile utilizzare una strategia di replicazione dinamica,la quale, come visto nel paragrafo C.5, sia capace di adattarsi ai cambiamentiin modo da mantenere il livello desiderato di prestazioni, pur continuando aosservare i vincoli applicativi con costo minimo.Il processo di adattamento consiste in una serie di modifiche nelle decisioniprese <strong>per</strong> il mantenimento della consistenza e <strong>per</strong> il posizionamento e la selezionedelle repliche.Perché l’adattamento della configurazione possa essere innescato automaticamente,è necessario che il sistema sia in grado di accorgersi del fatto che le prestazionisi stanno allontanando dall’intervallo <strong>dei</strong> valori accettabili. A seconda<strong>dei</strong> criteri di ottimizzazione, sarà necessario scegliere attentamente <strong>dei</strong> parametriche riflettano accuratamente il comportamento del sistema, e <strong>dei</strong> meccanismi<strong>per</strong> stimarne i valori.287


Replica Management ServiceGestione delle risorse12.2.4 Mantenimento della consistenzaIl problema del mantenimento della consistenza riguarda la scelta di un modellodi consistenza e la sua realizzazione tramite appositi protocolli, i qualipossono impiegare diversi meccanismi <strong>per</strong> la propagazione degli aggiornamenti.I modelli di consistenza, descritti nel paragrafo C.3, possono essere visti comeun contratto, stipulato tra il sistema di replicazione e i suoi client, che detta leproprietà relative alla consistenza delle risorse gestite dal sistema.Il requisito RM-R039 afferma che il sistema di Replica Management consideratodeve osservare la consistenza sequenziale; essa può essere garantita soltantose i processi che eseguono le o<strong>per</strong>azioni sui dati condivisi utilizzano le transazionie i meccanismi di locking [TvS01].Ad ogni risorsa gestita dal sistema di replicazione è associato un protocolloche, come visto nel paragrafo C.4, ha il compito di garantire che essa aderiscaal modello di consistenza definito. Si noti che uno stesso modello può essererispettato utilizzando protocolli diversi.Il requisito RM-R042 afferma che non devono presentarsi conflitti; di conseguenza,<strong>per</strong> il sistema considerato si rende necessario l’utilizzo di protocollipessimistici. In particolare, <strong>per</strong> le risorse il cui contenuto si prevede che non cambinel tempo, è sufficiente l’esistenza di un’unica replica modificabile, <strong>per</strong> cui siadotta l’approccio del sito primario, mentre <strong>per</strong> i dati che vengono spesso aggiornatiè opportuno <strong>per</strong>mettere l’esistenza di un insieme di repliche modificabili, equindi si adotta l’approccio a votazione.Quando si utilizza l’approccio del sito primario, è possibile portare a terminele o<strong>per</strong>azioni di lettura sui siti di backup oppure sulle copie cache senza violare laconsistenza sequenziale, come visto nel paragrafo C.4.1. Anche quando si utilizzal’approccio a votazione è possibile che una richiesta di lettura venga servitada una copia cache (a cui sono sempre assegnati zero voti) senza incorrere inalcuna violazione del modello di consistenza; ciò è utile, ad esempio, <strong>per</strong> renderele risorse disponibili in lettura qualora non si riesca ad ottenere il quorum nelmodo visto nel paragrafo C.4.2.Si osservi che, se le o<strong>per</strong>azioni di aggiornamento sono viste come atomiche,non c’è bisogno di mettere il lock sulla replica che serve una richiesta di lettura,poiché tale o<strong>per</strong>azione può soltanto vedere o il valore precedente o quello seguentead una modifica eseguita sulla stessa risorsa, ma mai uno stato intermedionon valido [RL05].Come espresso dal requisito RM-R037, la replicazione deve essere asincrona.Pertanto, un’o<strong>per</strong>azione di scrittura può considerarsi conclusa quando è stataeseguita, a seconda del tipo di approccio in uso, o sulla replica nel sito primarioo su un numero di repliche pari al quorum di scrittura, e comunque sempre senzaattendere che gli aggiornamenti siano propagati a tutte le restanti repliche. Ciò<strong>per</strong>mette la scalabilità del sistema.Di conseguenza, se si desidera <strong>per</strong> una risorsa un determinato grado di affidabilità,l’approccio a votazione <strong>per</strong>mette di garantire che <strong>per</strong> ogni o<strong>per</strong>azionedi scrittura sarà sicuramente aggiornato almeno un numero di repliche pari alquorum di scrittura.Come previsto dal requisito RM-R033, la configurazione di una risorsa puòcambiare nel tempo.288


Replica Management ServiceGestione delle risorseSoltanto il proprietario della risorsa può decidere riguardo l’unicità o menodella replica modificabile e, di conseguenza, il tipo di approccio da utilizzare <strong>per</strong>il mantenimento della consistenza.Quando si utilizza l’approccio del sito primario, la modifica della configurazionepuò consistere nella variazione del numero <strong>dei</strong> siti di backup, la qualepuò essere innescata su richiesta esplicita dell’utente o in base alle condizionidel sistema, come descritto più avanti nel paragrafo 12.2.5. Potrebbe ancheessere necessario affidare il ruolo di sito primario ad un sito che precedentementenon lo era: è importante che il processo di elezione del nuovo primarionon sia innescato automaticamente dal sistema, in modo da impedire che, incaso di partizionamenti della rete, non venga eletto un primario diverso in ognipartizione.Quando invece si utilizza l’approccio a votazione, la modifica della configurazionepuò riguardare anche la variazione <strong>dei</strong> valori <strong>dei</strong> quorum o la riassegnazione<strong>dei</strong> voti. Quest’ultima, in particolare, si rende necessaria ogni volta chesi aggiunge o si rimuove una replica; alla creazione, ad ogni replica si possonoassegnare zero voti, e la riassegnazione può avvenire in un momento successivo,mentre l’eliminazione di una replica con voti diversi da zero richiede necessariamentel’innesco della riassegnazione. Alcuni metodi <strong>per</strong> l’assegnazione <strong>dei</strong> votisono illustrati in [Jal94].A prescindere dal tipo di o<strong>per</strong>azione da effettuare su una risorsa, è sempredesiderabile minimizzare la complessità di comunicazione del protocollo di gestionedelle repliche, intesa come il numero di repliche da contattare <strong>per</strong> portarea termine ogni o<strong>per</strong>azione. Risulta dunque opportuno che, in generale, le dimensioni<strong>dei</strong> quorum di lettura e scrittura siano inversamente proporzionali allefrequenze delle corrispondenti o<strong>per</strong>azioni.Lo svantaggio principale nell’uso dell’approccio a votazione consiste proprionel fatto che il numero delle repliche da contattare <strong>per</strong> ottenere un quorum crescelinearmente con il numero totale di repliche associate alla risorsa. Ciò costituisceun’ostacolo alla scalabilità del sistema: si può allora pensare di adottare unasoluzione che preveda la costruzione di un quorum a più livelli, mappato sullagerarchia della rete sottostante.L’idea è quella di organizzare i nodi della rete in una gerarchia logica chepuò essere anche indipendente dalla topologia fisica della rete. Le foglie dellagerarchia, ossia i nodi al livello più basso, sono i nodi fisici, e tutti i nodi ailivelli su<strong>per</strong>iori sono entità logiche che agiscono <strong>per</strong> conto <strong>dei</strong> loro successori. Allivello più alto, il nodo radice rappresenta l’intera rete.Quando si vuole eseguire un’o<strong>per</strong>azione, si attraversa l’albero partendo dallaradice fino alle foglie; <strong>per</strong> ciascun livello della gerarchia tranne il più bassosi devono ottenere <strong>dei</strong> 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 utilizzanoIDN è illustrato nel paragrafo 6.3. Tale scenario realizza una gerarchia a duelivelli, in cui il livello inferiore è composto dai server collegati mediante LAN3 Si suppone che ogni nodo fisico sia in grado di eseguire le azioni di un qualsiasi nodo logiconella gerarchia.289


Replica Management ServiceGestione delle risorseall’interno delle organizzazioni, mentre il livello su<strong>per</strong>iore è composto da piùorganizzazioni che comunicano tra loro sfruttando Internet.Si può dunque pensare di costruire un quorum che preveda di ottenere, adesempio, la maggioranza tra le LAN su cui la risorsa è replicata, e poi in ciascunadi queste LAN la maggioranza tra i server che tengono una replica dellarisorsa. Questa soluzione garantisce che, comunque presi, due quorum abbianosempre almeno un nodo nell’intersezione, pur mantenendo più piccola possibilela dimensione di quest’ultima.Organizzando le repliche secondo la gerarchia, si ha come risultato una suddivisionedelle stesse che <strong>per</strong>mette di costruire quorum di dimensione minore.Ottenere la maggioranza al livello su<strong>per</strong>iore della gerarchia <strong>per</strong>mette di sceglierele LAN che si trovano più vicine a qualsiasi client dato, garantendo così untempo di accesso ottimale. Al livello inferiore si può scegliere nuovamente diottenere la maggioranza <strong>per</strong>ché, nella pratica, in ogni LAN il numero di serversu cui è presente una replica non su<strong>per</strong>a qualche unità, <strong>per</strong>ciò sarebbe su<strong>per</strong>fluoricorrere a costruzioni più complesse [BBB + 04].reteLAN 1 LAN 2LAN 311 12 13 21 22 23 31 32 33Figura 12.1: Votazione con quorum a maggioranza su due livelliNella figura 12.1 è mostrato un esempio in cui le repliche sono posizionatesui server 11 e 13 della LAN1, sui server 21, 22 e 23 della LAN2, e sul server 33della LAN3. Un quorum che comprende le LAN 1 e 2 è formato dalle replichesui server 11, 13, 21 e 22. Un quorum che comprende le LAN 2 e 3 è formatodalle repliche sui server 22, 23 e 33. Questi due quorum si intersecano nel server22.Altrimenti, nel caso in cui si vogliano mantenere bassi i costi delle o<strong>per</strong>azionidi lettura senza aumentare troppo quelli delle o<strong>per</strong>azioni di scrittura, si puòconsiderare la configurazione di tipo read-one-write-all <strong>per</strong> il quorum al livellosu<strong>per</strong>iore.Quando il sistema gestisce risorse di tipo IDN, potrebbe essere opportunoriuscire a selezionare sempre un quorum che comprenda almeno una trale LAN dell’organizzazione proprietaria della risorsa su cui si vuole effettuarel’o<strong>per</strong>azione.Il sito che serve un’o<strong>per</strong>azione di scrittura su una risorsa è incaricato dicomunicare, al termine dell’o<strong>per</strong>azione e se essa ha avuto successo, l’avvenutamodifica alle altre istanze di livello RM che possiedono una replica della stessarisorsa, delle quali viene a conoscenza tramite LS.I meccanismi <strong>per</strong> la propagazione degli aggiornamenti, descritti nel paragrafo290


Replica Management ServiceGestione delle risorseC.5.2, definiscono il modo in cui i server si scambiano gli aggiornamenti e in cheforma questi debbano essere trasferiti, oltre a chi inizializza il trasferimento equando esso debba avvenire.In generale, è opportuno scegliere la forma di aggiornamento che minimizzail sovraccarico totale nella comunicazione.Nel sistema di Replica Management considerato, l’avvenuta modifica di unarisorsa è notificata tramite l’invio di un’invalidazione, in modo da minimizzare ilnumero <strong>dei</strong> messaggi e la quantità di traffico immessi nella rete, come richiestodal requisito RM-R051. In pratica, si adotta un meccanismo di tipo push chevada ad innescare la richiesta <strong>dei</strong> dati modificati con un meccanismo di tipopull.Il requisito RM-R047 specifica le diverse situazioni in cui può essere innescatoil processo di sincronizzazione.Nonostante il sito in cui ha avuto origine la modifica possa effettuare ilrescheduling dell’invio dell’invalidazione, deve comunque essere sempre possibilerichiedere gli aggiornamenti con un meccanismo di tipo pull, ad esempio <strong>per</strong>sincronizzare una replica che è rimasta a lungo disconnessa, oppure quandoun nodo, in seguito al recu<strong>per</strong>o da un crollo, ha la necessità di controllare lapresenza di <strong>nuove</strong> versioni <strong>per</strong> 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 altrerepliche della relativa risorsa non sono neanche a conoscenza dell’esistenza dellacopia cache, <strong>per</strong>ché il suo URL non è restituito da LS in seguito all’o<strong>per</strong>azionedi lookup.L’aggiornamento di una copia cache deve necessariamente avvenire con unmeccanismo di tipo pull, innescato quando il sistema si accorge, in seguito allavalidazione, che è disponibile una versione più recente del contenuto dellarelativa risorsa.Se si utilizza il meccanismo di scadenza a tempo, conviene che il valore dell’intervallodi tempo <strong>per</strong> il quale la copia cache può essere utilizzata senza bisognodi validarne il contenuto sia grande se la risorsa riceve pochi aggiornamenti, epiccolo in caso contrario.Il requisito RM-R052 afferma che deve essere possibile, nella propagazionedegli aggiornamenti, inviare soltanto le parti della risorsa che sono state modificate.A supporto di ciò deve essere fornito un metodo <strong>per</strong> controllare ledifferenze tra due repliche di una stessa risorsa, come espresso dal requisitoRM-R053.Si suppone che ogni server mantenga un numero arbitrario di differenze trale versioni di ogni risorsa di cui possiede una replica.Quando riceve una richiesta di sincronizzazione <strong>per</strong> una certa risorsa, il serverconfronta il numero di versione della replica che possiede con quello delserver richiedente: se la differenza è disponibile può inviarla, riducendo il trafficoimmesso nella rete, altrimenti deve procedere all’invio dell’intero contenutodella 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


Replica Management ServiceGestione delle risorsesiderato sono messaggi di invalidazione) a repliche diverse usando connessioniseparate può comportare un traffico di rete eccessivo, oltre ad introdurre unsovraccarico considerevole anche sul server in cui la modifica ha avuto origine.Può allora risultare utile impiegare il modello di propagazione epidemico, ilquale si occupa di propagare gli aggiornamenti a tutte le repliche con il minornumero di messaggi possibili, ed ha nella scalabilità uno <strong>dei</strong> suoi principalivantaggi [TvS01].In un sistema che usa la propagazione epidemica, un sito non deve necessariamentericevere l’aggiornamento dal sito in cui ha avuto origine la modifica,ma la propagazione può passare attraverso <strong>dei</strong> siti intermedi; <strong>per</strong>ciò, questomodello fornisce la tolleranza ai fallimenti <strong>dei</strong> link di comunicazione.In generale, quando due siti comunicano, l’uno invia all’altro gli aggiornamentidi cui non è a conoscenza. Nei sistemi di area geografica, <strong>per</strong> ottenererisultati migliori può essere utile prendere in considerazione la topologia dellarete: ad esempio, si può fare in modo che i siti che sono connessi solo con alcunidegli altri vengano contattati con una probabilità relativamente alta, in quantorappresentano un ponte verso le altre parti della rete, e <strong>per</strong>ciò conviene che sianocontattati il prima possibile.Questo modello di propagazione degli aggiornamenti può essere utilizzatocon la semantica delle transazioni, eventualmente affiancato dall’approccio avotazione in modo da tollerare sia i fallimenti <strong>dei</strong> link di comunicazione chequelli <strong>dei</strong> nodi, come descritto in [HSAA03].12.2.5 Posizionamento delle replicheIl problema del posizionamento può essere suddiviso in due sottoproblemi distinti:il posizionamento <strong>dei</strong> server e il posizionamento <strong>dei</strong> contenuti [SSPvS04].Il primo sottoproblema consiste nel decidere dove posizionare i server cheandranno a contenere le repliche, e riguarda quindi la scelta di locazioni adattea tenere repliche di molte risorse.Anche se in generale la qualità del servizio <strong>per</strong>cepita dai client è un fattoreimportante <strong>per</strong> le decisioni relative al posizionamento, di fatto la scelta <strong>dei</strong> serverè legata a vincoli di tipo amministrativo e geografico, come ad esempio i costieconomici e la disponibilità del sito fisico. Nel posizionare i server si cerca diimmaginare quali possano essere le locazioni più interessanti a prescindere dalleesigenze di breve termine, basando le decisioni sulla topologia generale dellarete.Nel contesto IDN, le istanze di livello SI che forniscono il servizio di memorizzazione<strong>per</strong>sistente costituiscono i server sui quali risiedono fisicamente lerepliche delle risorse gestite dal Replica Management; il loro posizionamento èlegato alle caratteristiche delle infrastrutture di proprietà delle organizzazioniche decidono di usufruire <strong>dei</strong> servizi di IDN-SA.Il secondo sottoproblema consiste invece nel decidere quali <strong>dei</strong> server esistentiusare <strong>per</strong> contenere le diverse repliche di una certa informazione, al fine dimigliorare la qualità del servizio fornito ai client e bilanciare il carico.Una classificazione degli algoritmi di posizionamento delle repliche (Replica292


Replica Management ServiceGestione delle risorsePlacement Algorithm, in breve RPA) esistenti in letteratura e un confronto tradi essi in base alle loro prestazioni si trovano in [WCL + 03].Nel sistema di Replica Management considerato, la creazione e la rimozionedi una replica possono essere innescate internamente oppure richiesteesplicitamente dall’utente di un’istanza di livello RM.Per queste o<strong>per</strong>azioni, il sistema si interfaccia con il servizio di memorizzazione<strong>per</strong>sistente offerto da SI, e parallelamente si occupa di comunicare a LSl’inserimento o la rimozione dell’associazione tra l’URL della replica e il PRIdella risorsa.Si consideri cosa accade quando un’istanza di livello RM riceve una richiestadi creazione <strong>per</strong> una nuova risorsa. Nella richiesta può essere specificato, tramiteappositi parametri, il livello di affidabilità o di prestazioni atteso <strong>per</strong> 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 SIsulle quali creare le repliche.Ogni istanza di livello RM mantiene in locale un elenco di n istanze dilivello SI, con n variabile nel tempo, <strong>per</strong>ciò il problema del posizionamentoconsiste nello scegliere k su n servizi di storage sui quali creare una replicadella risorsa. Nell’elenco, le istanze di livello SI sono raggruppate <strong>per</strong> istanza dilivello RM autoritativa e ordinate <strong>per</strong> priorità, la quale dipende da fattori qualile caratteristiche di affidabilità e la capacità di storage <strong>dei</strong> dispositivi, e vieneaggiornata dinamicamente in base alle condizioni di carico. A parità di priorità,la scelta dell’istanza di livello SI su cui effettuare il posizionamento della replicapuò avvenire con una politica di tipo round-robin che selezioni uno dopo l’altrotutti server disponibili, bilanciando così il carico tra di essi.Se il risultato dell’algoritmo di posizionamento indica un’istanza di livello SIsu cui l’istanza di livello RM che aveva ricevuto la richiesta da parte dell’utenteè autoritativa, quest’ultima può direttamente procedere alla creazione dellareplica. Altrimenti, è necessario contattare l’istanza di pari livello RM autoritativa,la quale provvederà alla creazione della replica sull’istanza di livello SIscelta dall’algoritmo di posizionamento, se specificata, oppure su una qualsiasitra le istanze di livello SI sulle quali è autoritativa.In seguito a variazioni nel tasso delle richieste effettuate dai client, potrebbeessere opportuno innescare il posizionamento delle repliche allo scopo di adattareil sistema alle <strong>nuove</strong> condizioni. Ad esempio, se il sistema è in grado di identificareuna situazione in cui il numero di richieste <strong>per</strong> uno stesso oggetto logicoaumenta considerevolmente, può reagire aumentando il numero delle repliche adesso associate, <strong>per</strong> evitare che i client <strong>per</strong>cepiscano una latenza eccessiva.Nel sistema considerato, ogni istanza di livello RM può decidere autonomamente,in base ai pattern di richiesta da parte <strong>dei</strong> client, se creare una replicadi una risorsa, una volta ottenuto il <strong>per</strong>messo dal proprietario di quest’ultima.Ciascun server calcola <strong>per</strong>iodicamente il tasso di richieste <strong>per</strong> una data risorsa, edecide di creare una replica locale se esso su<strong>per</strong>a una certa soglia; decide invecedi rimuovere la replica quando gli accessi calano. In riferimento al paragrafoC.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 replichenei server esistenti è relativamente basso, gli algoritmi di posizionamento <strong>dei</strong>293


Replica Management ServiceGestione delle risorsecontenuti possono essere eseguiti spesso, in modo da seguire il più possibile levariazioni del carico.In relazione al livello di affidabilità richiesto <strong>per</strong> la risorsa, il sistema devefare in modo che il numero totale delle sue repliche non scenda oltre un limiteprestabilito.Per quanto riguarda le copie cache, infine, la decisione in merito alla lorocreazione nasce <strong>per</strong> motivi legati esclusivamente all’ottimizzazione delle prestazioni,qualora non si voglia creare una replica dell’informazione o il proprietariodella stessa non lo conceda.Una copia cache viene creata e rimossa da un servizio di storage con ilmedesimo criterio di posizionamento usato <strong>per</strong> le repliche.L’unica differenza è la mancata associazione in LS tra URL e PRI; sta aciascuna istanza di livello RM mantenere in un catalogo locale tale associazione<strong>per</strong> ognuna delle copie cache che possiede.12.2.6 Selezione della replica e routing delle richiestePosizionare le repliche attentamente è utile soltanto se poi i client sono ingrado di accedere veramente alla replica più vicina.Il problema della selezione della replica consiste nel decidere quale tra lerepliche di una stessa risorsa sia più adatta a servire la richiesta di un client:questa scelta è difficile, <strong>per</strong>ché le condizioni del sistema quali il carico <strong>dei</strong> server,la congestione <strong>dei</strong> collegamenti e, di conseguenza, la latenza della rete cambianocontinuamente.La variabilità delle condizioni può portare a scegliere repliche diverse a secondadel momento e del client che ha effettuato la richiesta. Ad esempio, unareplica che appare ottimale <strong>per</strong> <strong>per</strong> un dato client non necessariamente rimanesempre ottimale <strong>per</strong> quello stesso client; analogamente, quando due client richiedonola stessa risorsa contemporaneamente, possono essere serviti da replichediverse.Nel sistema di Replica Management considerato, quando un’istanza di livelloRM riceve una richiesta di accesso ad una risorsa da parte di un client, <strong>per</strong> primacosa controlla nel catalogo locale se il PRI della risorsa corrisponde ad una dellecopie cache che possiede: in caso affermativo, e se la copia cache è ancora valida,la utilizza <strong>per</strong> servire la richiesta.Altrimenti viene contattato LS, il quale restituisce una lista di URL corrispondentialle varie repliche della risorsa, raggruppati <strong>per</strong> istanza di livello RMproprietaria.Si noti che in LS la lista di URL è contenuta in una risorsa che si compone dipiù 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 PRIpotrebbe non comprendere gli URL di tutte le repliche esistenti nel sistema.A questo punto, viene invocato un algoritmo che sceglie una tra le replichecon URL nella lista restituita da LS.Tale algoritmo si avvale di un meccanismo che ad ogni istanza di livelloSI associa un peso, il quale può essere calcolato in base a <strong>dei</strong> parametri cheriflettano le condizioni del sistema. Quando si adotta l’approccio a votazione <strong>per</strong>294


Replica Management ServiceGestione delle risorseil 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 dicarico, in base alle quali è effettuata la riassegnazione <strong>dei</strong> voti.In generale, se esiste una replica di cui l’istanza di livello RM che ha ricevutola richiesta è proprietaria, si accederà a quella. In caso contrario, la richiestaviene 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 nonviene informato della scelta della replica, e si limita ad attendere la risposta daparte dell’istanza di livello RM.Si noti che, <strong>per</strong> come è stato definito finora, il sistema di Replica Management<strong>per</strong>mette che in alcuni casi i client osservino violazioni della consistenzasequenziale. Infatti, quando un client accede più volte ad una risorsa, può succedereche 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. Sisupponga che la replica A abbia ricevuto un aggiornamento che la replica Bnon ha ancora ricevuto: se un client accede prima ad A e poi a B, può darsi cheosservi in B <strong>dei</strong> valori che sono inconsistenti con la consistenza sequenziale.Perciò, è opportuno che la selezione della replica faccia in modo che un datoclient sia servito dalla stessa replica <strong>per</strong> lunghi <strong>per</strong>iodi di tempo.Questo inconveniente può essere risolto come suggerito in [NDI03]: ogniserver che mantiene una replica inserisce nelle risposte che invia ai client uncookie HTTP che indica l’ultima versione della risorsa osservata da quel client.Successivamente, questo cookie viene controllato ogni volta che il client inviauna richiesta <strong>per</strong> quella stessa risorsa.Se un server riceve una richiesta da parte di un client che ha osservato <strong>per</strong>ultima una certa versione della risorsa specificata nella richiesta, e la replica sulserver contiene una versione precedente, allora il server innesca la sincronizzazionein modo da ottenere l’ultima versione disponibile prima di processare larichiesta.12.2.7 Azioni atomiche e transazioniIn generale, ogni o<strong>per</strong>azione richiesta dall’utente sulle risorse gestite dal sistemasi compone di più passi, ossia o<strong>per</strong>azioni primitive eseguite indivisibilmenteda parte dell’hardware, in una certa sequenza, e in modo che una nuovao<strong>per</strong>azione possa iniziare solo dopo che la precedente è terminata.In altre parole, queste o<strong>per</strong>azioni primitive godono <strong>dei</strong> benefici di indivisibilità,sequenzialità e non interferenza correlati all’atomicità, e <strong>per</strong>ciò sonoconsiderate azioni atomiche. Nessuno degli stati interni, ma soltanto lo statoiniziale e lo stato finale dell’azione rispetto alla sua esecuzione sono visibili: èla cosiddetta proprietà “tutto o niente”, la quale implica che un’azione atomicao viene portata a termine completamente, e con successo, oppure deve apparirecome se non fosse stata eseguita affatto [Jal94].Perché la consistenza delle risorse gestite dal sistema di Replica Managementsia garantita, è necessario che le o<strong>per</strong>azioni che l’utente può richiedere su di esse295


Replica Management ServiceGestione delle risorsesiano azioni atomiche, cioè siano eseguite nello stesso modo in cui l’hardwareesegue le sue istruzioni.Adottando la terminologia in uso nel contesto <strong>dei</strong> database, un’azione daeseguire in modo atomico che rappresenta l’unità logica fondamentale di computazioneè detta transazione.Una transazione è portata a termine in modo affidabile se la sua esecuzionepresenta 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. Questaproprietà è 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 transazionifino 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 <strong>per</strong>manenti. Nelsistema considerato, questa proprietà è garantita dal livello SI.Nel sistema di Replica Management considerato, il controllo della concorrenzapuò essere realizzato utilizzando <strong>dei</strong> 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 comeuna sequenza di azioni compresa tra un comando begin_transaction e uncomando end_transaction. Quest’ultimo spesso è preceduto da un comandodi commit, il cui scopo è assicurare che il risultato della transazione non vengaannullato 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 <strong>per</strong> ripetere tale transazione, ormaiconsiderata come committed.In un sistema distribuito, la situazione è più complessa, <strong>per</strong>ché le o<strong>per</strong>azionidi una transazione possono essere eseguite su nodi diversi.Può succedere che un nodo decida di interrom<strong>per</strong>e l’esecuzione di quellaparte della transazione che viene eseguita in quel nodo, o <strong>per</strong>ché esso fallisce,o <strong>per</strong>ché, <strong>per</strong> qualche motivo, non è in grado di eseguire l’o<strong>per</strong>azione richiesta.Se ciò accade, anche se gli altri nodi sono in grado di eseguire le loro partidella transazione, l’intera transazione deve essere interrotta, cioè terminare comeaborted.4 Si osservi che le considerazioni esposte si riferiscono al livello Replica Management diIDN, il quale gestisce risorse che rappresentano una data versione di una data informazioneprimitiva. Sarà compito <strong>dei</strong> livelli su<strong>per</strong>iori occuparsi di gestire il controllo della concorrenzasu ognuno <strong>dei</strong> nodi che costituiscono il documento IDN, in modo da impedire che più utenti dilivello applicativo modifichino contemporaneamente un’informazione primitiva aggregata dapiù documenti.296


Replica Management ServiceInterfacceInfatti, se alcune parti della transazione non possono essere eseguite, alloratutte le sue attività dovranno essere annullate, <strong>per</strong>ché l’effetto deve essere lostesso che si sarebbe avuto se la transazione non fosse mai iniziata. Soltanto nelcaso in cui tutti i nodi che prendono parte alla transazione sono disponibili adeseguirne il commit, essa può terminare come committed.Un protocollo di commit (Atomic Commit Protocol, in breve ACP) garantiscel’atomicità in quanto si occupa di assicurare che sia mantenuta la proprietà“tutto o niente”. Un ACP utilizzato spesso in ambienti distribuiti, quando unatransazione coinvolge più siti, è il two-phase commit (2PC).Quando il sistema di Replica Management considerato utilizza l’approccioa votazione <strong>per</strong> il mantenimento della consistenza, si serve di un protocollo diquesto tipo ogni volta che raccoglie i voti <strong>per</strong> ottenere un quorum di lettura odi scrittura oppure esegue la modifica di una risorsa aggiornando un numero direpliche pari al quorum di scrittura.Infine, bisogna che l’atomicità delle o<strong>per</strong>azioni eseguite dall’utente sia preservataanche in presenza di fallimenti. Si rendono necessari <strong>dei</strong> protocolli <strong>per</strong>assicurare che una transazione venga completata, cioè sia committed o aborted,anche quando si verificano <strong>dei</strong> guasti.Un protocollo di termination, in particolare, viene utilizzato <strong>per</strong> gestire ilguasto, mentre un protocollo di recovery serve ad assicurare che una replicaguasta, una volta che è stata ripristinata, assuma uno stato consistente.Quando non c’è modo di determinare se una replica è guasta, il protocollodi termination non può essere invocato, e non resta che aspettare che le replicheguaste siano ripristinate. Ciò può capitare nel caso in cui la comunicazioneavvenga con modelli di interazione debolmente accoppiati, come ad esempioPOP3 e SMTP nel caso della posta elettronica.12.3 InterfacceLa finalità del sistema di Replica Management è quella di fornire all’utenteun servizio di gestione di risorse replicate in modo trasparente ai livelli su<strong>per</strong>iori.Dal punto di vista dell’utente, il Replica Management è un’entità remotaalla quale effettuare richieste di servizio. L’interazione è basata sul paradigmaclient-server: nel contesto IDN, il client è rappresentato dal livello InformationHistory, 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 adisposizione 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’o<strong>per</strong>azione.Un parametro può servire a specificare la politica di accesso in lettura, laquale indica il tipo di semantica attesa in risposta dal sistema; in altre parole,mediante questo parametro è possibile indicare se si desidera riceverenecessariamente l’ultima versione disponibile del dato.Esisteranno inoltre <strong>dei</strong> parametri tramite i quali l’utente ha la facoltà dicontrollare 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 essomessaggi in ingresso e/o in uscita. Il contesto è relativo ai diagrammi UML [RJB99].297


Replica Management ServiceInterfacceall’affidabilità, alla disponibilità e alle prestazioni in lettura e scrittura attese <strong>per</strong>quel dato. Questi parametri sono esposti all’utente ma non sono memorizzatidirettamente dal sistema, il quale si occupa di tradurli opportunamente e, diconseguenza, aggiornare i metadati di livello RM relativi a quella particolarerisorsa.Ad esempio, se attraverso gli appositi parametri l’utente richiede <strong>per</strong> unarisorsa un grado elevato di tolleranza ai guasti, il sistema può impostare uncerto numero minimo di repliche esistenti e decidere di utilizzare l’approccio avotazione <strong>per</strong> il mantenimento della consistenza, in modo che ad ogni o<strong>per</strong>azionedi scrittura venga obbligatoriamente aggiornata una quantità di repliche pari alquorum di scrittura.Nel seguito è dunque introdotta, secondo il formalismo <strong>dei</strong> diagrammi <strong>dei</strong>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 messaa disposizione da Localization Service, allo scopo di evidenziare come RM siavvalga di LS <strong>per</strong> soddisfare le richieste <strong>dei</strong> livelli su<strong>per</strong>iori.Per convenzione, ad ogni caso d’uso è assegnato un nome del tipo:identificativo_sistema.identificativo_contesto.numerodove:• identificativo_sistema è l’identificativo del sistema che <strong>per</strong>mette diassociare 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 aquale entità del sistema si riferisce il caso d’uso.Ad esempio, “Int” corrisponde all’interfaccia.• numero è il numero sequenziale che <strong>per</strong>mette di assegnare ad ogni casod’uso un nome univoco, come richiesto dalle specifiche UML.12.3.1 Interfaccia esposta da Replica ManagementNella 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 <strong>dei</strong> casi d’uso che riassumonograficamente le primitive esposte da Replica Management, raggruppatecon nomi diversi a seconda del tipo di funzionalità che offrono.In genere, queste o<strong>per</strong>azioni sono richieste dal livello su<strong>per</strong>iore, ossia InformationHistory, ma possono esserlo anche da istanze di pari livello che, non possedendoi diritti <strong>per</strong> eseguirle direttamente, procedono all’inoltro verso l’istanzaproprietaria della risorsa. Le o<strong>per</strong>azioni raggruppate col nome “Admin” realizzanodelle funzionalità che violano la trasparenza della replicazione, e possonoessere eseguite solo dagli amministratori del sistema.Nella figura 12.5 è riportato il diagramma <strong>dei</strong> casi d’uso che riassume graficamentele primitive esposte da Replica Management esclusivamente alle istanze298


Replica Management ServiceInterfaccedi pari livello: sono o<strong>per</strong>azioni che si occupano della propagazione degli aggiornamentitra le diverse repliche di una stessa risorsa, e in quanto tali non sonoesposte ai livelli su<strong>per</strong>iori.Replica ManagementRM.int.CREATERM.int.READRM.int.UPDATERM.int.DELETERM.int.PROBEMETAclientRM.int.READMETARM.int.UPDATEMETARM.int.READDATARM.int.UPDATEDATAFigura 12.2: Casi d’uso dell’interfaccia esposta da RM: o<strong>per</strong>azioni “CRUD”Caso d’uso: RM.Int.CREATEID: UC.RM.Int.1Attori: Information History.Sequenza degli eventi:1. Il caso d’uso inizia quando l’utente ha la necessità di creare una nuova risorsadi livello RM, ed invia al sistema la richiesta insieme ai dati e ai metadatiche ne costituiranno il contenuto.299


Replica Management ServiceInterfacceL’utente può inoltre specificare eventuali parametri relativi alle caratteristichedesiderate <strong>per</strong> la nuova risorsa, che altrimenti saranno generatiautomaticamente dal sistema.2. Il sistema richiede a LS la creazione di un nuovo PRI 6 (si faccia riferimentoal caso d’uso UC.LS.Int.1).3. Il sistema decide, in base ai parametri forniti dall’utente o generati automaticamente,quante repliche creare <strong>per</strong> la nuova risorsa, ed effettua ilposizionamento delle stesse richiedendone a SI la creazione mediante l’invio<strong>dei</strong> dati e <strong>dei</strong> 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 URLdelle sue repliche e aggiorna, in base ai parametri relativi alle caratteristichedella nuova risorsa, i metadati riguardanti, ad esempio, la politica <strong>per</strong> ilmantenimento della consistenza e/o il numero di repliche esistenti.5. Il sistema restituisce all’utente il PRI della nuova risorsa, se l’o<strong>per</strong>azione è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 distorage sul quale l’istanza di livello RM contattata dall’utente non è autoritativa,la richiesta dovrà essere inoltrata ad un’istanza di pari livelloRM autoritativa su quel servizio (si faccia riferimento al caso d’usoUC.RM.Int.16).Si suppone che ciò avvenga soltanto in seguito alla creazione di almenouna replica su uno <strong>dei</strong> servizi di storage sui quali l’istanza di livello RMcontattata dall’utente è autoritativa, e all’inserimento dell’URL di talereplica in LS. In questo modo si garantisce che esista almeno un URLassociato al PRI della risorsa.Caso d’uso: RM.Int.READID: UC.RM.Int.2Attori: 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’ultimodeve essere inserito nelle prime come metadato. Finché non è stata creata almenoun’associazione tra il PRI e un URL in LS, la risorsa <strong>per</strong>ò non è accessibile.300


Replica Management ServiceInterfacceSequenza degli eventi:1. Il caso d’uso inizia quando l’utente ha la necessità di accedere in lettura aduna risorsa, ed invia al sistema la richiesta insieme al PRI della risorsa.L’utente può inoltre specificare eventuali parametri relativi alla politica diaccesso.2. Il sistema richiede a LS la risoluzione del PRI e le relative informazioni (sifaccia riferimento al caso d’uso UC.LS.Int.2).3. Il sistema effettua la selezione della replica, scegliendo uno tra gli URLrestituiti 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’o<strong>per</strong>azione èavvenuta con successo, oppure un messaggio di errore, in caso contrario.Scenari secondari:• Se la politica di accesso specificata dall’utente lo <strong>per</strong>mette, prima di richiederea LS la risoluzione del PRI il sistema controlla se è in possessodi una copia cache della risorsa.In caso affermativo, ne richiede a SI la lettura, altrimenti procede acontattare LS.• Se il sistema si accorge che la replica con l’URL scelto ha ricevuto l’invalidazionedel 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 contattatadall’utente, la richiesta di lettura deve essere inoltrata all’istanzadi pari livello RM che ne è proprietaria.• Se la politica <strong>per</strong> il mantenimento della consistenza in uso <strong>per</strong> la risorsasegue l’approccio del sito primario, e se la politica di accesso specificatadall’utente lo richiede, deve essere selezionata la replica primaria.• Se la politica <strong>per</strong> il mantenimento della consistenza in uso <strong>per</strong> la risorsasegue l’approccio a votazione, e se la politica di accesso specificata dall’utentelo richiede, deve essere selezionato un numero di repliche tali che lasomma <strong>dei</strong> loro voti sia pari al quorum di lettura.Il sistema chiede a tali repliche di inviare il loro voto e il numero di versioneche possiedono. In seguito, il sistema richiede a SI la lettura di unaqualsiasi tra le repliche con il numero di versione più alto disponibile.Caso d’uso: RM.Int.UPDATEID: UC.RM.Int.3301


Replica Management ServiceInterfacceAttori: 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 scritturaad una risorsa, ed invia al sistema la richiesta insieme al PRI della risorsae 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 (sifaccia 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’o<strong>per</strong>azione èavvenuta con successo, oppure di errore, in caso contrario.6. Il sistema invia l’invalidazione a tutte le istanze di pari livello RM che sonoproprietarie di una replica della risorsa (si faccia riferimento al caso d’usoUC.RM.Int.20).Scenari secondari:• Se la replica selezionata non è di proprietà dell’istanza di livello RM contattatadall’utente, la richiesta di scrittura deve essere inoltrata all’istanzadi pari livello RM che ne è proprietaria.• Se la politica <strong>per</strong> il mantenimento della consistenza in uso <strong>per</strong> la risorsasegue l’approccio del sito primario, deve essere selezionata la replicaprimaria.• Se la politica <strong>per</strong> il mantenimento della consistenza in uso <strong>per</strong> la risorsasegue l’approccio a votazione, deve essere selezionato un numero di replichetali che la somma <strong>dei</strong> loro voti sia pari al quorum di scrittura.Il sistema chiede a tali repliche di inviare il loro voto e in seguito richiedela scrittura di ognuna di esse.Caso d’uso: RM.Int.DELETEID: UC.RM.Int.4Attori: Information History.Precondizioni:302


Replica Management ServiceInterfacce• 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 risorsadi 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 casod’uso UC.LS.Int.2).3. Il sistema richiede a SI l’eliminazione di tutte le repliche con URL restituitoda LS.4. Il sistema richiede a LS l’eliminazione del PRI (si faccia riferimento al casod’uso UC.LS.Int.4).5. Il sistema restituisce all’utente un messaggio di conferma, se l’o<strong>per</strong>azione èavvenuta con successo, oppure di errore, in caso contrario.Scenari secondari:• Se una delle repliche non è di proprietà dell’istanza di livello RM contattatadall’utente, la richiesta di rimozione deve essere inoltrata all’istanzadi pari livello RM che ne è proprietaria.Caso d’uso: RM.Int.PROBEMETAID: UC.RM.Int.5Attori: 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 metadatisono associati ad una risorsa di livello RM, ed invia al sistema larichiesta insieme al PRI della risorsa.L’utente può inoltre specificare eventuali parametri relativi alla politica diaccesso.2. Il sistema esegue la lettura della risorsa con PRI fornito dall’utente (si facciariferimento al caso d’uso UC.RM.Int.2).3. Il sistema restituisce all’utente i nomi <strong>dei</strong> metadati associati alla risorsa, sel’o<strong>per</strong>azione è avvenuta con successo, oppure un messaggio di errore, in casocontrario.303


Replica Management ServiceInterfacceCaso d’uso: RM.Int.READMETAID: UC.RM.Int.6Attori: 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 adun metadato di una risorsa di livello RM, ed invia al sistema la richiestainsieme al PRI della risorsa e al nome del metadato.L’utente può inoltre specificare eventuali parametri relativi alla politica diaccesso.2. Il sistema esegue la lettura della risorsa con PRI fornito dall’utente (si facciariferimento al caso d’uso UC.RM.Int.2).3. Il sistema restituisce all’utente il valore del metadato, se l’o<strong>per</strong>azione èavvenuta con successo, oppure un messaggio di errore, in caso contrario.Caso d’uso: RM.Int.UPDATEMETAID: UC.RM.Int.7Attori: 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 scritturaad un metadato di una risorsa di livello RM, ed invia al sistema la richiestainsieme 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 (sifaccia riferimento al caso d’uso UC.RM.Int.3).3. Il sistema restituisce all’utente un messaggio di conferma, se l’o<strong>per</strong>azione èavvenuta con successo, oppure di errore, in caso contrario.304


Replica Management ServiceInterfacceCaso d’uso: RM.Int.READDATAID: UC.RM.Int.8Attori: 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 aidati di una risorsa di livello RM, ed invia al sistema la richiesta insieme alPRI della risorsa.2. Il sistema esegue la lettura della risorsa con PRI fornito dall’utente (si facciariferimento al caso d’uso UC.RM.Int.2).3. Il sistema restituisce all’utente i dati contenuti nella risorsa, se l’o<strong>per</strong>azioneè avvenuta con successo, oppure un messaggio di errore, in caso contrario.Caso d’uso: RM.Int.UPDATEDATAID: UC.RM.Int.9Attori: 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 scritturaai dati di una risorsa di livello RM, ed invia al sistema la richiesta insiemeal 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 (sifaccia riferimento al caso d’uso UC.RM.Int.3).3. Il sistema restituisce all’utente un messaggio di conferma, se l’o<strong>per</strong>azione èavvenuta con successo, oppure di errore, in caso contrario.305


Replica Management ServiceInterfacceReplica ManagementRM.int.GETPOLICYRM.int.SETPOLICYRM.int.DUPLICATEclientRM.int.CHECKRM.int.LOCKFigura 12.3: Casi d’uso dell’interfaccia esposta da RM: o<strong>per</strong>azioni “Advanced”Caso d’uso: RM.Int.GETPOLICYID: UC.RM.Int.10Attori: 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 allecaratteristiche impostate <strong>per</strong> una risorsa, ed invia al sistema la richiestainsieme al PRI della risorsa.2. Il sistema richiede a LS le informazioni relative al PRI (si faccia riferimentoal caso d’uso UC.LS.Int.2).3. Il sistema restituisce all’utente i parametri che descrivono le caratteristichedella risorsa, se l’o<strong>per</strong>azione ha avuto successo, oppure un messaggio dierrore, in caso contrario.Caso d’uso: RM.Int.SETPOLICY306


Replica Management ServiceInterfacceID: UC.RM.Int.11Attori: 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 scritturaalle caratteristiche impostate <strong>per</strong> una risorsa, ed invia al sistema la richiestainsieme ai relativi parametri e al PRI della risorsa.2. Il sistema aggiorna le informazioni relative al PRI contenute in LS (si facciariferimento 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 <strong>per</strong> il mantenimento della consistenzae/o il numero di repliche esistenti.3. Il sistema restituisce all’utente un messaggio di conferma, se l’o<strong>per</strong>azione èavvenuta con successo, oppure di errore, in caso contrario.Scenari secondari:• Se l’aggiornamento riguarda il numero di repliche esistenti, il sistemapuò innescare il posizionamento richiedendo a SI la creazione o l’eliminazionedi un certo numero di repliche (si faccia riferimento ai casi d’usoUC.RM.Int.16 e UC.RM.Int.17).Caso d’uso: RM.Int.DUPLICATEID: UC.RM.Int.12Attori: 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 risorsadi livello RM con lo stesso contenuto di un’altra risorsa di livello RMesistente, ed invia al sistema la richiesta insieme al PRI di quest’ultima.L’utente può inoltre specificare eventuali parametri relativi alle caratteristichedesiderate <strong>per</strong> la nuova risorsa, che altrimenti saranno generatiautomaticamente dal sistema.307


Replica Management ServiceInterfacce2. Il sistema ottiene i dati e i metadati contenuti nella risorsa identificata dalPRI 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 imetadati 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’o<strong>per</strong>azione èavvenuta con successo, oppure un messaggio di errore, in caso contrario.Caso d’uso: RM.Int.CHECKID: UC.RM.Int.13Attori: 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 richiestainsieme al PRI della risorsa.2. Il sistema esegue la lettura della risorsa con PRI fornito dall’utente (si facciariferimento al caso d’uso UC.RM.Int.2).3. Il sistema verifica la validità <strong>per</strong> ogni tipo a cui la risorsa appartiene.4. Il sistema restituisce all’utente il risultato della validazione, se l’o<strong>per</strong>azioneè avvenuta con successo, oppure di errore, in caso contrario.Caso d’uso: RM.Int.LOCKID: UC.RM.Int.14Attori: Information History.Precondizioni:• Deve essere noto il PRI della risorsa di livello RM.Sequenza degli eventi:308


Replica Management ServiceInterfacce1. Il caso d’uso inizia quando l’utente ha la necessità di bloccare o sbloccarel’accesso ad una risorsa di livello RM, ed invia al sistema la richiesta insiemeal 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’o<strong>per</strong>azione èavvenuta con successo, oppure di errore, in caso contrario.Replica ManagementRM.int.LISTREPLICASRM.int.CREATEREPLICARM.int.DELETEREPLICAclientRM.int.READREPLICARM.int.FORCESYNCFigura 12.4: Casi d’uso dell’interfaccia esposta da RM: o<strong>per</strong>azioni “Admin”Caso d’uso: RM.Int.LISTREPLICASID: UC.RM.Int.15Attori: 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 replichesono associate ad una risorsa di livello RM, ed invia al sistema la richiestainsieme al PRI della risorsa.2. Il sistema richiede a LS la risoluzione del PRI (si faccia riferimento al casod’uso UC.LS.Int.2).309


Replica Management ServiceInterfacce3. Il sistema restituisce all’utente tutti gli URL restituiti da LS, se l’o<strong>per</strong>azioneè avvenuta con successo, oppure un messaggio di errore, in caso contrario.Caso d’uso: RM.Int.CREATEREPLICAID: UC.RM.Int.16Attori: 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 replicaassociata ad una risorsa di livello RM, ed invia al sistema la richiesta insiemeal PRI della risorsa.L’utente può inoltre specificare il servizio di storage sul quale creare lareplica, che altrimenti sarà scelto automaticamente dal sistema.2. Il sistema ottiene i dati e i metadati contenuti nella risorsa identificata dalPRI fornito dall’utente eseguendone la lettura (si faccia riferimento al casod’uso UC.RM.Int.2).3. Il sistema richiede a SI la creazione della replica mediante l’invio <strong>dei</strong> dati e<strong>dei</strong> metadati appena ottenuti.4. Il sistema aggiorna le informazioni relative al PRI fornito dall’utente contenutein 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’URLdella nuova replica e aggiorna i metadati riguardanti, ad esempio, la politica<strong>per</strong> il mantenimento della consistenza e/o il numero di repliche esistenti.5. Il sistema restituisce all’utente un messaggio di conferma, se l’o<strong>per</strong>azione èavvenuta con successo, oppure di errore, in caso contrario.Scenari secondari:• Se la risorsa di cui si intende creare una replica non possiede nessuna URLassociata al PRI in LS, l’o<strong>per</strong>azione restituisce un messaggio di errore.• Se la politica <strong>per</strong> il mantenimento della consistenza in uso <strong>per</strong> la risorsasegue l’approccio a votazione, la creazione di una nuova replica puòinnescare la riassegnazione <strong>dei</strong> voti.310


Replica Management ServiceInterfacceCaso d’uso: RM.Int.DELETEREPLICAID: UC.RM.Int.17Attori: 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 replicaassociata ad una risorsa di livello RM, ed invia al sistema la richiesta insiemeall’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 facciariferimento al caso d’uso UC.LS.Int.3).In particolare, rimuove l’associazione tra l’URL fornito dall’utente e il PRIdella risorsa alla quale la replica è associata e aggiorna i metadati riguardanti,ad esempio, la politica <strong>per</strong> il mantenimento della consistenza e/o ilnumero di repliche esistenti.4. Il sistema restituisce all’utente un messaggio di conferma, se l’o<strong>per</strong>azione èavvenuta con successo, oppure di errore, in caso contrario.Scenari secondari:• Se la politica <strong>per</strong> il mantenimento della consistenza in uso <strong>per</strong> la risorsasegue l’approccio a votazione, la rimozione di una replica può innescarela riassegnazione <strong>dei</strong> voti.Caso d’uso: RM.Int.READREPLICAID: UC.RM.Int.18Attori: Information History.Precondizioni:• Deve essere noto l’URL della replica.Sequenza degli eventi:311


Replica Management ServiceInterfacce1. Il caso d’uso inizia quando l’utente ha la necessità di accedere in letturaad una replica di una risorsa di livello RM, ed invia al sistema la richiestainsieme 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’o<strong>per</strong>azione è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 chene è proprietaria.Caso d’uso: RM.Int.FORCESYNCID: UC.RM.Int.19Attori: 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’ultimaversione disponibile una replica di una risorsa di livello RM, ed invia alsistema 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’o<strong>per</strong>azione èavvenuta con successo, oppure di errore, in caso contrario.Caso d’uso: RM.Int.INVALIDATEID: UC.RM.Int.20Attori: Replica Management.Precondizioni:312


Replica Management ServiceInterfacceReplica ManagementRM.int.INVALIDATEclientRM.int.REQUESTSYNCFigura 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 modificasu una risorsa ha la necessità di comunicare ad un altra replica l’avvenutoaggiornamento, ed invia all’istanza di pari livello RM che la possiede la notificainsieme all’URL della replica.L’istanza che richiede l’o<strong>per</strong>azione può inoltre specificare il PRI della risorsa.2. L’istanza di pari livello RM applica l’invalidazione alla replica con l’URLfornito dall’utente.3. L’istanza di pari livello RM restituisce un messaggio di conferma, se l’o<strong>per</strong>azioneè avvenuta con successo, oppure di errore, in caso contrario.Caso d’uso: RM.Int.REQUESTSYNCID: UC.RM.Int.21Attori: 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 sincronizzareall’ultima versione disponibile una replica di una risorsa di livelloRM, ed invia all’istanza di pari livello RM la richiesta insieme al PRI dellarisorsa e al numero di versione della replica che possiede.2. L’istanza di pari livello RM confronta il numero di versione fornito dall’utentecon quello della replica che possiede.313


Replica Management ServiceInterfacce3. L’istanza di pari livello RM restituisce la differenza tra le versioni del contenutodella risorsa, se possibile, oppure l’intero contenuto, in caso contrario.12.3.2 Interfaccia esposta da Localization ServiceLa definizione dell’interfaccia esposta da Localization Service assume particolareimportanza <strong>per</strong>ché il sistema <strong>dei</strong> nomi gioca un ruolo fondamentale inIDN.In questo caso, l’attore principale (il client) è Replica Management, il qualerichiede l’espletamento di alcuni servizi a Localization Service (il server). Nelladescrizione che segue, quindi, con “sistema” si intende LS, principale soggettodell’interazione.Localization ServiceLS.int.CREATELS.int.READReplicaManagementLS.int.UPDATELS.int.DELETEFigura 12.6: Casi d’uso dell’interfaccia esposta da Localization ServiceNella figura 12.6 è riportato il diagramma <strong>dei</strong> casi d’uso che riassume graficamentele primitive che LS fornisce a RM.Caso d’uso: LS.Int.CREATEID: UC.LS.Int.1Attori: Replica Management.Sequenza degli eventi:1. Il caso d’uso inizia quando l’utente ha la necessità di assegnare un identificatoreunivoco e <strong>per</strong>sistente ad una nuova risorsa di livello RM, ed invia alsistema la richiesta.2. Il sistema genera un nuovo identificatore di tipo PRI.314


Replica Management ServiceInterfacce3. Il sistema restituisce all’utente il nuovo PRI, se l’o<strong>per</strong>azione è avvenuta consuccesso, oppure un messaggio di errore, in caso contrario.Caso d’uso: LS.Int.READID: UC.LS.Int.2Attori: 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 relativoad una risorsa di livello RM negli URL delle sue repliche e/o di accedere inlettura ai metadati associati, ed invia al sistema la richiesta insieme al PRIdella risorsa.2. Il sistema recu<strong>per</strong>a le informazioni relative al PRI fornito dall’utente.3. Il sistema restituisce all’utente gli URL delle repliche della risorsa di livelloRM identificata dal PRI e i metadati associati, se l’o<strong>per</strong>azione è avvenutacon successo, oppure un messaggio di errore, in caso contrario.Caso d’uso: LS.Int.UPDATEID: UC.LS.Int.3Attori: 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 rimuoverel’associazione tra il PRI relativo ad una risorsa di livello RM e gli URL diuna 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


Replica Management ServiceInterfacce2. Il sistema aggiorna le informazioni relative al PRI fornito dall’utente.3. Il sistema restituisce all’utente un messaggio di conferma, se l’o<strong>per</strong>azione èavvenuta con successo, oppure di errore, in caso contrario.Caso d’uso: LS.Int.DELETEID: UC.LS.Int.4Attori: 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 relativoad una risorsa di livello RM, ed invia al sistema la richiesta insieme al PRIdella 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’o<strong>per</strong>azione èavvenuta con successo, oppure di errore, in caso contrario.316


Capitolo13Storage Interface ServiceStorage Interface si presenta come un servizio la cui interfaccia espone o<strong>per</strong>azioni<strong>per</strong> la gestione della memorizzazione <strong>per</strong>sistente di risorse. In questocapitolo sarà fornita la specifica delle o<strong>per</strong>azioni, il modello dati (formalizzatoin WSDL) ed i protocolli <strong>per</strong> la comunicazione.L’interfaccia del servizio scambia messaggi che trasportando informazioni,<strong>per</strong>mettono il trattamento delle risorse definite in questa specifica. Il serviziooffre delle specifiche funzioni <strong>per</strong> poter gestire queste risorse. Una determinatafunzionalità del servizio è realizzata da una o<strong>per</strong>azione. Durante l’esecuzionedi una o<strong>per</strong>azione, avviene lo scambio di messaggi tra consumer e providerdel servizio. I messaggi sono classificati in messaggi di input, output o fault eraggruppati in base alle funzionalità che offrono.Nella prima sezione verrà presentato l’information model della risorsa, l’informationmodel <strong>dei</strong> messaggi e la specifica delle o<strong>per</strong>azioni. Saranno inoltrepresentati i metadati predefiniti, che assolvono a funzioni nate dalla specifica<strong>dei</strong> requisiti.13.1 RequisitiSi riporta la stesura <strong>dei</strong> requisiti del servizio di Storage Interface.Ogni requisito è descritto da:• Codice identificativo• Classificazione del requisito• Testo del requisito• Eventuale descrizione in italiano


Storage Interface ServiceRequisitiOgni requisito ha un codice identificativo del tipo RXXX dove alle X si sostituisceun codice numerico di 3 cifre. Il codice è assegnato al requisito progressivamentein ordine cronologico. I codici <strong>dei</strong> requisiti rifiutati non sono statiriutilizzati, rendendo in questo modo univoca l’identificazione di ogni requisito.La descrizione è da considerarsi normativa la dove ambiguità possano insorgerenell’interpretazione del requisito.Requirement R001– Functional RequirementSI MUST manage Resources made of Data and MetadataLa funzionalità principale di SI è definita da questo requisito: il Storage Interfacedeve <strong>per</strong>mettere di utilizzare risorse composte da un dato, e di poter gestire <strong>dei</strong>metadati che sono associati a questi dati.Requirement R002– Functional RequirementSI MUST provide a Service for managing resourcesQuesto requisito specifica che SI deve essere un Servizio e che deve offrirefunzionalità di gestione di Risorse.Requirement R003– Functional RequirementSI MUST provide CRUD functionality on ResourcesIl servizio deve offrire le quattro funzionalità dello storage <strong>per</strong>sistente:• Create. Crea una nuova risorsa di livello SI nel servizio di storage a cuisono inviati i dati e i metadati che andranno a costituirla.• Read. Restituisce al consumer un messaggio che contiene i dati e i metadatidella risorsa di livello SI specificata.• Update. Modifica la risorsa di livello SI specificata attuando la memorizzazione<strong>dei</strong> 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 ConstraintThe Service MUST be globally addressable318


Storage Interface ServiceRequisitiIl servizio deve avere un nome che ne specifica il punto di accesso, in altre paroleil suo endpointRequirement R005– Functional RequirementA Resource MUST be identified and addressedQuindi una risorsa deve avere un nome che ne specifica il punto di accesso edidentità.Requirement R006– Standard ComplianceA Resource MUST be identified and addressed using URLsSi richiede che adottati Uniform Resource Locator (URL) come sistema di nomi<strong>per</strong> identificare ed indirizzare le risorse.Requirement R008– Design ConstraintSI’s interface MUST be abstractL’interfaccia definita dalla specifica di SI deve essere astratta, ovvero si richiedeche le o<strong>per</strong>azioni ed i messaggi siano descritti senza riferimenti a protocolli olinguaggi di programmazione specifici.Requirement R009– Design ConstraintSI’s interface MUST be RESTfulL’interfaccia deve essere progettata secondo lo stile <strong>dei</strong> sistemi REST[Fie00].Requirement R010– Functional RequirementSI SHOULD be implemented as a ROARequirement R011– PortabilitySI MAY support other protocol than HTTP319


Storage Interface ServiceRequisitiVisto che l’interfaccia di SI deve essere astratta, è possibile pensare ad una suaimplementazione basata su altri protocolli di trasporto <strong>per</strong> fini di flessibilità.Requirement R012– PortabilitySI MAY be implemented using other architectural solutionRequirement R013– Design ConstraintSI’s MUST be implementable using different programming languagesRequirement R015– SecuritySI MUST handle access control on ResourcesL’interfaccia deve quindi essere progettata seguendo criteri che <strong>per</strong>mettano dicontrollare l’accesso di una risorsa, e <strong>per</strong>tanto le o<strong>per</strong>azione devono prevedere iltrasporto di credenziali <strong>per</strong> l’autorizzazione di accesso ad una risorsa, <strong>per</strong> unadeterminata entità, svolgendo una determinata o<strong>per</strong>azione.Requirement R016– SecuritySI MUST support different authentication/authorization/audit systemsDeve essere possibile <strong>per</strong> 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 basandosisulle entità in gioco quali: detentore <strong>dei</strong> diritti sulla risorsa, richiedentedell’o<strong>per</strong>azione di accesso, sistema di accesso e lo stesso servizio di StorageInterface.Requirement R021– Functional RequirementSI MUST support notification messages to designed recipients in result ofevents generated by o<strong>per</strong>ations on ResourcesIn particolare si richiede che l’interfaccia definita abbia il supporto <strong>per</strong> la comunicazionedi notifiche ad entità autorizzate qualora un evento su una risorsadebba essere tracciato, <strong>per</strong> fini di manutenzione o altri scopi.320


Storage Interface ServiceRequisitiRequirement R022– Functional RequirementSI MAY support notification messages to designed recipients in result ofgeneric eventsMessaggi di notifica possono originare da eventi non conseguenti ad o<strong>per</strong>azionisu risorse, ad esempio eventi pianificati.Requirement R023– Design ConstraintSI MUST be able to expose the Data from Legacy Sources as ResourcesIl servizio deve essere progettato applicando tutti quei criteri che possono semplificarel’adattamento a sistemi di storage pre-esistenti.Requirement R024– Functional RequirementSI MAY validate the stored Resources and Resources after creation or updateor an explicit requestIl servizio può offrire funzionalità di validazione delle risorse, ovvero deve esserepossibile l’uso di procedure generiche che restituiscano informazioni su una risorsa.In particolare possono essere previsti meccanismi di validazione di risorsememorizzate, di risorse <strong>nuove</strong> durante la loro creazione o di risorse modificatedurante l’o<strong>per</strong>azione di aggiornamento.Requirement R025– Standard ComplianceSI SHOULD use WSDL for the definition of the Abstract InterfacePer offrire una migliore intero<strong>per</strong>abilità, se possibile, dovrebbe essere offerta unadescrizione dell’interfaccia astratta di SI tramite le specifiche di WSDL.Requirement R036– Standard ComplianceSI MAY use WSDL for the describing Interface implementationsLe implementazioni dell’interfaccia di SI potrebbero essere descritte con WSDLgrazie alle sue estensioni <strong>per</strong> HTTP e SOAP. In particolare potrebbe essere utiledefinire una nuova estensione di WSDL <strong>per</strong> descrivere interfacce che usano altriprotocolli, ad esempio TCP.321


Storage Interface ServiceRequisitiRequirement R026– Standard ComplianceResources SHOULD be compatible with RDF information modelIl modello con cui RDF descrive i metadati dovrebbe essere compatibile con imetadati di SI in modo da poter offrire tramite RDF i metadati associati ai datidi una risorsa.Requirement R027– Standard ComplianceResources SHOULD be compatible with RDF Schema type systemDovrebbe poter essere possibile usare RDF Schema <strong>per</strong> definire le classi a cuiuna risorsa appartiene.Requirement R028– Functional RequirementSI MAY support specific o<strong>per</strong>ations for management or for <strong>per</strong>formanceimprovementsSi possono definire altre o<strong>per</strong>azioni sulle risorse, ad esempio <strong>per</strong> la creazione diduplicati, o <strong>per</strong> recu<strong>per</strong>are l’elenco di risorse presenti in un determinato storage.Requirement R037– Functional RequirementO<strong>per</strong>ations different from the basic CRUD MUST be optional in specificimplementationsPer implementare un servizio di Storage Interface deve essere sufficiente supportarele quattro o<strong>per</strong>azioni di creazione, lettura, modifica e cancellazione, quindiogni requisito funzionale obbligatorio deve essere offerto attraverso questequattro o<strong>per</strong>azioni.Requirement R029– Functional RequirementSI MAY allow Locking and Unlocking of ResourcesSi possono definire o<strong>per</strong>azioni che <strong>per</strong>mettono di bloccare l’accesso alle risorsedurante la loro modifica.322


Storage Interface ServiceRequisitiRequirement R030– Standard ComplianceSI MUST allow XML representation of ResourcesRequirement R031– Design ConstraintSI MUST support synchronous and asynchronous interactionLe specifiche dell’interfaccia non devono impedire la possibilità di implementazionicon un meccanismo asincrono.Requirement R033– Functional RequirementSI MUST support arbitrary Metadata on resourcesDeve essere possibile memorizzare <strong>per</strong> una determinata risorsa, metadati di tiposconosciuto.Requirement R034– Functional RequirementMetadata SHOULD be univocally identified by a qualified nameOgni metadato in una risorsa deve avere un nome che lo identifica e questonome deve avere validità globale <strong>per</strong>chè ad esempio appartiene ad un namespacedefinito con URI.Requirement R035– Functional RequirementMetadata value SHOULD have a type defined by the qualified nameIl nome specificato <strong>per</strong> la risorsa implica che il valore del metadato abbia untipo la cui sintassi e semantica siano individuati dal nome e namespace a cuiesso appartiene. Un meccanismo di validazione può ad esempio curarsi dellaverifica che questi valori siano conformi.Requirement R036– Functional RequirementData and Metadata MUST be hierarchically subordinated to the resourceI dati ed i metadati sono contenuti nella risorsa e ne sono figli.323


Storage Interface ServiceInterfacciaRequirement R037– Functional RequirementSI MUST allow direct access to MetadataDeve essere possibile ottenere il valore di un metadato tramite indirizzamentodiretto, ad esempio combinando il nome del metadato con l’URL della risorsa.13.2 InterfacciaLe o<strong>per</strong>azioni ed i messaggi dell’interfaccia sono formulati sulla base <strong>dei</strong>requisiti R002, R003, R009, R015, R016, R021, R022, R024, R028, R029 edR037.Le o<strong>per</strong>azioni sono raggruppate in cinque gruppi:• CRUD: si compone delle quattro o<strong>per</strong>azioni <strong>dei</strong> sistemi di memorizzazione<strong>per</strong>sistente, e <strong>per</strong>mette di o<strong>per</strong>are sul servizio creando, leggendo,modificando e cancellando le risorse. Il requisito R003 è l’origine di questogruppo.• Plus: si compone di tre o<strong>per</strong>azioni che forniscono o<strong>per</strong>azioni ausiliarie <strong>per</strong>la gestione di risorse, quali la duplicazione diretta, l’elenco delle risorsedi un servizio e l’elenco <strong>dei</strong> nomi <strong>dei</strong> metadati di una specifica risorsa.Questo gruppo non nasce da requisiti specifici, ma è <strong>per</strong>messo da R028.Le funzionalità sono state dedotte da considerazioni di carattere praticoemerse nell’analisi degli scenari.• Specialized: si compone di quattro o<strong>per</strong>azioni <strong>per</strong> la lettura e la modificadiretta <strong>dei</strong> dati e <strong>dei</strong> metadati. Le o<strong>per</strong>azioni sui metadati sono conseguenzadel requisito R037, le o<strong>per</strong>azioni sui dati nascono da considerazionipratiche e sono <strong>per</strong>messe dal requisito R028.• Functional: si compone di tre o<strong>per</strong>azioni che offrono funzioni atte a soddisfarerequisiti opzionali del servizio. La funzionalità di Locking è offertasulla base del requisito R029, la funzionalità di validazione sulla base diR024. La funzionalità di verifica di condizione nasce da considerazionipratiche ed è <strong>per</strong>messa da R028• Event: Sulla base <strong>dei</strong> requisiti R021 ed R022, si offrono le funzionalità digestione di sottoscrizione e di notifica di eventi.Durante le chiamate di o<strong>per</strong>azioni si ha uno scambio di messaggi tra le entitàin gioco. Un messaggio è essenzialmente una informazione che viene trasmessaal provider (messaggio di input) o dal provider (messaggio di output). Alcunimessaggi trasportano informazioni, altri segnalano errori (messaggi di fault). Laprincipale tipologia di messaggi è quella che contiene dati o metadati di SI-R, adesempio il messaggio di output di una o<strong>per</strong>azione di lettura oppure il messaggiodi input di una o<strong>per</strong>azione di modifica.324


Storage Interface ServiceInterfaccia13.2.1 Messaggi di input, output, fault e generalitàI messaggi delle o<strong>per</strong>azioni sul servizio sono classificati in messaggi di input,messaggi di output o messaggi di fault. Questa classificazione segue il punto divista del provider del servizio, <strong>per</strong> il quale un messaggio di input è un messaggioche 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<strong>per</strong> comunicare un qualche inconveniente avvenuto durante la chiamata di unao<strong>per</strong>azione, e in questi casi si sostituiscono al messaggio di risposta.Sulla base <strong>dei</strong> requisiti e su considerazioni pratiche, i messaggi di input presentanodelle caratteristiche comuni <strong>per</strong> ogni o<strong>per</strong>azione. Il requisito R015 edR016 richiedono che le informazioni di autenticazione siano trasmesse insiemead un messaggio di input. Considerazioni pratiche derivate dallo studio degliscenari hanno suggerito di aggiungere informazioni di controllo che <strong>per</strong>mettonoil management ed il debug del servizio.Per questo, un messaggio di input trasporta opzionalmente:• Informazioni di autenticazione che <strong>per</strong>mettono l’attuazione del controllodegli accessi.• Informazioni sull’agente utilizzato dal consumer, in modo da identificarespecifici problemi applicativi o di compatibilità tra implementazioni diservizi e implementazioni di client.• Informazioni sull’origine del messaggio di input, in modo da ottimizzare le<strong>per</strong>formance di memorizzazione e la tracciabilità delle risorse memorizzate.• Informazioni <strong>per</strong> tracciare i messaggi, ad esempio in cui si è formulatol’invio o una chiave univoca del messaggio.Le informazioni <strong>per</strong> la tracciabilità sono trasportate anche nei messaggi dioutput.In figura 13.1 è rappresentato il modello <strong>dei</strong> messaggi su cui ogni input edoutput si basa.0..1authinput0..1agentoutput0..1trace0..1origin0..1traceFigura 13.1: Information Model <strong>dei</strong> messaggi di input e di outputSi definiscono sei messaggi di tipo fault:325


Storage Interface ServiceInterfaccia• Generic fault: descrive un errore generico <strong>per</strong> il quale non si è potutorispondere ad una richiesta (ad esempio <strong>per</strong> via di un timeout)• Condition fault: è fallita la verifica di una condizione specificata dallarichiesta• Unsupported fault: la richiesta ha chiamato una qualche funzionalità nonsupportata dalla specifica implementazione del servizio• Unauthorized fault: la richiesta ha fallito la verifica delle autorizzazioninecessarie al suo espletamento• Internal Error: si è verificato un errore interno al servizio e la richiestanon può essere portata a termine• Input Error: il messaggio di input non è valido e la richiesta non può essereportata a terminegenericunsupportedinternalErrorconditionunauthorizedinputErrorFigura 13.2: Tipi di messaggi di faultAlcuni messaggi di input specificano una query sui dati, una query sui metadatio una condizione. Le query sono delle informazioni testuali passate alservizio, il cui effetto è la restituzione di dati o di metadati in genere differentida quelli esattamente memorizzati nella risorsa. L’interpretazione delle query el’azione da intraprendere dipendono dalla implementazione del servizio. I datie i metadati trasformati sono restituiti con informazioni che dichiarano la trasformazioneche è stata effettuata. Ad esempio, un servizio può implementarel’accesso parziale ai dati di SI-R grazie alle query, e i dati restituiti sarannoaccompagnati da informazioni che descrivono il range di dati restituito.Le condizioni pongono un vincolo sull’espletamento della chiamata all’o<strong>per</strong>azione.I servizi che supportano le condizioni, dovranno portare avanti il processoinnescato dall’o<strong>per</strong>azione 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 serviziopotrà rispondere con un messaggio di errore di tipo unsupported fault a chiamatedi o<strong>per</strong>azioni che contengono condizioni o query.Ogni o<strong>per</strong>azione è condizionata alle autorizzazioni in possesso al chiamante.Nella descrizione delle o<strong>per</strong>azioni seguenti, è sempre possibile che in caso didiritti insufficienti sia inviato un messaggio di errore di tipo unauthorized fault.326


Storage Interface ServiceInterfaccia13.2.2 O<strong>per</strong>azioni base dello storage <strong>per</strong>sistenteL’o<strong>per</strong>azione Create si usa <strong>per</strong> creare una nuova risorsa. La chiamata daorigine alla seguente interazione:• In Input, è opzionale l’invio <strong>dei</strong> dati della risorsa e di zero o più metadati.• La chiamata causa la creazione di una nuova risorsa nel servizio di storageche contiene una copia <strong>dei</strong> dati e <strong>dei</strong> metadati inviati.• In output, viene restituito l’identificatore della nuova risorsa.L’o<strong>per</strong>azione Read si usa <strong>per</strong> leggere una risorsa memorizzata. La chiamata daorigine alla seguente interazione:• In Input, si invia l’identificatore della risorsa di cui si vuole leggere datie metadati. Sono supportati query su dati, metadati e condizioni diesecuzione.• L’o<strong>per</strong>azione è safe, ovvero la chiamata non è causa di azioni che modificanolo stato della risorsa.• In output, viene restituito un messaggio che contiene i dati ed i metadatidella risorsa.L’o<strong>per</strong>azione Update si usa <strong>per</strong> 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, insiemeai dati ed ai metadati, così come li si vuole memorizzare. È supportatal’esecuzione sottoposta a condizione.• La chiamata causa la memorizzazione <strong>dei</strong> dati e <strong>dei</strong> metadati ricevuti nellarisorsa specificata dall’identificatore. Il non invio <strong>dei</strong> dati, o il non invio <strong>dei</strong>metadati non comporta la loro cancellazione. L’o<strong>per</strong>azione è idempotente,ovvero il risultato non cambia ripetendo più volte la chiamata con gli stessiparametri di input.• In output, in caso l’esecuzione proceda regolarmente, viene restituito unmessaggio senza nessuna ulteriore informazione. Un errore comporta l’inviodi un messaggio di fault appropriato.L’o<strong>per</strong>azione Delete rimuove una risorsa dal servizio. La chiamata da originealla 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’identificatoree quindi l’URL della risorsa non sono più validi, e una successivarichiesta sulla risorsa fornirà un errore. L’o<strong>per</strong>azione è idempotente, ovveroil risultato non cambia ripetendo più volte la chiamata con gli stessiparametri di input.327


Storage Interface ServiceInterfaccia• In output, in caso l’esecuzione proceda regolarmente, viene restituito unmessaggio senza nessuna ulteriore informazione. Un errore comporta l’inviodi un messaggio di fault appropriato.In figura 13.3 è riportato lo schema del modello di queste o<strong>per</strong>azioni insieme aimessaggi scambiati.CreatecreateInInput messages0..*0..1namemetadatamime?encoding?Output messagescreateOut1resIdReadreadIn10..10..*0..1resIdqueryDataqueryMetaconditionreadOut0..*0..1namepath?metadatamime?encoding?range?unit?Update1resIdupdateIn0..*0..10..1namepath?metadatamime?encoding?range?unit?conditionupdateOutDeletedeleteIn10..1resIdconditiondeleteOutFigura 13.3: Information Model <strong>dei</strong> messaggi e delle o<strong>per</strong>azioni base <strong>per</strong> lamemorizzazione <strong>per</strong>sistente13.2.3 O<strong>per</strong>azioni <strong>per</strong> funzionalità di <strong>per</strong>formanceL’o<strong>per</strong>azione Duplicate crea un duplicato di una risorsa specificata.chiamata da origine alla seguente interazione:La328


Storage Interface ServiceInterfaccia• 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 dellarisorsa di cui si è passato l’identificatore in input.• In output, viene restituito l’identificatore della nuova risorsa.L’o<strong>per</strong>azione List fornisce un elenco degli identificatori delle risorse presenti nelservizio. La chiamata da origine alla seguente interazione:• Non ci sono parametri richiesti in input oltre a quelli comuni a tutti imessaggi (autorizzazione, traccia, etc.).• L’o<strong>per</strong>azione è safe, ovvero la chiamata non è causa di azioni che modificanolo stato della risorsa.• In output, viene restituito l’elenco degli identificatori delle risorse memorizzatenel servizio.L’o<strong>per</strong>azione ProbeMeta fornisce l’elenco <strong>dei</strong> nomi <strong>dei</strong> metadati che sono statiassociati ad una risorsa. La chiamata da origine alla seguente interazione:• In Input, si invia l’identificatore della risorsa che si desidera duplicare.• L’o<strong>per</strong>azione è safe, ovvero la chiamata non è causa di azioni che modificanolo stato della risorsa.• In output, viene restituito l’elenco <strong>dei</strong> nomi <strong>dei</strong> metadati memorizzati nellarisorsa.In figura 13.4 è riportato lo schema del modello di queste o<strong>per</strong>azioni insieme aimessaggi scambiati.13.2.4 O<strong>per</strong>azioni specializzate <strong>per</strong> dati e metadatiL’o<strong>per</strong>azione ReadData recu<strong>per</strong>a soltanto il dato della risorsa. La chiamatada 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’o<strong>per</strong>azione è safe, ovvero la chiamata non è causa di azioni che modificanolo stato della risorsa.• In output, viene restituito un messaggio che contiene i dati della risorsa.L’o<strong>per</strong>azione ReadMeta fornisce la lettura di un singolo metadato associato allarisorsa. La chiamata da origine alla seguente interazione:• In Input, si invia l’identificatore della risorsa ed il nome del metadatoche si vuole leggere. Sono supportati query su metadati e condizioni diesecuzione.329


Storage Interface ServiceInterfacciaInput messagesDuplicateduplicateIn1resId0..1conditionOutput messagesduplicateOut 1resIdListlistIn listOut 0..*resIdProbeMetaprobeMetaIn1resIdprobeMetaOut0..*metaNameFigura 13.4: Information model <strong>dei</strong> messaggi e delle o<strong>per</strong>azioni <strong>per</strong> funzionalitàduplicazione, lista di risorse e lista di metadati• L’o<strong>per</strong>azione è safe, ovvero la chiamata non è causa di azioni che modificanolo stato della risorsa.• In output, viene restituito un messaggio che contiene il metadato richiesto.L’o<strong>per</strong>azione UpdateData <strong>per</strong>mette la modifica <strong>dei</strong> soli dati della risorsa. Lachiamata da origine alla seguente interazione:• In Input, si invia l’identificatore della risorsa che si vuole modificare, insiemeai dati, così come li si vuole memorizzare. È supportata l’esecuzionesottoposta a condizione.• La chiamata causa la memorizzazione <strong>dei</strong> dati ricevuti nella risorsa specificatadall’identificatore. L’o<strong>per</strong>azione è idempotente, ovvero il risultatonon cambia ripetendo più volte la chiamata con gli stessi parametri diinput.• In output, in caso l’esecuzione proceda regolarmente, viene restituito unmessaggio senza nessuna ulteriore informazione. Un errore comporta l’inviodi un messaggio di fault appropriato.L’o<strong>per</strong>azione UpdateMeta <strong>per</strong>mette la modifica di un singolo metadato associatoalla risorsa. La chiamata da origine alla seguente interazione:• In Input, si invia l’identificatore della risorsa e il nome del metadato chesi vuole modificare, insieme al valore del metadato così come lo si vuolememorizzare. È supportata l’esecuzione sottoposta a condizione.• La chiamata causa la memorizzazione del metadato ricevuto nella risorsaspecificata dall’identificatore. L’o<strong>per</strong>azione è idempotente, ovvero il risultatonon cambia ripetendo più volte la chiamata con gli stessi parametridi input.330


Storage Interface ServiceInterfaccia• In output, in caso l’esecuzione proceda regolarmente, viene restituito unmessaggio senza nessuna ulteriore informazione. Un errore comporta l’inviodi un messaggio di fault appropriato.In figura 13.5 è riportato lo schema del modello di queste o<strong>per</strong>azioni insieme aimessaggi scambiati.Input messagesReadData1resId0..1readDataIn queryData0..1conditionOutput messagesreaddataOut0..1datamime?encoding?range?unit?ReadMetareadMetaIn1resId0metaName0..1queryMeta0..1conditionreadMetaOut0..1namepath?metaUpdateDataupdateDataInUpdateMetaupdateMetaIn110..11110..1resIddatamime?encoding?range?unit?conditionpath?resIdmetaNamemetaconditionupdateDataOutupdateMetaOutFigura 13.5: Information model <strong>dei</strong> messaggi e delle o<strong>per</strong>azioni dimemorizzazione di singoli dati o singoli metadati13.2.5 O<strong>per</strong>azioni <strong>per</strong> funzionalità specificheL’o<strong>per</strong>azione Lock previene la scrittura o la lettura di una risorsa.chiamata da origine alla seguente interazione:La331


Storage Interface ServiceInterfaccia• In Input, si inviano l’identificatore della risorsa e le informazioni sul lockda applicare. È supportata l’esecuzione sottoposta a condizione.• La chiamata causa l’assegnazione o la rimozione di un lock alla risorsa.Una successiva o<strong>per</strong>azione sulla stessa risorsa, è sottoposta alla verificadella condizione di locking. L’o<strong>per</strong>azione è idempotente, ovvero il risultatonon cambia ripetendo più volte la chiamata con gli stessi parametri diinput.• In output, in caso l’esecuzione proceda regolarmente, viene restituito unmessaggio senza nessuna ulteriore informazione. Un errore comporta l’inviodi un messaggio di fault appropriato.L’o<strong>per</strong>azione Verify <strong>per</strong>mette la verifica di una condizione su una risorsa. Lachiamata da origine alla seguente interazione:• In Input, è inviato l’identificatore della risorsa e la condizione.• L’o<strong>per</strong>azione è safe, ovvero la chiamata non è causa di azioni che modificanolo stato della risorsa.• In output, il risultato un booleano che specifica l’esito della verifica dellacondizione.L’o<strong>per</strong>azione Validate restituisce informazioni sulla conformità della risorsa sullabase <strong>dei</strong> tipi <strong>per</strong> cui è stata definita. La chiamata da origine alla seguenteinterazione:• In Input, è inviato l’identificatore della risorsa.• L’o<strong>per</strong>azione è safe, ovvero la chiamata non è causa di azioni che modificanolo stato della risorsa.• In output, viene restituito un elenco di associazioni tra tipo e risultatodella validazione. Per ogni tipo a cui la risorsa appartiene è verificata lavalidità.In figura 13.6 è riportato lo schema del modello di queste o<strong>per</strong>azioni insieme aimessaggi scambiati.13.2.6 O<strong>per</strong>azioni <strong>per</strong> la gestione degli eventiL’o<strong>per</strong>azione Subscrive specifica l’intenzione di sottoscrivere a notifiche dieventi 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 intendesottoscrivere, congiuntamente al punto di accesso a cui inviare le notifichequalora disponibile.• La chiamata causa l’iscrizione (o la sua revoca) alla lista <strong>dei</strong> destinataridi notifiche in seguito ad eventi <strong>per</strong> la risorsa specificata. L’o<strong>per</strong>azioneè idempotente, ovvero il risultato non cambia ripetendo più volte lachiamata con gli stessi parametri di input.332


Storage Interface ServiceInterfacciaInput messagesLocklockIn1resId1lockInfo0..1conditionOutput messageslockOutVerifyverifyIn11resIdconditionverifyOut1resultValidatevalidateIn1resIdvalidateOut0..*validityty<strong>per</strong>esultFigura 13.6: Information model <strong>dei</strong> messaggi e delle o<strong>per</strong>azioni <strong>per</strong> funzionalitàdi locking e validazione• In output, in caso l’esecuzione proceda regolarmente, viene restituito unmessaggio senza nessuna ulteriore informazione. Un errore comporta l’inviodi un messaggio di fault appropriato.L’o<strong>per</strong>azione Poll restituisce l’elenco di risorse sulla quale si è verificato unevento a cui il consumer si è sottoscritto. La verifica dell’identità del consumeravviene tramite l’invio delle informazioni di autenticazione. Il servizio può usarequesto meccanismo <strong>per</strong> notificare eventi qualora il consumer non abbia unproprio endpoint al quale inviare messaggi. Questo meccanismo è alternativoall’invio diretto di notifiche, qualora un consumer abbia un punto di accesso.Nel prossimo paragrafo sarà trattato questo aspetto più dettagliatamente. Lachiamata da origine alla seguente interazione:• Non ci sono parametri richiesti in input oltre a quelli comuni a tutti imessaggi (autorizzazione, traccia, etc.).• L’o<strong>per</strong>azione è safe, ovvero la chiamata non è causa di azioni che modificanolo stato della risorsa.• In output, è restituita la lista degli eventi a cui l’identità autenticata risultasottoscritta.In figura 13.7 è riportato lo schema del modello di queste o<strong>per</strong>azioni insieme aimessaggi scambiati.333


Storage Interface ServiceStorage Interface Data ModelInput messagesSubscribe1subscribeInresId0..1subscriber1eventNameOutput messagessubscribeOutPollnotifyInnotifyOut0..*eventresIdeventNametime?Figura 13.7: Information model <strong>dei</strong> messaggi e delle o<strong>per</strong>azioni a supporto dellanotifica di eventi13.2.7 Interfaccia delle notificheI requisiti R021 e R022 specificano che Storage Interface deve supportare lanotifica di eventi tramite messaggi a destinatari designati. L’o<strong>per</strong>azione Notifyè quindi un’o<strong>per</strong>azione che dal punto di vista del provider, trasmette un messaggiooutput, poiché è dal servizio che è avviata la chiamata. Le specifichedi Storage Interface definiscono l’interfaccia delle notifiche un punto di accessoimplementato sul consumer che <strong>per</strong>mette l’invio di messaggi di tipo notifyOutin conseguenza di eventi.Tuttavia l’invio di un messaggio prevede che il destinatario fornisca un puntodi 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 utilizzarel’o<strong>per</strong>azione di polling descritta nell’ultimo paragrafo della precedente sezione.L’o<strong>per</strong>azione Notify invia un messaggio unico col quale si informa un eventoavvenuto su una risorsa. L’interazione di una o<strong>per</strong>azione di notifica è la seguente:• Un evento su una risorsa <strong>per</strong> il quale esista una entità sottoscritta conpunto di accesso causa l’emissione del messaggio di notifica.• In output, è inviata una lista di uno o più eventi che sono avvenuti ed aiquali il destinatario risulta sottoscritto.In figura 13.8 è riportato lo schema del modello di questa o<strong>per</strong>azione e delmessaggio. Si noti che si tratta dello stesso messaggio di output visto nellao<strong>per</strong>azione di Poll.13.3 Storage Interface Data ModelNei paragrafi di questa sezione saranno riportate le specifiche e le proprietà<strong>dei</strong> modelli informativi <strong>per</strong> le risorse e <strong>per</strong> i messaggi. Le scelte si fondano sullaspecifica <strong>dei</strong> requisiti esposti e sullo studio casi applicativi.334


Storage Interface ServiceStorage Interface Data ModelOutput messagesNotifynotifyOut1..*eventresIdeventNametime?Figura 13.8: Interfaccia <strong>per</strong> le notifichePer i modelli presentati saranno richiamati, ed eventualmente discussi, irequisiti 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 <strong>dei</strong> requisiti R001, R005, R006, R026, R027, R033, R034, R035,R036 e R037, sono state formulate le seguenti proprietà <strong>per</strong> il modello dellarisorsa:• SI-R contiene dati e metadati, ovvero informazioni in formato adatto aglielaboratori e ulteriori informazioni che forniscono una descrizione <strong>dei</strong> dati.• La risorsa è una rappresentazione <strong>dei</strong> dati che essa contiene. I metadatisono proprietà di questa rappresentazione.• Ogni risorsa ha un identificatore, che lo identifica univocamente sul serviziodi storage su cui è mantenuta.• L’identificatore, composto con l’indirizzo del servizio, fornisce un URL che<strong>per</strong>mette l’accesso alla risorsa• Tra servizi di storage differenti, si usano gli URL <strong>per</strong> indirizzare e identificareglobalmente le risorse in modo univoco• Ogni metadato ha un nome ed è usato <strong>per</strong> associare una proprietà ad unarisorsa• Il nome identifica il metadato nell’ambito della risorsa, quindi <strong>per</strong> ognirisorsa può esistere un solo metadato con quel nome• Il nome di un metadato identifica universalmente il suo tipo e la suasemantica.• Il nome di un metadato è un URI ed è possibile adottare il meccanismo<strong>dei</strong> Namespace XML <strong>per</strong> l’identificazione del nome tramite prefisso• Il valore di un metadato è indirizzato dalla combinazione dell’URL dellarisorsa e del nome del metadato.Il disegno in figura 13.9 rappresenta la struttura della risorsa.335


Storage Interface ServiceStorage Interface Data ModelSI-Resource-ModelresIdserviceEndPoint0..*0..1resId?namereadonly?resId?mime?encoding?readonly?metadataFigura 13.9: Information Model di SI-RIl requisito R030 richiede che l’information model utilizzato <strong>per</strong> le risorse ei messaggi di Storage Interface, illustrato in sezione 13.1, possa essere rappresentatocon XML. Tuttavia i requisiti R025 e R036 raccomandano l’impiego diWSDL <strong>per</strong> descrivere l’interfaccia del servizio e poichè WSDL si basa su tipi didati 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 scambiatidall’interfaccia• idn-storage-interface-ext.xsd, sono formalizzati i metadati predefiniti diSI-RQuesti file saranno direttamente importati nei documenti WSDL che definisconoil servizio, ed in particolare gli stessi file .xsd sono riutilizzabili <strong>per</strong>le interfacce descritte con WSDL 2.0 o WSDL 1.1. Tali documenti sarannobrevemente illustrati in questa sezione ed a seguire integralmente riportati.13.3.1 MessaggiIl documento idn-storage-interface.xsd definisce la sintassi XML <strong>dei</strong> messaggidell’interfaccia e dichiara i tipi fondamentali su cui essa si basa <strong>per</strong> il funzionamento.I messaggi sono rappresentati con elementi (xsd:element) ed i tipisono sia xsd:complexType che xsd:simpleType. Inoltre è definito come elementolo schema di SI-R: . I tipi più importantisono quelli che rappresentano gli elementi fondamentali che compongonoSI-R e i tipi base da cui derivano i messaggi.• : rappresenta l’identifier delle risorse, edè derivato da xsd:anyURI (si ricorda che SI-R è identificata da URL).• : rappresenta il nucleo dell’informazionedi una risorsa. Si tratta di un elemento che contiene una sequenzadi caratteri, byte o XML.336


Storage Interface ServiceStorage Interface Data Model• : rappresenta una informazione chedescrive la risorsa. In XML un metadato ha obbligatoriamente un attributodi nome name che definisce il nome del metadato e ne identifica ilsuo tipo grazie ad un URI.Tutti i messaggi derivano dai seguenti tipi base:• • • La sintassi <strong>dei</strong> messaggi è formalizzata da istanze di elementi. Per ogni tipodi messaggio esiste un elemento che lo rappresenta in XML. Alcuni esempi sono:• rappresenta un messaggio di input dell’o<strong>per</strong>azionedi creazione.• rappresenta un messaggio di input dell’o<strong>per</strong>azionedi lettura.• rappresenta un messaggio di output dell’o<strong>per</strong>azionedi lettura.• rappresenta un messaggio di notifica inviatodal servizio.• rappresenta un messaggio di erroreche viene trasmesso qualora l’o<strong>per</strong>azione richiesta non possa essereportata a termine <strong>per</strong> diritti insufficienti.Il targetNamespace di questo schema è l’indirizzohttp://www.interdatanet.org/ns/StorageInterface, al quale è associato il prefissolocale idnsi.Nel seguente listato è riportato l’inizio del documento, nel quale si può vederel’elemento radice della definizione dello schema con gli attributi che contiene:337


Storage Interface ServiceStorage Interface Data Model13.3.2 Tipi predefinitiIl documento idn-storage-interface-ext.xsd definisce la sintassi XML <strong>dei</strong> metadatipredefiniti di una SI-R. Questi estensione di idnsi:meta, definito dal documentovisto nel precedente paragrafo, e rappresentano i metadati <strong>per</strong> il tipodella risorsa, i namespace utilizzati, lo stato del lock. Si indicano con:• idnsix:types• idnsix:lock• idnsix:namespacesI nomi estesi con l’URI espresso completamente sono i seguenti.• http://www.interdatanet.org/ns/StorageInterface/ext#types• http://www.interdatanet.org/ns/StorageInterface/ext#lock• http://www.interdatanet.org/ns/StorageInterface/ext#namespacesUn metadato di una SI-R il cui nome corrisponde ad uno <strong>dei</strong> tre visti qui sopra,deve rispettare la sintassi del tipo. Il seguente esempio mostra un metadatodi una SI-R che memorizza informazioni sul locking.Cristiano2007-11-21T11:13:10Il prefisso locale idnsix è associato al targetNamespace di questo schema,http://www.interdatanet.org/ns/StorageInterface/ext.Nel seguente listato è riportato l’inizio del documento, nel quale si può vederel’elemento radice della definizione dello schema con gli attributi che contiene:338


Storage Interface ServiceStorage Interface Data Model13.3.3 WSDL e XML SchemaStorage Interface XML SchemaIl seguente listato presenta lo schema XML <strong>dei</strong> messaggi e <strong>dei</strong> data type diStorage Interface.339


Storage Interface ServiceStorage Interface Data Model340


Storage Interface ServiceStorage Interface Data Model341


Storage Interface ServiceStorage Interface Data Model342


Storage Interface ServiceStorage Interface Data Model343


Storage Interface ServiceStorage Interface Data Model344


Storage Interface ServiceStorage Interface Data Model345


Storage Interface ServiceStorage Interface Data Model346


Storage Interface ServiceStorage Interface Data Model347


Storage Interface ServiceStorage Interface Data Model348


Storage Interface ServiceStorage Interface Data ModelStorage Interface Predefined TypesIl seguente listato presenta lo schema XML tipi predefiniti di Storage Interface.349


Storage Interface ServiceStorage Interface Data Model350


Storage Interface ServiceStorage Interface Data Model351


ConclusioniLe soluzioni di interdataworking si pongono l’obiettivo di collegare, distribuireed integrare i dati aumentando l’intero<strong>per</strong>abilità e la collaborazione traprocessi connessi in rete.Nei tredici capitoli che compongono questa tesi ho presentato <strong>InterDataNet</strong>(IDN): una architettura innovativa che intende risolvere a livello infrastrutturalei problemi relativi alla distribuzione fisica e logica di risorse ed utenti in rete,ridefinendo e rileggendo i comportamenti delle risorse in gioco a vantaggio delleattività collaborative. IDN determina una soluzione formale riutilizzabile ad unproblema contestualizzato che descrive il modello, le intenzioni, le motivazioni,i campi applicativi, le conseguenze, la struttura ed una implementazione diriferimento.I principi fondanti di <strong>InterDataNet</strong> esprimono ed acquisiscono l’es<strong>per</strong>ienzaed il valore <strong>dei</strong> risultati vincenti dell’internetworking, applicandoli all’interdataworking.Infatti è stata adottata la stratificazione quale principio guida nellaricerca e nella progettazione, attuando una estensione dal settore delle telecomunicazionial trattamento e gestione dell’informazione, <strong>per</strong>seguendo la scalabilitàe l’inclusione di dati esistenti (in sistemi legacy).L’intero<strong>per</strong>abilità <strong>dei</strong> dati, viene così portata nell’infrastruttura, prefigurandoun ambiente integrato ed a<strong>per</strong>to, capace di distribuire ed arricchire la conoscenzabasata sui dati. Tale ambiente viene concretamente realizzato graziead apparati di interdataworking, che implementano specifiche funzionalità in livellidiversi dell’architettura IDN, lasciando spazio allo sviluppo di applicazionia valore aggiunto. L’applicazione dell’internetworking all’interdataworking agevolacosì IDN a candidarsi a modello di riferimento, adottabile liberamente da<strong>per</strong>sone, imprese ed organizzazioni.Nella tesi si presentano e si discutono i principi concettuali e tecnologici di<strong>InterDataNet</strong>:• IDN è un middleware stratificato secondo un approccio SOA (ServiceOriented Architecture) in grado di consentire lo sviluppo di servizi intero<strong>per</strong>abilie debolmente accoppiati che possono essere combinati in sistemipiù complessi. L’approccio stratificato consente di abbattere la comples-


Conclusionisità del sistema applicando i principi di “information hiding”, “separationof concern” e “good enough”;• IDN adotta il paradigma REST (Representational State Tranfer) <strong>per</strong> realizzareuna interfaccia uniforme di interazione con le risorse (URI, UniformResource Identifier) in grado di assicurare contemporaneamente prestazioni,scalabilità e sufficiente astrazione in sistemi distribuiti composti darisorse 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 (<strong>InterDataNet</strong> Information Model). È il modello di informazioniche rappresenta un generico documento/dato in maniera indipendentedallo specifico contesto e dalla tecnologia. Definisce irequisiti, le proprietà desiderabili, i principi e la struttura del documentoche deve essere gestito da IDN. In IDN-IM, l’informazione èstrutturata e dotata di specifici metadati. Il modello illustra comela composizione degli elementi informativi costituenti il documentosia realizzata <strong>per</strong> costruire entità informative più complesse al fine diservire le necessità di una gestione collaborativa dell’informazione;– IDN-SA (<strong>InterDataNet</strong> Service Architecture). È il modello architetturaleService Oriented che descrive i servizi <strong>per</strong> la gestione didocumenti IDN. IDN-SA definisce le funzionalità di riferimento, isottosistemi, i protocolli e le interfacce <strong>per</strong> la gestione collaborativadi un documento IDN. La stratificazione assume un ruolo importantenella orchestrazione <strong>dei</strong> servizi che viene determinata in manieranaturale proprio dalla gerarchia <strong>dei</strong> livelli;– IDN-ON (<strong>InterDataNet</strong> Overlay Network). È l’architettura di rete incui sono collocati gli apparati di rete interdataworking. Rappresentail modello con cui costruire reti Overlay Network di IDN.L’insieme delle tre viste di <strong>InterDataNet</strong> caratterizza il sistema nel suo complessoe 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 <strong>InterDataNet</strong>Questa tesi è redatta al fine di inquadrare il risultato principale di questaricerca, ovvero la progettazione dettagliata di <strong>InterDataNet</strong>, in un contesto dicomprensione che faciliti il proseguimento del progetto stesso. Come si è giàdetto, <strong>InterDataNet</strong> non può costituire lo sforzo di un singolo, ma fin dalla suanascita rappresenta una visione e un progetto portati avanti da un gruppo diricerca composto da vari membri. Se dunque i capitoli che compongono questodocumento hanno lo scopo di ordinare tutta la conoscenza su <strong>InterDataNet</strong>, èanche opportuno mettere in evidenza qual’è stato il mio specifico contributoall’avanzamento del progetto.353


ConclusioniIl mio lavoro su IDN è cominciato nel 2003 con la tesi di laurea quinquennalein Ingegneria Informatica ed è proseguito negli anni successivi e duranteil dottorato di ricerca. In questo <strong>per</strong>corso ho assunto il ruolo di su<strong>per</strong>visore,progettista ed implementatore, svolgendo in particolare le seguenti attività:• indicare e definire le linee guida, gli strumenti, le tecniche, le metodologiee le tecnologie di progetto;• coordinare, durante il tutoraggio di laureandi, l’analisi del contesto e losviluppo <strong>dei</strong> livelli di IDN: sistema di nomi LS e LDNS, Virtual Repository,Information History, Replica Management, Storage Interface, protocolli dicomunicazione con delega, applicabilità al sistema informativo del Comunedi Firenze, sicurezza in sistemi distribuiti, gestione di documenti giuridici;• suggerire <strong>nuove</strong> prospettive ed approcci sistemici al problema in ambitocivile (sociale, giuridico, Pubblica Amministrazione), civile e militare (retidi sensori);• migliorare e sviluppare i sottosistemi;• promuovere e su<strong>per</strong>visionare elaborati su IDN nell’ambito del corso universitario“Telematica” al secondo anno di laurea specialistica in IngegneriaInformatica e delle Telecomunicazioni;• divulgare i risultati e produrre articoli scientifici.Applicazioni pratiche, implicazioni e ricerca futuraQuello che resta da fare in IDN è molto, il risultato di questa tesi e il riscontropositivo ottenuto nelle pubblicazioni fornisce <strong>per</strong> la prima volta un backgroundprogettuale solido <strong>per</strong>chè la “vision” IDN possa maturare e il “progetto” IDNpossa evolvere oltre.È certo prevedere <strong>per</strong> IDN delle applicazioni concrete nel campo delle CSCA(Computer Supported Collaborative Applications). Queste applicazioni possonoessere costruite sopra il middleware IDN senza la necessità di riscrivere funzionalitàdi base, trovando maggiore spazio <strong>per</strong> l’implementazione di serivizi avalore aggiunto. <strong>InterDataNet</strong> diventerebbe così framework <strong>per</strong> l’evolversi diapplicazioni distribuite nella produzione di contenuti e di documenti, nella gestionedel workflow e delle versioni, nella integrazione di sistemi groupware e dicollaborazione.Applicazioni test sono state ipotizzate o parzialmente documentate nella letteraturadi IDN; ad esempio il file system distribuito basato su IDN e l’editorcollaborativo (plugin <strong>per</strong> word-processor e browser). Sono stati a lungo studiateanche soluzioni ed applicazioni nel settore e-Government e dell’informaticagiuridica <strong>per</strong> la gestione <strong>dei</strong> flussi documentali.Come si è messo in evidenza nell’Introduzione, <strong>InterDataNet</strong> si pone in conformitàe coerenza con gli obiettivi della Web Science: <strong>InterDataNet</strong> è allineatocon la visione evolutiva del Web dal“Web of Document”al“Web of Data”. InfattiIDN sposta l’“intelligenza” dall’applicazione ai dati, <strong>per</strong> abilitare <strong>nuove</strong> <strong>frontiere</strong>nelle applicazioni, rendendosi così di supporto alla realizzazione del Web354


ConclusioniSemantico. Più specificamente, <strong>InterDataNet</strong>, in un <strong>per</strong>corso indipendente edoriginale, è arrivato a formulare e recepire il Linked Data, passaggio intermediotra il “Web of Document” ed il Semantic Web.Nella prosecuzione del progetto IDN si prevedono a medio termine l’ulterioreselezione e affinamento degli standard tecnologici e la promozione da applicazionedimostrativa ad applicazione stabile: estremizzando l’attenzione ai singolilivelli è già in atto la definizione di sottoprogetti a valore indipendente.Infine, <strong>per</strong> potere aprire la visione IDN verso <strong>nuove</strong> <strong>frontiere</strong> di ricerca siprevedono degli approfondimenti teorici che <strong>per</strong>mettano di evolvere la visioneIDN in armonia con i principi del Web Semantico. In particolare si mira a mapparel’isomorfismo fra IDN-IM ed RDF <strong>per</strong> sviluppare applicazioni semantichesu IDN.Concludendo questa sezione con un’a<strong>per</strong>tura verso una “utopia possibile”,l’ambizione della visione di <strong>InterDataNet</strong> è quella di guadagnarsi un successoanalogo a quello dell’internetworking. Parafrasando le parole di Tim BernersLee, se il TCP/IP è da considerare una “pretty general internetworking facility”mi piacerebbe poter considerare <strong>InterDataNet</strong> come una “pretty general interdataworkingfacility”. La larga adozione del middleware IDN potrebbe aggiungerealle soluzioni Internet la capacità di interdataworking, e il suo approcciopotrebbe finire <strong>per</strong> diventare standard di fatto, se venisse su<strong>per</strong>ata la massa criticadi utenti. Perchè ciò avvenga è necessario che la ricerca su <strong>InterDataNet</strong> siestenda da livello team a livello Web-community ed in particolare prenda spazionelle comunità di sviluppatori open source. Solo così si potrà s<strong>per</strong>are nell’effettonetwork capace di rendere IDN la nuova “interdataworking facility”.355


Parte VAppendici


AppendiceAABNFLa ABNF (Augmented Backus-Naur form) è una metasintassi, ovvero un linguaggioformale attraverso il quale è possibile descrivere la sintassi di linguaggiformali. Si tratta di uno strumento ideale <strong>per</strong> descrivere, in modo preciso e nonambiguo, la sintassi di linguaggi di programmazione, protocolli di rete, e cosìvia benché non manchino, in letteratura, esempi di sue applicazioni a contestianche non informatici e addirittura non tecnologici. Attraverso la BNF si puòdescrivere la sintassi di un qualunque linguaggio formale, a patto che tale sintassicorrisponda a quella che i teorici chiamano una grammatica context-freeo grammatica libera dal contesto. La BNF è molto utilizzata in informatica;la maggior parte <strong>dei</strong> programmatori, in particolare, ne conosce almeno le lineeessenziali. Fu inventata da John Backus <strong>per</strong> documentare formalmente la sintassidel linguaggio Algol 60. Su suggerimento di Donald Knuth, l’acronimo fuin seguito riletto come “Backus-Naur form” in onore di Peter Naur che insiemea Backus fu uno <strong>dei</strong> più grandi pionieri nella storia <strong>dei</strong> linguaggi di programmazionee <strong>dei</strong> compilatori. Una specifica BNF è un insieme di regole di derivazionedella forma: ::= dove viene detto un simbolo nonterminale ed è costituitada una o più sequenze di simboli (terminali, vedi sotto, o nonterminali)separate dalla barra verticale ‘|’. La regola esprime il fatto che il nonterminalealla sua sinistra può essere sostituito da una qualsiasi delle sequenze indicatesulla destra (come sarà chiarito a breve). In una sequenza alcuni simboli o sottosequenzepossono essere indicati come opzionali racchiudendoli fra parentesiquadre. I simboli che non appaiono mai a sinistra di una regola di derivazionesono detti terminali. I terminali sono in un certo senso il punto di arrivo, <strong>per</strong>chérappresentano elementi che si troveranno effettivamente in un testo scritto


ABNFsecondo le regole sintattiche che la specifica BNF descrive. Viceversa i non terminalisono strumenti utilizzati esclusivamente dalla BNF; si può dire che essirappresentano gli elementi astratti della grammatica.358


AppendiceBNotazioni e definizioniIn questa appendice sono sinteticamente elencate le notazioni, le definizionied i principali acronimi più utilizzati nei capitoli della tesi.B.1 Notazioni <strong>per</strong> i requisitiIn questo lavoro sono state usate le seguenti terminologia e convenzionitipografiche:Le keyword “MUST”, “MUST NOT”, “REQUIRED”, “SHALL”, “SHALLNOT”, “SHOULD”, “SHOULD NOT”, “RECOMMENDED”, “MAY” ed “OP-TIONAL” usate in questo documento devono essere interpretate come descrittoin [Bra97].• MUST, REQUIRED, SHALL. Il requisito è assoluto deve essere soddisfatto.• SHOULD, RECOMMENDED. Possono esistere alcune ragioni <strong>per</strong> lequali il requisito sia ignorato, tuttavia è richiesta una valida motivazionecomprensibile del motivo del rifiuto.• MAY, OPTIONAL. Il requisito è opzionale, e può essere ignorato <strong>per</strong>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 fondamentaleche deve essere svolta durante l’esecuzione del software accettando oprocessando l’input o processando e gene