JMS – Advanced

JMS is the API which includes the MessageListener interface, the QueueSender, the QueueReceiver and a bunch of such objects that are useful for sending and receiving messages. There are a couple of configuration files for messaging. These configuration files contain name of queue, queuemanager, host name of MQ machine etc.(MQ is IBM’s brand of messaging middle-ware) which usually the administrator handles. The configuration files are tapped to get the Properties() for getting the sender and receiver objects -the lookup. So suppose you need to send a message you read configuration files with code similar to the one in the earlier post. The configuration file is used to get the Properties() object, including the name of the OUT queue – the queue you will be placing your message on for sending. For sending a message you need an OUT queue. Then you create a message

TextMessage message = new TextMessage("blahblah"); 
outQueue.getSender().send(message);

TextMessage is part of the JMS API. The message goes out the door and sending is complete.
In point to point(queue) communication discussed earlier the two points described are applications similar to webservices when one application (webservice client) communicates to another application (webservice server).
Example
Suppose our application is a loan processing system, the lender company uses the application to process loans for customers. So if the home lies in a flood prone area the customer needs flood insurance. We send a request on MQ to the flood insurance company’s system using messaging.When the flood insurance company is ready to respond, it sends us back a confirmation. When the app needs additional functionality when needed, and we don’t want to incorporate that stuff in our application, you do this by messaging. The messaging service provides that extra functionality. This message initiates another process in the flood insurance guy’s s/w app which has a message listener that listens to messages and populates their database. When the guy is ready to process and approve it, he may respond by sending a message back. This is two way listening when an application would be both a sender and receiver,but the transaction is asynchronous; the sender does not have to wait for the listener to respond – there’s no deadlock now.The client application is not held up for a response; it just places message on queue and forgets about it for the time being.
Let us move on to receiving messages.
For receiving a message you can write a java class which implements MessageListener interface by implementing it’s onMessage(Message m) method. Sending does not require any interface to be implemented; it requires only getting Properties() and through it, the sender object
For receiving a message you can write a java class which implements MessageListener interface. This method gets invoked when a message arrives on the IN queue.
So you read the message like this

String payloadString = ((TextMessage)m).getText();

The string may be xml in which case you can create a DOM object. Message is a a param to the onMessage method which could be a binary message or text message that you cast to correctly read it. You can also listen using MDB in which case you will implement MessageDrivenBean and MessageListener interfaces. Here also you will need onMessage method, that functions exactly the same way
Many senders can share a single OUT queue.
With point to point using queues:
sender app -> OUT queue -> IN queue -> receiver app
with a queuemanager managing the OUT and IN queues.
Only one receiver app can listen to the IN queue. Technically multiple receivers can listen – but can’t be sure which one is going to get the message. It’s a hit and miss, entirely unpredictable. Here if there are multiple receiver apps reading the IN queue – you can’t be sure which receiver app is going to get the message, so it’s not a good strategy to use multiple receiver apps.
When one receiver app picks up the message, the message is consumed, the other receiver app will not get anything. That’s why it’s NOT a good idea to have multiple receiver apps listening to an IN queue, even though it is technically possible.
But in case of one to one, its always one sender and one listener to the IN que. In case of one to one
one sender -> OUT queue -> IN queue -> one receiver
Now technically one can have many senders
many sender -> OUT queue -> IN queue -> one receiver
There is no problem with that, so that many apps can get the service of a listener app.
But 99% cases are
one sender -> one receiver
If there are many senders, all these share the same OUT configured in the xml file.
Each application has its own config files to tell it the names of the queue etc.
Queue names,queuemanager name, host name, port are typically part of the configuration.
In case of Topics
one sender -> Topic -> multiple receivers
Here the difference is, there can be multiple receivers which will all receive the message because the messages are not “consumed” only by one receiver.
A Topic is the equivalent of a queue – the difference is that it is one to many, and the message is NOT CONSUMED. The messages are available for a moment and then vanish into thin air. They are not guaranteed to be delivered to any receiver, rather like a news broadcast or radio broadcasts and not even one reciever may get the message sometimes. It is not used much but could be useful for broadcasting news or such.

About cuppajavamattiz
Matty Jacob - Avid technical blogger with interests in J2EE, Web Application Servers, Web frameworks, Open source libraries, Relational Databases, Web Services, Source control repositories, ETL, IDE Tools and related technologies.

Comments are closed.

%d bloggers like this: