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.
