The third day of class covered many of the new features of EJB 2.0, including the benefits of CMP 2.0, local interfaces, and container-managed relations. During lunch, I talked to another one of the students to get a better idea of the different backgrounds of the people attending the course. The highlight of the afternoon was an indepth look into JDOs and a study of their pros and cons.
A Look at EJB 2.0
The morning started off with a lecture on using CMP in EJB 2.0. With BMP entity beans, we have to write the JDBC ourselves which means possibly having to write a large amount of code. With CMP 2.0 entity beans, the JDBC is implicitly provided for you through a Persistence Manager (PM). The Persistence Manager is new to EJB 2.0 and specializes in complex O/R mapping. The PM is pluggable into your J2EE server. Examples of proprietory PM's include Webgain's TOPLink and Thought Inc.'s Cocobase.
When the slide for the example CMP Entity Bean Class came up, it was interesting to see how vastly different it was from a BMP class. For one, the CMP bean class is abstract, defining abstract getters and setters. Why were there no persistent fields? This is the beauty of the Persistance Manager: It subclasses your bean, defines all your fields, and takes care of defining 'concrete' get/set methods. All you have to do is provide it with some instructions in your XML 'Persistance Descriptor' so that the PM can write the necessary JDBC and define finder methods in the subclass. EJB-QL written inside the deployment descriptor, a standard query language for objects, enables the PM to generate the JDBC for finders.
A question asked by one of the students about whether BMP and CMP can be combined prompted an answer by Partha that effectively summarized their significant differences, and why in fact they can't be combined. Whereas in BMP you have a concrete class, persistant fields, concrete get and set methods, and hard-coded JDBC inside the persistance methods, in CMP you have an abstract class, no persistant fields, abstract get and set methods, and no JDBC inside the class since the Persistance Manager takes care of creating it for you.
"EJB 2.0 has some great features that could make a grown man cry" said Partha as he unwrapped a cough drop. Just before lunch, a brief discussion of local interfaces helped to whet the class's appetite. A familiar theme from yesterday was echoed: reducing network overhead. The problem with remote interfaces is that they require all communication to use RMI-IIOP, even when the target bean is located in the same JVM. This hampers performance. Using local interfaces, a bean is being called from within the same JVM, and can hence be called using normal Java method calling semantics. The advantages of this are that no RMI-IIOP is required and the performance gain of pass-by-reference can be leveraged.
Another cool part of EJB 2.0 is its ability to deal with complex entity relationships using CMP and CMR (Container Managed Relations). Before EJB 2.0, foreign key references, referential integrity and cascading deletes had to all be painstakingly implemented with BMP. With CMP 2.0, you can now define relationships properties in the CMR field. Unlike normal CMP fields which map directly to the database, CMR fields do not map to the foreign-key column of the database. CMR fields actually pointto objects. In your XML deployment descriptor, the CMR field doesn't represent the foreign key of the related object; instead, it represents a pointer to the object itself. The allowed data types for CMR are entity bean local interfaces and collections and sets.
For the Love of J2EE, and a Job
During lunch, I spoke to Rick Critchett, a former C++ programmer looking to brush up and expand on his current J2EE skillset by taking this course. Rick worked extensively with the ATG Dynamo application server for a previous company, and has extensive experience with web and server side application development. Of the students I had spoken to, many were either looking to learn more about a specific J2EE technology or find out how they could improve their existing J2EE implementation at work. Rick however, was unique in that he was taking the course purely out of general and academic interest with the lesser motive of possibly getting a job afterwards.
"I'm sort've unique in that respect where I'm trying to learn as many details as possible about each and every aspect of EJB and extending beyond that to J2EE, how things fit together and how they're used. I'm also reading up on industry standards, usages, best practices and all of that. Reading a book you don't really get that. You don't get what's going on in the real world, and not being in the 'real world' right now, it's especially harder for me."
When asked what his ultimate goal was to get out of the EJB For Architects course, Rick responded, "I would love to get into a project where they're heading into the design phase of things, where they know what their business motivations are, what the problem is and how they want to approach it from a higher level and then translating some of those requirements into UML and how that relates to a J2EE focus."
Would you like JDO with that?
After lunch, on what was a beautiful spring afternoon in downtown Chicago, the class returned to commence the section on JDO. "The goal of JDO is pluggable persistance," announced Partha. "With JDO you can change dynamically where you're persisting your data to. The case for using JDOs is if you're writing BMPs which are currently going to relational databases, but you have the fear that you may be going to an object database sometime in the future." The two main objectives of JDO are to enable pluggable implementations of data stores into application servers and to provide application programmers with a Java-centric, object-oriented view of persistent information.
In order to become a JDO, a java object has to implement the PersistanceCapable interface which gives it lifecycle methods used by the PersistanceManager. There are two ways to make an object implement the PersistanceCapable interface: 1) by manually implementing the JDO interface or 2) by using a byte-code enhancer. A JDO Enhancer modifies the class's bytcode and allows the object to become persistent. A PersistanceManagerFactory generates a PersistanceManager which triggers the persistence of your JDO into a table, manages the life of persistant instances, creates query objects, and retrieves transactions. When you register your objects with a persistance manager, a handle to it is returned. A persistance manager can only be associated with one transaction at a time but you can easily engage in multiple transactions by instantiating more persistance managers.
As Partha discussed the ability of JDOs to inherit from one another and got into the details of JDO method implementations, one student suggested that enity beans might as well be replaced altogether by JDOs.
"Can JDOs totally replace entity beans?" Partha asked the class. "Why did we decide to go with entity beans in the first place?"
An answer came from the back of the room, "Because of the quality of services you gain with them."
"Right", replied Partha. "JDO's don't offer you security, or connection pooling for example."
It seemed that most of the class was buying into what JDO had to offer, until one dissenter confessed that "JDO sucks." Partha jokingly told him to leave the room. "If we don't see JDO in the next spec release, give me a call," said Partha to the class. Of course, he didn't give out his phone number.
At the end of the third day, the class seemed quite saturated with all the J2EE concepts that were being expounded since Day 1. The concepts definitely needed to be tied together into a real-world context. Tomorrow's class will attempt to bring together and drive home these concepts through a sample J2EE application which the class, divided into two groups, will have to model. Tomorrow's lectures and discussions will also focus on Web Services architecture, SOAP, and UDDI.