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
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,
In order to support scaling out asynchronous database applications, Service Broker includes reliable, transactional messaging between
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
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
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.
On the Surface, this looks like the toughest call because both
In general, Service Broker does high-performance, extremely reliable, asynchronous operations that span distributed