Message Queuing Overview
Applies To: Windows Server 2008 R2
Message Queuing (also known as MSMQ) is a messaging infrastructure and a development tool for creating distributed messaging applications for Microsoft Windows. Applications developed for Message Queuing send messages to queues, which are temporary storage locations, from which messages can proceed to their final destination as conditions permit. Such applications can communicate across heterogeneous networks and can send messages between computers that might be temporarily unable to connect to one another. Message Queuing provides the following benefits:
Guaranteed message delivery
Support for sending messages within transactions
Software products with these features are often referred to in the industry as:
With Message Queuing, end users can communicate across networks and computers that might be offline, regardless of the current state of the network and computers. System administrators can use Message Queuing to efficiently manage large, complex networks of computers and message queues.
This topic describes the features that are available with Message Queuing.
Message Queuing Server
This feature is the core component of Message Queuing, which enables you to perform basic Message Queuing functions. For more information about the Message Queuing Server feature, see What is Message Queuing (http://go.microsoft.com/fwlink/?LinkId=93512).
Directory Service Integration
This feature enables publishing of queue properties to Active Directory, out-of-the-box authentication and encryption of messages using certificates registered in Active Directory, and routing of messages across sites. For more information about the Directory Service Integration feature, see Directory Service Integration Feature (http://go.microsoft.com/fwlink/?LinkId=93513).
Message Queuing Triggers
This feature enables the invocation of a COM component or an executable depending on the filters that you define for the incoming messages in a given queue. For more information about the Message Queuing Triggers feature, see Triggers Overview (http://go.microsoft.com/fwlink/?LinkId=93514).
This feature enables the sending and receiving of messages over HTTP. For more information about the HTTP Support feature, see Internet Messaging (http://go.microsoft.com/fwlink/?LinkId=93515).
This feature enables queuing and sending of multicast messages to a multicast IP address. For more information about the Multicasting Support feature, see IP Multicasting (http://go.microsoft.com/fwlink/?LinkId=93516).
This feature routes messages between different sites and within a site. For more information about the Routing Service feature, see Message Queuing Routing at (http://go.microsoft.com/fwlink/?LinkId=93517).
Message Queuing DCOM Proxy
This feature enables the MSMQ DCOM API to connect to a remote Message Queuing server.
This feature enables you to logically group messages in a queue without creating another physical queue. Subqueues are implicitly created local queues that are logical partitions of a physical queue. Applications can use subqueues to group messages.
You can move messages in one of three ways:
Using the Move Message dialog box.
Performing a cut-and-paste operation.
Performing a drag-and-drop operation.
You can move messages between subqueues of the same main queue, or from a main queue to its subqueue. You cannot move messages from a main queue to a subqueue of a different main queue or between two main queues or between two subqueues of different main queues.
The message is moved as is, from the source queue to the target queue. The properties of the message remain unchanged, except for the current move count.
Per-Application Dead-Letter Queues
Message Queuing 4.0 introduced per-application dead-letter queues, so that each application can use its own dead-letter queue. An application can request its own dead-letter queue by using the PROPID_M_DEADLETTER_QUEUE property as part of the message. Instead of being sent to the system transactional dead-letter queue, the message is sent to the queue that is specified in the PROPID_M_DEADLETTER_QUEUE property.
The PROPID_M_DEADLETTER_QUEUE can be set to any legal path of a transactional queue. The transactional queue must be local to the queue manager that will move the negative acknowledgment (NACK) message to the queue. A legal path is defined in Queue Path Names (http://go.microsoft.com/fwlink/?LinkId=69583).
Transactional Remote Receive
Transactional remote receive is a transactional receive of a message from a remote queue. There are scenarios where a transactional remote receive is necessary. For example, when work orders from a remote central queue need to be processed across a farm of application servers, a transactional remote receive will enable the message processing to be load-balanced across the server farm.
Ability to Handle a Large Number of Message Queuing Queues
The following new feature is introduced in Message Queuing 5.0, released with Windows 7 and Windows Server 2008 R2:
Message Queuing 5.0 provides functionality to handle a significantly larger number of queues than Message Queuing 4.0. While Message Queuing 4.0 does not impose a specific limit on the number of queues that can be created, performance is negatively impacted if several thousand queues are created. Specifically, start up time of the Message Queuing 4.0 services is greatly increased when loading a very large number of queues into memory because of the queue lookup algorithm that is used. The queue lookup algorithm used by Message Queuing 5.0 at start up has been optimized to dramatically improve start up performance of Message Queuing when a very large number of queues are hosted on the system.
Message Queuing Features (http://go.microsoft.com/fwlink/?LinkId=93518)