Matt W's Windows Workflow Place : Workflow

Types, Metatypes and Bears, Redux

mwinkle — Fri, 23 Oct 2009 16:16:29 GMT

I made a quick post a few months back where I tried to talk about the way the designer works and lets us design types, as well as simply configure instances of types.

There were a couple of key points that I wanted to make there in that post:

The workflow designer can configure instances of activity graphs, and create entire types as well
Types are designed by editing an instance of a type that represents the type being designed, the metatype
There is some XAML trickery required to serialize and deserialize this
This same type of work is done to enable the DynamicActivity capability

A few folks have noticed (and sent me mail), that things look a little different in Beta2. While we are going to have a more thorough, “here’s everything that changed” doc, I want to go ahead and update at least some of the things that I’ve been talking about here.

What’s New

In reality, very little is new, we’ve primarily moved stuff around now. One thing that you may remember is that the DesignTimeXamlReader was not public in beta1, and if you are looking around, you may not find it. We have made this functionality public however. Thus, see the “what’s changed" bit.

What’s Changed

We took a long look at things and realized we had a bunch of XAML stuff all over the place. We felt it would be a good idea to try to consolidate that into one place in WF, so System.Activities.XamlIntegration.ActivityXamlServices becomes your one stop shop for most things Activity and XAML related. Let’s take a quick look and see what’s in there:

ActivityXamlServices Members

[This documentation is for preview only, and is subject to change in later releases. Blank topics are included as placeholders.]

Creates an instance of an activity tree described in XAML.

The ActivityXamlServices type exposes the following members.

Methods

Name

Description

CreateBuilderReader

Overloaded. Maps an x:Class activity tree to an ActivityBuilder or ActivityBuilder<(Of <(TResult>)>).

CreateBuilderWriter

Maps an ActivityBuilder or ActivityBuilder<(Of <(TResult>)>) from the specified writer to an x:Class activity tree.

CreateReader

Overloaded. Maps an x:Class activity tree to an DynamicActivity or DynamicActivity<(Of <(TResult>)>).

Load

Overloaded. Creates an instance of a declarative workflow.

Top

Load is used to generally take some XAML and return an Activity which you can then use to execute. If Load encounters a XAML stream for <Activity x:Class, it will subsequently generate a DynamicActivity. This functions basically the same way WorkflowXamlServices.Load() did in beta1.

You also see CreateBuilderReader, and CreateBuilderWriter, which are used to surface the DesignTimeXaml capabilities that we used in beta1. These will return an instance of a XamlReader/Writer that handles the transformation between the metatype and the <Activity x:Class XAML. The metatype has changed names from ActivitySchemaType to ActivityBuilder.

The table below should help summarize the uses and changes between beta1 and beta2. In this area, I don’t expect any changes between what you see now, and what you will see in RTM.

Task	Beta1	Beta2
metatype (type to build types)	ActivitySchemaType	ActivityBuilder
Mechanism to load DynamicActivity	WorkflowXamlServices.Load()	ActivityXamlServices.Load()
Mechanism to load ActivityBuilder	use WorkflowDesigner.Load() to get an ActivitySchemaType	Use the reader from CreateBuilderReader() to pass into XamlServices.Load()
Mechanism to save ActivityBuilder to XAML	Create a new DesignTimeXamlWriter, pass that to XamlServices.Save()	Use the writer returned from CreateBuilderWriter() to pass into XamlServices.Save()

To explore this, use CreateBuilderReader() and XamlServices.Load() on a workflow that you’ve built in the designer and poke around a bit to see what’s going on.

Here is some sample code that walks through this:

   1:  ActivityBuilder ab1 = new ActivityBuilder();

   2:  ab1.Name = "helloWorld.Foo";

   3:  ab1.Properties.Add(new DynamicActivityProperty { Name = "input1", Type = typeof(InArgument<string>) });

   4:  ab1.Properties.Add(new DynamicActivityProperty { Name = "input2", Type = typeof(InArgument<string>) });

   5:  ab1.Properties.Add(new DynamicActivityProperty { Name = "output", Type = typeof(OutArgument<string>) });

   6:  ab1.Implementation = new Sequence

   7:  {

   8:      Activities =

   9:      {

  10:          new WriteLine { Text = "Getting Started " },

  11:          new Delay { Duration = TimeSpan.FromSeconds(4) },

  12:          new WriteLine { Text = new VisualBasicValue<string> { ExpressionText= "input1 + input2" }},

  13:          new Assign<string> { To = new VisualBasicReference<string> { ExpressionText = "output" },

  14:                       Value = new VisualBasicValue<string> {ExpressionText= "input1 + input2 + \"that's it folks\"" } }

  15:      }

16:

  17:  };

  18:  StringBuilder sb = new StringBuilder();

  19:  StringWriter tw = new StringWriter(sb);

  20:  XamlWriter xw = ActivityXamlServices.CreateBuilderWriter(

  21:      new XamlXmlWriter(tw, new XamlSchemaContext()));

  22:  XamlServices.Save(xw , ab1);

  23:  string serializedAB = sb.ToString();

