TesiPapale PDF

Facolt di Ingegneria
Corso di Laurea Magistrale in Ingegneria Informatica
Tesi di Laurea
Un Meccanismo efficiente per

limplementazione del modello content-based
Publish-Subscribe su sistemi topic-based
Relatore: Laureando:
Prof. Roberto Baldoni Fabio Papale
Correlatore:
Dott. Leonardo Querzoni
Anno Accademico 2008/2009

Facolt di Ingegneria
Corso di Laurea Magistrale in Ingegneria Informatica
Tesi di Laurea
Un Meccanismo efficiente per

limplementazione del modello content-based
Publish-Subscribe su sistemi topic-based
Relatore: Laureando:
Prof. Roberto Baldoni Fabio Papale
Correlatore: matricola: 1197571
Dott. Leonardo Querzoni
Controrelatore:
Prof. Giuseppe Santucci
Anno Accademico 2008/2009

Ai miei genitori,
per esser stati un costante sostegno
durante questo lungo e difficile percorso.
Alla mia dolce met,

per aver camminato al mio fianco
dallinizio alla fine.
Ringraziamenti
Per la seconda volta sono arrivato a questo momento, scrivere i ringraziamenti

per la mia tesi di Laurea. Finalmente, si spera, che questa sia lultima!
Prima di tutto vorrei ringraziare il Professor Baldoni, per avermi ispirato con le
sue parole, portandomi sulla retta via : giunto a Roma due anni fa,
affascinato dallIntelligenza Artificiale, bastata una sola lezione del suo corso
per farmi appassionare pi che mai ai Sistemi Distribuiti, portandomi a
rivedere il mio intero piano di studi magistrali. Lo ringrazio inoltre per avermi
affidato a Leonardo, che con la sua passione e perspicacia, mi ha guidato ed
aiutato durante questo duro lavoro di tesi. Grazie a entrambi per avermi
permesso di lavorare ad unidea cos importante ed innovativa.
Inoltre un enorme Grazie ai miei genitori e alla mia famiglia, per avermi
sostenuto in questa pazza idea di specializzarmi a Roma. Grazie mamma e
pap per tutto quello che avete sempre fatto per me, e non vi preoccupate pi:
finalmente finita!!!
Infine, un ultimo ringraziamento lo voglio fare a quella pazzerella che venuta
a Roma con me: Floriana, grazie per avermi aiutato e sostenuto in questi due
anni, e soprattutto per tutti quei momenti (e vi assicuro che sono stati tanti) in
cui ti rompevo le scatole cercando di spiegarti tutte le contorsioni mentali dei
Sistemi Distribuiti e di questa tesi! Grazie Amore.
Grazie a tutti.
Fabio
Un meccanismo efficiente per limplementazione del
modello content-based Publish-Subscribe su sistemi topic-based
Indice
Capitolo 1 - Introduzione ..................................................................................................3

1.1. Contributo della tesi.........................................................................................................7
1.2. Organizzazione del testo.................................................................................................8
Capitolo 2 - I sistemi Publish-Subscribe ....................................................................9
2.1. Descrizione del sistema...................................................................................................9
2.2. Caratteristiche di disaccoppiamento......................................................................14
2.3. Altri paradigmi di comunicazione............................................................................15
2.4. Meccanismi di selezione delle notifiche................................................................17
2.4.1. Channel-based selection..................................................................................18
2.4.2. Topic-based selection.......................................................................................18
2.4.3. Content-based selection..................................................................................19
2.4.4. Type-based selection........................................................................................19
2.4.5. Schemi misti..........................................................................................................19
2.5. Un approfondimento sui meccanismi topic-based e content-based.........20
2.6. Implementazioni.............................................................................................................21
2.6.1. CORBA Event Service........................................................................................21
2.6.2. TIBCO Rendez-vous...........................................................................................23
2.6.3. SCRIBE.....................................................................................................................23
2.6.4. TERA........................................................................................................................24
2.6.5. Elvin..........................................................................................................................25
2.6.6. Gryphon..................................................................................................................25
2.6.7. SIENA.......................................................................................................................26
2.6.8. JEDI...........................................................................................................................26
2.6.9. Hermes....................................................................................................................27
2.6.10. REBECA...................................................................................................................27
1
Capitolo 3 - Trasformare un sistema topic-based in content-based........28

3.1. Introduzione al problema...........................................................................................28
3.2. Una corrispondenza dinamica tra spazi continui e insiemi discreti.........31
3.2.1. Discretizzare lo spazio continuo multidimensionale..........................32
3.2.2. Lalbero di sistema (ST)..................................................................................35
3.2.3. Il problema dei falsi positivi..........................................................................36
3.2.4. I protocolli di discretizzazione dinamica.................................................38
3.2.5. Garantire la consistenza degli alberi nel sistema distribuito..........45
3.3. Linterfaccia content-based.........................................................................................48
3.3.1. La pubblicazione di un evento......................................................................49
3.3.2. Sottoscrizioni ed advertisements................................................................49
3.3.3. Annullamento di sottoscrizioni ed advertisements............................52
Capitolo 4 - Test e risultati sperimentali................................................................54
4.1. Lambiente di simulazione..........................................................................................54
4.2. I test effettuati..................................................................................................................56
4.2.1. Analisi dei tempi di risposta del sistema..................................................56
4.2.2. Efficienza della discretizzazione dinamica..............................................59
4.2.3. Costo della discretizzazione dinamica......................................................63
Conclusioni..........................................................................................................................................64
I risultati ottenuti..............................................................................................................64
Sviluppi futuri.....................................................................................................................65
Appendice A - Implementazione del sistema.............................................................66
Bibliografia.......................................................................................................................................75
2
Capitolo 1
Introduzione
Le architetture dei grandi sistemi informativi sono, ancora oggi, nella

quasi totalit dei casi, costruite su piattaforme client/server. Nel paradigma
client/server due host interagiscono tra loro: uno richiede dati o funzionalit
(client), mentre il secondo (server) li fornisce. Il tipo di comunicazione
sincrono: il client invia una richiesta al server; questo la elabora, e quindi invia
la risposta al client. Durante tutto il periodo di interazione, client e server
risultano impegnati esclusivamente nella transazione e quindi impossibilitati ad
eseguire altre operazioni.
Un esempio di architettura client/server ci dato dal World Wide Web e nello
specifico dal protocollo HTTP usato per richiedere pagine HTML ad un server
web. In questo caso il client, impersonato da un browser, richiede al server una
specifica pagina HTML; il server, ricevuta la richiesta, la elabora, ed invia il
contenuto della pagina al client. In questo semplice esempio possibile
intravedere le caratteristiche del modello client/server che ne costituiscono la
sua forza, ma anche la sua debolezza.
Innanzi tutto bene notare che nei sistemi client/server le entit che possono
interagire in un dato istante sono solo due (client e server): questo rende molto
pi difficoltosa la realizzazione di applicazioni che richiedono comunicazioni
uno-a-molti o molti-a-molti, infatti il server deve essere strutturato in modo tale
che sia possibile gestire parallelamente pi canali di comunicazione
indipendenti con altrettanti client distinti. Inoltre il client, cio lhost che inizia
la comunicazione, deve necessariamente conoscere lindirizzo di rete del server
a cui richiedere le informazioni di cui necessita, e non potr quindi ottenere
servizi se non dai server a lui noti; questa caratteristica detta accoppiamento
spaziale. Il paradigma richiede, affinch la comunicazione abbia luogo, che
3
Capitolo 1: Introduzione
entrambi gli host siano attivi al momento della comunicazione: se il client invia
una richiesta, ma il server che deve riceverla non in quel momento attivo, il
client aspetter inutilmente una risposta che non arriver mai, fino allo scadere
di un timeout; questa caratteristica prende il nome di accoppiamento
temporale. Per concludere, come abbiamo gi accennato, il paradigma prevede
che i due host siano bloccati per tutto il periodo della comunicazione e non
possano, durante questo periodo, compiere ulteriori operazioni: questa
caratteristica detta accoppiamento nel flusso delle operazioni.
Nonostante i limiti che abbiamo ora visto, il modello client/server ha riscosso,
dalla nascita delle reti di elaboratori ad oggi, un incredibile successo. Ci da
imputare sia alla semplicit del modello stesso (solo due entit interagiscono
con un chiaro flusso temporale delle operazioni), sia alla sua adattabilit a
moltissimi ambiti applicativi. Pi in generale il paradigma client/server risulta
adeguato per tutte quelle applicazioni in cui esiste un soggetto che necessita di
un servizio o di un informazione solo in un certo istante nel tempo e sa gi da
chi ottenere questo servizio; il fatto che linformazione venga prelevata dalla
sorgente su richiesta ha portato a definire questo sistema anche come
information pull.
Naturalmente non tutte le applicazioni ricadono in questa categoria. Esistono
applicazioni in cui linformazione ad iniziare la comunicazione, e non la
necessit di ottenere questa stessa informazione. In questo tipo di applicazioni
linformazione interessa solitamente pi di un soggetto e pu essere prodotta in
un istante imprecisato nel tempo: per questo genere di applicazioni pi
naturale pensare ad una forma di interazione in cui sia lentit che produce
linformazione ad inviarla a chi ha espresso un interesse verso
quellinformazione (information push).
Un tipico esempio di information push offerto dai sistemi di monitoring delle
quotazioni azionarie: ad ogni variazione nella quotazione di un singolo titolo,
vengono avvertite (ma dora in poi diremo notificate) tutte le persone che hanno
espresso il proprio interesse nei confronti di quel titolo. In questo ambito, gli
4
operatori di borsa possono trovarsi nelle condizioni di dover prendere molte

decisioni con estrema rapidit a partire dal momento del cambio di valore di un
titolo.
Unapplicazione di monitoring basata sul modello client/server interroga
costantemente un server posto presso la borsa valori per aggiornare i valori dei
titoli (polling). Perch unapplicazione del genere risulti utile deve effettuare
interrogazioni con unalta frequenza per garantire alloperatore un
aggiornamento dei valori delle quotazioni con un ritardo massimo stabilito.
Minore il ritardo massimo accettabile, maggiore la frequenza delle
interrogazioni al server e di conseguenza lo spreco di risorse: infatti ad un
incremento della frequenza di aggiornamento corrisponde un incremento della
probabilit che tra due interrogazioni successive il valore dei titoli a cui
loperatore interessato non sia cambiato, rendendo quindi superflua
linterrogazione. Inoltre unapplicazione strutturata in questo modo
difficilmente sar scalabile verso un largo numero di client (ovvero in grado di
richiedere una crescita di potenza elaborativa proporzionale alla crescita del
numero di richieste da soddisfare): un singolo server dovrebbe elaborare
costantemente, una ad una, tutte le richieste provenienti da tutti i client
interessati ed inviare ogni volta lo stato aggiornato dei valori.
Appare quindi chiaro che la realizzazione di un applicazione come questa
porterebbe ad una forzatura del paradigma client/server.
La ricerca improntata alla risoluzione di questi problemi ha portato
allideazione di nuovi modelli di comunicazione. Tra questi molto credito stato
dato negli ultimi tempi al Publish-Subscribe.
Publish-Subscribe un paradigma di comunicazione asincrono che garantisce
un totale disaccoppiamento tra produttore e consumatori dellinformazione. I
consumatori, chiamati in questo ambito subscriber, possono esprimere il loro
interesse verso un sottoinsieme degli eventi, cio delle informazioni prodotte,
ed essere successivamente notificati di ogni evento generato da un publisher
(cio un produttore di informazioni) che appartiene al sottoinsieme a cui essi
5
sono interessati. Il punto di forza di questo modello risiede nel totale

disaccoppiamento temporale, spaziale e del flusso delle operazioni tra il
publisher ed i subscriber. Lintroduzione di questo nuovo modello allinterno di
applicazioni esistenti al posto di quello client/server ha permesso di migliorare
luso delle risorse da parte delle applicazioni stesse, lasciando inalterato il modo
di operare degli utenti.
Come si vedr nel capitolo successivo (cfr. paragrafo 2.4), i sistemi Publish-
Subscribe si differenziano principalmente in base al meccanismo di selezione
delle notifiche. Nel corso degli anni, uno dei meccanismi che ha riscosso maggior
successo il topic-based, ed il motivo di tale successo facilmente
riconducibile alla sua estrema semplicit (per un approfondimento vedi anche
paragrafo 2.5), la quale porta ad implementazioni molto efficienti. Il rovescio
della medaglia di questo meccanismo il problema dei falsi positivi, o pi
comunemente detti spam: siccome in un tale sistema gli utenti possono
scegliere soltanto largomento, cio il topic, degli eventi o delle sottoscrizioni da
pubblicare, senza poter esprimere ulteriori vincoli, la probabilit di ricevere
degli eventi che in realt non sono di interesse alta.
Per questo motivo, negli ultimi anni, la ricerca si spinta verso altri meccanismi
di selezione delle notifiche, individuando in quello content-based una valida
alternativa al precedente.
Ad oggi molte sono le proposte di sistemi Publish-Subscribe basate su tale
meccanismo (cfr. paragrafo 2.6), che quindi permettono una selezione molto pi
granulare dellinsieme di eventi di interesse, basata sui contenuti degli eventi
pubblicati e non solo sullargomento; di conseguenza, tali sistemi riescono ad
abbattere la probabilit di ricezione dei falsi positivi.
Purtroppo, data la complessit di tali sistemi, che durante le pubblicazione
devono essere in grado di realizzare un instradamento che sia funzione del
contenuto degli eventi stessi, non si riesce ancora a raggiungere i livelli di
efficienza dei sistemi Publish-Subscribe di prima generazione.
6
1.1 Contributo della tesi

In questo lavoro di tesi si cercato di superare i limiti di efficienza che
affliggono i sistemi Publish-Subscribe content-based appena evidenziati,
sviluppando principalmente due idee innovative:
Realizzare un sistema Publish-Subscribe content-based al di sopra

di un generico sistema topic-based, sfruttando quindi lefficienza
di questi ultimi durante linstradamento di eventi e sottoscrizioni,
e contemporaneamente riuscendo a fornire agli utenti
uninterfaccia altamente espressiva, tipica dei sistemi content-
based.
Realizzare unassociazione dinamica tra uno spazio continuo
multidimensionale ed un insieme discreto di elementi,
rappresentando questi i modelli dei dati su cui si basano
rispettivamente i sistemi content-based e topic-based.
In particolare, lo sviluppo di queste due idee ha richiesto:
La realizzazione di un meccanismo dinamico di mapping in grado di

associare ad ogni evento definito dal modello content-based sovrastante,
uno ed un solo topic del sistema topic-based sottostante.
Limplementazione di un prototipo dotato di interfaccia content-based e
del meccanismo di mapping dinamico del punto precedente.
La scelta di un ambiente di simulazione topic-based in cui poter inserire
il prototipo al fine di testare lefficienza del meccanismo dinamico ideato.
Lesecuzione di una serie di simulazioni e test sperimentali, e la relativa
analisi dei risultati ottenuti.
7
1.2 Organizzazione del testo

Nel capitolo successivo analizzeremo le caratteristiche salienti del
modello Publish-Subscribe ed i suoi punti di forza rispetto a quello
client/server; faremo quindi un confronto con altri paradigmi nati come
alternativa al client/server, analizzeremo le varie tipologie di sistemi Publish-
Subscribe, approfondiremo le differenze fra due di queste tipologie (i topic-
based ed i content-based), per concludere poi con unanalisi dei sistemi che
rappresentano lo stato dellarte per le architetture Publish-Subscribe.
Nel terzo capitolo entreremo nei dettagli di realizzazione delle idee alla base di
questo lavoro di tesi; vedremo come sia possibile elevare un generico sistema
topic-based in un pi complesso sistema content-based, realizzando un
meccanismo dinamico per il mapping tra i modelli dei dati dei due sistemi,
senza modificare i meccanismi di instradamento degli eventi e delle
sottoscrizioni propri del sistema topic-based.
Il quarto capitolo sar quindi interamente dedicato ai risultati degli esperimenti
che abbiamo svolto tramite un prototipo appositamente sviluppato, ed integrato
in un simulatore di un particolare sistema topic-based: TERA. Tali esperimenti,
ideati con lo scopo di confrontare il sistema sviluppato con soluzioni basate su
mapping statici, mostreranno come il nostro sistema, dotato di un meccanismo
di mapping dinamico, riesca ad essere, ad un costo relativamente basso, molto
pi efficiente di sistemi content-based basati su mapping statico dello spazio
degli eventi.
8
Capitolo 2
I sistemi Publish-Subscribe
2.1 Descrizione del sistema

