Mobile Agent and Enterprise Architecture Integration Agent and... · 1 Introduzione La rapida...

Mobile Agent and Enterprise Architecture IntegrationFulvio Di Marco – 196007

Reti di Calcolatori LS – Prof. Antonio Corradi – A.A. 2006/2007Referente Progetto: Samuele Pasini

Abstract

Il progetto consiste nella integrazione in seno ad un

Application Server (AS) di una piattaforma ad agenti mo

bili (AM) in grado di espletare non solo funzioni di esecu

zione e migrazione (così come previsto dal paradigma ad

agenti mobili stesso), ma anche di rappresentare un con

tainer per gli agenti totalmente integrato in un contesto

enterprise e attraverso il quale essi possano fruire dei

servizi tipicamente disponibili (servizi applicativi, COR

BA, servizi di naming e directory, servizi di messaggisti

ca, soluzioni per la gestione e il monitoraggio). Parimenti

si è realizzata un'implementazione di differenti qualità di

agenti in grado di eseguire e sfruttare i servizi offerti dal

nuovo ambiente perseguendo prestabiliti obiettivi e sotto

stando a precise politiche di migrazione.

1 Introduzione

La rapida espansione delle reti di calcolatori su larga scala

negli ultimi decenni ha incentivato molti fornitori di ser

vizi nella ricerca di nuove forme di comunicazione per ve

nire incontro ai bisogni dei clienti. In tale scenario a gra

diente di distribuzione crescente è parimenti diventata

pervasiva l'idea di riappropriarsi in parte di paradigmi di

computazione centralizzati orientandosi verso modelli al

trettanto centralizzati di erogazione di servizi ad una mol

teplicità di utenti in maniera efficiente, affidabile e scala

bile.

Lo sviluppo, tipicamente all'interno di organizzazioni di

grandi dimensioni, di componenti enterprise capaci di for

nire funzionalità di tipo business e la necessità di offrire

garanzie relativamente a integrità di dati e codice, confi

gurazione, sicurezza e prestazioni, ha oltremodo indiriz

zato il settore verso l'adozione di framework component

based (application servers) in grado di offrire servizi

middleware cui affidare la gestione di alcuni aspetti delle

applicazioni quali, ad esempio, persistenza dei dati, ge

stione delle risorse del sistema, transazionalità delle ope

razioni o bilanciamento del carico.

Obiettivo del presente progetto è ovviare alla mancanza di

un componente software collocabile in un contesto enter

prise in grado di gestire la logica di una piattaforma ad

agenti mobili.

Concorrentemente allo sviluppo di una conoscenza di

base dei componenti enterprise tipicamente in esecuzione

su un AS, obiettivi del progetto sono:

• l'estensione della piattaforma ad agenti mobili

SOMA come parte integrante dell’infrastruttura

costituita dall’AS in maniera tale che possa:

• esporre le proprie funzionalità in modo uni

forme a quelle degli altri servizi;

• garantire agli agenti mobili eseguiti gli stessi

meccanismi e servizi normalmente disponi

bili come piattaforma standalone;

• comunicare con piattaforme omologhe in

esecuzione su altri AS al fine di costruire il

Mobile Agent and Enterprise Architecture Integration 1

dominio di mobilità in cui gli agenti potran

no operare.

• la realizzazione di agenti mobili osservatori in

grado di eseguire nello stesso ambiente dell’AS e

sfruttare i servizi da esso esposti; tali agenti do

vranno, in particolare, esplorare ciclicamente

l’intero dominio di mobilità raccogliendo infor

mazioni circa lo stato, le risorse e i servizi di

ogni AS raggiunto.

Nel paragrafo 2 verranno brevemente esposti i vincoli tec

nologici che si è ritenuto imporre al progetto sia con l'in

tento di indirizzarne e semplificarne lo svolgimento sia di

rendere possibile il riutilizzo dei risultati raggiunti.

Nel paragrafo 3 verrano esposti i risultati delle fasi di ana

lisi, progettazione e implementazione dell'architettura del

la piattaforma enterprise per agenti mobili.

Il paragrafo 4 sarà dedicato ad una analisi delle scelte ar

