Logical Domain Name Service

Una medesima risorsa pu`o essere nominata in modo diverso e collocata in contesti diversi pur mantenendosi invariabile da un punto di vista di conte- nuti. All’interno di IDN questo aspetto viene gestito assegnando a ciascu- na risorsa uno o pi`u nomi canonici a cui possono essere aggiunti ulteriori alias; gli LRI corrispondenti sono gestiti dal Logical Domain Name Service (LDNS), sottoservizio di Virtual Resource.

Esso `e in grado di determinare l’identificativo canonico attuando una riso- luzione che pu`o essere svolta in uno o pi`u passi (qualora il nome LRI di partenza sia un alias) e quindi, a partire da esso, stabilire il VRI necessario per poter inoltrare la richiesta al livello inferiore.

Inoltre LDNS gestisce anche la risoluzione inversa degli alias; si ricordi che, come illustrato nel paragrafo 3.6, sono definite due categorie di alias:

• invertibili globalmente (ovvero bidirezionali); • invertibili localmente (ovvero monodirezionali).

La prima categoria offre un maggior livello di awareness globale in quan- to, instaurando una relazione bidirezionale fra le parti in gioco, permette al responsabile del nome (relativamente al quale viene creato un alias) di conoscerne tutti gli alias.

La creazione di alias bidirezionali `e comunque un processo relativamente complesso che richiede un livello di trust fra le parti in gioco; perci`o sono stati introdotti gli alias non invertibili globalmente (ovvero invertibili solo a livello locale) i quali, instaurando una relazione pi`u lasca, offrono minori garanzie, ma sono pi`u semplici da creare e gestire.

La scelta di utilizzare un tipo di alias o l’altro dipende sostanzialmente dal- le propriet`a richieste dalla relazione di alias che si intende instaurare fra i due LRI e nessuno dei due casi `e da considerarsi migliore dell’altro. Se da un lato infatti l’invertibilit`a globale `e una propriet`a auspicabile, dall’altro lato la possibilit`a di creare alias in modo trasparente per il responsabile del nome riferito `e una semplificazione che pu`o apportare notevoli vantaggi; inol- tre quest’ultima soluzione non introduce problemi di scalabilit`a a differenza della prima che deve essere maggiormente monitorata e controllata.

La creazione di alias invertibili a livello globale potrebbe portare infatti alla nascita di punti di accumulazione critici, ovvero LRI relativamente ai quali vengono creati numerosi alias. Il limite di scalabilit`a deriva dal fatto che

4.6 Virtual Resource 95 LRI1 alias1 alias2 alias3 aliasN

...

Caso (a): creazione non controllata di alias (non scalabile)

LRI1

alias1 alias2 alias3 alias4 alias5 alias6 alias7 alias8 alias9 alias10

...

Caso (b): creazione controllata di alias (struttura ad albero, scalabile)

Figura 4.11: Creazione controllata e non di alias.

ogni alias invertibile deve essere noto al sistema autoritativo sull’elemento al quale fa riferimento e pertanto, da questo punto di vista, InterDataNet offrirebbe prestazioni paragonabili ad un comune sistema centralizzato. Una soluzione scalabile a questo problema consiste nel creare gli alias in modo controllato, ovvero creare relazioni fra alias che rispettino la struttura ad albero (come nel caso (b) della figura 4.11), anzich´e creare tutti gli alias verso un unico LRI (come nel caso (a) in figura 4.11). La struttura ad albero offre infatti il vantaggio di permettere la distribuzione del carico di lavoro fra un numero arbitrario di host senza penalizzare la risoluzione diretta, nell’ipotesi che l’albero sia ben bilanciato e non degenerato su una lista.

Parte III

Capitolo 5

IDN Template Information

Model

All’interno di ogni ambito della vita ed in particolar modo per quanto ri- guarda l’ingegneria, un medesimo problema pu`o essere affrontato da soggetti diversi facendo ricorso a soluzioni completamente differenti.

