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

1

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

2

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.

3

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.

4

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.

5

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

6

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

7

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 event-

driven. 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

8

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.

9

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

10

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

11

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.

12

2.5 Modello Message-Oriented Middleware Publish Message Queueing

1. AUTHORING SERVICE: autenticazione al sistema

2. DISCOVERY SERVICE: gestione dei nomi dei servizi

3. PUBLISH-SUBSCRIBE: implementa le funzionalità del Publish-Subscribe

4. MESSAGE QUEUEING: implementa le funzionalità del MQ

5. 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

13

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.

14

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.

15

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:

16

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, Point-

to-Point è stato concepito per la consegna da uno a uno dei messaggi.

17

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.

18

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 “..\jboss-

5.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-attribute-

name="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

19

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

20

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

21

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

22

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.

23

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