A figure shows the basic mechanism of program-to-program communication using an asynchronous communication model.

Using the asynchronous model, Program A puts messages on Queue 1 for Program B to process, but it is Program C, acting asynchronously to Program A, which gets the replies from Queue 2 and processes them. Typically, Program A and Program C would be part of the same application. You can see the flow of this activity in Figure 1.

Figure 1. Asynchronous application design model

The asynchronous model is natural for WebSphere® MQ. Program A can continue to put messages on Queue 1 and is not blocked by having to wait for a reply to each message. It can continue to put messages on Queue 1 even if Program B fails. If so, Queue 1 stores the messages safely until Program B is restarted.

In a variation of the asynchronous model, Program A could put a sequence of messages on Queue 1, optionally continue with some other processing, and then return to get and process the replies itself. This property of WebSphere MQ, in which communicating applications do not have to be active at the same time, is known as time independence.