MokaByte Numero 19 - Maggio 1998
	Paolo Ciancarini Davide Rossi  Andrea Giovannini	Macondo:  Agenti mobili e Coordinazione per applicazioni Java distribuite

1 Introduzione

In questo articolo si introduce Macondo, una piattaforma per agenti mobili in Java. Tale piattaforma è basata su un linguaggio di coordinazione esteso per gestire la migrazione di agenti. Si presenta inoltre una tassonomia per sistemi mobili utilizzata per confrontare Macondo con i principali sistemi per agenti mobili in Java.

2 Macondo

Macondo h una piattaforma per lo sviluppo di applicazioni distribuite in Java basata su agenti mobili e tecnologia di coordinazione. Diversi sistemi esistenti per agenti mobili in Java forniscono meccanismi di comunicazione e collaborazione sviluppati appositamente per gli agenti. La principale caratteristica di Macondo h il completo disaccoppiamento fra i supporti per agenti mobili e per la tecnologia di coordinazione. Quest'ultimo h fornito da MJada, un potente linguaggio di coordinazione Linda-like. MJada pur quindi essere usato per coordinare diversi thread concorrenti nello stesso programma Java o diversi programmi Java distribuiti, come applet e agenti Macondo.
 

2.1 Agenti mobili in Macondo

I principali obiettivi di design nello sviluppo del supporto per agenti mobili in Macondo, acronimo per Mobile Agents and COrdinatioN in Distributed applicatiOns, sono la semplicit` e la flessibilit`. Il modello di agenti mobili adottato h basato su due concetti, agenti e luoghi (place).

