Aliases can be used for WebSphere MQ Everyplace queue managers, and can be used by application programs, to provide a level of indirection between the application and the real object.
The following examples illustrate some of the ways that aliasing can be used with queue managers.
Suppose you have a queue manager SERVER23QM on the server SAMPLEHOST, listening on port 8082. You have an application SERVICEX that accesses this queue manager, and wants to refer to the queue manager as SERVICEXQM. This can be achieved using an alias for the queue manager as follows:
The server-side application takes messages from this queue, and process them, sending messages back to the client.
A WebSphere MQ Everyplace application can now put messages to the SERVICEXQ on either the SERVER23QM queue manager, or the SERVICEXQM queue manager. In either case, the message will arrive on the SERVICEXQ.
Figure 8. Addressing a queue manager with two different names
If the SERVICEXQ queue is moved to another queue manager, the connection alias can be set up on the new queue manager, and the applications do not need to be changed.
Using this method of routing, the receiving queue manager does not know that the sending queue manager has given him an alias name. The aliasing is confined to the sending queue manager only.
On the mobile device:
If the Mobile58QM then wished to send its messages to a different server queue manager, Server24QM, it would remove the alias SERVICEXQM from the Server23QM connection, and add it to a Server24QM connection. This has no impact on the receiving queue managers, or the sending applications.
Figure 9. Addressing a queue manager with two different names
Using this method, the sending queue managers think that its messages are routed through an intermediate queue manager before reaching the target queue manager. The target queue manager doesn't actually exist. The 'intermediate' queue manager captures all the message traffic for this virtual target queue manager.
On the mobile device:
The via routing on the mobile device causes any messages that are put to SERVICEXQM to be directed to Server23QM. Server23QM gets the messages and notes that they are destined for the SERVICEXQM queue manager. It resolves the SERVICEXQM name and finds that it is an alias which represents the Server23QM queue manager (itself). The Server23QM queue manager then accepts the messages and puts them onto the queue.
Figure 10. Addressing a queue manager with two different names
As an alternative to the above, you can keep the SERVICEXQM in existence, but move it from its original machine to the same machine (but a different JVM) as the Server23QM queue manager. SERVICEXQM needs to listen on a different port, so the connection from Server23QM to SERVICEXQM needs to be changed as well.