Java's Sweet Spot

Application servers are at the core of Web application development efforts. While many IT managers and CIOs must deal with this curious piece of middleware every day, others see it only as an icon in an application diagram. Finding out what application servers can and can't do lets senior IT managers help their developers make informed decisions that can benefit an entire company.

Application servers evolved directly from the earliest HTML content servers. What makes an application server different from a Web server is its ability to turn data from a variety of sources into Web content, not just HTML. In this article, we'll look at the most popular app servers that conform to Sun Microsystems' Java 2 Enterprise Edition specification.

Developers using Java and J2EE are able to concentrate much more on business logic and application feature design rather than spending an equal or even greater effort incorporating Internet plumbing. This shift has opened the door to a demand for J2EE application-development tools as well as J2EE-compliant application servers that can handle this kind of code and add more value. They do this by supporting database, security, and Internet architecture features designed to make building and deploying a J2EE application quick and easy.

Given this demand, we tested leading application server packages from BEA Systems, iPlanet, and Sybase. We tested each product on its support for J2EE, its related standards, and on how well it might fit into a component-based Web application design. Related development tools were a big factor, as were management utilities. Security, load balancing, and clustering also were considered. All these features were tested in isolation by first running small Java demo applications on the product and then implementing a large, enterprise-class Java application, the source code for which we borrowed from a functioning dot-com.

We chose this enterprise application because it required the latest in Web application technology support, including full compliance with J2EE, Enterprise JavaBeans 1.1, the Java Naming and Directory Interface, Java Server Pages, servlets, and XML.

Making the decision to use an application server is largely a developer's choice. But IT managers can reasonably expect an application design to take such a direction if the application in question involves certain tasks; server-side Web functionality is an obvious one, but legacy-systems integration (especially databases) is another. Almost any time that back-end systems such as catalogs, transaction servers, and personalization servers are required, an application server will be needed to coordinate these services with the front-end application.

To make a successful application server implementation, IT managers should look for a number of supported features. The first is that the programming standard being employed is well supported. In the case of this test, that would be J2EE, but it could be something else such as Corba or Microsoft's Distributed Component Object Model.

The server must also provide support for messaging, transaction services, and distributed services. Given the mass of support that J2EE has in the E-commerce community, you should also look for features such as clustering, load balancing, and security. Finally, because an application server with these kinds of features will become the heart of your distributed application, management utilities are essential.

This brings up an interesting point in deciding on an application server. Most companies leave this decision entirely up to the development staff, which, in turn, concentrates exclusively on the package's support for programming standards. That's their job, after all. But if something goes wrong once your product has gone live, tracking the cause and finding a resolution should be the Holy Grail of your systems administration staff. Without a functioning application server, your E-commerce application is essentially dead.

Before signing off on an application server (and these are usually major purchases), senior IT managers and CIOs should make sure the package is agreeable to everyone who'll be using and managing it, not just the development staff. The quality of the programming feature set isn't always mirrored in the quality of the management utilities, for example, which is something your systems administrators should know about.

Making sure your application server platform meets the needs of all your IT staff is an important criteria in selecting such a product, but there are numerous other considerations.

The purpose of an application server is to expose all or portions of an application that's accessed via the Internet, typically using a Web browser. A Java-compliant middleware layer is only one approach to bringing off such a design successfully. For example, observant readers will quickly notice that while Microsoft aims to be a giant in the distributed Web-development business, it has no offering that really resembles the application server packages reviewed here.

That's because Microsoft's philosophy toward application servers starts at the operating-system level, not the middleware layer. Microsoft views Windows NT/2000 as the basis for its application server needs, and it simply enhances this platform with additional middleware functionality in the form of development tools and BackOffice Server packages, including Commerce Server, Site Server, Transaction Server, and especially Active Server Pages technology.

While this is a viable design strategy, it also forces developers into a highly Microsoft-centric view of technology. That was one reason we decided not to review Microsoft. The other is that while Microsoft is a powerful vendor in the Web-development arena, our focus is on Java-enabled application servers, and that's one area where Microsoft so far has chosen not to compete.

Similarly, other companies are changing the way developers think about application servers. Oracle's new 9iAS platform, though not available in time for this review, is a prime example. Oracle's view is that many developers are placing significant portions of their application logic inside the database in the form of complex SQL. So extending the database directly to the Web and application server should have design benefits.

By all reports, 9iAS is a well-rounded platform, supporting not only Java 2 Enterprise Edition, but XML, EJB, JSP, servlets, and more. But it will be interesting to see how freely developers are able to choose other components outside Oracle's product line to run other portions of their applications; the Web server is a good example, as are the Java development tools and management utilities. Oracle makes products that fit all those descriptions with varying degrees of success. Will users of 9iAS be able to pick and choose from third-party products to fulfill these needs, or will they be locked into Oracle?

This integration question doesn't apply only to the big-name vendors. Most application servers come as part of a larger suite of Java development tools. For instance, IBM's WebSphere ships with and is tightly integrated with its VisualAge for Java development environment and DB2 database.

Similar examples can be seen from many of the vendors we didn't get a chance to review, including Borland, Iona, Pramati, and SilverStream. Most of these companies integrate their application servers fairly tightly with their other product offerings, especially Java development packages, databases and a variety of deployment and management tools. The trick in evaluating an application server for your business can't revolve solely around the app server's technical capabilities (its support for Java and other standards). Evaluating bundled tools is just as important, as is how free developers and administrators are to choose other third-party solutions that may work better in a specific situation.

Choosing the right application server platform for your design is a critical step in completing a successful development project. Most often, this revolves around how well the product handles Java, J2EE, EJB, and JSP code. Support for bundled as well as third-party ancillary tools is also important. But the last step in evaluating an application server has to be its future.

Java is the darling today and will undoubtedly continue to be important for the foreseeable future. But anyone observing the Web application industry already can see future standards growing in importance. XML is an example, along with its associated standards, such as the Simple Object Access Protocol and the E-business XML (ebXML) effort. IT managers need to identify how important these technologies are to the future of their applications. How will the company that sells you a J2EE application server today support these standards tomorrow?

Extending the Web into the wireless world is another great example. New standards like the Wireless Access Protocol are making mobile Web apps not only feasible, but even practical. Closely intertwined with XML, these standards will become critical as wireless development becomes more popular, and application server and other Web middleware will need to support it.

What's important in an application server is changing just as quickly as the functionality of the Web is growing. Making an informed decision on such a platform means more than paying attention to today's requirements. It means looking at your application design from the server to the browser, divining as much of tomorrow's needs as well as today's, and only then taking a step toward purchasing one of these platforms.