David Chappell


Get the Feed! Subscribe

The Workflow Way  
# Monday, May 18, 2009
Windows Workflow Foundation (commonly called just WF) is a useful technology. It's not so simple to understand and use, however, and so it's not a widely used choice among enterprise Windows developers today. A primary goal of WF's next release is to change this, making the technology more approachable and more popular. For this to happen, people need to understand what WF really offers.

Toward this end, I've written a new introduction to WF. Called The Workflow Way: Understanding Windows Workflow Foundation, the paper's goal is to explain WF to mainstream Windows architects and developers in a straightforward way.

To me, everybody who builds software on Windows ought to understand the basics of WF--it's a fundamental part of the application platform. And while workflow isn't always the right approach, it's sometimes just what you need.

8 comments :: Post a Comment



This white paper is indeed a good introduction for developers who want to understand who to decompose their applications into a flow of activities. Good work!

Thanks very much, Edwin. Especially given your strong background in this area, I really appreciate your comments.

Respect. Thank you for making this complex topic [WF] crystal-clear for me.

By now, I believe I could actually explain how and when to use WF.

Brian Berry - Houston, TX

Hi! WF is very good for business process but this kind of iniciatives are not good for new companies.

I'm puzzled. Don't new companies need to implement business processes?

Hi David, this was a good read. Very informative. I never considered WF up until now, but the new release seems promising.
I'm a bit concerned about the persistence store though. Couldn't that be a scalability bottleneck? From one of your diagram, it looked like it was shared by multiple WF runtimes. I was wondering if it is possible to scale that part of the system too and how.

I really appreciate all your clarification of Microsoft technologies.
However, here, IMHO, you oversimplify the WFW classical "competition".
No decent server is single threaded as you describe in Fig. 1. The code is that way but multiple threads share it, and consequently share data and locks (state) in process memory .
So the issue is more a matter of sharing state in memory vs sharing state on disk (Fig. 2).
This changes the way to present how WFW helps. As I see it, its value is to handle in the run time (and so hide from the programmer) the necessary locking and persisting of activities' shared state at some synch points.
So the trade-off between traditional multi-threaded server and WFW-based server is caring about shared variables in memory or analyzing your problem using activities and messages.

You're right, Jacques--I think the paper is a bit oversimplified in this area.

My target audience, though, was mainstream .NET developers, especially enterprise developers for whom multi-threading isn't such a familiar concept. Accordingly, I chose to make the story a bit simpler than the one you describe.

It's always a challenge to write something that's clear, accurate, and simple. Maybe I can tackle the perspective you suggest in a future revision of this paper.

Post a Comment

<< Home