24:

  25:  DynamicActivity da2 = ActivityXamlServices.Load(new StringReader(serializedAB)) as DynamicActivity;

  26:  var result = WorkflowInvoker.Invoke(da2, new Dictionary<string,object> { {"input1","hello"}, {"input2", "world" }});

  27:  Console.WriteLine("result text is {0}", result["output"]);

28:

29:

  30:  ActivityBuilder ab = XamlServices.Load(

  31:      ActivityXamlServices.CreateBuilderReader(

  32:          new XamlXmlReader(new StringReader(serializedAB)))) as ActivityBuilder;

33:

  34:  Console.WriteLine("there are {0} arguments in the activity builder", ab.Properties.Count);

  35:  Console.WriteLine("Press enter to exit");

  36:  Console.ReadLine();

Good luck, and happy metatyping!

Navigating the WF4 Beta 2 Samples

mwinkle — Thu, 22 Oct 2009 19:25:04 GMT

Hot off the presses (and the download center) come the WF4 Beta 2 samples here. The team has invested a lot of time into these samples and they provide a good way to get up to speed on the way a particular feature or group of features work together.

Note, there are 2300 files to be unzipped, so hopefully there is a sample in here for everyone.

At a high level, we work down the directory structure from technology, sample type, and then some functional grouping of samples.

Within the “Sample Type” we have a few different categories we use.

Basic

These are “one feature” samples that are used to illustrate how to use a given sample. Often times they are hosted in the most basic wrapper necessary in order to get the feature to a point where it can be shown.
These are grouped within feature level areas, a few examples from the samples are:

\WF\Basic

\BuiltInActivities – how to configure and use the activities that are in the box
\CustomActivities

\CodeBodied\ – writing activities in code, including async, composite, and leveraging ActivityAction’s
\Composite – writing composite activities
\CustomActivityDesigners – writing activity designers

\Designer – programming against the infrastructure, a tree view designer, and a XamlWriter which will remove view state.
\Persistance
\Tracking

Scenario

These are higher level samples that require pulling together a number of features in order to highlight how the features can be combined to enable an application of the technology that might be of interest. In the WF bucket, you will see things like Compensation and Services, which pull together a number of individual features
The ActivityLibrary folder is chock full of interesting sample activities that are useful for seeing how to write activities, as well as code that might be useful in your application. Some of these are items which we aren’t shipping in the framework but may in the future. Many of these also include interesting designers as well. Some of the interesting sample activities in here:

Application

These samples are used to show how to pull everything together within the context of an application. For instance, the WorkflowSimulator is described this way:

This sample demonstrates how to write a workflow simulator that displays the running workflow graphically. The application executes a simple flowchart workflow (defined in Workflow.xaml) and re-hosts the workflow designer to display the currently executing workflow. As the workflow is executed, the currently executing activity is shown with a yellow outline and debug arrow. In addition tracking records generated by the workflow are also displayed in the application window. For more information about workflow tracking, see Workflow Tracking and Tracing. For more information about re-hosting the workflow designer, see Rehosting the Workflow Designer.

The workflow simulator works by keeping two dictionaries. One contains a mapping between the currently executing activity object and the XAML line number in which the activity is instantiated. The other contains a mapping between the activity instance ID and the activity object. When tracking records are emitted using a custom tracking profile, the application determines the instance ID of the currently executing activity and maps it back to the XAML file that instantiated it. The re-hosted workflow designer is then instructed to highlight the activity on the designer surface and use the same method as the workflow debugger, specifically drawing a yellow border around the activity and displaying a yellow arrow along the left side of the designer

Extensibility

This is a section inside the WCF samples that focuses on the various mechanisms and levels of extensibility

