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 視圖充分發揮效用，即使在同一個應用程式中需要時也是如此。

* 更新：上述願景已於 2008 年 1 月 11 日更新，此前考慮了 Spring 社群自 2007 年 Spring Experience 以來的大量回饋。 根據這些回饋，計劃於 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 方法的另一個缺點是，它需要重複工作才能將 Web Flow「融入」某些環境，尤其是 JSF FacesServlet。 在 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 在完成時會重定向到該 URL。

SWF 引擎現在原生支援這種模式。 要執行類似的操作，您只需向外部系統發出「外部重定向」。 Spring Web Flow 現在處理將正確的流程執行回呼 URL 嵌入到傳送到外部系統的重定向中。

資源

我們已證明的第三種視圖處理策略是能夠從資源包（例如 .jar 檔案）提供資源內容（圖像、JavaScript 檔案、CSS 檔案等）。 我們有一個預定義的「REST-ful」流程，由 Spring Faces 安裝，用於提供 Ext 和 Dojo 庫所需的 JavaScript 和 CSS 資源，當 Ext 和 Dojo JavaScript Widget 由 Spring Faces JSF 元件呈現時。

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 支援的令人興奮的事情要說！