WF 4.0中如何實現工作流版本管理

工作流版本管理一直是大家非常感興趣的話題。在剛剛過去的Tech.Ed 2009和MVP Open Day 2009中，通過和一些開發人員的交流，我發現許多人心中都有這樣一些問題：WF 4.0支不支持工作流版本管理？如果支持，要怎麼做？今天，我們就來談談這一話題。

什麼是工作流版本管理

工作流通常用來對企業、政府或其他組織內部或之間的業務邏輯進行建模，一個業務邏輯通常對應一個工作流定義，每個工作流定義通常會有多個工作流實例運行。舉例來說，企業內部都有報銷流程，在工作流系統中就會有一個工作流定義用來實現這個報銷流程，而企業中會有很多人需要報銷，因此這個報銷工作流會有很多實例運行。

業務邏輯通常不是一成不變的。當某一業務邏輯在已經有對應的工作流實例運行的情況下需要做出改變，就會涉及到一些問題。比如現在有10個報銷工作流的實例在運行，而企業希望調整報銷流程，應該怎麼辦呢？這一問題就是工作流版本，也就是說某一工作流定義需要根據業務流程的變化做出改變，因此產生了針對某一業務邏輯的多個版本的工作流定義。這一問題的解決方案就是工作流版本管理。

理想情況下，工作流版本只是工作流定義在服務器端做出的改變，對客戶端來說是透明的。換句話說，已經部署並運行的客戶端不需要做任何改動就可以繼續與工作流交互（當然，這一切的前提是工作流定義的改變並不會影響客戶端與其的交互方式）。然而，我們仍然要思考以下幾個問題：

1. 不同版本工作流定義的實例可以同時運行嗎？
2. 已經在運行的工作流實例應該升級到最新版本嗎？
3. 如何把客戶端的請求路由到不同版本的工作流實例呢？

針對這些問題，通常可以用以下幾種典型策略概括。

1. 新工作流實例創建機制。當需要創建一個新工作流實例時，服務器必須要選擇使用哪個工作流版本。
   1. 最新創建：服務器永遠會使用最新的工作流版本來創建工作流實例。
   2. 選擇創建：服務器通過某種判斷邏輯來決定使用那個工作流版本。判斷邏輯可以完全取決於服務器端，也可以是客戶端顯示指定需要那個版本。這種策略非常靈活，當然也需要服務器端做更多的事情。它的另一個好處就是可以控制流程的升級。比如可以先選擇性的在某些實例上進行升級，驗證新版本是否合適，然後再做全面升級。
   3. 延遲創建：服務器可以選擇在已有工作流實例結束之前拒絕所有創建新流程的請求。
2. 已有工作流實例處理機制。當工作流定義出現多個版本時，服務器必須決定如何處理那些已經存在的基於老版本的工作流實例。
   1. 終止實例：馬上終止老版本的工作流實例。這樣一來，就需要創建新實例來代替被終止的老實例。如果業務邏輯要求老版本和新版本不能共存，那麼這種策略是比較合適的選擇。
   2. 逐步取消：已有的工作流實例不會受到任何影響，它們會繼續執行。當所有這些已有老實例全部結束後，老版本的工作流定義將會被棄用。
   3. 完全升級：所有老實例全部都升級到新版本。
   4. 選擇性升級：某一部分老實例會被升級。更復雜一點的情況是當有多餘兩個版本存在時，比如有A、B、C三個版本，A是最初的版本，某些老實例可能不升級，仍然維持在版本A，某些老實例可能會被升級到版本B，某些老實例可能會被升級到版本C。

WF 4.0中的工作流版本管理

WF 4.0並不提供任何高層次的工作流版本管理功能。這意味着默認情況下，你無法查看或管理工作流定義的不同版本，你無法在你的應用中直接擁有以上介紹過的各種機制和策略。但是作爲一個基礎框架，WF 4.0允許你實現自己的工作流版本管理功能。下面我們就來看看如何實現。

從技術上來說，在新工作流實例創建機制方面，WF 4.0支持上面提到的全部三種策略；在已有工作流實例處理機制方面，WF 4.0不支持已有老版本工作流實例的升級（也就是說它不支持2.3和2.4）。已有工作流實例必須要麼執行結束（2.2），要麼被終止或被新版本的工作流實例替換（2.1）。注意我說“從技術上來說”是因爲WF 4.0並不默認提供這些機制和策略，你需要自己實現。

