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.
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.
Dave Wentzel CONTENT
sql server service broker service broker demystified