Is it possible to persist a state machine built in Workflow Foundation to a DB using Nhibernate?

Question

I have an application which contains multiple state machine instances when running. I would like these to be implicitly persisted to a database in order that if the application is restarted, they can be re-loaded from the database and they will resume in the same state they finished in, along with any object properties which had been set while the instance was in memory.

Is such a thing possible?

I've been searching Google in vain, which means one of three things:

1. This is impossible!
2. I'm terrible at using Google
3. A decent answer to this question will help out a lot of other folk

I hope the answer is 3! :)

Answer 1

Yes it is, but it's no picnic.

I have this implementation running and it took a lot of work to get it done. I won't provide the entire implementation (lots of code and non disclosure), but I will give the building blocks that got me to the end result.

• http://msdn.microsoft.com/en-us/library/dd483375.aspx located in WF_WCF_Samples\WF\Application\PurchaseProcess\CodedWorkflow\CS\WfDefinition\XmlWorkflowInstanceStore.cs has an XML persister for workflow. This circumvents the problem of needing to have the SQL tables and just lets you store the entire thing into one XML blob;

• This serializer (de)serializes the code with a NetDataContractSerializer. This serializer needs to have a SurrogateSelector set with which you translate your entities. The problem is that you do not want to store your entities. Besides that all lazy entities would be serialized together with your entity, by the time your XML is deserialized, your entity will be out of date. What you want instead is that only the internal ID is serialized. So, what you do is implement a SurrogateSelector that checks whether the object being serialized is an entity. If so, you replace it with a different class, say EntityReference which has the type and the ID;

• When the XML is deserialized, witht he same SurrogateSelector, you check for instances of EntityReference. If you find this, you do a ISession.Load() with the type and the ID in the reference and return that instead of the reference.

These are the basic building blocks of serializing and deserializing the workflow. This is not a simple feat, but these parts I got it working.

Hope this helps you.

Answer 2

Nhibernate is not particular useful for this because the physical persistence operation is a minor aspect of workflow persistence. The involved part is all the services that support unloading the reloading and activating workflows at the appropriate times etc. The inner workings of the runtime and services are also complicated by the fact that workflows span application boundaries that can last indefinitely. Various entities can be in various states at any given time. Since a call cannot be guaranteed to even have a client under these conditions, what the runtime actually does when you raise an event in a workflow for example is put a message in a queue rather than calling an actual function pointer. This is how you are able to "raise" an event in a workflow which is not running.

You can access these message queues and other low level details of the runtimes, but it is probably best to try to stay within the Microsoft framework and avoid rebuilding anything as much as possible. Si when you do things their way, which is much easier than tryiong to manage it yourself, Nhibernate becomes rather pointless because all it would do is persist a binary serialization stream.

Among the various extensions available, one is the ability to create custom persistence providers that can operate within the existing workflow framework. There is an Oracle provider already written. Cannot attest to it's reliability, but you should at least be able to build on this.

http://wftools.codeplex.com/

Answer 3

Would this be an appropriate solution?

Using the FilePersistence.cs custom persistence handler I discovered within the download link on the following article:

http://msdn.microsoft.com/en-us/library/ms741725%28v=VS.85%29.aspx

   public class FilePersistenceService : WorkflowPersistenceService
{

    public FilePersistenceService(bool unloadOnIdle)
    {
       // ...
    }

    protected override void SaveWorkflowInstanceState(Activity rootActivity, bool unlock)
    {
        // ...
    }

    private void ReloadWorkflow(object id)
    {
        // ...
    }

    protected override Activity LoadWorkflowInstanceState(Guid instanceId)
    {
        // ...
    }

    protected override void UnlockWorkflowInstanceState(Activity state)
    {
        // ...
    }

    protected override void SaveCompletedContextActivity(Activity activity)
    {
        // ...
    }

    protected override Activity LoadCompletedContextActivity(Guid activityId, Activity outerActivity)
    {
        // ...

    }

    protected override bool UnloadOnIdle(Activity activity)
    {
        // ...
    }

    private void SerializeToFile(byte[] workflowBytes, Guid id)
    {
        // ... Direct workflowBytes to DB, indexed by Guid
    }


    private byte[] DeserializeFromFile(Guid id)
    {
        // ... Load bytes from DB, by Guid
    }

}

... overriding the SerializeToFile and DeserializeFromFile to redirect the calls into a DB rather than the filesystem.

I would probably use NHibernate to accomplish the loading/saving - to keep my DAL common across the application, and hopefully keep DB independence (should it be required to use another DB platform).

Are there any major flaws to this plan?