Datasheet

To apply this idea to another area, the workflow management architecture should also be extensible.
Most workflow platforms provide functionality for persistence, tracking, and dynamic modifications.
These areas should be open for extension by developers so that an organization’s needs that were not
covered in the platform’s base functionality can be achieved.
Workflows Are Transparent and Dynamic Throughout Their Lifecycle
This tenet is easier to understand when compared to the traditional software development paradigm.
In conventional software, the code itself defines the behavior of the system. As you know, writing and
understanding code are very specialized skills that a very small percentage of the business population
possesses. Because of this fact, software systems are generally considered to be a black box. People in
the business cannot look at a block of code and ascertain what is happening behind the scenes. This can
even be difficult for a developer if the code was written by someone else. Workflows should provide the
advantage of being able to quickly and easily determine functionality at design time — that is, when
the workflow is not running.
Additionally, workflows should be transparent during runtime. This means that a workflow should be
able to be queried so that progress can be monitored while it is running. If you take this transparent run-
time concept a step further, a running workflow’s steps that have not yet occurred should be modifiable.
Compare this to traditional code, which, after it is compiled, cannot change itself. This notion of a work-
flow that can be changed during runtime is very powerful and can open a new set of possibilities related
to process automation.
Types of Workflows
At the risk of being too general, there are two types of workflow: ordered and event-driven. Both types
provide distinct functionality and would be used in different situations, depending on the requirements
of a given system.
Ordered Workflows
When people think of workflow, the first thing that comes to mind is probably an ordered workflow. An
ordered workflow represents a process that starts with a trigger and flows from one step to the next in a
predefined order. The process likely contains control or decision-making logic that includes
if-then
statements and while loops.
The steps in an ordered workflow and the order in which they occur are non-negotiable based on the
workflow’s definition. For example, in an order processing scenario, a customer’s credit check
always
occurs before the order is shipped. It wouldn’t make much sense to swap those two tasks.
Event-Driven Workflows
Event-driven workflows, sometimes called finite state machines (FSM), are based on the idea that you start
in one state and jump to another state based on a specific activity or event. For example, a light switch
starts in the
off state. When someone performs the turn on light action the light switch transitions to the
on state.
5
Chapter 1: An Introduction to Workflow and Windows Workflow Foundation
04_053867 ch01.qxp 2/20/07 2:40 PM Page 5