An Asynchronous World

Today’s business applications rarely live in isolation, to paraphrase Martin Fowler’s Patterns of Enterprise Application Architecture (Addison-Wesley, 2003). The customer care system gets the date of the customer’s last payment from the accounting system while the order processing system talks to the shipping company to estimate shipping charges. Traditionally, communication between systems has been the domain of batch processing or nightly file transfers.

The trend toward real-time responsiveness and computing mobility is enticing, but one thing holding it back is communication overhead: Sending data across networks can be orders of magnitude slower than a local method invocation. One possible answer to latency problems is middleware providing asynchronous messaging. One such solution is reaching maturity: the Java Messaging Service.

Better Than a Bottle Sending a JMS message to a destination.

Five years have passed since the introduction of the Java Messaging Service (JMS), a unified API to access asynchronous messaging services from a Java application. The API has gradually found its way into the J2EE specification, evolving into JMS 1.1 in the current J2EE 1.4 spec. Asynchronous messaging lets two or more applications send data to each other without having to wait for receipt confirmation. The infrastructure guarantees message delivery, even if the receiving application isn’t currently running or the network connection is interrupted. It sounds simple enough, but asynchronous messaging demands a new way of thinking about system architecture. First, let’s look at a trivial example.

“Hello, Asynchronous World!”
Applications send data via JMS by encapsulating it inside a message. The JMS API provides a set of different message types, including a text message that contains a character string (such as an XML document) or a message that contains a (serializable) Java object. Most message classes come with convenient constructors to make the creation of a message object pretty much a one-liner.

Once we have a message object, we need to send it somewhere. We do this by specifying a destination. As we’ll see shortly, a destination is a type of data channel agreed upon by both the sender of the message and the recipient. JMS provides two types of destinations: topics and queues. For now, let’s keep things simple and assume that we send the message to a queue, which implies that the message will be received by a single recipient. Before we can send the message, though, we first need to establish a connection to the messaging system:

 
  Context jndiContext = new InitialContext();
  ConnectionFactory connectionFactory = 
  		(javax.jms.QueueConnectionFactory)
  		jndiContext.lookup("QueueConnectionFactory");
  Connection connection = connectionFactory.createConnection();
  Session session = connection.createSession
  			(false, Session.AUTO_ACKNOWLEDGE);
  connection.start();

 Queue queue = (Queue) jndiContext.lookup("jms/Queue");
  MessageProducer producer = session.createProducer(queue);
  TextMessage requestMessage = session.createTextMessage
  				("Hello, Asynchronous World!");
  producer.send(requestMessage);

Pipes and Filters Loose coupling allows the insertion of additional steps into the chain of pipes (destinations) and filters (components).

Apparently, JMS makes sending messages quite easy (admittedly, I omitted any necessary exception handling and hard-coded all literal values): We obtain a reference to a message queue from JNDI, create a producer for this queue and send a message object on its way.

What’s Your Destination?
Our simple JMS example highlights one important property of asynchronous messaging: The source application does not send the message directly to another application—instead, it sends the message to a destination. What happens to the message after that is fairly irrelevant to the source application (some systems use the term “fire-and-forget”). The sending application may not even know which application consumes the message from the destination. Therefore, we call this mode of interaction “loosely coupled”—the sender and the receiver of the message depend on each other only for agreement on a common message format and a specific destination. This style of interaction works particularly well if the message represents a business event such as “New Order” or “Inventory Low”; the application that publishes this message needn’t be aware of the way this message is processed.

Loose coupling offers quite a bit of flexibility in setting up communication between systems. For example, if the two communicating applications don’t agree on a common message format, it’s easy to interject a transformation component to translate one message format into the other. This process is completely transparent to the sender application—the recipient application simply consumes messages of the destination to which the transformation component publishes. Because the resulting architecture consists of an alternation between destinations and components, it’s often referred to as a pipes-and-filters architectural style, labeling the destinations as pipes and the components as filters. Frank Buschmann’s Pattern-Oriented Software Architecture (Wiley, 1996) explains how this concept is used, among other things, to chain applications together in Unix/Linux shell scripting. Messaging employs the same concept, but distributed across multiple computers and applications.

Because of messaging’s loosely coupled nature, messages rarely flow directly from one application to another. Components such as message brokers are commonly interjected into the message stream. These brokers add another level of indirection between the applications by performing message format translation, routing, logging and other functions. As a result, when designing messaging architectures, it’s often more interesting to examine what sits between the applications than to elaborate on the JMS API features for message creation or consumption (we can get those from the online documentation).

Time Travel Is Possible
The concept of asynchronous, loosely coupled interaction is powerful. The sending application doesn’t have to worry about which application consumes the message, nor must it wait until the message is consumed. “Fire-and-forget” certainly seems convenient. Most experienced architects have learned, however, that there are no free lunches. I sometimes explain asynchronous messaging to developers by saying that it “makes things that used to be hard easy … but many things that used to be easy are now hard.” The convenience of sending guaranteed messages literally around the world to applications running on different platforms or technologies is a huge benefit. What’s the catch? The messaging system can guarantee that the message will be delivered, but it

does not guarantee when it will be delivered. Delays may occur because of network interruptions or because the receiving application is simply not available. Therefore, this type of delivery is better termed “guaranteed … ultimately.”

The Road Less Traveled Messages can get out of sequence if they take different paths.

Worse yet, if an application sends two messages, the messaging system doesn’t guarantee that they’ll arrive in the same order. While a specific destination usually maintains the internal sequence of messages, individual messages may be routed through different paths and intermediate steps before arriving at their final destination. Some of these intermediate steps may take longer than others, resulting in out-of-order message delivery. For example, let’s assume that some messages on a queue must undergo additional transformation, while others are passed straight to the next queue. If the transformation is slow, the transformed messages will arrive later than the other messages.

Out-of-sequence delivery can be problematic if messages depend on each other or if an application is expecting responses to a specific request—not always can an application really “fire and forget.” In many cases, an application needs to receive a response to a request message it sent. Because destinations are unidirectional, the application receives responses on a different destination than the one on which it publishes requests. This means that the responses can arrive in a different order than the requests were sent. As a result, the application must explicitly correlate incoming response messages to the requests.

New Order An application must be prepared to correlate request and response messages.

The application could avoid having to deal with correlation by not sending another message until the response to the previous message arrives. This requires the application to block between each request and response message, thus eliminating many of the benefits of asynchronicity. Having the application make a single request at a time can be particularly detrimental, because making a request to a remote system is much slower than making a local method call.

Synchronous method calls never made you worry about these issues: The call stack ensured that after a method finished, processing automatically resumed with the calling method. In the asynchronous world, correlation is such a common need that the JMS API includes the methods getJMSCorrelationID and setJMSCorrelationID in the message interface.

The Message-Oriented Mind-Meld
The Java Messaging Service API offers a glimpse into the world of asynchronous messaging. As is so often the case, however, getting to know the classes and methods defined in the API is only a tiny step toward creating successful solutions. Designing, developing and testing message-based solutions requires rethinking some basic assumptions. In many ways, it’s comparable to the switch from procedural to object-oriented programming. OO design introduced a relatively small number of new concepts, such as classes, inheritance and polymorphism, but it took a long time and many books to get our arms around the patterns and best practices that describe good solutions using these concepts. Developers creating asynchronous messaging solutions find themselves in similar need of guidance for this new programming model. One good source may be design patterns, which document common solutions to recurring problems. A collection of design patterns on asynchronous messaging are available at www.enterpriseintegrationpatterns.com.

;