Workflow Serialization - what you need to know about persistence

Jon Flanders’ recent blog on Workflow Serialization came about because of a question I raised on a Microsoft alias about  Workflow’s persistence service, which Jon responded to with this blog entry. I thought was a really simple question, but caused some discussion about what happens under the covers when serialization takes place, so I would encourage you to read it.

The  original question was along these lines: If you are developing workflows, do you need to  do anything special to work with the persistence service? If you have not come across the persistence service, it’s a very simple and elegant mechanism that allows the runtime to take your workflow out of memory, freeing up the threads and memory it was using, and persist it to some external store, such as a SQL Server database, until such time as there is work for it to do, when it can bring it back to life. One of the most common scenarios for this is when the workflow is waiting for some external event, such as a message to arrive, or a timer to go off.

Although the goal of the persistence service is to be as transparent as possible, Jon points out that one of the issues people have been running into with Workflow and persistence is that when you first start designing your WF system, you generally don't add a WorkflowPersistenceService at the beginning , and this issue that can trip you up here is that if you are adding fields or properties to your Workflow that can’t be persisted, so you need to think about Serialization upfront.