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