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.

The example of the .Net Framework is also very much on the mind of Marc Fleury, president and CTO of the JBoss Group in Atlanta. “I love its simplicity,” he says. He’s equally enthralled with the declarative, metadata-driven style of C#. “Most of JBoss 4 is about fighting with limitations of Java,” says Fleury — in particular, its lack of support for unknown interfaces. In versions 3.2 and 4 of JBoss, an EJB can be used in an “aspect-oriented” style, its services delegated in a declarative manner to non-J2EE handlers.

If this interface-oriented approach reminds you of Web services, you’re in good company. The boundaries that define J2EE and Web services have begun to blur, leading some to question the need for J2EE servers altogether. “I see an e-mail style of integration emerging out of Web services,” says Annrai O’Toole, CEO of Cape Clear, a Web services integration specialist based in San Mateo, Calif., and Dublin, Ireland. “The requirements are XML technology, servlets, and Java; you don’t need this edifice of J2EE to make it come true.” A J2EE container which “abstracts the hard stuff” (clustering, transaction monitoring) is a vital ingredient, he says, but shouldn’t be used to buy robustness at the cost of agility.

Ultimately we want the best of both worlds. We want systems that are (or can easily be made) robustly scalable, but can also adapt in real time to the constant flux of the agile enterprise. It’s a complex equation with no single solution. Developers are learning to choose intelligently from the smorgasbord of J2EE services, in accord with the unique requirements of every application. Vendors are providing tools and frameworks to simplify the exercise of choice. The J2EE server may be turning into a commodity, but when it comes to the robustness/agility trade-off, there’s plenty of room for innovation.