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

Question

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

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

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

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

此时我觉得我们需要工作流程和工作流程服务的组合。

我一直在努力解决这个问题，现在搜索得很高，但找不到有用的信息。

我认为我们有两种选择：

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

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

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

PS：我们在客户端上提供了WCF服务。工作流程可以与之通信。对于没有问题的短期运行请求，但事实是请求可能需要很长时间才能让客户“回答”它们。此外，如果用户点击了一个继续按钮，客户端只能请求信息（用户不应该只是在某个中间弹出一个因为服务器需要信息的话）

Answer 1

是的，使用AppFabric的工作流程服务非常理想，如果我能正确理解您的问题，应该可以直接使用。

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

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

如果您需要进一步的具体细节，请告诉我。