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 檢視充分發揮其功能，即使在同一個應用程式中也同樣如此。

* 更新：在考慮了自2007年Spring Experience以來Spring社群的大量反饋後，上述願景已於08年1月11日更新。基於該反饋，定於2008年3月釋出的Spring Web Flow 2.0將繼續專注於Web應用程式中受控導航和應用程式事務的編排，可用作基於Action的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請求生命週期的一半；與請求處理相關的一半，通常稱為Action階段。另一半，即渲染階段，被推給了呼叫者：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請求生命週期現在可以使用本地Web Flow執行鉤子進行觀察，從而可以在請求生命週期的適當點上集中應用安全性、異常處理、效能管理、併發管理和持久化上下文管理策略。下面顯示的新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應用程式。這也意味著無狀態或“RESTful”互動永遠不會分配會話儲存。這也意味著當為有狀態流程執行分配會話儲存時，分配的儲存量會更少，並且狀態的範圍是定義的（並且在實踐中通常比傳統的JSF Web應用程式更短）。

外部系統

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

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

資源

我們驗證的第三種檢視處理策略是能夠從資源包（如.jar檔案）中提供資源內容（影像、javascript檔案、css檔案等）。我們有一個由Spring Faces預定義的“RESTful”流程，用於為Ext和Dojo庫提供所需的Javascript和CSS資源，當Ext和Dojo JavaScript小部件由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忙於實現的新功能。Jeremy Grelle，Spring Faces專案的負責人，特別是有很多令人興奮的東西要談論關於新的JSF和Ajax支援！