Many different ways of writing server-side software for web applications have evolved over the years. Early on, the standard was CGI, which provided a way to service web browser requests with scripting language such as Perl. Various web servers also offered native-language APIs, such as modules for the Apache web server written in C and C++. The Java Servlet API, however, rapidly became the most popular architecture for building web-based applications because it offered portability, security, and high performance. Today, Java-based web services compete with similar services offered by Microsoft .NET and alternatives such as Ruby on Rails for building web application components. However, the overriding trend in web applications today is to focus less on the server technology and more on client-side technologies such as JavaScript and HTML5 in communication with server-side components and web services regardless of the implementation language. We’ll try to offer some perspective on this throughout this chapter.
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.
But a lot has changed in web application development in recent years. Standards for HTML and JavaScript have matured to the point where it is practical to write applications in which most of the user interface and logic reside on the client side and background calls are made to the server for data and services. In this paradigm, the server effectively returns just a single “page” of HTML that references the bulk of the JavaScript, CSS, and other resources used to render the application interface. JavaScript then takes over, manipulating elements on the page or creating new ones dynamically using advanced HTML DOM features to produce the UI. JavaScript also makes asynchronous (background) calls to the server to fetch data and invoke services. In many cases, the results are returned as XML, leading to the term Asynchronous JavaScript and XML (AJAX) for this style of interaction.
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.
Before we move on to our discussion of the Servlet API, we will briefly describe Java’s relationship to some related web technologies, old and new.
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.
XML is a set of standards for working with structured information in text form. The Extensible Stylesheet Language (XSL) is a language for transforming XML documents into other kinds of documents, including HTML. The combination of servlets that can generate XML content and XSL stylesheets that can transform content for presentation is a very powerful combination, covered in detail in Chapter 24. As we’ll discuss later, web services also use XML as their native data format, making them completely portable across platforms and languages. And, of course, XML is the basis for returning data to JavaScript applications in the original AJAX style of web development.
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.
Spring Web Flow is another popular web application MVC system that is based on the Spring application framework. There are many, many examples of Java web application frameworks.
Google Web Toolkit, or GWT, is a free framework produced by Google that allows developers to write web applications using the Java programming language. GWT compiles Java components to JavaScript that runs in a web browser and communicates with the server via a custom RPC mechanism that acts something like Java RMI. The GWT environment provides its own set of Java GUI classes and a substantial subset of the standard Java libraries. GWT is a very powerful framework that makes it possible to write large and complex applications with most of the benefits of the Java programming language while running in a web browser. However, GWT has a somewhat steeper learning curve than some other web frameworks (especially for those unfamiliar with both Java and JavaScript).
Java lives on the server side of web applications. To build the client pieces of applications that run in browsers, we must cooperate with Java’s namesake, JavaScript. As we’ve mentioned, in recent years efforts to standardize advanced features of HTML and JavaScript have paid off in a real revolution in the capabilities of web applications and the way in which they are built. Much of this began with adding more dynamic behavior to clients via AJAX calls. More recently, the explosion of mobile browsers has fueled the adoption of the HTML5 standard, bringing web browsers a richer feature set including a more complete DOM, native video and audio media support, general canvas drawing and vector graphics support, and offline data storage. Even more exciting technologies can be used today while working their way through the standards process. One to keep an eye on is WebSockets, which provides for low-latency messaging between the browser and server and should enable many new types of applications.
Get Learning Java, 4th Edition now with the O’Reilly learning platform.
O’Reilly members experience books, live events, courses curated by job role, and more from O’Reilly and nearly 200 top publishers.
