Parlando di miglioramenti si deve distinguere tra interventi che possono essere fatti al tool per la realizzazione di sistemi ad agenti mobili e quelli che possono essere fatti al sistema vero e proprio.

Gli sviluppi futuri del sistema possono essere molteplici, si può partire dalla realizzazione di un vero e proprio sistema distribuito in grado di garantire la possibilità di mantenere la duplicazione delle informazioni e arrivare fino alla realizzazione di un sistema che permetta l’utilizzo della frammentazione ibrida delle tabelle principali.

Per quel che riguarda i miglioramenti che possono essere introdotti al tool questi possono essere indirizzati verso un miglioramento delle performance e verso un integrazione di funzionalità specifiche, come ad esempio la possibilità di seguire l’agente lungo il cammino che percorre.

7.1 Estensioni al sistema di interrogazione distribuita

L’obiettivo che ci si prefigge in questo caso è la realizzazione di un sistema distribuito che sia in grado di gestire le transazioni e possa mantenere la duplicazione delle informazioni sui database, il progetto deve comunque rifarsi alle caratteristiche di progetto trattate in precedenza, specificatamente per problemi di faul tolerance si è ritenuto opportuno introdurre le limitazioni di progettazione della struttura della rete riportate nel paragrafo relativo alla tolleranza all’errore.

È evidente che la necessità di implementare un supporto alle transazioni esteso su tutta la rete implica il dover garantire l’esistenza di un qualche meccanismo di controllo nella distribuzione query. Si è pensato di implementare questo meccanismo individuando un sito centrale di smistamento a cui dovranno essere inviate tutte le transazioni [fig. 7.1.1].

Il sistema risulterà quindi avere due modalità di funzionamento: mentre per le query di ricerca verranno trattate nello stesso identico modo di prima, il ricorso alle transazioni passerà per un sito di coordinamento che avrà il compito di intercettare le query, ordinarle a seconda criteri temporali e di priorità ben definiti.

Il nodo coordinatore o Transaction Monitor sarà l’unico a conoscere tutti i nodi collegati, infatti il suo compito è quello di intercettare le transazioni provenienti dai vari siti, ordinarle secondo il tempo di arrivo e/o secondo una scala di priorità ben definita e inviarle ai siti opportuni. Essenzialmente il suo funzionamento consiste nel mantenere una struttura ordinata, dove saranno registrate i robot di transazione e alcune informazioni di utilità come ad esempio il nome del database di riferimento, dalla quale preleverà i vari agenti e li invierà su tutti i server che hanno dichiarato di avere dei riferimenti al database selezionato. Per espletare questi compiti dovrà avere una lista di tutti i nodi facenti parte della rete e per ogni nodo una lista dei database messi a disposizione.

Ora non resta che stabilire come individuare il Transaction Monitor. Questo può avvenire tramite un meccanismo molto simile a quello implementato nelle reti token ring per l’elezione dell’Active Monitor. Essenzialmente si tratta di associare ad ogni server un numero seriale univoco, magari ordinando le macchine per prestazioni, dopo di che al momento di attivazione ogni server invia un robot denominato ActivateServer a nodi collegati, tutti i nodi attivi risponderanno inviando al sorgente un robot contenente i dati del Transaction Monitor. Il server procederà verificano che il suo numero seriale sia inferiore a quello del Transaction Monitor, nel qual caso procederà inviando al nodo coordinatore il suo indirizzo.

Nel caso sia superiore provocherà la destituzione del Transaction Monitor inviando un agente opportuno direttamente al nodo di coordinamento, si attiverà in modalità provvisoria e aspetterà il passaggio delle consegne (lista dei siti componenti la rete e robot mantenuti in stand-by). In modalità provvisoria il sistema sarà in grado di intercettare le transazioni provenienti dai vari siti ma non potrà mandarle in esecuzione. Una volta arrivati tutti i dati dal nodi destituito il sistema si riavvierà in modalità Transaction Monitor e opererà come già descritto.

Per quel che riguarda la tolleranza agli errori vale lo stesso discorso fatto in precedenza, e cioè i nodi dovranno avere dei doppi collegamenti per garantire la rintracciabilità dei siti da parte dei server ad essi collegati, oltre a ciò è fondamentale che le varie stazioni sia collegati al minimo con due server. Per garantire una buona tolleranza agli errori si può inserire nella rete un Transaction Monitor secondario che funzioni in mirroring con il sistema principale; i due sistemi devono essere in grado di interscambiarsi le informazioni necessarie per mantenere allineati i due server e verificare che entrambe i nodi siano attivi. È necessario che il TM secondario invii degli "hello message" al TM principale in modo che esso verifichi che il nodo in mirroring sia attivo, nel caso il nodo secondario andasse in crash il nodo principale deve provvedere ad impostare un altro nodo come secondario. Nel caso in cui un nodo risulti temporaneamente inattivo, al momento della sua riattivazione gli verranno spediti tutte le transazioni che sono state fatte sui database presenti sul sito stesso.

Sarà carico della parte client del sistema inviare i robot di transazione direttamente al sia al Transaction Monitor che al sito di mirroring, per far ciò i due nodi suddetti dovranno comunicare il loro indirizzo all’applicazione client che vi farà riferimento quando necessario.

7.2 Estensioni al tool per la realizzazione di sistemi ad Agenti Mobili

Gli sviluppi della tecnologia ad agenti non sono finiti e a tutt’oggi non esiste nessuno standard che definisca esattamente come detti componenti devono comportarsi sulla rete, chiaramente non si transige a proposito delle caratteristiche di base e cioè sul fatto che essi devono poter migrare da una piattaforma all’altra, che agenti presenti sulla stessa piattaforma possano comunicare tra loro, e vi sia un modo per implementare politiche di sicurezza.

Una prima estensione a cui dovrà essere sottoposto il tool sarà quella di permettere la collaborazione di agenti presenti su server diversi. Questo non significa solo scambio di messaggi ma significa avere la possibilità di riferirsi a risorse non presenti sul sistema ospite avere cioè una visione omogenea di tutto il sistema e permettere la cooperazione e collaborazione tra gli agenti.

Altri miglioramenti sono legati agli aspetti che riguardano la sicurezza, inserire un meccanismo che mandi sulla rete gli agenti in un formato crittografato, ad esempio con chiave pubblica e chiave privata, darebbe la possibilità di certificare sia l’agente che il server.

In ultima analisi il tool realizzato è la piattaforma minima con cui si possa progettare e realizzare sistemi che utilizzino agenti mobili.