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支持！