Un sistema Publish-Subscribe essenzialmente costituito da un insieme
di client che scambiano eventi tra di loro in modo asincrono comportandosi,
secondo il caso, da produttori o consumatori di informazione [4, 5]. Unentit{
logica, chiamata event notification service (dora in avanti ENS), agisce come
mezzo di interconnessione, garantendo il disaccoppiamento tra i publisher ed i
subscriber (Fig. 2.1). Possiamo immaginare lENS come un servizio raggiungibile
da tutti gli host tramite il quale essi possono comunicare; il modello
architetturale sar a breve approfondito.
Figura 2.1: Architettura Publish-Subscribe
Un evento costituito da dati strutturati solitamente secondo uno schema

nome-valore. Per riprendere lesempio precedentemente visto, un possibile
evento nel sistema di monitoring delle quotazioni azionarie potrebbe essere
[titolo ACME INC, valore=125.50].
Un evento pu essere visto come un punto allinterno di uno spazio n-
dimensionale: se infatti immaginiamo che ciascuno degli n attributi definiti negli
eventi rappresenti una coordinata in uno spazio fittizio, un singolo evento
9
Capitolo2: I sistemi Publish-Subscribe
definisce un valore specifico per ogni coordinata, identificando quindi un punto

nello spazio (Fig. 2.2). Questo spazio fittizio chiamato event-space ed una
caratteristica di ogni applicazione basata sulluso del paradigma Publish-
Subscribe.
Figura 2.2: Esempio di spazio degli eventi bidimensionale
Ogni subscriber dichiara a quali eventi interessato tramite linvio allENS di

sottoscrizioni. Ogni sottoscrizione contiene un insieme di regole che lENS user
per filtrare gli eventi pubblicati e notificare quindi al subscriber solo quelli di
suo effettivo interesse.
Allinterno dellevent-space una sottoscrizione rappresentabile come un
sottospazio definito dai singoli filtri che la compongono (Fig. 2.2). In questo
modo linteresse di una sottoscrizione verso un evento pu essere facilmente
verificato controllando lintersezione nellevent-space tra la sottoscrizione e
levento (questa operazione detta matching dellevento con la sottoscrizione).
Linserimento di nuove sottoscrizioni o leliminazione di sottoscrizioni esistenti
avviene tramite luso delle primitive subscribe() ed unsubscribe() sullAPI
(Application Programming Interface) esposta dellENS (Fig. 2.1).
I publisher inseriscono eventi nel sistema tramite la primitiva notify() sullAPI
dellENS; questi provveder quindi a notificare levento ai subscriber interessati
tramite luso della stessa primitiva sullAPI di ogni singolo subscriber.
LENS è unentit che funge quindi da mediatore tra tutti i publisher e tutti i
subscriber mascherando linfrastruttura che permette la comunicazione tra essi.
10
Questa entit un astrazione la cui implementazione varia in modo significativo

da sistema a sistema. Nei primi esempi di sistemi Publish-Subscribe lENS era
realizzato in modo centralizzato con un programma in funzione su un singolo
server a cui facevano riferimento tutti i publisher e tutti i subscriber. In seguito
ci si resi conto che unimplementazione centralizzata non poteva in alcun
modo porre rimedio ai problemi di scalabilit propri delle architetture
client/server, e si quindi passati ad implementazioni distribuite. In queste
ultime lENS composto da un insieme di processi indipendenti, chiamati
broker, e posti su host distinti che interagiscono per portare a compimento tutte
le operazioni richieste.
In ogni caso, il tipo di implementazione usato per lENS un fattore che rimane
completamente trasparente, sia ai publisher che ai subscriber, i quali
interagiscono con esso esclusivamente tramite lAPI che esso espone.
Nel seguito di questa tesi supporremo di avere a che fare sempre con
implementazioni distribuite dellENS, il cui modello architetturale sar{ ora
brevemente descritto.
Figura 2.3: ENS con un'infrastruttura distribuita
In un sistema Publish-Subscribe distribuito lEvent Notification Service

costituito da un insieme di N processi B1,....,BN, chiamati event brokers, i quali
comunicano attraverso scambi di messaggi. Questi processi, ognuno in
11
esecuzione su differenti host (o nodi), cooperano in modo da realizzare le

funzionalit di un sistema Publish-Subscribe. La figura 2.3 mostra un esempio
della struttura interna di un ENS distribuito dove vari brokers (B) collaborano
per servire le richieste provenienti dai publisher (P) e dai subscriber (S).
Larchitettura generale di un sistema Publish-Subscribe distribuito mostrata
in figura 2.4, ed principalmente costituita da cinque livelli: Network, Overlay,
Routing, Matching e Interface.
Figura 2.4: Architettura generale di un ENS distribuito
Livello di rete. I protocolli di rete legano il sistema Publish-Subscribe alla rete

sottostante permettendo la trasmissione dei dati tra i partecipanti. Dato che un
sistema Publish-Subscribe pu essere distribuito su un insieme eterogeneo di
reti, esso potrebbe utilizzare pi di un singolo protocollo di rete sia per coprire
le possibili eterogeneit software/hardware, sia per massimizzare le
performance.
Livello Overlay. Le primitive di comunicazione fornite dal livello di rete sono

quindi usate dai broker per scambiare messaggi. Ogni messaggio inviato da un
broker Bi a un broker Bj attraverso un canale di livello applicativo, o link, li,j che
li collega. Questi link sono delle pure astrazioni e non rappresentano delle
connessioni durature o permanenti, quindi il vicinato di un broker nella rete
12
overlay determinata solamente da una relazione di conoscenza. Tutti i broker

e i loro link di collegamento, formano una rete di livello applicativo, la overlay
appunto, che incarna il sistema distribuito di notifica di eventi. Questa overlay
pu essere gestita con una soluzione ad - hoc, specificamente progettata per il
particolare sistema Publish-Subscribe in considerazione,oppure con un generico
protocollo di gestione delloverlay (Overlay Maintenance Protocol).
Livello di Routing. In un sistema Publish-Subscribe distribuito gli eventi e le

sottoscrizioni possono essere emessi da uno qualunque dei broker che
costituiscono il sistema. Quindi il sistema deve essere equipaggiato con un
sistema di instradamento degli eventi che sia in grado di realizzare dei corretti
flussi degli eventi allinterno dell ENS e raggiungere tutti i sottoscrittori
interessati. Pi formalmente: dato un evento e pubblicato su un broker Bi e una
sottoscrizione s emessa su un broker Bj, se la sottoscrizione copre levento, il
meccanismo di instradamento deve instradare sia e che s su uno stesso broker
Bk, dove il matching sar elaborato. Questo meccanismo di routing spesso
riferito, in letteratura, come event routing, anche se comprende anche le
sottoscrizioni. Durante linstradamento, un evento potrebbe essere ricevuto da
qualche broker che non ospita nessuna sottoscrizione coprente; messaggi
contenenti tali eventi sono chiamati messaggi di spam, perch il broker spreca
risorse locali inutilmente. Tale problema verr riaffrontato nel corso del terzo
capitolo e, rinominato come Problema dei Falsi positivi, sar studiato in modo
approfondito per capire come pu essere sfruttato per migliorare le prestazioni
di un particolare tipo di sistema content-based, quello proposto in questo lavoro
di tesi.
Livello di Matching. Il matching il processo di controllo se un evento

coperto da una sottoscrizione, cio se un evento soddisfa le condizioni espresse
dalla sottoscrizione. Questa operazione di solito viene effettuata dal sistema
Publish-Subscribe in modo da determinare se notificare un evento ad un
sottoscrittore oppure no, ma, a seconda della particolare implementazione del
13
livello sottostante di instradamento, a volte esso pu essere usato anche

durante il processo di diffusione degli eventi.
Livello di interfacciamento. Questo livello rappresenta come i client, per
esempio i publisher ed i subscriber, interagiscono con lENS. Due strategie
opposte sono solitamente considerate. Con la prima strategia i broker che
costituiscono lENS sono dei server specializzati distribuiti e mantenuti da una
azienda; ogni broker funge da access point per un numero molto largo di clienti,
memorizzando le loro sottoscrizioni e pubblicando i loro dati. Una seconda
strategia richiede invece che ogni client partecipi attivamente allinterno del
sistema anche come broker. Ogni broker, quindi, elabora solo le richieste
provenienti dalle applicazioni locali che vogliono accedere al sistema. E
comunque possibile un approccio misto, ma ad oggi, nessuna delle proposte
esistenti lo adotta.
2.2 Caratteristiche di disaccoppiamento
Lintermediazione fornita dallENS ha lo scopo di isolare completamente

ciascun client da tutti gli altri. Tale isolamento in grado di garantire:
Disaccoppiamento spaziale: Gli elementi che interagiscono non devono

necessariamente conoscersi dato che sia i publisher che i subscriber agiscono
direttamente sullENS; quando un publisher inserisce nel sistema un evento non
sa quanti e quali subscriber saranno notificati; allo stesso modo quando un
evento viene notificato ad un subscriber questi non sa da quale publisher
levento stato inserito nella rete, ne quanti sono i publisher facenti parte del
sistema. Questa caratteristica semplifica luso del sistema in quanto richiede che
ogni entit interagente (publisher o subscriber che sia) conosca esclusivamente
un punto di accesso allENS (solitamente lindirizzo di rete di un broker).
Disaccoppiamento temporale: I subscriber interessati ad un dato evento non

devono necessariamente essere collegati alla rete nellistante di inserimento di
14
esso da parte di un publisher. Allo stesso modo allistante in cui un subscriber

riceve levento il publisher potrebbe essere gi scollegato. Il disaccoppiamento
temporale tra produzione e consumo dellinformazione totale. Questo
semplifica la realizzazione delle applicazioni in quanto lo sviluppatore non deve
pi preoccuparsi di gestire il sincronismo tra produzione e consumazione
dellinformazione.
Disaccoppiamento nel flusso delle operazioni: Il normale svolgimento delle

operazioni allinterno di un client non in alcun modo interrotto dalla necessit
di inviare o ricevere un messaggio dallENS. Linterazione con lENS avviene in
modo asincrono allinterno dei client.
2.3 Altri paradigmi di comunicazione
Parallelamente allo sviluppo dei sistemi Publish-Subscribe si assistito

alla nascita di altri paradigmi tutti improntati a risolvere i problemi che
affliggono le architetture client/server. Nessuna delle alternative che ora
andremo brevemente ad analizzare riesce per a fornire lo stesso grado di
disaccoppiamento che abbiamo riscontrato nei sistemi Publish-Subscribe.
Message passing: si tratta di un paradigma di comunicazione strettamente

legato al concetto di socket, e come tale rappresenta una forma di
comunicazione a basso livello. Con il message passing spesso vengono
demandate allapplicazione molte funzioni basilari, come lindirizzamento fisico
o il data marshaling. La produzione dei messaggi anche in questo caso
asincrona, mentre rimane sincrono il consumo degli stessi. Produttore e
consumatore sono accoppiati sia nel tempo, dato che entrambi devono essere
contemporaneamente attivi al momento dello scambio dei messaggi, che nello
spazio, dato che il produttore deve conoscere lindirizzo fisico del consumatore.
15
RPC - invocazione remota: linvocazione remota di eventi, nelle sue numerose

forme, ad oggi il metodo pi diffuso per implementare il calcolo distribuito.
Con luso di questo paradigma lo sviluppatore pu utilizzare nella propria
applicazione metodi remoti come se questi fossero locali. La semplicit del
paradigma, unita alla sua potenza, ha decretato il suo successo sin dalla prima
apparizione sotto forma di RPC (remote procedure call), per continuare nelle
successive incarnazioni object-oriented (Java RMI, CORBA, Microsoft DCOM).
Daltra parte la natura uno-ad-uno della comunicazione con RPC rende poco
naturale il suo uso in applicazioni che richiedono comunicazioni del tipo uno-a-
molti. Inoltre lintrinseca sincronia di RPC introduce forte accoppiamento
temporale, spaziale e nel flusso delle operazioni sugli host interagenti.
Notifications: si tratta di una forma primitiva di Publish-Subscribe. Con questa

architettura i subscriber esprimono il loro interesse in un qualche tipo di
informazione direttamente presso il publisher da cui quellinformazione sar
originata. In questo caso si ha un completo disaccoppiamento nel flusso delle
operazioni dato che linformazione verr recapitata al subscriber solo nel
momento in cui sar disponibile, tramite luso di un callback precedentemente
dichiarato. Permane invece un forte accoppiamento spaziale dato che ogni
subscriber interessato ad un certo genere di informazione dovr conoscere in
anticipo quale publisher sar fonte di quellinformazione.
Shared spaces: il paradigma distributed shared memory fornisce agli host

partecipanti al sistema di calcolo distribuito, uno spazio di indirizzamento
comune; la comunicazione tra gli host avviene scrivendo e leggendo dati in
questo spazio comune. Il tipo di memoria condivisa più semplice è fornito dai
cosiddetti tuple-spaces, spazi di memorizzazione condivisi in cui le informazioni
assumono la forma di tuple ordinate accessibili da tutti gli host partecipanti. La
comunicazione tra host avviene tramite una primitiva di scrittura delle tuple
(out()), una di lettura e cancellazione (in()), ed una di sola lettura (read()). Gli
shared spaces garantiscono un completo disaccoppiamento temporale e
16
spaziale tra i partecipanti, ma richiedono che il prelievo delle tuple dallo spazio
condiviso sia sincrono.
Code di messaggi: le code di messaggi riprendono molti degli aspetti principali

dei tuple spaces aggiungendo caratteristiche di ordinamento temporale dei
messaggi, e propriet transazionali alle operazioni. Le operazioni di prelievo di
informazioni dalle code sono simili alla primitiva in() dei tuple spaces, ma in
questo caso quale informazione viene prelevata dipende dallistante di
inserimento di questa nella coda e non dalla sua struttura. Come nel caso degli
shared spaces le code di messaggi offrono disaccoppiamento nel tempo e nello
spazio, ma non nel flusso delle operazioni.
2.4 Meccanismi di selezione delle notifiche
La scelta di un adeguato metodo di selezione degli eventi un argomento

di cruciale importanza nella progettazione di un sistema Publish-Subscribe, in
quanto la scalabilit del sistema stesso dipender da esso. Un metodo di
selezione che imponga scelte troppo generiche porterebbe alla diffusione di
notifiche inutili e costringerebbe i subscriber ad effettuare ulteriori filtraggi
allarrivo delle notifiche stesse. Daltra parte un meccanismo in grado di offrire
unalta espressivit, e quindi una maggiore specificit nella generazione dei
filtri, renderebbe pi complesso e computazionalmente impegnativo il
meccanismo di routing delle notifiche, cio quel meccanismo che, allinterno
dellENS, porta le notifiche dal broker di ingresso a quelli su cui sono registrate
le relative sottoscrizioni. Proprio il problema che si pone davanti a questa scelta
ha ispirato questo lavoro di tesi, il cui contributo principale la realizzazione di
un sistema in grado di offrire unalta espressivit{, pur mantenendo la
complessit, in termini di routing degli eventi, dei sistemi che impongono scelte
troppo generiche. Analizzeremo ora i cinque principali approcci adottati nelle
implementazioni oggi esistenti, mettendo in luce il loro grado di espressivit.
17
2.4.1 Channel-based selection.

I primi esempi di sistemi Publish-Subscribe hanno adottato uno spazio degli
eventi suddiviso in canali. Quando un evento viene inserito nel sistema
necessario specificare il canale di appartenenza. Questo meccanismo risulta
molto efficace dal punto di vista della consegna degli eventi in quanto la
suddivisione in canali degli eventi e dei subscriber permette di adattare noti
algoritmi di multicasting al sistema di consegna delle notifiche. Daltra parte
sono evidenti i limiti di espressivit: se un subscriber ha interesse per pi canali
simili dovr inserire una sottoscrizione per ciascun canale; se un subscriber non
interessato a tutte le notizie pubblicate allinterno di un canale, dovr adottare
qualche strategia di filtraggio una volta ricevuta una notifica. E chiaro quindi
che questo metodo non permette unalta selettivià sulle notifiche se non
moltiplicando il numero di canali. A questo si aggiunge laccoppiamento tra i
publisher ed i subscriber dato dal fatto che un publisher deve conoscere in
anticipo i canali possibili per poi scegliere quello su cui inserire una notifica, ed i
subscriber devono conoscere i canali dai quali potranno ricevere le notifiche a
cui sono interessati.
2.4.2 Topic-based selection.

Il passo successivo nellevoluzione dei sistemi Publish-Subscribe stata
lintroduzione di una gerarchia dei canali. In questi sistemi [6, 7, 8] possibile
creare canali (che in questo caso prendono il nome di topic) nidificati: quando
un subscriber sottoscrive un canale riceve tutte le notifiche create in esso o in
uno dei canali sottostanti nella gerarchia. Questa semplice modifica ha portato
alla realizzazione di prodotti commerciali di successo tramite i quali possibile
implementare applicazioni anche molto complesse. Nonostante la maggiore
flessibilit offerta dai sistemi topic-based, in essi possiamo riscontrare tutti i
limiti propri dei sistemi channel-based.
18
2.4.3 Content-based selection.

Mentre con i due metodi precedentemente analizzati il contenuto di un evento
rimaneva opaco allevent notification service, nel caso di content-based
selection [9, 10, 11] la selezione delle notifiche da recapitare ai subscriber si
basa sullapplicazione dei filtri, da cui le sottoscrizioni sono composte, al
contenuto degli eventi. Lincremento di espressivit ottenuto permette di
ridurre, se non annullare completamente, il rischio di notificare ad un
subscriber un evento a cui non realmente interessato. Il rovescio della
medaglia dato dalla complessit nellimplementazione di efficaci algoritmi di
routing delle notifiche e dalla minore scalabilit di sistemi basati su questo
metodo. Il content-based routing garantisce un completo disaccoppiamento tra
publisher e subscriber.
2.4.4 Type-based selection.

Molto spesso, in un sistema topic-based, le notifiche appartenenti ad un canale
oltre a mostrare un affinit nel contenuto, mostrano una quasi totale identit
nella struttura. Questa idea ha portato a sostituire il concetto di topic con quello
di tipo. Grazie a questa scelta la gerarchia dei tipi non deve essere pi
esplicitamente dichiarata (come nel caso topic-based), ma viene indotta dalla
struttura delle classi che realizzano i tipi.
2.4.5 Schemi misti.

Molte applicazioni richiedono la trasmissione di informazioni dalla struttura
variegata che permette di attuare un approccio misto: un primo
partizionamento con una metodologia topic-based, per poi affinare la selezione
sugli attributi rimanenti per mezzo di tecniche di filtraggio tipiche dei sistemi
content-based. Data la variet delle applicazioni per cui consigliabile luso del
paradigma Publish-Subscribe, un approccio misto ha il grande vantaggio di
risultare pi facilmente adattabile ai vari possibili scenari.
19
2.5 Un approfondimento sui meccanismi topic-based e content-

based
Il paragrafo precedente ha fornito una visione generale di tutti i

meccanismi di selezione degli eventi su cui si basano i sistemi Publish-
Subscribe. In questo paragrafo si vuole dare un approfondimento su due dei
meccanismi precedentemente introdotti, dato che sono gli elementi
fondamentali di questo lavoro di tesi: i meccanismi topic-based e content-based.
Come si vedr{ nel terzo capitolo, lobiettivo di questo lavoro di tesi quello di
trasformare un sistema Publish-Subscribe topic-based in un sistema content-
based, con lintento di superare i limiti imposti dal primo modello senza
introdurre leccessiva complessit{ che caratterizza le implementazioni del
secondo modello. Questo paragrafo, quindi, analizza in modo pi approfondito i
due modelli confrontandone vantaggi e svantaggi.
In un sistema topic-based il modello dei dati estremamente semplice: esso
caratterizzato da un insieme discreto di argomenti, i topic, ai quali gli utenti
devono riferirsi per pubblicare eventi o per comunicare i loro interessi, cio
effettuare le sottoscrizioni (figura 2.5). Questa estrema semplicit porta a
realizzare implementazioni molto efficienti, che riescono ad avere dei livelli di
routing e di matching (vedi paragrafo 2.1) molto efficaci e veloci.
In un sistema content-based invece, il modello dei dati non pi un insieme
discreto, bens diventa uno spazio continuo multidimensionale definito da una
serie di attributi (una dimensione per attributo), i quali a loro volta definiscono
il contenuto degli eventi. Gli utenti di un sistema content-based, quindi,
pubblicano eventi definiti allinterno di questo spazio (ogni evento un punto
dello spazio multidimensionale), e comunicano le loro sottoscrizioni, le quali
rappresentano una particolare regione multidimensionale contenuta nello
spazio del sistema. In questo modo, ad un sottoscrittore saranno notificati solo e
soltanto quegli eventi che ricadono nelle regioni di interesse da lui definite.
20
Indubbi sono i vantaggi di una tale soluzione, ma come anticipato nel paragrafo
precedente, essa comporta implementazioni dei livelli di routing e di matching
abbastanza complesse.
Figura 1.5: Confronto tra i meccanismi topic-based e content-based
Questo lavoro di tesi, quindi, cerca di realizzare unimplementazione efficiente

del meccanismo content-based, prendendo come punto di partenza il
meccanismo topic-based, per cercare di sfruttare lefficienza dei livelli di routing
e di matching che si riesce ad ottenere con questo tipo di sistemi. Il terzo
capitolo, quindi, affronta la problematica di come realizzare una tale
implementazione.
2.6 Implementazioni
Analizzeremo ora le principali implementazioni esistenti del paradigma

Publish-Subscribe.
2.6.1 CORBA Event Service.

Un richiesta CORBA standard genera un tipo di comunicazione sincrono. Per
superare questa limitazione e permettere un maggiore disaccoppiamento nella
comunicazione tra processi, lOMG ha introdotto il concetto di Event Service.
LEvent Service [5] è un servizio offerto da CORBA che permette di
disaccoppiare la comunicazione tra oggetti. Esso definisce due ruoli per gli
21
oggetti: produttori e consumatori di informazione. Linformazione viene fatta

transitare dai produttori ai consumatori attraverso richieste CORBA standard.
CORBA Event Service supporta due tipi di approccio per lavvio di una
comunicazione e due per forma che la comunicazione pu assumere. I due
approcci possibili per instaurare una comunicazione sono il modello push e
quello pull. Il primo permette ad un produttore di informazioni di iniziare il
trasferimento dei dati verso i consumatori; il secondo permette al consumatore
di iniziare la comunicazione richiedendo i dati ad un produttore. Nel primo caso
liniziativa lasciata ai produttori, nel secondo ai consumatori. Il tipo di
comunicazione pu poi essere generico o tipizzato. Nel primo caso
linformazione, oggetto della comunicazione, completamente nascosta al
servizio: la comunicazione avviene quindi per mezzo di semplici operazioni di
push/pull nelle quali lunico parametro il pacchetto contenente linformazione
da trasferire. Nel secondo caso linformazioni strutturata e pu essere definita
come lo sviluppatore preferisce.
LEvent channel permette a pi produttori e pi consumatori di comunicare in
modo asincrono comportandosi esso stesso come produttore e consumatore.
CORBA Event Service si configura quindi come una classica implementazione di
servizio Publish-Subscribe channel-based.
Successivamente lOMG ha rilasciato la specifica relativa a CORBA Notification
Service [12], unevoluzione dellEvent Service. Allinterno di CNS i messaggi
possono essere di tre tipi: CORBA Any, un oggetto corba tipizzato in modo
statico, o un Structured Event composto da un tipo, pi campi filtrabili con una
struttura nome-valore, ed un payload non filtrabile. Nel caso venga utilizzato
questultimo genere di messaggi, il canale permette ai consumatori che vogliono
dichiarare il proprio interesse, di specificare un filtro da applicare ai messaggi in
transito attraverso il canale. Oltre a questa caratteristica, che avvicina CNS ai
sistemi Publish-Subscribe content-based, anche possibile federare pi canali
indipendenti in modo da formare una semplice rete per la diffusione degli
eventi.
22
2.6.2 TIBCO Rendez-Vous

TIBCO Rendezvous [13] unimplementazione commerciale di grande successo
del paradigma Publish-Subscribe. Si tratta di un sistema topic-based distribuito.
Il suo funzionamento incentrato sulla definizione di una spazio di indirizzi
comune tanto ai messaggi quanto ai subscriber. Ciascun subscriber si registra
presso il servizio indicando gli indirizzi a cui interessato (il linguaggio per la
dichiarazione degli indirizzi reso pi espressivo dalla possibilit di usare
wildcards). Allo stesso modo, allatto della generazione di un messaggio da parte
di un produttore, questo viene associato ad uno o pi specifici indirizzi e
recapitato quindi a tutti i relativi subscriber.
2.6.3 SCRIBE
SCRIBE [6] un implementazione del modello Publish-Subscribe topic-based
basato su una overlay network gestita da Pastry [14]. SCRIBE in grado di
gestire un alto numero di topic, ciascuno associato al proprio gruppo di
publisher e subscriber. Ogni subscriber deve dichiarare il proprio interesse per
un certo topic al sistema; questo mantiene, per ogni topic, un albero di multicast
che ha la sua base in un nodo di rendez-vous, e che contiene tutti i nodi che
hanno dichiarato il proprio interesse nei confronti del topic.
Allinserimento di un evento allinterno della rete, questo viene per prima cosa
inviato al nodo di rendez-vous responsabile per il suo topic, e da questo
inoltrato, tramite lalbero di multicast, a tutti i subscriber.
Questa particolare gestione dei topic basata sulla definizione di un nodo di

rendezvous e sul mantenimento del relativo albero di multicast, deriva
dallinfrastruttura peer-to-peer sottostante offerta da Pastry.
Il particolare metodo con cui, dato un topic, viene scelto il relativo nodo di
rendezvous (basato sullhashing del topic stesso), permette una buona
distribuzione del carico tra tutti i nodi appartenenti alla rete.
23
2.6.4 TERA
TERA [24] unimplementazione del modello Publish-Subscribe topic-based
basato su overlay. La novit interessante che introduce questo lavoro un
meccanismo chiamato Interest Clustering, con il quale si cerca di ridurre il
traffico inutile allinterno dellENS e soprattutto il numero di messaggi
indesiderati, i cosiddetti spam, notificati agli utenti.
Dato che questo il sistema topic-based utilizzato per simulare e testare il
sistema sviluppato in questo lavoro di tesi, doveroso trattarlo un po pi
approfonditamente.
Il meccanismo di interest clustering basato sul concetto di similarit delle
sottoscrizioni: quando le sottoscrizioni di un insieme di client sono
sufficientemente simili, allora possibile unire i client in un unico cluster. In
questo modo il cluster ricever principalmente traffico dati relativo alle
sottoscrizioni che hanno dato vita al cluster stesso, diminuendo quindi la
probabilit di ricevere spam. In un sistema Publish-Subscribe cos fatto, la
diffusione di un evento si divide in due fasi ben distinte: in una prima fase,
chiamata Outer-Cluster Routing, levento deve essere instradato nel sistema fino
a trovare il cluster associato alle sottoscrizioni che coprono levento; quindi,
trovato il cluster, inizia la seconda fase, chiamata Inner-Cluster Diffusion, in cui
levento viene inviato a tutti i client costituenti il cluster.
TERA, essendo topic-based, implementa un controllo della similarit delle
sottoscrizioni molto semplice ed efficiente: due sottoscrizioni si dicono simili se
esse si riferiscono allo stesso topic. In questo modo quindi, possiamo avere due
casi: o le sottoscrizioni non sono simili perch si riferiscono a diversi topic,
oppure sono perfettamente simili, in quanto si riferiscono allo stesso topic.
Come mostrato in figura 2.6, TERA implementa una overlay a due livelli: il
primo livello costituito da una overlay generale a cui appartengono tutti i
client del sistema Publish-Subscribe, ed qui che viene effettuata la prima fase
del processo di diffusione di un evento (in TERA anche le sottoscrizioni vengono
diffuse in questa overlay), tramite un cammino random nel grafo costituito dai
24
nodi della overlay; il secondo livello costituito invece da una serie di overlay,
una per ogni cluster di similarit, ed qui che avviene la seconda fase del
processo di diffusione di un evento, diffondendo levento in tutti i client della
cluster overlay che copre levento.
Figura 2.6: Architettura di TERA
2.6.5 Elvin
Elvin [15, 16] un prototipo avanzato di sistema Publish-Subscribe content-
based. La sua caratteristica principale un meccanismo, chiamato di quenching,
usato dai publisher per ridurre il numero di notifiche generato; in base a questo
meccanismo ciascun publisher pu interrogare il sistema per ottenere una
rappresentazione degli interessi espressi dai subscriber; sulla base di questa
rappresentazione il publisher pu quindi stabilire quali eventi devono essere
notificati e quali invece possono essere scartati, in quanto non sarebbero di
interesse per nessun subscriber.
Il problema generato da questo metodo dato dal fatto che, quando un
publisher abilita il quenching su di un server, questi girer su di lui lintero
database delle sottoscrizioni per ogni singolo cambio di sottoscrizione,
generando una notevole quantit di traffico.
2.6.6 Gryphon
Gryphon [17] un implementazione del modello Publish-Subscribe realizzata
dalla IBM. Esso implementa sia un meccanismo di selezione delle notifiche
basato su topic sia un pi complesso content-based. Il sistema composto da
25
una serie di broker (architettura multi broker) suddivisi in cluster detti celle;
ciascuna cella copre una limitata area geografica ed, allinterno di questa, offre
un servizio scalabile e tollerante ai guasti; per ottenere una maggiore copertura
geografica, pi celle possono essere connesse tramite un numero arbitrario di
link, in modo da garantire che la rete rimanga sempre connessa; eventuali cicli
allinterno della rete vengono gestiti dai protocolli interni a Gryphon.
Oltre a queste caratteristiche Gryphon implementa anche diversi sistemi di
sicurezza che ne permettono luso anche su reti pubbliche.
2.6.7 SIENA
Siena [10, 18] un ENS distribuito con content-based routing.
La grande novit introdotta da Siena consiste in un meccanismo, chiamato di
covering delle sottoscrizioni che permette di ridurre la quantit di
sottoscrizioni che il sistema deve inoltrare sulla rete per poi poter effettuare un
corretto routing delle notifiche.
Oltre a questo Siena introduce anche il concetto di Advertising delle
pubblicazioni tramite cui i publisher possono annunciare in anticipo il tipo di
eventi che intendono pubblicare sulla rete.
Queste due caratteristiche permettono di tagliare parti della rete che
costituisce lENS (che deve avere obbligatoriamente una topologia aciclica) dalla
propagazione di certi eventi in quanto, le informazioni ottenute dalle
sottoscrizioni e dagli advertisement delle pubblicazioni, garantiscono che tali
rami non contengono subscriber interessati.
Il concetto di advertisement di una pubblicazione introdotto da questo sistema,

sar ripreso nel terzo capitolo, in quanto risulta un elemento fondamentale per
il sistema sviluppato in questo lavoro di tesi.
2.6.8 JEDI
JEDI [19] unimplementazione del modello Publish-Subscribe con content-
based routing sviluppata presso il Politecnico di Milano.
26
LENS fornito da JEDI distribuito: esso composto da un numero variabile di

nodi connessi in modo da formare una gerarchia alla cui sommit risiede un
nodo radice.
Il funzionamento prevede una diffusione parziale delle sottoscrizioni dai nodi

che le hanno ricevute fino alla radice. Queste informazioni vengono poi usate
per evitare di dover distribuire le notifiche su tutta la rete.
2.6.9 Hermes
Hermes offre unarchitettura molto simile a quella gi vista con SCRIBE; si tratta
quindi di un ENS distribuito sviluppato su uninfrastruttura offerta da una
overlay network [20, 21, 22] sottostante.
Ci che distingue Hermes da SCRIBE limplementazione di una tipologia di
routing misto basata sia sullutilizzo di un topic per gli eventi (chiamato in
questo caso tipo), sia sul contenuto degli eventi stessi. La parte di filtering
degli eventi basato sul loro contenuto, trae forte ispirazione dal lavoro svolto
con Siena.
2.6.10 REBECA
REBECA [23] un prototipo di sistema Publish-Subscribe realizzato nellambito
di un lavoro per una tesi di dottorato. Anche in questo caso il routing degli
eventi basato sul loro contenuto.
La caratteristica pi interessante di REBECA quella di permettere luso di
diversi tipi di routing delle sottoscrizioni per poter analizzare le loro
prestazioni; a seconda dellalgoritmo scelto vengono sfruttati vari gradi di
similarit tra le sottoscrizioni per ridurre il traffico dovuto alla loro diffusione
allinterno dellENS.
27
Capitolo 3
Trasformare un sistema topic-based in content-based
3.1 Introduzione al problema

Lobiettivo di questo lavoro di tesi realizzare, in modo efficiente, un
sistema Publish-Subscribe basato su contenuti, che offra quindi la possibilit di
esprimere, attraverso le sottoscrizioni, interessi verso particolari contenuti.
Diversamente da quanto accade nei sistemi basati su topic quindi, in cui si
possono esprimere solo interessi verso interi argomenti, indipendentemente
dai contenuti di un singolo evento, e dove il modello dei dati rappresentato da
un insieme discreto di argomenti, i topic, in un sistema basato su contenuti,
possiamo immaginare linsieme totale degli eventi come uno spazio continuo
multidimensionale, in cui ogni dimensione rappresenta un attributo, mentre
una sottoscrizione, definita attraverso un insieme di vincoli sui valori degli
attributi, e cio sui contenuti, individua un particolare sottospazio nel quale
ricadono gli eventi di interesse. La figura 3.1 mostra la differenza tra i due
Figura 3.1: a sinistra il modello content-based; a destra il modello topic-based
28
Capitolo 3: Trasformare un sistema topic-based in content-based
modelli: un modello content-based tridimensionale di esempio con alcune

sottoscrizioni, ed un insieme discreto di topic.
In letteratura troviamo molte implementazioni di sistemi Publish-Subscribe

content-based: da sistemi basati su algoritmi e tabelle di instradamento degli
eventi di livello applicativo, come SIENA [1], a sistemi basati su reti P2P
strutturate, usate per ottimizzare linstradamento degli eventi [2][3].
La soluzione innovativa che abbiamo deciso di sviluppare in questo lavoro di
tesi, per limplementazione di un sistema content-based scalabile ed efficiente,
basata sullidea di non realizzare questultimo da zero, bens di cercare di
sfruttare lefficienza che riescono ad ottenere i sistemi topic-based
nellinstradare gli eventi: data la semplicit del modello dei dati, in tali sistemi in
pratica si instaura un semplice canale, il topic, tra i pubblicatori ed i
sottoscrittori nel quale viaggiano gli eventi. Lidea, quindi, quella di realizzare
un sistema content-based costruito al di sopra di un generico sistema topic-based:
in altre parole, lobiettivo quello di realizzare un sistema content-based che
utilizzi come livello di instradamento dei messaggi un sistema topic-based, in
modo da sfruttare lefficienza di questultimo e, allo stesso tempo, fornire
uninterfaccia utente caratterizzata da una elevata potenza espressiva per la
definizione delle sottoscrizioni, tipica dei sistemi basati su contenuti. Tale
concetto schematizzato nella figura 3.2: il sistema offre uninterfaccia content-
based e, attraverso il Mapping Layer, cuore del sistema, riesce a capire, per ogni
evento appartenente allo spazio multidimensionale, su quale topic inoltrarlo;
dopodich sar compito del
sistema topic-based
sottostante inviare gli
eventi. LMPL, punto
fondamentale di questa tesi,
sar presentato in ogni
dettaglio nel paragrafo 3.2 .
Figura 3.2: Architettura a livelli del sistema
29
Da quanto appena detto, risulta evidente che lobiettivo principale di questa tesi
quello di sviluppare lo strato intermedio, lMPL, il cui scopo quello di
realizzare un mapping tra lo spazio continuo multidimensionale che
caratterizza i sistemi content-based, e il mondo discreto su cui si basano i
sistemi topic-based. La figura seguente (3.3) illustra quanto detto: il Mapping
Module, contenuto nel Mapping Layer, dovr riuscire a determinare, per ogni
evento, ovvero per ogni punto dello spazio multidimensionale, qual il topic
responsabile dellinstradamento del particolare evento, in modo da poter poi
inoltrare il messaggio nel sistema topic-based sottostante.
Figura 3.3: Mapping tra uno spazio continuo ed un insieme discreto di topic
Adottando tale modulo, essendo in grado di mappare un qualsiasi spazio

continuo multidimensionale in un generico insieme discreto e finito di elementi,
saremo in grado, nello specifico, di trasformare un qualsiasi sistema Publish-
Subscribe basato su topic in un sistema content-based o, in altre parole, saremo
in grado di costruire un sistema Publish-Subscribe content-based partendo da
un qualsiasi sistema topic-based.
Concludendo, quindi, il sistema complessivo sar caratterizzato, rispetto al
sistema topic-based sottostante, da una maggiore potenza espressiva per la
definizione delle sottoscrizioni, e dalla stessa efficienza per linstradamento
degli eventi.
30
Nel paragrafo successivo sar mostrato in dettaglio il livello di mapping,

descrivendo come viene realizzata lassociazione biunivoca tra spazio continuo
e topic e quali strutture ausiliare usa; viene inoltre introdotto il problema dei
falsi positivi e come esso viene sfruttato nel modo migliore da un modulo di
retroazione per migliorare le prestazioni.
3.2 Una corrispondenza dinamica tra spazi continui ed insiemi

discreti
Come abbiamo capito dal paragrafo precedente, per realizzare un

sistema content-based che sfrutti come livello di instradamento dei messaggi un
sistema topic-based necessario realizzare una corrispondenza biunivoca tra i
modelli dei dati dei due sistemi, e cio tra uno spazio continuo
multidimensionale ed un insieme discreto di topic. Tale corrispondenza, basata
sulla discretizzazione dello spazio continuo, pu essere principalmente di due
tipi: statica o dinamica. Il primo tipo prevede una discretizzazione dellintero
spazio degli eventi fatta a priori, indipendentemente dalla distribuzione delle
sottoscrizioni e degli eventi, come possiamo vedere in figura 3.4. Un esempio in
cui stata adottata tale soluzione presentato in [2]: in tale articolo gli autori
sfruttano una overlay strutturata per assegnare staticamente ad ogni nodo della
overlay un particolare sottospazio.
Figura 3.4: Discretizzazione statica dello spazio degli eventi.
31
Il secondo tipo, invece, prevede una discretizzazione che si adatta alla

distribuzione delle sottoscrizioni e degli eventi, in modo da ridurre al minimo il
problema dei falsi positivi (vedi paragrafo 3.2.3). Da questa prima e breve
analisi possiamo intravedere vantaggi e svantaggi delle due soluzioni: con una
discretizzazione statica, e quindi indipendente da una particolare distribuzione
di eventi e sottoscrizioni, abbiamo che il numero di falsi positivi rimane
costante; invece, nel caso di discretizzazione dinamica, abbiamo che il numero
di falsi positivi diminuisce nel tempo, al costo per di introdurre overhead per
la gestione della discretizzazione. Dato che un sistema a discretizzazione statica
gi presente in letteratura e, volendo ridurre al minimo i falsi positivi che un
utente riceve, in questo lavoro di tesi abbiamo scelto di realizzare un sistema a
discretizzazione dinamica. Nel corso di questo paragrafo vedremo il Mapping
Layer in tutti i suoi dettagli, responsabile della corrispondenza biunivoca
dinamica tra lo spazio degli eventi del sistema content-based e linsieme
discreto di topic del sistema topic-based. Nel capitolo 4, invece, sar
approfondita lanalisi accennata precedentemente, e basandoci su risultati di
simulazione, capiremo quando e quanto conveniente utilizzare un sistema a
discretizzazione dinamica piuttosto che un sistema a discretizzazione statica.
3.2.1 Discretizzare lo spazio continuo multidimensionale.

Dunque, la strada che abbiamo deciso di percorrere quella di realizzare un
sistema a discretizzazione dinamica, che crei quindi, quando necessario, le
dovute associazioni tra sottospazi e topic. Limmagine precedente (figura 3.4)
rimane valida in un sistema dinamico, solo che i vari sottospazi, e i relativi topic,
anzich essere prestabiliti, vengono creati dinamicamente dal Mapping Layer, in
base alle richieste dellutente, e soprattutto in base alla distribuzione degli
eventi. Vedremo a breve infatti, che in base alle frequenze di ricezione degli
eventi, il sistema reagir in modo opportuno cambiando lo stato della
discretizzazione, sia introducendo nuovi sottospazi di minor dimensione, sia
unendo pi sottospazi in uno equivalente.
32
Nel nostro modello, la discretizzazione dello spazio degli eventi rappresentata

da un albero, il Discretization Tree (DT) in cui valgono le seguenti propriet:
Il nodo radice rappresenta lintero spazio degli eventi.

Ogni nodo dellalbero rappresenta un particolare sottospazio.
I figli di un nodo p rappresentano un livello successivo di
discretizzazione del sottospazio rappresentato da p.
Gli unici sottospazi in cui si possono effettuare sottoscrizioni sono quelli
rappresentati dai nodi foglia dellalbero (se fosse possibile sottoscriversi
anche a nodi di livello superiore, una pubblicazione in un nodo foglia
dovrebbe essere ripetuta per tutti i nodi sul percorso dal nodo foglia fino
alla radice).
Per spiegare meglio il DT e la sua associazione allo spazio degli eventi,

consideriamo un esempio in cui abbiamo uno spazio bidimensionale costituito
dagli attributi x e y: in figura 3.5 possiamo vedere un esempio di
discretizzazione effettuata sullo spazio S e il relativo Discretization Tree, dove,
ad ogni discretizzazione, il sottospazio diviso in due sottospazi utilizzando una
dimensione come pivot della discretizzazione (quella indicata tra parentesi nei
nodi del DT).
Figura 3.5: un esempio di discretizzazione di uno spazio bidimensionale S ed il relativo albero DT
33
Come si pu immaginare dalla figura precedente (3.5), ogni passo di

discretizzazione avviene su una sola dimensione, scelta in modo da ridurre il pi
possibile il numero di falsi positivi che ricadono nel sottospazio che si sta
discretizzando (vedi paragrafo 3.2.4 per ulteriori dettagli). Inoltre, un altro
fattore importante che regola la discretizzazione di un sottospazio la
cardinalit{ di questultima, ovvero il numero di sottospazi figli da generare: pi
alto questo numero, pi alta la probabilit di eliminare i falsi positivi con
ununica discretizzazione, introducendo per maggiore complessit{ nel sistema.
Come possiamo immaginare, il DT avr una struttura che cambia nel tempo,
regolata dal Mapping Module: in base alla distribuzione degli eventi e delle
sottoscrizioni, il modulo decide se discretizzare o meno un sottospazio, e se
eliminare o meno una discretizzazione presente, cio un sottoalbero di altezza
unitaria, perch non pi necessaria (anche in questo caso si rimanda al
paragrafo 3.2.4 per ulteriori dettagli).
Infine, lo stato iniziale pu cambiare da contesto a contesto: cos come
possiamo avere un semplice stato iniziale costituito solo dal nodo radice, il che
significa non avere discretizzazione, potremmo avere uno stato iniziale
costituito da pi livelli di discretizzazione. Ad esempio, possiamo considerare
come stato iniziale il nodo radice ed i suoi figli: ci significa che, appena avviato,
il sistema ha gi un primo livello di discretizzazione. In base ai principi di
funzionamento del MPL (vedi paragrafo 3.3 per approfondimenti), questa
configurazione pu portare, in alcuni scenari, a miglioramenti delle prestazioni.
A questo punto, per completare il mapping tra spazio continuo e topic,

sufficiente associare ad ogni nodo dellalbero un topic. Tuttavia, questo non
significa che il Discretization Tree rappresenta linsieme dei topic attualmente
esistenti nel sistema, bens esso rappresenta soltanto lo stato logico della
discretizzazione dello spazio degli eventi. In altre parole, linsieme dei nodi del
DT rappresenta linsieme dei possibili topic su cui possibile effettuare
operazioni di sottoscrizione, pubblicazione, ecc. Solo quando una sottoscrizione
ad un topic viene richiesta per la prima volta, questultimo viene effettivamente
34
creato ed associato ad un nodo dellalbero. Pi formalmente possiamo affermare

che il Mapping Layer realizza una prima corrispondenza biunivoca tra lo spazio
degli eventi e linsieme dei nodi dellalbero, ed una seconda corrispondenza
biunivoca tra un sottoinsieme dei nodi dellalbero e linsieme dei topic (figura
3): solo quando un sottospazio diventa di interesse per qualche sottoscrittore,
allora il nodo associato entra a far parte del dominio della seconda
corrispondenza, e quindi associato ad un topic.
3.2.2 Lalbero di Sistema (ST)

Una volta definita la corrispondenza tra spazio degli eventi e topic, si rende
necessaria la definizione di una serie di protocolli indispensabili per il corretto
funzionamento del sistema, uno fra tutti il protocollo per la gestione della
discretizzazione.
Essendo questo un sistema distribuito, tali protocolli si baseranno sullo scambio
di messaggi e, volendo rimanere completamente disaccoppiati dal livello di rete
sottostante, abbiamo deciso di utilizzare il sistema topic-based anche per le
comunicazioni di sistema. Tuttavia, per non sovraccaricare i topic utente, e
soprattutto, per rendere tali protocolli completamente trasparenti allutente,
abbiamo deciso di separare i canali applicativi, in cui viaggeranno gli eventi dei
pubblicatori, dai canali di sistema, in cui viaggeranno i messaggi dei protocolli.
Per quanto riguarda i protocolli, oltre ad aver definito un protocollo di
regolazione della discretizzazione, abbiamo definito una serie di protocolli che
regolano il comportamento dellinterfaccia Content-based offerta allutente per
quanto riguarda linterfacciamento con il Mapping Layer. Pertanto, mentre il
primo il cuore del modulo di mapping, e quindi sar trattato in questo
paragrafo (sezione 3.2.4), gli altri saranno approfonditi nel paragrafo seguente
(3.3). Concentriamoci adesso sul definire un canale alternativo per le
comunicazioni di sistema.
La soluzione adottata quella di utilizzare un canale di sistema indipendente
per ogni sottospazio: la scelta giustificata dalla considerazione che ci che
riguarda un sottospazio completamente indipendente da eventi esterni al
35
sottospazio stesso. In questo modo siamo in grado di ridurre al minimo il

numero di messaggi di servizio che circolano nel sistema, in quanto ogni nodo
ricever esclusivamente i messaggi di sistema associati ai sottospazi che
coprono le sue sottoscrizioni.
Questa soluzione si concretizza in un albero di sistema, il System Tree (ST),
identico al Discretization Tree, con la differenza che i topic mappati con lo
spazio degli eventi non serviranno per instradare messaggi applicativi, bens
messaggi di sistema. Una seconda e fondamentale differenza con il DT riguarda
linsieme di topic a cui il sistema si sottoscrive: mentre nel caso del DT le
sottoscrizioni riguardano solamente i nodi foglia dellalbero, nel caso del ST, il
sistema sottoscriver tutti i topic associati ai nodi del ramo del ST che parte da
un nodo foglia di interesse fino alla radice. Questo scelta, anche se pu sembrare
ridondante, necessaria sia per poter costruire gli alberi DT e ST, sia per
captare eventuali richieste di annullamento di qualche livello. In altre parole,
quando un utente entra nel sistema, lunica parte dellalbero che conosce lo
stato iniziale e, supponendo che questo sia composto solo dal nodo radice,
lutente comincer{ ad inviare richieste di aggiornamento di stato dellalbero
utilizzando il topic associato alla radice del ST; secondo, tutte le comunicazioni
relative alla eliminazione di un livello di discretizzazione dallalbero non
avvengono nei topic associati ai nodi foglia, bens nel topic associato al nodo
padre delle foglie che si ritiene non siano pi necessarie. Quindi, risulta
obbligatorio mantenere le sottoscrizioni a tutti quei topic associati ai nodi del
ST del ramo che va da una foglia di interesse fino alla radice. Ulteriori dettagli
sono descritti ed affrontati nei paragrafi successivi.
3.2.3 Il problema dei falsi positivi

Lultimo problema da affrontare prima di passare alla definizione del livello pi
esterno del sistema, linterfaccia content-based, riguarda il fenomeno dei falsi
positivi. Come ricordiamo, una sottoscrizione definisce un sottospazio nello
spazio degli eventi (figura 3.1). In generale, la discretizzazione dello spazio degli
eventi genera sottospazi che non coprono perfettamente le sottoscrizioni degli
36
utenti, pertanto, accade frequentemente che un utente si sottoscriva ad uno o

pi topic, i quali includono regioni alle quali non interessato. Di conseguenza,
egli ricever eventi esterni alle proprie sottoscrizioni: i falsi positivi.
Formalmente, possiamo cos definire linsieme dei falsi positivi relativi ad una
sottoscrizione:
Dato uno spazio degli eventi E ed una sottoscrizione S coperta dallinsieme di

sottospazi T, linsieme dei falsi positivi per una sottoscrizione S :
FPS =
Come possiamo vedere nellesempio di figura 3.6, in cui abbiamo tre sottospazi
associati a tre topic, la sottoscrizione SS1, essendo coperta da S1 e S2, si traduce
in una sottoscrizione ai topic A e B. Perci, tutti gli eventi che appartengono a S1
o S2, e non appartengono alla sottoscrizione SS1, sono dei potenziali falsi
positivi per SS1.
Figura 3.6: un esempio di sottoscrizione in una discretizzazione che genera elevati falsi positivi
37
Data la natura del sistema, basata sulla discretizzazione di uno spazio continuo,
tale problema non pu essere eliminato, ma, gestendolo in maniera opportuna,
lo si pu sfruttare per migliorare le prestazioni complessive: nel nostro sistema,
infatti, i falsi positivi sono il cardine della discretizzazione dinamica.
Nel sottoparagrafo successivo viene descritto il protocollo di discretizzazione, il
quale definisce il comportamento di un nodo del sistema, sia nello scenario in
cui esso ritiene necessario un livello successivo di discretizzazione, perch
riceve troppi falsi positivi, sia nello scenario duale, ovvero nel caso in cui il
sistema, o meglio un sottoinsieme di nodi del sistema, ritiene necessario
annullare un livello della discretizzazione.
3.2.4 I protocolli di discretizzazione dinamica

Come anticipato nel sottoparagrafo precedente, i protocolli di discretizzazione
regolano due scenari fondamentali di questo sistema: la creazione e
leliminazione di un livello di discretizzazione. Essi governano quindi la
dinamicit del sistema.
Quando creare un nuovo livello di discretizzazione?
La risposta a questa domanda risulta immediata: dato che vogliamo ridurre il
pi possibile il numero di falsi positivi che un utente riceve, e dato che la
probabilit di ricevere un falso positivo direttamente proporzionale al
rapporto tra le dimensioni di un sottospazio ed una sottoscrizione coperta da
esso, un nodo decide di discretizzare il sottospazio, e cio di ridurne le
dimensioni, quando riceve troppi falsi positivi, o in altre parole, quando il
sottospazio cos grande da generare un numero eccessivo di falsi positivi.
Quindi, la creazione di un nuovo livello di discretizzazione si basa sul rapporto
tra il numero di falsi positivi ed il numero totale di eventi ricevuti, cio sulla
percentuale di falsi positivi ricevuti: quando questa percentuale supera una
determinata soglia stabilita dallutente, la quale rappresenta la percentuale
massima di falsi positivi tollerati, il nodo decide di aggiungere un nuovo livello
di discretizzazione agli alberi DT ed ST
38
Formalmente possiamo cos definire la condizione di discretizzazione:
Dato un sottospazio T che contiene un insieme non vuoto di sottoscrizioni, e definiti i

falsi positivi di un sottospazio come quegli eventi che risultano essere falsi positivi per
tutte le sottoscrizioni contenute in esso:
= ,
Quindi, data una soglia di discretizzazione, T deve essere discretizzato quando
#
>
# + #
In particolare, ogni nodo utilizza una serie di contatori per memorizzare il

numero di eventi ricevuti, sia falsi positivi che veri, in modo da poter
controllare, ogni volta che arriva un nuovo evento, se la condizione precedente
soddisfatta, e quindi richiedere la discretizzazione. Entrando ancora di pi nei
dettagli, ogni nodo memorizza per ogni sottospazio a cui sottoscritto, un
contatore per i veri positivi ed una serie di contatori per i falsi positivi, uno
globale al sottospazio e poi uno per ogni dimensione del modello dei dati,
questo perch, come anticipato nel paragrafo 3.2.1, la discretizzazione viene
effettuata su una sola dimensione, quella associata al contatore con il valore
maggiore.
Questo ci che deve implementare un attore del sistema di tipo subscriber, in
quanto tali contatori sono necessari per controllare il superamento della soglia
ed eventualmente scegliere la dimensione pivot per un nuovo livello.
Per quanto riguarda un attore di tipo publisher invece, esso deve memorizzare
gli eventi pubblicati in ogni nodo foglia, in quanto, come vedremo a breve, il
protocollo inverso a quello di creazione di un nuovo livello, ovvero quello di
controllo di necessit{ di un livello, si basa sullanalisi della distribuzione passata
degli eventi, distribuzione che viene appunto memorizzata dai publisher, per
poi essere inviata ai subscriber ogni E secondi (E rappresenta la durata di
unepoca, ovvero ogni quanti secondi viene avviato lalgoritmo di controllo di
39
necessit). Analizzeremo ora i due protocolli appena citati: il protocollo di

creazione di un nuovo livello, costituito da due algoritmi, controllo soglia e
creazione vera e propria di un nuovo livello, ed il protocollo per il controllo di
necessit di un livello.
Il protocollo che regola la creazione di un nuovo livello negli alberi DT e ST
basato sui due algoritmi seguenti:
ALGORITMO 1 (controllo superamento soglia)

ogni volta che un nodo riceve un evento e coperto dal sottospazio T:
1.
a. Se e un vero positivo, il nodo incrementa il singolo contatore associato
al sottospazio T.
b. Altrimenti, se e un falso positivo di T, il nodo incrementa il contatore
globale dei falsi positivi di T, e poi verifica, per ogni sottoscrizione
contenuta in T, quali vincoli della sottoscrizione non sono soddisfatti,
incrementando quindi solo i contatori associati alle dimensioni su cui non
sono soddisfatti i vincoli.
2. Dopo aver aggiornato i contatori, il nodo verifica se la condizione di
discretizzazione soddisfatta.
3. In caso positivo, il nodo avvia il processo di discretizzazione del sottospazio
in questione, inviando sul topic associato al nodo dellalbero ST associato al
sottospazio T un messaggio di richiesta di discretizzazione per il sottospazio
T, indicando come dimensione pivot quella associata al contatore con valore
maggiore.
Analizzando lalgoritmo appena descritto, ed in particolare focalizzandoci sul

punto 1.b, possiamo notare che, per quanto riguarda i contatori di dimensione,
un falso positivo viene contato tante volte quante sono le sottoscrizioni che non
sono soddisfatte. In prima analisi, questo potrebbe sembrare un errore, in
quanto un unico falso positivo potrebbe generare un incremento pi che
40
unitario dei contatori. In realt questo incremento multiplo serve a tener traccia
del fatto che, nonostante ci siano pi sottoscrizioni in un sottospazio, e quindi
una minore regione non coperta da sottoscrizioni, e quindi una minore
probabilit di ricevere un falso positivo, il sistema ha comunque notificato un
evento che falso per pi sottoscrizioni. Con questi incrementi multipli quindi,
riusciamo a determinare con maggiore precisione su quale dimensione
necessario effettuare una discretizzazione in modo da ridurre il pi possibile i
falsi positivi del sottospazio.
Lalgoritmo invece che viene attivato ogni volta che viene ricevuto un messaggio
di richiesta di discretizzazione generato dallalgoritmo precedente, e che crea un
nuovo livello negli alberi DT ed ST il seguente:
ALGORITMO 2 (ricezione messaggio di richiesta di discretizzazione)

ogni volta che un nodo riceve una richiesta di discretizzazione nel topic ST (topic di
sistema associato al sottospazio T):
1. Si procede a realizzare il nuovo livello di discretizzazione creando negli alberi
DT ed ST K nuovi figli (con K parametro di sistema) per i nodi del DT e del ST
associati al sottospazio T.
2. Per ogni nuovo nodo di interesse, ovvero associato ad un sottospazio che
copre almeno una sottoscrizione o un advertisement, si effettua la
sottoscrizione al topic di sistema (quello associato allST) e, se lattore che
esegue lalgoritmo un subscriber, si effettua la sottoscrizione anche al
topic dati (quello associato al DT)
3. Terminata lanalisi sui nuovi figli, se lattore che esegue lalgoritmo un
subscriber, si procede allannullamento della sottoscrizione al topic dati
associato al nodo padre del DT appena discretizzato.
4. Una volta terminato il processo di discretizzazione, il sottospazio T
discretizzato in K sottospazi (dove K un parametro di sistema), e se lattore
che sta eseguendo lalgoritmo un publisher, allora esso trasferisce la
41
distribuzione che aveva memorizzato per il nodo associato al sottospazio T ai

nuovi figli, ovvero alle nuove foglie.
Come possiamo vedere, la creazione di un nuovo livello risulta semplice da

gestire: fondamentalmente composta da due fasi distinte, laggiornamento dei
contatori, e la verifica della condizione di discretizzazione. Completamente
differente, invece, leliminazione di un livello, che necessita di unanalisi pi
complessa.
Quando un livello di discretizzazione non pi necessario?
Per rispondere a questa domanda possiamo percorrere a ritroso il processo che
ha portato alla creazione di un nuovo livello e quindi chiederci: se annullassimo
tale livello, qualche sottoscrittore chiederebbe nuovamente di discretizzare? Se
la risposta no, allora si pu procedere alleliminazione. La soluzione adottata si
basa quindi sullanalisi della distribuzione degli eventi allinterno del livello in
questione, e su come essa sia percepita dai sottoscrittori interessati. In
particolare, quando la distribuzione degli eventi tale per cui il livello di
discretizzazione non pi indispensabile per ogni singolo sottoscrittore
coinvolto, allora si pu procedere alleliminazione di questo livello di
discretizzazione. In altre parole, un livello viene eliminato quando la nuova
configurazione dellalbero che si andrebbe a creare tale per cui ogni
sottoscrittore non ricever un numero di falsi positivi tale da soddisfare la
condizione di discretizzazione.
Lalgoritmo di controllo, attivato ogni volta che scatta un timeout (parametro di
configurazione del sistema), si basa su uno scambio di messaggi nei topic di
sistema associati alle radici dei sottoalberi di altezza unitaria dellalbero di
sistema ST (ad esempio i nodi 1.2 e 2.2 in figura 5), il cui scopo quello di far
conoscere ai sottoscrittori la distribuzione degli eventi.
42
Il protocollo di controllo della discretizzazione il seguente:
PROTOCOLLO 1 (CONTROLLO DI NECESSITA DI UN LIVELLO DI DISCRETIZZAZIONE)

ogni E secondi (che rappresentano un epoca)
1. I pubblicatori inviano sui topic di sistema un messaggio contenente il
numero di eventi pubblicati nei nodi foglia e attendono un tempo pari a 5t,
dove t un tempo stimato che indica il tempo massimo necessario per
ricevere un messaggio. Scaduto questo tempo, i pubblicatori eseguono
lultimo passo dellalgoritmo.
2. Se un nodo riceve un messaggio inviato da un pubblicatore al passo 1
contenente una distribuzione di eventi relativa ad un sottoalbero che per lui
non ad altezza unitaria, risponde immediatamente con un NOK e termina
lalgoritmo.
3. Quando un pubblicatore riceve un messaggio inviato al passo 1 da un altro
pubblicatore e non ha ancora avviato lalgoritmo, lo avvia immediatamente.
Invece i sottoscrittori, alla ricezione del primo messaggio, attendono 2t
prima di procedere al passo successivo, tempo sufficiente per ricevere da
tutti gli altri pubblicatori coinvolti i messaggi contenenti le distribuzioni degli
eventi.
4. Dopo il tempo 2t, i sottoscrittori, avendo a disposizione la distribuzione degli
eventi corrente allinterno dei sottospazi di altezza 1 (quelli con un solo
livello di discretizzazione), controllano, per ogni sottospazio, se la soglia di
discretizzazione superata, considerando come veri positivi gli eventi
pubblicati nelle foglie a cui sono sottoscritti, e come falsi positivi gli eventi
nelle foglie rimanenti. Nel caso in cui la soglia non viene superata, il
sottoscrittore invia un OK.
5. Dopo aver deciso, un sottoscrittore attende per altri 2t (tempo sufficiente
per ricevere eventuali NOK del passo successivo).
43
6. Se un sottoscrittore che ha deciso per il no, perch la soglia superata,

riceve un OK, invia un NOK e termina lalgoritmo.
7. Se un nodo riceve un NOK, termina lalgoritmo.
8. Quando i pubblicatori ed i sottoscrittori superano rispettivamente i 5t del
passo 1 ed i 2t del passo 4 senza ricevere NOK, questo pu rappresentare
due scenari differenti:
a) Tutti i sottoscrittori che stanno eseguendo lalgoritmo hanno deciso
per il NO al passo 4 e quindi nessuno ha inviato un OK. In questo caso
il livello non viene eliminato.
b) Tutti i sottoscrittori hanno deciso per il SI al passo 4, quindi stato
inviato almeno un OK, il quale stato ricevuto anche da tutti i
pubblicatori coinvolti. In questo caso, tutti i nodi coinvolti procedono
alleliminazione del livello in questione.
Figura 3.7: un esempio di esecuzione dellalgoritmo di controllo della discretizzazione
Nellesempio di figura 3.7 abbiamo 5 nodi coinvolti: due pubblicatori, P1 e P2, e

tre sottoscrittori, S1, S2 e S3. Nello scenario mostrato abbiamo che P1 invia il
messaggio contenente gli eventi pubblicati, poi P2, non avendo ancora iniziato
lalgoritmo, quando riceve il messaggio da P1 inoltra anche la sua distribuzione.
44
Dopo un periodo di tempo che va da 2t a 3t, a seconda di quando i sottoscrittori

ricevono il primo messaggio, ogni sottoscrittore decide se per lui il livello pu
essere eliminato oppure no. A questo punto, il nodo S1 decide di si e quindi invia
un OK. Quando S2, che ha deciso di no, riceve un OK, invia immediatamente un
NOK e termina lesecuzione, cos come terminano gli altri quattro nodi.
Una precisazione importante da evidenziare, che riguarda linvio dei messaggi

OK e NOK nellalgoritmo precedente, e che influenza loverhead introdotto dal
sistema, la seguente: ogni nodo che deve inviare un OK o un NOK, programma
linvio del messaggio posticipato di un ritardo random (tra 0 e 10), in modo tale
che, se nellintervallo di tempo tra il momento della programmazione dellinvio
e linvio stesso, lesecutore dellalgoritmo riceve un messaggio semanticamente
uguale (un OK o un NOK per lo stesso nodo dellalbero), allora annulla il suo
invio, dato che qualcun altro ha gi provveduto, inviando nello stesso topic lo
stesso messaggio.
Come si pu capire da quanto detto fino ad ora, ogni nodo costituente il sistema
Publish-Subscribe distribuito ha la necessit di conoscere lo stato degli alberi
DT ed ST, almeno per quel che riguarda le porzioni di interesse, cio quelle
contenenti le foglie associate a sottospazi che coprono le proprie sottoscrizioni
o advertisement.
Data la completa distribuzione degli alberi DT ed ST che caratterizza il nostro
sistema, il paragrafo successivo presenta le soluzioni adottate per garantire la
consistenza tra le copie locali degli alberi che ogni nodo del sistema costruisce
in base alle proprie necessit.
3.2.5 Garantire la consistenza degli alberi nel sistema distribuito

Volendo realizzare un sistema totalmente distribuito, abbiamo deciso di non
creare un unico nodo del sistema responsabile della gestione degli alberi, bens
di demandare tale responsabilit ad ogni nodo del sistema. Appare evidente
quindi la necessit di creare un protocollo che garantisca che tutte le operazioni
45
di modifica degli alberi vengano eseguite allunisono da tutti gli attori del
sistema coinvolti.
Le soluzioni che abbiamo realizzato si basano fondamentalmente sui principi di

base del protocollo di commit a due fasi: prima di fare una modifica, lattore
chiede a tutti gli altri interessati se anche loro possono procedere con la stessa
modifica; nel caso affermativo, tutti procedono alla modifica (commit),
altrimenti nessuno la effettua (abort). Trasportando questo concetto nel nostro
sistema, ogni attore, quando vuole modificare il suo albero, lo notifica a tutti gli
attori coinvolti; dopodich o tutti effettuano questa modifica oppure nessuno.
La prima cosa da fare per realizzare tale protocollo capire quali sono le
operazioni che vanno a modificare gli alberi: da quanto detto finora, appare
evidente che le uniche operazioni sono quelle definite dai protocolli di
discretizzazione, ovvero il protocollo di creazione di un nuovo livello
(ALGORITMI 1 e 2) e quello di controllo di necessit di un livello (PROTOCOLLO
1).
Il passo successivo creare un meccanismo che abiliti ogni attore del sistema a
decidere se pu procedere o meno allesecuzione di una particolare operazione
sullalbero. Riprendendo quanto gi{ detto precedentemente nel paragrafo 3.2.2,
ovvero che ogni sottospazio indipendente da ogni altro, a meno che non ci sia
una relazione padre-figlio, abbiamo deciso di creare un meccanismo di locking
dellalbero con una granularit{ del singolo nodo, ovvero del singolo sottospazio.
Ogni volta che un algoritmo pu portare alla modifica di un sottospazio,
lalgoritmo deve bloccare il nodo associato prima di procedere acquisendo il
lock del nodo; se lalgoritmo riesce ad acquisire il lock, allora procede, altrimenti
termina.
Creato il meccanismo di locking dellalbero, vediamo come esso debba essere
utilizzato dalle operazioni di modifica precedentemente individuate per
garantire una continua consistenza tra gli alberi di ogni attore del sistema
Publish-Subscribe distribuito.
46
Per quanto riguarda la creazione di un nuovo livello, quando un attore riceve un

evento, e conseguentemente decide di discretizzare (passo 3 dellalgoritmo 1),
prima di inviare il messaggio di discretizzazione al resto del sistema, deve
acquisire il lock associato al nodo che vuole discretizzare. Se non riesce ad
acquisire il lock, e questo significa che il nodo bloccato da unaltra operazione
di modifica, lalgoritmo 1 termina, altrimenti prosegue normalmente. Quando
un attore invece riceve un messaggio di richiesta discretizzazione, prima di
procedere (passo 1 dellalgoritmo 2), prova ad acquisire il lock per il nodo
associato alla richiesta. Se non riesce ad acquisire il lock, allora lattore invia un
messaggio di abort sullo stesso topic dal quale ha ricevuto la richiesta. In questo
modo tutti i nodi coinvolti in questa richiesta annullano il processo di
discretizzazione, terminando lesecuzione dellalgoritmo 2. Se invece lattore
riesce ad acquisire il lock, prima di proseguire eseguendo il passo 1
dellalgoritmo 2, attende un tempo pari a 2t, tempo necessario per ricevere
eventuali abort da altri attori coinvolti.
Apportando queste modifiche agli algoritmi 1 e 2, siamo sicuri che
unoperazione di discretizzazione o viene eseguita da tutti i nodi interessati
oppure, se qualche nodo non in grado di eseguire loperazione perch sta
eseguendo altre operazioni sullo stesso nodo, non viene eseguita da nessuno.
Per quanto riguarda invece il protocollo di controllo di necessit di un livello, sia
i publisher, prima di eseguire il passo 1 dellalgoritmo 3, sia i subscriber, quando
ricevono il primo messaggio contenente la distribuzione degli eventi (passo 3
dellalgoritmo 3), provano ad acquisire il lock su tutti i nodi del livello da
controllare, sia tutte le foglie che il padre di queste ultime. Se un attore non
riesce ad acquisire i lock su tutto il livello, invia un NOK per tale livello, facendo
quindi abortire il controllo anche a tutti gli altri attori coinvolti. Se invece un
attore riesce ad acquisire i lock su tutto il livello, allora il protocollo di controllo
prosegue normalmente. In questo modo il controllo di un livello, o viene
eseguito da tutti gli attori coinvolti, oppure, se qualche attore non pu
controllare il livello perch sta eseguendo altre operazioni sulle foglie, come ad
47
esempio la creazione di un nuovo livello, il controllo non viene eseguito da

nessun attore.
Con lintroduzione di un meccanismo di locking dei nodi e la modifica degli
algoritmi precedentemente presentati, siamo quindi riusciti a realizzare un
sistema completamente distribuito che mantiene nel tempo la consistenza tra le
sue strutture dati, regolando i metodi di accesso ad esse. Con questo abbiamo
terminato la presentazione del livello di mapping. Nel paragrafo successivo sar
presentato il livello pi esterno dellarchitettura, responsabile della definizione
dellinterfaccia basata su contenuti. Vedremo inoltre come anche questo livello
dovr necessariamente interfacciarsi con il meccanismo appena presentato per
continuare a garantire la consistenza tra gli alberi.
3.3 Linterfaccia Content-Based
Lobiettivo del livello CBI quello di implementare uninterfaccia utente

che sia conforme allinterfaccia offerta dai sistemi Publish-Subscribe di tipo
content-based. Data la natura di tali sistemi, le loro interfacce sono molto
semplici: esse prevedono funzionalit per pubblicare eventi, effettuare e
annullare sottoscrizioni e, in alcuni sistemi, come il nostro, annunciare la
volont di pubblicazione, cio gli advertisement. Vedremo quindi, nel corso di
questo paragrafo, come tali funzionalit siano implementate dal nostro sistema
in modo da garantire la corretta interazione con il livello inferiore, lMPL.
Lintero livello si basa su una conoscenza parziale e distribuita dellalbero di
discretizzazione, e quindi dei topic su cui pubblicare o a cui sottoscriversi:
vedremo infatti, che grazie alle sottoscrizioni e agli advertisements, sia i
pubblicatori che i sottoscrittori riescono a ricostruire la porzione del DT di
interesse, quella porzione che rappresenta il sottospazio degli eventi a cui sono
interessati, sia perch vogliono ricevere eventi da quel sottospazio, sia perch
pubblicheranno eventi in quel sottospazio.
48
3.3.1 La pubblicazione di un evento

La pubblicazione di un evento nel sistema uno scenario molto semplice che
viene anche velocizzato utilizzando gli advertisements: grazie a questultimi, un
nodo pubblicatore conosce a priori quali sono i topic associati ai sottospazi che
coprono gli eventi che pubblicher. Quindi, ogni volta che un attore deve
pubblicare un evento, baster semplicemente cercare il nodo coprente nel DT e,
se il nodo non bloccato da qualche altra operazione (vedi paragrafo 3.2.5 e
3.3.2), pubblicare levento nel relativo topic.
3.3.2 Sottoscrizioni ed Advertisements

Questi due scenari sono di fondamentale importanza per il sistema poich
costituiscono la base per la distribuzione degli alberi DT ed ST. I due scenari,
molto simili, sono utilizzati, il primo dai sottoscrittori e il secondo dai
pubblicatori, per conoscere quali sono i topic che coprono i sottospazi di
interesse, per poi, nel caso dei sottoscrittori, effettuare la sottoscrizione a livello
Topic. Siccome i due scenari sono molto simili, definiremo solo il protocollo che
regola un nuovo advertisement; quello per una nuova sottoscrizione identico,
in pi alla fine prevede la sottoscrizione ad i topic di interesse mappati dal DT.
Dunque, il protocollo per una nuova sottoscrizione/advertisement il seguente:
PROTOCOLLO 2 (NUOVA SOTTOSCRIZIONE/ADVERTISEMENT)

1) Si prova ad acquisire il lock di tutti i nodi associati ai sottospazi che coprono
la sottoscrizione/advertisement.
a. Se vengono acquisiti tutti i lock, si procede con il passo 2.
b. Altrimenti loperazione viene rimandata finch non si sbloccano tutti
i nodi interessati.
2) Sottoscrizione a tutti i topic di sistema associati ai nodi di interesse
controllati e bloccati al passo precedente.
3) Invio di una richiesta sui topic sottoscritti al punto 2 per conoscere eventuali
livelli successivi di discretizzazione e sospensione per un tempo pari a 2t,
tempo massimo per ricevere eventuali risposte.
49
4) Per ogni nodo coinvolto nei punti precedenti:

a. Se almeno un nodo ha risposto, vuol dire che il sottospazio associato
discretizzato; quindi il nodo aggiorna la propria conoscenza degli
alberi DT e ST aggiungendo un nuovo livello di discretizzazione ed
usando come dimensione pivot quella indicata nella risposta; quindi
ritorna al punto 2 usando i topic associati ai nodi di interesse appena
costruiti.
b. Altrimenti, se non stata ricevuta alcuna risposta, vuol dire che il
sottospazio non ulteriormente discretizzato; quindi, per questo
nodo, solo se lattore un sottoscrittore, si procede alla
sottoscrizione al topic dati associato, in modo da poter iniziare a
riceve eventi.
c. Se invece viene ricevuto un messaggio di wait, il processo di richiesta
per il singolo nodo viene momentaneamente interrotto e ripreso
solo quando viene ricevuta una risposta indicante lo stato attuale del
nodo, sia se discretizzato sia se esso un nodo foglia.
d. Se invece viene ricevuto un messaggio di richiesta di discretizzazione,
il processo interpreta questo messaggio come una risposta indicante
che il nodo non discretizzato e ora si richiede la sua
discretizzazione; quindi viene terminato il processo di richiesta stato
per il singolo nodo e viene immediatamente attivato il protocollo di
richiesta discretizzazione per il nodo in questione, senza rilasciare il
lock. In questo modo anche lattore corrente, appena diventato
interessato al particolare sottospazio, entra a far parte del protocollo
di discretizzazione per questultimo.
Come possiamo vedere, questo algoritmo invia dei messaggi di richiesta stato
per un nodo e attende eventuali risposte o riceve eventuali messaggi di wait,
50
sempre relativi a singoli nodi. Vediamo come si comporta un nodo del sistema
quando riceve un messaggio di richiesta stato per un nodo:
ALGORITMO 4 (RICEZIONE DI UN MESSAGGIO RICHIESTA STATO PER UN NODO X)

ogni volta che un attore del sistema riceve un messaggio di richiesta stato per un
nodo X
1) Se il nodo bloccato da unaltra operazione, lattore invia un messaggio di
wait, indicando che non pu rispondere ora perch sta eseguendo altre
operazioni sul nodo che potrebbero modificare lo stato del nodo.
2) Se il nodo non bloccato e non un nodo foglia, lattore invia un
messaggio di risposta contenente un numero intero che indica la
dimensione pivot della discretizzazione per quel nodo.
3) Altrimenti, se il nodo non bloccato ma un nodo foglia, lattore non fa
nulla.
Al termine del protocollo, il sottoscrittore o il pubblicatore, conosce la parte di

albero che gli interessa e, nel caso di sottoscrittore, sar sottoscritto ai topic di
interesse; mentre nel caso di pubblicatore, conosce i nodi foglia del DT, ovvero i
topic sui quali dovr pubblicare.
Unosservazione importante che garantisce il corretto funzionamento del
protocollo appena descritto che, mentre ogni sottoscrittore sar sottoscritto
solo a quei topic applicativi associati ai sottospazi foglia del DT, ogni nodo, sia i
pubblicatori che i sottoscrittori, dovr essere sottoscritto a tutti quei topic di
sistema associati ai nodi dellalbero ST che vanno dalla radice fino alle foglie di
interesse. Altrimenti, se ogni nodo fosse sottoscritto solo ai topic di sistema
associati ai nodi foglia del ST, come nel caso del DT per i sottoscrittori, alla
prima esecuzione del punto 2 del protocollo, se fosse presente anche solo un
livello di discretizzazione, non risponderebbe nessuno.
51
3.3.3 Annullamento di sottoscrizioni ed advertisements

Questi due scenari risultano estremamente semplici. Essi si basano sullidea di
eliminare le sottoscrizioni ai topic associati ai nodi foglia dellalbero DT, per
quanto riguarda una unsubscribe, e tutte le sottoscrizioni ai topic associati
allalbero ST che non servono pi, partendo dalle foglie coprenti fino ad arrivare
a controllare anche la radice del ST, se necessario. In particolare vediamo ora i
due algoritmi nei loro dettagli. Per quanto riguarda una sottoscrizione,
lalgoritmo di unsubscribe il seguente:
1. Ricerca dei nodi del DT che coprono la sottoscrizione.

2. Per ogni nodo coprente, se esso non copre altre sottoscrizioni registrate
precedentemente, allora:
2.1. Si effettua la unsubscribe al topic associato allalbero DT.
2.2. Se il nodo non copre anche degli advertisements (se non fosse cos
significherebbe che chi esegue lalgoritmo sia un publisher che un
subscriber):
2.2.1. Si effettua la unsubscribe al topic associato allalbero ST.
2.2.2. Per ogni livello dellalbero, dal livello del nodo corrente, fino
al livello 0, se i topic associati ai fratelli del nodo corrente del ST non
sono sottoscritti:
2.2.2.1. Si effettua la unsubscribe al topic associato al padre
del nodo corrente dellalbero ST e si ritorna al passo 2.2.2
considerando come nodo corrente, il padre appena de-
sottoscritto.
Per quanto riguarda invece lannullamento di unadvertisement, lalgoritmo

molto simile: in pratica, dato che un publisher si sottoscrive solo ai topic
associati ai nodi del ST, lalgoritmo identico al precedente tranne che per la
52
prima parte, e cio i punti 2 e 2.1, che sono inutili. Dunque, lalgoritmo di
annullamento di un advertisement il seguente:
1. Ricerca dei nodi del ST che coprono gli advertisement.

2. Per ogni nodo coprente, se esso non copre altri advertisements registrati
precedentemente, allora:
2.1. Si effettua la unsubscribe al topic associato allalbero ST.
2.2. Per ogni livello dellalbero, dal livello del nodo corrente, fino al livello 0,
se i topic associati ai fratelli del nodo corrente del ST non sono
sottoscritti:
2.2.1. Si effettua la unsubscribe al topic associato al padre del nodo
corrente dellalbero ST e si ritorna al passo 2.2.2 considerando
come nodo corrente, il padre appena de-sottoscritto.
Con questo abbiamo concluso la presentazione del Mapping Layer, il quale

realizza una corrispondenze biunivoca dinamica tra un modello dei dati di un
sistema content-based ed un insieme discreto di topic di un sistema topic-based.
Nel capitolo successivo, sar presentato lambiente di simulazione utilizzato per
testare il sistema appena descritto, ed infine saranno presentati e discussi i
risultati ottenuti da una serie di simulazioni, il cui scopo capire quando e
quanto un sistema a discretizzazione dinamica convenga rispetto ad uno a
discretizzazione statica.
53
Capitolo 4
Test e risultati sperimentali
4.1 Lambiente di simulazione
Dopo aver implementato un prototipo del sistema descritto nel capitolo

precedente (per i dettagli implementativi si rimanda allappendice A), abbiamo
dovuto scegliere un ambiente di simulazione che mettesse a disposizione un
sistema Publish-Subscribe topic-based, in modo da poter testare le prestazioni
del sistema sviluppato. La scelta caduta su un simulatore del sistema TERA,
realizzato da un altro tesista del nostro laboratorio (vedi paragrafo 2.6.4 per i
dettagli sul sistema TERA).
Il simulatore del tipo cycle-based, ci significa che ogni passo di simulazione,
cio ogni round, rappresentato da un ciclo effettuato su tutti i nodi costituenti
lo scenario, durante il quale viene eseguito, nodo dopo nodo, il codice da
simulare. Quando viene schedulato dal simulatore, ogni nodo esegue
principalmente le tre attivit dellelenco seguente, in questo ordine:
1) Gestione dei messaggi ricevuti.
2) Esecuzione di eventuale codice di scenario (publish, subscribe,...).
3) Esecuzione di eventuali thread virtuali in attesa di essere schedulati.
Per quanto riguarda la terza attivit, bene chiarire che il flusso di esecuzione
sempre lo stesso, ed unico: quello associato allo scheduler del simulatore. Per
thread virtuale si intende invece un insieme di istruzioni che deve essere
eseguito solo al verificarsi di una precisa condizione, ad esempio in risposta a
determinati eventi, o dopo un certo numero di cicli. In altre parole, i thread
virtuali consentono di creare un meccanismo event-based allinterno di un
simulatore cycle-based.
54
Capitolo 4: Test e risultati sperimentali
A questo punto, scelto il simulatore, abbiamo integrato in esso il codice del

