Windows Workflow Foundation WF4-工作流托管

Question

對於客戶端，我們正在創建的系統必須支持以下內容：
-必須有可能運行多個工作流，以及具有不同上下文（不同數據/業務對象）的同一工作流的多個實例。
-某些工作流程將長期運行，涉及多個用戶/客戶端會話並等待外部用戶輸入。 因此，工作流必須能夠持久化並響應來自客戶端應用程序的某些信號。 這也意味着必須在服務器應用程序上執行工作流（對嗎？）。
-我希望能夠在服務器應用程序上運行各種工作流程，並且我不想在工作流程發生更改時重新部署服務器應用程序。

我的第一個想法是工作流程服務。 經過大量研究，我得出結論認為這不是正確的方法，因為Workflow Services基本上使從客戶端應用程序中啟動的工作流在遠程位置執行活動成為可能。 它是否正確？ 還是可以將Workflow Services用於上述方案？ 大多數示例和/或教程基本上都是一個ReceiveSignal / Send組合，兩者之間有一些邏輯。

基本上，我想（從客戶端應用程序）使用特定上下文（在工作流服務器應用程序中）啟動工作流的啟動。

最好的方法是什么？

很感謝任何形式的幫助！

Answer 1

至於您的要求：

必須有可能運行多個工作流，以及具有不同上下文（不同數據/業務對象）的同一工作流的多個實例。

WF沒問題。

某些工作流將長期運行，涉及多個用戶/客戶端會話並等待外部用戶輸入。 因此，工作流必須能夠持久化並響應來自客戶端應用程序的某些信號。 這也意味着必須在服務器應用程序上執行工作流（對嗎？）。

WF專為長時間運行的任務而設計，可以與外界影響互動。 但是，這並不容易實現。 沒有可以連接的通用解決方案。 您可能必須設計與工作流擴展進行交互的自定義​​活動，該活動處理將用戶輸入移動到工作流中。 與將工作流程公開到外部相同，盡管WF4確實附帶了許多WCF活動，可以用來完成此任務。

我希望能夠在服務器應用程序上運行各種工作流，並且我不想在工作流發生更改時不必重新部署服務器應用程序。

這很難實現。 您至少必須將工作流與服務器代碼分開。 最簡單的方法是將工作流存儲為xaml， 並在運行時從數據庫中加載它 。

其他選項是使用某種依賴項注入框架（例如Structure Map或Unity），該框架在運行時加載工作流程序集。 如果工作流發生更改，則可以將新程序集放置在服務器上，更改配置並重新啟動。 或者，您可以將工作流程程序集隔離在它們自己的AppDomain中，在運行時加載它們，並在必須重新加載新版本時丟棄域。 您選擇哪一個取決於您的要求； 我實際上正在做第三種選擇，因為我必須在運行時加載許多不同版本的工作流程序集，並發運行它們，並且它們通常具有嵌入式資源，因此阻止了我使用XAML路由。

我的第一個想法是工作流程服務。 經過大量研究，我得出結論認為這不是正確的方法，因為Workflow Services基本上使從客戶端應用程序中啟動的工作流在遠程位置執行活動成為可能。 它是否正確？

我將工作流程托管在標准Windows服務應用程序中。 我必須管理和維護客戶端用於與我的工作流進行交互的WCF前端。 據我所知，如果我正確理解，那么工作流服務似乎是穩定工作流的可行選擇。 在AppFabric中托管應用程序也是一個不錯的選擇，而且我相信比使用Windows服務更簡單。 但是，無論主機是什么主機，您都有兩個選擇-您的工作流定義服務合同，或者必須定義服務合同並處理與您管理的工作流的所有執行和通信。

第一個是具有簡單外觀的穩定工作流的不錯選擇。 對於您來說，這似乎不是一個好選擇，因為您必須隨着工作流的變化動態地加載它們。 這要求工作流之外的邏輯不僅要處理來自客戶端的通信（“這是工作流X的新版本！”），還要管理工作流的壽命。

似乎您將必須找到某種宿主應用程序（IIS WebService應用程序，Windows Service，AppFabric，Azure），定義WCF服務並將其聯機，處理來自客戶端的調用，將這些調用傳達給工作流運行代碼，然后必須加載並執行這些調用，然后將結果返回鏈中。

我不禁注意到，您似乎對等待您的旅程略有准備。 我強烈建議您創建一個原型，以整齊地切入您需求的最中心的肉。 具有WCF前端的托管應用程序（建議使用AppFabric），可加載基於XAML的工作流以處理客戶端調用。 確定簡單版本后，您可以擴大范圍以涵蓋所有要求。