5

I'm reading the Spring Web Flow chapter in the book Pro Spring MVC. Unfortunately there's no explicit information, where the state during a flow execution is persisted. I assume it is saved in the JVM Heap and associated with the session.

Now HTTP is a stateless protocol (REST...) and I'd like to use Spring Web Flow without saving state on the server (besides the one and only state that a session might be authenticated).

One strategy is to send all parameters of the entire flow with every HTTP request of the flow (hidden input) and thus accumulating all necessary parameters until the flow has finished.

The overhead of re-validating parameters can be avoided with signatures over already validated parameters.

Do you know, whether it might be possible to use Spring Web Flow in this way? Has anybody already done this?

Update: Why?

Persisting state is not only a violation of the principles of HTTP as a stateless protocol but has practical problems too:

  • If the user browses with multiple browser tabs then this can lead to inconsistent state, race conditions or data loss.
  • Storing state on the server makes load balancing over several servers more complicate.
  • Testing and debugging becomes more complicate, because requests can not be tested or analyzed in isolation but only in the context of previous requests.
  • Cookies must be enabled to correlate servers sessions to requests.
  • The server needs to synchronize access to the server-side state.
  • The url of a request that also depends on server state does not contain all information necessary to bookmark the state inside a flow or to make sense of it in a bug report.

I've not yet looked at the details of Web Flow but I'm confident that one could have the same programming experience and still keep all information in the request parameters.

Update: I've now learned that my requested style of flow handling has a name: Continuations. The term continuation is more common in functional programming but it's apparently not uncommon to adapt the idea to HTTP interactions.

Thomas Koch
  • 2,833
  • 2
  • 28
  • 36
  • why do you want to do that? are there too many sessions you have to persist? – Philipp Sander Oct 22 '13 at 10:54
  • 2
    One of the main reasons for using Spring WebFlow is that it provides _conversational state_ through its use of flows. These flows by their very nature will maintain server-side state in order to perform their function. If you're looking to develop a stateless application - then I don't think WebFlow is what you want. You'd be better off with regular Spring-MVC or some other technology just as [Jersey](https://jersey.java.net/) for RESTful webservices. – Will Keeling Oct 24 '13 at 08:02
  • I can tell you, that at some point you will probably run into performance and data inconsistency problems with WebFlow, because every state/data in WebFlow are serialized/deserialized. With many REST request and data manipulation in WebFlow you will get easily in trouble of inconsistent data between those request, bugs hard to debug and reproduce. – Leszek Gruchała Aug 20 '14 at 09:55

1 Answers1

0

You might be interested in checking my bean flow FSM project (restflow): https://github.com/alfonso-presa/restflow

Although it doesn't use Spring WebFlow, I think it may help answering the spirit of the question, as it allows the implementation of a stateless server orchestrated flow. I started this project because I wanted to make almost the same as you with spring WebFlow but I found it was not possible as state is stored in session (and also REST/json serialization is not built in).

It's main purpose is making an state-machine (just like WebFlow does) but with it's state stored in a bean, which you can persist in a distributed store, or easily sign or encrypt and send back to the client as continuation for next requests.

I hope you find it useful.

edit: I created a showcase project here: https://github.com/alfonso-presa/restflow-spring-web-sample

Alfonso Presa
  • 1,024
  • 7
  • 11