prototipo implementato, trasformando quindi il sistema topic-based simulato,
TERA, in un sistema content-based.
Per quanto riguarda lo scenario di simulazione, esso definito dalle seguenti
propriet:
Lo spazio degli eventi costituito da un solo attributo di tipo reale,
definito nellintervallo [-500,500].
Il sistema Publish-Subscribe costituito da 20 nodi, di cui 3 publisher e 7
subscriber.
Il timeout di ricezione di un messaggio impostato a 15 (numero
massimo di cicli necessari al simulatore per consegnare un messaggio).
Unepoca dura 400 cicli di simulazione (vedi paragrafo 3.2.4).
Quindi, dopo aver configurato lo scenario con le propriet suddette, per

generare le sottoscrizioni, gli advertisement e gli eventi da pubblicare, sono
state utilizzate le seguenti distribuzioni di probabilit:
Quattro distribuzioni gaussiane, con varianza 0.5 e valore atteso scelto in

modo uniforme sullintero spazio degli eventi, per scegliere i centri degli
intervalli di sottoscrizione ed advertisement.
Una distribuzione esponenziale negativa, con lambda=0.03, per
determinare lampiezza degli intervalli di sottoscrizione ed
advertisement.
Una distribuzione uniforme per ogni advertisement, in modo da scegliere
con probabilit uniforme sullintero intervallo creato gli eventi da
pubblicare.
55
4.2 I test effettuati
Di seguito saranno mostrati i risultati ottenuti da una serie di simulazioni

