传统Web开发，一般都是以客户端作为主动的，客户端发请求，然后接收响应，然后再发请求...，整个流程都是以客户端为推动源。这样的一个结果就是，一般的web框架都是把他们的控制器分成一个个的方法调用，客户端的请求就对应到这些方法调用当中。而Web Continuation Server 通过引入Continuation机制将逻辑反转了过来，并以此实现了对于page flow的完整描述。
Continuation Server 以服务器作为主动方，服务器发送页面，然后等待客户端输入之后，继续执行，然后在发送页面并等待回应...，整个流程是服务器通过发送页面和等待回((SendPageAndWait))应进行推动。整个过程就像是函数调用那样，服务器发送页面回应(SendPageAndWait)就是函数调用开始，而用户发送请求就是函数的返回。要实现这个效果，就需要服务器端可以在收到请求之后能返回到之前的发送响应的后一语句。这里的核心就是服务器端需要能够动态的获取运行栈，在发送响应前，先对当前的运行栈作一个快照，然后在响应到达时，重新从快照那里执行，这样就相当于实现了刚才所说的函数调用效果。使用continuation server之后服务器端就只需要一个方法调用，对应初始请求。
procedure OnRequest()
begin
funcA();
input = SendPageAndWait("GetInfoFromUser.php");
HandleInput(input);
end;
在调用SendPageAndWait的时候，web框架会保存当前函数调用的continuation，向用户返回页面GetInfoFromUser.php，等待用户提交表单之后，web框架重新激活我们所保存的continuation，继续执行我们的函数。这种做法与系统调用和线程调度等机制是非常类似的。虽然这种基于continuation的方式可以自然的解决在session中保存并清理变量的问题，但是使用通用的continuation 实现很有可能会在无意中保存了过多的临时变量，从而对系统性能造成极大的损害，另外在集群环境下，continuation状态如何复制也是需要思考如何解决的问题。
那么为什么需要Continuation呢？利用 Continuation 理念，如果能很好地解决上述的两个问题，就可以很轻松的解决了服务器更新客户端的问题——服务器从而不用再为每一个等待响应的客户端单独建立一个线程，借助Continuations和新IO，可以在有限的线程内支持更多用户。根据Greg Wilkins的测试，使用Continuation的Jetty Cometd服务在10000个并发用户和875个线程下，只用了57M内存。
要实现 Web Continuation，我们需要在服务器中的HTTP会话中维护Continuation记录，并处理超时情况——当Http会话结束的时候是保留还是扔掉Continuation，需要指定Continuation的生存周期。我们还需要将Continuation Id发送道用户的浏览器，通过在URL上附加参数或者在表单中添加附加字段，不过不能放入Cookie中(所有同地址的浏览器窗口会共享该Cookie，从而无法分辨是哪一个窗口发出的)。
支持 Web Continuation 的框架
Continuation Server 以服务器作为主动方，服务器发送页面，然后等待客户端输入之后，继续执行，然后在发送页面并等待回应...，整个流程是服务器通过发送页面和等待回((SendPageAndWait))应进行推动。整个过程就像是函数调用那样，服务器发送页面回应(SendPageAndWait)就是函数调用开始，而用户发送请求就是函数的返回。要实现这个效果，就需要服务器端可以在收到请求之后能返回到之前的发送响应的后一语句。这里的核心就是服务器端需要能够动态的获取运行栈，在发送响应前，先对当前的运行栈作一个快照，然后在响应到达时，重新从快照那里执行，这样就相当于实现了刚才所说的函数调用效果。使用continuation server之后服务器端就只需要一个方法调用，对应初始请求。
procedure OnRequest()begin funcA(); input = SendPageAndWait("GetInfoFromUser.php"); HandleInput(input);end;在调用SendPageAndWait的时候，web框架会保存当前函数调用的continuation，向用户返回页面GetInfoFromUser.php，等待用户提交表单之后，web框架重新激活我们所保存的continuation，继续执行我们的函数。这种做法与系统调用和线程调度等机制是非常类似的。虽然这种基于continuation的方式可以自然的解决在session中保存并清理变量的问题，但是使用通用的continuation 实现很有可能会在无意中保存了过多的临时变量，从而对系统性能造成极大的损害，另外在集群环境下，continuation状态如何复制也是需要思考如何解决的问题。
那么为什么需要Continuation呢？利用 Continuation 理念，如果能很好地解决上述的两个问题，就可以很轻松的解决了服务器更新客户端的问题——服务器从而不用再为每一个等待响应的客户端单独建立一个线程，借助Continuations和新IO，可以在有限的线程内支持更多用户。根据Greg Wilkins的测试，使用Continuation的Jetty Cometd服务在10000个并发用户和875个线程下，只用了57M内存。
要实现 Web Continuation，我们需要在服务器中的HTTP会话中维护Continuation记录，并处理超时情况——当Http会话结束的时候是保留还是扔掉Continuation，需要指定Continuation的生存周期。我们还需要将Continuation Id发送道用户的浏览器，通过在URL上附加参数或者在表单中添加附加字段，不过不能放入Cookie中(所有同地址的浏览器窗口会共享该Cookie，从而无法分辨是哪一个窗口发出的)。
支持 Web Continuation 的框架
- Seaside (Smalltalk)
- Borges (Ruby)
- SISCWeb (Scheme)
- Cocoon (Java Spring-based)
- Spring Web flow (Java)
- RIFE (java)
- jetty6 - Jetty WebServer (Java)
