Per l'implementazione del progetto abbiamo utilizzati gli strumenti messi a disposizione dall' ORB Visibroker 3.4 per Java, assieme a JDK 1.2.2.
Lo Smart Agent è un servizio di directory distribuito. Le implementazioni degli oggetti si registrano presso lo Smart Agent su una lista di oggetti disponibili (su cui un client può effettuare la bind).
Lo Smart Agent viene localizzato sulla rete tramite un broadcast, e la comunicazione fra lui e i client avviene point-to-point tramite UDP.
E' possibile avere sulla rete più Smart Agent, che si coordinano per offrire il servizio distribuito, inoltre sono presenti politiche di fault-tolerance per continuare ad offrire il servizio in caso un agente smetta di funzionare.
Il location service è un'estensione di VisiBroker ai servizi di CORBA, ed è utilizzabile solo con oggetti implementati con VisiBroker (almeno nella versione 3.4). E' praticamene un'interfaccia allo SmartAgent (ed infatti dalla versione 4.0 di VB sono inclusi nello stesso eseguibile)
Questo servizio viene implementato con un oggetto CORBA di nome "LocationService" ed espone un'interfaccia che permette di, fra le altre cose:
1) Ottenere tutti gli oggetti registrati nell'ORB che implentano una certa interfaccia.
2) Ottenere la posizione di tutti gli Smart Agent.
3) Registrare/Deregistrare "Trigger", cioè degli oggetti che possono effettuare azioni in seguito all'attivazione/disattivazione di agenti che implementano una data interfaccia.
Nell'implementazione del progetto non abbiamo usato i Trigger (almeno nella versione definitiva) perchè creavano problemi di concorrenza...
Un metodo che è stato usato pesantemente nell'implementazione del progetto è stato il metodo all_instances(String repository_ID), che restituisce un array di riferimenti (org.omg.CORBA.Objects) agli oggetti che implementano una data interfaccia.
Per utilizzare il Location Service, occorre lanciare il processo che corrisponde all'eseguibile Locserv. Per il funzionamento corretto del progetto, occorre settare l'opzione -LOCVerify 1, con cui il location service controlla l'esistenza di un oggetto prima di restituirne il riferimento in seguito all'esecuzione di qualche metodo. Questo è necessario, perchè il Location Service prende le informazioni dallo Smart Agent, che non aggiorna le informazioni "velocemente" (se un server va giù ci mette, dalle nostre prove, circa 5 minuti per accorgersene...).
Inoltre occorre passare, al lancio di vbj l'opzione -DORBservices="com.visigenic.vbroker.ObjLocation"
Tutto il progetto gestisce riferimenti di oggetti. Questi riferimenti possono essere ottenuti sia tramite la Bind(), sia tramite i metodi del Location Service. Nel secondo caso, occorre effettuare un casting dei riferimenti ottenuti rispetto all'interfaccia che si vuole utilizzare. Poichè non si può utilizzare il casting normale di Java, occorre utilizzare il metodo narrow. Di questo metodo, così come per il bind, vengono utilizzate le versioni semplificate contenute nella classe "****Helper" prodotta dal compilatore IDL.
Un altro metodo che abbiamo utilizzato è _non_existent(), della classe org.omg.CORBA.Object. Questo metodo "pinga" l'implementazione di un oggetto e restituisce false se è attiva.
Abbiamo provato ad utilizzare anche Visibroker 4.0 (appena uscito quando abbiamo iniziato a lavorare al progetto...), ma aveva dei problemi. In particolare:
1) Nella prima release di VB 4.0 l'utilizzo del POA e il location service non sono compatibili, ovvero il location service non "vede" oggetti registrati tramite il POA (cosa confermata anche dal newsgroup inprise.public.visibroker).
2) Utilizzando il BOA, non siamo riusciti a disabilitare il "rebind" nella configurazione della politica di gestione dell'ORB.
Abbiamo quindi concluso che, nonostante fosse più scomodo (VB4.0 fornisce strumenti più evoluti, come la console per il monitoring, ecc...) l'unica soluzione fosse usare la versione 3.4.
In VB 3.4 è possibile configurare alcune politiche di gestione. In particolare è presente un meccanismo di fault-tolerance, attivo di default, per cui se un client richiede presso lo smart agent un oggetto che implementa una data interfaccia e questo non è disponibile, ma ne è disponible un'altro (con un altro nome, ma la stessa interfaccia) in maniera trasparente viene effettuato il bind con l'oggetto disponibile. Per disattivare questa politica occorre creare un oggetto di classe org.omg.CORBA.BindOptions, inizializzarlo e chiamare il metodo sull'orb: ((com.visigenic.vbroker.orb.ORB)orb).default_bind_options(bindOptions); //cast necessario
La politica di gestione dei Thread di default è il Thread Pooling. Non abbiamo cambiato i parametri di default di questa politica perchè non abbiamo trovato particolari problemi di performance. Occorrerebbe effettuare delle prove in condizioni di stress per determinare quali sono i parametri ottimali.
Per quel che riguarda la gestione delle connessioni, VisiBroker sceglie automaticamente la modalità di gestione delle connessioni migliore basandosi sulla politica di gestione dei Thread. Ad esempio può multiplexare la comunicazione fra più coppie client/thread su una stessa connessione.