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.
Tools to Work with WorkFlows
To furnish users the capabilities to create activities and link them together, Microsoft has created tools for different proficiency levels. For developers with knowledge of any of the .NET languages, Visual Studio 2005 is the tool of choice. For less-technically skilled users who still need to assemble some kind of workflow, there are special tools available, for example, SharePoint Designer, formerly known as FrontPage, that permits building workflows for SharePoint 2007 with constraints in the use of advanced properties. At the user level, customers of standard Microsoft software have the possibility of applying prefabricated workflows in documents (Office 2007) in collaboration with SharePoint 2007; in this case, the workflow can be initialized from an Office application (Word, for example), and handled by the workflow engine embedded inside SharePoint. Another Office 2007 application, InfoPath, has the capabilities to bind elements to a workflow.
Because Visual Studio is the tool for developers of Microsoft software, the WorkFlow Foundation installation setup also provides the necessary Visual Studio 2005 add-ins to design and program workflow. Additional project templates are ready for use after installation (Sequential and State Machine WorkFlow Libraries, WorkFlow Activity Library, WorkFlow, and State Machine Console Applications) and a new Library of Tools with the provided preprogrammed Activities is available.
Figure 2: Visual Studio 2005 .NET WorkFlow Designer
As shown in Figure 2, a workflow is described by dragging and dropping Activities from the toolbox and visually linking them together. As with other applications developed with Visual Studio, the Activities have associated code, and clicking on the shape of the Activity will open the code-behind page where custom code can be written in C# or Visual Basic (See Figure 3). The visual design and the code are permanently linked and any change in one will reflect back in the other automatically.
Figure 3: Visual Studio 2005 .NET WorkFlow code-behind
The definition of the WorkFlow in the Visual Studio designer is saved in an XOML file, an XML file that can be edited manually using any ASCII editor (Notepad, for example).
The complete Visual Studio developers experience is present to work with workflows: smart tags alert users that elements are not properly configured, IntelliSense, code completion, and so on. Complete support for debugging, breakpoints, stepping into and out, call-stack, and attaching are available. When the code design and code are completed, the developer can built the project and, depending on the kind of host, the result will be a managed FrameWork 2.0 assembly that can be interpreted by Windows.
The Visual Studio designer for WorkFlow can also be completely re-hosted outside of Visual Studio .NET and then be hosted in a custom application. This affords the possibility of creating specialized activities packages to provide customers the option to built and modify workflows. Because the definition of the workflow is only an XML file, it also is possible to create and modify workflows programmatically and compile them with the command-line .NET compiler wfc.exe. This opens intriguing new scenarios for building artificial intelligence or adaptive workflows or even workflows that can build their own workflows or modify themselves on the fly.
The Windows WorkFlow Foundation runtime and workflows require full trust to execute in the Windows context. Because of this, the developers and administrators must bear in mind that all custom Activities need to be extensively tested before incorporation into a workflow and be aware that exception handling is very important (exceptions not handled by the workflow should result in workflow termination) and that authorization changes made by a workflow can be a security vulnerability for the system.
The Windows WorkFlow Foundation is the Microsoft model to abstract process oriented applications in a visual and algorithm centric way, linking the individual processes and activities that need to happen in a particular time frame and order. In a traditional approach, this flow of events would be programmed in the business or logical layer of the application, in the same way that other software pieces are coded; with the Foundation and its process abstraction, the workflow can be handled in a reusable, controlled way, supplying a more suitable and logical framework. To built and deploy workflows, Microsoft provides a complete developmental environment, but also grants the possibility of using less sophisticated tools, leading the way to construct the workflows programmatically.
About the Author
Gustavo Velez is an MCSD Senior Application Developer for Winvision (http://www.winvision.nl), a Microsoft Gold Partner in the Netherlands, with many years experience in developing Windows and Office applications, and more than three years of daily programming experience with SharePoint. He is also Webmaster of http://www.gavd.net/servers, the only Spanish-language dedicated SharePoint site.