Gli agenti sono programmi autonomi che migrano fra diversi place per poter eseguire le proprie attivit`. Gli agenti sono creati estendendo le classi Macondo Agent e Traveller. Un agente Traveller estende Agent permettendo di definire un itinerario per gli agenti, cioh una sequenza di associazioni fra locazioni e attivit`. Gli agenti Traveller sono particolarmente adatti per applicazioni di workflow, poichi possono incorporare le attivit` di un processo di workflow.

Gli ambienti di esecuzione per gli agenti sono rappresentati dalla classe Place. Un oggetto Place pur essere usato come server stand alone oppure la classe pur essere estesa dal programmatore per fornire servizi piy avanzati.

Segue ora un semplice esempio di agente mobile Macondo.

 
import macondo.mak.*;

public class MyAgent extends Agent {

    public MyAgent() {
        // . . .
    }

    // this is executed at destination:8000
    public void work() {
        // do some work . . .
    }

    public void init() {
        // do some initialization
        // . . .

        // then go working at destination:8000
        try {
            go("destination", 8000, "work");
            // this is never reached
        } catch (TransportException e) {
            e.printStackTrace();
        }
    }
}

Il seguente esempio mostra un agente Traveller che migra fra diversi host, eseguendo un metodo diverso per ogni destinazione.

 
import macondo.mak.*;

public class MyTraveller extends Traveller {

    // this is executed at host1:8000
    public void method1() {
        . . .
    }

    // this is executed at host2:9000
    public void method2() {
    . . .
    }

    // this is executed at host3:8000
    public void method3() {
    . . .
    }

    public void init() {
        Itinerary i = new Itinerary();

        i.add("host1", 8000, "method1");
        i.add("host2", 9000, "method2");
        i.add("host3", 8000, "method3");
        setItinerary(i);

        // start moving
        doTrip();
    }
}

2.2 La tecnologia di coordinazione

Lo sviluppo delle reti di telecomunicazione ha fatto nascere la necessit` di applicazioni distribuite che supportino la cooperazione fra utenti remoti, sincrona e asincrona, e la condivisione di risorse. Tali sistemi vengono definiti sistemi distribuiti aperti. La difficolt` principale nel coordinare gli agenti di tali sistemi, siano essi mobili o stazionari, h dovuta al fatto che il loro numero e la loro interfaccia non possono essere noti durante lo sviluppo del sistema, essendo per definizione aperto.

I linguaggi di coordinazione rappresentano una elegante soluzione a questo problema, attraverso l'utilizzo di una collezione di elementi come mezzo di coordinazione condiviso dagli agenti. La struttura degli elementi, della collezione e delle operazioni disponibili sul mezzo sono caratteristiche peculiari di ogni linguaggio.

Il primo linguaggio di coordinazione h stato Linda, sviluppato alla Yale University. In Linda il mezzo di coordinazione h lo spazio di tuple, un multi-insieme di tuple, e gli elementi che contiene sono appunto detti tuple. Una tupla h un gruppo di campi dove ogni campo ha un tipo e pur contenere un valore di quel tipo oppure un placeholder. In quest'ultimo caso il campo viene detto formale e la tupla viene detta template.

In Linda le tuple vengono inserite in uno spazio attraverso la primitiva out, quindi possono essere lette o prelevate con le primitive read e in rispettivamente. Entrambe specificano come argomento una tupla template. La tupla ritornata deve corrispondere alla tupla template secondo un meccanismo di matching basato sul valore e sul tipo dei campi. Piy precisamente due tuple corrispondono se hanno lo stesso numero di campi, se i tipi di questi coincidono e, nel caso in cui entrambi i campi contengano un valore, se anche i valori dei campi coincidono. Se non h possibile trovare una tupla che corrisponda al template indicato read e in si bloccano, fino a quando un altro agente non la inserisce nello spazio con una out. Questo comportamento bloccante permette di combinare gli aspetti di sincronizzazione con quelli di comunicazione, ottenendo cosl coordinazione fra agenti. L'ultima operazione di Linda h eval e specifica come argomento una tupla attiva, cioh una tupla contenente alcuni campi che rappresentano funzioni da calcolare. Queste funzioni vengono quindi valutate e si inserisce nello spazio una tupla che contiene i risultati.

E' possibile osservare che i concetti introdotti da Linda rappresentano efficaci soluzioni al problema della coordinazione in sistemi distribuiti aperti:

• disaccoppiamento degli agenti: l'utilizzo di un mezzo di coordinazione permette di disaccoppiare gli agenti sia dal punto di vista spaziale che temporale. Inoltre non h necessario alcun meccanismo di identificazione per gli agenti;
• indirizzamento associativo: l'utilizzo di un meccanismo di matching associativo permette un notevole grado di astrazione nello specificare i dati richiesti;
• asincronia e concorrenza: la comunicazione generativa in Linda h fondamentalmente asincrona e l'esecuzione degli agenti h intrinsicamente concorrente;
• separazione dei problemi: Linda ha permesso di considerare in maniera ortogonale gli aspetti di computazione e coordinazione, semplificando lo sviluppo dei sistemi.

La tecnologia di coordinazione h come visto una soluzione efficacie per lo sviluppo di applicazioni in sistemi distribuiti aperti.

MJada (Mobile Jada) h un'estensione di Jada, un linguaggio di coordinazione per Java che h stato sviluppato all'Universit` di Bologna e utilizzato come nucleo di coordinazione per molti progetti di ricerca nel contesto del progetto PageSpace UE Open LTR.

Jada h realizzato come un insieme di classi Java e non h basato sull'uso di un preprocessore, come altre implementazioni di linguaggi Linda-like. I programmatori che usano Jada possono quindi mantenere il modello di programmazione object-oriented di Java.

Come in Linda le interazioni fra agenti sono basate sullo scambio di tuple in uno spazio di tuple, ma il modello di coordinazione di Jada estende Linda in diverse direzioni. MJada aggiunge a Jada il supporto per la coordinazione fra agenti mobili.

Il mezzo di coordinazione utilizzato in MJada h lo spazio di tuple, come in Linda. Mentre Linda utilizza solo uno spazio di tuple, eventualmente distribuito, MJada supporta spazi di tuple multipli annidati che formano una struttura di coordinazione gerarchica caratterizzata dall'oggetto TupleSpace. La classe TupleSpace possiede quindi dei metodi di "navigazione" che permettono a un thread o a un agente di muoversi all'interna della struttura di coordinazione come un file system UNIX. I nomi vengono espressi da stringhe, come ad esempio "/space" e "/chapter/section". Un oggetto TupleSpace pur essere creato con

TupleSpace tuple_space = new TupleSpace();

tuple_space.join("space1");

