EJB 3.0 in a Nutshell

Rusty Nuts writes "JavaWorld has a great article on the future of Enterprise JavaBeans (EJB). Are you frustrated learning EJB 2.1 or already know EJBs but loathe its complexities? Hold on a bit more for the the future of EJBs is looking brighter for you."

Comments

Book recommendations

[LizardKing]

I'm quite happy with using Java Servlets and JavaServer Pages - they're great technologies that clearly address shortxcomings on what came before.

However, Enterprise Java Beans make my brain ache. I've tried reading a couple of books that had reasonable reviews on Amazon, but I've still not got much confidence that I could use them well. Can anyone recommend some decent books on EJB's, or is it not worth the bother?

Re:Book recommendations

[bay43270]

You should be happy using servlets and jsp. Together, they provide you with most of the functionality you will ever need. Most companies switch to J2EE because IBM and Bea spend a lot of money pushing it. They think they need J2EE for these features:
- Transactions
- Persistance
- Security
- Scalability

Transactions (like the servlet api) are provided via an API subset that you can add to any program (J2EE or otherwise).

The J2EE persistence layer is almost silly. It would take a bit of writing to explain the historical reasons for the mistakes, but essentially Entity Beans were made to fulfill a need that no one had (client side references to server side persistable objects). Sun then changed their mind as to what need they filled (they are now simply a persistence model), and then kept making improvements to compete at this new task. Almost any other persistence model runs as well and they are all less complicated. J2EE 3 promises to improve on both fronts, but by leaving backwards compatibility, they haven't really reduced the learning curve much.

J2EE also has method level declarative security. Since the declarations are in the deployment descriptor, their not really dynamic. This isn't anything really exciting either.

Scalability is a bit difficult to argue. The lighter weight alternatives to J2EE (servlet containers, Spring, etc.) may scale to a decent size, but I haven't seen any example of huge applications being run with these solutions. If anyone hears of an Ebay sized app running on a Tomcat cluster, please post.

If you really want to learn EJB still, I would look for an entry level J2EE job. The books explain the implementation details, but I have yet to see any give honest explanations of when you should use parts of J2EE and what their limitations are.

Re:Book recommendations

[chochos]

You should be happy using servlets and jsp

Um, no thanks. JSP sucks. Having code in the UI layer is a big no-no. JSP's are hard to maintain. I agree with you that J2EE persistence with EJB's sucks, but you can certainly do a lot better than jsp and servlets.

Check out Tapestry, a much better way to write web apps than JSP, using MVC so that your html page is just an html with certain id's on some tags, and you have components that can be placed inside other components to make up a page. Or use Struts. Or Velocity. Or Turbine. But please, if you can avoid plain JSP's, then stay away from them. They lead to all kinds of nastiness in your apps.

That, together with other projects like Hibernate, which is a very good persistence layer (so good that it's going to become the new JDO; they're already adopting HQL for the new EJB persistence) and Spring, which you already seem to know, you can build much more elegant apps than using JSP and servlets.

Re:Book recommendations

[ekuns]

The most obvious reason for using J2EE that I can see (perhaps the only reason for the great majority of apps) is JMS. Other than that, most of the J2EE stuff is much too heavyweight for most applications.

Re:Book recommendations

[chez69]

with struts I've been able to have no code in my JSPs at all. it's not that hard, you just have to spend more time designing it.

I'm not attacking your or making any claims about your skill level. Slashdot is a festering buch of he said she said bullshit and I want to make sure folks are clear.

happy java coding!

Re:Book recommendations

[bay43270]

J2EE isn't a prerequisite for jms

Re:Book recommendations

[bay43270]

In typical slashdot fashion, you've taken my comment totally out of context (and removed the context so no one would notice). I was trying to point out the huge overhead of J2EE, and how a lighter framework is more useful in most situations. You only proved my point further by suggesting even more useful lightweight frameworks.

You are right, in that JSP isn't the cleanest solution. Tapestry is much cleaner. I've seen demos of velocity.. it just looks like another syntax of jsp to me. I don't see how its any cleaner. Struts isn't a presentation layer, so it can't be used as a replacement for jsp (although it augments JSP well).

Re:Book recommendations

[Anonymous Coward]

I've been a POJO programmer for a while and recently got into an EJB project (with some trepidation). The first book I grabbed was Rod Johnson's Expert one-on-one J2EE (which was the progenitor of Spring). Excellent book. I learned a lot from it; especially which parts of EJB were good (SLSB) and which are bad (entity beans).

