Share via

Message Queuing Features

  • Article

Applies To: Windows Server 2008

Message Queuing features

Following is a summary of the major features of Message Queuing 4.0:

  • Subqueues. New in Message Queuing 4.0, subqueues are implicitly created local queues that are logical partitions of a physical queue. Applications can use subqueues to group messages. The subqueues feature enables you to logically group messages in a queue without creating another physical queue. For more information see Subqueues.

  • Move messages. New in Message Queuing 4.0, move message functionality allows you to 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. For more information see Move Messages.

  • Per-application dead-letter queues. In Message Queuing 3.0, there is a system transactional dead-letter queue. If one or more applications are sending messages and requesting dead-letter handling, they each use the same system transactional queue. This can result in a bottleneck. It is also hard to determine which dead messages belong to which application because all applications share the same dead letter queues.

    Message Queuing 4.0, however, introduces 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 (https://go.microsoft.com/fwlink/?LinkId=69583).

  • Transactional remote receive. New in Message Queuing 4.0, transactional remote receive is a transactional receive of a message from a remote queue. Transactional remote receive capability may simplify or enable certain message processing scenarios. 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. For more information about Transactional messaging see Transactional Messaging.

  • Enhanced poison message handling functionality (new for MSMQ 4.0). Message Queuing 4.0 includes additional new features, such as move count and abort count, which enable poison message–handling scenarios. These are described in the Message Queuing Software Development Kit (SDK) documentation. For more information, see What's New in Message Queuing 4.0 (https://go.microsoft.com/fwlink/?LinkId=68744)

  • Delivering messages over HTTP transport. SRMP (SOAP Reliable Messaging Protocol), an XML-based messaging protocol, can be used for delivering high Quality of Service (QoS) messages. The direct, public, and private format names of administration and response queues can be included in messages sent over HTTP transport. Similarly, the names of administration and response queues in HTTP format can be included in messages sent over ordinary (non-HTTP) transport. For more information about these features, see HTTP/HTTPS messages. For more information about format names, see Queue Names.

  • Triggers. Triggers provides a mechanism that associates the arrival of each incoming message at a queue with a response that depends on the contents of the message and may invoke either a COM component or a stand-alone executable program. Business rules can be defined and invoked in response to such messages without any additional programming. For more information about this feature, see Triggers.

  • Sending messages to multiple destinations. MSMQ clients are able to send the same message to multiple recipient queues. Lists of destination queues can be specified explicitly by means of distribution group objects (distribution lists) in Active Directory Domain Services as well as in the form of multiple-element format names. Support for ensuring that messages sent to distribution lists and multiple-element format names will reach queues on downlevel computers is provided. In addition, message delivery to IP multicast destinations using the PGM protocol is supported. For more information about these features, see Multiple Destination Messaging.

  • Message lookup. Message Queuing 4.0 provides a way to peek at or retrieve a specific message without using cursors to navigate through the queue until the message sought is located. This functionality is based on a 64-bit lookup identifier that is assigned to each message when it is placed in a destination queue. For more information, see Messages.

  • Directory Service Integration. Message Queuing 4.0 provides functionality to integrate with Active Directory Domain Services to store all configuration, security, and status information. Message Queuing clients use the Lightweight Directory Access Protocol (LDAP) to access domain controllers and global catalog servers for Message Queuing-specific information in Active Directory Domain Services directly without assistance from a Message Queuing server on a domain controller.

  • Workgroup support. Message Queuing can be installed in workgroup mode on computers belonging to a Windows Vista®, Windows Server® 2008 or Windows Server 2003 workgroup, rather than to a domain. In addition, a computer on which Message Queuing is installed in a workgroup can later join a domain, and then separate from the domain. For more information about belonging to a workgroup or a domain, see Deploying in a Domain Environment and Deploying in Workgroup Mode.

  • Active/active cluster support. Message Queuing 4.0 fully supports the active/active paradigm in a server cluster, which means that Message Queuing can run on all nodes in a server cluster simultaneously. Message Queuing triggers are also integrated with active/active cluster support. For more information about the active/active model in server clusters, see Message Queuing Architecture.

  • Windows CE support. A special version of a Message Queuing client is preinstalled on handheld and palm-sized computers running the Windows CE 3.0 (or later) operating system. Windows CE supports the Message Queuing SRMP protocol, for HTTP messaging.

  • Message backup and restore. Message storage files, log files, transaction log files, and registry settings can be backed up and restored in case of computer failure. For more information, see Back Up and Restore Messages.

  • Message prioritization. Message prioritization allows urgent or important messages to be sent before less important messages, so you can guarantee adequate response time for critical applications at the expense of less important applications. For more information about sending messages with different priorities, see Message Priority.

  • Guaranteed message delivery. Messages can be stored on a disk-based queue, and then later forwarded to provide guaranteed delivery.

  • Sending messages within transactions. Using transactional capabilities, you can couple several related actions in a single transaction, ensure messages are delivered in order, ensure messages are delivered only once, and confirm that messages were successfully retrieved from the destination queue. For more information about sending messages within transactions, see Transactional Messaging.

  • Dynamic queue creation. You can create queues or change queue properties on the fly without affecting messaging applications.

  • Message routing. Message Queuing provides message routing based on the physical topology of the network, session concentration needs, and transport connectivity. Session concentration facilitates the efficient usage of slow communication links. For more information about this subject, see Routing with Message Queuing Servers.

  • Cross-platform integration. Message Queuing can be used across a wide variety of hardware platforms using connectivity products provided by other vendors. For more information about messaging with different platforms, see Cross-Platform Messaging.

These features make Message Queuing ideal for the implementation of semi-independent client/server systems (such as order entry, accounting, and inventory applications), batch processing, queue-based client/server systems (first-come, first-served resource access), and for migration from legacy systems.