• Post Reply Bookmark Topic Watch Topic
  • New Topic
programming forums Java Mobile Certification Databases Caching Books Engineering Micro Controllers OS Languages Paradigms IDEs Build Tools Frameworks Application Servers Open Source This Site Careers Other Pie Elite all forums
this forum made possible by our volunteer staff, including ...
Marshals:
  • Campbell Ritchie
  • Ron McLeod
  • Paul Clapham
  • Devaka Cooray
  • Tim Cooke
Sheriffs:
  • Rob Spoor
  • Liutauras Vilda
  • paul wheaton
Saloon Keepers:
  • Tim Holloway
  • Tim Moores
  • Mikalai Zaikin
  • Carey Brown
  • Piet Souris
Bartenders:
  • Stephan van Hulst

Session state management

 
Ranch Hand
Posts: 86
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
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
 
Ranch Hand
Posts: 317
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

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






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.
Coming back to the non web apps (swing etc), you have 2 choices, one is maintaining session in ejb layer or you can maintain it on the client side itself..maybe the business delegate caches the information pertaining to that client etc..I guess the choice is urs, the same non-technical "-ities" (performance, scalability etc) will come into contention and will influence your choice to a larger extent.
As far as security is concerned, I would personally go for container managed security and leave it at that. Session storage mechanisms wouldnt be affected how you manage your security needs.
So, personally, what I would do is explore session management techniques on the client (swing) tier and see how it affects performance, scalability etc and compare it with storing it on the session ejb tier (i.e. what possible features can I get by using ejb containers) and then choose either of the session management mechanisms.

hope this helps..and more importantly, I hope I understood your question

Parag
 
Tomi Tuomainen
Ranch Hand
Posts: 86
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
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
 
Parag Doshi
Ranch Hand
Posts: 317
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

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



I agree with you too and there are basically 2 ways, which we can go and we would have to strongly emphasise on that. if we go the ejb session management, we should put more leverage on best practices, scalability, more container resources etc. if we go the client session management, we can put the case across as choosing performance over scalability (no remote calls for session data etc) and as the number of swing users are less than 25, scalability really doesnt seem to be an issue. for the web clients, httpsession is the clear winner..u can pick up a page full of advantages from their blue prints itself
I think session management on the ejb layer has got its own issues and flaws, and if we justify that swing client are the best place to maintain session state, i dont think the SUN examiner should have offence to that. We can even quote a line from the blue print doc stating that there are *preferred* methods of doing things, but which method is chosen is driven by the needs of the system rather than theoritical best practices

parag
 
Ranch Hand
Posts: 1419
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Parag Doshi wrote:

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.



Parag,

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,

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).



The following section, 4.4.7.4, says:

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.



Another book, Core J2EE Patterns, refuses to advocate one over the other. Pages 48-49 discuss keeping session state on the EJB tier, then refers to an earlier discussion about keeping it in the Presentation (web) tier. Refusing to give a clear preference where both options are available it says,

"A full-scale discussion is outside the scope of this book, since the problem is multi-dimensional and depends very much on the deployment environment including:
  • Hardware
  • Traffic management
  • Clustering of Web container
  • Clustering of EJB container
  • Server affinity
  • Session replication
  • Session persistence

  • [ August 03, 2004: Message edited by: Frank Silbermann ]
     
    Parag Doshi
    Ranch Hand
    Posts: 317
    • Mark post as helpful
    • send pies
      Number of slices to send:
      Optional 'thank-you' note:
    • Quote
    • Report post to moderator


    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...



    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
     
    Ranch Hand
    Posts: 53
    • Mark post as helpful
    • send pies
      Number of slices to send:
      Optional 'thank-you' note:
    • Quote
    • Report post to moderator

    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



    http://java.sun.com/blueprints/guidelines/designing_enterprise_applications_2e/web-tier/web-tier5.html#1083750

    See 4.4.7.2.1 How the Web Container Manages Session State
     
    Tomi Tuomainen
    Ranch Hand
    Posts: 86
    • Mark post as helpful
    • send pies
      Number of slices to send:
      Optional 'thank-you' note:
    • Quote
    • Report post to moderator
    Thanks Frank for comments. This issue certainly must be studied more...

    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.



    If requirements state that application server and web server are different machines, local interfaces won't help us much (-> distributed architecture).



    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.


    I don't quite follow here. Do we need to create threads for handling session states?



    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.


    HTTP over SSL should support sessions. I'm not familiar with the details here.. is this support actually somehow "worse" than using stateful session beans?



    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.


    This is true, handling sessions in EJB tier for different client types makes sense. But if I have Request Intercepting Filter, Front Controller and Screen Flow Manager in my Web tier, I must handle session state already in my web application, right?

    Cade doesn't describe sessions in the example solution. I wonder if people have passed SCEA just by stating: "presentation tier maintains sessions".

    Tomi
    [ August 03, 2004: Message edited by: Tomi Tuomainen ]
     
    author
    Posts: 3252
    • Mark post as helpful
    • send pies
      Number of slices to send:
      Optional 'thank-you' note:
    • Quote
    • Report post to moderator

    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.

    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).

    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.

    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.

    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.

    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.

    - Peter
    [ August 03, 2004: Message edited by: Peter den Haan ]
     
    Parag Doshi
    Ranch Hand
    Posts: 317
    • Mark post as helpful
    • send pies
      Number of slices to send:
      Optional 'thank-you' note:
    • Quote
    • Report post to moderator
    It seems that the choice of HTTPSession or Stateful Session Beans is not as simple as it sounded before. The choice is highly debatable on both ends and I guess at the end of the day, we might have to choose one over another or choose both and justify the choice.
    I am leaning more towards a combination of both kind of state management techniques for the web app and client side state management for the non-web app.

    Parag
     
    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
    reply
      Bookmark Topic Watch Topic
    • New Topic