Il modello di sviluppo di cui abbiamo parlato nelle precedenti lezioni ha fatto sempre riferimento alla presenza di un server e di una serie di client che lo interrogano per richiederne dei servizi. Questo modello architetturale (client-server) è alla base della piattaforma J2EE e degli strumenti di logica applicativa di cui abbiamo discusso (EJB). La comunicazione in ambiente distribuito abbiamo visto essere basata sul protocollo RMI-IIOP, che consente lo sviluppo di applicazioni in maniera object oriented anche con componenti residenti su macchine diverse.
Non sempre però questo modello architetturale è un vantaggio per le applicazioni. Spesso, soprattuto in ambito web, l'utente non ha necessità di una risposta a seguito di una richiesta, specie se l'elaborazione implica molto tempo. Sarebbe il caso, allora, di valutare un modello di comunicazione asincrono, dove l'utente effettua una richiesta ma non attende la risposta. La risposta sarà elaborata, e successivamente inoltrata al richiedente.
La piattaforma J2EE ha pensato anche a questa evenienza, prevedendo una forma di middleware nota come MOM (Message Oriented Middleware). Il modello di comunicazione asincrono prevede lo scambio di messaggi (molto spesso in forma testuale) tra il Produttore (del messaggio) ed il Consumatore (del messaggio). L'idea, molto semplice e potente al tempo stesso, è quella di prevedere un sistema tra il client ed il server che si occupi di smistare opportunamente i messaggi.
In pratica uno o più produttori creano dei messaggi e li inviano a questo sistema MOM. Questo si preoccuperà di smistare opportunamente il messaggio ad uno o più consumatori.
Lo standard creato è JMS (Java Message Service), composto da una serie di API che facilitano il compito dello sviluppatore (ancora una volta, non ci preoccuperemo dell'implementazione concreta, ogni AS lo farà per conto suo). Come vedremo, dal punto di vista dello sviluppo, le API rendono molto chiaro e semplice il compito dello sviluppatore.
Qualche difficoltà in più potrebbe trovarsi nel far convivere implementazioni di MOM e gli application server. Alcuni application server, infatti, hanno delle soluzioni integrate di MOM, altri invece no, e devono far uso ad una delle tante proposte commerciali (anche gratuite, open source). Nel secondo caso bisognerà creare degli appositi bridge per utilizzare questi servizi terzi.
Dicevamo della specifica JMS presentarsi in maniera molto chiara allo sviluppatore. Esistono due tipi di comunicazione asincrona:
- Publisher / Subscriber: uno o più Consumer si "iscrivono" ad un argomento (Topic) e ricevono gli aggiornamenti quando uno o più Producer li pubblicano.
- Point to Point: un Consumer legge dalla propria coda (Queue) i messaggi inviati da uno o più Producer.
Il primo caso è il caso broadcast, il producer non conosce i consumer. Nel secondo invece, il producer deve conoscere il consumer (ed il suo indirizzo).
Come accade per tutti i servizi J2EE, anche questo viene utilizzato dai client attraverso JNDI. La connessione verso una coda (o un topic) viene precedentemente creata per mezzo di specifici descrittori (dipendenti dall'application server), quindi le viene associato un nome a cui ci riferiremo quando dovremo utilizzarla.
Per quanto riguarda la scrittura di un messaggio di una coda vedremo nelle lezioni seguenti dei client, per la ricezione di messaggi, e vedremo la presenza di un componente apposito che ci permetterà lo sviluppo di servizi evoluti.
