Win a copy of The Little Book of Impediments (e-book only) this week in the Agile and Other Processes forum!
  • Post Reply
  • Bookmark Topic Watch Topic
  • New Topic

SCEA part 2 - class diagrams and carts

 
Abhaya Rajakarunanayake
Greenhorn
Posts: 11
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Hi Good people at the Ranch,

I am working on my assignment at the moment and have two queries which I hope you guys can help me put to rest.

1. Instead of a single class diagram, I have divided my classes in line with the tiers - web, services and domain. This way I can show, not only my improved domain model but also the service classes comprising the facades etc. IMHO this presents a clearer view to the examiner rather than just the domain objects and a few controller and managers. Any thoughts?

2. In order to future proof my SuD, I have decided (for the moment ) to have my shopping cart as @Stateful. My question is, should the session facade controlling access to this Bean also be @Stateful? At the moment it is @Stateless.

Thanks
Abhaya
 
Jeanne Boyarsky
author & internet detective
Marshal
Posts: 35279
384
Eclipse IDE Java VI Editor
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Abhaya,
1) This is fine. I split my class diagram into two. (Entities and everything else.)
2) A stateless bean shouldn't be calling a stateful bean.
 
Abhaya Rajakarunanayake
Greenhorn
Posts: 11
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Jeanne, Many thanks for this. I do have one follow up question though.

If the session facade is stateful, is it the handle of the session facade that I need to store in my HttpSession? This would seem to make sense to me, rather than the handle for the shopping cart itself.

Abhaya.
 
Unni Pillai
Ranch Hand
Posts: 35
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator

Hi,

I am also confused at same point. Which component is best to call a statefull session bean? as per my design a http servlet will be calling a statefull bean. Here I am using service loacator pattern as well(to find the ejb). After that it will store the interface(handle) to http session.


Is it make any sense?

Abhaya, Is your thought process same?

Thanks,
Uma

 
Abhaya Rajakarunanayake
Greenhorn
Posts: 11
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Hi Uma,

I think the Biz Delegate should talk to the stateful bean (session facade). I would have some indirection between the servlet and EJB (hence the delegate). This keeps things clean and also shows you know your JEE patterns. It has quite a few other benefits as well.

1. Why use locater when you have Resource Injection?
2. EJB3 does not have handles similar to 2.x

Abhaya
 
Jeanne Boyarsky
author & internet detective
Marshal
Posts: 35279
384
Eclipse IDE Java VI Editor
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Abhaya Rajakarunanayake wrote:If the session facade is stateful, is it the handle of the session facade that I need to store in my HttpSession? This would seem to make sense to me, rather than the handle for the shopping cart itself.

I think so. I've never had the need to use a Stateful bean in practice. One thing I don't get: if you have a HttpSession, why do you need the stateful bean? You already have a place to keep state - the HttpSession.
 
Abhaya Rajakarunanayake
Greenhorn
Posts: 11
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Jeanne Boyarsky wrote:
Abhaya Rajakarunanayake wrote:If the session facade is stateful, is it the handle of the session facade that I need to store in my HttpSession? This would seem to make sense to me, rather than the handle for the shopping cart itself.

I think so. I've never had the need to use a Stateful bean in practice. One thing I don't get: if you have a HttpSession, why do you need the stateful bean? You already have a place to keep state - the HttpSession.


Ah yes, the question everybody asks. Well, given the description of my assignment, I thought I'd future proof my solution so that the application can be opened up to different channels. I am thinking of a call centre application for example which would have a different Java client. This way, you are re-using a key component as well as keeping your business logic away from the web tier. Also - @Statefuls are more transaction aware - they can roll back if thing go up in the air (according to what I've read).

overkill? possibly at this point but who knows where the business will be in the future with a 200% annual growth in the industry! Do you think that is a compelling argument?
 
Jeanne Boyarsky
author & internet detective
Marshal
Posts: 35279
384
Eclipse IDE Java VI Editor
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Abhaya Rajakarunanayake wrote:overkill? possibly at this point but who knows where the business will be in the future with a 200% annual growth in the industry! Do you think that is a compelling argument?

I think it is overkill. That doesn't make it wrong, but it is possible to future proof too much.
 
Sharma Ashutosh
Bartender
Posts: 346
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
You have to use either SFSB or HttpSession for the session management.
Yes you can use both - but it's just over engineering and sort of overkill.
 
  • Post Reply
  • Bookmark Topic Watch Topic
  • New Topic