Hello:
Until now, I've developed all my
Java EE applications using Stateless Session Beans only. The "only" state which I've needed to keep between method calls has been certain information about the authentication of the user, such as the user ID, login date and two or three properties more. For this task I've created my own session management, which makes a session ID after the user logins (a pseudo-random number, like many Web servers do), and stores the information associated to that ID into the database. This way, I return the session ID to the client application, so it employs this on every method call. Otherwise it would need to authenticate the user on every call, obviously.
I guess that this approach may be criticized for not taking advantage of the Stateful Sessions Beans to keep the state of the user session. But my problem is that I don't know what's the best strategy to move from my current design:
* Should I make an unique Stateful Session Bean which contain all the logic of my current Stateless Session Beans, so every method can access the user session information internally? I do not like this because it would ruin the "granularity" of my design and would make it a mess. Although I believe that a friend of me uses this design
pattern (I believe he callied it "one facade design").
* Or should I leave everything as is, but make a single Stateful Session Bean simply to keep the user session state? This would implement a method to login. Then, I would pass this SFSB to the SLSB as a parameter, instead of my session ID. However, I've serious doubts about the effects of passing an object which is a stub.
Thank you.
PS: When I mention "session" I'm referring to the state of an authenticated user. Just to clarify.