EJB 2.0 is not a complete solution -- and I don't see 3.0 being that way either. Luckily, the Java community provides us with the grout to fill in the cracks of our projects: we just need to pick the right color ;) The main problem I find is that the average IT manager these days doesn't have the time or inclination to keep up-to-speed on the melting-pot solution that works. They want to be spoon-fed; which is something that Microsoft is great at (cf: .Net).

Additionally there are still many companies that don't want Open Source (because of the ignorant managers mentioned above). For example, my current client is willing to spend $18K on an Oracle App Server and EJB2.0, and won't even consider something like Spring (or even JBOSS).

Re:Book recommendations

[chochos]

Yup, sorry.

I read the parent to your post AFTER I replied to you. Actually I think my original post goes more to the grandparent than to you, since he was saying that J2EE is too much bloat and that plain JSP and servlets was enough (clearly not the case and you already know it).

Re:Book recommendations

[JavaDweeb]

EJB has so many problems. And EJB is NOT NECESSARY. Take a look at Rod Johnson's book Expert One-on-One J2EE Development without EJB

Re:Book recommendations

[anomalous cohort]

Can anyone recommend some decent books on EJB's, or is it not worth the bother?

I used to teach at USF. I had a simple sample application coded many different ways for the students to study. You can find that sample code on this page, http://testbox3.menlo.edu/demo/ism410/faves.html.

The last two code samples linked from this page feature EJB code. One uses a stateless session bean and the other one also uses a Bean Managed Persistance entity bean.

This is a little out of date but the samples were designed to be illustrative of the concepts. It is as simple yet functional an example as you are bound to find.

Whether or not EJBs are worth the bother is a different question. If you are in a situation where an object/relational mapping in an unclustered environment is optimal, then consider EJB technology. But don't use it too much. Use it at a high level of granularity. Don't bother to use it to display summary data or while the user is drilling down. The advantage is it provides a nice place to hang business logic in an n-tier architecture where database vendor neutrality is important. The disadvantage is the excessive boilerplate and cognitive overhead that it needs and the very dreaded and hard to fix "excessive loads and stores" problem.

A small step in the right direction

[metamatic]

One of the biggest failings of EJB 1.x and 2.x was that there was no standardization around deployment descriptors. This made a mockery of "write once deploy anywhere", because every different combination of application server and EJB container required a different mess of XML files before it would accept your EAR file and deploy your application. Naturally, all these files had completely different tools for generating them, and sometimes the tools weren't driveable from standard build tools like ANT.

Now with EJB 3.x they're promising to make a half-assed attempt at solving the problem. Now you'll annotate your Java code, and the vendors will supply tools to turn the standard annotations into their proprietary deployment files.

So, you'll still have to deal with a mess of different tools, and you still won't be able to deploy the same application EAR anywhere, but at least you'll only have one set of syntax to learn to specify the deployment information, and you'll be able to keep the info in the same place as the actual code. So, a minor improvement.

Other stuff looks to be just as muddle-headed as before. Yay, a new syntax for EJB QL, to make it almost exactly the same as the SQL it was supposed to be a simple alternative to. Of course, nobody in their right minds uses entity beans anyway...

The BileBlog has its usual acerbic take...

[tcopeland]

...on EJB3 here. A sample:

Also, is anyone else distraught by the obsessive use of the acronyms POJO/POJI? While it's understandable that a bunch of open sores asshats enjoy indulging in this fappery, I find it highly upsetting that this 'street lingo' has made its way into a supposedly professional serious spec. Is it so hard to say JavaBean/Interface? What's even funnier is that in every case, the POJO/POJI silliness is never used standalone, but always in paranthesis after 'regular java bean' and 'regular interface' respectively.

Whew!

Spring, Hibernate...

[chochos]

I heard some rumors that the new JDO is basically going to be Hibernate (probably with a gazillion interfaces on top of it that will make up the JDO spec). To me this feels like Sun has accepted defeat in that area. Hibernate is obviously years ahead of any entity bean effort, so it makes sense that they make it the new JDO. Shouldn't they do something similar with Spring? I've been using it, and I must say it's pretty cool and powerful. I HATE EJB's, and Spring offers a much more flexible way to work with beans. You can have stand-ins for JTA, pooled datasources, etc which make unit tests a lot easier. It doesn't seem like EJB 3.0 will be able to run out of their J2EE context yet, so Spring will still be useful for this, and it gives you a lot more independence from the app server.

Re:Spring, Hibernate...

[mcbevin]

Sure Hibernate is years ahead of any entity bean effort. But so is JDO already.

