Sunday, October 12, 2008

CGI, Servlets, JSP, Model 1 & 2 Architectures


CGI, Servlets, JSP, Model 1 & 2 Architectures

Evolution of Dynamic Content Generation

When World Wide Web (WWW) started in the year 1989 at he CERN laboratory the idea was to have a mechanism which enabled sharing of research information among researchers using hypertext docs. And hence Web was designed to serve static contents in the beginning. The obvious and natural progression was to have the ability of dynamic content generation on Web and there came the concept of CGI.

CGI - Common Gateway Interface

CGI was designed to generate the contents on the Web dynamically. It became hugely popular in no time as it allowed the Web applications to access the database to show results based on dynamically selected criterio and it also facilitated insert/update of information in the database accepting the info from the end-user.

As the popularity grew the scalability of the web applications also grew and then we started realizing the limitaions of CGI.

Limitations of CGI

New Process per Request - the main drawback of CGI approach was that it spawned a new heavy-weight Operating System process everytime a new request was made from the end users (from browser). This immensely restricted the scalability and responsiveness of the web
applications as creating (and reclaiming once the request is served) OS processes are time and resource consuming stuff.Communication Gap between Web Server and Requests - since all the requests are executed in a different OS process from the Web Server process hence it becomes difficult to have a smooth communication between the server and the requests to handle stuff like logging, authorization, etc.

Alternatives of CGI

Several alternatives of CGI came into picture - all having relatively better performance and scalability support, but it was the Java Servlets Technology which actually replaced CGI almost entirely. These alternatives are:

  • FastCGI
  • mod_perl
  • NSAPI
  • ISAPI
  • Java Servlets
Java Servlets - what are they?

Sun Microsystems introduced this technology in the year 1997 and it became an instant hit due to various advantages it provided over CGI. It was no longer required to have a new process every time a request was made from an end-user. It was a platform-independent (As it is written completely in Java), component-based approach of developing web applications having dynamic content genration capabilities. Since it is written in Java hence all the tested and tried rich set of APIs of Java are readily available to be used and this advantage took this technology way above its competitors.

Why were JSPs needed when we had Servlets?

Servlets do an excellent job of dynamic content generation, but it becomes difficult and tedious to use Servlets for presentation of the data in HTML. EVery HTML change requires us to recompile the Servlet and the maintenance of Servlets become difficult as HTML changes are quite frequest in nature and using Servlets to do that ends up making corresponding Java code changes everytime.

Another serious drawback of this approach was that it didn't facilitate clear separation of roles and responsibilities. HTML design and devlopment is primarily the responsibility of a Web Designer (usually a person having limited Java expertise) whereas the responsibility of design & development of Servlets belongs to Java Developers. Using Servlets for presentaion of data mixed both these roles and hence the entire devlopment life cycle used to be more complex and hence slower. A clear separation of roles and responsibilities enhanced the overall development cycle and it also made the applications better maintainable.

JSP (JavaServer Pages) Technology is used to achieve this clear separation. A JSP can use normal HTML tags/elements the way we can have in any other normal HTML file and in addition it can have Tags, Scriptlets, etc. to encapsulate the business logic for the dynamic content generation. A Web Designer can simply use those tags or leave the scriptlets to be embedded by the Java Developers. In fact, it's become a better practice to avoid scriptlets as much as we can from a JSP page and to rely only on Tags for the dynamic content generation. This not only makes the life of JSP Page easier, but also enhances the reusability of the code (writen for Tags) and hence improves maintanability.

JSP Model 1 Architecture

JSP Model 1 Architecture

In this architecture a JSP Page is used not only for the display of the output to the client, but also for the entire request processing including Accepting the Request, Creating JavaBeans (or connecting to the DB for data), Executing the Business Logic to generate Dynamic Content, etc. This approach has the obvious disadvantage of having a complex inflexible and less maintainable JSP Page.

JSP Model 2 Archirecture

JSP Model 2 Architecture The main difference between Model 1 and Model 2 architectures lies in the way the request is processed. It's based on the MVC (Model View Controller) pattern and a Servlet (serving as the Controller) is used to intercept all the client requests which connects to the DB and builds the JavaBeans (which serve as the Model), and finally makes the data to the corresponding JSP (serving as the View) which actually serves the request. Evidently this approach ias far more organized, scalable, efficient, and maintainable than the previous one.



Share/Save/Bookmark


No comments: