EJB Crashes and Burns
Six years ago, only a few customers used persistence frameworks at all, and far fewer used them well. The top Java vendors and insiders pushed EJB hard, and the industry bought it. EJB introduced container managed persistence (CMP) as one of Java's first full-service persistence layers. No one could really make CMP work, but few could resist the EJB hype, which was at a fever pitch. Many developers in larger development shops simply adopted EJB because it was hot, and they believed that CMP would fatten their resumes.
In its early stages, CMP was all but unusable. It could not manage relationships, and forced entities to use expensive remote interfaces with pass-by-value semantics. Still, modern-day knights of application development mounted up, drew their keyboards, and tilted at the windmills. In the end, rather than scrapping CMP and starting over, they implemented their own persistence: bean-managed persistence (BMP). I can't imagine an uglier programming model. We had the worst of two worlds. BMP forced developers to code their own persistence, yet they still had to conform to EJB's confusing and awkward interface.
Many of the largest J2EE shops were in limbo. They had committed a cardinal sin: They believed their vendors. Contrary to its hype, EJB complicated programming, seldom worked, and scaled poorly. Eventually, most developers cracked and conceded that they were in over their heads. Amidst the wailing and gnashing of teeth, WebGain joined the fray with its TopLink object-relational (OR) mapper.
To this point, no persistence framework had yet experienced mass-market success. WebGain had been around for some time but only as a bit player. The vendor significantly grew its reputation and market share by providing TopLink, which could be used as a snap-in replacement for EJB CMP, enabling seamless persistence for that defective model. Along with providing rich OR mapping, TopLink supported the richness and complexity of relational databases. It also had a powerful caching model.
All this came at a cost, of course. TopLink was moderately complex and frighteningly expensiveespecially when you factored in the cost of its consultants. But most customers were in so much pain that they paid the price. And it worked. TopLink had its warts, but if you could afford it, it made your application fast, reliable, and flexible. For the first time, Java developers experienced true insulation between the persistent model and the database schema. Still, most persistence experts in the Java space insisted that there was a better way. Enter Java Data Objects.
JSR 00012 (the Java Specification Request for JDO) requested transparent persistence for Java in 1999. If you used early versions of EJB for persistence, then you know exactly how frustrated developers were with it. At the time, leadership representing TopLink and other persistence solutions did not want a standard for OR mapping. They fought JSR 00012 with the kind of venom and fervor once reserved for Microsoft.
To get the JSR through, JDO proponents eventually produced a spec without OR details, which was exactly what OR vendors and RDBMS vendors wanted. After all, the market leader always wants to be proprietary. RDBMS vendors did not want an interface that opened their customers to OODBMS vendors. Likewise, OR mapper vendors would not support an interface that opened their customers up to their competition. While a few vendors were happy, most would-be customers weren't.
The 1.0 version of the JDO specification finally made it out of committee in 2002, after three years of uncertainty and industry bickeringthat's three calendar years, not Web years. Unfortunately, the specification did not cover OR mapping, which was precisely what JDO customers wanted. The market did not respond well to the incomplete spec, the lack of big-time support by major vendors, or bytecode enhancement. Further, this young standard was trying to get established during a time when the economy was in shambles. Key players such as TopLink only partially adopted the standard, and even then, only early versions of it. Larger database and app server vendors held off entirely. Still, a core of strong JDO implementations began to emerge and evolve.
Meanwhile, on the EJB front, customer failures began to stack up and the press began to sound off against the specification. Critics claimed that the framework was too big, too hard, and incomplete. In swooped EJB 2.0. The new CMP specification fixed the most glaring problems by adding local interfaces and allowing relationship management. A few customers began to have some moderate success with EJB CMP, but the EJB backlash was picking up steam. I watched with interest, because I myself was writing a book that criticized key parts of the EJB specification. I needed that market to buy my book, but EJB faded too quickly.
Key consultants and academics in the Java community began to understand that the EJB framework was far too invasive: EJB components depended on the specification and could not run outside of a container. EJB CMP developers could not take advantage of basic Java features such as inheritance or threading. EJB applications also were tough to build and harder to tune for performance. More importantly, the framework did not support the ideals of easy testing and simplicity that developers desired. By early 2003, the community was coming to the conclusion that EJB, in its current incarnation, did not stack up to the hype that the big J2EE manufacturers aggressively pushed.
The struggling economy finally took its toll on WebGain. The company collapsed, but not before selling TopLink to Oracle. Once that happened, new customers with non-Oracle databases or application servers felt uncomfortable making TopLink investments, and the market share numbers reflected their reluctance. Ironically, now TopLink was the underdog. It needed to support a major open standard like JDO or it would be too risky of an investment for its customers. Nothing else has stepped into the void, yet.