effettuate per misurare diverse grandezze del sistema. Un primo insieme di test
stato ideato e realizzato per analizzare i tempi di risposta del sistema, in modo
da capire dopo quanto tempo il sistema va a regime, e come reagisce ad
eventuali cambiamenti di sottoscrizioni e/o advertisement una volta raggiunto
il regime. Un secondo insieme di test stato ideato e realizzato per misurare
lefficienza del sistema, confrontandolo con un sistema a discretizzazione
statica. Infine, un terzo insieme di test stato eseguito per analizzare il costo
della discretizzazione dinamica, ovvero loverhead generato dalla gestione degli
alberi di discretizzazione.
4.2.1 Analisi dei tempi di risposta del sistema

In questo insieme di test si studiato landamento nel tempo del sistema,
monitorando la grandezza falsi positivi/notifiche totali, ovvero la percentuale
media di falsi positivi ricevuti da tutti i sottoscrittori. In particolare, si voleva
capire quanto tempo fosse necessario al sistema per andare a regime, dove per
regime intendiamo una fase in cui il valore monitorato rimane al di sotto di un
valore di soglia scelto dallutente (la soglia di discretizzazione, cfr. 3.2.4),
rappresentante la percentuale massima di falsi positivi tollerati.
Secondo le caratteristiche del sistema, ci si aspetta che allaumentare della

