Struttura dell'architettura

Il repository consta di quattro categorie di agenti che si occupano dei diversi aspetti che sono coinvolti dal problema.

Massima attenzione è stata posta nel rendere il più possibile indipendenti ognuna delle quattro famiglie di agenti, affinché sia possibile utilizzare una di esse anche fuori dal contesto proposto.

• [Proxy]È l'agente più ``superficiale'' che dialoga direttamente con i clients e fornisce un interfaccia globale di accesso al repository. Si occupa di individuare tramite degli agents NameServer la locazione degli ObjectManager che gestiscono un determinato oggetto e di ottenere tramite essi un riferimento ad esso. Tramite i Proxies è consentito introdurre, prelevare, cancellare oggetti dal repository in modo indipendente dalla locazione fisica delle entità coinvolte nel processo.
  Sono previsti cammini ottimizzati per il reperimento delle informazioni, che prevedono l'accesso diretto agli Storage per la verifica della consistenza della cache locale con il repository, il caching dei nomi degli ObjectManager e il caching locale degli oggetti prelevati recentemente.
  La politica di caching implementata nel software presentato prevede l'inserimento nella cache locale di ogni oggetto che si desidera prelevare. Nessuna procedura di cancellazione di oggetti dalla cache risulta implementata (non è difficile scrivere un piccolo daemon locale che periodicamente scandisca la cache ed elimini gli oggetti ritenuti inutili).
  I Proxy sono stateless, nel senso che in caso di morte di un Proxy ne può essere attivato uno in sostituzione senza problemi (con i semplici ritardi dovuti ad una cache vuota), oppure può essere riattivato il Proxy morto anche in un secondo momento senza problemi di inconsistenza (eventuali politiche più aggressive di caching, che prevedano, p.es. il confronto con i timestamps degli oggetti nel repository solo in certi momenti non garantiscono questa semplicità e robustezza di funzionamento).
• [NameServer]Una rete di NameServer svolge il compito di individuare un server di destinazione dato il nome di un oggetto. Esso è utilizzato dai Proxy per individuare la locazione degli ObjectManager.
  Nella particolare implementazione, il NameServer permette di effettuare semplici bilanciamenti del carico (scegliendo con opportuni pesi il percorso per il raggiungimento di un server che fornisca il servizio desiderato), deferimento del compito di ricerca ad un altro NameServer (ricerca iterativa e ricorsiva), utilizzo di programmi esterni per la formulazione di particolari politiche personalizzate di ricerca (p.es. utilizzo di agenti che monitorizzino la rete e modifichino i parametri di funzionamento dei NameServer in funzione del suo stato).
• [ObjectManager]Gli object manager si occupano di gestire la replicazione degli oggetti su più Storages, di garantire la consistenza di tutte le copie degli oggetti presenti nel repository, di attuare politiche opportune di recovery nel caso di crash di uno o più Storages o nel caso di network failures.
  Nella particolare implementazione gli ObjectManager consentono di gestire politiche di replicazione con specifica del numero minimo/massimo di copie di un oggetto presenti nel repository; qualora la morte di qualche Storage faccia scendere il numero delle copie attive presenti sotto il minimo previsto dalla policy dell'oggetto, l'ObjectManager si preoccupa di riportare il numero di copie dell'oggetto nel repository al suo livello massimo.
  Gli ObjectManager sono dotati di uno stato che può essere ricostruito esaminando gli Storage da essi gestiti. Ciò permette di rendere facile il recovery in caso di guasto di un ObjectManager o di network-failure (basta infatti attivare un ObjectManager ``gemello'' di quello morto ed esso ricostruirà il proprio stato interno dalla consultazione degli Storage che deve gestire).
• [Storage]Gli Storages si occupano del mantenimento in forma persistente delle istanze degli oggetti presenti nel repository. Lo stato degli Storage consiste nell'insieme degli oggetti che sono sotto il proprio controllo, così come le metainformazioni specifiche degli oggetti locali (timestamp, replication policies). In caso di morte di uno Storage, il compito di ricostruire le informazioni mancanti spetta all'ObjectManager che lo gestisce.
  L'implementazione specifica prevede la memorizzazione sotto forma di file locale di una versione linearizzata dell'oggetto.

La specifica delle interfaccie proposte da ogni agente può essere analizzata nella documentazione del software.

Esempio di architettura realizzata utilizzando più istanze degli agenti proposti.