JAM: Java Agent Middleware

Transcript

1 JAM: Java Agent Middleware Progetto di Laboratorio per il corso di Programmazione in Rete e Laboratorio Anno Accademico 2003/2004 Matteo Baldoni Attenzione! Questo documento non è definitivo ma sarà aggiornato di settimana in settimana con il progredire del corso, questa versione è del March 16, Abstract Queste pagine descrivono il laboratorio per il corso di Programmazione in Rete e Laboratorio per l anno accademico 2003/2004. Il presente laboratorio ha come obiettivo la realizzazione di una semplice infrastruttura di rete basata su RMI per lo svilluppo di applicazioni che utilizzino a tecnologia ad agenti. L infrastruttura è denominata Java Agent Middleware (JAM, in breve). Novità e modifiche: : Data di inizio della stesura del documento : Pubblicazione della prima versione contenente la prima parte del laboratorio da svolgere : È stata rivista la Sezione 3.1 del laboratorio introducendo i tipi di messaggi. La Sezione 2.1 è in fase di revisione per accogliere la modifica sui tipi di messaggio : Corretti alcuni errori nella Sezione 3.1. Completata la revisione della Sezione 2.1 con l introduzione dei tipi di messaggio. Introdotta la Parte II del laboratorio : Introdotta la parte III del laboratorio : Apportate alcune correzioni rilevate in aula, estesa con il metodo getowner l interfaccia remota RemoteMessageBox nella Sezione 3.3, incominciato ad introdurre la quarta parte del laboratorio : Introdotta la sezione che spiega il test da effettuare sulle parti I-IV. 1

2 : Rivista con maggiori dettagli la sezione introdotta il giorno : Agginta la sezione che illustra la realizzazione dell interfaccia grafica ADSL Monitor, si veda la Sezione : Introdotta la quinta parte del laboratorio nella Sezione : Eliminati i riferimenti alle chiamate ai metodi rebind per gli ogetti MessageBox nelle Sezioni e 3.5 come discusso in aula : Eliminato dall interfaccia grafica per l ADSL la casella per inserire il nome come discusso in aula nella Sezione : Introdotta la parte sesta del laboratorio nella Sezione : Introdotta la settima parte del laboratorio nella Sezione 3.7. Modificato l esempio della Sezione 2.1 per accogliere alcune modifiche rese necessarie per la coerenza delle parti successivamente introdotte : Apportate alcune correzioni per errori di stampa : Apportate altre correzioni nell esempio della Sezione 2.1. Introdotto il metodo isboxempty nella classe MessageBox nella Sezione 3.2. Introdotto il metodo aretheremessages nella classe JAMAgent nella Sezione 3.5. Introdotta la Sezione 4 per i test : Corretto ulteriormente l esempio della Sezione Modalità di svolgimento e consegna del laboratorio È fortemente consigliato svolgere il laboratorio durante il corso e quindi sostenere l esame nella prima sessione d esame dopo il corso stesso. 1.1 Iscrizione del gruppo di laboratorio Si ricorda che per poter svolgere il laboratorio è necessario prima di tutto iscriversi compilando l apposito form di iscrizione al laboratorio: nel quale vanno indicati i componenti del gruppo, che possono essere al più due (limite rigido!), e i loro numeri di matricola. Tale iscrizione ha il solo ed unico scopo di conoscere come sono composti i gruppi di laboratorio. 2

3 1.2 Materiale da portare alla consegna del laboratorio Alla consegna del laboratorio è necessario allegare: un floppy disk contenente il codice sorgente e compilato del progetto svolto con tutte le istruzioni necessarie ad un facile utilizzo del software stesso; il listato stampato del codice sorgente; la documentazione generata mediante javadoc (sul floppy disk); i diagrammi di classe UML ed una breve relazione sul lavoro svolto. La data della consegna corrisponde al giorno dell esame orale dell appello prescelto. 1.3 Modalità d esame L esame è orale ed individuale anche se il laboratorio è svolto in collaborazione con un altra persona. Per sostenere l esame ad un appello è obbligatorio prenotarsi on-line: L esame ha l obitettivo di verificare sia il corretto svolgimento del laboratorio che la comprensione delle parti di teoria correlata al laboratorio stesso. Per poter discutere il laboratorio è necessario aver prima superato la prova scritta. È importante ricordare che il laboratorio potrà essere modificato e/o personalizzato per chi deciderà di sostenere l esame nelle sessioni successive alla prima (marzo/aprile 2004). Per modifiche si intende anche l aggiunta di nuove parti da svolgere. Tali modifiche verranno pubblicizzate sulla pagina web del corso: baldoni/didattica/aa0304/proginrete Il voto per lo scritto e per il laboratorio sarà espresso in trentesimi. Il voto finale sarà formato dalla media pesata del voto della prova scritta e del laboratorio, secondo il loro contributo in CFU, e cioè voto finale = (voto dello scritto * 2 + voto del laboratorio) / Valitidà del presente testo di laboratorio Il presente testo di laboratorio vale solo fino all inizio del corso di Programmazione in Rete e Laboratorio (parte di laboratorio) dell anno accademico 2004/2005 (l ultima sessione utile sarà quella di dicembre/gennaio prossimi). 2 Descrizione generale del laboratorio Il laboratorio è organizzato in diverse parti da svolgere in maniera incrementale. Lo scopo è la realizzazione una infrastruttura che permetta l implementazione di applicativi basati sulla tecnologia ad agenti in Java. Per maggiori informazioni 3

