In the previous chapter we saw how a Servlet handles a Http Request that comes from a web browser. We also saw that there are many doXXX() methods inside a Servlet that serve a specific purpose. In this chapter we are going look at the XXX part of the Servlet code.
So, lets get started!!!
The doXXX Methods
There are 3 main types of requests that get processed by a Servlet. They are:
• Get
• Post
• Put
Each of them have a corresponding doXXX() method in the Servlet class which would be:
• doGet
• doPost
• doPut
In the exam you can expect many questions related to this topic so pay attention!!!
These methods are called by the service method in your Servlet.
Let us now take a look at a sample Servlet that has these 3 doXXX methods.
import java.io.*;
import javax.servlet.*;
import javax.servlet.http.*;
/**
* A servlet that has the 3 doXXX Methods
*
* @author Anand
*/
public class OurSecondServlet extends HttpServlet
{
// doGet()
public void doGet(HttpServletRequest request,
HttpServletResponse response)
throws IOException, ServletException
{
requestType("GET", response);
}
// doPost()
public void doPost(HttpServletRequest request,
HttpServletResponse response)
throws IOException, ServletException
{
requestType("POST", response);
}
// doPut()
public void doPut(HttpServletRequest request,
HttpServletResponse response)
throws IOException, ServletException
{
requestType("PUT", response);
}
public void requestType(String requestType,
HttpServletResponse response)
throws IOException, ServletException
{
response.setContentType("text/html");
PrintWriter out = response.getWriter();
out.println("< html >");
out.println("< head >");
out.println("< title >Our Second Servlet" +
"< / title >");
out.println("< / head >");
out.println("< body >");
out.println("< h1 >Servlet Request< / h1 >");
out.println("The Submitted Request type is : " + requestType);
out.println("< / body >");
out.println("< / html >");
}
}
How this code works?
As you can see, we have 3 different doXXX methods in our servlet, each of them calling the same method with just one parameter that differentiates them. Ideally in most cases, our code would be like this too. The logic that gets executed is mostly the same irrespective of the type of request submission. So, the doXXX methods, just receive the request, add some identifier that can be used to identify what request is submitted and then calls another method which will eventually be called by the other doXXX methods too.
The delegate method does the actual processing and returns the results.
In this case, based on the doXXX method calling it, the output will be different. If you submit using the GET option, you will get the below screen:
As mentioned earlier, the service method would invoke the appropriate doXXX method based on the request submission type. But, if you are curious and wonder how the code for such a service method would look like, well, you don't have to search anymore. Here is how it would look:
protected void service(HttpServletRequest req,
HttpServletResponse resp)
throws ServletException, IOException
{
String method = req.getMethod();
if (method.equals(METHOD_GET))
{
// Call doGet
doGet(req, resp);
} else if (method.equals(METHOD_POST))
{
// call doPost
doPost(req, resp);
} else if (method.equals(METHOD_PUT))
{
// call doPut
doPut(req, resp);
} else
{
// Our Servlet doesn't currently support
// other types of request.
String errMsg = "Method Not Supported");
resp.sendError(
HttpServletResponse.SC_NOT_IMPLEMENTED, errMsg);
}
}
Previous Chapter: Chapter 6 - Servlet Handling of Http Request
Next Chapter: Chapter 8 - Servlet Request Types
Topics Covered in the Blog - Synopsis
Showing posts with label servlets and jsps. Show all posts
Showing posts with label servlets and jsps. Show all posts
Tuesday, March 1, 2011
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
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
Labels:
arpanet,
internet history,
j2ee history,
jsp,
jsp and servlets,
quick recap,
quick review,
scwcd,
scwcd certification,
scwcd exam,
servlets,
servlets and jsps
| Reactions: |
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 body >\r\n html >\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 body >\r\n html >\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
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 body >\r\n html >\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 body >\r\n html >\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
Labels:
jsp,
jsp and servlets,
jsp compilation,
jsp conversion,
jsp to servlet,
jsp to servlet conversion,
jsp translation,
servlet,
servlets and jsps
| Reactions: |
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)
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
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
Labels:
j2ee,
jsp,
jsp and servlets,
jsp code,
jsp sample,
sample jsp,
scwcd,
scwcd certification,
servlets and jsps
| Reactions: |
Monday, February 28, 2011
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
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
Labels:
getting scwcd certified,
jsp,
jsp and servlets,
jsp servlets,
jsps,
scwcd,
scwcd certification,
servlet,
servlet and jsp,
servlets,
servlets and jsps
| Reactions: |
Subscribe to:
Posts (Atom)
© 2013 by www.inheritingjava.blogspot.com. All rights reserved. No part of this blog or its contents may be reproduced or transmitted in any form or by any means, electronic, mechanical, photocopying, recording, or otherwise, without prior written permission of the Author.

