第 104 页

code, which becomes a maintenance burden and has a high potential to contain incorrect mappings.

suMMary

In this chapter you learned how to create a WCF service, host it, consume it, and configure it for

different purposes/uses. However, WCF isn’t the end of the story for communication layers — in

fact, a number of technologies are built on top of WCF to enhance its capabilities. These include

WCF Data Services and WCF RIA Services, with the latter detailed in Chapter 35.

fiGure 31-11

32 32

Windows Workflow

foundation (Wf)

what’s in this chaPter?

.

Understanding Windows Workflow Foundation

.

Creating a basic workflow

.

Hosting and executing a workflow

.

Hosting the workflow designer in your application

Windows Workflow Foundation (WF) is a powerful platform for designing and running

workflows — a central tenet in many business applications. WF was introduced with the

.NET Framework 3.0, and has been completely redesigned and rewritten for its .NET

Framework 4.0 version to overcome some of the problems it had in its previous incarnations.

Unfortunately, this has rendered it incompatible with workflows created in those previous

versions, but leaving it a much more robust technology as a result. This chapter takes you

through using the WF designer, and the process of creating and running workflows using WF.

what is windows workflow foundation?

Before discussing Windows Workflow, you should first examine exactly what workflow is.

A workflow is essentially a model of the steps that form a business process. For example, this

may incorporate document approvals, job status tracking, and so on.

A well-designed workflow requires a clear separation between the steps in the business process

(the work to be done), and the business rules/logic that binds them (the fl ow).

702 .

chaPter 32 WindoWS WorkFloW FoundATion (WF)

Windows Workflow is a complete workflow solution, including both the design and the run time

components required to design/create and run workflows. These workflows can then be hosted in an

application, or exposed publicly as a service.

One of the powerful features of WF is that you can host both the WF run time

and the WF designer in your application, enabling end users to reconfigure

workflows themselves through the WF designer hosted in your application.

Using WF requires you to break your business process into discrete tasks (known as activities), which

can then be declaratively connected and controlled in a confi gurable workfl ow using the WF designer.

You can use WF in your own products, but you will also find it embedded in various Microsoft

products, including Sharepoint and Windows Server AppFabric.

why use windows workflow?

A common question raised by those who investigate WF is regarding why should they use it, rather

than embed business logic directly in the code. It ’s a very valid question, and whether or not you

should use it really comes down to the business problem that you are attempting to solve and the

business process you need to model. This chapter covers some of the scenarios in which it might be

appropriate to use WF, but you will fi rst look at some of the benefi ts you would gain with using it.

One of the primary scenarios where you would achieve the most benefits from using WF is where

you have a business process that frequently changes (or the rules within the business process

frequently change). Alternatively, you may have an application that is deployed to different

customers, each of whom has different business processes. The business logic/rules that form

workflows in WF are defined declaratively rather than being embedded in code, which has the

advantage of enabling the workflow to be reconfigured without requiring the application to be

recompiled. This, combined with the ability to host the WF designer in your own application,

enables you to design highly configurable applications.

Another scenario where using WF provides a lot of advantages is where you are modeling long-

running processes. Some workflows can run from seconds, to minutes, hours, days, and even years.

WF provides a framework for managing these long-running processes, enabling a workflow to

be persisted while waiting for an event (rather than remaining memory resident), and able to be

continued after a machine restart.

An advantage of being able to design and visualize your workflows in the WF designer is that the

workflow diagram can be used as a form of documentation of the business process/logic. This diagram

can be exported from the WF designer as an image, and used in documentation or presentations. This

helps provide a high degree of transparency for the business process you are modeling.

Ultimately, it’s not appropriate to use WF in all applications that incorporate a business process that

requires modeling. If any of the benefits listed previously are core requirements in your application,

you should seriously consider designing your workflows and activities using WF. However, if none

Workflow Concepts .

703

of the listed benefits are necessary (nor likely to be in the future), it’s really a decision you need

to make based on whether you think it will improve the development practices of your team, and

whether you believe that the imposition of such a framework will still provide more benefits through

its use to outweigh the potential problems that it may create (which are not unheard of).

workflow concePts

Before you get into the practical aspects of designing and executing workflows, you first run

through some of the important concepts around workflows, and the terminology that is involved.

activities

An activity is a discrete unit of work; that is, it performs a task. An activity doesn’t have to just

perform a single task — in fact an activity can contain other activities (known as a composite

activity), which can each contain activities themselves, and so on. A workflow is an activity

itself, and so are control flow activities (discussed shortly). You can think of an activity as the

fundamental building block of workflows.

Activities can have input and output arguments, which enable the flow of data in and out of the

activity, and can return a value. An activity can also have variables, which (like in code) store a

value that any activities the activity contains can also get/set. The activity in which a variable is

defined designates its scope.

You can think of activities as being much like a method in regular code.

WF includes a base library of predefined activities that cover a wide variety of tasks, which you can

use in your workflow. These include activities that:

.

Control execution flow (If, DoWhile, ForEach, Switch, and so on)

.

Provide messaging functionality (for communicating with services)

.

Persist the current workflow instance to a database

.

Provide transaction support

.

Enable collection management (add/remove items in a collection, clear a collection, and

determine whether an item exists in the collection)

.

Provide error handling (try, catch, throw, rethrow)

.

