Developer's Toolkit

Building Workflows

If you have to build applications that require several discrete steps, then Windows Workflow Foundation is a tool that can help you do so.

• By Peter Varhol
• 11/15/2008

Applications rarely serve one function these days. Often they're used in conjunction with other applications to accomplish processes that require several steps. Those steps may be part of a single application or may combine applications or services.

The accepted way of tying together disparate applications today is through the use of Web services, connected using Simple Object Access Protocol (SOAP) over HTTP, .NET remoting or other mechanisms. But they remain separate applications or application components, using a loosely coupled approach to combining these independent components.

Using a strict Web-services model, you can also use the Business Process Execution Language (BPEL) to connect Web services and orchestrate them using the XML-based language. But often these approaches are overkill for simpler multistep processes, especially if only a single application is involved or if application components don't have to be orchestrated with BPEL or an enterprise service bus (ESB). Starting from scratch, these types of efforts can easily take a year or two and tend to be complex and expensive.

If your components are all .NET assemblies, you might consider using Windows Workflow Foundation (WF), a feature of .NET Framework 3.0 that will later let you build and execute workflow applications by leveraging .NET. It consists of a namespace, programming model, engine and tools for those workflows.

Programming Using WF
WF is based on the concept of the state machine, which means that it consists of a finite number of states, transitions between those states and actions occurring at each of those states. Installing WF in Visual Studio provides you with a toolbox of components, a properties window and a solution explorer, as well as the standard set of debug windows.

Starting off, the toolbox is the feature of most immediate interest. It provides graphical representations of activities that you can drag to the design canvas. In this way, you can build up a diagram with a set of states and actions that can be interpreted by .NET Framework and executed.

WF conveniently incorporates the visual design elements for building workflows and the ability to write code for the workflow within the same Visual Studio environment. Analysts can lay out the flow using the graphical modeling components, and developers can code the services and other application components that implement the workflow.

Workflow Projects
A workflow project is a console application, without a GUI. This makes some sense in that Web services and .NET assemblies implementing logic don't generally have a user interface that's associated with them. If a user interface is needed, it would generally be added to individual services or components in the workflow, rather than the workflow itself. You can, of course, write a driver application with a GUI to operate the workflow.

To automate a workflow using Visual Studio, you begin by selecting a workflow console application, which provides you with a canvas and a toolbox with the graphical workflow elements. Selecting from the toolbox, you can insert elements and connections between them onto the canvas. For example, you can select visual elements to start, conclude and create events entirely within Visual Studio. This puts you in the unique position of both laying out the workflow and coding for it.

Because each of the workflow states is represented in the workflow namespace, they can also be subclassed and coded. The classes themselves are rich, so often you have to make only minor customizations to your objects for unique business logic, and you don't have to worry about getting data between the steps in the workflow sequence.

The Pros and Cons
Unlike an ESB, WF doesn't allow you to add certain types of enterprise services to the workflow application. For example, there are no inherent WF facilities for security or for reliable transactions. Microsoft approaches these services from a different direction. They are collectively a part of .NET Framework. Specifically, they are packaged as programming interfaces to Windows Communication Foundation (WCF), and they can be added to the code at every step in the development process, rather than incorporated as a part of the orchestration.

If you have to build applications that require several discrete steps, then WF is a tool that can help you do so. For fast development and deployment, WF is easier to design and code than a more complex solution based on BPEL or an ESB.

Reader Comments: