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

Question

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

简单地说这就是我们希望在我们的客户机/服务器设置来实现：

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

对于我所了解的'正常'工作流没有端点来接收消息。另一方面，工作流服务的确如此，但对于WF服务，工作流实例将根据传入的请求创建，而不是让服务器控制工作流的创建（对吧？）。

现在看来我们需要将工作流和工作流服务结合起来。

我一直在努力与此一段时间，现在搜索高和低，但找不到有用的信息。

我认为，我们有两个选择：

1. 工作流服务; 如果我们要使用工作流服务，我们可以在启动工作流的工作流的开始处有一个Receive活动。但是，客户如何才能与特定的工作流程进行沟通？工作流服务具有一个特定的URL。

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

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

PS：我们在客户端有一个WCF服务。工作流程可以与之进行沟通。对于短时间运行的请求来说，这不是问题，但问题是请求在客户“回答”它们之前可能需要很长时间。另外，如果用户点击继续按钮，用户只能请求信息（用户不应该因为服务器需要信息而在弹出窗口中弹出一个弹出窗口）

Answer 1

是的，带有AppFabric的工作流服务非常理想如果我正确理解你的问题，应该开箱即用。

对于您的问题“然而，客户如何与特定的工作流程进行沟通？”答案是相关性，你可以很容易地设置在第一个接收。您只需添加一个CorrelationHandle变量并为传入参数（ownerid？）和CorrelatesWith设置接收的CorrelatesOn与该句柄。对所有其他收件人执行相同的操作，并且传入的邮件将始终路由到正确的实例。

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

如果您需要进一步的具体细节，请让我知道。