Originally posted by Tomi Tuomainen:
Supposing we have a typical shopping cart application with Web tier, EJB tier and Swing client... Does EJB tier need to manage any session information or can we let the clients (web app, swing) handle it?
To gain more security we could use disposable passwords and check the session everytime in EJB tier (from database or by using stateful session beans). But if we are dealing with a shopping cart or a reservation system, maybe container managed user/password over ssl is enough for authentication? In this case, is there any reason for us to manage sessions in EJB tier?
Any comments appreciated...
Tomi
Originally posted by Tomi Tuomainen:
Thanks Parag (again) . Using stateful session beans to handle user session is considered J2EE best practise in many sources. But on the other hand there's a lot talk about poor performance/scalability with stateful session beans. If HTTPSession is preferred way, maybe Swing client should take care of its session too (that is quite straightforward choice because of event-driven nature).
Again we face this problem: more common parts for different client types -> more manageability but possibly less performance/scability. But it's quite obvious what my assignment emphasizes... So I just wanted to be sure, that it's not J2EE "bad practise" to let clients (swing, web application) take care of sessions. Please comment if you disagree!
Tomi
According to the J2EE blue prints, they recommend storing session state on the ejb tier (by using stateful session beans) for non-http clients. if you are using a web client, then the web tier offers better session management thru the usage of HTTPSession interface.
When using enterprise beans, it's best to maintain session state with stateful session beans in the EJB tier. For Web-only applications, maintain the state in the Web tier as session attributes (using HttpSession).
Maintaining session state in stateful session beans is a BluePrints best practice. Web-tier components can access the session state through the stateful session bean's component interface and store just the reference as a session attribute. You can maximize the runtime performance of this approach by choosing a J2EE server product that permits use of local EJB interfaces from co-located Web components.
Reasons to prefer stateful session beans over other approaches to maintaining session state include:
Thread safety--Enterprise beans are thread-safe. By contrast, sophisticated thread-safe servlets are difficult to write.
Lifecycle management--The EJB container manages the lifecycle of enterprise beans components, automatically creating new instances, and activating and passivating instances as necessary to optimize performance.
Client type neutrality--Enterprise beans can be accessed, either directly or through some sort of adapter, from multiple client types. This contrasts with HTTP session attributes, which are available only to HTTP clients.
For example, the sample application stores session state in stateful session beans ShoppingClientControllerEJB and EJBClientControllerEJB.
Can you give me a reference into the BluePrints where it recommends keeping session state in the web tier even when using implementing a web application's business logic via EJBs? I cannot find it. In fact, in
the BluePrints book Designing Enterprise Applications with the J2EE Platform, Second Edition, section 4.4.7.3 Web Tier State Recommendations, it says...
Originally posted by Parag Doshi:
Frank,
I am trying to find that webpage where I had read it. The one thing i noticed was that I was looking at the First Edition of the blueprint..might not mean anything, but just an observation.
Parag
Originally posted by Frank Silbermann:
You can maximize the runtime performance of this approach by choosing a J2EE server product that permits use of local EJB interfaces from co-located Web components.
Reasons to prefer stateful session beans over other approaches to maintaining session state include:
Thread safety--Enterprise beans are thread-safe. By contrast, sophisticated thread-safe servlets are difficult to write.
Lifecycle management--The EJB container manages the lifecycle of enterprise beans components, automatically creating new instances, and activating and passivating instances as necessary to optimize performance.
Client type neutrality--Enterprise beans can be accessed, either directly or through some sort of adapter, from multiple client types. This contrasts with HTTP session attributes, which are available only to HTTP clients.
I can understand your confusion, Frank. IMHO this is just a load of FUD. The idea that EJBs are easier to write than threadsafe servlets is ludicrous (and if I need to I can always weave in a Spring pooling aspect; but that's another discussion entirely and nothing to do with the SCEA exam).Frank Silbermann quotes from Designing Enterprise Applications with the J2EE Platform, Second Edition:
Reasons to prefer stateful session beans over other approaches to maintaining session state include:
Thread safety--Enterprise beans are thread-safe. By contrast, sophisticated thread-safe servlets are difficult to write.
In the same way, the web tier can passivate and activate session data. In fact, although it certainly isn't the party line, many say maintaining state in the web tier is more scalable than maintaining it in the EJB tier. Myself, I'm not so sure; this may be true for individual implementations, but I don't see any a priori reason why HttpSessions should be significantly more scalable than SFSBs or vice versa.Lifecycle management--The EJB container manages the lifecycle of enterprise beans components, automatically creating new instances, and activating and passivating instances as necessary to optimize performance.
Granted. In a world with WS, XML-RPC and Hessian/Burlap the HTTP tier is quite open to multiple client types as well, but the EJB tier has the edge.Client type neutrality--Enterprise beans can be accessed, either directly or through some sort of adapter, from multiple client types. This contrasts with HTTP session attributes, which are available only to HTTP clients.
Peter den Haan | peterdenhaan.com | quantum computing specialist, Objectivity Ltd
Bring me the box labeled "thinking cap" ... and then read this tiny ad:
Gift giving made easy with the permaculture playing cards
https://coderanch.com/t/777758/Gift-giving-easy-permaculture-playing
|