Workflow Foundation 4 第一課 - 初探

原文出處: http://michaelchpeng.spaces.live.com/blog/cns!37633C3B61B57B57!1142.entry


微軟在這回推出包括像 Visual Studio 2010、.NET Framework 4.0 等新技術上較以往最大的不同就是儘可能早的提供訓練教材和文件,這讓我們在熟悉新技術上更容易提早入手。針對 Workflow Foundation,原本的訓練教材中就已經有一套還不錯的模組。不過由於從 Workflow Foundation 3.x 到 4.x 改變很大,而完全不曾接觸過 WF 的朋友即便能順利的完成教材中的實做,可能也會有摸不著頭緒的情況。所以我計劃以這份實做為基礎,用中文再提供一系列的文章,不同之處在於我不單只是著重在步驟,還會多花一些篇幅介紹原由。也就是說例子是教材中的例子 (因為在結構上我覺得設計的不錯,以逐步增加的方式引導我們進入狀況),但描述的方法和深入的程度有差別。已經接觸過 WF 的人,就可以跳過我的文章,直接看教材的內容會好一些。

我們先來看看 WF 從 3.x 到 4.0 主要有什麼變動,從最初 .NET Framework 3.x 發佈,最受人矚目的功能無外乎 WPF、WCF、WF 和 CardSpace。而到目前為止,使用最廣泛的,應該屬 WPF 以及 WPF 衍生出來的 Silverligh 技術,以及 WCF。前者是使用者操作介面技術和 Web 應用,原本就是最容易感受到改變和效益的技術。再來應該是 WCF,這主要是受益 Silverlight 技術主要透過它進行遠端通訊,而 Silverlight 的普及也間接帶動了它的應用。CardSpace 是屬於使用者身份認證的技術,在應用的範疇上有一定的侷限性。而 WF,則顯得有些吊詭。理論上它應該是在應用上最沒有侷限,不論 Windows 或 Web 平台,不論是那一種類型的應用,我們都應該樂見應用程式作業邏輯能以視覺化的方式表現。然而一方面由於它本身名稱上可能給人的聯想和誤解,使得許多人對它的印象僅停留在和工作流程有關的應用;另一方面要開發人員改變過去以程式碼為中心的開發方式,也是一個很大的挑戰。在找不到合適的利基點,以及觀念改變和開發技術難度的挑戰下,要將 WF 帶入到一般的應用中,確實是有它的障礙。

WF 3.x 在經過市場的考驗後,到了 4.0 做了很大的幅度的更動,而這部份的更動絕大多數都反映在開發工具上。一般開發人員在使用 WF 時,最容易碰到的障礙就是開發方法的差異。原本 WF 的出現,是希望透過 XAML 以結構化的方式表達應用程式的作業邏輯,而這些透過 XAML 定義的作業邏輯可以輕易的以視覺化的方式表現。所以開發人員可以透過 WF 設計工具將應用程式的作業邏輯清楚的呈現,讓應用程式的維護更容易進行。同時藉由 WF 作業環境的協助,讓開發人員能夠善用這些機制,去管理應用邏輯被重複叫用時的重要時間點,完整的管理一個作業邏輯執行的生命期。從最佳經驗的角度來看,WF 並不是要取代傳統程式碼,而是提供一個補強的方式去建立更容易理解的程式邏輯,並且花更多精神在樣式、可重複使用元件的建立上。這個前提是要能夠將應用邏輯明確的模組化,方便在不同的應用程式流程中重複使用,而且這些模組化的單元 (也就是 Activity) 又必須實做 WF 的介面,才能套用到 WF 流程中。對於許多開發人員而言,這個過程可能反而不如直接用程式碼表現來得直覺。再考慮到定義變數或參數的方式都不像過往直接在程式碼中操作一樣直接 (要繼承特定類別,要套用屬性宣告),這個難度就更高了。最後的結果,我們在 WF 流程中最常看到的 Activity 就是 Code Activity 了,因為那是所有開發人員都會的本事。

諷刺的是,一旦有 Code Activity 出現在 WF 流程中,就意謂著許多 WF 的特性和優點被放棄了。從我的角度,Code Activity 可以說是個敗筆,讓大家禁不住就在流程中直接寫程式碼。想像一下,你會在 Windows 或 Web 的 Control 中寫程式碼嗎?不會,你只能用屬性視窗去安排屬性。這個包裝的特性讓使用者介面元件的設計分工很合理的被分割,使用元件的人只想著如何控制元件的行為,或是繼承元件之後再修改它的行為。同理,既然 WF 的一個重大願景就是把商業邏輯像包裝使用者介面邏輯一樣,透過控制項的概念包裝起來,以方便視覺化的設計工具應用,就應該包裝的徹底些才是。不過由於之前 WF 設計介面在屬性視窗上的功能不盡理想,不像使用者控制項的屬性可以做很豐富、複雜的設定,Code Activity 反而成了一種必要之悪。

基於上述的原因,WF 最重大的變革,就是不能在流程中使用 Code Activity 了,而是一律要將必須由程式碼表現的作業邏輯包裝成 Activity。我們可以直接執行一個單一的 Activity (包裝了程式碼),也可以執行一個 WF 流程 (包裝了各種 Activity)。如果你接觸過 WF 3.x,就可以明白其實 WF 中任何一個流程都是一個 Activity 的衍生。所以 4.0 並沒有改變這個架構,只是更嚴格的限制了開發架構,讓開發人員透過開發工具去遵循一個最佳典範。

