Progettazione e sviluppo di un servizio di notifica Publish/Subscribe di tipo Content-Based con applicazione al Grid Monitoring

1. Il modello Publish/Subscribe 5
Fig. 1.1-1: Modello publish/subscribe 
Le sottoscrizioni restano memorizzate nell event service e non vengono inoltrate ai 
publisher. Per eliminare una sottoscrizione, il subscriber ha a disposizione la funzione 
unsubscribe(). 
Per generare un evento, un publisher ha a disposizione l operazione notify() (talvolta 
denominata publish()). L event service propaga l evento a tutti i subscriber interessati
1
. 
Talvolta l event service mette a disposizione dei publisher una funzione (advertise()), in 
modo che questi possano annunciare, all event service stesso, la natura degli eventi che 
produrranno. Queste informazioni aggiuntive possono essere utili sia all event service, per 
ottimizzare la gestione del flusso di informazioni, sia ai subscriber, per apprendere quando 
un nuovo tipo di informazione diventa disponibile. L operazione opposta all advertise() Ł 
unadvertise(). 
                                               
1
 Se l evento Ł compatibile con la sottoscrizione di un subscriber, questo viene notificato. 
1. Il modello Publish/Subscribe 6
1.2 Propriet  del modello 
Il punto di forza di questo modello Ł il disaccoppiamento (decoupling) che l’event 
service crea tra publisher e subscriber. Questa propriet  si esplica su tre livelli: quello 
spaziale, quello temporale e della sincronizzazione, come di seguito riportato: 

 Space decoupling: i publisher e i subscriber non hanno necessit  di conoscersi 
a vicenda. I publisher pubblicano eventi attraverso l event service e i subscriber 
li ricevono da quest ultimo. I publisher non mantengono un riferimento ai 
subscriber, nØ sanno quanti subscriber sono presenti nel sistema. Lo stesso vale 
per i subscriber. (Fig. 1.2-1). 
Fig. 1.2-1: Space decoupling. 

 Time decoupling: non occorre che le parti che interagiscono (publisher e 
subscriber) siano attive nello stesso momento. Ad esempio, un publisher pu  
pubblicare eventi, ma il subscriber interessato potrebbe non essere connesso; 
viceversa, un subscriber pu  ricevere notifica per un evento prodotto da un 
publisher che al momento risulta disconnesso (Fig. 1.2-2). 
Fig. 1.2-2: Time decoupling. 
1. Il modello Publish/Subscribe 7

 Synchronization decoupling: non esiste sincronizzazione tra publisher e 
subscriber, quindi 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 dell’event service
quando l’evento a cui sono interessati Ł disponibile. (Fig. 1.2-3). 
Fig. 1.2-3: Synchronization decoupling 
Space, time e synchronization decoupling tra produttori (publisher) e consumatori 
(subscriber) di informazioni (eventi) eliminano le dipendenze tra i partecipanti 
all’interazione, rendendo il modello estremamente flessibile. 
1.3 I diversi schemi del modello 
I subscriber, in generale, sono interessati solo ad un sottoinsieme di eventi prodotti dai 
publisher. I diversi modi di specificare gli eventi di interesse ha condotto a differenti 
schemi di sottoscrizione. Qui di seguito vengono illustrati tre schemi: il topic-based, il 
content-based ed il type-based (poco utilizzato rispetto agli altri due).  
1.3.1 Topic-based publish/subscribe 
E  lo schema publish/subscribe piø datato e si basa sulla nozione di topic (o subject). I 
partecipanti all’interazione possono pubblicare determinati eventi e sottoscriversi a 
1. Il modello Publish/Subscribe 8
specifici topic, identificati da una keyword. Un topic Ł molto simile alla nozione di 
 gruppo , quindi la sottoscrizione ad un topic T pu  essere vista come il divenire membro 
del gruppo T. Inoltre, la pubblicazione di un evento nell ambito del topic T si traduce in un 
broadcast a tutti i membri del gruppo.  
Fig. 1.3-1: Topic- based publish/subscribe. (a) Struttura gerarchica dei topic. (b) Struttura di un evento. 
Ciascun topic rappresenta, dunque, un differente canale di comunicazione e pu  essere 
visto come un event service di per sØ  stesso, identificato da un nome univoco. In realt  
esiste un unico event service, che mantiene la gerarchia dei topic al suo interno. Per gestire 
i subject vengono utilizzati diversi schemi; il piø diffuso Ł quello  gerarchico  (Fig. 
1.3-1(a)), utilizzato anche nel servizio di news USENET ([rif. 3]). In questo caso, se ci si 
sottoscrive ad un topic T, si ricever  notifica per tutti gli eventi prodotti dai publisher 
riguardanti anche i subtopic di T. 
Osservando la Fig. 1.3-1(a), se un subscriber si sottoscrive al topic  sport , ricever  
notifica anche per gli eventi riguardanti i subtopic  calcio ,  basket  e  nuoto . Se invece 
si sottoscrive al subject  news , allora ricever  notifica per qualsiasi evento, poichØ  news  
Ł la radice dell’albero dei topic. Nel modello topic-based publish/subscribe un evento si 
presenta come in Fig. 1.3-1(b): esiste un campo topic, che specifica il nome del topic a cui 
appartiene l’evento, e un campo body, che ne rappresenta il contenuto.  
1. Il modello Publish/Subscribe 9
E  possibile che in una sottoscrizione il nome del topic
1
 contenga il wildcard; ad 
