Both XNA Game Studio Express and Microsoft Robotics Studio shipped their 1.0 releases this week. So once you’re done hacking a robot to mow your lawn, you can relax by debugging your latest game on your Xbox 360. W00t!

Santa, please bring me a few extra hours per day so I can play with this stuff!

I’ve been spending some quality time with SSB and WF of late. On the balance, my opinion of both these technologies is very positive, though each has some warts of note. For Service Broker, they got the transactional messaging semantics right, but much of the lower level connection management – what SSB calls “routes” are clumsy to deal with. For Workflow Foundation, the execution model is amazingly flexible. Unfortunately, WF’s support for transactions is significantly more rigid.

If you’re build a SSB app, you’re typical execution thread looks like this:

1. Start a transaction.
2. Receive message(s) from top of the queue.
3. Execute service business logic. Obviously, this varies from service to service but it typically involves reading and writing data in the database as well as sending messages to other services.
4. Commit the transaction

When I sat down to marry SSB and WF, I naively assumed I could simply use WF for step three above. Alas, that turns out to be impossible. This thread on MSDN Forums has most of the gory details, but the short version is that WF does not support flowing host managed transactions into the workflow instance. As per Joel West in the aforementioned thread:

“[T]he WF runtime in V1 only supports flowing in a transaction on WorkflowInstance.Unload. There are various ways that you could try and hack this (with a custom persistence service or WorkflowCommitWorkBatchService) but if you do this it won’t work correctly 100% of the time and the times when it fails (error conditions or failures causing the tx to rollback) will be exactly when you are expecting transactional consistency.

Bottom line – the only way to make this work is to call WorkflowInstance.Unload inside your transaction scope.  This was the best that we could do in V1 to try and enable this pattern in some form.  Not always ideal but it can be made to work for most scenarios that require usage of an external transaction.”

So the WF compatible execution thread looks like this:

1. Start a transaction
2. Receive message(s) from the top of the queue
3. Load/Create the associated workflow instance for the received messages
   • All messages received are guaranteed to be from the same SSB conversation group, which is roughly analogous to a WF instance, so this turns out to be fairly easy
4. Enqueue the received message in the workflow instance
5. Unload the workflow instance
6. Commit the host transaction
7. Reload the workflow instance
8. Run the workflow instance (note, I’m using the manual scheduling service)
   • Workflow instance creates a transaction if needed
9. Unload the workflow instance (typically done via UnloadOnIdle in the persistence service)
   • Assuming the workflow instance needed a transaction, it gets committed after unload

Basically, you use two transactions. One host managed transaction to move the message from SSB to WF instance and one WF managed transaction to process the message.The need for two transaction instead of one is unfortunate, but required given the current design of WF. And frankly, given the importance and difficulty of transaction management, I’m not that surprised that WF has hard coded transaction semantics. Trying to build a generic transaction flow model that would work in the myriad of scenarios WF is targeting would have been extremely difficult. At least there is a work around, even if it means using two transactions and loading and unloading the workflow instance twice.

However, there is a silver lining to the two transaction approach: two unexpected benefits when dealing with poison messages. First, SSB doesn’t have dead letter queue like MSMQ does. Moving a poison message to a dead letter queue would break SSB’s exactly once and in order semantics.(MSMQ doesn’t guarantee in order delivery) But moving all messages into the WF instance gets them out of the main SSB queue so poison messages don’t continue to get processed over and over.

Second, because the workflow instance is peristed after the messages are enqueued, there’s a representation of the workflow after the message is received but before the message is processed. If there’s a poison message, attempting to processing the message will fail and rollback to this state. This persisted workflow instance could be sent to a developer who could step through it to determine the cause of the error. We could even have developer versions of runtime workflow services so we could read remote data and simulate data updates. I wouldn’t want the developer updating production data in this way, but it would be great for troubleshooting issues.

Washington Capitals record in the past four games: 4-0
Washington Capitals record in the past ten games: 4-4-2

That is what in the business of hockey you call “streaky”.

When your recent winning streak includes wins over Dallas (16-8 at the time, 19-9 now) and Eastern conference leading Buffalo (20-3-2 then, 21-4-2 now), you can feel pretty good about yourself. Being only one point out of the playoffs doesn’t hurt either.

On the other hand, the East is a beast this year. Only Florida and Philadelphia are below .500. Everyone else is in the thick of the playoff hunt. Another six game slide would really hurt the Caps’ playoff chances. By comparison in the West, seven of the fifteen teams are below .500 (i.e. everyone not currently in a playoff spot). Dallas, at ten games over .500 is 3rd in the Pacific Division behind Anaheim (+18) and San Jose (+12).

Finally, it’s always nice to be looking down on the Penguins in the standings. But their not far behind. Their 26 points puts them in 13th place in the East, but they’re at .500 (11-11-4) and only five points out of a playoff spot. Next Monday’s game should be a good one. It’s even on national TV in HD!

Most of the technical blogs I read are individual blogs (like this one). Yet, most of the political blogs I read are multi-user. Typically, there is a primary poster – such as Josh Marshal from Talking Points Memo. But TPM has at least four other bloggers on their home page (Paul Kiel, David Kurtz, Greg Sargent, Justin Rood). I wonder why these two blogging communities are so different?

With the real and serious problem we face in this country – the civil war in Iraq, the deteriorating situation in Afghanistan, rebuilding New Orleans, etc. - it boggles the mind that we waste any time at all on faux controversies such as the so-called “War on Christmas”. Getting Wal-Mart to use “Christmas” instead of “Holiday” in their marketing seems like a dubious accomplishment at best.

But where I rail against such stupidity, my brilliant wife writes poetry. One of Julie’s conservative friends sent her an insipid poem that’s been making the rounds on the Internet called “How The ‘Left’ Stole Christmas”. I must have missed Wolf Blitzer changing his name to “Wolf Blitzen” or the Senate passing legislation to take away Christian’s faith and forbid them to speak of salvation and grace.

My response would have simply been “Read the First Amendment, idiot!”. My wife, however, wrote a poem of her own in response. Check it out.