What is it?
Why does it exist?
Ok, then why a different implementation?
By using continuations, the state of your script is recorded in an encapsulation of its call stack (together with all local variables) whenever it sends back a HTTP response. Not only does it allow you to store state between two requests simply in script local variables, it also opens up quite wild possibilities. Namely, the users of your web application can navigate at will in your web application: use the back button of their browser few times then continue from there, or even open a new window at a backed page and diverge in two different directions. Your web application will seamlessly assume the script states appropriate for the current page on the next request, as those states aren't thrown away And remember that you only had to write a single, structured, mostly linear script for all of this! The system manages the mapping of user's unpredictable browsing behaviors to your structured-programming script for you!
At the moment, continuations can be stored in-memory, bound to a HTTP session, or for more sophisticated applications, they can be persisted to a JDBC data source or even let to be managed by the client's browser! Smart stubbing of shared objects is employed that both minimizes the size of the serialized state and allows continuations to be resumed in a different JVM than the one that originally created them, allowing for clustering and failover scenarios.
We provide a tutorial that builds on the example webapp that ships with the distribution.
Other players in the space
We already mentioned the Spring's default Spring Web Flow implementation. Apache Coccoon also has a web flow engine based on Rhino, but that engine would probably be hard to integrate into Spring proper.