Java Servlets and Java Server Pages
Well first maybe I should explain a bit about the first actual web applications called CGI's. CGI(Common Gateway Interface) is a protocol or language for formatting request and responses from an HTTP server to an HTTP client. A client would be any web browser typically. Initially, a web server would send a request in CGI format to standard output on the server, at the same time calling a program on the server to startup. This program can be written in any programming language which can get standard input and output to standard output (practically any language, and even shell scripts). So the server sends the request to standard output which is read as standard input by the program. It then processes the request and prepares a response which is again posted to standard output, the server then reads this back in as standard input. The server then sends this information back to the client as a response.
A better way
This was a pretty good thing in the dawn of the internet. However staring up a system process for each request used a lot of system overhead, ram, processor and such. This was especially true when the request begins to come in in large numbers at a time. A server could easily be bogged down with request it couldn't answer. It could even crash. However we have a savior, you might recall from the article on Desktop Applications and GUI 'multithreading'. Developers were already writing these servers on machines that could handle this multithreading. So they worked on a way to send this client request to a thread within the same process(the server itself) to be handled. In Java, we call this thread a Servlet.
This is far more efficient on system resources than starting up a whole system process (multitasking) for each client request. And threads may be pooled, meaning reused without shutting them down and restarting them each time saving even more precious ram and processor time. Since a servlet runs within the server process it is a mini-application. It is to the server what an "applet" is to the desktop application. The server is made in such a way that you merely drop your servlets into, this is even easier than plugging something in. I mean you simply build your Java sources for your Servlet classes, compile them and then locate them in a given folder structure. The Server automatically knows where to look for them based on good old standards.
Also, the Java Servlet API has some nice classes which encapsulate all that CGI messaging complexity. This API handles request data with one object and response data with another. It handles your HTTP request types such as POST, GET, DELETE, etc. with a single method call. The API simplifies the whole mess so that you the programmer are free to work on your web apps logic.
Are servlets enough? We can do anything we want with them now! Well yes but the ugliness of this was that source code becomes very ugly when its full of
System.out.println(" ..........HTML.........HTML........"); We have mixed logic with content. It works. It works fairly well actually. It's just ugly. What is a JSP page? Its a text file named "somename.jsp" that contains (text only)(HTML)(text and or HTML and JSP tags)(JSP tags may contain Java source)
Separating code logic from markup
They came up with Java Server Pages to resolve this problem of ugliness and separate HTML from Java source. A JSP page is a text file that has a mix of HTML and JSP tags. This page is compiled by the server at runtime into you guessed it, a Servlet and in this servlet the compiler builds all those
System.out.println("...HTML..."); lines for you. When is it compiled? The first time a JSP page is accessed from a browser. This can take seconds to even a minute and may confound a visitor who thinks the page is not loading. Developers usually access the JSP pages themselves to compile them to save the visitor from having to wait. Speaking of the compiled servlet source, the good news is that most of the time you never have to look at that ugliness. You can if you want too but there is usually no need unless a debugging problem arises. Java source code can also be included on the JSP page as well if needed though this is probably not best practice. Instead, you try to focus on keeping your content in the JSP pages and your application logic in supporting Servlets.
And can we somehow work JavaBeans into this scene? Yup, but I won't talk about it on this website at this time except to say its called EJB Enterprise Java Beans and that requires an additional Server to run with Tomcat called JBoss. There are other 3rd party EJB containers as well. And in fact you could probably use the JavaBean design without an EJB container if you tried with some benefit.
That's not the end of the story with JSP, JSP has what is called Tag Libraries. To be honest I have yet to mess with them. JSP and Servlets and servers for that matter have one very important feature called 'Server Side Includes'. This means the output of one servlet can be the input of another. It also means that multiple JSP pages and HTML pages can be combined into one HTML page for a single response. How is this helpful? Web page headers and footers are prime examples. Let say I have 100 web pages on a website. Instead of editing 100 pages to update a header or footer I now only edit two files, one for the header and one for the footer. The index.jsp page for each one will look something like the following pseudo example.
JSP Include header.html tag
JSP Include footer.html tag
You can use this technique on every page on your website for a header, footer, breadcrumb trail, horizontal menu, vertical menu, related links and recommended books. I sometimes use the same related links for sets of pages for example. Mastering the use of server-side includes is a must for any web developer that will save countless hours of work or at least make work possible that otherwise would be put off or never done.