K. Tsang wrote:
Having such data stored in HTTP session will most likely reduce (network) performance because of transfer the data back and forth each time.
Sorry. Did I miss something? The HttpSession object - and beans stored in its dictionary (J2EE session-scope objects) are NOT transferred back and forth. The HttpSession itself is stored in internal dictionary within the J2EE/JEE server. The map uses the jsessionId value as its key so that all that must be transported back and forth is the key (jsession), not the data. and that's not very big.
There are frameworks where shoving the entire session back and forth is done. It's an option for
JSF, for example, although not the default option. Certainly there are compelling reasons not to do so in most cases:
1. As mentioned, it can really add to network traffic
2. Unless secure transport is being used, middlemen can snoop and exploit detail data (the jsessionId enjoys certain protections that raw data does not).
3. Data that's sent to the client can be mangled on the client before turning it back again to the server. Thus, even a secure channel can be ruthlessly exploited.
The HTTPSession is created and managed by the J2EE server, and in all cases I know of, if you're using the J2EE container security system, it will be created even when you login, even if you store no objects in session scope. You can see this in that to logout, historically, you'd invoke session.invalidate().
So unless you're going with a pure ReST approach, you'd almost certainly be anchoring a stateful session EJB in an HttpSession object.
On the other hand, if you need a general-purpose session, for example, when providing services using non-J(2)EE servers, an EJB session object has the advantage that it doesn't depend on an HTTP environment.
I'm unclear who the "user" is supposed to be in the question. If it's the webapp, serving as the consolidated client for the various remote data sources, a stateful session EJB seems like a reasonable choice. Then again, potentially so does an application-scope J2EE object.
If, however, the "user" is the webapp's own remote users (clients), then the advantage is less clear to me.