JavaServer Faces (JSF)

JSF is a relatively new technology that attempts to provide a robust, rich user interface for web applications. JSF is used in conjunction with Servlets and JSPs.

When using just JSPs or Servlets to generate the presentation, your user interface is limited to what can be implemented in HTML. HTML does provide a good set of user interface components, such as lists, check boxes, radio buttons, fields, labels, and buttons. Alternatively, the client might be implemented as an applet. Applets can provide a rich user interface, but they do require the client to download and execute code in the browser.

The main drawback with both Servlet-generated HTML and applets is that the user interface components still must be connected to the business logic. When using this solution, much of your time as a developer will be spent retrieving and validating request parameters, and passing those parameters to business logic components.

JSF provides a component-based API for building user interfaces. The components in JSF are user interface components that can be easily put together to create a server-side user interface. The JSF technology also makes it easy to connect the user interface components to application data sources, and to connect client-generated events to event handlers on the server.

The JSF components handle all the complexity of managing the user interface, leaving the developer free to concentrate on business logic. The flexibility comes from the fact the user interface components do not directly generate any specific presentation code. Creating the client presentation code is the job of custom renderers. With the correct renderer, the same user interface components could be used to generate presentation code for any arbitrary device. Thus, if the client’s device changed, you would simply configure your system to use a renderer for the new client, without needing to change any of the JSF code. At the moment, the most common presentation format is HTML, and JSF comes with a custom renderer to create HTML user interfaces.

JavaServer Pages (JSPs)

JSPs, like Servlets, are concerned with dynamically generated web content. These two web components—Servlets and JSPs—comprise a huge percentage of the content of real-world Java EE applications.

Building Servlets involves building Java components that emit HTML. In a lot of cases, that works out well. However, that approach isn’t very accessible for people who spend their time on the visual side of building web applications and don’t necessarily care to know much about software development. Enter JSP. JSP pages are HTML-based text documents with chunks of Java code called scriptlets embedded into the HTML document.

When JSPs are deployed, something remarkable happens: The contents of the JSP are rolled inside out, like a sock, and a Servlet is created based on the embedded tags and Java code scriptlets, as shown in next Figure. This happens pretty much invisibly. If you care to, you can dig under the covers and see how it works (which makes learning about Servlets all the more worthwhile).

You may have had some exposure to JavaScript, which is a Java-like scripting language that can be included within a web page, and is executed by the web browser when a page containing JavaScript code is sent to the browser. JSP is a little like that, but the code is compiled and executed at the server, and the resulting HTML is fed back to the requesting client. JSP pages are lightweight and fast (after the initial compilation to the Servlet), and they provide a lot of scalability for web-based applications.

Developers can create both static and dynamic content in a JSP page. Because content based on HTML, XML, and so on forms the basis of a JSP page, a nontechnical person can create and update that portion of a page. A more technical Java developer can create the snippets of Java code that will interface with data sources, perform calculations, and so on—the dynamic stuff.


ince an executing JSP is a Servlet, JSP provides the same support for session management as Servlets. JSPs can also load and call methods of JavaBean components, access server-based data sources, or perform complex calculations at the server.

Java Servlets

You are no doubt familiar with accessing simple, static HTML pages using a browser that sends a request to a web server, which, in turn, sends back a web page that’s stored at the server, as illustrated in next Figure. In that role, the web server is simply being used as a virtual librarian that returns a document based on a request.

That model of serving up static web pages doesn’t provide for dynamically generated content, though. For example, suppose that the web client wants the server to return a list of HTML documents based on some query criteria. In that case, some means of generating HTML on the fly and returning it to the client is needed, as illustrated in next Figure.

Servlets are one of the technologies developed to enhance servers. A Servlet is a Java component implementing the javax.servlet.Servlet interface. It is invoked as a result of a client request for that particular Servlet. The Servlet model is fairly generic and not necessarily bound to the Web and HTTP, but all of the Servlets that you’ll encounter will fall into that category. The web server receives a request for a given Servlet in the form of an HTTP query. The web server, in turn, invokes the Servlet and passes back the results to the requesting client. The Servlet can be passed parameters from the requesting web client. The Servlet is free to perform whatever computations it cares to, and returns results to the client in the form of HTML.

The Servlet itself is managed and invoked by the Java EE Servlet container. When the web server receives the request for the Servlet, it notifies the Servlet container, which will load the Servlet as necessary, and invoke the appropriate javax.servlet.Servlet interface service method to satisfy the request.

Java Servlets are portable, and as you will see in later chapters, the Servlet containers provide support for session management that allows you to write complex web-based applications. Servlets can also incorporate JavaBean components (which share little more than a name with Enterprise JavaBeans) that provide an additional degree of application compartmentalization.

JDBC

If you’ve done anything at all on the Web other than simple surfing, you’ve probably used a database. Of course, that database has been hidden behind a fancy user interface, but you’ve used one nonetheless.

Have you searched for books or other products at www.amazon.com or www.costco.com or any other online store? The information about the products for sale is kept in some kind of database.

Have you searched for web sites on www.google.com or www.yahoo.com or any other search engine? Information about web pages and the data in them is kept is some kind of database.

Have you looked for information about public laws (thomas.loc.gov), driving directions (www.mapquest.com), or satellite imagery (www.terraserver.com)? This information is kept in some kind of database.

Most Java EE applications will include some kind of data-storage solution. Most often, that data-storage solution will be a relational database server of some kind. The database server may be an integral part of the application server, or it may be an application separate from the application server.

The examples can go on and on. The point should be clear though: Almost any type of nontrivial application will use a database of some kind. In the previous sentence, the term database is used in its loosest most general meaning as a collection of some data. That database could be anything from a text file of information for very simple applications to full-blown, enterprise-level relational or object databases for very complex systems. It could also include other data-storage systems, such as directories.

In any case, your application components need some means to communicate with the data-storage system. That is the job of JDBC. JDBC is a set of common APIs and system-specific libraries for communicating with a data-storage system. By communicating with the data-storage system through the common APIs, you can concentrate on the data, without needing to learn custom syntax for the particular data-storage system; that job is left to the system-specific library.

Most JDBC applications are used to communicate with a relational database. In a relational database, data is stored, conceptually, in tables. Each row in a table represents a set of data—a customer record, product information, a web site listing, and so on. And each column in the table represents a piece of data in that set. Tables can be linked by creating a relation between tables, thus it’s called a relational database. For example, a database might have a table of customer information and a table of information about orders. It makes no sense to repeat customer information for each order, so the orders table would include a customer ID that corresponds to a similar piece of data in the customers table, thus relating every order to a customer.

While JDBC is used most often with relational databases, it can be used with any data-storage system, as long as someone has created a system-specific library for that data-storage system.