Hi. I'm not going to ask you about the next steps in the next EJB specification since this article Mike Keith on EJB 3 do this. But do you think that EJB is a specification in jeopardy ? (Richard Monson-Haefel said, the whole JEE platform in jeopardy) ? In jeopardy here means, it will not be popular,it will be used widely amony the developers. Yes sure, EJB still has its -strong cards- especially in message-oriented applications or distributed transactions. But Hibernate and Spring really raised the bar so high and EJB may not be able to catch them. Please don't get me wrong, I like EJB and I wrote some of them (since EJB2.0 specifications), but you as an author who wrote a book about EJB means you still believe in EJB. So do you think EJB could come up for a breath of fresh air ? Thanks.
I would say "EJB 3 is the savior!". Prior to release of EJB 3/Java EE 5, EJB 2 /J2EE were indeed in jeorpardy!. I criticized J2EE for its complexities in many of my blogs and articles. I strongly believe that EJB 3 has the power to save the diminishing Java platform.
The question you ask clearly has no black and white answers. Truth be told, only you can be the ultimate judge of this question.
EJB 3 has all the goods to meet and exceed the demand of Java EE developemt simplicity and elegance. However, I don't think it's going to be easy to get over the EJB 2 quagmire. It really depends on whether people are compelled to take a good look at EJB 3 and not prejudge based on what was true in the past.
I was kind of getting impressed by the architectural changes in EJB3.0 compared to EJB2.0, after going through Mike Keith's JPA book, but then I came across the complexity in annotations - so many of them. I think if there was a way to simplify this, that would have been of great help. I understand it is a framework specs and it has to accomodate everyone's needs, has to accomodate all kinds of relationships, etc.
I definitely liked the conceptual changes in EJB3.0; in a way these changes aligned EJB3.0 with other event-driven framework's backend, like keeping one request in one JVM (no need of remoting), having only POJO entities (no entity beans), etc.. Hence the learning curve will not be that steep if one is familiar with any such framework's backend.
Even though EJB 3.0 has simplified things , organizations haven't forgotten the complexities of EJB 2.x and may be they are hesitant to move to new version.And also many have moved to Spring,Hibernate frameworks and may not have compelling reasons for switching.
Even though EJB 3.0 is standard many would argue that frameworks like Spring,Hibernate work on any application servers and possibly with little porting involved.
I was kind of getting impressed by the architectural changes in EJB3.0 compared to EJB2.0, after going through Mike Keith's JPA book, but then I came across the complexity in annotations - so many of them. I
Is it just the number of annotations that cause concern ? If I am not wrong one can just use default values for many of them.
Interesting topic. Hibernate et al address the entity bean part of EJBs. EJB 3 moves to the JPA spec (which Hibernate implements.) So it seems like they are getting the controversial part out of EJB leaving it to be session beans and MDBs.
After going thru the discussions i want to know is it worth going thu EJB2.0 at all. Should'nt I jump to EJB3.0 straightaway?
I feel that it is still useful to know about 2.0, as there are lots of jobs using it. 3.0 is still fresh. Whether or not to take the certification depends on people though. If you're working as a programmer, you may find it useful to know about it.