Using Windows Workflow in ASP.NET AJAX application

Question

I'm using Windows Workflow as part of a class library in an ASP.NET application. I've read all the suggestions about setting up WWF in ASP.NET and using a ManualWorkflowSchedulerservice, however, I'm not sure if that makes sense for my app.

My workflows are all sequential, no persistance; they're fire and forget. A client makes a request and comes back later to see the results (or waits around on the app). Up to now I've been using AJAX web service class to fire off the job.

function DoWebserviceJob()
{
   MywebService.DoJob(onComplete, onFailed);
}

[WebMethod]
public DoJob()
{
   //code from library
}

If the customer was still around he'd get a notice, if not it was OK. Now I'm using WWF instead of coding straight from the library. I know this works(since I've done it) but I'm wondering if there are some side-effects that I'm not aware of or other concerns. My new code looks like this:

[WebMethod]
public DoJob()
{
     WorkflowRuntime runtime = Application["RUNTIME"] as WorkflowRuntime;
     MyWorkflowManager.DoJob(runtime);
}

My Class Library:

public void DoJob(WorkflowRuntime runtime)
{
   WorkflowInstance instance = runtime.CreateWorkflow(typeof(MyWorkflow));
   instance.Start();
}

This is a bit simplified, but the overall process is here. This works fine right now, are there are any issues I should be concerned with? If it's threads (which seems to be the most cited concern), Iis this not the same as webservice firing off on a different thread?

Answer 1

It is kind of hard to give you a good answer as there are lots of unknowns but I will give it show anyway.

The most often heard issue with ASP.NET and WF is that both use the ThreadPool and are not aware of each other. This problem depends mostly on your ASP.NET site are WF by default uses only a few threads in the ThreadPool (4 per proc to execute workflows and another for the runtime). The problem is usually solved by using the manual WF scheduler as WF then uses the host thread, ie the one used by ASP.NET. Now this can be good or bad depending on your needs. First of all the ThreadPool size has been growing and is now up to 250 threads per proc so ThreadPool starvation is unlikely to be an issue unless it is a high load website. A downside of using the manual scheduler is that all requests, ie the instance.Start(), become synchronous. If you need something from the workflow to finish the request but if it is fire and forget your ASP.NET request is now waiting for the workflow to finish or reach some idle state. So in some cases you will be better off with the default scheduler in you ASP.NET app, it all depends on what you are doing and the server load.

One thing to keep in mind is that IIS will recycle the AppDomain after a specific time, I believe 25 hours by default, or number of requests. When that happens the WF runtime is destroyed and, with the next request I presume, recreated in another AppDomain. If you are not using persistence all your workflow state will be lost and existing workflows will be terminated. Depending on the amount of time a workflow takes this could be a problem or may not be, hard to tell from my end.