LuCe (Logic Tuple Centres) Oliviero Riganelli Andrea Vallorani
LuCe è un modello per la coordinazione degli agenti Internet. sfrutta la nozione di logic tuple-based based, spazio di interazione per gli agenti internet(tuple Centre). LuCe coordination model fornisce una network-trasparency : gli agenti percepiscono lo spazio di interazione in LuCe come un spazio globale composto da un mezzo di coordinazione identificato da un global name.
Coordination La coordinazione è più di una semplice comunicazione o interoperabilità tra componenti. I sistemi classici di comunicazione e sincronizzazione (es. client-server server) ) sono considerati deboli non riescono a separare la dimensione dell interazione da quella della computazione.
Coordination LuCe system consiste in una collezione di entità di coordinazione (agenti) con capacità computazionali indipendenti. Le loro interazioni determinano il comportamento dell'intero sistema. Logic Tuple Centres supporta la divisione tra computazione e coordinazione.
LP & MAS (1) LuCe adotta il logic tuple centre,, il quale permette di poter sfruttare LP. LP fornisce - un linguaggio per lo sviluppo di un singolo agente (linguaggio di computazione) - un linguaggio per la comunicazione tra agenti (linguaggio di comunicazione)
LP & MAS (2) Inoltre LP consente di - costruire comportamenti sociali, dichiarando le leggi per la coordinazione delle società degli agenti - abilitare gli agenti a ragionare sullo stato dello spazio di interazione, con la possibilità di ridefinire le leggi di coordinazione in base alle social tasks
Prolog & Java Adotta Prolog per la coordinazione tra agenti: - tuple -> Prolog ground fact - tuple-template template -> Prolog clause - tuple matching è l unificazione delle precedenti. - Tuple-Centre -> Prolog ground term Integrazione tra Prolog e Java.
Logic Tuple Space Il vantaggio nell'utilizzo di un tuple space è quello di avere una coordinazione basata sulle informazioni: gli agenti cooperano e si sincronizzano tramite le informazioni condivise nel dataspace. Gli agenti percepiscono il Tuple-Centre come un logic tuple space, al quale si può accedere tramite le tipiche operazioni di Linda: out, in, rd, inp, rdp.
Dal Tuple Space al Tuple Centre Con il tuple space non si possono implementare direttamente politiche di coordinazione gli agenti non si possono astrarre dai dettagli della coordinazione in quanto devono avere coscienza delle policy di coordinazione. non si ottiene più separazione tra computazione e coordinazione in quanto i due aspetti si fondono insieme a partire dalla progettazione dell'agente.
Dal Tuple Space al Tuple Centre Il Tuple Centre oltrepassa questi ostacoli scindendo la rappresentazione delle informazioni dalla loro percezione da parte degli agenti. In questo modo è possibile astrarre le entità al livello desiderato.
Tuple Centre(1) Si comporta come un canale di comunicazione che può essere definito a seconda dei bisogni dell applicazione. Reagisce con specifiche azioni agli accessi eseguiti dagli agenti Ogni LuCe Tuple Centre è identificato da un global name La chiara distinzione tra coordinatori (tuple( tuple- centres) ) e coordinati (agenti) permette al MAS di essere configurato dinamicamente.
Tuple Centre(2) Sia gli sviluppatori che gli agenti intelligenti possono cambiare i social behaviour di un MAS. un tuple-centre è un mezzo di coordinazione che tiene traccia sia dello stato di comunicazione degli agenti sia delle regole di coordinazione degli agenti espresse in termini di linguaggio ReSpect.
(a) Tuple space rd(philo(me,c1,c2)); while (true) { /* main cycle */ think (); /* acquisition */ in(chop(c1)); in(chop(c2)); eat(); /* release */ out(chop(c1)); out(chop(c2)); } (b) Tuple space (deadlock-free) rd(philo(me,c1,c2)); while (true) { /* main cycle */ think (); /* acquisition */ icaneat=false; while (!icaneat) { in(token); if (inp(chop(c1))) if (!inp(chop(c2))) out(chop(c1)); else icaneat=true; out(token); } eat(); /* release */ in(token); out(chop(c1)); out(chop(c2)); out(token); } (c) Tuple centre rd(philo(me,c1,c2)); while (true) { /* main cycle */ think (); /* acquisition */ in(chops(c1,c2)); eat(); /* release */ out(chops(c1,c2)); }
Performance
Reactions(1) Un tuple centre ha esattamente la stessa interfaccia di un tuple space standard ma agisce in maniera diversa in quanto le interazioni sono governate dalle regole di coordinazione contenute al suo interno. Ogni evento di comunicazione può essere costituito da una molteplicità o collezione di attività specifiche che prendono il nome di reactions.
Reactions (2) Una reaction o reazione è definita come un insieme di operazioni non sospensive con una semantica transazionale di tipo success/failure failure. Una success reaction può andare a modificare lo stato delle tuple,, una failed reaction non produce invece effetti. Ogni reazione può liberamente accedere alle informazioni del tuple-centre e modificarle. La programmazione delle reaction richiede la definizione di un appropriato linguaggio di specifica. Il linguaggio usato è il Respect.
LuCe System (1) Fornisce due livelli di astrazione: NTL (network trasparency layer) ) : abilita l astrazione dei nodi di rete, nascondendo la locazione fisica dei tuple centres nella network si occupa del routing dei messaggi tra i nodi CTL (coordination( trasparency layer): Opera in un singolo nodo della rete permette l astrazione delle comunicazioni locali in particolare comunica con il local tuple centre
LuCe System (2) L architettura si distingue per due tipi di comunicazione: Intra-node node(udp): tra demoni e agenti locali(anche tra main demon e TCH) Inter-node node(tcp): solo interazione tra demoni
Architettura di rete NODO A NODO B P1 P2 Pn P1 P2 Pn UDP UDP Main Demon TCP Demon UDP Tuple Centre Handle
TCH architettura(1) Il Tuple Centre Handler,, gestisce le risorse del Tuple Centre,, supportando il reaction model È realizzata tenendo conto delle seguenti specifiche di progettazione(query query/answer): Insertion constraint,, ad un operazione out(t) la tupla t deve sempre essere aggiunta al tuple space Query constraint,, le richieste in(t), rd(t), inp(t), rdp(t) devono essere sempre accodate. Reaction constraint,, il TCH deve prima servire ogni evento di comunicazione ed immediatamente eseguire tutte le reazione ad esso associate
TCH architettura(2) Il TCH è costruito intorno al main loop get_request/serve_request serve_request While (true) { get_request(r), serve_request(r), serve_reactions() } R: incoming operation request
Daemon È un proxy ad-hoc presente in ogni nodo I daemon si occupano dei problemi relativi al tuple centre naming Essi devono conoscere in quale host si trova un determinato tuple-centre ( tc?out(p) ) I demoni devono mantenere una tuple centre allocation table,, specificando per ogni nodo i tuple centres presenti
Conclusioni LuCe mostra un architettura flessibile, adatta per il supporto di sistemi multi-agent eterogenei. LuCe run-time Kernel concepisce tutti gli eventi di comunicazione visibili,
FINE