工作流托管选项

大多数 Windows Workflow Foundation (WF) 示例都使用托管在控制台应用程序中的工作流，但这并非现实世界工作流的实际场景。 实际业务应用程序中的工作流将会托管在恒定进程中 - 或是由开发人员编写的 Windows 服务，或是诸如 IIS 7.0 或 AppFabric 之类的服务器应用程序。 这些方法之间的区别如下。

用配有 Windows AppFabric 的 IIS 承载工作流

用配有 AppFabric 的 IIS 是承载工作流的首选方法。 用 AppFabric 来承载工作流的应用程序是 Windows Activation Service，它解除了仅通过 IIS 对 HTTP 的依赖。

仅用 IIS 来承载工作流

不建议仅用 IIS 7.0，因为 AppFabric 有管理和监视工具，便于对运行中的应用程序进行维护。 仅当迁移到 AppFabric 存在基础结构问题时，才应将工作流单独托管在 IIS 7.0 中。

警告

由于各种原因，IIS 7.0 定期对应用程序池进行回收。 当应用程序池被回收时，IIS 即停止接受发给旧应用程序池的消息，并实例化一个新的应用程序池以接受新请求。 如果工作流在发出响应后继续运行，则 IIS 7.0 不会知道正在运行的任务，可能会将主机应用程序池回收掉。 如果发生此情况，该工作流将中止，跟踪服务会记录一个 1004 - WorkflowInstanceAborted 消息，消息的 Reason 字段为空。

如果使用了持久化机制，则主机必须显式地从上一个持久化点重启被中止的实例。

如果使用了 AppFabric，则工作流管理服务最终将从上次成功持久化的点恢复工作流（如果使用了持久化机制）。 如果未使用持久化机制，则该工作流执行非“请求/响应”模式的操作，当工作流中止时，数据也将丢失。

在自定义 Windows 服务中承载工作流

若要创建自定义工作流服务来承载工作流，要求开发人员复制 AppFabric 自带的许多功能，但允许通过自定义功能实现更大的灵活性。 仅当 AppFabric 经证不合适时，才应考虑这一选项。