WebSphere MQ Everyplace has a queue type that accepts messages on a queue manager basis rather than on a queue basis. These are called store-and-forward queues, S&F queues for brevity). S&F queues maintain a list of queue manager names, called 'Queue anager Entries', or QME for brevity. The S&F queue will accept messages for any queue manager represented by a QME. This acceptance is independent of the destination queue name, and so allows one queue (the S&F queue) to route all messages for a given, or several given queue managers.
S&F queues can operate in two modes, pushing mode and pulling mode. In pushing mode the messages are moved to the next queue manager just as with remote queue references. In pulling mode the messages are removed from the S&F queue by the action of a home server queue. This section deals only with the pushing of messages, pulling messages with a home server queue is described in another section. A typical pushing S&F queue system might look like Figure 65.
Figure 65. A typical pushing S&F queue system.
A S&F queue called SafQueue has a queue manager entry (QME) for TargetQM. This allows it to accept messages for any queue on TargetQM. In common with ordinary Remote Queues, a Store and Forward queue requires a connection definition/listener pair set up in order to push messages. Unlike a normal Remote Queue Definition, a Store and Forward Queue effectively pushes to a Queue Manager rather than to a queue. The message arrives at the Queue Manager, where queue resolution is performed. When a message is put to LocalQM addressed to TargetQ@TargetQM the resolution is as follows, see Figure 66.
Figure 66. Routing of a message put to LocalQM and addressed to TargetQ@TargetQM
The Store and Forward queue forms part of a Multi Message Route. This abstract entity represents the potential for messages addressed to any queue on TargetQM, and so is called *@TargetQM, see Figure 67.
Figure 67. A multi message route.
If there is no queue to which the message can be put, then it is not delivered. This prevents any further messages from being pushed from that Store and Forward queue to that Queue Manager.
Because S&F queues can accept messages for any queue on a given queue manager, they can appear to be in conflict with a remote queue reference. In such cases the remote queue reference takes precedence, because it is more specific. So if we look again at our S&F queue resolution, but add a remote queue reference we can see that the message route resolution changes immediately, the S&F queue becomes irrelevant. We can see this in Figure 68
that queue resolution finds the best (most exact) match for the message address.
So a message put to QueueAlias@TargetQM goes via the S&F queue (asynchronous transmission), but a put to TargetQueue@TargetQM goes synchronously via the remote queue reference.
Pushing store and forward queues can be chained together into a more complex route, see Figure 69.
Figure 69. Pushing S&F queues chained together.
Note that the Store and Forward queue on LocalQM (SaFQueue@RemoteQM) has a Queue Manager Entry for TargetQM, but actually pushes to RemoteQM. LocalQM requires a connection definition to RemoteQM, but not to TargetQM. A message can then be transported via the intermediate S&F queue, see Figure 70.
Figure 70. Transporting messages via an intermediate S&F queue.
This works because the combination of queue resolution and connection resolution on LocalQM results in the message being put to the S&F queue on RemoteQM, which can then move it to its destination. The chain of Store and Forward Queues could be arbitrarily long, with each queue manager in the chain needing to know only about the next queue manager in the chain. The Message Routes express this very succinctly, see Figure 71.
Figure 71. A chain of store and forward queues.