I will be blogging more on some of the interesting (to me) individual samples. What do you think? Are there samples you’d like to see? How are you using these, is there anything we can do to make these more useful?

Usability Testing the WF Designer vNext (or, Yelling at Customers)

mwinkle — Thu, 15 May 2008 20:22:21 GMT

One of the things that my team is working on is the next version of the workflow designer. In order to help us get real feedback, we engaged with our usability teams to design and execute a usability study.

For details on what the test looks like (when we did them 3 years ago for the first version of the WF designer, see this great channel9 video). The setup is still the same (one way glass mirror, cameras tracking the face, screen, posture of the subject), the only difference is the software, we're busy testing out some new concepts to make workflow development much more productive. At this stage of the lifecycle, we're really experimenting with some different designer metaphors, and a usability test is a great way to get real feedback.

One thing I've always tried to do since I came to Microsoft is being sucked into the Redmond bubble. The symptoms of placement inside said bubble are a gradual removal from the reality that everyday developers face. When I came to the company two years ago, I was chock full of great thoughts and ideas from the outside, and much less tolerant of the "well, that's just how it works" defense.

Slowly, though, as you start to get deep into thinking about a problem, and tightly focusing on that problem, those concerns start to fade away, as you look to optimize the experience you are providing. Sitting in on the usability labs yesterday was a great reminder to me of how easily one can slip into the bubble. Our test subject was working with a workflow in the designer and had a peculiar style of working with the property window in VS. Now, when I use VS, I use the property grid in one way. I have it docked, and I have the dock set to automatically hide. I have known some developers who prefer the Apple / photoshop style where the property pane floats. The customer's way of working with the property grid was that he had it floating, but he would close it after every interaction. This required him to do one of two things in order to display the grid again, either go to the View menu, or (and what his style of work was) right clicking on an element and selecting properties.

The prototype we were doing the usability testing with, however, does not have that feature wired up, in fact, it currently doesn't display the properties item in the context menu at all. Not because we have an evil, nefarious plan to remove the properties item inconsistently throughout our designer, but rather because no one gave it any thought when we put the prototype together as we had other UI elements we wanted to focus on.

This became a serious problem for our customer, as the way he expected to work was completely interrupted. At one point, we asked him to dock the property window so we could continue with the test. This is the most fascinating part of the study to me, and that was watching him work to dock the property grid in the left panel. I've become so used to the docking behavior in VS (see screenshot below), that it didn't even occur to me that this might present a problem for the user. Instead, we watched for 3 minutes or so as he attempted to figure out how to move the window, and then try to process the feedback that the UX elements give. About 60 seconds in or so, the property grid was about at a similar location to the screenshot, with just a centimeter or two's distance away from being in "the right place". Watching his face, we saw him look slightly confused and then move it elsewhere. Two more times he came back to that same spot, just far enough away to not get the feedback that might help him in the right direction. It was at this point, the spontaneous yelling started among the observers in the room. Something that has become so obvious to us, something we have internalized and accepted as "just the way the world," was becoming crystal clear to us how much difficulty this was causing. The yelling was things like "Move up, move up" "no, wait, over, over" "oh, you almost, almost, no...." trying to will the customer through the soundproof wall what we wanted him to do.

This situation repeated itself time and time again with different UI elements, and it was very, very educational to see the way different users manage their workspace and interact with a tool that I've become so familiar with that I forget to see the forest for the trees. I also realized, that although I had worked with a lot of customers and other developers, very rarely had I paid attention to how they work, rather than simply their work.

Now, here's where I open up the real can of worms. We're looking to make usability improvements in the WF designer. Are there any that really bother you? What can we do to make you a more productive WF developer?

Pageflow questions: "What about WCSF / Acropolis / Codename 'foo'"?

mwinkle — Thu, 14 Jun 2007 23:34:02 GMT

So, I got a little bit of feedback from my initial post. First, thanks, it's great to see all of the interest in the technology. I want to use this as the place to answer common questions that arise about the sample.

Here's one that I got internally as well as externally(here, here )

What about WCSF and Acropolis? Does this change how we think about the problem today?

The short answers are "they are still here", "no".

WCSF