4 sui sitemi ad agenti si veda [5]. L infrastruttura è ispirata al Java Agent DEvelopment Framework (JADE) di TILab [4]. L infrastruttura da realizzare è basata sulla tecnologia RMI di Java [3], si veda la Figura 1. Questa sarà costituita da un ambiente a runtime, denominato Figure 1: Descrizione generale del progetto da realizzare. Runtime Agent Middleware (RAM, nel seguito). Il RAM sarà realizzato direttamente sull infrastruttura RMI offerta da Java mediante una serie di classi che costituiranno lo Agent Directory Service Layer (ADSL, nel seguito). Il RAM permetterà di ospitare, cercare, trovare, eseguire e soprattutto scambiare messaggi tra gli agenti presenti in un dato momento. Agenti che saranno definiti mediante un insieme di opportune classi, che costituiscono un altro degli obiettivi del laboratorio, denominate Java Agent Middleware (JAM, nel seguito). 2.1 L esempio dell asta Si consideri l esempio dell asta già presentato durante il corso [1] e vediamo come si potrebbe ridefinirlo attraverso l uso delle classi del package JAM. In un asta possiamo riconoscere due ruoli principali, il banditore ed il cliente. Solitamente alcuni clienti si contendono un oggetto effettuando le proprie offerte al banditore. Il cliente che effetuerà l offerta più alta vince l asta (Figura 2). I vari rilanci seguono un preciso schema, ogni offerta deve essere più alta della migliore offerta attuale. Se tale oferta è accettata dal banditore allora quella diventa la nuova migliore offerta. Se un cliente ritiene che la migliore offerta corrente è incompatibile con il suo budget a disposizione, si ritira dalla competizione. Se alla fine nessuno effettua un rilancio, il banditore incomincia a battere il martello e al terzo battito aggiudica l oggetto al migliore offerente di quel momento. Questo è quello che avviene in una gara d asta dal vivo. Nella nostra simulazione supponiamo che ogni cliente possa chiedere la migliore offerta corrente e quindi decidere se rilanciare oppure no a seconda del budget a disposizione. Lo schema dell interazione tra un cliente e il battitore è presentato 4

