The Advanced Workflow blog has an interesting post on choosing the correct scheduling service for the Windows Workflow Runtime when you are going to be running workflows from within ASP.NET applications. The recommendation is to use the ManualWorkflowSchedulerService instead of the DefaultWorkflowSchedulerService that is normally used in other scenarios, because it forces an explicit model instead of stealing threads from the ASP.NET Thread Pool. The benefit of this is that it solved some potential problems under stress and guarantees a more optimal use of the threads available. The downside is that it becomes the responsability of the developer and the ASP.NET application that hosts the runtime choosing when to allow workflows to be executed. In other words, the flow of the execution context from regular ASP.NET code to Workflow Code becomes explicit: you have to choose when to yield your execution thread over to the workflow runtime. This is significant because you are responsible for doing this every time, including when indirect behavior in the workflow is triggered, such as a long-running workflow getting reloaded for execution, or when a delay fires. Basically, I think this means that your developer responsability as a workflow scheduler is somewhat more complex than just calling workflows when necessary (there are quite a lot of discussions about this topic over on the WF forums ). Personally my opinion is: while hosting WF in ASP.NET can be seen as useful (and possibly simpler for some scenarios), this is only an acceptable for short-lived workflows such as page flows (modeling page interactions). ASP.NET most certainly is not, to me, an acceptable hosting environment for long-running workflows. Now, I'll be honest and tell you that I don't know what an alternative hosting model might be. Most likely, we won't have some kind of really robust hosting environment until (and if) BizTalk 200X (with X>6) ships with WF facilities built-in (and I don't know how much change we'll need to see in WF itself for this to be a reality). I would consider hosting my long-running workflows inside a Windows Service instead, and take advantage of the SCM facilities for automatic restarting of failed services, and possibly look into clustering the service in an active/passive fashion. This does bring a few problems with it, of course, and will take quite a bit more work, since it requires you to implement communicating the workflows in your custom host with the external applications that access it, but that can be helped by exposing workflows as WCF services (a pattern advocated in the post , as well). Update: Paul Andrew posts about upcoming changes to the ManualWorkflowSchedulerService post-Beta2.2 which should alleviate some of the issues with ASP.NET Hosting.
Read More...