At the PDC last week, Microsoft announced Windows Workflow Foundation as a key component of WinFX in conjunction with Windows Communication Foundation and Windows Presentation Foundation. This chapter describes the motivation behind Windows Workflow Foundation and provides an overview of its features.

This chapter is from the book

This chapter is from the book

Chapter
1: Workflow,
Tomorrow's
Application
Logic

In
this
chapter

The
Wonder of Flowcharts

Today's
Workflow Scenarios

Introducing
Windows Workflow Foundation

Windows
Workflow Foundation Engine Architecture

At
the
professional
developer
conference
in September
2005,
Microsoft
announced
Windows
Workflow
Foundation
as a
key
component
of WinFX
in conjunction
with
Windows
Communication
Foundation
and
Windows
Presentation
Foundation.
This
chapter
describes
the
motivation
behind
Windows
Workflow
Foundation
and
provides
an overview
of its
features.

NOTE

Windows
Workflow Foundation is a beta
technology and this book was written
before the beta was released.
It is very possible that changes
to the technology will be made
through the beta cycles, which
will reflect on the accuracy of
information presented in this
book.

The
Wonder
of Flowcharts

Inside classrooms around the planet students often receive their first
exposure to computer program design through the concept of a flowchart. The
flowchart provides a graphical model that is used to formalize the
design of program structure—with squares, diamonds, and triangles
representing the various steps in the flow such as activities and decisions.
Although the flowchart model is an excellent learning tool, the flowchart is not
directly represented in running software. The expense of maintaining a flowchart
model in software from a CPU-cycles perspective means that the flowchart is
nothing more than documentation. After the concepts of flowchart program design
are mastered by students, the flowchart model is forgotten and programs are
written directly in code.

Although writing programs directly in code has been the main development
paradigm for more than 25 years, and many millions of programs have been
created, a pure coding approach is not without issues.

Code written by one developer is often inherently hard to understand by
another. Although well-documented or commented code helps, it is often
unstructured in approach. Indeed the intellectual property that is the flow of
the program often stays in the mind of the original developer and is at risk
when that developer moves to a new job or a new role. The flowchart model, if
instantiated in code, would certainly provide an additional level of visibility
in program design.

Once compiled and executed, code is inherently opaque. The resulting
assembly language or intermediary language running on a CPU natively or through
a virtual machine executes a predefined set of op-codes to perform a set of
activities but does not provide visibility into how these activities are
executed. This has some advantages as it protects the intellectual property of
the code itself, but it also creates challenges. As programs become larger,
visibility into these programs at runtime becomes more important to troubleshoot
errors in context of program execution. The flowchart model, if available at
runtime, could provide visibility into the program execution.

Code is often grouped into procedures or objects. Encapsulation of code,
and indeed data, in these formalisms makes program design more componentized and
easier to maintain. On the other hand, it poses some interesting challenges. How
does data in one procedure or object move to the next procedure or object? There
are fundamentally two approaches. The first is to send a message from one object
to another such as a method call from one object to another passing state, or an
XML message serializing state. Although this design is functional in many cases,
it isn’t elegant as a state needs to be passed through a chain of many
objects all through parameters or XML messages. The second approach centralized
the shared state in an object. The state can be retrieved, updated, and
persisted to the object when required. Examples of this method include web pages
on a site that communicate through shared state held in databases that may be
session based or otherwise. However, in each case these state management
features were custom-crafted because of the lack of a consistent development
framework to manage state. Some of the challenges such a framework would face
include scalability challenges in managing state over long time periods. A
simple flowchart model has the notion of shared state. A variable is often set
in the first step of a flowchart and then referred to later in the thread of
execution. If this model for accessing state were more accessible to the
programmer in a scalable manner then state management could be more
efficient.

Although not part of mainstream development, over the past five years
instantiating a flowchart as part of a program runtime has proved so useful in
certain scenarios that regardless of the CPU cost it has become the preferred
method of interaction. Some of these scenarios are described in the following
sections.