Tuesday, May 20, 2008

Windows Workflow still immature

I have been spending the last couple of weeks looking at how to integrate Microsoft Windows Workflows into my ASP.Net website. It is a basic usage of workflow - implement a state machine, do some processing on state initialisation, maybe fire an email or reminder here and there. It all sounds great on the surface and it basically works. But there are a few things that will just mean that it isn't workable in my site.

You see I have long running workflows, let's say longer than a week. They might hang around waiting for user input, a client to phone back, fill in a web form or something of that nature. However I am taking an agile approach to this particular development - releasing little functionality increments for the client. The problem is that workflows are tied to assembly versions, and my assembly versions are changing all the time. Not to mention that the workflow structure is also changing all the time.

So what do I do? Something like Ruurd Boeke suggests could pass, but hell that is a lot of work, considering I'll be doing this every two weeks or so. I don't have a good solution, so for the moment it is shelved. I'll just implement a basic state flag on my object and then provide a generic mechanism for faking the state flow. If things are designed right then I should be able to reuse any code in workflow activities once it all gets running. I'll try to use workflows for some of the short tasks that are required, just to make sure I am still getting my feet wet with the technology.

This seems like a typical trend for Microsoft to release something that is really, really beta (nay, alpha?) to gauge public opinion and then develop it a production standard later on. Windows workflows seem to me like they are nowhere near ready for production systems.

Do you have an opinion??

kick it on DotNetKicks.com Shout it

No comments: