Chapter 19: Listeners & Interfaces in Web Context

We have seen a lot of things related to a web application like the HttpRequest, ServletContext etc. there are a lot of listeners and interfaces that are part of any J2EE applications life. In this chapter we are going to take a look at them.

So, lets get started!!!

What are Listeners Used For?

Listeners are a useful mechanism by which we can monitor and react to servlet events by defining the appropriate listener objects. These objects have methods that the container would invoke when the life-cycle event occurs. To make this happen, you define a listener class by implementing a listener interface. The container would invoke the listener method and pass it information about that event.

For ex: When the HttpSessionListener interface is implemented, the methods will be passed an HttpSessionObject

What are these Listeners?

There are many different types of Listeners that are available for us to use. The listener we can use depends on the purpose it serves. The Listeners and their purpose are as follows:

1. When a Servlet is Initialized or Destroyed
     a. javax.servlet.ServletContextListener
     b. contextDestroyed(ServletContextEvent sce) Notification that the servlet context is about to be shut down
     c. contextInitialized(ServletContextEvent sce) Notification that the Web application is ready to process requests
2. When a Context attribute is added/removed or replaced
     a. javax.servlet.ServletContextAttributeListener.
     b. attributeAdded(ServletContextAttributeEvent scab) Notification that a new attribute was added to the servlet context.
     c. attributeRemoved(ServletContextAttributeEvent scab) Notification that an existing attribute has been removed from the servlet context.
     d. attributeReplaced(ServletContextAttributeEvent scab) Notification that an attribute on the servlet context has been replaced
3. When a session is initialized or destroyed
     a. javax.servlet.http.HttpSessionListener.
     b. sessionCreated(HttpSessionEvent se) Notification that a session was created.
     c. sessionDestroyed(HttpSessionEvent se) Notification that a session became invalid or timed out.
4. When a session attribute is added/removed or replaced
     a. HttpSessionAttributeListener.
     b. attributeAdded(HttpSessionBindingEvent se) Notification that an attribute has been added to a session.
     c. attributeRemoved(HttpSessionBindingEvent se) Notification that an attribute has been removed from a session.
     d. attributeReplaced(HttpSessionBindingEvent se) Notification that an attribute has been replaced in a session

A Sample Listener Class

Let us now take a look at a sample class that is going to listen for context initialization and destruction. The attribute StartDate is set when the container initializes the application. Then when the application quits, the same attribute is logged and then deleted. This is just a simple example so we arent doing anything major here. But in realtime, we may end up putting a lot more code in these methods than what you see below…

Code:

import java.util.Date;
import javax.servlet.ServletContext;
import javax.servlet.ServletContextAttributeEvent;
import javax.servlet.ServletContextAttributeListener;
import javax.servlet.ServletContextEvent;
import javax.servlet.ServletContextListener;

public final class ContextListener
implements ServletContextListener
{
public void contextInitialized(
ServletContextEvent event)
{
ServletContext context = event.getServletContext();
context.setAttribute("StartDate", Date);
}

public void contextDestroyed(ServletContextEvent event)
{
ServletContext context = event.getServletContext();
Date startDate = context.getAttribute("StartDate");
customLog(startDate);
context.removeAttribute("StartDate");
}
}

Similarly we can have classes that listen for various other events and handle them appropriately…

Previous Chapter: Chapter 18 - Using Request Dispatcher

Next Chapter: Quick Recap - Chapters 6 to 19

Chapter 16: Servlet Context

In the previous chapter, we saw how data can be stored and utilized per user session. The session is specific to a users navigation of a website and is not shared among users. If you want the system to retain some information that needs to be shared among various users of the system, we need to user the Context. In this chapter, we are going to see what the context is and what are the methods that are available for us to use.

So, lets get started!!!

The Servlet Context

A Web application includes many parts. It is more than just one servlet or JSP. Numerous JSPs and one or more Servlets and other supporting java classes together form the web application. To help manage an application, you will sometimes need to set and get information that all of the servlets share together, which we will refer to as context-wide.

For Example, if you want a single name using which you can refer to the application, you can set it in the servlet context and have it shared across all instances that use the application.

