PUBLISH/SUBSCRIBE: UTILIZZANDO IL JMS (JAVA MESSAGING

UNIVERSITÀ DEGLI STUDI DI BARI “ALDO MORO”
DIPARTIMENTO DI INFORMATICA
CORSO DI LAUREA MAGISTRALE IN INFORMATICA
INSEGNAMENTO: SISTEMI DISTRIBUITI
APPROFONDIMENTO:
PUBLISH/SUBSCRIBE:
IMPLEMENTAZIONE MOM E DEL “MESSAGE QUEUEING”
UTILIZZANDO IL JMS (JAVA MESSAGING SYSTEM)
STUDENTI:
Sergio ANGELASTRO (MATRICOLA 624287)
Antonio DIOMEDE (MATRICOLA 629668)
Tommaso VITERBO (MATRICOLA 619103)
ANNO ACCADEMICO 2014/2015
Indice
INTRODUZIONE ............................................................................................................................................. 2
CAPITOLO 1 – MESSAGING ......................................................................................................................... 3
Introduzione....................................................................................................................................................... 3
1.1 Cosa è Messaging? .................................................................................................................................. 3
1.2 Che cosa è il Messaging System? ............................................................................................................ 4
1.3 Perché usare Messaging? ......................................................................................................................... 5
1.4 Sfide del Messaging Asincrono ............................................................................................................... 7
1.5 Pensare in modo asincrono ...................................................................................................................... 7
CAPITOLO II – PUBLISH SUBCRIBE........................................................................................................... 9
2.1 Contesto, problema e soluzione ............................................................................................................... 9
2.2 Comunicazione Publish/Subcribe .......................................................................................................... 10
2.3 Message Queueing System .................................................................................................................... 11
2.4 Message Oriented Middleware .............................................................................................................. 11
2.5 Modello Message-Oriented Middleware Publish Message Queueing ................................................... 12
2.6 Observer Design Pattern ........................................................................................................................ 12
2.6.1 Intenzione ....................................................................................................................................... 12
2.6.2 Motivazione .................................................................................................................................... 12
2.6.3 Applicabilità ................................................................................................................................... 13
2.6.4 Struttura .......................................................................................................................................... 14
2.6.5 Collaborazione ................................................................................................................................ 15
CAPITOLO III – JAVA MESSAGING SYSTEM ......................................................................................... 16
3.1 Che cosa è il Java Messaging System? ...................................................................................................... 16
3.2 JMS Messaging Models: Publish Subscribe e Point-to-Point ............................................................... 16
3.2.1 Publish Subscribe ........................................................................................................................... 17
3.3 Sviluppo Applicazione JMS .................................................................................................................. 18
3.3.1 Ambiente di Sviluppo ..................................................................................................................... 18
3.3.2 Configurazione JMS server ............................................................................................................ 18
3.3.3 Codice Sorgente.............................................................................................................................. 19
3.4 API 1.1 vs API 2.0 ................................................................................................................................. 20
CONCLUSIONE E SVILUPPI FUTURI........................................................................................................ 22
1
INTRODUZIONE
Questo progetto nasce nell’ambito dell’approfondimento ed applicazione dei concetti appresi durante
l’insegnamento di “Sistemi Distribuiti” nel C.d.L.M. in “Informatica” dell’Università degli Studi di Bari “Aldo
Moro” tenuto dal Professore Sebastiano Pizzutilo.
Un concetto da spiegare è che cosa intendiamo per un Sistema Distribuito? Esso è un insieme di processori
indipendenti (con proprie risorse HW/SW) interconnessi da una rete di comunicazione, che cooperano per
condividere alcune delle risorse ovunque distribuite.
Un altro concetto alla base è il modello di comunicazione Peer-to-Peer in cui ogni computer (nodo autonomo
ed indipendente) può operare indifferentemente come client o come server, consentendo accessi condivisi
a diverse risorse (come file, periferiche e sensori) senza la necessità di un server centrale.
Infine un altro concetto alla base è la persistenza. Una comunicazione è persistente se un messaggio immesso
nel canale trasmissivo, per essere trasmesso, viene memorizzato per tutto il tempo che serve fino alla sua
consegna.
Questo elaborato si occuperà dello studio del Messaging System e di una sua implementazione utilizzando il
linguaggio JAVA ENTERPRISE EDITION in cui sono presenti API che permettono lo sviluppo di un Messaging
System che nel linguaggio viene chiamato JAVA MESSAGING SYSTEM.
Nel primo capitolo si relazionerà su cosa intendiamo per Messaging System e di tutto quello che può essere
utile per capire al meglio come esso possa essere usato nell’ambito dei sistemi distribuiti.
Nel secondo capitolo si relazionerà sul modello di comunicazione PUBLISH SUBSCRIBE come argomento di
approfondimento scelto tra tutti gli argomenti trattati all’interno dell’insegnamento sopra indicato.
Nel terzo capitolo si relazionerà su cosa è il Java Messaging System e di come esso possa essere utile per
implementare il modello del PUBLISH SUBSCRIBE.
Nel quarto, ed ultimo capitolo, si concluderà la stesura dell’elaborato relativa allo studio del PUBLISH
SUBCRIBE con la sua implementazione pratica.
2
CAPITOLO 1 – MESSAGING
Introduzione
Tutte le soluzioni integrate hanno a che fare con alcune sfide fondamentali:
 Reti inaffidabili: le soluzioni per l’integrazione devono trasportare i dati da un computer ad un altro
attraverso molte reti. Rispetto a un processo in esecuzione su un singolo computer, il calcolo distribuito
deve essere preparato ad affrontare un set molto più grande di possibili problemi. Spesso, due sistemi
che devono essere integrati sono separati dai continenti e i dati tra loro devono viaggiare attraverso le
linee telefoniche, segmenti LAN, router, switch, reti pubbliche e collegamenti satellitari. Ognuno di
questi passaggi può causare ritardi o interruzioni.
 Reti lente: inviare dati attraverso una rete è più lento di diversi ordini di grandezza rispetto ad un
chiamata ad un metodo locale. Progettare una soluzione ampiamente distribuita è la stessa cosa se ci
si approccerebbe ad una singola applicazione ma questo potrebbe avere implicazioni disastrose sulle
performance.
 Due qualsiasi applicazioni sono differenti: le soluzioni per l’integrazione hanno bisogno di
trasmettere informazioni attraverso sistemi che usano diversi linguaggi di programmazione, sistemi
operativi e formato dei dati. Una soluzione per l’integrazione ha bisogno di interfacciarsi con tutte
queste tecnologie differenti.
 Cambiamenti inevitabili: le applicazioni cambiano attraverso il tempo. Una soluzione per
l’integrazione deve tenere il passo con i cambiamenti delle applicazioni a cui è connessa. Le soluzioni
per l’integrazione possono essere facilmente affette da modifiche rilasciate in un arco temporale molto
breve, provocando un effetto a valanga, se un sistema cambia, tutti gli altri sistemi possono essere
influenzati. Una soluzione per l’integrazione ha bisogno di minimizzare le dipendenze da un sistema
all’altro diminuendo l’accoppiamento tra applicazioni.
Col tempo, gli sviluppatori hanno superato queste sfide con questi quattro approcci:
1. File transfer: una applicazione scrive un file che verrà successivamente letta da un’altra.
L’applicazione ha bisogno di capire il nome del file e la locazione, il formato del file, il tempo di
quando verrà scritta e letta e chi cancellerà tale file.
2. Shared database: Molte applicazioni condividono lo stesso schema del database, localizzato in un
singolo database fisico.
3. Remote Procedure Invocation: Una applicazione espone alcune delle sue funzionalità in modo che
è possibile accedervi in remoto da altre applicazioni come una procedura remota. La comunicazione
avviene in real time e sincrona.
4. Messaging: un’applicazione pubblica i messaggi in un canale comunicativo comune. Altre
applicazioni posso leggere il messaggio dal canale in tempi differenti. Le applicazione devono
accordarsi sul canale cosi come sul formato del messaggio. La comunicazione è asincrona.
Mentre tutti questi approcci risolvono essenzialmente lo stesso problema, ogni stile ha i suoi vantaggi e
svantaggi. Infatti, applicazioni che potrebbero essere integrate usano stili multipli tali che ogni punto di
integrazione prenda i vantaggi dello stile scelto e che lo adatti al meglio.
1.1 Cosa è Messaging?
Messaging è una tecnologia che consente alta velocità, asincronia, comunicazione program-to-program con
distribuzione affidabile. I programmi comunicano inviando pacchetti di dati chiamati messaggi ad ogni altro
dispositivo che è in ascolto sul canale. I canali, anche conosciuti come code, sono percorsi logici che
connettono i programmi e i messaggi trasmessi. Un canale si comporta come una collezione o vettore di
messaggi, ma un canale può essere condiviso da molti computer e può essere usato simultaneamente da molte
applicazioni. Un Sender o Producer è un programma che invia un messaggio scrivendolo sul canale. Un
Receiver or Consumer è un programma che riceve un messaggio leggendolo (e cancellandolo) dal canale.
3
Il messaggio stesso è semplicemente una struttura dati predeterminata, come per esempio stringhe, vettori di
byte, un record o un oggetto. Può essere interpretato semplicemente come dato, come la descrizione del
comando invocato sul Receiver, o come la descrizione di un evento che occorre nel Sender. Un messaggio è
costituito da due parti, l’header e il body. L’header contiene le meta-informazioni riguardanti il messaggio, chi
lo invia, a chi è stato inviato ecc.; questa informazione è usata dal Messaging System e soprattutto (ma non
sempre) ignorato dall’applicazione che usa (consuma) il messaggio. Il body contiene i dati che si stanno
trasmettendo ed esso viene ignorato dal Messaging System. Nelle conversazioni, quando uno sviluppatore che
sta utilizzando il Messaging parla del messaggio, usualmente ci si riferisce al dato presente all’interno del body
del messaggio.
L’architettura del Messaging asincrono è molto potente, ma richiede di rivedere l’approccio usato nello
sviluppo. Come confrontato con gli altri tre approcci di integrazione, relativamente pochi sviluppatori hanno
avuto l’esposizione al messaggio e al Messaging System. Come risultato, gli sviluppatori in genere non hanno
famigliarità con i linguaggi e le peculiarità della piattaforma di comunicazione.
1.2 Che cosa è il Messaging System?
La funzionalità della messaggistica è tipicamente fornita da un sistema software separato chiamato Messaging
System o Message-oriented middleware (MOM). Un Messaging System gestisce la messaggistica allo stesso
modo come il Database System gestisce la persistenza dei dati. Solo un amministratore può popolare il database
con lo schema per i dati dell’applicazione, un amministratore deve configurare il Messaging System con i
canali che vengono definiti come sentieri della comunicazione attraverso le applicazioni. Il Messaging System
coordina e gestisce anche l’invio e la ricezione dei messaggi. Lo scopo primario del database è di rendere
sicuro ogni record di dati e garantire la persistenza, e allo stesso modo il task principale del Messaging System
è di spostare i messaggi dai computer Sender ai computer Receiver in modo affidabile.
La ragione per cui un Messaging System è necessario per spostare i messaggi da un computer ad un altro è che
i computer e le reti che li connettono sono intrinsecamente inaffidabili. Già perché se una applicazione è pronta
ad inviare una comunicazione non significa che l’altra applicazione è pronta a ricevere. Anche se entrambe le
applicazioni sono pronte, la rete potrebbe non essere funzionante, o potrebbe fallire la trasmissione. Un
Messaging System supera questi limiti cercando ripetutamente di trasmettere il messaggio fino a quando riesce
a inviarlo. In circostanze ideali, il messaggio è trasmesso con successo al primo tentativo, ma le circostanze
spesso non sono ideali.
Un messaggio è trasmesso in cinque fasi:
1. Create: il Sender crea il messaggio e lo popola con i dati.
2. Send: il Sender aggiunge il messaggio al canale.
3. Deliver: il Messaging System sposta i messaggi dal computer del Sender al computer del Receiver,
rendendolo disponibile al Receiver.
4. Receive: il Receiver legge il messaggio dal canale.
5. Process: il Receiver estrae i dati dal messaggio.
Il diagramma illustra queste cinque fasi di trasmissione del messaggio, che ogni computer effettua, e quale fasi
coinvolgono il Messaging System.
4
Il diagramma illustra anche due importanti concetti della messaggistica:
1. Send and Forget: nella fase 2, l’applicazione che invia il messaggio lo invia inserendolo nel canale ad
esso adibito. Una volta che l’invio è completato, il Sender può andare avanti svolgendo i propri compiti
mentre il Messaging System trasmetterà il messaggio in background. Il Sender può fidarsi che il
Receiver riceverà eventualmente il messaggio e non deve aspettare fino a quando esso non viene
ricevuto.
2. Store and Forward: nella fase 2, quando l’applicazione che invia il messaggio lo invia inserendolo nel
canale ad esso adibito, il Messaging System immagazzina il messaggio nel computer Sender, o in
memoria centrale o nel disco fisso. Nella fase 3, il Messaging System spedisce il messaggio
inoltrandolo dal computer Sender al computer Receiver, e poi immagazzina il messaggio di nuovo nel
computer Receiver. Il processo di Store and Forward potrebbe essere ripetuto molte volte, il messaggio
viene spostato da un computer a l’altro, fino a quando raggiunge il computer Receiver.
Le fasi di Create, Send e Process possono sembrare delle operazioni di inutile sovraccarico. Perché
semplicemente non spediamo il dato al Receiver? Impacchettando i dati come un messaggio e lo
immagazziniamo nel Messaging System, l’applicazione delega al Messaging System la responsabilità della
spedizione del dato. Il dato è impacchettato in un messaggio atomico, la spedizione può essere effettuata fino
a quando non avviene con successo e il Receiver può essere certo di ricevere, in modo affidabile, esattamente
la copia del dato inviato.
1.3 Perché usare Messaging?
La risposta più immediata è che il Messaging è più immediato del File Transfer, meglio incapsulato del Shared
Database e più affidabile della Remote Procedure Invocation. Tuttavia, questo è solo l'inizio dei vantaggi che
possono essere acquisiti usando il Messaging.
Benefici specifici del Messaging sono:
 Remote Comunication: Il Messaging consente alle applicazioni di separare il processo di
comunicazione e il processo di trasferimento dati. Due oggetti che risiedono nello stesso processo
possono condividere in modo molto semplice gli stessi dati in memoria. L’invio dei dati ad un altro
computer è complicato e richiede che siano copiati da un computer ad un altro. Questo significa che
l’oggetto è serializzato. Se la connessione remota non è necessaria, il Messaging non è necessario; una
soluzione molto semplice che possiamo prendere in considerazione sono le collezioni contemporanee
o la memoria condivisa, esse sono delle soluzioni sufficienti per raggiungere lo scopo.
 Platform/Language Integration: Quando si connettono molti sistemi di elaborazione attraverso la
comunicazione remota, questi sistemi probabilmente usano diversi linguaggi, tecnologie e piattaforme,
forse perché sono stati sviluppati col tempo da diversi team. L’integrazione di tali applicazioni
5







differenti possono richiedere una zona demilitarizzata del middleware per far sì che ognuna di esse
possa negoziare con tutte le altre applicazioni, spesso usando un fattore in comune (come i file di dati
uniformi con formato sconosciuto). In questa circostanza, un Messaging System può essere un
traduttore universale attraverso il quale le applicazioni che lavorano sui dati comuni, utilizzando
linguaggi e piattaforme differenti, comunicano per il tramite di una messaggistica comune.
Asynchronus Communication: il Messaging abilita l’approccio alla comunicazione Send and Forget.
Il Sender non ha bisogno di aspettare il Receiver per ricevere e processare il messaggio; non ha bisogno
di aspettare che il Messaging System consegni il messaggio. Il Sender ha bisogno solo di aspettare che
il messaggio sia inviato. Un volta che il messaggio è stato memorizzato, il Sender è poi libero di fare
altri lavori mentre il messaggio è trasmesso in background. Il Receiver può decidere di inviare un
riconoscimento o feedback al Sender, che richiede un altro messaggio, la cui spedizione dovrà essere
rilevata da un meccanismo di callback nel Sender.
Variable Timing: con la comunicazione sincrona, il chiamante deve aspettare la ricezione per finire il
processo di chiamata prima che il chiamante possa ricevere il risultato e continuare. In questo modo,
il chiamante può solo effettuare chiamate veloci come il Receiver le può eseguire. D’altronde, la
comunicazione asincrona permette al Sender e al Receiver di inviare e ricevere richieste in batch
ognuno al proprio ritmo. Questo permette ad entrambe le applicazioni di avere il throughput massimo
e non sprecare tempo aspettando su ogni altra richiesta.
Throttling: un problema con le remote procedure calls è che troppe richieste effettuate nello stesso
momento possono sovraccaricare il Receiver. Ciò può causare una riduzione delle performance che
porterebbe al crash del Receiver. La comunicazione asincrona consente al Receiver di controllare la
velocità con cui si consumano le richieste, in modo da non essere sovraccaricato da troppe richieste
simultanee. L’effetto negativo sui chiamanti causati da questo limite è ridotto al minimo in quanto la
comunicazione è asincrona, quindi i chiamanti non sono bloccati ma messi in attesa dal Receiver.
Reliable Communication: il Messaging fornisce in modo affidabile la consegna che una remote
procedure call non può effettuare. Il motivo per cui il Messaging è più affidabile del RPC è che il
Messaging utilizza uno Store e usa un approccio Forward per la trasmissione dei messaggi. I dati
vengono impacchettati in messaggi, che sono unità indipendenti atomiche. Quando il Sender invia il
messaggio il Messaging System si occupa della memorizzazione del messaggio. Successivamente il
messaggio viene recapitato trasmettendolo al computer del Receiver, in cui è stato nuovamente
memorizzato. La memorizzazione del messaggio sul computer del Sender e il computer del Receiver
garantisce l’affidabilità. Ciò che è inaffidabile è il forwarding del messaggio dal computer del Sender
al computer del Receiver, perché il Receiver o la network potrebbero presentare dei problemi. Il
Messaging System supera questo, inviando il messaggio fino a quando non riesce a fare questa
operazione. Questo tentativo automatico consente al Messaging System di superare i problemi con la
network in modo che il Sender e il Receiver non debbano preoccuparsi di questi dettagli.
Disconnected Operation: Alcune applicazioni sono specificamente progettate per funzionare
disconnesse dalla network, ma la sincronizzazione con i server avviene quando è disponibile una
connessione. Tali applicazioni vengono implementate su piattaforme come computer portatili, PDA,
e cruscotti di automobili. Il Messaging è ideale per l'attivazione di queste applicazioni da sincronizzare
– i dati da sincronizzare possono essere messi in coda quanto vengono creati e messi in attesa fino a
quando l’applicazione si ricollegherà alla rete.
Mediation: Il Messaging System funge da mediatore tra tutti i programmi che possono inviare e
ricevere messaggi. Un'applicazione può utilizzare per esempio directory di altre applicazioni o servizi
disponibili per l'integrazione. Se un'applicazione si stacca dagli altri, è sufficiente ricollegarla solo al
Messaging System e non a tutte le altre applicazioni di Messaging. Il Messaging System può essere
utilizzato per fornire un elevato numero di connessioni distribuite a una risorsa condivisa, come per
esempio un database. Il Messaging System può utilizzare le risorse ridondanti per fornire alta
disponibilità, bilanciamento del carico, reindirizzare le connessioni di rete fallite e ottimizzare le
prestazioni e la qualità del servizio.
Thread Manangement: per comunicazione asincrona intendiamo che una applicazione non deve
bloccarsi e mettersi in attesa mentre un'altra applicazione esegue il proprio compito. Piuttosto che
6
bloccarsi e aspettare una risposta, il chiamante può utilizzare una callback che avvisa il chiamante
quando la risposta arriva. Un gran numero di thread bloccati, o thread bloccati per lungo tempo, può
essere problematico. Troppi thread bloccati possono lasciare l'applicazione con troppo pochi thread
disponibili per eseguire il lavoro vero e proprio. Al riavvio di una applicazione andata in crash per via
di un numero variabile di thread bloccati è difficile ripristinare lo stato precedente di questi ultimi.
Ci sono una serie di diverse ragioni per cui un'applicazione o una enterprise possono beneficiare del Messaging.
Alcuni di questi sono dettagli tecnici che riguardano gli sviluppatori, mentre altri sono decisioni strategiche
per i membri del management dell’enterprise. Quale di questi motivi è più importante? Esso dipende dai
requisiti delle applicazioni particolari. Sono tutti buoni motivi per utilizzare il Messaging.
1.4 Sfide del Messaging Asincrono
L’asincronicità del Messaging risolve molte delle sfide dei più disparati sistemi per l’integrazione ma introduce
anche nuove sfide. Alcune di queste sfide sono inerenti al modello asincrono mentre altre sfide variano con la
specifica implementazione del Messaging System.
 Modello complesso di programmazione
I messaggi asincroni richiedono agli sviluppatori di lavorare con modelli di programmazione eventdriven. La logica di applicazione non può più essere codificata in un unico metodo che invoca altri
metodi, ma la logica non contempla una serie di event handlers che rispondono ai messaggi in arrivo.
Come un sistema è molto complesso così difficile da sviluppare e testare. Per esempio, l’equivalente
della chiamata di un metodo semplice prevede un messaggio e un canale di richiesta, un messaggio e
un canale di risposta, un identificatore di correlazione e una coda di messaggi non valida.
 Problemi di sequenza
I canali comunicazionali garantiscono la spedizione del messaggio, ma non viene garantito quando il
messaggio sarà recapitato. Ciò può causare che i messaggi inviati in sequenza possono non essere
ricevuti nella stessa sequenza. In situazioni in cui i messaggi dipendono reciprocamente, particolare
cura deve essere presa per ristabilire la sequenza del messaggio.
 Scenari sincroni
Non tutte le applicazioni possono operare nella modalità Send and Forget. Quindi molti Messaging
System hanno la necessità di colmare il divario tra le soluzioni sincrone e asincrone.
 Performance
I Messaging System sovraccaricano la comunicazione. Ci vuole impegno per inserire i dati in un
messaggio e inviarlo, e di ricevere un messaggio ed elaborarlo. Il Messaging è più adatta a mantenere
sincronizzati i sistemi dopo la replica di dati iniziali
 Supporto limitato alle piattaforme
Molti Messaging System proprietari non sono disponibili su tutte le piattaforme. Spesso è più facile
usare FTP se si vuole inviare un file ad un’altra piattaforma al posto di usare il Messaging System.
 Blocco del Venditore
Molte implementazioni del Messaging System utilizzano protocolli proprietari. Anche le specifiche di
Messaging comuni quali JMS non controllano la realizzazione fisica della soluzione. Di conseguenza,
diversi Messaging System di solito non si collegano ad altri Messaging System. Questo ci può lasciare
con una sfida per l’integrazione del tutto nuova: l'integrazione di molteplici soluzioni di integrazione!
Così i messaggi asincroni non risolvono tutti i problemi, e possono crearne anche di nuovi.
1.5 Pensare in modo asincrono
Il Messaging è una tecnologia asincrona, che consente di ripetere la consegna fino a quando non avviene con
successo. Al contrario, la maggior parte delle applicazioni utilizzano chiamate di funzione sincrona; per
esempio: una procedura chiama una sotto procedura, un metodo che chiama un altro metodo, o una remote
procedure call (RPC). Le chiamate sincrone implicano che il processo chiamante venga interrotto mentre il
sotto processo è l'esecuzione di una funzione. Anche in uno scenario RPC, dove il sotto processo chiamato
viene eseguito in un processo diverso, il chiamante è bloccato fino a quando la sotto procedura non restituisce
il controllo (e i risultati) ad esso. Quando si utilizza la messaggistica asincrona, il chiamante utilizza una
7
trasmissione e dimentica l'approccio che gli permette di continuare l’esecuzione dopo che invia il messaggio.
Di conseguenza, la procedura chiamante continua a funzionare mentre la sotto procedura viene richiamata.
Semantica Chiamata Sincrona
Semantica Chiamata Asincrona
La comunicazione asincrona ha molte implicazioni. In primo luogo, abbiamo non più un singolo thread di
esecuzione. Più thread abilitano sotto procedure eseguire contemporaneamente, che possono notevolmente
migliorare le prestazioni e contribuire a garantire che alcuni sotto processi stanno facendo progressi anche
mentre altri sotto processi possono essere in attesa dei risultati esterni. Tuttavia, thread concorrenti possono
anche fare debug ma in modo molto più difficile. In secondo luogo, i risultati arrivano tramite una callback.
Questo consente al chiamante di eseguire altre attività ed essere avvisati quando il risultato è disponibile,
questo può migliorare le prestazioni. Tuttavia, il chiamante deve essere in grado di elaborare il risultato, anche
mentre è nel mezzo di altri compiti, e deve essere in grado di utilizzare il risultato e di ricordare il contesto in
cui è stata effettuata la chiamata. In terzo luogo, i sottoprocessi asincroni possono essere eseguiti in qualsiasi
ordine. Ancora una volta, questo consente ad una sotto procedura di progredire anche mentre l'altra non può.
Ma significa anche che i sotto processi devono essere in grado di essere eseguiti autonomamente in qualsiasi
ordine, e il chiamante deve essere in grado di determinare quale risultato è arrivato da quale sotto processo e
combinare insieme i risultati. Quindi la comunicazione asincrona ha diversi vantaggi, ma richiede di ripensare
come una procedura utilizza le sue sotto procedure.
8
CAPITOLO II – PUBLISH SUBCRIBE
2.1 Contesto, problema e soluzione
Nei sistemi distribuiti il modello client/server non è in grado di ottemperare efficientemente in qualsiasi
contesto d’uso, ad esempio, se ci sono n client che hanno bisogno di richiedere frequentemente risorse di un
certo tipo a un server, del quale essi devono necessariamente conoscere l’indirizzo di rete (accoppiamento
spaziale), esso deve essere in grado di gestire parallelamente più comunicazioni indipendenti. Inoltre affinché
la comunicazione abbia luogo si richiede che sia il client che il server siano attivi in quel momento
(accoppiamento temporale), per evitare che si aspetti inutilmente una risposta che non arriverà mai, fino allo
scadere del time-out. E’ essenziale ai fini della comunicazione che sia il client che il server non compiano altre
operazioni simultaneamente (accoppiamento nel flusso delle operazioni). Il modello client/server è efficiente
nei sistemi di information pull dove un client richiede una risorsa in un dato instante a un server da lui
conosciuto. Tuttavia è possibile ricorrere a interazioni di tipo information push dove non è il client a iniziare
la comunicazione ma bensì il server che pubblica l’informazione a chi ne ha mostrato interesse. Il modello
Publish-Subscribe è conforme a questo tipo di interazione e risolve quei problemi di accoppiamento spaziale,
temporale e del flusso delle operazioni esistenti in quei contesti in cui si vogliono realizzare comunicazioni
multi-cast con frequenti aggiornamenti. Il modello Publish-Subscribe basato su P2P è vantaggioso rispetto al
semplice client/server in termini di scalabilità, laddove c’è una crescita di richieste da soddisfare esso è in
grado di disporre di una potenza elaborativa resistente.
Comunicazione Client/Server
Comunicazione Publish/Subscribe
9
2.2 Comunicazione Publish/Subcribe
E’ un design pattern o uno stile architetturale utilizzato per realizzare comunicazioni asincrone fra diversi
[Processi | Oggetti | Agenti].
Esso si basa sul modello di comunicazione P2P (peer-to-peer) dove ogni host (autonomo ed indipendente)
può operare indifferentemente sia come client che come server. Esso consente accessi condivisi a diverse
risorse senza la necessità di un server centrale. E’ essenziale ai fini della comunicazione che ciascun host
della rete utilizzi programmi compatibili.
1. I mittenti e i destinatari dialogano per tramite di data manager definiti come [Broker | Dispatcher]
che svolgono la funzione di Store-and-Forward;
2. Il data manager utilizza tecniche di Message Queueing per organizzare i messaggi ricevuti in
tematiche di interesse o in classi diverse;
3. I Mittenti (Publisher) pubblicano i loro messaggi sui data manager;
4. I Destinatari (Subscriber) si rivolgono al data manager abbonandosi (subscribing) alla ricezione del
messaggio a cui sono interessati;
5. Prima della sottoscrizione della ricezione il Destinatario attua un processo di filtering nel quale può
precisare la tipologia di messaggi a cui è interessato:
o Content-based: si sceglie l’informazione in base al contenuto, è una selezione più granulare
o Item-based: si sceglie l’informazione in base all’argomento di interesse, la probabilità di
ricevere messaggi a cui non si è interessati è alta;
6. I Publisher non sanno quanti e quali sono i Subscriber e viceversa:
o Questo contribuisce alla scalabilità del sistema.
Sono esempi di Publish-Subscribe:







WEB services ( SOA)
CORBA
SCRIBE
TERA
GRYPHON
JEDI
IBM WebSphere MQ
10
2.3 Message Queueing System
Esso è un sistema utilizzato nell’IPC (inter-process communication) o nell’inter-thread communication nello
stesso processo. Questo sistema fornisce un protocollo di comunicazione asincrona, basato sul modello p2p e
point-to-many, dove Sender e Receiver non hanno bisogno di interagire con la coda di messaggi nello stesso
momento. I messaggi messi in coda restano memorizzati fino a che il Receiver non li richiama. MOM
(message-oriented middleware) è una implementazione di questo sistema di message queueing.
2.4 Message Oriented Middleware
E’ un’infrastruttura basata sul modello client/server che distribuisce un’applicazione tra più piattaforme
eterogenee a vantaggio dell’interoperabilità, portabilità e flessibilità. Tale infrastruttura semplifica lo
sviluppo di applicazioni che usano SO e protocolli di rete diversi esulando il programmatore da questi dettagli.
Il meccanismo di invocazione remota trasparente è il RMI. Il MOM è caratterizzato da un forte
disaccoppiamento tra le entità in gioco, supporta la comunicazione many-to-many, permette la persistenza dei
messaggi e la scalabilità in rete, si basa su due tipologie di comunicazione: Publish-Subscribe e Message
Queueing. Sia il client che il server possiedono il software MOM, questo consente di inviare chiamate
asincrone fra gli stessi. I messaggi inviati a programmi non disponibili vengono memorizzati in apposite code
che li conservano fin quando il programma non torna disponibile per la consegna. Questo meccanismo
nasconde l’implicita natura master/slave del meccanismo client/server.
11
2.5 Modello Message-Oriented Middleware Publish Message Queueing
1.
2.
3.
4.
5.
AUTHORING SERVICE: autenticazione al sistema
DISCOVERY SERVICE: gestione dei nomi dei servizi
PUBLISH-SUBSCRIBE: implementa le funzionalità del Publish-Subscribe
MESSAGE QUEUEING: implementa le funzionalità del MQ
DATA MANAGER: gestisce i dati, fornisce interfacce di accesso trasparenti al sistema di
memorizzazione delle informazioni
Le componenti non condividono lo stesso ambiente di esecuzione:




Il carico computazionale è distribuito
I guasti sono isolati
I sottosistemi sono riusabili e indipendenti
Il sistemi è facilmente modificabile
2.6 Observer Design Pattern
2.6.1 Intenzione
Definire una dipendenza uno-a-molti tra oggetti in modo tale che quando un oggetto cambia il suo stato, tutti
i suoi dipendenti siano informati e aggiornati automaticamente.
2.6.2 Motivazione
Un effetto collaterale comune di un sistema di partizionamento in un insieme di classi che collaborano è la
necessità di mantenere la coerenza tra gli oggetti correlati. Non possiamo ottenere la coerenza con classi
strettamente collegate, perché questo riduce la loro riusabilità.
Molti Toolkit di interfaccia grafica utente, ad esempio, separano gli aspetti della presentazione dai dati
dell'applicazione sottostante. Classi che definiscono i dati dell’applicazione e le classi di presentazione possono
essere riutilizzate in modo indipendente. Essi possono anche lavorare insieme. Un grafico a barre e un foglio
di calcolo possono rappresentare gli stessi dati dell’applicazione utilizzando diverse presentazioni. Il foglio di
calcolo e il grafico a barre non si conoscono reciprocamente, consentendo quindi di riutilizzare solo quello che
12
serve. Ma si comportano come se lo facessero. Quando l'utente modifica le informazioni del foglio di calcolo,
il grafico a barre riflette le modifiche immediatamente e viceversa.
Questo comportamento implica che il foglio di calcolo e il grafico a barre dipendono dai dati e pertanto devono
essere notificati su qualsiasi cambiamento di stato. Non c'è alcuna ragione per limitare il numero di oggetti
dipendenti a solo due; ci può essere un numero qualsiasi di interfacce utente diverse degli stessi dati.
L’Observer Design Pattern descrive come stabilire queste relazioni. Gli oggetti chiave in questo modello sono
oggetto e observer. Un soggetto può avere qualsiasi numero di observer dipendenti. Tutti gli observer vengono
avvisati ogni volta che il soggetto subisce un cambiamento nello stato. In risposta, ogni observer interrogherà
il soggetto per sincronizzare il suo stato con lo stato del soggetto.
Questo tipo di interazione è anche noto come Publish-Subscribe. Il soggetto è l'editore delle notifiche. Esso
invia le notifiche senza sapere quali sono suoi observer. Qualsiasi numero di observer può iscriversi per
ricevere le notifiche.
2.6.3 Applicabilità
Si può utilizzare l’Observer Design Pattern in una qualsiasi delle seguenti situazioni:
 Quando un'astrazione ha due aspetti, una dipendente dall’altra. Incapsulare questi aspetti in oggetti
separati consente di variare e riutilizzarli in modo indipendente.
 Quando una modifica ad un oggetto richiede di cambiare tutti gli altri, e non sappiamo quanti oggetti
devono essere cambiati.
 Quando un oggetto dovrebbe essere in grado di notificare ad altri oggetti senza fare ipotesi su chi sono
questi oggetti. In altre parole, non vogliamo che questi oggetti siano strettamente collegati.
13
2.6.4 Struttura
Partecipanti:
 Subject
o Conosce i suoi observer. Ogni oggetto di tipo Observer può osservare un subject;
o Fornisce una interfaccia per attach e detach degli oggetti Observer.
 Observer
o Definisce una interfaccia di aggiornamento per tutti gli oggetti che dovrebbero ricevere la
notifica di cambiamento del subject.
 ConcreteSubject
o Immagazzina lo stato di interesse negli oggetti di tipo ConcreteObserver;
o Invia una notifica a tutti gli observer quando lo stato è cambiato.
 ConcreteObserver
o Mantiene un riferimento all’oggetto di tipo ConcreteSubject;
o Immagazzina lo stato che dovrebbe rimanere coerenti con i subject;
o Implementa l’aggiornamento dell’interfaccia dell’Observer per mantenere il suo stato che
deve essere coerente con il subject.
14
2.6.5 Collaborazione
 ConcreteSubject notificano ai propri observer ogni qualvolta si verifica un cambiamento che potrebbe
rendere il proprio stato incoerente con il proprio stato contenuto negli observer;
 Dopo essere stati informati di un cambiamento nel ConcreteSubject, un oggetto ConcreteObserver può
interrogare il subject per richiedere informazioni. ConcreteObserver utilizza queste informazioni per
conciliare il suo stato con quello del subject.
Il diagramma di interazione seguente illustra la collaborazione tra un subject e due observer:
15
CAPITOLO III – JAVA MESSAGING SYSTEM
3.1 Che cosa è il Java Messaging System?
Quando il Java fu introdotto, molte delle industrie IT si focalizzarono sulle caratteristiche dell’interfacce
grafiche utente e i vantaggi competitivi che offriva in termini di distribuzione e indipendenza della piattaforma.
Oggi, il focus si è considerevolmente ampliato: Java è stato riconosciuto come una piattaforma eccellente per
la creazione di soluzioni enterprise, in particolare per lo sviluppo di applicazioni distribuite sul lato server.
Questo spostamento ha che fare con il ruolo emergente di Java come linguaggio universale per produzione di
astrazioni indipendenti dell'implementazione per molte tecnologie di impresa. Le API JDBC sono il primo
esempio più familiare. JDBC provvede a fornire una interfaccia indipendente per l’accesso ai database di tipo
relazionale SQL. Questa astrazione ha avuto così tanto successo che è difficile trovare un fornitore di database
relazionali che non supporta JDBC. Astrazioni del Java per le tecnologie enterprise si sono ampliate
considerevolmente per includere JNDI (Java Naming and Directory Interface) per astrarre i servizi directory,
JMX (Java Management Extensions) per astrarre l’accesso ai dispositivi distribuiti sui calcolatori presenti nella
network e il JMS (Java Message Service) per astrarre l’accesso ai differenti prodotti Message-Oriented
Middleware.
JMS è diventato rapidamente un standard de facto del settore. Nella sua seconda versione, la maggior parte dei
fornitori di messaggistica aziendale ora supportano le specifiche JMS.
Il Java Message Service è un Java API implementata dai fornitori di Enterprise Messaging per fornire
applicazioni Java con un modello di programmazione comune ed elegante che è portatile attraverso i vari
sistemi di messaggistica. I Messaging System aziendali vengono utilizzati per inviare la notifica di eventi e
dati tra applicazioni software. Ci sono due modelli di programmazione comuni supportati dall'API JMS:
Publish Subscribe e Point-to-Point. Ogni modello fornisce dei benefici e uno o entrambi possono essere
implementati dai provider di JMS.
Il JMS ed gli Enterprise Messaging Systems forniscono agli sviluppatori Java un Messaging System asincrono
che consente ai sistemi di interagire senza richiedere loro di essere strettamente collegati. I messaggi possono
essere consegnati a sistemi che non sono attualmente in esecuzione e trasformati quando è più conveniente. La
caratteristica dell’asincronicità dell’Enterprise Messaging fa il JMS un potente e critico enterprise API. JMS è
utilizzato dagli sviluppatori nelle Java Enterprise Application Integration, progetti di Business-to-Business
(B2B) e il calcolo distribuito in generale.
Il JMS si muove velocemente in prima linea come una delle più importanti tecnologie J2EE, capire come
funziona il JMS e quando usarlo diventerà il segno distintivo dei professionisti informatici distribuiti più
riusciti.
3.2 JMS Messaging Models: Publish Subscribe e Point-to-Point
JMS prevede due tipi di modelli di messaggistica, Publish Subscribe e il Point-to-Point. Le specifiche JMS si
riferiscono a questi due modelli come domini di messaggistica. Nella terminologia del JMS, Publish Subscribe
e Point-to-Point sono frequentemente abbreviati rispettivamente in pub/sub e p2p (o PTP).
Nel senso più semplice, Publish Subscribe è destinato per una trasmissione da uno-a-molti dei messaggi, Pointto-Point è stato concepito per la consegna da uno a uno dei messaggi.
16
I Client di Messaging in JMS sono chiamati Client JMS e il Messaging System – MOM – è chiamato il Provider
JMS. Una applicazione JMS è un sistema d’impresa composto da molti Client JMS e, generalmente, un
Provider JMS.
3.2.1 Publish Subscribe
Un producer può inviare un messaggio a molti consumatori attraverso un canale virtuale chiamato topic. I
consumatori possono scegliere di sottoscrivere un topic. Ogni messaggio indirizzato ad un topic è spedito a
tutti i consumatori di quel topic. Ogni consumatore riceve una copia di ogni messaggio. Il modello pub/sub è
in generale basato sul modello push, quando i messaggi sono automaticamente trasmessi ai consumatori senza
richiedere ad ogni connessione il topic. Il producer non dipende dal consumer perché i client JMS che usano
il pub/sub possono stabilire delle sottoscrizioni durature che permettano di disconnettersi e riconnettersi
successivamente e di ricevere tutti i messaggi non ricevuti quando si era disconnessi.
17
3.3 Sviluppo Applicazione JMS
Si è provveduto a realizzare due Client JMS utilizzando sia l’API 1.0 sia le API 2.0 così da poter effettuare un
confronto tra le due applicazioni sviluppate.
3.3.1 Ambiente di Sviluppo
Per il Client JMS e il Provider JMS che utilizza l’API 1.1 abbiamo utilizzato i seguenti tools:
 Ambiente di Sviluppo: Eclipse Luna Java Enterprise Enviroment
 Development kit e Enviroment:
o
Java Development Kit 1.6 e Java Runtime Enviroment 1.6
 JMS Server: Jboss 5.0 CR2
Per il Client JMS e il Provider JMS che utilizza l’API 2.0 abbiamo utilizzato i seguenti tools:
 Ambiente di Sviluppo: Eclipse Kepler Java Enterprise Enviroment
 Development kit e Enviroment:
o
Java Development kit 1.8 e Java Runtime Enviroment 1.8
 JMS Server: GlassFish 4.0
3.3.2 Configurazione JMS server
Si è provveduto a configurare i due web server nel modo seguente:
 API 1.1
Inserimento all’interno del file “destination-service.xml” presente nel seguente indirizzo “..\jboss5.0.0.CR2\server\default\deploy\messaging\” il seguente testo:
<mbean code="org.jboss.mq.server.jmx.Topic"
name="jboss.mq.destination:service=Topic,name=PubSubChatTopic">
<depends optional-attributename="DestinationManager">jboss.mq:service=DestinationManager</depends>
</mbean>
 API 2.0
Inserimento all’interno della console dei seguenti parametri:
o In JMS Resource all’interno della voce JMS Connection Factories è stato inserito il canale
nella quale passeranno i messaggi: GFConnectionFactory
18
o
In JMS Resource all’interno della voce JMS Destination Resources è stato inserito il nome
del topic che le singole applicazioni possono sottoscrivere: Topic01
3.3.3 Codice Sorgente
 Set del collegamento dell’applicazione al JMS Provider
o API 1.1
o
API 2.0
 Istanziazione del collegamento al JMS Provider
o API 1.1
o
API 2.0
 Classe per gestire l’evento di invio del messaggio
o API 1.1
o
API 2.0
19
 Definizione Classe Publish
o API 1.1
o
API 2.0
 Subscribe
o API 1.1 Definizione di una classe che permetta la sottoscrizione del topic
o
API 2.0 Utilizzo del metodo createConsumer per implementare il processo di sottoscrizione
3.4 API 1.1 vs API 2.0
 Semplifica JMS API 1.1 esistenti senza perdere la compatibilità
 Nuove API che richiedono un minor numero di oggetti
o JMS provider
Una implementazione dell'interfaccia JMS per un MOM (Message-oriented
middleware). I provider possono essere implementati sia con JMS Java sia come
adattatori di un MOM non Java.
o JMS client
Una applicazione o un processo che invia e/o riceve messaggi
o JMS producer/publisher
Un client JMS che crea ed invia messaggi.
o JMS consumer/subscriber
Un client JMS che riceve messaggi.
o JMS message
Un oggetto che contiene i dati trasferiti tra i JMS client
20
o JMS queue
Una coda che raccoglie i messaggi inviati che sono in attesa di essere letti. I messaggi
vengono consegnati nell'ordine in cui vengono inviati ed una volta letti vengono
rimossi dalla coda.
o JMS topic
Un meccanismo di distribuzione per la pubblicazione di messaggi inviati a più client.
 Nel JAVA Enterprise Editon, permette al JMSContext di essere iniettato e gestito dal container
 Gli oggetti JMS implementano l’AutoCloseable
 Asincronia dell’invio del messaggio