cardinalit della discretizzazione (da ora il parametro K), il transitorio duri
sempre meno, dato che un K maggiore produce sottospazi pi piccoli, e quindi
riduce la probabilit di ricevere falsi positivi. Per questo motivo, stato eseguito
un insieme di test per monitorare landamento nel tempo del sistema
(monitorando sempre la grandezza falsi positivi/notifiche totali) al variare di K,
in modo da verificare se realmente esiste una relazione inversa tra questo
parametro e la durata del transitorio. Nelleseguire questa serie di test, la soglia
di discretizzazione (da ora r) stata fissata ad un valore abbastanza basso, 0.1
56
(10% di falsi positivi tollerati), in modo da testare il sistema in uno scenario non
troppo favorevole. Sono ora riportati solo due dei grafici ottenuti, uno per K=2 e
uno per K=9, in modo da mostrare landamento del sistema nei due casi limite
(nel prototipo realizzato il valore K[2,9] ).
Analizzando i due grafici, vediamo che nel primo, ovvero con K=2, il sistema va a
regime intorno al round 1000 quindi, considerando che il sistema parte al round
57
150, possiamo affermare che il sistema andato a regime, in questo scenario,

dopo 850 round; nel secondo grafico invece, ovvero con K=9, il sistema andato
a regime intorno al round 600, ovvero dopo 450 round. Quindi, da questi primi
grafici, sembra effettivamente che esista una relazione inversa tra le due
grandezze. Dopo aver eseguito altri test con altri valori di K, si in effetti
ottenuto il risultato atteso, come si pu vedere dal grafico seguente.
Come si pu vedere dal grafico precedente, la relazione che lega le due