Gli item di un nome possono essere specificati come cammini relativi ma anche come cammini assoluti. Per esempio, se lo spazio di tuple corrente h "/working_space" e viene richiamato il metodo join() con argomento "/games_space" allora le seguenti operazioni sono eseguite sullo spazio "games_space". E' anche possibile muoversi nello spazio che contiene quello corrente specificando ".." come argomento di join(). Infine, un nome pur avere item multipli come "space2/space3". per flessibilit` vengono forniti metodi addizionali per muoversi nello spazio di tuple esterno, leave(), o nello spazio di tuple radice della struttura di coordinazione, leaveAll().

In MJada una tupla h rappresentata dalla classe Tuple e contiene un insieme di oggetti Java. E' possibile creare una tupla nel seguente modo

Tuple tuple = new Tuple("Hello!", new Integer(1));

tuple_space.out(tuple);

Due tuple corrispondono se hanno la stessa cardinalit` e i campi delle tuple nella stessa posizione corrispondono. Per esempio, la seguente h una tupla template con un campo attuale di classe String e un campo formale di classe Class.

 
Tuple template = new Tuple("Hello!", Integer.class);

 
Tuple alpha = new Tuple("Hello!", new Integer(3));
Tuple beta = new Tuple("Hello!", new Integer(7));

Result read(Tuple formal)

Result in(Tuple formal)

Gli spazi di tuple in MJada possono essere sia "locali", cioh condivisi fra thread concorrenti all'interno della stessa Java Virtual Machine, oppure "remoti", cioh in esecuzione su host possibilmente remoti e acceduti attraverso una apposita classe proxy in modo molto simile a RMI.

La principale caratteristica di MJada per supportare la coordinazione fra agenti mobili h la possibilit` di annullare e inoltrare in modo trasparente una richiesta per un'operazione in() o read() pendente fra due migrazioni. In questo modo se un agente esegue

Result result = remote_tuple_space.in(my_tuple);

e la tupla richiesta non h disponibile al momento della chiamata, pur migrare in un diverso host e l'oggetto Result far` riferimento ancora a una valida operazione in eseguita su uno spazio di tuple remoto.

3 Una tassonomia per sistemi mobili

L'utilizzo di una terminologia chiara ed uniforme h fondamentale per lo sviluppo di una nuova tecnologia. Si vuole ora proporre un contributo nel campo dei linguaggi per la programmazione di agenti mobili, con una tassonomia relativa ai diversi tipi di entit` mobili e il relativo supporto linguistico per agenti mobili.

Diversi sistemi mobili supportano mobilit` per diversi tipi di entit` mobili. Ad esempio, la mobilit` di codice degli applet Java h diversa dalla mobilit` di agenti come definita in Aglets.

