Multi-Tiered Architecture

 Any application (software) can have Application

three major components.
Interface
 Interface
 Logic
Logic
 Storage (Permanent)

 Functionality of an application can be Data Store

separated into isolated functional

areas, called tiers.
 Multi-Tiered Architecture

 Single Tier:
 Multi-Tiered Architecture

 Two Tier Architecture:

 Multi-Tiered Architecture

 Three Tier Architecture:

 Enterprise Applications

 Large-scale, multi-tiered, scalable, reliable, and secure

network applications are called “Enterprise Applications”.

 These applications are designed to solve the problems

encountered by large enterprises.
 Expectations from Enterprise Applications

 Be available 24 x 7 without downtime.

 Have an acceptable response time even in the face of
increasing usage.
 Have the flexibility to be modified quickly without requiring
a redesign of the application.
 Be vendor (seller/Merchant) independent.
 Be able to interact with existing system.
 Utilize existing system components (objects).
Challenges of Enterprise Application Development:

1. Programming Productivity

2. Integration with Existing Systems

3. Freedom of Choice

4. Response to Demand

5. Maintaining Security
 JEE (Java Enterprise Edition) Concepts

JEE is a technology that aims to simplify the design and

implementation of enterprise applications.

Definition:

1.JEE is a suite of specifications for application programming

interfaces, a distributed computing architecture, and definitions

for packaging of distributable components for deployment.

Definition:

2.It’s a collection of standardized components, containers, and

services for creating and deploying distributed applications within

a well-defined distributed computing architecture.

Definition:

3. JEE provides a collection of standardized

components that facilitate software deployment, standard

interfaces that define how the various software modules

interconnect, and standard services that define how the different

software modules communicate.

Distributed Multi-tiered Architecture:
JEE Application1 JEE Application2

Client
Dynamic HTML Page Client Tier
Application Client Machine

JSP
Web Tier
Pages

Enterprise J2EE Server

Beans Machine
Enterprise
Beans Business Tier

Database
EIS Tier Server
Database Database
Machine

Three-Tier Architecture Four-Tier Architecture

Distributed Multi-tiered Architecture:

 Client-tier components run on the client machine.

 Web-tier components run on the J2EE server.

 Business-tier components run on the J2EE server.

 Enterprise information system (EIS)-tier software runs on

the EIS server.

The Client Tier:
 The client tier consists of application clients that
access a Java EE server and that are usually located
on a different machine from the server.

 Different types of applications can be Java EE

clients, and they are not always, or even often Java
applications.

 Clients can be a web browser, a stand-alone

application, or other servers.
The Web Tier:
 The web tier consists of components that handle
the interaction between clients and the business tier.
Its primary tasks are the following:

• Dynamic Content generation.

• Collecting input and returning appropriate
result.
• Control the flow of screens or pages on the client.
• Maintain the state of data for a user’s session.
• Perform some basic logic and hold some data
temporarily in JavaBeans components.
The Business Tier:

 The business tier consists of components that provide

the business logic for an application.

 Business logic is code that provides functionality to a

particular business domain, like the financial industry, or an e-
commerce site.

 In a properly designed enterprise application, the core

functionality exists in the business tier components.
The Enterprise Information Systems Tier:

 The enterprise information system tier handles EIS

software and includes enterprise infrastructure systems such as
enterprise resource planning (ERP), Mainframe transaction
processing, database systems, and other legacy information
systems.

 These resources typically are located on a separate

machine than the Java EE server, and are accessed by components
on the business tier.
Containers, Components and Services:

 Containers are the interface between a component and the low-

level platform specific functionality that supports the component.
OR
 Container is a software entity that provides services to
components, including life cycle management, security, deployment,
and runtime services.

 A container of a specific type of components, such as EJB, Web,

JSP, servlet, applet, or application client, will provide the services its
components need.
 Before a web component, enterprise bean, or application client
component can be executed, it must be assembled into a J2EE
module and deployed into its container.

Types of Containers:
1. Web Container
2. Application Client Container
3. EJB Container
J2EE Components:

 J2EE applications are made up of components. Essentially they

are building blocks of a J2EE application.

 J2EE Components are specific software units, supported by a

container, and configurable at deployment-time.
OR
 A J2EE component is a self-contained functional software unit that
is assembled into a J2EE application with its related classes and
files and that communicates with other components.
 The J2EE specification defines the following J2EE components:

 Application clients and applets are client components that run

on the client.

 Java Servlet and JavaServer Pages (JSP) technology components

are web components that run on the server.

 Enterprise JavaBeans™ (EJB™) components (enterprise beans)

are business components that run on the server.
 J2EE components are written in the Java programming language
and are compiled in the same way as any program in the language.

 The difference between J2EE components and “standard” Java

classes:
 J2EE components are assembled into a J2EE application.

 They are verified to be well formed and in compliance with

the J2EE specification.

 They are deployed to production, where they are run and
managed by the J2EE server.
JEE Containers and Components
Enterprise Beans

 The Enterprise JavaBeans (EJB) tier hosts application-specific

business logic and provides system-level services such as transaction
management, concurrency control, and security.

 An enterprise bean is a server-side component that encapsulates the

business logic of an application.

 An Enterprise JavaBean (EJB) is a component of the JEE

architecture that primarily provides business logic to a JEE
application and interacts with other server-side JEE components.
Business Logic:

 Business Logic is the set of all procedures or methods to manage a

specific business function.

 Business functions can be decomposed into set of components /

elements called business objects.

Common Requirements of Business Objects
 Maintain State
 Conversational State - State maintained in an object during
the conversation between client and the
application.
 Persistent State - State that is stored in the database.

 Operate on shared data

 Participate in transaction

 Service a large number of clients

 Remain available to clients

 Provide remote access to data

 Control access

 Reusable
Guidelines for using Entity Beans

 Representing persistent data

 Representing objects with clearly-defined identity

 Providing concurrent access by multiple clients

 Providing robust, long-lived persistent data management

 Persisting data in a portable manner

 Providing access through queries

 Simplifying transaction handling

Entity Beans:
 Entity Bean is used to manage a collection of data retrieved from a database

and stored in memory.

 An Entity Bean inserts, updates and removes data while maintaining the

integrity of data.
 Data collected and managed by entity bean is referred to as persistent data.

 Persistent data are managed in two ways.

 Bean Managed Persistence (BMP)

 Container Managed Persistence (CMP)

Session Bean:
 Session beans are used to implement business objects that hold

client-specific business logic.

 The state of such a business object reflects its interaction with a

particular client and is not intended for general access.

 A session bean typically executes on behalf of a single client and

cannot be shared among multiple clients.

 A session bean is a logical extension of the client program that runs

on the server and contains information specific to the client.

 The state of a session object is non-persistent and need not be

written to the database.

Stateful Session Beans
 A stateful session bean contains conversational state on behalf of its

client.

 The conversational state is defined as the session bean’s field values

plus all objects reachable from the session bean’s fields.

 Stateful session beans do not directly represent data in a persistent

data store, but they can access and update data on behalf of the
client.

 The lifetime of a stateful session bean is typically that of its client.

Uses of Stateful Session Beans

 Maintaining client-specific state

 Representing non-persistent objects

Stateless Session Beans:

 Stateless means that the session bean does not maintain any state information

for a specific client.

Uses of Stateless Session Beans

 Modelling reusable service objects

 Providing high performance

 Providing procedural view of data

Message-Driven Beans
 A message-driven bean allows J2EE applications to receive JMS messages

asynchronously.

 Asynchronous messaging: Exchanging messages in such a way that senders

are independent of receivers.

 The sender sends its message and does not need to wait for the receiver to

receive or process the message.

 Message-driven beans contain business logic for handling received messages.

 Message-driven bean’s business logic may include such operations as:

 Doing some computation

 Initiating a step in a workflow

 Storing data

 Sending another message

 Message-driven beans function as message listeners, consuming messages

from a JMS destination (queue or a topic).

Switching Networks:

1
6

E1
B
5
2
E2

3
4

C
D
Circuit Switching:
o Originally designed for voice traffic.

o Key characteristic is that resources with in the network are dedicated to a

particular communication request.

o There will be a dedicated communication path between the

communicating devices.

o Communication path is basically a connected sequence of links between

network nodes.

o Communication in Circuit Switching involves three phases.

o Circuit Establishment
o Data Transfer
o Circuit Disconnect
 Propagation Delay
Circuit Switching:
Communication
Request Signal

Processing Delay

Time
Call Accept Signal

User Data

Acknowledgement
Signal

Link Link Link

Nodes 1 2 3 4
Packet Switching:
o Data set is broken up into a series of packets and are transmitted.
User Data

CI - Control Info.

CI Packet 1 CI Packet 2 CI Packet 3

o Each packet contains data plus control information.

o At each network node, packets are received, stored briefly and passed
onto the next node.
Packet Switching:

PKT1

PKT2

PKT3 PKT1

Time
PKT2

PKT3 PKT1

PKT2

PKT3

Link Link Link

Nodes 1 2 3 4
Circuit and Packet Switching – A Comparison:

Description Circuit Switching Packet Switching

Dedicated path Yes No

Bandwidth Available Fixed Dynamic

Potentially wasted bandwidth Yes No

Store-and-forward Transmission No Yes

Each data unit follows the same

route Yes No

Call setup Required Not Needed

Possibility of Congestion
(overcrowding/jamming/blocking) At setup time On every packet

Charging Per Minute Per packet

Client Server Architecture:
Port Socket Port

HTTP Request
Client Server
HTTP Response

Internet Listener

o Client – Requests for a particular service.

o Server – Responds to the client’s request by fulfilling it.

o Requests are sent to particular ports to reach the correct server process.
(Ex: HTTP requests - Port 80, SMTP request – Port 25).
o At the server, respective socket will be activated for the communication.
Sockets:

o End point of a bidirectional inter process communication flow across a

internet protocol based computer networks.
o It is created by the operating system for the process and bound to a socket
address.
o Socket address is the combination of IP address and the port address.

o Classification:
o Datagram Sockets – Connectionless
o Stream Sockets – Connection Oriented
o Raw Sockets (Raw IP Sockets) – Available in routers and

other network equipments.

Ports:

o A port is an application-specific or process-specific software.

o It is a communications endpoint used by Transport Layer protocols of the
Internet Protocol Suite.
HTTP Protocol

o Hypertext Transfer Protocol (HTTP) is a generic, stateless

application level protocol for distributed, collaborative, hypermedia
information systems.

o It uses client server model.

o Tim Berners-Lee implemented it in 1990-91 at CERN.

o HTTP is
o Connectionless
o Media (content type) Independent
o Stateless
Characteristics of HTTP Protocol:

o Application Level: Application level protocol. It does not provide

reliability and retransmission itself.

o Request/Response: Once transport session has been established,

one side must send an http request to which
the other side responds.

o Stateless: Each http request is self-contained, the server

does not keep a history of previous
requests or previous sessions.

o Bidirectional Transfer:
A browser requests a web page, and the server
transfers a copy to the browser.
Characteristics of HTTP Protocol:

o Capability negotiation: Allows browsers and servers to negotiate

details such as the character set to be
used during transfer.

o Support for Caching: To improve response time, a browser

caches a copy of each web page it
retrieves.

o Support for Intermediaries: Allows a machine along the path between a

browser and the server to act as a
proxy server that caches web
pages and answers a browser’s
request from its cache.
Structure of HTTP Transactions

o The format of the request and response messages are similar, and
English-oriented. Both kinds of messages consist of:
o An initial line
o Zero or more header lines
o A blank line and
o An optional message body.

o <initial line, different for request and response>

Header1: value1

Header2: value2

Header3: value3

<optional message body>

Structure of HTTP Transactions

o Initial Line is different for request and response.

o Request initial line has three parts

o An http method
o The local path of the requested resource
o The version of the http being used

o Example request line

GET /path/to/file/index.html HTTP/1.0

Structure of HTTP Transactions

o Response initial line called as status line also has three parts

o Version of the http being used

o A response status code which gives the result of the response
o An English reason phrase describing the status code

o The status code is meant to be computer-readable; the reason phrase is

meant to be human-readable.

o Example response line

HTTP/1.0 200 OK
or
HTTP/1.0 404 Not Found
Structure of HTTP Transactions HTTP Status Code

o The status code is a three-digit integer, and the first digit identifies the
general category of response:

o 1xx indicates an informational message only

o 2xx indicates success of some kind
o 3xx redirects the client to another URL
o 4xx indicates an error on the client’s part
o 5xx indicates an error on the server’s part

o Example response line

HTTP/1.0 200 OK

or

HTTP/1.0 404 Not Found

Structure of HTTP Transactions

o The header line provides information about the request and response.

o If the http message includes the body, then the header part describes the
body.
o Content-Type: type of data in the message body

o Content-Length: number of bytes in the message body

http Methods:

o GET
o POST
o HEAD
Structure of HTTP Transactions
Client request
GET /index.html HTTP/1.1
Host: www.example.com
HTTP Headers
Server response
HTTP/1.1 200 OK
Date: Mon, 23 May 2005 22:38:34 GMT
Server: Apache/1.3.3.7 (Unix) (Red-Hat/Linux)
Last-Modified: Wed, 08 Jan 2003 23:11:55 GMT
Etag: "3f80f-1b6-3e1cb03b"
Accept-Ranges: bytes
Content-Length: 438
Connection: close
Content-Type: text/html; charset=UTF-8
Structure of HTTP Transactions
Server response
HTTP/1.1 200 OK
Date: Mon, 23 May 2005 22:38:34 GMT
Server: Apache/1.3.3.7 (Unix) (Red-Hat/Linux)
Last-Modified: Wed, 08 Jan 2003 23:11:55 GMT
Etag: "3f80f-1b6-3e1cb03b"
Accept-Ranges: bytes
Content-Length: 438
Connection: close
Content-Type: text/html; charset=UTF-8

<html>
<body>
<h1>Software Engineering</h1> (more file contents) . . .
</body>
</html>
Web Server Model:

Internet or
Internal Network
1. Enters URL 2. Sends request to web server
Web Web Server
Browser
4. Responds with HTML Page
5. Displays HTML

3. Web Server fetches stored

HTML page
 Dynamic HTML generation through CGI (Common Gateway Interface):

Internet or
Internal
Network
1. Enters URL 2. Sends request to web server
Web Web Server
Browser
5. Responds with HTML Page
6. Displays HTML

4. Takes output 3. Runs Program

as response

CGI Program /
Other Server side
scripts

To or from other systems,

database etc.,
Drawbacks of CGI (Common Gateway Interface) Programming:

1. The overhead of starting an operating system process for each incoming

request.

2. The overhead of loading and running a program for each incoming request.

3. The need for tedious and repetitive coding to handle the network protocol
and request decoding.

4. Lack of portability

5. No intrinsic support for session management.

JavaServer Pages:

JavaServer Pages (JSP) technology is the Java platform

technology for delivering dynamic content to web clients in a

portable, secure and well-defined way.

JavaServer Pages Development: Stages

 Creation:

 Deployment:

 Translation and compilation:

 HTML and Java code into Java Code Source File.

 Java Code Source File into JSP page implementation class.

JavaServer Pages Development:
 JSP
JSP Execution: Java

HTML
First request since JSP is compiled
Java
application was into a Servlet
started HTML

Server
Server Servlet
All Subsequent requests Servlet

Ask Server for

Java Server Page

Web Browser

Information returned Servlet

to client as HTML generates HTML
HTML
HTML
JSP Lifecycle:
 Loading and Instantiation
 Initialization
 Request Processing
 End of Life

Compiled
 J2EE Server / Standalone JSP Server
