When I talk to people about Service Broker, I inevitably get questions about how it relates to Microsoft Message Queue (MSMQ), BizTalk, or Windows Communication Foundation (WCF). This section will discuss some general guidelines for deciding whether Service Broker or one of the other messaging technologies is appropriate for your needs.
With Service Broker, SQL Server becomes a platform for building loosely coupled, asynchronous database applications. Service Broker implements queues as first-class database objects. The queue-handling code built into the database kernel handles the locking, ordering, and multithreading issues associated with managing queues.
To support scaling out asynchronous database applications, Service Broker includes reliable, transactional messaging between SQL Server instances. Because Service Broker messaging is built into the database, it offers message integrity, performance, and reliability that most transactional messaging systems can’t match. Service Broker dialogs provide ordering and delivery guarantees that no other messaging system offers.
Service Broker isn’t just a general-purpose messaging system. Although no other transactional messaging system offers the reliability and performance that Service Broker provides to SQL Server applications, the fact that Service Broker is built into SQL Server means that it works only for SQL Server applications.
Service Broker also supports only transactional messaging. Transactional messaging is the only way to ensure that messages are processed exactly once and in order. Because it is part of the database, Service Broker can do transactional messaging significantly better than messaging systems that aren’t built into the database. If the application doesn’t require transactional reliability, however, this is unnecessary overhead.
Finally, Service Broker is not just a messaging system. Although the messaging features might be very useful, a large number of Service Broker scenarios don’t require messaging at all. The ability to perform asynchronous, queued database actions is very useful, even if your database application isn’t distributed.
Because it is built into SQL Server, Service Broker messaging has some significant advantages over MSMQ transactional messaging:
Service Broker can commit updates to the message queue, database data, and application state in a simple database transaction. MSMQ requires a two-phase commit to do the same thing.
Service Broker messages can be processed by any application that can establish a database connection to the SQL Server database. Applications that process MSMQ transactional messages must run on the same physical machine as the queue.
MSMQ message ordering is assured within a single transaction. Service Broker message ordering in a dialog is assured across transactions, sending applications, and receiving applications.
The maximum MSMQ message size is 4 MB. The maximum Service Broker message size is 2 GB.
Service Broker activates another queue reader process only when the current processes aren’t keeping up with the load, while MSMQ triggers fire for every message that arrives.
On the other hand, MSMQ has some significant features that Service Broker doesn’t have, such as:
MSMQ offers express, reliable, and transactional message styles, while Service Broker is transactional only.
MSMQ can communicate between virtually any pair of Windows applications. Service Broker can communicate only between applications connected to SQL Server.
MSMQ offers both a TCP/IP binary protocol and an HTTP SOAP protocol for communications. Service Broker is binary TCP/IP only in SQL Server 2005.
Service Broker and BizTalk don’t have a lot in common other than reliable message delivery and database queues. Service Broker can reliably deliver a message to another SQL Server instance with exactly-once in-order assurances. BizTalk does this also, but in addition it can manipulate the contents of messages, map message formats, manage message processing, manage workflows, manage state, send messages over multiple different transports, and so on. If your application doesn’t use any of these features and just requires reliable delivery of XML documents from one SQL Server instance to another, Service Broker is probably a better alternative. However, if your application requires the more advanced BizTalk features, you will need to use BizTalk or write the logic yourself.
Service Broker supports reliable, transactional messaging over TCP/IP using a proprietary protocol between SQL Server instances. Windows Communication Foundation (WCF) supports many messaging styles over a variety of standards-based protocols between Windows and any operating system that implements the standard protocols that WCF supports. Although WCF can’t match Service Broker when it comes to connecting SQL Server applications together reliably, its total feature set and connectivity options go far beyond what Service Broker offers. You can combine the Service Broker asynchronous, reliable database platform capabilities with WCF’s interoperability to build reliable, heterogeneous applications.