c# - 工作流/工作流服务组合？如何在 'normal' 工作流上使用 Receive 事件？

Question

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

简而言之，这就是我们想要在客户端/服务器设置中实现的目标:

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

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

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

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

我认为我们有两个选择:

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

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

我的问题是: 有人对如何解决上述问题有一些有用的指导或信息吗？ 是否有有趣的替代方法(不使用 WF？)来完成此任务？ 有人有关于 WCF 消息如何路由到 WF 中正确的工作流实例的文档吗？

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

Answer 1

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

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

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

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