JSP Container (JSP Engine)
JSP Lifecycle:
JSP NO Translate
Java
Servlet JSP
Code
Exists? Source
YES File

JSP Generate JSP

YES
Request Servlet Servlet Source
Loaded?
Client
NO
Response
Compile JSP
Load Servlet
Servlet

Generate
Response

JSP Page Implementation

Class
 JSP Elements:

 Directive Elements:

Are used to give special instruction to the JSP container about what to do
during the translation of the page.

 Template Data:

Is the static text. This is passed directly through the JSP container
unprocessed.

 Action Elements:

Are JSP elements that are involved in the processing of the request.

 Scripting Elements:

The practice of embedding code in another programming language within a

JSP page is called scripting. Scripting Elements are embedded code,
typically in the Java programming language, within a JSP page.
Directive Elements: Page Directive

Attribute Description

Lists the Java packages to be imported into the

page. Multiple packages can be imported by
separating each by comma. User defined packages
import
can also be imported.

Ex: . . , usrpkg.*”
import = “java util *

If a page participates in a session and wants to

access any session information, then this attribute
session
should be set to true. Possible values are true and
false. Default is true.
Directive Elements: Page Directive

Attribute Description

Whether the page is thread-safe or not. If true, the

container can use the JSP for multiple concurrent
isThreadSafe
request threads. Possible values are true and false.
Default is true.

An arbitrary string with any value. It is provided so

that the JSP can provide information to the
Info
management tool about its contents, purpose,
name, etc.
Directive Elements: Page Directive

Attribute Description

The URL of the web page that should be sent to the

errorPage
client if an error occurs in a page.

Used to indicate whether the current page is an

isErrorPage error page. Possible values are true and false.
Default is false.

Indicates the charset (character set) of the current

page. The default is ISO-8859-1 (Latin Script).
pageEncoding
Charsets indicates how written characters are
encoded, so that page can support languages that
use different scripts.
Directive Elements: Page Directive

Attribute Description

Defines the content type of the page. The content

contentType type can appear as a simple type specification, or
as a type specification and charset.

Specifies the scripting languages used on the page

when adding scripting elements within the JSP.
language
The attribute is almost always JAVA.

Kept as an option for future changes.

Enables to specify the super-class that the

extends container will use during the translation phase for
the current JSP.
Directive Elements: include Directive

Attribute Description

Indicates the file to be included at the current

file position in the file. The included file any be any
HTML or JSP page or fragment of a page.
 Processing of JSP Directives
Translation Phase Compilation Phase Request Phase

JSP file .java source code Binary Bytecode

Compilatio
Translation
n

<%@include...%> <%@include...%>

Incoming Outgoing
Request Response

JSP file / fragment JSP file / fragment

 Scripting Elements:

Scripting Elements are the elements in the JSP that include Java code.

These are embedded code written in the Java programming language

with a JSP page.

 Scripting Elements have three sub-forms:

 Declaration

 Scriptlet Code

 Expression
 Declaration

◊ Declarations are Java Code used to declare, and optionally define, a

Java variable or method.

◊ The declarations appear only within the translated JSP page, but
not in the output to the client.

<%! Java declaration; %>

<html>
<body>

<%

String names[]={“Nagesh", “Arun”, “Bhuvan”, “Dhruthi”,

“Dhamani”};

sort(names);

%>

The sorted list of names is: <br>

<%

for(int i = 0 ; i < names.length ; i++)

out.print(" "+names[i]);

%>
<%!
void sort(String n[])
{
String nt = new String();
int i, j;
for( ; ; )
{
for( ; ; )
{
if (n[ ].compareTo(n[ ]) > 0)

{
Swap the contents of ith and jth
locations
}
}
}
}
%>
</body>
</html>
 Scriptlet Code:

◊ Scriptlets are arbitrary Java code segments. Any legal java code
statement can appear within a scriptlet.

◊ The code in the scriptlet appears in the translated JSP, but not in
the output to the client.

<% Java scriptlet; %>

◊ Everything between the scriptlet markers, <% and %>, is script

