TELECOM LA B
ITALIA
www.telecomitalialab.com
[Tipo Documento]
Cod. Doc.
DPC 2002.XYZ
JADE White Paper
Versione:
1.0
Data:
27.03.2003
Riservatezza:
Pubblico
Numero di pagine:
14
AUTORE:
Giovanni CAIRE (RO/SI/D)
Laura CONTIN (RO/SI/D)
REVISIONE:
Fabio BELLIFEMINE (RO/SI/D)
APPROVAZIONE:
Fabio BELLIFEMINE (RO/SI/D)
Executive summary
Il presente documento presenta le principali funzionalità e caratteristiche della piattaforma JADE
per lo sviluppo di applicazioni peer-to-peer ad agenti. Viene inizialmente fornita una panoramica sulle
tecnologie di riferimento. Ci si focalizza quindi su JADE e si descrive il modello funzionale e
architetturale della piattaforma, soffermandosi sulle caratteristiche di maggiore rilievo. Infine vengono
presentate varie considerazioni e individuati alcuni tra gli ambiti applicativi che potrebbero trarre
maggior vantaggio dal suo utilizzo.
DT vers. 1
TELECOM
LA B
ITALIA
Cod.: DPC 2002.XYZ
Vers:
1.0
Data:
27.03.2003
Titolo: JADE White Paper
Indice
1
Introduzione.............................................................................................................................. 3
2
Le tecnologie di riferimento ...................................................................................................... 3
2.1 Il modello peer-to-peer........................................................................................................... 3
2.1.1
Modelli architetturali di reti peer-to-peer ....................................................................4
2.2 Il paradigma ad agenti ........................................................................................................... 4
2.2.1
Lo standard di riferimento ..........................................................................................5
2.3 Il concetto di middleware ....................................................................................................... 6
2.4 La tecnologia Java................................................................................................................. 6
3
Che cos’è JADE? ..................................................................................................................... 7
3.1 Modello architetturale ............................................................................................................ 8
3.2 Modello funzionale................................................................................................................. 8
3.3 JADE in ambiente mobile .................................................................................................... 10
3.4 Dettagli tecnici ..................................................................................................................... 11
4
La comunità di JADE.............................................................................................................. 12
4.1.1 Il progetto open source ............................................................................................12
4.1.2 Il Board di controllo ..................................................................................................12
5
Perché usare JADE?.............................................................................................................. 12
5.1 Realizzazione di task complessi.......................................................................................... 13
5.2 Pro-attività............................................................................................................................ 13
5.3 Efficienza delle applicazioni multi-party............................................................................... 13
5.4 Interoperabilità ..................................................................................................................... 13
5.5 Efficienza nello sviluppo delle applicazioni.......................................................................... 13
5.6 Riduzione dei costi............................................................................................................... 14
6
Riferimenti .............................................................................................................................. 14
DT vers. 1
RISERVATEZZA:
Pubblico
Pagina 2 di 14
TELECOM
LA B
ITALIA
Cod.: DPC 2002.XYZ
Vers:
1.0
Data:
27.03.2003
Titolo: JADE White Paper
1
Introduzione
Il presente documento descrive le principali funzionalità e caratteristiche della piattaforma JADE
sviluppata da TILAB in questi anni e attualmente distribuita in Open Source secondo la licenza LGPL.
JADE è un middleware basato su Java per lo sviluppo di applicazioni peer-to-peer ad agenti in
ambiente fisso e mobile. Per meglio comprendere il significato di questa definizione il capitolo 2
fornisce una panoramica sulle tecnologie di riferimento ed in particolare
•
il modello di comunicazione peer-to-peer e le differenze con il modello client-server.
•
il paradigma degli agenti intelligenti e gli standard di riferimento.
•
il concetto di middleware e i vantaggi di un approccio “orizzontale” nello sviluppo di applicazioni
•
la tecnologia Java
Nel capitolo 3 ci si focalizza su JADE, vengono descritte le principali funzionalità, il modello
architetturale e sono presentati alcuni dettagli tecnici.
Il capitolo 4 fornisce i dati più significativi relativamente alla comunità che si è radunata in questi anni
attorno a JADE e presenta il progetto open source e il board di controllo.
Infine nel capitolo 5 sono presentate alcune considerazioni mirate ad evidenziare i vantaggi derivanti
dall’uso di JADE nello sviluppo di applicazioni distribuite.
2
Le tecnologie di riferimento
2.1 Il modello peer-to-peer
Il modello di comunicazione dominante nel panorama odierno delle applicazioni distribuite è
senza dubbio quello “client-server”. Tale modello è basato su una rigida distinzione di ruoli fra i nodi
client ed i nodi server: l’intelligenza, la logica applicativa e le informazioni risiedono interamente sui
server, mentre ogni client è solo uno strumento per gestire l’interfaccia grafica con l’utente e, in
particolare, presentare (render) l’informazione. I nodi server forniscono i servizi, offrono cioè le
capabilities, ma non hanno alcuna capacità di iniziativa, sono reattivi ed attendono di essere invocati
dai nodi client; questi ultimi, di contro, concentrano tutta l’iniziativa e, tipicamente dietro richiesta
dell’utente, richiedono il servizio, lo utilizzano, ma non forniscono alcuna capability. I client possono
comparire e scomparire nel tempo, mentre i server devono tipicamente fornire garanzie di stabilità e
generalmente rispondono ad un indirizzo fisso e pre-definito. I client comunicano con i server, ma non
possono comunicare tra loro.
Un tipico esempio di applicazioni basate sul modello client-server sono le applicazioni web
dove i client sono i browser (il cui unico compito è quello di reperire, su esplicita richiesta dell’utente,
informazioni residenti su siti internet e di presentarle in modo opportuno) e i server sono i siti/portali e
contengono tutte le informazioni e la logica applicativa.
Esistono peraltro varie classi di applicazioni distribuite che non si adattano bene ad un modello
di comunicazione client-server. Se consideriamo ad esempio una chat, dove un messaggio scritto
dall’utente X deve essere ricevuto dall’utente Y e viceversa, osserviamo che i nodi attivi sui terminali
degli utenti devono essere in grado di comunicare tra loro. Altre applicazioni di questo genere sono ad
esempio sistemi di file sharing (come Napster o Gnutella) e giochi multiplayer. Realizzare applicazioni
che appartengono a questa classe con un modello client-server è ovviamente possibile (nel caso della
chat per esempio il messaggio scritto dall’utente X potrebbe essere inviato ad un server centrale dal
quale il client dell’utente Y lo può reperire), ma costituisce sicuramente una forzatura. Infatti il server
non è un elemento necessario da un punto di vista logico, ma solo un artefatto implementativo. Un
modello di comunicazione cosiddetto “peer-to-peer” in cui tutti i nodi possono comunicare tra loro,
ogni nodo può giocare sia il ruolo di iniziatore che quello di risponditore nella comunicazione e dove le
risorse e l’intelligenza applicativa sono distribuite sui vari nodi, risulta decisamente più adatto. In un
modello peer-to-peer scompare completamente la distinzione di ruoli fra “client” e “server”, lasciando il
DT vers. 1
RISERVATEZZA:
Pubblico
Pagina 3 di 14
TELECOM
LA B
ITALIA
Cod.: DPC 2002.XYZ
Vers:
1.0
Data:
27.03.2003
Titolo: JADE White Paper
posto unicamente a nodi “peer”, dotati di una combinazione di iniziativa e di capabilities. La logica
della applicazione non è più concentrata nel server, ma viene distribuita tra i peer.
2.1.1 Modelli architetturali di reti peer-to-peer
Un’altra importante differenza tra i modelli client-server e peer-to-peer riguarda le modalità di
discovery dei nodi con cui interagire. Nei sistemi client-server ogni client deve conoscere il server e,
per contro, non ha mai necessità di conoscere gli altri client (in quanto non comunicherà mai con
loro). Nei sistemi peer-to-peer al contrario chi conosce chi al tempo 0 è del tutto arbitrario. In generale
un peer dovrà “scoprire” quali sono gli altri peer con cui comunicare (ad esempio perché offrono i
servizi di cui ha bisogno) prima di interagire effettivamente con essi. Di conseguenza i sistemi peer-topeer supportano in generale opportuni meccanismi di discovery (pagine gialle e pagine bianche) che
consentono ai vari peer di pubblicare le proprie caratteristiche (ad esempio i servizi offerti) e di
identificare altri peer con determinate caratteristiche. Sulla base di questi meccanismi è possibile
individuare due fondamentali modelli di rete [3] (Figure 1):
•
reti P2P pure o decentralizzate
•
reti P2P ibride o a indice centralizzato
Figure 1. Client/Server (a sinistra), P2P puro (a destra), P2P ibrido (a centro)
Una rete peer-to-peer pura è completamente decentralizzata e i peer hanno una completa
autonomia locale. Nelle architetture peer-to-peer pure, i singoli peer devono saper sfruttare i protocolli
messi a disposizione dalla rete per rintracciare altri potenziali partner (ad esempio mediante messaggi
di discovery) e comunicare a ciascuno di essi l’elenco delle risorse che sono disposti a condividere.
La ricerca della risorsa o servizio di interesse avviene mediante messaggi di query. La comunicazione
avviene su canali bidirezionali senza l’intervento di nessun elemento di coordinazione e gestione. Si
tratta di reti difficili da gestire e mantenere coerenti per l’assenza di nodi di riferimento. All’aumentare
dei nodi aumenta la capacità complessiva del sistema, ma il traffico cresce in maniera esponenziale.
Si tratta inoltre di reti non sicure poiché chiunque può entrare nella rete senza alcun meccanismo di
controllo.
Nelle architetture ad indice centralizzato (peer-to-peer ibrido), invece, sono presenti uno o più
nodi speciali (detti nodi indice) che hanno lo scopo di agevolare la ricerca dei peer attivi, mediante
servizi di discovery, e la ricerca delle risorse di interesse mediante servizi di content look up. Le reti a
indice centralizzato generano tipicamente meno traffico e sono più sicure in quanto richiedono la
registrazione dei peer. Tali reti dipendono però dalla disponibilità del nodo indice. Se tale nodo non è
disponibile il meccanismo di discovery fallisce.
2.2 Il paradigma ad agenti
Sebbene la comunità scientifica ne discuta ormai da tempo, è solo in questi ultimi anni che sta
cominciando a trovare riscontri applicativi pratici un nuovo paradigma di sviluppo software denominato
“Agent Oriented Programming”. Tale paradigma nasce dalla fusione di alcuni concetti derivanti dagli
DT vers. 1
RISERVATEZZA:
Pubblico
Pagina 4 di 14
TELECOM
LA B
ITALIA
Cod.: DPC 2002.XYZ
Vers:
1.0
Data:
27.03.2003
Titolo: JADE White Paper
studi sull’intelligenza artificiale con la tecnologia degli oggetti distribuiti. Per quanto non esista una
definizione universalmente accettata, il paradigma ad agenti prevede la realizzazione di
un’applicazione software come collezione di componenti (dette appunto agenti)
•
autonome, in grado cioè di svolgere task lunghi e complessi senza la necessità di ricevere
istruzioni dall’utente su cosa fare ad ogni passo
•
proattive, in grado cioè di prendere iniziative anche senza uno stimolo esplicito da parte di un
utente
•
comunicative, in grado cioè di interagire tra loro al fine di raggiungere l’obiettivo globale del
sistema.
Il modello architetturale di una applicazione realizzata con tecnologia ad agenti è intrinsecamente
peer-to-peer in quanto ogni agente è potenzialmente in grado di iniziare una comunicazione con ogni
altro agente nel sistema, ogni agente ha una sua logica e delle sue risorse interne, ogni agente è in
grado sia di offrire che di utilizzare servizi e gli agenti necessitano di opportuni meccanismi di
discovery per identificare con quali altri agenti interagire; in ottica peer-to-peer ogni agente è quindi un
peer.
•
•
•
In particolare, inoltre, il paradigma degli agenti pone l’accento sugli aspetti di comunicazione
asincrona – preserva l’autonomia degli agenti che possono gestire in base alla loro logica interna
come e quando gestire i messaggi che gli arrivano
loosely coupled – non è necessaria alcuna conoscenza delle caratteristiche interne
dell’interlocutore per poter interagire con esso
semanticamente comprensibile – ricevendo un messaggio, un agente può attribuirgli il corretto
significato e dedurre l’intenzione in base alla quale quel messaggio è stato inviato.
2.2.1 Lo standard di riferimento
Per sfruttare appieno le potenzialità della tecnologia ad agenti, nel 1996 varie aziende (tra cui
TILAB) nel mondo dell’ICT hanno dato vita a FIPA (Foundation for Intelligent Physical Agents) [2], una
iniziativa internazionale non-profit con l’obbiettivo di produrre specifiche per l’interoperabilità tra agenti
realizzati da produttori diversi e con tecnologie diverse. Essendo focalizzate sugli aspetti di
interoperabilità, le specifiche FIPA non trattano la struttura interna di un agente, ma definiscono un
linguaggio di comunicazione tra gli agenti detto ACL (Agent Communication Language) e delle
modalità di interazione con i servizi di pagine bianche e pagine gialle mediante i quali un agente può
trovare gli altri agenti con cui deve interagire per raggiungere i propri obiettivi.
In particolare il linguaggio ACL è derivato dalla teoria degli atti comunicativi: la comunicazione
avviene attraverso lo scambio di messaggi asincroni corrispondenti all’esecuzione di ben precise
azioni (al pari delle azioni “fisiche” quali la scrittura su un file o la computazione di un valore) dette
“comunicative” quali INFORM, PROPOSE, REQUEST…Oltre all’intenzione comunicativa, che
esprime in modo esplicito che cosa un agente si aspetta dal suo interlocutore, un messaggio ACL
contiene
•
le indicazioni sul mittente e i destinatari,
•
alcuni campi (ad esempio un identificatore di conversazione) che supportano l’implementazione
di interazioni lunghe e complesse quali aste, negoziazioni e deleghe di task,
•
il contenuto vero e proprio del messaggio ovvero ad esempio il fatto del quale si informa il
destinatario (se l’intenzione comunicativa è INFORM) o l’azione richiesta al destinatario (se
l’intenzione comunicativa è REQUEST),
•
le indicazioni sul “content language” (ovvero la sintassi con cui è espresso il contenuto) e sulla
”ontologia” (ovvero il vocabolario dei termini utilizzati nel contenuto e il loro significato) utilizzati.
Gli agenti che prendono parte ad una conversazione dovranno chiaramente “parlare” lo stesso
content-language e “conoscere” la stessa ontologia per capirsi effettivamente.
DT vers. 1
RISERVATEZZA:
Pubblico
Pagina 5 di 14
TELECOM
LA B
ITALIA
Cod.: DPC 2002.XYZ
Vers:
1.0
Data:
27.03.2003
Titolo: JADE White Paper
2.3 Il concetto di middleware
Il termine middleware sta ad indicare l’insieme del software (librerie, framework, toolkit) che
semplifica e rende più veloce lo sviluppo di applicazioni fornendo dei servizi generici, utili per una
molteplicità di applicazioni. Se consideriamo ad esempio un’applicazione distribuita, quando due nodi
attivi su host diversi devono comunicare, dovranno aprire una connessione di rete, trasferire i dati
opportunamente formattati e infine chiudere la connessione. L’implementazione di queste operazioni
è tipicamente complessa e alle volte può anche richiedere più tempo rispetto all’implementazione
della logica applicativa vera e propria. Peraltro tali operazioni sono sostanzialmente indipendenti
dall’applicazione che le attiva e possono quindi essere implementate da un middleware riutilizzabile
da tutte le applicazioni che hanno l’esigenza di trasferire dati. Ossia ogni applicazione non deve
realizzare ex-novo la propria soluzione di comunicazione ma può riusare la soluzione fornita dal
middleware, che sta appunto nel middle fra applicazione e strati di basso livello (sistema operativo,
driver di rete, hardware). La genericità e la trasversalità rispetto a vari domini applicativi suggeriscono
il nome di approccio “orizzontale” in contrapposizione allo sviluppo “verticale” di una soluzione ad-hoc
per uno specifico dominio applicativo come evidenziato in Figure 2.
Applicazioni
Middleware
OS / HW
Figure 2. Approccio "verticale" (a sinistra) e "orizzontale" (a destra)
Da un middleware per applicazioni basate sul modello peer-to-peer ci si può aspettare ad
esempio il supporto alla comunicazione simmetrica tra i peer, al discovery dei peer e alla sicurezza
(autenticazione dei peer, comunicazioni sicure). Da un middleware per applicazioni basate sul
paradigma degli agenti in aggiunta ci si può aspettare ad esempio il supporto alla gestione del ciclo di
vita (attivazione/terminazione degli agenti), all’esecuzione di interazioni complesse come aste e
negoziazioni e alla gestione della semantica e del significato dei messaggi.
2.4 La tecnologia Java
La tecnologia Java ha rappresentato in questi anni una vera e propria rivoluzione nel mondo
dell’Information Technology grazie alle feature avanzate e altamente orientate alla programmazione
ad oggetti del suo linguaggio di programmazione, ma soprattutto alle sue caratteristiche di portabilità
su hardware e sistemi operativi diversi. Considerate le differenze tra i device esistenti, la tecnologia
Java è oggi suddivisa in quattro edizioni con diversi livelli di funzionalità supportate e requirements
sulle risorse del device (Figure 3).
•
Java 2 Enterprise Edition (J2EE) – per ambienti server e applicazioni business
•
Java 2 Standard Edition (J2SE) – per ambienti desktop computer
•
Java 2 Micro Edition (J2ME) – per device portatili e suddivisa a sua volta in due configurazioni
−
CDC (profilo Personal Java) per PDA, set top boxes…
−
CLDC (profilo MIDP) per telefoni cellulari
•
Java card – per ambiente SIM/smart-card.
DT vers. 1
RISERVATEZZA:
Pubblico
Pagina 6 di 14
TELECOM
LA B
ITALIA
Cod.: DPC 2002.XYZ
Vers:
1.0
Data:
27.03.2003
Titolo: JADE White Paper
Figure 3. La tecnologia Java
3
Che cos’è JADE?
JADE [1] è un middleware sviluppato da TILAB per la realizzazione di applicazioni distribuite ad
agenti con architettura di comunicazione peer-to-peer. L’intelligenza, l’iniziativa, l’informazione, le
risorse ed il controllo possono essere completamente distribuiti sia su terminali mobili sia sulla rete
fissa e l’ambiente può evolvere dinamicamente nel tempo con peer, che in JADE sono denominati
appunto ‘agenti’, che nascono, appaiono e scompaiono nel sistema secondo le possibilità e necessità
del contesto applicativo ed in modo pressoché trasparente al programmatore di applicazioni. La
comunicazione fra peer, siano essi sulla rete mobile o su quella fissa, è completamente simmetrica ed
attivabile con iniziativa di qualunque parte.
JADE è interamente realizzato in linguaggio Java e alla base del suo sviluppo sono i seguenti
principi fondamentali:
•
Interoperabilità – JADE è conforme alle specifiche dello standard FIPA (2.2.1). Di
conseguenza un agente JADE può interoperare anche con peer che non usano il run-time di
JADE.
•
Uniformità e portabilità - JADE fornisce alle applicazioni un insieme di API indipendente sia
dallo strato di rete sia dalla versione di JVM. In particolare, l’ambiente run-time fornisce le
stesse API sia per ambiente J2EE, per J2SE, e J2ME. In linea teorica, il programmatore
potrebbe decidere al deployment-time l’ambiente Java di esecuzione.
•
Semplicità d’uso - La complessità del middle-ware viene nascosta al programmatore fornendo
alle applicazioni API molto semplici da usare.
DT vers. 1
RISERVATEZZA:
Pubblico
Pagina 7 di 14
TELECOM
LA B
ITALIA
Vers:
Cod.: DPC 2002.XYZ
1.0
Data:
27.03.2003
Titolo: JADE White Paper
•
Filosofia pay-as-you-go -. Il programmatore non è obbligato ad usare tutte le funzionalità
offerte da JADE e queste, se non usate, non aggiungono overhead computazionale, né
complessità di utilizzo.
3.1 Modello architetturale
JADE include sia le librerie di classi Java per la realizzazione degli agenti sia l’ambiente runtime che fornisce i servizi di base descritti in 3.2 e che deve essere attivo su un device affinché sia
possibile eseguire uno o più agenti su quel device. Ogni istanza del run-time di JADE è detta
container (“contenitore” di agenti) e l’insieme di tutti i container è detto piattaforma e costituisce uno
strato omogeneo che nasconde completamente agli agenti (ovvero alle applicazioni) la complessità e
l’eterogeneità degli strati sottostanti (hardware, sistemi operativi, tipi di rete, JVM).
Come evidenziato in Figure 4, JADE è compatibile con l’ambiente J2ME CLDC/MIDP1.0, ed è
già stato testato con prove in campo eseguite su rete GPRS per diversi terminali commerciali, tra cui:
Nokia 3650, Motorola Accompli008, Siemens SX45, PalmVx, Compaq iPaq, Psion5MX, HP Jornada
560. L’occupazione in memoria della libreria JADE in ambiente MIDP è di circa 100 KB, ma può
ridursi fino all’ordine di 50 KB utilizzando la tecnica del ROMizing, ossia compilando JADE con la Java
Virtual Machine stessa. La ridotta occupazione in termini di memoria ne consente l’installazione su
praticamente tutti i telefoni cellulari purchè java-enabled.
La versatilità di JADE è tale che non solo esso è stato integrato in ambienti con risorse limitate
come i terminali mobili, ma anche in architetture complesse come .NET o J2EE [4] dove JADE diventa
un servizio per eseguire applicazioni multiparty e pro-attive.
Applicazione distribuita costituita da un insieme di agenti
JADE LAYER
Container
Container
Container
Container
JA D E
JAV A V M
J2EE
J2S E
In te rn e t
LAYER
PersonalJava
C L D C
W ire le s s e n v iro n m e n t
Figure 4. L’architettura di JADE
3.2 Modello funzionale
Dal punto di vista funzionale, JADE fornisce i servizi di base necessari alle applicazioni
distribuite peer-to-peer in ambiente fisso e mobile. JADE permette ad ogni agente di scoprire
(discover) dinamicamente altri agenti e comunicare con essi in modalità peer-to-peer. Dal punto di
DT vers. 1
RISERVATEZZA:
Pubblico
Pagina 8 di 14
TELECOM
LA B
ITALIA
Cod.: DPC 2002.XYZ
Vers:
1.0
Data:
27.03.2003
Titolo: JADE White Paper
vista dell’applicazione, ogni agente è identificato da un nome e fornisce un insieme di servizi. Esso
può registrare e modificare i propri servizi e/o cercare agenti che ne forniscano altri, gestire il proprio
ciclo di vita e, soprattutto, comunicare con tutti gli altri peer.
La comunicazione tra gli agenti si basa sullo scambio asincrono di messaggi, un modello di
comunicazione ormai universalmente accettato per comunicazioni distribuite e loosely-coupled1,
ossia fra entità eterogenee e non accoppiate. Per comunicare, un agente invia semplicemente un
messaggio ad una destinazione. Non c’è alcuna dipendenza temporale fra i due in quanto mittente e
destinatario potrebbero anche non essere disponibili nello stesso istante; addirittura il destinatario
potrebbe anche non esistere, o non esistere ancora, o potrebbe essere non direttamente noto al
mittente (es. questo messaggio è per tutti gli agenti interessati al tema “calcio”). Il destinatario può
quindi non saper nulla circa il mittente né il mittente circa il destinatario.
Questa modalità non va a discapito della sicurezza in quanto, per le applicazioni che lo
richiedono, JADE fornisce strumenti di autenticazione e verifica dei ‘diritti’ dei singoli agenti. Quando
necessario, l’applicazione ha quindi la possibilità di verificare l’identità del mittente di un messaggio e
inibire le azioni per cui esso non è abilitato (es. un agente può essere abilitato a ricevere messaggi
dall’agente del capo ma non a trasmetterne). Tutti i messaggi scambiati fra gli agenti sono incapsulati
in un envelope che contiene solo le informazioni necessarie al livello di trasporto e che permette, ad
esempio, di cifrare separatamente il contenuto del messaggio.
La struttura dati del messaggio è conforme al linguaggio ACL definito da FIPA [2] e permette di
rappresentare informazioni di supporto all’interazione, quali timeout per le risposte, variabili di
contesto e, soprattutto, permette di riferire a conversazioni parallele in corso.
Il supporto alla conversazione è una funzionalità importante di JADE che fornisce alle
applicazioni scheletri di pattern tipici di interazione, associati a task specifici, quali la negoziazione, le
aste e la delega di task. Usando questi scheletri (ossia classi astratte Java), il programmatore viene
esulato dal gestire sincronizzazioni, timeout, condizioni di eccezione e, in generale, tutto quanto non
strettamente connesso alla normale logica applicativa.
Per aumentare la scalabilità o per ambienti a risorse vincolate, JADE offre l’opportunità di
parallelizzare diversi task, eseguendoli all’interno di uno stesso thread. Diversi task elementari, quali
ad esempio la comunicazione tra agenti, possono poi essere combinati tra loro per realizzare task più
complessi, che vengono così strutturati come macchine a stati finiti concorrenti.
In ambiente J2SE e PersonalJava, JADE fornisce inoltre la capacità di mobilità del codice e
dello stato di esecuzione. Un agente può cioè interrompere la propria esecuzione su un host, migrare
su un host remoto e riprendere l’esecuzione dallo stesso punto dal quale era stata interrotta. Questa
funzionalità consente ad esempio di distribuire al runtime il carico computazionale movendo agenti su
macchine più scariche in modo del tutto trasparente alle applicazioni.
La piattaforma include anche un servizio di naming e di pagine gialle distribuite e federabili in
modo, ad esempio, da poter gestire domini di servizi di agenti.
Un’altra feature molto importante è costituita dalla disponibilità di una ricca suite di strumenti
grafici di supporto alle fasi di debugging e di gestione/monitoring delle applicazioni. Utilizzando tali
strumenti è possibile ad esempio simulare delle conversazioni remote, ‘sniffare’ conversazioni fra
agenti, monitorare i task eseguiti da uno specifico agente e il suo stato nel ciclo di vita. Per quanto
riguarda la gestione ed il monitoring delle applicazioni messe in campo è inoltre possibile controllare
gli agenti presenti nel sistema, attivare, sospendere, terminare agenti anche su macchine remote,
controllare i servizi pubblicati nelle pagine gialle e generare opportuni log.
1
Una nota tecnica di Gartner [3] prevede che il MOM ( Message-Oriented-Middleware) entro il 2004
sarà la forma dominante di middleware di comunicazione per applicazioni mobili il mercato
business.
DT vers. 1
RISERVATEZZA:
Pubblico
Pagina 9 di 14
TELECOM
LA B
ITALIA
Cod.: DPC 2002.XYZ
Vers:
1.0
Data:
27.03.2003
Titolo: JADE White Paper
Queste funzionalità e, soprattutto, la possibilità di attivare (sia da codice che tramite console) in
modo remoto, anche su terminali mobili J2ME, dei task, delle conversazioni, ed anche dei peer, rende
JADE particolarmente adatto alla esecuzione di applicazioni distribuite, machine-to-machine, multiparty, ad agenti intelligenti pro-attivi.
3.3 JADE in ambiente mobile
Come già anticipato, il run-time di JADE può essere eseguito su una vasta gamma di device
variabile dai server ai telefoni cellulari con l’unico requisito di supportare Java MIDP1.0. Per far fronte
alle limitazioni di memoria e processing power dei device mobili e alle caratteristiche delle reti wireless
(GPRS in particolare) in termini di banda, latenza, connettività intermittente e variabilità degli indirizzi
IP, ed al contempo per essere efficiente quando eseguito su host nella rete fissa, JADE è
configurabile in modo da adattarsi alle caratteristiche dell’ambiente di deployment. L’architettura di
JADE infatti è completamente modulare e attivando alcuni moduli piuttosto che altri è possibile di volta
in volta far fronte a requisiti diversi in termini di connettività, capacità di memoria e capacità
elaborativa.
In particolare, un modulo denominato LEAP consente di ottimizzare i meccanismi di
comunicazione per device con risorse limitate su reti wireless. Attivando tale modulo un container
JADE viene “splittato” come rappresentato in Figure 5: un front-end effettivamente attivo sul terminale
mobile e un back-end attivo nella rete fissa. Un elemento architetturale, detto mediator, deve essere
preventivamente attivato ed ha il compito di istanziare e mantenere i back-end (che sono
sostanzialmente delle entry nel mediator stesso). Per far fronte a problemi di carico è possibile
mettere in campo vari mediator ciascuno dei quali può contenere vari back-end. Ogni front-end è
collegato al relativo back-end mediante una connessione permanente. È importante far notare che il
fatto che un agente sia in esecuzione su un container normale o sul front-end di un container splittato
è del tutto trasparente per l’agente stesso in quanto le funzionalità offerte e le API per accedervi non
cambiano.
•
•
•
•
•
L’approccio descritto presenta numerosi vantaggi:
Parte delle funzionalità del container sono delegate al back-end e ciò consente di rendere il frontend estremamente lightweight in termini di memoria e capacià di processing richieste.
Il back-end maschera agli altri container (siano essi normali o “splittati”) l’effettivo indirizzo IP
assegnato al device wireless. Ciò consente di nascondere al resto della piattaforma un eventuale
cambio di indirizzo.
Il front-end è in grado di riconoscere una caduta della connessione col back-end (dovuta ad
esempio all’assenza di campo) e di riattivarla automaticamente.
Sia il front-end sia il back-end implementano un meccanismo di store-and-forward per cui i
messaggi che non possono essere trasmessi a causa di una temporanea disconnessione
vengono bufferizzati e consegnati non appena la connessione viene ristabilita.
Alcune informazioni che i container si scambiano (ad esempio per reperire il container sul quale
si trova l’agente destinatario di un messaggio) sono gestite unicamente dal back-end. Questo
approccio, unitamente all’utilizzo di una codifica bit-efficient delle comunicazioni tra front-end e
back-end, consente di ottimizzare l’uso della risorsa radio.
DT vers. 1
RISERVATEZZA:
Pubblico
Pagina 10 di 14
TELECOM
LA B
ITALIA
Cod.: DPC 2002.XYZ
Vers:
1.0
Data:
27.03.2003
Titolo: JADE White Paper
J A D EA P I s
“ S p l i t c onta i ne r”
FrontEnd
B a c k End
J A D EA P I s
C onta i ne r
B a c k End
M e di a tor
c o n n e s s io n e
b id ire z io n a le
p e rm a n e n te
FrontEnd
Figure 5. Architettura di JADE per l'ambiente mobile
3.4 Dettagli tecnici
La tabella seguente riassume le principali caratteristiche tecniche di JADE.
Nome
JADE – Java Agent Development Framework
Produttore
TILAB
Sito Web
http://jade.cselt.it/
Linguaggio
Java, piattaforme J2EE, J2SE, J2ME CLDC/MIDP1.0
Disponibilità
Open Source con licenza LGPL.
TILAB può rilasciare licenze commerciali per scopi specifici.
Caratteristiche
tecnico-funzionali
Applicazioni distribuite multi-party con comunicazione peer-to-peer.
Gestione ciclo di vita degli agent.
Pagine bianche e pagine gialle con possibilità di creare grafi di federazione al
run-time.
Strumenti grafici di supporto alle fasi di debugging, monitoring e gestione
Supporto alla migrazione del codice e dello stato dell’agente
Supporto per protocolli di interazione complessi (es. contract-net)
Supporto per gestione del contenuto dei messaggi, incluso XML e RDF
Supporto all’integrazione in pagine JSP attraverso una tag library
Conforme allo standard FIPA
DT vers. 1
RISERVATEZZA:
Pubblico
Pagina 11 di 14
TELECOM
LA B
ITALIA
Cod.: DPC 2002.XYZ
Vers:
1.0
Data:
27.03.2003
Titolo: JADE White Paper
Supporto alla sicurezza a livello di applicazione (attualmente solo in ambiente
J2SE)
Protocolli di trasporto selezionabili anche al run-time, attualmente disponibili
Java-RMI, protocollo proprietario JICP, HTTP, IIOP.
Ambienti di rete
È già stato utilizzato in ambiente di rete BlueTooth, WLAN, GPRS, Internet
Terminali
Tutti i terminali con pJava o J2ME-MIDP1.0, in particolare già testato su Nokia
3650, Motorola Accompli008, Siemens SX45, PalmVx, Compaq iPaq,
Psion5MX, HP Jornada 560.
Tabella 1 - Sommario caratteristiche di JADE
4
La comunità di JADE
Sebbene il copyright di JADE sia oggi interamente posseduto da TILAB, al suo sviluppo
contribuisce una comunità in continua crescita imperniata su due componenti principali: il progetto
open source e il board di controllo.
4.1.1 Il progetto open source
Tutti i sorgenti di JADE sono distribuiti in open source con licenza LGPL [5]. La licenza LGPL
permette il pieno sfruttamento di JADE, anche in ambito di business, con il vincolo che ogni modifica
ed ogni lavoro derivativo di JADE deve essere restituita alla comunità con la stessa licenza. Non
esistono invece vincoli restrittivi sulle applicazioni e/o ogni altro tipo di software che usa JADE. TILAB,
in quanto originatore del progetto, ha il diritto esclusivo di rilasciare licenze commerciali su JADE.
Intorno a questo progetto si è formata una comunità di utilizzatori molto numerosa, che conta
più di mille iscritti (molti dei quali sono contact point di gruppi interni ad un’azienda o ad un’università)
e ha fatto registrare picchi di centinaia di download giornalieri. Gli iscritti provengono in parte
dall’ambiente accademico (JADE è infatti largamente utilizzato a scopi didattici), da centri R&D di
leader mondiali come Motorola, HP, Siemens e Rockwell Automation o da piccole start-up, quali
Mobile Tribe e Acklin, che puntano su JADE come tecnologia abilitante per lo sviluppo del loro
business. In particolare Motorola e Siemens hanno contribuito, nell’ambito di un progetto europeo IST
denominato Leap [6], agli sviluppi che hanno consentito il porting di JADE in ambiente J2ME/MIDP.
Il progetto è supportato da un sito web dal quale è possibile downloadare il codice, reperire la
documentazione segnalare eventuali problemi e trovare link utili oltre che da due mailing-list per gli
sviluppatori che fungono da forum di discussione.
4.1.2 Il Board di controllo
Allo scopo di diffonderne l’uso il più possibile in particolare in ambiente telco, lo sviluppo di
JADE (inizialmente gestito privatamente da TILAB) è recentemente passato sotto il controllo di un
board aperto. Il board è oggi costituito da TILAB (presidente) e da Motorola, ma altri key players del
settore e principalmente manifatturiere e operatori hanno manifestato il proprio interesse ad entrare.
5
Perché usare JADE?
Nel seguito vengono analizzati i punti di forza di JADE. Alcuni di questi, quali la realizzazione di task
complessi o la pro-attività degli agenti, possono riflettersi in un vantaggio importante per alcuni ambiti
applicativi particolari; altri, quali l’efficienza nello sviluppo di applicazioni, sono invece di validità più
generale.
DT vers. 1
RISERVATEZZA:
Pubblico
Pagina 12 di 14
TELECOM
LA B
ITALIA
Cod.: DPC 2002.XYZ
Vers:
1.0
Data:
27.03.2003
Titolo: JADE White Paper
5.1 Realizzazione di task complessi
La comunicazione peer-to-peer abilita lo sviluppo di applicazioni in cui sia richiesta la
realizzazione di compiti lunghi e complessi, quali la contrattazione, il coordinamento tra numerosi
agenti e il reperimento di informazioni distribuite. L’utente di un’applicazione sviluppata su JADE può
fornire all’agente i criteri secondo cui svolgere un determinato task e quindi delegarlo completamente
o in parte. Molti ambiti applicativi possono trarre vantaggio da questa potenzialità, includendo i settori
più disparati, come ad esempio: l’approvvigionamento delle aziende (supply chain management),
pronto intervento (per la gestione di un’emergenza), trasporti (fleet management), aste, turismo
(realizzazione di pacchetti personalizzati), solo per citarne alcuni.
5.2 Pro-attività
Gli agenti di JADE sono in grado di comunicare con altri agenti, senza che questo comporti
alcun intervento umano. Questa capacità, che viene generalmente identificata come proattività, rende
JADE l’ambiente naturale per lo sviluppo di applicazioni machine-to-machine (m2m). Gli esempi di
applicazioni che si potrebbero portare al riguardo sono numerosissimi, includendo ad esempio
l’automazione industriale, il controllo del traffico e la gestione di reti di comunicazioni.
5.3 Efficienza delle applicazioni multi-party
La applicazioni multi-party realizzate in architettura peer-to-peer sono intrinsecamente più
efficienti di quelle realizzate in architettura client-server, in quanto i server possono rappresentare un
collo di bottiglia e un punto critico per l’erogazione del servizio: un crash del server o l’attacco di un
virus possono infatti bloccare anche per giorni un servizio. Inoltre JADE è particolarmente efficiente
per quanto riguarda i tempi di comunicazione tra agenti.
Inoltre il fatto che l’intelligenza, l’informazione e l’iniziativa siano distribuite consente la
realizzazione di processi in cui l’ownership sia distribuita tra i peer, distribuendo in modo opportuno le
azioni a cui ciascun agente è abilitato. Infine JADE consente di introdurre elementi di
personalizzazione per cui il comportamento di ciascun agente può essere basato su un modello
utente che risiede sul terminale e che può essere aggiornato dinamicamente sulla base delle
indicazioni fornite dall’utente o grazie alla capacità di apprendimento automatico degli agenti.
Gli ambiti applicativi in cui possono essere utilizzati servizi multi-party sono molteplici, tra cui:
giochi multiplayer persistenti, car pooling, taxi collettivo, knowledge management, coordinamento
della forza lavoro e vari tipi di organizer (es. meeting organizer, per concordare data e luogo di una
riunione, evening organizer per accordarsi con gli amici per le attività della serata).
5.4 Interoperabilità
JADE è disponibile per tutte le versioni di JAVA, da J2EE a J2ME, abilitando il ‘porting’ di
applicazioni tra i vari ambienti e la comunicazione bidirezionale tra agenti che risiedono su reti di tipo
diverso, siano essi fisse o mobili. Questo consente, ad esempio, all’agente che risiede su un server di
rete (inteso in questo contesto come uno dei ‘peer’) di reperire informazioni su un cellulare.
JADE non solo garantisce l’interoperabilità tra reti e terminali eterogenei, ma anche tra
piattaforme ad agenti diverse, purchè conformi allo standard FIPA. A questo proposito, TILAB ha
partecipato a bake-off organizzati da FIPA in cui è stata verificata l’interoperabilità con altri
middleware.
5.5 Efficienza nello sviluppo delle applicazioni
Il middleware è stato progettato in modo da semplificare tutti gli aspetti di comunicazione e
trasporto messaggi, rendendo trasparenti allo sviluppatore i dettagli di più basso livello e
DT vers. 1
RISERVATEZZA:
Pubblico
Pagina 13 di 14
TELECOM
LA B
ITALIA
Cod.: DPC 2002.XYZ
Vers:
1.0
Data:
27.03.2003
Titolo: JADE White Paper
consentendogli di concentrarsi solo sulla logica dell’applicazione. Questo si riflette in una maggiore
efficienza nello sviluppo delle applicazioni: Siemens ha stimato che l’utilizzo di JADE riduce
mediamente i tempi del 30% rispetto allo sviluppo in ambiente JAVA.
5.6 Riduzione dei costi
La riduzione dei tempi di sviluppo delle applicazioni potrebbe determinare una riduzione dei
costi delle applicazioni stesse. Il risparmio maggiore è però relativo all’acquisto e manutenzione dei
server: il loro utilizzo potrebbe essere infatti limitato a qualche funzione specifica (es. mediator e
localizzazione), delegando i peer allo svolgimento di molte delle funzioni tradizionalmente assegnate
a server potenti e costosi. In alcuni casi si può addirittura ipotizzare la realizzazione di servizi in
architetture serverless.
6
Riferimenti
[1] JADE Web Site, http://jade.cselt.it
[2] FIPA Web Site, http://www.fipa.org
[3] M. Pezzini - Do MOM, ORBs and Data Access Middleware Suit Mobile? Gartner Research Note
Number: T-14-3936, 20 September 2001
[4] BlueJADE, http://sourceforge.net/projects/bluejade
[5] Licenza LGPL, http://www.opensource.org/licenses/lgpl-license.php
[6] LEAP Web Site, http://leap.crm-paris.com/
DT vers. 1
RISERVATEZZA:
Pubblico
Pagina 14 di 14
