Download
1 / 32
320 likes | 440 Views
J2EE Web Fundamentals Lesson 2 High-Level Overview. Instructor: Dr. Segun Adekile. Outline. Objectives Course Text Book Basham, Bryan; Sierra, Kathy; Bates, Bert (2012-10-30). Head First Servlets and JSP (Kindle Location 1349). O'Reilly Media. Kindle Edition. High-Level Overview
E N D
J2EE Web FundamentalsLesson 2High-Level Overview Instructor: Dr. Segun Adekile
Outline • Objectives • Course Text Book • Basham, Bryan; Sierra, Kathy; Bates, Bert (2012-10-30). Head First Servlets and JSP (Kindle Location 1349). O'Reilly Media. Kindle Edition. • High-Level Overview • Web App Architecture
Introduction and Overview • What is a Container? • What does the Container give you? • How the Container handles a request • Using the Deployment Descriptor to map URLs to servlets • The Model-View-Controller (MVC) Design Pattern • A “working” Deployment Descriptor (DD) • How J2EE fits into all this
Introduction and Overview • Servlets need help. • When a request comes in, somebody has to instantiate the servlet or at least make a new thread to handle the request. Somebody has to call the servlet’s doPost() or doGet() method. And, oh yes, those methods have crucial arguments — the HTTP request and HTTP response objects. Somebody has to get the request and the response to the servlet. Somebody has to manage the life, death, and resources of the servlet. That somebody is the web Container. • In this chapter, we’ll look at how your web application runs in the Container, and we’ll take a first look at the structure of a web app using the Model View Controller (MVC) design pattern.
What is a Container? • A Java Application that manages and runs the servlet. • Servlets don’t have a ‘main’ method. They are under the control of the container. • Examples: Tomcat, WAS
What does the Container give you? • Communications Support • The Container provides an easy way for your servlets to talk to your web server. You don’t have to build a ServerSocket, listen on a port, create streams, etc. • Lifecycle Management • The Container controls the life and death of your servlets. It takes care of loading the class, instantiating and initializing the servlets, invoking the servlet methods, and making servlet instances eligible for garbage collection. • Multithreading Support • The Container automatically creates a new Java thread for every servlet request it receives. • Declarative Security • With a Container, you get to use an XML deployment descriptor to configure (and modify) security without having to hard-code it into your servlet (or any other) class code. • JSP Support • The container also translates JSPs into Servlets.
How the Container handles a request • You’re wondering how the Container found the Servlet... • Somehow, the URL that comes in as part of the request from the client is mapped to a specific servlet on the server. • This mapping of URLs to servlets might be handled in a number of different ways, and it’s one of the most fundamental issues you’ll face as a web app developer. • The user request must map to a particular servlet, and it’s up to you to understand and (usually) configure that mapping.
How the Container handles a request • A servlet can have THREE names • File path name:A servlet has a file path name, obviously, like classes/ registration/ SignUpServlet.class (a path to an actual class file). The original developer of the servlet class chose the class name (and the package name that defines part of the directory structure), and the location on the server defines the full path name.
How the Container handles a request • A servlet can have THREE names • Deployment name: doesn’t have to be the same as the class or file name but can be. E.g the servlet class name (registration.SignUpServlet) or the relative path to the class file (classes/ registration/ SignUpServlet.class), but it can also be something completely different (like EnrollServlet).
How the Container handles a request • A servlet can have THREE names • Public URL name: the name the client knows about. In other words, the name coded into the HTML so that when the user clicks a link that’s supposed to go to that servlet, this public URL name is sent to the server in the HTTP request.
Using the Deployment Descriptor to map URLs to servlets • When you deploy your servlet into your web Container, you’ll create a fairly simple XML document called the Deployment Descriptor (DD) to tell the Container how to run your servlets and JSPs. • Although you’ll use the DD for more than just mapping names, you’ll use two XML elements to map URLs to servlets — one to map the client-known public URL name to your own internal name, and the other to map your own internal name to a fully-qualified class name.
The Model-View-Controller (MVC) Design Pattern • He considered having just a single servlet, with a bunch of if tests, but decided that separate servlets would be more OO — each servlet should have one responsibility like the query page, the sign-up page, the search results page, etc. Each servlet will have all the business logic it needs to modify or read the database, and prints the HTML to the response stream back to the client.
The Model-View-Controller (MVC) Design Pattern • With MVC the business logic is not only separate from the presentation... it doesn’t even know that there IS a presentation. • The essence of MVC is that you separate the business logic from the presentation, but put something between them so that the business logic can stand on its own as a reusable Java class, and doesn’t have to know anything about the view. • Bob was partly there, by separating out the business logic from the presentation, but his business logic still has an intimate connection to the view. In other words, he mixed the business logic into a servlet, and that means he can’t reuse his business logic for some other kind of view (like a Swing GUI or even a wireless app). His business logic is stuck in a servlet when it should
How J2EE fits into all this • The Java 2 Enterprise Edition is kind of a super-spec • J2EE incorporates other specifications, including the Servlets 2.4 spec and the JSP 2.0 spec. That’s for the web Container. • But the J2EE 1.5 spec also includes the Enterprise JavaBean 2.1 specification, for the EJB Container. In other words, the web Container is for web components (Servlets and JSPs), and the EJB Container is for business components. • A fully-compliant J2EE application server must have both a web Container and an EJB Container (plus other things including a JNDI and JMS implementation). • Tomcat is just a web Container! It is still compliant with the portions of the J2EE spec that address the web Container. Tomcat is a web Container, not a full J2EE application server, because Tomcat does not have an EJB Container. • A J2EE application server includes both a web Container AND an EJB Container. Tomcat is a web Container, but NOT a full J2EE application server. A J2EE 1.5 server includes the Servlet spec 2.4, JSP spec 2.0, and EJB spec 2.1.
