Destination Queues

Applies To: Windows 10, Windows 7, Windows 8, Windows 8.1, Windows Server 2008, Windows Server 2008 R2, Windows Server 2012, Windows Server 2012 R2, Windows Server Technical Preview, Windows Vista

Destination queues are any application queue that is used to store messages sent from an application. Typically, the destination queue is a local queue on a server. Client applications send messages to the destination queue on the server computer (in this case the server computer can also be referred to as the target computer), and the server applications process the messages after they arrive.

The following illustration shows a single destination queue used by two applications. The sending application on the client computer sends the message to the queue and the receiving application on the server computer reads the messages from the queue. Typically, destination queues are located on the same computer as the receiving application in order to minimize network traffic.

Destination queues can be public or private, and they can be transactional or nontransactional. When designing a distributed Message Queuing application, you must decide if the destination queues should be public or private queues, and whether the public or private queues used should be transactional or nontransactional. Whether a queue is public, private, transactional, or nontransactional is specified when the queue is created.

Public Versus Private Queues

The decision to use public or private destination queues depends primarily on whether you want other applications to be able to locate the queues.

The advantage of public destination queues is that they are registered in the directory service, where they can be located by other Message Queuing applications. Public queues are persistent, and their registration information can be backed up on the enterprise, making them good for long-term use.

Private queues are registered on the local computer, not in the directory service, and their properties cannot be obtained by Message Queuing applications running on remote computers. Message Queuing registers private queues locally by storing a description of each queue in a separate file in the local queue storage (LQS) folder on the local computer (the default Lqs folder is %windir%\System32\MSMQ\Storage\Lqs in MSMQ 2.0 and later, and \Program Files\MSMQ\Storage\Lqs in MSMQ 1.0). Note that a description of each public queue created on the local computer is also stored locally in a separate file in the Lqs folder.

Private queues have the advantage of minimal directory service overhead (faster to create, no latency, and no replication). Local private queues can be created and deleted when the directory service is not working, making private queues attractive for offline operations, where the directory service may not be available.

There is no need to query the directory service before accessing private queues designated by direct format names. However, in domain mode, when a remote private queue is designated by a private format name in a call to send or receive a message, a query is made to the directory service to convert the computer GUID to a computer name. Similarly, when a call is made to create a local private queue on a computer operating in domain mode, a query is sent to the directory service to obtain the security descriptor of the MSMQ-Configuration object, which the local Message Queuing service uses to verify that the user is allowed to create a queue.

When a message is sent in domain mode to a remote private queue designated by a private format name, the directory service is queried before the message is placed in the queue, but offline operation is supported. However, an attempt to receive a message from a remote private queue designated by a private format name fails at once if the directory service cannot be queried.

Private queues can be exposed to other applications by making the location of the private queue known to the applications. To distribute the location of a private queue, an application can send the format name of the private queue as the response queue property of a message.

Transactional Versus Nontransactional Queues

The decision to use transactional or nontransactional queues is based on whether the applications accessing the queue will be sending and receiving messages within the context of a transaction.

When sending messages, only transactional queues can accept messages sent in the context of a transaction. These messages are also referred to as transactional messages. In a similar way, nontransactional queues can only accept messages sent outside the context of a transaction. Note that only transactional messages are delivered with exactly-once-delivery (EOD) guarantees.

When receiving messages, only local transactional queues can be accessed within the context of a transaction. The transactional queue must be local to the receiving application. On the other hand, nontransactional queues can be accessed within or outside of a transaction. Also, transactional queues, local or remote, can be accessed outside of a transaction.