Why use JMS at all?

So what's all the hype about? This chapter helps you understand why so many developers are excited to use the JMS API.


The JMS API stands for Java™ Message Service Application Programming Interface, and it is used by applications to send asynchronous “business quality” messages to other applications. The JMS API does for Messaging what JDBC did for Database connectivity. It provides a consistent API across multiple Messaging providers. When you use the JMS API to satisfy your messaging requirements, you ensure that your application remains portable across several different Messaging providers.

JBoss comes with a JMS 1.0.2b compliant JMS provider called JBossMQ. When you use the JMS API in JBoss, you are using the JBossMQ engine transparently.

Producer/Consumer Decoupling

In the JMS world, messages are not sent directly to other applications. Instead, messages are sent to destinations, also known as “queues” or “topics”. Applications sending messages do not need to worry if the receiving applications are up and running, and conversely, receiving applications do not need to worry about the sending application’s status. Both senders, and receivers only interact with the destinations.

When producers and consumers are decoupled, you gain a more flexible processing architecture. You could collocate the producers and the consumers in the same application, or you could run the consumers and produces on different applications on different machines.

Asynchronous Messaging

Asynchronous messaging is the ability of a client application to send a message without having to wait for a response. Applications can take a “send it and forget” approach to processing. Once they send the JMS message, the sending application can continue processing the other work it has to do. The JMS provider takes over the responsibility of making sure the message is successfully delivered to a consumer that will process the message.

Since, the J2EE spec does not allow you to start a new thread within an Enterprise Bean, sending multiple asynchronous messages is the way an Enterprise Bean start other concurrent processes.

QoS Enforcement

As a result of the JMS API allowing you to do asynchronous messaging, it must also provide a way to control the Quality of Service (QoS) the messages receive. An example of QoS enforcement is ensuring that messages with a higher priory gets delivered to consumers before messages with a lower priority. Another form of QoS enforcement is allowing the JMS provider to drop old messages before they reach consumers. Other forms of QoS enforcement will be covered in chapter 3.5.3.