There are several different types of queue class that you can use in an WebSphere MQ Everyplace environment. The types that are available in the WebSphere MQ Everyplace development package are:
Queues may have characteristics, such as authentication, compression, and encryption. These characteristics are set using attributes, and are used when a message object is stored on a queue.
The simplest type of queue is a local queue. These are real queues that are the final destination for all messages. This type of queue is local to, and owned by, a specific queue manager. Applications on the owning queue manager can interact directly with the queue to store messages in safe and secure way (excluding hardware failures or loss of the device). These queues can be used on a standalone queue manager, or on a queue manager that is connected to a network.
The queue owns access and security and may allow a remote queue manager to use these characteristics (when connected to a network). This allows others to send or receive messages to the queue.
For more detailed information about local queues, see Local queue.
A remote queue is a local queue belonging to a queue manager on another machine. A remote queue definition is a proxy for a local queue belonging to a queue manager on another machine. This remote queue definition exchanges messages with the remote local queue.
You can access remote queues either synchronously or asynchronously. If there is a local definition of the remote queue, the mode of access is based on the definition. In this case, the mode of access may be either synchronous or asynchronous. However, if there is no local definition, queue discovery occurs. WebSphere MQ Everyplace retrieves the characteristics (authentication, cryptography, and compression) from the real queue, and forces the mode of access to synchronous.
For more information on remote queues, see Remote queue.
A store-and-forward queue stores messages on behalf of other queue managers until they are ready to receive them. This type of queue is normally defined on a server and can be configured to perform either of the following:
Store-and-forward queues can hold messages for many target queue managers, or there may be one store-and-forward queue for each target queue manager. For more detailed information about store-and-forward queues, see Store-and-forward queue.
This type of queue usually resides on a client and points to a store-and-forward queue on a server known as the home-server. The home-server queue pulls messages from the home-server store-and-forward queue when the client connects on the network.
Home-server queues normally have a polling interval that causes them to check for any pending messages on the server while the network is connected.
When this queue pulls a message from the server, it uses assured message delivery to put the message to the local queue manager. The message is then stored on the target queue.
For more detailed information about home-server queues, see Home-server queue.
This type of queue is always defined on an WebSphere MQ Everyplace gateway queue manager and provides a path from the WebSphere MQ Everyplace environment to the WebSphere MQ environment. The WebSphere MQ-bridge queue is a remote queue definition that refers to a queue residing on a WebSphere MQ queue manager.
Applications can use put, get, and browse operations on this type of queue, as if it were a local WebSphere MQ Everyplace queue.
For more detailed information about the WebSphere MQ-bridge queue, see WebSphere MQ-bridge queue.
WebSphere MQ Everyplace has a similar dead-letter queue concept to WebSphere MQ. Dead-letter queues store message that cannot be delivered. However, there are important differences in the manner they are used.
The use of dead-letter queues with an WebSphere MQ-bridge needs special consideration, see Handling undeliverable messages for more details.
The administration queue is a specialized queue that processes administration messages.
Messages put to the administration queue are processed internally. Because of this applications cannot get messages directly from the administration queue. Only one message is processed at a time, other messages that arrive while a message is being processed are queued up and processed in the sequence in which they arrive.