November 1, 1999

Servers Struggle With Enterprise JavaBeans Support

By Richard Hoffman, Network Computing, and Anthony Frey

ll five products we tested serve Java code, but each one does it slightly differently, so we couldn't produce one set of standardized Java test code to provide a quantitative performance measurement. Novera and ForeSite do not directly support deployment of standard servlets. Rather, you must extend a custom servlet class. The three products that support Enterprise JavaBeans each implement them differently, particularly regarding container-managed persistence for entity beans, due in part to the newness of the Enterprise JavaBeans 1.1 specification.

All of the products performed acceptably. While performance is important, the most critical differentiators are effectiveness at scaling up to multiple machines through flexible load balancing and failover, management granularity and control, and support for the most applicable Java standards. As the Java market matures, bulletproof support for standards will be crucial. It's no accident our top three products support the most current and evolving Java standards.

We gave each application server a dedicated test machine: a 400-MHz Dell OptiPlex GXI host with 256 Mbytes of RAM and a 4-Gbyte hard drive. Our Oracle 8.0.4 enterprise database server was a Dell PowerEdge with two 300-MHz Pentium II processors, 512 Mbytes of RAM, and two 4-Gbyte drives. For our Web server, we used Netscape Application Server on a Dell Dimension XPS D333 host with 128 Mbytes of RAM and a 4-Gbyte drive. The hosts ran Windows NT Server 4.0 Service Pack 5, and were connected through a 100-Mbps Extreme Networks Summit48 switch.

Servlets were designed as a Java alternative to Web-server CGIs. We found support for them to be little more than a shim between Web servers and a Java Virtual Machine. But servlets are fulfilling a transitional role between CGI scripts and full-fledged Enterprise JavaBeans applications, so it's wise to choose a Java application server with strong, flexible, standards-based servlet support.

Serving Enterprise JavaBeans components effectively will be a central function of enterprise-level Java application servers. However, Sun's EJB 1.0 spec barely defined the session/entity bean component model and its contract with the container's execution environment. That spec also lacked clear outlines of essential services. In transactions, Enterprise JavaBeans relied on the Java Database Connectivity spec evolving to 2.0 before nailing down X/Open XA interface support.

Imprecise specs foster much variation. However, our tests show the EJB 1.1 spec has given vendors a clearer direction because of the tightly defined auxiliary APIs. The most significant variations were in naming, fault-tolerance, and database connection pooling.

Flexible, nearly ubiquitous Java application and component portability is a possibility in the near future. The Java 2 Enterprise Edition spec, built on the Corba/Internet Inter-ORB Protocol, makes interoperability among various EJB implementations a solid hope.

Vendors are left to distinguish products in areas such as management, application development, and fault-tolerance, or specialize in a niche, sometimes to the detriment of the package. We looked at the application servers with an eye toward full Enterprise JavaBeans support, which hurt the ones that lack such functionality.

return to main story, "Java Servers Offer More"

Back to This Week's Issue
Send Us Your Feedback
Top of the Page

---