FACOLTA’ di INGEGNERIA Corso di Laurea in Ingegneria Informatica
Progettazione e Sperimentazione di
un Sistema Distribuito di Diffusione
Eventi in Ambiente Domotico
Tesi di Laurea in Reti di Calcolatori
Relatore:
Prof.Leonardo Querzoni
Controrelatore:
Prof.Massimo Mecella
Candidato:
Agostino De Bartolo
Anno Accademico 2009/2010
Introduzione 9
1 Le Comunicazioni Basate su Eventi 15
1.1 Principali Paradigmi di Comunicazione . . . 15
1.2 Paradigma di comunicazione Publish/Subscribe . . . 17
1.2.1 Pattern Publish/Subscribe . . . 17
1.2.2 Vantaggi del Modello Publish/Subscribe . . . 18
1.3 Principali Modelli di Selezione delle Notifiche . . . 19
1.3.1 Channel-Based selection . . . 19
1.3.2 Topic-Based selection . . . 20
1.3.3 Content-Based selection . . . 20
1.3.4 Type-Based selection . . . 21
1.3.5 Schemi Misti . . . 21
1.4 Principali Implementazioni del Paradigma Publish/Subscribe . . . 22
1.4.1 CORBA . . . 22
1.4.2 TIBCO rendez-vous . . . 23
1.4.3 SCRIBE . . . 24
1.4.4 TERA . . . 24 2
1.4.6 Gryphon . . . 26
1.4.7 SIENA . . . 27
1.4.8 Jedi . . . 27
1.4.9 Ermes . . . 28
1.4.10 REBECA . . . 28
2 Web-Service Notification 29 2.1 Panoramica sui Web Services . . . 29
2.1.1 Architettura SOA . . . 29
2.1.2 Pila dei Protocolli . . . 31
2.1.3 Vantaggi dei Web Services . . . 35
2.2 Specifiche WS che supportano il paradigma Publish/Subscribe . . 36
2.2.1 WS-Events . . . 36
2.2.2 WS-Eventing . . . 38
2.2.3 WS-Notification . . . 40
2.2.4 Confronto fra le Specifiche . . . 41
2.2.5 Scenari di funzionamento di WS-Notification . . . 42
2.3 Il framework Apache Muse . . . 54
2.3.1 Caratteristiche . . . 58
2.3.2 Architettura . . . 59
2.3.3 Deployment Descriptor . . . 64
2.3.4 Il Router . . . 65
2.3.5 Resource Types . . . 70 3
3 Il paradigma di Comunicazione SCRIBE 77
3.1 Introduzione a SCRIBE . . . 77
3.2 Pastry in Scribe . . . 78
3.2.1 La Routing Table di Pastry . . . 78
3.2.2 Proprietà di Pastry . . . 80
3.3 SCRIBE . . . 84
3.3.1 Logica Generale di Funzionamento . . . 85
3.3.2 Gestione dei Gruppi . . . 86
3.3.3 Gestione dei membri di un Gruppo . . . 87
3.3.4 Disseminazione dei Messaggi . . . 89
3.3.5 Affidabilità . . . 89
4 Architettura Software e Implementazione 91 4.1 Scenario Applicativo . . . 91
4.2 Analisi dei Problemi e Scelte Progettuali . . . 95
4.3 Architettura dell’ENS . . . 102
4.3.1 DHTBundle . . . 108
4.3.2 PRODUCERBundle . . . 115
4.3.3 CONSUMERBundle . . . 119
4.3.4 Il Bundle muse-wsn-impl . . . 122
4.3.5 Gli altri Bundle dall’ambiente Operativo OSGI . . . 124
5 Test e Risultati Sperimentali 127 5.1 Ambiente Operativo dei Test . . . 127
5.2 Tipologie di Test Effettuati . . . 129
Consclusioni 133
Bibliografia 135
1 L’architettura di Smart hoMes for All – Una Piattaforma Midd-
leware Integrata per ambienti pervasivi ed immersivi . . . 14
2.1 Architettura SOA . . . 31
2.2 Pila Protocolli Web Services . . . 31
2.3 Confronto fra le specifiche . . . 43
2.4 Scenario senza Broker . . . 45
2.5 Operazione di Subscribe . . . 45
2.6 Operazione di Renew . . . 46
2.7 Operazione di Unsubscribe . . . 47
2.8 Operazione di Pause . . . 48
2.9 Operazione di Resume . . . 48
2.10 Operazione di Notify . . . 49
2.11 Scenario con Broker . . . 50
2.12 Interfaccia Broker . . . 51
2.13 Operazione Register Publisher . . . 51
2.14 Operazione di Destroy . . . 53
2.15 Operazione di Notify . . . 53
2.16 Architettura Apache Muse . . . 60 2.17 Costruire una Resource attraverso le Capability . . . 62 3.1 Routing Table di un nodo Pastry con nodeID 65a1x, b=4, le cifre
sono in base 16 ed x rappresenta un suffisso arbitrario. . . 79 3.2 Routing di un messaggio dal nodo 65a1fc con chiave d46a1c. I
punti in grassetto rappresentano i nodi funzionanti nel Pastry Circle 80 3.3 Definizione dell’albero di multicast per un generico topic t . . . . 88 4.1 Ambiente Domotico con l’astrazione della rete SCRIBE formata
dai Nodi Fissi e anche i Nodi Transienti . . . 97 4.2 Astrazione dei moduli contenuti in un Nodo Fisso . . . 103 4.3 Astrazione della rete logica dell’ambiente applicativo . . . 103 4.4 Astrazione: Un Nodo Transiente può produrre eventi sul topic t . 104 4.5 Sequence Diagram dei componenti dell’ENS in presenza di un
wsn-ProducerClient . . . 105 4.6 Astrazione: Un Nodo Transiente vuole ricevere notifiche sul topic t106 4.7 Sequence Diagram dei componenti dell’ENS in presenza di un
wsn-ConsumerClient . . . 106 4.8 Astrazione: Un Nodo Transiente vuole ricevere notifiche sul topic
t e Un Nodo Transiente può produrre eventi sul topic t . . . 107 4.9 Struttura dei packages del DHTBundle . . . 108 4.10 il DHTBundle esporta i suoi servizi attraverso il REGISTER Bundle113 4.11 il DHTBundle usa i servizi del PRODUCERBundle ricercandoli
attraverso il REGISTER Bundle . . . 114 4.12 Struttura dei packages del PRODUCERBundle . . . 115
4.13 Struttura del file compresso wsn-producer.jar . . . 116 4.14 il PRODUCERBundle esporta i suoi servizi attraverso il REGI-
STER Bundle . . . 117 4.15 il PRODUCERBundle usa i servizi del DHTBundle ricercandoli
attraverso il REGISTER Bundle . . . 118 4.16 Struttura dei packages del CONSUMERBundle . . . 119 4.17 Struttura del file compresso wsn-consumer.jar . . . 120 4.18 il CONSUMERBundle usa i servizi del DHTBundle ricercandoli
attraverso il REGISTER Bundle . . . 122 5.1 Rappresentazione concettuale configurazione ambiente di test . . 128 5.2 Risultati del test per la verifica della perdita di messaggi nell’ENS 129 5.3 Risultati del test per la verifica della latenza dei messaggi nell’ENS131
Il lavoro svolto in questa tesi si colloca nell’ambito del progetto SM4ALL. In particolar modo, l’attività è stata finalizzata alla progettazione, implementazione e test del modulo Event Notification Service (ENS). Nella fase di analisi e pro- gettazione, ci si è posti come problema principale da risolvere, la definizione di un’architettura service-oriented per la gestione degli eventi all’interno della rete domotica, che fosse distribuita, scalabile, efficiente e fornisse inoltre un interfac- ciamento, a dispositivi esterni o moduli del sistema, coerente con una specifica di notifica eventi. Definita la fase progettuale, si è lavorato sulla fase implemen- tativa definendo un Macromodulo concettuale le cui funzionalità principali sono l’implementazione del paradigma SCRIBE (cap.3) per la diffusione degli eventi nella rete domotica interna e la possibilità di interagire con questa, produzione e consumo di eventi, attraverso un’architettura di tipo Web Service coerente con la Specifica WS-Notification (cap.2). Il paradigma di comunicazione alla base dell’architettura dell’Event Service Notification è di tipo publish/subscribe topic- based. Ogni nodo della rete domotica interna implementa il paradigma SCRIBE con tutte le sue funzionalità e offre due Web-Service che consentono, a dispositivi esterni alla rete interna o a generici moduli locali, dunque non capaci di interagire direttamente all’interno della rete SCRIBE, di produrre e consumare eventi. L’u-
è utilizzare un client coerente alla specifica WS-Notification. L’ambiente opera- tivo delle unità modulari (bundles) che definiscono l’implementazione dell’ENS è OSGI. La tecnologia OSGi si riferisce ad un framework per sviluppare sistemi Java all’interno di un’architettura modulare orientata ai servizi. I micromoduli (PRODUCERBundle , CONSUMERBundle, DHTBundle), che definiscono il Ma- cromodulo, interagiscono tra di loro secondo un modello service-oriented. Tale modello progettuale fornisce accessibilità e scalabilità nella gestione delle noti- fiche all’interno della rete domotica. In ultima istanza, va specificato che tale Event Notification Service, se pur realizzato nell’ambito dell’ SM4ALL project, può essere considerato come un modulo di diffusione eventi utilizzabile in diversi ambiti, in quanto disaccoppiato dai componenti proprietari del progetto. A tal proposito l’ambito domotico può essere considerato come un caso d’uso e non come ambiente applicativo esclusivo. L’elemento di novità introdotto da questa implementazione è l’aver reso il paradigma SCRIBE accessibile grazie all’archi- tettura web-service che consente l’invocazione delle operazioni di sottoscrizione e pubblicazione delle notifiche attraverso un semplice client conforme alla specifica WS-Notification.
Di seguito viene illustrata la struttura della tesi con breve accenno agli argomenti trattati in ciascun capitolo.
Il Capitolo 1 fornisce una panormamica generale sui vari paradigmi di co- municazione fornendo particolare enfasi al Paradigma Publish/Subscribe di cui sono stati analizzati gli aspetti più importanti come le tipologie di selezione delle notifiche, le qualità e i difetti di questo modello e descrivendo lo stato dell’arte per quanto concerne le diverse implementazioni esistenti.
do i vantaggi di una tale scelta progettuale. Di seguito si fa la descrizione e il confronto delle varie specifiche di Web Service che considerano il modello Pu- blish/Subscribe concentrandosi però sulla specifica WS-Notification che è quella implementata nell’ENS. Si conclude con una descrizione di Muse, il framework fornito da Apache, che supporta un’implementazione della specifica di base di WS-Notification
Il Capitolo 3 descrive in maniera approfondita il paradigma Scribe analiz- zando gli aspetti generali, che fanno di esso un ottimo sistema Publish/Subscribe distribuito, ma anche aspetti specifici come le API, la gestione dei membri e dei gruppi, la disseminazione dei messaggi e l’affidabilità.
Il Capitolo 4 presenta l’architettura software dell’ENS. Si parte da un’astra- zione molto generale che serve a fornire una panoramica iniziale dei componenti e della relazione che sussiste fra di essi. Vengono introdotti gli scenari applicativi più rilevanti fino a giungere all’analisi più approfondita del livello implementativo dei componenti principali.
Il Capitolo 5 descrive l’ambiente di test e la tipologia di test effettuati. Si conclude con l’analisi dei risultati ottenuti.
Infine, vengono presentate le considerazioni finali a conclusione del lavoro svolto.
Il Progetto SM4ALL
Il progetto SM4ALL [32] (Smart hoMes for All) mira allo studio e allo sviluppo di una piattaforma middleware innovativa per l’inter-operabilità di servizi smart embedded in ambienti immersive e person-centric, attraverso l’uso di compo- nibilità e tecniche semantiche per garantire dinamicità, affidabilità e sclabilità, preservando privacy e sicurezza della piattaforma e dei suoi utenti. Tutto ciò vie- ne applicato a scenari abitativi privati in presenza di utenti con abilità e bisogni differenti . In particolare, nel progetto SM4ALL, sono fusi in modo innovativo architetture P2P, service-oriented e context-awareness per diventare un modello di riferimento per embedded middleware in ambienti immersivi in cui domotica e home-care sono stati scelti come show-case. La piattaforma offrirà caratteristiche specifiche in termini di:
• Dinamicità - Sensori e sevizi non sono statici, come nelle reti classiche ma i sistemi distribuiti necessitano di adattarsi continuamente sulla base del con- testo, dele abitudini,etc. dell’ utente, aggiungendo/rimuovendo/componendo on-the-fly elementi di base come i servizi offerti da sensori, dispositivi, apparecchi.
• Scalabilità - Al fine di immergere l’utente nel sistema, il numero di ap- parecchi sensori/dispositivi/apparecchiature è molto alto, nell’ordine delle migliaia. La scalabilità diventa dunque un punto di forza centrale.
• Affidabilità - Quando gli utenti sono al centro del sistema, essi dipen- dono strettamente dall’ambiente e dal sistema stesso, quindi condizioni di affidabilità sono necessarie.
rezza diventa un elemento cruciale. Informazioni sensibili sull’utente, sia relativamente alla sicurezza che alla privacy, devono essere dunque protette facendo in modo che il sistema non perda però in dinamicità.
Sfruttando tecniche di computing autonomo e sistemi peer-to-peer, i servizi e la piattaforma offriranno tali caratteristiche built-in direttamente, e non come un’ulteriore add-on. Inoltre, la piattaforma è progettata con particolare atten- zione all’ontologia atta a descivere le capacità dei servizi, in modo da ottenere configurazione e composizione dinamica dei servizi. Particolare attenzione è de- dicata alla sicurezza globale dell’ambiente smart, in relazione a chi/che cosa può fare e ad eventuali inclusioni di sensori/servizi/dispositivi.Inoltre gli utenti con diverse capacità e necessità possono interagire con i servizi previsti dai vari di- spositivi di domotica, attraverso apparecchi, sensori di base e interfacce avanzate, essendo quest’ultime basate sulla tecnologia di interazione cervello-computer. La BCI (Brain Computer Interaction) è un insieme specifico di tecniche, basate sul- l’interazione di harware e software che consente all’utente di interagire con uno schermo per la selezione di un specifica funzione fra varie possibilità. Seleziona- ta la funzione, tecniche di composizione, stabiliranno la maniera più idonea per coordinare i servizi disponibili e attraverso un processo di orchestrazione si cer- cherà di assolvere alla richiesta dell’utente. Quindi, il sistema SM4ALL propone nuove alternative possibili, e il ciclo (scelta dell’utente, composizione e orche- strazione) è ripetuto fino a quando la soddisfazione dell’utente viene raggiunta.
In tal modo, la continua interazione tra l’utente e le infrastrutture della casa (l’interazione tra i vari punti agisce in modo proattivo e automatico, e non è
Figura 1: L’architettura di Smart hoMes for All – Una Piattaforma Middleware Integrata per ambienti pervasivi ed immersivi
Nella Figura è mostrata la visione dell’architettura SM4All, costituita da:
• Pervasive Layer - infrastrutture hardware (dispositivi, sensori) e il software
• Composition Layer - tutti i componenti che hanno bisogno di soddisfare automaticamente le esigenze degli utenti, vale a dire, il composition engine, il repository e il context-aware dell’utente.
• User Layer - interfacce utente tradizionali e Brain-Computer-Interface (BCIs).
Le Comunicazioni Basate su
Eventi
1.1 Principali Paradigmi di Comunicazione
RPC - invocazione remota: l’invocazione remota di eventi, nelle sue numero- se forme, è ad oggi il metodo più diffuso per implementare il calcolo distribuito.
Con l’uso di questo paradigma lo sviluppatore può utilizzare nella propria applica- zione 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 in- carnazioni 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-a-molti. 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 per un qualche tipo di infor- mazione 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 sa- rà 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 par- tecipanti al sistema di calcolo distribuito, uno spazio di indirizzamento comune;
la comunicazione tra gli host avviene scrivendo e leggendo dati in questo spa- zio comune. Il tipo di memoria condivisa più semplice è fornito dai cosiddetti tuple-spaces, spazi di memorizzazione condivisi in cui le informazioni assumono la forma di tuple ordinate accessibili da tutti gli host partecipanti. La comuni- cazione 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 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 princi- pali 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 que-
sto 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.
1.2 Paradigma di comunicazione Publish/Subscribe
1.2.1 Pattern Publish/Subscribe
I Pattern costituiscono una soluzione a problemi di progettazione software, che si incontrano spesso in applicazioni del mondo reale. Lo schema di interazione publish/subscribe soddisfa i requisiti di basso accoppiamento tra le parti comuni- canti, richiesti dai sistemi distribuiti. I sottoscrittori possono esprimere interesse verso un certo tipo di eventi e, ogni volta che un publisher pubblica tale evento, il sistema provvederà a consegnarlo a tutti i subscriber interessati. L’atto della pubblicazione da parte di un publisher è chiamato evento, mentre la consegna al subscriber si definisce notifica dell’evento. Tale meccanismo si basa sulla presenza di un sistema intermedio, Broker, che riceve gli eventi (prodotti dai publisher) e li notifica ai subscriber, che si comportano come consumatori di eventi. Il Broker costituisce il middleware e deve fornire delle funzioni tramite le quali publisher e subscriber possano effettuare, rispettivamente, la pubblicazione e la sottoscrizio- ne o revoca della sottoscrizione. Alcune specifiche prevedono una comunicazione diretta tra publisher e subscriber senza la necessità di un’intermediario. In alcune architetture tale modello può essere più adatto al processo di notifica.
1.2.2 Vantaggi del Modello Publish/Subscribe
Il punto di forza del modello publish/subscribe [2] è il disaccoppiamento che il broker crea tra publisher e subscriber. In particolare, si hanno i seguenti livelli di disaccoppiamento:
• Space decoupling: i publisher e i subscriber non hanno necessità di conoscersi a vicenda. I publisher pubblicano eventi attraverso il broker e i subscriber li ricevono da quest’ultimo. I publisher non mantengono un riferimento ai subscriber, ne sanno quanti subscriber sono presenti nel sistema. Lo stesso vale per i subscriber.
• Time decoupling: non occorre che le parti interagenti siano attive nello stesso momento. Ad esempio, un publisher può pubblicare eventi, ma il subscriber interessato potrebbe non essere connesso; viceversa, un subscri- ber può ricevere notifica per un evento prodotto da un publisher, che al momento risulta disconnesso.
• Synchronization decoupling: non esiste sincronizzazione tra publisher e subscriber. I publisher, all’atto della produzione di un evento, non restano in attesa che un subscriber interessato venga notificato; analogamente, i subscriber ricevono, in modo asincrono, una notifica da parte del broker, quando l’evento a cui sono interessati è disponibile.
Space, time e synchronization decoupling eliminano le dipendenze tra i parte- cipanti all’interazione, rendendo il modello estremamente flessibile. Un altro vantaggio è un’ implicita comunicazione multipunto, che migliora la scalabilità della soluzione.
1.3 Principali Modelli di Selezione delle Noti-
fiche
La scelta di un adeguato metodo di selezione degli eventi è un argomento di cru- ciale 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ù com- plesso e computazionalmente impegnativo il meccanismo di routing delle notifi- che. Analizzeremo ora i cinque principali approcci adottati nelle implementazioni oggi esistenti, mettendo in luce il loro grado di espressività.
1.3.1 Channel-Based selection
I primi esempi di sistemi Publish/Subscribe hanno adottato uno spazio degli even- ti 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 selettività 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.
1.3.2 Topic-Based selection
Il passo successivo nell’evoluzione dei sistemi Publish-Subscribe è stata l’intro- duzione di una gerarchia dei canali. In questi sistemi [8, 14, 15] è 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 fles- sibilità offerta dai sistemi topic-based, in essi possiamo riscontrare tutti i limiti propri dei sistemi channel-based.
1.3.3 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 selec- tion [10, 12, 13] 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.
1.3.4 Type-Based selection
Molto spesso, in un sistema topic-based, le notifiche appartenenti ad un canale oltre a mostrare un affinità nel contenuto, mostrano una quasi totale identità nella struttura. Questa idea ha portato a sostituire il concetto di topic con quello di tipo. Grazie a questa scelta la gerarchia dei tipi non deve essere più esplicitamente dichiarata (come nel caso topic-based), ma viene indotta dalla struttura delle classi che realizzano i tipi.
1.3.5 Schemi Misti
Molte applicazioni richiedono la trasmissione di informazioni dalla struttura varie- gata che permette di attuare un approccio misto: un primo partizionamento con una metodologia topic-based, per poi affinare la selezione sugli attributi rima- nenti 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.
1.4 Principali Implementazioni del Paradigma
Publish/Subscribe
1.4.1 CORBA
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 [16] è un servizio offerto da CORBA che permette di disac- coppiare la comunicazione tra oggetti. Esso definisce due ruoli per gli 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 la 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 comunica- zione richiedendo i dati ad un produttore. Nel primo caso l’iniziativa è lasciata ai produttori, nel secondo ai consumatori. La tipologia di comunicazione può poi essere generica o tipizzata. Nel primo caso l’informazione, oggetto della comuni- cazione, è 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’informa- zioni è 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 speci- fica relativa a CORBA Notification Service [20], un’evoluzione dell’Event Service.
All’interno di CNS i messaggi possono essere di tre tipi: CORBA Any, un ogget- to 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 carat- teristica, 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.
1.4.2 TIBCO rendez-vous
TIBCO Rendezvous [22] è un’implementazione commerciale di grande successo del paradigma Publish-Subscribe. Si tratta di un sistema topic-based distribui- to. 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 wild- cards). 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.
1.4.3 SCRIBE
SCRIBE [14] è un implementazione del modello Publish-Subscribe topic-based basato su una overlay network gestita da Pastry [23]. 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.
1.4.4 TERA
TERA [24] è un’implementazione del modello Publish-Subscribe topic-based ba- sato su overlay. La novità interessante che introduce questo lavoro è un mec- canismo 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. Il meccanismo di interest clustering è ba- sato 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 da- ti 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 fi- no 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. 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 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.
1.4.5 Elvin
Elvin [21, 25] è un prototipo avanzato di sistema Publish-Subscribe content- based. La sua caratteristica principale è un meccanismo, chiamato di quen- ching,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 rap- presentazione 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.
1.4.6 Gryphon
Gryphon [26] è 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 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.
1.4.7 SIENA
Siena [12, 27] è un ENS distribuito con content-based routing. La grande novità introdotta da Siena consiste in un meccanismo, chiamato di “covering delle sotto- scrizioni” 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 pubblica- zioni” tramite cui i publisher possono annunciare in anticipo il tipo di eventi che intendono pubblicare sulla rete. Queste due caratteristiche permettono di “taglia- re” parti della rete che costituisce l’ENS (che deve avere obbligatoriamente una topologia aciclica) dalla propagazione di certi eventi in quanto, le informazioni ot- tenute 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.
1.4.8 Jedi
JEDI [28] è un’implementazione del modello Publish-Subscribe con content-based routing sviluppata presso il Politecnico di Milano. 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.
1.4.9 Ermes
Hermes offre un’architettura molto simile a quella già vista con SCRIBE; si trat- ta quindi di un ENS distribuito sviluppato su un’infrastruttura offerta da una overlay network [23, 29, 30] 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.
1.4.10 REBECA
REBECA [31] è 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.
Web-Service Notification
2.1 Panoramica sui Web Services
Secondo la definizione data dal World Wide Web Consortium (W3C) un Web Service (servizio web) è un sistema software progettato per supportare l’intero- perabilità tra diversi elaboratori su di una medesima rete. Esso ha un’interfaccia descritta in un formato elaborabile da una macchina. Altri sistemi possono inte- ragire con il Web Service attivando le operazioni descritte nell’ interfaccia tramite appositi messaggi SOAP, tipicamente trasportati attraverso il protocollo HTTP, utilizzando una serializzazione XML in aggiunta ad altri standards relativi al Web [17]. L’architettura di funzionamento dei Web Service è nota con il nome di SOA (Service Oriented Architecture).
2.1.1 Architettura SOA
Service Oriented Architecture (SOA) è un’architettura software, atta a supportare l’uso di servizi, per soddisfare le richieste degli utenti, così da consentire l’utilizzo
delle singole applicazioni come componenti del processo di business. Focalizzando l’attenzione sul concetto di servizio, è ovvio immaginare come gli attori in causa siano necessariamente il fornitore e il richiedente. Questo tipo di paradigma è il medesimo che si riscontra nella tipica interazione di tipo client-server. Attraverso SOA, questa interazione viene arricchita con un ulteriore attore detto Service Directory o Broker che si inserisce, all’interno della comunicazione, tra fornitore e fruitore del servizio.
Service Provider: chi realizza e mette a disposizione il servizio. Tramite l’operazione di REGISTER il servizio viene pubblicizzato e memorizzato in un registry accessibile pubblicamente. Il Service Provider rimane quindi in attesa che un utente richieda il servizio.
Service Directory: si occupa della gestione del registry, permettendo di ricercare un servizio sulla base delle caratteristiche con le quali è stato definito e memorizzato.
Service Consumer: utente che richiede il servizio. Tramite l’operazione FIND l’utente interagisce con il Broker per ottenere il servizio. Individuato il servizio, si collega, tramite BIND, al corrispondente Service provider. Infine, tramite INVOKE, inizia ad usufruire del servizio. SOA definisce, dunque, chi fa che cosa all’interno di una serie di interazioni dove il servizio ricopre il ruolo principale. I tre componenti dell’architettura SOA, possono utilizzare piattaforme tecnologiche differenti, ma il canale trasmissivo deve essere lo stesso.
Figura 2.1: Architettura SOA
2.1.2 Pila dei Protocolli
Dopo aver analizzato l’architettura che sta alla base del funzionamento dei Web Services è interessante osservare i protocolli e le tecnologie utilizzate per eseguire le tre operazioni: REGISTER,BIND,FIND.
Alla base dello stack protocollare c’è il Transport layer che è responsabile dello scambio di messaggi XML tra le applicazioni. Il protocollo di trasporto maggior- mente usato è il protocollo HTTP. Altri protocolli web comunemente utilizzati sono SMTP e FTP.
Figura 2.2: Pila Protocolli Web Services
Ad livello superiore si trova XML-based messaging, dove viene costruito il mes- saggio, cioè l’unità di dati scambiata; questo è basato sull’utilizzo di XML. Il protocollo utilizzato per lo scambio di messaggi è SOAP (Simple Object Access Protocol). Il livello successivo di service description si occupa della descrizione dei servizi, utilizzando WSDL come standard. Infine nel livello superiore di service discovery si trovano ulteriori documenti atti a descrivere il contesto e la qualità del servizio; per questa attività, lo standard è UDDI.
• Protocollo SOAP: si tratta di un protocollo semplice, basato su XML, per lo scambio d’informazioni in un ambiente distribuito.Il suo compito prin- cipale è quello di garantire l’interoperabilità tra sistemi diversi che cercano di dialogare in ambienti disomogenei dal punto di vista software e hardware [19]. Questo standard permette di eseguire chiamate di procedure remo- te (RPC: Remote Procedure Call,tecnologia attraverso la quale sono stati realizzati i primi sistemi distribuiti.) o l’invio di messaggi XML attraverso il protocollo HTTP. La struttura del messaggio SOAP comprende i seguenti elementi:
1. Envelope, identifica il documento come un messaggio SOAP;
2. Un elemento Header opzionale, contenente informazioni specifiche per l’applicazione, che permette di definire alcuni messaggi, anche con diversi destinatari nel caso il messaggio dovesse attraversare più punti di arrivo;
3. Body è un elemento indispensabile che contiene il contenuto informa- tivo (payload o carico utile) scambiato dalle richieste/risposte;
4. Fault che è un elemento opzionale che fornisce informazioni riguardo ad eventuali errori manifestati durante la lettura del messaggio.
• Il registro UDDI: si tratta di un meccanismo di registrazione e consulta- zione di un archivio di servizi, pensato per la ricerca di Web Service in rete.
Si tratta quindi di una base di dati distribuita, contenente informazioni sulle aziende, suddivise per tipologia, sui servizi da queste offerti, con i dettagli tecnici sugli stessi e su come raggiungerli. UDDI fa parte di un progetto sponsorizzato dall’OASIS ( Organization for the Advancement of Structu- red Information Standards, un consorzio internazionale per lo sviluppo e l’adozione di standard nel campo dell’e-business e dei Web), volto a creare una tecnologia standard per consentire alle aziende e alle applicazioni di trovare e utilizzare i Web Service in modo rapido, semplice e dinamico.
Una registrazione UDDI consiste, di tre diverse componenti:
1. Pagine bianche (White Pages): indirizzo, contatti (dell’azienda che offre uno o più servizi) e identificativi;
2. Pagine gialle (Yellow Pages): categorizzazione dei servizi basata su tassonomie standardizzate;
3. Pagine verdi (Green Pages): informazioni (tecniche) dei servizi fornite dall’azienda;
L’UDDI è uno degli standard alla base del funzionamento dei Web Service:
è stato progettato per essere interrogato da messaggi in SOAP e per fornire il collegamento ai documenti WSDL che descrivono i vincoli protocollari ed
i formati dei messaggi necessari per l’interazione con i Web Service elencati nella propria directory.
• Web Services Description Language (WSDL): è un linguaggio for- male in formato XML utilizzato per la creazione di documenti per la de- scrizione di Web Service. Mediante WSDL può essere, infatti, descritta l’interfaccia pubblica di un Web Service ovvero creata una descrizione, basata su XML, di come interagire con un determinato servizio: un do- cumento WSDL contiene infatti, relativamente al Web Service descritto, informazioni su:
1. cosa puo‘ essere utilizzato (le operazioni messe a disposizione dal servizio);
2. come utilizzarlo (il protocollo di comunicazione da utilizzare per acce- dere al servizio, il formato dei messaggi accettati in input e restituiti in output dal servizio ed i dati correlati) ovvero i vincoli (bindings in inglese) del servizio;
3. dove utilizzare il servizio (cosiddetto endpoint del servizio che solita- mente corrisponde all’indirizzo in formato URI che rende disponibile il Web Service);
Le operazioni supportate dal Web Service ed i messaggi che è possibile scambiare con lo stesso sono descritti in maniera astratta e quindi collegati ad uno specifico protocollo di rete e ad uno specifico formato. Il WSDL è solitamente utilizzato in combinazione con SOAP e XML Schema per ren- dere disponibili Web Services su reti aziendali o su internet: un programma
client può, infatti, leggere il documento WSDL relativo ad un Web Service per determinare quali siano le funzioni messe a disposizione sul server e quindi utilizzare il protocollo SOAP per utilizzare una o piùdelle funzioni elencate dal WSDL. La versione 2.0 di WSDL è stata promossa a standard ufficiale (in forma di raccomandazione) dal W3C.
2.1.3 Vantaggi dei Web Services
La ragione principale per la creazione e l’utilizzo di Web services è il disaccoppia- mento che l’interfaccia standard, esposta dal Web Service, rende possibile fra il sistema utente ed il Web Service stesso. Per cui, modifiche di applicazioni pos- sono essere attuate in maniera trasparente. Tale flessibilità consente la creazione di sistemi software complessi, costituiti da componenti svincolati l’uno dall’al- tro e consente una forte riusabilità di codice e di applicazioni già sviluppate. In particolare, i vantaggi principali dei Web services sono i seguenti:
• Permettono l’interoperabilità tra diverse applicazioni software, su diverse piattaforme hardware.
• Utilizzano standard e protocolli open; i protocolli ed il formato dei dati è, ove possibile, in formato testuale, ciò li rende di più facile comprensione ed utilizzo da parte degli sviluppatori.
• Mediante l’uso di HTTP, per il trasporto dei messaggi, i Web services non necessitano, normalmente, che vengano effettuate modifiche alle regole di sicurezza come filtro sui firewall.
• Possono essere facilmente utilizzati in combinazione l’uno con l’altro (in- dipendentemente da chi li fornisce e da dove vengono resi disponibili) per formare servizi integrati e complessi.
• Consentono il riutilizzo di infrastrutture e di applicazioni già sviluppate
• Sono indipendenti dai sistemi operativi e dai linguaggi di programmazione.
2.2 Specifiche WS che supportano il paradig-
ma Publish/Subscribe
Attualmente per i web-services esistono varie specifiche in grado di supportare scenari di tipo publish/subscribe come quello appena descritto. In particolare, verranno, in seguito, analizzate singolarmente e poi messe a confronto tra loro tre differenti specifiche:
• WS-Events
• WS-Eventing
• WS-Notification
2.2.1 WS-Events
WS-Events[5] definisce un evento come un cambiamento nello stato di una ri- sorsa. Ciascun evento può esser rappresentato mediante un elemento XML denominato notification. La specifica WS-Events individua due categorie di attori:
• Event Producer
• Event Consumer
Un Event Producer è un’entità in grado di generare notifiche di eventi. In par- ticolare, può emettere più notifiche di evento, che possono essere ricevute o recuperate da uno o più Event Consumer. Con il termine Event Consumer, ci si riferisce all’insieme dei destinatari dei messaggi di notifica generati da un Event Producer. Al fine di garantire una corretta implementazione del pattern publish/subscribe, W-SEvents standardizza i meccanismi per effettuare le ope- razioni di Discovery e Sottoscrizione di eventi. In particolare, la specifica non definisce in che maniera i consumers possono venire a conoscenza dell’esistenza di servizi in grado di pubblicare eventi. Partendo da questo presupposto, la fase di discovery consiste soltanto in una serie di interrogazioni dirette dal consumer al producer, il cui scopo è quello di ottenere informazioni sui tipi di evento a cui è possibile sottoscriversi. Tale specifica offre, inoltre, un supporto sia per la comunicazione sincrona che asincrona. In modalità sincrona, il produttore di notifiche di evento richiama un metodo (callback) sul consumatore di eventi, passando come parametri una o più notifiche. In modalità asincrona, spetta al consumatore stesso invocare metodi dell’interfaccia del produttore, necessari al recupero dei notification messages, che nel contempo sono stati generati. In tal caso, il produttore avrà, implicitamente, l’obbligo di mantenere, di volta in volta, in memoria, i messaggi non ancora osservati. WS-Events non definisce un meccanismo ad eventi general-purpose. Esso, infatti, rappresenta solo uno dei possibili meccanismi publish/subscribe utilizzabili per il mondo dei Web Services.
Inoltre, WS-Events si inserisce all’interno dell’esistente Web Service Framework e,
pertanto, richiede necessariamente l’utilizzo di specifiche, quali WSDL e SOAP, per il suo corretto funzionamento. Nonostante il ruolo dell’intermediario (broker) abbia molta importanza nei sistemi ad eventi, l’attuale versione della specifica non definisce un protocollo di interazione con servizi che fungano da broker. WS- Events consente, inoltre, la definizione di particolari tipi di evento, da utilizzare nel caso in cui si verifichino delle modifiche alla lista delle event definitions di un producer. I tipi di evento supportati da un Event Producer possono esse- re, infatti, aggiunti, modificati ed eliminati a runtime. Ogni volta che avviene una modifica alla lista delle event definitions, tutti i consumers, già sottoscritti, vengono notificati del cambiamento avvenuto.
2.2.2 WS-Eventing
WS-Eventing[18] definisce un evento come un cambiamento nello stato di una risorsa. La specifica WS-Eventing identifica tre possibili ruoli:
• Subscriber
• Event Source
• Subscription Manager
Il Subscriber è un Web Service, che intende ricevere messaggi di notifica di eventi.
Per poter raggiungere questo obiettivo, il subscriber registra il proprio interesse presso un altro Web Service, chiamato Event Source. Scopo dell’event source, è quello di accettare richieste di sottoscrizione da parte dei subscribers. Un event source, normalmente, delega la gestione delle singole sottoscrizioni ad un
subscription manager. Facendo riferimento al documento ufficiale della specifica [18], si evince che gli obiettivi principali di WS-Eventing sono i seguenti:
• Definire una tecnica per poter creare ed eliminare sottoscrizioni a tipi di evento.
• Garantire che le sottoscrizioni abbiano una validità limitata nel tempo e che possano essere rinnovate.
• Definire come un Web Service possa sottoscriversi presso un event source.
• Definire come un event source possa delegare il compito di gestione delle sottoscrizioni ad un subscription manager.
WS-Eventing non definisce un meccanismo ad eventi general-purpose. Esso, in- fatti, rappresenta solo uno dei possibili meccanismi publish/subscribe utilizzabili per il mondo dei Web Services. Inoltre, WS-Eventing si inserisce all’interno dell’e- sistente Web Service Framework e, pertanto, richiede necessariamente l’utilizzo di specifiche, quali WSDL, SOAP e WS-Addressing, per il suo corretto funzio- namento. Non è tra gli obiettivi di WS-Eventing, quello di definire in che modo i subscribers possano venire a conoscenza dell’esistenza di potenziali event sour- ce. Lo scenario di funzionamento proposto dalla specifica WS-Eventing è molto simile a quello di WS-Notification. La principale differenza consiste nel fatto che WS-Eventing non prevede la presenza di brokers in fase di discovery, né in fase di sottoscrizione. Il subscriber ha un comportamento identico a quello dell’event consumer, definito nella specifica WS-Events.
2.2.3 WS-Notification
WS-Notification [9] definisce un evento come un cambiamento nello stato di una risorsa. Ogni evento può essere visto come una specifica istanza di un topic. Un topic rappresenta una categoria ben precisa di eventi a cui potersi sottoscrivere.
Facendo un paragone con l’object oriented progamming, un topic è molto simile ad una classe, esso è infatti provvisto di proprietà e metodi tramite i quali è possibile accedere al proprio stato interno, dunque un topic è una vera e propria risorsa ispezionabile. WS-Notification consente la definizione di gerarchie di topic allo stesso modo con cui è possibile definire gerarchie di classi nei linguaggi object oriented. WS-Notification distingue ben cinque possibili attori di sistema:
• Producer
• Consumer
• Subscriber
• Subscription Manager
• Broker
Un Producer, detto anche Notification Producer, ha il compito principale di accettare richieste di sottoscrizione da parte di un Consumer (i.e. Notification Consumer). Ogni richiesta di sottoscrizione identifica uno o più topics di interesse ed un consumer. In assenza di un broker, il producer ha l’obbligo di mantenere una lista di sottoscrizioni. Ogni volta che è necessario inoltrare una notifica, il producer confronta le informazioni contenute nella notifica con quelle delle varie sottoscrizioni a lui conosciute. Lo scopo è quello di inoltrare le notifiche
di evento ai consumers giusti. Un producer può delegare il compito di gestione delle notifiche ad uno specifico Subscription Manager, così come un consumer può delegare ad uno specifico subscriber il compito di portare avanti la trattativa di sottoscrizione con il producer. Infine, con il termine Broker ci si riferisce ad un intermediario il cui compito è quello di porsi tra il producer e il consumer.
Il broker è responsabile della gestione delle sottoscrizioni e dell’instradamento delle notifiche ai vari consumers. In definitiva, si può dire che l’obiettivo di WS-Notification è quello di definire:
• I ruoli
• La terminologia ed i concetti espressi nel modello.
• Uno standard per lo scambio dei messaggi.
• Un linguaggio per la descrizione dei topics.
WS-Notification, similmente a WS-Events, non definisce un meccanismo ad even- ti general-purpose. Si inserisce all’interno dell’esistente Web Service Framework, e pertanto richiede necessariamente l’utilizzo di specifiche, quali WSDL e SOAP per il suo corretto funzionamento. Non è tra gli obiettivi di WS-Notification, quel- lo di definire in che modo consumers e producers possano venire a conoscenza della presenza di potenziali producers.
2.2.4 Confronto fra le Specifiche
Come mostrato in Figura 2.3, ciascuna specifica estende specifiche web esistenti.
In particolare, WS-Notification richiede, per il suo funzionamento, che vengano implementate numerose altre specifiche, a differenza di come accade nel caso di
WS-Events e WS-Eventing. Un forte limite di WS-Events e WS-Eventing, è quel- lo di non riuscire a modellare scenari che consentano ai servizi di interagire con degli intermediari. Esclusa WS-Notification, non viene, infatti, mai standardiz- zato il ruolo del broker. Nessuna delle tre specifiche ha, nei suoi obiettivi, quello di garantire affidabilità nello scambio dei messaggi. Un messaggio potrebbe, ad esempio, andare perso e potrebbe non raggiungere mai il destinatario. Nonostan- te WS-Events, WS-Eventing e WS-Notification si somiglino molto, quest’ultima offre in generale maggiore espressività. Una differenza significativa tra le tre spe- cifiche risiede nel modo con cui ciascuna permette di definire categorie di eventi (topics). In particolare WS-Notification è l’unica specifica in grado di fornire un sistema di definizione dei tipi di evento basato sul concetto di topic.
2.2.5 Scenari di funzionamento di WS-Notification
WS-Notification è una famiglia di specifiche per Web services, che definisce un approccio di tipo Publish/Subscribe alla notifica di eventi. In particolare, ogni evento può essere visto come specifica istanza di un topic. Un topic rappresenta una categoria ben precisa di eventi a cui potersi sottoscrivere. Un topic, dunque, è una risorsa accessibile esternamente, avente una propria struttura dati interna.
Ricordiamo che le entità principali di un sistema, basato su WS-Notification sono cinque:
• Notification Producer
• Notification Consumer
• Subscriber
Figura 2.3: Confronto fra le specifiche
• Subscription Manager
• Notification Broker
Quando si fa riferimento a WS-Notification, si distingue tra tre differenti speci- fiche:
• WS-BaseNotification
• WS-BrokerNotification
• WS-Topic
WS-BaseNotification [6] standardizza gli scambi e le interfacce tra produttore e consumatore di notifiche. WS-BrokeredNotification [7] definisce l’interfaccia
web-service dei notification brokers, specifica, dunque, il ruolo del broker. WS- Topics [11] definisce, invece, un meccanismo per organizzare e categorizzare gli elementi di interesse per la sottoscrizione, ovvero i topics. La specifica prevede due scenari di funzionamento:
• In presenza di Broker
• In assenza di Broker
Scenario di Funzionamento in Assenza di Broker
Nel caso di funzionamento in assenza di broker, le entità coinvolte nella fase di discovery sono solo due: il producer e il subscriber. Responsabile di questa operazione è, generalmente, il subscriber stesso. Una volta individuati dei possibili topics di interesse, si passa alla fase di sottoscrizione, in cui il subscriber inoltra al producer la relativa richiesta. Tale richiesta conterrà informazioni riguardanti i topics, per cui si richiede la sottoscrizione e il consumer a cui dovranno essere inoltrate le notifiche di eventi. Una volta portata a termine con successo la fase di sottoscrizione, il producer genera la risorsa di sottoscrizione, la memorizza all’interno della lista di sottoscrizioni e delega ad un subscription manager il compito di gestire la specifica sottoscrizione. A questo punto, il producer avrà l’obbligo di inoltrare ai consumer sottoscritti i corretti messaggi di notifica. Il consumer potrà ricevere notifiche dal publisher ed inoltre, potrà interagire con il subscription manager al fine di modificare lo stato della risorsa sottoscrizione.
E’ da sottolineare il fatto che nulla vieta al consumer di svolgere anche il ruolo di subscriber, così come nulla vieta al producer di incaricarsi della gestione delle singole sottoscrizioni.
Figura 2.4: Scenario senza Broker
Subscribe Un NotificationProducer è in grado di produrre una sequenza di messaggi di notifica. Un Subscriber può registrare l’interesse di un Notification- Consumer di ricevere un sottoinsieme di questa sequenza. Un Subscriber invia, dunque, un messaggio di subscribe per registrare tale interesse. Se il messag- gio di sottoscrizione ha successo, allora il NotificationProducer deve produrre un messaggio di response ed inviarlo al subscriber.
Figura 2.5: Operazione di Subscribe
GetCurrentMessage In risposta al messaggio GetCurrentMessage, il No- tificationProducer deve ritornare l’ultima notifica pubblicata del topic dato. La funzione principale è informare un consumer appena iscritto, dell’ultimo even- to occorso. In alcune circostanze, un NotificationProducer può scegliere di non memorizzare l’ultima Notifica per uno o più Topics. In tal caso, il Notification- Producer risponderà con un fault message, indicando che non vi sono ultime notifiche per il topic dato.
RenewSubscription Per modificare il tempo di vita della sottoscrizione, il richiedente deve inviare un messaggio di RenewSubscriptionRequest al Subscrip- tionManager. Se il SubscriptionManager processa con successo il messaggio di RenewSubscriptionRequest, allora dovrà rispondere con un messaggio di Renew- SubscriptionResponse. Se, al contrario, l’elaborazione non dovesse andare a buon fine, verrà ritornato un fault message.
Figura 2.6: Operazione di Renew
Unsubscription Per terminare la sottoscrizione, un richiedente deve inviare un messaggio di UnsubscribeRequest al SubscriptionManager. In seguito ad una
richiesta di annullamento della sottoscrizione, il SubscriptionManager deve ten- tare di distruggere la risorsa Sottoscrizione. Se il SubscriptionManager gestisce con successo il messaggio di UnsubscribeRequest, allora dovrà rispondere con unmessaggio di UnsubscribeResponse.
Figura 2.7: Operazione di Unsubscribe
PauseSubscription Per sospendere temporaneamente la produzione di mes- saggi di notifica per una particolare Sottoscrizione, il richiedente deve inviare un messaggio di PauseSubscriptioRequest al SubscriptionManager. In risposta ad un messag gio di richiesta di pausa della Sottoscrizione, il SubscriptionManager dovrà rispondere con un messaggio di PauseSubscriptionResponse.
ResumeSubscription e un richiedente desidera riprendere la produzione dei messaggi di notifica, deve inviare un messaggio di ResumeSubscriptionRequest.
In risposta a tale messaggio, il SubscriptionManager dovrà inviarne uno di Resu- meSubscrip tionResponse. Se l’elaborazione non dovesse andare a buon fine, il messaggio di ritorno sarà un messaggio di fault message.
Figura 2.8: Operazione di Pause
Figura 2.9: Operazione di Resume
Notify In seguito al verificarsi di un evento, il NotificationProducer dovrà produrre messaggi di notifica. Non è richiesta alcuna risposta da parte del NotificationConsumer, in seguito alla ricezione di questo messaggio.
Scenario di Funzionamento in Presenza di Broker
Nel caso di funzionamento in presenza di broker, le entità coinvolte nella fase di discovery sono il Subscriber ed il Notification Broker. Il Publisher delega, infatti, al Broker il compito di mantenere le informazioni sui topics.
Una volta individuati dei possibili topics di interesse, il Subscriber può passare alla
Figura 2.10: Operazione di Notify
fase di sottoscrizione. Anche questa fase ha come protagonisti il Subscriber ed il Notification Broker. Il Subscriber, infatti, effettuerà la richiesta di sottoscrizione presso il Broker e non pià presso il Publisher. Spetterà, dunque, al Broker mante- nere memorizzata una lista di sottoscrizioni. Il Publisher, preliminarmente, deve aver contattato il Broker, mediante il metodo RegisterPublisher dell’interfaccia del Broker, dichiarando di essere disposto a pubblicare notifiche di eventi relativi a specifici topics. Una volta registratosi presso il Broker, il Publisher invierà le notifiche degli eventi che verranno prodotti soltanto al Broker presso cui è regi- strato. Il Broker sarà, quindi, in grado di capire verso quali Consumers dirigere le notifiche di evento, poichè manterrà la lista di tutte le sottoscrizioni. La presenza del Broker non modifica la semantica comportamentale del SubscriptionManager.
Infatti, una volta effettuata la sottoscrizione, è possibile accedere alla rispetti- va risorsa, mediante i metodi PauseSubscription e ResumeSubscription, messi a disposizione dall’interfaccia del SubscriptionManager.
Lo scenario di funzionamento in presenza di broker, permette di diminuire, con- siderevolmente, l’overhead dovuto alla necessità di spedire notifiche a ciascuno dei singoli consumer della rete. Il publisher dovrà, infatti, comunicare la notifica
Figura 2.11: Scenario con Broker
soltanto ai brokers presso cui è registrato. Secondo le specifiche WS-Notification, un NotificationBroker è rappresentato da un’interfaccia che deve estendere sia l’interfaccia rappresentante il NotificationConsumer, sia quella rappresentante il NotificationProducer. Questo risulta quindi essere un esempio di ereditarietà multipla, in cui una singola interfaccia estende più interfacce, in tal modo l’inter- faccia NotificationBroker erediterà i metodi presenti in entrambe le interfacce di livello superiore. In pratica, un NotificationBroker risulta essere, contemporanea- mente, sia un NotificationConumer che un NotificationProducer, e questo avviene in quanto esso è tenuto a eseguire i metodi propri di un NotificationConsumer mentre comunica con un NotificationProducer ed ad eseguire i metodi propri di un Notification Producer mentre comunica con un NotificationConsumer.
Sono, di seguito, rappresentati i diagrammi di sequenza, relativi alle singole ope- razioni svolte dagli attori del sistema, nel caso di funzionamento in presenza di broker.
RegisterPublisher Il messaggio RegisterPublisher è utilizzato dal Publisher
Figura 2.12: Interfaccia Broker
per confermare la sua capacità di pubblicare un dato topic, oppure un insieme di topics. Se un’entità desidera registrare un Publisher, deve inviare un mes- saggio di richiesta di RegisterPublisher al NotificationBroker. Se quest’ultimo accetta il messaggio di richiesta, allora dovrà rispondere con un messaggio di RegisterPublisherResponse. Il NotificationBroker delega ad un PublisherRegistra tionManager la gestione delle risorse PublisherRegistration.
Figura 2.13: Operazione Register Publisher
Subscribe Un Subscriber invia un messaggio di SubscribeRequest, per regi-
strare l’interesse a ricevere una sequenza di messaggi di notifica, direttamente al NotificationBroker e non più al NotificationProducer. Se l’operazione va a buon fine, il NotificationBroker restituirà un messaggio di SubscribeResponse, dopo aver aggiornato la lista delle sottoscrizioni.
GetCurrentMessage Un Subscriber invia un messaggio di GetCurrentMes- sageRequest al NotificationBroker, per ricevere l’ultima notifica del topic dato.
Se l’operazione va a buon fine, il NotificationBroker restituirà un messaggio di GetCurrentMessageResponse.
RenewSubscription Per modificare il tempo di vita della sottoscrizione, un Subscriber invia un messaggio di RenewSubscriptionRequest al Notification- Broker. Se l’operazione va a buon fine, quest’ultimo restituirà un messaggio di RenewSub scriptionResponse.
Unsubscribe Per terminare la sottoscrizione, un Subscriber invia un mes- saggio di UnsubscribeRequest al NotificationBroker. Quest’ultimo aggiornerà la sua lista di sottoscrizioni.
PauseSubscription Per sospendere temporaneamente la sottoscrizione, il Subscriber invia un messaggio di PauseSubscriptionRequest al NotificationBro- ker. Se l’operazione va a buon fine, quest’ultimo invierà un messaggio di Pause- SubscriptionResponse.
ResumeSubscription Per riprendere la produzione dei messaggi di notifi- ca, il Subscriber invia un messaggio di ResumeSubscriptionRequest al Notifica- tionBroker. Se l’operazione va a buon fine, quest’ultimo invierà un messaggio ResumeSubscriptionResponse.
Destroy Se un Publisher decide di non pubblicare più determinati topics, allo- ra invierà un messaggio di DestroyRequest al PublisherRegistrationManager. Se l’operazione ha successo, quest’ultimo invierà un messaggio di DestroyResponse.
Figura 2.14: Operazione di Destroy
Notify All’occorrenza di un nuovo evento, un Publisher manderà una no- tifica al NotificationBroker. Alla ricezione di un messaggio di Notify, il No- tificationBroker inoltrerà la notifica ai Subscribers interessati al determinato topic.
Figura 2.15: Operazione di Notify
Confronto fra Scenari
Lo scenario di funzionamento in assenza di Broker e lo scenario di funzionamento in presenza di Broker costituiscono, rispettivamente, una comunicazione diretta e una comunicazione indiretta tra i partecipanti. In particolare, lo scenario di funzionamento in presenza di broker, pur aumentando la complessità del siste- ma, permette di diminuire, considerevolmente, l’overhead dovuto alla necessità di spedire notifiche a ciascuno dei singoli consumers della rete, aumentando, così, il livello di scalabilità. La presenza del Broker aumenta, inoltre, il livello di disac- coppiamento tra le parti comunicanti, che non necessitano di avere riferimenti l’una dell’altra.
2.3 Il framework Apache Muse
Il progetto Apache Muse [1] è un’implementazione Java delle specifiche:
• WS-ResourceFramework(WSRF) [10]
• WS-BaseNotification(WSN)[6]
• WS-DistributedManagement(WSDM) [8]
e rappresenta la soluzione scelta in questo contesto per analizzare una possibile implementazione della WS-BaseNotification introdotta in precedenza. Lo sce- nario che vedremo comunque si basa solo sullo standard WS-BaseNotification:
rappresenta un’esempio di come è possibile esporre via Web Service delle resour- ces(producer e consumer) che comunicano attraverso lo scambio di messaggi (subscribe,unsubscribe..su protocollo SOAP) utilizzando gli standard WSN,WSRF e WSDM.
Brevemente:
il WS-ResourceFramework consiste in un insieme di specifiche che definiscono un pattern per lo scambio di messaggi per interrogare le proprietà delle risorse stateful e per stabilire come queste possono essere modificate:
• WS-ResourceLifetime
• WS-ResourceProperties
• WS-RenewableReferences
• WS-ServiceGroup
• WS-BaseFaults
Le specifiche definiscono sia i metodi per l’associazione tra Web service e stateful resource sia le modalità di creazione, accesso, monitoraggio e distruzione di una WS-Resource. Lo scopo del WS-RF è quello di definire come queste operazioni devono essere specificate all’interno del WSDL (Web Services Description Lan- guage) che descrive il servizio. Un Web Service viene quindi definito come un servizio che espone le proprietà di una resource tramite WS-RF.
Il WS-DistributedManagment è uno standard che consente la gestione delle applicazioni costruite usando Web Services, permettendo alle risorse di essere controllate da diversi gestori attraverso una singola interfaccia. Il WSDM in realtà è formato da due specifiche, Management Using Web Services (MUWS) e Management Of Web Services (MOWS). MUWS definisce come rappresentare ed accedere alle interfacce di gestione delle risorse come Web Services; definisce un insieme base di capacità di gestione, come l’identificazione di una risorsa, la
metrica, la configurazione e le relazioni con le altre risorse. Il MOWS definisce invece come gestire Web Services come risorse e come descrivere ed accedere alle funzionalità di gestione usando MUWS. La specifica utilizza alcuni SOAP Header proprietari e altri adottati da specifiche preesistenti, come WS-Addressing per instradare i messaggi e dichiarare per esempio il destinatario (To), il contesto di dialogo (MessageID e RelatesTo),a chi rispondere (ReplyTo) e a chi inviare eventuali errori (Fault To), oltre ovviamente all’oggetto del messaggio SOAP (Action).
Le operazioni codificate da WS-Management, con le relative action:
• Get e GetResponse
• Put e PutResponse
• Create e CreateResponse
• Delete e DeleteResponse
• Rename e RenameResponse
• Enumerate ed EnumerateResponse
• Pull e PullResponse
• Renew e RenewResponse
• GetStatus e GetStatusResponse
• Release e ReleaseResponse
• EnumerationEnd
• Subscribe e SubscribeResponse
• Renew e RenewResponse
• GetStatus e GetStatusResponse
• Unsubscribe e UnsubscribeResponse
• SubscriptionEnd
• Events
• Heartbeat
• DroppedEvents
• Ack
• Event
Queste operazioni consentono di costruire dialoghi o comunicazioni tra un client e un servizio che espone le risorse di un sistema, per monitorarne lo stato, per leggerne, scriverne o modificarne delle informazioni, per abbonarsi a degli eventi di notifica, eventualmente resi sequenziali dalla possibilità di inviare un Ack di conferma ricezione, prima dell’invio di eventuali ulteriori eventi. La specifica prevede inoltre la possibilità di inviare (tramite il SOAP Header Options) una serie di parametri (options) al sistema, per argomentare l’oggetto della richiesta inviatagli.
Apache Muse può essere quindi definito come un framework che attraverso la definizione di intefacce ed implementazioni di capability WSRF,WSN e WSDM permette sia di costruire interfacce Web Services per la gestione di resource che