21
CONCLUSIONE E SVILUPPI FUTURI
Concludendo possiamo affermare di aver gestito la comunicazione persistente, con la quale si intende che un
messaggio immesso nel canale trasmissivo viene memorizzato per tutto il tempo che serve fino alla consegna
al destinatario, infatti tutti i client che abbiamo testato, non attivi al momento della trasmissione del messaggio,
hanno ricevuto il messaggio trasmesso sul canale comunicativo. Questo perché il sistema sviluppato è
asincrono e permette al dato di essere consumato da tutti i client del sistema distribuito grazie al Message
Queueing.
Il modello di comunicazione Publish Subscribe appreso potrà con molta possibilità essere riutilizzato alla fine
del percorso di studi in quanto esso è un modello molto utilizzato nelle Enterprise, ciò porta a noi studenti un
valore aggiunto per quanto riguarda le competenze richieste dalle aziende di sviluppo software.
L’implementazione del Messaging System con il JMS è molto utile in quanto le statistiche mondiali affermano
che il linguaggio JAVA è un linguaggio ampiamento utilizzato nel mondo dello sviluppo e ovviamente grazie
alla sua estrema portabilità che gli permette di essere eseguito su tutti i calcolatori (come requisito è richiesta
l’installazione della JAVA VIRTUAL MACHINE) di vario tipo, alta astrazione dalla macchina fisica, velocità
di sviluppo, grande disponibilità di librerie, compatibilità con sistemi palmari ed embedded, alta integrazione
con il web e anche grazie al quale esso è un linguaggio interpretato.
Come un possibile sviluppo futuro un suggerimento potrebbe essere quello di creare un server JMS senza che
esso si basi su un framework quale JBOSS e GLASSFISH.
22
Bibliografia e Sitografia
 Enterprise Integration Patterns Designing, Build, and Delploying Messaging Solution – Gregor
Hohpe/Bobby Woolf - Publisher: The Addison-Wesley Signature Series
 Java Message Service - Richard Monson-Haefel/David A. Chappell - Publisher: O'Reilly - First Edition
January 2001 - ISBN: 0-596-00068-5
 Design Patterns Element s of Reusable Object-Oriented Software - Erich Gamma/Richard Helm/Ralph
Johnson/John Vlissides – Publisher Addison-Wesley
 Slide del Corso di Sistemi Distribuiti – Sebastiano Pizzutilo – CdLM Informatica – Università degli Studi
Di Bari “Aldo Moro” – a.a. 2014/2015
 Implementazione mom basata sul paradigma publish/subscribe e message queueing - Andrea
Antonio Garganico 197474 CdLS Ingegneria Informatica (0234) Reti di Calcolatori LS a.a. 2006/2007
 Un Meccanismo efficiente per l’implementazione del modello content-based Publish-Subscribe su
sistemi topic-based. Fabio Papale - CdLM Ingegneria Informatica Tesi di Laurea a.a. 2008/2009
23