Si propone la seguente tassonomia per entit` mobili:

• dati: i dati sono generalmente mobili nelle architetture client-server; ad esempio, quando un browser WWW scarica una pagina HTML da un server si ha mobilit` di dati poichi HTML non h un linguaggio Turing-completo;
• riferimento: usando un browser WWW o una shell UNIX l'utente pur "muoversi" su una diversa pagina WWW o in una diversa directory. In questo caso non abbiamo una reale entit` mobile, ma un riferimento che pur essere spostato fra diversi spazi di interazione. Uno spazio di interazione pur essere per esempio una pagina WWW o una directory. Questa h una potente astrazione, anche se non si ha una reale entit` mobile;
• codice: quando un browser WWW scarica un applet Java da un server si ha mobilit` di codice. Gli applet Java rappresentano l'esempio piy conosciuto di applicazioni a codice mobile. Il vantaggio principale consiste nella possibilit` di realizzare ambienti dinamici dove il codice h scaricato su richiesta, senza doverlo preinstallare;
• codice e store: in questo caso l'entit` mobile consiste di codice e store, dove per store si indica il valore delle variabili e, possibilmente, anche un punto di ingresso nel codice (cir che in genere h chiamato lo stato di un oggetto). Questa h una forma di mobilit` offerta da molti sistemi per agenti mobili per Java;
• chiusura: una chiusura h la completa descrizione a tempo di esecuzione di una computazione, costituita da codice e da un mapping fra gli identificatori del linguaggio e i corrispondenti valori delle risorse. Se un identificatore si riferisce ad esempio ad una connessione di rete e la corrispondente chiusura viene fatta migrare, allora la connessione viene mantenuta durante la migrazione. Obliq h un linguaggio che supporta la migrazione di chiusure;
• codice, store e stato di esecuzione: in questo caso h possibile trasferire anche il completo stato di scheduling di un'entit`, compresi tutti i thread. Questa h una importante caratteristica nei sistemi distribuiti dove la migrazione deve essere trasparente all'esecuzione di un'entit`, come ad esempio nei sistemi per il bilanciamento del carico. Questa forma di mobilit` h chiamata strong ed h utilizzata in Telescript;
• ambiente: Cardelli e Gordon hanno proposto un nuovo formalismo, l'ambient calculus, per descrivere in modo uniforme gli agenti mobili, i loro ambienti di interazione e la loro mobilit`. Per esempio h possibile modellare il trasferimento di un insieme di programmi in esecuzione, un ambiente, da un personal computer a un laptop, cioh da un ambiente contenitore a un altro. Nello stesso modo h possibile esprimere la mobilit` dell'ambiente laptop. Una forma simile di mobilit` h disponibile in Bauhaus.

• mobilit` pianificata: le destinazioni di un agente sono predefinite in un itinerario. L'agente pur avere un singolo punto di ingresso oppure punti di ingresso multipli legati alle destinazioni. Un itinerario pur essere fissato oppure modificabile dinamicamente. In entrambe le forme l'utilizzo degli itinerari permette di disaccoppiare il codice specifico dell'applicazione dalle primitive di mobilit`;
• mobilit` spontanea: l'esempio piy conosciuto di mobilit` spontanea h l'istruzione go() di Telescript. In questo caso h impossibile determinare a priori la sequenza di locazioni che un agente visiter`, poichi l'agente pur decidere di migrare in una nuova locazione in qualsiasi momento a tempo di esecuzione. La mobilit` spontanea h utile nei casi in cui l'agente deve gestire situazioni di insufficienza di risorse. Ad esempio, se la corrente locazione di un agente h soggetta a un carico eccessivo allora pur decidere autonomamente di migrare su una nuova locazione con un carico inferiore;
• mobilit` controllabile: per mobilit` controllabile si intende la migrazione di un agente forzata da un'autorit`, utilizzando un qualche meccanismo di I/O per comunicare con l'agente remoto. I sistemi di bilanciamento del carico sono un esempio di questa forma di mobilit`. La mobilit` controllabile h anche simulabile con la comunicazione e la mobilit` spontanea.

Ci sono diversi progetti su agenti mobili e Java. Verr` ora presentata una rassegna dei principali sistemi disponibili per agenti mobili in Java: Concordia, Aglets, Voyager, Odyssey e Mole. Quindi questi tool verranno confrontati con Macondo relativamente agli aspetti di mobilit` e di interazione fra agenti.

4.1 Rassegna dei sistemi esistenti

4.1.1 Concordia

Concordia h un completo tool per agenti mobili in Java sviluppato da Mitsubishi. Un agente Concordia pur muoversi solo attraverso l'uso di un itinerario, modellato come sequenza di coppie (locazione, metodo), dove ad ogni locazione viene eseguito il corrispondente metodo. In questo modo il codice dell'applicazione h completamente disaccoppiato dagli aspetti di mobilit`, ma in alcuni casi la disponibilit` di un metodo go() in modo simile a Telescript pur essere molto utile.

L'interazione fra agenti Concordia h supportata attraverso eventi distribuiti asincroni e un framework di collaborazione. Mentre l'utilizzo degli eventi permette agli agenti di comunicare in modo molto flessibile, il framework di collaborazione supporta l'esecuzione di attivit` collaborative fra agenti. A tal fine h necessario un punto di collaborazione, realizzato come oggetto Java distribuito, che fornisce un metodo invocato dagli agenti. Quindi l'oggetto colleziona i risultati parziali inseriti dagli agenti e calcola il risultato globale. Infine, questo risultato h comunicato a tutti gli altri agenti attraverso un'altra invocazione di metodi. Si ritiene che questo framework non sia sufficientemente adeguato per poter gestire complesse attivit` di coordinazione.

Il supporto per l'esecuzione degli agenti Concordia si basa sui Conduit Server. Ogni server h quindi costituito da diversi componenti, chiamati manager, che gestiscono gli aspetti di mobilit` degli agenti, sicurezza, comunicazione e persistenza.

4.1.2 Aglets

