- Introduction
- Prerequisite Review
- Discussion
- Essential Points
- Review Your Progress
This chapter is from the book
This chapter is from the book
This chapter is from the book
Prerequisite Review
The following list details resources and specifications that you should be familiar with before reading this chapter. The main resources are as follows:
- The JavaServer Pages 2.1 specification—JSR 245
- The Servlet 2.5 specification—JSR 154
- The JSF 1.2 specification—JSR 252
- The JSTL 1.2 specification—JSR 52
- The Java EE 5 specification—JSR 244
We now cover the specific topics that should be addressed at a high level before more esoteric and advanced discussions on the relative advantages and disadvantages of the various JEE web tier technologies.
Model View Controller (MVC)
Regardless of application domain or industry vertical, technology platform, and client-side technology, everyone agrees that three fundamental concepts should be decoupled and kept separate—namely, the data, the business logic that operates on that data, and the presentation of that data to the end user (see Figure 3-1). In the JEE platform, the seminal design pattern that enforces this separation of concerns is called the MVC model. In the earliest releases of the specification, references were made to Model 1 and Model 2 architectures. However, all mainstream frameworks now embrace Model 2 exclusively—where views (implemented as JSP pages with or without JSF components) forward to a central controller (implemented as a Servlet), which invokes a named handler for the page or action before forwarding the user to a well-defined page to render the outcome of the request.
)
Figure 3-1 A high-level schematic depicting the basic flow between the three major components of the Model-View-Controller design pattern. All MVC web frameworks follow this basic separation of concerns to a greater or lesser extent.
Web Container
The web container is analogous to the EJB container described in Chapter 4, "Business Tier Technologies." Simply put, one of the biggest advantages of the JEE platform is how much it gives the developer out of the box from an infrastructure perspective, leaving the developer free to focus on how to use the JEE platform to implement the required business logic for their application. A web container provides services to presentation and control components provided by the developer, implemented as JSPs, JSF components, Servlets, filters, web event listeners, and plain old Java classes (POJOs). These services include concurrency control, access to user-managed transactions (more on this later), configuration, and security management.
Servlets
A Servlet is a server-side component designed to handle inbound service requests from remote clients. Although the vast majority of all Servlets implemented are designed to respond to HTTP/HTTPS GET and POST requests, the Servlet model is designed to accommodate any protocol that is predicated around a request/response model. Servlet developers must implement the javax.servlet.Servlet interface, and specifically for HTTP Servlet developers, the javax.servlet.HttpServlet interface. The core service method contains the routing logic that forwards the inbound request to the appropriate handler. A Servlet is hosted by the container, and multiple threads use it in order to provide a scalable system unless the developer explicitly chooses not to do this by implementing the SingleThreadedModel tagging interface. (This interface has been deprecated, as it results in systems that do not scale.) Figure 3-2 illustrates the Servlet lifecycle, as managed by the web container.
)
Figure 3-2 The Servlet lifecycle is quite simple, as opposed to that of other server-side components in the JEE stack. Most developers simply override three methods—init(), doGet()/doPost(), and destroy() to add required behavior.
Filters
Filters are server-side components hosted by the web container that receive an inbound request before it is received by any other component. Filters then are used to pre-process requests—for example, log the event, perform security checks, and so on. Filters are frequently used by web frameworks to make their operation as transparent to the developer as possible, removing or at least ameliorating a significant barrier to their adoption—the complexity (perceived or otherwise) of their development overhead. In addition, filters can be used to perform dedicated processing after a request has been received and processed.
Listeners
Listeners are server-side components hosted by the web container that are notified about specific events that occur during a Servlet's lifecycle. Listeners are used to take actions based on these events. The event model is well-defined, consisting solely of notifications on the web context (Servlet initialization and destruction, attribute adds/edits/deletes) and session activity (creation, invalidation and timeout, and attribute adds/edits/deletes).
JavaServer Pages (JSP)
JavaServer Pages are HTML pages with embedded mark-up that is evaluated at runtime by the web container to create complete HTML pages, which are sent to the client for rendering to the end user. JSP technology has matured significantly in the JEE platform—key elements added since its inception have been the JSTL (Java Standard Tag Library) and the Unified Expression Language (EL), which are covered in separate sections later in the chapter. However, from an architect's perspective, their purpose is simple—they represent the ongoing effort from Sun to enforce a workable MVC model in the JEE, separating presentation logic from business logic. Like all container-managed objects in the JEE, JSPs have a well-defined lifecycle, depicted in Figure 3-3.
)
Figure 3-3 Although JSPs appear more complex than Servlets, and represent a huge improvement on developer productivity and code maintainability, they are actually implemented as Servlets under the hood by the web container.
Java Standard Tag Library (JSTL)
The JSTL is a set of tag libraries that forms part of the JSP specification. Before the advent of the JSTL, open source communities such as Apache, commercial companies, and indeed individual software teams built their own tag libraries. The JSTL brought much needed standardization to the tag library space, allowing developers and architects to effectively delegate control and enhanced presentation logic tags to the specification writers and focus instead on their application logic. The JSTL is an example of open standards adding tangible value to developers as the JSP specification grows out to bring structure to an area badly needing it.
Unified Expression Language (EL)
The EL was introduced in the JSP 2.0 specification, whereas the JSF 1.1 specification introduced its own EL. The word Unified indicates that in JEE 5, these two EL definitions come together in a logical attempt to simplify the overall platform. Simply put, the addition of an EL provides developers with the ability to banish Java scriptlets from JSP pages completely. There are two constructs to represent EL expressions: ${expr} and #{expr}. $ indicates that the expr is evaluated immediately, whereas # indicates to the container that evaluation should be deferred. The container also makes a number of useful implicit objects available to an executing EL snippet—for example, requestScope, sessionScope, and so on. Access to this information further improves the ability of EL to replace custom Java snippets in JSP. Custom Java snippets on their own are not necessarily a bad thing (although the code is often more readable, elegant, and easier to maintain). The single biggest danger when developers need to code Java in JSPs is that they implement not only presentation logic, but business logic as well, violating the core tenet of the MVC design pattern.
Managing Sessions
The Servlet specification provides an elegant way to allow a client-server conversation to manage session state over the HTTP protocol, which is essentially stateless. The web container provides access to a simple map, called the HttpSession, where developers can read from and write to any data that needs to be stored in order to process a client's request. Judicious use of this object is needed, however—storing large objects, such as collections of search results, is a known performance and scalability anti-pattern.
JavaServer Faces (JSF)
JavaServer Faces is a UI framework for web applications based on the JEE platform. Initially controversial (and still so in some quarters), with many developers and architects resenting the imposition of yet another web framework in an already over-crowded space, JSF has grown to represent the foremost method of constructing web UIs as recommended by Sun Microsystems. Nevertheless, many application architects still eschew JSF and use a simpler MVC model, typically leveraging a web framework like vanilla Struts.
Disregarding any good or bad will toward JSF, let's examine its goals. JSF is designed to be easy to use by developers; it is also designed to allow developers to stop thinking in terms of HTTP requests and responses and instead to think about UI development in terms of user- and system-generated events. JSF components are re-usable, improving developer productivity, software quality, and system maintainability; the clear intent of the JSF specification is that the technology be toolable, or provided with deep and mature support from IDEs like Eclipse, Netbeans, and IntelliJ. In this respect, JSF maps closely onto other technologies like ASP.NET from Microsoft and, in turn, is a clear break with directions from frameworks like Ruby on Rails, where the developer is never far away or insulated from the underlying HTTP request/response model.
Templating Frameworks
Especially in the early days of JSP and even today, a segment of the developer and architect population railed against what they saw as the poor ease of development and runtime performance provided by the JSP-centric model. These malcontents fought back against the tide by using the Servlet container to build out a simpler, more efficient way of including dynamic content in HTML fragments, resulting in the creation of template-centric frameworks such as Velocity and FreeMarker. The presence of these frameworks has kept the JSP and JSF communities honest, in showing how simple web development can and should be. However, no matter how relevant or pressing the claims of these frameworks may be, the fact remains that the mandated way to build presentation logic in the JEE platform is either using JSP or JSF.
Web Frameworks
Web frameworks fill the gap between the JSP/Servlet/JSF specification and what an architect needs in order to build a consistent, high-quality web application in the UI platform. The authors are often struck, after reading a three- or four-hundred-page specification, how many open questions there are. In the case of web UIs, a good web framework fills that void, providing the architect and developer with a clear roadmap on exactly how to implement core features such as action handlers, client- and server-side validation, how to handle transactions in a sensible manner, integrate security, manage session state, and build a maintainable and understandable web UI. In fact, mainstream web frameworks have been so successful, a significant percentage of architects have decided not to use EJB in their applications at all—so confident are they that a good web framework is all that is needed to design and construct a good JEE system. And in many, if not most, cases, they are correct. EJBs in the JEE platform provide specific features that are necessary only when business requirements dictate it (these features are detailed in Chapter 4, along with the decision matrix governing when the use of EJBs is appropriate). If you choose not to specify or use a web framework in Part II of the exam, be prepared to clearly justify your decision. We believe that very few, if any, non-trivial Java projects are not using a web framework to impose standard practices on the development team, to produce maintainable code, and to avoid re-inventing the wheel on every new development.