Java Enterprise Java Understanding Servlets

Understanding Servlets


This is Chapter 21: Servlets from the book Java 2 Primer Plus (ISBN: 0-672-32415-6), written by Steven Haines and Steven Potts, published by Sams Publishing.

© Copyright Sams Publishing. All rights reserved.


Chapter 21: Servlets

You will learn about the following in this chapter:

  • What servlets are why you need them

  • How servlets work

  • How to set up a Jakarta Web server to run servlets

  • How to program servlets in Java

  • How to call other Java classes from inside servlets

  • How to maintain the state of a servlet using cookies in the user’s browser

  • How to maintain the state of a servlet using a session on the server

When Java 1.01 was released, it was heavily oriented toward the development of applications that can run in a browser. The Applet architecture had received a lot of consideration and most of that release supported the GUI classes that facilitated their creation. Almost immediately, the question was asked, “What about developing for the server?”

The Java language offers much more to the developer than cool Internet graphics. It is a robust, highly object-oriented language that is easy to learn. It has a small footprint, and it can run on almost any computer that you can name. It is supported by a host of standard extensions that enables you to perform tasks, such as managing sound and video, without making you learn a host of proprietary command sets and scripting languages. It was only natural for Java to become popular on the server as well.

Java’s presence on the server side was initially through programs called servlets. Servlets, like applets, are intended to run in a container. The servlet’s engine is not called a browser, however, but a servlet container. Both applets and servlets have to be written to a pretty exact specification, but the servlets cannot have graphical user interfaces. They can, however, extract data from HTML forms, and they can create HTML and send it to the client to provide visual feedback.

With the introduction of the Java 2 Enterprise Edition (J2EE), servlets became only one of many server-side technologies available to programmers. Enterprise JavaBeans (EJB) have become popular for complex applications, but servlets remain as popular as ever.

In this chapter, we are going to cover servlets from the developer’s standpoint. First, you will learn how to obtain and install a servlet container on your machine. Next, you will learn how to develop, deploy, and run servlets. Following that, you will learn how to write servlets that maintain user information across transactions.

What Servlets Are and Are Not

Servlets are miniature programs that must be run inside another program called a container. The container is responsible for brokering communication between the servlet and the outside world. Beyond that, servlets are like every Java application. They can import packages, write to the hard drive, and even install viruses on your machine. By default, servlets are trusted code. The reason is that if someone has enough permission on your computer to install a servlet, he already has enough power to tie the whole machine in knots anyway. The thought is that this installer is a trusted person, so the work that he does should be trusted, too.

Servlets are not Java applications. They must be run inside a container instead of from a command line. That being said, you can add almost any functionality available to a Java application to a servlet also.

Servlets are not the only way for the server to communicate with a browser. A Web server is an HTTP application. It receives communication via the HTTP protocol and it communicates with the browser via HTTP also. You can write your own HTTP server-side application that processes its own requests, bypassing both servlets and the servlet container. This chapter contains a simple example of how that is done.

Why Do I Need Servlets?

Servlets are here to make your life easier. If the only option available was to write HTTP applications from scratch every time new functionality was needed, not much development would take place on the Web. Not many organizations could afford to write HTTP programs from scratch. The existence of the servlet container avoids the cost of having to include the entire HTTP header processing code in every program. Servlets extend classes that take care of all that work behind the scenes.

Another advantage of servlets is that they scale nicely. The servlet container is responsible for instantiating your servlet whenever it is needed. If it is needed a lot, the servlet container has the option of creating as many threads or instances of your servlet as its load-balancing algorithms indicates it needs.

Servlets make good use of machine resources. They run in threads that are created by the servlet container. Each individual HTTP application program runs in its own process. Processes are far more expensive to create than threads, so the servlet approach is more efficient. Servlet containers can also pool connections so that the threads already created are reused instead of discarded. The ancestor of the servlet, the CGI program, lacked these features and has faded in popularity as a result.

How Servlets Work

Servlets are really parts of an application and require a servlet container to run. This servlet container is responsible for instantiating your servlet and calling the appropriate methods in the servlet at the appropriate times.

When you type the name of a servlet, you are really making a call to a program that is located on a server and not on your machine. At first, this process seems like magic, but after a little study you will see that this process only requires that each piece of software in the process perform a fairly simple set of tasks. Figure 21.1 shows this process graphically.

Figure 21.1.

The servlet container is responsible for instantiating your servlets.

  1. You type in the URL of a servlet that you want to call.

  2. The browser creates a request that contains the servlet and the name of your machine so that the server will know who to send feedback to.

  3. The server receives the request and hands it to the servlet container. The servlet container is a program that knows how to run servlets.

  4. The servlet container checks to see if any instances of this servlet are already in memory. If not, it loads an instance and runs the servlet’s init() method.

  5. The servlet container waits for the init() method to finish. It then calls the service() method in your servlet from a new thread.

  6. The service() method calls the doGet() or doPost() method depending on what the request type is.

  7. A second user’s browser requests that the same servlet be run on its behalf.

  8. The servlet container notices that an instance of the servlet is already in memory. So, it creates a new thread and starts running the same servlet that you are running.

  9. This new thread calls the service() method.

  10. If this is an HTTP servlet, the service() method calls the doGet() or doPost() methods.

  11. The first thread finishes and a response is sent to the Web server, which forwards it to your browser.

  12. The second thread finishes and a response is sent to the Web server, which forwards it to the second user’s browser.

  13. At a certain point in the future, the servlet container decides to deinstantiate the servlet. At that point it calls the destroy() method once for each instance in memory.

Latest Posts

Related Stories