When EJB?

[fixthebug2003]

Hi,
I am a little new to J2EE and Java World.
I have read about EJB a little bit. My Question here is When should one consider using EJB? Are there any scenarios when one should not use EJB's ? Can someone explain this in detail , with example.

Thanks
Fixthebug2003

 

[sedj]

If you want to run arbitrary, untuned sql against your database, and also want to slow your application down due to the multilayered data model that is EJB, then you should use EJB !

Otherwise, stick to a decent tech spec, a coherent business logic, and stored procedures.

--------------------------------------------------
Free Database Connection Pooling Software

http://www.primrose.org.uk

 

[fixthebug2003]

sedj,
You sounded like EJB is really not a good solution to any application. Well, then what is the advantage of EJB?

Fixthebug2003

 

[timw]

EJB is coming to be seen as a very heavyweight way of leveraging the J2EE functionality set. Most of the things it allows you to do are achievable without recourse to EJBs.

It is worth considering lighter-weight frameworks such as Hibernate and Spring which are both Open Source.

There is a useful book called 'J2EE Development Without EJB, Expert One-on-One' which may help explain this point of view, and is written by one of the creators of Spring.

EJB does certain things pretty well, such as Corba Remoting, Message Handling and Distributed Transactions. EJBs can get very complicated though, and there are a whole host of separate design patterns which try to compensate for this. If you don't need any of the aforementioned functionality don't use EJBs.

 

[sedj]

EJB (IMO) is just a wrapper of a wrapper. OK, so it means you can build a data model that is mapped to your transaction layer, but I think its just way toooooo out there. I think you are much better off keeping things simple, and as unwrapped as possible. Plus, EJB trys to do a lot of things databases were MADE for - such as indexing, joining tables etc, which is just daft considering its mch more efficent to do such things in a tuned db procedure. And don't even get me started on EJB-QL !

--------------------------------------------------
Free Database Connection Pooling Software

http://www.primrose.org.uk

 

[timw]

All valid considerations IMO.

Another thing is scalability. Everyone thinks of 'scaling up' when this is mentioned, and EJB container providers certainly go to pains to market their product's ability in this area.

But what about scaling down? If you've implemented an application with EJBs and suddenly need to deploy to single seat customer, you've got to run the EJB container and everything else all on one machine. It's way overkill. EJBs don't scale down!

 

[sedj]

Another Christmas Eve worker timw ? Soon be lunchtime.

Sacaling up/Scaling down. I can't stand these terms personally. What does *scaling up* or *scalibility* really mean ? How can EJB be more scalable than a well thought out business logic coupled with a few core data objects (home grown) and a db transaction layer based on stored procedures ? Beats me. I'm not being sarcastic - can someone please enlighten me ?!

--------------------------------------------------
Free Database Connection Pooling Software

http://www.primrose.org.uk

 

[timw]

Alas, yes .. I'm sat here at my desk and lunctime is still 4 hours away.

Mmmm. Quick answer...I believe EJB cannot be more scalable than well thought out business logic .. etc.

IMO EJB seems to target a (perceived?!) need to gather all the J2EE API together and abstract it another level (your extra wrapper layer sedj).

At first glance (especially if you're using a swishy tool like JBuilder) EJBs appear to make life a whole lot easier. You get declarative transaction handling and other goodies....

To programmers starting out with J2EE (and I don't consider myself an expert in this), some things are hard and EJBs can look attractive because they do a lot of it for you ... One sting in the tail is that this separation restricts control over the underlying J2EE functionality and I think that nowhere is this felt more than in the DB layer.

Programmers with a good deal of expertise in DB coding are going to have difficulty with accepting EJBs. I personally think that Entity Beans are the weakest part of EJB.

However - Implementing your own db layer has its advantages, but what about the added design / implementation complexity needed if you are forced to cope with 'DB Independence' requirements by your all-knowing bosses?