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

標籤：style   blog   http   color   使用   os   資料   io   

第 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登場了。

 

 

 - [email protected]部落格園 -