共用方式為

工作流程方式：瞭解 Windows Workflow Foundation

  • 發行項

David Chappell
Chappell & Associates

2009 年 4 月

下載這篇文章

Windows Workflow Foundation 簡介

撰寫程式碼的每個人都想要建置絕佳的軟體。 如果該軟體是伺服器應用程式，其中一部分是調整良好，處理大型負載而不耗用太多資源。 一個絕佳的應用程式也應該盡可能輕鬆瞭解，同時適用于其建立者和維護它的人員。

達成這兩個目標並不容易。 協助應用程式調整的方法通常會將它們分開，將其邏輯分割成難以理解的個別區塊。 但撰寫存在於單一可執行檔中的統一邏輯，可讓應用程式調整到全部但不可能。 需要的是讓應用程式邏輯保持一致的方式，使其更容易瞭解，同時仍讓應用程式調整規模。

達成此目標是 Windows Workflow Foundation (WF) 的主要目標。 藉由支援使用工作流程建立的邏輯，WF 提供建立統一且可調整之應用程式的基礎。 此外，WF 也可以簡化其他開發挑戰，例如協調平行工作、追蹤程式的執行等等。

WF 最初是在 2006 年發行 .NET Framework 3.0，然後在 .NET Framework 3.5 中更新。 這前兩個版本很有用，特別是針對獨立軟體廠商 (ISV) ，但它們尚未成為企業開發人員的主要技術。 使用屬於 .NET Framework 4 一部分的 WF 版本，其建立者的目標是要變更此專案。 此最新版本的主要目標是讓 WF 成為所有 .NET 開發人員程式設計工具組的標準部分。

就像任何技術一樣，套用 WF 需要瞭解它是什麼、為何很有用，以及何時適合使用它。 此概觀的目標是要清楚說明這些事項。 您不會瞭解如何撰寫 WF 應用程式，但您將瞭解 WF 提供的內容、為何是它的方式，以及其如何改善開發人員生活。 換句話說，您將開始瞭解工作流程的方式。

挑戰：撰寫統一、可調整的應用程式邏輯

撰寫程式的其中一個簡單方法是建立在單一電腦上單一進程中執行的整合應用程式。 圖 1 說明此概念。

圖 1：應用程式邏輯可以建立為統一的整個，然後在單一電腦上執行之進程中的特定執行緒上執行。

此範例中的簡單虛擬程式碼會顯示應用程式通常會執行的種類：

  • 維護狀態，此處是由簡單的字串變數表示。
  • 從外部世界取得輸入，例如從用戶端接收要求。 簡單的應用程式只能從主控台讀取，而較常見的範例可能會從網頁瀏覽器或來自另一個應用程式的 SOAP 訊息接收 HTTP 要求。
  • 將輸出傳送至外部世界。 視其建置方式而定，應用程式可能會透過 HTTP、SOAP 訊息、寫入主控台或其他方式來執行此作業。
  • 使用控制流程語句，例如 if/else 和 while，透過邏輯提供替代路徑。
  • 在應用程式中的每個點執行適當的程式碼，以執行工作。

在此所示的統一方法中，應用程式邏輯會在單一電腦上特定進程內的執行緒上執行整個生命週期。 這個簡單方法有數個優點。 就一件事而言，邏輯可以直接、統一的方式實作。 這可協助使用程式碼的人員瞭解程式碼，同時也會明確排列允許的事件順序。 例如，在圖 1 中，用戶端的第一個要求必須位於第二個要求之前，程式的控制流程需要它。 當第二個要求送達時，不需要檢查第一個要求是否已處理，因為應用程式沒有其他路徑。

此方法的另一個優點是使用應用程式的狀態很簡單。 該狀態會保留在進程的記憶體中，而且由於進程會持續執行直到其工作完成為止，因此狀態一律可用：開發人員只會存取一般變數。 可能比較簡單？

不過，這個基本程式設計樣式有限制。 當應用程式需要等候輸入時，無論是從主控台的使用者、Web 服務用戶端或其他專案，它通常只會封鎖。 執行緒和它所使用的進程都會保留到輸入到達為止，不過需要很長的時間。 由於執行緒和進程相對較少資源，因此當它們只是等待輸入時，會保留其中一個資源的應用程式不會非常妥善調整。

更可調整的方法是在應用程式等候輸入時關閉應用程式，然後在該輸入送達時重新開機。 這種方法不會浪費資源，因為應用程式在不需要執行緒或進程時不會保留資源。 這麼做也可讓應用程式在不同的電腦上在不同時間在不同的進程中執行。 應用程式可以改為在數部可用的電腦上執行，而不是鎖定至單一系統，如圖 1 所示。 這也有助於延展性，因為工作可以更輕鬆地分散到不同的電腦。 圖 2 顯示此外觀。

圖 2：應用程式邏輯可以分成區塊，所有共用通用狀態，可在不同的電腦上執行。

