|
|
Architecturally, JAXM-based messaging apps fall into two broad categories, which determine the messaging capabilities the app can support: apps 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.
Without a provider, messaging requires simultaneous engagement of both endpoints of the exchange. This is called synchronous request-response (or point-to-point) messaging (Screenshot) and was described in . 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.
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 (Screenshot). 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. 
Screenshot: Synchronous messaging with response
An app 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 (Screenshot), 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).
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 (Screenshot). 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. 
Screenshot: Asynchronous messaging with response
In the asynchronous app 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 app 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 app that does not use a JAXM provider can support only a client role and can send messages only synchronously (such apps 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 app development for architects, because they no longer need to account for different transports based on the business's requirements at a particular time.
|
|