Ex Code:
public void init(ServletConfig config) throws ServletException
{
super.init(config);
// Get the Context
ServletContext context =config.getServletContext();
// Set the attribute
context.setAttribute(“appName", "My Test App");
}

Any time you want, you can refer to this attribute in the context and get its value like below:

String appName = context.getAttribute(“appName”);

After the above line of code, the variable appName will have the value “My Test App”

Methods in the Servlet Context

Apart from setting and getting custom attributes used for our application, the context also contains various methods that we can use to retrieve specific information about the application and other aspects. They are:

• getAttributeNames() - Returns an Enumeration object containing the attribute names available within this servlet context.
• getContext(String uripath) - Returns a ServletContext object that corresponds to a specified URL on the server.
• getInitParameter(String name) - Returns a string containing the value of the named context-wide initialization parameter, or null if the parameter does not exist.
• getInitParameterNames() - Returns the names of the context's initialization parameters as an Enumeration of string objects, or an empty Enumeration if the context has no initialization parameters.
• getMajorVersion() - Returns the major version as an int of the Java Servlet API that this Servlet Container supports.
• getMimeType(java.lang.String file) - Returns the MIME type as a string of the specified file, or null if the MIME type is not known.
• getMinorVersion() - Returns the minor version as an int of the Servlet API that this Servlet Container supports.
• getNamedDispatcher(String name) Returns a RequestDispatcher object that acts as a wrapper for the named servlet.
• getRealPath(String path) - Returns a string containing the real path for a given virtual path.
• getRequestDispatcher(String path) Returns a RequestDispatcher object that acts as a wrapper for the resource located at the given path.
• getResource(String path) - Returns a URL to the resource that is mapped to a specified path.
• getResourceAsStream(String path) - Returns the resource located at the named path as an InputStream object.
• getServerInfo() Returns the name and version as a String of the Servlet Container on which the servlet is running.

So, as you can see, the context is extremely powerful and useful for any J2EE developer…

Previous Chapter: Chapter 15 - Session

Next Chapter: Chapter 17 - Servlet Life Cycle

Chapter 15: The Session

In the previous chapter we took a look at how the HTTP Request can help us move data from the JSP to the Servlet and vice versa and the methods that are available in the Request object that would help us handle the data it carries.

In this chapter, we are going to look at the Session which is a super-set of the request and can contain data that needs to be retained across different pages.

So, lets get started!!!

The HTTP Session:

The Session is the place where data can be stored and retrieved across multiple hits from the same browser for a certain period of time. For example, lets say you want to login to your online banking website and the browser asks you to enter your login id and password after every click? It would be irritating isn’t it?

Exactly yes.

Thankfully we have the Http session.

When we logon to our bank website and enter our login id and password, the application saves our credentials in the session and uses it when we navigate between screens on the banks website.
Note: For reasons of safety and security, usually sessions in sensitive websites like a bank website or a stock brokers site, the session expires automatically after 5 minutes of inactivity or if the user presses the back or refresh buttons.

Getting the Session Object:

The session object can be obtained from the Request using the below line of code:

HttpSession session = request.getSession();


Setting & Getting Attributes from the Session:

We can set and retrieve attributes from the session using the setAttribute & getAttribute methods.

Ex:

session.setAttribute(“Key”, value); //Setting the value

Object obj = session.getAttribute(“Key”); //Getting the value

Here, “Key” is the identifier that will be used to locate the value saved in the session. The “Key” can be used to retrieve the value using the getAttribute() method.

Other Session Methods:

Some other methods available in the Session are:
1. getId() – Every session has a unique id and this method is used to get that id
2. getCreationTime() – To find out when the session was created
3. getLastAccessedTime() – To find out when the session was accessed last
4. getAttributeNames() – To retrieve all the values stored in the session as an Enumeration


To wrap up, sessions are what you can use to track a single user over a short time period (say 5 or 10 mins usually). You get the session object (HttpSession) from the request object. To track multiple users in your application, you can use the Context. Don't worry, that's our next stop…

For now, this chapter is over!!!

Previous Chapter: Chapter 14 - The Request Object

Next Chapter: Chapter 16 - Servlet Context

Chapter 8: Servlet Request Types

As we saw in the previous chapter, we have many different types of requests that can be handled by the Servlet. For simplicity sake (more importantly the exam has these only) we are going to look at the 3 main types which are Get, Post and Put.

So, lets get started!!!

GET

The GET type request is normally used for simple HTML page requests. The Servlets method that will handle this type of request would look like:
public void doGet(HttpServletRequest request, HttpServletResponse response)
throws IOException, ServletException
{
// code to handle Get Request here
}

This is probably the first of the servlet methods any programmer begins his j2ee journey with. Even if this is the only method in your servlet, you’ll be able to handle a majority of the requests that get submitted to it. When a request gets submitted using the Get method, the whole URL in the browsers address bar gets passed on to the servlet and will be parsed & understood by the servlet when the request is processed.

Note: The init() and service() methods involved in a request are already provided by the HttpServlet class, so they don't need to be overridden. Overriding the init() method is always a good idea and overriding the service method can be done if you want (remember the example in the previous chapter???)

On the Job: The GET is the most common type of browser request.

POST

The POST type request is frequently used by pages that use HTML forms. A typical doXXX method that handles these requests would look as below:
public void doPost(HttpServletRequest request, HttpServletResponse response)
throws IOException, ServletException
{
//Code to handle Post request
}

The POST method is more sophisticated than a GET request. Normally, a Web form has fields whose names and values are sent to the server in key-value pairs. The POST is designed for posting large messages or providing a block of data, such as the result of submitting a form; and submitting long data fields to a database etc.

The amount of data you can send from the browser to the Servlet using POST is much larger than what we can send using GET.


Comparison Between Get and Post:

GET	POST
Query string or form data is simply appended to the URL as name-value pairs.	Form name-value pairs are sent in the body of the request, not in the URL itself.
Query length is limited (~1KB).	Query length is unlimited.
Users can see data in address bar.	Data hidden from users.
Not Safe – A person standing over your shoulder can view your userid/pwd if submitted via Get	Safe – No one will be able to view what data is getting submitted
invokes doGet()	invokes doPost()
Supports ASCII.	Supports ASCII + Binary.
Easy to bookmark	Hard to bookmark.

PUT

The PUT type request is used for uploading files to the server. While uploading is its original intent, it isnt used much. Instead, people prefer the POST to upload files over PUT. The doXXX method that handles PUT requests would look like below:

public void doPut(HttpServletRequest request, HttpServletResponse response)
throws IOException, ServletException
{
//code to handle PUT request goes here
}

The doPut() method is called by the server (via the service method) to handle a PUT request. Uploading files from a browser has always been tricky. The idea behind the PUT operation is to make uploading easy. It is supposed to allow a client to place a file on the server, just like sending a file by FTP. The javadoc for this method warns that when overriding this method, you should leave intact any content headers sent with the request (including Content-Length, Content-Type, Content-Transfer-Encoding, Content-Encoding, Content-Base, Content-Language, Content-Location, Content-MD5, and Content-Range). This method is rarely used, but it is powerful if you decide on using it.

Setting Request Submission Type:

We have seen how the GET/POST request submissions work and what their features are. But, we havent yet seen how to set the request submission type. Well, its pretty straightforward. Lets look at an example:

< form method= "GET" action="/myservlet/process" >

The above is a form declaration where the method is set as “GET”. You can replace this with “POST” and your JSP would work without any issues (Remember that you need to have the corresponding doXXX method in your servlet to handle the request that gets submitted)


Previous Chapter: Chapter 7 - Overriding HttpServlet GET, POST, and PUT Methods

Next Chapter: Chapter 9 - Triggering HttpServlet GET, POST, and HEAD Methods

Quick Recap: Chapters 1 to 5

Let us quickly go over the concepts we have covered in the past few chapters.

JSP & Servlet History

• ARPANET was the initial backbone based on which Internet was built
• Tim Berners Lee paved the way for the current day Internet and World Wide Web
• CGI helped people transfer data from one computer to another
• Because CGI was not scalable, people looked out for better alternatives
• JSP and Servlets became an easier and a more scalable alternative to CGI


Advantages of Using Servlets

a. They are faster than CGI scripts because each CGI script produces an entirely new process that takes a lot of time to execute, whereas a servlet creates only a new thread.
b. Servlet API is standard and available easily on the internet (like JSPs)
c. Servlets have the advantages like ease of development & platform independence (like Java)
d. They can access all the J2SE and J2EE APIs
e. Can take the full advantage & capabilities of the Java programming language

Advantages of Using JSPs

a. Write Once, Run Anywhere
b. Code Re-use
c. Support for Scripting
d. Supports Actions
e. Supports both Static & Dynamic Content
f. Supports N-tier Enterprise Application Architecture
g. Superior Quality Documentation & Examples (All over the internet)
h. Reusable Tag Libraries

Web Servers & Servlet Containers

• A web server is the server on which our J2EE application runs
• A Servlet container is similar to a JVM for java programs and executes our Servlets
• Data is transferred using the request/response model


JSP to Servlet Conversion

• A JSP file gets converted into a Servlet at run time
• The web server (Ex: Tomcat) does the conversion of the JSP
• The web server invokes the converted Servlet version of the JSP page, every time the JSP is invoked.

Previous Chapter: Chapter 5 - JSP to Servlet Conversion

Next Chapter: Self Test - Chapters 1 to 5

Chapter 5: JSP to Servlet Conversion

In the previous chapter, we took a look at how a JSP file looks like and the contents that can be present inside a typical JSP file.

As you might already know (If you have J2EE programming experience) a JSP file gets converted into a Servlet at runtime and then gets executed. Well, if you did not know this, don't worry. That is what this chapter is for. To tell you the fact that JSPs get converted into Servlets for execution and also to tell you how that happens.

So, lets get started!!!

JSP to Servlet Conversion

JSPs are converted to servlets before the container runs them. This is actually cool because you don't need hardcore java programming skills to create a JSP page whereas you’ll need them to write a servlet. Moreover, all you’ll need to write a JSP is some expertise in creating HTML files and in using JavaScript. You can create front-end JSP pages without having much expertise in Java at all. Although JSP reduces the required skill level, JSP becomes a servlet, with the nice performance and portability benefits.

Below is how the conversion happens.

First lets look at a sample JSP page that we will consider for this conversion process. It's the same sample JSP we saw in the previous chapter. Lets name this guy my_first_jsp.jsp
Sample JSP File Code:

< html >
< body >
I Like Cars, Especially Ferrari .
< / body >
< / html >

This JSP file has to be placed in the …\jakarta-tomcat-4.0.1\webapps\examples\jsp folder in our system. To access this JSP through the tomcat server we can use the below URL:

http://localhost:8080/examples/jsp/my_first_jsp.jsp.

When you hit enter after typing the contents above in the browsers address bar, tomcat covnerts this JSP into a servlet, compiles it and then invokes it.

The servlet that gets created will be placed in …\jakarta-tomcat-4.0.1\work\localhost\examples\jsp as my_0005fservlet$jsp.java.

The contents of this converted Servlet would be as below:

package org.apache.jsp;

import javax.servlet.*;
import javax.servlet.http.*;
import javax.servlet.jsp.*;
import org.apache.jasper.runtime.*;

public class my_0005fservlet$jsp extends HttpJspBase {

static {
}
public my_0005fservlet$jsp( ) {
}

private static boolean _jspx_inited = false;

public final void _jspx_init()
throws org.apache.jasper.runtime.JspException {
}

public void _jspService(HttpServletRequest request,
HttpServletResponse response)
throws java.io.IOException, ServletException {

JspFactory _jspxFactory = null;
PageContext pageContext = null;
HttpSession session = null;
ServletContext application = null;
ServletConfig config = null;
JspWriter out = null;
Object page = this;
String _value = null;
try {

if (_jspx_inited == false) {
synchronized (this) {
if (_jspx_inited == false) {
_jspx_init();
_jspx_inited = true;
}
}
}
_jspxFactory = JspFactory.getDefaultFactory();
response.setContentType("text/html;charset=" +
"ISO-8859-1");
pageContext = _jspxFactory.getPageContext(this,
request, response, "",
true, 8192, true);

application = pageContext.getServletContext();
config = pageContext.getServletConfig();
session = pageContext.getSession();
out = pageContext.getOut();

// HTML // begin [file="/jsp/my_first_jsp.jsp"]
out.write(">
\r\n< html >\r\n< body >"+
"\r\nI Like Cars, Especially Ferrari ."+
"\r\n\r\n\r\n");

// end

} catch (Throwable t) {
if (out != null && out.getBufferSize() != 0)
out.clearBuffer();
if (pageContext != null)
pageContext.handlePageException(t);
} finally {
if (_jspxFactory != null)
jspxFactory.releasePageContext(pageContext);
}
}
}

A point to note here is that, the exact code that gets generated for your Servlet might vary slightly and may not exactly match what is given above.

As you can see, Tomcat does a lot of work when it converts our JSP into a servlet. If you look at the source that is sent to your browser, you will see the original HTML in the JSP file.
Well, the above example was a little too easy and in reality we will have some Java code too in our JSP. So, lets take a look at how the conversion happens if we put some java code into our earlier example.

Our Modified JSP:


< html >
< body >
I Like Cars, Especially Ferrari .

< % ! int val1 = 10, val2=5; % >
< % = val1 * val2 % >

//Close the html and body tags here too

Tomcat will now convert the Java embedded in the JSP to the following:

// begin [file="/jsp/my_first_jsp.jsp";from=(7,3);to=(7,31)]
int val1 = 10, val2=5;
// end

It also generates this version of the try block, which differs slightly from the previous servlet code:

try {

if (_jspx_inited == false) {
synchronized (this) {
if (_jspx_inited == false) {
_jspx_init();
_jspx_inited = true;
}
}
}
_jspxFactory = JspFactory.getDefaultFactory();
response.setContentType("text/html;charset=ISO-8859-1");
pageContext = _jspxFactory.getPageContext(this,
request, response,
"", true, 8192, true);

application = pageContext.getServletContext();
config = pageContext.getServletConfig();
session = pageContext.getSession();
out = pageContext.getOut();

// HTML // begin [file="/jsp/my_first_jsp.jsp"...]
out.write("" +
"\r\n< html >\r\n< body >\r\n" +
"I Like Cars, Especially < b > Ferrari < / b >.
\r\n");

// end
// HTML // begin [file="/jsp/my_first_jsp.jsp";from=...]
out.write("\r\n ");

// end
// begin [file="/jsp/my_first_jsp.jsp";from=...]
out.print(val1 * val2);
// end
// HTML // begin [file="/jsp/my_first_jsp.jsp";from=...]
out.write("\r\n\r\n\r\n\r\n");

// end

}

As you can see, Tomcat now takes our val1 and val2 variables that were declared at the top of our JSP page and generates declarations as class variables in the servlet.

So, < % - val1 & val2 % > becomes

out.print(val1*val2);

Once the conversion is complete, this servlet will be compiled and loaded to memory. Every call to invoke this JSP will make Tomcat compare the modification date of the loaded servlet with the date of the JSP. If it is the same, the compiled servlet is executed and contents displayed on screen. Else, if it sees that the JSP has changed, it will recompile the JSP and load the newly converted Servlet instead of the older version.

Previous Chapter: Chapter 4 - A Sample JSP

Next Chapter: Quick Recap - Chapters 1 to 5

Chapter 4: A Sample JSP

In the previous chapter, we took a look at how a sample Servlet would look like. In this Chapter, we are going to take a look at a sample JSP file and the contents of the file.

So, lets get started!!!

A JSP File Contents:

A JSP file can contain the following:
a. HTML contents
b. JavaScript
c. Java Code

Combining the features of the above 3 mentioned items; we get a powerful entity called the JSP. JSPs are used for the User Interface layer or the more colloquially called Front End layer of any J2EE application.

JSP Skeleton

Below is how a Skeleton JSP File would look like. (The file has to be saved as .jsp)

// Page Imports
<%@ page import = “com.xyz.ClassName %>

// Tag Library References
<%@ taglib URI = “path to Taglib file” prefix = “xx” %>
// here xx refers to the prefix with which the tag library will be referred to

// HTML Head & Title Content

// Java Script Content



// HTML Body & Form Contents


Note: Java code can be placed within the <% %> tags in the body part of the JSP page within the Body tags.

As you can see, a JSP file is pretty straightforward. Also, an important point to note here is the fact that, not all of the entities mentioned above are mandatory. You can include or exclude any of the entities mentioned above, based on your requirement and convenience.


Previous Chapter: Chapter 3 - A Sample Servlet

Next Chapter: chapter 5 - JSP to Servlet Conversion

Chapter 2: Web Servers and Servlet Containers

In the previous chapter we looked at the history of the Web (Internet) and how JSPs and Servlets came into being. As you might have already guessed by now, any J2EE application needs a server on which it runs. It is called a Web Server. Also, the Servlet needs something in which it would run (Think of the JVM in which all java applications run) and that is called the Servlet container.

In this chapter, we are going to take a look at these two entities.

So, lets get started!!!

Web Servers and Servlet Containers

A servlet is nothing but Java code that runs in a container. It generates HTML & other contents that get displayed in the web page that we see. It is purely coded in Java, so the benefits and restrictions of all regular Java classes apply here too. Servlets are compiled to form a platform neutral bytecode (All java code is platform neutral, isnt it? Serlvet is no different). Upon request, this bytecode file is loaded into a container. Some containers (servlet engines) are integrated with the Web server, while others are plug-ins or extensions to Web servers that run inside the JVM. Servlets look the same as static Web pages to the client, but they really are complete programs capable of complex operations.

The servlet container is an extension of a Web server in the same way CGI, ASP, and PHP are. A servlet functions just like them, but the language in which it is written is Java. That's the main difference. The servlet doesn't talk to the client directly. The Web server functions as the intermediary that does it for the servlet. In a chain of processes, the client sends a request to the Web server, which hands it to the container, which hands it to the servlet. The Servlet processes the request and generates a response. The response starts from the servlet and goes to the container and then to the Web server and back to the client. Of course there are several other steps that happen too but this is just the introduction so this much would suffice I believe.

The servlet architecture makes the container manage servlets through their lifecycle. The container invokes a servlet upon receiving an HTTP request, providing that servlet with request information and the container configurations. The servlet uses this to do its job which is processing the data it received as part of the request. When finished, it hands back HTML and objects that hold information about the response. The container then forms an HTTP response and returns it to the client which inturn displays the stuff sent by the Servlet on screen in the web browser.

Below is a simple illustration of the flow of control that starts and ends at the Web Browser. Control starts at the browser, goes to the server and then to the container which in turn invokes the Servlet. Our Servlet happily does the processing (which might involve hitting a database) and returns the data to the container which in turn passes it on to the web server which finally displays the contents on the web browser.

The Servlet container is often written in Java, since it eventually runs inside a JVM. However, some vendors implement their containers in different languages (they aren’t essentially bound to Java). The point here is the fact that, all we need is a servlet container that can read and execute our servlets. The language in which it is implemented is not necessarily important for us.

Previous Chapter: Chapter 1 - Servlet & JSP History

Next Chapter: A Sample Servlet

Chapter 1: Servlet & JSP History

Here we are, studying for the SCWCD exam. I would like to congratulate you again for this decision of yours because of which you are going to get yourself SCWCD certified. It's a big step and am gonna be with you step by step to help you get this certification.

Well, it wouldn't be much fun preparing for a certification on JSPs and Servlets without knowing their history. Would it?

This chapter is going to be a history lesson taking you to the humble beginnings of these two wonderful technologies that have made our lives so much more easier & powerful.

How it all Began – Internet

Early in the 1950’s computer scientists in USA were working their backsides off in order to compete with Soviet Unions (The late USSR) advancements in superpower computing. They formed the Advanced Research Projects Agency (ARPA) in the year 1957. In those they still had powerful computers, but they weren’t able to talk or communicate with one another. In 1966 Lawrence G. Roberts (From MIT) proposed the first computer network which was named the ARPANET. The US Department of Defense (DoD) funded the venture and it took them 3 years to implement the network. The ARPANET team rewarded the DoD by establishing the Network Control Protocol (NCP), the first host to host protocol, which made possible for the university and the research center PC’s to communicate with one another.

With the success of the NCP, telco major AT&T installed the first cross country link between UCLA and BBN. It was a humble beginning and by 1973 hundreds of computers were talking to one another.

The real big breakthrough came in the year 1982 when the TCP/IP standard was established by Vint Cerf and Bob Kahn. Based on this development, the Domain Name System was established and by 1984 there were over 1000 hosts registered.

This was the backbone of the current day Internet. It was called NSFNET originally and with multiplying hosts it was becoming difficult to manage. By 1991 there were over a hundred thousand hosts and the system was getting out of control. There was nobody incharge and there was utter chaos all around.

In 1991, Tim Berners Lee created hyperlinks. He invented the whole protocol that made links communicate with one another and the World Wide Web was born. Telnet, email and many other services started using the networks.

In 1993, Marc Anderson and his friends wanted to see what was on the Internet, so they developed a new program called the NCSA Mosaic at the University of Illinois based on Berners Lee’s ideas. (NCSA stands for National Center for Supercomputing Applications)

Mosaic was the catalyst that caused the internet to explode. Nearly 200 million hosts were in use by the end of the decade and more than 1 billion users were using it.

This was not the end of it. Mobile phones, PDAs, GPS, Cars etc started connecting to the internet and the number of users began growing beyond numbers that we can write down or calculate.

It all started with basic HTML pages and hungry scientists created more and more advanced technologies whose powers were unbelievable. JSPs and Servlets just changed the landscape catastrophically and here we are, studying them to become better J2EE web programmers!!!

History of JSP & Servlets

The Internet's original purpose was to access and copy files from one computer to another. While TCP/IP provided a highway layer, the File Transfer Protocol (FTP) specification provided a standard way to exchange those files. It defined a way of shuttling them back and forth, but said nothing about looking at the content. HyperText Markup Language (HTML) allowed us to see the documents on the Internet. FTP can transmit HTML files just as easily as HTTP can. But we use Hypertext Transfer Protocol (HTTP) to act as an FTP specifically for HTML documents because it is a stateless protocol which makes having many short connections more efficient.
HTTP is the plumbing that connects the various computers. Now it is time to discuss about the fluid that flows through it “JSP & Servlets”

Note: JSP & Servlets arent the only technologies that are used in J2EE applications. Struts, Hibernate, Springs etc are other technologies that are used in J2EE Web applications. But, don't worry about them because they arent in the exam.

Using HTTP and HTML people were able to view/browse files and contents on a remote server. This is very useful, but people wanted live data. This is where the CGI (Common Gateway Interface) specification helped us. It helped us connect to databases and display stuff on the fly. The CGI specification was a major breakthrough in Web Application Development. The CGI standards made sure that the same CGI program worked on different Web servers.

CGI became the bread and butter of web developers. It was the most common means of displaying dynamic content on the internet. Though it was good, it wasn't good enough. It was not able to handle the performance requirements of the bursting Internet users. It was literally too much for it.

If you are asking me why CGI couldn't handle the load, the answer is simple. CGI spawned a separate process for every request that it receives. This design was able to sustain during off-peak hours but ate off server resources during peak loads which was eventually too much for it.
With growing numbers of users of web applications, scalability became a key consideration which wasn't CGI’s Middle Name and hence people started exploring other options.

Many CGI derivatives came up as server-side programming solutions that implement business logic, including ASP, ColdFusion, PHP, and Perl. Java surpassed them all due to portability and its object oriented programming design.

Alas, he we are, learning JSPs and Servlets that are the children of the Java Family which make our lives all the more easier in the world of Web Development.

Java was conceptualized in 1991 but it wasn't in the internet programming world until 1997. Servlets were the alternative to CGI and were released in 1997. Unlike CGI, which starts a process for each request, Servlets just spawn a new thread. Servlets had a better or rather efficient architecture which was able to handle the loads of the internet.

Though Servlets were awesome when compared to CGI, they still had some issues when it came to displaying dynamic content on a web page. Thankfully, Sun released the JSP (Java Server Pages) specifications in 1998, which solved all our UI woes. JSPs enabled programmers to display dynamic HTML content that could also use Java features. The combination of JSPs and Servlets was just what the Doctor Prescribed and it just revolutionized the Web Programming industry.
That's it for the history lesson. Now we are all set to dive deep into the world of magical Servlets and JSPs.

Previous Chapter: Introduction to the SCWCD Exam

Next Chapter: Web Servers & Servlet Containers