In-Depth

Is Enterprise Java enterprise-ready?

• By Tony Baer
• January 1, 2001

Like any successful Web site, Sothebys.com was fast outgrowing its original patchwork architecture. Designed using Perl scripts, proprietary code and Oracle database-stored procedures, the e-commerce site of the famous auction house was growing to the point where a more scalable infrastructure was needed.

But thanks to early experience developing several intranet applications using the JRun Java-based application server from Newton, Mass.-based Allaire Corp., Enterprise Java appeared to be the right way to go, said Chief Technology Officer Laird Popkin.

But was the timing right to commit to Enterprise Java? With Sun's Java 2 Enterprise Edition (J2EE) in release since the beginning of the year, the way was cleared for the introduction of products that should theoretically become interoperable. With the standard in place, most major Java app server and tools vendors have begun committing themselves to swapping out proprietary technologies in favor of J2EE-compliant upgrades. Meanwhile, new players offering J2EE-compliant products are beginning to emerge. For example, at Flashline.com Inc., an electronic marketplace for components based in Cleveland, there are nearly 10 vendors offering almost two dozen Enterprise JavaBeans (EJBs) for sale, compared to none six months ago, according to CEO Charles Stack.

Nonetheless, for most users, Enterprise Java has the ring of first-generation technology. "It's a major expenditure and a major investment," observed Edwin Smith, chief architect of Allaire's JRun product, who noted that developers are looking carefully before making the jump. "They prefer something that they can easily get their hands around."

Sothebys.com decided to take the bait, but one step at a time. The firm's Popkin hopes that the result will enforce more disciplined development practices and true three-tier applications that, in the long run, will be easier to maintain and expand. The company is currently shopping for application servers, with the requirement that the choice must support high-availability clustering. They have also begun specifying their next-generation e-commerce site architecture, built on EJBs.

Of course, Java-based app servers from established players like BEA Systems Inc., San Jose, Calif., IBM, Bluestone Software Inc., Philadelphia, and iPlanet, Mountain View, Calif., have offered many of these features for several years. Consequently, many of the questions surrounding Enterprise Java are not necessarily whether the technology is there, but rather, if the technology being used will become obsolete because it is not standards-compliant.

Yet there are still questions regarding whether the basic technology is ready for prime time. For example, Sothebys.com has not decided how the beans will communicate. "We're wrestling with JMS [Java Messaging Services]," said the firm's Popkin. "We're unsure whether we need the sophistication and complexity of JMS, or whether to simply make direct calls to EJBs, which we're more familiar with." Besides which, J2EE will not have specifications for an interface between JMS and enterprise beans until the next revision of the specification, due next spring.

The lack of a standard interface between EJBs and JMS has not always been a showstopper, however. "Having the standard would have saved us some development time, but we've written the classes and methods in modularly so we can swap them out after the functionality comes out in EJB 2.0," noted Edward Pick, CTO at B2Bgalaxy.com, an operator of B2B online marketplaces in Parsippany, N.J.

Hesitation and workarounds are not unusual for new technologies that are moving as fast as Java. What makes the J2EE decision challenging is that the specification is not a single, monolithic technology, but a framework encompassing component definitions, Web page generation, object/relational data mapping, along with APIs to directory services, transaction management, messaging and database access. While Sun is striving to slow down and synchronize the release of new specifications, J2EE in actuality is a collection of technologies of varying maturity. For example, EJBs will enter their second generation when J2EE gets its next major revision next spring, while newer technologies such as Java Server Pages (JSPs) are still in their first iteration.

But with J2EE technology, age often has little bearing on maturity. For example, while Java Database Connectivity (JDBC) has been around for a while, it will not have the ability to scroll through large data sets until the next revision of the standard. Yet some of the newer parts of the spec, such as JSPs, servlets and the Java Naming and Directory Interface (JNDI), are for all practical purposes considered safe for everyday consumption because they are relatively simple. "We can easily assign JSPs to HTML developers who don't even know Java," noted Fred Kauber, vice president of technology and operations at Expression Engines, an e-commerce marketer.

Added Simon Pepper, senior product manager of Java products at Dublin, Ireland-based Iona Technologies Inc., "JNDI is only an API about COS Naming, so it does exactly what it's meant to do."

To bean or not to bean
Enterprise beans are the brass rings of Enterprise Java, extending JavaBeans for distributed deployment. By providing standard "containers," EJBs offer numerous services that would otherwise have to be hard-coded, such as exposing methods or classes, maintaining deployment life cycles and providing object/relational data mappings.

