Make your web session aware or your EJB a stateful session aware - discuss

[Luke Murphy]

Ok so you have a use case where information is passed across multiple requests from the user - the classic buying books on amazon, putthing them into your cart and committing at the end.

Somehow you need to maintain your information.

some options:

1. Use a managed bean with session scope. This doesn't even require a stateful session bean.
2. Use a stateful session bean.
3. use another framework such as SEAM.

I favour approach one. It just means you need to re attach things to the EntityManager.

Your thoughts --

This is a general architecture question. Mods, you can move it to another forum if you want.

[Srinivasan Rengan]

I have the same quesion in my mind.

Thinking about it, If we have only HTTP based client (not any other non HTTP clients) accessing the business component, then we can maintain state in HttpSession.

This is a point on which most of the websites concur upon too..

But ,would be watching this thread for further inputs on this..

[Jeanne Boyarsky]

I would definitely not use stateful session beans - either on the exam or in real life. And I wouldn't consider SEAM (or any proprietary framework) on an exam about pure JEE.

[Tirumal Reddy Moolamalla]

I agree. But i have one doubt regarding usage of stateful session beans for the given use case.

As this requirement is related to shopping cart (online). We can assume certain default non functional requirements. If we dont use EJB's for this use case then we need to handle transactions and state on our own, where as the very basic purpose of EJB stateful session bean is this.

please validate my understanding.

Regards,
Tirumal Reddy M

[Luke Murphy]

Tirumal Reddy Moolamalla wrote:I agree. But i have one doubt regarding usage of stateful session beans for the given use case.

As this requirement is related to shopping cart (online). We can assume certain default non functional requirements. If we dont use EJB's for this use case then we need to handle transactions and state on our own, where as the very basic purpose of EJB stateful session bean is this.

please validate my understanding.

Regards,
Tirumal Reddy M

For the online shopping cart, I would use JSF - Managed Bean (Session scope) - stateless session bean. All this means is you have to reattach entities if you are using an injected entity manager.

The design trade off as I see it is:

stateless session bean - means you have to keep re attaching entities.
stateful session bean - you don't have to re attach entities but you don't get the same scalability characteristics.

That's how I see it.

Anyone else?

[Jeanne Boyarsky]

Tirumal,
Stateful or stateless beans handle transaction support and non-functional requirements like security. State is not a non-functional requirement. It can be handles with a HttpSession just as easily as a stateful session bean. And be more efficient.

[Srinivasan Rengan]

Jeanne, no one can deny the scalability efficiency of stateless session bean. But i was wondering if this has a bold in the blue point about session management:

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

Under the section ( Web-Tier State Recommendations in the above link) and further down, the recommendation has been in favour of SFSB.

Would invite your comments on the same.

Srini

[Luke Murphy]

Srinivasan Rengan wrote:Jeanne, no one can deny the scalability efficiency of stateless session bean. But i was wondering if this has a bold in the blue point about session management:

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

Under the section ( Web-Tier State Recommendations in the above link) and further down, the recommendation has been in favour of SFSB.

Would invite your comments on the same.

Srini

That's a very good link and certainly would make you think about things.

If you use a stateful session bean is there any point in making your managed JSF beans (i.e. your backing beans) have session scope?

[Srinivasan Rengan]

Hey Luke!!

Take for instance a shopping cart app. I may have a state object (in form of Order or Cart etc etc) specific to the implementation. Keeping this as part of the SFSB would make my managed bean thin.

But my application might have other state information which might not need a SFSB. For instance: I might maintain a login authentication code or attribute. This might not actually make my managed bean fat.

This is purely my perception and I am happy to hear that it is wrong too!!

Thanks
Srini

[Luke Murphy]

Srinivasan Rengan wrote:
This is purely my perception and I am happy to hear that it is wrong too!!

Thanks
Srini

I agree. However what is missing from the JSF / EJB world is some details on best practises. There are obviously cases when you should:

1. Make JSF backing bean fat, SF SB
2. Make JSF backing bean fat, Stateless SB
3. Make JSF backing bean thin, SF SB
4. Make JSF backing bean thin, Stateless SB

For me 4 is obvious. 1,2,3 not so obvious.

[P Das]

From the current listing of the thread, we should respond from SCEA perspective only.

Accordingly, the questions crop up:
1) If we don't use stateful EJBs for maintaining conversational states, what are they doing in EJB specs?

2) The given example (shopping cart) requires quite a few crosscutting concerns to be fulfilled; if we don't answer q.#1 above in favor of stateful EJBs, who does the scaffolding and at what cost? In other words, how to justify the extra cost of development/maintenance, not to talk about cost of suspect quality for non following standards.

3) Is there any indication that I missed out in the short description that goes against using stateful EJBs?

4) If performance is an issue--somehow I tend to 'sense' this could be the bone of contention--why not use clustering*? Again, with stateless EJBs clustering would be of little use; isn't it?

(*) The shopping cart example might also require failover; hence, clustering is doubly indicated.

[Luke Murphy]

Ok been doing some thinking about this. To answer my own question...
In general I believe it is based to use a fat JSF backing bean to store presentation logic and state and to store business logic and state in the a stateful session bean.

Luke Murphy wrote:
1. Make JSF backing bean fat, SF SB

Presentation state and business state required.

2. Make JSF backing bean fat, Stateless SB

Presentation state required, business state not required.

3. Make JSF backing bean thin, SF SB

No presentation state required, business state required.

4. Make JSF backing bean thin, Stateless SB
[/QUOTE[
No presentation or business state required.

Now, you may be saying bu8t sure you can store business state in the HttpSession, ManagedBean.
Of course you can.

But is this good separation of concerns?

Maybe in a web centric architecture you could make arguments for such but in a EJB centric architecture no way.

It would be the same as storing presentation logic / state in the stateful session bean.

Yuke.

[Henry Naf.]

I am leaning to go with the Statefull Session Bean for session management. The key questions for me, in my decision were the following:

* Stateful session bean
Advantages:
1. It supports transaction service, security service, thread safety- so one need not to write code for these services.
2. Both web based and non-web based clients can use it, so we don't have to re-achitect our solution of other possible front end.

Disadvantages:
1 Performance: since it supports a number of services described above it takes more time to process a request.


Http Session object
Advantages:
1. It is a simple java object so takes very less time and resources to maintain a client state also easy to code.

Disadvantages:
1. It does not support the features described above you have to code for that features, at which point, the performance advantage might be lost...
2. only web clients are supported.

Thoughts/ comments?