Source from : http://www.pearsonitcertification.com/articles/article.aspx?p=29786&seqNum=3
The Internet's original purpose was to access and copy files from one computer to another far away (they already had short distance networks by then, but they were expensive, proprietary, and not ready for mass consumption). 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 connectionless/ stateless protocol which makes having many short connections more efficient.
Now that we have discussed the plumbing, our attention turns to the content. What files should be published? Perhaps our data isn't in files, but in databases. Some of the content is old, but the majority of data is only days old. This immediacy drives traffic on the Internet.
With HTML running over HTTP, an end user can browse files housed on a distant server. This is useful, but live data is even better. The Common Gateway Interface (CGI) specification allowed a Web server to reach beyond the file server and grab data from corporate databases. This also meant that CGI could change the HTML on-the-fly. The CGI specification was a major breakthrough in Web application development. The standard made sure that the same CGI program worked on different Web servers.
CGI became the most common means of delivering dynamic content. Alas, the pressure of the Internet was too much. CGI's performance just couldn't keep up because of a technical glitch where each request for a CGI script spawned a separate process. This design nibbled server resources off-hours but devoured them during peak loads. Further demand came, but, fortunately, better solutions came also. Functionality and scalability became key. Plain file-returning Web servers, even CGI-enabled ones, needed to mature into true application servers.
Many CGI derivatives sprouted 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.
Java has come a long way since its inception in 1991 when Sun launched "Project Green," which tried to integrate digitally controlled consumer devices like TV sets, CD players, and computers. OAK (a name which comes from an oak tree outside Gosling's window!) was born, but didn't come to life until HotJava and applets. This was a humble beginning. Sun threw the gauntlet down in 1995 by releasing Java as open source. The feedback was tremendous, and fixed more than just a few bugs. This drove Java deep into the server- side development industry.
Naturally, Sun packed Java with Internet functionality, and in June 1997 Sun announced the servlet interface. Servlets targeted CGI. Unlike CGI, which starts a process for each request, Servlets run in a single process using finer grain threads instead. Servlets represent a more efficient architecture, helping them withstand the Internet's mercurial crush. How can we possibly keep up? It's hard, but we can do it with Java servlets, which provide the foundation for developing Java Web components. One advantage to servlets is that the additional overhead for each additional simultaneous request the servlet handles is very small.
Servlets require real Java programming skills. However, the look and feel belongs to the marketing team. So, what can the graphics people do? They can thank Sun for JavaServer Pages (JSP), which was released in 1998. Inspired, some say copied, by the immensely successful Microsoft ASP, Sun made it easy to write dynamic HTML pages. With JSP, the marketing team can do their work, and with servlets the engineers can do theirs. Together, servlets and JSPs pages enable you to develop modular, maintainable, scalable, and portable Web applications. Another advantage is how Java provides a separation between JSPs, which are created by the marketers, and the JavaBeans they use, which are created by the engineers.