Messaging is a method of communication between software components and applications. The Java Message Service (JMS) documented at http://java.sun.com/products/jms/docs.html is a Java API designed by Sun that allows applications to create, send, receive, and read messages.
Messaging differs from other standard protocols, such as Remote Method Invocation (RMI) or Hypertext Transfer Protocol (HTTP), in two ways. First, the conversation is mediated by a messaging server, so it's not a two-way conversation between peers. Second, the sender and the receiver need to know what message format and what destination to use. This is in contrast to tightly coupled technologies, such as Remote Method Invocation (RMI), which require an application to know a remote application's methods.
In this chapter, we will cover:
- A brief introduction to message-oriented systems
- The building blocks of the JBoss messaging subsystem
- Setting up some proof of concept programming examples
- How to use JMS and resource adapters to integrate with external systems
JMS defines a vendor-neutral (but Java-specific) set of programming interfaces for interacting with asynchronous messaging systems. Messaging enables distributed communication that is loosely coupled. The whole messaging interchange is a two-step process: where, a component sends a message to a destination, which is in turn retrieved by the recipient with the mediation of the JMS server. In JMS, there are two types of destinations: topics and queues. These have different semantics, which are explained next.
In the point-to-point model, messages are sent from producers to consumers via queues . A given queue may have multiple receivers but only one receiver may consume each message. The first receiver to fetch the message will get it, while everyone else will not:
A message sent to a topic , on the other hand, may be received by multiple parties. Messages published on a specific topic are sent to all message consumers that have registered (subscribed) to receive messages on that topic. A subscription can be durable or nondurable. A nondurable subscriber can only receive messages that are published while it is active. A nondurable subscription does not guarantee the delivery of the message or may deliver the same message more than once. A durable subscription, on the other hand, guarantees that the consumer receives the message exactly once:
As far as message consumption is concerned, even though JMS is inherently asynchronous, the JMS specification allows messages to be consumed in either of the following two ways:
- Synchronously: A subscriber or a receiver explicitly fetches the message from the destination by calling the
receive()method of anyMessageConsumerinstance. Thereceive()method can block until a message arrives or can time out if a message does not arrive within a specified time limit. - Asynchronously: With the asynchronous mode, the client must implement the
javax.jms.MessageListenerinterface and overwrite theonMessage()method. Whenever a message arrives at the destination, the JMS provider delivers the message by calling the listener'sonMessagemethod, which acts on the contents of the message.
A JMS message consists of a header, properties, and a body. The message headers provide a fixed set of metadata fields describing the message, with information such as where the message is going and when it is received. The properties are a set of key-value pairs used for application-specific purposes, usually to help filter messages quickly when they have been received. Finally, the body contains whatever data is being sent in the message.
The JMS API supports two delivery modes for messages to specify whether or not the messages are lost if the JMS provider fails, indicated by the following constants:
- The persistent delivery mode, which is the default, instructs the JMS provider to take extra care to ensure that a message is not lost in transit in case of a JMS provider failure. A message sent with this delivery mode is logged to stable storage when it is sent.
- The non_persistent delivery mode does not require the JMS provider to store the message or otherwise guarantee that it is not lost if the provider fails.