我们目前正在尝试在我们的产品（.NET 4.5）中实现工作流功能。为此，我们考虑使用 Microsoft Workflow Foundation 4.5。然而，在这个早期阶段，我们遇到了一个看似非常可行的技术问题。
简单地说，这就是我们希望在客户端/服务器设置中实现的目标：
- 服务器根据特定事件启动工作流
- 工作流执行一些操作，直到涉及需要人工交互的活动。然后它应该等待来自客户端的消息。
- 一个客户端（有多个客户端）成为所有者，因此应将其唯一 ID 或地址发送到工作流
- 工作流向该客户端发送一条消息，表明它需要信息才能继续（例如，收件人、主题和正文等电子邮件参数）
- 几分钟后（可能是几分钟到几小时），客户端将信息发送到工作流，以便它可以继续（例如发送电子邮件）
- 如果需要另一个人工交互，服务器会再次向客户端发送请求消息，以便它知道应该向用户询问信息，然后客户端再次向工作流发送消息（如上）
据我所知，“正常”工作流程没有接收消息的端点。另一方面，工作流服务可以，但使用 WF 服务，工作流实例将根据传入的请求创建，而不是让服务器控制工作流的创建（对吗？）。
目前在我看来，我们需要工作流和工作流服务的组合。
我已经为此苦苦挣扎了一段时间，并且搜索了高低，但找不到有关它的有用信息。
我认为我们有两个选择：
工作流程服务；如果我们要使用工作流服务，我们可以在启动工作流的工作流开始时有一个接收活动。但是，客户如何与该特定工作流程进行通信？工作流服务有一个特定的 URL。
工作流程; 由服务器应用程序托管的正常工作流似乎是最自然的选择路径。但是，我们需要一种向它发送数据的方法。那么，是否可以升级正常的工作流程以便可以使用 Receive 活动？如果是这样，怎么办？消息如何最终出现在正确的工作流实例中？
我的问题是：是否有人对如何解决上述问题有一些有用的指导或信息？是否有有趣的替代方案（不使用 WF？）来实现这一点？是否有人有关于如何将 WCF 消息路由到 WF 中正确工作流实例的文档？
PS：我们在客户端提供了 WCF 服务。工作流可以与之通信。对于短期运行的请求，这不是问题，但问题是请求可能需要很长时间才能在客户端“回答”它们之前。此外，客户端只能在用户单击继续按钮时请求信息（用户不应该在某事中间得到一个弹出窗口，因为服务器需要信息）