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