What are your experiences with Windows Workflow Foundation?

Question

I am evaluating WF for use in line of business applications on the web, and I would love to hear some recent first-hand accounts of this technology.

My main interest

Answer 1

I consider MS WF as a low-level workflow library rather than a fully fledged enterprise workflow product such as K2. It will enable you to build a workflow enabled application, but is not in itself a workflow application. My experiance of it in this capacity has been positive, although we have had to build a lot of our own infrastructure around it (a pub/sub framework, a worlkflow lifetime manager etc). A lot of the documentation out there is fairly simplistic and does not cover building up an enterprise workflow application based on MS WF.

Answer 2

Hard to learn. Quite flexible. Not to be confused with a visual tool for end users, only for programmers. Not sure if I like the dependancy property approach.

Answer 3

Windows Workflow Foundation is a very capable product but still very much in its 1st version :-(

The main reasons for use include:

1. Visually modeling business requirements.
2. Separating your business logic from the business rules and externalizing rules as XML files.
3. Seperating your business flow from you application by externalizing your workflows as XML files.
4. Creating long running processes with the automatic ability to react if nothing has happened for some extended period of time. For example an invoice not being paid.
5. Automatic persistence of long running workflows to keep resource usage down and allow a process and/or machine to restart.
6. Automatic tracking of workflows helping with business requirements.

WF comes as a library/framework so most of the time you need to write the host that instantiates the WF runtime. That said, using WCF hosted in IIS is a viable solution and saves a lot of work. However the WCF/WF coupling is less than perfect and needs some serious work. See here http://msmvps.com/blogs/theproblemsolver/archive/2008/08/06/using-a-transactionscopeactivity-with-a-wcf-receiveactivity.aspx for more details. Expect quite a few changes/enhancements in the next version.

WF (and WCF) are pretty central to a lot of the new stuff coming out of Microsoft. You can expect some interesting announcements during the PDC.

BTW keeping multiple versions of a workflow running takes a bit of work but that is mostly standard .NET. I just did a series of blog posts on the subject starting here: http://msmvps.com/blogs/theproblemsolver/archive/2008/09/10/versioning-long-running-workfows.aspx

About visually modeling business requirements. In theory this works quite well with a separation of intent and implementation. However in practice you will drop quite a few extra activities on a workflow purely for technical reasons and that sort of defeats the purpose as You have to tell a business analyst to ignore half the shapes and lines.

Answer 4

We've used WF in a large-ish SharePoint application and I can say it's OK. It has lots of power and flexibility. and, as Kevin mentions, once you grok the underlying concepts of workflows, you can do pretty much anything you want with it.

On the other hand, it has some really serious issues, like lack of versioning, which can really hurt your application in the future. We've been forced to deploy up to 3 parallel versions of the same workflow named xxx-v1, xxx-v2 and xxx-v3 to keep older instances running and have new instances use the updated versions. A real pain in the ass. Oh, and there are also some really non-intuitive concepts in there (correlation tokens, wtf??)

Answer 5

Related question: When to use Windows Workflow Foundation? My answer there:

You may need WF only if any of the following is true:

1. You have a long-running process.
2. You have a process that changes frequently.
3. You want a visual model of the process.

For more details, see Paul Andrew's post: What to use Windows Workflow Foundation for?

Please do not confuse or relate WF with visual programming of any kind. It is wrong and can lead to very bad architecture/design decisions.

So, if you have such requirements, then WF is a good candidate. Of course it is relatively complex, but mention that the problems that is trying to solve is also complex (and sometimes very complex). IMHO, it is very complex for example to dehydrate/rehydrate objects that have event handlers attached (with events that can be triggered when the object is not in memory).

I can not judge what you mean by "small to medium-sized project", but in general I would say that if your project has at least two requirements from the above list, then you can consider WF as a solution.

Answer 6

Brian, I can't reply to your comment, but anyway, by versioning i mean making changes to the underlying code of the workflow without breaking already running instances, and gracefully applying updates to existing workflows. I'm not sure about 'stock' WF, but at least in SharePoint environment there's no concept of workflow versions so new versions have to be deployed as completely different workflows which becomes a maintenance nightmare. This has nothing to do with 'rehydration', rehydration is the process by which you bring a 'dormant' workflow back to activity after some event or change in state. That is handled transparently by the workflow runtime.