The simplest way to describe SQL Service Broker is “message queues in the database.” If the queues are tables in the database then you can do your entire message processing using a local transaction. If you use a separate queuing technology like MSMQ, you can still pull items off the queue, update data in the database and send out messages in the scope of a transaction – it just has to be a distributed transaction. Being able to use a local tx gives us a big performance gain. But, while important, this perf gain isn’t the most compelling reason to use SSB. It turns out that SSB provides important semantic messaging benefits in addition to perf benefits.

If you study at the semantic messaging model defined by message queuing systems such as MSMQ, MQ Series and WS-RM you’ll notice that it is inherently one way. Section 2 of the WS-RM spec defines the reliable messaging model to be between a source sending the messages and a destination receiving them. The problem with this model is that as message patterns between services gets richer, we’re going to want bi-directional reliable messaging. SSB calls this a dialog.

Before you can send messages between services in SSB (assuming everything’s been configured), you first have to BEGIN DIALOG and provide the initiating and target service, plus the message contract (more on that in a later post). Note that it’s called initiator and target, not sender and receiver. Either side of the dialog can send messages to the other as part of the contract by using SEND ON CONVERSATION – the only requirement is that the initiator sends the first message (hence the name “initiator”). All messages are guaranteed to be delivered exactly once and in order, or both sides of the conversation are notified of the failure and the dialog is torn down. I’m not sure if it guarantees in-order delivery of messages in opposite directions. There are cases where this might be important – I send an order cancellation as I send you a shipping notification – but typically there’s a business reason for who “wins” such a conflict. In this shipping/cancellation example, even if you sent me the cancellation before I sent shipment notification, it’s not like I can recall the shipment.

My only issue with this bi-directional reliable messaging is that I’m so used to thinking in terms of one-way RM that it’s taking me a while to wrap my head around it. Many of the sample interactions I come up with are simple patterns where the target simply acknowledges the incoming message. Order processing is a good example where I may get meaningful messages (i.e. not simple acks) coming from both ends. What are some others?

Paul Murphy pointed out a SSB wrapper class that ships as part of the integrated storefront sample that ships with SQL 2005. It’s a bit tricky to install, so I refer you to Paul’s blog for instructions. (you have to install the sample installer) The wrapper class is in a file called ServiceBroker.cs and supports the following operations:

• Get Conversation Group
• Begin a Dialog
• Begin a Dialog (with related conversation)
• Send a Message
• Receive a Message
• Receive all messages from a conversation group
• End a Dialog

If you’re not sure what dialogs and conversation groups are, I’ll be blogging about them in the coming weeks.

Since Norman joined the team a few months ago, I’m no longer in firefighter mode. For about six months my team was short a marketing manager and I ended up picking up a bunch of extra duties. For example, I took over as TechEd architect track owner when out previous marketing manager left. I don’t know much about marketing, but I guess I did OK – I received a Marketing Impact Award for my work on TechEd. However, I’m very happy to have handed those marketing responsibilities back to their rightful owner. Even still, Norman is trying to educate me about marketing. He made me read the first two chapters of Building Strong Brands by David Aaker. I actually got thru the first three chapters before borrowing Birth of the Chaordic Age by Dee Hock from my father at Thanksgiving.

You would think that I would now have more time for blogging, but alas that has not been the case. When I was firefighting, I had no time for planning. Now, of course, I do. So between planning and thanksgiving vacation I’ve just been too busy to blog much.

One thing I’m getting into recently is SQL Service Broker. I’m working on an interesting community project that is building on top of SSB. Luckily, one of the primary architects of SSB sits down the hall from me. Of course, not everyone is so lucky, so watch this space as I dig deeper on SSB. A good place to start is the SSB First Look article. In order to start getting a handle on SSB, I ported the Hello World example from that article from T-SQL to C#. It’s a bit tricky, as there is no SSB-specific framework – you just use SqlCommand to execute SSB commands like BEGIN DIALOG and RECEIVE – but otherwise it’s pretty straightforward. My sample also demonstrates using the new SQL Management Objects to create databases and SSB related objects (message types, contracts, queues and services). Here’s the code – enjoy.

Roger Sessions, noted architectural guru, author and Microsoft Architect MVP, has posted his latest newsletter on the WS-* family of specs. In typical Roger fashion, he decides to give them his own name – WS-SCRAM with SCRAM standing for “Secure, Coordinated, Reliable Async Messages”. (I forget where, but I once heard Roger refer to “three-phase transactions” instead of the relatively standard “two-phase commit transactions”.) Roger claims MS et. al. are pushing WS-STAR where “STAR” is an acronym standing for “Secure, Transacted, Async, Reliable”. Personally, I’ve never seen it written out like a an acronym and I always thought the * in WS-* was used as a wildcard, but it is true that we are focused more on transactions than coordination. On the Longhorn DevCenter, Indigo is described as providing “secure, reliable, and transacted messaging along with interoperability.”

This is actually the second time Roger’s taken on transactions in a web services architecture. His last newsletter on the topic had a much more detailed but harder to follow example. He points out that there are two related specs in this space – WS-AtomicTransaction and WS-BusinessActivity but that he thinks only WS-BA is going to work in the long run. WS-AT requires holding locks open in the DB, which is highly unlikely between services in different trust boundaries communicating with async messaging. Am I really going to lock the records in my database while I wait for a service that I don’t trust to figure out if it is able to commit or abort? I don’t think so. Pat’s wrote a great scenario showing how unrealistic the concept of long-running transactions really are.

However, at the end of the newsletter, Roger takes Indigo to task for implementing WS-AT and not WS-BA and I don’t agree with him. While I think WS-AT shouldn’t be used in web services architectures, Indigo is also responsible for moving existing technologies like COM+ forward. Leaving out WS-AT isn’t really an option in those scenarios. As for not implementing WS-BA, I’ve got to wonder just how valuable is WS-BA? While WS-BA avoids the DB locking issue of WS-AT, it still doesn’t deal with the delegation of control. WS-BA still leaves me beholden to the decision of some outside coordinator. This seems to violate two of Don’stenets of service orientation: “Boundaries are Explicit” and “Services are Autonomous”.

I’ll be honest, with a quick glance at WS-Enumeration and WS-Transfer I’m at what Don refers to as Stage 1. Especially WS-Transfer which appears at first glance to be CRUD for web services. Maarten talks about using CRUD only when you can afford it. My biggest issue with CRUD is that it assumes a trust relationship – that some other service is responsible for deciding when and how to CUD entities that I manage. I can’t imagine exposing an interface like that on any service I build.

But it is nice to see we’ve started publishing specs in easy to download PDF format.