We've all been involved with software projects that try to improve a business process. The process might have involved pizza orders, or financial transactions, or health care. Invariably, the word workflow will arise as we talk about these projects. While the workflow might sound simple, we know the devil is always in the details. We'll need database tables and data access classes to manage the workflow state. We'll need components to send emails and components to wait for messages to arrive in a queue. We will also need to express the workflow itself for the computer to execute. Let's look at a theoretical implementation of a workflow:

// The workflow for a newly submitted Purchase Order
class PurchaseOrderWorkflow
{
public void Execute(PurchaseOrder order)
{
WaitForManagerApproval(order);
NotifyPurchaseManager(order);
WaitForGoods(order);
}
…
}

Assuming we have definitions for the three methods inside of Execute, can a workflow really look this simple? The answer is no. We'll have to add code for exception handling, logging, and diagnostics. We'll need to raise events and provide hooks to track and cancel a running workflow. Also, this workflow will be idle and waiting for an external event to occur, like the arrival of the purchased goods, for the majority of the time. We can't expect to block a running application thread for days or weeks while waiting for a delivery. We'll need to provide a mechanism to save the workflow's state of execution to a persistent data store and remove the running workflow instance from memory. When a significant event occurs, we'll need to restore the workflow state and resume execution.

Unfortunately, we will have so much code in and around the workflow that we will lose sight of the workflow itself. All the supporting code will hide the process we are trying to model. A non-technical businessperson will never be able to look at the code and see the workflow. A developer will need to dig through the code to find the workflow inside.

An improved workflow design will try to separate the definition of a workflow from the engine and supporting code that executes the workflow. This type of approach allows a developer, or even a businessperson, to express what the workflow should be, while the workflow engine takes care of how to execute the workflow. These days, many workflow solutions define workflows inside the loving embrace of angled brackets. Let's look at some theoretical XML for a workflow definition:

<Workflow Name="PurchaseOrderWorkflow">
<Steps>
<WaitForTask Event="ManagerApproval"/>
<NotifyTask Target="PurchaseManager"/>
<WaitForTask Event="Delivery"/>
</Steps>
<Parameters>
<Parameter Type="PurchaseOrder" Name="order"/>
</Parameters>
</Workflow>

Let's ask the question again — can a workflow really look this simple? The answer is yes; what we will need is a workflow engine that understands this XML, and can transform the XML into instructions for the computer. The engine will include all the required features like exception handling, tracking, and enabling cancellations.

One of the benefits to using XML is the large number of tools with the ability to read, modify, create, and transform XML. XML is tool-able. Compared to parsing C# code, it would be relatively easy to parse the XML and generate a visualization of the workflow using blocks and arrows. Conversely, we could let a business user connect blocks together in a visual designer, and generate XML from a diagram.

Let's think about what we want in a workflow solution. We want to specify workflows in a declarative manner, perhaps with the aid of a visual designer. We want to feed workflow definitions into a workflow engine. The engine will manage errors, events, tracking, activation, and de-activation.

Enter Windows Workflow Foundation.