Did you successfully adopt Windows Workflow in a real world web application?

Question

I have recently posted a question regarding the Windows Workflow running in a web application. Granted it was a fairly technical question that contained terms like ManualWorkflowSchedulerService, HandleExtrenalEvent, etc... it got about 15 views over the course of 20 days.

While it is most likely a matter of me not asking the question the right way, it got me thinking about the adoption of windows workflow in real world applications, especially in web applications.

Have you successfully implemented real world internet applications with WF and looking back, has the investment of your time (money) paid back?

Answer 1

I used Windows Workflow in a web application designed to manage the lifecycle of change control requests in an enterprise system. I admittedly fumbled around in it, and definitely didn't do a lot of things correctly, but it worked pretty well and I was satisfied with how easily I could change the rules without writing even more code.

However, once I rolled off the project, the person who inherited it decided he didn't like WF or didn't want to learn it, so the application died and they went back to using emails and phone calls. So the the implementation was successful, but the investment was ultimately a waste.

Answer 2

My experience was simillar to Out Into Space, we had looked at using WF to control a compelx and varried ordering process, in variuos B2B scenarios. Last I heard they were in the process of gutting it.

I think it is hard for many developers to think in terms of workflow.

Answer 3

We use the state machine workflow to manage a couple service request processes with about 10 states each. I am not sure if it is was 100% the right choice, because implementing a simple state machine design would have been simpler(maybe we suffered here from BDUF).

The biggest downside for us was the learning curve. I mean, workflow is practically a stripped down version of biztalk(for free!).

Off the top of my head, these are the areas we've benefited from WF:

• Hosting the workflow as service forced us to decouple the workflow from our other layers, and this(so far) has been a pretty decent design.
• We have been able to easily interact with the work flow from various applications using the provided workflow service host
• Tracking service provides good business metrics
• Runtime service and persistance service are stable
• Changes to running workflows are complicated but work better than if we would have tried do it ourselves

I always try to keep in mind that it really is a foundation. As a developer/architect, you have to commit to building something useful on top of it.

Answer 4

I have deployed 3 applications. 2 are ASP.NET applications and 1 of the workflow was deployed to a SharePoint environment. Looking back, I think the investment was worth it. Like the previous guy said, WF is a framework that you have to build upon. It's one more layer to worry about but the benefits outweigh the costs.

Answer 5

hi Tom i really dont think WF shines well when we are using web applications cause most likely we are gonna use DB to persist state you have exactly asked the question which i had on my mind we had used WF in our production environment and its giving lots of problem when we are upgrading from one version to another secondly it has lots of limitations i.e. it does not support ambient transaction i think we should wait for Version 4 or 5 to see if it has anything better to offer