I've just read  Klaus Aschenbrenner's  Service Broker article on DevX. While the article provides a nice overview of the mechanics of service broker, I think there's a need to elaborate more on the essene of Service Broker (esp. vs. MSMQ) - so here's my 2 cents on the subject.

While MSMQ is a general purpose messaging engine, Service Broker is focused on (some would say limited to)  transactional messaging -And in this area it does a better job than most if not all the other messaging solutions out there. Here are two examples:

• Message order - MSMQ transactional messages only guarantees ,message order inside the transaction - it does not guarantee order between transactions also messages from two transactions can be interleaved (see MSDN for illustrations). Service broker solves both these problems.
• Multiple readers - If you have a large message load and want to set up multiple readers. One problem that might happen (which Service broker solves) is of  two related messages being handles by different readers at the same time - this can occur if you have a long running processes between services or if you utilize service broker for message exchange inside a service. Also in the realm of multiple readers - Service broker will do some form of load balancing the readers for you - if you are willing to let the reader be stored procedures.

Another important trait of Service Broker is that it seems it was built with service orientation in mind (and not just because of the name..). For one you have to define messages and contracts (which party can send which messages) in order to establish a conversation (even though you can trivialize it to send any message you want in any direction). Furthermore, you send messages on a conversation and not to a queue. This means that the sender doesn't really have to know who would get the message (well some layer has to know in order to set up the plumbing - but the business logic that decides to send a message is free from all this).

The other use for Service Broker is to introduce asynchronous operations into the database. It lets you create short transactions updating a single table or view and have the effects of the change ripple as a continuing transaction or transactions. for example you can update a view (that has a lot of underlying tables) and in its "instead of " triggers put the updated information in a queue. You can then read from the queue in another transaction and update the underlying tables. since everything is transactional (the send from the view's trigger, as well as the read by the updater stored procedure) you can be sure that the updates will occur (by the way, this view scenario is something that can be used for implementing insert-only databases, but that's a matter for another blog post :) ).

Arvindra Shemi posted a diagram with the main concepts of service brokers. Note that he also mentions there Monologs, which, as Pat Helland once told me (before he left Microsoft), was originally intended to be part of the product, but was dropped (postponed ?) somewhere along the way. It should be noted that you can implement the behavior of monologs using dialogs, however you need to do a some work to make that work. Another concept missing from that diagram is conversation group, which is a way to treat several conversations as if they were a single conversation.

One technical remark on the DevX article - The article shows the TSQL - it isn't too difficult to wrap these with C# code. I didn't check the latest beta of SQL  but the samples of previous versions already had such an implementation (prepared by the service broker team).

[minor updates]