Mobile Agent and
Enterprise Architecture
Integration
Il gestore della mobilità degli agenti
Raffaelli Massimo
matricola 0000171842
Obiettivi del progetto

Integrazione su un Application Server di una
piattaforma ad agenti mobili per la realizzazione
di:

Agenti come entità specializzate cui delegare
l’effettivo uso di servizi e la memorizzazione dei
risultati, sotto il controllo dei gestori.

Gestore come entità in grado di realizzare
migrazioni consapevoli degli agenti, in funzione
di considerazioni sulla località delle risorse, sul
bilanciamento del carico e sulle politiche attuate
da gestori omologhi.
Requisiti implementativi
Integrazione componente realizzato su
application server J2EE (JBoss).
 Uso di SOMA, piattaforma ad agenti mobili
realizzata dal DEIS e completamente
implementata in JAVA.
 Utilizzo del servizio di discovery JNDI.

Scelta del linguaggio JAVA
Application Server, gestori, agenti
Mobile
Agent
AS
AS
MAEAI
MAEAI
Mobile
Agent
Mobile
Agent
Mobile
Agent
Architettura logica di un nodo MAEAI
MAEAIAgentManager
MAEAIAgent
MAEAIAgentManager
mi g r
ate
and
m
m
canAccept
c o mm
co
an
d
hasLibrary()
findLibrary()
uploadLibrary()
downloadLibrary()
hasService()
findService()
ServicesManager
MAEAIAgentManager
LibrariesManager
Policy
manageAgentsForOverCharge()
MAEAIChargeManager
command
command
MAEAIChargeManager
intra dominio
MAEAIChargeManager
extra dominio
command
manageCharge()
manageOverCharge()
Charge monitor
L’Agente MAEAI - Struttura
Incapsula la business logic dell’applicazione
che utilizza l’infrastruttura MAEAI:
 Nozione
dei servizi e dei relativi parametri di
utilizzo.
 Librerie necessarie per la computazione.
 Strutture dati contenenti risultati parziali o
finali.
 Elenco di località preferite per la
esecuzione.
L’Agente MAEAI - Funzionalità
Funzionalità implementate:
 Comportamentali di base, e per l’ interazione
con il gestore degli agenti.
 Supporto per l’inizializzazione delle strutture dati
di base.
Funzionalità non implementate:
 Business logic finale. (fortemente dipendente
dall’applicazione specifica).
 Meccanismo per reperimento del fattore di
carico effettivo apportato sul server (servizio su
Application Server per assolvere tale compito).
L’Agente MAEAI - Comportamento

La prima operazione effettuata alla “nascita” o in seguito
alla migrazione su un nuovo nodo è la richiesta presso il
gestore locale di:




migrazione se per il servizio da utilizzare ha un luogo di
esecuzione preferito diverso dal corrente.
accettazione e reperimento del servizio nell’AS locale. In caso
di rifiuto procede alla richiesta di migrazione su eventuale altro
nodo preferito di esecuzione, o alla migrazione sul nodo indicato
dal gestore all’atto del rifiuto.
L’agente mantiene coerenti le informazioni circa il suo
stato di migrabilità e circa il prossimo servizio di cui
necessiterà durante la sua missione.
Se un agente riceve una richiesta di migrazione mentre
sta eseguendo un servizio in maniera non interrompibile,
migrerà non appena terminato l’uso di quel servizio.
Gestore del carico - Responsabilità

Informare il gestore degli agenti di situazioni
di sovraccarico: dati di carico o sovraccarico
ricevuti dal monitor del carico.

Mantenere informazioni di carico sui nodi
della rete conosciuti per poterle fornire al
gestore degli agenti a fronte di necessità di
migrazioni.

Informazioni sul carico sono fortemente
dinamiche legate all’esecuzione. Persistenza
non richiesta.
Gestore del carico - Scelte progettuali

Divisione della rete in località ai fini della scalabilità.
Senza località no scalabilità:



Eccessivo overhead in termini di messaggi di carico sulla rete,
in quanto spesso non è necessario avere l’informazione
aggiornata di ogni altro nodo della rete.
Informazione di carico fortemente distribuita: le tabelle di
carico possono aumentare a piacere, proporzionalmente ai nodi
della rete.
Località mappata con il dominio SOMA.



Dominio: come aggregazione di place vicini fisicamente o
logicamente (inter dominio comunicazione diretta).
Place: luogo di esecuzione degli agenti, astrazione di nodo della
rete in cui sono presenti risorse.
Place di default: place che fa da anche da ponte di
collegamento tra il dominio e altri domini.
Gestore del carico - Scelte progettuali


Informazione aggiornata per nodi inter dominio;
meccanismo a notifica dai vari gestori (pool di
connessioni SOMA sempre disponibili).
Conoscenza parziale sui nodi all’esterno del dominio,
legata alla parziale visibilità di altri domini del place di
default. Polling per limitare numero di messaggi
scambiati.



Place di default: polling sui domini conosciuti per richiesta
tabella di carico di dominio.
Place non di default: polling su place di default per richiesta
tabelle di carico domini conosciuti
Polling a frequenza minore rispetto a quella di monitoraggio:
informazione meno aggiornata e meno attendibile. Si suppone
che pur cambiando rapidamente il fattore di carico, ciò non valga
però per la condizione di macchina carica/scarica.
Gestione del carico extra dominio
Non default
Place
Non default
Place
Tabella di
carico
Tabella di
carico
Tabella di
carico
Non default
Place
Default place Tabella di
carico
Tabella di
carico
Default place
Presenza di un gestore funzionante
Richiesta della tabella di carico
Non default
Place
Tabella di
carico
Non default
Place
Tabella di
carico
Gestore del carico - Dettagli