grandezze sembra essere unesponenziale negativo con un asintoto orizzontale
intorno al valore 400. Purtroppo non ci siamo potuti spingere oltre il valore 9
per analizzare meglio la relazione, date le limitazioni del prototipo
implementato.
Un ultimo test, sempre centrato sullanalisi del sistema nel tempo, stato
effettuato per capire cosa accade quando, una volta che il sistema a regime,
cambia linsieme di sottoscrizioni e/o advertisement. Per eseguire questo test,
al round 1300, sono state cambiate tutte le sottoscrizioni e gli advertisement,
annullando le precedenti ed effettuandone delle nuove.
58
Come si pu vedere, il sistema reagisce e durante il nuovo transitorio, pi breve

rispetto al precedente (perch una parte degli alberi gi configurata), gli alberi
vengono riconfigurati in modo da adattarsi ai nuovi intervalli di sottoscrizione
ed advertisement, fino a raggiungere nuovamente il regime.
Analizzando quindi i risultati ottenuti, si potrebbe immaginare di usare il valore

massimo consentito per il parametro K in modo da minimizzare i tempi del
transitorio. Vedremo con i prossimi test che un valore eccessivamente alto di K
riduce lefficienza del sistema a discretizzazione dinamica, fino a renderlo meno
performante di un sistema a discretizzazione statica.
4.2.2 Efficienza della discretizzazione dinamica