chitetturali e dei modelli di comunicazione adottati nel

l'ottica di estendere i nativi sistemi di nomi della piattafor

ma ad agenti originaria sfruttando API di comunicazione

più ricche e potenti offerte dall'AS.

Il paragrafo 5 prenderà in esame una delle due differenti

qualità di agenti mobili (agenti mobili osservatori) di cui è

richiesta la realizzazione.

I paragrafi 6 e 7 saranno, infine, dedicati a conclusioni e

considerazioni finali sullo stato del progetto e ad un anali

si di potenziali scenari di sviluppo futuri.

2 Aspetti tecnologici

• Secure and Open Mobile Agents (SOMA);

• JBoss AS;

• Java Management Extensions (JMX);

• Enterprise Java Beans 3.0;

2.1 Agenti Mobili

In un contesto di rapido e intensivo sviluppo di sistemi e

applicazioni sempre più orientate alla distribuzione su lar

ga scala e le cui specifiche di scalabilità sempre più diffi

cilmente trovano una soddisfacente risposta nell'utilizzo

di tecniche classiche di soluzione basate sul modello di

programmazione client/server, il paradigma ad Agenti

Mobili apre un nuovo scenario offrendo un approccio più

intuitivo nella progettazione e realizzazione di applicazio

ni distribuite.

La capacità unica di un agente di spostarsi in maniera au

tonoma all'interno di ambienti distribuiti alla ricerca delle

condizioni che gli consentano di espletare un task prefis

sato, integrandosi con le risorse locali e cooperando con

altri agenti, introduce notevoli benefici specialmente in

tutti gli scenari applicativi che possano trarre vantaggio

da astrazioni di località nell'accesso alle risorse, da se

mantiche di interazione con l'utente asincrone e da capaci

tà di trasferimento dinamico di comportamento, informa

zioni e stato.

A differenza dei paradigmi di Remote Evaluation e Code

On Demand in cui l'attenzione è rivolta allo spostamento

di codice fra componenti in esecuzione, nel modello ad

agenti è il componente stesso che è capace di rilocarsi,

trasportando i propri dati, codice e stato di esecuzione e

fornendo quindi la possibilità di offrire servizi flessibili,

facilmente espandibili e adeguabili alla dinamicità della

rete.

La struttura topologica della rete non deve essere traspa

rente alle applicazioni, ma deve poter essere rappresentata


in modo uniforme, trascendendo i particolari e consenten

done un utilizzo semplice e standardizzato. Analizzando

la topologia delle reti di grandi dimensioni si può conve

nire sulla loro struttura gerarchica, organizzata secondo

un incapsulamento verticale di domini e sottodomini,

fino a giungere agli host finali. Un modello ad agenti mo

bili dovrebbe quanto più astrarre dal concetto di nodo av

valendosi di contesti di esecuzione non strettamente legati

alla macchina fisica; in ciascun nodo possono quindi esi

stere uno o più place, sintetizzabili come contesti in cui

gli agenti eseguono ed interagiscono con i servizi e risor

se disponibili; ciascun place afferisce ad un dominio,

identificabile con una località reale o con una caratteristi

ca logica.

Illustrazione 1: Astrazioni di località per agenti mobili.

2.1.1 SOMA

Realizzato presso il Dipartimento di Elettronica Informa

tica e Sistemistica (DEIS) della Facoltà di Ingegneria In

formatica dell'Università di Bologna, SOMA (Secure and

Open Mobile Agents) è un framework per applicazioni ad

agenti mobili implementato interamente in linguaggio

Java e fedele alle caratteristiche fisionomiche salienti di

un sistema ad agenti mobili:

• scalabilità: suddivisione degli ambienti di esecu

zione degli agenti nei due livelli logici di Normal

Place e Dominio; possibilità di inserimenti dina

mici di nuove località senza danneggiare la strut

tura globale creata in precedenza; limite del nu

mero degli agenti presenti nel sistema imposto

solo dalle risorse hardware; SOMA introduce il

concetto di Default Place: unico all'interno di un

Dominio (del cui nome è portatore), rappresenta

l'astrazione di un centro di servizi di basso livello

