Presenta - LIA

Università degli studi di Bologna
Corso di Laurea Specialistica in Ingegneria Informatica
Reti di Calcolatori LS
Java Distributed Event
Service
Bringing events to J2EE platform
Un progetto di:
Maurizio Cimadamore [email protected]
Relazione a cura di Maurizio Cimadamore
Outline

La piattaforma di sviluppo J2EE

Java Distributed Event Service
 Architettura
di riferimento
 Funzionalità
avanzate
 Benchmark

Servizio JDEFilter

Conclusioni e sviluppi futuri
Java 2 Enterprise Edition
La piattaforma di sviluppo J2EE
rappresenta lo standard per lo sviluppo di
componenti server Java-based;
 Integra molteplici tecnologie:

 Enterprise
JavaBeans (EJB)
 Java Message Service (JMS)
…

Manca tuttavia un supporto adeguato per
la programmazione ad eventi in ambito
distribuito!
Java Message Service
JMS permette ai componenti J2EE di
interagire mediante scambio di messaggi
 Presenta i vantaggi tipici di un MOM…

 Disaccoppiamento
(in tempo e spazio)
 Persistenza dei messaggi
 Supporto per la comunicazione many-to-many

… e alcuni limiti
espressività
 Quale modello di gestione delle risorse JMS?
 QoS non sempre adeguato
 Scarsa
Java Distributed Event Service
Java Distributed Event Service (JDE)
fornisce a componenti di un’applicazione
J2EE un supporto per la programmazione
ad eventi
 Due ruoli

 Produttore
di eventi JDE
 Gestore di eventi JDE

Obiettivi:
 Scalabilità
 Integrazione
 QoS
all’interno dell’architettura J2EE
JDE – architettura di riferimento
Client
Client
JDEChannel
JDE Server
J2EE Application Server
Client
JDEChannel
JDE Channel
L’ente JDEChannel disaccoppia i client
JDE dalle risorse J2EE allocate sul server
e necessarie alla comunicazione
distribuita;
 Grazie ad esso un client JDE può:

 Essere
abilitato alla ricezione di notifiche
remote in corrispondenza del verificarsi di
determinati eventi nel sistema (mediante
opportune operazioni di registrazione)
 Effettuare la generazione di una notifica
remota
JDE – architettura di riferimento
Client
Client
JDEChannel
JDE Server
J2EE Application Server
Client
JDEChannel
JDE Server – propagazione notifiche
JDEChannel
5: report
remote event
JDEChannel
1: generate
remote event
Un JDEChannel effettua l’invio
TuttiJDE
i JDEChannel
di una
notifica remota
Application
Una
registrazione
2: produce è
Server Layer
all’evento
composta dallainteressati
tripletta:
Il tipo di notifica viene
ricevuto vengono
EventNotifier
EventGenerator notificati
utilizzato per
scoprire,
EventNotifier• Nome evento;
EventGenerator
EventQueue
via
callback-object
EventNotifier
EventGenerator
tramite un’operazione
di
• JDEChannel ID;
lookup, quali sono i
• Callback
Object,
tramiteche devono
JDEChannel
4: read/write
3: consume
può dal
essere notificati
I messaggiregistration
vengono il quale il JDEChannel
essere notificato.
serverEventGenerator
JDE
L’ente
consumati dall’ente
Registration
Registration
incapsula tale
notifica in un
EventNotifier
DBMS
Registration
messaggio JMS
JDE – Soft state

E’ necessario controllare periodicamente
che le registrazioni JDE presenti sul server
siano valide;
 Una
registrazione è valida se il JDEChannel
cui essa si riferisce è attivo;

JDE adotta la politica Least Recently Used
allo scopo di rimuovere periodicamente le
registrazioni JDE non utilizzate entro un
certo quanto di tempo
JDE – Affidabilità e QoS
Necessario evitare congestione sul server
JDE a fronte di eccessive richieste di
propagazione delle notifiche;
 Politica Random Early Detection per
prevenire la congestione

 Una
notifica viene propagata con una
probabilità proporzionale al numero di
messaggi presenti nella coda JMS di JDE;

Possibilità di configurazione in cluster ad
alta disponibilità (application-server
dependent)
JDE – Callback asincrono


Necessario minimizzare il tempo impiegato dal
server JDE per effettuare la propagazione delle
notifiche;
Inoltre, problemi legati alla semantica
dell’invocazione sul callback object:
 Se
meccanismo sincrono, possibile stallo del server a
causa di un errore nella gestione della notifica (lato
client);

Meccanismo di callback asincrono assicura:
 Disaccoppiamento
tra server e client JDE.
 Determinazione di eventuali comportamenti erronei
nella gestione delle notifiche da parte dei client JDE.
JDE – Risultati benchmark
JDE - performance
Il tempo di invio e
tempo (millisecondi)
Il tempo di propagazione
200
della notifica
varia
linearmente con il
150
numero di JDEChannel
connessi
100
propagazione delle
notifiche si mantiene
buono all’aumentare del
numero di JDEChannel
ricezione notifica
connessi
invio notifica
50
0
1
5
#listeners
10
Esempio concreto: JDEFilter
JDE manca di un servizio di filtraggio delle
notifiche di alto livello;
 JDEFilter integra i servizi offerti da JDE
permettendo all’utente di definire regole
per il filtraggio delle notifiche in base al
loro contenuto;
 Peculiarità:

 File
di configurazione XML
 Uso di motore inferenziale Prolog per
l’applicazione delle regole di filtraggio;
Conclusioni e sviluppi futuri

JDE estende la piattaforma J2EE con un
servizio di comunicazione ad eventi
 Affidabile
 Efficiente
 Scalabile

Molto lavoro ancora da fare…
 Sistema
di nomi per individuare i client JDE
interessati ad un dato evento;
 Impiego di application server J2EE
professionali (IBM / BEA) per analisi più
approfondite;