Progetto RE.VE.N.GE. CORBAREliable and Versatile News delivery support for aGEncies

Realizzazione del Sistema di Consegna

UNIVERSITA’ DEGLI STUDI DI BOLOGNAFACOLTA’ DI INGEGNERIA

Corso di Laurea in Ingegneria InformaticaReti 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 requisitiin 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 = StructuredEventArgomenti 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

Interazione Push

0 0

15

47 47

62

93 94

0 0

31

63

79

0

20

40

60

80

100

0 10 50 100 105 120 150 152

Eventi emessi

Mil

lise

con

di

rice

zio

ne

Increased maxEvents in Queue

Standard Settings

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

Interazione Pull

0 0 16 47 6207015

47156

97047

114047

0

20000

40000

60000

80000

100000

120000

0 10 50 100 120

Eventi emessi

Mil

lise

con

di

rice

zio

ne

Standard Poll Interval

Reduced Poll Interval

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