e funge da gateway fra la rete locale e il mondo

esterno; esso ha una conoscenza completa dei

place appartenenti al dominio mentre ha solo una

visione parziale della topologia dell’intero siste

ma; l’insieme dei Default Place è totalmente

connesso, ed in questo modo i Domini sono tutti

collegati fra loro; ciò rende il grafo formato da

tutti i Normal Place di tutti i Domini, non total

mente, ma semplicemente connesso, nel senso

che per ogni coppia di place è sempre possibile

trovare un cammino che li congiunga.

• portabilità: compatibilità assoluta con la JVM

standard;

• apertura: CORBAcompliant, OMGcompliant;

• mobilità (debole): dipendente dalla scelta di Java

che impedisce per motivi di sicurezza l'accesso

allo stack di esecuzione di un thread rendendone

impossibile il ripristino in seguito, ad esempio,

ad una serializzazione; la suddivisione del flusso

di esecuzione degli agenti in moduli da eseguire

nei diversi ambienti in cui migrano non costitui

sce limite significativo all'espressività del model

lo.

• comunicazione: scambio di messaggi, condivi

sione di risorse, comunicazione anonima;

• sicurezza: utilizzo di algoritmi crittografici per

proteggere place e agenti e risolvere problemati


che di riservatezza, integrità e paternità;

2.2 Application ServerA partire dalla seconda parte degli anni Novanta è diven

tata sempre più diffusa la convinzione e la conseguente

tendenza a migrare nuovamente verso un modello di com

putazione centralizzato e di fornire servizi, tipicamente

webbased, ai singoli clienti. In tale ottica, un application

server può quindi essere pensato come un framework

componentbased capace di raggruppare ed armonizzare

un insieme di servizi middleware e facility per la gestione

di aspetti come sicurezza, accesso dati, transazionalità e

persistenza sollevando gli sviluppatori da tali responsabi

lità e velocizzando quindi sviluppo, integrazione, deploy e

gestione di applicazioni verticali multitier distribuite.

2.2.1 JBoss ASJBoss AS è un application server open source rilasciato

sotto licenza LPGL pienamente conforme allo standard

Java 2 Enterprise Edition (J2EE), standard per lo sviluppo

di applicazioni Java serverside e per l'implementazione di

architetture enterpriseclass serviceoriented (SOA) e

applicazioni web di nuova generazione.

Architetturalmente si sviluppa attorno ad un Microkernel

Service Oriented e JMXBased, dando vita un modello a

componenti leggeri che definisce in maniera precisa non

solo ciclo di vita, configurazione e gestione dei servizi,

ma fornisce anche un meccanismo standard per l'assem

blaggio di componenti che garantisce accesso, gestione e

integrazione dei servizi in maniera uniforme e consisten

te.

Si elencano alcune caratteristiche salienti di JBoss AS di

interesse per il progetto includendo riferimenti a elementi

della bibliografia per ulteriori approfondimenti personali:

• piena compatibilità con le specifiche e con il mo

dello di programmazione Enterprise Java Beans

3.0 (EJB 3.0) che costituisce una forte semplifi

cazione delle precedenti API EJB; [7] [8]

• JBossMQ: JMS provider pienamente compatibile

con le specifiche JMS 1.1 per fornire un modello

distribuito e asincrono di messaggistica e orien

tato alla QOS (persistenza, guaranteed delivery,

transazionalità, clustering); [2]

• Web Application Services, CORBA, Security

Services, High Availability Services, O/R Map

ping e Persistence Services; [5] [6]


Illustrazione 2: J2EECompliant Application Server

3 Architettura della piattaforma enterprise

per agenti mobili

Affinché i componenti mobili sviluppati nell'ambito del

progetto possano operare all'interno dell'ambiente di ese

cuzione tipico di un AS, il framework utilizzato per l'ese

cuzione degli agenti deve:

• essere reso disponibile come parte integrante

dell'infrastruttura ospitante;

• figurare, quindi, fra i servizi messi a disposizio

ne dall'AS;

• esporre analogamente ed uniformemente a tali

servizi le proprie funzionalità;

