Windows工作流基礎WF4 - 工作流託管

Question

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

我的第一個想法是Workflow Services。經過大量研究，我得出結論認爲，這不是正確的道路，因爲Workflow Services基本上可以在客戶端應用程序中啓動的工作流程的遠程位置執行活動。它是否正確？或者我可以使用上面的場景的工作流服務？大多數示例和/或教程基本上都是一個ReceiveSignal/Send組合，其間有一些邏輯。

基本上我想（從客戶端應用程序）啓動具有特定上下文（在工作流服務器應用程序中）的工作流的開始。

什麼是最好的方法？

任何幫助非常感謝！

Answer 1

至於你的要求：

必須能夠運行多個工作流程，並用不同的上下文（不同的數據/業務對象）相同的工作流程的多個實例。

這對WF沒有任何問題。

一些工作流程會長時間運行， 涉及多個用戶/客戶端會話 並等待外部用戶輸入。 因此，工作流程必須能夠保持 ，並從客戶端應用程序響應某些信號 。這也意味着 工作流程的執行必須在服務器應用程序上完成（右？） 。

WF是專爲長時間運行的任務，可以與外部影響交互。但是，這並不是說它很容易完成;沒有通用的解決方案，您可以將其引入。您可能必須設計與Workflow Extensions相互作用的自定義活動，以便將用戶輸入移動到工作流中。與將工作流程公開給外部一樣，儘管WF4確實附帶了一系列可用於完成此任務的WCF活動。

我希望能夠在服務器上的應用程序運行各種 工作流程，我也 不希望有重新部署 服務器應用程序時，工作流程的變化。

這很難完成。您至少必須將工作流與服務器代碼分開。最簡單的方法是將您的工作流存儲爲xaml和load it at runtime，例如從數據庫中存儲。

其他選項是使用某種類型的依賴注入框架（如結構映射或統一）的，其在運行時加載工作流程序集。如果工作流程發生變化，您可以將新程序集放到服務器上，更改您的配置並重新啓動。或者，您可以在自己的AppDomain中隔離工作流程組件，在運行時加載它們，並在必須重新加載新版本時丟棄該域。你做哪一件取決於你的要求;實際上，我正在做第三種選擇，因爲我必須在運行時加載許多不同版本的工作流程組合，同時運行它們，並且它們通常會嵌入資源，從而阻止我進入XAML路線。

我首先想到的是工作流程 服務。經過大量研究，我 的結論是，這不是正確的 路徑，因爲工作流服務基本上 可以執行 活動在遠程位置從 工作流在客戶端應用程序中啓動。是 這正確嗎？

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

首先是一個簡單的門面穩定的工作流程，一個不錯的選擇。對於您來說，這似乎不是一個好的選擇，因爲您必須隨着更改動態地加載工作流;這需要工作流以外的邏輯來處理不僅來自客戶端的通信（「這裏是新版本的工作流X！」），還要管理工作流程的使用壽命。

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

我不禁注意到，你似乎爲等待你的旅程稍微準備不足。我強烈建議創建一個原型，通過您的要求的最核心的切片整齊地切片。一個託管應用程序（我建議AppFabric）與一個WCF前端加載一個基於XAML的工作流程來處理客戶端調用。一旦確定了簡單版本，就可以擴大範圍以涵蓋所有需求。