spring web flow是spring framework中的web应用组件，它提供了一种编写有状态和基于会话的web应用的简便手段。spring web flow使得逻辑流程成为web应用中的一等公民，它能让你定义为自包含模块，以独立于应用的其它部分来配置和重用。

spring web flow引入了几种有状态数据域：request、flash、flow和conversation等，这让你能用新的方式来开发有状态web应用。它也提供了定制应用状态管理的扩展点。

terracotta for spring是通过在多个jvm集群来给基于spring的应用提供高可用性的运行时。它给spring web flows的所有域都提供了透明的声明式集群服务（普通的spring beans同样适用）。

在这篇文章中我们会首先给你一个spring web flow和terracotta for spring的总体介绍。然后会向你展示如何联合使用这些技术来进入构建有状态、基于会话、可扩展和高可用的web应用的新领域。

什么是spring web flow？

spring web flow是spring framework中的web应用组件，它提供了一种编写有状态和基于会话的web应用的简便手段。spring web flow使得逻辑流程成为web应用中的一等公民，它能让你定义为自包含模块，以独立于应用的其它部分来配置和重用。它不依赖于框架从而能够方便的与可选的web应用框架一同使用，比如spring mvc、struts或者jsf等。

页面流转使用一种领域定义语言（dsl）来配置，这个语言专门开发用来定义和组合页面流转。目前的实现方式是xml和java.

spring web flow引入了能满足多种用户案例和需求的几种有状态数据域：request、flash、flow和conversation，这给你开发有状态web应用提供了很大的灵活性和能力。

这里是1.0 release中最有趣特性的快速概要。（来自release notes on infoq）：

在一个地方而不是把逻辑分散在很多地方来定义应用任务的所有控制逻辑，比如一个搜索流程。

把简单的流转组合在一起来创建富控制模块。

使用自然和面向对象的线性编程模型，而不是冗长的的if/else块来定义严格的用户导航规则。

但流转结束或过期时自动清除你在流转执行中分配的内存。

在使用你选择的基础web框架的servlet环境中deploy一个可执行的流转。

改变web框架（比如struts、spring mvc、jsf及其它）而不用修改流转定义。

和环境一起改变而不需要修改你的流转定义, 比如从junit测试到portlet。

开发时在不重启容器的情况下不断完善你的应用导航规则。

自动正确响应浏览器按钮（后退、前进、刷新）而不需要定制编程。

在4个受管理域中存储任务数据：request、flash、flow、和、conversation等，每个都有自己的独特语义。

脱离容器单独测试流转。能在部署前确保应用控制逻辑能正常运作。

使用spring ide 2.0进行可视化编辑你的流转导航逻辑图

听上去很有趣？到目前为止还仅仅是概念和理论，但我们很快会看到这些都能在实践中应用。所以请多等一会。

企业对扩展性和高可用性的需求

集群在企业应用开发中变得越来越重要，开发人员经常会碰到这样的问题：

我们如何在一个节点上扩展来提高应用的可扩展性？

如果保证高可用性和消除单点故障，如何确保我们能满足客户的slas(service level agreement)?

为了支撑业务，可预测的扩展性和高可用性是一个生产应用必须展示的运行特性。一些企业需要超过99.9999%的正常运行时间，另一些不要求这么高，但所有的应用都需要保证sla规定的可运行性。从预测的角度看，开发一个系统在99.9%和99.9999%级别是一样困难的。

集群一直以来都是难以解决的问题。在spring web flow和普通web应用上下文中，这尤其意味着保证用户状态的高可用性和故障恢复能力是满足性能且值得信赖的。在一个节点出现故障（应用服务器或jvm崩溃），使用session粘滞（这是配置负载均衡最通用的首选方式）是一个开始，但我们需要一个有效手段来无缝的将用户状态从一个节点迁移到另一个节点。

当我们说集群时意味着什么，它和缓存有什么区别？我们使用的集群定义是: 在多个jmv间共享应用状态，而缓存可以被定义为： 让应用状态靠近执行上下文。从这个角度看，缓存是集群的一个子集。

我们所认为的企业级web/企业集群最小解决方案集至少需要包括：

可扩展性

高可用性

fail-over

性能

对已有代码的最小影响

简单的部署和配置

可见运行时(监控)

让我们关注一个能解决所有这些看上去无关的需求的解决方案。通常解决一个问题有很多方案，而且市场上也有很多宣称能给web应用提供高可用性的产品。terracotta就提供了这样一个解决方案。

什么是terracotta for spring?

terracotta for spring是基于spring应用的运行时，它为spring应用提供了透明的高性能集群支持，对应用代码和部署及配置流程影响都很小。它通过在应用下面的堆级别进行集群而不是直接集群应用。