不過若是開發 Activity 的難度沒有下降,那要開發人員願意用 Activity 以程式碼來包裝可供 WF 流程使用的作業邏輯,也是有困難的。所以在 WF 4.0 中的另一個改變就是藉由工具 (也就是 Visuals Studio 2010) 的協助,隱藏掉所有底層宣告的細節,讓開發人員能更專注在 Activity 中要包裝的作業邏輯之中。Visual Studio 2010 這部份最大的變化就是結合 WPF,把整個流程設計工具都改寫了,充份善用 WPF 的特性,讓我們可以對 Activity 進行完整的設定作業,同時也可以很容易的寫出 Activity Designer,方便流程開發人員使用。在後面的課程中,大家可以更明確的感受到這部份的改變。

所以啦,歸結一句話,從架構的角度,WF 3.x 到 4.0 並沒有相當根本性的變化。最大的變化都反應在開發工具的搭配上,讓我們能夠以更直覺、更容易的方式進入到 WF 的世界。透過 Visual Studio 2010 的協助,讓開發人員不經意的就遵循最佳經驗,以合理的方式進行 WF 流程的設計工作,並且更有效率,更容易被應用在不同的場合。如果更進一步結合未來在 Windows 中會提供的 Windows Azure 服務 (原本的代號 Dublin 和 Velocity),就能讓應用程式更容易管理,更容易排除問題。

WF 4.0 的另一個重要改變,就是在 Visual Studio 中不像過往提供 Sequence Workflow 和 State Machine Workflow 兩種工作流程範本。其實在 WF 3.x 的架構中就很明確的表示工作流程不是只有這兩種,開發人員可以依據需要自行定義新的工作流程類型,因為這基本上就是定義一個新的 Activity。所以在 Visual Studio 2010 的 Workflow 設計工具中,你不會再看到以往這種以工作流程類型分類的範本,而只是很單純的依使用的特性分類的範本:

我們可以看到範本的類型有四種,第一種是 Activity Designer Library,它和第二種 Activity Library 相關。我們會利用 Activity Library 建立我們自己的 Activity,包裝我們的作業邏輯。一個 Activity Library 中可能定義了多個 Activity,可以加載到工具箱中。當開發人員把自訂的 Activity 拖放到流程當中,就必須透過視覺化的方式進行這個 Activity 的設定,這時就牽涉到對應的 Activity Designer。所以 Activity Designer Library 範本就是協助我們製作這些設計工具,方便開發人員應用。

至於後兩個範本,則影響我們要建立的工作流程應用的方式。Workflow Console Application 是建立一個獨立執行的工作流程,雖然它有個 Console 的字眼,好像是建立以主控台作業的工作流程為主,但不代表這裡建立的工作流程無法使用在 Windows 應用程式之中。只是預設的情況下,它會提供一個可以在主控台內啟動的環境,方便我們做偵錯測試的作業。所以如果我們想建立能獨立執行的 WF 流程,就以這個範本為起點進行開發。但是如果我們要建立的作業流程是能夠遠端呼叫,以服務的形式對外提供作業時,就可以選擇 WCF Workflow Service Application,它會幫我們建立對應的 WCF 服務端口,並且能以 IIS 做為主控環境,對遠端提供服務。過往使用WF的另一個障礙就在於要有主控環境 (Host) 的概念,而要設計一個功能完善,有效率的主控環境,並不是容易的事。一般開發人員也很難一下掌握住不同的主控環境的類型 (自訂、Windows Service、IIS) 和相關開發技術。而在 VS 2010 中,就把事情簡化成兩種,Console 就是屬於自訂這一類,WCF Service 就屬於 IIS 這一類,而且直接結合 WCF 技術,不用像過去要分別考量到兩者的需求,這又克服了一個原本存在的障礙。而且之前 WF 3 只支援 Web Service 的存取,缺乏和 WCF 整合的能力。既然微軟把所有遠端存取的技術重心都轉移到 WCF 身上了,WCF 又涵蓋了 Web Service 的使用,沒有理由是這樣的狀況。所以 WF 4 也很緊密的支援 WCF 的使用,這是它的另一個改進。

一旦我們建立了工作流程專案,可以再加入不同的工作流程項目,進行開發的作業。下圖中可以看到工作流程項目的範本有四個,前兩個都是用來設計 Activity,Code Activity 是透過程式碼的方式設計,Activity 則是透過組合既有 Activity,以視覺化的方式設計。WCF Workflow Service 則是建立個別的 WCF 服務,將 WF 流程包裝成可供遠端取用的作業服務。至於 Activity Designer 則是設計供開發人員使用的設計器,以定義 Activity 的內容。

在上述的範本中,你已經看不到 Code Behind 了,WF 4.0 中所有的流程都是宣告式的。原因其實前面已經交待過,就是所有最基礎的作業邏輯都應該包裝在 Activity 中,而操作這些 Activity 都應該透過屬性的改變和宣告完成。當你在 Visual Studio 中試圖對 XAML 檔下 View Code 的命令時,會發現它只是轉到 XAML 文字內容,而不再是一個 VB 或 C# 的環境。如果真的牽涉到程式碼的作業,也都是包裝在 XAML 檔案中,這對於部署到不同的環境和動態執行都是一個相對容易處理的安排,也是最初 XAML 的願景的一部份。

這樣子我們應該對 WF 4.0 有一個基本的概念了,後面的課程中就會透過實例帶著大家去認識這個新生的 WF。