Aglets Workbench di IBM h uno dei primi e piy conosciuti progetti su agenti mobili in Java. Il principale obiettivo di design h stato lo sviluppo di un modello di programmazione per agenti mobili il piy possibile simile a quello degli applet Java.

La API di Aglets h basata principalmente sui concetti di aglet, proxy, contesto e messaggio. Un aglet h un oggetto Java mobile e autonomo che pur migrare fra diversi host. Un proxy viene utilizzato per riferirsi ad un aglet, per proteggerlo da accessi indiscriminati e per fornire indipendenza dalla locazione. Un contesto h l'ambiente di esecuzione degli aglet e pur proteggere gli host da aglet "maliziosi". Un messaggio h un oggetto utilizzato per la comunicazione fra aglet. Pur essere utilizzato per comunicazione sincrona e asincrona. Viene supportato anche il multicasting di messaggi.

Il ciclo di vita di un aglet h definito da una sequenza di eventi, cioh creazione, clonazione, rilascio, ritiro, attivazione, deattivazione, rimozione e comunicazione. Un aglet pur reagire a questi eventi attraverso metodi che possono essere ridefiniti dai programmatori, permettendo una notevole flessibilit`. Un problema del modello di programmazione degli aglet h il livello di complessit` introdotto dagli eventi.

Il meccanismo di comunicazione di Aglets h semplice e flessibile, ma risulta essere troppo limitato per applicazioni che richiedono coordinazioni complesse fra agenti.

4.1.3 Voyager

Voyager h un ORB che supporta agenti mobili. Il supporto per CORBA e la prevista interoperabilit` con DCOM rendono Voyager una potente piattaforma per il calcolo distribuito.

Il modello object oriented di programmazione distribuita di Voyager h basato su interfacce, come RMI. E' supportata la generazione automatica di interfacce attraverso una apposita utility.

Una delle principali caratteristiche degli agenti Voyager h data dal fatto che la destinazione di una migrazione pur essere un programma oppure un oggetto Java. In questo caso l'oggetto che migra pur raggiungere la destinazione, ottenere un riferimento all'oggetto specificato e interagire localmente con esso.

Voyager permette anche di invocare un metodo su un oggetto in movimento. Questo h possibile perchh un agente lascia un forwarder in ogni locazione visitata. Una invocazione diretta ad una locazione obsoleta verr` rediretta in maniera completamente trasparente alla nuova locazione dell'agente. Le invocazioni seguenti faranno riferimento alla nuova locazione.

Un'altra caratteristica interessante di Voyager h che il metodo moveTo(), utilizzato per la migrazione, pur specificare un metodo da invocare sull'agente a destinazione. In questo modo un agente pur avere diversi punti di ingresso nel proprio codice per diverse destinazioni. Gli itinerari non sono supportati in Voyager.

La comunicazione in Voyager h basata su diverse forme di invocazione remota di metodi, ovvero sincrona, asincrona, oneway, future (asincrona), oneway multicast e publish/subscribe.

Nonostante il supporto per la comunicazione in Voyager sia molto potente e flessibile, si ritiene che questo approccio sia limitato per i sistemi distribuiti aperti. In tali sistemi h infatti impossibile conoscere a priori l'interfaccia di un agente, mentre questo h richiesto per supportare la comunicazione diretta.

4.1.4 Odyssey

General Magic h stata la prima societ` a lavorare sugli agenti mobili con il linguaggio Telescript. A causa del fatto che Telescript era un linguaggio proprietario e del crescente successo di Java, General Magic ha deciso di sviluppare Odyssey, un sistema per agenti mobili in Java basato sui concetti di Telescript.

Un sistema Odyssey h basato su agenti e luoghi (place). Gli agenti possono migrare fra i place usando un metodo go() o gli itinerari. Diversamente da altri tool in Odyssey devono essere implementati anche i place; i sistemi realizzati sono quindi molto flessibili.

Gli agenti comunicano con altri agenti e con i place attraverso l'invocazione locale di metodi. E' anche possibile scambiare riferimenti a oggetti all'interno di un place, ma il meccanismo non fornisce alcuna forma di sincronizzazione.

Una caratteristica interessante del sistema di esecuzione di Odyssey h il supporto per diversi meccanismi di trasporto. Quello standard fornito h RMI ma sono supportati anche DCOM di Microsoft e CORBA IIOP.

Odyssey h un tool molto ben progettato ma manca di un sofisticato meccanismo di comunicazione e coordinazione fra agenti.

4.1.5 Mole

Mole h un sistema per agenti mobili sviluppato all'Universit` di Stoccarda. Mole supporta due tipi di agenti: agenti mobili e agenti di sistema. Mentre gli agenti mobili migrano fra diversi host, gli agenti di sistema sono stazionari e rappresentano l'interfaccia per i servizi forniti dagli host.