Provide some primitive functionality (delays, variable assigning, write to console, and so on)

Of course, despite this wide range of predefined activities available to you, you will no doubt want

to create custom activities to suit your own requirements, especially when you have complex logic to

implement. These are written in code, will appear in the Toolbox in the WF designer, and you can

drag and drop them into your workflow.

704 .

chaPter 32 WindoWS WorkFloW FoundATion (WF)

When creating your own custom activities, you have a number of custom activity types to choose

from: Activity, CodeActivity, NativeActivity, and DynamicActivity (the custom activity

inherits from one of these base classes).

Activities based on the Activity class are composed of other activities, and are designed visually

in the WF designer. As previously stated, workflows are activities themselves, so your workflow

is actually based on the Activity class. Activities composed in this manner can be used in other

activities too.

An activity that is based on CodeActivity, as its name suggests, is an activity whose action(s)/logic

is defined in code. This code is actually a class that inherits from CodeActivity and overrides the

Execute method in which the code to be executed should be placed.

Activities don’t necessarily have to be executed synchronously, blocking the continuing execution

of the workflow while performing a long-running task, or waiting for an operation to complete, a

response or input to be received, or an event to be raised. You can create asynchronous activities by

inheriting from the AsyncCodeActivity class. This is much like the CodeActivity class, except

rather than having a single Execute method to be overridden, it has a BeginExecute and an

EndExecute method instead. When an asynchronous activity is executed, it will do so on a separate

thread from the scheduler and return immediately. It can then continue to execute without blocking

the execution of the main workflow. The scheduler that invoked it will be notified when it has

completed executing.

Note that a workflow cannot be persisted or be unloaded while an asynchronous

activity is executing.

An activity that is based on the NativeActivity class is much like one that inherits from

CodeActivity, but whereas CodeActivity is limited to interacting with arguments and variables,

NativeActivity has full access to all the functionality exposed by the workflow run time (which

passes it a NativeActivityContext object that provides it with this access). This includes the

ability to schedule and cancel child activity execution, aborting activity execution, access to activity

bookmarks, and scheduling and tracking functions.

control flow activities

Control flow activities are used to control the flow of activities — essentially providing the binding

between them that organizes them into a workflow and forming the logic/rules of the process being

modeled. Control flow activities are just standard activities themselves, but designed to control the

execution/flow of the activities it contains (by scheduling the execution of those activities).

There are two primary types of control flow activities (essentially workflow types): Sequence and

Flowchart. A Sequence executes the activities that it contains (as its name suggests) in sequence. It’s

not possible to go backward and return to a previous step in a sequence; execution can only move

forward through the sequence. A Flowchart, however, enables the execution to return to a previous

step, making it more suited to decision making (that is, business) processes than sequences.

Workflow Concepts .

705

If you’ve worked with previous versions of WF, you will note that there is no longer a state machine

control flow activity. There is, however, expected to be an out-of-band release of a state machine control

flow activity at some stage in the near future.

You are not limited to using a single control flow activity in a workflow — because they are

activities, you can mix and match them as required in the same workflow.

expressions

Expressions are VB code (only) that return a value, and are used in the designer to control the values

of variables and arguments. You can think of them much like formulas in, say, Excel. Expressions

are generally bound to an activity’s input arguments, used to set the value of variables, or used to

define conditions on activities (such as the If activity).

workflow run time/scheduler

The workflow run time (also known as the scheduler) is the engine that takes a workflow

definition file and executes it in the context of a host application. The host application starts a given

workflow in the workflow run time using the WorkflowInvoker, the WorkflowApplication, or the

WorkflowServiceHost

classes.

The WorkflowInvoker class is used in a “hands off” approach to executing the workflow, leaving the

workflow run time to handle the entire execution of the workflow. The WorkflowApplication class is

used when requiring a “hands on” approach to executing the workflow (such as resuming a persisted

instance), enabling the execution to be controlled by the host. The WorkflowServiceHost class is

used when hosting the workflow as a service to be used by client applications.

bookmarks

A bookmark marks a place in the workflow, from which its execution can be resumed at a later

point in time. Bookmarks enable a workflow instance to be “paused” while it’s waiting for input

to be received, specifying a point from which it will be resumed when that input has been received.

A bookmark is given a name and specifies a callback function, pinpointing the activity that is

currently executing and specifying the method in the activity that should be called when the

workflow is resumed.

Creating a bookmark stops the workflow from executing, and releases the workflow thread

(although the workflow isn’t complete, but simply paused), enabling the workflow to be persisted

and unloaded. The host is then tasked with capturing the input that the workflow is waiting on, and

resuming that workflow’s instance execution again from the bookmark position (passing in any data

to the callback method received from the awaited input).

Bookmarks are particularly useful in long-running processes where the workflow is waiting for an

input to be received, that potentially may not be received for quite some time. In the meantime, it

releases the resources that it’s using (freeing them up for use by other workflows), and its state can

be persisted to disk (if required).

706 .

chaPter 32 WindoWS WorkFloW FoundATion (WF)

Persistence

Persistence enables the current state of a workflow instance and its metadata (including the values of

in-scope variables, arguments, bookmark data, and so on) to be serialized and saved to a data store

(known as an instance store) by a persistence provider, to be retrieved and resumed at a later point

in time. To persist a workflow instance, the workflow execution must be idle (such as if it’s waiting