Dopo lanalisi del comportamento del sistema nel tempo, si passati ad un
insieme di test realizzati per confrontare la soluzione a discretizzazione
dinamica, sviluppata in questo lavoro di tesi, con soluzioni a discretizzazione
statica, gi presenti in letteratura. Per poter confrontare i due tipi di soluzione,
si dovuto prima di tutto capire quali grandezze li accomunano: a differenza del
nostro sistema, basato su discretizzazione dinamica dello spazio degli eventi, in
un sistema a discretizzazione statica si ha semplicemente che lo spazio degli
59
eventi interamente discretizzato, che tale discretizzazione non cambia nel

tempo, e che ogni sottospazio responsabilit di un nodo del sistema. Appare
evidente quindi, che un buon indicatore per un test comparativo tra i due
sistemi il numero medio di sottospazi sottoscritti da ogni sottoscrittore, dato
che esso corrisponde, nei sistemi statici, ad una misura delle risorse utilizzate.
Inoltre, tale grandezza fornisce anche una misura del carico che il nostro
sistema introduce nel sistema topic-based sottostante.
Una volta scelta la grandezza da monitorare, si deciso di utilizzare come
sistema statico il nostro stesso prototipo, settando come soglia di
discretizzazione il valore 1 (cio 100% di falsi positivi tollerati): in questo modo
non si richiede mai la discretizzazione di un sottospazio, e viene disattivato il
modulo che controlla la necessit di un livello di discretizzazione.
Per quanto riguarda il sistema dinamico, esso stato testato al variare della
percentuale di falsi positivi tollerati (r), utilizzando due cardinalit di
discretizzazione diverse (K=4 e K=6), monitorando sempre il numero medio di
sottospazi sottoscritti da ogni sottoscrittore
Invece, per il sistema statico, in cui non ha senso specificare la percentuale di
falsi positivi tollerati dato che la discretizzazione non cambia, esso stato
testato mettendolo nelle condizioni di operare agli stessi livelli di qualit del
sistema dinamico. In altre parole, per ogni valore v per il quale si effettuato il
test con il sistema dinamico (la percentuale di falsi tollerati), il sistema statico
stato testato creando manualmente una discretizzazione uniforme dellintero
spazio degli eventi (dato che a priori non si conoscono le distribuzioni delle
sottoscrizioni e degli eventi necessariamente uniforme), tale da consentire al
sistema di mantenere la percentuale di falsi positivi notificati al di sotto di v.
Riassumendo, in questo test si misurato quindi il numero medio di sottospazi
sottoscritti da ogni sottoscrittore al variare della percentuale di falsi positivi
tollerati, il che significa, per il sistema statico, effettuare la misurazione dopo
aver creato, per ogni valore del test, una discretizzazione uniforme dello spazio
60
degli eventi che garantisce tale valore. Il risultato dei test mostrato nel grafico
seguente:
Come si pu notare dal grafico, per valori bassi della percentuale (cio per
qualit richieste elevate), il sistema statico utilizza molti pi sottospazi del
sistema dinamico. Questo risultato si spiega considerando che per raggiungere
gli stessi livelli di qualit del sistema dinamico, quello statico ha bisogno di una
discretizzazione molto fitta e, a differenza del dinamico che crea granularit fine
solo quando e dove necessaria (vicino alle sottoscrizioni), il sistema statico
caratterizzato da una discretizzazione uniforme, cio con granularit uguale
sullintero spazio degli eventi. Questo implica, per il sistema statico, un elevato
numero di sottospazi ed unalta probabilit{ che una sottoscrizione sia coperta
da pi sottospazi.
Un secondo risultato interessante che si legge dal grafico precedente
linversione delle prestazioni che si ottiene per percentuali alte (qualit{
richieste basse): dato che il sistema dinamico legato al parametro K, esso
comunque crea un numero minimo di sottospazi, mentre il sistema statico
riesce a garantire gli stessi livelli di qualit utilizzando una discretizzazione
uniforme meno granulare.
61
Un ultimo interessante risultato da analizzare riguarda la relazione tra il valore

misurato in questo test, e la cardinalit{ della discretizzazione K. Allaumentare
di K, chiaramente aumenta il numero di sottospazi generati dal sistema
dinamico, e questo implica tempi di transitorio pi brevi, come visto con i test
precedenti, ma anche un incremento della probabilit che una sottoscrizione sia
coperta da pi sottospazi. Quindi, come possiamo vedere dallultimo grafico,
allaumentare di K, diminuisce lefficienza del sistema dinamico, in quanto
aumenta il numero medio di topic sottoscritti.
Infine, si pu concludere questa importante analisi affermando quindi che valori
bassi di K massimizzano lefficienza del sistema ma rendono il transitorio pi
lento, il che implica un numero maggiore di falsi positivi ricevuti; al contrario,
valori alti di K rendono veloce il transitorio, quindi un numero minore di falsi
positivi ricevuti, ma riducono lefficienza del sistema dinamico. Ne segue che,
scelta la percentuale di falsi positivi tollerati, questa analisi aiuta a determinare
il valore ottimale di K: se si vuole un valore basso della percentuale (cio qualit
elevata), come pi probabile che sia, il valore di K pu anche essere scelto
grande in modo da minimizzare i transitori, anche se questo implica utilizzare
un numero maggiore di topic (numero che comunque rimane inferiore rispetto
al sistema statico). Se invece ci si accontenta di percentuali maggiori (qualit
inferiore), allora per continuare ad avere senso il sistema dinamico, il valore di
K deve rimanere basso, in modo da non arrivare al punto di inversione di
prestazioni tra statico e dinamico.
62
4.2.3 Costo della discretizzazione dinamica

Unultima analisi stata effettuata per capire quanto costa gestire la dinamicit{
della discretizzazione. In tale test stata misurata la percentuale di messaggi di
controllo inviati, rispetto al totale dei messaggi inviati. Anche in questo caso il
test stato eseguito al variare della percentuale di falsi positivi tollerati.
Come era facile intuire, allaumentare della percentuale, siccome diminuisce la

necessit di discretizzare, il numero di messaggi di controllo, ovvero quei
messaggi inviati per gestire la discretizzazione, diminuisce. E interessante
notare come anche nei casi critici, ovvero a percentuali basse, loverhead non
supera il 5% del totale dei messaggi inviati.
63
Conclusioni
5.1 I risultati ottenuti

Abbiamo iniziato questo lavoro di tesi con unintroduzione ai sistemi
Publish-Subscribe (cfr. capitolo 2), in cui abbiamo evidenziato le differenze fra i
meccanismi topic-based e content-based (cfr. 2.5); quindi abbiamo creato, nel
capitolo 3, un meccanismo efficiente per limplementazione del modello
content-based partendo da un generico meccanismo topic-based,
trasformandolo in uno content-based. Nel quarto capitolo, infine, abbiamo
presentato i risultati di una serie di test effettuati utilizzando un prototipo da
me sviluppato (cfr. Appendice A) ed un simulatore del sistema TERA
opportunamente modificato.
Tali risultati dimostrano principalmente come un sistema a discretizzazione
dinamica, grazie ad una granularit della discretizzazione non uniforme, ma che
segue le distribuzioni delle sottoscrizioni e degli eventi, riesca ad essere quasi
sempre pi efficiente di un sistema a discretizzazione statica, riducendo il
numero di sottospazi necessari a garantire un determinato livello di qualit.
Inoltre, i test mostrano come loverhead introdotto per la gestione della
discretizzazione dinamica sia relativamente contenuto, rimanendo sempre al di
sotto del 5%.
Possiamo concludere, quindi, affermando che il sistema Publish-Subscribe da
noi sviluppato riesce ad essere pi performante di sistemi statici, ad un costo
decisamente accettabile.
64
Conclusioni
5.2 Sviluppi futuri

Il prossimo passo da eseguire per continuare lo sviluppo ed il test di
questo sistema, consiste nel cercare di eliminare i limiti introdotti dal prototipo
utilizzato, purtroppo sviluppato rapidamente per motivi di tempo legati alla
tesi. Una caratteristica che limita molto il sistema, infatti, legata ad una
propriet del simulatore utilizzato: i nominativi dei topic sono dei numeri interi
piuttosto che stringhe di caratteri. Questa caratteristica influenza due elementi
fondamentali del nostro sistema, il quale deve necessariamente creare una
corrispondenza biunivoca tra i nomi dei sottospazi, di tipo stringa, ed i nomi dei
topic, di tipo intero: nel prototipo sviluppato la cardinalit della discretizzazione
non pu essere superiore a 9, e laltezza degli alberi di discretizzazione non pu
essere maggiore di 9, altrimenti lintero associato ai sottospazi foglia rischia di
superare i valori massimi consentiti per il tipo intero.
Superato questo limite, sarebbe interessante testare il sistema con valori alti di
K. In un tale scenario, ci aspettiamo comunque, che aumentando K, la durata del
transitorio si assesti su un valore minimo, che lefficienza continui a diminuire, e
che i costi diminuiscano, anchessi assestandosi su un valore minimo.
Inoltre, un altro test interessante da eseguire, sarebbe quello di analizzare la
relazione tra il valore di K ed il valore di percentuale di falsi positivi tollerati
dopo il quale si ha linversione di prestazioni tra sistema statico e dinamico.
Come si intravede dallanalisi gi{ effettuata (cfr. 4.2.2), ci aspettiamo una
relazione inversa tra le due grandezze, ovvero allaumentare della cardinalit{ di
discretizzazione, linversione di prestazioni dovrebbe avvenire dopo valori
sempre pi piccoli della percentuale di falsi positivi tollerati, fino ad assestarsi
nellintorno di un asintoto orizzontale.
Infine, uno sviluppo interessante sarebbe quello di modificare il prototipo
sviluppato, in modo da disaccoppiarlo dal simulatore, per poi testarlo su un
sistema topic-based reale, non simulato.
65
Appendice A
Implementazione del sistema
In questa appendice sono mostrati i diagrammi dello schema XSD (XML

Schema Definition) che definisce i parametri di input del sistema, ed i
diagrammi delle classi del prototipo sviluppato per testare il meccanismo
sviluppato in questo lavoro di tesi. In particolare, per ogni package sviluppato,
contenuta una breve descrizione delle funzionalit del package ed il diagramma
delle classi contenute in esso.
XML Schema Definition per i parametri di input del sistema

Questo file XSD definisce le regole da rispettare per inserire i parametri di input
del sistema.
Gli elementi contenuti in DESMAType sono i parametri di input del sistema.

Seguendo poi il diagramma, si capisce ogni singolo parametro di che tipo .
66
Appendice A: Implementazione del sistema
Package dataModel
Questo package contiene tutte le classi che definiscono il modello dei dati di un
sistema Publish-Subscribe. Si pu infatti vedere la classe EventSpace, che
rappresenta lo spazio degli eventi multidimensionale, e le classi che
rappresentano attributi e sottoscrizioni (AttributeDef, Attribute, Subspace e
Constraint).
67
Package events
Questo package contiene tutta la gerarchia di classi che definisce gli eventi che
possono essere pubblicati. Possiamo vedere come da uninterfaccia generale che
rappresenta un evento, viene creato un tipo AppEvent che rappresenta gli
eventi pubblicati dai publisher, e una gerarchia di SysEvent, che rappresenta i
messaggi di controllo pubblicati dal sistema.
68
Package exceptions
Questo package contiene tutta la gerarchia di classi che definisce le eccezioni
che possono essere lanciate dal sistema. In particolare, queste eccezioni servono
a garantire che gli eventi che si vogliono pubblicare, e i sottospazi a cui ci si
vuole sottoscrivere o fare advertisements, siano effettivamente contenuti nello
spazio degli eventi del sistema.
69
Package mapping
Questo package rappresenta il cuore del sistema. In esso troviamo infatti
implementato il livello CBI, ovvero linterfaccia content-based, ed il livello MPL,
ovvero il livello che realizza il mapping dinamico tra spazi continui
multidimensionali e insiemi discreti.
70
Package threads
Questo package contiene tutte quelle classi necessarie per implementare un
meccanismo di esecuzione di codice basato su eventi. In altre parole, ogni classe
di questo package rappresenta un insieme di istruzioni da eseguire solo in
risposta ad un determinato evento, come la ricezione di un messaggio, o lo
scadere di un timeout. Come si pu vedere, le classi sono strutturate in una
gerarchia in cui la classe padre, SimulatedThread, rappresenta la classe di
interfacciamento con il simulatore; in questa classe infatti troviamo metodi
come start(), run() e sleep(), i quali ovviamente rappresentano implementazioni
simulate dei relativi metodi della classe Thread reale, la quale ribadisco, non
viene mai usata, in quanto bisognava avere, per le simulazioni, un unico flusso
di esecuzione.
71
Package topicInterfacing
Questo package contiene la gerarchia di classi necessaria per realizzare, nel
modo pi disaccoppiato possibile, linterfacciamento con il sistema topic-based
sottostante. Possiamo notare infatti la classe TopicAPI, la quale rappresenta per
il nostro sistema, la classe di interfacciamento con il sistema topic: essa infatti
una classe astratta che non implementa i metodi chiave di un sistema Publish-
Subscribe, ovvero publish(), subscribe() e unsubscribe(), i quali poi devono
essere implementati da una classe che estende TopicAPI. Dato che i nostri test
sono stati effettuati utilizzando solo TERA come sistema topic-based, abbiamo
implementato solo una classe di interfacciamento, TeraInterfacing, la quale sa
come comunicare con il sistema topic-based.
72
Package utilities
Questo package contiene tutte le classi di utilit utilizzate dal sistema. Notiamo
infatti il parser XML (ConfigurationReader) che importa i parametri di sistema
scritti in un file XML, controllando che esso sia ben formato rispetto allo schema
definito nel relativo XSD visto allinizio dellappendice. Inoltre notiamo la classe
che inizializza tutte le altre (DESMAStarter), la classe che genera le distribuzioni
casuali, ed infine una gerarchia, che rappresenta linterfacciamento con
lapplicazione sovrastante a cui bisogna notificare gli eventi di interesse. Tale
gerarchia consente di disaccoppiare il nostro sistema con lapplicazione
sovrastante, cos come avviene tra il nostro sistema ed il topic-based
sottostante.
73
Package trees
Questo package contiene tutte le classi necessarie per implementare gli alberi di
discretizzazione e tutti i metodi per visitarli.
74
Bibliografia
[1] A. Carzaniga, David S. Rosenblum, e Alexander L. Wolf, SIENA: Design

and Evaluation of a Wide-Area Event Notification Service.
[2] R. Baldoni, C. Marchetti, e A. Virgillito, Content-Based Publish-Subscribe

over Structured Overlay Networks.
[3] S. Voulgaris, E. Rivire, A.M. Kermarrec, e M. van Steen, Sub2Sub: Self

Organizing Content-Based Publish-Subscribe for Dynamic Large Scale
Collaborative Networks.
[4] P.Th. Eugster, P. Felber, R. Guerraoui, and A.M. Kermarrec. The Many
Faces of Publish/Subscribe. Technical Report ID:2000104, EPFL, DSC, Jan
2001.
[5] Object Management Group. Common object services specification, March

1995.
[6] A. Rowston, A. Kermarrec, M. Castro, and P. Druschel. Scribe: The design

of a large-scale notification infrastructure. In 3rd International
Workshop on Networked Group Communication (NGC2001), 2001.
[7] B. Oki, M. Pfluegel, A. Siegel, and D. Skeen. The Information Bus - An

Architecture for Extensive Distributed Systems. In Proceedings of the
1993 ACM Symposium on Operating Systems Principles, December 1993.
[8] S. Q. Zhuang, B. Y. Zhao, A. D. Joseph, R. Katz, and J. Kubiatowicz. Bayeux:

An architecture for scalable and fault-tolerant wide-area data
dissemination. In 11th Int. Workshop on Network and Operating Systems
Support for Digital Audio and Video, 2001.
[9] G. Banavar, T. Chandra, B. Mukherjee, J. Nagarajarao, R.E. Strom, and D.C.

Sturman. An Efficient Multicast Protocol for Content-based Publish-
Subscribe Systems. In Proceedings of International Conference on
Distributed Computing Systems, 1999.
75
[10] Antonio Carzaniga, David S. Rosenblum, and Alexander L. Wolf. Design

and evaluation of a wide-area event notification service. ACM
Transactions on Computer Systems, 19(3):332383, August 2001.
[11] Peter R. Pietzuch and Jean M. Bacon. Hermes: A distributed event-based

middleware architecture. In Workshop on Distributed Event-Based
Systems (DEBS), 2002.
[12] Object Management Group. Notification service: Joint revised

submission, July 1999.
[13] Teknekron Software Systems. Rendezvous software bus programmers

guide, 1995.
[14] A. Rowston and P. Druschel. Pastry: Scalable, distributed object location

and routing for large-scale peer-to-peer systems. In IFIP/ACM
Middleware, 2001.
[15] B. Segall and D. Arnold. Elvin Has Left the Building: A Publish-Subscribe
Notification Service with Quenching. In Proc. of the 1997 Australian
UNIX and Open Systems Users Group Conference, 1997.
[16] B. Segall, D. Arnold, J. Boot, M. Henderson, and T. Phelps. Content-Based

Routing with Elvin4. In Proceedings of AUUG2K, Canberra, Australia,
June 2000.
[17] Gryphon Web Site. http://www.research.ibm.com/gryphon/ .
[18] SIENA Web Site. http://www.cs.colorado.edu/users/carzanig/siena/ .
[19] G. Cugola, E. Di Nitto, and A. Fuggetta. Exploiting an event-based

infrastructure to develop complex distributed systems. In Proceedings
of the 10th International Conference on Software Engineering (ICSE
98), April 1998.
[20] I. Stoica, R. Morris, D. Karger, M. F. Kaashoek, and H. Balakrishnan.

Chord: a scalable peer-to-peer lookup service for internet applications.
In ACM SIGCOMM, 2001.
[21] A. Rowston and P. Druschel. Pastry: Scalable, distributed object location

and routing for large-scale peer-to-peer systems. In IFIP/ACM
Middleware, 2001.
76
[22] S. Q. Zhuang, B. Y. Zhao, A. D. Joseph, R. Katz, e J. Kubiatowicz. Tapestry:

An infrastructure for fault-tolerant wide-area location and routing.
Technical Report UCB/CSD-01-1141, University of California at
Berkeley, Computer Science Division, April 2001.
[23] Gero Muhl. Large-Scale Content-Based Publish/Subscribe Systems. PhD

thesis, September 2002.
[24] R. Baldoni, R. Beraldi, V. Quema, L. Querzoni, e S. Tucci-Piergiovanni.

TERA: Topic-based Event Routing for peer-to-peer Architectures, in
DEBS07, June 2007.
77

TesiPapale PDF

Uploaded by

Document Information

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

TesiPapale PDF

Uploaded by

Copyright:

Available Formats

Facolt di Ingegneria

Corso di Laurea Magistrale in Ingegneria Informatica

Un Meccanismo efficiente per

Anno Accademico 2008/2009

Un Meccanismo efficiente per

Anno Accademico 2008/2009

Alla mia dolce met,

Per la seconda volta sono arrivato a questo momento, scrivere i ringraziamenti

Capitolo 1 - Introduzione ..................................................................................................3

Capitolo 3 - Trasformare un sistema topic-based in content-based........28

Appendice A - Implementazione del sistema.............................................................66

Le architetture dei grandi sistemi informativi sono, ancora oggi, nella

operatori di borsa possono trovarsi nelle condizioni di dover prendere molte

sono interessati. Il punto di forza di questo modello risiede nel totale

1.1 Contributo della tesi

Realizzare un sistema Publish-Subscribe content-based al di sopra

In particolare, lo sviluppo di queste due idee ha richiesto:

La realizzazione di un meccanismo dinamico di mapping in grado di

1.2 Organizzazione del testo

2.1 Descrizione del sistema

Figura 2.1: Architettura Publish-Subscribe

Un evento costituito da dati strutturati solitamente secondo uno schema

definisce un valore specifico per ogni coordinata, identificando quindi un punto

Figura 2.2: Esempio di spazio degli eventi bidimensionale

Ogni subscriber dichiara a quali eventi interessato tramite linvio allENS di

Questa entit un astrazione la cui implementazione varia in modo significativo

Figura 2.3: ENS con un'infrastruttura distribuita

In un sistema Publish-Subscribe distribuito lEvent Notification Service

esecuzione su differenti host (o nodi), cooperano in modo da realizzare le

Figura 2.4: Architettura generale di un ENS distribuito

Livello di rete. I protocolli di rete legano il sistema Publish-Subscribe alla rete

Livello Overlay. Le primitive di comunicazione fornite dal livello di rete sono

overlay determinata solamente da una relazione di conoscenza. Tutti i broker

Livello di Routing. In un sistema Publish-Subscribe distribuito gli eventi e le

Livello di Matching. Il matching il processo di controllo se un evento

livello sottostante di instradamento, a volte esso pu essere usato anche

2.2 Caratteristiche di disaccoppiamento

Lintermediazione fornita dallENS ha lo scopo di isolare completamente

Disaccoppiamento spaziale: Gli elementi che interagiscono non devono

Disaccoppiamento temporale: I subscriber interessati ad un dato evento non

esso da parte di un publisher. Allo stesso modo allistante in cui un subscriber

Disaccoppiamento nel flusso delle operazioni: Il normale svolgimento delle

2.3 Altri paradigmi di comunicazione

Parallelamente allo sviluppo dei sistemi Publish-Subscribe si assistito

Message passing: si tratta di un paradigma di comunicazione strettamente

RPC - invocazione remota: linvocazione remota di eventi, nelle sue numerose

Notifications: si tratta di una forma primitiva di Publish-Subscribe. Con questa

Shared spaces: il paradigma distributed shared memory fornisce agli host

Code di messaggi: le code di messaggi riprendono molti degli aspetti principali

2.4 Meccanismi di selezione delle notifiche

La scelta di un adeguato metodo di selezione degli eventi un argomento

2.4.1 Channel-based selection.

2.4.2 Topic-based selection.

2.4.3 Content-based selection.

2.4.4 Type-based selection.

2.4.5 Schemi misti.

2.5 Un approfondimento sui meccanismi topic-based e content-

Il paragrafo precedente ha fornito una visione generale di tutti i

Figura 1.5: Confronto tra i meccanismi topic-based e content-based

Questo lavoro di tesi, quindi, cerca di realizzare unimplementazione efficiente

Analizzeremo ora le principali implementazioni esistenti del paradigma

2.6.1 CORBA Event Service.

oggetti: produttori e consumatori di informazione. Linformazione viene fatta