Gli agenti mobili in Mole non supportano gli itinerari e possono avere un singolo punto di ingresso, come gli aglet.

La comunicazione fra agenti avviene attraverso lo scambio di oggetti messaggio. Vengono fornite due apposite classi, Message e RPCMessage, dove l'ultima h utilizzata per simulare l'invocazione remota di metodi. I servizi offerti dagli agenti di sistema possono essere registrati su un dizionario condiviso, che viene poi interrogato da altri agenti.

Altre caratteristiche interessanti di Mole sono la orphan detection, che h un meccanismo utilizzato per rilevare e rimuovere gli agenti dal sistema, e un originale architettura per la migrazione del codice. Sono inoltre in corso progetti relativi alla creazione di gruppi di agenti, sicurezza e transazioni per agenti mobili.

Come gli altri sistemi presentati anche Mole non fornisce correntemente alcun supporto avanzato per la coordinazione di agenti.

4.2 Confronto

Ora si presenter` un confronto dei sistemi presentati utilizzando la tassonomia introdotta in precedenza.

Relativamente al tipo di entit` trasmessa, tutti i sistemi supportano la migrazione di codice e dati di un agente. Cir h dovuto alla impossibilit` in Java di preservare lo stato di esecuzione di un programma.

Nella seguente tabella si confrontano i sistemi presentati con Macondo dal punto di vista del supporto linguistico alla mobilit`.
 

Tipo di mobilit`	Concordia	Aglets	Voyager	Odyssey	Mole	Macondo
Pianificata mutevole	Sl	Sl	No	Sl	No	Sl
Spontanea	No	Sl	Sl	Sl	Sl	Sl
Controllabile	No	Sl	Sl	No	No	No

Nessuno dei sistemi esaminati supporta mobilit` pianificata fissata. Voyager e Mole non supportano la mobilit` pianificata mutevole, mentre tutti gli altri sistemi permettono ai programmatori di definire itinerari mutevoli. Tranne Concordia tutti i sistemi forniscono mobilit` spontanea in modo simile a Telescript.

La mobilit` controllabile richiede l'invocazione di una primitiva di mobilit` spontanea su un agente. Le capacit` di invocazione remota di metodi di Voyager supportano la mobilit` controllabile in modo naturale. Aglets supporta inoltre la mobilit` controllabile attraverso l'uso di un proxy: l'invocazione di un metodo di dispatching sul proxy causa la migrazione del corrispondente aglet nella specificata destinazione. Tutti gli altri sistemi non supportano questo tipo di mobilit`.

La seguente tabella presenta un confronto dei precedenti sistemi, compreso Macondo, relativamente alle caratteristiche di interazione fra agenti.
 

Caratteristiche di interazione	Concordia	Aglets	Voyager	Odyssey	Mole	Macondo
Invocazione remota di metodi	No	Simulabile	Sl	No	Simulabile	Simulabile
Invocazione di metodi su agenti mobili	No	No	Sl	No	No	No
Eventi distribuiti	Sl	No	Sl	No	No	Simulabile
Publish/Subscribe	No	Sl	Sl	No	No	Simulabile
Meeting	No	Sl	Sl	Sl	Sl	Simulabile
Coordinazione/Collaborazione	Sl, limitata	No	Sl, aperta	Solo locale	No	Sl, aperta

I punti precedenti verranno ora descritti

