In a Java environment you have three key pieces to making your program run.
- The Java Virtual Machine (JVM)
- The Classpath
- The Class loader
The class loader is the important one here. It is the job of the class loader to get your Java class loaded into the JVM. This is much the same as a loader for an OS.
The Class Loader is "boot strapped" by the java command line utility. This is all fine and dandy, up till you get to a point where you need classes loaded by a remote client.
Enter the container. The container is a concept much like the class is. A container is a class that loads other classes, much like the class loader. It can other things as well like support LDAP security, email users, establish an SSL connection, manage database transactions, and so on. The container is limited by the scope of the system class loader, but the container can load classes based on whatever rules it provides.
Much like a class hides data members from the programmer, containers hide the method of invocation for classes loaded into it. A web container gets an HTTP request and loads Java objects in response, it doesn't really matter how it goes about doing it.
Servlets are the base of the Java EE model. They are invoked by an HTTP request, by means of a web container (see above). Servlets implement the Servlet interface which allows a container to invoke and maintain the life cycle of the object. More than likely you will be looking to extend the javax.servlet.http.HttpServlet class. This class comes with pre-built methods to handle the common HTTP request. Such as:
- doDelete - to handle the HTTP DELETE request
- doGet - to handle the HTTP GET request
- doPost - to handle the HTTP POST request
and so on... Each servlet that you create translates into a web page. Each method implements logic to handle a type of request. You'll be spending the bulk of you code in the doGet and doPost methods.
Working with the base servlet model is not the idea tool for interactive web pages. Basically you are writing a web page in Java as opposed to HTML, which adds to the complexity. Using the base servlet model is good for operations that you really want fine grain control over the entire logic flow. Here is an example of a servlet. You can readily see that we're just writing a web page within Java.
import java.io.IOException;
import java.io,PrintWriter;
import javax.servlet.ServletException;
import javax.servlet.http.HttpServlet;
import javax.servlet.http.HttpServletRequest;
import javax.servlet.http.HttpServletResponse;
public class HelloWorld extends HttpServlet {
public void doGet(HttpServletRequest request, HttpServletResponse response)
throws ServletException, IOException {
PrintWriter wout = response.getWriter();
wout.println("<html>\n<head><title>Hello, World!</title></head>
\n<body><h1>Hello, World!</h1></body>\n<html>");
}
}
As you can see this isn't exactly the greatest model. That's where JSP comes into play, but I'll cover that later. For now, you can see that a servlet allow fine control over what type of request will cause what action, but it is a lot to be asking you programmers to be Java/Web/Http experts all the time (ie, you could not manage [reasonably] a web site strictly made up of servlets.) Usually you will reserve servlets for testing EJBs and stuff that requires fine control over the process. You'll mostly use JSP/JSF for all other stuff.
Cheers!
