Email	Print Reprint
	add to:
	Del.icio.us Digg Google Furl	Slashdot Y! MyWeb Blink

In his March 26, 2003, SD West panel discussion, “Enterprise JavaBeans Don’t Support Complex Object Models: What to Do,” Scott Ambler gestured at the panelists. “If you can make them cry,” he told the audience, “we’ll count this one a success.” The panelists mimed shock and fear.

Ambler, the president of Ronin International, didn’t want the audience to pull any punches when it came to awkward questions. After all, the topic was the story of a failure—but the panelists themselves came out swinging. “Most people wouldn’t recognize a domain object if it bit them on the rear end,” said IBM Senior Technical Staff Member Kyle Brown. “People haven’t really done object-oriented analysis or design. They say they have an object model, but under the covers is a transactional script approach. Domain models are useful when building complex applications, but most people simply don’t have the experience to make it work.”

Keiron McCammon didn’t pussyfoot around, either: “Entity beans suck—that’s my position, and I’m sticking to it.” Apparently, complained the Versant CTO, the software community refuses to learn from past mistakes: The CORBA community ran into the same morass when putting remote interfaces onto objects backed by relational storage, and now entity beans perpetuate the pain syndrome. “Ignore container-managed persistence (CMP),” he urged. And don’t assume that the features available should drive your design: “Decide if a domain model is really necessary. Decide if you need the complexity first; if you do, then you can address it.” Brown agreed, to some extent: “Luckily, if you enforce rules like don’t ever put a remote interface on an entity bean, it’s usable.”

Floyd Marinescu, director of TheServerSide.com and author of EJB Design Patterns (Wiley, 2002), bemoaned lost chances. “It’s still really hard to build complex object models with entity beans. You still have to worry about ‘component baggage’ with them. There was a chance to create a marketplace of reusable components—but it didn’t work out.” As an alternative to CMP, he recommended using the Session Façade design pattern to build applications, and pointed out at least one open-source alternative. “Hibernate is a transparent framework for persistence—it’s one of the top 10 downloads from SourceForge.”

Craig Russell was the lone—make that lonely—Sun representative at the table. But even he refused to defend entity beans. “Session beans rule. I’ll defend that position to the death.” He listed programmer complaints about container-managed persistence, including the inability to use inheritance and polymorphism to express models persisted via CMP. “And complex types are hard to represent, especially your own types; they wind up being serialized, then persisted basically as binary large objects, and then you can’t query on their contents.” But the architect of Java Data Objects held out hope for the beleaguered object modeler: “I’m going to propose that JDO solves all the issues I’ve named. These objects are implemented as Plain Old Java Objects (POJOs) that get stored in the database. Relationships are defined between persistent classes; you can use inheritance. Complex objects are optional features—they’re not supported everywhere—but you can find them.”

Not so fast, said Brown. “JDO has some terrific features. The problem is that unfortunately we live in the real world with data sources that we can’t control, database schemas that are 20 years old and don’t map to our object format. We need to work a little bit more to marry that beautiful user experience to the underside of what happens in the relational databases.” Russell retorted, “SQL is not a standard!” He went on to give examples of vendor-specific extensions that make life ugly for the API builder. At least, he said, “JDO papers over many of those differences.” Brown and McCammon asserted that standardization was needed so that IT shops could avoid lock-in, but Russell disagreed. “As long as you’ve got a solution that works, you’ve got what you need,” he asserted. “You’re not going to replace your SQL with Versant, for example —sorry, Keiron! It’s not just the JDBC tier; it’s every other tier,” he continued, pointing out that dependencies on the database percolate throughout the enterprise. “The real challenge is not reusable components; it’s reusable programmers: Why should you have to learn five tools when one will do the job?”

The audience took their best shots at eliciting tears from the panelists. “This is déjà vu all over again,” said one attendee. “Ten years ago, I went to object databases. I just want my Java objects with no work whatsoever. Why haven’t more efforts been made to provide object-database hooks into the Java virtual machine?” Nobody had a direct answer for that; Russell said that features like the debugging hooks that are built into the current JVMs made such an effort “theoretically possible.” He said that JDO actually could take advantage of them, but that “it’s primarily focused on the user experience instead of on the undergarments of how persistence is implemented.”

Another audience member focused on the dog that didn’t bark in the night: “I haven’t seen much discussion of how J2EE server operates in the enterprise with things that aren’t J2EE, like, say, Oracle Forms.” Brown responded, “That’s really a Java Services model; it’s something that needs more research.” But he cautioned that architects shouldn’t count on just waving the Web services magic wand over their problems: “WSDL is a good way to describe your services, but it’s not a good way to describe your domain objects.” The questioner agreed, pointing out that “legacy code won’t be using WSDL; it’ll be using the Oracle call interface, or C++ libraries.” Brown held out hope, though: “Consider using Web services: IBM just announced a kit for Cobol—there’s something available for just about anything you can imagine.”

Panelists and audience members alike longed for an easy way to do relational-to-object mapping, but all agreed that it’s a tough nut to crack. Said Russell, “If the JDO expert group had tried to standardize on O-R mapping, we’d still be working on the spec today.”

To a man, the panelists recommended pragmatism over a technology-centric approach. The collective opinion was that EJBs might get ugly, but they aren’t necessarily broken. “In the long run,” said Brown, “it doesn’t matter which way you wind up representing your complex domain models. If you design your system properly, you can change out the details three, four times, and it won’t matter. Neither EJB/CMP nor JDO will make or break your application.” “If you already have EJBs, and they’re working,” said Marinescu, “it’s cost-effective right out of the box.” For all their faults, said Russell, EJBs do work. “The benchmarks with EJBs do thousands of transactions per second. It’s a ruggedized, enterprise solution. Now, for remote access to persistent data, stateless session beans and JDO is the way to go”

“The key thing,” concluded McCammon, “is for us to understand the tools that are available. People widely assumed that EJBs were the only thing available; hence the right thing to do. There are things available, from design patterns, roll-your-own, to JDO.”

Sure, it was tough up there. But nobody cried.

RELATED ARTICLES Q&A: Software Testing In A Virtualized World Secure Software Needs Careful Testing -- And Lots Of It Securing the Java Core Petascale Tools and Genomic Evolution Legal Compliance: Open Source and Quality Assurance		TOP 5 ARTICLES No Top Articles.