Alcuni dettagli implementativi

Nella piattaforma sono presenti diversi host, ognuno dei quali rappresenta uno o più container di agenti e quindi un ambiente completo: il primo ad essere avviato viene definito main container,esso è responsabile del mantenimento di un registro conte- nente i riferimenti a tutti gli altri container della stessa piattaforma.

In ogni piattaforma è presente almeno un AMS (Agent Management System) che tiene traccia di tutti gli agenti presenti anche tra i container remoti: esso deve essere contattato dagli agenti per la registrazione alla piattaforma, senza la quale l’agente non esiste. Le registrazioni permettono di mantenere un servizio di pagine bianche col quale reperire gli agenti tramite il loro identificativo e indipendentemente dalla loro posizione momentanea.

In ogni piattaforma esiste un DF (Directory Facilitator) che tiene traccia di tutti i servizi offerti dagli agenti di quella piattaforma: mantiene un servizio publish/sub- scribe di pagine gialle ma in precedenza deve ovviamente essere contattato da ciascun agente che vuole offrire un qualsiasi servizio.

CAPITOLO 6. MAPPING ARCHITETTURA ASTRATTA SU

MIDDLEWARE ESISTENTE 105

Figura 6.2: strutture principali in Jade

Di seguito andremo ad esplorare nel dettaglio alcune tematiche particolari.

MODELLO DEGLI AGENTI, CICLI DI VITA E BEHAVIOUR

Ogni classe di agenti deve estendere jade.core.Agent mentre ciascuna istanza di tali classi viene eseguita su un singolo thread.Ogni agente ha un globally unique name (aid) nella forma local_name@platform_name, ma il nome completo viene utilizza- to solo in caso di comunicazione fra piattaforme diverse. La business logic di ogni agente viene descritta in termini di behaviours mentre la comunicazione viene affi- data a messaggi che seguono le specifiche strutturale FIPA ACL.

Durante il suo ciclo di vita l’agente si trova in uno dei seguenti stati:

• Initiated, creato ma non ancora registrato e quindi privo di aid;

• Active, registrato e in grado di eseguire i propri behaviours;

• Waiting, bloccato nell’attesa di un messaggio;

• Suspended, stoppato senza che nessuno dei suoi behaviours sia in esecuzione;

CAPITOLO 6. MAPPING ARCHITETTURA ASTRATTA SU

MIDDLEWARE ESISTENTE 106

• Unknown, fase conclusiva che segue la sua deregistrazione.

Di seguito le operazioni che comportano cambi di stato:

• doSuspend() da ACTIVE o WAITING a SUSPENDED;

• doActivate() da SUSPENDED a qualsiasi stato in cui si trovasse al momento della chiamata alla doSuspend();

• doDelete() da un qualsiasi stato a UNKNOWN;

• doWait() da ACTIVE a WAITING;

• doWake() da WAITING a ACTIVE;

• doMove() da un qualsiasi stato a TRANSIT.

CAPITOLO 6. MAPPING ARCHITETTURA ASTRATTA SU

MIDDLEWARE ESISTENTE 107

La sequenza delle operazioni che vengono eseguite in fase di costruzione dell’a- gente è la seguente:

1. Viene eseguito il costruttore dell’agente.

2. Viene assegnato all’agente un AID in base alla piattaforma su cui è stato creato.

3. In seguito alla chiamata del metodo register() l’agente viene registrato al- l’AMS.

4. L’agente entra nello stato attivo.

5. Viene eseguito il corpo del metodo setup().

6. Comincia lo scheduling dei behaviours associati all’agente.

Un behaviour estende la classe jade.core.behaviours.Behaviour e viene definito co- me una sequenza di attività da eseguire allo scopo di completare un task, tali attività possono essere proattive e quindi eseguite spontaneamente dall’agente, oppure reat- tive e quindi in risposta ad eventi verificatisi come la ricezione di un messaggio o la scadenza di un timeout. Essi vengono eseguiti concorrentemente da un thread Java utilizzando uno scheduler round- robin non-preemptive, completamente trasparente all’utente: il corpo del metodo action descrive lo specifico task dell’agente mentre done viene utilizzato per controllare la condizione di terminazione del task.

I comportamenti non sono eseguibili contemporaneamente nè interrompibili, quindi può verificarsi uno switch solo nel caso in cui quello in esecuzione termini; nel caso in cui completi la sua sequenza di azioni senza che la condizione di terminazione sia soddisfatta, esso viene reinserito all’interno del pool di scheduling.

MOBILITÀ

Jade supporta meccanismi di mobilità strong, questo termine indica la possibilità di trasferire/ clonare non solo il codice dell’agente ma anche il suo stato seguendo questa sequenza:

1. si ferma l’esecuzione dell’agente nel container locale;

2. si muove/clona l’agente nel container remoto (se il codice non è disponibile nel nuovo container esso viene recuperato automaticamente dalla piattaforma Jade);

CAPITOLO 6. MAPPING ARCHITETTURA ASTRATTA SU

MIDDLEWARE ESISTENTE 108

3. si riprende l’esecuzione dell’agente nello stesso punto esatto in cui era stata interrotta. Per essere trasferito o clonato, ogni agente deve appartenere ad una classe Serializable.

Il luogo in cui gli agenti possono trasferirsi è rappresentato dall’interfaccia jade.core.Location, la quale viene implementata da due classi differenti a seconda degli scenari in que-

stione:

• ContainerID per la mobilità interna alla piattaforma;

• PlatformID per la mobilità fra piattaforme differenti (richiede la presenza di un add-on da installare.

COMUNICAZIONE

I messaggi asincroni in ricezione vengono immagazzinati in una coda identificabile con una mailbox: l’agente viene notificato ad ogni nuovo inserimento ma sarà solo lui a decidere quando e quali messaggi processare. Esso ha a disposizione le seguenti primitive:

• send() invia un messaggio asincrono;

• receive() recupera in maniera asincrona il primo messaggio dalla mailbox (se ce ne sono);

• receive(MessageTemplate) esegue una receive selettiva;

• blockingReceive() esegue una receive sincrona sospendendo i comportamenti di tutti gli agenti e non solo di quello chiamante;

• blockingReceive(long) esegue una receive sincrona a tempo;

• blockingReceive(MessageTemplate) esegue una receive sincrona e selettiva;

• blockingReceive(MessageTemplate, long) esegue una receive sincrona, selet- tiva e a tempo.

Il meccanismo di recupero selettivo segue un preciso pattern specificato al momen- to della chiamata di tale metodo senza seguire la coda presente; nel caso in cui il tentativo di recupero non produca risultati, l’eventuale scadere del timeout risveglia

CAPITOLO 6. MAPPING ARCHITETTURA ASTRATTA SU

MIDDLEWARE ESISTENTE 109

l’agente che proseguirà il proprio behaviour.

CONTENUTO DEL MESSAGGIO

Ciascun messaggio è ovviamente costituito da una serie di campi che devono essere riempiti (manualmente, tramite metodi specifici che lo fanno semi-automaticamente, o completamente in maniera automatica):

• sender, campo settato in automatico che identifica il mittente;

• receiver, campo da settare che identifica il destinatario (anche indirizzi muti- pli);

• performative, indica la tipologia di messaggio possibile:

 CFP (Call For Proposal) per ottenere proposte

 INFORM per mettere qualcuno a conoscenza di qualcosa  PROPOSE per proporre qualcosa

 REQUEST per richiedere un servizio

 SUBSCRIBE per sottoscriversi a una notifica  AGREE per segnalare consenso

 REFUSE per rifiutare una proposta

6.2 Mapping dei principali elementi infrastrutturali