SLSB: we need to pass around all the info. about the itinerary back and forth for some of calls. For example, user selects seats and confirms seats are two separate calls, both need itinerary info.
considering the data contained in itinerary (flight specification, seat numbers, etc.), I do not think that is a lot of data.
SFSB: we need to pass around the EJB handle, but this concerns us with scalability. This stores sessions in app. server. But, Rod Johnson did say that, if we have two web servers and only one app. server, we should store sessions in the web server.
Database session: we could store itinerary into database, and return to client a key to the itinerary. Future calls will pass around internal ID, thus no need for SFSB, a SLSB would work. Some discourages this because we are passing around an internal ID but I do not find it troubling me. After all, we are passing around EJB handle with SFSB.
So, it seems that either one of the three would work. I do not know if I missed anything.