Carico fittizio
Fattore di carico per un nodo costituito da somma di due
componenti: fattore di carico reale, notificato dal monitor, e
fattore di carico fittizio (pesato), tiene conto di una sorta di “soft
state” creato dalle prenotazioni per migrazioni di agenti da parte
di gestori di agenti remoti.

Espansione conoscenza extra dominio
Conoscenza extra dominio fortemente legata a configurazione
dell’infrastruttura SOMA impostata staticamente.
Possibilità in futuro di espandere le tabelle DNS del place di default
a tempo di esecuzione in base a criteri.

Comandi SOMA e assenza di gestori
Comunicazione avviene mediante comandi SOMA, entità inviate in
remoto e dotate di un flusso di esecuzione autonomo specifico.
Gestita la possibilità di mancanza di gestori MAEAI su place di
default o non di default mediante comandi specifici.
Gestore degli agenti - Responsabilità



Accogliere o meno agenti sul nodo locale, e in questo
secondo caso ordinarne la migrazione su un altro nodo.
Decidere se consentire migrazioni dal nodo locale di
agenti che ne fanno richiesta.
In caso di sovraccarico della macchina, ordinare la
migrazione di agenti che eseguono sul nodo locale.
Gestione di tutti gli aspetti riguardanti la mobilità degli
agenti (cambiamento di prospettiva rispetto al
paradigma classico degli agenti mobili)
Il gestore degli agenti incapsula un meccanismo.
Per le decisioni si coordina con il gestore delle migrazioni
che realizza le politiche.
Gestore degli agenti - Accettazione

Richiesta di accettazione locale

Accettazione agente sulla base di:



presenza del servizio specifico.
decisione presa dal gestore delle migrazioni sulla base del
fattore di carico del nodo e dell’apporto al carico dato
dall’agente stesso.
No considerazioni su dati di carico o di località di risorse
riguardanti altri nodi della rete. Cause migrazione:



Invio da altro nodo (es. sovraccarico).
Invio diretto (es. da strato più alto del livello applicativo,
migrazione su iniziativa dell’agente).
Le politiche non consultate se agente presente nella
lista di prenotazione del nodo. (V.di meccanismo
prenotazione).
Gestore degli agenti - Accettazione

Richiesta di prenotazione da remoto


Richiesta da gestore remoto della disponibilità ad
accettare un agente. In caso positivo il gestore
locale mantiene questa informazione.
Decisione presa in base alle informazioni di carico
del nodo e all’apporto al carico dato dall’agente:

Scelta globale fatta dal gestore remoto.
Gestore degli agenti - Migrazione

Reazione a condizione di sovraccarico



Per ogni agente in esecuzione, prenotazione su
ogni nodo con il servizio richiesto che si rende
disponibile ad accettare l’agente.
Informazioni passate al gestore delle migrazioni:
agenti in esecuzione, dato di carico nodo corrente,
dati di carico nodi conosciuti, insieme di place con il
servizio disponibili ad accettare l’agente.
Associazione dapprima con nodi del dominio…




Informazione di carico più recente
Probabile vicinanza fisica, ad esempio rete locale
…poi eventualmente con nodi extra dominio.
Invio dell’agente sul nodo destinazione previo invio
librerie necessarie.
Gestore degli agenti - Dettagli
Meccanismo di prenotazione


Prenotazione con soft state sul nodo destinazione e somma al
fattore di carico del nodo un fattore di carico fittizio dovuto all’agente.
Risposte attese e considerate entro un timeout.
Interrogazione concorrente di più nodi permette:
migliore capacità di reazione al sovraccarico (meno tempo)

migliore visione globale per le politiche (conoscenza globale)
…ma altera fattore di carico di una molteplicità di gestori. Soluzione:

Carico fittizio pesato in base ad un indice (es. dipendente da probabilità
di scelta del nodo o di arrivo dell’agente dopo una migrazione).

Disdette prenotazioni su nodi scartati -> durata minima per soft state


Allineamento delle librerie


Upload concorrente librerie in caso di migrazione.
Download concorrente delle librerie mancanti per l’esecuzione sul
nodo corrente.
Conclusioni

Affidabilità: l’infrastruttura SOMA deve essere
affidabile in termini di persistenza dei dati e degli
agenti (es. integrazione come servizio in un cluster).

Sicurezza: aspetti legati alla sicurezza sono
delegati a SOMA che supporta, al suo livello,
confidenzialità ed autenticazione: protezione place
da agenti malintenzionati e viceversa.
MAEAI e applicazioni enterprise
Agente
MAEAI
Agente
MAEAI
MAEAI
Place
Agente
MAEAI
SOMA
Mobile
Place
Application Server
SERVIZIO BUSINESS
SOMA
Place
SOMA
• La creazione di un agente
MAEAI deve avvenire su un
nodo in cui sia presente un
gestore.
• Agenti diversi possono
essere istanziati da un
servizio del livello
applicativo superiore a
seconda della business
logic che realizzano per
esso.