C# WF4的WorkflowServiceHost的替代方案？

我们希望用WF4工作流取代我们业务逻辑的一部分。
它们都是非常典型的工作流：用户操作创建实例、数据库工作、下一个用户确认等

我们对工作流主机的要求如下：

从存储在数据库中的XAML定义创建工作流（DynamicActivity）

支持不同版本上的工作流

支持基于长时间的事件（我们目前知道5天后会有通知，30天后会回滚工作流）

支持多个工作流的多个实例（我们已经确定了10个工作流，其中大约4000个正在运行，其中只有少数几个在同一时间进行处理）

重新启动服务后保留所有状态（包括基于时间的事件）

对呼叫用户进行身份验证（如果可能，请使用Windows身份验证）

作为迁移工作的一部分，我使用“WCF工作流服务应用程序”项目构建了一些POC，但从我所看到的情况来看，这些并不能立即实现

我知道#2是通过WCF路由完成的，我的理解是WSH将为我们处理#3（这是真的吗，给定#5？），但我不知道#1如何从默认项目结构工作。
我已经使用WorkflowApplication实例解决了#1问题，但这依赖于使用书签来恢复每个输入事件，我不相信WorkflowApplication能够在不卸载空闲工作流的情况下扩展到我们的需要，这会破坏延迟活动

那么，如果你一直和我在一起的话：

• 有没有一种方法可以通过使用WSH来实现所有这些，或者在默认项目中，或者通过自己实现其中的一部分
• 我们是否最好编写自己的“DurableDelay”活动，记录真实唤醒时间并卸载工作流，以便主机进程恢复，因为卸载和重新加载工作流的持续时间很长，并且可能需要卸载和重新加载工作流
• 如果WSH不打算这样做，是否有现有的替代方案

我并不反对编写我们自己的主机服务来处理工作流生命周期，我们甚至已经拟定了建议的设计，但如果发现有现成的解决方案，我不想沿着这条路线开始

干杯

通过使用从数据库而不是文件系统加载工作流，您可以实现#1。有关此操作的更多信息，请参阅

工作流版本控制（#2）在.NET 4.0中不受支持，但在.NET 4.5中，您可以更好地支持真正的版本控制。看见但是，如果您不需要在工作流启动后更改工作流，只需要新实例以新版本启动，而已经执行的实例可以使用以前的工作流定义完成，则可以在数据库级别实施版本控制，只需处理每个工作流定义版本具有不同的工作流服务

然后，您可以将IIS（）中托管的工作流服务与SQL Server实例存储一起使用，几乎免费获得#3、#4和#5

---

最后，对于#6，假设您坚持使用.NET 4.0，您可以看看。

我正在开发相同类型的工作流

我还首先介绍了工作流服务，但由于我们的工作流完全集成在业务层中，我不想使用WCF访问工作流。
因此，我现在使用WorkflowApplication作为主机，以便可以实例化和操作主机。

---

最大的问题是恢复使用延迟活动的工作流（您需要在数据库中检查自己）

谢谢。对于#2（“每个工作流定义版本都有一个不同的工作流服务”），我将对此进行研究。理想情况下，我们希望每个工作流类型有一个服务，通过路由完成版本控制；不确定这是如何与AppFabric一起工作的，所以我将检查这两个选项。我还要看看AppFabric对我们来说是否是一个可行的选择，因为安装任何东西都是一场噩梦。我只是想跟进一下，我们最终构建了自己的运行时。实际上，它是一个Workflow应用程序池，在处于非活动状态5秒后卸载。有一个简单的调度器，用于监视现有工作流的预期唤醒时间，并在预期唤醒时间之前将其加载到WorkflowApplication实例中。花了几天时间，但它很轻，而且完全符合我们的需要。此外，我们在几秒钟内将其旋转到10个盒子上，并实现了自动负载平衡（您不能在多个主机中拥有单个工作流）。