Is learning EJB 3 worth it?

[Theodore Casser]

More just a general thought, but as the authors of a book on the latest verison are here, and there's doubtless going to be more attention in this forum for the week, I thought I'd pose the question. Is it worth learning EJB 3, or is it having it's last gasp?

Almost all of the applications I've developed since moving into the Java EE space have been servlet/JSP, with the few recent needs for something 'EJB-like' being taken up by Hibernate. And while the two have moved closer together, I'm still not convinced there's going to be much market up-take of the technology. Is there any sign that the trend towards avoiding EJB isn't continuing?

[Christophe Verré]

I think it's still worth learning it. Let's keep an open mind. After that, you could judge yourself if this is crap of not You have so many certifications, you can devote a little bit of time to the poor thing

[Mark Spritzler]

I think it is definitely worth it. I have been using it for almost a year now, and I love it. If you ever get to use JSF and now JBoss's Seam, you will find that using Session Beans and Entity Beans as JSF backing beans and Seam's conversational states will make Web development so much more easier.

It is just so much simpler, that it will be just like writing plain old Java objects.

Mark

[Theodore Casser]

Originally posted by Satou kurinosuke:
I think it's still worth learning it. Let's keep an open mind. After that, you could judge yourself if this is crap of not You have so many certifications, you can devote a little bit of time to the poor thing

I'm thinking of removing my certs from my sig, just because of comments like that.

It's not so much that I think that EJB is crap - I can certainly (especially after the SCEA) think of places where I'd use them. I'm just wondering if there's really all that much demand for it anymore, or if it's having its last gasp, to justify learning it.

As for JSF, I'm slowly learning that, if only because I suspect strongly that's going to come into play at my office eventually. An argument for EJB with Seam... I suspect that means I need to install more software at home to play with...

[clive jordan]

Hi Theodore,

I found myself asking a similar question. I decided to bite the bullet and learn EJB3.0, and thought I might as well get certified whilst doing it. Along the way, I learned an aweful lot about the J2EE platform but I confess to not even trying to apply EJBs to any of my commercial projects since becoming EJB certified. This is maily due to my work domain which lends itself better to Servlet/JSPs/JNDI and JDBC. I cannot justify the use of EJBs mainly because:

(1) I do not have massive database applications with thousands of transactions/day. Databases yes, huge ones, no. Webservices/SOAP/RPC serve me better.
(2) Speed. We need a high throughput and throwing more hardware at it is not an option. EJB comes at a cost.
(3) Large learning curve for new team members. EJB is not trivial.
(4) Writing EJBs is pretty straightforward, deploying them can be a real nightmare. If we had people whose whole job was only to deploy things, it may be different, usually you end up wearing many hats and have to know a lot about a lot! My brain is quite small, things fall out after a while.

In my opinion, EJBs bring many great things with them, transactional safety, declaritive security, decreased database lock-in and above all *abstraction*.

For my environment, the cost is too high to justify the benefits and yes, I confess to reinventing the wheel to claw back some of the benefits that EJB would provide.

If I worked in a hugely database intensive environment (banking, gambling etc), I would reconsider my options but for me, EJBs are not worth it.

I don't think learning is ever wasted, but with only a limited number of hours in the day, I guess we have to be picky what we learn!

Again, these are my humble opinions based on the area I work in, one size does not fit all !!

Cheers,
Clive

[Mike Keith]

Clive,

I am interested by your response, and hope that you don't mind if I ask you a question or two so that I can learn from what your experience was. We set out to make EJB 3.0 easy to use and attempted to reduce the learning curve. It sounds like you didn't find this to be the case. Can you elaborate a bit more on what parts you think are/were hard to understand for a developer?

Also, a Java EE architecture question, why is it that you did not want to use EJBs for component logic? Most people would want to separate their business logic from their request handling and presentation logic. Servlets and JSP are typically only the front end of the application, so was there a reason why you had to, or wanted to, put your business logic in these layers?

I don't know about other servers, but when we benchmark the Oracle EJB Container (OC4J) we get really good throughput numbers, and the container transactions can actually offer better performance than trying to hand code the transaction demarcation. Were there any real speed/performance issues or were you just expecting there to be some?

What were the deployment problems? What EJB 3 Container were you using? We have found that deployment is so much easier in EJB 3.0 because there are so many fewer mistakes that can be made. In our experience the defaults have made deployment a trivial exercise, but if there were problems in yours I would like to hear about them so that the next version of the spec could deal with them.

Thanks,
-Mike

[clive jordan]

Hi Mark,

Firstly, apologies for my not reading the question properly!. I was talking about EJB2.0, not EJB3.0 and yes, it was rather painful to learn. As I mentioned, I have a small brain! Perhaps EJB3.0 has solved many of the issue, I have not had the opportunity to check it out yet.

Issues that caused me many headaches were often around the edges, like the default security settings preventing RMI communications working out-of-the-box. I found little information about this in EJB literature (albeit not really an EJB problem, it would have saved many a headache!).

As for not using EJBs to encapsulate business logic and the use of servlets. Simple MVC allows easy seperation of business logic from presentation layers, without the need for complex frameworks.

Cheers,
Clive

[Alexandros Stivaktatis]

I share a similar experience. Learning EJB 2.1
was not a walk in the park, but the biggest
surprise came with the actual use, where
much that now has been solved with EJB 3.0
was putting pressure on the project.

Especially the extra coding and configuration
you need to do when you are not using simple
POJO's.

Bye,

Alex