A process-oriented design, driven by a workflow, can be the right approach for a significant fraction of Windows software. The purpose of WF is to let developers create and execute these workflow-based applications. The diagram below shows the components WF provides to do this.
As described earlier, every workflow is built from some number of activities. Workflows and activities are just classes, so both can be created directly in code. WF also provides the Workflow Designer, a Visual Studio-hosted graphical tool for constructing workflows. However a workflow is created, its activities can be drawn from the Base Activity Library (BAL) provided with WF or from any other source.
Once a workflow has been defined, it’s eventually executed by the WF runtime engine. This engine relies on a group of runtime services for persisting the workflow’s state, tracking the workflow’s execution, and more. All of these things—the runtime services, the runtime engine, and the workflow itself—are contained within some host process. This process can be any Windows process, ranging from a simple console or WPF application running on a desktop to a scalable server process.
Understanding WF requires knowing at least a little about all of its components. The following sections take a brief look at each one.
Stripped to its essentials, a workflow is nothing more than a group of activities. WF provides built-in support for two styles of workflow:
Sequential workflows, which execute activities in a defined order. Like a traditional flow chart, a sequential workflow can contain branches, loops, and other control structures. By default, however, activities execute in sequence, one after another.
State machine workflows, which implement a traditional finite state machine. Like any state machine, which activity executes at a particular time is determined by the combination of the current state and whatever event has been received.
The sequential option is useful for well-defined workflows, such as those used in purely software-based processes. They’re relatively simple to create and understand, and they initially feel more natural to most developers. State machine workflows are a better choice when the path of execution is less predictable. A good example of this is a workflow that involves interactions with people, any of whom can cancel the workflow at any point. Addressing this situation with a sequential workflow is possible, but every step could be a branch: Do this if the workflow isn’t cancelled, do something else if it is cancelled. Modeling this kind of behavior using a state machine is significantly simpler, since a request to cancel the workflow is just another event that can be received and handled at any point.
Support for state machine workflows is one example of how WF attempts to provide support for human as well as system workflow. Another example of this is WF’s support for changing a running workflow. People can be capricious, and it’s not uncommon for someone involved in a workflow to wish to add a step, delete a step, or make some other change in the process while it’s underway. To accommodate this in a controlled way, WF allows the developer who creates a workflow to specify whether and how that workflow can be modified while it’s executing.
The Base Activity Library
Developers are free to create custom activities. In fact, Microsoft’s goal is to foster the growth of a WF ecosystem full of reusable activities. Still, starting with a common set of fundamental activities makes life simpler for everyone. Providing this common set is the role of the Base Activity Library (BAL).
A workflow isn’t required to use anything from the BAL. Still, many developers will find that the BAL makes their lives simpler, especially at first. Among the activities contained in the BAL are the following:
IfElse: executes the activities contained in two or more possible paths based on whether a condition is met.
While: repeatedly executes one or more activities as long as a condition is true.
Sequence: executes a group of activities one at a time in a defined order.
Parallel: executes two or more groups of activities in parallel.
Code: executes a defined chunk of code.
Listen: waits for a specific event, then executes one or more activities when that event is received.
InvokeWebService: calls a Web service using ASP.NET Web Services.
State: represents a state in a workflow’s state machine.
EventDriven: defines a transition containing one or more activities that should be executed when a specific event is received while in a particular state.
Policy: allows executing business rules using a WF-supplied rules engine.
Rather than define a particular language for specifying workflows, WF instead takes the more general approach of using activities. The BAL provides one “language”, but anybody using WF is free to define his own as well.
Tools for Windows Workflow Foundation: The Workflow Designer
One of the advantages of creating applications using workflows is the ability to define the workflow graphically. WF’s Workflow Designer allows this, as shown below. By default, the activities in the BAL appear in the Toolbox, letting a developer drag and drop them onto the tool’s design surface to create a workflow.
Some developers prefer to write code—they don’t like graphical designers. WF allows this approach, too (and sometimes requires it: activities are generally built directly in code). It’s also possible to combine the two approaches, creating a workflow using both the Workflow Designer and direct coding. The goal is to let developers use the approach that’s most productive for them. And to allow broad er tool support, workflows can also be expressed in XAML, the same language used by WPF. In fact, workflows created using the Workflow Designer default to a XAML definition.
The Runtime Engine and Runtime Services
As described earlier, the WF runtime engine has the job of executing the activities in a workflow. As part of doing this, it relies on a group of runtime services. WF includes standard implementations of these services, but ambitious developers can replace them if desired. These services support a few different things, but two stand out as most interesting:
Persistence: A workflow that’s blocked waiting for some event can use this service to have its in-memory state automatically persisted to disk. When the event occurs, the service will automatically reload the workflow’s state and restart execution. This is especially useful for workflows that involve people, since hours, days, or more might elapse while waiting for a response.
Tracking: The activities in a workflow cleanly demarcate the execution of the process they implement. WF’s tracking service allows a developer to cause information about the workflow’s execution to be automatically written to a database. For example, a developer might wish to track when a workflow starts and ends, when each of its activities starts and ends, and other information.
WF and WCF make an obvious combination. Workflows will commonly need to invoke services, and implementing a service with a workflow can often be a good idea. The initial release of WF in the .NET Framework 3.0 didn’t make combining these two technologies especially easy, but the situation has improved significantly in the .NET Framework 3.5. In this version, it’s straightforward to use WF and WCF together to create workflow-enabled services.
This combination depends on two new WF activities:
Send: Sends a request using WCF, then waits for a response. A developer specifies the operation that should be invoked and the endpoint at which that operation can be found.
Receive: Receives an incoming request via WCF, then sends a response. The developer specifies just the name of the operation that accepts this incoming request.
These two activities can be dragged and dropped into a WF workflow like any others, then configured as needed. The intent is to allow combining WF and WCF in useful ways.
Windows Workflow Foundation and Other Microsoft Technologies
Introducing new approaches inevitably influences what already exists. With WF, this influence has been felt most strongly by Windows SharePoint Services, the Microsoft Office 2007 system, and BizTalk Server.
To let developers more easily create workflow applications for document collaboration and other kinds of information sharing, Windows SharePoint Services, version 3 hosts the WF runtime. Office SharePoint Server 2007, part of the Office 2007 system, builds on the WF support in Windows SharePoint Services. Among other things, adding this server allows displaying InfoPath forms directly in Office 2007 client applications and using a set of pre-defined workflows for common scenarios such as approving a document.
Anyone familiar with BizTalk Server has certainly noticed by now the similarity between this product’s orchestration capabilities and what WF provides. In fact, the next major release following BizTalk Server 2006 R2 is scheduled to replace the product’s existing orchestration function with WF, providing tools to help migrate existing orchestrations to WF workflows.
Because it’s the standard workflow technology for Windows, WF will also show up in other Microsoft products and technologies. WF has also found a home in a number of applications created by independent software vendors (ISVs) and enterprises. While not every Windows application should be built as a workflow, WF can make a developer’s life much easier for those that are.