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

Question

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

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

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

对于我所理解的，“正常”工作流没有接收消息的端点。另一方面，工作流服务是这样的，但是使用WF服务，工作流实例将基于传入的请求创建，而不是让服务器控制工作流的创建(对吗？)

此时此刻，我觉得我们需要一个工作流和一个工作流服务的组合。

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

我想我们有两个选择：

1. 工作流服务；如果要使用工作流服务，则可以在启动工作流的工作流开始时进行接收活动。但是，客户端如何与特定的工作流进行通信呢？工作流服务有一个特定的URL。
2. 工作流；服务器应用程序承载的正常工作流似乎是最适合选择的路径。然而，我们需要一种将数据发送到它的方法。那么，是否有可能升级一个正常的工作流，以便可以使用接收活动？如果是，怎么做？消息是如何在正确的工作流实例中结束的？

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

PS:我们在客户端有一个WCF服务。工作流可以与之进行通信。简而言之，运行请求并不是一个问题，但问题是，在客户端“回答”请求之前，请求可能需要很长时间。此外，只有当用户单击“继续”按钮时，客户端才能请求该信息(由于服务器需要信息，用户不应在某件事情的中间获得弹出)。

Answer 1

是的，使用AppFabric的工作流服务是理想的，如果我正确理解您的问题，就应该立即开始工作。

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

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

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