Designing with JAXM

Architecturally, JAXM-based messaging applications fall into two broad categories, which determine the messaging capabilities the application can support: applications that do not use a JAXM provider (synchronous messaging) and those that use a JAXM provider (asynchronous messaging). We will now look at these in further detail and the type of business use cases each category can address.

Synchronous Messaging

Without a provider, messaging requires simultaneous engagement of both endpoints of the exchange. This is called synchronous request-response (or point-to-point) messaging (Figure 11.21) and was described in Chapter 10. The client sends a message and blocks until a reply or fault is received from the service. It cannot do any other work while awaiting the response. This is analogous to making a phone call. Either someone responds by picking up the handset on the other end, or a busy tone is received.

Figure 11.21: Point-to-point messaging from a client without a provider

At a lower level, synchronous communication between a message sender and receiver falls into two categories:

• Synchronous with response. The sender is blocked till the response to the message is received (Figure 11.22). This usually implements use cases corresponding to a read-only messaging pattern called synchronous-inquiry, in which data on the receiver's side is not changed as a result of the invocation. For example, the request contains a purchase order. The service processes that order and returns an invoice and shipping details.

  
  Figure 11.22: Synchronous messaging with response

• Synchronous with acknowledgment. The receiver does not send a response but sends more of a "got it" acknowledgment (Figure 11.23). The client remains blocked until it receives the acknowledgment, which may not even relate to the original message (but usually does). Its purpose is to notify the client that the message was received and to unblock the calling thread. This is often used to implement use cases corresponding to a synchronous-update messaging pattern. This involves changing business data that may potentially be used by other services or consumers on the receiver's side. For example, the request contains a change of address form, and the service responds by acknowledging that it was received.

  
  Figure 11.23: Synchronous messaging with acknowledgment

Asynchronous Messaging

An application that use an underlying JAXM provider can provide support for both synchronous and asynchronous messaging, because the provider acts like a MOM or message broker. In asynchronous messaging (Figure 11.24), the client sends a message and continues processing without waiting for a return. Based on some a priori agreement (such as a predefined and agreed-upon endpoint), the service sends a response to the client. There is no requirement on the time frame or other physical aspects (such as using the same transport or connection).

Figure 11.24: Provider roles in asynchronous messaging

This is analogous to making a phone call and getting an answering machine. The caller leaves a message and continues. The person on the other end gets the message and returns the call by dialing the number left on the machine or a number he or she already knows.

This gives rise to the problem of co-relation, or how to relate a response to a previously sent request. This problem does not exist with synchronous messaging per se. JAXM does not specify how this co-relation is built, relying on the messaging profile layer for it.

At a lower level, asynchronous communication between a message sender and receiver falls into two categories:

• Asynchronous with response. The client sends a message to the recipient and expects a response. However, it does not wait for the response to arrive and continues doing other work (Figure 11.25). The recipient asynchronously sends a reply to the sender when it has done the work on its side, with no time limitation on its doing so. This often implements use cases corresponding to an asynchronous inquiry messaging pattern. This is a read-only operation; data on the receivers side is unchanged.

  
  Figure 11.25: Asynchronous messaging with response

• Asynchronous with acknowledgment. This is similar to asynchronous with response, with the difference that the message consumer sends a confirmation or acknowledgment to the sender (Figure 11.26) correlated to a request previously sent. The semantics of the correlation are not specified by JAXM and are typically at the profile level. This usually implements use cases corresponding to an asynchronous-update messaging pattern, where business data that may potentially be used by other consumers undergoes some mutation on the receiver's side.

  
  Figure 11.26: Asynchronous messaging with acknowledgment

• One-way messaging. The client sends a message and does not block or wait to receive a reply (Figure 11.27). It is free to do other work. This is analogous to sending a fax (fire and forget!) A number is dialed and a fax sent. You do not need a person to answer the other phone (just a fax machine). This also implements use cases corresponding to an asynchronous-update pattern, in which data on the receiver's side is updated with new values.

  
  Figure 11.27: Asynchronous one way messaging

In the asynchronous application models, an analogy can be drawn between the messaging provider and an email server that we looked at with JavaMail earlier. A mail is sent, and one may or may not receive a response or acknowledgment, depending on the details of the message and how the system is configured.

A message sender and consumer (or client and server) are more logical views than physical entities in an architecture. An application using a JAXM provider can function in a client as well as service role, meaning it is capable of switching between a message sender and message consumer. An application that does not use a JAXM provider can support only a client role and can send messages only synchronously (such applications are also referred to as standalone JAXM clients).

We have looked at five design approaches (two synchronous and three asynchronous). The decision on where and when to use a provider depends on which of the five use cases models the business requirement accurately. Most asynchronous messaging environments can also operate in synchronously if necessary, which explains the popularity of message-oriented middleware as the underlying mechanism. Most businesses work both asynchronously and synchronously, and it is useful to have a single medium that supports both.

For example, a car rental company offering online reservations may choose to process credit cards asynchronously in batches for frequent customers with gold memberships, because bulk authorizations are cheaper. and these customers have established their creditworthiness. It may also choose to authorize cards synchronously for new customers before completing a reservation. It is useful to have a single underlying design that can support both these business requirements, which provider-based architecture offers. It also simplifies application development for architects, because they no longer need to account for different transports based on the business's requirements at a particular time.