Patterns of persistence

Programmers spend time and effort translating between objects represented in high-level programming languages, such as Java, and structures stored in relational databases. Object databases can remove that impedance, automatically binding programming-language objects to database objects. But doing so transparently requires some deep magic.

Free IT resource TechNet: More ways to know it, share it, and keep it running. Sponsored by Microsoft Free IT resource Attend the SOA Executive Forum: Breaking SOA Bottlenecks SOAExecForum.com/may2007 Sponsored by InfoWorld

I got my first taste of it years ago working with ObjectStore (formerly ObjectDesign, then Excelon, and now Progress Software). You could make ObjectStore versions of standard Java classes (Hashtable, Vector) persistent, and you could also make your own user-defined classes persistent. But in order to do it, you had to postprocess the generated bytecodes. The postprocessor injected new bytecodes to intercept get-and-set operations and make the user-defined objects persistent, transactional, and able to cooperate with ObjectStore’s intelligent distributed cache.

Object databases have always been specialty items. But no matter what flavor of database you choose, there’s still that disconnect between programming-language objects and database storage. And the same old techniques are still being used to address it. For example, today’s implementations of the JDO (Java Data Objects) spec typically use the same trick that ObjectStore used back in 1997: They “enhance” bytecodes to make Java objects persistent and transactional. Vendors of JDO implementations include stalwarts such as Versant and Poet Software, which map JDO to their own object databases, as well as newcomers such as SolarMetric and LIBeLIS which work with relational and/or object databases.

Because bytecode enhancement is controversial, JDO implementations aren’t required to do it. Source-level enhancement is another way to add persistence, but vendors favor the bytecode approach because it’s less invasive. Since all JDO enhancers must be binary-compatible, you can in theory move a persistence-enabled class from one   implementation to another.

Although JDO can be used with J2EE, it runs parallel to it and is not explicitly supported by vendors of J2EE servers. They instead highlight the CMP (Container-Managed Persistence) features of EJB (Enterprise JavaBeans) 2.0. Marc Fleury, president and CEO of the JBoss Group, is interested in decoupling persistence from J2EE, even though he thinks that CMP 2.0 trumps JDO. With the forthcoming JBoss 4.0, he told me, even plain Java objects can be persistent, transactional, and cacheable. How? “Java is flexible enough to be supercharged with bytecode engineering so that it acts as a superlanguage,” says Fleury.

For object or relational databases, simple objects, and EJBs, the same underlying technique has been used to achieve persistence. When I see a repeating pattern, I listen to what it’s telling me. In this case, the message has little to do with the practice of hacking Java bytecodes and everything to do with an emerging discipline called AOP (aspect-oriented programming). Seen through the AOP lens, persistence is something you declare about an object, not something intrinsic to it. The “managed” middleware environments (J2EE, COM+) take a similarly declarative approach, as do the new breed of Web services management solutions. AOP is crossing from theory to practice, but it’s a profoundly unifying idea that will resonate throughout the industry.