Where does Service Broker Fit?
One of the most frequently asked questions I get when talking about Service Broker is how does it fit with the other messaging products that Microsoft has. Specifically, I hear a lot about MSMQ, WCF (Indigo) and BizTalk. In this post, I will try to clarify the scenarios where Service Broker is the right solution and the scenarios where one of the other products is a better fit. Keep in mind that this is my interpretation of the product positioning and other people my have slightly different outlooks.
What is Service Broker?
Before I dive into where Service Broker fits, it may help if I summarize some of the core features of Service Broker. With Service Broker, SQL Server 2005 becomes a platform for building loosely-coupled, asynchronous database applications. Most large database applications have one or more tables which are used as queues. While using a table as a queue is a very useful way to improve performance and scalability, it’s very difficult to get right. Service Broker addresses this issue by implementing queues as first-class database objects. The queue handling code built into the database kernel handles the locking, ordering, and multithreading issues associated with most home-grown database queues.
In order 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.
To ensure that there will always be an application running to process received messages, Service Broker includes an activation facility that keeps the right number of stored procedures running to handle the messages arriving on a queue. Activation automatically detects and compensates for changes in the incoming message rate so the queue doesn’t grow faster than necessary and resources are not wasted when the queue is empty.
Finally, Service Broker is not JUST a messaging system. While the messaging features are very useful, a large number of Service Broker applications don’t require messaging at all. The ability to do asynchronous, queued database actions is very useful, even if your database application isn’t distributed.
Service Broker and MSMQ
MSMQ is a mature, general purpose reliable messaging system that is part of Windows. MSMQ can communicate over TCP/IP or HTTP and supports three types of reliable messaging – non-persistent, persistent and transactional. Service Broker supports transactional messaging between instances of SQL Server 2005 over TCP/IP.
Since Service Broker is built into the database, it does transactional messaging significantly faster and more efficiently than MSMQ. MSMQ is a message transport and not a database so if application messages themselves are important business objects that must have high data integrity including backup and failover, Service Broker is also a better choice. If your application can survive an occasional lost message, must communicate over HTTP, or can’t live with a SQL Server database at both ends of the communications link, then MSMQ is a better choice.
One of the grey areas is client to server reliable messaging. While SQL Express makes Service Broker available for client applications, you will have to decide whether the extra overhead of having a database running on the client is justified by the extra data integrity provided by Service Broker. In some cases, the client needs a database anyway and so the Service Broker is a viable choice. Point of Sale terminals are a good example of a client where a SQL Express database talking Service Broker to a server database makes sense.
WCF (Indigo) and Service Broker
WCF is the only product in this comparison that does unreliable messaging so if Unreliable messaging meets your needs then the choice is obvious. WCF has at least two reliable messaging options. The first is based on MSMQ so the same considerations apply. The second is a non-persistent message transport that uses ws-rm as a transport This is the only choice if you need to interoperate with another ws-rm based product but doesn’t offer the degree of reliability that the persistent implementation offer.
One of the items on the list for a future release of Service Broker is a WCF channel for Service Broker. This would combine the reliability and data integrity of Service Broker messaging with the programming model of WCF. There is no committed schedule for this yet but when it happens, it will be a boost for both Service Broker and WCF.
BizTalk and Service Broker
On the Surface, this looks like the toughest call because both BizTalk and Service Broker communicate between SQL Server instances. If all you need to do is deliver a bunch of bits from one SQL Server instance to another over a TCP/IP connection then Service Broker is probably the best choice because it it smaller and more efficient at delivering messages. If on the other hand, you need the features of BizTalk – message transformation, orchestration, a variety of transport options, data dependant routing of messages, etc. then you must either choose BizTalk or be prepared to write and support the code to do these things yourself.BizTalk does Information Integration, Workflow, and heterogeneous messaging which Service Broker knows nothing about.
Summary
In general, Service Broker does high-performance, extremely reliable, asynchronous operations that span distributed SQL Server database instances. If this describes your application requirements then you should very seriously consider Service Broker. If your application doesn’t have these requirements, you should still look at Service Broker but you should also consider the other alternatives.
Comments
Anonymous
February 28, 2006
If you have been reading my recent posts, you must have noticed that I have been talking about data....Anonymous
May 10, 2006
Have Data Will Travel : Where does Service Broker Fit?.
This is a good “perspective” post...Anonymous
September 08, 2006
Architecting Service Broker Applications
 
I signed up to do a presentation on Architecting Service...Anonymous
November 27, 2006
Jeg havde længe gået og tænkt på flere forskellige scenarier hvor man måske kunne anvende SQL ServerAnonymous
November 27, 2006
Jeg havde længe gået og tænkt på flere forskellige scenarier hvor man måske kunne anvende Service Broker