这让开发者能够开发与无状态方式不同的单节点有状态spring应用。这使得在需要扩展的应用开始设计时不考虑集群。而在应用需要扩展或者要保证搞可用性和故障恢复时，他们只需要在terracotta配置文件中定义哪些spring应用上下文中的beans需要进行集群。terracotta for spring使得应用能够被自动和透明的集群，还保证在集群间的语义和单节点一样。

对于spring web flow来说，这实际上更简单。用户为了获得web应用的状态和持续仓库的集群能力， 只需要在terracotta配置文件中把特定的web应用声明为启用“session-support”。（详细内容见下面的章节“声明式配置”）

从宏观上看，terracotta for spring提供了：

http session状态的集群。保证spring web flow中的用户状态和扩展仓库或放入http session的其它状态的高可用性和故障恢复能力。

spring bean的集群。springbean的生命周期语义和域在集群间被保存，它们在“逻辑”上相同的applicationcontext中。目前能被集群的bean类型是singleton和session scoped. 用户可以声明式配置哪个application contexts中的哪个bean需要被集群。

透明集群pojo。不需要修改已有的代码，甚至不需要源代码。应用基于很少的声明式xml 配置文件，在载入期透明的生效。terracotta for spring不需要实现serializable, externalizable或其它接口的类。能这样实现的原因它并没有使用序列化，而只是将实际的差量和已经改变了的数据传输给当前需要的节点(lazily)。

虚拟内存管理。它也提供分布式垃圾收集和虚拟堆功能。比如，由于物理内存在需要时被换入换出，它能在一个4g ram的机器上运行需要200g堆的web应用。 这也意味着你不需要关心spring web flow会话数据的大小是否超过了物理堆大小。

堆层次集群

terracotta for spring使用aspect-oriented技术来在类载入时适配应用。在这个阶段它扩展了应用以保证java语义在集群间被正确的维护，包括对象引用，进程调用和垃圾收集等

我们在前面提到terracotta并没有使用serialization。这意味着任何spring web flow维护的会话都可以在集群间共享。这也意味着terracotta并没有把会话状态的全部对象图发给所有节点，而是把图分解成纯粹的数据，并在网络间传输实际的“差量”和改变--数据的“原始信息”在其它节点上。

因为有一个记录节点间相互引用的中心调度器（见下文），它能以lazy的方式工作，而只把改变传送到引用了这些“dirty”数据的节点。这需要使用局部引用。如果负载均衡配置为使用"session粘滞" 就更有效率，因为这意味着很多数据可能永远不会脱离实际的session而不用复制到其它节点。

这个架构是中心辐射的，也就是有一个管理客户端的中心调度器。在这里客户端就是你配有terracotta for spring运行时的普通应用。调度器不是单点失败的，但你可以配置一组备用调度器，并在主调度器崩溃时选择一个来接替。你也可以独立于客户端，对调度器进行集群扩展。

构建一个高可用的有状态web应用

这里我们使用一个叫sellitem的示例应用来推动讨论并展示给大家：

如何使用spring web flow来构建一个有状态基于会话的web应用。

如何使用terracotta for spring来声明式集群有状态应用。

sellitem示例应用可以在spring web flow的发布版本中找到。（更多信息见文章末尾的“resources”章节）

使用spring web flow实现一个有状态web应用: sellitem

sellitem是展示结合了有条件转移、会话域、流程执行转向和延续性的示例应用。用户在几个页面间导航，可以定义货物的价格、可以销售的货物数量、折扣比率、送货详情（如果需要）和最后查看所有信息。

我们不会通读应用的所有源码，而是主要介绍一些关键概念，如怎么配置spring web flow输出的不同标准服务（bean）和怎么定义页面流转（使用针对页面流转的spring web flowdsl的xml版本）。

在spring mvc中配置dispatcherservlet

应用的入口是一个标准的spring mvc dispatcherservlet，它在web.xml中注册并在web application context中映射到*.htm。　

sellitem　

org.springframework.web.servlet.dispatcherservlet

contextconfiglocation

/web-inf/sellitem-servlet-config.xml

/web-inf/sellitem-webflow-config.xml

sellitem

*.htm

dispatcherservlet配置在spring的配置文件sellitem-servlet-config.xml和sellitem-webflow-config.xml中。 sellitem-servlet-config.xml中有一个映射到"/pos.htm"的控制器，它将所有该url的请求转发到spring web flow系统（它的入口是一个流程执行器）：

配置flow executor和flow registry beans

spring flowexecutor bean配置使用一个flowregistry bean来执行"/web-inf/flows/"目录中的基于xml的流转定义。

