Login | Register   
LinkedIn
Google+
Twitter
RSS Feed
Download our iPhone app
TODAY'S HEADLINES  |   ARTICLE ARCHIVE  |   FORUMS  |   TIP BANK
Browse DevX
Sign up for e-mail newsletters from DevX


advertisement
 

Microsoft Queuing Frameworks: SQL Service Broker vs. MSMQ

Not quite a knockout, SQL Service Broker beats MSMQ at its own game.


advertisement
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 servers—and 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 model—see 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.
Feature/Issue MSMQ SQL Service Broker
Cost Free with all business versions of Windows Requires SQL Server 2005 license
Highest Performance Higher performance possible Lower performance when standard messaging functions are not necessary
Transaction Performance Relatively expensive transactions using the Distributed Transaction Coordinator Efficient transactions using SQL Server's internal transactions
Code Location Queuing code cannot run in SQL Server Message processing logic can run in SQL Server
Type Enforcement Type enforcement provided via message types and contracts No type enforcement
Disconnected Queuing Support for fully disconnected mode Requires connection to SQL Server (at least SQL Server Express Edition) to send messages
Backup Non-trivial backup 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.



Comment and Contribute

 

 

 

 

 


(Maximum characters: 1200). You have 1200 characters left.

 

 

Sitemap