Hello Ranchers, Can we call a stateless session bean from a StatefulBean. I want to implement my DAO (EAO) as a stateless bean and shopping cart is a stateful bean. Can we use DI to inject stalessBean in Stateful. Please let me know if this architecture makes sense.
For the SCEA exam, I think you'll want to be able to diagram that relationship. I think going down to the part for dependency injection is definitely to low a level of detail for the exam, but regardless, it would definitely work.
I doubt I'd use a stateful session bean if I had a web based client. I'd probably want to shift the burden of state management to the HttpSession, but it's just an alternative.
You use dependency injection to get rid of service locator. This needs to come out in some form in your architecture.This will also play a role in deciding whether your calling client is a managed component. So is DI a low level detail?
Joined: May 28, 2008
Cameron, Thank you for the reply. So having the shopping cart as a stateless session bean and maintaining the state with HTTPSession on the web-tier is a valid implementation? The EJB spec says to implement the shopping cart as a StatefulBean. The Java Petstore reference implementation 1.1 has the same logic. I don't have any handson with either technology, I'm just following the literature from Core Patterns and EJB Spec.
Pratik, I have a business delegate and a service locator in my design. Now that I can use DI, I was thinking of just using JSF Backing bean instead of a Business Delegate. [ September 07, 2008: Message edited by: Rama Zha ]
Joined: Jun 28, 2008
You donot need a business delegate and service locator as long as your calling client is a managed component(servlet/JSF managed bean). You can introduce a business delegate if you want to introduce flexibility of using a single business layer interface for multiple types of clients (both managed and unmanaged-swing based).
I doubt this architecture you plan to use (DAO's as Stateless Session Beans) makes sense... Here's what I think:
We should use the Session Bean component model to benefit from the advantages provided by the EJB container, right? I will list here some of these advantages. Do you really need them? If not, why using such a complex model? I would rather implement the DAO's as POJO.
- distribution Do you plan to distribute your DAO's?
- transaction management Do your DAO's are aware of transactions? Usually, this would be the Session Facade responsibility...
- thread management / instance pooling Do you need instance pooling for your DAO's? Aren't they just some very light objects?