JMS è un insieme di API che fornisce un sistema di messaggistica destinato allo scambio di informazioni tra più componenti J2EE.
Mediante le API JMS è possibile ottenere due differenti modelli di messaggistica: Point-To-Point e Publish-Subscribe.
Nel modello Point-To-Point il mittente (Producer) invia un messaggio ad una Queue gestita dal Server JMS, ma soltanto un destinatario (Consumer) può leggerlo. Il messaggio inviato dal Producer viene memorizzato finché non viene letto dal Consumer, quindi non è necessario che il destinatario sia in ascolto quando il messaggio viene inviato.
Nel modello Publish-Subscribe il mittente (Publisher) spedisce il messaggio ad una Topic gestita dal Server JMS ed uno o più destinatari (Subscriber) in ascolto, o precedentemente sottoscritti, possono leggerlo. Il messaggio inviato dal Publisher viene cancellato quando tutti i Subscriber attivi o sottoscritti hanno letto il messaggio.
Quando viene creata una destinazione (Queue o Topic) è possibile anche definire un modulo per gestire la persistenza dei dati al fine di prevenire la perdita delle informazioni in caso di crash del sistema.
Configurazione di una Destination (Queue o Topic) su WebLogic Server
La configurazione di una Destination (Queue o Topic) su un Server WebLogic (versione 10) implica la creazione e la configurazione dei seguenti elementi:
- JMS Server
- JMS Module
- Subdeployment JMS Module
- Connection Factory
- Queue o Topic
La creazione di questi elementi può essere fatta da Services -> Messaging. Nella creazione di un Server JMS è possibile anche settare un modulo per gestire la persistenza dei messaggi: File System, JDBC o altro.
Tipi di messaggi disponibili
Sia Queue che Topic possono gestire 5 differenti tipologie di messaggi:
- TextMessage: contiene messaggi di tipo String
- ObjectMessage: contiene oggetti serializzabili
- MapMessage: contiene coppie chiave/valore
- BytesMessage: contiene stream di byte
- StreamMessage: contiene stream di valori di tipo primitivo Java
WebLogic mette a disposizione anche un'altra tipologia di messaggi, l'XMLMessage che contiene testo in formato XML.
Esempi di funzionamento
Avendo a disposizione tutti gli strumenti necessari per poter scambiare messaggi utilizzando le API JMS, presenteremo due semplicissimi esempi: il primo basato sul modello Point-To-Point, l'altro basato sul modello Publish-Subscriber.
Nel modello Point-To-Point il Producer invia i messaggi sulla Queue e il Receiver li legge.
Sia il Producer che il Receiver per poter inviare un messaggio alla Queue devono ottenere prima di tutto un riferimento al contesto del Server WebLogic.
Listato 1. Ottiene un riferimento al contesto del Server WebLogic
Hashtable env = new Hashtable();
env.put(Context.INITIAL_CONTEXT_FACTORY, "weblogic.jndi.WLInitialContextFactory");
env.put(Context.PROVIDER_URL, "t3://localhost:7001");
env.put(Context.SECURITY_PRINCIPAL, "weblogic");
env.put(Context.SECURITY_CREDENTIALS, "weblogic");
InitialContext ctx = new InitialContext(env);
Successivamente mediante operazione di lookup JNDI devono ottenere il riferimento alla Connection Factory e alla Queue.
Listato 2. Ottiene il riferimento alla Connection Factory e alla Queue
QueueConnectionFactory queueConnectionFactory = (QueueConnectionFactory)ctx.lookup(JNDI_CONNECTION_FACTORY);
Queue queue = (Queue) ctx.lookup(JNDI_QUEUE);
Mediante il riferimento alla Connection Factory è possibile creare una connessione al Server JMS e aprire una Sessione.
Listato 3. Crea una connessione al Server JMS e apre una Sessione
QueueConnection queueConnection = queueConnectionFactory.createQueueConnection();
QueueSession queueSession = queueConnection.createQueueSession(false, QueueSession.AUTO_ACKNOWLEDGE);
Fin qui Producer e Receiver svolgono le medesime operazioni. Ora vediamo in dettaglio la procedura utilizzata dal Producer e dal Receiver, rispettivamente per inviare e per leggere messaggi dalla Queue.
Producer
Il Producer crea il messaggio da inviare alla Queue e, mediante un'istanza dell'oggetto QueueSender ottenuta utilizzando la Sessione creata precedentemente, invia il messaggio alla Queue.
Listato 4. Crea e invia il messaggio alla Queue
TextMessage textMsg = queueSession.createTextMessage();
textMsg.clearBody();
textMsg.setIntProperty("severity", 1);
textMsg.setText("Ciao, sono il producer e sto inviando il mio primo messaggio sulla Queue!!!");
QueueSender queueSender = queueSession.createSender(queue);
queueSender.send(textMsg);
Receiver
Per leggere i messaggi in arrivo sulla Queue, il Receiver, deve avviare la connessione e mettersi in ascolto sulla Queue. In questo caso conosce la tipologia di messaggio presente sulla Queue quindi effettua un cast alla tipologia richiesta, nel nostro caso si tratta di un TextMessage. La chiamata non è bloccante. Se non vengono individuati messaggi, il processo termina.
Listato 5. Il Receiver si mette in ascolto del Queue e riceve i messaggi
qConnection.start();
TextMessage msg = (TextMessage)qReceiver.receiveNoWait();
while (msg != null) {
System.out.println("Ricevuto msg: " + msg.getText());
msg = (TextMessage)qReceiver.receiveNoWait();
}
qConnection.close();
Ovviamente occorre eseguire prima il processo Producer e poi il processo Receiver. Non ci sono dipendenze temporali tra Producer e Receiver in quanto il messaggio viene memorizzato dal Server JMS fin quando un client non lo legge confermando (acknowledge) la ricezione.
Nell'esempio di Publish-Subscribe il Publisher invia i messaggi sulla Topic e gli n Subscriber in ascolto sulla Topic li leggono.
Le operazioni effettuate dal Publisher e dal Subscriber sono simili a quelle del Producer e del Receiver dell'esempio precedente. Cambiano le classi utilizzate: nel primo esempio le classi avevano il prefisso Queue, nel secondo caso, invece, le classi hanno prefisso Topic. Ciò fino al listato 3 (compreso), dal listato 4 e cose cambiano.
Publisher
Il Publisher crea il messaggio da inviare alla Topic e, mediante un'istanza dell'oggetto TopicPublisher ottenuta utilizzando la Sessione creata precedentemente, invia il messaggio alla Topic.
Listato 6. Crea e invia il messaggio
TextMessage textMsg = topicSession.createTextMessage();
textMsg.clearBody();
textMsg.setIntProperty("severity", 1);
textMsg.setText("Ciao, sono il producer e sto inviando il mio primo messaggio sulla Queue!!!");
TopicPublisher publisher = topicSession.createPublisher(topic);
publisher.send(textMsg);
Subscriber
Per leggere i messaggi in arrivo sulla Topic, il Subscriber, deve avviare la connessione e mettersi in ascolto sulla Topic. In questo caso la chiamata è bloccante. Il processo resta in attesa di messaggi.
Listato 7. Avvia la connessione e si mette in ascolto sul Topic
topicConnection.start();
TopicSubscriber subscriber = topicSession.createSubscriber(topic);
TextMessage msg = (TextMessage)subscriber.receive();
while (true){
System.out.println("Letto un messaggio dalla Queue: " + msg.getText());
msg = (TextMessage)subscriber.receive();
}
In questo caso è possibile eseguire i processi in un ordine casuale. Infatti, il Subscriber si mette in ascolto sulla Topic per la lettura di tutti i messaggi che arrivano. Naturalmente se viene lanciato il processo Publisher e nessun Subscriber è in ascolto, il messaggio viene perso; si parla in questo caso di Non-Durable Subscriber.
È possibile definire anche un Subscriber di tipo Durable, cioè che riesce a leggere i messaggi in un momento successivo rispetto a quello in cui vengono inviati. Ciò necessita però di una configurazione particolare della Topic.
