Just got back from the SQLskills Immersion event in Chicago. There were a couple of bonus sessions, with Kimberly doing a high-availability talk for Microsoft customers and our students one evening, and Joe Celko making an appearance on Wedsnesday. Joe spoke on elements of SQL style, and I was able to acquire a signed copy of his new (but not his latest) book "Joe Celko's SQL Programming Style". He's also just released a book on analytics since the style book.
With all the weary smiles at dinner on Thursday, I got the idea that everyone in attendence had a good time and was full to overflowing with the topics we presented. If this sounds interesting to you, there are some spaces in our October event in NYC.
An interesting question that came up at dinner was "how do you motivate use of the Service Broker in SQL Server and how mainstream are the use cases"? Here's how.
If you've ever purchased anything on the web, you'll notice that no matter how popular the website, once you navigate through the catalog, fill out the forms with your personal, shipping, and credit info, the actual order screen is quite quick. You get back an acknowledgement very quickly, but it usually only consists of an "echo" of a subset of the data you entered and an order ID. Also, there is likely a hyperlink where you can check the status of your order. Perhaps an email is sent.
Bet they didn't do a credit check, set up billing, shipping, check inventory, and consult the MRP system for a manufacturing schedule while you were waiting, did they? Most or all of this is done asynchronously, probably with queued messages of some sort. Otherwise, it would be quite a transaction, and if all subsystems weren't on the same instance, a (slower) distributed transaction at that.
Generating an order number, saving the order details (maybe in XML format, for later decomposition into the relevent relational tables), and updating/checking the customer table is much faster. And, if the queueing system is inside the database, your queued messages and database updates will be a fast *local* transaction. If you need to save state, you're already in the "state machine/DBMS", rather than one tier or more away. BTW, if you're using SQL Server's Database Mail feature, the email is also sent asynchronously using Service Broker. Gotta save on that synchronous distributed processing. Else you'll get impatient and push "Buy" again. Or perhaps not return next purchase.
That's the motivation.