開發人員越來越多地采用面向服務的體系結構 (SOA) 作為構建分布式應用程序的方式。對於缺乏經驗的人，設計和實現面向服務的分布式應用程序可能會令人生畏。然而，Microsoft .NET Framework 4 使得使用 Windows Workflow Foundation (WF) 實現 Windows Communication Foundation (WCF) 服務變得比以往任何時候都更簡單。
WCF 工作流服務為編寫長時間運行、持久的操作或服務（其中通過排列操作的順序強制實施應用程序協議十分重要）提供了一個高效的環境。工作流服務是通過使用可利用 WCF 發送和接收數據的 WF 活動來實現的。
在本文中，我將說明如何組合 .NET Framework 4 中引入的 WCF 和 WF 的許多功能，以在不編寫代碼的情況下，建模一個用於房地產公司的長時間運行、持久且經過檢測的抵押審批流程。本文的意圖既非概括介紹 WCF 或 WF，也非逐步向您介紹創建工作解決方案的整個流程。我打算通過實際業務應用場景重點介紹新的重要 .NET Framework 4 功能的使用。本文的代碼下載中包含一個完整的工作解決方案。
應用場景
首先，讓我們概要介紹一下圍繞其構建工作流應用程序的應用場景。Contoso Housing 是一家銷售普通住宅和高級公寓的房地產公司。為提供更優質的客戶服務和端到端購買體驗，Contoso 與幫助潛在客戶解決其抵押需要的三家抵押公司合作。每家抵押公司提供不同的利率。Contoso 按照抵押供應商的利率對其進行優先級排序，以確保客戶獲得最佳交易（采用更好的利率使房屋銷售出去的可能性更大這一假設）。
客戶通過 Web 應用程序提供其抵押請求數據。每個客戶輸入一個客戶 ID、房屋價格、首付金額、貸款期限（年）、工資信息以及某些背景核實信息。
申請工作流的第一步（參見圖 1）使用客戶輸入的數據篩選客戶並確定是否具備資格，然後將請求發送至抵押供應商。
圖 1 抵押審批流程
申請遵循以下規則：
如果申請人被取消贖回權、破產或正處於訴訟中，申請將被拒絕。
如果申請人沒有信貸記錄且提供低於 20% 的首付款，則會將申請返回進行修改（申請不恰當），但不是被拒絕。客戶必須提供至少 20% 的首付款才能繼續。
如果上述情況均不適用，將批准申請。
Contoso 根據其提出抵押請求的首選順序與抵押供應商聯系。如果抵押供應商拒絕申請人，則詢問下一個。所有供應商均實施標准的抵押審批請求服務約定。在審批流程的此階段期間，客戶應該能夠查詢其請求的狀態。
在抵押申請解決後（一個供應商接受或全部拒絕），通過 CRM 系統提供的一項服務將客戶交互記錄到 Contoso 的客戶關系管理 (CRM) 系統中。然後，將結果返回給客戶。
請注意，圖 1 中顯示的抵押審批流程概括介紹了業務流程，但並未說明如何實施。工作流服務將是對此流程的實施。
創建聲明性服務
工作流服務將從客戶那裡接收數據，進行初步篩選，協調與抵押供應商的溝通，將交互登記到 CRM 服務中並將結果提供給客戶。
該服務將是長時間運行的（可能需要幾天或幾個月才能完成）、持久的（可以先保存狀態，稍後重新開始）且經過檢測的（開發人員和用戶均能夠在無需調試服務的情況下了解正在執行的作業）。通過使用 WCF 和 WF，您可以在不編寫任何代碼的情況下以聲明方式全部實現這些目標，您只需組裝和配置 .NET Framework 提供的組件。圖 2 顯示了解決方案的體系結構圖。
圖 2 解決方案的體系結構
WCF 工作流服務包含在定義工作流的 .xamlx 文件中。您可以使用 WF 設計器以可視化方式定義業務流程，服務約定可基於工作流的結構進行推斷。
要在 Visual Studio 2010 中創建工作流服務，請創建一個新項目，然後選擇“WCF 工作流服務應用程序”模板。此項目模板會使用 Receive 和 SendReply 活動創建一個十分簡單（但運行）的工作流。這類似於一個具有接收整數並返回一個字符串的方法的類。您可以通過向其中添加更多活動來擴展工作流。這些活動可能會添加執行邏輯或服務操作。
要定義服務約定，可使用 WF 提供的消息傳送活動。服務的配置存儲在 web.config 文件中，就像在常規 WCF 服務中一樣。如果打開 web.config，您將會看到一個非常干淨的配置文件，因為 WCF 工作流服務利用了 WCF 4 中引入的服務配置增強功能。
消息傳送活動以無縫方式將 WF 和 WCF 結合起來。它們設計用於支持面向消息的工作流並且更好地將消息傳送集成到工作流中。借助消息傳送活動，工作流能夠將數據發送到外部其他系統（Send、 SendReply 和 SendAndReceiveReply），以及從其他系統接收數據（Receive、ReceiveReply 和 ReceiveAndSendReply）。它們還包括用於處理關聯（InitializeCorrelation、CorrelationScope）和事務 (TransactedReceiveScope) 的活動。
Receive 和 Send 活動允許在工作流內為消息傳送交互建模。服務中的約定可通過在其中配置 Receive 和 Send 活動來定義。每個 Receive 活動以操作形式公開。每個 Send 活動會將消息發送到服務。目標服務無需利用 WCF，甚至是 .NET Framework，因為您是通過標准協議與其進行交互。
Receive 和 Send 活動可配置為使用基於消息或基於參數 (RPC) 的方法接收和發送實際數據。這會控制發送或接收數據的傳輸格式。
采用流程圖描述流程
您可以使用 Sequence 建模流程，但是快速浏覽圖 1 表明，有時流程需要返回上一步，而順序工作流中並不直接支持這一操作。（需要手動使用諸如具有認真建模條件的 While 活動的構造建模循環。）Flowchart 更加適合於對此應用場景進行建模。
Flowchart 是在 WF 4 中引入的新控制流活動，使您能夠像在白板上一樣描述您的流程。Flowchart 描述的流程實際上是按順序組織的，具有單一執行路徑，在某些情況下可能需要返回上一步。為了描述流程，Flowchart 使用箭頭和方框（許多領域中的常用方法）。
“WCF 工作流服務”項目模板創建的默認工作流是一個 Sequence，但這並不意味著您只能在工作流服務中使用控制流活動。要在服務中使用 Flowchart（或任何其他復合活動）作為根活動，只需刪除 Sequence，然後添加一個 Flowchart。
從圖 3 可以看出，輕輕松松即可從圖表（企業用戶通常草擬該圖表以描述流程）創建一個 Flowchart。
圖 3 作為一個 Flowchart 的抵押審批流程
Flowchart 是一個描述業務流程的強大工具，最大程度降低了可執行流程與其指定方式之間的不匹配性。在這種情況下，Flowchart 定義為 流程的文檔。
讓我們將速度減慢一些。我們已經立即從空 Flowchart 跳至一個完整的 Flowchart。我們返回到空 Flowchart，開始研究它。
潛在購房者通過 Web 應用程序引入其數據。此數據通過 Receive 活動被傳遞給工作流。在 Flowchart 中包括 Receive 活動的結果是 WorkflowServiceHost 會公開一個端點，其允許用戶通過向工作流發送消息與工作流進行通信。
正如我前面所述，您可以將 Send 和 Receive 活動配置為使用基於消息或基於 RPC 的方法。在本例中，我將 Receive 活動配置為使用基於 RPC 的方法。這表示它會接收一組輸入參數，類似於方法調用。要使這些參數可用於工作流，我需要創建變量並將它們綁定到參數（參見圖 4）。另一種可行的方法是具有一個折疊所有這些字段的 DataContract。
圖 4 配置輸入參數
如果您希望在收到消息後創建並啟動一個新的工作流實例，您需要將 Receive 活動中的 CanCreateInstance 屬性設置為 true。這意味著當 WorkflowServiceHost 從此端點收到消息後將創建一個新實例。
使用 WF 組合建模篩選步驟
在工作流中擁有數據後，您便可以開始處理數據。第一步是進行篩選，表示驗證一組條件以便確定申請人是否符合抵押條件，然後再與供應商聯系。
一種方法是向主 Flowchart 中添加許多判斷形狀 (FlowDecision)。盡管該方法行之有效，但會使整個流程難以理解。此外，對篩選規則進行任何修改都需要更新主流程。Flowchart 似乎非常適合於以可視化方式表達條件，但是我們希望精簡主流程。
解決方案就是在現有 Flowchart 內添加一個新的 Flowchart。WF 4 在本質上為組合提供強大支持，因此可自由地組合活動。這意味著您可以在需要的地方添加一個新的 Flowchart，包括在現有 Flowchart 內。此外，組合是隨意進行的並且不會施加任何限制。您可以在方便時組合現有活動。
子流程圖顯示折疊在父流程圖內（Flowchart 設計器不支持就地展開）。您需要雙擊流程圖以建模篩選邏輯。篩選 Flowchart（參見圖 5）是主 Flowchart 的一個子項，可訪問其變量和參數。
圖 5 添加篩選流程圖
如果要編寫一些代碼，該怎麼辦？當然，您可以編寫代碼以描述篩選流程。例如，在本例中，您可以編寫一個 CodeActivity，以從客戶那裡接收數據作為輸入，執行驗證（一組采用所選語言的鏈接 if 語句）並返回結果。這有其自身的利弊。它可能會提供更好的性能（所有驗證均在一輪執行操作中執行），以及提供比聲明性方法更加簡明的表述。另一方面，您會失去流程的可視表示形式（不透明性），而且更改流程需要修改代碼和重新編譯。
將結果發送給客戶
當篩選驗證完成後，我需要將結果返回給申請人。我在工作流開始時通過 Receive 活動收到申請人的數據。我使用 SendReply 活動返回答復（通過右鍵單擊“Receive”並選擇“Create SendReply”可以為現有 Receive 創建一個 SendReply）。Receive 和 SendReply 的組合允許實現請求-響應消息交換模式。SendReply 配置為將操作的結果和一條說明消息返回給客戶。
為什麼選擇使用 SendReply 而不使用 Send？您可以使用一對 Receive 和 Send 活動建模雙向消息交換模式，如“請求並等待響應”（類似於回調），但 SendReply 更適合於建模請求-響應消息交換模式（類似於方法調用）。
確定接下來要執行的操作
完成篩選後，工作流可以繼續執行抵押申請流程。此時，有兩個分支：Reject 和 Approved，但是當申請人需要提供更多數據時，工作流必須返回上一步。Flowchart 允許將這一畫一條直線 操作建模到工作流將繼續的步驟。
我使用 FlowSwitch 活動（類似於 switch 語句）確定基於篩選結果要采用的路徑（如圖 6 所示）。
圖 6 FlowSwitch 中的每個出站箭頭代表 Switch 中的一個用例
關聯
當抵押請求被視為不正確時，工作流會要求客戶向現有工作流實例提供其他信息。Receive 活動怎樣才能知道其接收的數據是客戶先前所提供數據的更正？換句話說，您怎樣才能將另一條消息發送給正在運行的工作流實例？答案是關聯。
WF 4 為關聯引入一個框架。關聯實際上是以下兩種方法之一：
一種將消息分組到一起的方法。一個典型的示例是 WCF 中的會話，甚至只是請求消息與其答復之間的關系。
一種將一段數據映射到工作流服務實例的方法。
.NET Framework 4 中提供了許多類型的關聯，我在本示例工作流中使用基於內容的關聯。基於內容的關聯從傳入消息獲取數據，然後將其映射到現有實例。當工作流服務具有多個從單一客戶端訪問的方法，且交換的消息中的一段數據標識所需實例時，使用基於內容的關聯。
為了設置關聯，我聲明了一個 CorrelationHandle 類型的變量。這是用於存儲關聯信息的句柄（配套解決方案中的 customerCorrelationHandle）。下一步是使用關聯句柄。Receive 活動的屬性網格具有一個 Correlations 部分，用於配置關聯。其具有的屬性可用於配置關聯句柄 (CorrelatesWith)，指定您通過關聯查詢關聯的數據 (CorrelatesOn) 以及初始化關聯處理程序 (CorrelationInitializers)。我在 Receive 活動中配置了 CorrelatesWith 和 CorrelatesOn 參數，以關聯 customerCode 字段。
CorrelatesOn 和 CorrelatesWith 可能會造成混淆。下面的規則可幫助您進行區分：Receive CorrelatesWith 是一個現有關聯句柄，CorrelatesOn 是由關聯查詢指定的數據。
所有這些參數均可使用 WF 設計器進行設置。
我希望關聯客戶標識，因此我創建了一個從消息中提取 customerCode 的關聯查詢。請注意，關聯查詢是使用 XPath 編寫的，但是您無需了解 XPath，因為 WF 設計器會通過為您檢查收到的消息的約定創建查詢。
工作流中的第一個 Receive 活動配置為在收到消息時創建新的工作流實例。然而，當我回退到該 Receive 活動時，它不會創建新實例，因為它還配置為關聯 customerCode。在創建新實例之前，它會使用該關聯鍵查找現有實例。
向供應商詢問利率
如果申請通過篩選，則會將其發送給供應商進行評估。請注意，Contoso 與三家供應商合作，並且具有與他們開展業務的首選順序。因此，流程會按順序詢問供應商，直到有一家供應商批准。
所有供應商均實施標准的抵押審批請求服務約定。向三家抵押供應商請求利率之間的唯一區別是服務的 URI。然而，由於供應商利率請求涉及發送消息和異步等待響應，同時同步響應客戶請求的狀態，因此使其變得復雜。
我可以將此流程建模一次，然後在工作流中復制三次，但是這會導致許多不必要的重復，從而導致嚴重的可維護性問題。我希望精簡此步驟，因此我可以多次使用同一流程。理想情況下，我將為工作流提供相同的輸入數據，並在操作完成後獲取結果，這正是自定義活動的作用。
WF 4 提供以下兩種方法用來創建自定義活動：
聲明性通過組合其他現有活動來創建新活動。
命令性通過編寫代碼創建新活動。可派生許多具有不同功能的基類，包括 CodeActivity（簡單的命令性行為）、AsyncCodeActivity（異步執行操作）和 NativeActivity（與 WF 運行時交互）。
活動的參數在活動可接收的數據 (InArgument) 以及在它們完成後將返回的數據 (OutArgument) 方面定義其公開簽名。我的活動將接收客戶抵押信息和服務 URI 作為輸入，將返回利率和結果字符串消息。
我在 Visual Studio 中使用“活動”項模板以利用 WF 設計器以聲明方式創建新活動。設計器允許您通過拖放現有活動並設置其參數來以可視化方式編寫自定義活動。使用設計器編寫自定義活動的結果是一個定義 x:Class 的 XAML 文件。
我將此活動稱為“AskVendor”。AskVendor 活動從客戶那裡接收抵押信息和服務的 URI 作為輸入，並提供利率和結果字符串消息作為輸出。如果利率為 0，則表示申請已被拒絕。
AskVendor 向抵押供應商發送一條消息詢問利率，然後等待供應商的響應。此響應可能需要幾分鐘、幾小時甚至幾天才能到達。在等待響應的同時，申請人可能想了解流程的狀態。因此，活動還可以響應來自申請人的狀態請求消息。
為了同時處理這兩項操作，我使用一個 Parallel 活動作為自定義活動的根。在一個分支中，我具有所有用於與抵押供應商進行通信的活動，在另一個分支中，具有用於偵聽客戶同時等待供應商的響應的活動。 AskVendor 內使用的所有消息傳送活動均配置為關聯 customerCode 字段。圖 7 顯示了 AskVendor 自定義活動。
圖 7 AskVendor 自定義活動
正如我所述，自定義活動的根為 Parallel。左側分支向供應商發送消息並等待響應。收到響應後，它會設置結果字符串消息的格式並將完成的標記設置為 true。右側分支偵聽來自申請人的狀態查詢請求。Receive 和 SendReply 均處於 While 活動內，該活動在完成標記設置為 true 之後才執行。Parallel 活動的完成狀態（在某個分支完成後執行）將完成標記設置為 true。因此，當左側分支完成（收到來自供應商的消息）後，完成變量標記為 true 且右側的 While 也完成。
自定義活動幾乎與任何其他活動一樣。當您創建一個自定義活動時，它會自動顯示在活動工具箱中。而且使用它與使用任何其他現有活動沒有任何區別：將其從工具箱拖放到設計器中，然後配置其參數。因為我沒有為此活動創建設計器，因此為其分配了默認設計器（一個矩形，您可以在其中設置 DisplayName 屬性）。屬性窗格會自動顯示活動的所有參數。
我在前面提到 WF 4 為組合提供強大支持，這同樣適用於自定義活動。如果您創建自己的復合活動，您將能夠自由地將其與任何其他現有活動（如，Sequence、Flowchart、Parallel），甚至是其他自定義活動組合。
調用 CRM 服務
Contoso 的 CRM 系統的核心功能為提供服務。其中一項服務允許登記與客戶的交互。我可以使用 Send 活動調用它，但是這意味著手動配置活動並導入其服務數據約定。
最理想的情況是，我能夠只將服務導入 WF 中，然後執行它。這正是在工作流服務項目中“添加服務引用”所完成的工作：有了服務約定，它會自動創建代理活動（為服務中每項操作創建一個），這些活動可用於調用服務（參見圖 8）。在本例中，CRM 服務約定具有三項操作，因此“添加服務引用”創建了三個活動，這些活動顯示在工具箱中。
圖 8 向 CRM 服務添加服務引用
傳達結果
最後，我需要將結果提供給客戶。為簡化應用程序，我只使用 ReceiveAndSendReply 活動將結果公開給客戶。在客戶讀取結果後，工作流即完成。
為此，我需要在 Flowchart 中拖放一個 ReceiveAndSendReply。請注意，當您將活動拖放到設計器表面時，您會獲得一個折疊的 Sequence。這是因為 ReceiveAndSendReply 是一個活動模板，這意味著它是一個預先配置的活動集（在本例中，是一個具有 Receive 和 SendReply 的 Sequence）。前面當我添加子 Flowchart 用於進行篩選時您已經看到。
要配置 ReceiveAndSendReply，我需要深入了解並在 Receive 活動中設置端點消息。我還需要將 Receive 配置為按客戶標識進行關聯，以便在客戶使用其 customerCode 發送消息時，他將獲得響應。
長時間運行的工作
工作流將審批請求發送給供應商後，服務實例將處於空閒狀態，等待響應。此響應可能需要幾分鐘、幾小時、幾天甚至幾周才能到達。這會帶來許多有趣的挑戰。您很可能不希望將所有實例都存儲在內存中，因為這會占用不必要的系統資源而且不能縮放。而且，如果主機進程崩潰（或者在決定性不大的應用場景中，需要關閉以進行維護），任何未完成的實例都將丟失。
如果當某個實例不執行任何工作時，您可以只將其保存到持久存儲中並將其從內存中刪除，豈不是很好？您可以通過 WF 持久性框架，其允許將工作流實例保存到存儲介質中以供稍後檢索。
這意味著實例未被綁定到任何現有進程或計算機。在示例工作流中，篩選可在一個進程中執行，向第一個供應商詢問利率可在另一個進程中執行，接收響應可在第三個進程中執行，而不影響工作流實例的執行或其數據。這實現了更好地利用資源，改進可伸縮性以及提供恢復能力，主機崩潰並不會導致活動實例丟失，因為可從上次保存它們的時間點恢復它們。
工作流實例被保存到實例存儲中。WF 4 包括一個基於 SQL Server 的實例存儲，由於持久性框架是可擴展的，因此您可以編寫自己的實例存儲。（例如，SDK 中的 PurchaseProcess 示例顯示了如何編寫一個十分簡單的文本文件實例存儲。）
我使用內置 SQL Server 實例存儲保存 Contoso 工作流的實例。值得高興的是，您無需編寫任何代碼即可使用它。在工作流服務中，持久性行為可在 web.config 文件中通過如下方式配置：
<!--Set up SQL Instance Store-->
<sqlWorkflowInstanceStore connectionString="Data Source=.\SQLExpress;Initial Catalog=InstanceStore;
Integrated Security=True;Asynchronous Processing=True"/>
<!--Set the TimeToUnload to 0 to force the WF to be unloaded. To have a durable delay, the workflow needs to be unloaded-->
<workflowIdle timeToUnload="0"/>
第一行將持久性行為配置為使用 SQL Server 實例存儲。第二行指示持久性框架在實例進入空閒狀態時保存實例並將其卸載（這意味著當您執行 Receive 並進入空閒狀態等待響應時，工作流實例將被卸載並被保存到數據庫中）。
如果工作流配置為持久的並且配置了關聯，則主機 (WorkflowServiceHost) 負責在消息到達時基於關聯信息加載正確的實例。
假定您擁有一個配置為關聯 customerCode 的實例，假設 customerCode = 43。您向抵押供應商詢問利率，在等待響應時實例被保存（持久性包括保存關聯信息）。當抵押公司為 customerCode = 43 發送回消息時，WorkflowServiceHost 自動從實例存儲中加載該實例並發送消息。
請注意，默認情況下，未安裝 SQL 實例存儲。您需要通過運行一組隨 .NET Framework 4 提供的腳本顯式安裝它。
跟蹤服務
我擁有一個長時間運行的服務，其采用基於消息的方式與其他服務進行通信。此服務配置為持久的，並行執行其許多工作，並且可執行異步活動。這似乎非常復雜。如果出現問題，該如何處理？如何了解哪個活動失敗？如果您只想知道服務實例的情況，該怎麼辦？
Visual Studio 允許調試工作流（您可以通過設置斷點在 WF 設計器中進行逐步調試，就像在代碼中執行一樣），但是這不適用於生成環境。
WF 包括一個豐富的跟蹤基礎結構，可提供有關正運行的工作流的數據。跟蹤會將工作流中發生的情況（跟蹤事件）告知跟蹤參與者，然後跟蹤參與者保存這些事件。跟蹤配置文件允許篩選跟蹤參與者接收的事件，以便其只獲取需要的信息。
WF 4 提供一個將數據保存到 Windows 事件日志中的跟蹤參與者 (EtwTrackingParticipant)。您可以通過擴展 TrackingParticipant 創建自己的跟蹤參與者。對於此工作流，我使用了默認 EtwTrackingParticipant。您無需編寫任何代碼即可使用它；只需在 web.config 文件中提供適當的配置。我首先將服務配置為使用 EtwTrackingParticipant：
<!--Set up ETW tracking -->
<etwTracking profileName="HealthMonitoring "/>
我還將其設置為使用 HealthMonitoring 配置文件，該配置文件提供有助於評估服務運行狀況的事件（參見圖 9）。現在，服務提供有關事件的信息，可幫助您監控其運行狀況並在出現問題時加以修復。SDK 提供了許多示例，它們顯示了如何創建您自己的跟蹤參與者以及如何編寫故障排除配置文件。
圖 9 指定跟蹤參與者配置文件
<tracking>
<profiles>
<!--The health monitoring profile queries for workflow instance level records and for workflow activity fault propagation records-->
<trackingProfile
name="HealthMonitoring">
<workflow activityDefinitionId="*">
<workflowInstanceQueries>
<workflowInstanceQuery>
<states>
<state name="Started"/>
<state name="Completed"/>
<state name="Aborted"/>
<state name="UnhandledException"/>
</states>
</workflowInstanceQuery>
</workflowInstanceQueries>
<faultPropagationQueries>
<faultPropagationQuery
faultSourceActivityName ="*"
faultHandlerActivityName="*"/>
</faultPropagationQueries>
</workflow>
</trackingProfile>
</profiles>
</tracking>
部署和使用服務
我已經使用設計器創建了一個工作流並將其配置為持久性和跟蹤。剩下的唯一任務就是承載並運行此服務。
在開發時，您可在 Visual Studio 2010 中使用內置 Web 服務主機承載服務。為此，您只需運行包含服務的項目即可完成操作。
將服務承載於生產環境只是稍微復雜一些。您可將 WCF 工作流服務承載於 IIS 或 AppFabric 應用程序服務器擴展中。使用 Visual Studio 2010，您可以創建一個可直接導入到 IIS 中的包。如果您決定使用 AppFabric，您將能夠利用諸如儀表板之類的功能（其會提供有關您的服務實例的摘要信息），以及查詢記錄的跟蹤。
最後一步實際上是使用服務。在此應用場景中，Contoso 需要一個基於 Web 的界面，以允許用戶與服務交互。這表示從 ASP.NET 應用程序使用服務。
您在這裡看到的示例 WCF 工作流服務正如您可以采用純代碼編寫的任何其他 WCF 服務一樣。要使用它，您需要在客戶端項目中添加一個服務引用。此服務引用會創建客戶端代理，以調用服務。
添加引用後，您即可調用服務。此服務的客戶端針對服務中的每個 Receive 活動執行一項操作。圖 10 顯示了用於請求抵押審批的代碼（因此啟動一個新的服務實例）。
圖 10 使用服務
protected void OnSubmit(object sender, EventArgs e) {
using (ContosoRealEstate.ContosoRealEstateClient client =
new ContosoRealEstate.ContosoRealEstateClient()) {
string message = "";
string result = client.EvaluateMortgage(
out message,
this.txtId.Text,
Convert.ToInt32(this.txtHousePrice.Text),
Convert.ToInt32(this.txtDownpayment.Text),
Convert.ToInt32(this.txtYears.Text),
Convert.ToInt32(this.txtSalary.Text),
this.chkCreditHistory.Checked,
this.chkBankrupcy.Checked,
this.chkLawsuit.Checked,
this.chkForeclosure.Checked);
lblMessage.CssClass= result;
lblMessage.Text = message + " (" + result + ")";
this.btnSubmit.Visible = result.Equals("Incorrect");
this.btnMonitor.Visible = result.Equals("Approved");
}
}
結束語
正如您所看到，.NET Framework 4 提供了豐富的功能集，可用於通過組裝現有組件構建復雜的實際應用解決方案。該架構還提供了擴展點，以根據適應各種應用場景的具體需要定制這些組件。
通過 WCF 工作流服務，您只需組合現有活動並配置服務即可以聲明方式描述長時間運行、持久且經過檢測的流程，但是您還可以在必要時編寫自己的代碼。
在本文中，我組合了 WF 4 和 WCF 4 中的許多功能，以構建獨立執行許多工作並協調與其他現有服務的對話的服務。我在未編寫代碼的情況下構建了整個服務，包括新項目（自定義活動）。
利用這些 .NET Framework 4 技術，您可以實現更多目標。
下載代碼示例：http://code.msdn.microsoft.com/mag201005WCF