其實，無論是創建新工作流實例還是處理已有工作流實例，無論選擇哪種策略，需要解決的問題 只有兩個：

1. 如何承載不同版本的工作流定義（Hosting）？
2. 如何路由客戶端請求到不同的版本（Routing）？

在開始進入這兩個問題之前，需要先介紹一下WF 4.0的承載機制。在WF 4.0中，工作流定義可以籠統的分爲兩類：普通工作流和工作流服務（Workflow Service）。普通工作流顧名思義就是最普通的工作流定義，它有一些活動組成。工作流服務比較特別，它是由工作流實現的網絡服務。一個工作流服務可以包含多個服務方法（Service Operation），客戶端可以使用標準的網絡服務協議調用這些服務方法，從而觸發工作流實例的初始化和流轉。在WF 4.0中，工作流服務的底層是由WCF實現的。

針對這兩種工作流定義，WF 4.0提供了兩種不同的承載方式：WorkflowApplication和WorkflowServiceHost。WorkflowApplication針對普通工作流，WorkflowServiceHost針對工作流服務。你可以在自己的程序中通過代碼來創建這些宿主。對於工作流服務，你還可以把它們部署到IIS中，後者會自動創建WorkflowServiceHost。

承載（Hosting）

在WF 4.0中，每個工作流定義都必須運行在一個單獨的工作流宿主中。也就是說，如果一個工作流定義有多個版本需要同時被使用，開發人員必須創建相應數量的工作流宿主。這些宿主可以運行在同一個進程中，也可以運行在不同進程中。

這聽起來似乎不是很方便，但實際上並非如此。因爲大部分的工作流定義（尤其是涉及到人工活動的工作流），我們都建議實現成工作流服。在部署工作流服務時，只要把它們發佈到IIS上，IIS就會自動創建相應的WorkflowServiceHost，你不需要做任何額外的工作。如果你需要使用WorkflowApplication，在代碼中創建它們也不是什麼難事兒。

路由（Routing）

相比承載，路由是一個略顯複雜的問題。根據你定義的是一個普通工作流還是工作流服務，可以有不同的實現方式。

自定義的版本路由控制器

自己實現工作流版本的路由控制器。這樣做的好處是有最大的靈活性，既可以用於普通工作流，也可以用於工作流服務；壞處是你自己需要實現所有的邏輯（顯而易見J）。

對於普通工作流的情況，它可以是一段決定應該使用哪個工作流版本的代碼。一個客戶端請求會被先發送到這個路由控制器，然後控制器會決定使用哪個工作流版本並調用相應代碼創建該版本的工作流實例。

對於工作流服務的情況，它可以是一個網絡服務。客戶端在申請創建一個工作流實例前先發送一個請求到該控制器，然後控制器會就決定使用哪個工作流版本並返回相應的工作流服務地址。隨後客戶端再發送請求到這個地址以便創建工作流實例。

WCF路由服務

如果使用工作流服務，那麼一種更好的方法是使用WCF路由服務。WCF路由服務是WCF 4.0中提供的新功能，它可以幫助你非常方便的實現網絡服務路由。因爲工作流服務的底層實現就是WCF，因此我們可以利用WCF路由服務來實現版本路由。在這種方法中，每一個客戶端請求都需要在其請求參數中包含一個版本令牌（version token）。WCF路由服務會根據這個版本令牌把請求轉發到相應的工作流服務。當然我們也可以實現一些默認邏輯，例如對不包含版本令牌的請求，一律路由到工作流的最新版本。

關於WCF路由服務以及WCF 4.0新功能，請參考這篇文章A Developers’ Introduction to Windows Communication Foundation 4。

後續

以上就是在WF 4.0中實現工作流版本管理的方式。可以看到，雖然WF 4.0默認並沒有提供高層次的版本管理功能，但是實現一套自己的版本管理並不困難。今天我介紹了不少理論上的東西，在下一篇文章中，我將進入實戰環節，實現一個簡單的工作流版本管理，與大家共同討論。