此範例應用程式包含與之前相同的邏輯，但現在已分成不同的區塊。 收到用戶端的第一個要求時，會載入並執行適當的區塊。 處理此要求並傳迴響應之後，就可以卸載此區塊，而不需要保留在記憶體中。 當用戶端的第二個要求送達時，會載入並執行處理它的區塊。 如圖 2 所示，此區塊可以在與第一個區塊不同的電腦上執行的不同進程中，在不同的執行緒上執行。 處理要求之後，也可以卸載這個第二個區塊，釋放它所使用的任何記憶體。

以這種方式運作的技術其中一個常見範例是 ASP.NET。 開發人員會將 ASP.NET 應用程式實作為一組頁面，每個頁面都包含應用程式邏輯的一些部分。 當要求送達時，會載入、執行正確的頁面，然後再次卸載。

此樣式中建置的應用程式可以更有效率地使用使用稍早所示簡單方法所建立的機器資源，因此會更妥善地調整。 但我們已針對此改善的延展性支付複雜度。 就一件事而言，各種程式碼區塊必須以某種方式共用狀態，如圖 2 所示。 由於每個區塊會視需要載入、執行，然後關閉，因此必須在外部儲存此狀態，例如在資料庫或其他持續性存放區中。 開發人員現在必須執行特殊動作，才能取得和儲存應用程式的狀態，而不是只存取一般變數，例如圖 1 所示的案例。 例如，在 ASP.NET 應用程式中，開發人員可以直接將狀態寫入資料庫、存取 Session 物件，或使用一些其他方法。

此改善延展性的另一個成本是程式碼不再提供程式整體邏輯的統一檢視。 在圖 1 所示的版本中，程式預期輸入的順序很明顯，只有一個可能的路徑可透過程式碼。 不過，使用圖 2 的版本，此控制流程並不明顯。 事實上，處理用戶端第二個要求的程式碼區塊可能需要先檢查第一個要求是否已完成。 對於實作任何一種重大商務程式的應用程式，瞭解並正確實作各種區塊的控制流程可能會是一項挑戰。

這種情況是：撰寫統一的應用程式可讓開發人員的生活變得簡單，且程式碼易於瞭解，但結果無法妥善調整。 撰寫共用外部狀態的區塊式應用程式，例如 ASP.NET 應用程式，允許延展性，但讓管理狀態變得更困難，並失去統一的控制流程。 我們想要做兩種方法：使用簡單的狀態管理撰寫可調整的商務邏輯，但仍具有應用程式的控制流程統一檢視。

這是工作流程提供的方式。 下一節將示範如何。

解決方案：工作流程方式

瞭解 WF 應用程式如何解決這些問題 (和其他) 需要逐步解說 WF 運作方式的基本概念。 在過程中，我們將瞭解為什麼這項技術在大量的案例中，讓開發人員生活變得更好。

建立整合應用程式邏輯

使用 WF 建立的工作流程型應用程式會執行與一般應用程式相同的類型：它會維護狀態、從輸出取得輸入，並將輸出傳送至外部世界、提供控制流程，以及執行執行應用程式工作的程式碼。 不過，在 WF 工作流程中，所有這些工作都是由活動完成。 圖 3 顯示此外觀，並顯示統一程式碼方法與比較。

圖 3：在 WF 工作流程中，所有程式的工作都是由活動執行。

如圖 3 所示，每個工作流程都有最外層的活動，其中包含所有其他活動。 在這裡，這個最外層的活動稱為 Sequence，就像一般程式一樣，它可以有可維護其狀態的變數。 因為 Sequence 是複合活動，所以也可以包含其他活動。

在這個簡單的範例中，工作流程會以 ReceiveMessage 活動開始，該活動會從外部世界取得輸入。 後面接著 If 活動， (不小心) 實作分支。 如果 也是複合活動，則包含其他活動 (標示為 X 和 Y 的活動，) 在每個分支上執行的工作。 If 活動後面接著 SendMessage 活動，此活動會將某些輸出傳送至此工作流程以外的世界。 接下來會出現另一個 ReceiveMessage 活動，這會取得更多輸入，接著接著 While 活動。 雖然 包含另一個活動 Z，但會執行這個 while 迴圈的工作。 整個工作流程會以最終 SendMessage 活動結束，並傳送程式的最終結果。

所有這些活動都以功能方式對應至一般程式的各個部分，如圖 2 中對應的色彩。 但是，相較于使用內建語言元素，因為傳統程式確實是 WF 工作流程中的每個活動都是類別。 工作流程的執行是由 WF 執行時間執行，這是知道如何執行活動的元件。 圖 4 說明此概念。

圖 4：WF 執行時間會依工作流程所決定的循序執行活動。

當它開始執行工作流程時，WF 執行時間會先執行最外部的活動，在此範例中為 Sequence。 接著，它會在該活動內執行第一個活動，也就是 ReceiveMessage，後面接著下一個活動，依此類傳。 在任何特定情況下，確切執行哪些活動取決於工作流程所採取的路徑。 例如，在第一個 ReceiveMessage 活動中取得一種輸入可能會導致 If 活動執行活動 X，而另一種輸入可能會導致它執行活動 Y。就像任何其他程式一樣。

