Messaging
Many enterprise applications are built from separate software components. These components can reside on the same system or in a distributed or multi-tiered environment on several Java Virtual Machines.
Some method of communication is almost always required between the components in large systems. It is often a requirement that this communication should also be loosely coupled or asynchronous. In asynchronous communication, the sender sends the message and continues execution without waiting for a reply, and the receiver can retrieve the message at any time after it has been sent. In a loosely coupled system, the sender does not need to necessarily know who the recipient is; the communication itself may or may not be asynchronous. This communication between software components is called messaging.
Without support for a messaging system, the programmer would typically use a sockets interface for inter-application communication. With sockets, both the sender and receiver need to agree on the socket address, and both applications need to be running at the same time. Likewise, if Remote Method Invocation (RMI) is used, the sender (or calling application) needs to know about the receiver's (or remote application's) methods. With messaging, the sender and receiver only have to agree on the message format and where to send it. The sender and receiver do not need to know anything about each other, nor do they both need to exist at the same time.
Messaging should be used in preference to a tightly coupled API such as RMI when some or all of the following conditions exist:
The components interfaces are not known or not published.
Not all of the components will be running at the same time.
A sender needs to communicate with multiple receivers.
No response is required.
Messaging should not be confused with electronic mail (email). Email is used to communicate between people, whereas messaging is the mechanism used to communicate between applications.
Messaging is used in various environments and many applications; it is not unique to J2EE. A well-known example of a messaging service is IBM's MQ Series. While there are numerous messaging APIs, the only one supported by J2EE is JMS.
Message Passing
There are several models of message passing, but JMS only supports two—point-to-point and publish/subscribe. Both of these are what is known as a push model. The sender of the message is the active initiator, and the receiver is a passive consumer.
With point-to-point, the sender and receiver agree on a message destination, also known as a queue. The sender leaves the message and the receiver picks up the message at any time thereafter. The message remains in the queue until the receiver removes it. The following are some real-life examples of point-to-point communication:
Sending a fax
Dropping letters at a hotel desk to be picked up later by a hotel guest
Leaving a voice mail message
Figure 9.1 illustrates point-to-point messaging.
Figure 9.1. Point-to-point messaging model.
With the publish/subscribe model, the sender, now called a publisher, again sends messages to an agreed upon destination. The destination is, by convention, known as a topic and this time there may be many receivers, and these are called subscribers. A message is immediately delivered to all current subscribers and is deleted when all the subscribers have received the message. Real life examples of this model include a public address system or an Internet chat room. Figure 9.2 portrays the publish/subscribe messaging model.
Figure 9.2. Publish/Subscribe messaging model.
Within JMS, these models are called message domains. Code examples and further details on the JMS implementation of these message domains are presented in the next section.