Workflow Development Styles

In Windows Workflow Foundation, there are three modes of workflow development and composition, and there are pros and cons associated with each. These development modes are discussed in the following sections.

Markup Only

This style of workflow enables you to declaratively define a workflow entirely in one file. The layout of the workflow file is a flavor of XML called XAML (eXtensible Application Markup Language). To use this type of workflow you have two options. The first is to compile the file with the Windows Workflow Foundation command-line compiler. You can also use the CreateWorkflow overloads of the WorkflowRuntime class that take an XmlReader instance. (Chapter 5 covers creating workflow instances.)

Defining Workflows in XAML

XAML is a means for declaratively developing software. XAML is not specific to Windows Workflow Foundation - you can also use it to develop user interfaces in Microsoft Windows Presentation Foundation. Previously, Windows user interfaces were developed programmatically by declaring controls and manipulating properties such as size and location to control the look and feel. With XAML, you can define a user interface hierarchically with XML elements that correspond to controls. The same goes for Windows Workflow Foundation workflows.

Each XML element corresponds to an activity class, with the root element corresponding to one of the workflow activity types. So the root element can be either SequentialWorkflowActivity or State MachineWorkflowActivity. Just as elements map to classes, attributes map to properties on these classes. The following code is a short example of a workflow written entirely in XAML. The workflow basically loops five times and prints a short message on each iteration:

  <SequentialWorkflowActivity   xmlns="http://schemas.microsoft.com/winfx/2006/xaml/workflow"   xmlns:x="http://schemas.microsoft.com/winfx/2006/xaml"   Name="XomlWorkflow"   x:>   <WhileActivity x:Name="myWhileLoop">     <WhileActivity.Condition>       <CodeCondition Condition="WhileCondition" />     </WhileActivity.Condition>     <CodeActivity x:Name="myCodeActivity"       ExecuteCode="myCodeActivity_ExecuteCode" />   </WhileActivity>   <x:Code>     <![CDATA[       int count = 0;       private void WhileCondition(object sender, ConditionalEventArgs e)       {         e.Result = count++ < 5;       }       private void myCodeActivity_ExecuteCode(object sender, EventArgs e)       {         Console.WriteLine("The count is " + count.ToString());       }     ]]>   </x:Code> </SequentialWorkflowActivity> 

Figure 4-1 shows what this workflow looks like in the workflow designer.

Figure 4-1

Because the workflow is implemented entirely in XAML, the supporting C# code is listed in a CDATA block inside an x:Code element (The CDATA block allows the representation of any kind of text.) To see how this XAML works, compile it with the command-line compiler, wfc.exe as follows (wfc.exe is discussed in more detail later in this chapter):

  wfc.exe XomlWorkflow.xoml /target:assembly /out:XomlWorkflow.dll 

