Columns

Staying out of the deep end

• By Tony Baer
• January 1, 2002

When skill availability was tight over the past few years, technology bets skewed aggressively because of the urgency to retain restless developers, the need to get Web sites running, or both. Over the past five years, we've seen bets placed on HTML and PERL, Linux for Web servers and, more recently, Java and EJBs. Over the next year, we will probably add C# and XML to the list. But in the current climate, new technology adoption will probably be slow.

Does this mean that J2EE—Java's brass ring—has become "safe" for enterprise deployment? A year ago, developers said yes, but only as long as you could handpick your technologies. Java server pages, servlets, and naming and messaging services were considered pretty mature, and JDBC a bit less so. It didn't hurt that, at the time, J2EE was the only alternative to proprietary technologies.

EJBs were another story. Highly complex in nature, they contained a mélange of housekeeping services that, depending on your viewpoint, made them a management dream or a developer's nightmare. If you could accept the complexities of EJBs, session beans were pretty straightforward; and even though they hadn't been invented yet, the verdict looked similar for message-driven beans.

Entity beans, which encapsulated object-relational mappings, proved to be far more challenging. Few developers trusted container-managed persistence (CMP), which automated the mapping job, while even fewer had the patience to individually create the mappings bean by bean, using bean-managed persistence (BMP) alternatives.

Fast forward to the present, and when it comes to EJBs, little has changed, according to a cross section of panelists we spoke with at a recent SIGS Java conference. "EJBs are too cumbersome for us," declared Jordan Zimmerman, senior software architect at Altura International, Monterey, Calif. "When we started using EJBs, there were different configurations for each application server," added Prasuna Dornadula, chief technology officer at CareTouch Inc., Concord, Calif. "Persistence mechanisms are getting better defined," countered Tom Geer, chief architect at USSearch.com, Los Angeles, adding that, "thanks to the versatile EJB container, you no longer have to worry about specifying various naming services." Nonetheless, developers are wondering if alternatives, like Java Data Objects, might provide easier workarounds for object/relational mapping.

Maybe a few years from now we'll all be laughing about the fact that we ever worried about all this. For instance, HP's Tony Wassermann ventured that while persistence looks difficult to automate today, not so long ago, people thought the same things about menial tasks like writing files and pointer structures for database mappings.

However, the real underlying issue is not the difficulties of entity beans or other Java technologies per se, but the fact that, as with any new technology, the learning curve typically lags behind the adoption curve by at least 12 to 18 months. In other words, by the time best practices emerge, the technology in question has become old news. Nonetheless, as technology professionals, we are often under the gun to make snap decisions before all the evidence is in.

With .NET about to come out, those decisions will get harder. We'll quickly stack up the pros and cons: Java's maturity, .NET's superior Web services support, Java's multiplatform support vs. .NET's Windows-centered strategy, and so on. Either way, we might soon get to the point where both technologies become safe enough choices that nobody will get fired for buying either one. But it also pays to keep in mind that no technology ever fulfills 100% of its promises. Java's "write once, run anywhere" promise has stalled on some browser clients. Will .NET's promise to support writing in almost any compliant language and running on the same platform prove just as elusive?

So, when making your next quick technology bet, just remember that even "safe" technologies are never lacking for hazards.