There are a lot of people who are using the Web Client Software Factory. It is definitely something you should check out, it is a great toolkit to build composite web applications. Part of what it does, among many other things, is the Pageflow Application Block designed to model navigation. This is what most people are wondering about when they first hear about the pageflow sample we released. Don't they do the same thing? From a functional level, yes, they both provide a nice abstraction to model flow through an application. This is a sample usage of WF to solve a similar problem in a little bit of a different way. The model inside the WCSF is extensible, allowing a different provider of pageflow information, so it is probably even possible to put this pageflow sample inside of the WCSF, I have yet to give that a try.

At a deeper level, there are some differences that stem from the implementation of the Pageflow Application Block as a state machine, which I will get into in my next post.

Acropolis

Acropolis, announced at TechEd last week, is still early on in its lifecycle, as part of the ".NET Client Futures". I haven't spent a lot of time looking at it yet, but it is something else which will have a way to model the flow within an application, in this case between WPF forms.

Conclusion

From a support perspective, it's important to note that this sample is unsupported (save for myself and a few others) as opposed to Acropolis and WCSF which have teams working on them.

It is important to note that both WCSF and Acropolis aim to solve a much larger problem than simple UI navigation. In that sense, in no way does the pageflow sample released represent a wholesale replacement of either of them. The sample that we released aims to illustrate a way to use WF to solve the problem of UI navigation. The important thing to take away from this is that it can be incredibly valuable to model the flow through one's application using a technology which allows separation from the UI. This makes our UI more loosely coupled with the rest of our application, and increases the agility to react to changes in process / data required / need to track infomation.

Also, even if you don't want to use this for pageflow, tune in, because there are some pretty valuable things that any WF developer can learn by taking a look at this sample. I will continue to discuss those as well.

Pageflow Questions: Why not a state machine?

mwinkle — Thu, 14 Jun 2007 18:00:03 GMT

Here's a comment from my initial post introducing the pageflow sample from wleong:

NavigatorWorkflow looks like a state machine to me. Why create a new workflow type?
Tuesday, June 12, 2007 3:44 AM by wleong

This is a good question. There a couple of reasons why we create our own workflow type:

To more accurately model a process
Enable different execution semantics
Make development faster by focusing on the model, not the implementation details.

For a little more background on the problem, see my previous post on "Different Execution Patterns for WF (or, Going beyond Sequential and State Machine)" that talks in a little more depth about the trouble one can encounter by only think about the two out of the box models.

For this problem, in particular, all of the reasons are relevant.

Accurately modeling a process

It is very natural to think of UI navigation as a series of places we can be, and a set of transitions from any one of those places to another. That's what the navigator workflow models. There is a subtle difference from a state machine that plays to point 3 here. This model allows me to not worry about putting an IEventActivity at the top of a state, then making some decision and then setting a new state. We abstract away from defining the events, that's taken care of for us. This lets us model the process naturally. In a state machine, one could argue that modeling pageflow with transitions has me place one event and then have an IfElse activity that lets me decide which state to transition to. This adds mental overhead to the model, moving me much closer to the implementation details (again, point 3).

Enable Different Execution Semantics

This was the primary reason I wrote the original article, my customer was doing some very unnatural acts in order to model their process in a sequential workflow. In the case of UI navigation, we have the ability to be in multiple interactions at the same time. The WF state machine has the (very natural) restriction that we can only be in one state at a given time (although there are certainly other state machine models that do not have that restriction). The pageflow sample allows you to be in multiple interactions at the same time, so think about filling out a mortgage application, I can be in the midst of many minor sub processes that all roll up into the larger application process, and I can jump from filling out my salary history to the details of the property I am buying by simply clicking on a tab at the top of the page.

Make development faster by focusing on the model, not the implementation details.

If we decide to use a state machine, we are coupling our model to the implementation and execution details of the state machine, which will cause us to do things that we don't need to do for this application. The WF state machine is generic, any state can receive n different events and react to each on differently. In pageflow, we know there is only one event, "GoForward" and then we have a set of rules to operate on that to determine where we transition to. By spending the time to create our own root activity, we remove the burden of the implementation details from the workflow developer, allowing them to focus on the details of their process, not the configuration of a given activity.

Two Cool Technologies, One Great Solution

mwinkle — Wed, 04 Apr 2007 22:24:33 GMT

My peer, David, has a great screencast posted on Channel9 that shows off a solution from FullArmor that incorporates WF and PowerShell and one really cool looking designer.

On my list of cool things to check out when I have free time (currently June 2015) is PowerShell. It's a great tool for devs to make their apps much more managable, by both devs and our dear friends, the IT Pro. David has built some samples that build right on top of things to return collections of data in order to PowerShell enable them.