This command compiles your .xoml file into XomlWorkflow.dll. By using a .NET developer’s best friend, Lutz’s Reflector (www.aisto.com/roeder/dotnet), you can take a look at what was done with your XAML markup. The following shows the workflow class metadata:

  [WorkflowMarkupSource(@"C:\Documents and Settings\Administrator\My Documents\Visual Studio 2005\Projects\Book\Chapter 4\XomlWorkflow\XomlWorkflow.xoml", "7EB9EE5D6FFF9178C357DFC35593D31C")] public class XomlWorkflow : SequentialWorkflowActivity {       // Methods       public XomlWorkflow();       private void InitializeComponent();       private void myCodeActivity_ExecuteCode(object sender, EventArgs e);       private void WhileCondition(object sender, ConditionalEventArgs e);       // Fields       private int count;       private CodeActivity myCodeActivity;       private WhileActivity myWhileLoop; } 

The following code is in the InitializeComponent method generated by the workflow compiler:

  private void InitializeComponent() {    base.CanModifyActivities = true;    CodeCondition condition1 = new CodeCondition();    this.myWhileLoop = new WhileActivity();    this.myCodeActivity = new CodeActivity();    this.myWhileLoop.Activities.Add(this.myCodeActivity);    condition1.Condition +=       new EventHandler<ConditionalEventArgs>(this.WhileCondition);    this.myWhileLoop.Condition = condition1;    this.myWhileLoop.Name = "myWhileLoop";    this.myCodeActivity.Name = "myCodeActivity";    this.myCodeActivity.ExecuteCode +=       new EventHandler(this.myCodeActivity_ExecuteCode);    base.Activities.Add(this.myWhileLoop);    base.Name = "XomlWorkflow";    base.CanModifyActivities = false; } 

Pretty cool, huh? The compiler took the XAML code, parsed it, and generated common language runtime (CLR) code that was then compiled into a .NET assembly.

Because markup-only workflows are contained in a single file, end users can define and run their own workflows. Granted, a user would probably use a front-end application that has been custom developed with a specific problem domain in mind. In this type of situation, you, as the developer, can use the WorkflowCompiler class to compile the XAML workflow programmatically, just as the wfc.exe utility does. (The WorkflowCompiler class is discussed later in this chapter.)

Drawbacks

Despite the niceties of this model, it has its drawbacks. Most obvious, the inclusion of .NET code for logic is not implemented in the most natural way for developers. Even though the code included in the x:Code element is eventually compiled into a .NET class, you are forced to write code inside an XML element with none of the features available in Visual Studio or outside the object-oriented paradigm. If you decide to go this route, you should first develop the code inside a real code file and class and then copy the code contents into the XML file. This way, you can use features such as IntelliSense, code highlighting, and developing in a true object-oriented manner.

Code and Markup

Also called code-beside, the code-and-markup development model is very similar to what ASP.NET developers are familiar with. The workflow definition exists in a markup file, as discussed in the previous section, but a standard .NET code file exists for the implementation of other business logic. This is a very elegant development mode because it allows for complete separation of the declarative workflow definition and logic implemented in code.

The code-beside model uses the concept of partial classes. Partial classes allow the definition of one class to be in multiple files or locations. By splitting key parts of a class into different files, multiple developers can work on the class at the same time. However, the functionality of partial classes in this development model is a little different (more on why in a moment).

To use this workflow development method, you must declare the .NET code file as a partial class. This is extremely simple - you just use the partial keyword on the class definition. For example:

  public partial class MyWorkflow : SequentialWorkflowActivity {    ... } 

Aside from the partial keyword, there is really nothing special about this file. In the following workflow markup, the x:Class attribute points to the class defined in the previous code. This tells the workflow compiler to create a class called MyWorkflow when parsing the markup and generating the CLR code:

  <SequentialWorkflowActivity    x:    Name="MyWorkflow"    xmlns="http://schemas.microsoft.com/winfx/2006/xaml/workflow"    xmlns:x="http://schemas.microsoft.com/winfx/2006/xaml">    ... </SequentialWorkflowActivity> 

The magic happens during the compilation process. The XAML workflow definition is parsed into a partial class of the same name as the .NET code file. At this point, the partial classes are merged and compiled as any standard .NET partial classes would be.

Code-Only

The code-only workflow development model will probably be one of the more commonly used methods because it is the default in the Visual Studio development environment. In this model, the workflow definition is defined entirely in a CLR language, such as C# or Visual Basic .NET. If you’ve done any development with Windows Forms in Visual Studio, this method will probably seem familiar (more on that in the Visual Studio section of this chapter).

The following is an example of a code-only workflow that prints a message using a Code activity. There are a couple things to notice here. First, MyCodeOnlyWorkflow inherits from SequentialWorkflowActivity, which means the class is a sequential workflow. Next, take a look at the class’s private field, myCode Activity, and the lone constructor. The constructor initializes the Code activity, wires an event handler for the ExecuteCode event, and then adds the activity to the workflow’s Activities collection. Finally, the ExecuteCode event handler is defined as myCodeActivity_ExecuteCode.

  public class MyCodeOnlyWorkflow : SequentialWorkflowActivity {     private CodeActivity myCodeActivity;     public MyCodeOnlyWorkflow()     {         this.CanModifyActivities = true;         this.myCodeActivity = new System.Workflow.Activities.CodeActivity();         this.myCodeActivity.Name = "myCodeActivity";         this.myCodeActivity.ExecuteCode +=             new System.EventHandler(this.myCodeActivity_ExecuteCode);         this.Activities.Add(this.myCodeActivity);         this.Name = "CodeOnlyWorkflow";         this.CanModifyActivities = false;     }     private void myCodeActivity_ExecuteCode(object sender, EventArgs e)     {         Console.WriteLine("Hello world!");     } } 

Although this might not look like the workflows you’re used to, it is just as much a workflow as anything in Windows Workflow Foundation. You can compile this code file into a .NET assembly and use it as you would a workflow developed with any other mode.

You will probably not use this development mode very often, if at all. Windows Workflow Foundation is all about declaratively and visually developing workflows, so piecing together a workflow definition with C# or Visual Basic .NET is not the best or easiest choice given the alternatives available. Visual Studio can write this initialization code for you while you focus on the visual definition of the workflow itself.