NonStop Servlets for JavaServer Pages (NSJSP) 5.0 System Administrator's Guide

Overview and Architecture
NonStop Servlets for JavaServer Pages (NSJSP) System Administrator’s Guide—525644-003
1-2
Java 2 Enterprise Edition (J2EE) Overview
To use this documentation, you should have some familiarity with the Java language
and tools and the Java Servlet Application Programming Interface (API) defined by
JSR 154: Java 2.4 Specifications. This section does not attempt to teach you how to
program servlets or JSPs, although it does offer advice and ideas.
You also should be familiar with the overall iTP Secure WebServer environment, which
must be installed and running before you can install and use NSJSP.
Java 2 Enterprise Edition (J2EE) Overview
This subsection summarizes these topics:
•
The Web Container on page 1-3
•
JavaServer Pages (JSP) on page 1-4
•
The Web Application on page 1-5
•
The WEB-INF Subdirectory on page 1-5
•
The Deployment Descriptor on page 1-6
•
Web Archive (WAR) Files on page 1-6
J2EE defines the standard for developing and running applications in a multi-tier
architecture.
The iTP WebServer implementation of servlets and JSP is a key component for J2EE
compliance. For an overview of all the other components of a complete J2EE
environment, see the Sun Microsystems J2EE website.
The J2EE architecture has two types of client: web clients and application clients.
Application clients belong to the client-server model where the “fat” client provides not
only the GUI, but also most of the application logic. Web clients, belong to a newer
three-tier model where the “thin” client (typically a browser) supplies the GUI, and a
middleware layer, on a Webserver, provides the application logic between the GUI and
the database. The middleware layer itself is now typically based on reusable
components designed in a Model-View-Controller architecture. For an introduction to
this concept, see Model-View-Controller Designs on page 1-7.
The web client model typically uses HTTP to provide a request-response relationship
between the browser and the application logic. The client Resource Locator (URL) —
for example www.company.com/index.html — consists of the domain name —
www.company.com — and the Universal Resource Identifier (URI), the name of the
resource, in this case index.html. The URI provides the context path that is used to
locate servlets (see Map Requests to Applications and Servlets on page 3-19).
Initially, HTTP resources were static pages of text or graphics, the same resource
being served to each client request, but now the emphasis is on building and using
dynamic resources where the same resource can be dynamically modified for each
different client request. For example, consider a mailbox, where the structure and
function is the same, but the content is clearly different for each user.