Modern web applications are situated in a complex technological context. Some books that you read might be about a single subject, such as the Java language, or a specific API or library. This book is about Struts 2, a full-featured web application framework for the Java EE platform. As such, this book must take into account the vast array of technologies that converge in the space of the Java EE.
In response to this complexity, we’ll start by outlining some of the most impor- tant technologies that Struts 2 depends on. Struts 2 provides some powerful boosts to production through convention over configuration, and automates many tasks that were previously accomplished only by the sweat of the developer. But we think true efficiency comes through understanding the underlying technological context, particularly as these technologies become more and more obscured by the opacity of scaffolding and the like. That said, the first half of this chapter provides a primer on the Struts 2 environment. If you’re comfortable with this stuff, feel free to skim or skip these sections entirely.
After sketching the important figures of the landscape, we’ll move into a high-level overview of Struts 2 itself. We’ll introduce how the Model-View-Controller (MVC) fits into the Struts 2 architecture. After that, we’ll go through a more detailed account of what happens when the framework processes a request. When we finish up, you’ll be fully ready for chapter 2’s HelloWorld application.
Let’s get going!
1.1 Web applications: a quick study
This section provides a rough primer on the technological context of a web application. We’ll cover the technology stack upon which web applications sit, and take a quick survey of common tasks that all web applications must routinely accomplish as they service their requests. If you’re quite familiar with this information, you could skip ahead to the Struts 2 architectural overview in section 1.3, but a quick study of the following sections would still provide an orientation on how we, the authors, view the web application domain.
1.1.1 Using the Web to build applications
While many Java developers today may have worked on web applications for most of their careers, it’s always beneficial to revisit the foundations of the domain in which one is working. A solid understanding of the context in which a framework such as Struts 2 is situated provides an intuitive understanding of the architectural decisions made by the framework. Also, establishing a common vocabulary for our discussions will make everything easier throughout the book.
A web application is simply, or not so simply, an application that runs over the Web. With rapid improvements in Internet speed, connectivity, and client/server technologies, the Web has become an increasingly powerful platform for building all classes of applications, from standard business-oriented enterprise solutions to personal software. The latest iterations of web applications must be as full featured and easy to use as traditional desktop applications. Yet, in spite of the increasing variety in applications built on the web platform, the core workflow of these applications remains markedly consistent, a perfect opportunity for reuse. Frameworks such as Struts 2 strive to release the developer from the mundane concerns of the domain by providing a reusable architectural solution to the core web application workflows.
1.1.2 Examining the technology stack
We’ll now take a quick look at two of the main components in the technology stack upon which a web application is built. In one sense, the Web is a simple affair: as with all good solutions, if it weren’t simple, it probably wouldn’t be successful. Figure 1.1 provides a simple depiction of the context in which Struts 2 is used.
As depicted in figure 1.1, Struts 2 sits on top of two important technologies. At the heart of all Struts 2 applications lie the client/server exchanges of the
HTTP protocol. The Java Servlet API exposes these low level HTTP communications to the Java language. Although it’s possible to write web applications by directly coding against the Servlet API, this is generally not considered a good practice. Basically, Struts 2 uses the Servlet API so that you don’t have to. But while it’s a good idea to keep the Servlet API out of your Struts 2 code, it seems cavalier to enter into Struts 2 development without some idea of the underlying technologies. The next two sections provide concise descriptions of the more relevant aspects of HTTP and Java Servlets.
HYPERTEXT TRANSFER PROTOCOL (HTTP)
Most web applications run on top of HTTP. This protocol is a stateless series of client/server message exchanges. Normally, the client is a web browser and the server is a web or application server. The client initiates communication by sending a request for a specific resource. The resource can be a static HTML document that exists on the server’s local file system, or it can be a dynamically generated document with untold complexity behind its creation.
Much could be said about the HTTP protocol and the variety of ways of doing things in this domain. We’ll limit ourselves to the most important implications as seen from the perspective of a web application. We can start by noting that HTTP was not originally designed to serve in the capacity that web application developers demand of it. It was meant for requesting and serving static HTML documents. All web applications built on HTTP must address this discrepancy.
For web applications, HTTP has two hurdles to get over. It’s stateless, and it’s text based. Stateless protocols don’t keep track of the relationships among the various requests they receive. Each request is handled as if it were the only request the server had ever received. The HTTP server keeps no records that would allow it to track and logically connect multiple requests from a given client. The server has the client’s address, but it will only be used to return the currently requested document. If the client turns around and requests another document, the server will be unaware of this
client’s repeated visits.
But if we are trying to build more complex web applications with more complicated use cases, this won’t work. Take the simplest, most common case of the secure web application. A secure application needs to authenticate its users. To do this, the request in which the client sends the user name and password must somehow be associated with all other requests coming from that client during that user session. Without the ability to keep track of relationships among various requests, even this introductory use case of modern web applications is impossible. This problem must be addressed by every modern web application.
Equally as troublesome, HTTP also is text based. Mating a text-based technology to a strongly typed technology such as Java creates a significant amount of data-binding work. While in the form of an HTTP request, all data must be represented as text. Somewhere along the way, this encoding of data must be mapped onto Java data types. Furthermore, this process must occur at both ends of the request-handling process. Incoming request parameters must be migrated into the Java environment, and outgoing responses must pull data from Java back into the text-based HTTP response. While this is not rocket science, it can create mounds of drudge work for a web application. These tasks are both error-prone and time-consuming.
JAVA SERVLET API
The Java Servlet API helps alleviate some of the pain. This important technology exposes HTTP to the Java platform. This means that Java developers can write HTTP server code against an intuitive object-oriented abstraction of the HTTP client/server communications. The central figures in the Servlet API are the servlet, request, and response objects. A servlet is a singleton Java object whose whole purpose is to receive requests and return responses after some arbitrary back-end processing. The request
object encapsulates the various details of the request, including the all-important request parameters as submitted via form fields and querystring parameters. The response object includes such key items as the response headers and the output stream that will generate the text of the response. In short, a servlet receives a request object, examines its data, does the appropriate back-end magic, and then writes and returns the response to the client.
ESSENTIAL KNOWLEDGE
You should know Sun and the Servlet Specification. If you’re unfamiliar with Sun’s way of doing things, here’s a short course. Sun provides a specification of a technology, such as the Servlet API. The specifications are generated through a community process that includes a variety of interested parties, not the least of which is Sun itself. The specification details the obligations and contracts that the API must honor; actual implementations are provided by various third-party vendors. In the case of the Servlet Specification, the implementations are servlet containers. These containers can be standalone implementations such as the popular Apache Tomcat, or they can be containers embedded in some larger application server. They also run the gamut from open source to fully proprietary. If you’re unfamiliar with the Servlet Specification, we recommend reading it. It’s short, to the point, and well written.
Next
Sebuah kelompok penekan pro-Israel tengah merencanakan sebuah kampanye rahasia dan berjangka panjang untuk menginfiltrasi ensiklopedia online terpopuler Wikipedia, dengan maksud menulis ulang sejarah Palestina, menciptakan impresi agar sebuah propaganda tampak sebagai fakta, dan bahkan mengambil-alih struktur administratif Wikipedia untuk memastikan berbagai perubahan itu berjalan tanpa terdeteksi dan tanpa tentangan