When we talk about messaging in the Java EE context, what we really mean is the process of loosely coupled, asynchronous communication between system components. Most communication between components is synchronous, such as simple method invocation or Java RMI. In both cases, the invoker and the invocation target have to be present for the communication to succeed. Synchronous communication also means that the invoker must wait for the target to complete the request for service before proceeding.
As an analogy, you’re communicating synchronously when you (the invoker) call and talk to someone over the phone. But what if the person (the invocation target) isn’t available? If possible, you leave a voicemail message. The voicemail service makes the communication asynchronous by storing your message so that the receiver can listen to it later and respond. Message-oriented middleware (MOM) enables messaging in much the same way that a voicemail service does— by acting as the middleman between a message sender and the receiver so that they don’t have to be available simultaneously. In this section, we briefly introduce MOM, show how messaging is used in our ActionBazaar application, and examine popular messaging models.
Figure 4.1 Basic MOM message flow. When the producer sends a message to the software, it is stored immediately and later collected by the consumer. Looks a lot like e-mail, doesn’t it?
Message-oriented middleware
Message-oriented middleware is software that enables asynchronous messages between system components. When a message is sent, the software stores the message in a location specified by the sender and acknowledges receipt immediately. The message sender is called a producer, and the location where the message is stored is called a destination. At a later point in time, any software component interested in messages at that particular destination can retrieve currently stored messages. The software components receiving the messages are called the message consumers. Figure 4.1 depicts the various components of MOM.
MOM is not a new concept by any means. MOM products include IBM WebSphere MQ, TIBCO Rendezvous, SonicMQ, ActiveMQ, and Oracle Advanced Queuing.
To flesh out messaging concepts a bit more, let’s explore a problem in the ActionBazaar application. We’ll continue working on this problem as we progress through the topic.
Messaging in ActionBazaar
As an additional source of revenue, ActionBazaar will list items for bid when the company is able to find good bulk deals through its extensive purchasing network. These items, displayed on the site as "ActionBazaar Specials," come with "complete satisfaction" guarantees. ActionBazaar automatically ships these items from their warehouse to winning bidders as soon as they order them. When ActionBazaar started as a two-person Internet operation, Joe and John, the two founders, made a sweet deal with Turtle Shipping Company’s founder Dave Turtle. As a part of the deal, Joe and John agreed to ship with Turtle for a few years.
Figure 4.2 ActionBazaar ordering before MOM is introduced. Slow B2B processing is causing customer dissatisfaction.
As soon as a user places an order for an "ActionBazaar Special," a shipping request is sent to the Turtle system via a business-to-business (B2B) connection, as shown in figure 4.2. The order confirmation page loads only after Turtle confirms receipt. Now that the number of ActionBazaar customers has gone through the roof, the slow Turtle servers and B2B connection simply cannot keep up and completing a shipping order takes what seems like forever. To make matters worse, the Turtle server occasionally goes down, causing orders to fail altogether.
Taking a closer look at things, we see that we could make the forwarding process of the shipping request asynchronous and solve this problem. Instead of communicating directly with the Turtle server, the ActionBazaar ordering process could send a message containing the shipping request to MOM, as depicted in figure 4.3. As soon as the message is stored in MOM, the order can be confirmed without making the user wait. At a later point in time, the Turtle server could request pending shipping request messages from MOM and process them at its own pace.
In this case, the most obvious advantage MOM is offering is an increase in reliability. The reliability stems from not insisting that both the ActionBazaar and Turtle servers be up and running at the same time. Also, the servers are not expected to function at the same processing rate. In the most extreme case, even if the Turtle server is down at any given time the shipping request is not lost and is simply delivered later. Another significant advantage of messaging is loosely coupled system integration. We could, if we wanted to, easily switch from the Turtle Shipping Company to O’Hare Logistics once our current contract runs out. Note how different this is from having to know the exact interface details of the Turtle servers for synchronous communication technologies like RMI or even remote session beans.
Figure 4.3 ActionBazaar ordering after MOM is introduced. Messaging enables both fast customer response times and reliable processing.
So far we’ve described a particular form of messaging known as point-to-point to explain basic messaging concepts. This is a good time to move away from this simplification and fully discuss messaging models.
Messaging models
A messaging model is simply a way of messaging when a number of senders and consumers are involved. It will be more obvious what this means as we describe each model. Two popular messaging models are standardized in Java EE: point-to-point (PTP) messaging and publish-subscribe messaging. We’ll discuss each of these messaging models next.
Point-to-point
You can probably guess from the names of the messaging models how they function. In the PTP scheme, a single message travels from a single producer (point A) to a single consumer (point B). PTP message destinations are called queues. Note that PTP doesn’t guarantee that messages are delivered in any particular order— the term queue is more symbolic than anything else. Also, if more than one potential receiver exists for a message, a random receiver is chosen, as figure 4.4 shows. The classic message-in-a-bottle story is a good analogy of PTP messaging. The message in a bottle is set afloat by the lonely castaway (the producer). The ocean (the queue) carries the message to an anonymous beach dweller (the consumer) and the message can only be "found" once.
Figure 4.4 The PTP messaging model with one producer and two consumers
The ActionBazaar shipping request forwarding problem is an excellent candidate for the PTP model, as we want to be guaranteed that the message is received once and only once.
Publish-subscribe (pub-sub)
Publish-subscribe messaging is much like posting to an Internet newsgroup. As shown in figure 4.5, a single producer produces a message that is received by any number of consumers who happen to be connected to the destination at the time. Much like Internet postings, the message destination in this model is called a topic and a consumer is called a subscriber.
Pub-sub messaging works particularly well in broadcasting information across systems. For example, it could be used to broadcast a system maintenance notification several hours before an outage to all premium sellers whose systems are directly integrated with ActionBazaar and who are listening at the moment.
Figure 4.5 The publish-subscribe messaging model with one producer and three consumers. Each topic subscriber receives a copy of the message.
At this point, you should have a good conceptual foundation of messaging and are perhaps eager to get a taste of some code. Next, we take a brief look at JMS and implement the ActionBazaar message producer for sending the message.
The request-reply model
In the ActionBazaar example, you might want a receipt confirmation from Turtle once they have the shipping request you sent to the queue.
A third kind of model called request-reply comes in handy in these kinds of situations. In this model, we give the message receiver enough information so that they might "call us back." This is known as an overlay model because it is typically implemented on top of either the PTP or pub-sub models.
For example, in the PTP model the sender specifies a queue to be used to send a reply to (in JMS, this is called the reply to queue) as well as a unique ID shared by both the outgoing and incoming messages (known as the correlation ID in JMS). The receiver receives the message and sends a reply to the reply queue, copying the correlation ID. The sender receives the message in the reply queue and determines which message received a reply by matching the correlation ID.
