I am confused about where to store login credentials if I use a stateful session bean to store session data. To retrieve anything from the SFSB, what would be the key? In most applications I've worked on the user Id is stored in the HTTPSession and is propogated to the EJB layer when required.
Kate, I am assuming that your question pertains to the assignment. My take is that the login use case is out of scope for the assignment (since no information is provided on it). I would recommend that you not focus on authentication (and authorization) and instead focus on the 4 main use cases for which information is provided.
To answer your original question, if one were to use a SFSB in place of the HttpSession, then instead of looking up an attribute in the session, you would instead call a method in the SFSB to obtain the user object (which you conceivably stored in the SFSB some point earlier).
SCEA<br />SCJD<br />SCJP
Joined: Jun 14, 2005
Thank you, Giri. But my question is how do you look up any object you stored earlier i.e. what parameters would you pass to the SFSB? Take the example of a shopping cart. If the user hasn't logged in and adds something to the cart, how would I retrieve the information from the cart? I guess my question is more on the lines of how to use a stateful session bean. For example, if I used the SFSB to store my session data( i.e. flights in this case), how would I retrieve that information without the handle for the SFSB? So I would have to store the SFSB handle in my HttpSession! Is this correct since I wanted to avoid using HTTPSession so the swing client can also use the SFSB? [ June 23, 2005: Message edited by: Kate Young ]
There is nothing to put the Handle in the Http session I think. As getting to Swing appln, he might call the EJB Tier directly over RMI/IIOP/TCP schema. So he after having made the first request, already has a handle.
In my case, I created a UserInteractionInterface which contains user interaction methods and which is to be implemented by SwingImpl and WebImpl classes, so that I decouple the EJBTier from the client types.