According to Matt Winkle some performance enhancements have been made to the Workflow designer in Visual Studio 2008 SP1. Strangely enough no mention of these improvements is made in the release notes. I wonder if they made it in.

Matt Winkle: "In .NET 3.5 SP1, there are no features introduced, but there have been a number of internal improvements made, including some substantial perf gains in the WF designer (for certain scenarios)."

Windows Workflow scheduling services manage how workflow instances are scheduled by the workflow runtime engine. Whether they are handled in an asynchronous manner through the DefaultWorkflowSchedulerService, or in a manual, synchronous manner through the ManualWorkflowSchedulerService, these services are an important part of your workflow solution.

The application I'm working on right now uses ManualWorkflowScheduler, so I needed to figure out the exact differences between the two scheduler, luckily MSDN actually offers pretty clear documentation:

Default Workflow Scheduler Service

DefaultWorkflowSchedulerService is used by the workflow runtime engine by default. It creates and manages the threads that run workflow instances in an asynchronous manner on the workflow runtime engine. Workflows that are waiting to run are stored in the internal queue of the DefaultWorkflowSchedulerService . When the DefaultWorkflowSchedulerService wants to start a workflow, a thread is acquired from the .NET Framework thread pool and used to run the workflow. The MaxSimultaneousWorkflows property determines how many simultaneous threads the scheduler service will allow at one time. If the limit is four, for example, the DefaultWorkflowSchedulerService will acquire up to four threads from the .NET Framework thread pool to execute the workflows. If four workflows are already running, additional work items (workflows) are placed in the queue and eventually executed as threads become available. The following figure shows how the DefaultWorkflowSchedulerService executes workflows in an asynchronous manner.

You can set the maximum number of workflow instances that can be active at any one time by passing a parameter to the DefaultWorkflowSchedulerService constructor or by using an application configuration file. Task 1: Configure Runtime Services Using Code shows how to configure the DefaultWorkflowSchedulerService class by using the constructor. Task 2: Configure Runtime Services using App.Config shows the same configuration of the DefaultWorkflowSchedulerService but uses an application configuration file.

Manual Workflow Scheduler Service

The ManualWorkflowSchedulerService provides a threading service that enables the host application that creates a workflow instance to donate the Thread on which the workflow instance is run. Using this threading service, host applications can run a workflow instance on a single Thread (that is, in synchronous mode). This mode blocks the execution of the host application until the workflow instance becomes idle. Subsequently, the workflow instance can only be executed by using the RunWorkflow method of this service.

Alternatively, the workflow can be run on a thread created by a .NET timer by setting the useActiveTimers constructor parameter to true. When this timer expires, the workflow is executed on the timer's thread, rather than the host application's thread. This timer is implemented as a DelayActivity activity.

ManualWorkflowSchedulerService controls the number of threads spawned in an ASP.NET process by reusing the thread that made the ASP.NET Web request to run the workflow instance. This ensures that at any time, the number of active threads in the workflow runtime equals the number of active Web requests in the ASP.NET process.

ManualWorkflowSchedulerService does not automatically run a workflow instance that is in the queue. The host must call RunWorkflow to run a specified workflow.

The workflow designer in VS2008 can sometimes be a little sluggish. I ran across a post on the forum which offers the following advice:

Commonly reported issues

1. Time taken to open a workflow document is long.

2. Opening Activity bind dialog is slow.

Reasons for slow down

The Workflow designer relies on parsing the source code in the current project to provide updated design information in workflow design surface, rules dialog intellisense etc. This is mainly to enable scenarios where picking up changes from the source even before the project has been rebuilt.

Tips to make designer perform better

1. Move all types used in workflows to a different project than where the workflows live.

Move interfaces, event types, custom activities, helper classes to a different project than in which the workflow resides. E.g. in the solution from a customer, there were about 10 project, with 10 workflows each and 10 associated event types. These types are all reparsed to update to build the design time type information every time the user changes workflows in the project. Moving these to a different assembly e.g  just one project with all the types needed for the 10 workflow projects will help improve performance.

2. Reduce the number of workflows in a project.