esempio, se un subscriber Ł interessato ai subject  newsgroup ,  newsletter ,  newspaper  
e via dicendo, pu  semplicemente indicare il nome del topic come news*. 
In questo caso il subscriber, oltre a sottoscriversi a tutti i subject il cui nome inizia per 
 news , si sottoscriver  anche ai vari subtopic di news*, per la propriet  della struttura 
gerarchica dei subject discussa precedentemente. La Fig. 1.3-2 mostra un tipico esempio di 
modello topic-based publish/subscribe, in cui si suppone di avere un insieme di azioni 
( quote ) divise tra vari proprietari interessati a venderle ai vari acquirenti. 
Fig. 1.3-2: Topic-based publish/subscribe. (a) Semplice codice Java per subscribing. (b) Modello di 
interazione topic-based. 
Gli acquirenti (subscriber) manifestano il proprio interesse sottoscrivendosi al topic 
 /LondonStockMarket/Stock/StockQuotes ; si noti la keyword espressa con notazione 
URL. Il corpo del messaggio Ł composto da cinque attributi: un identificatore globale di 
quota  id , il nome della compagnia  company , il prezzo dell’azione  price , la quantit  
 amount  e l’identificativo del venditore dell’azione  traderId . 
Quando un venditore (publisher) desidera vendere delle stock quote lo comunicher  
all’event service, che gestisce il topic StockQuotes, passando come parametro alla funzione 
publish() un oggetto evento. Il servizio eventi memorizzer  l’evento prodotto e notificher  
gli eventuali subscriber interessati. Si noti che, in questo modello, un subscriber non pu  
assolutamente specificare informazioni di preferenza su particolari stock quote, come, ad 
                                               
1
 Il nome del topic Ł rappresentato da una keyword, di solito si utilizza la notazione URL. 
1. Il modello Publish/Subscribe 10
esempio, l’interesse per un determinato prezzo oppure per una stock quote di una 
particolare compagnia. 
I subscriber, interessati alle stock quote, saranno sempre notificati ogni volta che un 
publisher decide di vendere delle stock quote; questo comportamento mette in evidenza la 
poca flessibilit  di questo modello e come il linguaggio di sottoscrizione sia poco 
espressivo. 
1.3.2 Vantaggi e svantaggi del modello topic-based 
Il topic-based publish/subscribe Ł un modello molto robusto e semplice da realizzare. 
Non occorre dare una struttura al corpo del messaggio-evento, poichØ il matching
1
, da 
parte dell event service, avviene esclusivamente in base al campo topic. Questo approccio 
introduce basso carico computazionale poichØ, per ogni evento E, l’event service dovr  
soltanto analizzare il campo topic di E e notificare tutti i subscriber interessati. 
Il modello tuttavia Ł poco flessibile a causa del linguaggio di sottoscrizione poco 
espressivo: non Ł possibile specificare preferenze per determinati eventi, salvo che non sia 
presente un topic specifico. 
Ad esempio, osservando la Fig. 1.3-1(a), i publisher dovrebbero definire i subject
 \NEWS ,  \NEWS\SPORT ,  \NEWS\CINEMA  e via dicendo; inoltre, se si desidera 
fornire un servizio che consenta di ricevere news circa la propria squadra di calcio 
preferita, i publisher dovrebbero creare i topic  \NEWS\SPORT\CALCIO\NAPOLI , per 
la squadra Napoli, mentre  \NEWS\SPORT\CALCIO\PARMA  per il Parma, procedendo 
in questo modo per ogni squadra. 
Un altro svantaggio di questo modello Ł che i publisher devono attenersi in modo 
rigido al tipo di eventi accettati dall’event service. Quindi se il metodo publish del servizio 
eventi accetta come parametro un oggetto di tipo event, i publisher devono assolutamente 
produrre eventi che sono istanza della classe event. 
Di seguito sono mostrate delle semplicissime implementazioni in Java di un’interfaccia 
per l’event service e di una classe event, che rappresenta il tipo di eventi accettati: 
                                               
