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.

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...

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.

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]

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!