Struts: The Complete Reference, 2nd Edition
A Brief History of Web Application Development
In order to fully understand and appreciate the need for and value of Struts, it's necessary to shed some light on how Web application development has evolved over the past several years. Initially the Internet was used primarily by the academic and military communities for sharing research information, most of which was in the form of static documents. Thus, originally, the Internet was mostly a mechanism for sharing files.
In 1995 the commercialization of the Internet began and there was an explosion of content made available on the Web. Similar to the research content that was being shared on the Web, the early commercial content principally consisted of text mixed with simple graphics. Hyperlinks were used to connect the content together. Although hyperlinks enabled the user to move from page to page, each page was still a static document that did not support other forms of user interaction. It wasn't long, though, before businesses wanted to be able to offer dynamic content that offered the user a richer, more interactive experience.
Before continuing, it will be helpful to explain precisely what is meant by dynamic content. In short, dynamic content is data that is specifically targeted for a particular user. For example, a user may want to check the price and availability of some item in an online store. The user enters the item name in an HTML form and the server supplies the response. The response is generated on the fly based on the request, and is thus dynamic content.
To fill the dynamic-content void, Web server software began to support the use of CGI scripts for creating applications that could run on a Web server and generate dynamic content back to a browser. CGI, or Common Gateway Interface, allowed Web servers to accept a request and execute a server-side program that would perform some action and then generate output on standard out. Web server software would then read that output and send it back to the requesting browser. Initially, many of these CGI scripts were written in Perl or other Unix-based scripting languages. Over time, though, as the applications being built to run as CGI scripts grew in complexity, more application-oriented languages like C and C++ were being used to create larger, more robust applications. With the advent of HTML forms, CGI scripts also were able to receive data from the browser and process it. As most readers know, HTML forms allow data entry on a Web page. That data could be sent to a CGI script on the server and then manipulated, stored, or otherwise processed.
Around the same time that CGI-based application development was becoming popular on the server side, the Java programming language was introduced, with an initial focus on applets. Applets gave the Web developer the ability to add rich, dynamic functionality to Web pages. Because Java offered the promise of "write once and run anywhere" programs, any browser that supported Java could run the applets. For the first time, developers could easily include dynamic content on a Web page.
For the same reasons that Java began to blossom on the client side with applets, Java also began to make inroads on the server side with the advent of servlet technology in 1997. Servlets solved many of the shortcomings of CGI, such as portability and efficiency, and offered a Java-based solution for the Web application paradigm. Servlets are portable across operating systems and can run on any server that has a Java Virtual Machine (JVM) and servlet container. Thus, they also benefit from Java's "write once, run anywhere" philosophy. Servlets have a more efficient execution model than CGIs because they are multithreaded instead of requiring a new process for each request. Servlets also have access to Java's vast libraries, including the JDBC APIs.
After servlets were introduced, Sun released the JavaServer Pages (JSP) technology as an extension to the servlet technology. JSPs take the reverse approach from servlets to building Web applications by having Java code intermingled in an HTML-based page. When a request is made to the server for a JSP, the Java servlet container checks if the JSP has already been compiled into a servlet. If it has, it proceeds to execute the servlet. If the JSP has not yet been compiled into a servlet, the server container converts the JSP code into a Java source file and then compiles that source so that subsequent requests to the JSP will find the servlet already compiled and ready to execute.
The nice thing about this approach is that changes to the JSP HTML can be made without having to manually recompile the code. The server container manages the compilation and will recognize that the HTML in the JSP has changed and recompile the JSP into a servlet for you. JSPs solve the problem of presentation code (HTML) being embedded in servlets, which made development cumbersome because HTML authors had to wade through Java code to edit HTML (not a good separation of responsibilities). In contrast, HTML developers can work on JSPs directly without interfering with Java code.
As the preceding discussion shows, many of the changes in Web-based development that have occurred over the past several years have been driven by the desire to efficiently include dynamic content in a Web page. Streamlining the use of dynamic content has been, and remains, one of the more important issues associated with the Internet and the applications that use it. As you will see, Struts is part of the solution to the dynamic-content problem.