Java Distributed Event Service Bringing events to J2EE platform Università degli studi di Bologna Corso di Laurea Specialistica in Ingegneria Informatica.

Presentazione sul tema: "Java Distributed Event Service Bringing events to J2EE platform Università degli studi di Bologna Corso di Laurea Specialistica in Ingegneria Informatica."— Transcript della presentazione:

1 Java Distributed Event Service Bringing events to J2EE platform Università degli studi di Bologna Corso di Laurea Specialistica in Ingegneria Informatica Reti di Calcolatori LS Un progetto di: Maurizio Cimadamoremaurizio.cimadamore2@studio.unibo.itmaurizio.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 JDE – architettura di riferimento J2EE Application Server JDE Server JDEChannel Client

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 JDE – architettura di riferimento J2EE Application Server JDE Server JDEChannel Client

9 JDE Server – propagazione notifiche DBMS Registration EventNotifier EventGenerator EventQueue JDEChannel 2: produce 3: consume 1: generate remote event 5: report remote event 4: read/write registration Application Server Layer Un JDEChannel effettua l’invio di una notifica remota L’ente EventGenerator incapsula tale notifica in un messaggio JMS I messaggi vengono consumati dall’ente EventNotifier Il tipo di notifica viene utilizzato per scoprire, tramite un’operazione di lookup, quali sono i JDEChannel che devono essere notificati dal server JDE 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.

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 callback asincrono assicura:  Disaccoppiamento tra server e client JDE.  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 J2EE professionali (IBM / BEA) per analisi più approfondite;