Choose your J2EE weapons wisely

When Sun finally shipped J2EE in December 1999, Java was already well-established as a platform for serious enterprise applications. The features that Java app server vendors were already delivering -- transaction and session management, clustering, role-based security -- would now, it seemed, coalesce into a standard. But the dizzying complexity of that standard touched off a debate that continues to this day. It boils down to robustness vs. agility. In theory, J2EE can combine both by cleanly separating plumbing from business logic. In practice, the means of achieving that separation are subtle, varied, and controversial.

One lightning rod for controversy has been EJBs, a component technology that can be used to package business objects for automatic replication and fail-over, perform automatic translation between Java objects and SQL statements, enroll business objects in transactions, and more. Just because you can do these things, of course, doesn’t mean that you should. A few years ago, EJB was too often the hammer that made every problem look like a nail. More recently, developers have learned to be more thoughtful and selective in their use of EJB technology.

For Allie Rogers, CTO of Triple Point Technology, a Westport, Conn.-based developer of financial trading systems, a J2EE container is best used as a dispatching mechanism to enable coarse-grained (i.e., more general and hence more flexible) business objects to “scale out, not up.” Complete encapsulation of relational database entities is “the rat hole we intentionally avoided,” Rogers says. Likewise, he eschews J2EE transactions in favor of database-scoped transactions that are simpler and, for his purposes, sufficient.

Steve Muench is a lead developer and product manager at Oracle in Redwood Shores, Calif. He has written extensively about Oracle’s BC4J (Business Components for Java) framework and tells a similar story about a large customer whose application never needed to enroll multiple business objects in a transaction and therefore didn’t need the overhead and complexity of container-managed transactions. The legitimate desire to future-proof an application, in case such need should later arise, has led many a J2EE developer to embrace too much unwieldy complexity too soon. With Oracle’s BC4J framework, Muench says, you can “zig one way or zag the other as needs dictate.” A developer who initially targets lightweight deployment such as servlets or JDBC transactions can, for example, migrate to heavyweight EJB-style deployment with relative ease.

Developers who use BEA’s WebLogic Workshop aren’t even aware of the EJB infrastructure silently generated by that toolset. “J2EE was very well designed for systems programmers who want to see and control the plumbing,” says BEA’s Vice President of Engineering Adam Bosworth, “but application developers want that plumbing hidden.” If vendor-specific tools and frameworks are the only way to do that, though, then J2EE’s value as an industry standard is questionable. Bosworth acknowledges the point, and says that BEA, based in San Jose, Calif., will push for a consensus framework that will enable J2EE vendors to deliver the coherence and consistency that Windows developers find in Microsoft’s .Net Framework.