La programmazione di rete nell'architettura proposta

Nella tabella seguente sono riassunti i punti fondamentali che differenziano fra di loro gli agenti utilizzati, per quanto riguarda il differente approccio avuto nell'affrontare le varie problematiche di rete.

Per quanto riguarda la scalabilità, va aggiunto che tutti gli agenti implementati sono multithreaded e l'accesso ai dati condivisi è protetto da opportune politiche di locking che impediscono l'accesso di un client ad un Oggetto, qualora esso sia in fase di modifica da parte di un altro client (la granularità del locking è del singolo Oggetto, con la presenza di lock Shared o Exclusive, che limitano l'accesso serializzato agli oggetti alle sole parti realmente sequenziali del processo).

	Scalabilità	Stato	Obbiettivi	Recovery
Proxy	I Proxies consentono di mantenere buone le prestazioni qualora gli accessi in lettura siano preponderanti senza necessità di aumentare il numero di Storage o di partizionare il repository in un grande numero di dominî controllati ognuno da un ObjectManager.	Cache dei dati. Viene verificata prima della lettura.	Fornire un front-end trasparente al sistema. Migliorare le prestazioni tramite l'utilizzo di cache locale.	Rilancio di un nuovo Proxy. I client, in caso di fallimento con un Proxy primario possono provare su uno o più Proxies secondarî.
Name Server	Consentono grazie alla possibilità di lavorare in congiunzione con altri NameServer o mantenendo una cache locale delle richieste più frequenti di risolvere il problema della locazione dei nomi in maniera efficace. La scalabilità si ottiene utilizzando un adeguato numero di NameServer e strutturando il DataBase delle regole in modo da partizionare il carico equamente su di essi.	Tabelle di regole di risuluzione dei nomi. Statiche.	Consentire il funzionamento di un client indipendentemente dalla locazione in rete degli agenti che contribuiscono a fornire il servizio. Permette un ampio grado di mobilità ai server.	Possibilità di avere attivi più NameServer con le medesime tabelle, oppure NameServer con tabelle diverse, ma che garantiscano una copertura (più o meno efficiente) dello spazio degli ObjectManager.
Object Manager	Ogni ObjectManager deve essere dimensionato in modo da gestire un insieme di Oggetti compatibile con la propria disponibilità di risorse (memoria, network bandwidth). La scalabilità si ottiene ripartendo l'insieme degli oggetti su un numero opportuno di ObjectManager.	Stato di replicazione degli oggetti (elenco dei server su cui resiedono). In fase di validazione elenco delle istanze di ogni oggetto, con proprietà (ts e prop).	Coordinare i processi di replicazione ed occuparsi delle procedure di recovery in caso di network-failure o di morte di un agente.	Necessità di scandire l'insieme di Storages sotto il proprio controllo, per verificarne la consistenza e potere ricreare le proprie tavole interne.
Storage	Il numero degli Storage coinvolti dipende dalla quantità di dati che si vuole mantenere nel repository e dal grado di replicazione degli oggetti (da cui dipende la resistenza ai guasti dell'intero sistema). L'aggiunta di Storages al repository aumenta la quantità di dati memorizzabili. Per ottenere prestazioni elevate conviene mantenere il rapporto Storages/ObjectManagers piuttosto costante.	Oggetti e loro proprietà (ts e prop).	Garantire la persistenza temporale di un determinato oggetto. Si occupa della memorizzazione dell'oggetto su un particolare supporto (file system, DBMS, OODBMS, ...).	In caso di crash di uno Storage, il proprio stato viene replicato dall'ObjectManager dagli altri Storages serviti. In caso di fallimento di più Storages, viene garantita la sopravvivenza degli oggetti compatibilmente con i vincoli di replicazione imposti al momento della creazione.

Altri aspetti che differenziano sostanzialmente fra di loro gli agenti del progetto sono: le struttura dati utilizzate; l'àmbito logico in cui lavorano, il tipo di risorse utilizzate in prevalenza, il tempo di vita degli Oggetti o delle strutture loro collegate in transito da/verso il cliente, la politica di gestione degli errori interni e degli errori causati dall'accesso ad altri Agenti, le modalità di verifica ed uso dei certificati di sicurezza/autenticazione/segretezza.

In particolare al variare dei parametri di utilizzo (quantità di dati, tipo di accessi, ampiezza degli oggetti, frequenza degli accessi, tasso di ``mortalità'' degli Agenti o di network failures, diversa strutturazione del dominio dei nomi dei dati) il numero di istanze degli agenti in gioco varia in modo diverso a seconda del tipo di agente (p.es. il numero degli oggetti influisce pesantemente sul numero degli ObjectManager e sulla struttura dei NameServer, ma incide in maniera meno vistosa sui Proxies, che a loro volta sono invece fortemente influenzati dalle caratteristiche della rete e dal numero di richieste).