Spring Web Flow 2.0 M2 剛剛釋出了。我對此版本感到特別興奮，因為它為實現我們社群未來的宏大願景奠定了所需的基礎。在這篇文章中，我將解釋這個願景是什麼，以及這個基礎將具體實現什麼。我還會詳細介紹 Web Flow 2.0 的架構，並將其與 1.0 版本進行比較。

Spring Web Flow 2.0 願景

2.0 的目標是將 Spring Web Flow 演進為一個受控導航引擎，以顯著改進對 JavaServerFaces、流程管理的持久化以及非同步事件處理（Ajax）的原生支援。新的 Spring Faces 專案將基於 Web Flow 2.0，在 Spring 環境中為 JSF 檢視提供一流支援。此外，Web Flow 將繼續為基於 Spring MVC 的檢視提供一流支援，允許原生 JSF 和 MVC 檢視充分發揮作用，甚至在同一應用程式中同時使用。

* 更新：上述願景已於 08 年 1 月 11 日根據自 2007 年 Spring Experience 以來收到的 Spring 社群大量反饋進行了更新。基於這些反饋，計劃於 2008 年 3 月釋出的 Spring Web Flow 2.0 將繼續專注於 Web 應用程式中受控導航和應用程式事務的編排，可作為基於動作的 MVC 環境中 Spring MVC 的補充，以及基於元件的環境中 JavaServerFaces 的補充。與 JSF 一起使用時，Spring Web Flow 2.0 可以作為“黑盒”驅動整個基於 JSF 的 Web 應用程式，或者可以與實現自由導航要求的標準 JSF 導航處理器混合使用。 2.0，因此，將是一個演進版本，增加對 JSF 和 Ajax 的一流支援，支援 Java 1.4+，並提供與 SWF 1.0 流程定義語言的完全向後相容。

現在我想更詳細地介紹一下 Web Flow 2.0 引擎架構，以及它與 1.0 版本的比較。首先讓我們回顧一下 1.0 的歷史。

1.0 歷史回顧...

在 Spring Web Flow 1.0 中，SWF 控制器引擎負責 Web 請求生命週期的一半；與請求處理相關的部分，通常稱為動作階段。另一半，渲染階段，則交由呼叫者負責：Spring MVC、Struts 或 JSF 前端控制器。這可以在下面的 SWF 1.0 架構圖中顯示。

這種架構的主要好處是，將 Spring Web Flow 引入現有專案變得非常自然。無論您使用的是 Struts、Spring MVC 還是 JSF，您都可以引入 Web Flow 來處理更復雜的使用者互動，其餘部分則使用普通控制器。

這種方法的缺點是，在請求生命週期的檢視渲染階段，如果不依賴於前端控制器特定的介面卡，很難應用應用程式控制邏輯。例如，考慮一下對流程管理的持久化上下文的需求。這樣的上下文應該在一個新的流程執行開始時分配，在結束時釋放，並在中間檢視渲染後斷開連線，等待使用者繼續。如果檢視渲染不受流程控制，如何在正確的時間發出斷開連接回調？類似的問題也存在於異常處理、併發管理和安全性領域。

SWF 1.x 方法的另一個缺點是，在某些環境，特別是 JSF FacesServlet 中，“適配”Web Flow 需要重複勞動。在 JSF 的情況下，Web Flow 和 JSF 實現都在爭奪 URL 的控制權以及如何管理伺服器端狀態。

歡迎 Spring Web Flow 2.0

從 Web Flow 2.0 M2 開始，整個 Web 請求生命週期，包括檢視渲染階段，現在都在 Spring Web Flow 的控制下。此外，Spring Web Flow 現在可以使用任何檢視技術渲染響應，並對 Java Server Faces 和基於 Spring MVC 的檢視提供一流支援。實際上，這意味著 SWF 2.0 是同類中少數幾個提供統一控制器模型來處理所有型別的使用者互動（無論是無狀態還是有狀態）並支援多種檢視技術的框架之一。這也意味著現在可以使用原生 Web Flow 執行鉤子來觀察整個 Web 請求生命週期，從而可以在請求生命週期的適當點集中應用安全性、異常處理、效能管理、併發管理和持久化上下文管理策略。新的 SWF 2 架構，在 Spring MVC DispatcherServlet 內部執行，如下圖所示。

