I have some doubts regarding the proper usage of stateless session beans.
My application has a 'session facade' for receiving all external requests. After receiving requests, the facade interacts with 3 other state less session beans(individual components - each having a distinct functionality) to service the requests. And, each of these individual session bean components can interact with one or more entity bean for DB access/updates.
That was my application design - untill I got this doubt:
Why should I use stateless session beans for those individual components ?
why can't they be plain java classes that access the entity beans(just like the session beans where accessing before)
By this, I can avoid a JNDI lookup from the facade - each time I want to access the individual components.
I'am not sure of the negative effects this may have - related to transactions/scalability..,,.
So, I would be happy - if some one can contribute their opinion in this regard.
Thanks in advance,
You've asked the very question many J2EE developers and architects have been asking for some time now. Why SLSBs? Indeed, why EJB at all. You use of entity beans is probably more questionable than your use of session beans! Rod Johnson's book J2EE App Dev Without EJB is a good guide to this area.
In a nutshell, you have to ask what do your session beans give you? e.g. CMT, Remoting, Clustering, Resource Management, Security etc. Are you using these services? If so, is it worth the overhead of accessing the EJB?
If only more developers asked this very question. We generally use SLSBs for their CMT only. Hence they become mere fascades for an underlying data access tier. I would rather we dumped them completely and did programmatic transaction management, or used some other container but developers seem to think their CVs will suffer if they don't use EJBs. Fools.