Like J2EE, of which it is a part, EJBs also comprise a grab bag of technologies of varying vintages and degrees of readiness. For example, entity beans, which are used for mapping data objects to relational databases, are newer than session beans, which encapsulate business logic. Not surprisingly, most of the EJBs in use today are session beans. "The easy part is session beans. Most programmers understand RPCs [Remote Procedure Calls], and they are essentially the same thing," said Kim Sheffield, application server general manager at SilverStream Software Inc., Burlington, Mass.

Given that EJBs are barely one or two years old, it is not surprising that they have not been adopted in critical mass. Ergon, a Swiss consulting firm specializing in Java and Internet applications, has only just begun its first EJB project. According to Marketing Director Alois Sauter, there is still some customer reticence in accepting EJBs. "Our customers are using CORBA infrastructures because they are easy to connect to any back-end system," he noted, adding that CORBA's language-independence has been another inducement against implementing EJBs. "There is still a lot of C and C++ in [the] current world; we have to live with that," he stated.

Understandably, the Java community is waiting for the standards to settle down. "The sense was that EJB 1.1 was transitional, and that most people were waiting for 2.0," explained Bob Bickel, executive vice president of products and executive technology officer at Bluestone Software. Although EJB 2.0 specs are out in draft form, and commercially available from some app server vendors, the final version is not due out until Q2/2001.

In some cases, the EJB decision hinges on whether more accessible Java components like servlets and JavaBeans provide acceptable alternatives. "We started with servlets and JSPs because they are easily adaptable to other technologies," said Jim Howell, architecture specialist for S2 Systems Inc., a developer of e-commerce systems for health-care and financial services industries headquartered in Dallas. And, although ordinary JavaBeans were not designed for distributed deployment like EJBs, S2 has relied on load-balancing features from its Bluestone app server to provide the next best thing.

Meanwhile, DesignOnline, an emerging B2B marketplace for interior designers, is still evaluating Enterprise JavaBean architectures. For now, it uses servlets to perform double duty, accessing data and generating Web pages via JSPs.

For others, EJBs are just a matter of time. At Expression Engines, the use of JSPs that invoke JavaBeans has so far worked fine. "Our infrastructure is still very centralized," said the firm's Kauber. "If we were invoking business logic with other business partners or deploying our application on servers around the world, EJBs would be a lot more compelling." Another driver might be the sheer growth of the application itself. "JSPs are like managing HTML pages," he said, noting that his group has already developed several thousand JSPs to date. But Kauber concedes that, as JSPs proliferate, they could eventually make version control a real challenge.

The newest entity
The newest enterprise beans, entity beans, map objects to relational data structures and manage the persistence of database connections. Beneath the hood, entity beans perform housekeeping services, including basic EJB functions from life-cycle management to security, plus services that are specific to interacting with databases.

Depending on your viewpoint, entity beans are either a useful means of producing well-designed, three-tier apps or a waste of precious computing resources. "Entity beans are necessary," said Vishnu Mavuram at Random Walk, a New York-based consulting company. "Before they came out, everybody wrote database code to do routine operations like managing instances and caching them."

Philip Bride, marketing director at Beaverton, Ore.-based GemStone Systems Inc., wonders aloud if these advantages are worth the price. "The biggest drawback of entity beans is all the container callbacks that the entity bean has to go through during the course of its life cycle," he said. Of course, these are the same callbacks that are performed by session beans, and some developers wonder whether the overhead and effort of building an entity bean is necessary when a lighter-weight object could perform the same database interaction.

Flashline.com's Stack views this as a non-issue. "If you look at the utilization across a call, the bulk of your cycles are in the transmission on the network and data store," he said, claiming that the resulting overhead of entity bean communication is marginal.

The solution, said B2Bgalaxy.com's Pick, is careful coding and configuration. "Obviously, you need to know the proper memory configuration settings," he said, insisting that the effort of using lighter-weight objects would, in the long run, prove more costly. "Maintaining them [JSPs or servlets] could be a nightmare because you have to know where they all are," he said. "Entity beans were much better for maintaining security."

Nonetheless, there is no silver bullet for handling database interactions. While B2Bgalaxy.com uses entity beans, it uses the database, not the bean, to maintain state. According to Pick, the rationale was to reduce overhead and simplify failover processes. "If we maintained session state in the application, [we would] have to rely on app servers to replicate all sessions," he said.

The lack of consensus over entity bean use could be because they are so new, and that so little is known about how to best deploy them. Not surprisingly, there is no common pattern to when and how they are used.

For example, New York City-based Codexa is building a real-time financial trading information service and has dispensed with entity beans altogether. The firm used session beans in conjunction with an object database embedded within the GemStone/J app server. "It was a conscious decision," noted Chief Architect Tom Geer, explaining that CORBA provided more robust session pooling and transaction processing services, not to mention superior approaches to persistence. "The [EJB] specification around container-managed persistence is not flushed out yet, while bean-managed persistence was less efficient," he said.

