Java needs to address the needs of performance and robustness on the server side to fulfill its promise of providing a networking solution for the enterprise. Servlets complement applets on the server side and complete the definition of Java's role in the client/server hierarchy. In the next few years, servlets are going to play a prominent role in the acceptance of Java as the primary object-oriented language of the future.
In this discussion, I would like to focus on some of the Internet technologies and Java APIs that servlets complement or substitute for. This issue of JDJ also features other articles that focus on the Servlet API and example applications (see pages 8 and 40).
The first few sections of this article provide a high-level introduction to servlets and their role in the Java client/server architecture. Subsequent sections include brief discussions of other Java APIs and related technologies in light of the servlet paradigm.
So What Are Servlets?
Servlets are server-side Java programs that provide a means of generating dynamic Web content. They are not standalone applications that can be executed from the command line; instead, they run within Web servers. Of course, in order to run servlets inside a Web server the server must have a Java Virtual Machine running within itself. Unlike applets, servlets are not constrained by security restrictions. They have the capabilities of a full-fledged Java program and can access files for reading and writing, load classes, change system properties, etc. They are restricted only by the file system permissions, just like other Java application programs.
From a networking standpoint, servlets are Java applications that reside on the server side of an HTTP server. Since servlets are not subject to artificial security constraints, they enable the developer to extend Java programming to the server side of the HTTP protocol.
The Java Servlet API is a standard extension to the core API.
Java Servlet Usage
Servlets may be used at different levels on a distributed framework. The following are some of the obvious examples of servlet usage:
CGI and Servlets
- Protocol support is one of the most viable uses for servlets. For example, a file service can start with NFS and move on to as many protocols as desired; the transfer between the protocols would be made transparent by servlets. Servlets could be used for tunneling over HTTP to provide chat, newsgroup or other file server functions.
- Servlets could play a major role as part of middle tiers in enterprise networks by connecting to SQL databases via JDBC. Corporate developers could use this for several applications over the Intranet, extranet, and Internet.
- Servlets often work in conjunction with applets to provide a high degree of interactivity and dynamic Web content generation.
- The most common use for servlets is to accept form input and generate HTML Web pages dynamically, similar to traditional CGI programs written in other languages.
- Servlets could be used for collaborative applications such as online conferencing.
- A community of servlets could act as active agents which share data with each other.
- Servlets could be used for balancing load among servers which mirror the same content.
Servlets provide an alternative mechanism to CGI programs for generating dynamic data. CGI programs have existed for a while; they are stable and universally accepted. They are language-independent (although they are not platform-independent). They are fairly easy to write. The question that comes to mind is, why should you consider replacing CGI with servlets? The main advantages of servlets over CGI scripts are:
Servlets offer a substantial improvement in performance over CGI. Each CGI request on the same server results in the creation of a new process. On the other hand, a servlet can continue to run in the background after servicing a request. Also, CGI programs are not threaded. Servlets can use threading to process multiple requests efficiently, provided that the JVM embedded in the Web server offers thread support.
CGI programs are platform-dependent. Servlets are Java classes and follow the "write once, run everywhere" doctrine. Therefore, they are truly portable across platforms.
CGI programs are stateless because they result in the creation of a new process each time a request is serviced. A servlet has memory of its state once it is loaded by the server. The JVM running on the Web server loads the servlet when it is called. The servlet does not have to be reloaded until it changes, and a modified servlet may be dynamically reloaded without restarting the server. Maintaining state information allows multiple servlets to share information.
Applets and Servlets
Servlets are often referred to as faceless applets. Unlike applets, they have no user interface components. As mentioned earlier, servlets are free of the security restrictions that apply to applets. This is because they run within a Web server on the server-side. Thus, they are trusted programs.
Like applets, servlets may be called from HTML files dynamically and there are several cases in which the two could be used interchangeably. So when should we design servlets and when should we design applets? The answer to this question goes back to the basic issue of load distribution between the client and the server. The distributed client/server paradigm has shifted over the past few years from fat clients to thin clients and subsequently from thin servers to fat servers. Applets are representative of the client side of the architecture and servlets represent the server side. Some scenarios in which servlets are more appropriate are given below:
Applets are more appropriate in the following scenarios:
- Applet classes are downloaded over the Internet to the client and then executed in a JVM running on the client. If this involves loading large pieces of code over slow modem lines, applets are not the appropriate choice.
- If a large part of the computation for generating the Web page can be done on the server side, it is pointless to load the part of the code that does the computation to the client. The computation should be done on the server and the results passed back to the client.
- If processing involves operations that applets cannot perform due to security restrictions, then a local servlet may be used.
Applets and servlets can also share data and communicate. Therefore, the processing can be split between them.
- Applets basically have a well-defined user interface (remember that they derive from Panel). In servlets, on the other hand, a user interface would have to be built from scratch. Therefore, when a sophisticated user interface is desired applets are appropriate.
- If the speed of the communication channel is adequate, then the overhead involved in downloading applets may not be an issue.
Servlets exist only in the context of a Web server. Therefore, it is important to know what level of support servers have for servlets and what issues are involved in using one for servlet invocation. Javasoft bundles a package with the Servlet API which may be used to embed servlet support in Apache servers, Netscape servers and Microsoft IIS. Of these, the Java Web Server from Sun is the first commercial server that incorporates the Servlet API. In Netscape servers, servlets are supported as plug-ins. In Microsoft IIS, servlets are supported via DLLs.
One thing to keep in mind while using Web servers is the version. Web server JVMs are usually a couple of steps behind Sun's current Java JDK versions. Also, the version of the Servlet development kit from Sun Microsystems should be supported. At the time of this writing, only the Java Web Server has complete support for JDK 1.1. Before going on to design servlets, the developers must make sure that they are working with compatible versions of the various APIs.
Server Side Includes and SHTML
Servlets can be accessed directly via a URL request from the Web client/browser. Web servers that have complete servlet support also allow servlet invocation via Server Side Includes (SSI), which involve embedding the servlet in an HTML page. The SSI mechanism is implemented in the form of an HTML tag which has the following form:
<servlet> ... </servlet>
HTML files that include SERVLET tags are called SHTML files and have the extension .shtml. The code snippet in an SHTML file shown in Listing 1 illustrates how java servlets may be embedded in HTML.
Figure 1 illustrates servlet invocation using SHTML files.
Web Page Compilation and JHTML
As mentioned in the preceding sections, servlets are usually invoked either by a by URL invocation or as Server Side Includes in SHTML files. In both cases, the servlet is first coded as a Java class by the developer and then invoked using one of these two mechanisms. Page compilation is a different way of creating the servlet class file which involves generating HTML pages from HTML files that contain embedded Java code. These files, which are a hybrid of HTML script and Java code, are called JHTML files and have the extension .jhtml.
The Java Web Server includes support for page compilation. This is not a recommendation for readers to use the Java Web Server but rather an introduction to an alternate mechanism for dynamic Web page design using servlets. The code snippet in a JHTML file shown in Listing 2 illustrates how java code may be embedded in HTML.
As you can see in Listing 2, Java code within a JHTML file is embedded within <JAVA> ...</JAVA> tags. When the PageCompileServlet is loaded, it does the following:
Figure 2 illustrates servlet invocation using JHTML files.
- Translates the HTML/Java file into a Java source file
- Compiles the file into a Java class file
- Instantiates the Java class file
- Runs the compiled file as a servlet
Servlets as Agents
Servlets may be viewed as the next step in client/server architecture towards mobile agents. Similar to an agent, a servlet may be downloaded from different servers, performing the same action on each server in turn. They also may be uploaded to different servers to perform the same function. Since they are portable across platforms, servlets can be loaded to heterogeneous platforms. Additionally, servlets bring Java's security features to the world of agents and thus help in filling the security hole that is a matter of concern in using mobile agents.
CORBA and RMI
Servlets provide the capability to access data residing on the servers in several different ways. They can be used in conjunction with distributed framework technologies like CORBA and RMI. One interesting application of servlets with CORBA is to create a servlet that is also a CORBA server. Similarly, a servlet can be made an RMI server. The advantage of such a servlet is that the CORBA server can accept and process Web requests directly. The client invocations on this server could be either from a Web server via HTTP requests or from a CORBA client itself.
Figure 3 illustrates a Web server that loads two servlets, an RMI Server and a CORBA server, to service client requests. Note that both servlets, once loaded, may be directly accessed by direct URL invocations via a Web browser.
Java servlet and Beans technologies can be combined to develop server-side distributed components. This involves creating servlets that are also JavaBeans™. Implementing a servlet as a bean simply means designing a servlet that adheres to the JavaBeans design pattern. Programmatically, all this means is that the properties of the servlet that require persistence should have the beans getter/setter methods as follows:
void setProperty (PropertyType property)
The advantages of designing "servlet beans" are:
The Java Web Server from Sun Microsystems, Inc. inherently provides support for servlet beans by assuming that all servlets are beans.
- Any changes to the configuration of servlet beans take place immediately.
- Beans add persistence to servlets. A servlet bean can be serialized and its dynamic state can be preserved. This way the state of a servlet can be preserved between its incarnations.
Servlets are a fairly new concept in the client/server world. They have started replacing CGI as a means for creating dynamic Web content. However, the Java Servlet API and related tools are still evolving. Two key components that have been developed at Sun Microsystems, Inc. are:
The Java Servlet API supports Java programs on the main Web servers like Netscape servers, Miscrosoft IIS, etc. Also, this API is expected to be a standard extension API in JDK 1.2. The Java Server Toolkit is available in beta form and adds features to the Servlet API such as a network threading framework, dynamic Web-based remote administration, server side sandboxes, SSL, Web page compilation, client session management, etc. to servlets.
- The Java Servlet API.
- The JavaServer Toolkit
There are several aspects of servlets that are beyond the scope of this article - servlet security issues, servlet chaining, servlet-applet communications, accessing native code, data access, etc. Even regarding the technologies mentioned in this article, we have only touched the tip of the iceberg. But I hope the preceding discussion has given the readers an idea of the impact that servlets are going to have in the client/server arena and also of some of the other technologies in current distributed architectures that directly contribute to the success of Java servlets.
Table 1 contains a glossary of the technologies mentioned in this article.
Readers may also want to look up the following references for additional information:
About the Author
- The javasoft Website:
- Sridharan, Prashant, "Advanced Java Networking", Prentice Hall, PTR, 1997.
- Harold, Eliot Rusty, "Java Network Programming", O'Reilly & Associates, 1997.
Ajit Sagar is a member of the technical staff at i2 Technologies in Dallas, Texas. Ajit has seven years of programming experience in C, including one and a half years in Java. His focus is on networking, and UI architecture development. You can reach Ajit at Ajit_Sagar@i2.com
Listing 1: Code in an SHTML file.
<PARAM NAME=param1 VALUE=value1>
<PARAM NAME=param2 VALUE=value2>
Listing 2: Java code embedded in HTML.
System.out.println("Goodbye Cruel World");