1
 Operazione attraverso la quale, dato un evento, si determina l insieme di subscriber interessati ad esso. La 
determinazione avviene comparando l evento con le sottoscrizioni espresse dai subscriber. 
1. Il modello Publish/Subscribe 11
L’esempio evidenzia come i publisher debbano attenersi alla produzione di eventi che 
siano istanza della classe event. La rigidit  introdotta sui tipi degli eventi Ł superata in 
parte dal modello type-based, descritto successivamente. 
1.3.3 Type-based publish/subscribe 
I topic, in genere, raggruppano eventi che presentano elementi comuni non solo nel 
contenuto, ma anche nella struttura. Questa osservazione ha condotto alla realizzazione di 
uno schema che filtra gli eventi in accordo al loro tipo [bib. 24]. In altre parole, la nozione 
di categoria di evento viene mappata direttamente con il  tipo  di evento. 
Gli eventi, questa volta, non vengono classificati in base al topic ma in base ai tipi, 
quindi un subscriber pu  comunicare all event service il proprio interesse verso oggetti che 
sono istanza di una particolare classe. Quando un publisher produrr  un evento  oggetto , 
interface event_service{                  
boolean publish(event ob);      
boolean advertise(event ob);    
int subscribe(String topic);       
unsubscribe(int id);          
} 
class event{
private String topic, body; 
//Costruttore parametrizzato 
event(String topic,String body){ 
this.topic=topic; 
this.body=body; 
} 
//Crea Clone 
event(event ob){ 
topic=ob.topic; 
body=ob.body; 
} 
//Costruttore standard 
event (){ 
topic=null; 
body=null; 
} 
String get_topic(){ 
return topic; 
} 
String get_body(){ 
return body; 
} 
void set_topic(String topic){ 
this.topic=topic; 
} 
void set_body(String topic){ 
this.body=body; 
} 
} 
1. Il modello Publish/Subscribe 12
lo consegner  all’event service, che determiner  la classe di cui l’oggetto Ł istanza e 
notificher , eventualmente, i subscriber interessati. La Fig. 1.3-3 mostra un semplice 
esempio di type-based publish/subscribe. 
Fig. 1.3-3: Type-based publish/subscribe. (a) Semplice codice Java per subscribing. (b) Modello di 
interazione type-based. 
La gerarchia dei tipi (Fig. 1.3-3(b)) Ł una delle caratteristiche principali di questo 
modello. La classe Stock eredita dalla classe generica Event e la specializza aggiungendo il 
nome della compagnia, il numero di quote e l’identificativo del venditore. Le classi 
StockQuote e StockRequest, ereditano entrambe dalla classe Stock e la specializzano 
aggiungendo, rispettivamente, il prezzo della quota e il range dei possibili prezzi; gli stock 
event sono, quindi, divisi in due tipi distinti (Fig. 1.3-3(b)): stock quote, per la vendita, e 
stock request, per gli acquisti. 
Anche questo modello Ł poco flessibile, infatti i subscriber possono manifestare il 
proprio interesse soltanto verso particolari oggetti, istanze di una determinata classe; 
inoltre non Ł possibile esprimere preferenze riguardanti il corpo dell’evento, quindi Ł 
impossibile ricevere notifica soltanto per eventi riguardanti stock quote di una determinata 
compagnia, oppure con un determinato prezzo o range di prezzi.  
1. Il modello Publish/Subscribe 13
1.3.4 Vantaggi e svantaggi del modello type-based 
Il modello type-based, essendo abbastanza simile al topic-based, Ł molto robusto e 
semplice da realizzare. Anche in questo, caso non occorre dare struttura al corpo 
dell’evento, giacchØ il matching da parte dell’event service avviene esclusivamente in base 
alla classe di cui l’oggetto Ł istanza. Il modello si presta molto bene ad implementazioni 
pratiche, superando la rigidit  imposta dal topic-based. Di seguito Ł mostrato un 
semplicissimo esempio, in codice Java, di un’interfaccia per event service basato sui tipi: 
I metodi publish() e advertise() accettano oggetti generici, quindi i publisher sono 
svincolati dal tipo di evento che desiderano produrre. Il costo dell operazione di matching
Ł molto basso ed Ł simile a quello dello schema topic-based. L’event service cataloga gli 
eventi in base alla classe a cui essi appartengono. 
Lo svantaggio principale di questo modello Ł la poca flessibilit  dovuta, anche questa 
volta, ad un linguaggio di sottoscrizione poco espressivo. Per offrire un buon servizio, 
occorre che i publisher definiscano una quantit  enorme di tipi, appesantendo l’event 
service nell’operazione di catalogazione degli oggetti. 
1.3.5 Content-based publish/subscribe 
Il modello basato sui contenuti supera gli svantaggi dei modelli discussi 
precedentemente. Gli eventi non sono piø classificati in base a criteri prestabiliti (es: nome 
di un topic) ma in base alle loro propriet , che possono essere: 

 attributi interni alla struttura dati che rappresenta l’evento, come in Gryphon
