I was planning to use Stateless Session Facade which manages a Stateful Session Bean. The handle to the Stateful Session bean is maintained in the client tier and passed each time to the EJB tier. In such a design the stateful session bean provides a remote interface. I have seem many discussions in this forum regarding use of Stateless session facade managing a Stateful Session bean. The only thing worries me is that the examiner will buy the assumption that the application server in which the FBN application will be deployed supports optimization of co-located enterprise beans ? I din't liked the idea of creating everything in HttpSession and when the customer confirms the itinerary then the stateful session bean is created, because after the customer confirms the itinerary there will be nothing 'stateful' about the stateful session bean as it no longer needs to keep track of the customer's actions....there are no more actions left actually which require changing anything in the stateful session bean. BUT this approach definitely has one advantage: the fine grained calls to the Stateful session bean have been reduced as the selection of flights and seats was done to some shpping cart object stored in the HttpSession and the stateful session bean only contains the completed customer's itinerary.