Java Distributed Event Service

1. 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 maurizio.cimadamore2@studio.unibo.it Relazione a cura di Maurizio Cimadamore

2. Outline • La piattaforma di sviluppo J2EE • Java Distributed Event Service • Architettura di riferimento • Funzionalità avanzate • Benchmark • Servizio JDEFilter • Conclusioni e sviluppi futuri

3. 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!

4. 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 • Scarsa espressività • Quale modello di gestione delle risorse JMS? • QoS non sempre adeguato

5. 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 all’interno dell’architettura J2EE • QoS

6. Client Client Client JDEChannel JDEChannel JDE Server J2EE Application Server JDE – architettura di riferimento

7. 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

8. Client Client Client JDEChannel JDEChannel JDE Server J2EE Application Server JDE – architettura di riferimento

9. JDEChannel JDEChannel 5: report remote event 1: generate remote event EventNotifier EventNotifier Application Server Layer EventNotifier 2: produce EventGenerator EventGenerator EventQueue EventGenerator Registration Registration 4: read/write registration 3: consume Registration DBMS JDE Server – propagazione notifiche Un JDEChannel effettua l’invio di una notifica remota Tutti i JDEChannel interessati all’evento ricevuto vengono notificati via callback-object • Una registrazione JDE è composta dalla tripletta: • Nome evento; • JDEChannel ID; • Callback Object, tramite il quale il JDEChannel può essere notificato. Il tipo di notifica viene utilizzato per scoprire, tramite un’operazione di lookup, quali sono i JDEChannel che devono essere notificati dal server JDE I messaggi vengono consumati dall’ente EventNotifier L’ente EventGeneratorincapsula tale notifica in un messaggio JMS

10. 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

11. 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)

12. 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 callbackasincrono assicura: • Disaccoppiamento tra server e clientJDE. • Determinazione di eventuali comportamenti erronei nella gestione delle notifiche da parte dei client JDE.

13. JDE – Risultati benchmark Il tempo di invio e propagazione delle notifiche si mantiene buono all’aumentare del numero di JDEChannel connessi Il tempo di propagazione della notifica varia linearmente con il numero di JDEChannel connessi

14. 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;

15. 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 J2EEprofessionali (IBM / BEA) per analisi più approfondite;