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

Question

我使用 Windows Workflow 作为 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 服务不一样吗？

Answer 1

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

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

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