Java Reference
In-Depth Information
WHAT IS MESSAGE‐ORIENTATED MIDDLEWARE
The communication between components in a Java EE system is synchronous. A call chain is started
from the calling Enterprise JavaBean (EJB) to a data access object (DAO) to the entity, and so on to the
i nal target. All components of the call chain must be available and ready to receive the call, and the
calling component must wait for a response before proceeding. The success of the invocation depends
on the availability of all components. As you saw in Chapter 9, “Asynchronous,” an invocation of an
asynchronous method does not require the calling object to wait for a response. It can continue with
the normal l ow of execution, while the asynchronous method sets up its own call chain.
Message‐oriented middleware (MOM) provides a type of buffer between systems that allows the
communication to be delayed if a component is not up and running. Messages are delivered as soon
as all components are available. Invocations are translated into messages and sent via a messaging
system to a target component that processes the message and may respond. If the target component
is not available, the messages are queued waiting for the system to become available. When the
component is available, the messages are processed.
At one end of the chain is a producer that translates the call into a form that can be transmitted as a
message, and at the other end is a consumer who receives the message. The consumers and produc-
ers are highly decoupled, because they don't know anything about each other. They don't even have
to be written in the same language or be hosted on the same network; they may even be distributed
over several external servers.
A MOM system is composed of four players: messages, consumers, producers, and brokers.
Producers generate the messages and send them to brokers, who distribute the messages to
destinations where they're stored until a consumer connects and processes them.
There are two architectural implementations of MOM: point‐to‐point and publish/subscribe.
In the point‐to‐point implementation, the producer sends a message to the destination, which is called
a
queue
. In the queue, the message waits for a consumer to pick it up and coni rm that it has been pro-
cessed successfully. If it has, the message is then removed from the queue. Figure
15-1 shows the pro-
ducer putting the message M1 onto the queue and then the consumer picking up the message from the
queue and processing it. In this implementation the message is only processed by one consumer.
M1
Producer
Queue
Consumer
M1
FIGURE 15-1:
Point‐to‐point implementation
In the publish/subscribe implementation, the destination is called a
topic
. A producer publishes a
message to a topic, and all consumers who subscribe to the topic receive a copy of the message. This
is shown in Figure 15-2, where messages M1 and M2 are published to the topic T1 and consumed
by consumer C1 and C2, and message M3 is published on topic T2 and consumed by consumers C2
and C3.
