|
Simpler Enterprise Java
The ServerSide Symposium 2004 revealed the development of less-complex EJBs with better container-managed persistence
by Kito D. Mann
Posted June 23 2004
The simplification of Enterprise JavaBeans (EJB) 3.0 was one of the biggest announcements at The ServerSide Symposium, held May 6–8 in Las Vegas, Nevada. Although many companies use EJB, the growing consensus has been that developing them is a pain. There are just way too many interfaces, deployment descriptors, and so on, to manage that code generators like XDoclet (see Resources) have become popular.
The complexity of implementing EJBs has sparked several open source "lightweight" containers, like PicoContainer and Spring (see Resources), which provide many of the features common in EJB servers. The main difference is that to write a component for these containers, you don't need to worry about multiple interfaces—they work with plain old Java objects (POJOs).
In addition to the implementation headaches, EJB's container-managed persistence has always been second-rate at best, giving rise to alternative technologies like Cocobase, TOPLink, Java Data Objects (JDO), and Hibernate, which means effectively that EJB has fallen short of one its biggest goals: providing enterprise-level object persistence capabilities.
The growing popularity of EJB alternatives threatens to marginalize the lucrative market for J2EE servers. What's the answer? EJB 3.0, now under development through the Java Community Process (JCP) as Java Specification Request (JSR) 220. Besides improving the architecture to reduce EJB complexity, the secondary motive of JSR 220 is to fix container-managed persistence. To help with this process, the EJB 3.0 Expert Group recruited Gavin King, the founder of the Hibernate project (see Resources), a popular open source, object-persistence solution.
Now Hear This…
How will it all work? Let's start with the programming model. (Please read these details with a grain of salt, this information is preliminary and subject to change.) The biggest change is that EJBs will be POJOs. In the event that you think this was a typo, let me repeat: EJBs will be POJOs. These POJOs will be annotated using the Java Metadata facility that will be part of JDK 1.5 (see "Extending Metadata Recognition," Java Pro Online, June 16, 2004).
To write a session or entity bean, you simply write a class, annotate it to indicate that it's an EJB, and give the container the details it needs to perform its work. Finally, we can stop drowning in XML files. Some things really do belong in code (see Listing 1).
All of those lines that start with "@" are annotations that tell the EJB container how to handle this entity bean. (The <Bid> in the code is an example of the use of generics, which is another JDK 1.5 feature.) Session beans have their own annotations, but the idea is the same: write a normal Java class, annotate it, and voila! You have an EJB. This ideal is a far cry from how things work now, and it's a welcome change.
The Listing 1 code sample came from Gavin King's talk at the TSS Symposium about Hibernate and EJB 3.0 (see Resources). In his fast-paced, fidgety manner, Gavin explained some other potential EJB 3.0 features, including support for inheritance (for entity beans) and an EntityManager API that allows session beans to access entity beans (much like Hibernate's session).
We can also expect to see an enhanced EJB Query Language (EJBQL) that includes some of Hibernate's query features, like named parameters, pagination, dynamic queries constructed in code, and native SQL queries. The EG is also examining the possibility of extending the Web request context to session beans—a powerful proposition.
If you're working with JDO, it may not seem clear where the persistence capabilities of EJB 3.0 fit in. JDO focuses on transparent persistence and works in any standard Java application. As you can see from the code sample, EJB 3.0 persistence isn't transparent; there is definite knowledge of the database in the annotations. EJB is also designed specifically for enterprise environments.
It's an exciting time for Java. Pressure from both .Net and the open source community is driving the most dramatic set of changes since JDK 1.1. Those of us who build Java solutions will definitely reap the benefits.
About the Author
Kito D. Mann is an independent, hands-on enterprise architect who has consulted for several Fortune 500 companies. He is the author of JavaServer Faces in Action (Manning Publications Company, 2004), and runs the JSFCentral.com community site.
Back to top
|