工作流/工作流服务组合?如何在'；正常'；工作流

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

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

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

据我所知，"正常"工作流没有接收消息的端点。另一方面，工作流服务是这样做的，但对于WF服务，工作流实例将根据传入的请求创建，而不是由服务器控制工作流的创建（对吗？）。

此时此刻，在我看来，我们需要工作流和工作流服务的结合。

我已经为此挣扎了一段时间，到处搜索，但找不到有用的信息

我认为我们有两个选择：

1. 工作流服务；如果我们要使用工作流服务，我们可以在启动工作流的工作流的开头有一个Receive活动。然而，那么客户端如何与特定的工作流进行通信呢？工作流服务有一个特定的URL。

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

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

附言：我们在客户端上提供了WCF服务。工作流可以与之通信。对于短时间运行的请求，这不是问题，但问题是请求可能需要很长时间才能被客户端"回答"。此外，只有当用户单击"继续"按钮时，客户端才能请求信息（用户不应该因为服务器需要信息而在中间弹出）