Java Servlets are special Java classes that can integrate with an enhanced web server and enable you to dynamically generate web pages by executing Java code - effectively running your code "inside the web server". Essentially, a web server can be configured to hand some/all web page requests over to a Servlet Engine which translates these requests into method calls into Java servlet classes, dynamically loading and initialising them as necessary. The web server and servlet engine may be a single integrated piece of software, or be two separate communicating processes.
As such, servlets are a bit similar to other dynamic web page generation programming technologies such as PHP scripts, ASP scripts and the old faithful CGI scripts [which can be written in any language you like, like our favourite Perl:-)]. However, Java Servlets are obviously lots better than any of them because there are lots and lots of lovely "J" words involved.
To be serious, there are significant differences - most other web technologies (CGI scripts especially) are one-shot - that is, each time the web server handles a page request, it runs the appropriate CGI script - actually starts executing it, waits for it to finish (gathering all its output) and then returns the output as the result of the page request. This means that a complex web application which involves many steps of filling in web forms ends up running the CGI script many times in different modes or states. Thus, one of the most important aspects of CGI programming is tracking each extended (multi-state) session - making sure that the CGI program can retrieve sufficient information at each stage to know which session it's part of, what stage it's at in that session, and what to do next.
Servlets have a fundamentally different lifecycle. Once initialised, a servlet object can handle multiple successive requests while storing per-session information inside instance variables - thus quite neatly solving the session management problem.
So, What's a Servlet Engine?
A Servlet Engine is a large chunk of Java code that either:
- is a complete web server itself, or
- can communicate with a web server
and handle dynamic loading of servlet classes, compilation of JSP files, initialisation of servlet instances and handling of page requests. Several servlet engines exist - often embedded into commercial middleware software which may include a specialised web server, database access logic, and the servlet engine itself. However, there is an open-source reference implementation servlet engine - Jakarta Tomcat from the Apache Project. Tomcat can operate as a full blown web server, or under control of Apache.
What is JSP?
JSP stands for Java Servlet Pages, and is a shorthand way of writing simple Servlets, more akin to other web scripting languages like PHP and ASP. A JSP file basically contains HTML, but with embedded JSP tags with snippets of Java code inside them. When you request a .jsp file in a suitable way (see servlet engine and context information below), the JSP file is automatically translated into a proper Java servlet, compiled, and if successful, loaded into the servlet engine and "run" by performing a method call into the servlet class. The generated servlet code (both source and executable forms) is cached to avoid having to regenerate it unnecessarily. Just like a full blown servlet, the servlet generated from a JSP file is able to store context between invocations.
What is a Context?
In Servlet speak, a Context is a directory that contains a single web application - envisaged as a set of related html files, Java Beans, JSP files, and/or servlets that form a single user experience. The terms context and webapp are pretty much synonymous. A context directory may contain one or more servlets. While some requests may correspond to simple static .html files and the like, many requests do not correspond straightforwardly to files and directories inside the context directory - instead they correspond to Java method calls in a servlet class of your own design.
Every context directory has a partially fixed, and partially variable, layout as shown below:
If you want to use servlets or Java Beans, inside your context directory you should make a special directory called WEB-INF. You will probably need to make subdirectories to this, depending on your exact needs - individual Java .class files should be placed in WEB-INF/classes, or (preferably) Java .jar archive files should be placed in WEB-INF/lib. If you are writing full blown servlets, you can also construct a configuration file called WEB-INF/web.xml which tells the servlet engine how to map URL requests to servlet class files (found in either WEB-INF/classes or WEB-INF/lib). However, you don't need to - a default is used.
Any other files are assumed to be normal static web files (or directories containing such), and Tomcat will attempt to read them and return their contents. Tomcat will even auto-generate a directory listing if no such file exists - but it generates it in a slightly different format than Apache does.
How's it setup here at DoC?
Enough already! How do you use Tomcat here at DoC?
