Share via


Message Queuing Applications

 

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

Message Queuing applications can be divided into two categories: sending applications, which send messages to queues, and receiving applications, which read messages in queues and can remove messages from queues. The following illustration shows several sending applications sending messages to a queue and several receiving applications reading the messages in the queue. (Using the directory service is not required; messages can be sent to the queue and read from the queue without accessing the directory service.)

<No Change>

Sending Applications

Sending applications send messages to a queue, not to the receiving application. Using a queue as the destination allows the sending application to operate independently of the receiving application.

Developers have several options to consider when designing sending applications:

  • Transactional messages versus nontransactional messages. Sending a transactional message can be included with other operations—such as updating a database or sending one or more other transactional messages—in an atomic process that can be aborted if any part of the transaction fails. Transactional messages guarantee exactly-once and in-order delivery. Conversely, nontransactional messages cannot guarantee exactly-once or in-order delivery.

  • Express delivery versus recoverability. A message may be routed through several computers before it reaches its destination. Recoverable messages can be delivered even if one of these computers crashes. This is because a copy of the message is stored locally on disk on the sending computer and on every computer that forwards the message during routing until the message is delivered to the next computer. After delivery to the destination queue, recoverable messages are stored on disk in memory-mapped files until they are received. Express messages, on the other hand, are stored only in volatile memory on the sending computer, during routing, and after delivery to the destination queue. As a result, if the computer where the message resides crashes or reboots, the message is not available when the computer restarts. Similarly, an express message delivered to a queue on a virtual server in a cluster will be lost if the virtual server fails over before the message is received.

  • Direct routing versus store-and-forward routing. Direct messages are sent directly to the computer where the destination queue resides and do not access the directory service. Store-and-forward routing requires a connection to the directory service, and the path that the message takes is determined by Message Queuing.

  • Sending messages to a single destination versus multiple destinations. Message Queuing supports both sending messages to a single destination and sending messages to multiple destinations. MSMQ 3.0 provides support for sending messages to multiple destinations in the form of distribution lists, multiple-element format names, and multicast addresses.

  • Authenticated messages versus non-authenticated messages. Authenticated messages are digitally signed and authenticated by Message Queuing. When a message is authenticated, Message Queuing guarantees that no one has tampered with the message, and it verifies the identity of the sender.

  • Encrypted messages versus non-encrypted messages. Encrypted messages are encrypted before they leave the source computer to after the time when they reach the target computer. Information in non-encrypted messages can be read while the message is on the wire.

  • Online versus offline operations. When online, the sending application has access to information stored in the directory service. When operating offline, the sending application cannot make any calls that require access to the directory service.

Receiving applications

Receiving applications read the messages in the queue in two different ways. The receiving application can peek at a message in the queue, leaving the message in the queue, or it can retrieve the message, taking the message out of the queue.

Developers should consider the following when designing their receiving applications:

  • Local versus remote read. Messages should always be read locally. Reading messages remotely consumes a lot of resources.

  • Transactional versus nontransactional messages. The retrieval of a transactional message can be combined with other operations—such as retrieving one or more other transactional messages, sending one or more other messages, or updating a database—within a single transaction that can be aborted if any action in the transaction fails.

  • Synchronous versus asynchronous reading. The asynchronous reading of messages allows the receiving operation to continue its processing while it waits for the messages to be read from the queue. The synchronous reading of messages blocks processing until the messages are read from the queue or a time-out expires.

  • Peek versus retrieve. Peeking at message allows the receiving application to look at the message and leave a copy of the message in the queue. Retrieving messages from the queue removes the messages from the queue.

  • Online versus offline operations. When online, the receiving application has access to information stored in the directory service. When operating offline, the receiving application cannot make any calls that require access to the directory service.

For information on See
Options for sending messages Sending Messages
Network sessions for sending and reading messages Network Sessions
Transactions Transactions
Authenticated messages Message Authentication
Encrypted messages Message Encryption
Applications running under offline conditions Message Queuing Offline Support