• Post Reply Bookmark Topic Watch Topic
  • New Topic
programming forums Java Mobile Certification Databases Caching Books Engineering Micro Controllers OS Languages Paradigms IDEs Build Tools Frameworks Application Servers Open Source This Site Careers Other Pie Elite all forums
this forum made possible by our volunteer staff, including ...
Marshals:
  • Campbell Ritchie
  • Jeanne Boyarsky
  • Ron McLeod
  • Paul Clapham
  • Liutauras Vilda
Sheriffs:
  • paul wheaton
  • Rob Spoor
  • Devaka Cooray
Saloon Keepers:
  • Stephan van Hulst
  • Tim Holloway
  • Carey Brown
  • Frits Walraven
  • Tim Moores
Bartenders:
  • Mikalai Zaikin

should we use EJB ?

 
Ranch Hand
Posts: 472
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
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 ...
 
Ranch Hand
Posts: 1683
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
DAO hides the implementation of your persistant store from your business logic, so cannot come before your session beans.
 
(instanceof Sidekick)
Posts: 8791
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
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.
 
Greenhorn
Posts: 5
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
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
 
Greenhorn
Posts: 1
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
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
 
Ranch Hand
Posts: 704
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
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.
     
    Consider Paul's rocket mass heater.
    reply
      Bookmark Topic Watch Topic
    • New Topic