Windows Workflow Foundation内部部署托管和Web Api

Question

我想使用Windows Workflow Foundation 4.5并通过web api触发工作流程。现在我的托管选项是什么，MS正在结束AppFabric支持？我应该使用Windows Workflow Foundation还是应该查看第三方解决方案？

这是内部部署，我没有能力使用azure。我已经完成了一些工作流程，看起来WWF并不难用，但目前还不清楚如何托管它。我可以在没有AppFabric的web api项目中托管吗？

我主要担心的是，如果IIS应用程序池使用WorkflowApplication或服务器崩溃进行回收，则可以恢复工作流。我没有使用WCF我计划在web api中使用WorkflowApplication。

有人能指出我在实现AppFabric负责的自定义功能方面的正确方向吗？恢复，记录等。

来自MS：使用IIS和AppFabric是工作流程的首选主机。使用AppFabric的工作流的主机应用程序是Windows激活服务，它仅通过IIS消除了对HTTP的依赖性

IIS 7.0会出于各种原因定期回收应用程序池。当应用程序池被回收时，IIS将停止接受对旧池的消息，并实例化新的应用程序池以接受新请求。如果工作流在发送响应后继续工作，则IIS 7.0将不会知道正在完成的工作，并且可能会回收主机应用程序池。如果发生这种情况，工作流将中止，跟踪服务将记录带有空原因字段的1004 - WorkflowInstanceAborted消息。

如果使用持久性，则主机必须从上一个持久性点显式重新启动已中止的实例。

如果使用AppFabric，如果使用持久性，工作流管理服务最终将从上一个成功的持久性点恢复工作流。如果未使用持久性，并且工作流在请求/响应模式之外执行操作，则在工作流中止时数据将丢失。

Answer 1

一种托管策略是让您的Web API方法简单地将消息放入队列（如MSMQ或Rabbit MQ），并拥有用于实际托管工作流实例的后端Windows服务。后端服务将持续读取队列并启动您需要的正确工作流程。

这样，您就不会遇到可能终止工作流的IIS应用程序池回收事件。

如果您需要Web API方法等待工作流程完成，您可以让它等待“关联消息”到达队列以表示操作已完成。或者您可以将WF实例结果存储在数据库表中。

我实际上建议不要使用App Fabric，只需滚动自己的托管服务以获得更好的灵活性。另外，使用您想要的行为实现一个相对简单。

这是一个图表，我希望这将有助于您的设计或提出想法：