• comunicare con piattaforme omologhe in esecu

zione su altri AS al fine di costruire il dominio di

mobilità in cui gli agenti possono operare.

Un aspetto pervasivo e caratterizzante di tutta la fase di

analisi del progetto è stato quello di orientare la progetta

zione verso la realizzazione di componenti wrapper degli

Environment SOMA capaci di offrire un nuovo ambiente

totalmente cablato in una logica enterprise, ma con la as

soluta priorità di mantenere tutti i servizi previsti dalla

piattaforma SOMA originale e garantendo quindi la piena

compatibilità per gli agenti pensati e implementati per

l'ambiente standalone.

Dovendo tale piattaforma figurare fra i servizi messi a di

sposizione dall'AS ed essendo JBoss AS architetturalmen

te concepito attorno ad un MBean Server JMX che gioca

il ruolo di un microkernel per consentire l'aggiunta di

componenti e risorse, si è deciso di suddividere la logica

della piattaforma ad agenti mobili in una serie di compo

nenti MBean. Questa scelta ha consentito di sfruttare in

pieno le potenzialità di tale framework offrendo la possi

bilità di fruire, ad esempio, dei meccanismi di notifica di

JMX o di interfacciare i componenti della piattaforma con

gli Invocation Layer Services di JBossMQ, servizi respon

sabili della gestione dei protocolli di comunicazione che

singoli client usano per spedire e ricevere messaggi.

Tutti gli MBean espongono una interfaccia che ne consen

te configurazione e monitoraggio a runtime.

La piattaforma è architetturalmente strutturata in tre

MBean, più un quarto con funzioni di simulazione del ca

rico della macchina per finalità di testing:

• SomaInitServiceMBean: dedicato alla fase di

bootstrap, ha la responsabilità di inizializzare e

configurare gli altri MBean della piattaforma.

• EnterpriseDefaultPlaceMBean/Enterprise

NormalPlaceMBean: costituiscono la parte più

importante della piattaforma e racchiudono gran

parte della logica del sistema. Entrambi incapsu

lano un'istanza della piattaforma SOMA origina

le.


Illustrazione 3: Visione architetturale di JBossAS.

Illustrazione 4: Architettura della piattaforma enterprise per agenti mobili.

3.1 SomaInitServiceMBean

A questo MBean, singleton all'interno dell'AS, è intera

mente delegata la fase di bootstrap della piattaforma. Esso

si occupa di:

1. effettuare il parsing di un file XML contenente

parametri di configurazione della piattaforma ad

agenti mobili e la topologia dei place.

2. istanziare, inizializzare e registrare presso l'M

Bean server tutti gli MBean relativi ai default

place della topologia.

Questa fase comprende:

1. la creazione e l'inizializzazione di un Envi

ronment SOMA;

2. la creazione di una classe wrapper dell'Envi

ronment SOMA;

3. la creazione e la configurazione (tramite

Destination Manager, servizio centrale di

JBossMQ) delle code JMS per il servizio di

MigrationManager, per servizi generici, per

il domainlevel logging, per il forward dei

messaggi interdominio e del topic JMS per

il servizio di nomi Enterprise Place Name

Service.

4. la creazione di una coda pubblica presso

l'host di centro stella JMS, utilizzata per lo

scambio di messaggi interdominio (in loca

lhost nella versione di testing vedi Comu

nicazioni);

5. la creazione e la registrazione del MBean

del default place.

3. istanziare, inizializzare e registrare presso l'M

Bean server tutti gli MBean relativi ai place nor

mali della topologia.

Questa fase comprende:

1. la creazione e l'inizializzazione di un Envi

ronment SOMA;

2. la creazione di una classe wrapper dell'Envi

ronment SOMA;

3. la registrazione (mediante RMIAdaptor)

presso il default place del dominio di appar

tenenza;

4. la creazione e la registrazione del MBean

del place.

4. creare (mediante service descriptor XML) coda e

topic per il servizio di nomi Enterprise Domain

Name Service, presso l'host di centro stella JMS

(in localhost nella versione di testing vedi Co

municazione).


3.2 EnterpriseDefaultPlaceMBean, Enter

