Figure 11-4.Purchase Product use case
The preceding flow is very simple, consisting of two steps the user must complete. These
include:
1.Entering the product purchase information
2.Optionally entering product shipping information
There are also two additional steps that perform back-end processing—the first deter-
mining whether shipping is required and the second for submitting the order for processing.
The user never “sees” these steps, as they are carried out by application code.
Finally, there is a single end step called “Show cost confirmation.” When that step is
reached, the user can review the result of order processing but cannot go back and resubmit.
As you will see, one of the architectural strengths of SWF is that it composes logical user
interactions into discrete, self-contained components called flows. This brings several bene-
fits. When an execution of a flow starts, the user can participate in it, but once it ends the user
cannot go back; she can only start a new execution. In addition, the user can only participate
in a very controlled manner, with the flow fully determining how to handle user events.
As a self-contained component, the Purchase Product flow can be made independent
of the other work flows in the system, such as Authenticate User or Browse Catalog, and be
reused in other contexts. This leads to a highly composable application, with the ability to
mix and match flows to create larger and more complex applications.
start
Enter
purchase
information
Is shipping
required?
Place order
Enter shipping
information
cancel
Cancel
submit
submit
no
yes
Show
cost confirmation
CHAPTER 11 ■INTRODUCTION TO SPRING WEB FLOW 317