Tech Brief
Windows Workflow Foundation
Should you code your business logic or use a workflow model?
Windows Workflow Foundation (WF) provides the programming model, engine and tools for quickly building workflow-enabled applications on Windows. It comprises a new .NET Framework namespace called System.Workflow, an in-process workflow engine and workflow designers for Visual Studio 2005 and Visual Studio 2008 ("Orcas").
WF provides full support for Visual Basic.NET and C#, debugging and a graphical workflow designer. You can develop your workflow completely in code or as declarative XML (XAML). It provides an extensible model and designer to build custom activities that encapsulate workflow functionality for end users or for reuse across multiple projects. It runs on both Windows clients (XP and Vista) and Windows Servers (2003 and 2008).
WF includes the base support required for both system and human workflow across a wide range of scenarios involving long-running, frequently changing or tracked business logic. It can also be applied to software patterns from Service-Oriented Architecture (SOA) to simple-state machines and to utility functions such as user interface page flow.
When to Use Workflow
Workflow development is a natural progression from writing code. But many developers are uncertain about when to use a workflow runtime instead of just writing code for business logic. It's a good question because it's possible to develop all of your business logic in code. However, using a workflow runtime offers some major benefits in certain scenarios.
The first scenario is when you have long-running business logic. Code is naturally short running, and if you want to do anything that takes any time at all you have to think about storing state and how to pick it up again later. When you translate a long running process into code you have to write several distinct methods in code that act as atomic blocks of the process. Properly designed procedural code can't just wait for a response and extra code must be written to deal with the state and any message correlation once the event being waited on is received.
Using a workflow solves the long-running logic problem by modeling the process at a slightly higher level than directly in code. You still have to write code but the state management, persistence and correlation of incoming messages is provided by the workflow runtime.
The second scenario is if the business logic or business rules governing the process change frequently. This is evident if you have logic or rules changes more frequently than you're able to deploy new compiled code. Each customer of a line-of-business software vendor has its own unique requirements for the business-logic implementation and often a long period of customization before the software can be used by the customer.
Using a workflow provides a model in which a set of activities can be built in code, and the order of execution of those activities and the properties on those activities can be customized for an individual customer easily in the WF designer.
The software is still built primarily in code, but customization of the model for a new customer-or for a customer that requests changes frequently-becomes much easier. Since the workflow model can be stored in XML, using a workflow allows for a scenario in which business logic implemented as a workflow model, or as a set of rules, can be changed while the application is executing.
WF Services
The third scenario is if visibility into business-logic execution or the business-logic model is required. Once you decide to build your business logic as a workflow model, you can take advantage of WF services. These services include ACID transactions, compensating actions, exception management and process tracking. The tracking service provides visibility into executing workflow instances and, like other services, it's something that can be applied to the workflow runtime without adding extra code.
You also gain visibility into the workflow model simply because you can view a workflow model in the workflow designer, and you can print it out or take a copy of the image for inclusion in a functional specification. This can be valuable in explaining the software to non-developers, or it could be useful documentation for when a software design needs to be learned by others and modified later.
Built on WF
WF will be used across many future Microsoft products including the 2007 Office system, the Dynamics product line and the next major version of BizTalk Server.
Finally, workflow provides a way of describing the order of execution and dependent relationships between pieces of short- or long-running work. A workflow model can be executed inside any Windows process that hosts the .NET Framework, including console apps, forms-based apps, Windows Services, ASP.NET Web sites and Web Services.