What is Windows Workflow Foundation?
The Windows Workflow Foundation is that part of the .NET 3.0 framework that lets you build workflow enabled applications easily. I guess we could do that before too, but what workflow gives you on top of everything else, is a graphical representation of your workflow, ability to add custom activities, ability to host the runtime engine anywhere you want, ability to pause, persist and resume a workflow, transactions support, and a whole bunch of other things.
I will be covering many of these in subsequent blog posts.
So how does it work?
Any workflow is composed of elemental units called Activities. Each activity performs a specific portion of your workflow process, and the workflow itself is an order of execution and dependent relationships.
The workflow itself is created and maintained by an in-process runtime engine. There can be only one workflow runtime engine per app domain, though there can be multiple workflows in a single runtime engine.
When all activities finish running within a workflow, the workflow instance terminates.
Workflows can be authored in various styles.
They can be sequential – where operations are mostly system based, predictable and repetitive. This is the most straightforward way of programming workflows.
They can be state machine workflows, where a set of event driven states control the workflow.
Or they can be data driven or conditional, where based on certain conditions per the local data, the nature of the workflow changes.
Writing a workflow
A workflow can be authored using the workflow designer. The actual business logic is written in a language such as C# or VB.NET. There are various choices you have when authoring a workflow.
a) You could write a workflow purely in code. This is very much like what windows forms do today. You have a partial class called *.designer.cs, and visual studio understands that this needs to be rendered as a visual flowchart-ish look and feel.
b) You could write a workflow as a mix of markup and code. The workflow markup is basically a .xoml file, which actually works in a way very similar to a .xaml file. It is basically an XML file, which makes it’s magic happen through serialization and deserialization.
c) Finally you could write a workflow as pure markup. This means, only a .xoml file, which is compiled using the command line compiler, or loaded into the workflow runtime engine through a host application.
So in subsequent blogposts we’ll be divin’ deeper and covering different aspects of what this animal is.