工作流程/工作流程服務組合？如何在'正常'工作流上使用接收活動？

Question

我們正在嘗試在我們的產品（.NET 4.5）中實現工作流功能。爲此，我們考慮使用Microsoft Workflow Foundation 4.5。然而，在這個早期階段，我們碰到了一個看似非常可行的技術問題。

簡單地說這就是我們希望在我們的客戶機/服務器設置來實現：

• 基於特定事件的服務器將啓動工作流程
• 工作流執行一些動作，直到它涉及到一項活動這需要人類的互動。然後它應該等待來自客戶端的消息。
• 一個客戶端（有多個客戶端）成爲所有者，因此應將其唯一的ID或地址發送到工作流程
• 工作流向該客戶端發送一條消息，指出它需要信息才能繼續（例如，電子郵件參數主題和身體）
• 幾分鐘後（可能是幾分鐘到幾個小時），客戶端將信息發送到工作流程以便它可以繼續（例如發送電子郵件）
• 如果需要另一個人工交互，服務器再次向客戶端發送請求消息，以便它知道應該向用戶詢問信息，然後客戶端再次向該工作流程發送消息（如ab Ove）

對於我所瞭解的'正常'工作流沒有端點來接收消息。另一方面，工作流服務的確如此，但對於WF服務，工作流實例將根據傳入的請求創建，而不是讓服務器控制工作流的創建（對吧？）。

現在看來我們需要將工作流和工作流服務結合起來。

我一直在努力與此一段時間，現在搜索高和低，但找不到有用的信息。

我認爲，我們有兩個選擇：

1. 工作流服務; 如果我們要使用工作流服務，我們可以在啓動工作流的工作流的開始處有一個Receive活動。但是，客戶如何才能與特定的工作流程進行溝通？工作流服務具有一個特定的URL。

2. 工作流程; 由服務器應用程序託管的正常工作流似乎是最自然的選擇路徑。但是，那麼我們需要一種向其發送數據的方式。那麼，是否有可能升級正常的工作流程以便使用接收活動？如果是這樣，怎麼樣？消息如何在正確的工作流實例中結束？

我的問題是： 是否有人對如何解決上述問題的一些有益的指導和信息？ 有沒有有趣的替代品（不使用WF？）來實現這一目標？ 有沒有人有關於如何將WCF消息路由到WF中的正確工作流實例的文檔？

PS：我們在客戶端有一個WCF服務。工作流程可以與之進行溝通。對於短時間運行的請求來說，這不是問題，但問題是請求在客戶「回答」它們之前可能需要很長時間。另外，如果用戶點擊繼續按鈕，用戶只能請求信息（用戶不應該因爲服務器需要信息而在彈出窗口中彈出一個彈出窗口）

Answer 1

是的，帶有AppFabric的工作流服務非常理想如果我正確理解你的問題，應該開箱即用。

對於您的問題「然而，客戶如何與特定的工作流程進行溝通？」答案是相關性，你可以很容易地設置在第一個接收。您只需添加一個CorrelationHandle變量併爲傳入參數（ownerid？）和CorrelatesWith設置接收的CorrelatesOn與該句柄。對所有其他收件人執行相同的操作，並且傳入的郵件將始終路由到正確的實例。

AppFabric將有助於您的WF服務從內存中卸載並在閒置時間過長時保持不變，在新的接收來臨時喚醒等等。它還可以幫助您在自己的IIS應用程序上設置自動啓動池。 WAS將根據收到的請求激活您的工作流服務。

如果您需要進一步的具體細節，請讓我知道。