Right, reversing those two gives a common structure:
jsp --> EJB (session bean) --> DAO --> hibernate --> DB
Do you need the EJB container? Tough call. Look at the features you get ... security, transaction management, public remote API, management APIs, etc. How much are those worth to you? Do you have the skills to do the EJB stuff without much pain or would getting started be a major hurdle?
I use a vendor framework that gets the benefits of the EJB container with minimal coding pain by having a single stateless session bean that acts as a gateway for all calls. Once you get through there it's POJO the rest of the way, so we have developed dozens of services with no particular EJB skills at all.
A good question is never answered. It is not a bolt to be tightened into place but a seed to be planted and to bear more seed toward the hope of greening the landscape of the idea. John Ciardi
Well I myself am new to EJB. Three quarters of the way through Head First EJB and planning to take the SCBCD exam shortly.
The reason I write is that I have grown slightly disheartened of late with my quest to learn about all things EJB.
Taking Stan up on his response, I also worked on a project where the architecture was such that you had a stateless session bean entry point and everything after that was delegated to POJO's. A Toplink layer provided the o/r mapping for persistence.
I am currently midway through the extensive Entity Bean chapters of my exam prep and I have began to question (a) Why am I studying something that seems to get bypassed all to regularly in favour of technologies such as JDO, Hibernate, Toplink etc, (b) Why am I studying an area that as I understand it was heavily revised between EJB specs 1.1 and 2.0 and will be again with 3.0.
Indeed, it seems to me that there is considerable discussion these days as to just how much value EJB adds. With books on the market such as 'Expert One on One J2EE Development without EJB', which comes from a seemingly highly regarded author, I'm really beginning to wonder.
Should I be focusing my energies on learning about the J2EE web tier instead. What future is predicted for EJB's? Will the industry start to look at alternatives for transaction management, security and everything else that EJB provides?
As I said I'm new to this so so any thoughts or inspiration would be much appreciated.
(a) Why am I studying something that seems to get bypassed all to regularly in favour of technologies such as JDO, Hibernate, Toplink etc (b) Why am I studying an area that as I understand it was heavily revised between EJB specs 1.1 and 2.0 and will be again with 3.0.
Not many really good reasons, but here there are few of them:
There will still be plenty of jobs out there for maintaining old ejb applications, or migrate them to newer technologies.
It will help you understand better the advantages provided by the new coming ejb 3.0 technology. It will help you understand better other distributed components based architectures.
There still are valuable concepts in ejbs 2.0 technology, like RMI/IIOP protocol, transaction isolation levels, clustered stubs, etc.
EJB is still a standard, while JDO, Hibernate, etc are proprietary solutions. They are open sources true, but still they are not standards.