On the other hand, Diamelle Technologies, an e-commerce software pro-vider in Cortlandt Manor, N.Y., uses entity beans to represent customer orders but not to make order inquiries. When checking orders, a stateful session bean makes calls to external, lightweight Java objects which in turn generate the necessary SQL statements.

"Entity beans don't handle complex data very well," said Suneet Shah, chief technology officer. "They can represent details like order line items, but not entire order pages, which contain multiple elements from many tables. That would take multiple hits on the database." According to Shah, it takes much less code to develop a Java object to make complex data queries compared to using an entity bean.

Persistent questions
Even where entity beans are playing starring roles, there is no consensus on how to handle persistence or transaction state. In some cases, persistence is handled by the database. In others, developers are using "bean-managed" persistence (BMP), where all the logic for maintaining the transaction and targeting data structures is coded individually, bean by bean. "With bean-managed persistence, you really have to know how the bean works," noted B2Bgalaxy.com's Pick.

Sun is driving development of container-managed persistence (CMP), a specification for automating the process of performing object/relational mappings. The inducement for CMP is tempting because it provides generic settings for processes that are fairly complex to configure. Not surprisingly, John Kiger, marketing director at BEA Systems, estimates that about 60% of WebLogic customers are interested in it.

The debate over CMP, however, is whether one size can really fit all. Today, it obviously cannot. The current version of CMP in the EJB 1.1 spec, which only supports one-to-one mappings between an entity bean class and a database table or row, cannot handle the complex data structures that typify most business applications. For example, B2B trading exchanges may have to map entity beans against multiple data sources, including vendor, shipper, product and pricing tables or rows, each of which could change during a single session—especially if dynamic auctioning is involved. Similarly, CMP would break down for larger apps involving mapping of classes to hundreds or thousands of database rows.

Although Sun promises improvements to CMP as part of EJB 2.0, vendors such as Iona and Oracle Corp. insist that this is where they can add their own value, such as automating the generation of beans from database schema or providing pre-built business components to make the process easier.

However, Enterprise Java developers are from Missouri: They want to see real CMP first. "I don't expect anyone to nail CMP down, because you're looking for the Holy Grail, a switchboard that could understand every conceivable application schema," said Codexa's Geer. B2Bgalaxy.com's Pick added that, while CMP might be adequate for non-critical applications, mission-critical systems would prove to be another story.

The more things change
The ability to run applications on any platform has long been a hallmark of Java's appeal. Although most first-generation Enterprise Java users have tended to stick with the same vendor's tools or middleware, portability is increasingly being added as a checklist item. "Many firms often start with low-cost tools because their budgets are limited, and [they] would like to know that they could move up to more scalable products to protect their investments," noted Diamelle's Shah.

But some users want it both ways. "I'm concerned about vendor independence, but I'm also concerned about performance," said Codexa's Geer.

For J2EE, Sun has instituted a rigorous compliance testing process, with more than 6,000 tests, to ensure compatibility. However, because Java technology has been a moving target, many tool and middleware vendors have added temporary features rather than wait for the Java standards to catch up, such as SilverStream's scrolling capabilities that extend JDBC and BEA's object/relational mappings that venture beyond Sun's first-generation CMP specifications. And most are promising backward compatibility and migration paths as they phase in J2EE 1.3 products (which will include EJB 2.0) next year. For example, BEA will support both its original CMP capabilities and those specified by EJB 2.0 in the next release of WebLogic.

Even then, vendor differentiation will not go away. For example, IBM, BEA and Bluestone package their own transaction services; GemStone offers the ability to run Java Virtual Machines; Iona is bundling a visual object/relational mapping tool; and Oracle offers business components to simplify database interactions.

When all the pieces fall into place, Enterprise Java will likely become as standard as Unix or SQL. Basic compatibilities will exist, but modifications will have to be made if users switch tools or app servers. Codexa's Geer suggests designing Enterprise Java apps with separate "superclasses" covering vendor-specific product features that could be swapped out if necessary. Naturally, any migration would inevitably involve some work. "But the impact would not be catastrophic," he maintains.

If any of this sounds familiar, it should. Portability questions have been around since the dawn of the term "open systems." Similarly, infrastructure quality issues have always surrounded new technologies. These were exactly the same questions that client/server developers were asking five years ago.

What is different this time is that the Internet business environment often provides companies no alternative to wait for new technology, such as Enterprise Java, to mature. "When we did our due diligence last fall, we discovered that there weren't many users who had production systems," noted B2Bgalaxy.com's Pick. That did not stop them from opening three marketplaces using technologies such as EJBs, JMS and servlets. And, noted S2 Systems' Howell, the lack of portability will not stop them from considering an upgrade to their system to run EJBs. "That isn't a critical success factor for us."