工作流/工作流服务组合？如何在“正常”工作流程中使用接收活动？

Question

我们目前正尝试在我们的产品 (.NET 4.5) 中实现工作流功能。为此，我们考虑使用 Microsoft Workflow Foundation 4.5。然而，在这个早期阶段，我们遇到了一个看似非常可行的技术问题。

简单地说，这就是我们希望在客户端/服务器设置中实现的目标：

• 服务器根据特定事件启动工作流
• 工作流会执行一些操作，直到涉及需要人工交互的活动。然后它应该等待来自客户端的消息。
• 一个客户端（有多个客户端）成为所有者，因此应将其唯一 ID 或地址发送到工作流
• 工作流向该客户端发送一条消息，指示它需要信息才能继续（例如，收件人、主题和正文等电子邮件参数）
• 几分钟后（可能是几分钟到几小时），客户端将信息发送到工作流，以便它可以继续（例如发送电子邮件）
• 如果需要其他人机交互，服务器会再次向客户端发送请求消息，以便它知道应该向用户询问信息，然后客户端再次向工作流发送消息（如上）

据我所知，“正常”工作流程没有接收消息的端点。另一方面，工作流服务可以，但使用 WF 服务，工作流实例将根据传入的请求创建，而不是让服务器控制工作流的创建（对吗？）。

目前在我看来，我们需要工作流和工作流服务的组合。

我已经为此苦苦挣扎了一段时间，并且搜索了高低，但找不到有关它的有用信息。

我认为我们有两个选择：

1. 工作流服务； 如果我们要使用工作流服务，我们可以在启动工作流的工作流开始时有一个接收活动。但是，客户如何与该特定工作流程进行通信？工作流服务有一个特定的 URL。

2. 工作流程； 由服务器应用程序托管的正常工作流似乎是最自然的选择路径。但是，我们需要一种向它发送数据的方法。那么，是否可以升级正常的工作流程以便可以使用 Receive 活动？如果是这样，怎么办？消息如何在正确的工作流实例中结束？

我的问题是： 有人对如何解决上述问题有一些有用的指导或信息吗？ 是否有有趣的替代方案（不使用 WF？）来实现这一点？ 有人有关于如何将 WCF 消息路由到 WF 中正确工作流实例的文档吗？

PS：我们在客户端上提供了 WCF 服务。工作流可以与之通信。对于短期运行的请求，这不是问题，但问题是请求可能需要很长时间才能在客户端“回答”它们之前。此外，客户端只能在用户单击继续按钮时请求信息（用户不应该在某事中间得到一个弹出窗口，因为服务器需要信息）

Answer 1

是的，带有 AppFabric 的工作流服务是理想的，如果我正确理解您的问题，应该可以直接使用。

对于您的问题“但是，客户如何与该特定工作流程进行通信？”答案是相关性，您可以在第一次接收中轻松设置它。您只需添加一个 CorrelationHandle 变量并将传入参数（ownerid？）的接收的 CorrelatesOn 和 CorrelatesWith 设置为该句柄。对所有其他接收执行相同操作，传入的消息将始终路由到正确的实例。

AppFabric 将有助于您的 WF 服务从内存中卸载并在其空闲时间过长时持续存在，在新接收到来时唤醒等等。它还有助于您可以在 IIS 应用程序池上设置自动启动. WAS 将在收到请求时激活您的工作流服务。

如果您需要更多具体细节，请告诉我。