[bib. 19], Siena [bib. 9], Elvin [bib. 20] e Jedi [bib. 21]. 

 meta-dati associati all’evento come in Java Messaging Service [bib. 22]. 
interface Event_service{ 
boolean publish(Object ob); 
boolean advertise(Object ob); 
int subscribe(Object type); 
boolean unsubscribe(int id);  
}
1. Il modello Publish/Subscribe 14
Occorre, quindi, dare una struttura al corpo dell’evento, in quanto il matching da parte 
dell’event service si basa sul contenuto dell’evento stesso. 
Fig. 1.3-4: Content-based publish/subscribe. (a) Semplice codice Java per subscribing. (b) Modello di 
interazione content-based. 
I subscriber, tramite la definizione di un filtro, possono manifestare interesse soltanto 
per particolari t ipi di eventi, scartando i rimanenti. Il filtro, solitamente composto da coppie 
(nome, valore) (Fig. 1.3-4(a)), Ł realizzato tramite un particolare linguaggio chiamato 
subscription language, che deve comprendere almeno gli operatori di confronto  (=, <, >, 
≤, ≥). Definire un filtro significa stabilire delle  restrizioni  che possono anche essere 
logicamente combinate tra loro, utilizzando operatori logici (and, not, or, etc.); la 
combinazione di queste restrizioni prende il nome di subscription pattern. 
Alcuni sistemi, come Cambridge Event Architecture (CEA) [bib. 23], permettono ai 
subscriber di esprimere interesse per una combinazione di eventi semplici, ricevendo 
notifica solo quando gli eventi prodotti da qualche publisher rispettano la combinazione 
specificata. La flessibilit  di questo modello appare ormai ovvia; osservando la Fig. 
1.3-1(a) questa volta un subscriber pu  connettersi all’event service NEWS e specificare, 
tramite subscription language, interesse, ad esempio, per news di tipo calcio riguardanti le 
squadre Napoli e Parma, news di tipo cinema riguardanti soltanto i film di azione e 
drammatici, news di tipo sport riguardanti le olimpiadi invernali e via dicendo. 
Esprimere tali preferenze utilizzando i modelli topic-based e type-based avrebbe 
portato alla definizione di moltissimi topic e tipi da parte dei publisher. Nel modello 
content-based il metodo subscribe() dell’event service deve essere opportunamente 
1. Il modello Publish/Subscribe 15
modificato in modo da poter accettare un parametro addizionale, il  subscription pattern , 
che pu  essere rappresentato nei seguenti modi: 

 Stringa: Ł il modo piø comune e potente, vengono utilizzati linguaggi come 
SQL, Xpath oppure linguaggi proprietari. 

 Template object: si ispira a JavaSpaces e Linda (tuple-based matching); un 
subscriber, dichiarando un oggetto  t , esprime il proprio interesse per ogni 
evento che Ł conforme al tipo  t , in cui gli attributi sono compatibili con i 
corrispondenti attributi di  t .  

 Codice eseguibile: Ł il metodo meno utilizzato e meno efficiente. I subscriber 
forniscono all’event service del codice eseguibile atto a filtrare gli eventi di loro 
interesse a runtime. Il servizio eventi provveder  ad eseguire il codice ogni 
volta che un evento viene prodotto da un publisher. Questo approccio Ł molto 
costoso e limita la scalabilit  del servizio. 
L’esempio in Fig. 1.3-4 propone un semplice modello content-based publish/subscribe. 
Si noti come un subscriber possa connettersi al LondonStockMarket e specificare, tramite 
subscription language, i tipi di eventi a cui Ł interessato. 
Adesso Ł possibile manifestare interesse per stock quote di una particolare compagnia, 
con un determinato prezzo, di un particolare venditore ed Ł possibile anche combinare le 
preferenze grazie ad operatori logici. 
1.3.6 Vantaggi e svantaggi del modello content-based 
Il modello basato sui contenuti offre molta flessibilit , grazie al linguaggio di 
sottoscrizione fortemente espressivo, in grado di superare tutti gli svantaggi dei modelli 
topic e type based. Ottenere una buona flessibilit  introduce un carico maggiore 
nell’operazione di matching da parte dell’event service, che dovr  confrontare il contenuto 
di ogni evento, con i vari subscription pattern, definiti dai subscriber, e instradare l’evento 
lungo il canale di comunicazione adeguato. 
L’implementazione del filtering engine Ł piø difficile e complessa. Tuttavia esistono 
numerose tecniche per ottimizzare la fase di matching.