InfoQ

InfoQ

InfoQ

En | 中文 | 日本語 | Br

592,113 Apr unique visitors

News

My Bookmarks

Login or Register to enable bookmarks for unlimited time.

The content has been bookmarked!

There was an error bookmarking this content! Please retry.

Building Applications On Windows Workflow Foundation

Posted by David Totzke on May 29, 2006

Sections
Enterprise Architecture,
Architecture & Design,
Development
Topics
Workflow / BPM ,
Business Process Management ,
Business ,
SOA ,
.NET ,
Enterprise Architecture ,
Programming ,
Modeling ,
Architecture ,
Windows Workflow Foundation

In his article in The Architecture Journal David Green of the Microsoft Windows Workflow Foundation team discusses the typical attributes of an effective workflow model platform and then goes on to explore how Windows Workflow Foundation fulfills these requirements.  The article is a long and thorough read, below is a quick summary of some of the key points:

Why haven't we seen more widespread use of workflow models?  There are three main factors that have limited their adoption. The cost of most workflow products has been quite high.  Integrating the workflow platform with existing systems and standardizing on a particular workflow model is also costly.

What is a workflow?  In simple terms a workflow describes an organization of work "units".  Points of interaction within the workflow are referred to as contracts. Contracts can connect multiple parties and parties to a contract can be human or an automated process. The workflow connects and drives the activities.

Workflows can also be dynamic. They can change as they execute.  One way to deal with this is to try and anticipate all of the possible branches and changes that may occur.  Another way to deal with this is to treat changes as external to the workflow. Actions in this type of model are generally focussed on the achievement of a specific goal.  Steps are added or removed as needed through external manipulation of the workflow.

  • Problem Resolution Collaboration. This is an example of a dynamic type of workflow where different steps may be taken depending on various factors.  Changes are not arbitrary but are constrained by the role of the user and the current state of the workflow.  Rather than performing assigned tasks, the user chooses from actions available at that point in the process.
  • Scripted Operations. Scripting allows a user to define and execute a series of common tasks. One issue with this type is that the output of one operation is needed as input for the next. Because data support is not needed by all workflows, it's better to layer data support on top of the workflow model rather than include it as a first class service of the model.
  • Guided User Application. Guided user systems lead the user to their goal by offering limited choices at each step.  Think of a typical call center system. Press one for sales, two for service etc... This type of system usually involves the business staff to a large extent and are far more fluid that other types of workflow.  They tend to change quite frequently.  There must be a clear way for IT and the business to communicate these changes clearly.
  • Test Record/Replay. This type of workflow intercepts user interactions within the application and records them.  A key difference of this type is that the workflow is written by a program, not a user, so full programmability is required.  This type also needs to be dynamically updateable.  For example, during playback an exception could be raised because a date is different from what it was when the workflow was recorded.  A tester should be able to easily mark this field to be ignored for something like a current date field. 

The Workflow model must be one that is built from elements that are meanginful in the workflow domain to the exclusion of all else.  It does not contain integer to string conversion functions for example.  Such a model may be exploited in many ways:

  • Visualization: represent the workflow graphically
  • Insight: workflows can be analysed and driven programmatically to simulate and predict workloads
  • Expressiveness: The workflow model contains a domain specific language.  In a document review process, three out of five may mean that the document is good and the others can be cancelled.  Coding this is difficult at best but a good workflow model can provide this out of the box
  • Execution: it is possible to add run-time support for common problems such as long-running state
  • Monitoring: the model allows the production of a semantically meaningful event stream without developer effort

David then ties in these requirements and begins explaining how they map into Windows Workflow foundation:

Thus far we have effectively recapitulated the thinking that drove the development of WF. WF as a realization of these concepts is the means by which this value can be translated into delivered solutions.

WF implements the idea of workflow as an organization of work items, abstracted away from the related ideas with which it has been coupled in traditional workflow products. The abstractions fall under three main categories: design and visualization, hosting, and semantics.

For a more detailed and in depth look at workflow, check out the full article.

  • This article is part of a featured topic series on SOA

No comments

Watch Thread Reply