Bridge queue

An MQ bridge queue definition can contain the following attributes.

Table 1. MQ bridge queue properties
Property Explanation
Alias names Alternative names for the queue
Authenticator Must be null
Class Object class
Client connection Name of the client connection service to be used
Compressor Must be null
Cryptor Must be null
Expiry Passed to transformer
Maximum message size Passed to the rules class
Mode Must be synchronous
MQ queue manager proxy Name of the MQ queue manager to which the message should first be sent
MQ bridge Name of the bridge to convey the message to MQ
Name Name by which the remote MQ queue is known to MQe
Owning queue manager Queue manager owning the definition
Priority Priority to be used for messages, unless overridden by a message value
Remote MQ queue name Name of the remote MQ queue
Rule Rule class used for queue operations
Queue manager target MQ queue manager owning the queue
Transformer Name of the transformer class that converts the message from MQe format to MQ format
Type MQ bridge queue

More detail of each property can be found in the Java Programming Reference, in the administration class com.ibm.mqe.mqbridge.MQeMQBridgeQueueAdminMsg.

Example code which manipulates a bridge queue can be found in the Java™ class examples.mqbridge.administration.programmingAdminHelperBridgeQueue.

Note: The cryptor, authenticator, and compressor classes define a set of queue attributes that dictate the level of security for any message passed to this queue. From the time on MQe that the message is sent initially, to the time when the message is passed to the MQ bridge queue, the message is protected with at least the queue level of security. These security levels are not applicable when the MQ bridge queue passes the message to the MQ system, the security send and receive exits on the client connection are used during this transfer. No checks are made to make sure that the queue level of security is maintained.

MQ bridge queues are synchronous only. Asynchronous applications must therefore use either a combination of MQe store-and-forward and home-server queues, or asynchronous remote queue definitions as an intermediate step when sending messages to MQ bridge queues.

Applications make use of MQ bridge queues like any other MQe remote queue, using the putMessage, browseMessages, and getMessage methods of the MQeQueueManager class. The queue name parameter in these calls is the name of the MQ bridge queue, and the queue manager name parameter is the name of the MQ queue manager. However, in order for this queue manager name to be accepted by the local MQe server, a connection definition with this MQ queue manager name must exist with null for all the parameters, including the channel name.

Note: there are some restrictions on the use of getMessage and browseMessages with MQ bridge queues. It is not possible to get or browse messages from MQ bridge queues that point to MQ remote queue definitions. Nor is it possible to use nonzero Confirm IDs on MQ bridge queue gets. This means that the getMessage operation on MQ bridge queues does not provide assured delivery. If you need a get operation to be assured, you should use transmission-queue listeners to transfer messages from MQ.

Administration of the MQ bridge is handled in the same way as the administration of a normal MQe queue manager, through the use of administration messages. New classes of messages are defined as appropriate to the queue.


Terms of use | WebSphere software

(c) Copyright IBM Corporation 2004, 2005. All rights reserved.