Java Message Service ( JMS )

JMS è l'acronimo di Java Message Service [A27-A30] ed indica un'insieme di API che permettono lo scambio di messaggi tra applicazioni Java. Prima di descrivere in dettaglio JMS è necessario inquadrare il contesto del suo utilizzo. Con il termine Messaging si definisce un meccanismo che permette la comunicazione asincrona tra client mediante scambio di messaggi. Data questa definizione si può considerare Messaging System un qualsiasi sistema che scambia pacchetti TCP/IP tra programmi client utilizzando un proprio protocollo, ma questo non è lo scopo dei creatori di JMS, che si sono prefissati lo scopo ulteriore di creare un meccanismo di messaging generico, valido per ogni situazione che richieda lo scambio di dati, anche tra applicazioni diverse.

Il sistema che sta alla base di JMS è nominato Message Oriented Middleware (MOM). Mediante l'infrastruttura middleware del MOM processi residenti su macchine diverse possono interagire tra loro mediante l'invio e la ricezione di messaggi tipicamente asincroni. I client interagiscono tra loro, però, non in modo diretto ma tramite la mediazione di un messaging server. Il messaging server riceve i messaggi dai produttori e li recapita ai relativi destinatari (consumatori). Grazie alla mediazione del messaging server i client risultano essere disaccoppiati, cioè non devono sapere nulla l'uno dell'altro. Il disaccoppiamento tra il produttore di messaggi e il consumatore di messaggi è una caratteristica molto importante. Nel caso di Remote Procedure Call (come ad esempio RMI in Java) un'applicazione per poter comunicare con un oggetto remoto deve essere a conoscenza dei suoi metodi per poterli invocare. Invece nei sistemi MOM i client non devono interagire direttamente tra di loro: il produttore ed il ricevitore non devono essere a conoscenza l'uno dell'altro ma l'unica cosa che entrambi devono sapere è il formato del messaggio e la "casella di posta" (destination) da usare. La Figura 3-3 evidenzia quanto detto.

Altra importante caratteristica offerta dai sistemi MOM è il concetto di Guaranteed Message Delivery (GMD) che garantisce la consegna del messaggio.

3. Implementazione del prodotto OpenSPCoop 137

Figura 3-3, Differenza tra un sistema RPC ed un sistema MOM

Nell’architettura MOM sono possibili due tipi di scambio di messaggi [A27]:

• Point-To-Point. Un client può mandare uno o più messaggi ad un altro client attraverso una destinazione che prende il nome di Queue (coda). Più produttori e più consumatori possono condividere la stessa coda, ma aspetto importante è che ogni messaggio ha un solo consumatore; questo permette di fatto una comunicazione uno a uno. Non ci sono dipendenze temporali tra sender e receiver del messaggio e quindi il receiver può ricevere il messaggio anche se non era in ascolto sulla coda al momento dell'invio.

• Publish/Subscribe. Nel modello Publish/Subscribe (detto anche sistema di messaging event-driven), i client inviano messaggi ad un topic, che si tratta di una coda "speciale" in grado di inoltrare i messaggi a più destinatari. Il sistema si prende carico di distribuire un eventuale messaggio pubblicato da un publisher ai sottoscrittori che si sono dichiarati interessati alla ricezione, avendo attivato una connessione sul topic. Esiste una dipendenza temporale tra publisher e subscriber visto che il receiver può consumare il messaggio solo dopo essersi "sottoscritto" (subscription) al topic d'interesse e dopo che il client ha effettivamente inviato il messaggio. Inoltre il receiver deve mantenere la connessione al topic attiva se vuole continuare a ricevere (a meno di utilizzare Durable Subscriptions). Il messaggio una volta consumato da tutti i subscriber interessati viene tolto dal Topic.

3. Implementazione del prodotto OpenSPCoop 138 Java Message Service (JMS) è un'insieme di API Java che permette di creare,

spedire, ricevere e leggere messaggi. JMS è stato sviluppato da SUN insieme ai maggiori produttori di sistemi MOM per definire un'interfaccia comune indipendente dalla specifica implementazione del sistema di messaging in modo analogo a quanto avviene con JDBC e JNDI. L'applicazione Java JMS risulta così essere indipendente, oltre che dal sistema operativo, anche dalla specifica implementazione del sistema di messaging. In un'applicazione JMS gli attori coinvolti sono riassunti nella Figura 3-4.

Figura 3-4, Attori coinvolti in un contesto JMS

ConnectionFactory e Destination. La Connection Factory e le destinazioni su cui inserire e ricevere messaggi sono detti Administered Objects poiché sono realizzati attraverso specifiche implementazioni dei Provider JMS. Gli Administered objects sono realizzati ed implementati da diverse aziende e per questo motivo non sono gestiti all'interno dell’interfaccia Java. Le interfacce JMS permettono allo sviluppatore Java di astrarsi dai dettagli implementativi della specifica versione di MOM. La creazione del connection factory e delle destination è compito dell'amministratore JMS che deve inserirli all'interno di un contesto JNDI (associandogli un identificativo) in modo da poterli recuperare da qualsiasi client mediante le normali API JNDI che permettono la ricerca e l’estrazione di oggetti registrati in un server applicativo, a cui è stato associato un identificativo. E’ simile ad un server DNS, con l’unica differenza che invece di ritornare un indirizzo IP (frutto di una traduzione dell’identificativo nominale di un host) ritorna un oggetto. Un'applicazione JMS, per inviare messaggi (Sender/Publisher) o per riceverli (Receiver/Subscriber), utilizza i servizi JNDI per ottenere un oggetto di tipo ConnectionFactory e uno o più oggetti destination (Queue o Topic).

3. Implementazione del prodotto OpenSPCoop 139 Connection. Rappresenta l'astrazione di una connessione attiva su di un particolare

JMS provider e si ottiene dall'oggetto Connection Factory.

Session. L'interfaccia Session si ottiene dall'oggetto Connection e rappresenta il canale di comunicazione con una destinazione e permette la creazione sia di produttori che di consumatori di messaggi.

MessageProducer

Il MessageProducer è l'oggetto che permette l'invio dei messaggi verso una particolare destinazione.

MessageConsumer

Il MessageConsumer rappresenta un oggetto in grado di ricevere messaggi. Messages

I messaggi JMS sono costituiti da tre parti: un'intestazione (message header), una serie di campi contenti proprietà (property fields) ed il corpo (message body). Il message header è costituito da campi che sono usati sia dai client che dai provider al fine di identificare ed inoltrare il messaggio. I property fields sono coppie di nome e valore e sono utili per costruire "filtri" a livello applicativo utilizzati da client per la ricezione filtrata di messaggi che hanno una determinata caratteristica. Infine nel messaggio è presente un body che è specifico a seconda del tipo di messaggio JMS utilizzato. I messaggi JMS possono essere di varia natura come evidenzia la Tabella 3-1.

Tabella 3-1, Tipi di Messaggi JMS

Tipo di Messaggio Descrizione

TextMessage Contiene messaggi di tipo String.

ObjectMessage Contiene oggetti serializzabili.

MapMessage Contiene coppie nome/valore.

BytesMessage Contiene uno stream di byte

3. Implementazione del prodotto OpenSPCoop 140