Coming improvements to ASP.NET hosting of Windows Workflow Foundation after WF Beta 2.2
The DefaultWorkflowSchedulerService is the out-of-box Windows Workflow Foundation scheduler used by the runtime to execute workflow instances on new CPU threads. These threads are leveraged from the.NET thread pool associated with the host application. This works well unless the workflow runtime is hosted in ASP.NET. Because of the limited thread resource in the IIS server, we would be allocating an additional unnecessary thread to execute the workflow instance for every HTTP request that required workflow execution. The ManualWorkflowSchedulerService was developed to address this issue by allowing the thread that is processing the HTTP request to execute a workflow instance. Unfortunately in WF Beta 2.2 and prior, it didn’t handle the correct processing of timer events (i.e. delay activities).
After customer feeback, the WF team has modified the ManualWorkflowSchedulerService class to enable the creation of a background thread that handles timer events. These events are normally generated by delay activities. This behavior can be configured via a parameter called UseActiveTimers=”true” or by using a new ManualWorkflowSchedulerService constructor. This new behaviour makes WF a good candidate for both web page flow control scenarios and for implementing business logic in ASP.NET applications. This functionality was added after beta 2.2 was released.
Until the next public drop of Windows Workflow Foundation bits, our suggestion is to use the DefaultWorkflowSchedulerService for ASP.NET applications as a temporary solution for getting things up and running. It will work as expected, but it should not be expected to scale well in an ASP.NET application. By the time you need to deploy your solution, we should have released a new version of WF with the new ManualWorkflowSchedulerService functionality. At that point, you could swap the WorkflowScheduler in your config file.
This new functionality will still require you to explicitly call the RunWorkflow(…) method on the ManualWorkflowSchedulerService after calling the StartWorkflow(…) or EnqueItem(…) methods in the ASP.NET code. However, timer events will be processed as expected, automatically, without having to make any explicit calls.
Thanks to Israel Hilerio, who is the program manager responsible for hosting on the Windows Workflow Foundation team. He provided much of this information for me.
Samples for Windows Workflow Foundation and ASP.NET
Scroll down to Technology Samples where you'll find an ASP.NET hosting sample.
http://www.windowsworkflow.net/default.aspx?tabindex=4&tabid=49
Jon Flanders has a sample of User Interface Page Flow in ASP.NET
http://www.masteringbiztalk.com/blogs/jon/PermaLink,guid,0fae3e73-7801-4cf6-a5a5-9370b0f99973.aspx
Dino Esposito writes about using ASP.NET with workflow
http://msdn.microsoft.com/msdnmag/issues/06/04/CuttingEdge/
This forums post from Tom Lake provides some helpful hints
http://forums.microsoft.com/MSDN/ShowPost.aspx?PostID=358078&SiteID=1
----
Update July 5th, 2006: Since the RC2 is now available here in the June CTP of .NET Framework 3.0 (formerly WinFX), you should upgrade to that and use the ManualWorkflowScheduler for ASP.NET workflow applications.
