aspose file tools*
The moose likes EJB and other Java EE Technologies and the fly likes should we use EJB ? Big Moose Saloon
  Search | Java FAQ | Recent Topics | Flagged Topics | Hot Topics | Zero Replies
Register / Login
JavaRanch » Java Forums » Java » EJB and other Java EE Technologies
Bookmark "should we use EJB ?" Watch "should we use EJB ?" New topic
Author

should we use EJB ?

Nakata kokuyo
Ranch Hand

Joined: Apr 13, 2005
Posts: 442
hi , good day everyone , we are developing a new system , this system is some kind related on supply chain ..

our planned system architecture for the system , will be
jsp --> DAO --> hibernate --> DB

however , there have some suggestion that we should adopt the following achitecture

jsp --> DAO --> EJB (session bean) --> hibernate --> DB

as i'm new to EJB , can anyone suggest pro and cons of the suggested architeture ...

thank you very much for your valuable comments ...
Roger Chung-Wee
Ranch Hand

Joined: Sep 29, 2002
Posts: 1683
DAO hides the implementation of your persistant store from your business logic, so cannot come before your session beans.


SCJP 1.4, SCWCD 1.3, SCBCD 1.3
Stan James
(instanceof Sidekick)
Ranch Hand

Joined: Jan 29, 2003
Posts: 8791
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
Joe Miller
Greenhorn

Joined: Jul 13, 2000
Posts: 5
Another specific consideration to add to Stan's response is if you think you'll need message-driven bean functionality with JMS then you'll need EJB.

Joe
Nick Cartwright
Greenhorn

Joined: Apr 18, 2005
Posts: 1
Hi folks,

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.

Regards
Valentin Tanase
Ranch Hand

Joined: Feb 17, 2005
Posts: 704
Hi Nick,


(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.


  • Regards.


    I think, therefore I exist -- Rene Descartes
     
    I agree. Here's the link: http://aspose.com/file-tools
     
    subject: should we use EJB ?