Check it out here

WF and BizTalk Server 2006 R2

mwinkle — Thu, 25 Jan 2007 01:48:32 GMT

One of the cool things coming in BizTalk R2 is a tracking service for WF that talks to BAM. Jesus Rodriguez has put together a walkthrough of using the BizTalk Server R2 BAM interceptor for WF.

Matt and Paul talk WF

mwinkle — Thu, 14 Dec 2006 19:26:50 GMT

A few weeks back Paul Andrew and I sat down with Ron Jacobs to record this Arcast about WF.

The funny thing is that a few weeks before that, Paul Andrew and I sat down with Ron Jacobs to record that same Arcast, except there was a problem with the microphone and Ron's voice didn't get recorded, so it was as if Paul and I were extemporaneously responding to the voices in our heads about WF.

There are more questions to go through, so we will be doing at least a part 2. Any feedback or other questions you want to see answered? Let me know!

Back From Barcelona

mwinkle — Tue, 14 Nov 2006 02:45:00 GMT

I arrived into SEA yesterday around 3, so I'm feeling a little bit of the 'lag from my week in Barcelona. A few things to point out:

Tim has a fantastic "Vista on the M400" post. The little dude's getting an upgrade while this gets typed, results in a future post
Kudos to who-ever put together this diagram. I think it could be made a bit better by having links to the section of MSDN which further explains how to dev, say, win32 or hybrid applications, but it's a nice way to represent and download the bits you're interested in.
The long awaited WF perf whitepaper is available, as Paul points out. As Paul mentions, the 10K empty workflows per second is not a number one should run out a room assuming can be obtained, but there are a few things that I really liked seeing:
- What happens when we scale out?
- Should I implement a while loop in my code to loop 1000 times, or should I use the While activity? This is one of my favorite examples when people ask "How should I think about moving to a WF driven design?" I like this paper as it explains things in terms of trade-offs.
- Finally, beneath figure 13, the discussion of the overhead involved with using the tracking service is discussed. This is important, and it shows the difference between batching and not batching the "transactions" of the tracking service. Transaction is mentioned in quotes as these have little to do with System.Transactions, rather when tracking data is written to the database. The number to notice here is not just workflows per second, but also the increased load on the SQL Server. Again, these are just some things to think about when you start discussing "perf" with workflow. The papers about 50 pages long, so there's a bunch of stuff to see there. Check it out!
Thanks to everyone who dropped in on my sessions in Barcelona. I'll be posting some followup information when I get a little time to recover (or at 3:30 tomorrow morning when I am wide awake and thinking it is lunch time in Barcelona :-) )
There's also this page, which is a nice gateway into downloading all sorts of the things we talked about at TechEd.

Did you hear the news, .NET 3.0 is live

mwinkle — Wed, 08 Nov 2006 11:21:00 GMT

Things got signed off last week, and early yesterday (depending on the timezone), the RTM build was published on MSDN. James put the details up on the community site, and there's been a ton of people headed to check it out (look at all the trackbacks on James' post). Thank you to all of the bloggers who have picked up the story and are passing it along.

So, now what? Well, there's still plenty of work for me to do, including looking forward to vNext (the great part of evangelism!) In the short term, I'll be presenting today on Reliabilty, Scalability and Maintainability of workflows hosted in IIS here in Barcelona. I won't be talking about the IIS scenario nearly as much as the other three parts, as well as discussing some performance information. After the talk, a number of us are headed to a soccer game, which I'm looking forward to. Tomorrow, Paul Andrew and I are conducting a drop-in clininc for WF, so, if you got questions, stop on by.

So, what's next for you? Get the bits, get some training, and start writing workflows!

[updated] realized I had a problem spelling "hear" in the title :-)

Off to Barcelona!

mwinkle — Fri, 03 Nov 2006 18:34:00 GMT

I'm in the office this morning, wrapping some things up and then it's wheels up to Barcelona for a week. Paul, Clemens, Shy and I will all be there hanging out somewhere between our talks and the Connected Systems booths, so stop on by and say hi!

SOA Conference Questions

mwinkle — Thu, 05 Oct 2006 18:30:25 GMT

I headed over to building 33 yesterday for the Microsoft SOA and Business Process Conference to host a Q&A session with some other people from the Connected Systems division (Clemens, Shy, Lee and Joe). We had a pretty decent audience, and I wanted to repost the questions that I got here and answer them.