請務必瞭解 WF 執行時間完全不知道其執行之活動內部的任何內容。 無法從 ReceiveMessage 告訴 If。 唯一知道如何執行的動作是執行活動，然後執行下一個活動。 不過，執行時間可以看到活動之間的界限，如我們所見，這是有用的專案。

這很重要的一項結果，就是 WF 不會定義任何特定語言來描述工作流程，所有專案都取決於開發人員選擇使用的活動。 為了方便使用，WF 包含基本活動程式庫 (BAL) ，可提供一組廣泛的實用活動。 (這裡所使用的所有範例活動都是從 BAL 繪製，事實上.) 但開發人員可以建立他們喜歡的任何其他活動。 他們甚至可以選擇完全忽略 BAL。

這裡有一個明顯的問題：為何要前往這一切問題？ 使用活動建立程式與開發人員使用的活動不同，因此為何應該讓任何人都兩手？ 為什麼不只撰寫一般程式碼？

當然，答案是此方法可協助我們建立更好的程式碼。 例如，工作流程方式可讓開發人員獲得統一的控制流程。 如同如圖 1 所示的簡單案例，程式的主要邏輯定義于一個一致的資料流程中。 這可讓您更容易瞭解，而且因為邏輯不會分成區塊，所以不需要進行任何額外的檢查。 工作流程本身表示允許的控制流程。

這代表我們目標的一半：建立統一的應用程式邏輯。 但 WF 應用程式也可以完成後半部，使用簡單的狀態管理來建立可調整的應用程式。 下一節說明工作流程方式如何讓此作業變得可行。

提供延展性

若要擴充，伺服器應用程式無法鎖定到單一電腦上的單一進程。 但明確地將應用程式邏輯分成區塊，如同在 ASP.NET 網頁中，細分應該是統一的控制流程。 它也會強制程式設計人員明確處理狀態。 我們真的喜歡的是讓邏輯自動細分成可在不同電腦上在不同進程中執行的區塊。 我們也想要讓應用程式的狀態受到管理，因此我們只需要存取變數。

這是工作流程所提供的確切內容。 圖 5 顯示 WF 如何完成這些工作的基本概念。

圖 5：WF 執行時間在等候輸入時卸載工作流程，然後在輸入送達後再次載入。

就像任何應用程式一樣，WF 工作流程會封鎖等候輸入。 例如，在圖 5 中，工作流程會在第二個 ReceiveMessage 活動封鎖，等候用戶端的第二個要求 (步驟 1) 。 WF 執行時間會注意到這點，因此它會儲存工作流程的狀態，以及工作流程應該在持續性存放區中繼續的位置， (步驟 2) 。 當輸入到達此工作流程 (步驟 3) 時，WF 執行時間會尋找其持續性狀態，然後重載工作流程，然後在步驟 4 (步驟 4) 停止執行。 這全都會自動發生—WF 開發人員不需要執行任何動作。 因為 WF 執行時間可以看到工作流程中，所以它可以處理所有這些詳細資料本身。

這種方法的其中一個明顯優點是工作流程不會在記憶體中停止回應封鎖執行緒，並在等候輸入時使用進程。 另一個優點是，保存的工作流程可能會在原本執行所在的電腦上重新載入。 因此，工作流程的不同部分最終可能會在不同的系統上執行，如圖 6 所示。

圖 6：工作流程可能會在不同的執行緒、不同進程中，以及在其存留期間在不同的電腦上執行。

在此範例中，假設工作流程會在機器 A 的進程中處理第一個用戶端要求。當第二個 ReceiveMessage 造成工作流程封鎖等候輸入時，WF 執行時間會將工作流程的狀態卸載至持續性存放區，如前所述。 當用戶端的第二個要求送達時，此工作流程可能會重載到機器 B 上的進程。而不是鎖定在特定電腦上特定進程中的特定執行緒，您可以視需要移動 WF 工作流程。 開發人員免費取得此靈活度，WF 會自動提供。

值得一提的是，WF 執行時間不會關心工作流程必須等候輸入的時間長度。 在工作流程保存後，可能需要幾秒鐘的時間、幾分鐘後，或甚至幾個月後才到達。 只要持續性存放區仍保留至工作流程的狀態，就可以重新開機該工作流程。 這讓 WF 成為建置實作長時間執行進程之應用程式的吸引力技術。 例如，考慮支援雇用程式的應用程式，其中包含排程初始面試到將新員工整合到組織的所有專案。 此程式可能過去幾周或幾個月，因此使用 WF 管理應用程式的狀態相當合理。 不過，雖然 WF 對於這種長時間執行的程式相當有用，但請務必瞭解這不是唯一的用途。 任何需要統一、可調整邏輯的應用程式都可以是 WF 的良好候選項目。

事實上，請看一下圖 6。 這看起來不像圖 2，其中顯示區塊化應用程式如何 (，例如，只使用 ASP.NET) 達到延展性所建置的應用程式？ 事實上，圖 6 與圖 1 沒有強大的相似性，這顯示使用線性控制流程所建置的統一應用程式？ WF 可達成這兩項：應用程式的控制流程是以可理解、統一的方式表示，而且應用程式可以調整，因為它不會鎖定為單一電腦上的單一進程。 這是工作流程方式的優點。

這並非全部;使用 WF 也有其他優點。 它可以讓協調平行工作變得更容易，例如，協助追蹤應用程式的進度等等。 下一節將探討技術的各個層面。

工作流程方式的其他優點

WF 工作流程是由 WF 執行時間執行的活動所組成。 雖然瞭解 WF 世界需要一些心力，但以此樣式撰寫應用程式邏輯可讓許多常見的程式設計挑戰變得更容易，如下所述。

協調平行工作

WF BAL 包含與熟悉的程式設計語言語句對應的活動。 因此，您可以撰寫類似一般程式的工作流程。 不過，WF 執行時間的存在也允許建立提供比傳統程式設計語言更多的活動。 其中一個重要範例是使用工作流程來協調平行工作。

請勿混淆：此處的重點不是撰寫在多核心處理器上同時執行的平行程式碼。 相反地，請考慮需要呼叫兩個 Web 服務的應用程式，然後等候這兩個結果再繼續。 平行執行呼叫的速度會比循序執行呼叫更快，但撰寫執行這項作業的傳統程式碼並不簡單。 而且，雖然.NET Framework提供各種方法以非同步方式進行這些呼叫，但其中沒有任何方法特別簡單。 這是另一種情況，工作流程方式可以亮起：WF 可讓您輕鬆完成此作業。 圖 7 顯示方式。

圖 7：平行活動內所包含的活動會以平行方式執行。

此圖顯示類似上一個範例的簡單工作流程。 最大的差異在於它現在會叫用兩個 Web 服務，然後等候兩者的回應再繼續。 為了平行執行這些呼叫，工作流程的建立者會在 Parallel 活動內包裝兩組 SendMessage 和 ReceiveMessage 活動。 Parallel 是 WF 基底活動程式庫的標準部分，其名稱建議的確切用途：以平行方式執行它所包含的活動。 WF 執行時間和平行活動會執行繁重的工作，而不是讓開發人員處理此作業的複雜性。 開發人員必須執行的所有動作，都是視需要安排活動來解決她的問題。

提供自動追蹤

由於 WF 執行時間可以看到工作流程活動之間的界限，因此它會知道每個活動何時開始和結束。 因此，提供工作流程執行的自動追蹤很簡單。 圖 8 說明此概念。

圖 8：WF 執行時間可以自動追蹤工作流程的執行。

如本範例所示，WF 執行時間可以將工作流程執行記錄寫入追蹤存放區。 其中一個選項是記錄活動，並在每次活動開始和結束執行時寫入記錄。 例如，在圖中顯示的目前，工作流程即將開始執行 If 活動，因此 WF 執行時間正在撰寫指出此事件的事件。 您也可以追蹤特定變數，也就是工作流程狀態，在工作流程執行的各個時間點記錄其值。

如同 WF 的其他層面，此自動記錄基本上不需要在開發人員的一部分上運作。 他可以直接指出應該進行追蹤，並指定他感興趣的層級，而 WF 負責處理其餘專案。

建立可重複使用的自訂活動

WF BAL 中的活動提供各種實用的函式。 例如，此內建集合包含控制流程的活動、傳送和接收訊息、平行執行工作等等。 但建置實際應用程式通常需要建立執行該應用程式特定工作的活動。

為了達成此條件，WF 允許建立自訂活動。 例如，在稍早顯示的工作流程中標示為 X、Y 和 Z 的活動實際上是自訂活動，如圖 9 所示。

圖 9：自訂活動可讓工作流程執行應用程式特定的工作。

自訂活動可能很簡單，只要執行一項工作，也可以是包含任意複雜邏輯的複合活動。 無論是簡單還是複雜，自訂活動都可以以許多不同的方式使用。 例如，使用 WF 建立的商務應用程式可能會實作應用程式特定的邏輯作為一或多個自訂活動。 或者，使用 WF 的軟體廠商可能會提供一組自訂活動，讓客戶生活更容易。 例如，Windows SharePoint Services可讓開發人員建立 WF 型應用程式，以透過 SharePoint 的標準清單與人員互動。 為了簡化此作業，SharePoint 包含自訂活動，以將資訊寫入清單。

您可以使用 C# 或 Visual Basic 或其他語言，直接以程式碼撰寫自訂活動。 您也可以藉由結合現有的活動來建立它們，這允許一些有趣的選項。 例如，組織可能會為其最熟練的開發人員建立較低層級的自訂活動，然後將這些活動封裝成較高層級的商務功能，讓技術人員較少使用。 這些較高層級的活動可以實作所需的任何商務邏輯，全都整齊地包裝在可重複使用的方塊中。

另一種思考方式是將 WF 執行時間所執行的特定一組活動視為語言來檢視。 如果組織建立一組可重複使用的自訂活動來解決多個應用程式的特定問題，他們真正執行的動作是建立一種網域特定語言 (DSL) 。 完成此動作之後，技術人員可能會使用這些預先封裝的自訂功能區塊來建立 WF 應用程式。 除了撰寫新的程式碼來實作應用程式的函式之外，也可以藉由組合現有的活動來建立有用的新軟體。 以工作流程方式定義的這種 DSL 樣式，在某些情況下可以大幅改善開發人員生產力。

讓進程可見

使用傳統程式設計語言建立應用程式表示撰寫程式碼。 使用 WF 建立應用程式通常不是相當低的層級。 相反地，至少可以圖形方式組合工作流程的主要控制流程。 為了允許這種情況，WF 包含可在 Visual Studio 內執行的工作流程設計工具。 圖 10 顯示範例。

圖 10：在 Visual Studio 內執行的工作流程設計工具，可讓開發人員藉由拖放活動來建立工作流程。

如本範例所示，WF 開發人員可用的活動會出現在左側。 若要建立工作流程，她可以在設計介面上組合這些活動，以建立應用程式所需的任何邏輯。 如有必要，WF 工作流程設計工具也可以重新裝載于其他環境中，讓其他人在自己的供應專案內使用此工具。

對於某些開發人員，此圖形化方法可讓應用程式更快速且更容易建立。 它也會讓應用程式的主要邏輯更可見。 WF 工作流程設計工具提供簡單的概觀，可協助開發人員更快速地瞭解應用程式的結構。 這對於必須維護已部署應用程式的人員特別有用，因為學習新應用程式夠好，以變更它可能是耗時的程式。

但自訂活動呢？ 還不需要撰寫程式碼嗎？ 答案是是，因此 WF 也允許使用 Visual Studio 在 C#、Visual Basic 和其他語言中建立自訂活動。 若要瞭解運作方式，請務必瞭解 WF 設計工具如何代表工作流程的各個部分。 圖 11 顯示這通常如何完成。

圖 11：工作流程的狀態和控制流程通常會在 XAML 中描述，而自訂活動則可以程式碼撰寫。

WF 工作流程的組成—它包含的活動及其相關方式—通常是使用 eXtensible Application Markup Language (XAML) 來表示。 如圖 11 所示，XAML 提供 XML 架構的方式，將工作流程的狀態原因為變數，並表示工作流程活動之間的關聯性。 例如，最外層工作流程活動的 XAML 包含 ReceiveMessage 活動，後面接著 If 活動，就像您預期一樣。

This If activity contains the custom activities X and Y. Rather to created in XAML， however， these activities are written as C# classes. 雖然可以單獨在 XAML 中建立一些自訂活動，但更特製化的邏輯通常會直接以程式碼撰寫。 事實上，雖然這不是一般方法，但開發人員也可以完全在程式碼中撰寫工作流程，而不需要使用 XAML。

使用 Windows Workflow Foundation：某些案例

瞭解 WF 的機制是瞭解工作流程方式不可或缺的一部分。 不過，這不夠：您也需要瞭解工作流程在應用程式中的使用方式。 因此，本節會探討 WF 可能在某些典型情況下的使用方式和原因。

建立工作流程服務

建置商務邏輯即服務通常很合理。 例如，假設必須透過 ASP.NET、Silverlight 用戶端和獨立桌面應用程式，從瀏覽器存取相同的功能集。 實作此邏輯作為一組可從這些用戶端叫用的作業，也就是服務即服務，可能是最佳方法。 將邏輯公開為服務也可讓其他邏輯存取，有時可能會讓應用程式整合變得更容易。 (這是 SOA、服務導向架構的概念背後的核心概念。)

對於現今的 .NET 開發人員而言，建立服務的科技是 Windows Communication Foundation (WCF) 。 此外，WCF 可讓開發人員實作可使用 REST、SOAP 和其他通訊樣式存取的商務邏輯。 對於某些服務，WCF 可以是所有必要的服務。 如果您要實作一項服務，其中每個作業都是獨立的，例如，您可以隨時呼叫任何作業，而不需要排序，將這些服務建置為原始 WCF 服務就沒問題。 服務建立者，其作業只會公開資料，例如，只使用 WCF 即可離開。

不過，對於更複雜的情況，如果服務中的作業實作一組相關的功能，WCF 可能就不夠。 請考慮讓客戶預訂航班保留或線上購物或執行一些其他商務程式的應用程式。 在這些情況下，您可以選擇使用 WF 來實作服務的邏輯。 此組合甚至具有名稱：使用 WF 實作的邏輯，並透過 WCF 公開稱為工作流程服務。 圖 12 說明概念。

圖 12：工作流程服務會使用 WCF 來公開 WF 型邏輯。

如圖所示，WCF 允許公開用戶端可以透過 SOAP、REST 或其他專案叫用的一或多個端點。 當用戶端在此範例服務中呼叫初始作業時，會由工作流程的第一個 ReceiveMessage 活動處理要求。 If 活動隨即出現，且其所包含的自訂活動執行方式取決於用戶端要求的內容。 當 If 完成時，會透過 SendMessage 傳迴響應。 用戶端的第二個要求叫用另一個作業會以類似的方式處理：ReceiveMessage 接受該要求、由工作流程的邏輯處理，然後使用 SendMessage 回應。

為什麼以這種方式建置服務導向商務邏輯是個好主意？ 答案很明顯：它可讓您建立統一且可調整的應用程式。 這項知識內嵌在工作流程邏輯本身中，而不是要求每個作業包含檢查， 是否合法叫用我？— 這項知識會內嵌在工作流程邏輯本身。 這可讓應用程式更容易撰寫，而且對於最終必須維護應用程式的人員來說，更容易瞭解。 而且，WF 執行時間不會撰寫自己的程式碼來處理延展性和狀態管理，而是為您執行這些動作。

工作流程服務也會取得稍早所述的所有優點，就像任何其他 WF 應用程式一樣。 這些選項包括：

  • 實作執行平行工作的服務很簡單：只要將活動卸載到平行活動即可。
  • 追蹤是由執行時間提供。
  • 視問題網域而定，可能會建立可重複使用的自訂活動，以用於其他服務。
  • 工作流程可以透過圖形方式建立，並在 WF 工作流程設計工具中直接顯示進程邏輯。

像這樣一起使用 WF 和 WCF—建立工作流程服務，在舊版 WF 中並不容易。 有了 .NET Framework 4，這項技術組合會以更自然的方式結合在一起。 目標是讓以此樣式建立商務邏輯盡可能簡單。

使用 「Dublin」 執行工作流程服務

尚未討論工作流程的一大問題：他們在哪裡執行？ WF 執行時間是類別，如同活動。 所有這些專案都必須在某些主機進程中執行，但這是哪一個進程？

答案是 WF 工作流程可以在幾乎任何進程中執行。 您可以免費建立自己的主機，甚至取代某些 WF 的基本服務， (例如持續性) 。 許多組織都已完成這項操作，特別是軟體廠商。 但是，為 WF 建置真正功能性的主機程式，但完全具備管理功能，並不是全世界最簡單的事。 而且，對於想要花費其金錢來建置商務邏輯而非基礎結構的組織，避免這項工作很合理。

較簡單的選項是在 Internet Information Server (IIS) 所提供的背景工作進程中裝載 WF 工作流程。 雖然運作正常，但它只提供裸機解決方案。 為了簡化 WF 開發人員的存留時間，Microsoft 提供名為 「Dublin」 的技術程式碼。 實作為 IIS 和 Windows Process Activation Service (WAS) 的延伸模組，主要目標是讓 IIS 和 WAS 成為工作流程服務的主機。 圖 13 顯示工作流程服務在「阿姆斯特丹」環境中執行時的外觀。

圖 13：「阿姆斯特丹」提供工作流程服務的管理和更多功能。

雖然 WF 本身包含保存工作流程狀態、追蹤等的機制，但它只提供基本概念。 「阿姆斯特丹」是以 WF 的內部支援為基礎，提供更完整的實用且可管理的環境。 例如，除了以SQL Server為基礎的持續性存放區和追蹤存放區之外，「阿姆斯特丹」也提供管理工具來處理這些存放區。 此工具實作為 IIS 管理員的延伸模組，可讓使用者檢查和管理 (，例如終止) 保存的工作流程、控制完成多少追蹤、檢查追蹤記錄等等。

除了新增 WF 的現有功能之外，「阿姆斯特丹」也會新增其他服務。 例如，「阿姆斯特丹」可以監視執行中的工作流程實例，自動重新開機任何失敗的實例。 Microsoft 的主要目標是「阿姆斯特丹」：提供一組實用的工具和基礎結構，以管理及監視裝載于 IIS/WAS 中的工作流程服務。

在 ASP.NET 應用程式中使用工作流程服務

假設大部分的 .NET 應用程式都使用 ASP.NET。 讓工作流程成為主流，這表示讓 WF 成為 ASP.NET 開發人員的吸引力選項。

在舊版 WF 中，工作流程效能不足以用於大量 ASP.NET 應用程式。 不過，針對.NET Framework 4 版，WF 的設計工具會重新建構技術的重要部分，大幅提升效能。 此版本連同「阿姆斯特丹」的出現，讓 WF 型應用程式特別是工作流程服務成為 ASP.NET 開發人員更可行的選項。 圖 14 顯示此外觀的簡單圖片。

圖 14：ASP.NET 應用程式的商務邏輯可以實作為工作流程服務

在此案例中，ASP.NET 網頁只會實作應用程式的使用者介面。 其邏輯完全在工作流程服務中實作。 對工作流程服務，ASP.NET 應用程式只是另一個用戶端，而對 ASP.NET 應用程式，工作流程服務看起來就像任何其他服務一樣。 它不需要知道此服務是使用 WF 和 WCF 來實作。

不過，同樣地，重大問題是為何要這麼做？ 為什麼不只以一般方式撰寫 ASP.NET 應用程式的邏輯？ 使用 WF (和 WCF) 購買什麼？ 此時，這些問題的大部分答案可能很明顯，但仍值得注意：

  • 該邏輯可以改為在單一整合工作流程中實作，而不是將應用程式的邏輯分散到許多不同的 ASP.NET 網頁。 特別是針對大型網站，這可讓應用程式更容易建置和維護。
  • 開發人員可以依賴 WF 執行時間來執行此動作，而不是在 ASP.NET 應用程式中明確使用狀態，或許是使用 Session 物件或其他專案。 ASP.NET 應用程式只需要追蹤每個工作流程實例的實例識別碼， (每個使用者) ，例如將它儲存在 Cookie 中。 當應用程式將此識別碼提供給 「阿姆斯特丹」時，會自動重載工作流程實例。 然後它會開始執行其離開的位置，並還原其所有狀態。
  • WF 的其他優點也適用，包括更容易平行處理原則、內建追蹤、可重複使用活動的可能性，以及將應用程式邏輯視覺化的能力。

由於工作流程服務未系結至特定電腦上的特定進程，因此可以在多個「阿姆斯特丹」實例之間進行負載平衡。 圖 15 顯示此外觀的範例。

圖 15：複寫的 ASP.NET 應用程式可以使用多個「阿姆斯特丹」實例來執行工作流程服務。

在此簡單案例中，ASP.NET 應用程式的頁面會在三部 IIS 伺服器機器之間複寫。 雖然這些頁面會處理與使用者的互動，但應用程式的商務邏輯會實作為使用 「Dublin」 執行的工作流程服務。 兩個「阿姆斯特丹」環境的實例正在執行，每一個實例都在自己的電腦上。 當使用者收到第一個要求時，負載平衡器會將它路由傳送到 IIS 的最上層實例。 處理此要求 ASP.NET 網頁會呼叫工作流程服務中實作此商務邏輯區塊的作業。 這會導致 WF 工作流程開始在圖中最上層機器的 「阿姆斯特丹」實例中執行。 完成此工作流程中的相關活動之後，呼叫會返回 ASP.NET 網頁，並保存工作流程。

使用者的第二個要求會路由傳送至不同的 IIS 實例。 接著，此電腦上的 [ASP.NET] 頁面會叫用 (保存) 工作流程中的作業，與處理其第一個要求的電腦不同。 這並無問題：「阿姆斯特丹」只會從它與其同一部伺服器共用的持續性存放區載入工作流程實例。 此重載的工作流程服務接著會處理使用者的要求，並挑選離開的位置。

瞭解 WF (和 WCF) ，然後學習以這個新樣式建立邏輯需要一些工作。 針對簡單的 ASP.NET 應用程式，提高此學習曲線可能不值得投入心力。 不過，任何使用 .NET 建立大型 Web 應用程式的人，至少應該考慮將其邏輯建立為工作流程服務的可能性。

在用戶端應用程式中使用工作流程

到目前為止，焦點完全是使用 WF 來建立伺服器應用程式。 不過，雖然這是現今最常使用的技術，但 WF 也有助於用戶端應用程式。 其延展性層面通常不會在此案例中新增很多，因為用戶端電腦上執行的程式碼通常不需要處理大量同時使用者，但 WF 仍可使用。

例如，請考慮用戶端應用程式，以使用 Windows Forms 或 Windows Presentation Foundation建立的圖形化介面來呈現其使用者。 應用程式可能會有事件處理常式來處理使用者的滑鼠按一下，或許會將商務邏輯分散到這些事件處理常式。 這與 ASP.NET 應用程式將邏輯分散到個別頁面群組，而且可以建立相同的挑戰。 例如，應用程式流程可能難以辨識，而開發人員可能需要插入檢查，以確保以正確的順序完成。 如同 ASP.NET 應用程式一樣，將此邏輯實作為統一 WF 工作流程有助於解決這些疑慮。

WF 的其他層面也可以在用戶端上使用。 假設應用程式需要平行叫用多個後端 Web 服務，例如，或可從追蹤獲益。 如同在伺服器上，WF 可協助解決這些挑戰。 雖然現今大部分的 WF 應用程式在伺服器上執行，但請務必瞭解這不是唯一的選擇。

深入探討：Windows Workflow Foundation 的技術

此概觀的目標是不要讓您成為 WF 開發人員。 不過，只要深入瞭解 WF 的技術，有助於決定何時選擇工作流程方式很合理。 因此，本節會深入探討一些 WF 最重要的部分。

工作流程種類

在.NET Framework 4 中，WF 開發人員通常會選擇兩種不同的工作流程樣式，方法是選擇不同的最外層活動。 這些活動包括：

  • 順序：依序執行活動，逐一執行。 序列可以包含 If 活動、While 活動和其他類型的控制流程。 不過，無法往後移動，不過，執行必須一律向前移動。
  • 流程圖：依序執行活動，例如 Sequence，但也允許控制返回先前的步驟。 這個更有彈性的方法，.NET Framework 4 版 WF 的新功能，更接近實際程式的運作方式，以及我們大部分的想法。

雖然 Sequence 和 Flowchart 都可以做為工作流程中最外層的活動，但它們也可以在工作流程內使用。 這可讓這些複合活動以任意方式巢狀。

在前兩個版本中，WF 也包含另一個稱為 State Machine 之工作流程外部活動的選項。 如其名稱所示，此活動可讓開發人員明確地建立狀態電腦，然後讓外來事件觸發該狀態機器中的活動。 不過，.NET Framework 4 中的 WF 是一項重大變更，需要重新撰寫舊版中大部分的活動，並建置新的設計工具。 由於涉及的工作，WF 的建立者將不會從初始.NET Framework 4 版傳遞狀態機器活動。 (即使 Microsoft 的資源沒有限制。) 仍然如此，新的流程圖活動應該解決先前使用狀態機器所需的許多情況。

基底活動程式庫

工作流程可以包含開發人員選擇使用的任何一組活動。 例如，工作流程完全合法，只包含自訂活動。 不過，這不太可能。 大部分時候，WF 工作流程至少會使用基底活動程式庫中提供的一些內容。 在 .NET Framework 4 中，WF 所提供的更廣泛實用 BAL 活動如下：

  • 指派：將值指派給工作流程中的變數。
  • 補償：提供補償的方式，例如處理長時間執行交易中發生的問題。
  • DoWhile：執行活動，然後檢查條件。 只要條件成立，活動就會經過執行。
  • 流程圖：將一組循序執行的活動分組在一起，但也允許控制返回先前的步驟。
  • ForEach：針對集合中的每個物件執行活動。
  • 如果：建立執行的分支。
  • 平行：同時執行多個活動。
  • 保存：明確要求 WF 執行時間保存工作流程。
  • 選擇：允許等候一組事件，然後只執行與第一個事件相關聯的活動。
  • ReceiveMessage：透過 WCF 接收訊息。
  • SendMessage：透過 WCF 傳送訊息。
  • 順序：將一組循序執行的活動分組在一起。 除了做為工作流程最外層的活動之外，Sequence 在工作流程內也很有用。 例如，While 活動只能包含一個其他活動。 如果該活動是 Sequence，開發人員可以在 while 迴圈內執行任意數目的活動。
  • Switch：提供多向執行分支。
  • 擲回：引發例外狀況。
  • TryCatch：允許建立 try/catch 區塊來處理例外狀況。
  • While：只要條件為 true，就會執行單一活動。

這不是完整清單—.NET Framework 4 中的 WF 包含更多內容。 此外，Microsoft 計畫在 CodePlex 上提供新的 WF 活動，其主控網站適用于開放原始碼專案。 例如，在.NET Framework 4 版之後不久，尋找讓工作流程發出資料庫查詢和更新、執行 PowerShell 命令等的活動。

如這份清單所建議，BAL 主要是回應傳統一般用途程式設計語言的功能。 這不應該令人意外，因為 WF 是一般用途的技術。 不過，如本概觀所述，它採用的方法—WF 執行時間所執行的活動，有時可能會讓應用程式開發人員生活更好。

.NET Framework 4 中的工作流程

.NET Framework第 4 版對 Windows Workflow Foundation 帶來重大變更。 例如，BAL 中的活動已重新撰寫，並已新增一些新的活動。 這帶來真正的優點—例如，許多工作流程現在執行得更快，但也表示使用舊版 WF 建立的工作流程無法由 WF 執行時間的 .NET 4 版本執行。 不過，這些較舊的工作流程仍然可以與.NET Framework 4 個工作流程一起執行，不過，它們不需要擲回。 此外，使用舊版 WF 建立的活動，包括整個工作流程，可能會在 .NET Framework 4 中 WF 提供的新 Interop 活動內執行。 這可讓來自較舊工作流程的邏輯用於新的工作流程。

除了更好的效能之外，這個新版的 WF 也會帶來其他有趣的變更。 例如，舊版 WF 包含可包含任意程式碼的程式碼活動。 這可讓開發人員將幾乎任何所需的功能新增至工作流程，但它是稍微不刪除的解決方案。 在 .NET Framework 4 中，WF 的建立者讓撰寫自訂活動變得相當簡單，因此已移除 Code 活動。 新功能現在會建立為自訂活動。

自 2006 年 WF 的原始外觀以來，.NET Framework 4 版的變更最顯著。 不過，所有這些專案都有相同的目標：讓開發人員更容易使用工作流程建置有效的應用程式。

結論

Windows Workflow Foundation 提供許多應用程式的實際優點。 在第一個版本中，WF 大多與軟體廠商合作。 這些技術的原始內建很有用，但不適合用于主要企業用途。 使用 .NET Framework 4，WF 的建立者想要變更此問題。

藉由讓 WF 和 WCF 一起運作良好、改善 WF 的效能、提供更佳的工作流程設計工具，以及使用 「Dublin」 提供功能完整的主機程式，Microsoft 會讓工作流程方式更吸引更廣泛的案例。 其日子是 Windows 應用程式開發課程中的特製化播放機，即將接近。 WF 正在中心階段。

關於作者

David Chappell 是加州加州 的 Chappell & Associates 主體。 透過他的演講、撰寫和諮詢，他可協助世界各地的人員瞭解、使用及做出更妥善的新技術決策。