Introduction
Chapter 24 presented Java's fundamental networking capabilities from package java.net, which offers both socket-and packet-based communication. Higher-level views of networking are provided by classes and interfaces in the java.rmi packages (five packages) for Remote Method Invocation (RMI) and the org.omg packages (seven packages) for Common Object Request Broker Architecture (CORBA). The RMI packages allow Java objects running on separate JVMs (normally on separate computers) to communicate via remote method calls. Such calls appear to invoke methods on an object in the same program, but actually have built-in networking (based on the capabilities of package java.net) that communicates the method calls to another object on a separate computer. The CORBA packages provide functionality similar to that of the RMI packages. A key difference between RMI and CORBA is that RMI can only be used between Java objects, whereas CORBA can be used between any two applications that understand CORBAincluding applications written in other programming languages. [ Note: Remote Method Invocation over the Internet Inter-Orb Protocol (RMI-IIOP) enables the integration of Java with non-Java distributed objects by using CORBA IIOP.] In Chapter 13 of our book Advanced Java 2 Platform How to Program, we present Java's RMI capabilities. Chapters 2627 of Advanced Java 2 Platform How to Program discuss the basic CORBA concepts and present a case study that implements a distributed system in CORBA.
Client-Server Relationship
Our discussion in this chapter continues the focus in Chapter 24the client-server relationship. The client requests that some action be performed and the server performs the action and responds to the client. This request-response model of communication is the foundation for the highest-level views of networking in Javaservlets and JavaServer Pages (JSP). A servlet extends the functionality of a server, such as a Web server that serves Web pages to a user's browser using the HTTP protocol. Packages javax.servlet and javax.servlet.http provide the classes and interfaces to define servlets. Packages javax.servlet.jsp and javax.servlet.jsp.tagext provide the classes and interfaces that extend the servlet capabilities for JavaServer Pages. Using special syntax, JSP allows Web-page implementors to create pages that encapsulate Java functionality and even to write scriptlets of actual Java code directly in the page.
A common implementation of the request-response model is between Web browsers and Web servers. When a user selects a Web site to browse through the browser (the client application), a request is sent to the appropriate Web server (the server application). The server normally responds to the client by sending the appropriate XHTML Web page. [Note: If you are not familiar with XHTML and CSS, refer to the PDF documents Introduction to XHTML: Part 1, Introduction to XHTML: Part 2 and Cascading Style Sheets (CSS) on the CD that accompanies this book. For the purposes of this chapter and Chapter 27, JavaServer Pages (JSP), we assume you already know XHTML.] Servlets are effective for developing Web-based solutions that help provide secure access to a Web site, interact with databases on behalf of a client, dynamically generate custom XHTML documents to be displayed by browsers and maintain unique session information for each client.
This chapter continues our networking discussions by discussing servlets that enhance the functionality of Web serversthe most common form of servlet. Chapter 27, JavaServer Pages (JSP), discusses JSPs, which are translated into servlets. JSPs are a convenient and powerful way to implement the request-response mechanism of the Web without getting into the lower-level details of servlets. Together, servlets and JSPs form the Web components of the Java 2 Enterprise Edition (J2EE) that run on a J2EE server.
Thin Clients
Many developers feel that servlets are the right solution for database-intensive applications that communicate with so-called thin clientsapplications that provide presentation but do not process data, thus requiring fewer computing resources. The server is responsible for database access. Clients connect to the server using standard protocols available on most client platforms. Thus, the presentation-logic code for generating dynamic content can be written once and reside on the server for access by clients, to allow programmers to create efficient thin clients.
In this chapter, our servlet examples demonstrate the Web's request-response mechanism (primarily with get and post requests), redirecting requests to other resources and interacting with databases through JDBC. We placed this chapter after our discussion of JDBC and databases intentionally, so that we can build multitier, client-server applications that access databases.
Apache Jakarta Project and the Tomcat Server
Sun Microsystems, through the Java Community Process, is responsible for the development of the servlet and JavaServer Pages specifications. The reference implementation of both these standards is developed by the Apache Software Foundation (www.apache.org) as part of the Jakarta Project (jakarta.apache.org). As stated on the Jakarta Project's home page, "The goal of the Jakarta Project is to provide commercial-quality server solutions based on the Java Platform that are developed in an open and cooperative fashion." There are many subprojects under the Jakarta project to help commercial server-side developers. The servlet and JSP part of the Jakarta Project is called Tomcat. This is the official reference implementation of the JSP and servlet standards. We use Tomcat to demonstrate the servlets in this chapter. The most recent implementation of Tomcat at the time of this writing was version 5.0.25. For your convenience, Tomcat 5.0.25 is included on the CD that accompanies this book. However, the most recent version always can be downloaded from the Apache Group's Web site. To execute the servlets in this chapter, you must install Tomcat or an equivalent servlet and JavaServer Pages implementation. We discuss the setup and configuration of Tomcat in Section 26.3 and Section 26.4.1, after we introduce our first example.
In our directions for testing each of the examples in this chapter, we indicate that you should copy files into specific Tomcat directories. All the example files for this chapter are located on the CD that accompanies this book and on our Web site, www.deitel.com. At the end of Section 26.11, we provide a list of Internet specifications (as discussed in the Servlet 2.4 Specification) for technologies related to servlet development. Each is listed with its RFC (Request for Comments) number. An RFC is a document that describes standard protocols, mechanisms and procedures for Internet development. We provide the URL of a Web site that allows you to locate each specification for your review.