Will Speech Server (or SharePoint, or other hosts) let me run activity x?

The other big host to talk about right now is Office, in SharePoint. The answer, in true consultant fashion is that it depends. It will really be left up to the implementation of the host as to what behavior they will allow. For instance, the SharePoint host will not allow the addition of additional services. This has been done for performance, stability and security reasons. SharePoint is also very particular about the activities it will allow to be executed, using the concept of a white-list in order to mark activities as able to be run. You can imagine that allowing a code activity could be a very bad thing in SharePoint, and thus, it is not allowed.

These are all hosts for WF, their behavior is chosen to optimize for the scenario to be used in. Similarly, you may have the same constraints, which you can enforce in your host, or maybe you have none of them, in which case, you don't need to implement any of them.

Is the WF Rules Engine a Rete Engine? (with follow on: If not, why not?)

No, the WF Rules Engine is not based on a Rete algorithm. Check out Don's blog posting here. There are a few relevent paragraphs I will repost here.

There are plenty of resources out there that describe what the Rete algorithm does and why it is so often used in Rules engines. At the end of the day, Rete is an optimization. You don't need a Rete engine to implement a forward-chaining rules engine; however, the Rete optimization may improve the runtime performance of a Rule Set. That's what optimizations do. In particular, Rete reduces the number of predicate evaluations by remembering the most recent value and re-using it on subsequent re-evaluations.

and

I certainly concede that there are many examples of Rule Sets that contain a lot of common predicates. In those cases, a Rete-based Rules engine like BRE will crush a non-Rete engine like WF Rules. However, in cases where there are few common predicates, the reverse has also been demonstrated: WF Rules and its non-Rete execution mechanism will crush Rete-based BRE.

My point is simply that Rete is an optimization strategy that is not necessarily appropriate for all Rules-based solutions. For WF Rules, we placed much more importance on how much you can express in your Rules, how easy it is to express it, and how well it integrates into Windows Workflow Foundation and the .NET framework.

If you're interested in more things about rules, Kavita emailed me the other day to let me know the team has started blogging here.

wf.netfx3.com new rss feeds

mwinkle — Mon, 10 Jul 2006 23:33:00 GMT

One thing that isn't so nice about the new http://wf.netfx3.com site is that all of the file listings do not roll up into one single nice syndication feed. I want the ability to aggregate all of the files into nice rss feeds so I can stay on top of samples, activities, etc. In order to enable this I had to create new blogs that aggregate the individual folder feeds, and then another one to aggregate those blogs.

So, here we go:

And, the rss feed that rules them all

All Content From wf.netfx3.com

Enjoy!

Look Mom, We Made CNET!!!

mwinkle — Wed, 14 Jun 2006 20:15:00 GMT

The workflow Technical Learning Center appears in CNET's "The View From TechEd 2006"

A Quick Update

mwinkle — Fri, 09 Jun 2006 19:41:00 GMT

I was out of town for most of this week, so I am busy catching up on things here.

First, I would like to thank Jon for this post, pointing out some areas of improvement which can be made in the designer re-hosting sample that I pointed to. Paul then let me know that Vihang's article on MSDN had been updated as well. Vihang's article is a great introduction to a lot of the issues that you will encounter in designer rehosting.

Other than that, I'm getting ready to head off to TechEd, where the WF team will be in full force. If you're looking to find out anything about worklow, stop by our sessions or chalk talks. If you're plate is already full with other things to do, stop on by the Connected Systems TLC in the developer section (I think it's "blue"). There will be plenty of product team members hanging around to talk about any workflow questions you might have. I'll be the guy wearing the blue Microsoft shirt, so I should be pretty easy to find!

Oh, and make sure to check out www.windowsworkflow.net on Monday morning, we've got a little bit of an update coming :-);

	Name	Description
	CreateBuilderReader	Overloaded. Maps an x:Class activity tree to an ActivityBuilder or ActivityBuilder<(Of <(TResult>)>).
	CreateBuilderWriter	Maps an ActivityBuilder or ActivityBuilder<(Of <(TResult>)>) from the specified writer to an x:Class activity tree.
	CreateReader	Overloaded. Maps an x:Class activity tree to an DynamicActivity or DynamicActivity<(Of <(TResult>)>).
	Load	Overloaded. Creates an instance of a declarative workflow.