I find JDO and Hibernate both really nice technologies. The main difference being that JDO is a standard with multiple implementations (mostly commerical), vs Hibernate being a single open-source project, and that JDO uses code-morphing vs Hibernate just using reflection, which makes JDO more powerful but requires a post-compilation code-morphing stage.

If Sun would take either of these and replace the entity beans with them in the next J2EE spec that'd be great. But how do you come to the conclusion that JDO is basically going to be Hibernate?? JDO _is_ already on a level with Hibernate both in features and ease of use. JDO 2.0 brings a few good features missing from the JDO 1.x spec, but other than that is no major change.

Re:Spring, Hibernate...

[chochos]

If you RTFA, it says JDO is using something very similar to the Hibernate Query Language.

From what I've seen, Hibernate is not using reflection; it's using CGLIB, which if I understand correctly, generates code on the fly to speed up invocations that would normally use reflection, without the need to do post-compilation code-morphing. Perhaps it uses reflection for some stuff but it is my understanding that they're using runtime code generation for the parts that would become bottlenecks were they using reflection.

Implementor?

[Anonymous Coward]

Nobody is going to invest in implementing EJB3, so why bother? JBoss hasn't even made it out of the 2.0 swamp yet.

The EJB Bible

[jnana]

Every you need to know about EJBs is in this book.

And yes, Spring is an incredibly powerful, flexible, and *simple* framework to use. I don't know that I've ever used the terms elegant or beautiful for software remotely related to J2EE, but Spring is amazing.

And no, I'm not involved in the project. Just a happy user.

ejb3 sounds like a hack

[npgmr]

Hey, this's suppose to be professional programming right? Why does this ejb3 way of programming looks so much like a hack and is not backward compatible?

Anyone can take a look at the spec. and you will know what I mean. I'd rather stay away from those arcane annotation style, and stick with Hibernate/Spring/XDoclet.

If something has been done, might as well try to co-exist with them. If trying to compete, fine, but at least do it properly. With those new stuff, it's not going to earn any more respect than EJB 2.x.

Sometimes it's good to be non-backward compatible, but not in this case.

Re:ejb3 sounds like a hack

[mike_sucks]

"Hey, this's suppose to be professional programming right? Why does this ejb3 way of programming looks so much like a hack and is not backward compatible?"

It's a new major version. EJB 3.x vs EJB 2.x. Most professional people consider this is the only time where it is acceptable to break backwards comaptibility.

If Sun needs to break backwards comaptibility to simpify EJBs, I'm all for it.

Re:ejb3 sounds like a hack

[npgmr]

"If Sun needs to break backwards comaptibility to simpify EJBs, I'm all for it."

Just like the diff between java 1.4 and 1.5?

I didn't know there's a need to specify version when I compile a c/c++ program. Btw, I'm a SCJP and I think Java is great. But the annotations is not something inside the comment, but part of the language! Is this really needed?

Anyone who had used XDoclet and Hibernate would know that EJB 3 is not doing something new. The change is not technical, but commercial, in my opinion, to take the control back.

I don't see the need to repeat everything while anyone can google it or take a look at theserverside.com to look at what others have in their minds.

Re:ejb3 sounds like a hack

[mike_sucks]

I think a lot of the changes in 1.5 are a response to C#. But I don't think this is a bad thing, and if you don't use the new constructs and APIs and provided you don't tell the compliler to target 1.5 only, then any code you write in 1.5 will be backwards compatible.

Also, I think annotations do belong with the class/method/field rather than in the comment. XDoclet is an excellent product but the only reason they overloaded the use of @tags in comments is because they couldn't put them in the actual source without breaking every Java tool out there. The JCP /can/ make this change and so they did. It would be great to see XDoclet supporting 1.5-style annotations, because that's where they belong.

I think you need to keep in mind that Sun is a commercial entity, they need to make money and so they need to keep up with the competition. The EJB3 spec is a response to the competition they are getting from various groups, including Microsoft. It's not about control, it's about competition.

No one is making you use v3 EJBs, so if you prefer using XDoclet and Hibernate, go for it! I personly only use the web-tier whenever possible because there usually isn't much need for the middle tier. But please don't complain about competition, it's a good thing. The EJB3 spec will only drive XDoclet and Hibernate guys to make their products better!

Re:ejb3 sounds like a hack

[npgmr]

Good. :)

Re: EJB 3.0 in a Nutshell

[dkf]

That title makes me wonder what sort of nut would have that shell. Coconut's too small...