There are trade-offs to consider when evaluating this strategy:•If the flowExecutionis large then it becomes more expensive to send to the client and
back on every request. You may be limited to POSTs only.- There is a security risk when storing all the information on the client. This risk is
mitigated by encrypting the _flowExecutionId, but not entirely, and therefore needs
to be considered. - There is no way to track conversation invalidation after completion (for example, when
a continuation reaches an end state). It is possible to “go back” after completing a flow
and resubmit, completing a single logical application transaction more than once.
Supporting conversation completion detection properly likely involves combining a
client-based continuation strategy with some form of centralized storage, like a data-
base-backed conversation table.
■NoteAlthough the _flowExecutionIdencryption can be customized, the default implementation is still
open to attack. The default encoding algorithm is done by the Commons Codec package (http://jakarta.
apache.org/commons/codec), with optional support for GZIP compression.Conversation Invalidation After Completion
All but one of the FlowExecutionRepositoryimplementations provide support for “conversa-
tion invalidation after completion.” This ensures that after a logical conversation ends, it is not
allowed to continue. In other words, once a flow execution has ended, you cannot resume it;
you can only start a new, independent FlowExecution. This prevents the possibility of a dupli-
cate submission.
This is accomplished by explicitly managing the duration of a logical conversation
between a client and the server with the aforementioned conversationId. Once a FlowExecution
associated with a conversation reaches an end state, the entire conversation will be invali-
dated. Any subsequent requests to continue that conversation will result in a
NoSuchConversationExceptionbeing thrown consistently each time.■NoteThe exception to this is ClientContinuationFlowExecutionRepository,which does not yet
provide support for conversation invalidation at the time of writing. This will likely be added in a future
release of Spring Web Flow.States and Transitions Revisited
In Chapter 11 we took a brief look at the various constructs within Spring Web Flow, such as
the flow, states, and transition elements, and this section will explore them again in more
detail. Table 12-7 recalls the different types of states.358 CHAPTER 12 ■ADVANCED SPRING WEB FLOW