Windows Workflow Foundation (WF) is a Microsoft technology that provides an API, an in-process workflow engine, and a rehostable designer to implement long-running processes as workflows within .NET applications. The current version of WF was released as part of the .NET Framework version 4 and is referred to as (WF4).
A workflow, as defined here, is a series of distinct programming steps or phases. Each step is modeled in WF as an Activity. The .NET Framework provides a library of activities (such as WriteLine, an activity that writes text to the console or other form of output). Custom activities can also be developed for additional functionality. Activities can be assembled visually into workflows using the Workflow Designer, a design surface that runs within Visual Studio. The designer can also be hosted in other applications.
Encapsulating programming functionality into the activities allows the developer to create more manageable applications; each component of execution can be developed as a Common Language Runtime object whose execution will be managed by the workflow runtime.
The workflow engine provides the following features.
Scheduling and executing workflows and activities. Workflows can be executed using one of three methods:
Using WorkflowInvoker, which executes workflows on the calling thread (that is, a new thread is not created for the workflow). This means that the calling process will wait for the workflow to complete.
Using WorkflowApplication, which executes workflows on a new thread (so that the calling application will not pause its execution while the workflow runs).
Using WorkflowServiceHost, which will execute the workflow as a WCF Service. The resulting workflow service will typically use data from the network as inputs for contained activities.
Managing the flow of execution between activities. Workflow execution can be modeled visually in the designer, using activities such as Flowchart, If, Sequence, Pick, and Parallel.
Persisting workflows. Persisting a workflow saves the workflow's data to a persistent medium (such as SQL Server) and unloads the workflow from memory. The workflow can be reloaded after a specified time period, or when the workflow receives a message. By removing idle workflows from memory, the workflow engine can greatly increase the number of active workflows a system can handle, thus increasing scalability.
Managing data for executing activities. Data is consumed by activities using Arguments and Variables, which the runtime maintains. Using arguments and variables to store data for activities means that the runtime has access to an activity's complete state in the event that it needs to be persisted. The runtime can also correlate incoming messages and data to a specific workflow instance in the case that several workflows are running concurrently.
A built-in tracking provider that records built-in Workflow events (such as an activity starting, completing, or faulting), or custom events (such as a custom activity tracking application-specific data). The default tracking provider in .NET Framework version 4 records tracking events to the Windows event log, but a custom tracking provider can be developed to track events to other event repositories.
Providing extensibility in the form of Workflow Extensions. Extensions are custom objects added to the runtime that provide custom functionality, such as enhanced communications with the host process or custom persistence and tracking functionality.
Providing visual debugging capabilities using the workflow designer. Workflows can be executed in the development environment, and debugged using the same breakpoint and stepping processes used in debugging code.
Workflow Foundation versions
Workflow Foundation was first released in Version 3 of the .NET Framework, and primarily uses the System.Workflow.Activities, System.Workflow.ComponentModel, and System.Workflow.Runtime namespaces. Workflows in version 3 were created using either the Sequential model (in which activities are executed in order, with the completion of one activity leading to the next), or the State Machine model (in which activities are executed in response to external events). Microsoft SharePoint 2007 uses WF 3.
In .NET 3.5, messaging activities were introduced that integrated Workflow with Windows Communication Foundation (WCF). With the new ReceiveActivity, workflows could respond to incoming WCF messages. The new features of Workflow in version 3.5 use the System.ServiceModel namespace. Microsoft SharePoint 2010 uses WF 3.5.
In .NET 4, Windows Workflow Foundation was largely updated, with new features such as Data Contract Resolver, Flowchart, and other flow control activities added. Workflow in .NET 4 uses the System.Activities namespace. Most notably, there is no longer a Workflow Runtime object in version 4; workflows are executed directly using WorkflowApplication or WorkflowInvoker instead.
Activities created in previous versions of the .NET Framework can be executed by .NET 4 workflows using the Interop activity.
Future versions and releases of WF will include an updated State Machine and Dynamic Update.
Workflow usage scenarios
Windows Workflow Foundation is used to create applications that execute an ordered business process, such as the steps needed to approve a document, hire a candidate for a position, or make a purchase. These processes can execute in a short amount of time, but are typically long-running, in which the application will need to shut down to conserve memory between steps. Typically, business processes to be modeled as workflows have the following features:
Have specific business logic that may need to change periodically, such as the tax or shipping calculation needed to determine the purchase price of an item, or the series of steps needed to approve a purchase, hire, or process.
Have several inputs into the workflow that may come hours or days apart
Have advanced business logic that might require workflow execution to travel down different branches depending on different circumstances.
Need to interact with other systems, such as a database, website or other client application, or web service.
Workflows are created either by being defined in XAML Extensible Application Markup Language using the workflow designer, or by being assembled programmatically in a .NET language such as C# or VB.NET. If the designer is used, activities are assembled on the workflow designer canvas by dragging them from the toolbox. Workflow arguments and variables are also created and assigned within the designer. If a workflow is assembled in code, activities are instantiated like other CLR objects, and assembled into collections of a single parent activity, usually a Sequence or Flowchart. The single parent activity is then executed using WorkflowApplication or WorkflowInvoker, and runs as a workflow. The term "Workflow" here usually refers to the root activity that is executed by the host. Workflows can use both out-of-box activities and custom activities. Out-of-box activities include flow control activities such as DoWhile, Flowchart-related activities such as FlowDecision, WCF Messaging activities such as Send, and primitive activities that perform simple tasks like Assign and WriteLine. Custom activities are user-created CLR objects that derive from the class System.Activities.Activity, and provide declarative functionality by allowing the developer to define the execution behavior of the activity in code. Custom activities can benefit from having a custom activity designer associated with them to enhance the visual authoring experience in the Visual Studio IDE.