【翻譯習做】 Windows Workflow Foundation程序開發-第一章01

第 1 章    歡迎來到工做流的世界

…思想如蝴蝶般飛到我身邊 —— Gossard / Vedder

（譯註：Gossard與Vedder是來自Pearl Jam樂隊的2名樂手，該句出自他們的歌曲《Even flow》）

 

Windows Workflow可被看做是繼COM＋和分佈式事務協調器（DTC）以後，Windows平臺上最使人矚目的一款中間件產品。它們之間的區別在於：不是每個軟件應用都須要進行分佈式事務處理；但幾乎每一個軟件都要在其內部實現工做流。爲了可以領會微軟設計Windows Workflow的初衷,讓咱們先從一般意義上的工做流談起。

工做流是什麼？簡單地說，一個工做流就是爲了完成一個特定任務而涉及的一系列步驟、決策和規則。想想你在當地一家比薩餅店點餐這樣一個流程。你先跟餐廳招待講明想要哪款比薩餅。招待把點菜單傳給廚師，廚師就着手把原料處理好並放入烤爐。稍後，廚師把烤好的比薩餅交給招待，招待把比薩送到你面前並跟你結帳。至此，整個流程結束。這項工做先「流」向招待，而後「流」向廚師，最後又「流」了回來。

在上述每個步驟中，全部參與者都進行了規則評估並作出決策。廚師在接受點菜單以前要先看看後廚的備料是否夠用。在結帳時，要是你拿出了優惠券，招待一定要看看它們是否有效；若是懷疑你用假鈔付款，他還要通知餐廳經理。

工做流不必定非要有人蔘與其中（這點好啊，由於人但是有本事把最簡單的過程都給搞複雜了）。一個工做流可能發生在兩個分佈式應用軟件之間。例如，兩個內容管理軟件可能會在夜間經過應用一系列特定的操做和規則來實現兩者間的內容同步。

大部分的工做流都是有狀態的，並且常常會須要至關長的執行時間。幸運的是，你點的比薩餅會在30分鐘內作好。在這段時間內，點菜單的狀態信息，好比你已經點的比薩餅蓋頭，不能有變化。比薩餅店向供貨商定奶酪的流程可跟你點比薩餅的不同。供貨商不可能在30個小時內都不把奶酪送來，比薩店也不會在30天內都不向供貨商支付貨款。在那30天中，對於一個交易來講，須要某種東西來維持其工做流狀態。

一個工做流在其生存期內可能要花費大部分的時間等待來自外部世界的事件信息。在顧客等待上菜，招待等待顧客付款，或者廚師等待比薩出爐的時候，工做流會處於空閒狀態。在這種狀況下，工做流並不須要任何資源。

一個工做流就是爲了完成一項任務而執行的一系列步驟。工做流常常會長時間地運行，並且它是有狀態的，時常須要等待事件，並與人進行交互。你會發現工做流無處不在。做爲程序員，咱們常常要在本身開發的軟件中實現工做流。

1.1         建立工做流解決方案

咱們都有參與一些軟件開發項目的經驗，啓動這些項目的目的就是想經過軟件來改進現有的業務流程。這些流程多是關於比薩餅訂單的，關於金融交易的，或者是關於醫療保健的。不管如何，每當談論到這些項目時，咱們都不可避免的要碰到「工做流」這個老朋友。工做流看似簡單，但是深刻其中，你就會發現內藏的玄機。爲了管理工做流狀態，咱們須要數據庫表格和數據訪問類。咱們須要Email發送組件和隊列消息等待組件。咱們還要告訴計算機如何執行工做流。讓咱們先來看看理論上工做流是如何實現的：

// 這是一個處理新提交的採購訂單的工做流
class PurchaseOrderWorkflow { public void Execute(PurchaseOrder order) { WaitForManagerApproval(order); NotifyPurchaseManager(order); WaitForGoods(order); } … }        

 

