icrosoft offers two queuing frameworks to its 'brand' of developers: MSMQ and SQL Service Broker. These two frameworks offer many of the same features, but differ in some important areas that might affect which you choose for your queuing project. MSMQ is a time-tested technology, while SQL Service Broker is new to most developers. This article outlines some of the differences and may help you to make an informed choice when selecting a queuing technology.
Queuing frameworks are still among the most underutilized frameworks for building enterprise applications. Used properly, they can improve user interface interaction by making long-running resource requests asynchronous, distribute workloads across several servers or services, provide disconnected applications with asynchronous connectivity, enable loose coupling between clients and serversand the list goes on. The real benefit to developers is that the majority of the heavy lifting to provide these services has already been written by Microsoft. You don't need to author data schemas and stored procedures to manage hand-built queues using SQL Server. There are other queuing services available to Windows developers, such as IBM's MQ Series and BEA's MessageQ, but MSMQ and Service Broker are the two most likely candidates for developers who use Microsoft tools. The cost of MSMQ, the ubiquity of SQL Server availability to Microsoft developers, and the wide range of Windows client platforms supported by both make MSMQ and SQL Service Broker easy choices.
Microsoft originally provided MSMQ in the Windows NT4 Option Pack, and has since published multiple revisions. DevX has published several articles detailing MSMQ's features and programming modelsee the Related References section in the left column of this article for links. MSMQ is included free of charge with all versions of Windows Server (after Windows NT 4 with the Option Pack), Windows 2000 Professional, and Windows XP. MSMQ provides API, COM, and .NET interfaces for sending and receiving messages and for managing queues.
With the release of SQL Server 2005, Microsoft also offers Service Broker as an alternative to MSMQ. Because it's tied closely to the database platform, Service Broker can be more efficient for data-intensive queuing operations; however, unlike MSMQ, you must obtain a license for SQL Server to use Service Broker. Service Broker functionality is available in any language you use to access data from SQL Server. Also, most queuing operations in SQL Service Broker are performed using extensions to T-SQL.
Given the popularity of both MSMQ and Service Broker and the lack of comparisons between the two tools is surprising. This article fills that void.
Viewing the two tools strictly from a high-level perspective, they seem very similar; both provide reliable first-in/first-out prioritized queuing, asynchronous message processing, and are accessible from a wide variety of languages. However, their differences will likely make one or the other a better choice for your development project.
Table 1 provides a brief comparison between SQL Service Broker and MSMQ. The list is not comprehensive, but provides some of the most important differences between the two. The main criterion for inclusion was to identify features or issues that would help in selecting one technology over the other.
Table 1. Feature Comparison: These features and issues help can you decide which technology, MSMQ or SQL Service Broker, is most compatible with your particular project or environment.
||SQL Service Broker
||Free with all business versions of Windows
||Requires SQL Server 2005 license
||Higher performance possible
||Lower performance when standard messaging functions are not necessary
||Relatively expensive transactions using the Distributed Transaction Coordinator
||Efficient transactions using SQL Server's internal transactions
||Queuing code cannot run in SQL Server
||Message processing logic can run in SQL Server
||Type enforcement provided via message types and contracts
||No type enforcement
||Support for fully disconnected mode
||Requires connection to SQL Server (at least SQL Server Express Edition) to send messages
||Backup via standard SQL Server backup procedures
While the table provides a convenient, if brief, overview, in the rest of this article, I'll expand on each of the features and issues shown.