5 Figure 2: Ruoli in un asta. nella Figura 3. Un agente in JAM è definito mediante l estensione di una opportuna classe, la classe JAMAgent. Questa mette a disposizione tutte le primitive per inviare e ricevere messaggi da altri agenti presenti in un dato momento nello RAM a cui esso appartiene. Il comportamento di un agente è definito mediante un oggetto di tipo JAMBehaviour. Tale oggetto contiene un metodo denominato action che viene eseguito in un thread all avvio dell esecuzione dell agente. L azione definita può essere eseguito una sola volta o ripetuto ciclicamente sino al raggiungimento di una determinata situazione. Le classi che definiscono il comportamento e l agente Banditore potrebbero essere, ad esempio, le seguenti. class BanditoreAstaBehaviour extend JAMWhileBehaviour { public BanditoreAstaBehaviour(JAMAgent myagent) { super(myagent); public void action() { Message msg = myagent.receive(); if (msg.gettype() == MessageType.REQUEST) { if (msg.getcontent().equals("attuale OFFERTA?")) { Message answerrequest = new Message(MessageType.INFORM); answerrequest.setsender(myagent.getid()); answerrequest.setreceiver(msg.getsender()); if ((msg.getsender()).equals(miglioreofferta.getofferente())) { battuta++; System.out.println(miglioreOfferta.getOfferta() + " e " + battuta + " per " + miglioreofferente.getofferente() + "!"); if (battuta == MAX_BATTUTE) { System.out.println("Aggiudicato per " + miglioreofferta.getofferta() + " a " + 5

6 Figure 3: Sequence diagram dell interazione tra un agente cliente ed un banditore. miglioreofferta.getofferente() +"!"); answerrequest.setcontent("aggiudicato"); answerrequest.setextraargument(miglioreofferta); myagent.send(answerrequest); done(); else { System.out.println("Ci sono altre offerte?"); sleep(tempo_attesa); if (myagent.aretheremessage()) battuta = 0; answerrequest.setcontent("migliore OFFERTA"); answerrequest.setextraargument(miglioreofferta); myagent.send(answerrequest); else { answerrequest.setcontent("migliore OFFERTA"); answerrequest.setextraargument(miglioreofferta); myagent.send(answerrequest); else { 6

7 Message answerrequest = new Message(MessageType.REFUSE); answerrequest.setsender(myagent.getid()); answerrequest.setreceiver(msg.getsender()); answerrequest.setcontent("request NON SODDISFACIBILE"); answerrequest.setextraargument(msg); myagent.send(answerrequest); else if (msg.gettype() == MessageType.QUERY-IF) { if (msg.getcontent().equals("rilancio")) { Offerta rilancio = (Offerta) msg.getextraargument(); Message answerqueryif = new Message(MessageType.INFORM); answerrequest.setsender(myagent.getid()); answerrequest.setreceiver(msg.getsender()); if (miglioreofferta.migliore(rilancio)) { battuta = 0; System.out.println(miglioreOfferta() + " per " + miglioreofferta.getofferente()); answerrequest.setcontent("rilancio ACCETTATO"); else answernewbid.setcontent("rilancio RIFIUTATO"); myagent.send(answerqueryif); else { Message answerqueryif = new Message(MessageType.REFUSE); answerqueryif.setsender(myagent.getid()); answerqueryif.setreceiver(msg.getsender()); answerqueryif.setcontent("query_if NON SODDISFACIBILE"); answerqueryif.setextraargument(msg); myagent.send(answerqueryif); else if (msg.gettype() == MessageType.INFORM) { if (contentmsg.equals("rinuncia")) { System.out.println(msg.getSender() + " si ritira dalla competizione!"); else { Message answerinform = new Message(MessageType.NOT-UNDERSTOOD); answerinform.setsender(myagent.getid()); answerinform.setreceiver(msg.getsender()); answerinform.setcontent("non CAPISCO"); answerinform.setextraargument(msg); myagent.send(answerinform); else { Message notunderstoodmsg = new Message(MessageType.NOT-UNDERSTOOD); notunderstoodmsg.setsender(myagent.getid()); notunderstoodmsg.setreceiver(msg.getsender()); notunderstoodmsg.setcontent("non CAPISCO"); notunderstoodmsg.setextraargument(msg); myagent.send(notunderstoodmsg); 7

8 class Banditore extend JAMAgent { public Banditore() { addbehaviour(new BanditoreAstaBehaviour(this)); Le classi che definiscono, invece, il comportamento e l agente Cliente potrebbero essere, ad esempio, le seguenti. class ClientAstaBehaviour extend JAMWhileBehaviour { public ClientAstaBehaviour(JAMAgent myagent) { super(myagent); public void action() { Message request = new Message(MessageType.REQUEST); request.setsender(myagent.getid()); request.setreceiver(((clientagent)myagent).getmybanditoreid()); request.setcontent("offerta ATTUALE?"); myagent.send(request); Message answerrequest = myagent.receive(messagetype.inform, (((ClientAgent)myAgent).getMyBanditoreID())); if (answerrequest.getcontent("aggiudicato")) { System.out.println("Sono il vincitore!!"); Offerta offertavincitrice = (Offerta) msg.getextraargument(); System.out.println("Con un offerta di " + offertavincitrice.getofferta()); done(); else if (answerrequest.getcontent().equals("migliore OFFERTA")) { Offerta offertacorrente = (Offerta) msg.getextraargument(); if (!(offertacorrente.getofferente().equals(myagent.getname()))) { if (offertacorrente.getofferta() < ((ClientAgent)myAgent).getBudget() - RILANCIO) { Offerta rilancio = new Offerta (myagent.getid(), current.getofferta() + (int)(math.random() * RILANCIO)); Message rilanciomsg = new Message(MessageType.QUERY-IF); rilanciomsg.setsender(myagent.getid()); rilanciomsg.setreceiver((((clientagent)myagent).getmybanditoreid())); rilanciomsg.setcontent("rilancio"); rilanciomsg.setextraargument(rilancio); myagent.send(rilanciomsg); Message answerrilancio = myagent.receive(messagetype.inform, (((ClientAgent)myAgent).getMyBanditoreID())); if (answerrilancio.getcontent().equals("rilancio ACCETTATO")) sleep((int)(math.random() * DELTA ); 8

9 else if (!answerrilancio.getcontent().equals("rilancio RIFIUTATO")) { Message notunderstoodmsg = new Message(MessageType.NOT_UNDERSTOOD); notunderstoodmsg.setsender(myagent.getid()); notunderstoodmsg.setreceiver((((clientagent)myagent).getmybanditoreid())); notunderstoodmsg.setcontent("non CAPISCO"); notunderstoodmsg.setextraargument myagent.send(notunderstoodmsg); else { Message rinunciamsg = new Message(MessageType.INFORM); rinunciamsg.setsender(myagent.getid()); rinunciamsg.setreceiver((((clientagent)myagent).getmybanditoreid())); rinunciamsg.setcontent("rinuncia"); myagent.send(rinunciamsg); System.out.println("Rinuncio alla competizione."); done(); else sleep((int)(math.random() * TEMPO ATTESA); else { Message notunderstoodmsg = new Message(MessageType.NOT_UNDERSTOOD); notunderstoodmsg.setsender(myagent.getid()); notunderstoodmsg.setreceiver((((clientagent)myagent).getmybanditoreid())); notunderstoodmsg.setcontent("non CAPISCO"); notunderstoodmsg.setextraargument myagent.send(notunderstoodmsg); class ClientAgent extend JAMAgent { private AgentID mybanditoreid; private int budget; public AgentID getmybanditoreid() { public int getbudget() { public ClientAgent() { addbehaviour(new ClientAstaBehaviour(this)); 9

10 3 Descrizione dettagliata delle parti da svolgere 3.1 Parte I: le classi AgentID, MessageType e Message Definire una classe AgentID le cui istanze contengono il seguente campo: name: di tipo String che rappresenta il nome simbolico dell agente (es. Christie s ); role: di tipo String che rappresenta il ruolo a cui appartiene l agente (es: banditore, cliente ). Definire poi una classe MessageType che permette di specificare il tipo di messaggio (performativa, si veda anche [5, Sezione 8.2.3]) creato (REQUEST, INFORM, REFUSE, QUERY-IF, QUERY-REF, AGREE, FAILURE, NOT- UNDERSTOOD, ecc.) contenente la dichiarazione di un inseme di costanti, una per ogni tipo di messaggio: public class MessageType { public static final int UNKNOWN = 0; public static final int REQUEST = 1; Si definisca un vettore (privato? pubblico? statico? non statico?) contenente per ogni tipo di messaggio definito la corrispondente nome in formato di stringa, facendo corrispondere il valore numerico con la posizione nel vettore stesso per una più facile estrazione. La classe deve contenere il seguente metodo: public String gettypename(int i) che restituisce il corrispondente nome del tipo possato come parametro. Nel caso che il valore del parametro sia fuori del range degli indici del vettore definito sopra si restituisca UNKNOWN. Definire poi una classe Message le cui istanze contenengono i seguenti campi: sender: di tipo AgentID che indica il mittente del messaggio; receiver: di tipo AgentID che indica il destinatario del messaggio; type: di tipo int che specifica il tipo del messaggio content: di tipo String che memorizza il contenuto del messaggio; extraargument: di tipo Object che permette di memorizzare eventuali ulteriori informazioni in forma di oggetto. Per ogni classe (anche per la classe MessageType?) si definiscano gli opportuni costruttori. Per esempio, per la classe Message si definiscano i costruttori: 1. public Message () 10

11 2. public Message(int type) 3. public Message (int type, AgentID sender, AgentID receiver, String content) 4. public Message (int type, AgentID sender, AgentID receiver, String content, Object extraargument) Il costruttore (1) crea l oggetto inizializzando tutti i suoi campi a null (e il tipo con UNKNOWN), il costruttore (2) che specifica il tipo del messaggio mentre tutti gli altri campi sono inizializzati a null, il costruttore (3) inizializza l oggetto mediante i valori dei parametri passati al costruttore stesso a parte il campo extraargument che viene inizializzato a null, infine il costruttore (4) inizializza tutti i campi tramite i parametri passati al costruttore. Si definiscano poi un metodo di tipo get ed uno di tipo set, per ogni campo presente nelle classi AgentID e Message (e nelle classi che scriveremo in seguito!); ad esempio, per il campo sender della classe Message: public AgentID getsender(): restituisce l oggetto di tipo AgentID rappresentante il mittente del messaggio contenuto nel campo sender; public void setsender(agentid sender): inizializza il campo sender con il valore contenuto nel parametro sender. Si definisca, per ogni classe introdotta (anche per la classe MessageType?) e che introdurremo in futuro, il metodo public String tostring() che restituisce una stringa che rappresenta l oggetto stesso in formato stampabile su console. Ad esempio, se messaggio è una variabile che contiente un riferimento ad un oggetto di tipo Message, allora messaggio.tostring() restituisce una stringa che stampata dovrebbe risultare qualcosa del tipo: Type: REQUEST Sender: (banditore, Christie s) Receiver: (cliente, Aldo) Content: OFFERTA CORRENTE? ExtraArgument: null Inoltre si definisca per la classe AgentID il metodo public boolean equals(agentid agentid) che restituisce true se l identificatore dell agente passato come parametro ha lo stesso nome e appartiene alla stessa categoria dell oggetto su cui è invocato il metodo, false altrimenti. Si ricordi di scegliere (sapendo giustificarne il motivo) il tipo di visibilità (private? protected? public? default?) per ogni campo, metodo e classe. Infine si definisca una classe ProvaMessaggio contenente un metodo main che effettui il test delle classi precedentemente definite. 11

12 3.2 Parte II: la classe MessageBox Si definisca una classe MessageBox che contenga i campi: owner: di tipo AgentID che specifica il proprietario della casella postale; box: di tipo java.util.list (si scelga l implementazione preferita, ArrayList, LinkedList, Vector ma il campo box deve essere di tipo List) che rappresenta la coda dei messaggi ricevuti dall utente proprietario della casella; ed i metodi: set e get per il campi sopra introdotti; Message readmessage(): restituisce il primo oggetto di tipo Message in coda su box (il più vecchio in attesa); boolean isboxempty(): restituisce true se box è vuota, false altrimenti; Message readmessage(agentid agentid): restituisce il primo oggetto di tipo Message in coda su box il cui sender è agentid; Message readmessage(int type): restituisce il primo oggetto di tipo Message in coda su box il cui tipo è type; Message readmessage(int type, AgentID agentid): restituisce il primo oggetto di tipo Message in coda su box il cui tipo è type e il cui sender è agentid; void writemessage(message message): inserisce in coda alla casella il messaggio passato come parametro. Si noti che tutte le readmessage tolgono il messaggio letto dalla coda. Si provi a cambiare il tipo di implementazione per il campo box (ad esempio, ArrayList anzichè Vector) e si verifichi che ancora tutto funzioni. 3.3 Parte III: gestire gli accessi remoti e sincronizzati in una MessageBox Ogni agente della piattaforma JAM possiede una propria coda di messaggi MessageBox; in tale coda gli altri agenti gli possono far recapitare i messaggi (si veda la Figura 4). La lettura dei messaggi avviene esclusivamente da parte dell agente proprietario della coda mentre la scrittura può avvenire da parte di un qualsiasi altro agente. La coda di messaggi è quindi una risorsa condivisa a cui è necessario garantire l accesso in mutua esclusione ed accessibile remotamente (per la scrittura) in quanto i vari agenti possono risiedere su java virtual machine diverse. 12

13 Figure 4: Scambio di messaggi e uso del MessageBox L interfaccia RemoteMessageBox Al fine di permettere l accesso in maniera remota in scrittura alla coda di messaggi di un agente della piattaforma si introduca l interfaccia remota (cioè questa estende l interfaccia java.rmi.remote) contenente i metodi void writemessage(message message) throws... AgentID getowner() throws... che la classe MessageBox deve implementare Sincronizzare gli accessi alla coda di messaggi Diversi sono gli aspetti da trattare. In primo luogo è necessario garantire l accesso ad una coda di messaggi in mutua esclusione per le operazioni di lettura (readmessage) e scrittura (writemessage) contemporanee (cioè se eseguite su thread diversi) alla stessa coda di messaggi. In secondo luogo, si desidera che le operazioni di lettura di messaggi siano bloccanti. Questo significa che quando un agente effettua una operazione di lettura e non è presente alcun messaggio nella propria coda l esecuzione si arresta per attendere che un altro agente ne recapiti uno. Il thread contenente la lettura deve quindi essere posto in wait, liberare la risorsa ed essere risvegliato quando qualcuno effettuerà una scrittura di un messaggio. Si noti che esistono diversi tipi di letture di messaggi (readmessage), quella generica che legge il primo messaggio in coda e quella che legge dalla coda un messaggio con specifiche caratteristiche (sender e/o tipo di messaggio). Anche in questi casi la lettura è bloccante, ossia il thread contenente la lettura deve essere posto in wait finchè un messaggio con le caratteristiche richieste non viene trovato indipendentemente dal fatto che nella coda siano presenti altri messaggi. Si modifichi la classe MessageBox in modo da soddisfare queste richieste. 13

14 3.4 Parte IV: l Agent Directory Service Layer L ADSL ha lo scopo di pubblicare i RemoteMessageBox degli agenti presenti nella piattaforma in un dato momento. Rappresenta una sorta di rmiregistry in sui è possibile effettuare operazioni di ricerca avanzate. Un agente quando viene creato deve registrare la propria RemoteMessageBox come oggetto remoto (iscriverlo presso un rmiregistry concordato a priori) e quindi richiedere all ADSL l iscrizione presso di esso. Quando un agente A vuole a inviare un messaggio ad un agente B si rivolge all ADSL specificando l identificatore dell agente B, l ADSL restituisce restituisce il RemoteMessageBox di B, sul quale A può invocare la writemessage. Si definisca una interfaccia remota ADSL contenente i metodi: RemoteMessageBox getremotemessagebox(agentid agentid) throw..., che restituisce il riferimento all aggetto remoto RemoteMessageBox dell agente agentid; void insertremotemessagebox(remotemessagebox messagebox) throw..., che richiede l inserimento di messagebox presso l ADSL; void removeremotemessagebox(agentid agentid) throw..., che richiede la cancellazione dell oggetto RemoteMessageBox presente presso l ADSL di proprietà dell agente agentid. Si definisca quindi la classe ADSLImpl che implementa l interfaccia remota ADSL e contenente il campo: messageboxes: contenente gli oggetti remoti di tipo RemoteMessageBox. Si scelga l implementazione più opportuna per messageboxes. Si consideri che l operazione più frequente è la ricerca di un RemoteMessageBox dato un oggetto di tipo AgentID (List? Map? SortedMap?). Si tenga presente che messageboxes è una risorsa condivisa, più agenti possono richiedere inserimenti/cancellazioni/interrogazioni contemporaneamente. Si realizzino le implementazioni dei metodi get, insert e remove in maniera opportuna Gestione degli errori I metodi get/insert/remove della classe ADSLImpl possono incontrare delle situazioni in cui è opportuno sollevare delle eccezioni. Si definisca una eccezione di nome ADSLException lanciata dai vari metodi get/insert/remove (modificare, quindi, anche la definizione dell interfaccia ADSL) che viene lanciata quando: si richiede una insert di un oggetto di tipo RemoteMessageBox non ben formato, cioè quando i suoi campi box e owner non sono inizializzati, il campo owner non contiene un agetid con entrambi i campi name e role inizializzati. Per effettuare questi controlli è consigliabili introdurre dei metodi di tipo 14

15 boolean iswellformed() nelle classi AgentID e RemoteMessageBox (si estendano in modo opportuno le classi e/o le interfacce coinvolte); si richiede una insert di un oggetto di tipo RemoteMessageBox e presso l ADSL è già presente un RemoteMessageBox per lo stesso proprietario; si richiede una remove di un oggetto di tipo RemoteMessageBox non presente presso l ADSL Creazione dell oggeto remoto ADSL Si crei un oggetto di tipo ADSLImpl e si effettui il bind (o il rebind) dell oggetto presso un rmiregistry attivo (si veda la Figura 5). Tutto questo lo si realizzi, ad Figure 5: Creazione di un oggetto di tipo ADSLImpl e iscrizione presso l rmiregistry. esempio, mediante il main di una classe di nome ProvaADSL del tipo: public class ProvaADSL { public static void main(string[] args) { ADSLImpl adsl = new ADSLImpl(); try { // la riga seguente e in alternativa con l attivazione // a prompt del rmiregistry java.rmi.registry.locateregistry.createregistry(2000); Naming.rebind("rmi:// :2000/ADSL", adsl); catch (Exception e) { System.err.println("Failed to bind to RMI Registry"); System.exit(1); A questo punto, in un altra o più classi, ad esempio ProvaRemoteMessage- BoxUno, ProvaRemoteMessageBoxDue, si effettui il lookup presso l rmiregistry 15

16 Figure 6: Lookup dell oggetto di tipo ADSL presso rmiregistry. dell oggetto ADSL creato in ProvaADSL, si veda la Figura 6, quindi si crei un oggetto di tipo MessageBox (che è anche un oggetto di tipo RemoteMessage- Box) e lo si iscriva presso l ADSL attraverso l invocazione del metodo remoto insertremotemessagebox, si veda la Figura 7) Il codice potrebbe essere del tipo: Figure 7: Iscrizione di un oggetto di tipo RemoteMessageBox presso l ADSL. public class ProvaRemoteMessageBoxUno { public static void main(string[] args) { ADSL adsl; AgentID myid; MessageBox box1; try { myid = new AgentID(); adsl = (ADSL)Naming.lookup("rmi:// :2000/ADSL"); box1 = new MessageBox(); box1.setowner(myid); adsl.insertremotemessagebox(box1); catch(exception e) { System.out.println("Failed rmi" + e); 16

17 Ora è possibile da uno dei vari programmi richiedere mediante il metodo getremotemessagebox un oggetto di tipo RemoteMessageBox disponibile remotamente (si veda la Figura 8), quindi invocare su di esso il metodo writemessage Figure 8: Richiesta di un RemoteMessageBox mediante l ADSL. per inserire un oggetto di tipo Message sulla casella remota (si veda la Figura 9). Si legga quindi la propria casella per verificare se sono arrivati messaggi inviati Figure 9: Scrivere un messaggio su un MessageBox remoto. da altri programmi (esempio, ProvaRemoteMessageBoxDue). Infine si cancelli dal ADSL l oggetto MessageBox iscritto precedentemente (questo per simulare il momento che l agente viene tolto dalla piattaforma), si veda la Figura 10. Il codice dovrebbe assomigliare al seguente: public class ProvaRemoteMessageBoxUno { public static void main(string[] args) { ADSL adsl; AgentID myid; MessageBox box1; 17

18 Figure 10: Rimozione della MessageBox dalla ADSL. try { myid = new AgentID(); adsl = (ADSL)Naming.lookup("rmi:// :2000/ADSL"); box1 = new MessageBox(); box1.setowner(myid); adsl.insertremotemessagebox(box1); Message msg = new Message(); AgentID agentremoteid = new AgentID(); RemoteMessageBox remotebox2 = adsl.getremotemessagebox(agentremoteid); remotebox2.writemessage(msg); Message mymsg = box1.readmessage(); System.out.println(myMsg); adsl.removeremotemessagebox(myid); catch(exception e) { System.out.println("Failed rmi" + e); A questo punto si proceda con la compilazione di tutti i file sorgenti > javac *.java la creazione dei file stub per MessageBox e ADSLImpl > rmic -v1.2 MessageBox > rmic -v1.2 ADSLImpl E si proceda con l esecuzione, si avvii lo rmiregistry e ProvaADSL > rmiregistry 2000 & > java ProvaADSL 18

19 (il comando & è per UNIX, per Windows si usino più finestre DOS diverse), entrambi i comandi dati attiveranno un processo che terminerà solo mediante un CTRL-C esplicito. Quindi si lancino da altri due finestre di comando i programi ProvaRemoteMessageBoxUno e ProvaMessageBoxDue > java ProvaRemoteMessageBoxUno Alcune note. Lo scopo dell ADSL è quello di evitare di effettuare presso ogni agente la lookup delle caselle di ogni altro agente presente nel sistema e questo al fine di ottenere una maggiore dinamcità della piattaforma. La lookup nell esempio esposto è effettuato infatti sul solo oggetto di tipo ADSL. Al fine di ottenere un corretto funzionamento della piattaforma è comunque il fatto che gli oggetti MessageBox siano dichiarati anche remoti e iscritti presso un rmiregistry. Infatti, se gli oggetti MessageBox non fossero remoti, l effetto di passarli come parametro del metodo insertremotemessagebox o come valore di ritorno del metodo getremotemessagebox creerebbe una copia presso l ADSL anzichè un riferimento all aggetto stesso e quindi non si avrebbe l effetto desiderato (si veda anche [3, Sezione 5.2]). Altro punto importante da notare è relativo alla realizzazione dei metodi della classe ADSLImpl, questi sono insertremotemessagebox, getremotemessagebox e removeremotemessagebox. In tutti e tre questi metodi si deve cercare un certo RemoteMessageBox dato un oggetto di tipo AgentID, o perchè deve essere verificato se un certo RemoteMessageBox è già presente prima di inserirne uno nuovo (insertremotemessagebox), o perchè deve essere restituito dal metodo stesso come valore di ritorno (getremotemessagebox) o perchè ne è stata richiesta la cancellazione (removeremotemessagebox). È importante assicurarsi che le realizzazioni di questi metodi utilizzino il metodo equals definito in AgentID per un corretto funzionamento. Si osservi come l oggetto di tipo ADSL funga da vero e proprio rmiregistry esteso. Infatti non è necessario effetture alcuna rebind o lookup degli oggetti di tipo MessageBox per condividerne i riferimenti remoti (ma questi comunque debbono essere dichiarati remoti per poter passare il solo riferimento remoto come parametro o valore restituto della insertremotemessagebox e getremotemessagebox, rispettivamente, e non come copia) Un interfaccia grafica per l ADSL Si realizzi un interfaccia grafica del tipo mostrato in Figura 11 che permette di gestire l ADSL e visualizzare i messaggi di log. In particolare, si modifichi la classe ADSLImpl aggiungendo i campi port (di tipo int) e name (di tipo String) che contengono rispettivamente la porta in cui viene avviato lo rmiregistry in cui l oggetto di tipo ADSLImpl viene iscritto. Si introducano poi i tre metodi seguenti: void startrmiregistry(), che avvia un processo rmiregistry sulla porta port della macchina su cui l applicativo è eseguito; void startadsl(), che iscrive (rebind) l oggetto ADSLImpl corrente sullo rmiregistry con nome ADSL; 19

20 Figure 11: L ADSL monitor. void stopadsl(), che cancella (unbind) l oggetto ADSLImpl corrente dallo rmiregistry. I bottoni Start reg., Start up e Shutdown quando premuti richiedono l esecuzione del corrispondente metodo sopra descritto. ADSLMonitor osservatore di ADSLImpl (facoltativo) La classe ADSLMonitor che realizza l interfaccia grafica dell ADSL deve visualizzare una stringa di log per ogni operazione effettuata e visualizzare questa presso un opportuno JTextArea (si veda la Figura 11). Per realizzare questo si faccia in modo che ADSLMonitor risulti un osservatore dell oggetto ADSLImpl creato con la pressione del tasto Start reg. e quindi si modifichi ulteriormente la classe ADSLImpl in modo da rendere gli oggetti creati osservabili. In particolare, devono essere osservate ogni richiesta di esecuzione dei metodi getremotemessagebox, insertremotemessagebox e removeremotemessagebox. Queste richieste di esecuzione devono far comparire un opporturno messaggio sulla Connection console, ad esempio: Iscrizione nuovo box per (Aldo, cliente) Iscrizione nuovo box per (Giovanni, cliente) Iscrizione nuovo box per (Christie s, banditore) Richiesto box (Christie s, banditore) Richiesto box (Aldo, cliente) Cancellato box (Giovanni, cliente) Si noti che poichè la classe ADSLImpl estende già la classe UnicastRemoteObject non è possibile che questa estenda anche la classe Observer, è necessario quindi realizzare in proprio le funzionalità messe a disposizione da questa. 20

21 3.5 Parte V: la classe JAMAgent In questa parte del laboratorio incominceremo a realizzeremo la classe JAMAgent utilizzata nell esempio dell asta per definire la classe Banditore e ClientAgent. Si definisca la classe JAMAgent contenente i campi: mymessagebox: di tipo MessageBox; myid: di tipo AgentID; asdl: di tipo ADSL; ip: di tipo String, contenente l indirizzo IP dello rmiregistry; port: di tipo int, contiene il numero della porta su cui è disponibile lo rmiregistry all indirizzo ip. Si scelgano gli opportuni qualficatori di visibilità e si definiscano, se lo si ritiene necessario, i metodi get e set. Si definiscano inoltre i seguenti metodi (scegliendo l opportuno qualificatore di visibilità): void init(): effettua la lookup presso lo rmiregistry all indirizzo ip/por t dell oggetto ADSL di nome ADSL e memorizza tale riferimento remoto in adsl, quindi, se tutto è andato bene, iscrive presso l ADSL l oggetto di tipo MessageBox mymessagebox. void destroy(): effettua la rimozione della casella mymessagebox dall ADSL; boolean aretheremessages(): restituisce true se vi sono messaggi in mymessagebox, false altrimenti; void send(message message): richiede all ADSL mediante il metodo getremotemessagebox l oggetto di tipo RemoteMessageBox il cui proprietario è il destinatario del messaggio message, su tale oggetto restituito invoca la writemessage di message. Message receive(): legge della propria casella mymessagebox un messaggio mediante il metodo readmessage() e lo restituisce; Message receive(agentid agentid): come per il metodo receive ma il messaggio letto ha come sender agentid; Message receive(int type): come per il metodo receive ma il messaggio letto ha tipo type; Message receive(int type, AgentID agentid): come per il metodo receive ma il messaggio letto ha tipo type e il sender è agentid. Si definiscano quindi i seguenti costruttori: 21

22 public JAMAgent(String name, String role, String ip, int port): dove name è il nome dell agente, role il suo ruolo, ip contiene l indirizzo IP dello rmiregistry e port la porta dello rmiregistry, il costruttore inizializza gli opportuni campi creando l oggetto myid e mymessagebox; public JAMAgent (String name, String role): come sopra ma si assume per l IP il valore e 1099 per la porta; public JAMAgent(AgentID agentid): come sopra dove però l oggetto myid è passato come parametro. 3.6 Parte VI: un interfaccia per monitorare l agente Si realizzi un interfaccia grafica del tipo mostrato in Figura 12 che permette di monitorare l attività di un agente visualizzando i messaggi inseriti nella Message- Box locale e quelli successivamente letti. La classe JAMAgentMonitor contiene Figure 12: Lo JAMAgent monitor. un campo agent inizializzato mediante costruttore il riferimento all oggetto JA- MAgent di cui la corrente istanza di interfaccia grafica è monitor. Si introducano poi i metodi seguenti: void initjamagent(), che invoca il metodo init sull oggetto agent; void startjamagent(), che invoca il metodo start (che verrà introdotto nella Sezione 3.7) sull oggetto agent. void destroyjamagent(), che invoca il metodo destroy sull oggetto agent; I bottoni Init, Start e Destroy quando premuti richiedono l esecuzione del corrispondente metodo sopra descritto. Ad esempio, per avviare l interfaccia grafica sull agente banditore del nostro esempi iniziale si potrà procedere come segue: 22

23 class Banditore extend JAMAgent { public Banditore() { addbehaviour(new BanditoreAstaBehaviour(this)); JAMAgentMonitor monitorbanditore = new JAMAgentMonitor(banditore); Per effettuare un test si può per ora utilizzare un agente generico JAMAgent (che presto dovrà però diventare una classe astratta!). JAMAgentMonitor osservatore di JAMAgent La classe JAMAgentMonitor che realizza l interfaccia grafica per le classi che estenderanno JAMAgent deve visualizzare una stringa di log per ogni operazione effettuata e che si desidera monitorare presso una opportuna JTextArea ( devono essere monitorate almeno le esecuzioni delle send e delle receive), si veda la Figura 12. Per realizzare questo si faccia in modo che JAMAgentMonitor risulti un osservatore dell oggetto di tipo JAMAgent contenuto nel campo agent di JAM- AgentMonitor passato come parametro e quindi si modifichi la classe JAMAgent in modo da rendere gli oggetti creati osservabili. In particolare, devono essere osservate almeno ogni richiesta di esecuzione dei metodi send e receive (ogni receive!). Queste richieste di esecuzione devono far comparire un opporturno messaggio sulla Connection console, ad esempio: SEND message REQUEST to SEND message INFORM to RECEIVE message INFORM from Per realizzare questo l interfaccia JAMAgentMonitor deve implementare la classe Observer e quindi registrare le proprie istanze come osservatori dell oggetto agent, un semplice modo è farlo nel costruttore stesso di JAMAgentMonitor: class JAMAgentMonitor extend implements Observer { private JAMAgent agent; public JAMAgentMonitor(JAMAgent ag) { agent = ag; agent.addobserver(this); e quindi la classe JAMAgentMonitor dovrà implementare il metodo public void update(observable ob, Object extra arg) specificato nell interfaccia Observer. Il metodo update di occuperà di aggiornare la Connection console dove la stringa di log sarà ricevuta attraverso extra arg. La classe JAMAgent deve essere modificata in modo da estendere la classe Observable. Quindi ogni metodo che si desidera monitorare nella Console connection dovrà essere modificato con l aggiunta delle invocazioni dei metodi setchanged e notifyobservers 23

24 class JAMAgent extend Observable { public vodi send(message message) { String log = ; setchanged(); notifyobservers(log); 3.7 Parte VII: definire il comportamento di un agente Obiettivo di questa parte del corso è quella di definire le classi che permettono di specificare il/i compartamento/i di un agente. Ogni comportamento di un agente è eseguito all interno di un thread ad esso dedicato. In JAMabbiamo due tipi di comportamento: uno ciclico ed uno semplice. Il comportamento ciclico consiste nell eseguire il codice specificato in un determinato metodo (action) in modo ripetitivo finchè non si ritiene il compito completato (specificato invocando un altro metodo, done). Il comportamento semplice consiste invece nell eseguire il codice specificato in un determincato metodo (action) una volta sola. Si definisca la classe astratta JAMBehaviour in modo che estenda la classe Thread e contenga i seguenti campi: done, di tipo boolean, che indica se il comportamento è stato eseguito completamente; myagent, di tipo JAMAgent, che indica l agente possessore di tale comportamento. Si definiscano, inoltre, i seguenti metodi: void done(): che imposta la variabile booleana done a true; boolean isdone(): che restituisce il valore corrente della variabile booleana done; void sleep(int ms): che invoca la Thread.sleep sul thread corrente per ms millisecondi; void action() throws InterruptedException: metodo astratto che definisce il codice da eseguire una o più volte. Il costruttore della classe JAMBehavior inizializza il campo myagent (prendendo l opportuno valore da un parametro), impostra done a false. Si definisca ora la classe astratta JAMWhileBehaviour. Questa classe estende la classe JAMBehaviour ed ridefinisce il metodo run di Thread (si veda anche la Figura 13). Poichè in questo caso il comportamento specificato è di tipo ciclico il contenuto di action deve essere eseguito sino a quando non si ritiene il comportamento completato. Il metodo run è qualcosa del tipo: 24

25 Figure 13: Il diagramma a classi di JAMBehaviour, JAMWhileBehaviour e JAMSimpleBehaviour. public void run() { while (!isdone()) try { action(); catch (InterruptedException err) { if (isdone()) return; Il metodo action può contenere delle invocazioni dei metodi receive e send di JAMAgent. Questi metodo posso far si che il thread sia messo in stato di wait in attesa di un messaggio o che la risorsa MessageBox si liberi. Se si invoca il metodo done con l intenzione di far terminare l esecuzione del thread (ad esempio, in seguito alla pressione del bottone destroy) in questi casi non ha alcun effetto, in quanto il thread non sta eseguendo alcun codice e quindi non può accorgersi se è stata richiesta la terminazione. A questo scopo si modifichi il metodo done appena definito in modo che oltre ad impostare il valore della variabile done a true invochi il metodo interrupt della classe Thread public void done() { interrupt(); in modo da permette di far uscire dallo stato di wait il thread corrente. La necessità di catturare l eccezione di tipo InterruptedException è data dalla presenza di tale interrupt. 25

26 Si noti che nella piattaforma Java 2 i metodi stop, suspend e resume sono stati dichiarati deprecati. Lo schema della classe JAMWhileBehaviour è ispirata a quanto mostrato in [3, pagina 47 vecchia edizione, pagina 67 nuova edizione] e presenta una soluzione per permettere ad un thread di interrompere un altro thread senza ricorso al metodo stop. Si definisca ora la classe astratta JAMSimpleBehaviour che ridefinisce il metodo run di Thread in modo che questo invochi in metodo action una sola volta e quindi il metodo done. Si noti che anche qui è necessario includere le due chiamate all interno del costrutto try catch come per il caso della run di JAMWhileBehaviour. Modifiche da apportare alla classe JAMAgent Si modifichi la classe JAMAgent in modo da accogliere la definizione di comportamenti. Prima di tutto si definisca la classe JAMAgent astratta: public abstract class JAMAgent Quindi si aggiunga ai suoi campi il campo mybehaviours di tipo java.util.list (si scelga un implementazione) e si introducano i seguenti metodi: void addbehaviour(jambehaviour behaviour), che aggiunge il comportamento behaviour alla lista mybehaviours; void start(), che invoca il metodo start su ogni oggetto di tipo JAMBehaviour (che sono anche di tipo Thread!) presente in mybehaviours avviando tutti i comportamenti in esso presenti (ci si ricordi di completare l interfaccia grafica della Sezione 3.6 in modo che venga eseguito questo metodo in corrispondenza della pressione del tasto Start ). Si modifichi, infine, il metodo destroy in modo che oltre ad effettuare i compiti già descritti nella Sezione 3.5, invochi anche il metodo done su ogni comportamento presente in mybehaviour. 4 Test da eseguire 4.1 L agente TimeProvider Si definisca un agente TimeProvider che risponde a performative di tipo RE- QUEST con content Che ora e? inviando un messaggio di tipo INFORM contenente l ora di sistema corrente. Si noti che se il messaggio inviato non è di tipo REQUEST allora l agente TimeProvider invia come risposta un messaggio di tipo REFUSE. Se il content della REQUEST non è di tipo Che ora e? allora TimeProvider risponde con un messaggio di tipo NOT-UNDERSTOOD. Si definiscano uno o più agenti che richiedono l ora a TimeProvider. 4.2 L esempio dell asta Si completi il codice dell esempio presentato nella Sezione 2.1 e si effettui il test. 26

27 4.3 Il protocollo di interazione Contract Net (facoltativo) Si realizzi due o più agenti che realizzano il protocollo di interazione Contract Net come descritto in [2]. References [1] M. Baldoni. Esempi di programmi in java. baldoni/didattica/esempiprogrammijava. [2] FIPA Fipa contract net interaction protocol specification. December Copia è disponibile anche al seguente indirizzo baldoni/didattica/aa0304/proginrete/fipa00029.pdf. [3] C. S. Horstmann and G. Cornell. Java 2: Tecniche Avanzate. McGraw-Hill, [4] TILab S.p.A. Java Agent DEvelopment frameork. [5] M. Wooldridge. An Introduction to MultiAgent Systems. Wiley, Disponibile (ma escluso dal prestito) presso la biblioteca del Dipartimento di Informatica di Torino. 27