2013-03-06 12 views
1

我工作的公司正在考虑采用和实施在IIS中托管的Workflow Foundation来处理数据。我们仍在设计我们的问题域,但有人担心长时间运行的线程在IIS内部并不理想。以下是我们正在制定的一些假设,因为工作流仍然是我们小组的一项新技术:我应该创建使用Workflow Foundation建模的长时间运行的线程吗?

我们正在区分长时间运行的流程和长时间运行的流程,耗时的CPU,而长时间运行的工作流只是持续不确定的时间等待额外的请求来完成它的工作。

我的问题是:创建一个长时间运行的线程作为IIS中托管的Window Workflow的一部分,或者我们是否应该通过传统Windows服务实现IIS以外的长时间运行的进程?

+1

在IIS上长时间运行的线程[通常是个坏主意](http://stackoverflow.com/a/539000/87825)。这就是说,如果你想考虑使用WF,例如,因为你想要定期改变它的逻辑,直观地,没有完整的编译/部署,没有什么能阻止你在Windows服务上运行工作流,通过[ WorkflowInvoker](http://msdn.microsoft.com/en-us/library/system.activities.workflowinvoker.aspx)或[WorkflowApplication](http://msdn.microsoft.com/en-us/library/system。 activities.workflowapplication.aspx)。 – Joao 2013-03-07 22:36:54

+1

如果您仍然需要Workflow Services功能(WCF方式),@Sentinel再次表明了一个优点,但IIS对于长时间运行的线程并不理想。 – Joao 2013-03-07 22:39:18

回答

1

使用AppFabric的只是坚持你的循环(我假设它必须是一个循环,因为否则接收或延迟将卸载空闲的时候,所以不会发生长时间运行的进程),启用实例的控制和设置未处理的异常的动作放弃(将WF实例恢复到最后一个持久点)。

在应用程序池中,禁用回收,快速失败等是否是好的做法取决于很多事情,如部署问题,如果要使用wcf调用与进程交互,如果要轻松扩展等。就我个人而言,我不喜欢Windows服务的麻烦,我认为你总是必须处理意外的进程终止,所以为什么不认为它会发生,并以一个安全的持续点去IIS路线?

相关问题