code; everything outside the markers is template data. It will be
sent to the client as written.
 Difference between Scriptlet Code and declaration:

◊ Scriptlets cannot be used to define a method; only declarations can

be used for that.

◊ Variables declared in a declaration are instance variables of the JSP

page implementation class. These variables are visible to all other
code statements or methods in the page.

◊ Variables declared in a scriptlet are local to a method in the JSP

page implementation class. They are visible only within their
defining code block.
 Expression

◊ Expressions are used to output the value of a Java expression to

the client.

◊ Any legal Java expression can be used with an expression element.

◊ An expression could contain a method call, or a literal expression,

or an expression using Java variables or keywords or any
combination of these.

<%= Java Expression %>

 Comments:

◊ Comments are the way of describing the statement or block of

statements to enhance the readability.

◊ Two forms of comments can be written in JSP.

HTML Comment <!-- HTML Comment -->

◊ These comments will appear in the page source received by the

client.

JSP Comment <%-- JSP Comment --%>

◊ These comments will not appear in the page source received by the
client.
 Template Data:

◊ Everything that is not a directive, declaration, scriptlet, expression,

or JSP Comment is termed as Template Data.

◊ All the HTML and text in the JSP page is Template data.

◊ This data is output to the client as if it had appeared within a static

web page.
 Action Elements:

◊ Action Elements, also called as standard actions are built-in tags

that are built into every JSP implementation.

◊ These are defined by JSP specification and are used frequently in

almost every JSP .
 Action Elements:

◊ All standard actions are prefixed by jsp: and have the following
general form.

<jsp: tagname . . . Attributes . . . />

◊ Some standard actions also have a body that can include other
tags. The body part of any standard action specify typically the
parameters that have to be used.

<jsp: tagname . . . Attributes . . . >

<jsp: param . . . Attributes . . . />

. . . More parameters

</jsp: tagname>
 Action Elements:

◊ The standard actions can be classified into six groups:

1. Actions that work with and manipulate JavaBean instances

within JSPs.

2. Actions that include that output from additional JSP or web

resources at request time.

3. Actions for forwarding the incoming request to another JSP or

web resource for further processing.
 Action Elements:

◊ The standard actions can be classified into six groups:

4. Actions for specifying parameters within the body of other

standard actions.

5. Actions for embedding Java objects such as applets and

JavaBeans within a client’s web page.

6. Actions used only within the tag files.

1. Actions that work with and manipulate JavaBean instances within
JSPs.
 JavaBeans are objects written in Java programming language that
follow a specific set of coding conventions. They are the objects
with properties. These properties can be read (accessed) through a
get operation, or changed through a set operation.

 The JavaBean class has a no-argument constructor.

 Every property of the bean that is provided for the client use
has a method to set the value of the parameter, and a method
to get the value of the parameter. The methods have the
following form.
 The JavaBean methods have the following form.
public type getSomeParameter()
{
return someParameter;
}

public void setSomeParameter(type

someParameter)
{
//set the parameter. . . ;
}

public Boolean isSomeParameter()

{
return someParameter;
}
 Three standard actions are available for using JavaBeans:

 <jsp:usebean> - For creating a JavaBean instance or

associating a name with in
existing JavaBean instance.
 <jsp:setProperty> - To set the property of a
JavaBean instance.
 <jsp:getProperty> - To render (supply) the value of
a JavaBean property.
 <jsp:useBean>

This element makes a JavaBean available to the current JSP.

<jsp:useBean> element has the following attributes.

Attribute Description

The name used to access the bean in the rest of the

id page. It must be unique. It is essentially the
variable name that references the bean instance.

The scope of the bean. Valid values are page,

scope
request, session, or application. The default is page.
 Attribute Description

class The fully qualified class name of the bean class.

The type to be used for the variable that references

the bean. This
follows Java rules, so it can be the class of the
type
bean, any parent class of
the bean, or any interface implemented by the bean
or by a parent class.
 The <jsp:useBean> element causes the container to try to find and
existing instance of the object in the specified scope and the specified
id.
 If no object with the specified id is found in the scope, and a class or
