在ASP.NET AJAX应用程序中使用Windows工作流

我正在使用Windows工作流作为ASP.NET应用程序类库的一部分。我已经阅读了所有关于在ASP.NET中设置WWF和使用ManualWorkflowSchedulerservice的建议，但是，我不确定这对我的应用程序是否有意义

我的工作流程都是连续的，没有持久性；他们是火和遗忘。客户端发出请求并稍后返回以查看结果（或在应用程序上等待）。到目前为止，我一直在使用AJAX web服务类来完成这项工作

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

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

如果客户还在附近，他会收到通知，如果没有，也可以。现在我使用WWF而不是直接从库中编码。我知道这是有效的（因为我已经做了），但我想知道是否有一些副作用，我不知道或其他问题。我的新代码如下所示：

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

我的类库：

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

---

这有点简化，但整个过程就在这里。现在这个很好用，有什么我应该关心的问题吗？如果是线程（这似乎是被引用最多的问题），那么这与Web服务在另一个线程上启动不一样吗？

很难给你一个好的答案，因为有很多未知因素，但无论如何我都会展示出来

ASP.NET和WF最常听到的问题是，两者都使用线程池，并且彼此都不知道。此问题主要取决于您的ASP.NET站点。默认情况下，WF仅使用线程池中的几个线程（每个进程4个线程来执行工作流，另一个线程用于运行时）。这个问题通常通过使用手动WF调度程序来解决，因为WF然后使用主机线程，即ASP.NET使用的线程。现在，这可以是好的，也可以是坏的，这取决于你的需要。首先，线程池的大小一直在增长，现在每个进程最多有250个线程，因此线程池不足不太可能成为问题，除非它是一个高负载的网站。使用手动调度程序的一个缺点是，所有请求（例如instance.Start（））都是同步的。如果您需要工作流中的某些内容来完成请求，但如果请求已启动且忘记，则ASP.NET请求正在等待工作流完成或达到某种空闲状态。因此，在某些情况下，使用ASP.NET应用程序中的默认计划程序会更好，这完全取决于您正在执行的操作和服务器负载

---

需要记住的一点是，IIS将在特定时间（我认为默认情况下为25小时）或请求数后回收AppDomain。当这种情况发生时，WF运行时将被销毁，并且，我猜想，下一个请求将在另一个AppDomain中重新创建。如果不使用持久性，则所有工作流状态都将丢失，现有工作流将终止。根据工作流所需的时间长短，这可能是个问题，也可能不是，从我的角度很难判断。

感谢您的回复；尤其是appdomain的回收——我没有想到这一点——尽管我的工作流程很短（目前），但将来可能会出现问题。