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.

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.

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 to do it you had to post-process the generated byte codes. The post-processor injected new byte codes 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 flavour 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” byte codes 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 byte code enhancement is controversial, JDO implementations aren’t required to do it. Source-level enhancement is another way to add persistence, but vendors favour the byte code 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 Java Beans) 2.0. Marc Fleury, 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 byte code 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 byte codes 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.

Udell is lead analyst for the InfoWorld Test Center.

Join the newsletter!

Error: Please check your email address.

Tags Strategic Developer

More about JBossProgress SoftwareVersant

Show Comments

Market Place

[]