Objects and Their Relationships

A workflow ultimately becomes a group of managed objects in memory. The trick is to arrange the objects in a relationship so they can perform useful work. This trick isn't specific to workflow software. Consider some code from a Windows application:

button1 = new System.Windows.Forms.Button();
button1.Location = new System.Drawing.Point(13, 13);
button1.Name = "button1";
button1.Size = new System.Drawing.Size(75, 23);
button1.Text = "Click Me!";
this.Controls.Add(this.button1);

This code is similar to the code we saw in the InitializeComponent method the workflow designer created earlier. Instead of arranging activities, this code is arranging user interface controls. The code creates a Button object and sets some properties so the button will appear visually appealing. This code lives inside a class derived from System.Windows.Forms.Form. The most important line of code is adding the button object to the form's Controls collection: this.Controls.Add(this.button1). If we never established a relationship between the Form object and the Button object, the button would never appear on the form.

We generally don't write code like this ourselves, but we rely on a designer to generate the code. The designer-generated code has two goals. The first goal is to instantiate objects and set their properties to an initial value. The second goal is to establish relationships between the new objects and construct the relationships between the objects.

The ASP.NET designer-generated code for a web form has the same goals, but looks a bit different:

<asp:Panel runat="server" ID="panel1">
<asp:Button runat="server" ID="button1" Text="Click Me!" />
</asp:Panel>

The ASP.NET designer produces declarative mark-up instead of imperative code. Arguably, the primary reason for using declarative mark-up is the ability to intertwine .NET objects with HTML, and HTML is already a declarative language. However, using a declarative style increases readability of the generated code. At a glance, we can see the Button object is a child of the Panel object.

Both Windows Presentation Foundation and Windows Workflow use the eXtensible Application Markup Language (XAML), which takes the declarative style even further.

<Grid>
<Button Grid.Row="0" Grid.Column="0">
Click Me!
</Button>
</Grid>

XAML has the advantage of being valid XML. We are now looking at a declarative style that is human readable (it's easy to see the Button as a child of the Grid control), and tool-able. Tool-able meaning we don't have to rely on custom designers and compilers to read, write, modify, and parse the mark-up. We could write a custom tool for special tasks using the wide variety of XML technologies available, like XPath, XQuery, XSLT, and the XML DOM.

In the next section, we will look at using a purely declarative approach to building workflows using XAML.