定义页面流转

剩余的逻辑在我们已经注册的flowregistry bean的流转定义中。（参照前面的'配置flow executor和flow registry beans章节）。

在深入流转实现细节前，我们先看一下页面流转的状态图（如下图）。

从上面我们可以看到流转在结束前经过了几个步骤，在决定销售是否需要送货时有一个决策状态。

一个很好的针对上面导航规则的初始流转定义实现如下：

xmlns:xsi="http://www.w3.org/2001/xmlschema-instance"

xsi:schemalocation="

http://www.springframework.org/schema/webflow

http://www.springframework.org/schema/webflow/spring-webflow-1.0.xsd"〉

我们从上面的定义可以看到，实际状态与状态图中的状态对应，状态转换与图中的箭头对应。"sale" bean是流转开始时分配的流转变量实例。它持有了sale相关的属性。

上面的定义展示了所有的导航逻辑，但还没有实现任何应用行为。特别是在用户提交时更新sale bean的逻辑还没有实现。另外后台的sale处理逻辑还没有定义。

实现了所有必需行为的完整spring web flow定义如下：

xmlns:xsi="http://www.w3.org/2001/xmlschema-instance"

xsi:schemalocation=" http://www.springframework.org/schema/webflow

http://www.springframework.org/schema/webflow/spring-webflow-1.0.xsd"

在定义导航逻辑之外，也定义了适时调用恰当应用行为的action。这包括处理用户提交事件和调用后台处理器来处理sale的逻辑。

form绑定和验证

当进入展示表单的视图状态时，流转调用一个formaction command bean来进行表单的装配和提交逻辑。在提交时，formaction把用户的请求参数绑定到相应的sale属性上并同时验证它们。

更多信息

spring web flow全部的代码、文档和10个示例应用（包括sellitem）都可以在spring网站上找到http://www.springframework.org/webflow。

集群sellitem应用

现在我们已经看过了如何使用spring web flow来实现一个有状态web应用。接下来让我们更高兴的看如何给我们的示例应用启用高可用性和故障恢复，如何使用terracotta for spring进行集群来提供透明容错性和在节点间共享状态。

听上去很难? 你会发现这实际上很简单。

声明式配置

sellitem示例应用使用一个sale类的实例来保存当前销售的会话数据；同样spring web flow executor repository也使用http session 来保存所有的会话数据。

要使用terracotta for spring，我们需要确保为给定的web应用启用了http session集群，包括所有可能被保存在 http session中（或者能被保存在http session中的实例引用）的类，以便于检测。这里是terracotta for spring的tc-config.xml配置文件的一个例子：

name="swf-sellitem"〉

true

org.springframework.webflow.samples.sellitem.sale

这里我们为swf-sellitem war文件启用了http session集群并配置了sale类。

就是这样，我们已经做了很多了。

启用terracotta

我们唯一需要做的就是在应用中启用terracotta for spring运行时。这可以通过修改tomcat web服务器的启动脚本并在脚本最前面加入下面的环境变量完成：

set java_opts=-xbootclasspath/p:"%dso_boot_jar%"

set java_opts=%java_opts% -dtc.install-root="%tc_install_dir%"

set java_opts=%java_opts% -dtc.config="%local_dir%\tc-config.xml"

这里面：

dso_boot_jar环境变量指向jar的根目录(能在terracotta for spring安装的根目录的common/lib/dso-boot下找到)。

tc_install_dir环境变量指向terracotta for spring安装的根目录。

local_dir指向包含tc-config.xml的目录.。

sellitem应用预配置了terracotta for spring集群的代码可以在下面的'resources'章节找到。也包括了开箱即用的tomcat集群配置。

注解：spring应用上下文中的集群bean可以在服务(bean)级别配置，并依赖于terracotta for spring的 auto-include检测机制.例如，大多数情况下我们不需要关心引入哪个类，而只需要在tc-config.xml文件中定义希望集群的bean的名称。

总结

spring web flow 给包括文章中看到的这种简单应用到有很多页面流转的大型企业应用，都提供了构建基于会话的有状态应用的有力手段。 terracotta for spring给你的spring web flow提供了高可用性。

简而言之， terracotta for spring提供了：

给基于spring web flow的应用包括普通spring的应用提供容错性。

不需要实现java.lang.serializable，在多个节点间分布的应用中透明共享状态。

在多个分布式节点进行资源调用。

在多个分布式节点间保持了pass-by-reference语义。

声明式配置基本上不用修改现有代码(除了以前是无状态spring应用，现在需要变成有状态)

spring web flow和terracotta for spring结合在一起，给你提供了构建有状态、基于会话、可扩展和高可用性web应用的新方式。