Windows WorkFlow Foundation (WF) is one of the core components of the .NET 3.0 Framework (formerly WinFX) wave from Microsoft. It provides a singular engine to ensure the workflow execution for all Microsoft applications in the Windows platform.
Windows WorkFlow Foundation (WF) is the Microsoft technology that provides the model, engine, and tools to define, execute, and manage workflows. It is a constituent part of the Microsoft .NET 3.0 Framework , together with the Windows Communication Foundation (WCF, formerly codenamed Indigo) and the Windows Presentation Foundation (WCP, formerly code-named Avalon). WCF is a set of .NET technologies for building and running interconnected systems, and WCP allows the foundation to build the presentation layer for Windows applications.
A workflow is the movement of information, documents, and tasks through a working process, all aspects of which perform an action, define the relationship of this action with other components of actors, and allow for the synchronization of the different actions. All of these activities are involved in the WorkFlow. From this point of view, a WorkFlow involves different dimensions:
- The actions that are performed
- The actors who perform them
- The time dimension within which everything will happen
The tools of WF sanction users to describe, visually design, and program algorithms to create WorkFlows not only for Windows applications, but also for any kind of system using the embedded SOAP Web Services. By using Microsoft Visual Studio 2005, designers and programmers not only create the WorkFlows, but also fashion the constitutive parts or the WorkFlow Activities, a reusable software ingredient that defines the building blocks.
The Object Model of the Windows WorkFlow Foundation provides the classes, methods, and properties to program against the WF engine. WorkFlows can be started, stopped, and their status queried. More advanced tasks, such as controlling the state and modifying a WorkFlow at run time, are also possible with its Object Model.
The Foundation provides two main types of WorkFlows: Sequential and State Machine. For the construction of WorkFlows, one needs to utilize Activities, the smallest piece of action that the flow employs. Additionally, a WorkFlow requires a Host in which context the process will be executed.
Types of Windows WorkFlows
A Sequential WorkFlow is a Top-Down process, also known as a Human Flow Process, where the activities transpire from a beginning situation and end after a predefined sequence of steps. Each human activity can be described as a function of a Sequential WorkFlow; business authorization activities are a well-known type. Consider tasks such as order processing, expenses approbation, or purchase requests as typical scenarios of this kind of flow. Sequential WorkFlows are self-driven; once they are initiated, they have a totally predictable behavior throughout the execution of the activities.
The State Machine WorkFlow does not have a defined path but represents a set of states and transitions between these states. State Machine WorkFlows are event-driven: Each state can be activated after a predefined action has taken place; then, the engine executes the activities needed and stops after completion of the next state. There is no deterministic execution path between the steps because the WorkFlow does not execute in a chronological order.
State Machine WorkFlows are the solution for complex modeling processes. Visualize an order supply process where an order can have different states: received, approved, and shipped. In a sequential model, the only way to realize a WorkFlow is by using loops and decision algorithms that code all possible paths of the order (if received data is not complete then..., if product is not in stock, wait until..., and so forth). The State Machine provides a very convenient design pattern that defines a state of the process and includes all the variables to make it valid (following the last example; a state can be received when all the data of the order is present before the process can go on to the next state: approved. Each state is stopped after completion and an external event, generated by the state itself, can promote it to the next state).
Not every workflow problem lends itself to a State Machine over a Sequential WorkFlow. State Machine WorkFlows offer a natural, rational model where the state and the present activity of the process that is being executed are more important than the order of the steps to complete. In situations requiring many unplanned steps to track and where it may not be possible to represent all the possible paths to follow, a State Machine WorkFlow can be easier and more orderly to program.
Components of a Windows WorkFlow
Activities are the construction blocks and the smallest constitutive element of a workflow. An Activity represents an action in a workflow; it can be anything from a straightforward action (as a timer) to a composite action that consists of an assembly of several activities. They can be aggregated to a workflow by using Microsoft Visual Studio 2005, an external tool, or programmatically to form a complete process. Activities can also be sequential, as the whole workflow itself, where the order of the steps is predetermined at design time, or it can be event-driven, where the order of the actions is determined at run time in response to external events, as in the State Machine WorkFlow.
The WF contains a library of standard Activities and also provides the mechanisms to create your own, thus ensuring reusability between different workflows. The included Activities provide functionality for communication with services and applications, control flow, event handling, conditions and looping, and state management. Some Activities can act as a container for other Activities: Exception handlers, Compensation, and Event handlers can host every kind of activity; so defined, the Sequential WorkFlow and the State Machine WorkFlow are also Activities of a special kind that contain complex definitions.
Different types of Activities are the Condition Activities—Sequence, Parallel, While, IfElse, ConditionedActivityGroup and Replicator—that contain conditions and rules to control the flow of the actions. Another group of Activities are the "WorkFlow Lifetime Activities:" InvokeWorkflow, Suspend, Terminate and Delay that affect the life and handling of time in the workflow. With the latter group of activities, it also is possible to execute other workflows asynchronously, allowing for cascading workflows and the reuse of existing ones.
The Event Waiting Activities group, namely EventDriven and Listen Activities, enable the processing of a workflow to be stopped until some external action occurs; the Listen Activity contains multiple EventDriven activities and works as a container for events of a different kind. The Transaction and Exception Activities group, TransactionalContext, Throw, ExceptionHandler, and Compensate Activities, catch and throw exceptions, permit the processing to continue after any exception has occurred, and make it possible to define short- and long-term transactions inside the workflow.
As a final point, the Code Activity is arguably the most utilized Activity for programming custom algorithms in the workflow because it permits adding code handlers everywhere in the workflow. This Activity enables developers to insert .NET code—such as C# or Visual Basic .NET code—into the WorkFlow and to compile this code together with the code-behind of the workflow.
Host for a Windows WorkFlow
The Windows WorkFlow Foundation has no intrinsic execution processes; instead, it is an in-process engine that runs contained in a host process. The host process provides the set of services needed for the lifecycle of the workflow.
Any application that can execute workflows of the WF and manage their lifetime (start, stop, pause) can be considered as a host. In the first instance, any Windows application that can execute managed code on the .NET Framework 2 (and upwards) also can execute workflows and be a host. On the other hand, as each workflow needs a host to function, a Web service, Web page, Windows Form application, console application or Windows service also can host a workflow.
The host is in charge of initializing the workflow and has control over its lifetime, messaging, and configuration-related tasks. To perform the task, WF presents namespaces, methods, and properties in the object model to interact with the workflow: the WorkFlowRuntime class holds a couple of namespaces (Runtime, Hosting, Messaging, and Configuration) that manage the timing and configuration of the workflow.
WorkFlow Foundation uses a layered architecture within any application into which it is integrated.
Figure 1: Architecture WorkFlow Foundation
At the top of the model is the location where developers build the code to run a workflow. This layer provides the out-the-box Activities, the model for the construction of custom Activities, and the engine to build rules, as well the plumbing tools to configure and connect the Activities together. The tools to build and work with workflows will take action in this layer.
The Runtime layer ensures the execution aspects of the workflow and contains the mission-critical services required: for example, the state management and persistence service, the rules service that provides policy execution functionality, the scheduler service, and the tracking service.
The Hosting layer is the connecting link between the WorkFlow Foundation and the outside world and provides a package of services (Persistence, Timer, Tracking, Communication) needed to guarantee the control and management of the workflow. Although interfaces needed for this layer can be specially developed if appropriate or desired, WF ships pre-built services that provide all the interfaces necessary to work with FrameWork 2 (and upwards) of .NET.