priseNormalPlaceMBean

Questa coppia di MBean costituisce il core della piattafor

ma ad agenti mobili inglobando gran parte della logica

dell'intero sistema e incapsulando un Environment

SOMA; ciò garantisce quindi da un lato piena backport

compatibility per gli agenti, dall'altro offre ad essi tutti i

servizi pensati per il nuovo ambiente.

L'esposizione di una interfaccia secondo un pattern prede

finito consente al JMX Agent (in JBossAS accessibile

mediante un HTML Adaptor) di eseguire operazioni di

configurazione e controllo sugli MBean.

La classe astratta EnterprisePlace viene estesa sia dalla

classe dedicata ai Default Place che dalla classe dedicata

ai Normal Place e fornisce una implementazione di base

di tutti i place.

Tale classe si occupa di:

• fornire un'implementazione dei metodi dell'inter

faccia JMX EnterprisePlaceMBean;

• creare e registrare in JNDI le interfacce di servi

zio (EnterprisePlaceService) che consentono

agli agenti di usufruire dei servizi offerti dal pla

ce che li ospita;

• gestire la connessione con il server JMS;

• gestire il ciclo di vita del place : avviare, sospen

dere e terminare in modo ordinato tutti i sottosi

stemi principali (ovvero SOMAEnvironment e

MigrationManager).

Ciascun MBean si interfaccia al Notification Framework

messo a disposizione da JMX che fornisce meccanismi di

callback per listeners interessati a ricevere notifiche a se

guito di eventi, cambiamento di stato o informazioni stati

stiche da parte di altri MBean. Nell'ottica di sviluppare

opportuni protocolli di azione, ciò consente di ricevere da

un ulteriore MBean (SystemChargeSimulator) notifiche ad

ogni cambiamento dello stato delle risorse di calcolo di

sponibili presso l'host.

4 Comunicazione

Nell'ottica di fornire ad agenti e place i servizi, i paradig

mi e le semantiche di comunicazione tipici di un Message

Oriented Middleware (MOM), la piattaforma ad agenti fà

uso dei servizi offerti da JBoss Messaging (JBossMQ),

implementazione pienamente conforme alle specifiche

JMS.

Nelle successive sezioni verranno esaminate le scelte fatte

inerentemente ai modelli e ai protocolli di comunicazione

adottati.

L'integrazione del framework SOMA in un contesto enter

prise ha reso necessaria l'estensione dei nativi sistemi di

nomi di dominio (PNS) e di interdominio (DNS) sfrut

tando API di comunicazione più ricche e potenti offerte

dall'AS; tali scelte architetturali, che non alterano le ipote

si di località dei sistemi ad agenti e di SOMA in particola

re, sono premesse necessarie per poter affrontare tutta una

serie di problematiche inerenti alla distribuzione su larga

scala; fault tolerance, scalabilità, bilanciamento di carico

e QOS non sono state affrontate direttamente nell'ambito

di questo progetto (poiché non richiesto dalle specifiche),

ma non sono state trascurate in fase di analisi rendendo

possibile una loro trattazione in futuri sviluppi.

La piattaforma SOMA originale soffre intrinsecamente

della presenza di single point of failure localizzati nei de

fault place di dominio per quanto riguarda i servizi di


nomi PNS e DNS. La decisione di impiegare nel progetto

architetture centralizzate a stella può, inizialmente, far

pensare ad un ulteriore aggravamento delle capacità di

fault tolerance del sistema. Nonostante tale aspetto esulas

se dagli scopi del progetto, il single point of failure di cui

è affetta la piattaforma SOMA può ora avvalersi in manie

ra forte dell'integrazione con la piattaforma enterprise,

come ad esempio della possibilità di depositare messaggi

in maniera persistente in un database relazionale usando

Java Database Connectivity (JDBC) o della possibilità dei

message server di operare in un cluster localizzato su di

verse macchine, apparendo ai client come un singolo ser

ver logico. Un provider JMS può infatti risolvere il pro

blema di un single point of failure distribuendo le connes

sioni fra molteplici server operanti nel cluster; in caso di

caduta di un servitore, gli altri possono continuare ad ope

