Jms Parte 1

Jms è un servizio integrato nella piattaforma J2EE e fornisce un’api per i principali sistemi di messaging esistenti.

Un JMS Provider è quello strato-software che converte i messaggi in formato standard JMS nel formato specifico per il sistema di messaging sottostante.

Jms consente due modalità di scambio di messaggi:

• Point-to-Point

Prevede un un singolo ricevente ed uno o più produttori di messaggi.

Il ricevente usufruisce di una coda FIFO nella quale i messaggi arrivano a destinazione, da quella coda poi verranno consumati uno per volta.

I messaggi in una queue possono essere resi persistenti, cioè salvati su un supporto persistente dopo essere stati immessi in una coda:                                                                                                                                                                                      questo ci permette di stare tranquilli in caso di fault sulla macchina che ospita la coda, infatti una volta ripristinato il funzionamento di quella macchina, essa può prelevare le informazioni dalla memoria persistente e ritornare allo stato antecedente al fault. Viceversa se i messaggi non sono persistenti, corro il rischio di perdere il contenuto di una coda in caso di guasto, ma il sistema necessita solo della singola operazione di accodamento e non deve gestire uno storage per il salvataggio dei dati.

• Publish/Suscribe

Prevede più riceventi di ogni messaggio, ed uno o più produttori.                                                                                                                                                                                                                                                                                                                                     Il produttore si limita a pubblicare il messaggio in una struttura chiamata Topic, diversi utenti si sottoscrivono a quel Topic e ricevono dal sistema JMS i messaggi in esso inseriti.

I messaggi pubblicati possono essere durevoli o non durevoli.
Se un subscriber non è online durante la pubblicazione di un messaggio sul topic a cui è sottoscritto e  tale messaggio è  durevole, allora tale messaggio gli sarà recapitato alla sua prossima riconnessione. Per poter disporre di una tale funzionalità bisogna inserire dell’overhead al messaggio conservato, cioè una lista dei destinatari a cui non è ancora stato spedito.

Ci potremmo chiedere cosa succede se un utente sottoscritto al topic non si collega più: onde evitare un accumulo di messaggi, tipicamente si preferisce settare un timeout oltre il quale il messaggio, spedito o no a tutti i suoi destinatari, dovrà essere cancellato dal server.

JMS come del resto tutti i servizi di messaging, rispetto a sistemi basati su RPC offre sicuramente il vantaggio di essere scalabile, infatti l’incremento del numero di utenti non comporta la necessità di dover modificare la logica applicativa, ed è anche robusto, infatti poichè vi è un disaccoppiamento tra produttore e consumatore di messaggi ( i messaggi vengono recapitati in modo asincrono), un fault che avviene a livello di produttore, consumatoreo rete, non comporta una perdita di informazioni.

Il modello di messaggio fornito dalla specifica è il seguente:

Tale formato è un comune denominatore a tutti i formati di messaggio vendor-specific, sarà il provider ad effettuare una corretta conversione.
Il campo Header contiene la Destination (il nome JNDI dello strumento di messaggistica scelto).

Tra le varie proprietà che permettono di configurare il messaggio citiamo

• JMSExpiration          che ci da un tempo di expiration oltre il quale il messaggio viene cancellato dalla struttura dati. È importante sottolineare che la qualità nel delivery dei messsaggi offerta dallo strumento di messaggistica, dipende da quanto questo parametro sia settato basso nei messaggi, in modo tale da non sovraccaricare il sistema con messaggi troppo vecchi.
• JMSDeliveryMode     che ci dice se il messaggio deve essere reso persistente o meno.
• JMSPriority       Ci da informazioni sulla priorità del messaggio. Ogni Coda generalmente è suddivisa in varie Sotto-Code, ognuna viene servita con un livello di priorità differente, e tale parametro ci informa su quale di queste deve essere la sua effettiva destinazione.
• JMSTimeStamp offre il time-stamp, necessario ad esempio per scartare messaggi duplicati.
• JMSType Il tipo di messaggio contenuto nel Body. Generalmente questo ha a che fare con la codifica, ad esempio posso avere uno StreamMessage (stream di dati), o un ObjectMessage (un oggetto serializzato)

Le due API, che possono essere utilizzate per amministrare gli oggetti che costituiscono un’architettura JMS, sono Connection Factory e Destination, di cui parleremo nel prossimo post.

Immagini gentilmente concesse dal prof. Bellavista ed estratte dalle slides inerenti al corso di Sistemi Distribuiti M di Ingegneria Informatica, Università di Bologna, tutti i diritti riservati