Network Computingwww.networkcomputing.com

Java can execute in two places: a client browser on the user's desktop, or a server on the network. While Java on the browser delivers benefits today and holds promise for the future, its widespread acceptance of all active content has been limited by security restrictions and available bandwidth. A combination of Java deployed on the server and dynamic HTML has emerged as the most practical technology implementation to provide business solutions.

Client-side Java spared you any tough decisions. If you chose client-side Java, the built-in Java classes supported by the browser were determined by Microsoft or Netscape. The scope of applications was also limited by the amount of disposable bandwidth available for your targeted user population. And in many cases, organizational security policies blocked Java content at the firewall. The only decision you had to make was to pick a Java IDE (Integrated Development Environment), which is a matter of personal preference.

Paradoxically, when examining server-side Java--supposedly the cleaner environment--you have more to think about. You must consider which Web server is in place and which transaction manager to use. The decision to deploy Java on the server gets wrapped up in key behind-the-firewall infrastructure decisions.

Ideally, server-side Java is an open development model, not tethered to any particular IDE. When choosing a Java server infrastructure, your decision should focus on what type of services the Java execution environment on the server provides.

While different Java environments deliver variations on provided services, all offer the core Java classes. Here, we'll look at three alternatives for deploying Java on the server: the Java servlet engine as provided by IBM Corp.'s WebSphere; GemStone/J, an application server for EJB from GemStone Systems; and a specialized environment for Java as a stored procedure language under Oracle Corp.'s Oracle 8i. While these products represent different examples of deployment, each vendor also offers other Java products (for example, IBM and Oracle both support EJB).

Before discussing WebSphere, it's important to turn to the ubiquitous and accessible Java servlet API. Simply add Java to the server, get a Java IDE and a Web server that supports the Java servlet engine (most do), and you're set. Purists may cringe, but you can think of the servlet API as a CGI for Java. But unlike CGI scripts, Java on the server encourages--but does not guarantee--creation of reusable object frameworks. And CGI scripts provide no underlying object framework.

The selling point of the Java servlet model is that it provides a standard, uniform API and environment, so it doesn't bind you to any single vendor, and it avoids the performance hits associated with the CGI process per invocation model (each servlet is spun off as a lightweight thread). Servlets execute in their own sandbox, which provides Java security and application services. And since the JVM (Java Virtual Machine) executes as its own user process, any aberrant servlets that may result from NSAPI/ISAPI (Netscape API/Internet Server API) programming won't crash or degrade the Web server processes. As a bonus, you get all the additional classes, tools and APIs developed for the Java platform.

But the servlet model has its trade-offs. Raw performance is one concern. Given an identical server and identical Web server processes, the Java servlet solution incurs a context switch between the Web server and the JVM. Additionally, the NSAPI/ISAPI solution can be written in native code, avoiding the overhead of Java byte-code interpretation. And though an errant servlet may not affect the Web server, it can affect overall application availability.

AJava servlet engine is a JVM that provides services to your Java applications via an API, and a protocol to communicate with a Web server process. The servlet API consists of two packages: javax.servlet and javax. servlet.http. The servlet engine (typically the Web server) is responsible for loading your class and managing threads and multiple client requests. The engine instantiates your servlet and creates the configuration and session objects required by the servlet. The engine also terminates the servlet and performs garbage collection. The servlet API provides a simple object framework to support HTML-based clients, including objects for retrieving Web-server requests, a simple stream interface and advanced features, such as cookies, session tracking and thread support.

The "stock" servlet engine provides conversational services such as sessions and cookies; standard Java classes, such as JDBC (Java Database Connectivity), provide access to enterprise data. But what if you need more? WebSphere (as well as GemStone/J) enhances the servlet engine, providing basic management and configuration services to the standard and moves on to advanced transaction processing and object persistence services.