icrosoft .NET developers can use several tools to perform operations asynchronously; that is, beginning a process without waiting for the operation to complete. MSMQ has provided this facility to developers since its inception. It was especially useful for VB developers, because before MSMQ, there were very few options for managing an asynchronous process in VB. As awkward as it now seems, the most elegant solution involved using SQL Server tables to manage the 'queued' processes. Despite the multitude of tools available today for managing processes asynchronously, such as MSMQ, BizTalk, and other .NET-specific mechanisms, many developers continue to use SQL Server. This article provides an overview of MSMQ for .NET developers, including code samples for several major MSMQ features that you can use in your own applications.
At its most basic level, MSMQ is a tool for sending and receiving messages. MSMQ is powerful enough to provide near real-time message exchange throughput, depending on the machines and transports involved in the exchange, and flexible enough to provide many features required in assembling a communications infrastructure for your application system. You can send MSMQ messages across machine boundariesincluding across the Internetto queues where a receiving application can retrieve them in a prioritized first-in first-out manner. MSMQ also integrates with Active Directory to provide domain-wide queue management features.
This article covers MSMQ functionality exposed through the System.Messaging namespace in the .NET Framework. As such, you need to add a reference to the System.Messaging assembly before attempting to work with any of the sample code provided. The System.Messaging namespace provides access to functionality available in MSMQ 2.0, available on Windows 2000, as well as MSMQ 3.0, which is only available on Windows XP and Windows Server 2003. This article focuses the more broadly available MSMQ 2.0 features, reserving discussion of some of the features new to MSMQ 3.0 for a later article.
Workgroup Mode and Active Directory Integration
MSMQ was designed to integrate with Active Directory (AD) by publishing information about its queues in the AD directory structure, which facilitates searching for queues and testing for the presence of queues across the entire domain. However, I have found MSMQ to be much more reliable when you install it in Workgroup Mode, because that mode explicitly instructs MSMQ to disable AD integration. The main functionality that you lose in Workgroup Mode is queue search capabilities, and the ability to use public queues. Neither tradeoff is significant enough to warrant the integration with AD.
Public and Private Queues
MSMQ has two basic types of message queues: public and private. There is little functional difference between the two types, except that MSMQ publishes information about public queues in AD. AD provides many useful ways of searching for queues throughout the domain. Unfortunately, the ability to search for public queues comes at a great costreliance on AD considerably reduces the robustness of MSMQ (see my article titled Nine Tips to Enterprise-proof MSMQ for more information about AD integration with MSMQ). Private queues require a more absolute naming convention, and you can't search for them as easily as public queues.