UNIVERSITA’ DEGLI STUDI DI BOLOGNA
FACOLTA’ DI INGEGNERIA
Corso di Laurea in Ingegneria Informatica
Reti di Calcolatori LS
Progetto RE.VE.N.GE. CORBA
REliable and Versatile News delivery support for aGEncies
Realizzazione del Sistema di Consegna
A cura di: Claudia Fontan
A.A. 2005/2006
Outline








Requisiti progettuali
Analisi del problema
Notification Service
Gestione degli eventi
Implementazione
Test
Conclusioni ed Estensioni future
Demo
2
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
Fonti
Fruitori
Sistema di consegna
3
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
P
Sistema di consegna
P
4
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?
5
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
aleventi
sistema
da realizzare:
 Estende il Applicato
modello ad
di OMG
introducendo
Notizia =evento
StructuredEvent
 StructuredEvent:
con struttura predefinita
Argomenti
di interesse
filtrati
 Capacità di filtrare
gli eventi
in ricezione
a modalità
 PossibilitàSupporto
di garantire
differentipush
QoS e
a pull
seconda del particolare
canale di comunicazione, Proxy o evento considerato
 Implementazione usata: JacORB
 Non realizza la persistenza del canale di comunicazione e degli
eventi
6
Gestione degli eventi
 Eventi possibili:
7
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
8
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’))
9
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
10
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
11
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
Millisecondi ricezione
Interazione Push
100
93
80
94
79
63
60
47
40
Increased max
Events in Queue
62
47
Standard Settings
31
20
15
0
0
0
0
10
50
100
105
120 150
Eventi emessi
152
12
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
Millisecondi ricezione
Interazione Pull
120000
114047
100000
97047
80000
Standard Poll Interval
60000
Reduced Poll Interval
47156
40000
20000
0
7015
0
0
0
10
16
50
47
100
62
120
Eventi emessi
13
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
14