假設咱們已經給出了Execute當中三個方法的定義，一個工做流看上去真的會如此簡單嗎？答案顯然是否認的。咱們必需要編寫一些代碼來實現異常處理、日誌記錄和診斷功能。咱們須要引起事件並提供掛鉤函數以便可以跟蹤和取消正在運行的工做流。同時，這個工做流會在大部分時間裏處於空閒狀態並等待一個外部事件發生，好比說一直在等待供貨商把已下單的貨物送上門來。在等待到貨的時候，咱們不能讓運行中的應用程序線程空空等上幾天甚至幾周。咱們須要提供一種機制，它可以把工做流的執行狀態保存到持久化的數據存儲介質中，而後將這個正在運行的工做流實例從內存中清除。當有一個重要的事件發生了，咱們還會恢復這個工做流的狀態，並讓它繼續執行下去。

遺憾的是，這樣一來，咱們就會在工做流內部和外部添加太多的代碼，以致於使本身迷失在工做流之中，很有一種「不識廬山真面目，只緣身在此山中」的困惑。全部這些支持性代碼會掩蓋住咱們正試圖實現的業務流程。一個不懂技術的業務人員將永遠沒法透過這些代碼看清其中的工做流。一個程序員若是不對代碼仔細探查一番，也不會理清其中的工做流。

一種改進的工做流設計方法試圖把工做流的定義與執行該工做流的引擎和支持性代碼相分離。這種方法容許程序員，甚至是業務人員，來描述這個工做流 「應該作什麼」，而讓工做流引擎來決定「如何」讓這個工做流去作。目前，許多工做流解決方案都是在廣受歡迎的尖括號中定義工做流。讓咱們看看理論上使用XML定義工做流的方法。

<Workflow Name="PurchaseOrderWorkflow"> 
    <Steps> 
        <WaitForTask Event="ManagerApproval"/> 
        <NotifyTask Target="PurchaseManager"/> 
        <WaitForTask Event="Delivery"/> 
    </Steps> 
    <Parameters> 
        <Parameter Type="PurchaseOrder" Name="order"/> 
    </Parameters>
</Workflow>

 

這裏再問一句，一個工做流看上去真的會如此簡單嗎？此次的答案是確定的；咱們還須要一個可以理解這段XML並把它翻譯成計算機指令的工做流引擎。這個引擎將包括全部必需的功能，好比異常處理、追蹤以及取消執行功能。

 

咱們在前面看到的C#代碼是一個命令性編程方式的例子。在這種方式中，咱們經過提供一系列可執行的指令來描述「如何」完成一項任務。上面的XML標記是一個聲明性編程方式的例子。在這種方式中，咱們對任務看上去是「什麼」樣子進行描述，而讓其它軟件來決定爲了完成任務須要執行哪些步驟。軟件市場上大部分的商業化工做流解決方案都容許使用聲明方式定義工做流，由於這種方式不與異常處理、事件激發等低層次的實現細節攪合在一塊兒。

 

使用XML的好處之一就是有大量的工具可以對XML標記碼進行讀取、修改、建立以及轉換操做。也就是說，咱們能夠藉助工具進行XML開發。與解析C#代碼相比，XML標記碼解析起來更容易，而且可使用圖形框和箭頭爲工做流生成可視化效果。反過來，咱們也能夠先讓業務用戶使用可視化設計器，經過把一些圖形框相連的方式繪製出工做流框圖，再從框圖中自動生成XML標記碼。

咱們到底想從一個工做流解決方案中得到什麼？咱們想以聲明方式對工做流進行描述，也許還須要一個可視化設計器來幫忙。咱們想把工做流的定義輸入到一個工做流引擎中。這個引擎會運行工做流，並對錯誤、事件、追蹤、啓用以及停用操做進行管理。

下面該Windows Workflow Foundation登場了。

 

章節連接：
【翻譯習做】 Windows Workflow Foundation程序開發

【翻譯習做】 Windows Workflow Foundation程序開發-前言