Each workflow is a type ( directly in c#/vb, and indirectly in xoml case) that needs a design time type to be built by parsing, so if there are 10 workfows in a project, opening any workflow in the project for the first time means parsing all the other workflows as well. Classifying these workflows based on their function and grouping them in 2-3 workflows per project improved performance drastically.

3. Re-Factor large state machine workflows into smaller workflows

One example we found from a customer had 780 states and 1000 activity binds in the same workflow, leading to a InitializeComponent() of about 16000 lines. Factoring this state machine into smaller reusable workflows will making designer performance much better, and reduce a lot of redundant states.

4. Don’t do long running work in activity constructors

Activity constructors are called during design time also, so doing things like connecting to a database etc should never be done in constructors, this can make the designer take too long to open workflow documents using these activities.

Tomorrow night I'll be the guest speaker at the BAND (Bangor Area .NET Developers user group). I'll be talking about Workflow Foundation.

Workflow Foundation (WF) is one of the pilars of .NET 3. If you think WF is an end user tool then you’re wrong. It is a framework targeted at software developers that want to embed workflow into their custom applications. This session will explore the WF basics and focus on implementing State Machine Workflows, how to use the workflow runtime and where Windows Communication Foundation fits in the whole picture.

Sign up here.

Background: Assume we have workflow which is hosted as a WCF service. Every workflow instance is identified by the workflow instanceId. When a remote call comes into the workflow runtime the runtime needs to identify which workflow instance the caller wants to communicate with. If no identification is provided the runtime will assume a new workflow instance needs to be created.

Consider the following piece of client side code which calls a workflow service called FirstOperation() which is handled by a ReceiveActivity on the server:

ClientProxy proxy = new ClientProxy();
proxy.Open();
proxy.FirstOperation(); //creates a new workflow
proxy.Close();

Now assume a second call needs to be made and the second call needs to be handled by the same workflow because in this workflow there is second ReceiveActivity waiting for the SecondOperation to be called.
The following piece of code will do just that:

ClientProxy proxy = new ClientProxy();
proxy.Open();
proxy.FirstOperation(); //creates a new workflow
//.. more code, keep the WCF channel open
proxy.SecondOperation();
proxy.Close();

The above code will work because the ReceiveActivity in combination with the WorkflowServiceHost automatically adds information to the WCF context. The instanceId of the workflow has been added to the context. The above code is bad design. The connection to the server is a valuable resource and should be closed as soon as possible. The following code snippet show how the context manager is used to retrieve the context from the call which initiates the workflow and is then reused when a new client proxy is created.

ClientProxy proxy = new ClientProxy();
proxy.Open();
proxy.FirstOperation(); //creates a new workflow
IContextManager manager = proxy.InnerChannel.GetProperty();
IDictionary context = manager.GetContext();
proxy.Close();

//.. more code, the WCF channel is now closed

proxy = new ClientProxy();
IContextManager manager = proxy.InnerChannel.GetProperty();
manager.SetContext(context);
proxy.SecondOperation();
proxy.Close();

The IContextManager has been added in .NET 3.5 to help with correlation. The code needed in .NET 3.0 to achieve the similar functionality is much less elegant.

Note 1: Server side both the ReceiveActivity as well as the SendActivity have a Context property allowing for easy access to the context. A common pattern for implementing a callback is to set the context of the SendActivity to the value of the context of the ReceiveActivity. In the scenario illustrated above the context would consist of just the instanceId. In scenarios where the workflow is using send and receive activities within a parallel activity the context will automatically get extended to include a conversationId, allowing the WorkflowServiceHost to correlate an incoming call to the correct receive activity.

Note 2: If you want manually add the instanceId to a context, have a look at this post by Maurice de Beijer.

The Boston Code Camp 9 is over and done with. It was a great two day event and kudos to Chris, Chris and all the presenters that put their time and effort into making this an excellent happening!

Here are the two presentations from the session that I did:

Marcel de Vries has delivered a release version of his project on CodePlex in which he offers a set of Workflow activities you can use to implement service operations using Windows Communication Foundation (WCF).

Go to: http://blogs.infosupport.com/marcelv/archive/2007/05/08/WCF-activities-version-1.0-now-released-at-codeplex.aspx

My Amazon <-> WF integration article is now listed as a download on the official .NET 3.0 web site. Cool!

Go to: http://wf.netfx3.com/files/folders/web_services/default.aspx

Chris Bowen (Microsoft Developer Evangalist for New England) and Bob Familiar will be touring New England with a roadshow about development on the .NET 3.0.

Roadshow Schedule and Registration

My article on integrating Amazon Mechanical Turk into Windows Workflow Foundation has been placed on the Amazon web services developer connection.

Read it here: http://developer.amazonwebservices.com/connect/entry.jspa?entryID=635&ref=featured

I just created a new virtual machine image and installed .NET Framework 3.0 and the Windows Workflow Foundation extension for Visual Studio 2005. Pretty smooth install, the 2.9MB download for the .NET Framework turned out to be just a bootstrapper which in turn downloaded another 30MB. Don't you just love high speed Internet, it only took 25 seconds.

They're out!

MSDN subscribers can download Windows Vista via http://msdn.microsoft.com/.

If you're running Windows XP and want to try out the .NET Framework 3.0 RC1, then get the bits at http://msdn.microsoft.com/windowsvista/downloads/products/getthebeta/default.aspx

The .NET Framework download is available for everyone. Not just MSDN subscribers.

There will be a session about Windows Workflow Foundation (WWF) by Marcel de Vries on the upcoming Software Developer Event. Just to get a headstart have a look at this article by Dino Espito: http://msdn.microsoft.com/windowsvista/building/workflow/default.aspx?pull=/library/en-us/dnlong/html/wfgetstart.asp