Different Scopes
As previously discussed, information (or context) created during a user’s interaction with the
server is stored in a request, session or conversational scope.
The Servlet API provides infrastructure for accessing request and session scope, and
Spring Web Flow provides access to conversational scope/flow scope.
The primary concern when considering scopes is that of storage: where does data placed in
a scope actually live? Request scope is stored in the request (the data sent from the browser); ses-
sion (and application) scope is stored on the server. Where is flow scope stored? The answer is in
a repository. More specifically, Spring Web Flow delegates this responsibility to implementations
of org.springframework.webflow.execution.FlowExecutionRepository. As you would expect,
Spring Web Flow provides a number of implementations to support different usage scenarios:
- SimpleFlowExecutionRepository
- ContinuationFlowExecutionRepository
- ClientContinuationFlowExecutionRepository
The first two repository implementations are stateful and are managed in server-side data
structures, typically the session. In this case, putting attributes in flow scope directly increases
server-side memory requirements, as it increases the size of a flow execution stored in a
repository that is managed in a user’s session.
The last implementation is stateless and requires no server-side data structures. When
using this strategy, encoded flow executions representing the state of user conversations are
serialized out to clients and decoded on each request into the server.
You will learn much more about the different repository implementations in Chapter 12,
including how ContinuationRepositoriesallow browser navigational buttons to behave in a
sensible way within Spring Web Flow. For now it is important to understand that Spring Web
Flow represents the concept of an ongoing conversation with a user in an object called a
FlowExecutionand is fully responsible for the management of those executions within a
repository.
Building Blocks
Before Spring Web Flow can executeflows, there must be at least one flow defined. As dis-
cussed, the key artifact in Spring Web Flow is the flow definition. The primary challenge for
developers becomes the design and implementation of a flow definition, a blueprint for user
conversations that drives the execution of a business process.
■NoteWith Spring Web Flow, the primary challenge for developers is the design and implementation of a
flow definition.
To demonstrate the process of designing and implementing a flow definition, we’ll show a
use case of purchasing a product (graphically represented in Figure 11-4). For our purposes,
let’s simplify and assume the user has already logged in and already chosen the type of prod-
uct she wishes to purchase.
316 CHAPTER 11 ■INTRODUCTION TO SPRING WEB FLOW