In the context of Message Queuing, queues are temporary storage locations for different types of messages. Queues can be created by:
Queues that applications or administrators create are referred to as application queues. Queues that Message Queuing creates are known as System queues.
Message Queuing includes the following types of application queues:
Destination queues, including:
Public and private queues
Transactional and nontransactional queues
Public and private queues
In a domain environment, public queues are queues that are published in Active Directory Domain Services (AD DS) and hence are replicated throughout a forest. Only the properties for these queues are replicated, not the actual queues themselves or their contents. Any computer within your forest can potentially access information regarding public queues, provided the user has sufficient permissions to access the applicable queue objects. Generally speaking, any user in the forest with access to AD DS and the Send Message permission for a given public queue can send messages to it. This permission is granted by default when the queue is created. To read messages from a public queue, you must have the Peek Message or Receive Message permissions for the queue.
In an AD DS environment, defining public queues ensures that queues are registered in the directory service, and that their registration is backed up. They are persistent and available to other applications.
Private queues are queues that are not published in AD DS. They are displayed only on the local computer that contains them. Private queues have the advantage of no directory service overhead, which results in queues that:
Are quicker to create.
Have no latency when they are accessed.
Have no replication overhead.
In a workgroup environment, only private queues are available.
For a Message Queuing application on the local computer to access a private queue, the application only needs to know the path of the queue. For a Message Queuing application on a remote computer, the application requires a direct or private format name to access such a queue. To read messages from the queue, the remote Message Queuing application requires the Receive Message permission for that queue. By default, everyone has permissions to send messages to public and private queues.
Transactional and nontransactional queues
A transactional queue is one that only contains transactional messages, which are messages sent within a transaction. The requirements for sending and receiving messages are based on the type of queue used (transactional or nontransactional) and the queue's location (local or remote).
When using transactions to send messages, the messages can be sent to any transactional queue regardless of where the queue is located, but transactional queues can only accept messages sent in the context of a transaction. In a similar way, nontransactional queues can only accept messages sent outside the context of a transaction.
You can receive messages from a local or remote queue.
Subqueues are a new feature in Message Queuing 4.0. They allow applications to group messages. Subqueues are useful in the following scenarios:
Work order processing. If an application processes messages that contain items from different work orders, it can use the subqueues to group the line items by work order for more efficient processing.
Poison message handling. If an application receives a message that it cannot process at that time, it can move the message to a fault subqueue to be processed later.
Subqueues are implicitly created when they are opened. In other words, when a message is moved to a subqueue, this action essentially creates a subqueue if one does not already exist. Subqueues are deleted when empty, and they have no open handles. Applications cannot send messages directly to subqueues. They can only move messages to a subqueue. They can receive messages from subqueues, move them between a main queue and its subqueue, or move them between subqueues of the same main queue. They cannot move them from the subqueue of a main queue to the subqueue of a different main queue.
For example, in the following figure, messages can be moved back and forth between subqueue1 (or subqueue2) and the Queue messages folder of queuea. Messages can also be moved between subqueue1 and subqueue2. Similarly, messages can be moved back and forth between queuez and its subqueues, subqueue3 and subqueue4.
However, messages cannot be moved in either direction between queuea and subqueue3 or subqueue4, or between queuez and subqueue1 or subqueue2. Similarly, messages cannot be moved back and forth between the subqueues of queuea (subqueue1 or subqueue2) and the subqueues of queuez (subqueue3 or subqueue4).
Subqueues do not have their own properties or state. They share the properties of the main queue. For example, a subqueue does not have its own:
Access control list (ACL)
Subqueues share the quota of the main queue, and messages in the subqueue are factored into that quota.
Subqueues cannot be created under journal or other system queues, or other subqueues.
Administration queues are application-generated queues. They are used to store system-generated negative and positive acknowledgment messages that Message Queuing or connector applications create. They are specified programmatically in the original messages by the sending application. Any available nontransactional queue can be specified as an administration queue. Administration queues do not contain administrative messages, which are stored in internal private queues.
The system-generated acknowledgment messages returned to these queues can indicate whether a message arrived at its destination queue, whether it was retrieved from the destination queue, or both. Each acknowledgment message contains information that describes what triggered the acknowledgment and to which message the acknowledgment refers. When requesting acknowledgment messages, the sending application must specify the queue to be used as the administration queue and the acknowledgment level of the message. Typically, an administration queue is a local queue, so that the sending application can read the acknowledgment messages locally.
Like administration queues, response queues are application-generated. They are used to store application-generated response messages that are typically returned by an application that is reading messages from a queue. Response queues are specified programmatically by the sending application when a message is sent. Any available queue can be specified as a response queue. Response messages are not the same as administrative response messages, which are stored in an internal private queue.
The response messages returned to these queues must be understood by the application returning the response messages and the application reading the response messages. Message Queuing has no control over what information is sent in response messages. When requesting response messages, the sending application must specify the queues that it wants to use as response queues. Typically, response queues are local queues, so that the sending application can read the response messages locally.
When a response queue and an administration queue are both needed, their functionality can be combined into a single queue. However, because all administration queues must be nontransactional, this queue will accept only nontransactional messages.
Report queues are application-generated queues used to store report messages that Message Queuing or connector applications generate when the sending application requests tracing. The report messages indicate the route that a message took to its destination on a remote computer or the route that a test message took to a test queue on a remote computer. There can be only one report queue for each computer.
All report queues must have the following label and queue type identifier:
Label: MQReport Queue
Queue type identifier:
The Message Queuing administrator typically creates report queues by using Active Directory Users and Computers. However, an application can also generate them, if the correct label and queue type identifier are specified when the queue is created. Message Queuing uses the label and queue type identifier to locate and open the appropriate queue when sending report messages.
Message Queuing creates system queues. Applications can read the messages in system queues, but cannot address messages to them. Message Queuing provides different types of system queues, including:
Journal queues, which contain copies of all messages removed from a queue. Computer journals contain copies of all messages sent from a computer.
Internal private queues, which are used as interim queues for storing and forwarding messages in transit to a destination queue. These queues are not published in AD DS. Outgoing queues are local internal private queues, generated automatically to store messages sent to remote queues.
Dead-letter queues, which contain messages that cannot be delivered. Message Queuing provides a transactional dead-letter queue and a nontransactional dead-letter queue.
Connector queues, which are used for cross-platform messaging.
Outgoing queues, which are local internal queues that are used to store messages sent to remote queues. Messages can be stored in outgoing queues under offline conditions and then sent to target queues on remote computers when connectivity is re-established. These queues are generated automatically and cannot be created or deleted manually.
Perform the following procedures as needed to administer queues: