WF學習系列之一：WF基本知識點概述
此文是從msdn中摘錄而來，并經過相關的提煉，主要介紹了WF的基礎知識點，希望對大家有所幫助。本文主要包括以下11個方面：
1 工作流概述 ：工作流是一組存儲為模型的名為活動的基本單元，活動用于描述實際進程。工作流運行時引擎用來創建和維護工作流實例的。
2 活動概述：活動是工作流的基本單元，可以執行單個操作，也可以是一組復合的活動。活動在其生存期內有六種狀態：Initialized, Executing, Canceling, Closed, Compensating, Faulting。
3 服務概述 ：工作流運行的時候，需要各種服務，主要包括：計劃服務（創建和管理在工作流運行時引擎以異步/同步的方式運行工作流實例的線程）；CommitWorkBatch服務（啟用與提交工作批次相關的自定義邏輯） 持久性服務（滿足長時間才能完成的工作流，將工作流暫時從內存轉移到硬盤）；跟蹤服務（宿主通過捕獲工作流執行期間引發的事情，以觀察到工作流實例，可以采用將信息入庫、輸出到控制臺等多種方式）。
4 補償概述 ：主要用于發生異常時的撤銷。
5 本地通信和關聯概述 ：解決宿主進程同工作流或工作流中特定活動通信的問題而提出的兩個概念。
6 持久性概述 ：從內存中卸載工作流，而且工作流可以序列化為持久性存儲。
7 跟蹤概述 ：捕獲有關工作流實例的信息，并在這些實例執行時存儲該信息。
8 序列化概述 ：對工作流、活動和規則可以進行序列化和反序列化。
9 工作流更改概述： 可以在運行時動態更新工作流實例和聲明性規則，不必重新編譯和重新啟動工作流。
10 “規則和條件”概述： Windows Workflow Foundation 可將業務邏輯作為規則或條件來實現，使用工作流更改來執行動態更新，可在運行時修改這些規則和聲明性條件。
11 錯誤處理概述 ：Windows Workflow Foundation 中的錯誤處理指的是以異步方式處理異常。
12 工作流標記概述 ：采用XAML，使開發人員和設計人員以聲明的方式為業務邏輯建模。
Windows Workflow Foundation 是編程模型、引擎和工具，用于在windows上快速生成啟用工作流的應用程序。它包括一個命名空間、一個進程內工作流和多個VS2005設計器。
Windows Workflow Foundation 是一個框架，讓用戶可以在其為Windows Vista、Windows XP和Windows Server 2003 系列編寫的應用程序中創建系統或人工工作流。
Windows Workflow Foundation 可用于解決簡單方案，如根據用戶輸入顯示UI控件，或用于解決大型企業遇到的復雜方案，如訂單處理和庫存控制。
Windows Workflow Foundation 可以處理的方案包括：
在業務線應用程序中啟用工作流
用戶界面頁流
以文檔為中心的工作流
人工工作流
面向服務應用程序的復合工作流
業務規則驅動的工作流
系統管理的工作流
Windows Workflow Foundation 提供了與其他 .NET Framework 3.0 技術（如 Windows Communication Foundation 和 Windows Presentation Foundation）一致和熟悉的開發體驗。 Windows Workflow Foundation API 完全支持 Visual Basic .NET 和 C#、專用工作流編譯器、在工作流中調試、圖形工作流設計器，并支持完全用代碼或標記開發工作流。 Windows Workflow Foundation 還提供了可擴展模型和設計器，用于生成為最終用戶或跨多個項目重用封裝工作流功能的自定義活動。
1 工作流概述
工作流是一組存儲為模型的名為活動的基本單元，活動用于描述實際進程。 工作流提供了一種方法，用于描述多項短期運行或長期運行的工作之間的執行順序和依賴關系。 此工作從頭到尾地貫穿模型，并且活動可以人工執行或由系統功能執行。
工作流運行時引擎
每個正在運行的工作流實例都是由進程中運行時引擎創建和維護的，該引擎通常稱為“工作流運行時引擎”。 在一個應用程序域中可以有多個工作流運行時引擎，并且運行時引擎的每個實例均可支持多個并發運行的工作流實例。
工作流模型經過編譯后，可以在包括控制臺應用程序、基于窗體的應用程序、Windows 服務、ASP.NET 網站和 Web 服務在內的任意 Windows 進程中執行。 由于工作流是在進程中承載，因此工作流可以輕松地與其宿主應用程序通信。
下面的插圖顯示了如何在一個宿主應用程序的進程中同時承載工作流、活動和工作流運行時引擎。
2 活動概述
活動是工作流的基本單元。 以編程方式將活動添加到工作流中，與向根節點添加 XML DOM 子節點的方式類似。 當給定流路徑中的所有活動都完成運行時，工作流實例即完成。
活動可以執行單個操作，如向數據庫寫入值，也可以執行復合活動并包含一組活動。 活動有兩種行為類型：運行時和設計時。 運行時行為在執行時指定操作。 設計時行為在設計器中顯示時可以控制活動的外觀及其交互。
Windows Workflow Foundation 包括一個標準活動庫，并為您提供創建自己的活動的機制。 這支持工作流之間的擴展性和可重用性。
Windows Workflow Foundation 包含一組默認活動，這些活動提供了有關控制流、條件、事件處理、狀態管理以及與應用程序和服務通信的功能。 在設計工作流時，可以使用 Windows Workflow Foundation 提供的活動，并且可以創建自己的自定義活動。
活動是工作流的基本構造塊。 工作流是一組以樹狀結構分層組織的活動。 活動表示工作流中的操作。 它可以是延遲之類的簡單操作，也可以是由多個子活動組成的復合活動。
與工作流一樣，活動可以是順序的，這意味著其操作順序在設計時指定。 活動也可以是事件驅動的，這意味著其操作順序是在運行時為響應外部事件而確定的。
每個活動都有一個活動執行上下文，它表示活動的執行環境。 活動執行上下文類似于 HTTP 上下文：對象具有狀態、一組參數以及它在給定時間點所獨有的構造。 某些復合活動（如 ReplicatorActivity 活動和 WhileActivity 活動）會在執行期間創建其子活動的多個實例，每個子活動都有其自己的活動執行上下文作為其運行環境。有關活動執行上下文的更多信息，請參見了解活動執行上下文。
ActivityExecutionContext (AEC) 是在宿主應用程序調用 Start 方法時為活動創建的執行環境。
AEC 提供了一種復合活動，該復合活動具有執行 (ExecuteActivity) 或取消 (CancelActivity) 子活動的能力。 它也可以通過 CloseActivity 方法來關閉自己。 這些是僅有的父活動可以通過 AEC 控制的執行狀態更改。 所有其他活動狀態都是由工作流運行時引擎控制的。
AEC 具有名為 ExecutionContextManager 的屬性，使其可以生成新 AEC。 這些 AEC 是父活動（如 WhileActivity 活動、ReplicatorActivity 活動或 ConditionedActivityGroup 活動）每次運行其子活動超過一次時生成的。 每次迭代都使用其自己的 AEC 創建一個克隆的活動，因此子活動的這些不同實例可以獨立運行（而對于 ReplicatorActivity 活動則可能并行運行）。
此外，ActivityExecutionContextManager 恢復保持的上下文和完成的上下文，其中所有活動處于 Closed 或 Initialized 狀態，并具有可選的持久性。AEC 只有在其相關活動處于 Closed 或 Initialized 狀態時才能完成。
活動只有在生成的所有執行上下文 (CreateExecutionContext) 都已完成 (CompleteExecutionContext) 時才能關閉。 違反此行為將導致工作流運行時引擎引發異常。
了解活動狀態模型
活動在其生存期內可以有六種狀態。 這些狀態分別為 Initialized、Executing、Canceling、Closed、Compensating 和 Faulting。
在 Initialized 狀態期間，將為活動創建 ActivityExecutionContext，并將執行特定于該活動的其他初始化詳細信息。 例如，某些 Windows Workflow Foundation 活動（如 SuspendActivity）會在初始化期間檢查其是否具有父級復合活動。當某個活動進入 Executing 狀態時，將會執行該活動的主要功能。 活動的 Canceling 狀態可以由父活動顯式置入，也可以因為在執行該活動期間引發異常而置入。 Closed 狀態是活動的最后和最終狀態。 需要注意的一個問題是，如果某活動成功完成，但根據業務邏輯隨后必須經過 Compensating 活動。 因此，該活動將會從 Closed 轉換到 Compensating，然后在完成補償邏輯后轉換回 Closed。 有關補償的更多信息，請參見在工作流中使用補償和使用 CompensateActivity 活動。如果在活動的 Executing 狀態、Canceling 狀態或 Compensating 狀態期間引發異常，活動將轉換到 Faulting 狀態。
下面的流程圖演示了活動如何在各種活動狀態之間轉換。
紅色實線表示工作流運行時引擎負責將活動從 Initialized 狀態轉換到 Executing 狀態，或從 Closed 狀態轉換到 Compensating 狀態。
黃色實線表示父活動負責將子活動從 Executing 狀態轉換到 Closed 狀態。 如果您創建自定義復合活動，則必須親自進行處理。
藍色實線表示工作流運行時引擎負責將活動從 Executing、Canceling 或 Compensating 狀態轉換到 Faulting 狀態。
黃色虛線表示工作流運行時引擎負責將活動從 Canceling 狀態、Compensating 狀態或 Faulting 狀態轉換到 Closed 狀態。
注意:
活動不能從 Closed 狀態轉換到 Executing 狀態。 如果試圖進行轉換，將會在調用 Execute 時引發異常。
僅當所有子活動都處于 Closed 或 Initialized 狀態時，才能關閉活動。 由于這是一條遞歸規則，因此意味著試圖關閉的活動下面的整個樹必須為 Closed 或 Initialized 狀態，調用才會成功。
|
活動 |
說明 |
|
與 HandleExternalEventActivity 活動一起使用，以實現與本地服務之間的輸入和輸出通信。 有關更多信息，請參見使用 CallExternalMethodActivity 活動。 |
|
|
用于包含在復合活動的所有子活動執行完畢之前取消的復合活動的清理邏輯。 有關更多信息，請參見使用 CancellationHandlerActivity 活動。 |
|
|
可用于向工作流中添加 Visual Basic 或 C# 代碼。 有關更多信息，請參見使用 CodeActivity 活動。 |
|
|
SequenceActivity 的可補償版本。 有關更多信息，請參見使用 CompensatableSequenceActivity 活動。 |
|
|
TransactionScopeActivity 的可補償版本。 有關更多信息，請參見使用 CompensatableTransactionScopeActivity 活動。 |
|
|
可用來調用代碼以撤消或補償在發生錯誤時已由工作流執行的操作。 有關更多信息，請參見使用 CompensateActivity 活動。 |
|
|
為已完成的 TransactionScopeActivity 活動執行補償的一個或多個活動的包裝。 有關更多信息，請參見使用 CompensationHandlerActivity 活動。 |
|
|
根據應用于 ConditionedActivityGroup 活動本身的條件以及分別應用于每個子活動的條件來執行子活動。 有關更多信息，請參見使用 ConditionedActivityGroup 活動。 |
|
|
可用于在工作流中根據超時間隔建立延遲。 有關更多信息，請參見使用 DelayActivity 活動。 |
|
|
包裝在指定事件發生時執行的一個或多個活動。 有關更多信息，請參見使用 EventDrivenActivity 活動。 |
|
|
提供一個用于將事件與活動關聯的框架。 有關更多信息，請參見使用 EventHandlersActivity 活動。 |
|
|
將其主要子活動與 EventHandlersActivity 活動并發執行。 有關更多信息，請參見使用 EventHandlingScopeActivity 活動。 |
|
|
用于處理指定類型的異常。 有關更多信息，請參見使用 FaultHandlerActivity 活動。 |
|
|
表示一個復合活動，它有一個由類型為 FaultHandlerActivity 的子活動組成的有序列表。 有關更多信息，請參見使用 FaultHandlersActivity 活動。 |
|
|
與 CallExternalMethodActivity 活動一起使用以實現與本地服務之間的輸入和輸出通信。 有關更多信息，請參見使用 HandleExternalEventActivity 活動。 |
|
|
測試每個分支條件，在第一個條件為 true 的分支上執行活動。 有關更多信息，請參見使用 IfElseActivity 活動。 |
|
|
表示 IfElseActivity 活動的一個分支。 有關更多信息，請參見使用 IfElseBranchActivity 活動。 |
|
|
使工作流能夠調用 Web 服務。 有關更多信息，請參見使用 InvokeWebServiceActivity 活動。 |
|
|
使工作流能夠調用其他工作流。 有關更多信息，請參見使用 InvokeWorkflowActivity 活動。 |
|
|
只包含 EventDrivenActivity 子活動的復合活動。 有關更多信息，請參見使用 ListenActivity 活動。 |
|
|
用于計劃將兩個或更多個 SequenceActivity 子活動分支同時進行處理。 有關更多信息，請參見使用 ParallelActivity 活動。 |
|
|
用于表示一個規則集合。 規則由條件和引起的操作組成。 有關更多信息，請參見使用 PolicyActivity 活動。 |
|
|
創建單個子活動的多個實例。 有關更多信息，請參見使用 ReplicatorActivity 活動。 |
|
|
提供一種將多個活動鏈接在一起以順序執行的簡單方法。 有關更多信息，請參見使用 SequenceActivity 活動。 |
|
|
指定到新狀態的轉換。 有關更多信息，請參見使用 SetStateActivity 活動。 |
|
|
表示狀態機工作流中的一個狀態。 有關更多信息，請參見使用 StateActivity 活動。 |
|
|
在 StateActivity 活動中用作容器，以容納在離開 StateActivity 活動時執行的子活動。 有關更多信息，請參見使用 StateFinalizationActivity 活動。 |
|
|
在 StateActivity 活動中用作容器，以容納在進入 StateActivity 活動時執行的子活動。 有關更多信息，請參見使用 StateInitializationActivity 活動。 |
|
|
掛起工作流的操作，以便能夠在出現某種需要特別注意的錯誤情況時進行干預。 有關更多信息，請參見使用 SuspendActivity 活動。 |
|
|
在同步域中按順序執行所包含的活動。 有關更多信息，請參見使用 SynchronizationScopeActivity 活動。 |
|
|
可用于在發生錯誤情況時立即結束工作流的操作。 有關更多信息，請參見使用 TerminateActivity 活動。 |
|
|
可用于捕獲作為工作流的過程元數據的一部分引發的業務異常。 有關更多信息，請參見使用 ThrowActivity 活動。 |
|
|
提供一個用于事務和異常處理的框架。 有關更多信息，請參見使用 TransactionScopeActivity 活動。 |
|
|
用于對 Web 服務錯誤的發生進行建模。 有關更多信息，請參見使用 WebServiceFaultActivity 活動。 |
|
|
接收來自 Web 服務的數據。 有關更多信息，請參見使用 WebServiceInputActivity 活動。 |
|
|
響應對工作流發出的 Web 服務請求。 有關更多信息，請參見使用 WebServiceOutputActivity 活動。 |
|
|
使工作流能夠在條件得到滿足之前進行循環。 有關更多信息，請參見使用 WhileActivity 活動。 |
3 服務概述
當工作流實例運行時，工作流運行時引擎使用多種服務。 Windows Workflow Foundation 提供可滿足多種應用程序需要的運行時服務的默認實現，例如在 SQL 數據庫中存儲工作流實例的執行詳細信息的持久性服務。 這些服務組件是可插入的，這樣，應用程序就可以以特定于執行環境的方式提供這些服務。運行時引擎使用的其他類型服務包括計劃服務、事務服務和跟蹤服務。
通過從基服務類派生可以創建自定義服務以擴展 Windows Workflow Foundation 平臺。使用 XML 文件而不使用數據庫進行存儲的持久性服務就屬于這種情況。
Windows Workflow Foundation 提供了多項服務，您的應用程序可以使用這些服務來執行以下操作：通過事務執行批處理工作、管理工作流實例的線程、將工作流實例保留到存儲介質中以在日后進行檢索，以及跟蹤工作流實例的執行情況。
Windows 工作流計劃服務
Windows 工作流計劃服務管理工作流運行時引擎計劃工作流實例的方式。 無論這些服務是通過 DefaultWorkflowSchedulerService 以異步方式處理的，還是通過 ManualWorkflowSchedulerService 以手動、同步的方式處理的，它們都是工作流解決方案的重要部分。
默認情況下，DefaultWorkflowSchedulerService 由工作流運行時引擎使用。它創建和管理在工作流運行時引擎上以異步方式運行工作流實例的線程。 等待運行的工作流存儲在 DefaultWorkflowSchedulerService 的內部隊列中。 當 DefaultWorkflowSchedulerService 要啟動工作流時，從 .NET Framework 線程池中獲取一個線程并使用此線程運行工作流。 MaxSimultaneousWorkflows 屬性確定調度程序服務同一時間允許的并發線程數。例如，如果限值為 4，則 DefaultWorkflowSchedulerService 將從 .NET Framework 線程池中最多獲取 4 個線程來執行工作流。如果已經運行 4 個工作流，則其他工作項（工作流）將放入隊列中，最終在線程可用時執行。 下圖演示 DefaultWorkflowSchedulerService 如何以異步方式執行工作流。
ManualWorkflowSchedulerService 提供了一個線程服務，該服務允許創建工作流實例的宿主應用程序指定用于運行工作流實例的 Thread。 使用此線程服務，宿主應用程序可在單個 Thread 上運行一個工作流實例（即處于同步模式）。 此模式將阻止宿主應用程序的執行，直到工作流實例進入空閑狀態。 隨后，只能通過使用此服務的 RunWorkflow 方法執行工作流實例。或者，可以通過將 useActiveTimers 構造函數參數設置為 true，在 .Net 計時器創建的線程上運行該工作流。如果此計時器過期，將在該計時器的線程（而不是宿主應用程序的線程）上執行該工作流。 此計時器作為 DelayActivity 活動來實現。
ManualWorkflowSchedulerService 通過重用一個線程（該線程發出 ASP.NET Web 請求以運行該工作流實例），對 ASP.NET 進程中生成的線程數進行控制。 這確保了工作流運行時中的活動線程數在任意時候都等于 ASP.NET 進程中的 Web 活動請求數。
ManualWorkflowSchedulerService 不會自動運行隊列中的工作流實例。宿主必須調用 RunWorkflow 來運行指定的工作流。
Windows 工作流 CommitWorkBatch 服務
Windows 工作流 CommitWorkBatch 服務的用途是啟用與提交工作批次相關的自定義邏輯（又稱作持久性點）。 當提交工作批次時，運行時將對當前 CommitWorkBatch 服務進行調用并傳遞委托，該委托可以對工作批次執行實際提交。運行時仍必須執行提交，但是它允許服務將自身插入到進程中，從而支持針對提交進程進行一些自定義。
DefaultWorkflowCommitWorkBatchService 服務的目的在于允許自定義邏輯提交工作批次（又稱作持久點）。當提交工作批次時，工作流運行時將對 DefaultWorkflowCommitWorkBatchService 服務進行調用并為其提供委托，調用該委托可以對工作批次執行實際提交。運行時仍必須執行提交；但是它允許該服務將自身插入到進程中，以便根據提交進程進行自定義。
DefaultWorkflowCommitWorkBatchService 服務唯一的真正要求是：在調用它的 CommitWorkBatch 方法時，如果不存在事務，則將創建一個事務。 如果事務不存在（當 Current 屬性返回 null 時會發生這種情況），DefaultWorkflowCommitWorkBatchService 必須在調用 CommitWorkBatchCallback 委托之前創建一個事務并設置環境事務。 這是通過用 TransactionScope 包裝委托調用來完成的。
使用此服務類型的主要目的在于啟用自定義的錯誤處理邏輯。 如果該事務由 DefaultWorkflowCommitWorkBatchService 服務擁有，那么，由于它會在 Current 返回 null（在 Visual Basic 中為 Nothing）時創建一個事務，因此它可以多次調用委托，并為每個調用創建一個新事務。 一個最常見的示例就是處理間歇性網絡問題或 SQL 群集故障轉移。 如果在調用 CommitWorkBatchCallback 時引發異常，則 WorkflowCommitWorkBatchService 可以捕獲此異常、啟動新事務并再次調用委托。 這為工作流實例執行提供了一定的彈性，否則將導致工作流終止。
注意:
如果當前的環境事務是由 WorkflowCommitWorkBatchService 服務創建的，則該服務只能重試提交。 如果在運行時調用 CommitWorkBatch 方法時已經存在環境事務，則意味著某個其他對象擁有該事務，并且可能已對它執行了某些工作。由于 DefaultWorkflowCommitWorkBatchService 服務不能重新生成外部工作，因此它重試提交無效。 TransactionScopeActivity 事務或者在調用 Unload 方法之前由宿主代碼創建的事務就是這樣的示例。
也可以選擇使用 SharedConnectionWorkflowCommitWorkBatchService 服務。 此服務用于在不同對象之間使用共享連接的數據庫事務。 若要在 WorkflowRuntime 實例中使用 SharedConnectionWorkflowCommitWorkBatchService 服務而不是 DefaultWorkflowCommitWorkBatchService 服務，請使用 AddService 方法，如下例所示。 SharedConnectionWorkflowCommitWorkBatchService 構造函數的參數是數據庫連接字符串。
注意:
如果 SharedConnectionWorkflowCommitWorkBatchService 服務所用的 SQL Server 已關閉（例如由于 SQL 群集故障轉移或間歇性網絡問題所致），則 SharedConnectionWorkflowCommitWorkBatchService 服務將重試提交過程至少 15 至 20 次，然后引發 ServicesExceptionNotHandled 事件。 但是，僅當 SharedConnectionWorkflowCommitWorkBatchService 服務的 EnableRetries 屬性設置為 true 時，才會發生此行為。
Windows 工作流持久性服務
許多業務流程都需要花很長時間才能完成（長達數月或甚至數年）。 將工作流保存在內存中不僅不切實際（由于內存限制的原因），而且，因為必須在單一服務器上處理實例，所以還會妨礙縮放。 許多這些長期運行的工作流都是執行不活躍的流程或過程邏輯，并且實際上處于空閑狀態，等待來自用戶或其他系統的輸入。通過卸載空閑的實例，主機應用程序將能夠節省內存，并且能夠跨處理服務器進行縮放。
當工作流運行的時候發生特定情況時，工作流運行時引擎就會使用持久性服務（如果在運行時加載了持久性服務）保留有關工作流實例的狀態信息。這些情況包括：
當完成 TransactionScopeActivity 活動和 CompensatableTransactionScopeActivity 活動中的原子事務時。
當工作流實例空閑，且對 WorkflowPersistenceService 將 UnloadOnIdle 標志設置為 true 時。 例如，在使用 DelayActivity 活動時會發生此情況。
當運行時主機應用程序對工作流實例調用 System.Workflow.Runtime.WorkflowInstance.Unload 或 System.Workflow.Runtime.WorkflowInstance.TryUnload 時。
當中止工作流實例或工作流實例結束時。
當使用 PersistOnCloseAttribute 屬性的自定義活動完成時。
如果滿足這些條件之一且將持久性服務添加到運行時引擎，則運行時引擎會調用由持久性服務提供的方法，以保存關于工作流實例的狀態信息。同樣，當工作流運行時引擎必須還原以前保留的工作流實例時，它調用由持久性服務提供的方法，以加載此狀態信息。 換句話說，工作流實例決定持久性發生的時間，但持久性服務決定是否執行必要的持久性操作。
由 SqlWorkflowPersistenceService 管理的工作流狀態的另一部分是計時器信息。 每當在您的工作流定義內配置 DelayActivity 活動，且使用類似 SqlWorkflowPersistenceService 的持久性服務時，與該活動相關的時間跨度信息會作為工作流狀態的一部分被保留下來。 每當由工作流運行時計算工作流實例時，都會處理掛起計時器事件。
創建持久性服務
可以通過從 WorkflowPersistenceService 類派生一個類來創建持久性服務。通過調用 AddService 或在應用程序配置文件中添加合適的項，可以將持久性服務添加到工作流運行時引擎。 Windows Workflow Foundation 提供了 SqlWorkflowPersistenceService 類，這是一種全新的持久性服務，可以按原樣使用或對其進行擴展。 有關創建自定義持久性服務的更多信息，請參見創建自定義持久性服務。有關使用 SqlWorkflowPersistenceService 類的更多信息，請參見使用 SqlWorkflowPersistenceService。
注意:
WorkflowRuntime 必須僅包含一個持久性服務。
鎖定工作流狀態信息
工作流運行時引擎具有鎖定工作流狀態信息的語義，當在其他進程中運行的持久性服務可能有權訪問單個數據存儲區時，可以使用該語義。使用 WorkflowPersistenceService 類，您可以通過以下方法支持工作流引擎的這一功能：向指定是否應該在存儲區解鎖工作流實例的狀態信息的 SaveWorkflowInstanceState 提供參數，以及提供解鎖以前鎖定的工作流狀態信息的 UnlockWorkflowInstanceState 方法。在實現鎖定的持久性服務中，對 LoadWorkflowInstanceState 的調用將鎖定工作流實例的狀態信息。
在創建自己的持久性服務時，如果該服務不將狀態信息保存到其數據存儲區或從其數據存儲區加載狀態信息，則引發 PersistenceException。 工作流運行時引擎需要此行為。
持久性服務批處理行為
為使用持久性存儲區來保存工作流狀態信息的服務提供了批處理機制。 在這種情況下，在持久性服務使用的持久性存儲區與工作流運行時引擎內部狀態之間保持一致十分重要。您可以將由 IPendingWork 接口定義的功能添加到服務，然后通過將數據存儲區更改作為工作項添加到 WorkBatch，來參與由 WorkflowCommitWorkBatchService 服務提供的工作流事務批處理。 有關更多信息，請參見 SaveCompletedContextActivity 或 SaveWorkflowInstanceState。
復雜的宿主情形
Windows Workflow Foundation 解決方案部署的一個可能的情形是創建多個主機應用程序，每個應用程序都有在不同的桌面和服務器配置上運行的一組不同的服務。在這種情形下，可能要求在解決方案中定義的一些工作流只能在特定的系統上執行。 Windows Workflow Foundation 中全新的服務（如 SqlWorkflowPersistenceService 服務）不支持這種配置。 若要控制在哪些系統上加載哪些工作流實例，必須創建自定義持久性服務。 有關更多信息，請參見創建自定義持久性服務。
Windows 工作流跟蹤服務
使用 Windows Workflow Foundation 可以以一致、可靠而靈活的方式跟蹤與工作流相關的信息。 Windows Workflow Foundation 跟蹤框架旨在使宿主通過捕獲工作流執行期間引發的事件，而在執行期間可以觀察到工作流實例。 此框架為可插入式設計，使宿主可以編寫自己的跟蹤服務，也可以使用現成可用的或第三方跟蹤服務。此外，由于使用 Windows Workflow Foundation 運行時引擎可以在其生存期過程中添加多個運行時服務，因此可以同時啟用多個不同類型的跟蹤服務。例如，Windows Workflow Foundation 包含一個現成可用的 SqlTrackingService 服務，此服務將數量可配置的跟蹤信息寫入 SQL Server 數據庫。 Windows Workflow Foundation 示例還包含一個示例 ConsoleTrackingService Sample，用于偵聽事件和這些事件向控制臺輸出的內容。 可以將這兩個服務一起運行，以使最終用戶可以查看工作流執行，并在開發過程中生成調試信息。
Windows Workflow Foundation 中的跟蹤功能
Windows Workflow Foundation 內置多種功能，使得在啟用工作流的應用程序中可以進行跟蹤。
|
|
功能 |
說明 |
|
|
|
|
確保以一致的方式進行跟蹤。 |
用戶和應用程序可以跟蹤工作流狀態以及實時工作流和已存檔到磁盤的工作流的歷史記錄。 跟蹤服務所采用的一致框架確保自定義跟蹤服務符合邏輯和連貫的模式。 |
|
|
|
|
提供可伸縮性和可靠性。 |
跟蹤框架屬于輕量級，足以部署在單臺計算機上，但與此同時，它也可以進行適當伸縮，以滿足大多數企業業務（如要求群集和分布式數據中心環境的那些業務）的要求。 |
|
|
|
|
無論基礎數據存儲區是什么，都使工作流數據可跟蹤。 |
對于管理跟蹤事件的數據存儲區，跟蹤框架為不可知。 最終用戶可以獲得用于跟蹤事件的定義完善的架構；但是，最終將由數據存儲區控制基礎持久性數據的架構。 |
|
|
|
|
提供一個位置以便跨宿主環境查詢與工作流相關的數據。 |
可在多個環境中承載 Windows Workflow Foundation；而應用程序要求接口保持一致，才能通過該接口查詢工作流信息。 |
|
|
|
用于查詢過去和現在的工作流生命周期，并確定工作流實例未來執行時所可能采用的路徑。 |
跟蹤框架提供一種發出工作流定義和與工作流關聯的元數據的方式，以實現指南類型查詢。 還提供一種發出數據狀態更改的方式，以便可以跟蹤用戶定義的狀態。 |
|||
|
支持以編程方式更改跟蹤配置文件。 |
可以使用跟蹤配置文件對象模型創建跟蹤配置文件。 這樣就可以在執行活動工作流的過程中根據需要加載自定義配置文件。 |
|||
跟蹤配置文件
跟蹤服務通過使用跟蹤配置文件篩選數據，從而確定接收的數據量。 跟蹤服務可以接收工作流事件、活動執行狀態和自定義用戶跟蹤數據項。工作流實例在運行的時候，跟蹤服務負責跟蹤其從運行時引擎接收的數據。 此服務可以在文件或數據庫中存儲數據、在內存中創建查詢存儲區、將數據寫入系統事件日志或僅僅將跟蹤數據輸出到控制臺。
可以使用跟蹤配置文件 XML 架構以聲明方式創作跟蹤配置文件，也可以使用跟蹤配置文件對象模型以編程方式進行創作。 此外，還可以使用 TrackingProfileSerializer API 將 XML 格式的跟蹤配置文件反序列化為 TrackingProfile 實例。
有關跟蹤配置文件的更多信息，請參見創建和使用跟蹤配置文件。
跟蹤事件類型
使用 Windows Workflow Foundation 中的跟蹤時，可以跟蹤工作流執行過程中所引發的單個事件或事件組。 ActivityExecutionStatus 枚舉中定義了對于活動可以跟蹤的事件：
· Initialized
· Executing
· Canceling
· Closed
· Compensating
· Faulting
除了跟蹤活動的事件之外，使用跟蹤基礎結構還可以跟蹤工作流實例級別發生的事件。 TrackingWorkflowEvent 枚舉中定義了可以跟蹤的實例級別事件：
· Created
· Completed
· Idle
· Suspended
· Resumed
· Persisted
· Unloaded
· Loaded
· Exception
· Terminated
· Aborted
· Changed
· Started
有關跟蹤單個事件的信息，請參見創建和使用跟蹤配置文件。
顯式代碼級別跟蹤
生成工作流和任務的開發人員可能要以顯式跟蹤事件來檢測其代碼。 只有在跟蹤配置文件無法用于為所需的跟蹤事件檢測運行時的情況下才應該這樣做。
工作流創作者可以對 ActivityExecutionContext 使用 TrackData 重載方法之一來跟蹤任何類型的信息。 對用戶跟蹤點的數量沒有限制，而對可以從跟蹤方法發出的數據類型也沒有限制。 在 SqlTrackingService 實現中，如果傳入 TrackData 方法的第二個參數的對象不能進行二進制序列化，則所保存的數據是調用該對象 ToString 方法所得的結果。
跟蹤僅標記工作流
借助于僅工作流標記的工作流和 Windows Workflow Foundation 跟蹤功能，您可以使用常規跟蹤配置文件，也可以在啟動每個工作流實例之前對此實例使用 ReloadTrackingProfiles（如果要從此實例跟蹤特定的事件/項）。如果決定使用 ReloadTrackingProfiles，則必須為 XML BLOB 創建工作流實例、獲取實例 GUID、生成特定于該實例的跟蹤配置文件，然后讓實例重新加載其配置文件。調用含有實例 ID 的 GetProfile 時，跟蹤服務應將此配置文件返回到工作流運行時引擎。 這是實例與配置文件之間發生關聯的地方。
跟蹤規則
執行 RuleSet 時，將向在宿主上配置的跟蹤服務發送跟蹤事件，這些宿主已通過向其跟蹤配置文件添加 UserTrackPoint 注冊了這些事件。 將發送 RuleActionTrackingEvent，其中提供了已計算的規則的名稱以及條件計算結果 (true/false)。 有關更多信息，請參見 RuleActionTrackingEvent Sample。
通過跟蹤活動執行情況，可以隱式地跟蹤活動上的規則條件的計算結果。
自定義跟蹤服務
Windows Workflow Foundation 包含 SqlTrackingService 服務，該服務可用于跟蹤存儲在 SQL Server 數據庫中的數據。但是，由于 Windows Workflow Foundation 使用了擴展性模型，因此可以創建使用如本地文件等各種存儲介質的自定義跟蹤服務，這是因為運行時引擎不關心數據的最終目標或交付格式。有關如何創建自定義跟蹤服務的更多信息，請參見創建自定義跟蹤服務。
4 補償概述
補償是由于工作流中其他位置發生異常而做出的一種行為，這種行為撤消由成功完成的可補償活動所執行的任何操作。
已完成事務的 Windows Workflow Foundation 補償模型是一個處理工作流中發生的任何業務異常并合乎邏輯地撤消已完成事務的過程。
Windows Workflow Foundation 補償可以是：
未指定異常處理程序或未處理特定異常時，默認為隱式。
使用 CompensateActivity 活動時為顯式。
5 本地通信和關聯概述
宿主進程可以通過經由自定義本地通信服務交換數據來與工作流進行通信。 這些本地通信服務實現了一些用戶定義的接口，這些接口定義了將在工作流和宿主進程之間進行傳遞的方法和事件。
通過使用在宿主進程和工作流之間作為事件參數傳遞的唯一 ID，宿主進程還可以在特定的工作流實例中與特定的活動進行交互。 這稱為“關聯”。
Windows Workflow Foundation 支持工作流的承載環境中的本地通信服務和 Web 服務通信。
Windows Workflow Foundation 通信服務使工作流能夠使用方法和事件通過消息與外部系統交互。 事件用于將數據發送到工作流，而工作流使用方法將數據發送到主機應用程序。 通過事件與工作流進行通信的功能提供了一種將數據發送到工作流的異步方式。
在工作流中使用本地服務
Windows Workflow Foundation 工作流通信服務向工作流編寫器公開用戶定義的服務類，作為方法調用和事件處理程序，以簡化出站和入站消息交換的建模。 單個服務類實例到多個工作流實例的多路復用允許主機編寫器對出站消息的單個位置進行編程，而引發事件時仍針對特定工作流實例。
下圖演示本地通信服務如何與其主機應用程序通信。
工作流實例上的 HandleExternalEventActivity 和 CallExternalMethodActivity 活動與在自定義接口中聲明并在自定義本地服務中實現的事件和方法交互。 HandleExternalEventActivity 活動響應由主機應用程序引發且由本地服務實現的特定事件。 CallExternalMethodActivity 對本地服務調用方法。
工作流通信服務
Windows Workflow Foundation 工作流通信服務實現一種供對象與工作流實例通信的簡單機制。通信通道的定義是一個接口，其實現是添加到運行時以方便通信的服務類。對于服務類，工作流的行為很像任何其他類，您通過引發事件和接收方法調用與其通信。 對于工作流，通信接口顯示為包含入站事件接收和出站操作方法調用的通道。ExternalDataExchangeService 將接口上的外部方法聲明轉換為服務對象上的方法調用。 我們可以視為本地服務的類能夠引發事件，工作流運行時引擎截獲這些事件并將其作為工作流的入站消息加以傳送。
下面的代碼示例演示如何定義本地工作流通信接口的示例。
[ExternalDataExchange]
public interface ICommunicationService
{
void HelloHost(string message);
event EventHandler<ExternalDataEventArgs> HelloWorkflow;
}
服務類
服務類實現用于定義與工作流進行通信的接口。 接口上的所有事件都是單向的，也就是說，這些事件沒有 ref 或 out 參數，并且沒有返回值。 但是，對于傳出請求，接口上的方法可以具有 ref 和 out 參數，并且有返回值。
通信模型為多對一：有很多工作流實例，每個實例可以使用此單一實例服務對象在很多會話上傳遞。這意味著對所有工作流中的特定方法 m 的所有出站調用由同一個對象上的同一個 m 提供服務。相反，所有入站調用必須顯式定向到正確的工作流實例和會話。 Windows Workflow Foundation 為 m 提供一種機制以區別出站調用的工作流實例和會話。 使用這兩段信息，對象可以將響應定向回正確的工作流實例上的正確的會話。
Windows Workflow Foundation 在出站調用線程上的 System.Workflow.Runtime.WorkflowEnvironment.WorkflowInstanceId 中提供調用工作流的實例標識符。
下 面的代碼示例演示通信服務實現。
public class CommunicationService : ICommunicationService
{
public event EventHandler<ExternalDataEventArgs> HelloWorkflow;
public void HelloHost(string message)
{
Console.WriteLine("This is the message: {0}", message);
// Raise the HelloWorkflow event.
HelloWorkflow(null, new ExternalDataEventArgs(WorkflowEnvironment.WorkflowInstanceId));
}
}
您啟動工作流的實例之前，必須將 ExternalDataExchangeService 添加到工作流運行時引擎，然后將自定義通信服務添加到 ExternalDataExchangeService，如下面的代碼示例所示。
ExternalDataExchangeService externalService = new ExternalDataExchangeService();
workflowRuntime.AddService(externalService);
externalService.AddService(new CommunicationService());
在工作流中使用關聯
Windows Workflow Foundation 運行時引擎使用關聯將入站消息映射到某個工作流實例中的特定 HandleExternalEventActivity 活動。 對實例的映射是在將工作流實例 InstanceId 傳遞到 ExternalDataEventArgs 構造函數時完成的。通過使用接口屬性來定義關聯。 Windows Workflow Foundation 工作流通信服務接口可以為關聯指定附加的元數據。 關聯某個工作流實例的事件活動時需要此關聯數據。 關聯元數據規范采用接口屬性的形式，即 CorrelationParameterAttribute 屬性。
注意:
為通信接口提供關聯屬性是可選的。 默認情況下，通信接口都是無關聯的。 用戶只有在需要使用關聯將消息傳遞給特定活動實例時才應添加關聯屬性。
接口屬性
下表描述在可供 Windows Workflow Foundation 工作流通信服務使用的接口定義中可以使用的接口屬性全集。
|
屬性 |
說明 |
|
用于指定在接口中定義的方法和事件的用于關聯的參數名稱。 如果方法或事件包含一個與該名稱匹配的形參，則該參數定義該方法或事件上的相關值。 如果方法或事件沒有此類參數，則方法或事件可以使用 CorrelationAliasAttribute 來定義相關值的位置。 此屬性在一個接口中可以出現多次。 |
|
|
用于在方法或事件中指示相關參數的值是在調用該方法或引發該事件時初始化的。 對于給定的 CorrelationToken，必須在對話中的任何其他方法或事件執行之前調用或接收初始值設定項方法或事件。 任何可以初始化新對話（即新的相關令牌）的方法或事件都必須使用此屬性進行標記。 對于每個相關令牌，方法或事件必須包含一個適當的命名參數或一個 CorrelationAliasAttribute。 |
|
|
在方法或事件定義中用來重寫該成員的 CorrelationParameter 設置。 CorrelationAliasAttribute 屬性指定可用參數中可以獲得相關值的位置。 該字符串參數是針對形參集的以點分隔的路徑。 該參數指示在何處可以找到匹配數據值。 如果定義了多個相關令牌，還必須指定令牌 Name 命名參數。 |
使用相關屬性
CorrelationParameterAttribute 命名對話標識符和關聯。 然后，使用該名稱的形參對接口上的每個方法或事件進行聲明（例如 id），如下面的 ITaskService 接口代碼示例所示。 也可以使用其他屬性來說明更復雜的相關映射。 當實例和相關信息已為某個對話所了解時，該類將引發其本地服務事件。它在調用上的參數數據中指定關聯。
下面的代碼演示與接口定義相關的工作流通信服務 ITaskService。
[Serializable]
public class TaskEventArgs : ExternalDataEventArgs
{
private string id;
public TaskEventArgs(Guid instanceId,string id)
:base(instanceId)
{
this.id = id;
}
public string Id
{
get { return id; }
set { id = value; }
}
}
[ExternalDataExchange]
[CorrelationParameter("taskId")]
public interface ITaskService
{
[CorrelationInitializer]
void CreateTask(string taskId, string assignee, string text);
[CorrelationAlias("taskId", "e.Id")]
event EventHandler<TaskEventArgs> TaskCompleted;
}
任何啟動新對話的操作、方法或事件必須具有 CorrelationInitializerAttribute 屬性。 如果發生對 CorrelationInitializerAttribute 方法 m 的調用，則服務類能了解該調用正在初始化新對話。 工作流對話生存期由相關引用的生存期指示。 工作流可以在對話之間卸載或加載。
下面的代碼示例演示實現 ITaskService 的服務類。
public class TaskService : ITaskService
{
public void CreateTask(string taskId, string assignee, string text)
{
Console.WriteLine("task " + taskId + " created for " + assignee);
}
public void RaiseEvent(TaskEventArgs args)
{
if (TaskCompleted != null)
TaskCompleted(null, args);
}
public event EventHandler<TaskEventArgs> TaskCompleted;
}
6 持久性概述
Windows Workflow Foundation 簡化了有狀態的、長期運行的持久性工作流應用程序的創建過程。 工作流運行時引擎管理工作流的執行情況，而且允許工作流長期保持活動狀態并在應用程序重新啟動之后存在。這種持久性是 Windows Workflow Foundation 的關鍵原則。 它意味著可以在等待輸入時從內存中卸載工作流，而且工作流可以序列化為持久性存儲（如 SQL 數據庫或 XML 文件）。 只要收到了輸入，工作流運行時引擎就會將工作流狀態信息重新加載到內存中并繼續執行工作流。
Windows Workflow Foundation 提供的 SqlWorkflowPersistenceService 可以與 Microsoft SQL Server 2005 Express、SQL Server 2000（或更高版本）或 SQL Server 2000 Desktop Engine (MSDE) 很好地集成，以便方便而又高效地保持工作流信息。 您還可以通過從 WorkflowPersistenceService 基類派生來創建自己的持久性服務，以便按照所需的方式存儲工作流狀態信息。
7 跟蹤概述
“跟蹤”是一項功能，用于指定并捕獲有關工作流實例的信息，并在這些實例執行時存儲該信息。 Windows Workflow Foundation 提供了 SqlTrackingService 這一跟蹤服務，該服務使用 SQL 數據庫來存儲所收集的跟蹤信息。您也可以編寫自己的跟蹤服務來收集該信息，并以您應用程序需要的任何格式將其存儲下來。
創建新工作流時，該跟蹤服務會請求一個要與該工作流相關聯的跟蹤通道。 之后，會將該工作流中的所有跟蹤信息發送到該跟蹤通道。
該跟蹤服務可以跟蹤三種類型的事件：工作流實例事件、活動事件和用戶事件。 通過提供跟蹤配置文件，您可以配置您的服務要為特定工作流實例或特定類型的工作流接收的信息類型和數量。
跟蹤框架還能夠在事件期間提取與活動或工作流相關的信息。 如果需要跟蹤活動或工作流中的特定屬性或字段，您可以在跟蹤配置文件的提取節中提供此信息，將在指定事件期間提取該信息。
8 序列化概述
對工作流、活動和規則可以進行序列化和反序列化。 這樣就可以保持它們，在工作流標記文件中使用它們，以及在工作流設計器中查看其屬性、字段和事件。
Windows Workflow Foundation 為標準活動提供了默認的序列化功能，您也可以為自定義活動創建自己的序列化功能。例如，利用自定義活動序列化程序，可以決定對哪些成員進行序列化以及如何對其進行序列化。 這也將確定這些成員在工作流設計器中是可見還是隱藏。
9 工作流更改概述
使用 Windows Workflow Foundation，可以在運行時動態更新工作流實例和聲明性規則。在計劃待執行的活動之前，可以更改預期行為、流控制等。 使用該功能，可以修改業務處理邏輯，且不必重新編譯和重新啟動工作流。
10 “規則和條件”概述
Windows Workflow Foundation 可將業務邏輯作為規則或條件來實現。 IfElseBranchActivity、ConditionedActivityGroup、WhileActivity 和 ReplicatorActivity 活動使用條件來控制活動的執行。 條件可以聲明方式表示，也可以在代碼中定義。 聲明性條件以代碼 DOM 語句的形式在規則的 XML 文件中創建。 基于代碼的條件可引用工作流的代碼文件中的一個方法，該方法通過 Result 屬性返回其結果。
與條件一樣，規則以代碼 DOM 語句的形式表示，并收集到規則的 XML 文件中。 規則包含一個條件語句和一些操作集合，這些集合中的操作是根據條件的結果來執行的。規則將會收集到規則集中，規則集既支持規則的簡單依序執行，也支持規則的復雜正向鏈接。 規則集由 PolicyActivity 活動執行。
使用規則和聲明性條件定義邏輯的一個主要優點是，通過使用工作流更改來執行動態更新，可在運行時修改這些規則和聲明性條件。 此外，規則使您可將業務邏輯與工作流分開，以便與其他工作流共享這些規則。最后，通過在規則中定義業務邏輯，可在對象模型之上構建高級工具，如依賴關系可視化工具和影響分析工具。
11 錯誤處理概述
工作流運行時引擎在一個稱為“錯誤處理”的進程中異步處理活動中所出現的異常。 異常被安排在隊列中以便日后處理。 如果異常類型與特定 FaultHandlerActivity 活動所處理的類型相符，則該活動將處理此異常。 如果無法處理異常，則通過父活動向上冒泡，直到最終導致工作流實例終止。
Windows Workflow Foundation 中的錯誤處理指的是以異步方式處理異常。這意味著工作流運行時引擎會捕獲在活動中（顯式或隱式）引發的異常，然后將其安排在隊列中以便以后處理。 這與常規異常處理不同，因為在常規異常處理中，如果異常是在 try 塊中引發的，則它可以由相應的 catch exception 塊捕獲，也可以立即對用戶引發。
異常的原因
在工作流中，異常可能通過下列方式生成：
TransactionScopeActivity 或 CompensatableTransactionScopeActivity 中的事務超時。
工作流通過使用 ThrowActivity 活動引發的顯式異常。 有關更多信息，請參見使用 ThrowActivity 活動。
從代碼活動的處理程序或自定義活動的代碼旁置引發的 .NET Framework 異常。
從庫或在工作流中使用的組件等外部代碼引發的異常。
捕獲異常
在錯誤處理中，如果引發異常的活動不能處理異常，則該異常將被傳輸到其父活動以進行解決。 在處理異常或工作流運行時引擎終止工作流實例之前，該異常將被傳輸到工作流層次結構中。
異常由 FaultHandlerActivity 活動來處理。 每個 FaultHandlerActivity 活動都與 .NET Framework 異常類型相關聯，并且如果引發的異常與該異常類型匹配，則該活動還包含一組所執行的活動。 FaultHandlerActivity 活動是包含 0-n 個 FaultHandlerActivity 活動的 FaultHandlersActivity 活動的父級。 FaultHandlersActivity 可以是任何復合活動的子活動。
Windows Workflow Foundation 中錯誤處理的目標是撤消已發生異常的活動的部分工作及不成功的工作。 FaultHandlerActivity 活動的完成從不被視為其相關活動的成功完成。 這意味著，當執行 FaultHandlerActivity 活動時，引發異常的活動被置于錯誤狀態。當 FaultHandlerActivity 活動完成時，相關聯的活動被置于關閉狀態。 此外，相關聯活動的任何同級活動（如 ParallelActivity 活動的其他子級）被置于取消狀態，然后置于關閉狀態。它們永遠不會成功執行。
錯誤處理與補償
錯誤處理與補償之間的區別是，補償只能對已成功完成的活動執行，不能對引發異常和處于錯誤狀態的活動執行；但是，在與引發異常的活動相關聯的 FaultHandlerActivity 活動內可以執行 CompensateActivity 活動。 例如，補償處理的典型情形是，一項活動成功完成，但在工作流后面的另一活動中引發異常。該活動的錯誤處理程序包含一個 CompensateActivity，后者可撤消在工作流中以前完成的任何操作。 若要對此進行進一步擴展，您可能要在工作流后面由另一活動引發 ItemDiscontinuedException 之后向客戶退款。
12 工作流標記概述
基于可擴展應用程序標記語言 (XAML) 的工作流標記可以使開發人員和設計人員以聲明方式為業務邏輯建模，并將其與由代碼旁置文件建模的低級實現細節區分開。因為工作流可以聲明方式建模，所以可以在運行時，通過直接將工作流標記文件加載到工作流運行時引擎的方式來激活工作流。
posted on 2008-12-09 15:47 mjgforever 閱讀(2263) 評論(2) 收藏 舉報
浙公網安備 33010602011771號