Differences

This shows you the differences between two versions of the page.

--- servlets [2007/10/08 16:42] – created roumani
+++ servlets [2008/10/08 19:36] (current) – roumani
@@ Line 1: / Line 1: @@
 ====== Servlets ======
+This lecture covers the JEE's approach to server-side processing. It introduces the overall Tomcat architecture and focuses on the servlet container. The hands-on lab session will walk you through the installation of Tomcat and introduces you to the capabilities of its three engines, Coyote, Catalina, and Jasper.
+===== Outline =====
+== Tomcat as a Framework ==
+  * Infrastructural services (networking, logging, data access, etc.)
+  * Persistence and session management
+  * Events (context and session listeners)
+  * Filters
+  * Declarative security
+== Architecture ==
+  * Tomcat = Coyote + Catalina + Jasper. It is a reference implementation of Sun's Servlet/JSP standards.
+  * All three are 100% Java and live off the same VM. They are one process in the eyes of the O/S.
+  * Coyote is a web server / connector, Catalina is a servlet container (aka engine), and Jasper is a JSP processor.
+  * Client uses HTTP to reach Coyote over TCP/IP; Coyote consults its URL mappings to determine how to serve: traditionally (NFS for static, CGI, or PHP/SSI) or via delegating to Catalina.
+  * Catalina works on the request guided by your servlet.
+  * Jasper turns JSP documents into servlets. Think of it as a JSP compiler.
+  * Coyote can also operate as a connector to an existing web server, such as Apache or IIS. In that case, the web server would handle traditional serving and, for servlet requests, would use the JK protocol (similar to HTTP but binary) to delegate to Catalina in process.
+== The MVC Design Pattern ==
+  * Separation of concerns
+  * Controller = servlet
+  * Model = POJO
+  * View = JSP
+== The Life Cycle ==
+  * Server makes one instance of your servlet
+  * It invokes the ''init'' method on it. You may need to instantiate POJO's/beans or initialize in ''init''.
+  * It creates a pool of threads ready to invoke your servlet's ''service'' method.
+  * When a client connects, a thread is (randomly) chosen and assigned to serve this request.
+  * There is no client-to-thread mapping: the same client may get served by the same or a different thread.
+  * When it is time to stop this servlet, the server invokes its ''destroy'' method then unloads it.
+== The Directory Structure ==
+  * The subdirectories bin and conf
+  * The lib subdirectory
+  * The subdirectories logs and work
+  * The projects root: webapps
+  * The role of WEB-INF vis-a-vis visibility
+  * The subdirectories of WEB-INF: classes and lib
+  * The web.xml file
+  * Deploying war files
+  * The manager application
+== The API ==
+  * No need to override ''service'' since it filters based on the request method. Override either ''doGet'' or ''doPost'' (or both)
+  * The request object enables you to retrieve socket data, HTTP data, the headers, the parameters, and the payload (for POST).
+  * Note that parameters are available as Map<String,String[]> and that for payloads you can have a raw stream or a wrapped up one.
+  * The response object allows you to set the HTTP response line and headers as well as the payload.
+===== To Do =====
+  * Read Sections 6.1 through 6.5 of our textbook.
+  * Take an overall look at the servlet API (accessible from our //Resources// Page.
+  * Complete and then review Lab-3