n September of 2005, Microsoft unleashed Windows Workflow Foundation (Windows WF) at its semi-annual Professional Developer's Conference. As one of the pillars of the WinFX APIs, Windows WF provides developers with a common framework on which to develop process driven and workflow-centric applications.

Currently, when organizations wish to automate business processes the standard answer is to assemble a team of developers to write the appropriate code. While this approach has generally served organizations well, it has some inherent problems. To understand why, you need to understand some fundamental characteristics of a workflow.

A workflow is essentially a way of documenting the activities involved in completing a unit of work. Typically, work "flows" through one or more activities during processing. These activities can be performed by either machines or by people, and can be as simple as defining the sequence of pages in an Internet application, or as complex as managing documents or products that must be seen, altered, and approved by any number of people.

Because so many workflows must allow for human involvement, they can take long periods of time to complete, ranging from hours to months or longer. For example, people involved in the process may be unavailable, out-of-town, or busy with other tasks; therefore, workflows must be able to persist themselves during periods of inactivity. Furthermore, processes implemented solely using code can be difficult for non-technical people to understand and for developers to change. This and other factors are the target of generic workflow frameworks such as Windows WF, which aim to make creating, altering, and managing workflows easier, both by giving them a visual interface and by defining a common API.

You can host Windows WF workflows in any type of .NET application, including Windows Forms, console applications, Windows Services, and ASP.NET Web applications. Each type requires special considerations. While examples that showcase hosting workflows in Windows Forms and console applications are already plentiful, this article focuses on issues facing ASP.NET developers who wish to integrate workflow into their applications.

Author's Note: The code provided with this article was written with Beta 1 of Windows WF and Beta 2 of Visual Studio 2005. You can find information on installing Windows WF at www.windowsworkflow.net. While this article covers some basics of Windows WF, there are other resources available that cover the essentials. I've assumed that readers have at least some exposure to Windows WF. The purpose of this article is to dig into Windows WF and ASP.NET, rather than to cover Windows WF at a high level.

Windows WF and the MVC Pattern
One common way in which you might use Windows WF in an ASP.NET application is to implement a Model-View-Controller (MVC) approach. Essentially, the goal of MVC is to separate the presentation layer, application logic, and application flow logic from each other.

To illustrate how this would be useful in an ASP.NET application, consider a help desk ticket workflow scenario. A business user starts the workflow by filling out an ASP.NET Web form and clicking a submit button. Next, a server notifies a help desk employee using a Windows Forms application that a new ticket is available. The help desk employee would then work on the problem, and eventually close the ticket. If this workflow scenario were developed using Windows WF, all the process logic and flow could be contained in the workflow itself, and the ASP.NET application would need to know nothing about the logic.

This scenario provides some solid evidence that separating presentation from logic is a good thing. Because the process of handling help desk requests is common, if the logic were implemented using C# or VB.NET code in several different .NET applications, you'd run the risk of duplicate code or worse, different implementations of the same business process in completely different code. But if you implement the process in Windows WF, the developers of applications that need the process would need to modify the steps in only one place—the workflow itself—without worrying about changing logic in their applications. Code duplication and the ambiguity of where to implement process can be mitigated with Windows WF.

When implementing the MVC architecture in ASP.NET using Windows WF, developers should attempt to build workflows independent of the applications in which they will be hosted. This will assist in keeping logic separate from presentationand maintain a high degree of independence between the order of workflow steps and page flow in the Web application.

A novice Windows WF developer might be tempted to develop a workflow with a set number of activities in a certain order and afterward, develop a set of ASP.NET Web forms that flow from one to another in the same order. Unfortunately, while that seems logical, it's counterproductive, because you would be implementing the workflow logic twice. Web page X should not need to know whether it needs to go to Page Y or Page Z to implement the workflow steps correctly. Instead, the workflow (the model) should tell ASP.NET (the controller) what the next step is, and then ASP.NET should determine which page (the view) to display. In this way, each page requires little knowledge of the overall process; it only needs to know how to complete one distinct activity and let the workflow worry about how the pages flow from one to the next. This separation provides developers with a great deal of flexibility related to the order of page flow. For example, if you decided to change the page display sequence, you could easily do that in the workflow, without changing one line of code in the ASP.NET application.