WebSphere MQ Everyplace allows flexibility in the way that applications process their messages. Messages can be transmitted synchronously or asynchronously.
An application does not need to know how or when its messages are transmitted, however it can take control of this process if it wishes, using synchronous messaging. Synchronous messaging means that the message is transmitted as soon as the put message command is issued. This type of messaging can only take place when both local and target queue managers are online simultaneously, and does not work if the queue manager is not connected to the network. Synchronous messaging offers the performance advantages of instant connection and the knowledge that a message has reached its destination.
Asynchronous messaging allows an application to continue processing messages, whether or not the device is connected to a network. The application puts a message to a remote queue definition, and the message is stored by the queue manager. The message is transmitted later when a connection is established to the remote queue manager. The application does not need to be aware of when the transmission takes place.
The typical example of asynchronous messaging is an application for a field engineer or salesman. The field personnel can send orders or inventories when it is convenient. The messages are stored locally until the device is physically connected to a network. When a connection is made, the messages can be transmitted.
For asynchronous transmission to occur, the queue manager must be triggered. The triggering is done either by an application calling the queue manager's mqeQueueManager_triggerTransmission() function.
The method of message transmission depends on how the remote queue is defined. A queue manager that is sending a message to a remote queue holds a definition of that queue. This definition is known as a remote queue definition. When a message is put to a remote queue, the local queue manager determines how to transmit the message using the remote queue definition.
Figure 9. WebSphere MQ Everyplace message flow
Messages are transmitted from the local queue manager to the remote queue manager using the authenticator, cryptor, and compressor that are defined on the remote queue. Before it can create a message channel between the two queue managers, the local queue manager needs to know the remote queue attributes. The local queue manager keeps this information as part of its remote queue definition.
The two transmission styles handle this differently.
If an application puts a message to a remote queue and a definition of the remote queue is held locally then the remote queue definition is used to determine characteristics of the queue. If a definition is not held locally, queue discovery occurs. This local queue manager synchronously contacts the remote queue manager in an attempt to ascertain characteristics of the queue. The following characteristics are discovered:
After successful discovery of a queue, the definition of the queue is stored as a remote queue definition on the queue manager that initiated the discovery. This discovered queue definition is treated like a normal remote queue definition. The Queue_Mode is not discovered as all discovered queues are set for synchronous operation.
Asynchronous transmission is not able to request information from the target queue manager. Therefore, a remote queue definition must exist before asynchronous transmission can occur. Remote queue definitions can be created using WebSphere MQ Everyplace administration messages (see Administering messaging resources).
The combination of synchronous and asynchronous messaging allows WebSphere MQ Everyplace to cope with unreliable communications links. If a putMessage fails on a synchronous queue, then you have the opportunity to put the message to an asynchronous queue. An example of this is shown below. By defining two queues the application can handle a situation where synchronous transmission is not possible.