Java Server Faces

支援的第一種檢視處理策略是 Java Server Faces。透過 Spring Faces 專案，SWF 引擎現在可以充當 JSF 的容器，並完全驅動 JSF UI 元件生命週期，將 SWF 應用程式控制器模型的所有優勢與 JSF UI 元件模型的所有優勢結合起來。因此，我們為社群帶來了以下好處：

• 一種以 Spring 為中心的方式來配置和部署使用 JSF 的 Spring Web 應用程式。要啟動和執行，您需要部署一個 Spring Web Servlet 並將其指向您的 bean 定義檔案，這與您今天配置 Spring MVC Web 應用程式的方式非常相似。不需要 faces-config.xml 或任何其他特殊的 JSF 檔案。這使得 Spring 使用者可以非常輕鬆地利用 JSF 而無需承擔任何傳統缺點。如果願意，您甚至可以在 Spring MVC DispatcherServlet 內部使用 JSF，當在“嵌入式”模式下執行時。

• 自動支援 POST+REDIRECT+GET 模式，以防止在使用瀏覽器導航按鈕時出現重複提交和瀏覽器警告。這出於同樣的原因是可能的：Spring Web Flow 原生支援此模式，並且我們已將 JSF 整合到我們的模型中。

• 流程管理的 UI 元件狀態。這特別有趣，因為傳統上使用 JSF 意味著需要大量的 HTTP Session 狀態來儲存元件樹。JSF 元件狀態現在完全作為 SWF FlowExecution 例項狀態進行管理，這意味著該狀態如何儲存取決於使用的流程執行倉庫。這意味著可以實現一個完全沒有會話儲存的 JSF 應用程式。這也意味著對於無狀態或“REST-ful”互動，從不分配會話儲存。這也意味著當為有狀態流程執行分配會話儲存時，分配的儲存量更少，並且該狀態的範圍是明確的（並且在實踐中通常比傳統的 JSF Web 應用程式更短）。

外部系統

我們驗證的第二種檢視處理策略是 SWF 引擎透過 HTTP 與外部系統和會話上下文通訊的能力（儘管 API 是協議無關的）。一個很好的例子是電子購物網站可能會使用像 paypal 這樣的第三方服務。假設您正在引導使用者進行電子購物體驗，並且作為該體驗的一部分，您需要暫停並將使用者重定向到 paypal 完成支付授權過程。Paypal 在接管支付授權控制權後，會回撥您，以便您可以從暫停的地方恢復使用者的電子購物體驗。通常透過向外部服務傳遞一個回撥 URL 來支援此功能，外部服務完成操作後將重定向到該 URL。

這種模式現在已由 SWF 引擎原生支援。要執行類似操作，您只需向外部系統發出“外部重定向”。Spring Web Flow 現在負責在傳送到外部系統的重定向中嵌入適當的流程執行回撥 URL。

資源

我們驗證的第三種檢視處理策略是能夠從資源包（如 .jar 檔案）提供資源內容（影像、javascript 檔案、css 檔案等）。當 Ext 和 Dojo JavaScript 小部件由 Spring Faces JSF 元件渲染時，Spring Faces 安裝了一個預定義的“REST-ful”流程，用於提供 Ext 和 Dojo 庫所需的 Javascript 和 CSS 資源。

Spring MVC 檢視

最後，我們驗證的第四種檢視處理策略是能夠提供基於 Spring MVC 的檢視。這使得現有的 Spring MVC 檢視模板能夠像以往一樣與 Web Flow 2.0 協同工作，這對於我們現有的 Spring MVC 和 Web Flow 使用者來說非常重要。

結論

本文對 Spring Web Flow 2.0 版本的目標以及最近釋出的Spring Web Flow 2.0 M2 版本中奠定的架構基礎進行了高階概覽。敬請關注後續文章，這些文章將重點介紹 M2 中的主要新功能以及我們目前正在為 M3 忙於實現的新功能。Spring Faces 專案負責人 Jeremy Grelle 特別有很多關於新的 JSF 和 Ajax 支援的激動人心的內容要分享！