bean name is specified, the container will try to create a new instance of
the object.
public class User
{
public void setSurname(String surname)
private String id;
{
private String surname;
this.surname = surname;
}
public void setId(String id)
{
public String getSurname()
this.id = id;
{
}
return surname;
}
public String getId()
} //end of the JavaBean
{
return id;
}
<jsp:useBean id="userA" class="User" />
<jsp:setProperty id="userA" property="surname" value= “Arun" />
<jsp:setProperty id="userA" property="id"
value=“E-03" />
Implicit Objects:

 The objects which the JSP container provides.

 These are accessible to JSP without needing to explicitly

declaration and initialization.

 Implicit objects are used within scriptlet and expression

elements.
request
response
out
session
config
exception
application
The request Object:
 JSP pages are web components that respond to and process
HTTP requests. The request implicit object represents this HTTP
request.

 Through the request object, HTTP headers, the request

parameters, and other information about the request can be
accessed.

 When a browser submits a request to a server, it can send

information along with the request in the form of request
parameters.

 The request object has request scope. That means that the
implicit request object is in scope until the response to the
client is complete.
The information sent to the server take two forms:

 URL-encoded parameters—These are parameters appended to the

requested URL as a query string. The parameters begin with a
question mark, followed by the name-value pairs of all the
parameters, with each pair delimited by an ampersand (&):

http://www.myserver.com/path/to/resource?name1=value1&name2=value2

 Form-encoded parameters –These parameters are submitted as a

result of a form submission. They have the same format as URL-
encoded parameters, but are included with the body of the request
and not appended to the requested URL.
The following methods can be used to read through the parameters passed
by the request object:

String request.getParameter(String name);

String[] request.getParameterValues(String name);
Enumeration request.getParameterNames();
Map getParameterMap();

 The getParameter(String) method returns the value of the

parameter with the given name. If the named parameter has multiple
values (for example, when a form submits the value of checkboxes), this
method returns the first value.
 For multi-valued parameters, getParameterValues(String) returns
all the values for the given name.

 The getParameterNames() method returns all the parameter

names used in the request.

 getParameterMap() returns all the parameters as namevalue

pairs.
The response Object:

 The response object encapsulates the response to the web

application client.

 The object can be used to set headers, set cookies for the client,
and send a redirect response to the client.

 The following methods can be used to perform the above

activities.

public void addHeader(String name, String value)

public void addCookie(Cookie cookie)
public void sendRedirect(String location)
The out Object

 The out implicit object is a reference to an output stream which

can be used within scriptlets. Using the out object, the scriptlet can
write data to the response that is sent to the client.

 The out object is an instance of javax.jsp.JspWriter. It has page

scope.
The session Object:

 To join the separate interactions into one coherent conversation

between client and application, web applications use the concept
of a session.

 A session refers to the entire conversation between a client and

a server.

 The JSP components in a web application automatically

participate in a given client’s session, without needing to do
anything special.
 Any JSP page that uses the page directive to set the session
attribute to false does not have access to the session object, and
thus cannot participate in the session.

 Using the session object, the page can store information about the
client or the client’s interaction.

 JSP page can only store objects in the session, and not Java
primitives. To store Java primitives, wrapper classes such as
Integer, or Boolean etc., have to be used.
 The methods for storing and retrieving session data are:
Object setAttribute(String name, Object value);
Object getAttribute(String name);

 The session object has session scope, and all the objects stored in
the session object also have session scope.
The config Object:

 This object is used to obtain JSP-specific init parameters. These

initialization parameters are set in the deployment descriptor, but
are specific to a single page.

 If JSP initialization parameters are defined in the deployment

descriptor, then they can be accessed using:
config.getInitParameter(String name);
The exception Object:

 This implicit object is only available within error pages. It is a

reference to the java.lang.Throwable object that caused the server
to call the error page.S
The application Object:

 This object represents the web application environment.

 The object can be used to get application level configuration

parameters.

 The value of the parameter can be accessed using:

application.getInitParameter(String name);