簡介
通過使用WWF，你可以創建基於處理器流的工作流並且把它們部署在任何類型的.NET應用程序中。此外，本文還討論了ASP.Net開發者面對的一些特有的問題-這些問題可能通過使用工作流得到解決，如維持狀態和頁面導航等。
在2005年9月，微軟在它的一年兩次的專業開發者會議上公開了Windows Workflow Foundation(WWF，Windows工作流基礎)。作為WinFX API的支柱之一，WWF提供給開發者一個普通框架-在其上開發過程驅動的和以工作流為中心的應用程序。
當前，有些組織力圖把整個商業過程自動化；他們的標准答案就是集合一隊開發者來開發相應的代碼。盡管這種方式對於這些組織帶來良好的作用，然而也有一些固有的問題。為了深入理解這一問題，你需要理解一個工作流的基本特征。
一個工作流本質是一種方法-用來歸檔包含在完成一個單元的工作中的活動。典型地，在處理過程中，工作"流"流過一項或更多活動。這些活動可以通過機器或人工來實現，並且有可能象在一個互聯網應用程序定義頁面順序一樣得簡單，也有可能象管理必須為任何數目的人都要看到、更改並同意的文件或產品一樣得復雜。
因為如此多的工作流必須考慮到人工參預，所以可能需要花費很長工期才能完成，時間可能為幾小時到數月或更長。例如，參預在該過程中的人可能無法找到，不在本地或忙於另外的任務；因此，工作流必須在所有非活動期間能夠把自身持續性存儲。而且，通過編碼獨立實現的過程可能對非技術人員難於理解而對開發者卻難於更改。這一點和其它一些因素正是例如WindowsWF等通用工作流框架的目標-其目的就在於使創建、改變和管理工作流更容易-這是通過向它們提供一個可視化接口或通過定義一組普通API來實現的。
你可以把WWF工作流放置在任何類型的.NET應用程序中-包括Windows表單程序，控制台應用程序，Windows服務和ASP.NET Web應用程序。每種類型都需要專門的考慮。盡管一些現有示例已經足夠說明如何把工作流宿主到Windows表單程序和控制台應用程序中，但是本文將集中於討論ASP.Net開發者的問題-他們希望把工作流集成到自己的應用程序中。
作者注:本文所提供的代碼是以Windows WF Beta 1和Visual Studio 2005 Beta 2 為工具創建的。你可以在www.windowsworkflow.net找到有關安裝Windows WF的信息。盡管本文討論了Windows WF的一些基礎問題，但是還有其它一些這方面的可用資源。我假定讀者至少了解一點Windows WF。本文的目的是深度分析Windows WF和ASP.Net，而不是從一個高層次上討論Windows WF。
一、 Windows WF和MVC模式
在開發一個ASP.Net應用程序時，你可能使用WWF的一個普通的方法是實現一種模型-視圖-控制器(MVC)方法。實質上，MVC的目標是把描述層、應用程序邏輯和應用程序流邏輯分離開來。
搞清楚這個將十分有益於一個ASP.NET應用程序的開發，請考慮一個幫助桌面票工作流的場所。假定有一個商業用戶通過填寫一個ASP.NET Web表單並點擊一個提交按鈕來啟動該工作流。接下來，服務器就會通知一個使用Windows表單應用程序和幫助桌面的雇員--"有新票可用了"。該幫助桌面雇員然後將在這一問題上工作，並在最後關閉該票。如果使用Windows WF來開發這個工作流情形，那麼所有的處理邏輯和流程可以被包含在工作流本身，而該ASP.Net應用程序將完全不需要了解這一邏輯。
這種場所提供了一些穩固的證據-把描述與邏輯相分離是一件好事情。因為這個處理幫助桌面請求的過程是非常普通的，如果使用C#或VB.NET代碼在若干不同的.Net應用程序中實現這一邏輯，那麼你將會冒著重復編碼的危險甚至更壞的情形--用完全不同的代碼導致同樣的商業處理過程的不同實現。但是如果你使用WWF來實現這一過程，那麼需要這一過程的應用程序開發者將僅需在一處修改這些步驟-工作流本身-而不必擔心這樣會改變應用程序邏輯。代碼復制和在哪裡實現該過程可以通過Windows WF的使用來加以緩和。
當使用Windows WF在ASP.Net中實現MVC架構時，開發者應該嘗試構建獨立於應用程序的工作流-而該工作流仍然宿主於該應用程序中。這將有助於保持邏輯獨立於描述並且保持在該Web應用程序中的工作步驟順序和頁面流之間的高度獨立性。
一個WWF開發新手可能試圖用一固定數目的活動以某種順序去開發一個工作流，然後開發一組ASP.NET Web表單--這些表單以與之相同的順序從一個表單流向另一個表單。很遺憾，盡管這看上去挺符合邏輯，但是實際上這是非常不具有生產效率的，因為你將會再次實現這個工作流邏輯。Web頁面X不需要知道是否它需要轉到頁面Y或頁面Z來正確地實現該工作流步驟。代之的是，該工作流(模型)應該告訴ASP.NET(控制器)下一步該干什麼；然後ASP.NET應該決定要顯示哪個頁面。這樣，每個頁面幾乎不需要了解整個過程；它僅需要知道怎樣完成一個不同的活動並且讓該工作流來關心頁面是如何從一處流向另一處的。這種分離在開發者處理頁面流時帶來了一種極大的靈活性。例如，如果你決定改變該頁面顯示順序，那麼你可以從工作流中容易地實現這一點，而不需要改變該ASP.Net應用程序中的一行代碼。
二、 一個簡單的工作流MVC實例
為了說明這一思想，我將向你展示一個簡單ASP.Net應用程序和工作流。這個過度簡化的工作流描述了一個進度-收集一些來自於一外部應用程序的私人信息，然後顯示它。步驟如下：
1. 調用一個方法--這意味著請求一個人的名字;該工作流使用了InvokeMethod活動(見圖1)。
2. 等待直到一個事件被激發--這意味著收到一個名字；在這一步中，該工作流使用了EventSink活動。
3. 使用一類似調用，從宿主獲得一個電子郵件地址。
4. 等待一個事件意味著收到一個地址。
5. 在收到名字和電子郵件以後，該工作流啟動一個InvokeMethod活動來發送個人資料到調用者應用程序。在一種真實世界情形，這最後一步並不很重要。更可能的是，你將調用一個Web服務來發送數據到另外的系統，或把它放進一數據庫。
圖1.示例工作流:這個工作流描述了隱含在示例ASP.NET應用程序中的過程 為了在ASP.Net中實現這個工作流，你需要一個頁面來收集人名，一個頁面來收集電子郵件地址和一個頁
面來顯示個人資料。記住，數據登錄表單應該絲毫不知道之前或之後所發生的一切。對於顯示頁面也是如此。然而，該ASP.NET應用程序必須了解要把哪個頁面顯示給用戶；這正是引入控制器的目的之所在。這個示例使用一個Http處理器來實現該解決方案。這個稱為WorkflowController的定制的處理器負責下列任務： ·獲得到工作流運行時刻的一個參考。 ·獲得一個到已有的或啟動一個新的工作流實例的參考(這依賴於是否已啟動一個工作流實例)。 ·建立控制器和工作流之間的通訊。 ·處理來自該工作流的事件。 ·告訴ASP.NET需要顯示哪個頁面，這依賴於現在正執行該工作流中的哪一層。 你已看到，這個定制的處理器實質上負責處理所有的與WWF和頁面控制相關的工作--讓單個的ASP.NET頁面對在後台正在進行的動作保持"緘默"。Web表單需要擔心的唯一的事情是執行手頭特定的任務並且把必要的數據傳遞到控制器。 默認地，WWF以一個異步的模型工作。這意味著，當一個應用程序宿主啟動一個工作流實例時，控制立即返回到該宿主，而該工作流繼續在另一個線程上執行。這在一個Windows表單應用程序中可能是很有用的-其中十分期盼用戶接口的連續響應性。通過使用這個異步的模型，工作流可以在後台執行而該用戶可以繼續操作該應用程序。然而，在一個Web應用程序中，可能不期望這種類型的行為，因為在服務器完成一個單元的工作後控制通常將只返回到用戶。這正是Windows WF的可擴展性的體現。在Windows WF中，開發者可以利用或創建"運行時刻服務"來監控甚至修改該工作流運行時刻。該示例包括： ·持續性服務-存儲執行和空閒時間之間的工作流狀態 ·追蹤服務-輸出有關工作流執行的信息到某種媒體 ·事務服務-幫助維持工作流執行過程中的數據完整性 另外，線程服務讓開發者控制工作流實例的執行方式。如前面所討論的，工作流運行時刻默認地將在一個獨立於宿主的線程上異步地運行實例。但是由於這很可能不是ASP.Net所期望的，所以你需要交換默認工作流線程服務。幸運的是，微軟已經為此提供了一種解決方案--ASPNetThreadingService。為了實現這一變化，你或者可以手工編碼方式把ASPNetThreadingService添加到工作流運行時刻服務，或在web.config文件中完成這一任務。本文中的示例應用程序使用了配置方式。在web.config(見列表1)的工作流運行時刻/服務節中，添加類似下列的這一行： ＜add type=
"System.Workflow.Runtime.Hosting.ASPNetThreadingService,
System.Workflow.Runtime, Version=3.0.00000.0,
Culture=neutral, PublicKeyToken=31bf3856ad364e35"/＞ 三、 實現控制器邏輯 接下來，你需要以一個Http處理器來實現控制器邏輯。為了構建該控制器，所有你需要做的是創建一個稱為WorkflowController處理器的類-它實現IHttp處理器接口。到目前為止，你還沒有看到有關Windows WF的任何特別的東西-這是特別針對於ASP.NET的功能(請繼續往下讀)。 在這個WorkflowController處理器類中，名為ProcessRequest的IHttp處理器接口方法處理一個來自於該ASP.NET應用程序的Web請求。這裡，你需要獲得到一個靜態的工作流運行時刻實例的一個參考，為該工作流建立事件處理器，並且啟動工作流的執行。在啟動一個工作流實例之前，你需要檢查是否該請求的查詢串值包含一個代表一個工作流實例ID的GUID。如果存在這個ID，你就知道已經有一個實例正在運行，這樣你可以得到一個到該實例的參考並繼續執行。如果不存在這個ID，你需要通過調用工作流運行時刻Start Workflow方法來創建一個新的實例並且開始執行過程。 在啟動一個實例後，事件處理器將管理進出工作流的通訊。因為本文的目的不是討論本地通訊服務，所以在此我不會詳細討論這個主題，而是分析其高級的實現技術，並再次討論這在一個ASP.NET應用程序中是如果工作的。為了便利通訊處理，你將需要若干.Net接口--用於描述出/入該工作流和宿主的信息。你會在本文所附WorkflowClassLibrary工程源碼中找到這一些。你還會找到一些實現這些接口的類以及實現工作流機制所必須的相應功能。 讓我們再簡單地看一下web.config文件。注意，在早些時候討論的ASPNetThreadingService元素附近，我們使用了三個元素來描述通訊服務類: ＜add type="Workflow.RuntimeServices.GetNameService,
Workflow.Library, Version=1.0.0.0, Culture=neutral,
PublicKeyToken=c4620ae819b5257e"/＞
＜add type="Workflow.RuntimeServices.GetEmailService,
Workflow.Library, Version=1.0.0.0, Culture=neutral,
PublicKeyToken=c4620ae819b5257e"/＞
＜add type="Workflow.RuntimeServices.SendDataService,
Workflow.Library, Version=1.0.0.0, Culture=neutral,
PublicKeyToken=c4620ae819b5257e"/＞ 這裡還有一個元素，它指導工作流運行時刻庫來使用SqlStatePersistenceService。這種另外的服務把一個工作流的狀態持續性存儲到一個在頁面請求之間的SQL服務器數據庫之中。你必須提前手工地創建這個數據庫，但是微軟提供了SQL腳本來做這件事情。你將會在C:\WINDOWS\Microsoft.NET\Framework\v2.0.50215\Windows Workflow Foundation\SQL文件夾下找到它們。就象模型服務一樣，你可以編程地添加這些服務，但是你也可以在配置中實現它，這將會大大降低代碼的編寫量並且提供靈活性-甚至在代碼生產之後。而且在web.config中有一行，它添加一個HttpModule-它支持在ASP.Net中的Windows WF運行時刻庫；還有一行用於設置更早些時候討論的Http處理器控制器。如你所見，在這個配置中存在許多的東西。 作為結論，Windows WF為開發者在其上開發基於工作流的應用程序提供了一個極其易用和可擴展的框架。實現商業過程已經並將繼續成為一種重要的應用程序技術。除非你是一個技術服務公司或ISV，否則軟件是一定要提供商業及其運行過程的。通過使用如Windows W
F這樣的工具，開發者可以使得開發過程容易且靈活。