rare normalmente minimizzando quindi l'impatto del gua

sto. Possono essere inoltre implementate logiche di ricon

nessione nei singoli client che potrebbero cercare un nuo

vo server qualora il server al quale si sono inizialmente

connessi dovesse non essere più reperibile.

Message server operanti in cluster possono anche intelli

gentemente instradare messaggi verso altri server, offrire

persistenza in caso di guaranteed messages, aggiungere

servizi sicuri basati su Access Control List, assicurando

consegna dei messaggi esclusivamente a chi ne detiene di

ritto.

Per tutte le comunicazioni, siano essere afferenti al mo

dello publish/subscribe o al modello pointtopoint, è stata

scelta una semantica asincrona di tipo catch&return avva

lendosi dell'AUTO_ACKNOWLEDGE mode fornito dal

protocollo di acknowledge delle API JMS; l'acknowledge

ricevuto dal produttore non è direttamente correlato alla

avvenuta consegna del messaggio al destinatario, bensì si

gnifica che il server si è assunto totale responsabilità di

consegna del messaggio. Il processo di acknowledge sot

tostante è totalmente trasparente al client che può così

continuare la propria esecuzione senza bloccarsi in attesa

dell'effettiva consegna.

Illustrazione 5: JMS message autoacknowledgment protocol.

4.1 Sistemi di Nomi Enterprise e Comunica

zioni InterDominio

4.1.1 Enterprise Place Name Service

Analogamente a quanto accade nel framework SOMA ori

ginale, tutti i place appartenenti allo stesso dominio devo

no potersi conoscere vicendevolmente al fine di poter dia

logare e concordare la migrazione di agenti.

Si è scelta quindi una topologia a stella che prevede il de

fault place al centro e i place normali alle estremità ed è

stato scelto come modello di messaggistica un modello di

tipo publish/subscribe; i messaggi, pubblicati dal default

place su un apposito topic di dominio, vengono automati

camente consegnati in broadcast dal provider ai singoli


normal place sottoscritti senza che essi debbano singolar

mente e attivamente richiederne il prelievo.

Al momento della creazione di un MBean incapsulante la

logica di un normal place, la procedura di inizializzazione

della piattaforma ne richiede la registrazione (tramite

RMI Adaptor) presso l'MBean del default place di domi

nio il quale dopo aver inserito le informazioni relative al

nuovo place entrante nel proprio dizionario locale si occu

pa di inviare ad esso un RegistrationResult contenente, ol

tre a semplici informazioni di nomi, anche JMS admini

stered objects per vari servizi ed una copia della tabella di

PNS locale.

Le informazioni del nuovo place entrante vengono poi

pubblicate dal default place mediante un messaggio

(PNS_REGISTER) sull'apposito topic di dominio di modo

che tutti i normal place precedentemente registratisi pres

so il dominio possano aggiornare la propria tabella di

PNS locale.

Dualmente, la deregistrazione di un place avviene me

diante una richiesta presso il default place di dominio cui

segue la pubblicazione sul topic di dominio di un messag

gio (PNS_UNREGISTER) contenente il nome del place.

Illustrazione 6: Enterprise Place Name Service: registrazione e aggiornamento.

4.1.2 Enterprise Domain Name Service

In maniera del tutto analoga, anche i default place sono

connessi mediante una rete JMS a stella al fine di consen

tire comunicazioni e migrazioni interdominio. A tale sco

po, essi mantengono connessioni con un ulteriore provider

