Mobile Agent and Enterprise Architecture Integration Il gestore della mobilità degli agenti Raffaelli Massimo matricola

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 AS MAEAI Mobile Agent Mobile Agent AS MAEAI Mobile Agent Mobile Agent

Architettura logica di un nodo MAEAI

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

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 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.