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 体验以来，在考虑了 Spring 社区的大量反馈意见后，上述愿景于 2008 年 1 月 11 日进行了更新。根据这些反馈，计划于 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。在 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 请求生命周期，从而允许在请求生命周期的适当点集中应用安全、异常处理、性能管理、并发管理和持久性上下文管理策略。下面显示了在 Spring MVC DispatcherServlet 内部运行的新 SWF 2 架构

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 会话状态用于存储组件树。JSF 组件状态现在完全作为 SWF FlowExecution 实例状态进行管理，这意味着如何存储该状态是所用流程执行存储库的功能。这意味着可以实现一个根本没有会话存储的 JSF 应用程序。这也意味着永远不会为无状态或“RESTful”交互分配会话存储。这也意味着当为有状态流程执行分配会话存储时，分配的存储量更少，并且该状态的范围已定义（并且在实践中通常比传统的 JSF Web 应用程序短）。

外部系统

我们已经验证的第二种视图处理策略类型是 SWF 引擎能够通过 HTTP 与外部系统和对话上下文进行通信（尽管 API 与协议无关）。一个很好的例子是电子商务网站可能使用第三方（如 PayPal）来完成的事情。假设您正在引导用户完成电子商务体验，并且作为该体验的一部分，您需要暂停并将用户重定向到 PayPal 以完成付款授权流程。PayPal 在接管付款授权控制权后，将回调您，以便您可以从暂停的地方恢复用户购物体验。这通常通过将回调 URL 传递给外部服务来支持，当外部服务完成后，它将重定向到该 URL。

SWF 引擎现在原生支持这种模式。要执行类似的操作，您只需向外部系统发出“外部重定向”。Spring Web Flow 现在负责将正确的流程执行回调 URL 嵌入到发送到外部系统的重定向中。

资源

我们已经验证的第三种视图处理策略类型是能够从资源包（如 .jar 文件）中提供资源内容（图像、JavaScript 文件、CSS 文件等）。我们有一个预定义的“RESTful”流程由 Spring Faces 安装，用于提供 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 积极实施的新功能。Spring Faces 项目负责人 Jeremy Grelle 特别有很多关于新的 JSF 和 Ajax 支持的内容要谈！