Everybody who writes code wants to build great software. If that software is a server application, part of being great is scaling well, handling large loads without consuming too many resources. A great application should also be as easy as possible to understand, both for its creators and for the people who maintain it. Achieving both of these goals isn’t easy. Approaches that help applications scale tend to break them apart, dividing their logic into separate chunks that can be hard to understand. Yet writing unified logic that lives in a single executable can make scaling the application all but impossible. What’s needed is a way to keep the application’s logic unified, making it more understandable, while still letting the application scale.
Achieving this is a primary goal of Windows Workflow Foundation (WF). By supporting logic created using workflows, WF provides a foundation for creating unified and scalable applications. Along with this, WF can also simplify other development challenges, such as coordinating parallel work, tracking a program’s execution, and more.
WF was first released with the .NET Framework 3.0 in 2006, then updated in the .NET Framework 3.5. These first two versions were useful, especially for independent software vendors (ISVs), but they haven’t become mainstream technologies for enterprise developers. With the version of WF that’s part of the .NET Framework 4, its creators aim to change this. A major goal of this latest release is to make WF a standard part of the programming toolkit for all .NET developers. Like any technology, applying WF requires understanding what it is, why it’s useful, and when it makes sense to use it. The goal of this overview is to make these things clear. You won’t learn how to write WF applications, but you will get a look at what WF offers, why it is the way it is, and how it can improve a developer’s life. In other words, you’ll begin to understand the workflow way.
A workflow based program is like traditional programs that allow you to coordinate work and perform operations but has some important differences:
- Workflows use a declarative model (see Declarative programming) of writing programs by linking together pre-defined activities rather than an imperative programming model of writing each line of code
- Workflows can handle long-running work by persisting themselves to a durable store, such as a database, when idle and loading again once there is work to be performed
- Workflows can be modified dynamically while running when new conditions require a workflow to behave differently than when it was created
- Workflows provide a distinct separation of business rules and host application code making it easier to modify the business rules
- Workflows support sequential workflows for systems with sequential logic and state machine workflows for systems with event-based logic
- Workflows usually have a visual counterpart that allows a flowchart-like description of their logic
Windows Workflow Foundation (WF) provides the declarative framework for building application and service logic and gives developers a higher level language for handling asynchronous, parallel tasks and other complex processing. WF is a set of tools for declaring your workflow (your business logic), activities to help define the logic and control flow, and a runtime for executing the resulting application definition. In short, WF is about using a higher level language for writing applications, with the goal of making developers more productive, applications easier to manage, and change quicker to implement. The WF runtime not only executes your workflows for you, it also provides services and features important when writing application logic such persistence of state, bookmarking and resumption of business logic, all of which lead to thread and process agility enabling scale up and scale out of business processes.
A Windows Communication Foundation (WCF) approach to workflow communication was added in .NET Framework 3.5. This functionality comes in the form of two activities, SendActivity and ReceiveActivity, which send and receive WCF messages respectively. Workflows which include a ReceiveActivity expose a selected interface method as a WCF service. This could allow external code to, for example, make a Web Services call to a running workflow instance. The WF Runtime provides infrastructure to ensure that if a WCF call is made to a workflow instance that is in a persisted state (i.e. waiting for some external event like a WCF call or a timer event), then the instance will be reloaded into memory so that the message can be delivered to the workflow instance. Workflows which include a SendActivity are able to call external services via WCF.
A good video explaining the use of WF and its benefits is as follows:
A good video showing how to create a WF project is as follows:
For further reading refer to MSDN article.