Nell’ambito delle pagine di formazione online che abbiamo iniziato a ospitare sul nostro portale, ospitiamo un contributo di Objectway, focalizzato sulla piattaforma J2Ee, utile anche in vista della prossima Java Conference di Milano. L’autore è consulente presso la sopracitata azienda. L’articolo è
MOM e Java Message Service
Il Message Oriented Middleware (MOM) fornisce un modo uniforme ed affidabile per creare, spedire, ricevere, e leggere messaggi in qualsiasi Enterprise System.
I vantaggi nell’adozione di tale middleware sono molteplici:
- non sono richieste connessioni simultanee tra il sender ed il receiver.
- si hanno trasmissioni sicure anche quando non si verificano comunicazioni contemporanee tra sender e receiver.
- i messaggi possono essere dinamicamente adattati a formati differenti.
- molti aspetti implementativi e di basso livello sono trasparenti allo sviluppatore ed è possibile adottare vendors differenti.
I sistemi di messaging, quindi, permettono un elevato disaccoppiamento delle applicazioni di un sistema distribuito (loosely coupled applications) .
Il Java Message Service (JMS) fornisce un’interfaccia standard basata su Java per i servizi di messaging.
(si veda fig. 1)
Perchè utilizzare JMS
La flessibilità di JMS ed il livello di disaccoppiamento che introduce lo rendono un sistema vincente non solo nelle applicazioni B2B, ma anche in realtà d’integrazione(EAI) e per le Mobile Applications.
Le qualità di un’applicazione JMS sono sintetizzabili in:
- Robustezza ai cambiamenti . Sono presenti tipologie differenti di messaggi e feature customizzabili.
- Time independence . La simultanea attivazione del sender e del receiver non è obbligatoria.
- Location independence e Latency hiding. Grazie anche all’uso del sistema di naming di Java (JNDI) non è necessario avere un riferimento diretto ad oggetti remoti, ma ci si affiderà alla presenza di elementi generici definiti DESTINATION.
- Quality of Service configurabile . Sono previsti diffenti livelli di affidabilità per considerare molteplici scenari applicativi.
- Transactions Support . Le specifiche JMS prevedono, sia in fase di trasmissione che di ricezione, il supporto alle transazioni permettendo, ad esempio, di esprimere in un unico ambito transazionale gruppi di messaggi.
Messaging Domains
I messaging system prevedono essenzialmente due modelli di base per la gestione dei messaggi: Point-To-Point e Publish/Subscribe; un terzo modello (Request\Replay) è attuato partendo dal design degli altri due.
Le specifiche JMS forniscono l’implementazione di questi due domini in maniera separata e definiscono le compatibilità per ogni dominio dando la possibilità ai produttori di implementarle senza costringere l’applicazione a legarsi ad esso.
Point-To-Point Domain
Il Point-To-Point (PTP) lavora sfruttando il concetto di coda (Queue), receiver e sender. Ogni messaggio è inviato dal sender ad una specifica coda ed i receivers recupereranno il messaggio da questa coda. Un messaggio è ritenuto ricevuto quando un receiver l’ha recuperato.
Il PTP ha le seguenti caratteristiche:
- Ogni messaggio ha un solo consumatore. Ciò non vuol dire che ci deve essere un solo receiver ma che solo un receiver otterrà il messaggio.
- Non c’è una dipendenza tra il sender ed il receiver. Il sender può inviare il messaggio anche quando non ci sono receiver attivi, appena un receiver si attiverà verranno letti i messaggi che sono stati inviati sino a quel momento.
- Il receiver gestisce il successo della lettura dei messaggi. Cio vuol dire che se mentre vengono ricevuti i messaggi capita un errore, il receiver può impostare uno stato di lettura senza successo. In questo modo i messaggi non vengono cancellati dalla code e possono essere riletti.
Publish/Subscribe Domain
Il Publish/Subscrbe (pub/sub) lavora, invece, sfruttando il concetto di topic, publisher e subscriber. Con publisher s’intende uno o più clients che "registrano" il messaggio in una topic che è resa disponibile a tutti i subscriber. Il subscriber si mette in ascolto sulla topic e reperisce i messaggi che sono inviati dal momento che lui si è messo in ascolto perdendo i precedenti.
Se ci sono più subscribers in ascolto sulla topic i messaggi verranno ricevuti da tutti.
(si veda fig. 2)C’è una dipendenza temporale tra il publisher ed il subscriber; se nessun subscriber è attivo mentre un publischer invia un messaggio quest’ultimo verrà perso.
Il pub/sub ha le seguenti caratterstiche:
- Ogni messaggio potrebbe avere più consumatori (subscriber)
- C’è una dipendenza temporale tra il publisher ed il subscriber.
Le API del JMS forniscono comunque un supporto per ottenere una "durable subscription" che permette ai messaggi di non essere cancellati sino a quando un subscriber non li riceve. Si ha perciò una caratteristica del PTP system ma con la proprietà di avere più client che ricevono il messaggio.
Un semplice Esempio
Possiamo immaginare un sistema che si occupa della vendita su internet di libri.
Il cliente compra un libro ed il sottosistema STORE toglie il libro dal magazzino: se la soglia del numero di libri scende al di sotto del limite minimo chiama un BUSINESS PARTNER. La chiamata al business partner potrebbe durare anche dei secondi e non si vuole legare l’attesa del cliente a questa funzione. In questo caso grazie a JMS il sottosistema magazzino viene immediatamente disaccoppiato dopo aver inviato il messaggio.
Si veda Fig3
Conclusione
La realtà di ogni giorno non offre situazioni così semplici e non solo per il complicarsi dei flussi di messaggi: la presenza di richieste contemporanee, gli aspetti transazionali e le necessità sulla security rendono indispensabile l’adozione di un elemento come il Java Message Service. La presenza, nella release 2.0 degli Enterprise Java Bean, di componentware legato al JMS dimostra, inoltre, l’importanza architetturale del MOM e la necessita di un completo inserimento nella piattaforma J2EE per lo sviluppo di sistemi distribuiti sempre più robusti, scalabili e performanti.
