For most of the lifetime of Java, web-based applications followed the same basic paradigm: the browser makes a request to a particular URL; the server generates a page of HTML in response; and actions by the user drive the browser to the next page. In this exchange, most or all of the work is done on the server side, which is seemingly logical given that that’s where data and services often reside. The problem with this application model is that it is inherently limited by the loss of responsiveness, continuity, and state experienced by the user when loading new “pages” in the browser. It’s difficult to make a web-based application as seamless as a desktop application when the user must jump through a series of discrete pages and it is technically more challenging to maintain application data across those pages. After all, web browsers were not designed to host applications, they were designed to host documents.
This new model simplifies and empowers web development in many ways. No longer must the client work in a single-page, request-response regime where views and requests are ping-ponged back and forth. The client is now more equivalent to a desktop application in that it can respond to user input fluidly and manage remote data and services without interrupting the user.
JSPs are a document-centric (page-oriented) way to write server-side applications. They consist of HTML source utilizing custom tag libraries along with a Java-like syntax embedded within the pages. JSPs are compiled dynamically by the web server into Java servlets and can work with Java APIs directly and indirectly in order to generate dynamic content for the pages. Although all of the work still occurs on the server side, JSPs allow the developer to work as if code was running directly in the page, which has both benefits and drawbacks. The benefit of this sort of “immediate mode” programming style is that it is easy to grasp and quick to crank out. The drawback is that it can lead to an unmanageable mix of business logic and presentation logic in the pages. The more code that appears mixed in with the static content, the greater the maintenance headache.
Most large-scale JSP projects utilize custom tag libraries to minimize ad hoc code in the pages. JSPs are also used in combination with controller servlets that can do the heavy lifting and business logic for them. In this case, the term controller refers to the Model-View-Controller (MVC) separation of concerns that we introduced earlier when talking about Swing GUIs. Maintaining this separation leverages the advantages of JSP while avoiding its pitfalls.
If we think about web applications in terms of the classic MVC model, then a traditional page-oriented application generally has “view” components rendered in the browser, while the model (data) and controllers (logic) reside on the server side. We’ve mentioned some reasons why this style of web application is fading in favor of “single page” applications where more of these components move into the browser; however, over the years many frameworks have been developed to support this classic web app arrangement. Generally these frameworks work at a higher level than servlets, providing a convenient way to write controller components, connect them, and configure page views for the results.
One of the most popular frameworks for building page-oriented web applications has been the Apache Foundation’s Struts Web Application Framework. Struts implements the MVC paradigm by providing both a modular controller component architecture and an extensive tag library for JSP page view development. Struts abstracts some of the mapping and navigation aspects required to glue together a web application through the use of an XML-based configuration file and also adds the ability to do declarative mapping of HTML forms to Java objects as well as automated validation of form fields.
JSF was Sun’s response to Struts. Developed through the Java Community Process (including some of the original Struts people) it was intended to become the “official” Java-sanctioned web-application framework. JSF built upon lessons learned with Struts and refined the MVC model with server-side application components and more fine-grained navigation and event management. JSF met mixed reviews and never really surpassed Struts in popularity.