As its name implies, Microsoft's Windows Workflow Foundation, or WF, is a framework for creating workflow-enabled applications. It has emerged as a major piece of .NET 3.0 and, thus, developing applications for Windows Vista.
Workflow here refers to the sequence of, and relationship among, events in a process like verifying a customer's credit card information or filling out a survey. WF defines the events in a workflow as activities, links them to a runtime engine and runtime services and gives developers the ability to apply persistence, tracking and serialization to workflows and activities.
A good starting point is Manage application processes with WF, an article by Brian Noyes on sister site TheServerSide.NET. Once a workflow has been designed -- graphically, using Visual Studio 2005 -- Noyes outlines how to host a workflow in an application, run it and, most importantly, write the code that lets the workflow get the data it needs.
"Once you get over the initial learning curve…you should find the resulting applications artifacts easier to understand, maintain and change," Noyes writes. "You can start at the top level abstraction of an overall workflow and drill down to just the activities that concern you through the graphical flowchart design model."
Another good introductory resource is Bart De Smet's blog entry, Getting started with WF. De Smet offers a quick tutorial on creating a sequential workflow with code separation and then executing it.
Developers who want to play with the drag-and-drop graphic design capabilities of Windows Workflow Foundation should check out Jon Flanders' Web-based Atlas Workflow Designer. You can check out the application here and read about it in this blog entry. (Word to the wise: A red exclamation point means an activity is not configured properly.)
Once one understands the basics of WF, it is time to dig deeper into the framework. De Smet offers a two-part series on making workflow dynamic. Part 1: Modification from the inside demonstrates how to add and remove workflow activities. For this to work, a workflow must be built to allow changes. Part 2: Modification from the outside shows an alternative to making changes inside a workflow -- suspending the workflow and making changes outside the workflow sequence.
Meanwhile, a second Noyes tutorial, Will work for process: Create and run WF workflows, looks at how Windows Workflow Foundation runs within a particular process and at WF's host communications model, which is a critical factor in integrating workflows into applications as well as a complex one. This, Noyes notes, is because a workflow is a tad more involved than a program: "If a workflow can be dehydrated and persisted out to a database at any given point in time, you can't just hold object references in memory to a workflow to communicate with it the way you would with other objects in a program."
Is WF too complex?
Dig deep into Windows Workflow Foundation and it becomes clear that many parts of WF, like the host communications model, can seem complex. Is it because WF itself is complicated or because workflows themselves are complicated?
In a blog entry written the day after a user group meeting, Noyes writes, " The more I work with WF, the more comfortable I get with it, but also the more I become convinced that they need a WF-Lite version….[C]ertain aspects, particularly communicating with the executing workflow, are much harder than calling from one chunk of code to another in a standard .NET application."
K. Scott Allen agrees: "Setting up communications between a workflow and its host is a tremendous amount of work, and it's easy to get wrong….WF isn't as easy as it first appears. It's powerful, but requires an investment of time."
Flanders, author of the Atlas Workflow Designer, takes the time to respond to both bloggers. He agrees that Windows Workflow Foundation is not easy -- but argues that an easy WF would not be a powerful WF. In addition, he writes here in his blog, WF, like BizTalk Server, is all about modeling processes:
You have to remember the charter of the WF Team -- they aren't just building a visual way to write random .NET code[,] they are creating a way to write applications that are workflow enabled, that need all or some of the potential services that the WF model provides. The workflow runtime is based on a certain set of assumptions about how applications should be put together…Perhaps your application won't do well with the model that WF provides. But I think with more and more people writing services[,] there is going to be a big need to tie those services together.
This discourse shows that Windows Workflow Foundation remains a work in progress. As with any new framework, there is much to learn and much to question. Knowing what WF is meant to do, as Flanders points out, is a good first step -- but other steps soon follow. If you have any WF resources that you would like to share, send them along and we'll add them to this tip.
