Mobile Agent andMobile Agent andEnterprise Architecture Enterprise Architecture IntegrationIntegration

Il gestore della mobilità degli agenti

Raffaelli Massimomatricola 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

AS

MAEAI

MobileAgent

MobileAgent

AS

MAEAI

MobileAgent

MobileAgent

Architettura logica di un nodo MAEAI

MAEAIChargeManager

MAEAIAgentManager

manageCharge()manageOverCharge()

manageAgentsForOverCharge()

MAEAIChargeManager extra dominio

MAEAIChargeManager intra dominio

command

command

command

ServicesManager LibrariesManager

hasService()findService()

hasLibrary()findLibrary()uploadLibrary()downloadLibrary()

MAEAIAgent

comm

and

comm

and

canAccept

migrate

MAEAIAgentManager

MAEAIAgentManager

Charge monitor

Policy

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

Default place

Default place

Non defaultPlaceNon default

Place

Non defaultPlace

Non defaultPlace

Non defaultPlace

Tabella di carico

Tabella di carico

Tabella di carico

Tabella di carico

Tabella di carico

Tabella di carico

Tabella di carico

Presenza di un gestore funzionante

Richiesta della tabella di carico

Gestore del carico - Dettagli

Carico fittizioFattore 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 dominioConoscenza 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

MobilePlace Application Server

MAEAI

SOMA

Place

Agente MAEAI

SERVIZIO BUSINESS

SOMA

SOMA

Place

Agente MAEAI

Agente MAEAI

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