Phew, it's not just me

First off, Canary Wharf is one weird place. I haven't been there for a while but it's almost like it has a dress code, everybody is wearing a suit, or shirt and trousers at the very least. So when I rolled out of the station in my old jeans with a few days facial hair growth I thought I'd be picked up by the police as a terrorist suspect. Fortunately I didn't bump into any police men. I was fairly sure Credit Suisse wouldn't let me in either but perhaps they'd been warned that a group of geeks was visiting.

I was attending a London .NET User Group meeting for a talk about Windows Workflow. The first part of this talk was reasonably interesting, although it was clear the presenter has been reading the same book as me, so a lot of it wasn't new to me. But things got interesting when one of the guys who's been developing a WF application at Credit Suisse talked about their experiences. The things that came up were pretty much the same issues that I've come up against.

First, the versioning story just isn't there yet. Storing serialized objects in the database means upgrading workflows can be somewhat tricky, since after an upgrade the deserialization is unlikely to work. Which is why I think using serialization is generally a bad design decision, unless the life of the serialized objects will be very short (copying to the clipboard, sending an object across the wire etc). So they've been forced to write some code to get pertinent information from the live workflow, destroy the instance and recreate it using the new workflow version and re-assign the state data.

The second problem is actually caused by the same issue. You might think since the workflow is stored in a SQL Server database, you could just query it to find all the instances that have a particular property, but again the fact that the worklfows are opaque blobs means this isn't possible. They worked around this by extending the persistence service to store relevant data relationally whenever a workflow is persisted.

It's nice to know that most problems can be worked around. There is so much flexibility in the WF hosting and runtime that almost all of the default implementations can be re-implemented to do what you want. I just hope this doesn't lead to Microsoft not fixing what are clearly problems with the default implementations.

One final thing that was mentioned that I was coming round to thinking myself is that state machine workflows are actually the way to go for many kinds of problems. Most of the talk in books and the web seems to be about sequential workflows but I think state machines are actually a better way to go most of the time. Of course this may just be due to my background in Metastorm e-Work which uses something closer to a state machine than a sequential workflow.