Java Message Service (JMS) is quite simply a standard in which people typically follow to exchange messages between one another. There's a few interfaces that's available within the J2EE platform that allows you to follow the particular standard. If done right, you can set these JMS interfaces that provides a JMS client (definition of a 'JMS client' below) the ability to create, send, receive, and read the messages.

There's many JMS 'components' that you'll need to consider, but keep in mind not all not every JMS component is required (it really depends what type of AQ you're attempting to do.

To kick this off, I have summarize the JMS components:

• JMS provider <-- Provides the access to the JMS interfaces
• JMS client <-- Can be considered as the application that creates the message. It can be considered as the application that receives the message also, so be careful with the ambiguity
• JMS producer/publisher <-- Who ever creates and sends the message
• JMS consumer/subscriber <-- Receives the JMS message
• JMS message <-- The actual message being transferred. It contains the header and a payload
• JMS queue <-- Once the message has been delivered, this is where the message will reside until a JMS consumer/subscriber 'consumes' the message
• JMS topic <-- Used for publishing the message to multiple subscribers
• JMS queue table <-- Basically where all the messages sit when published by the producer

Once you've got a basic level of understanding, you then need to determine the scenarios to determine what components are required. For instance, if a publisher sends a message to the queue, how many users will consume the message? More than 1 aka multiple consumers? If so, you must have subscribers. If the queue only has one JMS consumer, then you dont need a JMS subscriber.

In fact, if there are multiple consumers, you need a JMS topic. For a single consumer (aka point-to-point), you need a JMS queue.

As mentioned, a JMS queue is only a point to point model meaning there's a guarantee delivery of the message between two clients. This is because the consumer 'pulls' the message, instead of the message being sent automatically in the hope that the consumer is alive Because it's only a one-to-one relationship between the JMS producer and the JMS consumer, you can get the JMS consumer to give the 'thumbs-up' acknowledgement to the JMS queue once received. Furthermore, the consumer can view the message first and then decide whether or not to accept the message

On contrast, a a JMS Topic typically has Multiple clients and subscribe to the message. Unlike the JMS Queue, there's not guarantee that the message is delivered

So now you have a basic understanding of JMS Queues and Topics, let's now jump to the JMS messages blog.

The next blog HOW TO: Enqueue a JMS_TEXT_MESSAGE from java to Oracle database Queue also elaborates particular components of a JMS message as well as understanding the syntax of a JMS TEXT MESSAGE

About the author