• Invocazione remota di metodi: Questa h una caratteristica supportata direttamente solo da Voyager in un modo molto flessibile. Mole permette lo scambio di speciali oggetti RPCMessage, quindi simulando RMI. Allo stesso modo lo scambio di messaggi in Aglets pur essere usato per implementare l'invocazione di metodi. Odyssey non fornisce alcun meccanismo di comunicazione remota, mentre la comunicazione in Concordia h basata su eventi. Utilizzando MJada h possibile simulare l'invocazione remota di metodi in modo semplice e elegante;
• Invocazione di metodi su agenti mobili: questa h una caratteristica unica di Voyager, descritta in precedenza. Poichi la comunicazione in MJada h generativa, gli aspetti di mobilit` e localit` non sono difficili da gestire;
• Eventi distribuiti: solo Concordia e Voyager supportano eventi distribuiti. In particolare, Voyager utilizza il modello di eventi a delegazione sviluppato per i JavaBean. Questo paradigma pur essere espresso con le primitive di MJada in modo molto semplice;
• Publish/Subscribe: Voyager e Aglets permettono di sottoscrivere l'invocazione di un metodo o l'invio di un messaggio in base alle loro proprietà. Questo tipo di selezione di messaggi h molto simile allo scambio di tuple;
• Meeting: questo h un concetto introdotto originariamente in Telescript e consiste nell'invocazione diretta di metodi fra agenti nello stesso ambiente di esecuzione. Aglets, Voyager, Odyssey e Mole supportano i meeting a differenza di Concordia. Anche questo meccanismo di comunicazione pur essere espresso semplicemente attraverso scambio di tuple;
• Coordinazione/Collaborazione: Voyager e MJada forniscono dei framework di coordinazione e collaborazione molto aperti e flessibili. Mentre Voyager usa eventi distribuiti e invocazione remota di metodi, MJada h basato su Linda, il linguaggio di coordinazione per eccellenza. Lo scambio di riferimenti a oggetti in Odyssey h simile alle primitive di Linda ma Odyssey non fornisce operazioni bloccanti. Concordia offre come visto un supporto esplicito per la collaborazione fra agenti, ma h molto limitato.

Dalla precedente rassegna emerge evidente il fatto che molti gruppi di ricerca stiano lavorando sull'utilizzo di Java per sistemi di agenti mobili. Considerando inoltre che anche grandi societ` commerciali, come IBM, sono coinvolte in questi progetti si pur avere una chiara indicazione del grande numero di persone che possono trarre vantaggio da questa tecnologia. La rapida diffusione della telefonia cellulare apre nuove e interessanti opportunit`: si pensi ad esempio all'utilizzo di un processore picoJava e di una GUI pen-driven in un telefono cellulare. Ma la disponibilit` dell'hardware h inutile senza un ambiente operativo che possa supportare le applicazioni dell'utente. Inoltre le applicazioni per questi device, che in genere non sono continuamente connessi, devono gestire una certa forma di mobilit` di codice (ci si riferisce in genere all'utilizzo di tali device mobili con il termine di nomadic computing). La ricerca non ha ancora ben definito se sia necessaria la migrazione di entit` Turing-complete per poter supportare questa nuova generazione di applicazioni, ma il nostro gruppo di ricerca sta cercando di raggiungere questo obiettivo estremo per poter valutare vantaggi e problemi del paradigma degli agenti mobili.

In questo contesto h stata presentata una nuova piattaforma per agenti mobili in Java, Macondo, che comprende il linguaggio di coordinazione MJada. Questi strumenti verranno utilizzati per la realizzazione di applicazioni nel campo del nomadic computing e del lavoro collaborativo.

Paolo Ciancarini è professore associato di Scienze dell'Informazione all'Università di Bologna. I suoi interessi di ricerca includono: sistemi e linguaggi di coordinazione, la programmazione di sistemi basati su oggetti distribuiti e metodi formali nell'ingegneria del software.

Andrea Giovannini h laureato in Scienze dell'Informazione all'Universit` di Bologna ed ha implementato Macondo come parte della propria tesi. I suoi principali interessi sono Java, i sistemi distribuiti, gli agenti mobili e la tecnologia di coordinazione.

Davide Rossi è studente di dottorato in Scienze dell'Informazione all'Università di Bologna ed è l'autore di Jada. Attualmente è visiting scientist alla Yale University. I suoi interessi di ricerca sono i sistemi operativi, i sistemi distribuiti, i linguaggi di coordinazione, le tecnologie ad agenti, la programmazione object-oriented (C++, Java) e la compressione delle immagini.
 
  

	MokaByte rivista web su Java MokaByte ricerca nuovi collaboratori Chi volesse mettersi in contatto con noi può farlo scrivendo a mokainfo@mokabyte.it