Mobile Agent and Enterprise
Architecture Integration
Il Gestore di Librerie e Servizi
Lambertini Riccardo
Abstract: L’utilizzo di un Application Server permette di sviluppare una varietà di servizi e
risorse in ambito enterprise, affrontando tipiche problematiche di gestione in maniera
ottimale. Un componente utile in molti casi è il Gestore di una piattaforma ad Agenti
Mobili che estenda le funzionalità dell’AS avvicinando idealmente i clienti ai servizi in
modo trasparente, permettendo quindi un miglior uso delle risorse locali e remote. In
particolare, tale Gestore, coordinandosi con il servizio di discovery messo a disposizione
dall’AS stesso, effettua il reperimento locale o remoto dei servizi e librerie necessarie
all’esecuzione dell’agente. In base a precise politiche, che considerano anche criteri di
località e bilanciamento del carico, il Gestore decide lo scaricamento delle risorse
necessarie o la migrazione dell’agente verso di esse.
1
Introduzione
Un Application Server (AS) offre servizi di vario tipo come pagine web, Java Servlet Page (JSP),
Enterprise Java Bean (EJB), etc. Normalmente tali servizi sono forniti attraverso la mediazione di un
container che gestisce servizi standard quali persistenza dei dati, gestione delle connessioni remote e
delle istanze di oggetti in memoria, bilanciamento del carico e così via.
Il progetto svolto è relativo all’integrazione su Application Server di un Gestore di Agenti Mobili.
Tale componente modifica il concetto di località del servizio, consentendo di gestire le richieste
pervenute all’AS tramite agenti mobili, in grado quindi di rilocarsi sulla rete. Ad esempio, a seguito di
una richiesta di interazione con un database remoto, l’Agente Mobile incaricato potrebbe spostarsi
attraverso la rete verso il server che offre questo servizio, interrogarlo da locale e, a esecuzione
terminata, riportare i risultati all’AS di partenza.
In questo modo viene ridotto il carico di rete – deve essere trasferito il solo codice dell’agente – si
migliorano le tolleranze ai guasti e possono essere implementate politiche intelligenti per il
bilanciamento del carico.
Il Gestore di Agenti Mobili realizza inoltre una migrazione consapevole degli agenti, scegliendo per
ognuno di essi la località migliore ove eseguire in funzione di precise considerazioni sulla località delle
risorse, sul carico e sulle politiche attuate dai Gestori omologhi.
2
Analisi del problema
L'integrazione di un gestore di una piattaforma ad agenti mobili in un Application Server e la
possibilità, per tali agenti, di interagire con componenti presenti sul server, prevede di dover affrontare
numerose problematiche.
Nell'intenzione di garantire la consistenza con il paradigma di agente mobile, analizziamone le
proprietà fondamentali e i ruoli svolti da chi deve garantirle.
Autonomia: ogni agente possiede uno stato ed è il solo in grado di modificarlo. Tale stato deve però
poter essere conosciuto, tipicamente dal gestore degli agenti mobili, in relazione a decisioni
sull'eventuale migrazione dell'agente
Interazione con l'ambiente: ogni agente deve essere in grado di percepire l'ambiente circostante
mediante l'utilizzo di sensori e di agire nell'ambiente mediante opportuni attuatori. L'agente deve
eseguire e poter decidere di migrare in modo autonomo. Parte dell'interazione con l'ambiente, in
particolare il ruolo di sensore, è mediata dal gestore che conosce: il tipo di risorse di cui ogni agente
necessita ed il suo bisogno di capacità di calcolo, la disponibilità di risorse e di capacità di calcolo sulla
macchina, le librerie necessarie per l'esecuzione dell'agente e le librerie a disposizione sulla macchina.
E' inoltre compito del gestore realizzare un opportuno protocollo di comunicazione con i gestori
presenti sugli altri AS al fine di indagare la presenza in remoto di risorse necessarie all'agente,
richiedere il loro scaricamento o ordinare la migrazione dell'agente verso le risorse.
Proattività: il comportamento dell'agente deve essere guidato da obiettivi. Tipicamente si tratterà
dell'esecuzione di un servizio delegato dall’AS al nostro componente. Ancora una volta il gestore ha il
ruolo di aiutare ed eventualmente guidare l'agente nel raggiungimento del suo scopo, effettuando il
reperimento del servizio e realizzando il deploy dell'agente e delle risorse a lui necessarie.
Cooperazione: ogni agente deve essere in grado di interagire con altri agenti. La piattaforma dovrà
quindi fornire meccanismi per la comunicazione tra agenti. Una cooperazione di più alto livello dovrà
poi essere effettuata a livello dei gestori che attueranno opportuni protocolli di comunicazione al fine di
gestire la mobilità degli agenti, realizzando opportune politiche di gestione delle risorse.
Inoltre, anche se non richiesto esplicitamente, un punto cruciale nell'utilizzo degli agenti mobili è la
gestione della sicurezza. Il problema della sicurezza è duplice: occorrerà infatti proteggere sia
l'ambiente dagli agenti, sia gli agenti dall'ambiente tramite meccanismi di autenticazione reciproca e di
gestione dei permessi di esecuzione per gli agenti. E’ aperta la scelta relativa alla realizzazione, per gli
agenti, di una mobilità forte o una mobilità debole.
Onde garantire scalabilità al sistema è necessario che i nodi in cui è presente il gestore
dell'infrastruttura ad agenti non si conoscano tutti. Una possibile soluzione è di raggruppare
logicamente tali nodi in domini. Ogni nodo del dominio potrà conoscere in toto o in parte gli altri nodi
del proprio dominio e, onde garantire che la rete sia connessa, almeno un nodo per ogni dominio dovrà
avere una conoscenza parziale del resto della rete. Ovviamente il fatto di avere più nodi che hanno
visibilità al di fuori del dominio, ossia la replicazione di una risorsa critica, permette una maggiore
affidabilità della rete.
Il gestore deve comunicare con i rispettivi in remoto per verificare la loro disponibilità di servizi o
librerie necessari alla esecuzione di un agente e la loro disponibilità ad accogliere agenti.
A fronte di forte carico computazionale su un AS, il relativo gestore potrebbe dialogare con i vari
omologhi remoti, per trovare uno o più AS a cui delegare parte del carico, inviando in remoto uno o più
agenti mobili. Questa richiesta, tuttavia, implicherebbe l’attesa delle risposte in condizioni critiche di
sovraccarico. In seconda istanza un gestore potrebbe mantenere localmente una tabella che memorizza
le disponibilità dei nodi del proprio dominio o diverso raggruppamento logico, in modo tale da poter
scegliere, a fronte di carico eccessivo, su quale nodo/i far migrare uno o più agenti. Questo tipo di
struttura richiede continuo aggiornamento dei dati di disponibilità tra i vari nodi del dominio, o diverso
raggruppamento, ma garantisce un'attesa minore in condizioni critiche di sovraccarico.
Al fine di evitare un eccessivo overhead di aggiornamento si potrebbe ipotizzare di avere per ogni
dominio una tabella centralizzata, aggiornata da ogni nodo ad un cambiamento di stato (carico/scarico)
e interrogata su necessità; in questo modo, nell'ipotesi di escludere nodi appartenenti a più
raggruppamenti logici, per ogni evento sarebbe necessario un solo messaggio di aggiornamento.
Ovviamente, nel caso di sovraccarico di tutti i nodi di un dominio è necessario che un gestore possa
interrogarne altri esterni al dominio; ciò è possibile poiché, come detto, almeno un nodo per ogni
dominio deve avere una conoscenza anche parziale del resto della rete. Tramite esso sarà quindi
possibile interrogare tabelle di altri domini.
Per quanto riguarda la gestione delle librerie e dei servizi, a fronte di necessità per un agente di una
risorsa non presente in locale, ci si potrebbe tipicamente appoggiare ad un sistema di nomi e, in base
anche alle informazioni sul carico, attuare politiche intelligenti. A questo proposito, si ricorda infatti
che le decisioni del gestore devono poggiare fortemente su politiche che potrebbero essere specificate
da parte dell'amministratore dell'infrastruttura.
3
Scelte progettuali
Si è scelto di utilizzare l'infrastruttura ad agenti mobili SOMA (Secure and Open Mobile Agent),
progetto in Java sviluppato dal DEIS dell'Università di Bologna. Tale piattaforma, infatti, si adatta
molto bene alla necessità progettuali discusse nel precedente paragrafo:
Il fatto che SOMA sia stato completamente implementato in Java, senza peraltro averne modificato
la Macchina Virtuale, garantisce la completa portabilità del sistema.
SOMA garantisce, introducendo opportune astrazioni di località, la scalabilità del sistema.
SOMA implementa meccanismi di sicurezza tali da garantire protezioni sia degli ambienti di
esecuzione che degli agenti.
SOMA fornisce già, per ogni Place, l'astrazione di gestore degli agenti fondamentale nella struttura
del progetto. Tipicamente estendendo le funzionalità di quest'ultimo e/o tramite l'implementazione
di particolari tipi di agenti è possibile aggiungere alla piattaforma esistente tutte le funzionalità
necessarie.
Per quanto detto il linguaggio di programmazione adottato è Java.
Si è scelto di utilizzare come Application Server di riferimento la piattaforma sviluppata dal gruppo
JBoss, poichè open source e pienamente compatibile con le specifiche J2EE 1.4.
Per il reperimento di servizi e librerie necessarie all'esecuzione degli agenti si è scelto di utilizzare il
servizio JNDI (Java Naming and Directory Interface) messo a disposizione dall'Application Server.
Oltre a garantire portabilità, scalabilità e sicurezza, l’impostazione strutturale data al progetto cerca
di seguire i principi generali di riusabilità e manutenzione, al fine di garantire al prodotto finale
longevità ed estendibilità nel modo più semplice possibile. A tal fine, la modularità è stata considerata
una scelta obbligata nell’intero progetto e ne consegue pertanto una suddivisione delle responsabilità
tra i vari componenti della piattaforma ad Agenti Mobili.
Si è quindi deciso di suddividere logicamente l’intero sistema in tre parti: il Gestore delle Librerie e
dei Servizi, relativo ai servizi e alle librerie messe a disposizione dai server remoti, il Gestore delle
Politiche, relativo alle politiche e ai fattori influenti sulla migrazione degli AM, e il Gestore della
Mobilità degli Agenti, il cuore dell’applicazione, che si occupa del coordinamento tra le altre due parti,
dell'interazione con l’Application Server locale e della gestione degli Agenti Mobili in esecuzione su di
esso.
Per quanto riguarda le problematiche di rete discusse in fase di analisi, la scelta di SOMA impone di
fatto un’organizzazione dei nodi in domini, che d’altra parte era già stata ipotizzata come soluzione più
logica ai fini della scalabilità.
1
Application
Server
0..*
1
1
1
1
Gestore Librerie e Servizi
MAEAI
0..*
Controllore Agenti
Monitor Risorse di Esecuzione
1
0..*
1..*
1
1
1
Container Politiche
1
Agente Mobile
0..*
Figura 1 - Architettura logica di M.A.E.A.I.
4
Il Gestore di Librerie e Servizi
La caratteristica innovativa principale di questa applicazione, come estensione di una Piattaforma ad
Agenti Mobili, è quella di poter ottimizzare il traffico di rete, già ampiamente ridotto dall’uso degli
Agenti Mobili stessi, permettendo ad essi di migrare laddove vi è più possibilità che l’assoluzione del
servizio avvenga in tempi rapidi. In buona sostanza, aggiunge al servizio di migrazione la
consapevolezza del fatto che il nodo scelto sia il migliore per le politiche adottate.
Questa scelta ottimale del server di destinazione è operata, oltre che secondo una serie di politiche
definibili dall’utente tramite il Gestore delle Politiche, in base alla disponibilità o meno sul nodo
remoto di librerie e/o servizi necessari all’Agente Mobile per poter adempiere al suo compito. A tal
fine, il Gestore della Mobilità degli Agenti interrogherà il Gestore di Librerie e Servizi, informandosi
sulle risorse disponibili sui vari server in lizza per poter essere scelti come destinazione.
In sintesi questo componente, che a tutti gli effetti si potrebbe vedere come un servizio del Gestore
della Mobilità degli Agenti, ha il compito di reperire le informazioni aggiornate relative alle librerie e
ai servizi dei server appartenenti alla rete conosciuta (ma non solo: come vedremo nel capitolo 4.1,
vengono raccolte anche le informazioni dei “vicini” della rete conosciuta, permettendo agli Agenti di
uscire dal “mondo conosciuto” mantenendo però la scalabilità del progetto) senza appesantire le
comunicazioni di rete.
A tal fine, vengono supposti a disposizione due servizi tipici di un Application Server:
un servizio di discovery dei servizi della rete
un servizio di gestione del classpath delle librerie
In particolare, viste le specifiche tecnologiche di linguaggio Java e server JBoss, sarà sempre
presente il servizio JNDI (Java Naming and Directory Interface) poiché previsto dalle specifiche della
J2EE 1.4.
4.1 Comunicazioni per lo scambio e il reperimento delle informazioni
Per poter reperire tutte queste informazioni, il Gestore di Librerie e Servizi dovrà in qualche modo
comunicare con i server remoti. Utilizzando a tal fine direttamente i servizi di discovery e di gestione
del classpath delle librerie, il reperimento di informazioni potrebbe non essere facilmente attuabile in
maniera pulita. Ad esempio i server remoti potrebbero non permettere a richieste esterne di poter
manipolare il contenuto del classpath delle librerie, o ancora il servizio di discovery potrebbe non
restituire le informazioni corrette. A proposito di quest’ultimo punto, infatti, le specifiche del JNDI non
prevedono la visibilità della locazione dei servizi e, un’interrogazione diretta, potrebbe restituire, a
seguito di una richiesta della lista dei servizi locali, un lista contenete anche servizi che locali non sono,
ma che sono semplicemente stati inseriti come disponibili nelle tabelle del JNDI. È pertanto legittimo e
più pulito (nonché meno oneroso per il traffico di rete) utilizzare questi servizi attraverso il Gestore di
Librerie e Servizi omologo nel nodo remoto, il quale li ha comunque già a disposizione (eventualmente
con privilegi particolari assegnatigli dal suo server) assicurandosi di ottenere solo i servizi locali.
Scegliere di reperire queste informazioni attraverso il Gestore, potrebbe sembrare vincolante in
quanto, così facendo, si ridurrebbe la gamma di possibili server da scegliere come destinazione per gli
Agenti Mobili al solo sottoinsieme di quegli Application Server su cui risiede MAEAI. Tuttavia un
Agente, per poter migrare e lavorare su di un server, necessita di un’infrastruttura di supporto che lo
possa gestire, senza la quale il server non saprebbe come comportarsi a seguito dell’arrivo dell’Agente
Mobile. È pertanto lecito fare una scelta di questo tipo.
Per mantenere il funzionamento di questo componente scalabile con la dimensione della rete,
requisito fondamentale nel nostro progetto, è sufficiente notare che la piattaforma SOMA mantiene già
di per sé questa proprietà. È quindi sensato nonché utile utilizzare la struttura gerarchica delle reti
SOMA1 come base per reperire le informazioni necessarie sulle librerie ed i servizi della rete.
Seguendo questo ragionamento, si è deciso di strutturare ordinatamente il flusso delle informazioni
della rete secondo un ben preciso schema. In particolare la scelta è stata quella di far convergere le
informazioni dei servizi e delle librerie dei Place di tutto il Dominio sul nodo del DefaultPlace e di
diffondere e scambiare poi questo blocco di informazioni tra i DefaultPlace che si conoscono
reciprocamente. Parallelamente, sarà incarico del DefaultPlace di ogni Dominio fornire ai Place del
proprio Dominio le informazioni sul resto della rete conosciuta.
Lo schema seguente sintetizza i vari flussi di informazioni tra i nodi.
Figura 2 – Comunicazione tra Place
I particolari di come sono stati implementati questi meccanismi verranno affrontati nel capitolo
Implementazione del Progetto.
1
La gerarchia SOMA è strutturata secondo il concetto di Dominio: ogni Dominio consta di uno o più Place, i nodi logici
della rete, uno e uno soltanto dei quali viene eletto a DefaultPlace. Questo particolare nodo è l’unico del Dominio a
conoscere DefaultPlace di altri Domini rendendo la rete connessa e fungendo da “gateway”, mentre gli altri Place hanno una
conoscenza della rete limitata al Dominio di cui fanno parte.
4.2 Comunicazioni con l’Application Server
Il Gestore di Librerie e Servizi, come detto, si appoggia a due servizi garantiti dall’Application
Server sui cui risiede: il servizio di discovery dei servizi remoti e il servizio di gestione delle librerie
nel classpath. All’atto dell’avvio dell’applicazione della nostra piattaforma avviene il legame di questi
due servizi col nostro componente. Successivamente l’utilizzo di questi servizi avverrà direttamente,
senza passare attraverso l’Application Server.
4.3 Struttura del progetto
Il Gestore di Librerie e Servizi, sebbene considerato sin qui come un’entità unica, è logicamente
scomponibile in due parti facilmente individuabili dal nome: il Gestore delle Librerie
(LibrariesManager) e il Gestore dei Servizi (ServicesManager).
Strutturalmente, questi due componenti disgiunti sono molto simili per vari aspetti:
1. utilizzano ad uso esclusivo all’interno di MAEAI un servizio messo a disposizione
dall’Application Server ospitante
2. devono mantenere aggiornate delle informazioni riguardanti il nodo di residenza
3. devono mantenere aggiornate delle informazioni riguardanti la rete
4. devono rispondere a delle richieste riguardanti le informazioni gestite
Pertanto sono stati progettati e sviluppati con lo stesso concetto di fondo, sebbene presentino certune
differenze. Oltre ad utilizzare diversi servizi dell’AS, quindi gestibili in modo differente, le risorse di
cui mantengono aggiornate le informazioni (librerie in un caso, servizi nell’altro) hanno caratteristiche
molto diverse. Principalmente, mentre le librerie possono essere facilmente replicate sui vari nodi della
rete, i servizi sono più complessi da gestire: ad esempio, un servizio che accede ad una base di dati,
potrà sì essere replicato su di un altro server, ma, non avendo sul nuovo nodo la base di dati, non potrà
operare correttamente. In sostanza, la principale differenza tra librerie e servizi è che le prime possono
essere caricate e scaricate tra nodi remoti senza particolari accorgimenti, mentre le seconde non è
previsto possano venir replicate da MAEAI. Nel caso in cui il server si occupi della gestione di questa
replicazione, registrando il nuovo servizio in JNDI quest’ultimo sarà automaticamente riconosciuto dal
Gestore dei Servizi.
Figura 3 – Struttura di un generico Gestore
In Figura 3 si può notare come ciascuno dei due gestori mostri un’interfaccia esterna per poter
ricevere le richieste: richieste provenienti sicuramente dal Gestore della Mobilità degli Agenti, ma,
volendo, anche da un qualunque componente che ne abbia bisogno. Infatti, in linea teorica questa
interfaccia potrebbe anche essere registrata sul servizio di discovery JNDI ed essere utilizzata da nodi
remoti.
Le informazioni proprie del nodo e quelle della rete conosciuta, vengono mantenute all’interno del
Gestore e messe a disposizione in caso di richieste esterne. Per entrambi i tipi di informazioni sono stati
utilizzati dei thread per mantenere aggiornate queste tabelle:
nel caso delle informazioni locali, il thread è usato onde evitare ritardi dovuti al servizio
offerto dall’Application Server, ad esempio causati da code di richiesta sul servizio.
Utilizzando un flusso di controllo separato si evita a priori di bloccare l’intero gestore. In
questo modo anche in fase di aggiornamento delle informazioni, il Gestore è in grado di
rispondere a richieste esterne (ovviamente, per ragioni di consistenza, l’accesso in lettura e
scrittura delle informazioni contenute nel Gestore, riguardino esse il nodo locale o la rete, è
mutuamente esclusivo).
nel caso delle informazioni remote, benché, vista la scelta di gestione al punto precedente, non
ci dovrebbero essere ritardi significativi nel reperimento di informazioni di località sui nodi
remoti, è d’obbligo tenere in considerazione tutte le problematiche di rete che possano
influenzare le tempistiche di questo reperimento, quali ritardi di rete o problemi al server
remoto.
Oltre alle suddette ragioni, l’utilizzo di un thread separato ci permette di poter impostare un
comando ciclico di aggiornamento delle informazioni. Il periodo di questo aggiornamento è impostato
a default all’avvio dell’applicazione, ma può essere modificato ad applicazione avviata tramite
un’interfaccia visibile dal JMX. In aggiunta, l’aggiornamento delle informazioni può essere
direttamente comandato dall’amministratore del server (sempre tramite JMX).
L’utilizzo di due thread separati per ogni tipo di informazione, permette, oltre che di impostare
tempistiche diverse per l’aggiornamento ciclico, di mantener separati i due tipi di problematiche di
ritardo sopra descritte per le informazioni locali e per quelle remote trattando ciascuna
specificatamente.
4.4 Implementazione del Progetto
Vista la simmetria di struttura e comportamento tra il Gestore delle Librerie e il Gestore dei Servizi,
anche l’implementazione verrà trattata per un generico Gestore, specificando ove necessario le
differenze tra i due. In questo senso si parlerà di “risorse” riferendosi alle librerie od ai servizi in
conformità a quale Gestore fanno riferimento.
Sebbene i servizi offerti dall’Application Server di discovery dei servizi e di gestione delle librerie
non abbiano alcun riferimento al sistema di nomi SOMA, si è ritenuto corretto e pulito lavorare
all’interno della nostra piattaforma estesa ad Agenti Mobili col solo sistema di nomi SOMA. Per far
ciò, i due gestori trattati, unici interagenti con questi servizi dell’AS, si occuperanno di tradurre, ove
necessario, i nomi SOMA in indirizzi di rete (utilizzati da questi servizi) e viceversa.
4.4.1 Informazioni su risorse locali
Le informazioni sulle risorse locali sono mantenute in un insieme di valori concernenti il Place su
cui risiede il Gestore, in particolare in un HashSet<String>. Il set permette di evitare la replicazione di
valori all’interno dell’insieme nel caso si tenti di aggiungere una risorsa già presente e l’utilizzo delle
stringhe per rappresentare le risorse viene adottato in quanto String è la classe standard utilizzata per
rappresentare i servizi nel sistema di nomi JNDI (è possibile registrare i servizi anche tramite la classe
Name, ma passare da questa a String e viceversa è un’operazione semplice) ed è anche valida per poter
mantenere i nomi delle librerie Java del classpath.
L’aggiornamento di questa tabella avviene, come detto, tramite interrogazione del servizio dell’AS
relativo: il servizio di gestione delle librerie del classpath in un caso, il servizio di discovery nell’altro.
Tale aggiornamento viene di default invocato periodicamente da un thread ciclico (rispettivamente
UpdaterPlaceLibrariesTableThread e UpdaterPlaceServicesTableThread).
4.4.2 Informazioni su risorse remote
Tutte le informazioni sulle risorse remote sono mantenute in tabelle hash (Hashtable) per poter
essere reperite direttamente: in particolare, ad ogni chiave viene associato un insieme di valori (anche
in questo caso è stato scelto un HashSet, per le stesse ragioni sopra scritte e per omogeneità). In alcuni
casi è risultato comodo mantenere le stesse informazioni in due tabelle dal contenuto identico ma
interrogabili con chiavi differenti, a scapito della memoria occupata su disco ma a tutto vantaggio della
velocità (in ogni caso, memoria e velocità non vengono influenzate, negativamente o positivamente, in
maniera sensibile). Saranno quindi presenti due tabelle: una con chiave la stringa rappresentante la
risorsa e con valori l’insieme dei PlaceID rappresentanti i Place in cui questa risorsa è presente, e
un’altra con chiave il PlaceID e con valori l’insieme di stringhe rappresentanti le risorse presenti su
quel Place. In questo modo è possibile reperire direttamente sia le risorse di un dato nodo, sia i nodi in
cui vi è una data risorsa.
Vi è inoltre una terza tabella utilizzata solo dai DefaultPlace che mantiene, ordinati per chiave
PlaceID, i servizi di tutto il dominio facente capo a questo DefaultPlace. Questa tabella è utilizzata tra
DefaultPlace che si conoscono, come spiegato nel capitolo 2.1 e dalla Figura 1, per scambiarsi in
blocco le informazioni sulle risorse dell’intero dominio del quale si è referenti.
L’aggiornamento di queste tabelle, come per quella delle risorse locali, è comandato da un thread
del tutto simile all’altro, con la sola eccezione che, invece di reperire le informazioni direttamente dal
servizio offerto dall’Application Server, queste vengono richieste ai Gestori omologhi sui nodi remoti
mediante dei Command (descritti nel capitolo 4.4.3 Comunicazioni). L’aggiornamento di queste tabelle
avviene quindi al momento dell’arrivo delle informazioni inviate in risposta dai Gestori remoti.
Ovviamente, avendo qui due tabelle contenenti gli stessi dati, all’atto dell’aggiornamento sarà
mantenuta la sincronia tra le stesse, al fine di mantenere la consistenza dell’insieme d’informazioni.
4.4.3 Comunicazioni
Le comunicazioni tra i corrispettivi Gestori di nodi remoti avvengono sfruttando un meccanismo
fornito dalla piattaforma ad Agenti Mobili SOMA, ossia i Command2. In questo modo è possibile
mandare un Command nel nodo del quale si vuole un’informazione, fargli ottenere quest’informazione
in locale e fargliela rispedire al mittente tramite un altro comando. In particolare quest’altro comando,
una volta raggiunto il nodo richiedente i dati, si occuperà di aggiornare le tabelle locali con la nuova
informazione appena reperita.
L’utilizzo di un comando per ogni nodo del quale si vuole il blocco d’informazioni, porta ad
un’interessante proprietà dell’applicazione: l’aggiornamento delle tabelle locali, dunque, è effettuato
ogni qual volta ritorna uno e un solo comando, evitando ritardi lunghi dovuti a comandi ritardatari o,
peggio, blocco in caso di smarrimento di uno o più comandi. L’incremento del carico di lavoro dovuto
all’uso di un aggiornamento multiplo piuttosto che un singolo aggiornamento di tutti i dati, non è però
significativo visto che, per la struttura stessa delle tabelle, vengono interrogate e modificate solo quelle
righe relative al Place le cui informazioni sono state rinnovate. Le informazioni obsolete relative ai
nodi dei comandi non ritornati vengono perciò mantenute, mentre le informazioni dei nodi dei comandi
ritardatari, vengono aggiornate col relativo ritardo. Un’altra importante scelta effettuata a proposito dei
comandi, è stata quella di inserire nel codice del Command anche il codice del comando di ritorno: in
questo modo si sono potuti gestire anche casi quali l’invio in Place SOMA non più aventi a
disposizione sull’AS MAEAI, oppure quali l’invio da Place SOMA che fanno parte di un dominio il
cui DefaultPlace non abbia la nostra piattaforma. In tutti questi casi, dunque, l’anomalia viene gestita e,
salvo problemi di rete o mancanza dell’infrastruttura SOMA (peraltro necessaria per gestire gli Agenti
Mobili) il comando viene sempre rispedito al mittente.
Questo meccanismo di sicurezza garantisce, appesantendo un poco i comandi mandati sulla rete, una
certa risposta anche in alcuni casi sfavorevoli. A titolo d’esempio, nel caso in cui in un nodo venga
rimossa la nostra piattaforma, il comando ritorna con una lista di risorse vuota. In questo modo dalle
tabelle locali vengono rimosse le righe relative e dunque, successivamente, nessun Agente Mobile
verrà fatto migrare verso quel nodo finché il servizio non torni ad essere disponibile.
5
Conclusioni e sviluppi futuri
Il progetto M.A.E.A.I. integra su un Application Server un componente software in grado di gestire la
logica di una piattaforma ad agenti mobili affidando ad essa non solo il compito di permettere
l’esecuzione e la migrazione degli agenti, ma anche quello di costituire il tramite tra gli agenti e gli altri
componenti presenti sull’AS, incarnando politiche di gestione degli agenti.
In particolare il Gestore di Agenti Mobili realizza una migrazione consapevole degli agenti, scegliendo
per ognuno di essi la località migliore ove eseguire in funzione di precise considerazioni sulla località
delle risorse, sul carico e sulle politiche attuate dai Gestori omologhi.
Tuttavia, come descritto nelle relazioni, M.A.E.A.I. necessita, per alcune delle sue funzionalità,
dell’interazione con componenti che, come suggerito dalle specifiche, non sono stati implementati, ma
supposti come già realizzati: si renderà quindi necessaria, ad esempio, l’integrazione con un
componente in grado di calcolare, per un Application Server, i parametri relativi al fattore di carico
della macchina e il fattore di carico introdotto da un agente in esecuzione.
2
I Command sono in tutto e per tutto thread che, inviati ad un Place remoto tramite la funzione
sendCommand(PlaceID,Command) del NetworkManager di SOMA, incominciano l’esecuzione appena arrivati in loco.
Si deve supporre inoltre che l’AS offra un servizio a cui rivolgere circa le risorse disponibili e il
caricamento di librerie nel classpath, avendo M.A.E.A.I. opportuni protocolli di azione basati su di
esso.
Infine, il servizio JNDI messo a disposizione dall’AS dovrà fornire indicazioni aggiuntive relative alla
locazione dei servizi registrati, funzionalità necessarie per operare le scelte per la migrazione
consapevole degli Agenti Mobili.
Tra gli sviluppi futuri di M.A.E.A.I. si potrebbe prevedere di utilizzare agenti mobili come proxy di un
utente mobile, in grado quindi di memorizzarne informazioni quali sessione o profilo. Si consente in tal
modo la fruizione dei servizi dell’AS da parte di tale utente tramite la mediazione di un componente in
grado, ad esempio, di spostarsi sull’AS più vicino alla posizione dell’utente stesso.
Una possibile estensione, da valutare e gestire attentamente, potrebbe essere l’espansione e/o
l’aggiornamento della conoscenza della rete ad esempio tramite un agente per ogni place. Esso,
migrando di dominio in dominio, potrebbe reperire nuove informazioni di DNS e permettere in questo
modo l’aggiornamento della conoscenza della rete.
6
Appendice A – Diagramma delle classi
Gestore delle Librerie e dei Servizi
SOMA.network.connection.Command
DownloadLibraryCommand
RequestDomainServicesCommand
RequestDomainLibrariesCommand
DownloadLibrariesCommand
RequestGlobalServicesCommand
RequestGlobalLibrariesCommand
UploadLibraryCommand
RequestPlaceServicesCommand
RequestPlaceLibrariesCommand
UploadLibrariesCommand
SOMA.Environment
1
UpdateGlobalServicesTableThread
UpdatePlaceServicesTableThread
1
1
ServicesManager
1
UpdateGlobalLibrariesTableThread
11
1
UpdatePlaceLibrariesTableThread
1
LibrariesManager
IServicesManager
«interfaccia»
JNDI
ILibrariesManager
«interfaccia»
TransferManager
Figura 4 - Diagramma delle classi del Gestore delle Librerie e dei Servizi
