Earlier in this document we described Queue Manager Aliases and said that they had a more important part to play in routing. To illustrate, we consider an example of a common situation often known as fail-over. In this we have a client communicating with a server, and we have a backup server that can be used if the main server fails, or is taken down for maintenance, see Figure 79.
Figure 79. Queue manager aliases and fail-over.
Here we see the local client queue manager, with a connection to ServerQM and a remote queue definition for TargetQueue@ServerQM. The server (bottom left) has a local queue as the target for our example message, and this is mimicked by the backup server (bottom right). Additionally, on the client queue manager, there is a Queue Manager Alias mapping the name Server to ServerQM. This mapping is then used for messages put to the server. The message resolution is shown below for the normal operating configuration, where a message put to TargetQueue@Server is directed to TargetQueue@ServerQM, see Figure 80.
Figure 80. Routing traffic using a "server" alias
The alias maps messages for Server to ServerQM, and this selects the remote queue definition TargetQueue@ServerQM. If the network administrator needs to route traffic to the backup server, only the Queue Manager Alias needs to be changed (it is in fact deleted, and recreated with a different target name, in this case BackupQM, see Figure 81).
Figure 81. Routing traffic to the backup server, using a "server" alias
The change of alias reroutes the message to a different remote queue, and hence on to the backup queue manager and to TargetQueue@BackupQM. In essence what we have is a pair of message routes, one to each server, and we are using a Queue Manager Alias to choose between the message routes, see Figure 82.
Figure 82. Choosing between message routes.
The example above required a change to every client on a system that requires rerouting to a backup server. If there are a large number of clients this may be impractical. In addition, each client requires two complete message route definitions (a remote queue and a connection definition for each). It would be far more elegant to avoid the need to change the client. We can do this by having a second server ready to listen on the same address and port as the first. When the administrator wishes to change over the first can be brought down, and the second can change over. In this circumstance it may be convenient to keep the names of the servers different. The backup server can be given a Queue Manager Alias mapping BackupQM to ServerQM. This will allow BackupQM to impersonate ServerQM.
Warning |
---|
Changing the WebSphere MQ Everyplace network topology in this fashion is not always a wise thing to do. Care must be taken to ensure that there are no 'in doubt' messages that would be affected by the change. If a message is put with a non-zero confirm id, and then the WebSphere MQ Everyplace network topology is changed to alter the routing of the subsequent confirmGetMessage call, then the unconfirmed message will not be found. WebSphere MQ Everyplace protocol treats a failure to confirm a put as an indication that the put message has been confirmed already, and therefore assumes success. This could leave an unconfirmed message on a queue, which represents a loss of a message, and therefore breaks the assured delivery promise. Since WebSphere MQ Everyplace uses the same two step process to assure delivery of asynchronously sent messages, changing the network topology can break the assured delivery of asynchronous message sends. |