替换WF4的WorkflowServiceHost？

Question

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

我们对工作流程主机的要求是：

1. 从存储在数据库中的XAML定义（DynamicActivity）
创建工作流程
2. 支持不同版本的工作流程
3. 支持基于时间的长时间事件（我们目前知道5天后发出通知并在30天后回滚工作流程）
4. 支持许多工作流程的许多实例（我们已经确定了10个工作流程，其中大约有4000个工作流程，其中只有少数工作流程在任何时间处理）
5. 服务重启后保留所有状态（包括基于时间的事件）
6. 验证主叫用户（如果可能，则为Windows身份验证）

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

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

所以，如果你这么坚持我：

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

我不反对编写我们自己的主机服务来处理工作流程生命周期，我们甚至已经拟定了提议的设计，但如果事实证明已经准备就绪，我不想开始这条路线制作解决方案。

干杯

Answer 1

您可以使用VirtualPathProvider从数据库而不是文件系统加载工作流，从而实现＃1 。有关详细信息，请参阅How To Build Workflow Services with a Database Repository。

工作流版本控制（＃2 ）是.NET 4.0不支持的，但在.NET 4.5中，您可以更好地支持实际版本控制。见What's New in Windows Workflow Foundation 4.5。但是，如果您不需要在启动后更改工作流，只需要新实例以新版本开始，而已经执行的实例可以使用以前的工作流定义完成，那么您可以在数据库级别实现版本控制并只需处理每个工作流定义版本具有不同的工作流服务。

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

最后对于＃6 并假设您坚持使用.NET 4.0，您可以查看WF Security Pack CTP 1。

Answer 2

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

我还首先介绍了工作流服务，但由于我们的工作流完全集成在业务层中，因此我不想使用WCF来访问工作流。
所以我现在使用WorkflowApplication作为主机，因此我可以实例化和操作主机 最大的问题是恢复使用延迟活动的工作流程（您需要在数据库中检查自己）