Tesi di Laurea. Un Meccanismo efficiente per l implementazione del modello content-based Publish-Subscribe su sistemi topic-based
|
|
- Tiziano Molinari
- 8 anni fa
- Visualizzazioni
Transcript
1 Facoltà di Ingegneria Corso di Laurea Magistrale in Ingegneria Informatica Tesi di Laurea Un Meccanismo efficiente per l implementazione del modello content-based Publish-Subscribe su sistemi topic-based Relatore: Prof. Roberto Baldoni Correlatore: Dott. Leonardo Querzoni Laureando: Fabio Papale Anno Accademico 2008/2009
2 Facoltà di Ingegneria Corso di Laurea Magistrale in Ingegneria Informatica Tesi di Laurea Un Meccanismo efficiente per l implementazione del modello content-based Publish-Subscribe su sistemi topic-based Relatore: Laureando: Prof. Roberto Baldoni Fabio Papale Correlatore: matricola: Dott. Leonardo Querzoni Controrelatore: Prof. Giuseppe Santucci Anno Accademico 2008/2009
3 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 dall inizio alla fine.
4 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 l ultima! 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 dall Intelligenza 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 un idea 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
5 Un meccanismo efficiente per l implementazione del modello content-based Publish-Subscribe su sistemi topic-based Indice Capitolo 1 - Introduzione Contributo della tesi Organizzazione del testo...8 Capitolo 2 - I sistemi Publish-Subscribe Descrizione del sistema Caratteristiche di disaccoppiamento Altri paradigmi di comunicazione Meccanismi di selezione delle notifiche Channel-based selection Topic-based selection Content-based selection Type-based selection Schemi misti Un approfondimento sui meccanismi topic-based e content-based Implementazioni CORBA Event Service TIBCO Rendez-vous SCRIBE TERA Elvin Gryphon SIENA JEDI Hermes REBECA
6 Un meccanismo efficiente per l implementazione del modello content-based Publish-Subscribe su sistemi topic-based Capitolo 3 - Trasformare un sistema topic-based in content-based Introduzione al problema Una corrispondenza dinamica tra spazi continui e insiemi discreti Discretizzare lo spazio continuo multidimensionale L albero di sistema (ST) Il problema dei falsi positivi I protocolli di discretizzazione dinamica Garantire la consistenza degli alberi nel sistema distribuito L interfaccia content-based La pubblicazione di un evento Sottoscrizioni ed advertisements Annullamento di sottoscrizioni ed advertisements...52 Capitolo 4 - Test e risultati sperimentali L ambiente di simulazione I test effettuati Analisi dei tempi di risposta del sistema Efficienza della discretizzazione dinamica Costo della discretizzazione dinamica...63 Conclusioni...64 I risultati ottenuti...64 Sviluppi futuri...65 Appendice A - Implementazione del sistema...66 Bibliografia
7 Un meccanismo efficiente per l implementazione del modello content-based Publish-Subscribe su sistemi topic-based 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è l host che inizia la comunicazione, deve necessariamente conoscere l indirizzo 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
8 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 l informazione 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 è l informazione ad iniziare la comunicazione, e non la necessità di ottenere questa stessa informazione. In questo tipo di applicazioni l informazione 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 l entità che produce l informazione ad inviarla a chi ha espresso un interesse verso quell informazione (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 d ora in poi diremo notificate) tutte le persone che hanno espresso il proprio interesse nei confronti di quel titolo. In questo ambito, gli 4
9 Capitolo 1: Introduzione 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. Un applicazione di monitoring basata sul modello client/server interroga costantemente un server posto presso la borsa valori per aggiornare i valori dei titoli (polling). Perché un applicazione del genere risulti utile deve effettuare interrogazioni con un alta frequenza per garantire all operatore 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 l operatore è interessato non sia cambiato, rendendo quindi superflua l interrogazione. Inoltre un applicazione 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 all ideazione 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 dell informazione. 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
10 Capitolo 1: Introduzione 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. L introduzione di questo nuovo modello all interno di applicazioni esistenti al posto di quello client/server ha permesso di migliorare l uso 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 l argomento, 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 dell insieme di eventi di interesse, basata sui contenuti degli eventi pubblicati e non solo sull argomento; 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
11 Capitolo 1: Introduzione 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 l efficienza di questi ultimi durante l instradamento di eventi e sottoscrizioni, e contemporaneamente riuscendo a fornire agli utenti un interfaccia altamente espressiva, tipica dei sistemi contentbased. Realizzare un associazione 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. L implementazione 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 l efficienza del meccanismo dinamico ideato. L esecuzione di una serie di simulazioni e test sperimentali, e la relativa analisi dei risultati ottenuti. 7
12 Capitolo 1: Introduzione 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 topicbased ed i content-based), per concludere poi con un analisi dei sistemi che rappresentano lo stato dell arte 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
13 Un meccanismo efficiente per l implementazione del modello content-based Publish-Subscribe su sistemi topic-based 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]. Un entit{ logica, chiamata event notification service (d ora in avanti ENS), agisce come mezzo di interconnessione, garantendo il disaccoppiamento tra i publisher ed i subscriber (Fig. 2.1). Possiamo immaginare l ENS 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 l esempio 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 all interno 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
14 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 sull uso del paradigma Publish- Subscribe. Figura 2.2: Esempio di spazio degli eventi bidimensionale Ogni subscriber dichiara a quali eventi è interessato tramite l invio all ENS di sottoscrizioni. Ogni sottoscrizione contiene un insieme di regole che l ENS userà per filtrare gli eventi pubblicati e notificare quindi al subscriber solo quelli di suo effettivo interesse. All interno dell event-space una sottoscrizione è rappresentabile come un sottospazio definito dai singoli filtri che la compongono (Fig. 2.2). In questo modo l interesse di una sottoscrizione verso un evento può essere facilmente verificato controllando l intersezione nell event-space tra la sottoscrizione e l evento (questa operazione è detta matching dell evento con la sottoscrizione). L inserimento di nuove sottoscrizioni o l eliminazione di sottoscrizioni esistenti avviene tramite l uso delle primitive subscribe() ed unsubscribe() sull API (Application Programming Interface) esposta dell ENS (Fig. 2.1). I publisher inseriscono eventi nel sistema tramite la primitiva notify() sull API dell ENS; questi provvederà quindi a notificare l evento ai subscriber interessati tramite l uso della stessa primitiva sull API di ogni singolo subscriber. L ENS `e un entità che funge quindi da mediatore tra tutti i publisher e tutti i subscriber mascherando l infrastruttura che permette la comunicazione tra essi. 10
15 Capitolo2: I sistemi Publish-Subscribe Questa entità è un astrazione la cui implementazione varia in modo significativo da sistema a sistema. Nei primi esempi di sistemi Publish-Subscribe l ENS 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 un implementazione 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 l ENS è 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 l ENS è un fattore che rimane completamente trasparente, sia ai publisher che ai subscriber, i quali interagiscono con esso esclusivamente tramite l API che esso espone. Nel seguito di questa tesi supporremo di avere a che fare sempre con implementazioni distribuite dell ENS, il cui modello architetturale sar{ ora brevemente descritto. Figura 2.3: ENS con un'infrastruttura distribuita In un sistema Publish-Subscribe distribuito l Event 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
16 Capitolo2: I sistemi Publish-Subscribe 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). L architettura 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
17 Capitolo2: I sistemi Publish-Subscribe 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 dell overlay (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 all interno 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 l evento, 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 l instradamento, 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
18 Capitolo2: I sistemi Publish-Subscribe 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 l ENS. Due strategie opposte sono solitamente considerate. Con la prima strategia i broker che costituiscono l ENS 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 all interno 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 L intermediazione fornita dall ENS 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 sull ENS; 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 l evento è stato inserito nella rete, ne quanti sono i publisher facenti parte del sistema. Questa caratteristica semplifica l uso del sistema in quanto richiede che ogni entità interagente (publisher o subscriber che sia) conosca esclusivamente un punto di accesso all ENS (solitamente l indirizzo di rete di un broker). Disaccoppiamento temporale: I subscriber interessati ad un dato evento non devono necessariamente essere collegati alla rete nell istante di inserimento di 14
19 Capitolo2: I sistemi Publish-Subscribe esso da parte di un publisher. Allo stesso modo all istante in cui un subscriber riceve l evento il publisher potrebbe essere già scollegato. Il disaccoppiamento temporale tra produzione e consumo dell informazione è totale. Questo semplifica la realizzazione delle applicazioni in quanto lo sviluppatore non deve più preoccuparsi di gestire il sincronismo tra produzione e consumazione dell informazione. Disaccoppiamento nel flusso delle operazioni: Il normale svolgimento delle operazioni all interno di un client non è in alcun modo interrotto dalla necessità di inviare o ricevere un messaggio dall ENS. L interazione con l ENS avviene in modo asincrono all interno 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 all applicazione molte funzioni basilari, come l indirizzamento 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 l indirizzo fisico del consumatore. 15
20 Capitolo2: I sistemi Publish-Subscribe RPC - invocazione remota: l invocazione remota di eventi, nelle sue numerose forme, è ad oggi il metodo più diffuso per implementare il calcolo distribuito. Con l uso 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). D altra parte la natura uno-ad-uno della comunicazione con RPC rende poco naturale il suo uso in applicazioni che richiedono comunicazioni del tipo uno-amolti. Inoltre l intrinseca 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 quell informazione sarà originata. In questo caso si ha un completo disaccoppiamento nel flusso delle operazioni dato che l informazione verrà recapitata al subscriber solo nel momento in cui sarà disponibile, tramite l uso 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 quell informazione. 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`u semplice `e 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
21 Capitolo2: I sistemi Publish-Subscribe 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 dall istante 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 all arrivo delle notifiche stesse. D altra parte un meccanismo in grado di offrire un alta 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, all interno dell ENS, 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 un alta 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
22 Capitolo2: I sistemi Publish-Subscribe 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. D altra 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 all interno di un canale, dovrà adottare qualche strategia di filtraggio una volta ricevuta una notifica. E chiaro quindi che questo metodo non permette un alta selettivi`a sulle notifiche se non moltiplicando il numero di canali. A questo si aggiunge l accoppiamento 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 Topic-based selection. Il passo successivo nell evoluzione dei sistemi Publish-Subscribe è stata l introduzione 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
23 Capitolo2: I sistemi Publish-Subscribe Content-based selection. Mentre con i due metodi precedentemente analizzati il contenuto di un evento rimaneva opaco all event notification service, nel caso di content-based selection [9, 10, 11] la selezione delle notifiche da recapitare ai subscriber si basa sull applicazione dei filtri, da cui le sottoscrizioni sono composte, al contenuto degli eventi. L incremento 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à nell implementazione 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 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 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 l uso del paradigma Publish-Subscribe, un approccio misto ha il grande vantaggio di risultare più facilmente adattabile ai vari possibili scenari. 19
24 Capitolo2: I sistemi Publish-Subscribe 2.5 Un approfondimento sui meccanismi topic-based e contentbased 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, l obiettivo di questo lavoro di tesi è quello di trasformare un sistema Publish-Subscribe topic-based in un sistema contentbased, con l intento di superare i limiti imposti dal primo modello senza introdurre l eccessiva 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 all interno 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
25 Capitolo2: I sistemi Publish-Subscribe 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 un implementazione efficiente del meccanismo content-based, prendendo come punto di partenza il meccanismo topic-based, per cercare di sfruttare l efficienza 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 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, l OMG ha introdotto il concetto di Event Service. L Event Service [5] `e un servizio offerto da CORBA che permette di disaccoppiare la comunicazione tra oggetti. Esso definisce due ruoli per gli 21
26 Capitolo2: I sistemi Publish-Subscribe oggetti: produttori e consumatori di informazione. L informazione viene fatta transitare dai produttori ai consumatori attraverso richieste CORBA standard. CORBA Event Service supporta due tipi di approccio per l avvio 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 l iniziativa è lasciata ai produttori, nel secondo ai consumatori. Il tipo di comunicazione può poi essere generico o tipizzato. Nel primo caso l informazione, oggetto della comunicazione, è completamente nascosta al servizio: la comunicazione avviene quindi per mezzo di semplici operazioni di push/pull nelle quali l unico parametro è il pacchetto contenente l informazione da trasferire. Nel secondo caso l informazioni è strutturata e può essere definita come lo sviluppatore preferisce. L Event 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 l OMG ha rilasciato la specifica relativa a CORBA Notification Service [12], un evoluzione dell Event Service. All interno 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 quest ultimo 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
27 Capitolo2: I sistemi Publish-Subscribe TIBCO Rendez-Vous TIBCO Rendezvous [13] è un implementazione 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, all atto 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 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. All inserimento di un evento all interno della rete, questo viene per prima cosa inviato al nodo di rendez-vous responsabile per il suo topic, e da questo inoltrato, tramite l albero 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 dall infrastruttura peer-to-peer sottostante offerta da Pastry. Il particolare metodo con cui, dato un topic, viene scelto il relativo nodo di rendezvous (basato sull hashing del topic stesso), permette una buona distribuzione del carico tra tutti i nodi appartenenti alla rete. 23
28 Capitolo2: I sistemi Publish-Subscribe TERA TERA [24] è un implementazione 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 all interno dell ENS 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, l evento deve essere instradato nel sistema fino a trovare il cluster associato alle sottoscrizioni che coprono l evento; quindi, trovato il cluster, inizia la seconda fase, chiamata Inner-Cluster Diffusion, in cui l evento 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
29 Capitolo2: I sistemi Publish-Subscribe 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 l evento in tutti i client della cluster overlay che copre l evento. Figura 2.6: Architettura di TERA Elvin Elvin [15, 16] è un prototipo avanzato di sistema Publish-Subscribe contentbased. 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 l intero database delle sottoscrizioni per ogni singolo cambio di sottoscrizione, generando una notevole quantità di traffico 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
30 Capitolo2: I sistemi Publish-Subscribe una serie di broker (architettura multi broker) suddivisi in cluster detti celle ; ciascuna cella copre una limitata area geografica ed, all interno 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 all interno della rete vengono gestiti dai protocolli interni a Gryphon. Oltre a queste caratteristiche Gryphon implementa anche diversi sistemi di sicurezza che ne permettono l uso anche su reti pubbliche 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 l ENS (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 JEDI JEDI [19] è un implementazione del modello Publish-Subscribe con contentbased routing sviluppata presso il Politecnico di Milano. 26
31 Capitolo2: I sistemi Publish-Subscribe L ENS 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 Hermes Hermes offre un architettura molto simile a quella già vista con SCRIBE; si tratta quindi di un ENS distribuito sviluppato su un infrastruttura offerta da una overlay network [20, 21, 22] sottostante. Ciò che distingue Hermes da SCRIBE è l implementazione di una tipologia di routing misto basata sia sull utilizzo 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 REBECA REBECA [23] è un prototipo di sistema Publish-Subscribe realizzato nell ambito 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 l uso di diversi tipi di routing delle sottoscrizioni per poter analizzare le loro prestazioni; a seconda dell algoritmo scelto vengono sfruttati vari gradi di similarità tra le sottoscrizioni per ridurre il traffico dovuto alla loro diffusione all interno dell ENS. 27
32 Un meccanismo efficiente per l implementazione del modello content-based Publish-Subscribe su sistemi topic-based Capitolo 3 Trasformare un sistema topic-based in content-based 3.1 Introduzione al problema L obiettivo 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 l insieme 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
33 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 l instradamento degli eventi [2][3]. La soluzione innovativa che abbiamo deciso di sviluppare in questo lavoro di tesi, per l implementazione di un sistema content-based scalabile ed efficiente, è basata sull idea di non realizzare quest ultimo da zero, bensì di cercare di sfruttare l efficienza che riescono ad ottenere i sistemi topic-based nell instradare 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. L idea, quindi, è quella di realizzare un sistema content-based costruito al di sopra di un generico sistema topic-based: in altre parole, l obiettivo è quello di realizzare un sistema content-based che utilizzi come livello di instradamento dei messaggi un sistema topic-based, in modo da sfruttare l efficienza di quest ultimo e, allo stesso tempo, fornire un interfaccia 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 un interfaccia contentbased 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. L MPL, punto fondamentale di questa tesi, sarà presentato in ogni dettaglio nel paragrafo 3.2. Figura 3.2: Architettura a livelli del sistema 29
34 Capitolo 3: Trasformare un sistema topic-based in content-based Da quanto appena detto, risulta evidente che l obiettivo principale di questa tesi è quello di sviluppare lo strato intermedio, l MPL, 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 dell instradamento 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 l instradamento degli eventi. 30
35 Capitolo 3: Trasformare un sistema topic-based in content-based Nel paragrafo successivo sarà mostrato in dettaglio il livello di mapping, descrivendo come viene realizzata l associazione 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 dell intero 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
36 Capitolo 3: Trasformare un sistema topic-based in content-based 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 l insieme discreto di topic del sistema topic-based. Nel capitolo 4, invece, sarà approfondita l analisi 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 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. L immagine 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 dell utente, 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
37 Capitolo 3: Trasformare un sistema topic-based in content-based 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 l intero spazio degli eventi. Ogni nodo dell albero 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 dell albero (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
38 Capitolo 3: Trasformare un sistema topic-based in content-based 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 per ulteriori dettagli). Inoltre, un altro fattore importante che regola la discretizzazione di un sottospazio è la cardinalit{ di quest ultima, ovvero il numero di sottospazi figli da generare: più è alto questo numero, più è alta la probabilità di eliminare i falsi positivi con un unica 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 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 dell albero un topic. Tuttavia, questo non significa che il Discretization Tree rappresenta l insieme dei topic attualmente esistenti nel sistema, bensì esso rappresenta soltanto lo stato logico della discretizzazione dello spazio degli eventi. In altre parole, l insieme dei nodi del DT rappresenta l insieme 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, quest ultimo viene effettivamente 34
39 Capitolo 3: Trasformare un sistema topic-based in content-based creato ed associato ad un nodo dell albero. Più formalmente possiamo affermare che il Mapping Layer realizza una prima corrispondenza biunivoca tra lo spazio degli eventi e l insieme dei nodi dell albero, ed una seconda corrispondenza biunivoca tra un sottoinsieme dei nodi dell albero e l insieme 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 L albero 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 all utente, 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 dell interfaccia Content-based offerta all utente per quanto riguarda l interfacciamento 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
40 Capitolo 3: Trasformare un sistema topic-based in content-based 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 l insieme di topic a cui il sistema si sottoscrive: mentre nel caso del DT le sottoscrizioni riguardano solamente i nodi foglia dell albero, 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, l unica parte dell albero che conosce è lo stato iniziale e, supponendo che questo sia composto solo dal nodo radice, l utente comincer{ ad inviare richieste di aggiornamento di stato dell albero utilizzando il topic associato alla radice del ST; secondo, tutte le comunicazioni relative alla eliminazione di un livello di discretizzazione dall albero 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 Il problema dei falsi positivi L ultimo problema da affrontare prima di passare alla definizione del livello più esterno del sistema, l interfaccia 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
41 Capitolo 3: Trasformare un sistema topic-based in content-based 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 l insieme dei falsi positivi relativi ad una sottoscrizione: Dato uno spazio degli eventi E ed una sottoscrizione S coperta dall insieme di sottospazi T, l insieme dei falsi positivi per una sottoscrizione S è: FP S = x E x T x S Come possiamo vedere nell esempio 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
42 Capitolo 3: Trasformare un sistema topic-based in content-based 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 I protocolli di discretizzazione dinamica Come anticipato nel sottoparagrafo precedente, i protocolli di discretizzazione regolano due scenari fondamentali di questo sistema: la creazione e l eliminazione 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 dall utente, 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
43 Capitolo 3: Trasformare un sistema topic-based in content-based 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: false positive T = x T subscription s in T, x FPs Quindi, data una soglia di discretizzazione, T deve essere discretizzato quando # T false positives > Discretization threshold # T true positives + # T false positives 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 sull analisi 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 un epoca, ovvero ogni quanti secondi viene avviato l algoritmo di controllo di 39
44 Capitolo 3: Trasformare un sistema topic-based in content-based 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 dell albero 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 l algoritmo 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
45 Capitolo 3: Trasformare un sistema topic-based in content-based 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. L algoritmo invece che viene attivato ogni volta che viene ricevuto un messaggio di richiesta di discretizzazione generato dall algoritmo 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 all ST) e, se l attore che esegue l algoritmo è un subscriber, si effettua la sottoscrizione anche al topic dati (quello associato al DT) 3. Terminata l analisi sui nuovi figli, se l attore che esegue l algoritmo è un subscriber, si procede all annullamento 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 l attore che sta eseguendo l algoritmo è un publisher, allora esso trasferisce la 41
46 Capitolo 3: Trasformare un sistema topic-based in content-based 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, l aggiornamento dei contatori, e la verifica della condizione di discretizzazione. Completamente differente, invece, è l eliminazione di un livello, che necessita di un analisi 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 all eliminazione. La soluzione adottata si basa quindi sull analisi della distribuzione degli eventi all interno 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 all eliminazione di questo livello di discretizzazione. In altre parole, un livello viene eliminato quando la nuova configurazione dell albero che si andrebbe a creare è tale per cui ogni sottoscrittore non riceverà un numero di falsi positivi tale da soddisfare la condizione di discretizzazione. L algoritmo 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 dell albero 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
47 Capitolo 3: Trasformare un sistema topic-based in content-based 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 l ultimo passo dell algoritmo. 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 l algoritmo. 3. Quando un pubblicatore riceve un messaggio inviato al passo 1 da un altro pubblicatore e non ha ancora avviato l algoritmo, 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 all interno 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
48 Capitolo 3: Trasformare un sistema topic-based in content-based 6. Se un sottoscrittore che ha deciso per il no, perché la soglia è superata, riceve un OK, invia un NOK e termina l algoritmo. 7. Se un nodo riceve un NOK, termina l algoritmo. 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 l algoritmo 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 all eliminazione del livello in questione. Figura 3.7: un esempio di esecuzione dell algoritmo di controllo della discretizzazione Nell esempio 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 l algoritmo, quando riceve il messaggio da P1 inoltra anche la sua distribuzione. 44
49 Capitolo 3: Trasformare un sistema topic-based in content-based 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 l esecuzione, così come terminano gli altri quattro nodi. Una precisazione importante da evidenziare, che riguarda l invio dei messaggi OK e NOK nell algoritmo precedente, e che influenza l overhead introdotto dal sistema, è la seguente: ogni nodo che deve inviare un OK o un NOK, programma l invio del messaggio posticipato di un ritardo random (tra 0 e 10), in modo tale che, se nell intervallo di tempo tra il momento della programmazione dell invio e l invio stesso, l esecutore dell algoritmo riceve un messaggio semanticamente uguale (un OK o un NOK per lo stesso nodo dell albero), 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à 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
50 Capitolo 3: Trasformare un sistema topic-based in content-based di modifica degli alberi vengano eseguite all unisono 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, l attore 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 all esecuzione di una particolare operazione sull albero. 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 dell albero con una granularit{ del singolo nodo, ovvero del singolo sottospazio. Ogni volta che un algoritmo può portare alla modifica di un sottospazio, l algoritmo deve bloccare il nodo associato prima di procedere acquisendo il lock del nodo; se l algoritmo riesce ad acquisire il lock, allora procede, altrimenti termina. Creato il meccanismo di locking dell albero, 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
51 Capitolo 3: Trasformare un sistema topic-based in content-based Per quanto riguarda la creazione di un nuovo livello, quando un attore riceve un evento, e conseguentemente decide di discretizzare (passo 3 dell algoritmo 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 un altra operazione di modifica, l algoritmo 1 termina, altrimenti prosegue normalmente. Quando un attore invece riceve un messaggio di richiesta discretizzazione, prima di procedere (passo 1 dell algoritmo 2), prova ad acquisire il lock per il nodo associato alla richiesta. Se non riesce ad acquisire il lock, allora l attore 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 l esecuzione dell algoritmo 2. Se invece l attore riesce ad acquisire il lock, prima di proseguire eseguendo il passo 1 dell algoritmo 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 un operazione di discretizzazione o viene eseguita da tutti i nodi interessati oppure, se qualche nodo non è in grado di eseguire l operazione 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 dell algoritmo 3, sia i subscriber, quando ricevono il primo messaggio contenente la distribuzione degli eventi (passo 3 dell algoritmo 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
52 Capitolo 3: Trasformare un sistema topic-based in content-based esempio la creazione di un nuovo livello, il controllo non viene eseguito da nessun attore. Con l introduzione 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 dell architettura, responsabile della definizione dell interfaccia 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 L interfaccia Content-Based L obiettivo del livello CBI è quello di implementare un interfaccia utente che sia conforme all interfaccia 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, l MPL. L intero livello si basa su una conoscenza parziale e distribuita dell albero 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
53 Capitolo 3: Trasformare un sistema topic-based in content-based 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 quest ultimi, 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 e 3.3.2), pubblicare l evento nel relativo topic 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 l operazione 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
54 Capitolo 3: Trasformare un sistema topic-based in content-based 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 l attore è 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 l attore corrente, appena diventato interessato al particolare sottospazio, entra a far parte del protocollo di discretizzazione per quest ultimo. 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
55 Capitolo 3: Trasformare un sistema topic-based in content-based 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 un altra operazione, l attore 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, l attore 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, l attore 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. Un osservazione 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 dell albero 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
56 Capitolo 3: Trasformare un sistema topic-based in content-based Annullamento di sottoscrizioni ed advertisements Questi due scenari risultano estremamente semplici. Essi si basano sull idea di eliminare le sottoscrizioni ai topic associati ai nodi foglia dell albero DT, per quanto riguarda una unsubscribe, e tutte le sottoscrizioni ai topic associati all albero 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, l algoritmo 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 all albero DT Se il nodo non copre anche degli advertisements (se non fosse così significherebbe che chi esegue l algoritmo è sia un publisher che un subscriber): Si effettua la unsubscribe al topic associato all albero ST Per ogni livello dell albero, dal livello del nodo corrente, fino al livello 0, se i topic associati ai fratelli del nodo corrente del ST non sono sottoscritti: Si effettua la unsubscribe al topic associato al padre del nodo corrente dell albero ST e si ritorna al passo considerando come nodo corrente, il padre appena desottoscritto. Per quanto riguarda invece l annullamento di un advertisement, l algoritmo è molto simile: in pratica, dato che un publisher si sottoscrive solo ai topic associati ai nodi del ST, l algoritmo è identico al precedente tranne che per la 52
57 Capitolo 3: Trasformare un sistema topic-based in content-based prima parte, e cioè i punti 2 e 2.1, che sono inutili. Dunque, l algoritmo 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 all albero ST Per ogni livello dell albero, dal livello del nodo corrente, fino al livello 0, se i topic associati ai fratelli del nodo corrente del ST non sono sottoscritti: Si effettua la unsubscribe al topic associato al padre del nodo corrente dell albero ST e si ritorna al passo 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 l ambiente 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
58 Un meccanismo efficiente per l implementazione del modello content-based Publish-Subscribe su sistemi topic-based Capitolo 4 Test e risultati sperimentali 4.1 L ambiente di simulazione Dopo aver implementato un prototipo del sistema descritto nel capitolo precedente (per i dettagli implementativi si rimanda all appendice 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 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à dell elenco 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 all interno di un simulatore cycle-based. 54
59 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 nell intervallo [-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). Un epoca 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 sull intero spazio degli eventi, per scegliere i centri degli intervalli di sottoscrizione ed advertisement. Una distribuzione esponenziale negativa, con lambda=0.03, per determinare l ampiezza degli intervalli di sottoscrizione ed advertisement. Una distribuzione uniforme per ogni advertisement, in modo da scegliere con probabilità uniforme sull intero intervallo creato gli eventi da pubblicare. 55
60 Capitolo 4: Test e risultati sperimentali 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 l efficienza 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 l overhead generato dalla gestione degli alberi di discretizzazione Analisi dei tempi di risposta del sistema In questo insieme di test si è studiato l andamento 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 dall utente (la soglia di discretizzazione, cfr ), rappresentante la percentuale massima di falsi positivi tollerati. Secondo le caratteristiche del sistema, ci si aspetta che all aumentare 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 l andamento 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. Nell eseguire questa serie di test, la soglia di discretizzazione (da ora r) è stata fissata ad un valore abbastanza basso,
61 Capitolo 4: Test e risultati sperimentali (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 l andamento 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
62 Capitolo 4: Test e risultati sperimentali 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 un esponenziale 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 sull analisi del sistema nel tempo, è stato effettuato per capire cosa accade quando, una volta che il sistema è a regime, cambia l insieme 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
63 Capitolo 4: Test e risultati sperimentali 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 l efficienza del sistema a discretizzazione dinamica, fino a renderlo meno performante di un sistema a discretizzazione statica Efficienza della discretizzazione dinamica Dopo l analisi 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
64 Capitolo 4: Test e risultati sperimentali 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 dell intero 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
65 Capitolo 4: Test e risultati sperimentali 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 sull intero spazio degli eventi. Questo implica, per il sistema statico, un elevato numero di sottospazi ed un alta probabilit{ che una sottoscrizione sia coperta da più sottospazi. Un secondo risultato interessante che si legge dal grafico precedente è l inversione 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
66 Capitolo 4: Test e risultati sperimentali Un ultimo interessante risultato da analizzare riguarda la relazione tra il valore misurato in questo test, e la cardinalit{ della discretizzazione K. All aumentare 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 dall ultimo grafico, all aumentare di K, diminuisce l efficienza 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 l efficienza 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 l efficienza 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
67 Capitolo 4: Test e risultati sperimentali Costo della discretizzazione dinamica Un ultima 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, all aumentare 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, l overhead non supera il 5% del totale dei messaggi inviati. 63
68 Un meccanismo efficiente per l implementazione del modello content-based Publish-Subscribe su sistemi topic-based Conclusioni 5.1 I risultati ottenuti Abbiamo iniziato questo lavoro di tesi con un introduzione 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 l implementazione 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 l overhead 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
69 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 l altezza degli alberi di discretizzazione non può essere maggiore di 9, altrimenti l intero 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 l efficienza continui a diminuire, e che i costi diminuiscano, anch essi 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 l inversione di prestazioni tra sistema statico e dinamico. Come si intravede dall analisi gi{ effettuata (cfr ), ci aspettiamo una relazione inversa tra le due grandezze, ovvero all aumentare della cardinalit{ di discretizzazione, l inversione di prestazioni dovrebbe avvenire dopo valori sempre più piccoli della percentuale di falsi positivi tollerati, fino ad assestarsi nell intorno 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
70 Un meccanismo efficiente per l implementazione del modello content-based Publish-Subscribe su sistemi topic-based 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
71 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
72 Appendice A: Implementazione del sistema Package events Questo package contiene tutta la gerarchia di classi che definisce gli eventi che possono essere pubblicati. Possiamo vedere come da un interfaccia 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
73 Appendice A: Implementazione del sistema 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
74 Appendice A: Implementazione del sistema Package mapping Questo package rappresenta il cuore del sistema. In esso troviamo infatti implementato il livello CBI, ovvero l interfaccia content-based, ed il livello MPL, ovvero il livello che realizza il mapping dinamico tra spazi continui multidimensionali e insiemi discreti. 70
75 Appendice A: Implementazione del sistema 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
76 Appendice A: Implementazione del sistema Package topicinterfacing Questo package contiene la gerarchia di classi necessaria per realizzare, nel modo più disaccoppiato possibile, l interfacciamento 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
Reti di Telecomunicazione Lezione 8
Reti di Telecomunicazione Lezione 8 Marco Benini Corso di Laurea in Informatica marco.benini@uninsubria.it Livello di trasporto Programma della lezione relazione tra lo strato di trasporto e lo strato
DettagliArchitetture software
Corso di Laurea Magistrale in Ingegneria Informatica Corso di Ingegneria del A. A. 2013-2014 Architettura software 1 Architetture software Sommario Definizioni 2 Architettura Definizione. L architettura
DettagliIndice generale. OOA Analisi Orientata agli Oggetti. Introduzione. Analisi
Indice generale OOA Analisi Orientata agli Oggetti Introduzione Analisi Metodi d' analisi Analisi funzionale Analisi del flusso dei dati Analisi delle informazioni Analisi Orientata agli Oggetti (OOA)
DettagliAutomazione Industriale (scheduling+mms) scheduling+mms. adacher@dia.uniroma3.it
Automazione Industriale (scheduling+mms) scheduling+mms adacher@dia.uniroma3.it Introduzione Sistemi e Modelli Lo studio e l analisi di sistemi tramite una rappresentazione astratta o una sua formalizzazione
DettagliReti di Telecomunicazione Lezione 6
Reti di Telecomunicazione Lezione 6 Marco Benini Corso di Laurea in Informatica marco.benini@uninsubria.it Lo strato di applicazione protocolli Programma della lezione Applicazioni di rete client - server
DettagliA intervalli regolari ogni router manda la sua tabella a tutti i vicini, e riceve quelle dei vicini.
Algoritmi di routing dinamici (pag.89) UdA2_L5 Nelle moderne reti si usano algoritmi dinamici, che si adattano automaticamente ai cambiamenti della rete. Questi algoritmi non sono eseguiti solo all'avvio
DettagliMODELLO CLIENT/SERVER. Gianluca Daino Dipartimento di Ingegneria dell Informazione Università degli Studi di Siena daino@unisi.it
MODELLO CLIENT/SERVER Gianluca Daino Dipartimento di Ingegneria dell Informazione Università degli Studi di Siena daino@unisi.it POSSIBILI STRUTTURE DEL SISTEMA INFORMATIVO La struttura di un sistema informativo
DettagliComunicazione tra Computer. Protocolli. Astrazione di Sottosistema di Comunicazione. Modello di un Sottosistema di Comunicazione
I semestre 04/05 Comunicazione tra Computer Protocolli Prof. Vincenzo Auletta auletta@dia.unisa.it http://www.dia.unisa.it/professori/auletta/ Università degli studi di Salerno Laurea in Informatica 1
DettagliDatabase. Si ringrazia Marco Bertini per le slides
Database Si ringrazia Marco Bertini per le slides Obiettivo Concetti base dati e informazioni cos è un database terminologia Modelli organizzativi flat file database relazionali Principi e linee guida
Dettagli3. Introduzione all'internetworking
3. Introduzione all'internetworking Abbiamo visto i dettagli di due reti di comunicazione: ma ce ne sono decine di tipo diverso! Occorre poter far comunicare calcolatori che si trovano su reti di tecnologia
DettagliAgenti Mobili Intelligenti e Sicurezza Informatica Utilizzare un nuovo paradigma applicativo per la realizzazione di sistemi informatici sicuri.
Agenti Mobili Intelligenti e Sicurezza Informatica Utilizzare un nuovo paradigma applicativo per la realizzazione di sistemi informatici sicuri. Roma, 25 ottobre 2010 Ing. Antonio Salomè Ing. Luca Lezzerini
DettagliUTILIZZATORI A VALLE: COME RENDERE NOTI GLI USI AI FORNITORI
UTILIZZATORI A VALLE: COME RENDERE NOTI GLI USI AI FORNITORI Un utilizzatore a valle di sostanze chimiche dovrebbe informare i propri fornitori riguardo al suo utilizzo delle sostanze (come tali o all
DettagliARCHITETTURA DI RETE FOLEGNANI ANDREA
ARCHITETTURA DI RETE FOLEGNANI ANDREA INTRODUZIONE È denominata Architettura di rete un insieme di livelli e protocolli. Le reti sono organizzate gerarchicamente in livelli, ciascuno dei quali interagisce
DettagliSISTEMI INFORMATIVI AVANZATI -2010/2011 1. Introduzione
SISTEMI INFORMATIVI AVANZATI -2010/2011 1 Introduzione In queste dispense, dopo aver riportato una sintesi del concetto di Dipendenza Funzionale e di Normalizzazione estratti dal libro Progetto di Basi
DettagliIl database management system Access
Il database management system Access Corso di autoistruzione http://www.manualipc.it/manuali/ corso/manuali.php? idcap=00&idman=17&size=12&sid= INTRODUZIONE Il concetto di base di dati, database o archivio
DettagliReti e Internet: introduzione
Facoltà di Medicina - Corso di Laurea in Logopedia Corso di Informatica III anno Prof. Crescenzio Gallo Reti e Internet: introduzione c.gallo@unifg.it Reti e Internet: argomenti Tipologie di reti Rete
DettagliFasi di creazione di un programma
Fasi di creazione di un programma 1. Studio Preliminare 2. Analisi del Sistema 6. Manutenzione e Test 3. Progettazione 5. Implementazione 4. Sviluppo 41 Sviluppo di programmi Per la costruzione di un programma
DettagliGuida Compilazione Piani di Studio on-line
Guida Compilazione Piani di Studio on-line SIA (Sistemi Informativi d Ateneo) Visualizzazione e presentazione piani di studio ordinamento 509 e 270 Università della Calabria (Unità organizzativa complessa-
DettagliNetwork Monitoring. Introduzione all attività di Network Monitoring introduzione a Nagios come motore ideale
Network Monitoring & Introduzione all attività di Network Monitoring introduzione a Nagios come motore ideale Nicholas Pocher Poker SpA - Settimo Torinese, Novembre 2013 1 Indice Il Network Monitoring:
DettagliValutazione sperimentale di middleware pub/sub per reti wireless!
tesi di laurea! Valutazione sperimentale di middleware pub/sub per reti wireless! Anno Accademico 2009/2010! relatore! Ch.mo prof. Domenico Cotroneo! correlatore! Ing. Christiancarmine Esposito! candidato!
DettagliReti di Telecomunicazioni Mobile IP Mobile IP Internet Internet Protocol header IPv4 router host indirizzi IP, DNS URL indirizzo di rete
IP Analizziamo con sufficiente dettaglio il sistema denominato IP, usato per consentire a due computer mobili di spostarsi liberamente in altre reti pur mantenendo lo stesso indirizzo IP. In particolare,
DettagliSoftware per Helpdesk
Software per Helpdesk Padova - maggio 2010 Antonio Dalvit - www.antoniodalvit.com Cosa è un helpdesk? Un help desk è un servizio che fornisce informazioni e assistenza ad utenti che hanno problemi nella
DettagliOrganizzazione degli archivi
COSA E UN DATA-BASE (DB)? è l insieme di dati relativo ad un sistema informativo COSA CARATTERIZZA UN DB? la struttura dei dati le relazioni fra i dati I REQUISITI DI UN DB SONO: la ridondanza minima i
DettagliBanca dati Professioniste in rete per le P.A. Guida all uso per le Professioniste
Banca dati Professioniste in rete per le P.A. Guida all uso per le Professioniste versione 2.1 24/09/2015 aggiornamenti: 23-set-2015; 24-set-2015 Autore: Francesco Brunetta (http://www.francescobrunetta.it/)
DettagliUniversità di Roma Tor Vergata Corso di Laurea triennale in Informatica Sistemi operativi e reti A.A. 2014-15. Pietro Frasca. Parte II Lezione 5
Università di Roma Tor Vergata Corso di Laurea triennale in Informatica Sistemi operativi e reti A.A. 2014-15 Parte II Lezione 5 Giovedì 19-03-2015 1 Intensità del traffico e perdita dei pacchetti La componente
DettagliNAVIGAORA HOTSPOT. Manuale utente per la configurazione
NAVIGAORA HOTSPOT Manuale utente per la configurazione NAVIGAORA Hotspot è l innovativo servizio che offre ai suoi clienti accesso ad Internet gratuito, in modo semplice e veloce, grazie al collegamento
Dettagli1. BASI DI DATI: GENERALITÀ
1. BASI DI DATI: GENERALITÀ BASE DI DATI (DATABASE, DB) Raccolta di informazioni o dati strutturati, correlati tra loro in modo da risultare fruibili in maniera ottimale. Una base di dati è usualmente
DettagliLezione 1. Introduzione e Modellazione Concettuale
Lezione 1 Introduzione e Modellazione Concettuale 1 Tipi di Database ed Applicazioni Database Numerici e Testuali Database Multimediali Geographic Information Systems (GIS) Data Warehouses Real-time and
DettagliSiamo così arrivati all aritmetica modulare, ma anche a individuare alcuni aspetti di come funziona l aritmetica del calcolatore come vedremo.
DALLE PESATE ALL ARITMETICA FINITA IN BASE 2 Si è trovato, partendo da un problema concreto, che con la base 2, utilizzando alcune potenze della base, operando con solo addizioni, posso ottenere tutti
DettagliPublish/Subscribe Communication Infrastructures. Esercizi M I D L A B. Sistemi Distribuiti Leonardo Querzoni - 20/3/2007
M I D L A B M i d d l ew a re L a b o r a t o r y Università di Roma La Sapienza Dipartimento di Informatica e Sistemistica Publish/Subscribe Communication Infrastructures Esercizi Sistemi Distribuiti
DettagliEXPLOit Content Management Data Base per documenti SGML/XML
EXPLOit Content Management Data Base per documenti SGML/XML Introduzione L applicazione EXPLOit gestisce i contenuti dei documenti strutturati in SGML o XML, utilizzando il prodotto Adobe FrameMaker per
DettagliIntroduzione alla Virtualizzazione
Introduzione alla Virtualizzazione Dott. Luca Tasquier E-mail: luca.tasquier@unina2.it Virtualizzazione - 1 La virtualizzazione è una tecnologia software che sta cambiando il metodo d utilizzo delle risorse
Dettagli2003.06.16 Il sistema C.R.M. / E.R.M.
2003.06.16 Il sistema C.R.M. / E.R.M. Customer / Enterprise : Resource Management of Informations I-SKIPPER è un sistema di CONOSCENZE che raccoglie ed integra INFORMAZIONI COMMERCIALI, dati su Clienti,
DettagliBASI DI DATI per la gestione dell informazione. Angelo Chianese Vincenzo Moscato Antonio Picariello Lucio Sansone
BASI DI DATI per la gestione dell informazione Angelo Chianese Vincenzo Moscato Antonio Picariello Lucio Sansone Libro di Testo 22 Chianese, Moscato, Picariello e Sansone BASI DI DATI per la Gestione dell
DettagliProva di Esame - Rete Internet (ing. Giovanni Neglia) Lunedì 24 Gennaio 2005, ore 15.00
Prova di Esame - Rete Internet (ing. Giovanni Neglia) Lunedì 24 Gennaio 200, ore 1.00 NB: alcune domande hanno risposta multipla: si richiede di identificare TUTTE le risposte corrette. Cognome: Nome:
DettagliManuale Amministratore Legalmail Enterprise. Manuale ad uso degli Amministratori del Servizio Legalmail Enterprise
Manuale Amministratore Legalmail Enterprise Manuale ad uso degli Amministratori del Servizio Legalmail Enterprise Pagina 2 di 16 Manuale Amministratore Legalmail Enterprise Introduzione a Legalmail Enterprise...3
Dettagli1) GESTIONE DELLE POSTAZIONI REMOTE
IMPORTAZIONE ESPORTAZIONE DATI VIA FTP Per FTP ( FILE TRANSFER PROTOCOL) si intende il protocollo di internet che permette di trasferire documenti di qualsiasi tipo tra siti differenti. Per l utilizzo
DettagliIntroduzione. Classificazione di Flynn... 2 Macchine a pipeline... 3 Macchine vettoriali e Array Processor... 4 Macchine MIMD... 6
Appunti di Calcolatori Elettronici Esecuzione di istruzioni in parallelo Introduzione... 1 Classificazione di Flynn... 2 Macchine a pipeline... 3 Macchine vettoriali e Array Processor... 4 Macchine MIMD...
Dettaglie-dva - eni-depth Velocity Analysis
Lo scopo dell Analisi di Velocità di Migrazione (MVA) è quello di ottenere un modello della velocità nel sottosuolo che abbia dei tempi di riflessione compatibili con quelli osservati nei dati. Ciò significa
DettagliCORSO DI RETI SSIS. Lezione n.2. 2 Novembre 2005 Laura Ricci
CORSO DI RETI SSIS Lezione n.2. 2 Novembre 2005 Laura Ricci IL DOMAIN NAME SYSTEM (DNS) Indirizzi IP poco adatti per essere memorizzati da utenti umani è prevista la possibiltà di associare nomi simbolici
DettagliDimensione di uno Spazio vettoriale
Capitolo 4 Dimensione di uno Spazio vettoriale 4.1 Introduzione Dedichiamo questo capitolo ad un concetto fondamentale in algebra lineare: la dimensione di uno spazio vettoriale. Daremo una definizione
DettagliLe fattispecie di riuso
Le fattispecie di riuso Indice 1. PREMESSA...3 2. RIUSO IN CESSIONE SEMPLICE...4 3. RIUSO CON GESTIONE A CARICO DEL CEDENTE...5 4. RIUSO IN FACILITY MANAGEMENT...6 5. RIUSO IN ASP...7 1. Premessa Poiché
DettagliSistemi centralizzati e distribuiti
Sistemi centralizzati e distribuiti In relazione al luogo dove è posta fisicamente la base di dati I sistemi informativi, sulla base del luogo dove il DB è realmente dislocato, si possono suddividere in:
DettagliTelerilevamento e GIS Prof. Ing. Giuseppe Mussumeci
Corso di Laurea Magistrale in Ingegneria per l Ambiente e il Territorio A.A. 2014-2015 Telerilevamento e GIS Prof. Ing. Giuseppe Mussumeci Strutture di dati: DB e DBMS DATO E INFORMAZIONE Dato: insieme
DettagliSoftware di sistema e software applicativo. I programmi che fanno funzionare il computer e quelli che gli permettono di svolgere attività specifiche
Software di sistema e software applicativo I programmi che fanno funzionare il computer e quelli che gli permettono di svolgere attività specifiche Software soft ware soffice componente è la parte logica
DettagliCOMUNIC@CTION INVIO SMS
S I G e s t S.r.l S e d e l e g a l e : V i a d e l F o r n o 3 19125 L a S p e z i a T e l e f o n o 0187/284510/15 - F a x 0187/525519 P a r t i t a I V A 01223450113 COMUNIC@CTION INVIO SMS GUIDA ALL
DettagliArchitetture Applicative
Alessandro Martinelli alessandro.martinelli@unipv.it 6 Marzo 2012 Architetture Architetture Applicative Introduzione Alcuni esempi di Architetture Applicative Architetture con più Applicazioni Architetture
DettagliApproccio stratificato
Approccio stratificato Il sistema operativo è suddiviso in strati (livelli), ciascuno costruito sopra quelli inferiori. Il livello più basso (strato 0) è l hardware, il più alto (strato N) è l interfaccia
DettagliCORSO ACCESS PARTE II. Esistono diversi tipi di aiuto forniti con Access, generalmente accessibili tramite la barra dei menu (?)
Ambiente Access La Guida di Access Esistono diversi tipi di aiuto forniti con Access, generalmente accessibili tramite la barra dei menu (?) Guida in linea Guida rapida Assistente di Office indicazioni
Dettagli03. Il Modello Gestionale per Processi
03. Il Modello Gestionale per Processi Gli aspetti strutturali (vale a dire l organigramma e la descrizione delle funzioni, ruoli e responsabilità) da soli non bastano per gestire la performance; l organigramma
DettagliLa piattaforma di lettura targhe intelligente ed innovativa in grado di offrire servizi completi e personalizzati
La piattaforma di lettura targhe intelligente ed innovativa in grado di offrire servizi completi e personalizzati Affidabilità nel servizio precisione negli strumenti Chanda LPR Chanda LPR è una piattaforma
DettagliLo scenario: la definizione di Internet
1 Lo scenario: la definizione di Internet INTERNET E UN INSIEME DI RETI DI COMPUTER INTERCONNESSE TRA LORO SIA FISICAMENTE (LINEE DI COMUNICAZIONE) SIA LOGICAMENTE (PROTOCOLLI DI COMUNICAZIONE SPECIALIZZATI)
DettagliWEB SEMINAR Dettaglio servizio
WEB SEMINAR Dettaglio servizio INTRODUZIONE L organizzazione di un web seminar prevede diverse e ben distinte fasi che iniziano con la promozione dell evento e si concludono con i report relativi alle
DettagliBrochure Internet. Versione 2010.1 The Keyrules Company s.r.l. Pagina 2 di 8
Ogni organizzazione possiede un sistema di regole che la caratterizzano e che ne assicurano il funzionamento. Le regole sono l insieme coordinato delle norme che stabiliscono come deve o dovrebbe funzionare
DettagliScenario di Progettazione
Appunti del 3 Ottobre 2008 Prof. Mario Bochicchio SCENARIO DI PROGETTAZIONE Scenario di Progettazione Il Committente mette a disposizione delle risorse e propone dei documenti che solitamente rappresentano
DettagliIndice. pagina 2 di 10
LEZIONE PROGETTAZIONE ORGANIZZATIVA DOTT.SSA ROSAMARIA D AMORE Indice PROGETTAZIONE ORGANIZZATIVA---------------------------------------------------------------------------------------- 3 LA STRUTTURA
DettagliCoordinazione Distribuita
Coordinazione Distribuita Ordinamento degli eventi Mutua esclusione Atomicità Controllo della Concorrenza 21.1 Introduzione Tutte le questioni relative alla concorrenza che si incontrano in sistemi centralizzati,
DettagliFirewall applicativo per la protezione di portali intranet/extranet
Firewall applicativo per la protezione di portali intranet/extranet Descrizione Soluzione Milano Hacking Team S.r.l. http://www.hackingteam.it Via della Moscova, 13 info@hackingteam.it 20121 MILANO (MI)
DettagliGestione della memoria centrale
Gestione della memoria centrale Un programma per essere eseguito deve risiedere in memoria principale e lo stesso vale per i dati su cui esso opera In un sistema multitasking molti processi vengono eseguiti
DettagliTi consente di ricevere velocemente tutte le informazioni inviate dal personale, in maniera assolutamente puntuale, controllata ed organizzata.
Sommario A cosa serve InfoWEB?... 3 Quali informazioni posso comunicare o ricevere?... 3 Cosa significa visualizzare le informazioni in maniera differenziata in base al livello dell utente?... 4 Cosa significa
DettagliAppunti sulla Macchina di Turing. Macchina di Turing
Macchina di Turing Una macchina di Turing è costituita dai seguenti elementi (vedi fig. 1): a) una unità di memoria, detta memoria esterna, consistente in un nastro illimitato in entrambi i sensi e suddiviso
DettagliCreare una Rete Locale Lezione n. 1
Le Reti Locali Introduzione Le Reti Locali indicate anche come LAN (Local Area Network), sono il punto d appoggio su cui si fonda la collaborazione nel lavoro in qualunque realtà, sia essa un azienda,
DettagliYOU ARE WHAT YOU CURATE COS E LA CONTENT CURATION E COME APPLICARLA
YOU ARE WHAT YOU CURATE COS E LA CONTENT CURATION E COME APPLICARLA YOU ARE WHAT YOU CURATE INTRODUZIONE DEFINIZIONE: COS E LA CONTENT CURATION? PERCHE FARNE USO IL CONTENT CURATOR COME NON FARE CONTENT
DettagliUniversità degli Studi "Roma Tre" Dipartimento di Informatica ed automazione. Facoltà di Ingegneria
Università degli Studi "Roma Tre" Dipartimento di Informatica ed automazione Facoltà di Ingegneria Corso di Laurea in Ingegneria Informatica Tesi di Laurea AUTENTICAZIONE PER APPLICAZIONI WEB Relatore
DettagliCorso di Informatica
CdLS in Odontoiatria e Protesi Dentarie Corso di Informatica Prof. Crescenzio Gallo crescenzio.gallo@unifg.it Le Reti di Computer 2 Introduzione Una rete è un complesso insieme di sistemi di elaborazione
DettagliLA GESTIONE DELLE VISITE CLIENTI VIA WEB
LA GESTIONE DELLE VISITE CLIENTI VIA WEB L applicazione realizzata ha lo scopo di consentire agli agenti l inserimento via web dei dati relativi alle visite effettuate alla clientela. I requisiti informatici
DettagliPROJECT MANAGEMENT SERVIZI DI PROJECT MANAGEMENT DI ELEVATA PROFESSIONALITÀ
PROJECT MANAGEMENT SERVIZI DI PROJECT MANAGEMENT DI ELEVATA PROFESSIONALITÀ SERVIZI DI PROJECT MANAGEMENT CENTRATE I VOSTRI OBIETTIVI LA MISSIONE In qualità di clienti Rockwell Automation, potete contare
DettagliIndirizzi Internet e. I livelli di trasporto delle informazioni. Comunicazione e naming in Internet
Indirizzi Internet e Protocolli I livelli di trasporto delle informazioni Comunicazione e naming in Internet Tre nuovi standard Sistema di indirizzamento delle risorse (URL) Linguaggio HTML Protocollo
DettagliSDD System design document
UNIVERSITA DEGLI STUDI DI PALERMO FACOLTA DI INGEGNERIA CORSO DI LAUREA IN INGEGNERIA INFORMATICA TESINA DI INGEGNERIA DEL SOFTWARE Progetto DocS (Documents Sharing) http://www.magsoft.it/progettodocs
DettagliHardware delle reti LAN
Hardware delle reti LAN Le reti LAN utilizzano una struttura basata su cavi e concentratori che permette il trasferimento di informazioni. In un ottica di questo tipo, i computer che prendono parte allo
DettagliIl servizio di registrazione contabile. che consente di azzerare i tempi di registrazione delle fatture e dei relativi movimenti contabili
Il servizio di registrazione contabile che consente di azzerare i tempi di registrazione delle fatture e dei relativi movimenti contabili Chi siamo Imprese giovani e dinamiche ITCluster nasce a Torino
DettagliTELECOMUNICAZIONI II: LE RETI DI COMUNICAZIONE. INTRODUZIONE... pag.2
1 TELECOMUNICAZIONI II: LE RETI DI COMUNICAZIONE INDICE INTRODUZIONE... pag.2 LE RETI DI COMUNICAZIONE.. pag.2 La rete interconnessa (o a maglia).. pag.2 La rete a commutazione. pag.3 La rete policentrica
DettagliApplication note. CalBatt NomoStor per i sistemi di accumulo di energia
1. Panoramica Application note CalBatt NomoStor per i sistemi di accumulo di energia Gli Energy Management Systems () sono dispositivi atti al controllo dei flussi di energia dalle sorgenti di produzione
DettagliIT Cloud Service. Semplice - accessibile - sicuro - economico
IT Cloud Service Semplice - accessibile - sicuro - economico IT Cloud Service - Cos è IT Cloud Service è una soluzione flessibile per la sincronizzazione dei file e la loro condivisione. Sia che si utilizzi
DettagliIl calendario di Windows Vista
Il calendario di Windows Vista Una delle novità introdotte in Windows Vista è il Calendario di Windows, un programma utilissimo per la gestione degli appuntamenti, delle ricorrenze e delle attività lavorative
DettagliCon il termine Sistema operativo si fa riferimento all insieme dei moduli software di un sistema di elaborazione dati dedicati alla sua gestione.
Con il termine Sistema operativo si fa riferimento all insieme dei moduli software di un sistema di elaborazione dati dedicati alla sua gestione. Compito fondamentale di un S.O. è infatti la gestione dell
Dettagliuadro Soluzioni software per L archiviazione elettronica dei documenti Gestione Aziendale Fa quadrato attorno alla tua azienda
Fa quadrato attorno alla tua azienda Soluzioni software per L archiviazione elettronica dei documenti Perché scegliere Q Archiviazione Elettronica dei Documenti? Tale applicativo si pone come obbiettivo
DettagliREGIONE BASILICATA DIPARTIMENTO PRESIDENZA DELLA GIUNTA UFFICIO SOCIETÀ DELL INFORMAZIONE
REGIONE BASILICATA DIPARTIMENTO PRESIDENZA DELLA GIUNTA UFFICIO SOCIETÀ DELL INFORMAZIONE Bando pubblico per lo sviluppo della rete a Banda Larga nelle aree a fallimento di mercato finalizzato al superamento
Dettagli7. Architetture Software
7. Architetture Software progettare la struttura Andrea Polini Ingegneria del Software Corso di Laurea in Informatica (Ingegneria del Software) 7. Architetture Software 1 / 20 Scopo della fase di design
DettagliAl termine del lavoro ad uno dei componenti del gruppo verrà affidato l incarico di relazionare a nome di tutto il gruppo.
Pag. 1 di 5 6FRSR analizzare problemi complessi riguardanti la gestione di un sito interattivo proponendo soluzioni adeguate e facilmente utilizzabili da una utenza poco informatizzata. 2ELHWWLYL GD UDJJLXQJHUH
DettagliAirone Gestione Rifiuti Funzioni di Esportazione e Importazione
Airone Gestione Rifiuti Funzioni di Esportazione e Importazione Airone Funzioni di Esportazione Importazione 1 Indice AIRONE GESTIONE RIFIUTI... 1 FUNZIONI DI ESPORTAZIONE E IMPORTAZIONE... 1 INDICE...
DettagliCorso Analista Programmatore Web PHP Corso Online Analista Programmatore Web PHP
Corso Analista Programmatore Web PHP Corso Online Analista Programmatore Web PHP Accademia Futuro info@accademiafuturo.it Programma Generale del Corso Analista Programmatore Web PHP Tematiche Trattate
Dettagliesales Forza Ordini per Abbigliamento
esales Rel. 2012 Forza Ordini per Abbigliamento Scopo di questo documento è fornire la descrizione di una piattaforma di Raccolta Ordini via Web e la successiva loro elaborazione in ambiente ERP Aziendale.
DettagliIL SISTEMA INFORMATIVO
LEZIONE 15 DAL MODELLO DELLE CONDIZIONI DI EQUILIBRIO AL MODELLO CONTABILE RIPRESA DEL CONCETTO DI SISTEMA AZIENDALE = COMPLESSO DI ELEMENTI MATERIALI E NO CHE DIPENDONO RECIPROCAMENTE GLI UNI DAGLI ALTRI
DettagliLa gestione di un calcolatore. Sistemi Operativi primo modulo Introduzione. Sistema operativo (2) Sistema operativo (1)
La gestione di un calcolatore Sistemi Operativi primo modulo Introduzione Augusto Celentano Università Ca Foscari Venezia Corso di Laurea in Informatica Un calcolatore (sistema di elaborazione) è un sistema
DettagliIl modello veneto di Bilancio Sociale Avis
Il modello veneto di Bilancio Sociale Avis Le organizzazioni di volontariato ritengono essenziale la legalità e la trasparenza in tutta la loro attività e particolarmente nella raccolta e nell uso corretto
DettagliReti di calcolatori. Lezione del 10 giugno 2004
Reti di calcolatori Lezione del 10 giugno 2004 Internetworking I livelli 1 fisico e 2 data link si occupano della connessione di due host direttamente connessi su di una rete omogenea Non è possibile estendere
DettagliIL CICLO DI VITA DEL PROGETTO. Elementi essenziali di progetto. Fasi e tappe Gli Approcci
UNIVERSITA MILANO BICOCCA Corso di laurea di primo livello in servizio sociale anno accademico 2009-2010 Progettare il sociale Prof. Dario A. Colombo IL CICLO DI VITA DEL PROGETTO Elementi essenziali di
DettagliExcel. A cura di Luigi Labonia. e-mail: luigi.lab@libero.it
Excel A cura di Luigi Labonia e-mail: luigi.lab@libero.it Introduzione Un foglio elettronico è un applicazione comunemente usata per bilanci, previsioni ed altri compiti tipici del campo amministrativo
DettagliMon Ami 3000 Varianti articolo Gestione di varianti articoli
Prerequisiti Mon Ami 3000 Varianti articolo Gestione di varianti articoli L opzione Varianti articolo è disponibile per le versioni Azienda Light e Azienda Pro e include tre funzionalità distinte: 1. Gestione
DettagliUniversità Politecnica delle Marche. Progetto Didattico
Università Politecnica delle Marche Facoltà di Ingegneria Corso di Laurea in Ingegneria Informatica e dell Automazione Sede di Ancona Anno Accademico 2011-2012 Corso di Tecnologie WEB Docente prof. Alessandro
DettagliProgettare un Firewall
Progettare un Firewall Danilo Demarchi danilo@cuneo.linux.it GLUG Cuneo Corso Sicurezza 2006 Concetti introduttivi Come pensare un Firewall Argomenti trattati I Gli strumenti del Firewall Gli strumenti
DettagliDeterminare la grandezza della sottorete
Determinare la grandezza della sottorete Ogni rete IP possiede due indirizzi non assegnabili direttamente agli host l indirizzo della rete a cui appartiene e l'indirizzo di broadcast. Quando si creano
DettagliLE FUNZIONI A DUE VARIABILI
Capitolo I LE FUNZIONI A DUE VARIABILI In questo primo capitolo introduciamo alcune definizioni di base delle funzioni reali a due variabili reali. Nel seguito R denoterà l insieme dei numeri reali mentre
DettagliOttimizzazione Multi Obiettivo
Ottimizzazione Multi Obiettivo 1 Ottimizzazione Multi Obiettivo I problemi affrontati fino ad ora erano caratterizzati da una unica (e ben definita) funzione obiettivo. I problemi di ottimizzazione reali
DettagliConsiglio regionale della Toscana. Regole per il corretto funzionamento della posta elettronica
Consiglio regionale della Toscana Regole per il corretto funzionamento della posta elettronica A cura dell Ufficio Informatica Maggio 2006 Indice 1. Regole di utilizzo della posta elettronica... 3 2. Controllo
DettagliCorso di Amministrazione di Reti A.A. 2002/2003
Struttura di Active Directory Corso di Amministrazione di Reti A.A. 2002/2003 Materiale preparato utilizzando dove possibile materiale AIPA http://www.aipa.it/attivita[2/formazione[6/corsi[2/materiali/reti%20di%20calcolatori/welcome.htm
DettagliBASE DI DATI: introduzione. Informatica 5BSA Febbraio 2015
BASE DI DATI: introduzione Informatica 5BSA Febbraio 2015 Di cosa parleremo? Base di dati relazionali, modelli e linguaggi: verranno presentate le caratteristiche fondamentali della basi di dati. In particolare
Dettagli