Service Broker Demystified - Why do we need Services and Queues?

People claim that they don't want to use Service Broker because it is too complicated. I started a blog series called Service Broker Demystified because SSB really isn't that difficult if you understand some basic concepts. Folks don't understand why both a "Service" and a "Queue" are needed.  Why not just have one object?  In this post I'll show you why and give you a quick rule-of-thumb to avoid the confusion.  

Today we are going to cover why we need both Services and Queues.  

Let's start with some definitions.  A Service is used to route messages to the correct queue and enforce any contracts for a message.  Remember that contracts are optional anyway so the only purpose of a service is to route the message to the correct queue.  A Queue is where messages are stored and then processed based on rules you create.  The queue is where all of the magic and important stuff occurs.  99% of what you code in Service Broker will be functionality involved with queue message processing.  

In most SSB designs (probably 95% that I've worked with) there is a one-to-one correlation between services and queues.  Why do we need to have both?  Is there any benefit to having both?  Service-to-queue correlation is just one more of those things that adds to the confusion around SSB.  

Remember that services route messages to queues.  So, in some advanced designs you may want to change which queue processes your messages based on some event.  You can therefore change the queue associated with your service and then the queue-processing logic can be different on the new queue.  You can do all of this without changing your application code, which is coded to a specific SERVICE, never to a specific QUEUE.  So this could potentially help in "versioning" your SSB design but there are far better ways to do that.  

This "new" queue can be a different queue in the same db or on an entirely new SQL Server instance on the other side of the world.  Hopefully you see that separating Qs from Services gives your design a bit of resiliency and failover.  The CREATE ROUTE command helps you here too.  You can map a SERVICE to a new SSB instance somewhere else.  But that is a complicated design that most noobs needn't worry about.  

I can't think of any good reasons to model "multiple Queues per Service" and I've never seen one in action.  "Versioning" would be one use case, but not a very good one.  

The other possibility is to model "multiple Services per Queue".  I have seen people model their designs this way, with disastrous results.  In this model you have many services, each with possibly multiple contracts, that all dump their messages to a single "Enterprise" Q.  The payload of all messages in the Q is similar with a "message type" discriminator embedded in the XML.  The activator proc for this Q shreds the XML and looks at the "message type" to determine the processing logic and the originating service.  Basically the activator proc is a gigantic switch statement ("if then" block).  People that model their SSB implementations like this believe that it is convenient to keep all of their activator logic in one procedure.  The disaster strikes when one service begins to overload all processing and we can't throttle it using MAX_QUEUE_READERS.  If each service had its own Q then we could throttle any service hogs by throttling that Q's MAX_QUEUE_READERS entry.  

Summary

Services are meant merely as an aid to route messages and enforce contracts.  The bulk of your logic will be concerned with Q processing, the queue being where the message is persisted while it is waiting to be asynchronously processed.  I have never seen a good design that uses "multiple services per queue" or "multiple queues per service" that couldn't be modeled more effectively in another manner.  Just remember that Service and Queue objects pretty much refer to the same thing...a mechanism to route and persist data until it can be processed.  

You have just read "Service Broker Demystified - Why do we need Services and Queues?" on davewentzel.com. If you found this useful please feel free to subscribe to the RSS feed.