Progetto RE.VE.N.GE. CORBA REliable and Versatile News delivery support for aGEncies Realizzazione del Sistema di Consegna UNIVERSITA’ DEGLI STUDI DI BOLOGNA FACOLTA’ DI INGEGNERIA Corso di Laurea in Ingegneria Informatica Reti di Calcolatori LS A cura di: Claudia Fontan A.A. 2005/2006

2 Outline  Requisiti progettuali  Analisi del problema  Notification Service  Gestione degli eventi  Implementazione  Test  Conclusioni ed Estensioni future  Demo

3 Requisiti progettuali  Si vuole realizzare un sistema middleware di supporto per la distribuzione di notizie su larga scala da parte di agenzie di stampa  Considerando fonti di informazione e fruitori diversi ed eterogenei  Realizzando modalità di interazione di tipo push e pull  Utilizzando il Notification Service di CORBA Sistema di consegna Fonti Fruitori

4 Requisiti progettuali  Fonti  Producono le notizie e le inviano al sistema di consegna  Già realizzate  Fruitori  Ricevono le notizie dal sistema di consegna in accordo agli argomenti di interesse specificati  Negoziano con il sistema la QoS per il servizio di notifica  Possono essere leggeri e dunque non sempre connessi alla rete  Proxy intermedio che consegna le notizie alla riconnessione  Sistema di Consegna  Inoltra le notizie dalle fonti ai fruitori in base al contratto stipulato  Media l’interazione Sistema di consegna P P

5 Analisi del problema  Il sistema di consegna  Inoltra le notizie  Rispettando priorità e tempo di consegna stabiliti dalle fonti  In accordo al contratto stipulato con i fruitori  Tiene traccia degli enti registrati delineandone la sessione in modo forte  Eventi di connessione e disconnessione  Il proxy  Si registra al servizio  Può modificare gli argomenti di interesse  Salva le notizie ricevute per poterle consegnare al fruitore alla sua riconnessione Come tradurre questi requisiti in base alla tecnologia richiesta?

6 Notification Service di CORBA  Realizza il paradigma dell’architettura publish/subscribe  i subscribers si registrano ad un servizio indicando il loro interesse per una determinata categoria di eventi e vengono conseguentemente notificati nel caso in cui i publishers generino tali eventi  Estende il modello ad eventi di OMG introducendo  StructuredEvent : evento con struttura predefinita  Capacità di filtrare gli eventi in ricezione  Possibilità di garantire differenti QoS a seconda del particolare canale di comunicazione, Proxy o evento considerato  Implementazione usata: JacORB  Non realizza la persistenza del canale di comunicazione e degli eventi Applicato al sistema da realizzare: Notizia = StructuredEvent Argomenti di interesse filtrati Supporto a modalità push e pull

7 Gestione degli eventi  Eventi possibili:

8 Gestione degli eventi  Interazione Fonte/Sistema di consegna:  OnLineFonte + id: la Fonte segnala la sua adesione al servizio e comunica il suo identificativo, che viene memorizzato dal Sistema  SendNewsFonte: invio di una notizia in modalità push da parte della Fonte al Sistema di consegna  PullFonte: il Sistema richiede alla Fonte mediante un’interazione pull se ha nuove notizie non ancora inviate  OfflineFonte + id: abbandono del servizio da parte della Fonte; il suo identificativo viene eliminato dalla lista delle Fonti attive  Interazione Sistema di consegna/Proxy:  OnLineUser + userName: il Proxy segnala la sua adesione al servizio e comunica lo username per ottenere un identificativo  NewUser + id: il Sistema memorizza lo username ed assegna al Proxy un identificativo univoco abilitandolo alla ricezione di notizie  ArrivingNews: invio della notizia ai fruitori ed ai Proxy in modalità push  OffLineUser + id: abbandono del servizio ed uscita dal sistema del Proxy; eliminazione dalla lista

9 Gestione degli eventi  Con l’evento ArrivingNews il Sistema di Consegna invia sul canale la notizia ricevuta da una Fonte  Un fruitore (il relativo Proxy)  Sfrutta il servizio solo se dispone di un identificativo  Riceve la notizia soltanto se riguarda uno degli argomenti di interesse specificati  Filtraggio degli eventi  Ricezione del proprio identificativo (esclusivamente):  $type_name == ‘NewUser’ and $event_name == ‘Claudia’  Ricezione delle sole notizie ritenute interessanti:  $type_name == ‘ArrivingNews’ and (($.filterable_data[1].value == ‘Sport’) or ($.filterable_data[1].value == ‘Salute’))

10 Implementazione  GUI per la gestione degli argomenti di interesse e per il controllo di Sistema di Consegna e Proxy  Modularità grazie all’uso di handler per i paradigmi di interazione push e pull  Salvataggio delle notizie ricevute dal Proxy in un file XML  Estendibilità e disaccoppiamento grazie all’uso delle primitive del Notification Service nella gestione degli eventi

11 Test  Due principali fasi di test  Test funzionali: verifica del rispetto delle specifiche e del corretto funzionamento del sistema  Test sull’infrastruttura: analisi delle prestazioni di JacORB in relazione alla modalità di interazione ed ai parametri impostati  Test funzionali effettuati su diversi aspetti  Ricezione delle notizie in modalità push e pull da parte del Sistema di Consegna  Inserimento e cancellazione di una Fonte dalla lista delle fonti attive in seguito agli eventi corrispondenti  Inserimento e cancellazione di un fruitore ed attribuzione di un identificativo univoco nell’interazione tra Proxy e Sistema di Consegna  Ricezione in modalità push delle sole notizie relative ad argomenti di interesse da parte del Proxy  Salvataggio delle notizie in un file XML  Verifiche di funzionamento con Fonti e Proxy multipli

12 Test  Test prestazionali su JacORB: analisi dei parametri che influiscono su tempi di risposta e funzionamento  Interazione push  Configurazioni iniziali: il sistema non è in grado di gestire più di 105 eventi consecutivi  max_events_per_consumer da 100 a 150: il sistema arriva a gestirne 152 ed a parità di numero di eventi si registrano tempi minori  In entrambi i casi avvicinandosi al limite superiore del numero di eventi consecutivi ricevibili i tempi di ricezione tendono asintoticamente ad un limite massimo  Caso comunque estremamente improbabile

13 Test  Interazione pull: accento sul tempo di esecuzione  Configurazioni iniziali: tempi di ricezione estremamente elevati, specie se confrontati con interazione push  supplier.poll_interval da 1000 a 10 ms: tempi di esecuzione paragonabili a quelli della modalità push  Valore originario comunque ragionevole per la natura dell’interazione pull  non si vogliono tutti gli eventi

14 Conclusioni ed Estensioni future  Progetto in grado di raggiungere gli obiettivi posti inizialmente e di soddisfare i requisiti funzionali fissati in fase di analisi  Cruciale importanza del Notification Service di CORBA per architettura e semplicità di implementazione  Possibili estensioni:  Distribuzione del sistema di consegna su più località con opportuni protocolli di coordinamento per la gestione delle notizie  Cambiamento degli argomenti accettati dal sistema di consegna a run time