tl;dr - I can't see the point in Service Broker; it doesn't appear to do what it says on the tin and is too convoluted to use...

_________________

On the surface, it looks like an ideal way to get SQL Server to 'annouce' to your application layer that something has happened (rather than the application layer polling the database every so often to look for changes). I have admittedly not delved far into its workings but, when I did, I wrote it off as a non starter. I'm sure others have done the same.

For me, the problems are: obscurity, complexity, coupling and a lack of userland documentation.

Service Broker is a bit too hidden-away for most of my developers to even think about. This obscurity means that it is not a first choice solution for any problem. Not saying it should matter but, realistically, how useful is Management Studio for promoting/configuring/managing Service Broker. I can see an tree node for a Service Broker Endpoint (but can't do anything with it -- an empty Reports option and a Refresh option is not Management in anyone's Studio). Admittedly, the SSMS-side of things is much better in 2008/R2 but, if this feature was expected to be so useful in 2005, its tools should have been there from the get-go.

Secondly, the complexity. XML is not fun to work with. XML is especially not fun to work with in SQL Server. Sure, anyone can write a basic XML document; I'm sure most of us can also put something together with a nice set-based FOR XML statement and some of us can even get that data back out with the functions built into the XML datatype but that still leaves a lot of people (good, upstanding, professionals in their field) whose eyes just glaze over at the very sight of it. Besides, good XML (with schemas and transforms and validation and such) is a pain in the rear that even the most capable of us usually want to avoid.

Even for all its XML-ness (surely originally designed as a common 'language' for interoptability in data transfer), it still feels like the only thing that can talk to a Service Broker is...another Service Broker. So you have SQL Server talking to another SQL Server. Great, but we can already do that well-enough with Linked Servers -- at least we get to talk SQL to those (even if badly-written queries can lead to vast swathes of data going back and forward across the wire).

Despite all the talk about decoupling and being able to provide interfaces for another process to communicate with, it all still feels so ostensibly coupled. If it is supposed to be a decoupling messaging framework, surely there should be some example out there of how you can listen for these messages from your own appplications (or are you just expected to throw WCF/RabbitMQ/some other messaging system into a SQLCLR if you want to do that?).

There also doesn't appear to be any usable abstraction to work with this stuff in a way that allows portability to another major platform. I know, deep down, that is the point (i.e. to tie you to SQL Server) but most other features can be abstracted away in your app layer -- you don't usually have to rewrite the entire data access layer to switch from SQL Server to Oracle, but you would have to reimplement Service Broker in your new target platform (any real parallels to Oracle Queues?).

Finally, there just doesn't seem to be that much practical information out there about why you should use it. The Microsoft documentation is all 'this is how you do it' (and can be terse, at best), the evangelist blog writers are all 'this is how you do it' (and pretty much just blog about their particular implementation) but noone is really talking about what problems it can overcome and why you might want to consider it.

In the face of that, the howtos all cover the same sort of ground: read data from your table, transform it into a message in a given format and send it somewhere vs. listen for a message in a given format, read the data from it and store/process it. And that seems like an awful lot of work when you could just replicate the data between two servers and have a SQL Agent job poll the replicated table for new rows.

Ironically, when my developers have implemented solutions that would benefit from some sort of messaging, they've ultimately ended up storing those 'messages' in tables, and polling their own service apps. Not saying that it was right, just saying it was so. They understand them, have been using them for some time, and don't necessarily require any glorified string manipulation to get anything usable out of them.

At best, I can see it allow some decoupling between disparate SQL Server databases, whereby you can transform your data, stored in your table layout to a given common format, and they can transform their data, stored in their table layout to the same common format and both can just get along.

Maybe that is the point of Service Broker (and I've only just this second got it!).