Si pensi ad esempio, alla progettazione di un ponte, di un’automobile, di un componente hardware, di una libreria software, ecc. . . . Restando lo stesso il fine che due ingegneri intendono raggiungere (come ad esempio la realiz- zazione di un software per risolvere un determinato problema), le modalit`a mediante le quali l’obiettivo viene raggiunto possono differire sensibilmente e con molte variabili: ad esempio, nel caso dei programmi software pu`o cam- biare il linguaggio di programmazione utilizzato, i diagrammi UML ottenuti nella fase di ingegnerizzazione, fino alle librerie software utilizzate e cos`ı via. Una situazione analoga a quella descritta si presenta anche all’interno del- l’infrastruttura InterDataNet: risulta di fondamentale importanza il fatto che ciascun progettista di documenti IDN metta a disposizione della comu- nit`a una serie di informazioni volta a specificare, in una modalit`a che possa essere quanto pi`u standard possibile, quali sono le scelte da lui effettuate du- rante la fase di progettazione e che hanno portato a strutturare i documenti in una certa modalit`a piuttosto che in altre. In particolare `e necessario che il progettista dichiari quale `e il modello dei dati che ha utilizzato, palesando quindi le interconnessioni esistenti tra i vari nodi di cui il documento IDN `e costituito, nonch´e tutte quelle informazioni relative al contenuto di cui ogni nodo si fa carico (ovvero ai cosiddetti dati di livello applicativo) quali: il formato, la sintassi, la semantica.

All’interno del presente capitolo saranno dapprima analizzate le motivazioni delle suddette esigenze concentrandosi sugli aspetti fondamentali per la defi- nizione di un modello dei dati per i documenti IDN, ovvero nell’ordine la sua struttura, quindi il formato e la sintassi del contenuto ed infine la relativa semantica. Successivamente verr`a introdotta la soluzione proposta per un

information model 1 di un opportuno modello dei dati (il cosiddetto IDN Template); al fine di chiarificare tale presentazione sar`a fatto ricorso ad un particolare esempio, ovvero la gestione all’interno di InterDataNet degli Open Data del Comune di Firenze relativi ai musei, della quale si parler`a pi`u dettagliatamente all’interno del capitolo 8.

Infine, verr`a tracciato un parallelo tra il dominio della programmazione orientata agli oggetti e quello dei documenti IDN, mettendo in risalto alcune analogie individuabili. Tale trattazione risulta di particolare importanza per la comprensione del capitolo 6, al cui interno sar`a illustrato come `e possibile effettuare il riuso di parti di un IDN Template all’interno di un altro. In tale ottica il modello costituisce quindi anche una forma di rappresentazio- ne consultabile di documenti IDN-IM, in grado di aiutare un progettista a operare con profitto il riuso virtuoso dei dati.

5.1

La necessit`a di individuare regole per i dati

All’interno del capitolo 3 `e stato illustrato il data model dei documenti IDN allo stato dell’arte: esso fornisce a qualunque progettista la possibilit`a di realizzare documenti che possono essere utilizzati da utenti distribuiti nel tempo e nello spazio per collaborare intorno ad elementi informativi. Allo stato dell’arte non risulta immediata la possibilit`a di riuso di tali dati da parte di soggetti terzi: infatti un documento IDN di livello VR non dispone di un meccanismo che fornisca al suo progettista la possibilit`a di specificare informazioni quali il modo in cui sono stati organizzati i dati all’interno del dataset, con quale granularit`a, con quale rappresentazione di livello applicativo, quale sia la semantica dei dati.

All’interno del presente paragrafo saranno illustrati nel dettaglio quattro aspetti di particolare importanza, cercando di motivare la necessit`a di una loro descrizione da parte del progettista. Tali aspetti sono: la struttura di un documento IDN, il formato, la sintassi e la semantica dei dati di livello applicativo gestiti dai nodi.