WindowsWorkflowFoundation (WF) is one of the parts of the .NET 3.0 framework as released by Microsoft. One of the most interesting aspects of WindowsWorkflowFoundation (WF) is the separation between business process code and the actual implementation, often a requirement in ServiceOrientedArchitecture (SOA). Before WindowsWorkflowFoundation the typical scenario would be to write both the business logic and the actual implementation in CSharp (C#), VisualBasic .NET or another .NET language. The result was no clear separation between business logic and its implementation. With the release of Windows Workflow Foundation (WF) the business logic can be defined in the workflow while the actual underlying implementation is done in C#, Visual Basic .NET or another .NET language. So basically the what is done in the workflow and the how is done in traditional programming code.
The best way to look at a workflow is as a schematic description of a real world problem. For example: If an order is placed, check if we have enough inventory and if not create a purchase order and send it to the supplier, notify the account manager by email of the expected delivery date the supplier specified. These activities are modeled in a graphical way making the workflow much more understandable. The activities themselves, like sending an email, are done in traditional C# or Visual Basic .NET code in such a way that they are unaware of their context, all they know is that they have to send an email as told by the workflow.
WindowsWorkflowFoundation is basically a library consisting of an execution engine, a rules engine, a number of activities, a number of supporting runtime services and a designer allowing developers to design their workflows graphical in VisualStudio2005 (VS2005). In fact it even includes a graphical debugger allowing the developer to step through the workflow and even into the underlying .NET code. The engine is designed in such a way that the developer has a free choice between building the workflow as code constructs or in a declarative fashion using XAML. Either way he can use the graphical designer the same way, all that changes is the output. Because the runtime engine has the capability of parsing and executing the XAML itself we have tremendous flexibility in our workflows. There is no need to compile them at the same time as the rest of the application. This flexibility even goes further and the engine allows for the runtime alteration of the executing workflow, how about that for flexibility!
Because WindowsWorkflowFoundation is a library, not a standalone platform or service, the developer is completely free to include the WindowsWorkflowFoundation library in process in his own application or web site/service. This can be of great benefit to existing applications where using a separate workflow server, like BizTalk 2006, would be prohibitive. Because of the modular way WindowsWorkflowFoundation is designed, the developer is free to replace standard services like persistence, scheduling or tracking with another implementation if he or she so desires.