JMS (in fase di testing della piattaforma si è considerato

lo stesso JMS provider dell'AS su cui è localizzato il de

fault place radice dell'albero gerarchico dei domini); pres

so tale provider è stata prevista una coda per la comunica

zione P2P con il root DNS (DNSRootQueue) in fase di re

gistrazione e deregistrazione (DNS_REGISTER /

DNS_UNREGISTER) ed un topic utilizzato dal root DNS

(DNSEventsTopic) per propagare a tutti i default place

precedentemente registrati (e quindi sottoscritti a tale to

pic) una copia aggiornata del dizionario contenente la to

pologia di tutti i domini attualmente conosciuti

(DNS_REFRESH).


Illustrazione 7: Enterprise Domain Name Service: registrazione e aggiornamento.

4.2 Comunicazioni interdominio

Ciascun default place implementa una coppia di Forward

Unit (Incoming Forward Unit e Outgoing Forward Unit)

dedicate alle comunicazioni interdominio e capaci di for

nire ai place appartenenti al dominio e agli agenti stan

zianti presso di essi un meccanismo di invio messaggi as

solutamente trasparente alla locazione.

Ciascuna Outgoing Forward Unit è adibita allo smista

mento del traffico in uscita verso altri domini; preleva

messaggi da una forward queue di dominio e, previa

estrazione del contenuto informativo di un header dedica

to al forward (contenente i nomi di place e dominio di de

stinazione), è in grado di selezionare facendo uso del Do

main Name Service locale la coda pubblica del dominio

di destinazione dislocata presso il nodo di centro stella.

Dualmente, ciascuna Incoming Forward Unit preleva i

messaggi dalla coda pubblica di dominio dislocata presso

il nodo di centro stella e tramite la lettura dell'header e la

consultazione del Place Name Service locale spedisce il

messaggio alla coda privata del place destinatario.

Illustrazione 8: Forward Units dedicate alle comunicazioni interdominio.

5 Agenti Mobili

Le specifiche richiedono la realizzazione di due differenti

qualità di agenti mobili, entrambe in grado di eseguire

nello stesso ambiente dell'AS e di sfruttare i servizi da

esso esposti:

• agenti mobili regolati, con capacità di esecuzio

ne autonoma e di migrazione (sia autonoma sia

regolata dal gestore degli agenti consistentemen

te alle politiche da esso attuate;)

• agenti mobili osservatori, con funzioni di esplo

razione ciclica dell’intero dominio di mobilità

raccogliendo informazioni circa lo stato, le risor

se e i servizi di ogni AS raggiunto.

Nell'ambito di questa relazione si discuterà degli agenti

mobili osservatori.

5.1 Agenti Mobili Osservatori

Sono stati realizzati due tipi di agenti osservatori: agenti

osservatori intradominio ed agenti osservatori interdo


minio. Del tutto affini logicamente, essi differiscono

esclusivamente per il dominio di mobilità all'interno del

quale eseguono ciclicamente migrazioni.

Attualmente la selezione della destinazione avviene con

una politica molto semplice e decisamente fair mediante

estrazione da una lista circolare.

Responsabilità di tali agenti è quello di raccogliere ad

ogni place raggiunto informazioni circa lo stato delle ri

sorse (ad esempio il carico corrente di CPU, rete e memo

ria) e i servizi disponibili e di distribuire tali conoscenze a

tutti i place facenti parte del dominio di mobilità, mante

nendo quindi una sorta di soft state distribuito di tali in

formazioni.

L'interrogazione delle informazioni avviene mediante l'in

terfaccia di servizio esposta da ciascun place; ciascuna in

terrogazione determina la restituzione all'agente di un re

soconto dello stato dell'AS sul quale è dislocato il place

affiancato da un numero di versione gestito da un contato

re locale al place. L'agente mantiene un dizionario perso

nale in cui a ciascun place visitato sono associate le infor

mazioni prelevate a seguito dell'ultima interrogazione,

correlatamente al numero di versione.

Ad ogni salto, la distribuzione dello stato avviene effet

tuando un confronto/allineamento fra il dizionario di stato

locale al place e quello trasportato da ciascun agente os

servatore. Allo stato della corrente implementazione, l'ag

giornamento di una entry avviene solamente se la copia

posseduta dall'agente è contraddistinta da un numero di

versione maggiore.

Illustrazione 9: Domini di mobilità di AM osservatori intradominio e AM osservatori interdominio.

Illustrazione 10: AM osservatori: softstate distribuito delle informazioni mediante numero di versione.

6 Conclusioni

La proposta di progetto ha offerto l'opportunità di appro

fondire alcuni aspetti pervasivi nell'ambito delle reti di

calcolatori e dei sistemi distribuiti nonché di affrontare in

maniera razionale, propositiva e collaborativa il ciclo di

sviluppo di una applicazione distribuita dalle prime fase

di analisi, passando per quelle di progettazione, fino al

l'implementazione e al deploy finale, cercando un com


promesso equilibrato fra le forze in gioco e secondo un

approccio componentbased indotto dal contesto enterpri

se.

I vincoli tecnologici imposti dalle specifiche di progetto

hanno parimenti consentito di acquisire ingente know

how su tecnologie e modelli di programmazione prece

dentemente sconosciuti.

Per quanto limitati ad un basso numero di macchine fisi

che, i test effettuati sui deploy dell'applicazione hanno

mostrato esiti positivi, sia in termini logici che in termini

prestazionali e le robuste ipotesi di scalabilità di cui gode

originariamente la piattaforma SOMA unite a quelle poste

in fase di analisi e di design della piattaforma costituisco

no un buon punto di partenza per la messa in prova su reti

di larga scala.

7 Sviluppi futuri

Il processo di integrazione di una piattaforma ad agenti

mobili in un ambito enterprise intrapreso dai lavori affe

renti a questo progetto ha posto le basi per ulteriori ambiti

di sviluppo:

• la realizzazione di servizi applicativi aggiuntivi a

disposizione degli agenti realizzati mediante tec

nologia Enterprise Java Beans 3.0 o mediante

oggetti CORBA;

• la sostituzione dei componenti mock utilizzati

per restituire informazioni circa lo stato delle ri

sorse di calcolo di ciascun host con opportuni

sensori portabili;

• l'estensione dei meccanismi di sicurezza già pre

visti dall'ambiente SOMA originale facendo uso

dei framework di sicurezza offerti in ambito en

terprise al fine di attuare politiche di restrizione

di accesso a grana fine;

• la trattazione di tematiche conseguenti alla distri

buzione su larga scala come fault tolerance, sca

labilità, bilanciamento di carico e QOS; deve es

sere quindi prioritaria la risoluzione dei single

pointoffailure di cui è affetto il sistema di nomi

della piattaforma a causa della necessità di avere

un prototipo funzionante in tempi previ senza oc

cuparsi di clustering o replicazione.

• l'utilizzo di agenti mobili come proxy di un uten

te mobile, in grado quindi di memorizzarne in

formazioni 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 stes

so;

• la fruizione dei servizi dell’AS da parte di tale

utente tramite la mediazione di un componente

in grado di spostarsi sull’AS più vicino alla posi

zione dell’utente stesso;

• la creazione di domini di mobilità più ampi del

singolo raggruppamento in cluster cui general

mente un AS appartiene e dei confini dell’orga

nizzazione cui il cluster fa capo.

8 Bibliografia

[1] A. Corradi: lucidi del corso di Reti di Calcolato

ri LS;

[2] Richard MonsonHaefel , David A. Chappell :

“Java Message Service”, O'Reilly, First Edition

January 2001;

[3] J. Steven Perry: “Java Management


Extensions”, O'Reilly, First Edition January

2002;

[4] Ben G. Sullins , Mark B. Whipple: “JMX in Ac

tion”, Manning, 2003;

[5] Mark Fleury, Scott Stark, Richards Norman :

“JBoss® 4.0 The Official Guide”, SAMS, 2005;

[6] Scott Davis, Tom Marrs: “JBoss at Work: A

Practical Guide”, O'Reilly, 2005;

[7] Bill Burke, Richard MonsonHaefel: “Enterprise

JavaBeans, 3.0”, O'Reilly, 2006;

[8] Debu Panda , Reza Rahman , Derek Lane: “EJB

3 in Action”, Manning, 2007;

[9] Rosanna Lee: “The JNDI Tutorial. Building Di

rectory Enabled Java Applications”; Sun Java,

2001;

[10] vv.aa.: Documentazione/Tesi/Papers su SOMA,

http://wwwlia.deis.unibo.it/Research/SOMA


Mobile Agent and Enterprise Architecture Integration Agent and... · 1 Introduzione La rapida...

Documents

Transcript of Mobile Agent and Enterprise Architecture Integration Agent and... · 1 Introduzione La rapida...