Service Broker: Complex But Not Hard.
I've been thinking a lot recently about Yukon's Service Broker in preparation for some talks I'm working. Pretty much everything I've learned so far has come from Dan Sullivan (who really needs to get a blog) or Robert Hurlbut, two names to follow if you're going to be serious about SSB (well, other than Roger Wolter, but you better already know who he is…).
Today I had a chance to start reading Towbridge et. al. Integration Patterns book and something just clicked. We hear a lot of folks asking the question: "Well, if it had a GUI, why would I still use BizTalk?" My answer now is "because BizTalk is a Process Integration Controller, where as Service Broker is what its name implies." To understand that answer, you have to understand the differences between Process Integration Control and Message Brokering. I couldn't really hope to that justice here, and the definition of what a Process Manager does is pretty much describes what BizTalk does. The seeming lack of differences between an SSB Service Application (typically a stored proc, T-SQL or otherwise) and a BizTalk orchestration muddies waters further. But the key difference in my mind is how you use them. For example, SSB also fits nicely within this book's definition of a message brokering system -- basically a concentrator/multiplexer for messages between. BizTalk, however, makes it easier to build out more finely-grained process integration programs that operation between most any set of endpoints (between bounds, OS and the myriad of other factors.)
That thought helped confirmed a mnemonic for SSB that I've been working on for a while: Complex, but not hard. But be careful to understand that's not literally what I'm saying -- its just a shortcut for remembering the following:
SSB provides a framework for building Asynchronous, Distributed, Transacted and Queue Messages (ADTQM for short). It takes care of the hard-to-code problems like guaranteeing in-order delivery and message correlation. In other words, you don't have to (or likely want to) do that hard work if SSB is an option in environment. What SSB also does is allow you to focus on the complex parts more immediately. That is: how do I design an application for the business problem. Think of it this way: suppose you working on a "e-tailing" application that lets customers buy products from you online. SSB removes one of the barriers you have to making that kind of application scale up and out gracefully by giving you the framework to work with that solves the hard parts of writing messaging applications. How you choose to solve the complexities like making sure that a customer's credit is okay, or posting charges to the general ledger or creating a shipping order for the warehouse are done right and in the right order is left up to you.
Now if we just had a nice GUI for doing that! I'd be a nice surprise to see one ship with SQL Server 2005 though. That's not to say that the community or third-party ISVs couldn't create some very good ones indeed. I'm sure several will.