Slashdot Mirror
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."
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...
GCHQ Quantum Insert installed. If only our tongues were made of glass, how much more careful we would be when we speak
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.
Go hug some trees.
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.
Go hug some trees.
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.