142
©Copyright 2004, Cognizant Academy, All Rights Reserved J2EE Version: J2EE/HANDOUT/0605/2.0 Date: 14-06-05 Cognizant Technology Solutions 500 Glen Pointe Center West Teaneck, NJ 07666 Ph: 201- 801- 0233 www.cognizant.com

J2EE Handout

Embed Size (px)

Citation preview

Page 1: J2EE Handout

©Copyright 2004, Cognizant Academy, All Rights Reserved

J2EE

Version: J2EE/HANDOUT/0605/2.0

Date: 14-06-05

Cognizant Technology Solutions

500 Glen Pointe Center West Teaneck, NJ 07666 Ph: 201-801-0233

www.cognizant.com

Page 2: J2EE Handout

J2EE

©Copyright 2004, Cognizant Academy, All Rights Reserved 2

TABLE OF CONTENTS

Introduction .........................................................................................................................5

About this Module ..............................................................................................................5

Target Audience.................................................................................................................5

Module Objectives..............................................................................................................5

Pre-requisite ......................................................................................................................5

Chapter 1: J2EE Introduction...............................................................................................6

Learning Objectives............................................................................................................6

Introduction........................................................................................................................6

Multi-tiered Architecture......................................................................................................6

Client Tier..........................................................................................................................7

Web Tier ...........................................................................................................................8

Business Tier.....................................................................................................................8

EIS Tier.............................................................................................................................8

J2EE API...........................................................................................................................8

Enterprise Java Beans .....................................................................................................12

Session ...........................................................................................................................12

Entity...............................................................................................................................14

SUMMARY......................................................................................................................16

Chapter 2: HTML ................................................................................................................17

Learning Objectives..........................................................................................................17

Introduction......................................................................................................................17

Create first HTML document .............................................................................................19

Elements of HTML ...........................................................................................................20

Create Hyperlinks.............................................................................................................21

Creating a mail to link.......................................................................................................22

Create Images .................................................................................................................22

The Alt Attribute ...............................................................................................................22

Create Lists .....................................................................................................................23

Create Forms...................................................................................................................25

Create Form Elements .....................................................................................................25

Create Tables ..................................................................................................................27

Create the HTML <FONT> tag and CSS............................................................................28

SUMMARY......................................................................................................................30

Chapter 3: Servlets ............................................................................................................31

Page 3: J2EE Handout

J2EE

©Copyright 2004, Cognizant Academy, All Rights Reserved 3

Learning Objectives..........................................................................................................31

Introduction......................................................................................................................31

Servlet architecture ..........................................................................................................32

Servlet Request & Response Model ..................................................................................32

Using the HttpServletRequest and HttpServletResponse Object..........................................33

Writing a simple Servlet....................................................................................................34

Complex Example............................................................................................................35

Servlet life cycle...............................................................................................................36

Web.xml configuration ......................................................................................................37

Servlet scope objects .......................................................................................................38

Session ...........................................................................................................................40

Carrying forward a Request ..............................................................................................42

Form-Servlet Integration ...................................................................................................45

SUMMARY......................................................................................................................47

Chapter 4: JSP...................................................................................................................48

Learning Objectives..........................................................................................................48

Introduction......................................................................................................................48

Learning the Basic Syntax ................................................................................................51

JSP Syntax Elements. ......................................................................................................52

Predefined Variables ........................................................................................................57

THE JSP PAGE LIFE CYCLE ...........................................................................................58

UNDERSTANDING JSP...................................................................................................60

JAVABEANS: A BRIEF OVERVIEW..................................................................................65

JSP tag libraries...............................................................................................................72

SUMMARY......................................................................................................................87

Chapter 5: XML ..................................................................................................................88

Learning Objective ...........................................................................................................88

Introduction......................................................................................................................88

XML Grammar .................................................................................................................90

XML document rules: .......................................................................................................96

Understand Document Type Declarations..........................................................................98

Creating a Simple XML Document................................................................................... 100

Well Formed and Valid XMLs.......................................................................................... 102

Common XML errors ...................................................................................................... 103

XML Attributes ............................................................................................................... 103

Quote Styles, "female" or 'female'?.................................................................................. 103

Page 4: J2EE Handout

J2EE

©Copyright 2004, Cognizant Academy, All Rights Reserved 4

Use of Elements vs. Attributes ........................................................................................ 104

Avoid using attributes? ................................................................................................... 105

An Exception to this Attribute rule.................................................................................... 105

XML Parsing.................................................................................................................. 106

DOM ............................................................................................................................. 106

SAX .............................................................................................................................. 107

When to use DOM and SAX parsers ............................................................................... 108

SUMMARY.................................................................................................................... 109

Chapter 6: Design patterns .............................................................................................. 110

Learning Objective ......................................................................................................... 110

Introduction.................................................................................................................... 110

MVC pattern .................................................................................................................. 110

Singleton Pattern ........................................................................................................... 111

Factory Pattern .............................................................................................................. 112

Transfer/Value Object..................................................................................................... 114

Session Façade ............................................................................................................. 117

Sample Code................................................................................................................. 119

SUMMARY.................................................................................................................... 128

Chapter7: J2EE Best Practices & Performance Tips........................................................ 129

Learning Objective ......................................................................................................... 129

Introduction.................................................................................................................... 130

SUMMARY.................................................................................................................... 140

REFERENCES.................................................................................................................. 141

WEBSITES.................................................................................................................... 141

BOOKS ......................................................................................................................... 141

STUDENT NOTES: ........................................................................................................... 142

Page 5: J2EE Handout

J2EE

©Copyright 2004, Cognizant Academy, All Rights Reserved 5

Introduction

About this Module

The module deals with standard IBM utilities and imparts knowledge on the same at a very

basic

level.

Target Audience

The module is specifically aimed at Entry Level Trainee Programmers.

Module Objectives

The module seeks to achieve the following objectives:

q Explain the various utilities and its functions

q Familiarize with data set and system related utilities

q Implement the utilities for basic operations

Pre-requisite

The module requires a prior knowledge of the following applications in a student:

q Programming in Cobol or any other mainframe language

q MVS operating system

Page 6: J2EE Handout

J2EE

©Copyright 2004, Cognizant Academy, All Rights Reserved 6

Chapter 1: J2EE Introduction

Learning Objectives

After completing this chapter, you will be able to:

q Understand Multi-tired Architecture

q Know about J2EE API

q Understand about session and entity

Introduction

J2EE stands for Java 2 Enterprise Edition. It is a specification provided by Sun Microsystems

for server side development in Java that is deployable in distributed environments. The latest

available version is J2EE version 1.4.

One unified specification of J2EE has helped to create applications that are vendor

independent. There are several application servers currently available in the market on which

a server side Java application can run. IBM Websphere, BEA Weblogic, Sun Java System

Application Server, Oracle 9i etc are most common examples. All these servers are J2EE

compliant servers as the vendors for these servers (IBM, BEA, Sun, Oracle) have made the

servers as J2EE compatible. Due to this, an application developed with J2EE compliance ad

running on one server can run on another server that supports J2EE, without any change (at

least in theory).

J2EE also facilitates component-based development. It gives different technologies to

develop the components at different layers. A JSP (Java Server Pages) developer can create

the web pages. A business component developer can create EJBs. An application server

vendor can create a J2EE engine that takes cares of factors like performance, transaction,

multithreading etc. Each of these roles can execute their job without being concerned about

how the other role has implemented its component. For example, a JSP developer need not

know how an EJB developer is retrieving data and processing it. Similarly an EJB developer

need not know how the JSP developer is going to display the data or how the application

server vendor is managing the integrity of the transaction of the EJBs that he created.

Multi-tiered Architecture

Before delving deeper into J2EE, it would be ideal to understand the multi-tier architecture

and how J2EE aligns to these tiers. The block diagram (Diagram 1) shows the schematic

representation of the multi-tier application. The left side shows the multi-tier representations

and the right side shows the equivalent J2EE layers.

The sub-sections below explain the tiers in detail:-

Page 7: J2EE Handout

J2EE

©Copyright 2004, Cognizant Academy, All Rights Reserved 7

Diagram 1

Client Tier

Client tier resides on one side of the network and the servers reside on the other. It is

represented by the sum total of all the client machines that are accessing the server where

the application is running. A program might be running on the client side that executes the

operations of the client tier. A browser is an ideal example of such an application. The client

tier can be further classified into the following:-

Thin client

A thin client has minimal processing logic. It depends completely on the server to do the

processing. An ideal thin client will just pass on events to the server requesting for data and

renders the data that is sent while the server responds. Examples of thin client are HTML,

XML, Javascript, etc running on a browser.

Thick client

A thick client will involve some processing at the client side. The server is contacted for data

retrieval. Number crunching, calculations, data manipulations etc will happen on the client

side. For a client, this may provide faster response than a thin client because the server is

contacted less frequently as compared to thin client.

EIS Tier

Client Tier

Business Tier

Web Tier

Multi-tier architecture

Database

HTML in Web browser

EJBs

JSP pages and Servlets

J2EE layers VS

Client Machine

J2EE Server

Intranet

In t rane t o r Internet

Page 8: J2EE Handout

J2EE

©Copyright 2004, Cognizant Academy, All Rights Reserved 8

Out of the two, a thin client is always preferred. Thin client model encourages the server to do

all the processing. This makes the application more maintainable and load balanced. If the

processing logic has to change, a thick client will have to under go change for every client

machine in the tier. But in thin client, the change is centralized and in the server. Also, a client

machine may not be well equipped to handle operations that require lot of processor capacity.

But this can be easily managed at server side as servers are usually installed with more

capable processors and memory. Also load balancing is possible at server side where

multiple servers can be added to distribute the load.

Web Tier

J2EE web components are either servlets or pages created using JSP technology (JSP

pages). Servlets are Java programming language classes that dynamically process requests

and construct responses. JSP pages are text-based documents that execute as servlets but

allow a more natural approach to creating static content.

Static HTML pages and applets are bundled with web components during application

assembly but are not considered web components by the J2EE specification. Server-side

utility classes can also be bundled with web components and, like HTML pages, are not

considered web components.

Business Tier

This includes the business code, which is logic that solves or meets the needs of a particular

business domain such as banking, retail, or finance, is handled by enterprise beans running in

the business tier.

EIS 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. For example, J2EE

application components might need access to enterprise information systems for database

connectivity.

J2EE API

The J2EE platform supports the multi-tier architecture by supporting a wide range of APIs that

will provide for the functionalities of the various tiers of the distributed system.

Enterprise JavaBeans Technology

An Enterprise JavaBeans (EJB) component, or enterprise bean, is a body of code having

fields and methods to implement modules of business logic. You can think of an enterprise

bean as a building block that can be used alone or with other enterprise beans to execute

business logic on the J2EE server.

There are three kinds of enterprise beans: session beans, entity beans, and message-driven

beans. Enterprise beans often interact with databases. One of the benefits of entity beans is

that you do not have to write any SQL code or use the JDBC API (see JDBC API) directly to

perform database access operations; the EJB container handles this for you. However, if you

override the default container-managed persistence for any reason, you will need to use the

Page 9: J2EE Handout

J2EE

©Copyright 2004, Cognizant Academy, All Rights Reserved 9

JDBC API. Also, if you choose to have a session bean access the database, you must use

the JDBC API.

Java Servlet Technology

Java servlet technology lets you define HTTP-specific servlet classes. A servlet class extends

the capabilities of servers that host applications that are accessed by way of a request-

response programming model. Although servlets can respond to any type of request, they are

commonly used to extend the applications hosted by web servers.

Java Server Pages Technology

Java Server Pages (JSP) technology lets you put snippets of servlet code directly into a text-

based document. A JSP page is a text-based document that contains two types of text: static

data (which can be expressed in any text-based format such as HTML, WML, and XML) and

JSP elements, which determine how the page constructs dynamic content.

Java Message Service API

The Java Message Service (JMS) API is a messaging standard that allows J2EE application

components to create, send, receive, and read messages. It enables distributed

communication that is loosely coupled, reliable, and asynchronous.

Java Transaction API

The Java Transaction API (JTA) provides a standard interface for demarcating transactions.

The J2EE architecture provides a default auto commit to handle transaction commits and

rollbacks. An auto commit means that any other applications that are viewing data will see the

updated data after each database read or write operation. However, if your application

performs two separate database access operations that depend on each other, you will want

to use the JTA API to demarcate where the entire transaction, including both operations,

begins, rolls back, and commits.

JavaMail API

J2EE applications use the JavaMail API to send email notifications. The JavaMail API has two

parts: an application-level interface used by the application components to send mail, and a

service provider interface. The J2EE platform includes JavaMail with a service provider that

allows application components to send Internet mail.

JavaBeans Activation Framework

The JavaBeans Activation Framework (JAF) is included because JavaMail uses it. JAF

provides standard services to determine the type of an arbitrary piece of data, encapsulate

access to it, discover the operations available on it, and create the appropriate JavaBeans

component to perform those operations.

Java API for XML Processing

The Java API for XML Processing (JAXP) supports the processing of XML documents using

Document Object Model (DOM), Simple API for XML (SAX), and Extensible Stylesheet

Language Transformations (XSLT). JAXP enables applications to parse and transform XML

documents independent of a particular XML processing implementation.

JAXP also provides namespace support, which lets you work with schemas that might

otherwise have naming conflicts. Designed to be flexible, JAXP lets you use any XML-

compliant parser or XSL processor from within your application and supports the W3C

Page 10: J2EE Handout

J2EE

©Copyright 2004, Cognizant Academy, All Rights Reserved 10

schema. You can find information on the W3C schema at this URL:

http://www.w3.org/XML/Schema.

Java API for XML-Based RPC

The Java API for XML-based RPC (JAX-RPC) uses the SOAP standard and HTTP, so client

programs can make XML-based remote procedure calls (RPCs) over the Internet. JAX-RPC

also supports WSDL, so you can import and export WSDL documents. With JAX-RPC and a

WSDL, you can easily interoperate with clients and services running on Java-based or non-

Java-based platforms such as .NET. For example, based on the WSDL document, a Visual

Basic .NET client can be configured to use a web service implemented in Java technology, or

a web service can be configured to recognize a Visual Basic .NET client.

JAX-RPC relies on the HTTP transport protocol. Taking that a step further, JAX-RPC lets you

create service applications that combine HTTP with a Java technology version of the Secure

Socket Layer (SSL) and Transport Layer Security (TLS) protocols to establish basic or mutual

authentication. SSL and TLS ensure message integrity by providing data encryption with

client and server authentication capabilities.

Authentication is a measured way to verify whether a party is eligible and able to access

certain information as a way to protect against the fraudulent use of a system or the

fraudulent transmission of information. Information transported across the Internet is

especially vulnerable to being intercepted and misused, so it's very important to configure a

JAX-RPC web service to protect data in transit.

SOAP with Attachments API for Java

The SOAP with Attachments API for Java (SAAJ) is a low-level API on which JAX-RPC

depends. SAAJ enables the production and consumption of messages that conform to the

SOAP 1.1 specification and SOAP with Attachments note. Most developers do not use the

SAAJ API, instead using the higher-level JAX-RPC API.

Java API for XML Registries

The Java API for XML Registries (JAXR) lets you access business and general-purpose

registries over the web. JAXR supports the ebXML Registry and Repository standards and

the emerging UDDI specifications. By using JAXR, developers can learn a single API and

gain access to both of these important registry technologies.

Additionally, businesses can submit material to be shared and search for material that others

have submitted. Standards groups have developed schemas for particular kinds of XML

documents; two businesses might, for example, agree to use the schema for their industry's

standard purchase order form. Because the schema is stored in a standard business registry,

both parties can use JAXR to access it.

J2EE Connector Architecture

The J2EE Connector architecture is used by J2EE tools vendors and system integrators to

create resource adapters that support access to enterprise information systems that can be

plugged in to any J2EE product. A resource adapter is a software component that allows

J2EE application components to access and interact with the underlying resource manager of

the EIS. Because a resource adapter is specific to its resource manager, typically there is a

different resource adapter for each type of database or enterprise information system.

Page 11: J2EE Handout

J2EE

©Copyright 2004, Cognizant Academy, All Rights Reserved 11

The J2EE Connector architecture also provides a performance-oriented, secure, scalable,

and message-based transactional integration of J2EE-based web services with existing EISs

that can be either synchronous or asynchronous. Existing applications and EISs integrated

through the J2EE Connector architecture into the J2EE platform can be exposed as XML-

based web services by using JAX-RPC and J2EE component models. Thus JAX-RPC and

the J2EE Connector architecture are complementary technologies for enterprise application

integration (EAI) and end-to-end business integration.

JDBC API

The JDBC API lets you invoke SQL commands from Java programing language methods.

You use the JDBC API in an enterprise bean when you override the default container-

managed persistence or have a session bean access the database. With container-managed

persistence, database access operations are handled by the container, and your enterprise

bean implementation contains no JDBC code or SQL commands. You can also use the JDBC

API from a servlet or a JSP page to access the database directly without going through an

enterprise bean.

The JDBC API has two parts: an application-level interface used by the application

components to access a database, and a service provider interface to attach a JDBC driver to

the J2EE platform.

Java Naming and Directory Interface

The Java Naming and Directory Interface (JNDI) provides naming and directory functionality.

It provides applications with methods for performing standard directory operations, such as

associating attributes with objects and searching for objects using their attributes. Using JNDI,

a J2EE application can store and retrieve any type of named Java object.

J2EE naming services provide application clients, enterprise beans, and web components

with access to a JNDI naming environment. A naming environment allows a component to be

customized without the need to access or change the component's source code. A container

implements the component's environment and provides it to the component as a JNDI naming

context.

A J2EE component locates its environment naming context using JNDI interfaces. A

component creates a javax.naming.InitialContext object and looks up the environment naming

context in InitialContext under the name java:comp/env. A component's naming environment

is stored directly in the environment naming context or in any of its direct or indirect

subcontexts.

A J2EE component can access named system-provided and user-defined objects. The

names of system-provided objects, such as JTA UserTransaction objects, are stored in the

environment naming context, java:comp/env. The J2EE platform allows a component to name

user-defined objects, such as enterprise beans, environment entries, JDBC DataSource

objects, and message connections. An object should be named within a subcontext of the

naming environment according to the type of the object. For example, enterprise beans are

named within the subcontext java:comp/env/ejb, and JDBC DataSource references in the

subcontext java:comp/env/jdbc.

Because JNDI is independent of any specific implementation, applications can use JNDI to

access multiple naming and directory services, including existing naming and directory

Page 12: J2EE Handout

J2EE

©Copyright 2004, Cognizant Academy, All Rights Reserved 12

services such as LDAP, NDS, DNS, and NIS. This allows J2EE applications to coexist with

legacy applications and systems.

Java Authentication and Authorization Service

The Java Authentication and Authorization Service (JAAS) provides a way for a J2EE

application to authenticate and authorize a specific user or group of users to run it.

JAAS is a Java programming language version of the standard Pluggable Authentication

Module (PAM) framework, which extends the Java 2 Platform security architecture to support

user-based authorization.

Enterprise Java Beans

An enterprise bean is a server-side component, written in the Java programming language

that encapsulates the business logic of an application. The business logic is the code that

fulfills the purpose of the application.

An enterprise bean is used under the following situations

1. If the application has to be scalable

2. Data integrity is to be ensured by the transactions

3. The application has to be exposed as a service to several clients

There are three types of EJB:-

Session

A session bean represents a single client inside the Application Server. To access an

application that is deployed on the server, the client invokes the session bean's methods. The

session bean performs work for its client, shielding the client from complexity by executing

business tasks inside the server.

As its name suggests, a session bean is similar to an interactive session. A session bean is

not shared; it can have only one client, in the same way that an interactive session can have

only one user. Like an interactive session, a session bean is not persistent. (That is, its data is

not saved to a database.) When the client terminates, its session bean appears to terminate

and is no longer associated with the client.

There are two types of session beans: stateless and stateful.

Stateless session

A stateless session bean does not maintain a conversational state for the client. When a

client invokes the method of a stateless bean, the bean's instance variables may contain a

state, but only for the duration of the invocation. When the method is finished, the state is no

longer retained. Except during method invocation, all instances of a stateless bean are

equivalent, allowing the EJB container to assign an instance to any client.

Page 13: J2EE Handout

J2EE

©Copyright 2004, Cognizant Academy, All Rights Reserved 13

Because stateless session beans can support multiple clients, they can offer better scalability

for applications that require large numbers of clients. Typically, an application requires fewer

stateless session beans than stateful session beans to support the same number of clients.

At times, the EJB container may write a stateful session bean to secondary storage. However,

stateless session beans are never written to secondary storage. Therefore, stateless beans

may offer better performance than stateful beans.

A stateless session bean can implement a web service, but other types of enterprise beans

cannot.

Stateful session

The state of an object consists of the values of its instance variables. In a stateful session

bean, the instance variables represent the state of a unique client-bean session. Because the

client interacts with its bean, this state is often called the conversational state.

The state is retained for the duration of the client-bean session. If the client removes the bean

or terminates, the session ends and the state disappears. This transient nature of the state is

not a problem, however, because when the conversation between the client and the bean

ends there is no need to retain the state.

When to use

In general, you should use a session bean if the following circumstances hold:

q At any given time, only one client has access to the bean instance.

q The state of the bean is not persistent, existing only for a short period (perhaps a

few hours).

q The bean implements a web service.

Stateful session beans are appropriate if any of the following conditions are true:

q The bean's state represents the interaction between the bean and a specific

client.

q The bean needs to hold information about the client across method invocations.

q The bean mediates between the client and the other components of the

application, presenting a simplified view to the client.

q Behind the scenes, the bean manages the work flow of several enterprise beans.

To improve performance, you might choose a stateless session bean if it has any of these

traits:

q The bean's state has no data for a specific client.

q In a single method invocation, the bean performs a generic task for all clients. For

example, you might use a stateless session bean to send an email that confirms

an online order.

q The bean fetches from a database a set of read-only data that is often used by

clients.

Page 14: J2EE Handout

J2EE

©Copyright 2004, Cognizant Academy, All Rights Reserved 14

Entity

An entity bean represents a business object in a persistent storage mechanism. Some

examples of business objects are customers, orders, and products. In the Application Server,

the persistent storage mechanism is a relational database. Typically, each entity bean has an

underlying table in a relational database, and each instance of the bean corresponds to a row

in that table. Entity beans are persistent, allow shared access, have primary keys, and can

participate in relationships with other entity beans.

Because the state of an entity bean is saved in a storage mechanism, it is persistent.

Persistence means that the entity bean's state exists beyond the lifetime of the application or

the Application Server process. If you've worked with databases, you're familiar with

persistent data. The data in a database is persistent because it still exists even after you shut

down the database server or the applications it services.

There are two types of persistence for entity beans: bean-managed and container-managed.

With bean-managed persistence, the entity bean code that you write contains the calls that

access the database. If your bean has container-managed persistence, the EJB container

automatically generates the necessary database access calls. The code that you write for the

entity bean does not include these calls.

Primary key

Each entity bean has a unique object identifier. A customer entity bean, for example, might be

identified by a customer number. The unique identifier, or primary key, enables the client to

locate a particular entity bean.

Relationships

Like a table in a relational database, an entity bean may be related to other entity beans. You

implement relationships differently for entity beans with bean-managed persistence than

those with container-managed persistence. With bean-managed persistence, the code that

you write implements the relationships. But with container-managed persistence, the EJB

container takes care of the relationships for you. For this reason, relationships in entity beans

with container-managed persistence are often referred to as container-managed

relationships.

When to use

The entity bean can be used under the following situations:-

q The bean represents a business entity and not a procedure. For example,

CreditCardBean would be an entity bean, but CreditCardVerifierBean would be a

session bean.

q The bean's state must be persistent. If the bean instance terminates or if the

Application Server is shut down, the bean's state still exists in persistent storage

(a database).

Message driven

A message-driven bean is an enterprise bean that allows J2EE applications to process

messages asynchronously. It normally acts as a JMS message listener, which is similar to an

event listener except that it receives JMS messages instead of events. The messages can be

sent by any J2EE component--an application client, another enterprise bean, or a web

Page 15: J2EE Handout

J2EE

©Copyright 2004, Cognizant Academy, All Rights Reserved 15

component--or by a JMS application or system that does not use J2EE technology. Message-

driven beans can process either JMS messages or other kinds of messages.

The most visible difference between message-driven beans and session and entity beans is

that clients do not access message-driven beans through interfaces. Unlike a session or

entity bean, a message-driven bean has only a bean class.

Message-driven beans have the following characteristics:

q They execute upon receipt of a single client message.

q They are invoked asynchronously.

q They are relatively short-lived.

q They do not represent directly shared data in the database, but they can access

and update this data.

q They can be transaction-aware.

q They are stateless.

When to use

Session beans and entity beans allow you to send JMS messages and to receive them

synchronously, but not asynchronously. To avoid tying up server resources, you may prefer

not to use blocking synchronous receives in a server-side component. To receive messages

asynchronously, use a message-driven bean.

Client code to access EJB

Accessing an EJB from a client class has the following steps

q Locating the home interface

q Creating an enterprise bean instance

q Invoking a business method

Locating the Home Interface

The ConverterHome interface defines life-cycle methods such as create and remove. Before

the ConverterClient can invoke the create method, it must locate and instantiate an object

whose type is ConverterHome. This is a four-step process.

1. Create an initial naming context.

Context initial = new InitialContext();

The Context interface is part of the Java Naming and Directory Interface (JNDI). A naming

context is a set of name-to-object bindings. A name that is bound within a context is the JNDI

name of the object.

An InitialContext object, which implements the Context interface, provides the starting point

for the resolution of names. All naming operations are relative to a context.

2. Obtain the environment naming context of the application client.

Context myEnv = (Context) initial.lookup("java:comp/env");

Page 16: J2EE Handout

J2EE

©Copyright 2004, Cognizant Academy, All Rights Reserved 16

The java:comp/env name is bound to the environment naming context of this client

component.

3. Retrieve the object bound to the name ejb/MyBean.

Object objref = myEnv.lookup("ejb/MyBean");

The ejb/MyBean name is bound to an enterprise bean reference, a logical name for the home

of an enterprise bean. In this case, the ejb/MyBean name refers to the MyHome object. The

names of enterprise beans should reside in the java:comp/env/ejb subcontext.

4. Narrow the reference to a MyHome object.

MyHome home = (MyHome) PortableRemoteObject.narrow(objref, MyHome.class);

Creating an Enterprise Bean Instance

To create the bean instance, the client invokes the create method on the MyHome object. The

create method returns an object whose type is Converter. The remote Converter interface

defines the business methods of the bean that the client can call. When the client invokes the

create method, the EJB container instantiates the bean and then invokes the

MyBean.ejbCreate method. The client invokes the create method as follows:

MyRemote myRemote = myHome.create();

Invoking a Business Method

Calling a business method is easy: you simply invoke the method on the myRemote object.

The EJB container will invoke the corresponding method on the MyBean instance that is

running on the server.

myRemote.anyEjbMethod();

SUMMARY

After completing this chapter, you will have learned:

q Understand Multi-tired Architecture

q Know about J2EE API

q Understand about session and entity

Page 17: J2EE Handout

J2EE

©Copyright 2004, Cognizant Academy, All Rights Reserved 17

Chapter 2: HTML

Learning Objectives

After completing this chapter, you will able to:

q Create HTML Pages yourself

Introduction

What is the World Wide Web?

The World Wide Web (Web) is a network of information resources. The Web relies on three

mechanisms to make these resources readily available to the widest possible audience:

1. A uniform naming scheme for locating resources on the Web (e.g., URIs).

2. Protocols, for access to named resources over the Web (e.g., HTTP).

3. Hypertext, for easy navigation among resources (e.g., HTML).

Introduction to URIs

Every resource available on the Web -- HTML document, image, video clip, program, etc. --

has an address that may be encoded by a Universal Resource Identifier, or "URI".

URIs typically consists of three pieces:

1. The naming scheme of the mechanism used to access the resource.

2. The name of the machine hosting the resource.

3. The name of the resource itself, given as a path.

Consider the URI that designates the W3C Technical Reports page:

http://www.w3.org/TR

This URI may be read as follows: There is a document available via the HTTP protocol (see

[RFC2616]), residing on the machine www.w3.org, accessible via the path "/TR". Other

schemes you may see in HTML documents include "mailto" for email and "ftp" for FTP.

Here is another example of a URI. This one refers to a user's mailbox:

<A href="mailto:[email protected]">Joe Cool</A>.

To publish information for global distribution, one needs a universally understood language, a

kind of publishing mother tongue that all computers may potentially understand. The

publishing language used by the World Wide Web is HTML (from HyperText Markup

Language).

Page 18: J2EE Handout

J2EE

©Copyright 2004, Cognizant Academy, All Rights Reserved 18

HTML gives authors the means to:

q Publish online documents with headings, text, tables, lists, photos, etc.

q Retrieve online information via hypertext links, at the click of a button.

q Design forms for conducting transactions with remote services, for use in

searching for information, making reservations, ordering products, etc.

q Include spread-sheets, video clips, sound clips, and other applications directly in

their documents.

Fragment identifiers

Some URIs refers to a location within a resource. This kind of URI ends with "#" followed by

an anchor identifier (called the fragment identifier). For instance, here is a URI pointing to an

anchor named section_2:

http://somesite.com/html/top.html#section_2

Relative URIs

A relative URI doesn't contain any naming scheme information. Its path generally refers to a

resource on the same machine as the current document. Relative URIs may contain relative

path components (e.g., ".." means one level up in the hierarchy defined by the path), and may

contain fragment Identifiers.

Relative URIs are resolved to full URI using a base URI. As an example of relative URI

resolution, assume we have the base URI

http://www.acme.com/support/intro.html

The relative URI in the following markup for a hypertext link:

<A href="suppliers.html">Suppliers</A>

Would expand to the full URI

http://www.acme.com/support/suppliers.html,

While the relative URI in the following markup for an image

<IMG src="../icons/logo.gif" alt="logo">

Would expand to the full URI

http://www.acme.com/icons/logo.gif.

Page 19: J2EE Handout

J2EE

©Copyright 2004, Cognizant Academy, All Rights Reserved 19

Application of URIs

In HTML, URIs are used to:

q Link to another document or resource

q Link to an external style sheet or script

q Include an image, object, or applet in a page

q Create an image map.

q Submit a form.

q Create a frame document.

q Cite an external reference.

q Refer to metadata conventions describing a document.

Learn Specific limitations of HTML

HTML Does not

q Recognize spaces, tabs or margins

q Translate easily from other types of documents

q Support all font styles.

q Recognize line breaks, or paragraph breaks (unless you code it in, of course).

Create first HTML document

Document Type Declaration

An HTML document should begin with a so-called document type definition (abbr. DTD) which

specifies the particular version of HTML used in the file. Although most browsers ignore it, it is

crucial when the document is processed by a validator. The DTD is also very important if the

document is processed by a general SGML browser, i.e. a program which can display a

document written in any language defined using SGML, not just HTML documents.

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0//EN">

The HTML start tag

The HTML Contents are identified by the start tag. The Language attribute can be set here

<html>

</html>

Contents

The content inside the html is mainly divided into two parts

head – Contains the information about the document

Body – Contains that are to be displayed in the browser

First HTML should at least have this

<html> <head> <title>page title</title> </head> <body>

Page 20: J2EE Handout

J2EE

©Copyright 2004, Cognizant Academy, All Rights Reserved 20

<p>contents comes here</p> </body> </html>

Every HTML document is required by the HTML standard to have a title. The title should

instantly tell the reader what the document is about.

The above forms the basic skeleton for a HTML file. The file should be saved as htm or html.

HTML tags are not case sensitive; <b> means the same as <B>. But, the World Wide Web

Consortium (W3C) recommends lowercase tags in their HTML 4 recommendation, and

XHTML (the next generation HTML) demands lowercase tags.

Elements of HTML

Create HTML and text

Comments can be added with the <!—tag.

<!-- This is a comment -->

Headings are defined with the <h1> to <h6> tags. <h1> defines the largest heading. <h6>

defines the smallest heading.

<h1>This is a heading</h1>

HTML automatically adds an extra blank line before and after a heading.

HTML display will not insert line breaks or paragraph breaks on its own – they have to be

inserted using tags in the HTML file. <br> would insert a line break. The <br> tag is used

when you want to end a line, but don't want to start a new paragraph. Paragraph elements

are defined by the p tag. <p> ( Text goes here) </p>.

HTML automatically adds an extra blank line before and after a paragraph. Some text

formatting tags :

<b>This text is bold</b><br> <strong>This text is strong</strong><br> <big>This text is big</big><br> <em>This text is emphasized</em><br> <i>This text is italic</i><br> <small>This text is small</small><br> This text contains <sub>subscript</sub><br> This text contains <sup>superscript</sup> <pre>This is preformatted text. It preserves both spaces and line breaks. </pre>

Page 21: J2EE Handout

J2EE

©Copyright 2004, Cognizant Academy, All Rights Reserved 21

Create Hyperlinks

HTML uses the <a> (anchor) tag to create a link to another document. An anchor can point

to any resource on the Web: an HTML page, an image, a sound file, a movie, etc.

The syntax of creating an anchor:

<a href="url">Text to be displayed</a>

The <a> tag is used to create an anchor to link from, the href attribute is used to address the

document to link to, and the words between the open and close of the anchor tag will be

displayed as a hyperlink.

This anchor defines a link to the Cognizant website:

<a href="http://www.cognizant.com/">Visit us at the Cognizant website!</a>

The Target Attribute With the target attribute, we can define where the linked document will

be opened. The line below will open the document in a new browser window:

<a href="http://www.cognizant.com/" target="_blank"> Visit us at the Cognizant website!</a>

The Anchor Tag and the Name Attribute

The name attribute is used to create a named anchor. When using named anchors we can

create links that can jump directly into a specific section on a page, like a bookmark in MS

Word, instead of letting the user scroll around to find what he/she is looking for. Below is the

syntax of a named anchor:

<a name="label">Contact US Text to be displayed</a>

The name attribute is used to create a named anchor. The name of the anchor can be any

text. A named anchor is not displayed in a special way. To link directly to the "Contact Us "

section, add a # sign and the name of the anchor to the end of a URL, like this:

<a href="http://www.cognizant.com/html_links.asp#label"> Contact Us!</a>

A hyperlink to the Contact Us Section from WITHIN the file "html. " will look like this:

<a href="#Contact">Contact Us!</a>

A trailing slash should always be added to subfolder references. If we link like this:

href="http://www.cognizant.com/html"

Two HTTP requests to the server will be generated, because the server will add a slash to the

address and create a new request like this:

href= http://www.cognizant.com/html/

Named anchors are often used to create "table of contents" at the beginning of a large

document. Each chapter within the document is given a named anchor, and links to each of

these anchors are put at the top of the document. If a browser cannot find a named anchor

that has been specified, it goes to the top of the document. No error occurs.

Page 22: J2EE Handout

J2EE

©Copyright 2004, Cognizant Academy, All Rights Reserved 22

Creating a mail to link

This is a mail link:

<a href="mailto:[email protected]?subject=Hello %20again">Send Mail</a>

This will generate a hyperlink that will directly open an email client with Hello Again as the

Subject. This is another, more complicated mailto link:

<a href="mailto:[email protected]?cc=someoneelse @cognizant.com&[email protected]&subject=Customer%20Complaint&body=I%20wish%20to%20register%20a%20product%20complaint.">Send mail!</a>

Create Images

In HTML, images are defined with the <img> tag.

The <img> tag is empty, which means that it contains attributes only and it has no closing tag.

To display an image on a page, we need to use the src attribute. Src stands for "source". The

value of the src attribute is the URL of the image we want to display on ther page. The syntax

of defining an image:

<img src="url">

The URL points to the location where the image is stored. An image named "vertical.gif"

located in the directory "images" on "www.cognizant.com" has the URL:

http://www.cognizant.com/images/vertical.gif.

The browser puts the image where the image tag occurs in the document. If an image tag is

put between two paragraphs, the browser shows the first paragraph, then the image, and then

the second paragraph.

The Alt Attribute

The alt attribute is used to define an "alternate text" for an image. The value of the alt attribute

is an author-defined text:

<img src="vertical.gif" alt="Verticals">

The "alt" attribute tells the reader what he or she is missing on a page if the browser can't

load images. The browser will then display the alternate text instead of the image. It is a good

practice to include the "alt" attribute for each image on a page, to improve the display and

usefulness of the document for people who have text-only browsers.

Best Practice

Loading images take time, so images must be used sparingly. Wherever possible, we must

use thumbnails that then open up into bigger images when clicked on.

Page 23: J2EE Handout

J2EE

©Copyright 2004, Cognizant Academy, All Rights Reserved 23

1. Adding a Background Image to the HTML Page

We can add a background by using the background attribute of the <body> tag.

<body background="background.jpg">

Both gif and jpg files can be used as HTML backgrounds. If the image is smaller than the

page, the image will repeat itself.

2. Changing the size of the image

You can make a picture larger or smaller changing the values in the "height" and "width"

attributes of the img tag. But enlarging an image may spoil the display if the image does not

have the requisite resolution.

<img src="/images/switzerland.gif" width="20" height="20">

3. Aligning an Image

<img src ="/images/xhtml.gif" align="bottom" width="100" height="50">

OR

<img src ="/images/xhtml.gif" align="middle" width="100" height="50">

4. To make the image float to the left of this text.

<img src ="/images/xhtml.gif" align ="left" width="100" height="50">

An image can be used as a link:

<a href="lastpage.html"><img border="0" src="buttonnext.gif" width="65" height="38">

Create Lists

Unordered Lists

An unordered list is a list of items. The list items are marked with bullets. An unordered list

starts with the <ul> tag. Each list item starts with the <li> tag.

<ul> <li>Operating Systems</li> <li>Client Server</li> </ul>

Inside a list item we can put paragraphs, line breaks, images, links, other lists, etc.

Ordered Lists

An ordered list is a numbered list of items. The list items are marked with numbers. An

ordered list starts with the <ol> tag. Each list item starts with the <li> tag.

<ol> <li> Operating Systems </li> <li> Client Server </li> </ol>

Page 24: J2EE Handout

J2EE

©Copyright 2004, Cognizant Academy, All Rights Reserved 24

Here is how it looks in a browser:

1. Operating Systems

2. Client Server

Inside a list item we can put paragraphs, line breaks, images, links, other lists, etc.

Definition Lists

A definition list is not a list of items. This is a list of terms and explanation of the terms also

called a glossary list.

A definition list starts with the <dl> tag. Each definition-list term starts with the <dt> tag. Each

definition-list definition starts with the <dd> tag.

<dl> <dt>Operating systems</dt> <dd>Duration: 8 hours Coverage: Operating System concepts and Basics</dd> <dt>Client Server</dt> <dd>Duration : 8 hours Coverage: Evolution upto n tier systems</dd> </dl>

Inside a definition-list definition (the <dd> tag) we can put paragraphs, line breaks, images,

links, other lists, etc.

Different Lists:

For a list numbered as A, B, C

<h4>Letters list:</h4> <ol type="A"> <li>Tim Berners Lee</li> <li>Judy Brewer</li> <li>Steve Bratt </li> <li>Daniel Dardailler</li> </ol>

For a list numbered with Roman numbers:

<h4>Roman numbers list:</h4> <ol type="I"> <li>Tim Berners Lee</li> <li>Judy Brewer</li> <li>Steve Bratt </li> <li>Daniel Dardailler</li> </ol>

For a list bulleted with a circle:

<h4>Lowercase Roman numbers list:</h4> <ul type="circle"> <li>Tim Berners Lee</li> <li>Judy Brewer</li> <li>Steve Bratt </li> <li>Daniel Dardailler</li> </ul> For a list bulleted with a circle:

Page 25: J2EE Handout

J2EE

©Copyright 2004, Cognizant Academy, All Rights Reserved 25

<ul> <li>Module 1</li> <li>Module 2 <ul> <li>History of Operating Systems</li> <li>Basic Concepts</li> </ul> </li> <li>Module 3</li> </ul>

Create Forms

A form is an area that contains form elements. Form elements are elements that allow the

user to enter information (like text fields, textarea, fields, drop-down menus, radio buttons,

checkboxes, etc.) in a form. Forms are typically used for registration of new users, providing

payment details , answering surveys, submitting feedback etc on websites. Forms are an

important part of website interaction and enhance visitor experience.

A form is defined with the <form> tag.

<form name="registration" action="html_form_action.asp" method="get"> <input> <input> </form>

Action Attribute and method attribute

When the user clicks on the "Submit" button, the content of the form is sent to another file.

The form's action attribute defines the name of the file to send the content to. The file defined

in the action attribute usually does something with the received input.

<form name="input" action="Search_Input_Form1.asp" method="get"> Search: <input type="text" name="user"> <input type="submit" value="Submit"> </form>

If some characters are typed in the text field above, and "Submit" button clicked, input will be

sent to a page called " Search_Input_Form1.asp ". That page will show the received input or

process it in some way.

Create Form Elements

TextBoxes

The most used form tag is the <input> tag. The type of input is specified with the type

attribute.The most commonly used input types are explained below.

Page 26: J2EE Handout

J2EE

©Copyright 2004, Cognizant Academy, All Rights Reserved 26

Text Fields

Text fields are used when you want the user to type letters, numbers, etc. in a form.

<form> First name: <input type="text" name="firstname"> <br> Last name: <input type="text" name="lastname"> </form>

The form itself will not be visible. The default number of characters is 20 and can be set by

the attribute “size”.

Radio Buttons

Radio Buttons are used when the user has to select one of a limited number of choices

(Mutually Exclusive Options).

<form> <input type="radio" name="sex" value="male"> Male <br> <input type="radio" name="sex" value="female"> Female </form>

Note that only one option can be chosen.

Checkboxes

Checkboxes are used when the user can select one or more options of a limited number of

choices.

<form> <input type="checkbox" name="Category 1"> Professional<br> <input type="checkbox" name="Category 2"> Self Employed <br> <input type="checkbox" name="Category 3"> IT Services </form>

Drop Down List

A Drop Down List will display a text box with a downward arrow which when clicked on will

open downwards into a list of choices – only one of which can then be chosen.

<form> <select name="pets"> <option value="Dog">Dog <option value="Cat">Cat <option value="Canary">Canary <option value="Parrot">Parrot </select> </form>

Page 27: J2EE Handout

J2EE

©Copyright 2004, Cognizant Academy, All Rights Reserved 27

Textarea

A text area is a like a text box but can be scollable and has a wrap option.

<textarea rows = “10” columns = “30”> A textarea is like a scrollable text box and upto 255 characters can be displayed </textarea>

Submit Button / Reset Button

<input type="submit" value="Submit">&nbsp<input type=”reset” value=”Refresh”>

Create Tables

Tables are a good way of displaying text in cells or to align text on a page as HTML is

equipped to control text inherently. Table attributes are:

q Align

q bgcolor

q border

q bordercolor

q cellpadding

q cellspacing

q height

q width

<table border="0" width="360"> <tr> <td align="center">EMI<br>Signings</a></td> <td align="center">Songwriter<br>Spotlight</a></td> <td align="center">News<br>in Brief</a></td> </tr> <tr> <td align="center">Contact<br>EMI</a></td> <td align="center">Job<br>Listings</a></td> <td align="center">Why<br>Register?</a></td> </tr> </table>

Cell <td> attributes

q align

q valign

q bgcolor

q colspan

q rowspan

q height

q width

Page 28: J2EE Handout

J2EE

©Copyright 2004, Cognizant Academy, All Rights Reserved 28

Sometimes, a table may not be symmetric and need some columns or rows to be merged .

This is achieved by the <td colspan = “some number”> or <td rowspan = “some number”>

attribute.

The table in the page below was generated by the following HTML:

<table border="0" width="360"> <tr> <td colspan=”2” align="center">EMI<br>Signings</a></td> <td align="center">Songwriter<br>Spotlight</a></td> </tr> <tr> <td align="center">Contact<br>EMI</a></td> <td align="center">Job<br>Listings</a></td> <td align="center">Why<br>Register?</a></td> </tr> </table>

Create the HTML <FONT> tag and CSS

The <font> tag is used to set the font style, size, color much the same as in MS Word or any

other word processing software. It is a best practice to use stylesheets so that a lot of HTML

code can be saved by applying a stylesheet instead of having numerous font tags throughout,

say, a website. A stylesheet is a blueprint of font styles that apply to different kinds of text for

eg :

Headers, Paragraph headings etc. By attaching style sheets to structured documents on the

Web (e.g. HTML), authors and readers can influence the presentation of documents without

sacrificing device-independence or adding new HTML tags.

<font face="Arial,Helvetica,sans-serif" size="2" color="#0F5F8D">Stylesheets / CSS

Cascading Style Sheets (CSS) is a simple mechanism for adding style (e.g. fonts, colors,

spacing) to Web documents. Setting the color of the text and the background: This can be

done by using the STYLE element to set style properties for the document's tags:

<style type="text/css"> body { color: black; background: white; } </style>

The text between the <style> and </style> is written in special notation for style rules. Each

rule starts with a tag name followed by a list of style properties bracketed by { and }. In this

example, the rule matches the body tag. The body tag provides the basis for setting the

overall look and feel of the Web page.

Each style property starts with the property's name, then a colon and lastly the value for this

property. When there is more than one style property in the list, you need to use a semicolon

between each of them to delimit one property from the next. In this example, there are two

properties - "color" which sets the color of the text, and "background" which sets the color of

the page background. Colors can be given as names or as numerical values, for instance

Page 29: J2EE Handout

J2EE

©Copyright 2004, Cognizant Academy, All Rights Reserved 29

rgb(255,204, 204) which is light pink. The 3 numbers correspond to red, green and blue

respectively in the range 0 to 255. But as a best practice, we should use a hexadecimal

notation, where the same color can also be written as #FFCCCC.

Note that the style element must be placed in the document's head along with the title

element. It shouldn't be placed within the body.

If the same styles are to be used for several Web pages it is worth considering using a

separate style sheet which can then be linked from each page. This can be done as as

follows:

<link type="text/css" rel="stylesheet" href="style.css">

The LINK tag should be placed in the document's head. The rel attribute must be set to the

value "stylesheet" to allow the browser to recognize that the href attribute gives the Web

address (URL) for the style sheet.

Font styles

The most common styles are to place text in italic or bold. Most browsers render the em tag in

italic and the strong tag in bold. Let's assume that we want em to appear in bold italic and

strong in bold uppercase :

em { font-style: italic; font-weight: bold; } strong { text-transform: uppercase; font-weight: bold; }

We can fold headings to lower case as follows:

h2 { text-transform: lowercase; }

Setting the font size

Most browsers use a larger font size for more important headings. It is recommended to

specify font sizes in relative terms. This example sets heading sizes in percentages relative to

the size used for normal text:

h1 { font-size: 200%; } h2 { font-size: 150%; } h3 { font-size: 100%; }

Setting the font family

It is likely that the font specified won't be available on all browsers. To get around this, we are

allowed to list several fonts in preference order. There is a short list of generic font names

which are guaranteed to be available, so you are recommended to end your list with one of

these: serif, sans-serif, cursive, fantasy, or monospace, for instance:

body { font-family: Verdana, sans-serif; } h1,h2 { font-family: Garamond, "Times New Roman", serif; }

Page 30: J2EE Handout

J2EE

©Copyright 2004, Cognizant Academy, All Rights Reserved 30

In this example, important headings would preferably be shown in Garamond, failing that in

Times New Roman, and if that is unavailable in the browsers default serif font. Paragraph text

would appear in Verdana or if that is unavailable in the browser's default sans-serif font. The

legibility of different fonts generally depends more on the height of lower case letters than on

the font size itself. Fonts like Verdana are much more legible than ones like "Times New

Roman".

Setting left and right indents: <style type="text/css"> body { margin-left: 10%; margin-right: 10%; } h1 { margin-left: -8%;} h2,h3,h4,h5,h6 { margin-left: -4%; } </style>

This example has three style rules. One for the body, one for h1 (used for the most important

headings) and one for the rest of the headings (h2, h3, h4, h5 and h6). The margins for the

headings are additive to the margins for the body. Negative values are used to move the start

of the headings to the left of the margin set for the body.

SUMMARY

q HTML is Hypertext Markup Language – the language on which the WWW and the

Internet are based on.

q HTML is all about display of text and does not possess programming capabilities

q The HTML standards are set by W3C and the standard is moving towards a

hybrid of XML and HTML called XHTML

q HTML consists of tags, attributes with name value pairs and can be understood

by browsers.

q Most tags are a pair – starting tag and closing tag

q Cascading stylesheets are now a standard for defining look and feel of HTML

pages

Page 31: J2EE Handout

J2EE

©Copyright 2004, Cognizant Academy, All Rights Reserved 31

Chapter 3: Servlets

Learning Objectives

After completing this chapter, you will be able to:

q Understand Servlet Architecture

q Know Servlet lifecycle and how to write Servlet

q Know Web.xml Configuration

q Understand Servlet scope and Session

Introduction

Servlets are Java technology’s answer to Common Gateway Interface (CGI) programming.

They are programs that run on a Web server, acting as a middle layer between a request

coming from a Web browser or other HTTP client and databases or applications on the HTTP

server. Their job is to:

q Read any data sent by the user. This data is usually entered in a form on a

Webpage, but could also come from a Java applet or a custom HTTP client

program.

q Look up any other information about the request that is embedded in the HTTP

request. This information includes details about browser capabilities, cookies, the

host name of the requesting client, and so forth.

q Generate the results. This process may require talking to a database, executing

an RMI or CORBA call, invoking a legacy application, or computing the response

directly.

q Format the results inside a document. In most cases, this involves embedding the

information inside an HTML page.

q Set the appropriate HTTP response parameters. This means telling the browser

what type of document is being returned (e.g., HTML), setting cookies and

caching parameters, and other such tasks.

q Send the document back to the client. This document may be sent in text format

(HTML), binary format (GIF images), or even in a compressed format like gzip

that is layered on top of some other underlying format.

Returning pre-built documents can satisfy many client requests, and the server would handle

these requests without invoking servlets. In many cases, however, a static result is not

sufficient, and a page needs to be generated for each request. There are a number of

reasons why Web pages need to be built on the fly like this:

q The Web page is based on data submitted by the user. For instance, the results

page from search engines and order-confirmation pages at on-line stores are

specific to particular user requests. The Web page is derived from data that

changes frequently. For example, a weather report or news headlines page might

Page 32: J2EE Handout

J2EE

©Copyright 2004, Cognizant Academy, All Rights Reserved 32

build the page dynamically, perhaps returning a previously built page if it is still up

to date.

q The Web page uses information from corporate databases or other server-side

sources.For example, an e-commerce site could use a servlet to build a Web

page that lists the current price and availability of each item that is for sale.

q In principle, servlets are not restricted to Web or application servers that handle

HTTP requests, but can be used for other types of servers as well. For example,

servlets could be embedded in mail or FTP servers to extend their functionality.

Servlet architecture

The featured component created with the servlet API is the servlet itself. A servlet is an

object that extends either the javax.servlet.GenericServlet class or the

javax.servlet.http.HttpServlet class. The javax.servlet.GenericServlet class defines methods

for building generic, protocol-independent servlets. The javax.servlet.http.HttpServlet class

extends this class to provide HTTP-specific methods. The diagram in following figure

illustrates the hierarchy of a typical HTTP servlet and the relationships and functionality

exposed by the classes in the hierarchy.

Class hierarchy

As you can see, the GenericServlet class defines generic server-side operations; the

HttpServlet extends this to define HTTP-specific operations; and application-specific servlets

extend this to provide application-specific operations. We will be referring to servlets created

for the HTTP environment throughout this article.

Servlet Request & Response Model

Servlets use classes and interfaces from two packages: javax.servlet and javax.servlet.http.

The javax.servlet package contains classes to support generic, protocol-independent servlets.

The classes in the javax.servlet.http package to add HTTPspecific functionality extend these

classes. The top-level package name is javax instead of the familiar java, to indicate that the

Servlet API is a standard extension. Every servlet must implement the javax.servlet.Servlet

interface. Most servlets implement it by extending one of two special classes:

javax.servlet.GenericServlet or javax.servlet.http.HttpServlet. A protocol-independent servlet

should subclass GenericServlet, while an HTTP servlet should subclass HttpServlet, which is

itself a subclass of GenericServlet with added HTTP-specific functionality. Each time the

Page 33: J2EE Handout

J2EE

©Copyright 2004, Cognizant Academy, All Rights Reserved 33

server dispatches a request to a servlet, it invokes the servlet’s service () method. A generic

servlet should override its service () method to handle requests as appropriate for the servlet.

The service () method accepts two parameters: a request object and a response object. The

request object tells the servlet about the request, while the response object is used to return a

response. Figure shows how a generic servlet handles requests.

In contrast, an HTTP servlet usually does not override the service () method. Instead, it

overrides doGet () to handle GET requests and doPost () to handle POST requests. An HTTP

servlet can override either or both of these methods, depending on the type of requests it

needs to handle. The service () method of HttpServlet handles the setup and dispatching to

all the doXXX () methods, which is why it usually should not be overridden. Figure shows how

an HTTP servlet handles GET and POST requests.

An HTTP servlet can override the doPut () and doDelete () methods to handle PUT and

DELETE requests, respectively. However, HTTP servlets generally don’t touch doHead (),

doTrace (), or doOptions (). For these, the default implementations are almost always

sufficient.

Using the HttpServletRequest and HttpServletResponse Object

These are Java classes from the Java servlet API that allow the servlet programmer to

interact with HTTP requests and responses. They're instantiated and used in doGet or doPost

Page 34: J2EE Handout

J2EE

©Copyright 2004, Cognizant Academy, All Rights Reserved 34

methods, and they provide a variety of methods for accessing and manipulating HTTP

headers, attributes, URL parameters, etc.

An example of how these objects get instantiated in a doGet method is below:

public void doGet(HttpServletRequest request,

HttpServletResponse response)

Below are some examples of the most commonly used methods of the HttpServletRequest

and HttpServletResponse classes. (The naming conventions used for the HttpServletRequest

and HttpServletResponse objects below are standard practice. If desired, object instances

can be renamed, such res and req.

q response.getWriter()

This method returns a PrintWriter object, which is used for your response to the client. Once

PrintWriter out = response.getWriter(); is used, out.println("lt;HTMLgt;"); ..

out.println("lt;/HTMLgt;"); can be used.

q request.getParameter()

This following example shows how to assign the value of a request parameter named

parName to a string named parValue using the getParameter method.

String parValue = request.getParameter("parName").

The value in parValue is the string representation of the parameter associated to parName or

is null if parName does not exist. In the case of multiple values associated with the name, the

first value is returned. To obtain all of the values in undetermined order, use the String[]

getParameterValues("parName").

q response.setContentType()

How does the client know what to do with the returned output? The Internet is used to

transport thousands of different flavors of information. The client is given a hint by setting an

attribute of the output, namely its content type. HTML has a content type of text/html, normal

text text/plain and plain binary data application/octet-stream. The list of possible attributes is

known as MIME types.

To tell the client that the output is to be treated as HTML, the following object should be used:

response.setContentType("text/html")

The browser would then attempt to render the page accordingly.

Writing a simple Servlet

import java.io.*; import javax.servlet.*; import javax.servlet.http.*; public class HelloWorld extends HttpServlet { public String getServletInfo() { return "A simple Hello World Servlet by Andy Bailey"; }

Page 35: J2EE Handout

J2EE

©Copyright 2004, Cognizant Academy, All Rights Reserved 35

public void doGet(HttpServletRequest req, HttpServletResponse resp)

throws ServletException, IOException { resp.setContentType("text/html"); PrintWriter out = resp.getWriter(); out.println("lt;HTMLgt;"); out.println("lt;HEADgt;lt;TITLEgt;HelloWorld

Outputlt;/TITLEgt;lt;/HEADgt;"); out.println("lt;BODYgt;"); out.println("lt;H1gt;Hello World!lt;/H1gt;"); out.println("lt;/BODYgt;"); out.println("lt;/HTMLgt;"); out.close(); }

}

Here is a quick review of the previous material.

q The init method is used to pass parameters to the servlet when it is first loaded

into the servlet engine. This method allows flexibility to be built into the servlet.

q The HTTP protocol allows for the transport of data to the client in many different

flavors. The "flavor" of the response tells the browser what it should do with the

content that is sent as part of the response.

q Specifically, resp.setContentType("text/html"); sets the MIME type of the

response content (hence setContentType) to the standard text/html type, which

tells the browser to render the content as HTML. If the content type is changed to

text/plain, the browser will show the content as is. If the type to application/octet-

stream is changed, the browser will open a "Save As" dialog box to download and

save the text as a file on the user's computer.

q PrintWriter out = resp.getWriter(); simply creates an object for writing things back

to the client.

Complex Example

In this example, two types of request will be served, namely the request for a simple page

with a form in it via a GET request and process the form with some simple validation via a

POST request. The methods doGet and doPost are both implemented in the code below.

By passing the servlet two parameters, errorMsg and niceMsg, the servlet will be more

flexible with the messages that are passed back to the client as a result of the validation. The

way in which the init parameters are picked up is illustrated in the init method of this example.

There is also a helper method, createForm, used to remove the form generation away from

the actual request methods. It is used by both of the request methods to generate the form.

import java.io.*; import javax.servlet.*; import javax.servlet.http.*; public class FormServlet extends HttpServlet { private String errorMsg =

Page 36: J2EE Handout

J2EE

©Copyright 2004, Cognizant Academy, All Rights Reserved 36

"You need to fill in the required Field!!!"; private String beNice =

“The form was filled in correctly, thank you for calling.";

public void init(ServletConfig config) throws ServletException, UnavailableException { String tmp = config.getInitParameter("errorMsg"); if(tmp != null) { errorMsg = tmp; } tmp = config.getInitParameter("niceMsg"); if(tmp != null) { beNice = tmp; } } public void destroy() { // although I don't actually need to clear anything up here // this is the method to do it in. } public void doGet(HttpServletRequest req,HttpServletResponse resp) throws ServletException, IOException { resp.setContentType("text/html"); PrintWriter out = resp.getWriter(); out.println(""); out.println(""); out.println(createForm("", "", "")); out.println(""): }

Servlet life cycle

The servlet life cycle is highly flexible. Servers have significant leeway in how they choose to

support servlets. The only hard and fast rule is that a servlet engine must conform to the

following life cycle contract:

q Create and initialize the servlet.

q Handle zero or more service calls from clients.

q Destroy the servlet and then garbage collects it.

It’s perfectly legal for a servlet to be loaded, created, and instantiated in its own JVM, only to

be destroyed and garbage collected without handling any client requests or after handling just

one request. Why not use a constructor instead? Well, in JDK 1.0 (for which servlets were

originally written), constructors for dynamically loaded Java classes (such as servlets)

couldn’t accept arguments. So, in order to provide a new servlet any information about itself

and its environment, a server had to call a servlet’s init () method and pass along an object

those implements the ServletConfig interface. Also, Java doesn’t allow interfaces to declare

constructors. This means that the javax.servlet. Servlet interface cannot declare a constructor

that accepts a ServletConfig parameter. It has to declare another method, like init (). It’s still

Page 37: J2EE Handout

J2EE

©Copyright 2004, Cognizant Academy, All Rights Reserved 37

possible, of course, for you to define constructors for your servlets, but in the constructor you

don’t have access to the ServletConfig object or the ability to throw a ServletException. This

ServletConfig object supplies a servlet with information about its initialization (init)

parameters. These parameters are given to the servlet itself and are not associated with any

single request. They can specify initial values, such as where a counter should begin

counting, or default values, perhaps a template to use when not specified by the request.

The server calls a servlet’s destroy () method when the servlet is about to be unloaded. In the

destroy () method, a servlet should free any resources it has acquired that will not be garbage

collected. The destroy () method also gives a servlet a chance to write out its unsaved cached

information or any persistent information that should be read during the next call to init ().

Web.xml configuration

Servlets are the pure Java solution to handle web requests. Many application will use servlets

instead of JSP and others will use servlets in conjunction with JSP. Experienced JSP

programmers use servlets in conjunction with JSP to create clearer and simpler applications.

The servlets handle Java processing: form handing, calculation and database queries. JSP

formats the results. Servlets belong in WEB-INF/classes. WEB-INF/classes is the standard

location for servlets and other Java classes

For a simple servlet “HelloServlet” at location

“WEB-INF/classes/test/ “ looks as

WEB-INF/classes/test/HelloServlet.java

package test; import java.io.*; import javax.servlet.http.*; import javax.servlet.*; public class HelloServlet extends HttpServlet { public void doGet (HttpServletRequest req, HttpServletResponse res) throws ServletException, IOException { PrintWriter out = res.getWriter(); out.println("Hello, world!"); out.close(); }

}

Configuration for the servlet is in the WEB-INF/web.xml file.

The servlet needs to be configured and it needs to be mapped to a URL. The <servlet> tag

configures the servlet. In our simple example, we just need to specify the class name for the

servlet.

Page 38: J2EE Handout

J2EE

©Copyright 2004, Cognizant Academy, All Rights Reserved 38

The <servlet-mapping> tag specifies the URLs which will invoke the servlet. In our case, say

the /hello URL invokes the servlet. Web.xml configuration file lookslike this for our example.

WEB-INF/web.xml

<web-app xmlns="http://caucho.com/ns/resin"> <servlet> <servlet-name>hello</servlet-name> <servlet-class>test.HelloServlet</servlet-class> </servlet> <servlet-mapping> <servlet-name>hello</servlet-name> <url-pattern>/hello</url-pattern> </servlet-mapping>

</web-app>

Servlet scope objects

Servlets persist between requests as object instances. In other words, at the time the code for

a servlet is loaded, the server creates a single class instance. That single instance handles

every request made of the servlet. This improves performance in three ways:

q It keeps the memory footprint small.

q It eliminates the object creation overhead that would otherwise be necessary to

create a new servlet object. A servlet can be already loaded in a virtual machine

when a request comes in, letting it begin executing right away.

q It enables persistence. A servlet can have already loaded anything it’s likely to

need during the handling of a request. For example, a database connection can

be opened once and used repeatedly thereafter. It can even be used by a group

of servlets.

Another example is a shopping cart servlet that loads in memory the price list along with

information about its recently connected clients. Yet another servlet may choose to cache

entire pages of output to save time if it receives the same request again. Not only do servlets

persist between requests, but also so do any threads created by servlets. This perhaps isn’t

useful for the run-of-the-mill servlet, but it opens up.

Servlet request, Servlet response: Status, Header, Body.

HTTP is a simple, stateless protocol. A client, such as a web browser, makes a request, the

web server responds, and the transaction is done. When the client sends a request, the first

thing it specifies is an HTTP command, called a method, that tells the server the type of

action it wants performed. This first line of the request also specifies the address of a

document (a URL) and the version of the HTTP protocol it is using.

For example:

GET /intro.html HTTP/1.0

This request uses the GET method to ask for the document named intro.html, using HTTP

Version 1.0. After sending the request, the client can send optional header information to tell

Page 39: J2EE Handout

J2EE

©Copyright 2004, Cognizant Academy, All Rights Reserved 39

the server extra information about the request, such as what software the client is running and

what content types it understands. This information doesn’t directly pertain to what was

requested, but the server in generating its response could use it. Here are some sample

request headers:

User-Agent: Mozilla/4.0 (compatible; MSIE 4.0; Windows 95)

Accept: image/gif, image/jpeg, text/*, */*

The User-Agent header provides information about the client software, while the Accept

header specifies the media (MIME) types that the client prefers to accept. After the headers,

the client sends a blank line, to indicate the end of the header section. The client can also

send additional data, if appropriate for the method being used, as it is with the POST method.

If the request doesn’t send any data, it ends with an empty line. After the client sends the

request, the server processes it and sends back a response. The first line of the response is a

status line that specifies the version of the HTTP protocol the server is using, a status code,

and a description of the status code.

For example:

HTTP/1.0 200 OK

This status line includes a status code of 200, which indicates that the request was

successful, hence the description “OK”. Another common status code is 404, with the

description “Not Found”—as you can guess, this means that the requested document was not

found. After the status line, the server sends response headers that tell the client things like

what software the server is running and the content type of the server’s response.

For example:

Date: Saturday, 23-May-98 03:25:12 GMT

Server: JavaWebServer/1.1.1

MIME-version: 1.0

Content-type: text/html

Content-length: 1029

Last-modified: Thursday, 7-May-98 12:15:35 GMT

The Server header provides information about the server software, while the Content-type

header specifies the MIME type of the data included with the response. The server sends a

blank line after the headers, to conclude the header section. If the request was successful,

the requested data is then sent as part of the response. Otherwise, the response may contain

human-readable data that explains why the server couldn’t fulfill the request.

GET and POST

When a client connects to a server and makes an HTTP request, the request can be of

several different types, called methods. The most frequently used methods are GET and

POST. Put simply, the GET method is designed for getting information (a document, a chart,

or the results from a database query), while the POST method is designed for posting

information (a credit card number, some new chart data, or information that is to be stored in

a database). To use a bulletin board analogy, GET is for reading and POST is for tacking up

new material. The GET method, although it’s designed for reading information, can include as

part of the request some of its own information that better describes what to get—such as an

x, y scale for a dynamically created chart. This information is passed as a sequence of

characters appended to the request URL in what’s called a query string. Placing the extra

Page 40: J2EE Handout

J2EE

©Copyright 2004, Cognizant Academy, All Rights Reserved 40

information in the URL in this way allows the page to be book marked or emailed like any

other. Because GET requests theoretically shouldn’t need to send large amounts of

information, some servers limit the length of URLs and query strings to about 240 characters.

The POST method uses a different technique to send information to the server because in

some cases it may need to send megabytes of information. A POST request passes all its

data, of unlimited length, directly over the socket connection as part of its HTTP request body.

The exchange is invisible to the client. The URL doesn’t change at all. Consequently, POST

requests cannot be book marked or emailed or, in some cases, even reloaded. That’s by

design— information sent to the server, such as your credit card number, should be sent only

once. In practice, the use of GET and POST has strayed from the original intent. It’s common

for long parameterized requests for information to use POST instead of GET to work around

problems with overly long URLs. It’s also common for simple forms that upload information to

use GET because, well—why not, it works! Generally, this isn’t much of a problem. Just

remember that GET requests, because they can be book marked so easily, should not be

allowed to cause damage for which the client could be held responsible. In other words, GET

requests should not be used to place an order, update a database, or take an explicit client

action in any way.

Other Methods

In addition to GET and POST, there are several other lesser-used HTTP methods. There’s

the HEAD method, which is sent by a client when it wants to see only the headers of the

response, to determine the document’s size, modification time, or general availability. There’s

also PUT, to place documents directly on the server, and DELETE, to do just the opposite.

These last two aren’t widely supported due to complicated policy issues. The TRACE method

is used as a debugging aid—it returns to the client the exact contents of its request. Finally,

the OPTIONS method can be used to ask the server which methods it supports or what

options are available for a particular resource on the server.

Session

Many applications require a series of requests from a client to be associated with one

another. For example, the Duke's Bookstore application saves the state of a user's shopping

cart across requests. Web-based applications are responsible for maintaining such state,

called a session, because the HTTP protocol is stateless. To support applications that need to

maintain state, Java Servlet technology provides an API for managing sessions and allows

several mechanisms for implementing sessions.

Accessing a Session

Sessions are represented by an HttpSession object. You access a session by calling the

getSession method of a request object. This method returns the current session associated

with this request, or, if the request does not have a session, it creates one. Since getSession

may modify the response header (if cookies are the session tracking mechanism), it needs to

be called before you retrieve a PrintWriter or ServletOutputStream.

Associating Attributes with a Session

You can associate object-valued attributes with a session by name. Such attributes are

accessible by any Web component that belongs to the same Web context and is handling a

request that is part of the same session.

Page 41: J2EE Handout

J2EE

©Copyright 2004, Cognizant Academy, All Rights Reserved 41

For example say, The Duke's Bookstore application stores a customer's shopping cart as a

session attribute. This allows the shopping cart to be saved between requests and also allows

cooperating servlets to access the cart. CatalogServlet adds items to the cart;

ShowCartServlet displays, deletes items from, and clears the cart; and CashierServlet

retrieves the total cost of the books in the cart.

public class CashierServlet extends HttpServlet { public void doGet (HttpServletRequest request, HttpServletResponse response) throws ServletException, IOException { // Get the user's session and shopping cart HttpSession session = request.getSession(); ShoppingCart cart = (ShoppingCart)session. getAttribute("cart"); ... // Determine the total price of the user's books double total = cart.getTotal();

Session Management

Since there is no way for an HTTP client to signal that it no longer needs a session, each

session has an associated timeout so that its resources can be reclaimed. The timeout period

can be accessed with a session's [get|set]MaxInactiveInterval methods. You can also set the

time-out period in deploy tool:

q Select the WAR.

q Select the General tab.

q Enter the time-out period in the Advanced box.

q Or can make setting in Web.xml file as:

<web-app> <display-name>Your application name</display-

name> <description>Your application description</description>

<session-config> <session-timeout>60</session-timeout> </session-config> </web-app>

To ensure that an active session is not timed out, you should periodically access the session

via service methods because this resets the session's time-to-live counter.

When a particular client interaction is finished, you use the session's invalidate method to

invalidate a session on the server side and remove any session data.

Page 42: J2EE Handout

J2EE

©Copyright 2004, Cognizant Academy, All Rights Reserved 42

Carrying forward a Request

Overview

Servlet API provides us functionality of carrying a request forward to another page r servlet

with the RequestDispatcher interface. This interface has just two methods, forward() and

include() which do pretty much what their names suggest.

In this article we will learn how to pass control from one Servlet to another using

RequestDispatcher.forward() method and how to include response from another Servlet

within the caller Servlet using RequestDispatcher.include() method.

RequestDispatcher Interface

This interface is present in the javax.servlet package and contains only following two

methods:

q forward(ServletRequest request, ServletResponse response) Forwards a request

to another resource on the same server. That resource can be a Servlet, JSP

page or a simple HTML page.

q include(ServletRequest request, ServletResponse response) Works like a server-

side include ( SSI ) and includes the response from the given resource ( Servlet,

JSP page, HTML page ) within the caller response.

Getting a reference to RequestDispatcher Interface ?

In order to use forward() or include() methods we discussed above we will have to get a

reference to RequestDispatcher interface. There are two ways you can do this:

q ServletContext.getRequestDispatcher(String resource)

q ServletRequest.getRequestDispatcher(String resource)

If your Servlet is extending HttpServletRequest then you can simply call

getRequestDispatcher(String resource) to get reference to the RequestDispatcher object for

the given resource. This is what we will do in the demo application later.

// req is HttpServletRequest object RequestDispatcher rd; rd = req.getRequestDispatcher("pathToServlet"); rd.forward(req, res);

Or you can use ServletContext's getRequestDispatcher(String resource) to do the same.

RequestDispatcher rd; rd = getServletContext().getRequestDispatcher("pathToServlet"); rd.forward(req, res);

Page 43: J2EE Handout

J2EE

©Copyright 2004, Cognizant Academy, All Rights Reserved 43

Having learned the theory about including and forwarding response using RequestDispatcher

interface, it is time now that we build some demo application and demonstrate the use of

these methods. We will also be learning one more thing which is setting and getting attributes

from HttpServletRequest object.

RequestDispatcher Demo Application

Our demo application will consist of two Servlets. First Servlet will call forward() and include()

methods to display response from second Servlet. To demonstrate the use of

HttpServletRequest attributes, we will set an attribute in the first Servlet and display at

attribute from within the second Servlet.

TestDispatcherServlet1

package com.stardeveloper.servlets; import java.io.*; import javax.servlet.*; import javax.servlet.http.*; public class TestDispatcherServlet1 extends HttpServlet { private static final String forwardTo = "/servlet/com.stardeveloper.servlets." + "TestDispatcherServlet2"; private static final String includeIn = "/servlet/com.stardeveloper.servlets." + "TestDispatcherServlet2"; public void doGet(HttpServletRequest req, HttpServletResponse res) throws ServletException, IOException { res.setContentType("text/html"); PrintWriter out = res.getWriter(); out.print("<html><head><style>"); out.print("p,form{font-family:tahoma;font-size:10pt;}"); out.print("input{width:20;height:20;}"); out.print("</style></head><body>"); // Displaying Form out.print("<form action=\""); out.print( req.getRequestURI() ); out.print("\" method=\"post\">"); out.print("<input type=\"hidden\" name=\"mode\" "); out.print("value=\"forward\">"); out.print("<input type=\"submit\" value=\" \""); out.print("> "); out.print(" Forward to another Servlet .."); out.print("</form>"); out.print("<form action=\""); out.print( req.getRequestURI() );

Page 44: J2EE Handout

J2EE

©Copyright 2004, Cognizant Academy, All Rights Reserved 44

out.print("\" method=\"post\">"); out.print("<input type=\"hidden\" name=\"mode\" "); out.print("value=\"include\">"); out.print("<input type=\"submit\" "); out.print("value=\" \"> "); out.print(" Include another Servlet .."); out.print("</form>"); out.print("</body></html>"); out.close(); } public void doPost(HttpServletRequest req, HttpServletResponse res) throws ServletException, IOException { String mode = req.getParameter("mode"); // Forwarding to Servlet2 if(mode != null && mode.equals("forward")) { req.setAttribute("mode", "Forwarding Response.."); req.getRequestDispatcher(forwardTo).forward(req, res); } // Including response from Servlet2 if(mode != null && mode.equals("include")) { req.setAttribute("mode", "IncludingResponse.."); req.getRequestDispatcher(includeIn).include(req, res); } } }

Explanation

Our Servlet above extends HttpServlet class and overrides doGet() and doPost() methods.

We also declare two variables forwardTo and includeIn which point to the path of the second

Servlet. For this example they both point to same Servlet.

In doGet() we display a Form to the user giving the option to either test the forward() method

or the include() method. To determine user clicked which button we provide a hidden input

field with name of 'mode' and a value of 'forward' (for forwarding) or 'include' (for

including).We handle the user response in our doPost() method and depending on the type of

button clicked we either forward the request to the second Servlet or include it's response in

the first Servlet.

Page 45: J2EE Handout

J2EE

©Copyright 2004, Cognizant Academy, All Rights Reserved 45

We also set the attribute "mode" in the HttpServletRequest object to a value depending on

which button user clicked, which can be displayed on the next page by accessing the value

from the request object.

Form-Servlet Integration

Constructing a form is far less intimidating that it may appear at first. If you've already set up

web pages using HTML, then you'll move naturally into setting up forms, which are also

written using HTML tags embedded right in an ordinary HTML page.

Example form

Enter your name: Test this form

Here's the source HTML for the above form:

< FORM METHOD=POST ACTION="http://www.yahoo.com/cgi-bin/form" > Enter your name: < INPUT NAME=your_name > < INPUT TYPE=submit VALUE="Test this form" > < /FORM >

Let's take a close look at each of the elements of this form.

The FORM tag - Opening and Closing a Form

<FORM METHOD=POST ACTION="[name of program]"> </FORM>

These tags start and end a form (all input fields of the form are placed between these two

tags). METHOD specifies which technical protocol the web server will use to pass the form

data to the program which processes it (always set it to POST), and ACTION tells the server

exactly which program that is. Note: POST must be capitalized; otherwise the method

defaults to "GET".

In our example, the action is a program is the Yahoo Forms Processor. In this case we

configured it just say hello and echo the name you entered. Most or all of your forms in your

Yahoo account will point to http://www.yahoo.com/cgi-bin/form - the WebCom form processor,

a program which reads a configuration file you set up in your directory in which you define

how you want the form data to be formatted and routed, what to display to the user after they

submit the form, etc. (the configuration file is optional - if you don't have one the form

processor simply emails the contents of the form to you (the name and value of each field on

the form when the user submitted it)).

A web page (i.e., an HTML document) may include multiple forms; however, forms may not

be nested (you cannot create a form within a form). You must end the current form with <

/FORM > before you can start a new form.

Page 46: J2EE Handout

J2EE

©Copyright 2004, Cognizant Academy, All Rights Reserved 46

Getting a line of text from the user

Enter your name: <INPUT NAME=your_name>

The above code creates the text input box for the user's name in our example form. Most form

fields begin with < INPUT NAME=[field_name] and end with > . NAME defines the name of

the data for the field; it's how the program which processes the form references the data from

this field.

You can pick any name for your fields, just make sure it is not one of the pre-defined Form-

parameters. These variables, when set to have values, perform certain specialized tasks. For

instance, one of the most common errors in creating forms is to have an input field ask for a

client's email address, and using the variable email to store the address in. The word 'email',

however, is one of the predefined parameters. Giving email a value tells the Forms Processor

to send the form's results to that address, which is usually not what is intended.

You also want to be careful to use only letters, numbers, and underscores in your field

names. The HTML standard allows other symbols other than letters, numbers, and

underscores to be used in a field name but the Yahoo form processor will not recognize such

field names (and it's good practice to stick with letters, numbers and underscores for

readability). TYPE defines the various types of input fields recognized in the current HTML

specification (text, radio, checkbox, password, or submit), which we'll look at a little later.

The text input type creates what user interface designers call a single line edit, an input field

which allows the user to enter and/or edit a single line of text. This is the type of field we used

in our sample form. We did not have to say TYPE=text because that is the default type, but

we could just as well have coded the field as follows with the same result:

Enter your name: <INPUT TYPE=text NAME=your_name>

Some other things we can do with a text input field are defining an initial value for the field,

and make it longer (or shorter):

Enter your name: <INPUT TYPE=text NAME=your_name SIZE=50 VALUE="Joe Schmoe" >

Enter your name:

Joe Schmoe Test this form

Note that the user could still type more than 50 characters in the above field, the browser just

scrolls the text in the window. You can also limit the length of the text input by the user by

including a MAXLENGTH=nn in the INPUT field definition.

Enter your name: <INPUT TYPE=text NAME=your_name SIZE=50 VALUE="Joe Schmoe" MAXLENGTH=50>

Page 47: J2EE Handout

J2EE

©Copyright 2004, Cognizant Academy, All Rights Reserved 47

The Submit Button

<INPUT TYPE=submit VALUE="Test this form">

Each form must have exactly one field of type submit. This creates the button the user pushes

when they're done filling out a form, and should come after all the other input fields. If a form

doesn't have a submit button, it is useless since once the user finishes typing in the data they

won't have anyway of sending it to a server. You can put whatever words you like on the

submit button, using the VALUE keyword. If you omit the VALUE keyword, the button will be

labeled "Submit".

When the user clicks the submit button, the browser collects the values of each of the input

fields (text typed by the user, etc.) and sends them to the web server identified in the ACTION

keyword of the FORM open tag (and that web server passes that data to the program

identified in the ACTION, using the METHOD specified).

You may at some point get the urge to create a form with two or more submit buttons, each of

which you'd like to perform a different task (say one to subscribe to a mailing list, and another

to unsubscribe. This is a natural inclination, but unfortunately you can't do it with the current

WWW standards. Sometimes you can simulate this behavior by having multiple forms on one

page, each with its own submit button (and perhaps nothing else). But if you associate

multiple submit buttons with the same input fields by putting them on the same form (that is,

between the same FORM tags), all the submit buttons will do exactly the same thing (namely

pass the data of that form to the program identified by the ACTION identifier).

SUMMARY

After completing this chapter, you have learned:

q Servlet Architecture

q Know Servlet lifecycle and how to write Servlet

q Know Web.xml Configuration

q Understand Servlet scope and Session

Page 48: J2EE Handout

J2EE

©Copyright 2004, Cognizant Academy, All Rights Reserved 48

Chapter 4: JSP

Learning Objectives

After completing this chapter, you will be able to:

q Learn the basic syntax of JSP and predefined variables

q Understand JSP Page Lifecycle

q Know a brief overview of JAVABEANS

q Create your own customized tags

Introduction

In the J2EE suite of specifications that includes Servlets, JavaServer Pages (JSP), the Java

Naming and Directory Interface (JNDI), Enterprise JavaBeans (EJB), and so forth, the JSP is

a web-tier specification that supplements the Servlet specification and is useful in the

development of web interfaces for enterprise applications.

JSP is a technology that combines the HTML/XML markup languages and elements of the

Java programming language to return dynamic content to a web client. For this reason, it is

commonly used to handle the presentation logic of a web application, although the JSP pages

may also contain business logic.

Understanding the need for JSP

What is needed, clearly, is an industry-wide solution for creating pages with dynamically

generated content. This solution should address the limitations of current alternatives by:

q Working on any web or application server

q Separating the application logic from the appearance of the page

q Allowing fast development and testing

q Simplifying the process of developing interactive web-based applications

The Java Server Pages (JSP) technology was designed to fit this need. The JSP specification

is the result of extensive industry cooperation between vendors of web servers, application

servers, transactional systems, and development tools. Sun Microsystems developed the

specification to integrate with and leverage existing expertise and tools support for the Java

programming environment, such as Java Servlets and JavaBeans. The result is a new

approach to developing web-based applications that extends powerful capabilities to page

designers using component-based application logic.

Advantages of JSP over other technology

q vs. Active Server Pages (ASP). ASP is a similar technology from Microsoft. The

advantages of JSP are twofold. First, the dynamic part is written in Java, not

Visual Basic or other MS-specific language, so it is more powerful and easier to

Page 49: J2EE Handout

J2EE

©Copyright 2004, Cognizant Academy, All Rights Reserved 49

use. Second, it is portable to other operating systems and non-Microsoft Web

servers.

q vs. Pure Servlets. JSP doesn't give you anything that you couldn't in principle do

with a servlet. But it is more convenient to write (and to modify!) regular HTML

than to have a zillion println statements that generate the HTML. Plus, by

separating the look from the content you can put different people on different

tasks: your Web page design experts can build the HTML, leaving places for your

servlet programmers to insert the dynamic content.

q vs. Server-Side Includes (SSI). SSI is a widely supported technology for

including externally defined pieces into a static Web page. JSP is better because

it lets you use servlets instead of a separate program to generate that dynamic

part. Besides, SSI is really only intended for simple inclusions, not for "real"

programs that use form data, make database connections, and the like.

q vs. JavaScript. JavaScript can generate HTML dynamically on the client. This is

a useful capability, but only handles situations where the dynamic information is

based on the client's environment. With the exception of cookies, HTTP and form

submission data is not available to JavaScript. And, since it runs on the client,

JavaScript can't access server-side resources like databases, catalogs, pricing

information, and the like.

q vs. Static HTML. Regular HTML, of course, cannot contain dynamic information.

JSP is so easy and convenient that it is quite feasible to augment HTML pages

that only benefit marginally by the insertion of small amounts of dynamic data.

Previously, the cost of using dynamic data would preclude its use in all but the

most valuable instances.

The JavaServer Pages Technology Approach to Web Application Development

In developing the JSP specification, Sun Microsystems worked with a number of leading web

server, application server and development tool vendors, as well as a diverse and

experienced development community. The result is an approach that balances portability with

ease-of-use for application and page developers.

JSP technology speeds the development of dynamic web pages in a number of ways:

Separating content generation from presentation

Using JSP technology, web page developers use HTML or XML tags to design and format the

results page. They use JSP tags or scriptlets to generate the dynamic content (the content

that changes according to the request, such as requested account information or the price of

a specific bottle of wine). The logic that generates the content is encapsulated in tags and

JavaBeans components and tied together in scriptlets, all of which are executed on the server

side. If the core logic is encapsulated in tags and beans, then other individuals, such as web

masters and page designers, can edit the JSP page without affecting the generation of the

content.

Page 50: J2EE Handout

J2EE

©Copyright 2004, Cognizant Academy, All Rights Reserved 50

On the server, a JSP engine interprets JSP tags and scriptlets, generates content (for

example, by accessing JavaBeans components, accessing a database with JDBCTM

technology, or including files), and sends the results back in the form of an HTML (or XML)

page to the browser. This helps authors protect proprietary code while ensuring complete

portability for any HTML-based web browser.

Emphasizing reusable components

Most JSP pages rely on reusable, cross-platform components (JavaBeans or Enterprise

JavaBeansTM

components) to perform the more complex processing required of the

application. Developers can share and exchange components that perform common

operations, or make them available to larger user or customer communities. The component-

based approach speeds overall development and lets organizations leverage their existing

expertise and development efforts for optimal results

.

Simplifying page development with tags

Web page developers are not always programmers familiar with scripting languages. The

JavaServer Pages technology encapsulates much of the functionality required for dynamic

content generation in easy-to-use, JSP-specific XML tags. Standard JSP tags can access and

instantiate JavaBeans components, set or retrieve bean attributes, download applets, and

perform other functions that are otherwise more difficult and time-consuming to code.

The JSP technology is extensible through the development of customized tag libraries. Over

time, third-party developers and others will create their own tag libraries for common

functions. This lets web page developers work with familiar tools and constructs, such as

tags, to perform sophisticated functions

Understand the JSP environment.

The JSP runs on a Web or an App server within a ‘Container’ or a ‘Web Cartridge’. The job of

a container is to provide the JSP its life cycle (Loading, Initialization, Execution, Destroying).

Each container can handle a single or a group of related JSPs in a web application. When,

the JSP container loads a JSP for the first time (which is typically associated with the JSP

being accessed the first time), the servlet code necessary to fulfill the JSP tags is

automatically generated, compiled, and loaded. The static portions of the HTML page are

produced by sending static String objects to write (). The dynamic portions are included

directly into the servlet. From then on, as long as the JSP source for the page is not modified,

it behaves as if it were a static HTML page with associated servlets (all the HTML code is

actually generated by the servlet), however, If you modify the source code for the JSP, it is

automatically recompiled and reloaded the next time that page is requested. Of course,

because this you’ll see a lag in response for the first-time a JSP is accessed. However, since

a JSP is usually used much more than it is changed, you will normally not be affected by this

delay.

Page 51: J2EE Handout

J2EE

©Copyright 2004, Cognizant Academy, All Rights Reserved 51

Learning the Basic Syntax

What Does a JSP Page Look Like?

A JSP page looks like a standard HTML or XML page, with additional elements that the JSP

engine processes and strips out. Typically, the JSP elements create text that is inserted into

the results page.

The JSP technology is best described using an example. The following JSP page is very

simple; it prints the day of the month and the year, and welcomes you with either "Good

Morning" or "Good Afternoon," depending on the time of day.

The page combines ordinary HTML with a number of JSP elements:

q Calls to a clock JavaBean component

q An inclusion of an external file (for copyright information)

q JSP expressions and scriptlets

<HTML> <%@ page language=="java" imports=="com.wombat.JSP.*" %> <H1>Welcome</H1> <P>Today is </P> <jsp:useBean id=="clock" class=="calendar.jspCalendar" /> <UL> <LI>Day: <%==clock.getDayOfMonth() %> <LI>Year: <%==clock.getYear() %> </UL> <% if (Calendar.getInstance().get(Calendar.AM_PM) ==== Calendar.AM) { %> Good Morning <% } else { %> Good Afternoon <% } %> <%@ include file=="copyright.html" %> </HTML>

The page includes the following components:

q A JSP directive passes information to the JSP engine. In this case, the first line

indicates the location of some Java programming language extensions to be

accessible from this page. Directives are enclosed in <%@ and %> markers.

q Fixed template data: Any tags that the JSP engine does not recognize it passes

on with the results page. Typically, these will be HTML or XML tags. This includes

the Unordered List and H1 tags in the example above.

q JSP actions, or tags: These are typically implemented as standard tags or

customized tags, and have an XML tag syntax. In the example, the jsp:useBean

tag instantiates the Clock JavaBean on the server.

q An expression: The JSP engine evaluates anything between <%== and %>

markers. In the List Items above, the values of the Day and Year attributes of the

Clock bean are returned as a string and inserted as output in the JSP file. In the

Page 52: J2EE Handout

J2EE

©Copyright 2004, Cognizant Academy, All Rights Reserved 52

example above, the first list item will be the day of the year, and the second item

the year.

q A scriptlet is a small script that performs functions not supported by tags or ties

everything together. The native scripting language for JSP 1.0 software is based

on the Java programming language. The scriptlet in the above sample

determines whether it is AM or PM and greets the user accordingly (for daytime

users, at any rate).

The example may be trivial, but the technology is not. Businesses can encapsulate critical

processing in server-side Beans, and web developers can easily access that information,

using familiar syntax and tools. Java-based scriptlets provide a flexible way to perform other

functions, without requiring extensive scripting. The page as a whole is legible and

comprehensible, making it easier to spot or prevent problems and to share work.

JSP Syntax Elements.

Learn JAVA Scripting Element

JSP scripting elements let you insert code into the servlet that will be generated from the JSP

page. There are three forms:

q Expressions of the form <%= expression %>, which are evaluated and inserted

into the servlet’s output

q Scriptlets of the form <% code %>, which are inserted into the servlet’s

jspService method (called by service)

q Declarations of the form <%! code %>, which are inserted into the body of the

servlet class, outside of any existing methods

Page 53: J2EE Handout

J2EE

©Copyright 2004, Cognizant Academy, All Rights Reserved 53

Expressions

Expressions act as placeholders for Java language expressions. This is an example of a JSP

expression:

<%= count; %>

The expression is evaluated each time the page is accessed, and its value is then embedded

in the output HTML. Instead of incrementing the count variable in a scriptlet, we could have

incremented it in the expression itself:

A JSP expression always starts with <%= and ends with %>. Unlike variable declarations,

expressions must not be terminated with a semicolon. Thus, the following is not valid:

<%= count; %>

We can print the value of any object or any primitive data type (int, boolean, char, etc.) to the

output stream using an expression. We can also print the value of any arithmetic or Boolean

expression or a value returned by a method call. The exam may ask you to identify valid JSP

expressions. Tables 11.2 and 11.3 contain some examples of valid and invalid JSP

expressions based on the following declarations:

Page 54: J2EE Handout

J2EE

©Copyright 2004, Cognizant Academy, All Rights Reserved 54

Valid expressions

Invalid Expression

Directives

Directives provide general information about the JSP page to the JSP engine. There are three

types of directives: page, include, and taglib.

A page directive informs the engine about the overall properties of a JSP page. For example,

the following page directive informs the JSP engine that we will be using Java as the scripting

language in our JSP page:

<%@ page language="java" %>

An include directive tells the JSP engine to include the contents of another file (HTML, JSP,

etc.) in the current page. Here is an example of an include directive:

<%@ include file="copyright.html" %>

A taglib directive is used for associating a prefix with a tag library. The following is an example

of a taglib directive:

<%@ taglib prefix="test" uri="taglib.tld" %>

A directive always starts with <%@ and ends with %>. The general syntax of the three

directives is:

<%@ page attribute-list %> <%@ include attribute-list %> <%@ taglib attribute-list %>

Page 55: J2EE Handout

J2EE

©Copyright 2004, Cognizant Academy, All Rights Reserved 55

In the sample tags above, attribute-list represents one or more attribute-value pairs that are

specific to the directive. Here are some important points to remember about the syntax of the

directives:

q The tag names, their attributes, and their values are all case sensitive.

q The value must be enclosed within a pair of single or double quotes.

q A pair of single quotes is equivalent to a pair of double quotes.

q There must be no space between the equals sign (=) and the value.

Declarations

Declarations declare and define variables and methods that can be used in the JSP page.1

The following is an example of a JSP declaration:

<%! int count = 0; %>

This declares a variable named count and initializes it to 0. The variable is initialized only

once when the page is first loaded by the JSP engine, and retains its value in subsequent

client requests. That is why the count variable is not reset to 0 each time we access the page.

A declaration always starts with <%! and ends with %>. It can contain any number of valid

Java declaration statements. For example, the following tag declares a variable and a method

in a single tag:

<%! String color[] = {"red", "green", "blue"}; String getColor(int i) { return color[i%3]; } %>

We can also write the above two Java declaration statements in two JSP declaration tags:

<%! String color[] = {"red", "green", "blue"}; %> <%! String getColor(int i) { return color[i%3]; } %>

Note that since the declarations contain Java declaration statements, each variable’s

declaration statement must be terminated with a semicolon.

Page 56: J2EE Handout

J2EE

©Copyright 2004, Cognizant Academy, All Rights Reserved 56

Scriptlets

Scriptlets are Java code fragments that are embedded in the JSP page. For example,this line

from the counter.jsp is a JSP scriptlet:

<% count++; %>

The scriptlet is executed each time the page is accessed, and the count variable is

incremented with each request.

Since scriptlets can contain any Java code, they are typically used for embedding computing

logic within a JSP page. However, we can use scriptlets for printing HTML statements, too.

The following is equivalent to the code:

<%@ page language="java" %> <%! int count = 0; %> <% out.print("<html><body>"); count++; out.print("Welcome! You are visitor number " + count); out.print("</body></html>"); %>

Instead of writing normal HTML code directly in the page, we are using a scriptlet to achieve

the same effect. The variable out refers to an object of type javax.servlet.

jsp.JspWriter.

Actions

Actions are commands given to the JSP engine. They direct the engine to perform certain

tasks during the execution of a page. For example, the following line instructs the engine to

include the output of another JSP page, copyright.jsp, in the output of the current JSP page:

<jsp:include page="copyright.jsp" />

There are six standard JSP actions:

q jsp:include

q jsp:forward

q jsp:useBean

q jsp:setProperty

q jsp:getProperty

q jsp:plugin

The first two, jsp:include and jsp:forward, enable a JSP page to reuse other web

components.The next three, jsp:useBean, jsp:setProperty, and jsp:getProperty,are related to

the use of JavaBeans in JSP pages.The last action, jsp:plugin, instructs the JSP engine to

generate appropriate HTML code for embedding client-side components, such as applets.

This action is not specified in the exam objectives, and its details are beyond the scope of this

book. In addition to the six standard actions, a JSP page can have user-defined actions.

These are called custom tags.

Page 57: J2EE Handout

J2EE

©Copyright 2004, Cognizant Academy, All Rights Reserved 57

Comments

Comments do not affect the output of a JSP page in any way but are useful for documentation

purposes. The syntax of a JSP comment is:

<%-- Anything you want to be commented --%>

A JSP comment always starts with <%-- and ends with --%>.

We can comment the Java code within scriptlets and declarations by using normal Java-style

comments and the HTML portions of a page by using HTML-style comments,as shown here:

<html><body> Welcome! <%-- JSP comment --%> <% //Java comment %> <!—- HTML comment --> </body></html>

As we mentioned earlier, the exam does not cover comments, but they can be quite useful

when you’re debugging JSP pages. The JSP engine drops everything between <%-- and --

%>, so it is easy to comment out large parts of a JSP page—including nested HTML and

other JSP tags. However, remember that you cannot nest JSP comments within other JSP

comments.

Predefined Variables

To simplify code in JSP expressions and scriptlets, you are supplied with eight automatically

defined variables, sometimes called implicit objects. The available variables are request,

response, out, session, application, config, pageContext, and page. Details for each are given

below.

Request

This is the HttpServletRequest associated with the request, and lets you look at the request

parameters (via getParameter), the request type (GET, POST, HEAD, etc.), and the incoming

HTTP headers (cookies, Referer, etc.). Strictly speaking, request is allowed to be a subclass

of ServletRequest other than HttpServletRequest, if the protocol in the request is something

other than HTTP. This is almost never done in practice.

Response

This is the HttpServletResponse associated with the response to the client. Note that, since

the output stream (see out below) is buffered, it is legal to set HTTP status codes and

response headers, even though this is not permitted in regular servlets once any output has

been sent to the client.

Out

This is the PrintWriter used to send output to the client. However, in order to make the

response object useful, this is a buffered version of PrintWriter called JspWriter. Note that you

can adjust the buffer size, or even turn buffering off, through use of the buffer attribute of the

page directive.. Also note that out is used almost exclusively in scriptlets, since JSP

Page 58: J2EE Handout

J2EE

©Copyright 2004, Cognizant Academy, All Rights Reserved 58

expressions automatically get placed in the output stream, and thus rarely need to refer to out

explicitly.

Session

This is the HttpSession object associated with the request. Recall that sessions are created

automatically, so this variable is bound even if there was no incoming session reference. The

one exception is if you use the session attribute of the page directive to turn sessions off, in

which case attempts to reference the session variable cause errors at the time the JSP page

is translated into a servlet.

Application

This is the ServletContext as obtained via getServletConfig().getContext().

Config

This is the ServletConfig object for this page.

PageContext

JSP introduced a new class called PageContext to encapsulate use of server-specific

features like higher performance JspWriters. The idea is that, if you access them through this

class rather than directly, your code will still run on "regular" servlet/JSP engines.

Page

This is simply a synonym for this, and is not very useful in Java. It was created as a

placeholder for the time when the scripting language could be something other than Java.

THE JSP PAGE LIFE CYCLE

A JSP page goes through seven phases in its lifetime. These phases are called life-cycle

phases. The exam requires you to know the sequence of the phases and the activity that

takes place in each of the phases. But before we start discussing the life cycle of a JSP page,

we need to understand the two important points regarding JSP pages that are explained in

the following sections.

JSP pages are servlets

Although, structurally, a JSP page looks like an HTML page, it actually runs as a servlet. The

JSP engine parses the JSP file and creates a corresponding Java file. This file declares a

servlet class whose members map directly to the elements of the JSP file. The JSP engine

then compiles the class, loads it into memory, and executes it as it would any other servlet.

The output of this servlet is then sent to the client. Figure illustrates this process.

Page 59: J2EE Handout

J2EE

©Copyright 2004, Cognizant Academy, All Rights Reserved 59

Understanding translation units

Just as an HTML page can include the contents of other HTML pages (for example, when

using frames), a JSP page can include the contents of other JSP pages and HTML pages.

This is done with the help of the include directive.

But an important thing to remember here is that when the JSP engine generates the Java

code for a JSP page, it also inserts the contents of the included pages into the servlet that it

generates. The set of pages that is translated into a single servlet class is called a translation

unit. Some of the JSP tags affect the whole translation unit and not just the page in which

they are declared.

Keep in mind these other points regarding a translation unit:

q The page directives affect the whole translation unit.

q A variable declaration cannot occur more than once in a single translation unit.

For example, we cannot declare a variable in an included page using the include

directive if it is already declared in the including page since the two pages

constitute a single translation unit.

Page 60: J2EE Handout

J2EE

©Copyright 2004, Cognizant Academy, All Rights Reserved 60

q The standard action <jsp:useBean> cannot declare the same bean twice in a

single translation unit.

JSP life-cycle phases

You might have observed that when a JSP page is accessed for the first time, the server is

slower in responding than it is in the second, third, and subsequent accesses. This is

because, as we mentioned previously, every JSP page must be converted into an instance of

a servlet class before it can be used to service client requests. For each request, the JSP

engine checks the timestamps of the source JSP page and the corresponding servlet class

file to determine if the JSP page is new or if it has already been converted into a

UNDERSTANDING JSP

PAGE DIRECTIVE ATTRIBUTES

A page directive informs the JSP engine about the overall properties of a JSP page.This

directive applies to the entire translation unit and not just to the page in which it is declared.

Table describes the 12 possible attributes for the page directive.

Page 61: J2EE Handout

J2EE

©Copyright 2004, Cognizant Academy, All Rights Reserved 61

The import attribute

The import attribute of a page directive is similar to the import statement in a

Java class. For example, if we want to use the Date class of the package java.util, then we

have to either use the fully qualified class name in the code or import it using the page

directive. At the time of translation, the JSP engine inserts an import statement into the

generated servlet for each of the packages declared using this attribute. We can import

multiple packages in a single tag by using a comma-separated list of package names, as

shown here:

<%@ page import="java.util.*, java.io.*, java.text.*, com.mycom.*, com.mycom.util.MyClass " %>

We can also use multiple tags for readability. For example, the above page directive can also

be written as:

<%@ page import="java.util.* " %> <%@ page import="java.io.* " %>

Page 62: J2EE Handout

J2EE

©Copyright 2004, Cognizant Academy, All Rights Reserved 62

<%@ page import="java.text.* " %> <%@ page import="com.mycom.*, com.mycom.util.MyClass " %>

Since the order of import statements in a Java class does not matter, the order of import tags

shown here does not matter, either. A JSP engine always imports the java.lang.*,

javax.servlet.*, javax.servlet.jsp.*, and javax.servlet.http.* packages, so we do not have to

import them explicitly.

NOTE import is the only attribute of the page directive that can occur multiple times in a

translation unit. Duplicate values are ignored.

The session attribute

The session attribute indicates whether or not the JSP page takes part in an HTTP session.

The default value is true, in which case the JSP engine declares the implicit variable session.

If we do not want the page to participate in a session, then we have to explicitly add the

following line:

<%@ page session="false" %>

The errorPage and isErrorPage attributes

During the execution of a page, it is possible that the embedded Java code will throw

exceptions. Just as in normal Java programs, we can handle the exceptions in JSP pages

using try-catch blocks. However, the JSP specification defines a better approach, which

separates the error-handling code from the main page and thus promotes reusability of the

exception-handling mechanism. In this approach, a JSP page uses the errorPage attribute to

delegate the exception to another JSP page that has the errorhandling code

<%@ page errorPage="errorHandler.jsp" %> <html> <body> <% if (request.getParameter("name")==null) { throw new RuntimeException("Name not specified"); } %> Hello, <%=request.getParameter("name")%> </body> </html>

The above JSP page throws an exception if the parameter name is not supplied in the

request, but it does not catch the exception itself. Instead, with the help of the errorPage

attribute, it instructs the JSP engine to delegate the error handling to errorHandler.jsp. The

isErrorPage attribute conveys whether or not the current page can act as an error handler for

any other JSP page. The default value of the isErrorPage attribute is false. For example, the

errorHandler.jsp that we used in the previous example must explicitly set this attribute to true.

In this case, the JSP engine declares the implicit variable exception in the page’s servlet

class.

<%@ page isErrorPage="true" %> <html>

Page 63: J2EE Handout

J2EE

©Copyright 2004, Cognizant Academy, All Rights Reserved 63

<body> Unable to process your request: <%=exception.getMessage()%><br> Please try again. </body> </html>

Notice that this page only extracts the information from the exception and generates an

appropriate error message. Because it does not implement any business logic, it can be

reused for different JSP pages. In JSP 1.2, it is not necessary that the errorPage value be a

JSP page. It can also be a static file, such as an HTML page:

<%@ page errorPage="errorHandler.html" %>

The buffer and autoFlush attributes:

The buffer attribute specifies the minimum size required by the output buffer that holds the

generated content until it is sent to the client. The default size of the buffer is JSP engine

implementation dependent, but the specification mandates it to be at least 8kb. The following

line sets the buffer size to 32kb:

<%@ page buffer="32kb" %>

The value of the buffer is in kilobytes and the suffix kb is mandatory. To send the data directly

to the client without any buffering, we can specify the value as none.

The autoFlush attribute specifies whether the data in the output buffer should

be sent to the client automatically as soon as the buffer is full. The default value for autoFlush

is true. If it is set to false and the buffer is full, an exception is raised when we attempt to add

more data to the buffer. Here is the syntax for this attribute:

<%@ page autoFlush="false" %>

Obviously, the following combinations occurring in a JSP page are invalid and may either

cause an error at translation time or have an unknown behavior at runtime:

<%@ page buffer="none" autoFlush="false" %> <%@ page buffer="0kb" autoFlush="false" %>

The isThreadSafe attribute:

The isThreadSafe attribute specifies whether a page can handle multiple requests

concurrently. Although this attribute is not mentioned in the exam objectives, you should

understand how it works. For instance, neither of our examples, counter.jsp ), is thread safe.

If multiple client requests arrive simultaneously, then it is possible that two or more clients will

receive the same value for the visit count. This is because, by default, the value of

isThreadSafe attribute is true. This tells the container that it can dispatch multiple requests to

the page’s servlet concurrently in different threads. When this happens, each thread will

attempt to increment the same instance of the variable count simultaneously that is declared

using the declarations tags. Since the access to the variable is not synchronized, it is possible

that two threads will access it at the same time, one incrementing the value and the other

printing its value in the output. One way we can avoid this situation is by adding the following

line in our counter.jsp and persistent_counter.jsp pages:

Page 64: J2EE Handout

J2EE

©Copyright 2004, Cognizant Academy, All Rights Reserved 64

<%@ page isThreadSafe="false" %>

If isThreadSafe is set to false, the container dispatches the requests to the page one at a time

in the order they are received. This is equivalent to implementing the SingleThreadModel

interface for servlets. “Developing Thread-Safe Servlets.” In this case, only one thread will

execute the servlet code at a time, incrementing the value of count and then printing it in the

output HTML. However, note that even this is not a totally foolproof method of synchronizing

the counter. It will work when there is only one instance of the servlet serving the requests.But

if the container decides to create a pool of instances of the thread-unsafe servlet, then each

servlet instance will have its own copy of the count variable. A request to the same JSP page

will then return the count depending on which servlet instance was used from the pool. In

such cases, it is better to use a programmatic synchronization mechanism for incrementing

the count and leave the page as thread safe:

<%@ page isThreadSafe="true" %> <% synchronized(this)//this refers to the servlet instance { count++; out.print("Welcome! You are visitor number " + count); } %>

In this code, the attribute-value pair isThreadSafe=true will ensure that the servlet does not

implement SingleThreadModel; that way, only a single instance of the servlet is created. The

this keyword refers to the servlet instance, and the synchronized block on the instance will

make sure that the two operations—incrementing the count and printing its value—are

executed by a single thread at a time, thus printing a unique value of the count in the output

HTML for each request.

The contentType and pageEncoding attributes-internationalization

The contentType attribute specifies the MIME type and character encoding of the output. The

default value of the MIME type is text/html; the default value of the character encoding is ISO-

8859-1. The MIME type and character encoding are separated by a semicolon, as shown

here:

<%@ page contentType="text/html;charset=ISO-8859-1" %>

This is equivalent to writing the following line in a servlet:

response.setContentType("text/html;charset=ISO-8859-1");

The pageEncoding attribute specifies the character encoding of the JSP page. The default

value is ISO-8859-1. The following line illustrates the syntax:

<%@ page pageEncoding="ISO-8859-1" %>

Page 65: J2EE Handout

J2EE

©Copyright 2004, Cognizant Academy, All Rights Reserved 65

JAVABEANS: A BRIEF OVERVIEW

The JavaBeans component model architecture is both a specification and a framework of

APIs that supports a set of features that includes component introspection, properties, events,

persistence, and so forth. Since it is platform independent, it enables us to write portable and

reusable components. Components developed according to this specification are called

beans. From a developer’s perspective, a bean is a Java class object that encapsulates data

in the form of instance variables. These variables are referred to as properties of the bean.

The class then provides a set of methods for accessing and mutating its properties. The

actual strength of a bean as a reusable component lies in its ability to allow programmatic

introspection of its properties. This ability facilitates automated support for bean customization

using software programs called bean containers.

JavaBeans from the JSP perspective

In the JSP technology, the JSP engine acts as a bean container. Any class that follows these

two conventions can be used as a JavaBean in JSP pages:

q The class must have a public constructor with no arguments. This allows the

class to be instantiated as needed by the JSP engine.

q For every property, the class must have two publicly accessible methods, referred

to as the getter and the setter, that allow the JSP engine to access or mutate the

bean’s properties. The name of the method that accesses the property should be

getXXX() and the name of the method that mutates the property should be

setXXX(), where XXX is the name of the property with the first character

capitalized. Here are the signatures of the methods:

public property-type getXXX(); public void setXXX(property-type);

In the following getter and setter methods, the name of the property is color and its data type

is String:

public String getColor(); public void setColor(String);

Let’s look at a simple example of a Java class that can be used as a JavaBean in a JSP

page.

Why Accessors and Not Public Fields

Accessor(s) act as the public interface to values of the underlying data, they provide a dual

purpose of elegance and security to the content in the bean. The accessor can be used as a

preliminary checkpoint to ensure the validity of the data being written/read based on the

contextual requirements of application, as well as it separates the storage and use allowing

more control on the code.

Using JAVABEANS with JSP actions

Table below summarizes the three standard actions for using JavaBeans in a JSP page. In

the sections that follow, we will describe each of these actions in details.

Page 66: J2EE Handout

J2EE

©Copyright 2004, Cognizant Academy, All Rights Reserved 66

Declaring JavaBeans using <jsp:useBean>

The jsp:useBean action declares a variable in the JSP page and associates an instance of a

JavaBean with it. The association is a two-step process. First, the action tries to find an

existing instance of the bean. If an instance is not found, a new instance is created and

associated with the declared variable. We can customize the behavior of this action using the

five attributes shown in table

Handling exceptions

The default scope .The following declaration uses only two attributes—id and class:

<jsp:useBean id="address" class="AddressBean" />

This is similar to the previous example, except that we have not specified the scope attribute.

In this case, the page scope is used by default. Thus, this bean is available only in the JSP

page in which it is defined and only for the request for which it is created. It is equivalent to

the following code:

AddressBean address = (AddressBean) pageContext.getAttribute("address"); if (address == null) { address = new AddressBean(); pageContext.setAttribute("address", address); }

Using serialized beans In the following useBean declaration, the beanName attribute

specifies the use of a serialized bean, businessData.Address.John:

<jsp:useBean id="address" type="AddressBean" beanName="businessData.Address.John" scope="session" />

Page 67: J2EE Handout

J2EE

©Copyright 2004, Cognizant Academy, All Rights Reserved 67

Setting Bean properties – Explicitly from Request

<jsp:setProperty name="entry" property="numItems" param="numItems" />

In the JSP even if the property numItems is int and the numitem is passes as a request

parameter param attribute is defined to casted to the required type and then the value is set.

Explicit conversion is not required.

Values of Scope attribute

Application scope:

Application-scoped objects are shared across all the components of the web application and

are accessible for the life of the application. These objects are maintained as attribute-value

pairs by an instance of the ServletContext class. In a JSP page, this instance is available in

the form of the implicit object application. Thus, to share objects at the application level, we

use the setAttribute() and getAttribute() methods of the ServletContext interface.

Page 68: J2EE Handout

J2EE

©Copyright 2004, Cognizant Academy, All Rights Reserved 68

Session scope:

Objects in the session scope are shared across all the requests that belong to a singleuser

session and are accessible only while the client is active. These objects are maintained as

attribute-value pairs by an instance of the HttpSession class. In a JSP page, this instance is

available in the form of the implicit object session. Thus, to share objects at the session level,

we can use the session.setAttribute() and session. getAttribute() methods. In the following

example, the login.jsp page adds the user ID to the session scope so that the userProfile.jsp

page can retrieve it:

<%-- Add the userId to the session --%> <% String userId = // getUserLoggedIn session.setAttribute("userId", userId); %>

In the file userProfile.jsp:

<%-- Retrieve the userId from the session --%> <% String userId = (String) session.getAttribute("userId") //use the userId to retrieve user details. String name = getUserNameById(userId); %> User Name is: <%=name%>

Request scope:

Objects in the request scope are shared across all the components that process the same

request and are accessible only while that request is being serviced. These objects are

maintained as attribute-value pairs by an implementation instance of the interface

HttpServletRequest. In a JSP page, this instance is available in the form of the implicit object

request. Thus, we can add attributes to the request in one page and forward the request to

another page. The second page can then retrieve these attributes to generate a response. In

this example, the file login.jsp creates a user object and adds it to the request, and then

forwards the request to authenticate.jsp:

<% //Get login and password information from the request object //and file it in a User Object. User user = new User(); user.setLogin(request.getParameter("login")); user.setPassword(request.getParameter("password")); //Set the user object in the request scope for now request.setAttribute("user", user); //Forward the request to authenticate.jsp pageContext.forward("authenticate.jsp"); return; %>

Page 69: J2EE Handout

J2EE

©Copyright 2004, Cognizant Academy, All Rights Reserved 69

In the file authenticate.jsp:

<% //Get user from the forwarding page User user = (User) request.getAttribute("user"); //Check against the database. if (isValid(user)) { //remove the user object from request scope //and maintain it in the session scope request.removeAttribute("user"); session.setAttribute("user",user); pageContext.forward("account.jsp"); } else { pageContext.forward("loginError.jsp"); } return; %>

Page scope:

Objects in the page scope are accessible only in the translation unit in which they are defined.

They do not exist outside the processing of a single request within a single translation unit.

These objects are maintained as attribute-value pairs by an instance of a concrete subclass

of the abstract class PageContext. In a JSP page, this instance is available in the form of the

implicit object pageContext. ” The only way for actions (standard JSP actions and user-

defined custom tags) to share data and JavaBean objects with other actions or custom tags

appearing in the same JSP page (translation unit) and in the same request thread is to use

the pageContext implicit object and the page scope.

Conditional Bean Creation:

To make bean sharing more convenient, there are two situations where bean-related

elements are evaluated conditionally. First, a jsp:useBean element results in a new bean

being instantiated only if no bean with the same id and scope can be found. If a bean with the

same id and scope is found, the preexisting bean is simply bound to the variable referenced

by id. A typecast is performed if the preexisting bean is of a more specific type than the bean

being declared, and a ClassCastException results if this typecast is illegal. Second, instead of

<jsp:useBean ... />

you can use

<jsp:useBean ...>

statements

</jsp:useBean>

The point of using the second form is that the statements between the jsp:useBean start and

end tags are executed only if a new bean is created, not if an existing bean is used. This

conditional execution is convenient for setting initial bean properties for beans that are shared

by multiple pages. Since you don’t know which page will be accessed first, you don’t know

which page should contain the initialization code. No problem: they can all contain the code,

but only the page first accessed actually executes it.

Page 70: J2EE Handout

J2EE

©Copyright 2004, Cognizant Academy, All Rights Reserved 70

AccessCountBean - Conditional Bean Creation:

A simple bean that can be used to record cumulative access counts to any of a set of related

pages is given below. It also stores the name of the first page that was accessed. Since there

is no way to predict which page in a set will be accessed first, each page that uses the shared

counter has statements like the following:

<jsp:useBean id="counter" class="coreservlets.AccessCountBean" scope="application"> <jsp:setProperty name="counter" property="firstPage" value="Current Page Name" /> </jsp:useBean>

AccessCountBean.java package coreservlets; /** Simple bean to illustrate sharing beans through * use of the scope attribute of jsp:useBean. */ public class AccessCountBean { private String firstPage; private int accessCount = 1; public String getFirstPage() { return(firstPage); } public void setFirstPage(String firstPage) { this.firstPage = firstPage; } public int getAccessCount() { return(accessCount++); } } SharedCounts1.jsp <!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN"> <HTML> <HEAD> <TITLE>Shared Access Counts: Page 1</TITLE> <LINK REL=STYLESHEET HREF="JSP-Styles.css" TYPE="text/css"> </HEAD> <BODY> <TABLE BORDER=5 ALIGN="CENTER"> <TR><TH CLASS="TITLE"> Shared Access Counts: Page 1</TABLE> <P> <jsp:useBean id="counter" class="coreservlets.AccessCountBean" scope="application"> <jsp:setProperty name="counter" property="firstPage" value="SharedCounts1.jsp" /> </jsp:useBean> Of SharedCounts1.jsp (this page), <A HREF="SharedCounts2.jsp">SharedCounts2.jsp</A>, and <A HREF="SharedCounts3.jsp">SharedCounts3.jsp</A>, <jsp:getProperty name="counter" property="firstPage" /> was the first page accessed. <P>

Collectively, the three pages have been accessed

<jsp:getProperty name="counter" property="accessCount" /> times.</BODY></HTML>

Page 71: J2EE Handout

J2EE

©Copyright 2004, Cognizant Academy, All Rights Reserved 71

JAVABEANS IN SERVLETS

We know that JSP pages are converted into servlets at translation time, which means that the

beans that we use in our JSP pages are actually used from a servlet. This implies that we can

use JavaBeans from servlets, too. This section discusses the ways in which we can share

beans between JSP pages and servlets. The exam requires you to know the servlet code that

is equivalent to using beans in the different scopes: request, session, and application.

Suppose a JSP page uses three beans, each with a different scope, request, session, and

application, declared as:

<jsp:useBean id="address1" class="AddressBean" scope="request" /> <jsp:useBean id="address2" class="AddressBean" scope="session" /> <jsp:useBean id="address3" class="AddressBean" scope="application" />

Shows how to achieve the same functionality in the servlet code.

import javax.servlet.*; import javax.servlet.http.*; import AddressBean; public class BeanTestServlet extends HttpServlet { public void service(HttpServletRequest request, HttpServletResponse response) throws java.io.IOException, ServletException { AddressBean address1 = null; AddressBean address2 = null; AddressBean address3 = null; //Get address1 using the parameter request synchronized(request) { address1 = (AddressBean) request.getAttribute("address1"); if (address1==null) { address1 = new AddressBean(); request.setAttribute("address1", address1); } } //Get address2 using HttpSession HttpSession session = request.getSession(); synchronized(session) { address2 = (AddressBean) session.getAttribute("address2"); if (address2==null) { address2 = new AddressBean(); session.setAttribute("address2", address2); } } // Get address3 using ServletContext ServletContext servletContext = this.getServletContext(); synchronized(servletContext) { address3 = (AddressBean) servletContext.getAttribute("address3");

Page 72: J2EE Handout

J2EE

©Copyright 2004, Cognizant Academy, All Rights Reserved 72

if (address3==null) { address3 = new AddressBean(); servletContext.setAttribute("address3", address3); } } }//service }//class

JSP tag libraries

Although very useful, the standard tags provide just a basic set of features. As your web

application grows, you will find that these standard JSP tags are somewhat restrictive and

don’t provide support for the presentation logic that is required for formatting dynamic data.

For instance, you may be forced to write too much of your presentation logic code in JSP

scriptlets. Moreover, you may have to copy and paste those presentation logic scriptlets onto

multiple pages of the application. At this point, you need a way to put that presentation logic in

one place and reuse it wherever it is required. These user-defined tags are called custom

tags.

Tag handler

The JSP specification defines a tag handler as a runtime, container-managed object that

evaluates custom actions during the execution of a JSP page. In practical terms, a tag

handler is a Java class that implements one of the tag interfaces— Tag, IterationTag, or

BodyTag—of the package javax.servlet.jsp.tagext. Remember that while executing a JSP file,

if the JSP engine encounters a custom tag, it calls the methods on the tag’s handler class to

do the actual work. The JSP specification defines a tag library as a collection of actions that

encapsulate some functionality to be used from within a JSP page. Typically, we would not

create just one tag to fulfill a particular requirement. Rather, we would design and develop a

set of custom tags that work together and help solve a recurring requirement. Such a set of

custom tags is called a tag library.

Page 73: J2EE Handout

J2EE

©Copyright 2004, Cognizant Academy, All Rights Reserved 73

Tag library descriptor

When we use custom tags in a JSP page, the JSP engine needs to know the tag handler

classes for these tags, in which tag library they are located, and how are they used. This

meta-information is stored in a file called the tag library descriptor (TLD).

Location of a TLD file

A TLD file can reside in one of two types of places. First, it can be placed in any directory of a

web application; for example:

<docroot>/sampleLib.tld <docroot>/myLibs/sampleLib.tld <docroot>/WEB-INF/sampleLib.tld <docroot>/WEB-INF/myLibs/sampleLib.tld

We usually keep the TLD file in a directory, instead of a JAR file, during the development of a

tag library. This speeds up the development and testing cycles, during which we design new

tags, add new handler classes, and modify the TLD file frequently. However, once

development is finished, we package the handler classes and the TLD file of the library as a

JAR file. This file is then deployed under the <doc-root>/web-inf/lib directory along with other

jarred classes, such as servlets and third-party tools. The JSP specification mandates that,

when deployed in a JAR file, a TLD file be placed either directly under or inside a subdirectory

of the META-INF directory. In addition, the name of the TLD file must be taglib.tld. Thus, a

JAR file containing a packaged tag library is typically structured like this:

myPackage/myTagHandler1.class

myPackage/myTagHandler2.class

myPackage/myTagHandler3.class

META-INF/taglib.tld

Different types of TAGS available

q Empty Tags

q Tags with attribute

Page 74: J2EE Handout

J2EE

©Copyright 2004, Cognizant Academy, All Rights Reserved 74

q Tags with JSP code

q Tags with nested custom tags

Understanding the tag library descriptor

A tag library descriptor is an XML document that follows the DTD designated by the JSP

specification so that it can be created, read, and understood by all kinds of users, including

human users and the JSP engine, as well as other development tools. In essence, it informs

the user of a tag library about the usage and behavior of the tags that the library provides.

Interpreting the tag elements

The above tag indicates that it accepts an attribute named user. Since the value of the

<required> tag is false, a JSP page author may choose not to use the attributevalue pair.

Further, since <rtexprvalue> is true, a JSP page author may use a request-time expression

value. Therefore, the following lines from a JSP page are valid usages of this tag:

Page 75: J2EE Handout

J2EE

©Copyright 2004, Cognizant Academy, All Rights Reserved 75

THE TAG EXTENSION API

The Tag Extension API is a set of interfaces and classes that forms a contract between the

JSP container and the tag handler classes. Just as we need to know the Servlet API to write

servlets, we need to know the Tag Extension API to write custom tags. This API consists of

just one package: javax.servlet.jsp.tagext.

Exception classes

Page 76: J2EE Handout

J2EE

©Copyright 2004, Cognizant Academy, All Rights Reserved 76

The doStartTag() method

After setting up the tag with appropriate references by calling the setPageContext(),

setParent(), and setter methods, the container calls the doStartTag() method on the tag. The

signature of doStartTag() is: public int doStartTag() throws JspException; This method marks

the beginning of the tag’s actual processing, giving the tag handler a chance to do initial

computations and to verify whether or not the attribute values passed in the setter methods

are valid. If the initialization fails, the method may throw a JspException or a subclass of

JspException, such as JspTagException, to indicate the problem, depending on application

requirement. After initialization, the doStartTag() method decides whether or not to continue

evaluating its body content. As a result, it returns one of the two integer constants defined in

the Tag interface: EVAL_BODY_INCLUDE or SKIP_BODY. A return value of

Tag.EVAL_BODY_INCLUDE indicates that the body must be executed and that its output

must be included in the response, while a return value of Tag.SKIP_BODY indicates that the

body must be skipped and that it is not to be evaluated at all. This method cannot return any

other value.

Page 77: J2EE Handout

J2EE

©Copyright 2004, Cognizant Academy, All Rights Reserved 77

The doEndTag() method

After the body of the tag is evaluated or skipped (depending on the return value of

doStartTag()), the container calls the doEndTag() method. The signature of doEndTag() is:

public int doEndTag() throws JspException;

This marks the end of the processing of the tag and gives the tag handler a chance to do the

final cleanup for the tag. If anything fails during the cleanup process, the method may throw a

JspException or a subclass of JspException, such as JspTagException, to indicate the

problem. Finally, the doEndTag() method decides whether or not to continue evaluating the

rest of the JSP page. As a result, it returns one of the two integer constants defined in the Tag

interface: EVAL_PAGE or SKIP_PAGE. A return value of Tag.EVAL_PAGE indicates that the

rest of the JSP page must be evaluated and its output be included in the response, while a

return value of Tag.SKIP_PAGE indicates that the rest of the JSP page must not be

evaluated at all and that the JSP engine should return immediately from the current

_jspService() method. If this page was forwarded or included from another JSP page or a

servlet, only the current page evaluation is terminated, and if the page was included, the

processing resumes from the calling component. The tag cannot return any other value from

this method.

The release() method

Finally, the container calls the release() method on the handler class when the tag handler

object is no longer required. The signature of release() is:

public void release();

A custom tag may occur multiple times on a JSP page. A single instance of the tag handler

may be used to handle all of these occurrences. The JSP container calls the release() method

on the handler class when the handler object is no longer required. It is important to note that

this method is not called after every call to doEndTag(). It is called only once, when the

container decides to put this instance out of service. For example, if the container

implementation maintains a pool of tag handler instances, the container may reuse an

instance of a tag by calling the sequence setPageContext(), doStartTag(), doEndTag()

multiple times. The container calls the release() method only when the tag is to be removed

permanently from the pool. This method can be used to release all resources acquired by the

tag handler during its lifetime.

Page 78: J2EE Handout

J2EE

©Copyright 2004, Cognizant Academy, All Rights Reserved 78

Order of processing in a tag handler class that implements the Tag interface.

Implementing the ITERATIONTAG Interface

In the previous examples, we used the Tag interface to either include or skip the body content

of the tag. However, if the body content was included, it was included only once. The

IterationTag interface extends the Tag interface and allows us to include the body content

multiple times, in a way that is similar to the loop functionality of a programming language.

The IterationTag interface declares one method and one constant, as shown in table

Page 79: J2EE Handout

J2EE

©Copyright 2004, Cognizant Academy, All Rights Reserved 79

The doAfterBody() method

The doAfterBody() is the only method defined by the IterationTag interface. It gives the tag

handler a chance to reevaluate its body. The signature of doAfterBody() is:

public int doAfterBody() throws JspException;

If an error occurs during the invocation of the doAfterBody() method, it may throw a

JspException or a subclass of it, such as JspTagException, to indicate the problem. If

everything goes fine, it decides whether or not to reevaluate its body. To evaluate the body

again, it will return the integer constant EVAL_BODY_AGAIN, which is defined in the

IterationTag interface. This will cause an evaluation of the tag’s body the second time, and

after the evaluation, the JSP container will call doAfterBody() for the second time. This

process continues until doAfterBody() returns SKIP_BODY, which is defined in the Tag

interface. We cannot return any other value from this method. Finally, the doEndTag() method

is called, either because doStartTag() returns SKIP_BODY, or because doAfterBody() returns

SKIP_BODY. The purpose and functionality of the doEndTag() method in the IterationTag

interface are the same as in the Tag interface.

Order of processing in a tag handler class that implements the IterationTag interface.

Example of simple counter implemented as a iterative tag

Page 80: J2EE Handout

J2EE

©Copyright 2004, Cognizant Academy, All Rights Reserved 80

Implementing the BODYTAG Interface

The BodyTag interface extends IterationTag and adds a new functionality that lets the tag

handler evaluate its body content in a temporary buffer. This feature allows the tag to process

the generated contents at will. For example, after evaluation, the tag handler can view the

body content, discard it completely, modify it, or add more data to it before sending it to the

output stream. Since it is derived from IterationTag, BodyTag can also handle the evaluation

and processing of the content as many times as required.

Page 81: J2EE Handout

J2EE

©Copyright 2004, Cognizant Academy, All Rights Reserved 81

The setBodyContent() method

The JSP container calls the setBodyContent() method to pass an instance of BodyContent to

the tag. The signature of setBodyContent() is:

public void setBodyContent(BodyContent);

A typical implementation of this method is to save the BodyContent reference in a private

member for future use.

The doInitBody() method

The JSP container calls the doInitBody() method after calling setBodyContent().

The signature of doInitBody() is:

public void doInitBody(BodyContent) throws JspException;

This method allows the tag handler class to initialize the BodyContent object, if required,

before the actual evaluation process starts. Thus, if the initialization of Body- Content fails, the

doInitBody() method may throw a JspException or a subclass of JspException, such as

JspTagException, to indicate the problem. Since BodyTag extends IterationTag, which in turn

extends the Tag interface, BodyTag inherits all the functionality of IterationTag as well as Tag.

The container sets up the implementation handler class with appropriate references by calling

the setPageContext() and setParent() methods, passes the attribute values using the setter

methods, and calls doStartTag(). The doStartTag() method of a class that implements the

BodyTag interface returns any one of three values: EVAL_BODY_INCLUDE or SKIP_BODY

inherited from the Tag interface, or EVAL_BODY_BUFFERED, which is defined in the

BodyTag interface. The actions taken by the JSP container for the return values

EVAL_BODY_ INCLUDE and SKIP_BODY are the same as for the IterationTag interface.

However, if doStartTag() returns EVAL_BODY_BUFFERED, the JSP container takes a

different course of action. It first creates an instance of the BodyContent class. The

BodyContent class is a subclass of JspWriter and overrides all the print and write methods of

JspWriter to buffer any data written into it rather than sending it to the output stream of the

response. The JSP container passes the newly created BodyContent instance to the tag

handler using its setBodyContent() method, calls doInitBody() on the tag, and finally evaluates

the body of the tag, filling the BodyContent buffer with the result of the body tag evaluation.

The container calls doAfterBody() after evaluating the body, writing the data directly into the

output or buffering it, as the case may be. If the output was buffered, we can add, modify, or

delete the contents of this buffer. Finally, this method returns EVAL_BODY_AGAIN or

EVAL_BODY_BUFFERED to continue evaluating the body in a loop, or returns SKIP_BODY

to terminate the loop. Finally, the container calls doEndTag(), and, as with the other

interfaces, the tag handler class that is implementing the BodyTag interface can return either

SKIP_PAGE or EVAL_PAGE.

Page 82: J2EE Handout

J2EE

©Copyright 2004, Cognizant Academy, All Rights Reserved 82

Page 83: J2EE Handout

J2EE

©Copyright 2004, Cognizant Academy, All Rights Reserved 83

Example of search charecterstring and make it bold

Page 84: J2EE Handout

J2EE

©Copyright 2004, Cognizant Academy, All Rights Reserved 84

Accessing implicit objects

One of the greatest features of custom tags is their ability to access all the objects that are

accessible to the JSP page in which they appear from within the tag handler classes. This is

done with the help of the PageContext object, which is set by the container using the

setPageContext() method before calling the doStartTag() method.Using the p ageContext

object, we can access any other object available to the page. For example, we have used it to

get the JspWriter object to write out HTML in some of the previous examples:

JspWriter out = pageContext.getOut();

STATIC INCLUSION

<%@ include file="relativeURL" %> <jsp:directive.include file="relativeURL" />

Implications of static inclusion

When an include directive includes a file, the following rules apply:

q No processing can be done at translation time, which means the file attribute

value cannot be an expression. Therefore, the following use of the include

directive is invalid:

<% String myURL ="copyright.html"; %> <%@ include file="<%=myURL%>" %>

Page 85: J2EE Handout

J2EE

©Copyright 2004, Cognizant Academy, All Rights Reserved 85

q Because request parameters are a property of the requests and do not make any

sense at translation time, the file attribute value cannot pass any parameters to

the included page. Thus, the value of the file attribute in the following example is

invalid:

<%@ include file="other.jsp?abc=pqr" %>

q The included page may or may not be able to compile independently. If you look

at listing 13.2, the productDescription.jsp file cannot be compiled, since it does

not define the variable productId. In general, it is better to avoid such

dependencies and use the implicit variable pageContext to share objects across

statically included pages by using the pageContext.setAttribute() and

pageContext.getAttribute() methods.

DYNAMIC INCLUSION

In dynamic inclusion, when the JSP page is requested, it sends a request to another object,

and the output from that object is included in the requested JSP page. We use the standard

JSP actions <jsp:include> and <jsp:forward> to implement dynamic inclusion. Their syntax is

as follows:

<jsp:include page="relativeURL" flush="true" /> <jsp:forward page="relativeURL" />

The page attribute is mandatory. It must be a relative URL, and it can refer to any static or

dynamic web component, including a servlet. It can also be a request-time expression, The

flush attribute is only valid for <jsp:include> and not for <jsp:forward>. It is optional and

specifies that if the output of the current JSP page is buffered, then the buffer should be

flushed before passing the output stream to the included component. The default value for the

flush attribute is false. Functionally, the <jsp:include> and <jsp:forward> actions are

equivalent to the RequestDispatcher.include() and RequestDispatcher.forward() methods that

are used in servlets to include and forward the requests to other components.

Page 86: J2EE Handout

J2EE

©Copyright 2004, Cognizant Academy, All Rights Reserved 86

if the output is buffered, it is first cleared, and then the request is forwarded to the other

resource. However, if the output is not buffered and/or if the response is already committed by

the forwarding resource, then a java.lang.IllegalStateException is raised when we attempt to

forward the request.

The Future for JSP Technology

JSP technology is designed to be an open, extensible standard for building dynamic web

pages. Developers will use JSP pages to create portable web applications that can run with

different web and application servers for different markets, using whatever authoring tools fit

their market and their needs.

By working with a consortium of industry leaders, Sun has ensured that the JSP specification

is open and portable. You should be able to author JSP pages anywhere and deploy them

anywhere, using any client and server platforms. Over time, tool vendors and others will

extend the functionality of the platform by providing customized tag libraries for specialized

functions.

Page 87: J2EE Handout

J2EE

©Copyright 2004, Cognizant Academy, All Rights Reserved 87

SUMMARY

q JSP (Java Server Pages) is a dynamic web page generation technology it’s a

layer above the Servlet API.

q Usage of a JSP allows users to embed dynamic content generation chunks into a

HTML page, during the access to the JSP the JSP page gets converted on the fly

to a servlet, which is equivalent in functionality to the coded JSP.

q JSPs contain predefined tags, which provide specific functionality by getting

converted to appropriate artifacts, when the JSP is translated to a servlet.

q JSPs can use Java Beans to isolate view/UI generation from logic

implementation.

Page 88: J2EE Handout

J2EE

©Copyright 2004, Cognizant Academy, All Rights Reserved 88

Chapter 5: XML

Learning Objective

After completing this chapter, you will be able to:

q Understand XML Grammar and Document Rules

q Understand Document type declaration

q Create well formed and valid XML’s

q Know various rules of writing XML’s

q Understand XML Parsing, DOM, SAX

Introduction

XML, or Extensible Markup Language, is a markup language that you can use to create your

own tags. It was created by the World Wide Web Consortium (W3C) to overcome the

limitations of HTML, the Hypertext Markup Language that is the basis for all Web pages. Like

HTML, XML is based on SGML -- Standard Generalized Markup.

Language. Although SGML has been used in the publishing industry for decades, its

perceived complexity intimidated many people that otherwise might have used it. XML was

designed with the Web in mind.

XML documents are made up of storage units called entities, which contain either parsed or

unparsed data. Parsed data is made up of characters, some of which form character data,

and some of which form markup. Markup encodes a description of the document's storage

layout and logical structure. XML provides a mechanism to impose constraints on the storage

layout and logical structure.

Why XML?

HTML is the most successful markup language of all time. You can view the simplest HTML

tags on virtually any device, from palmtops to mainframes, and you can even convert HTML

markup into voice and other formats with the right tools. Given the success of HTML, why did

the W3C create XML? To answer that question, take a look at this document:

<p> <b>Mrs. Mary McGoon</b> <br> 1401 Main Street <br> Anytown, NC 34829

</p>

The trouble with HTML is that it was designed with humans in mind. Even without viewing the

above HTML document in a browser, you and I can figure out that it is someone's postal

address. (Specifically, it's a postal address for someone in the United States; even if you're

not familiar with all the components of U.S. postal addresses, you could probably guess what

this represents.)

Page 89: J2EE Handout

J2EE

©Copyright 2004, Cognizant Academy, All Rights Reserved 89

As humans, you and I have the intelligence to understand the meaning and intent of most

documents. A machine, unfortunately, can't do that. While the tags in this document tell a

browser how to display this information, the tags don't tell the browser what the information is.

You and I know it's an address, but a machine doesn't.

To render HTML, the browser merely follows the instructions in the HTML document.The

paragraph tag tells the browser to start rendering on a new line, typically with a blank line

beforehand, while the two break tags tell the browser to advance to the next line without a

blank line in between. While the browser formats the document beautifully, the machine still

doesn't know this is an address.

Consider the task of extracting the postal code from this address. Here's an (intentionally

brittle) algorithm for finding the postal code in HTML markup: If you find a paragraph with two

<br> tags, the postal code is the second word after the first comma in the second break

tag.Although this algorithm works with this example, there are any number of perfectly valid

addresses worldwide for which this simply wouldn't work. Even if you could write an algorithm

that found the postal code for any address written in HTML, there are any numbers of

paragraphs with two break tags that don't contain addresses at all. Writing an algorithm that

looks at any HTML paragraph and finds any postal codes inside it would be extremely difficult,

if not impossible. Now let's look at a sample XML document. With XML, you can assign some

meaning to the tags in the document. More importantly, it's easy for a machine to process the

information as well. You can extract the postal code from this document by simply locating the

content surrounded by the <postal-code> and </postal-code> tags, technically known as the

<postal-code> element. <address>

<name> <title>Mrs.</title> <first-name>Mary</first-name> <last-name>McGoon</last-name> </name> <street>1401 Main Street</street> <city>Anytown</city> <state>NC</state> <postal-code>34829</postal-code>

</address>

Page 90: J2EE Handout

J2EE

©Copyright 2004, Cognizant Academy, All Rights Reserved 90

To summarise:

XML HTML

User definable tags Defined set of tags designed

for web display

Content driven Format driven

End tags required for well formed documents

End tags not required

Quotes required around attributes values

Quotes not required

Slash required in empty tags Slash not required

What do XML documents look like?

Here’s how a simple XML document looks like:

<?xml version="1.0" encoding="UTF-8" standalone="no"?> <hostmappings>

<env type="dev"> <host name="hyddl0290" /> </env> <env type="prod"> <host name="hyddl0351" /> </env>

</hostmappings>

XML Grammar

XML declarations:

<?xml version="1.0" encoding="UTF-8" standalone="no"?>

Most XML documents start with an XML declaration that provides basic information about the

document to the parser. An XML declaration is recommended, but not required. If there is

one, it must be the first thing in the document. It is also called as prologue.

The declaration can contain up to three name-value pairs (many people call them attributes,

although technically they're not). The version is the version of XML used; currently this value

must be 1.0. The encoding is the character set used in this document. The ISO-8859-1

character set referenced in this declaration includes all of the characters used by most

Page 91: J2EE Handout

J2EE

©Copyright 2004, Cognizant Academy, All Rights Reserved 91

Western European languages. If no encoding is specified, the XML parser assumes that the

characters are in the UTF-8 set, a Unicode standard that supports virtually every character

and ideograph from the world's languages.

Finally, standalone, which can be either yes or no, defines whether this document can be

processed without reading any other files. For example, if the XML document doesn't

reference any other files, you would specify standalone="yes". If the XML document

references other files that describe what the document can contain, you could specify

standalone="no". Because standalone="no" is the default, you rarely see standalone in XML

declarations.

Elements

Elements are the most common form of markup. Delimited by angle brackets, most elements

identify the nature of the content they surround. Some elements may be empty, as seen

above, in which case they have no content. If an element is not empty, it begins with a start-

tag, <element>, and ends with an end-tag, </element>.

Page 92: J2EE Handout

J2EE

©Copyright 2004, Cognizant Academy, All Rights Reserved 92

Attributes

Attributes are name-value pairs that occur inside tags after the element name. For example,

<div class="preface"> is the div element with the attribute class having the value preface. In

XML, all attribute values must be quoted.

Entity References

In order to introduce markup into a document, some characters have been reserved to

identify the start of markup. The left angle bracket, "<", for instance, identifies the beginning of

an element start- or end-tag. In order to insert these characters into your document as

content, there must be an alternative way to represent them. In XML, entities are used to

represent these special characters. Entities are also used to refer to often repeated or varying

text and to include the content of external files.

Every entity must have a unique name. Defining your own entity names is discussed in the

section on entity declarations below. In order to use an entity, you simply reference it by

name. Entity references begin with the ampersand and end with a semicolon. For example,

the amp entity inserts a literal ampersand into a document. So the string "O'Reilly &

Associates, Inc." can be represented in an XML document as O'Reilly &amp; Associates, Inc.

Comments

Comments begin with "<!--" and end with "-->". Comments can contain any data except the

literal string "--". You can place comments between markup anywhere in your document.

Comments are not part of the textual content of an XML document. An XML processor is not

required to pass them along to an application.

Processing Instructions

Processing instructions (PIs) are an escape hatch to provide information to an application.

Like comments, they are not textually part of the XML document, but the XML processor is

required to pass them to an application.

Processing instructions have the form: <?name pidata?>. The name, called the PI target,

identifies the PI to the application. Applications should process only the targets they recognize

and ignore all other PIs. Any data that follows the PI target is optional, it is for the application

that recognizes the target. The names used in PIs may be declared as notations in order to

formally identify them.PI names beginning with "XML" are reserved for XML standardization.

CDATA Sections

In a document, a CDATA section instructs the parser to ignore most markup characters.

Consider a source code listing in an XML document. It might contain characters that the XML

parser would ordinarily recognize as markup (< and &, for example). In order to prevent this, a

CDATA section can be used.

<![CDATA[*p = &q;b = (i <= 3);]]>

Page 93: J2EE Handout

J2EE

©Copyright 2004, Cognizant Academy, All Rights Reserved 93

Between the start of the section, "<![CDATA[" and the end of the section, "]]>", all character

data is passed directly to the application.

The only string that cannot occur in a CDATA section is "]]>". Note: comments are not

recognized in a CDATA section. If present, the literal text "<!--comment-->" will be passed

directly to the application.

Document Type Declarations

A large percentage of the XML specification deals with various sorts of declarations that are

allowed in XML. If you have experience with SGML, you will recognize these declarations

from SGML DTDs (Document Type Definitions). If you have never seen them before, their

significance may not be immediately obvious.

One of the greatest strengths of XML is that it allows you to create your own tag names. But

for any given application, it is probably not meaningful for tags to occur in a completely

arbitrary order. Consider the old joke example introduced earlier. Would this be meaningful?

<quote><oldjoke>Goodnight, <applause/>Gracie</oldjoke></quote>

<burns><gracie>Say <quote>goodnight</quote>, </gracie>Gracie.</burns>

It's so far outside the bounds of what we normally expect that it's nonsensical. It just doesn't

mean anything.

However, from a strictly syntactic point of view, there's nothing wrong with that XML

document. So, if the document is to have meaning, and certainly if you're writing a style sheet

to present it, there must be some constraint on the sequence and nesting of tags.

Declarations are where these constraints can be expressed .More generally, declarations

allow a document to communicate meta-information to the parser about its content. Meta-

information includes the allowed sequence and nesting of tags, attribute values and their

types and defaults, the names of external files that may be referenced and whether or not

they contain XML, the formats of some external (non-XML) data that may be included, and

entities that may be encountered. There are four kinds of declarations in XML: element

declarations, attribute list declarations, entity declarations, and notation declarations.

Element Declarations

Element declarations [Section 3.2] identify the names of elements and the nature of

their content. A typical element declaration looks like this:

<!ELEMENT oldjoke (burns+, allen, applause?)>

This declaration identifies the element named oldjoke. Its "content model" follows the element

name. The content model defines what an element may contain. In this case, an oldjoke must

contain burns and allen and may contain applause. The commas between element names

indicate that they must occur in succession. The plus after burns indicates that it may be

repeated more than once but must occur at least once. The question mark after applause

indicates that it is optional. A name with no punctuation, such as allen, must occur exactly

once.

Page 94: J2EE Handout

J2EE

©Copyright 2004, Cognizant Academy, All Rights Reserved 94

Declarations for burns, allen, applause and all other elements used in any content model

must also be present for an XML processor to check the validity of a document.In addition to

element names, the special symbol #PCDATA is reserved to indicate character data. The

moniker PCDATA stands for "parseable character data".Elements with both element content

and PCDATA content are said to have "mixed content".For example, the definition for burns

might be

<!ELEMENT burns (#PCDATA | quote)*>

The vertical bar indicates an "or" relationship, the asterisk indicates that the content is

optional (may occur zero or more times); therefore, by this definition, burns may contain zero

or more characters and quote tags. All content models that include PCDATA must have this

form: PCDATA must come first, all of the elements must be separated by vertical bars, and

the entire group must be optional.

Two other content models are possible: EMPTY indicates that the element has no content

(and consequently no end-tag), and ANY indicates that any content is allowed. The ANY

content model is sometimes useful during document conversion, but should be avoided at

almost any cost in a production environment because it disables all content checking in that

element.

Here is a complete set of element declarations for the example used in this article:

<!ELEMENT oldjoke (burns+, allen, applause?)>

<!ELEMENT burns (#PCDATA | quote)*><!ELEMENT allen (#PCDATA | quote)*><!ELEMENT quote (#PCDATA)*><!ELEMENT applause empty>

Attribute Declarations

Attribute declarations identify which elements may have attributes, what attributes they may

have, what values the attributes may hold, and what default value each attribute has. A typical

attribute declaration looks like this:

<!ATTLIST oldjoke name ID #required label CDATA #implied status ( funny | not funny ) 'funny'>

In this example, the oldjoke element has three attributes: name, which is an ID and is

required; label, which is a string (character data) and is not required; and status, which must

be either funny or notfunny and defaults to funny if not specified.

Each attribute in a declaration has three parts: a name, a type, and a default value.You are

free to select any name you wish, subject to some slight restrictions, but names cannot be

repeated on the same element.

Page 95: J2EE Handout

J2EE

©Copyright 2004, Cognizant Academy, All Rights Reserved 95

There are six possible types:

CDATA: CDATA attributes are strings, any text is allowed.

ID: The value of an ID attribute must be a name. All of the ID values used in a document

must be different. IDs uniquely identify individual elements in a document. Elements can have

only a single ID attribute.

IDREF or IDREFS: An IDREF attribute's value must be the value of a single ID attribute on

some element in the document. The value of an IDREFS attribute may contain multiple

IDREF values separated by white space.

ENTITY or ENTITIES: An ENTITY attribute's value must be the name of a single entity. The

value of an ENTITIES attribute may contain multiple ENTITY values separated by white

space.

NMTOKEN or NMTOKENS : Name token attributes are a restricted form of string attribute. In

general, an NMTOKEN attribute must consist of a single word, but there are no additional

constraints on the word, it doesn't have to match another attribute or declaration. The value of

an NMTOKENS attribute may contain multiple NMTOKEN values separated by white space.

A list of names: You can specify that the value of an attribute must be taken from a specific

list of names. This is frequently called an enumerated type because each of the possible

values is explicitly enumerated in the declaration.

There are four possible default values:

#REQUIRED: The attribute must have an explicitly specified value on every occurrence of the

element in the document.

#IMPLIED: The attribute value is not required, and no default value is provided. If a value is

not specified, the XML processor must proceed without one.

"value": An attribute can be given any legal value as a default. The attribute value is not

required on each element in the document, but if it is not present, it will appear to be the

specified default.

#FIXED "value" : An attribute declaration may specify that an attribute has a fixed value. In

this case, the attribute is not required, but if it occurs, it must have the specified value. One

use for fixed attributes is to associate semantics with an element. A complete discussion is

beyond the scope of this article, but you can find several examples of fixed attributes in the

XLL specification.

Entity Declarations

Entity declarations allow you to associate a name with some other fragment of the document.

That construct can be a chunk of regular text, a chunk of the document type declaration, or a

reference to an external file containing either text or binary data. Here are a few typical entity

declarations:

Page 96: J2EE Handout

J2EE

©Copyright 2004, Cognizant Academy, All Rights Reserved 96

<!ENTITY ATI "ArborText, Inc.">

<!ENTITY boilerplate SYSTEM "/standard/legalnotice.xml"><!ENTITY ATIlogo SYSTEM "/standard/logo.gif" NDATA GIF87A>

XML document rules:

Elements can’t overlap:

XML elements can't overlap. Here's some markup that isn't legal:

<!-- NOT legal XML markup --> <p>

<b>I <i>reallylove</b> XML.</i>

</p>

If you begin a <i> element inside a <b> element, you have to end it there as well. If you want

the text XML to appear in italics, you need to add a second <i> element to correct the markup:

<!-- legal XML markup --> <p>

<b>I <i>reallylove</i> </b> <i>XML.</i>

</p>

End tags are required:

You can't leave out any end tags. In the first example below, the markup is not legal because

there are no end paragraph (</p>) tags. While this is acceptable in HTML (and, in some

cases, SGML), an XML parser will reject it.

<!-- NOT legal XML markup --> <p>Yada yada yada... <p>Yada yada yada... <p>...

If an element contains no markup at all it is called an empty element; the HTML break (<br>)

and image (<img>) elements are two examples. In empty elements in XML documents, you

can put the closing slash in the start tag. The two break elements and the two image

elements below mean the same thing to an XML parser:

<!-- Two equivalent break elements -->

<br></br> <br />

<!-- Two equivalent image elements --> <img src="../img/c.gif"></img> <img src="../img/c.gif" />

Page 97: J2EE Handout

J2EE

©Copyright 2004, Cognizant Academy, All Rights Reserved 97

Elements are case sensitive:

XML elements are case sensitive. In HTML, <h1> and <H1> are the same; in XML, they're

not. If you try to end an <h1> element with a </H1> tag, you'll get an error. In the example

below, the heading at the top is illegal, while the one at the bottom is fine.

<!-- NOT legal XML markup --> <h1>Elements are case sensitive</H1> <!-- legal XML markup --> <h1>Elements are case sensitive</h1>

Attributes must have quoted values:

There are two rules for attributes in XML documents:

q Attributes must have values.

q Those attributes must be enclosed within quotation marks.

Compare the two examples below. The markup at the top is legal in HTML, but not in XML.

To do the equivalent in XML, you have to give the attribute a value, and you have to enclose it

in quotes.

<!-- NOT legal XML markup --> <ol compact> <!-- legal XML markup --> <ol compact="yes">

You can use either single or double quotes, just as long as you're consistent. If the value of

the attribute contains a single or double quote, you can use the other kind of quote to

surround the value (as in name="Doug's car"), or use the entities &quot; for a double quote

and &apos; for a single quote. An entity is a symbol, such as &quot;, that the XML parser

replaces with other text, such as ".

Namespaces:

XML's power comes from its flexibility, the fact that you and I and millions of other people can

define our own tags to describe our data. Remember the sample XML document for a

person's name and address? That document includes the <title> element for a person's

courtesy title, a perfectly reasonable choice for an element name. If you run an online

bookstore, you might create a <title> element for the title of a book. If you run an online

mortgage company, you might create a <title> element for the title to a piece of property. All

of those are reasonable choices, but all of them create elements with the same name. How

do you tell if a given <title> element refers to a person, a book, or a piece of property? We do

this with namespaces. To use a namespace, you define a namespace prefix and map it to a

particular string. Here's how you might define namespace prefixes for our three <title>

elements:

<?xml version="1.0"?> <customer_summary

xmlns:addr="http://www.xyz.com/addresses/" xmlns:books="http://www.zyx.com/books/" xmlns:mortgage= http://www.yyz.com/title/>

... <addr:name><title>Mrs.</title> ... </addr:name>

Page 98: J2EE Handout

J2EE

©Copyright 2004, Cognizant Academy, All Rights Reserved 98

... ... <books:title>Lord of the Rings</books:title> ... . . . < m o r t g a g e : t i t l e > N C 2 9 4 8 -388-1983</mortgage:title> ...

In this example, the three namespace prefixes are addr, books, and mortgage. Notice that

defining a namespace for a particular element means that all of its child elements belong to

the same namespace. The first <title> element belongs to the addr namespace because its

parent element, <addr:Name>, does. One final point: The string in a namespace definition is

just a string.

Yes, these strings look like URLs, but they're not. You could define xmlns:addr="mike" and

that would work just as well. The only thing that's important about the namespace string is

that it's unique.

Understand Document Type Declarations

So far we have learned about the basic rules of XML documents; that's all well and good, but

you need to define the elements you're going to use to represent data. There are two ways of

doing that – DTD and XML Schema. We restrict ourselves here to DTD.

One method is to use a Document Type Definition, or DTD. A DTD defines the elements that

can appear in an XML document, the order in which they can appear, how they can be nested

inside each other, and other basic details of XML document structure. DTDs are part of the

original XML specification and are very similar to SGML DTDs.

Let’s look at a sample DTD for an address document.

<!-- address.dtd --> <!ELEMENT address (name, street, city, state, postal-code)> <!ELEMENT name (title? first-name, last-name)> <!ELEMENT title (#PCDATA)> <!ELEMENT first-name (#PCDATA)> <!ELEMENT last-name (#PCDATA)> <!ELEMENT street (#PCDATA)> <!ELEMENT city (#PCDATA)> <!ELEMENT state (#PCDATA)> <!ELEMENT postal-code (#PCDATA)>

This DTD defines three basic things:

q An <address> element contains a <name>, a <street>, a <city>, a <state>, and a

<postal-code>. All of those elements must appear, and they must appear in that

order.

q A <name> element contains an optional <title> element (the question mark

means the title is optional), followed by a <first-name> and a <last-name>

element.

q All of the other elements contain text. (#PCDATA stands for parsed character

data; you can't include another element in these elements.)

Page 99: J2EE Handout

J2EE

©Copyright 2004, Cognizant Academy, All Rights Reserved 99

Although the DTD is pretty simple, it makes it clear what combinations of elements are legal.

An address document that has a <postal-code> element before the <state> element I sn't

legal, and neither is one that has no <last-name> element.

Symbols in DTDs

There are a few symbols used in DTDs to indicate how often (or whether) something may

appear in an XML document. Here are some examples, along with their meanings:

<!ELEMENT address (name, city, state)>

The <address> element must contain a <name>, a <city>, and a <state> element, in that

order. All of the elements are required. The comma indicates a list of items.

<!ELEMENT name (title?, first-name, last-name)>

This means that the <name> element contains an optional <title> element, followed by a

mandatory <first-name> and a <last-name> element. The question mark indicates that an

item is optional; it can appear once or not at all.

<!ELEMENT addressbook (address+)>

An <addressbook> element contains one or more <address> elements. You can have as

many <address> elements as you need, but there has to be at least one. The plus sign

indicates that an item must appear at least once, but can appear any number of times.

<!ELEMENT private-addresses (address*)>

A <private-addresses> element contains zero or more <address> elements. The

asteriskindicates that an item can appear any number of times, including zero.

<!ELEMENT name (title?, first-name, (middle-initial | middlename)?, last-name)>

A <name> element contains an optional <title> element, followed by a <first-name> element,

possibly followed by either a <middle-initial> or a <middle-name> element, followed by a

<lastname> element. In other words, both <middle-initial> and <middle- name> are optional,

and you can have only one of the two. Vertical bars indicate a list of choices; you can choose

only one item from the list. Also notice that this example uses parentheses to group certain

elements, and it uses a question mark against the group.

<!ELEMENT name ((title?, first-name, last-name) | (surname,mothers-name, given-

name))>

The <name> element can contain one of two sequences: An optional <title>, followed by a

<firstname> and a <last-name>; or a <surname>, a <mothers-name>, and a <given-name>.

Defining attributes:

You can define attributes for the elements that will appear in your XML document. Using a

DTD, you can also:

q Define which attributes are required

Page 100: J2EE Handout

J2EE

©Copyright 2004, Cognizant Academy, All Rights Reserved 100

q Define default values for attributes

q List all of the valid values for a given attribute

Suppose that you want to change the DTD to make “state” an attribute of the <city> element.

Here's how to do that:

<!ELEMENT city (#PCDATA)> <!ATTLIST city state CDATA #REQUIRED>

This defines the <city> element as before, but the revised example also uses an ATTLIST

declaration to list the attributes of the element. The name city inside the attribute list tells the

parser that these attributes are defined for the <city> element.

The name state is the name of the attribute, and the keywords CDATA and #REQUIRED tell

the parser that the state attribute contains text and is required (if it's optional, CDATA

#IMPLIED will do the trick).

To define multiple attributes for an element, write the ATTLIST like this:

<!ELEMENT city (#PCDATA)> <!ATTLIST city state CDATA #REQUIRED postal-code CDATA #REQUIRED>

This example defines both state and postal-code as attributes of the <city> element.

Finally, DTDs allow you to define default values for attributes and enumerate all of the valid

values for an attribute:

<!ELEMENT city (#PCDATA)> <!ATTLIST city state CDATA (AZ|CA|NV|OR|UT|WA) "CA">

The example here indicates that it only supports addresses from the states of Arizona (AZ),

California (CA), Nevada (NV), Oregon (OR), Utah (UT), and Washington (WA), and that the

default state is California. Thus, you can do a very limited form of data validation.

Creating a Simple XML Document

Now that you know the basic rules for creating an XML document, let's try them out.

You can create XML documents using a plain text editor like Notepad (PC), TextEdit (Mac), or

pico (Unix). You can also use programs like Dreamweaver and Cooktop, but all that is

necessary to create the document is a text editor.

Let's say we have two types of documents we would like to wrap in XML: emails and letters.

We want to encode the emails and letters because we are creating an online repository of

archival messages within an organization or by an individual. By encoding them in XML, we

hope to encode their content once and be able to translate it to a variety of outputs, like

HTML, PDFs, or types not yet created.

Page 101: J2EE Handout

J2EE

©Copyright 2004, Cognizant Academy, All Rights Reserved 101

To begin, we need to declare an XML version:

<?xml version="1.0" encoding="iso-8859-1"?>

Now, after declaring the XML version, we need to determine the root element for the

documents. Let's use message as the root element, since both email and letters can be

classified as messages.

<?xml version="1.0" encoding="iso-8859-1"?> <message> </message>

Note: We created both the opening and closing tags for the message element. When creating

XML documents, it is useful to create both the opening and closing elements at the same

time. After creating the tags, you would then fill in the content. Since one of the fatal errors for

XML is forgetting to close an element, if you make the opening and closing tags each time

you create an element, you won't accidentally forget to do so.

Parent and child relationships

A way of describing relationships in XML is the terminology of parent and child. In our

examples, the parent or "root" element is <message>, which then has two child elements,

<email>, and <letter>.

An easy way of showing how elements are related in XML is to indent the code to show that

an element is a child of another. For example,

<?xml version="1.0" encoding="iso-8859-1"?> <message> <email> </email> </message>

Now that we have the XML declaration, the root element, and the child element (email), let's

determine the information we want to break out in an email. Say we want to keep information

about the sender, recipients, subject, and the body of the text. Since the information about the

sender and recipients are generally in the head of the document, let's consider them children

elements of a parent element that we will call <header>. In addition to <header>, the other

child elements of <email> will be <subject> and <text>. So our XML will look something like

this:

<?xml version="1.0" encoding="iso-8859-1"?> <message> <email> <header> <sender>[email protected]</sender> <recipient>[email protected]</recipient> </header> <subject>Re: XML </subject> <text>I'm working on my XML project right now. </text>

Page 102: J2EE Handout

J2EE

©Copyright 2004, Cognizant Academy, All Rights Reserved 102

</email> </message>

Now, let's create an XML document for a letter. Some of the information in a letter we want to

know include the sender, the recipient, and the text of the letter. Additionally, we want to know

the date that it was sent and what salutation was used to start off the message. Let's see

what this would look like in XML:

<?xml version="1.0" encoding="iso-8859-1"?> <message>

<letter> <letterhead> <sender>Margaret</sender> <recipient>God</recipient> <date>1970</date> </letterhead> <text> <salutation>Are you there God?</salutation> It's me Margaret... </text> </letter> </message>

Now say we wanted to keep track of whether or not these messages were replies or not.

Instead of creating an additional element called <reply>, let's assign an attribute to the

elements <email> and <letter> indicating whether that document was a reply to a previous

message.

In XML, it would look something like this:

<email reply="yes">

or

<letter reply="no">

When creating XML documents, it's always useful to spend a little time thinking about what

information you want to store, as well as what relationships the elements will have. Now that

we've made some XML documents, let's talk about "well formed" XML and valid XML.

Well Formed and Valid XMLs

Well formed in relation to XML means that it has no syntax, spelling, punctuation, grammar

errors, etc. in its markup. These kinds of errors can cause your XML document to not parse.

Note: An XML Parser is software that reads XML documents and interprets or "parses" the

code according to the XML standard. A parser is needed to perform actions on XML. For

example, a parser would be needed to compare an XML document to a DTD.

In the next section, we will talk about some common errors that prevent an XML document

from being well formed.

Page 103: J2EE Handout

J2EE

©Copyright 2004, Cognizant Academy, All Rights Reserved 103

When you say an XML document is valid, you're saying that the element structure and

markup of the XML document matches a defined standard of relationships, in addition to

having well formed markup. In other words, is this XML document a quality document?

One standard used to validate XML is a DTD, or Document Type Declaration, although XML

Schemas are also used.

These standards are useful when dealing with the creation of a number of XML documents for

they provide a quality control measure to ensure that all the documents meet a minimum

standard. Another benefit is that it allows for errors to be detected in the process of creating

the XML document, rather than at the end. Later, we'll create a sample DTD for our email and

letter XML documents.

Note: An important thing to remember is that when a document is valid it is also "well formed,"

but a "well formed" document is not necessarily valid. Additionally, you can create XML

documents without a DTD, but the XML document can't be considered valid without a

document type.

Common XML errors

q Missing a closing tag.

q Use a mix of both upper and lower case characters while opening and closing an

element’s tag.

q Another common error is forgetting to close your quotations around the attributes

value.

q XML parsers expect to see tags opened and closed in a certain order. XML

requires the most recently opened XML element to be closed first.

XML Attributes

XML elements can have attributes.

From HTML you will remember this: <IMG SRC="computer.gif">. The SRC attribute provides

additional information about the IMG element.

In HTML (and in XML) attributes provide additional information about elements:

<img src="computer.gif"> <a href="demo.asp">

Attributes often provide information that is not a part of the data. In the example below, the file

type is irrelevant to the data, but important to the software that wants to manipulate the

element:

<file type="gif">computer.gif</file>

Quote Styles, "female" or 'female'?

Attribute values must always be enclosed in quotes, but either single or double quotes can be

used. For a person's sex, the person tag can be written like this:

<person sex="female">or like this: <person sex='female'>

Page 104: J2EE Handout

J2EE

©Copyright 2004, Cognizant Academy, All Rights Reserved 104

Note: If the attribute value itself contains double quotes it is necessary to use single quotes,

like in this example:

<gangster name='George "Shotgun" Ziegler'>

Note: If the attribute value itself contains single quotes it is necessary to use double quotes,

like in this example:

<gangster name="George 'Shotgun' Ziegler">

Use of Elements vs. Attributes

Data can be stored in child elements or in attributes.

Take a look at these examples:

<person sex="female"> <firstname>Anna</firstname> <lastname>Smith</lastname>

</person>

<person> <sex>female</sex> <firstname>Anna</firstname> <lastname>Smith</lastname>

</person>

In the first example sex is an attribute. In the last, sex is a child element. Both examples

provide the same information.

There are no rules about when to use attributes, and when to use child elements. My

experience is that attributes are handy in HTML, but in XML you should try to avoid them. Use

child elements if the information feels like data.

Rule is to store data in child elements.

The following three XML documents contain exactly the same information:

A date attribute is used in the first example:

<note date="12/11/2002"> <to>Tove</to> <from>Jani</from> <heading>Reminder</heading> <body>Don't forget me this weekend!</body>

</note>

A date element is used in the second example:

<note> <date>12/11/2002</date>

Page 105: J2EE Handout

J2EE

©Copyright 2004, Cognizant Academy, All Rights Reserved 105

<to>Tove</to> <from>Jani</from> <heading>Reminder</heading> <body>Don't forget me this weekend!</body>

</note>

An expanded date element is used in the third:

<note> <date> <day>12</day> <month>11</month> <year>2002</year> </date> <to>Tove</to> <from>Jani</from> <heading>Reminder</heading> <body>Don't forget me this weekend!</body>

</note>

Avoid using attributes?

Should you avoid using attributes?

Some of the problems with using attributes are:

q attributes cannot contain multiple values (child elements can)

q attributes are not easily expandable (for future changes)

q attributes cannot describe structures (child elements can)

q attributes are more difficult to manipulate by program code

q attribute values are not easy to test against a Document Type Definition (DTD) -

which is used to define the legal elements of an XML document

If you use attributes as containers for data, you end up with documents that are difficult to

read and maintain. Try to use elements to describe data. Use attributes only to provide

information that is not relevant to the data.

Don't end up like this ( if you think this looks like XML, you have not understood the point):

<note day="12" month="11" year="2002" to="Tove" from="Jani" heading="Reminder" body="Don't forget me this weekend!"> </note>

An Exception to this Attribute rule

Rules always have exceptions.

Sometimes we assign ID references to elements. These ID references can be used to access

XML elements in much the same way as the NAME or ID attributes in HTML. This example

demonstrates this:

Page 106: J2EE Handout

J2EE

©Copyright 2004, Cognizant Academy, All Rights Reserved 106

<messages> <note id="p501"> <to>Tove</to> <from>Jani</from> <heading>Reminder</heading> <body>Don't forget me this weekend!</body> </note> <note id="p502"> <to>Jani</to> <from>Tove</from> <heading>Re: Reminder</heading> <body>I will not!</body> </note> </messages>

The ID in these examples is just a counter, or a unique identifier, to identify the different notes

in the XML file, and not a part of the note data.

What I am trying to say here is that metadata (data about data) should be stored as attributes,

and that data itself should be stored as elements.

XML Parsing

Parsing an XML is to parse a stream of well-formed XML tags into an element tree, letting

you perform the common task of extracting data from XML-formatted text.

Two Most popular XML parsers developed and used over a range of domains are SAX and

DOM parsers. SAX (Simple API for XML) and DOM (Document Object Model) were both

designed to allow programmers to access their information without having to write a parser in

their programming language of choice. By keeping the information in XML 1.0 format, and by

using either SAX or DOM APIs your program is free to use whatever parser it wishes. This

can happen because parser writers must implement the SAX and DOM APIs using their

favorite programming language. SAX and DOM APIs are both available for multiple

languages (Java, C++, Perl, Python, etc.).

So both SAX and DOM were created to serve the same purpose, which is giving you access

to the information stored in XML documents using any programming language (and a parser

for that language). However, both of them take very different approaches to giving you access

to your information

DOM

DOM gives you access to the information stored in your XML document as a hierarchical

object model. DOM creates a tree of nodes (based on the structure and information in your

XML document) and you can access your information by interacting with this tree of nodes.

The textual information in your XML document gets turned into a bunch of tree nodes. Figure

below illustrates this.

Page 107: J2EE Handout

J2EE

©Copyright 2004, Cognizant Academy, All Rights Reserved 107

SAX

SAX chooses to give you access to the information in your XML document, not as a tree of

nodes, but as a sequence of events! You ask, how is this useful? The answer is that SAX

chooses not to create a default Java object model on top of your XML document (like DOM

does). This makes SAX faster, and also necessitates the following things:

q creation of your own custom object model

q creation of a class that listens to SAX events and properly creates your object

model.

Note that these steps are not necessary with DOM, because DOM already creates an object

model for you (which represents your information as a tree of nodes).

In the case of DOM, the parser does almost everything, read the XML document in, create a

Java object model on top of it and then give you a reference to this object model (a Document

object) so that you can manipulate it. SAX is not called the Simple API for XML for nothing, it

is really simple. SAX doesn't expect the parser to do much, all SAX requires is that the parser

should read in the XML document, and fire a bunch of events depending on what tags it

encounters in the XML document. You are responsible for interpreting these events by writing

an XML document handler class, which is responsible for making sense of all the tag events

and creating objects in your own object model. So you have to write: your custom object

model to "hold" all the information in your XML document into a document handler that listens

to SAX events (which are generated by the SAX parser as its reading your XML document)

and makes sense of these events to create objects in your custom object model.

SAX can be really fast at runtime if your object model is simple. In this case, it is faster than

DOM, because it bypasses the creation of a tree based object model of your information. On

the other hand, you do have to write a SAX document handler to interpret all the SAX events

(which can be a lot of work).

Page 108: J2EE Handout

J2EE

©Copyright 2004, Cognizant Academy, All Rights Reserved 108

What kinds of SAX events are fired by the SAX parser? These events are really very simple.

SAX will fire an event for every open tag, and every close tag. It also fires events for

#PCDATA and CDATA sections. You document handler (which is a listener for these events)

has to interpret these events in some meaningful way and create your custom object model

based on them. Your document handler will have to interpret these events and the sequence

in which these events are fired is very important. SAX also fires events for processing

instructions, DTDs, comments, etc. But the idea is still the same, your handler has to interpret

these events (and the sequence of the events) and make sense out of them.

When to use DOM and SAX parsers

If your XML documents contain document data (e.g., Framemaker documents stored in XML

format), then DOM is a completely natural fit for your solution. If you are creating some sort of

document information management system, then you will probably have to deal with a lot of

document data. An example of this is the Datachannel RIO product, which can index and

organize information that comes from all kinds of document sources (like Word and Excel

files). In this case, DOM is well suited to allow programs access to information stored in these

documents.

However, if you are dealing mostly with structured data (the equivalent of serialized Java

objects in XML) DOM is not the best choice. That is when SAX might be a better fit.

If the information stored in your XML documents is machine readable (and generated) data

then SAX is the right API for giving your programs access to this information. Machine

readable and generated data include things like:

q Java object properties stored in XML format

q Queries that are formulated using some kind of text based query language (SQL,

XQL, OQL)

q Result sets that are generated based on queries (this might include data in

relational database tables encoded into XML).

q

So machine generated data is information that you normally have to create data structures

and classes for in Java. A simple example is the address book, which contains information

about persons, as shown in Figure 1. This address book XML file is not like a word processor

document, rather it is a document that contains pure data, which has been encoded into text

using XML.

The SAX document handler you write does element to object mapping. If your information is

structured in a way that makes it easy to create this mapping you should use the SAX API.

On the other hand, if your data is much better represented as a tree then you should use

DOM.

Page 109: J2EE Handout

J2EE

©Copyright 2004, Cognizant Academy, All Rights Reserved 109

SUMMARY

After completing this chapter, you have learned:

q XML Grammar and Document Rules

q Understand Document type declaration

q Create well formed and valid XML’s

q Know various rules of writing XML’s

q Understand XML Parsing, DOM, SAX

Page 110: J2EE Handout

J2EE

©Copyright 2004, Cognizant Academy, All Rights Reserved 110

Chapter 6: Design Patterns

Learning Objective

After completing this chapter, you will be able to:

q Understand various design patterns like MVC, Factory, Singleton

q Know about Transfer object and Session Facade

Introduction

Design patterns are recurring solutions to software design problems you find again and again

in real-world application development. Design patterns are about design and interaction of

objects, as well as providing a communication platform concerning elegant, reusable solutions

to commonly encountered programming challenges.

The knowledge of the following patterns will help you to fit business requirements into object

models that is proven for efficiency in an enterprise application

MVC pattern

When developing an application to support a single type of client, it is sometimes beneficial to

interweave data access and business rules logic with interface-specific logic for presentation

and control. Such an approach, however, is inadequate when applied to enterprise systems

that need to support multiple types of clients. Different applications need to be developed, one

to support each type of client interface. Non-interface-specific code is duplicated in each

application, resulting in duplicate efforts in implementation (often of the copy-and-paste

variety), as well as testing and maintenance. The task of determining what to duplicate is

expensive in itself, since interface-specific and non-interface-specific code are intertwined.

The duplication efforts are inevitably imperfect. Slowly, but surely, applications that are

supposed to provide the same core functionality evolve into different systems.

By applying the Model-View-Controller (MVC) architecture to a Java 2 Platform, Enterprise

Edition (J2EE) application, you separate core business model functionality from the

presentation and control logic that uses this functionality. Such separation allows multiple

views to share the same enterprise data model, which makes supporting multiple clients

easier to implement, test, and maintain.

Page 111: J2EE Handout

J2EE

©Copyright 2004, Cognizant Academy, All Rights Reserved 111

The following diagram represents the Model-View-Controller pattern:

The MVC architecture is applied to map the traditional input, processing, and output tasks to

the graphical user interaction model. However, it is straightforward to map these concepts into

the domain of multi-tier enterprise applications.

Model - The model represents enterprise data and the business rules that govern access to

and updates of this data. Often the model serves as a software approximation to a real-world

process, so simple real-world modeling techniques apply when defining the model.

View -The view renders the contents of a model. It accesses enterprise data through the

model and specifies how that data should be presented. It is the view's responsibility to

maintain consistency in its presentation when the model changes. This can be achieved by

using a push model, where the view registers itself with the model for change notifications, or

a pull model, where the view is responsible for calling the model when it needs to retrieve the

most current data.

Controller - The controller translates interactions with the view into actions to be performed

by the model. In a stand-alone GUI client, user interactions could be button clicks or menu

selections, whereas in a Web application, they appear as GET and POST HTTP requests.

The actions performed by the model include activating business processes or changing the

state of the model. Based on the user interactions and the outcome of the model actions, the

controller responds by selecting an appropriate view.

Singleton Pattern

This pattern ensures that a class has only one instance and provide a global point of access

to it. A singleton class is shown in the following class diagram:-

Page 112: J2EE Handout

J2EE

©Copyright 2004, Cognizant Academy, All Rights Reserved 112

The singleton class achieves this by:-

q Having a private constructor

q Holding a static instance within itself that can be accessed by an instance() or

getInstance() method. The getInstance() method lazy-initialized the static

instance of the object.

public static Singleton getInstance() {

If (instance == null) {

instance = new Singleton()

} return instance;

}

The singleton pattern is used for:

q An object that caches read only data for an application

q An object that has no state but has some calculation (There is no need to create

multiple instances of such an object and waste memory)

Factory Pattern

This pattern defines an interface for creating an object, but let subclasses decide which class

to instantiate. Factory Method lets a class defer instantiation to subclasses

The classes and/or objects participating in this pattern are (The class name mentioned in

bracket are examples. For example, Page is an example product):

q Product (Page) defines the interface of objects the factory method creates

q ConcreteProduct (EducationPage, ExperiencePage) implements the Product

interface

Page 113: J2EE Handout

J2EE

©Copyright 2004, Cognizant Academy, All Rights Reserved 113

q Creator (Document) declares the factory method, which returns an object of

type Product. Creator may also define a default implementation of the factory

method that returns a default ConcreteProduct object. may call the factory

method to create a Product object.

q ConcreteCreator (Report, Resume) overrides the factory method to return an

instance of a ConcreteProduct

In the above example, the code will look like:-

(Assume that Page is the parent class for EducationPage and ExperiencePage)

public interface Document {

Page createPage(); // The factory method

}

public class Report {

public Page createPage () { // The implementation

return new EducationPage();

}

}

public class Report {

public Page createPage () { // The implementation

return new ExperiencePage();

}

}

Page 114: J2EE Handout

J2EE

©Copyright 2004, Cognizant Academy, All Rights Reserved 114

Client code will look like:-

Document doc = new Report();

Page page = doc.createPage()

This code will fetch the EducationPage object and the client need not know the method of

creation of EducationPage. The client even need not know that the page that is returned is an

EductaionPage. In another day, if it is decided that the Report creates a ProgressPage, then

the clinet code need not change, only the createPage() in Report class need to change.

Hence the pattern is used to hide the details of creation of an object (EducationPage)

EJB technology used factory pattern in its HomeInterface. The create method is the factory

method.

Transfer/Value Object

Java 2 Platform, Enterprise Edition (J2EE) applications implement server-side business

components as session beans and entity beans. Some methods exposed by the business

components return data to the client. Often, the client invokes a business object's get

methods multiple times until it obtains all the attribute values.

Session beans represent the business services and are not shared between users. A session

bean provides coarse-grained service methods when implemented per the Session Facade

pattern.

Entity beans, on the other hand, are multiuser, transactional objects representing persistent

data. An entity bean exposes the values of attributes by providing an accessor method (also

referred to as a getter or get method) for each attribute it wishes to expose.

Every method call made to the business service object, be it an entity bean or a session

bean, is potentially remote. Thus, in an Enterprise JavaBeans (EJB) application such remote

invocations use the network layer regardless of the proximity of the client to the bean,

creating a network overhead. Enterprise bean method calls may permeate the network layers

of the system even if the client and the EJB container holding the entity bean are both running

in the same JVM, OS, or physical machine. Some vendors may implement mechanisms to

reduce this overhead by using a more direct access approach and bypassing the network.

As the usage of these remote methods increases, application performance can significantly

degrade. Therefore, using multiple calls to get methods that return single attribute values is

inefficient for obtaining data values from an enterprise bean.

Page 115: J2EE Handout

J2EE

©Copyright 2004, Cognizant Academy, All Rights Reserved 115

The following issues are there with this remote communication:-

q All access to an enterprise bean is performed via remote interfaces to the bean.

Every call to an enterprise bean is potentially a remote method call with network

overhead.

q Typically, applications have a greater frequency of read transactions than update

transactions. The client requires the data from the business tier for presentation,

display, and other read-only types of processing. The client updates the data in

the business tier much less frequently than it reads the data.

q The client usually requires values for more than one attribute or dependent object

from an enterprise bean. Thus, the client may invoke multiple remote calls to

obtain the required data.

q The number of calls made by the client to the enterprise bean impacts network

performance. Chattier applications-those with increased traffic between client and

server tiers-often degrade network performance.

The solution is to use a Transfer Object to encapsulate the business data. A single method

call is used to send and retrieve the Transfer Object. When the client requests the enterprise

bean for the business data, the enterprise bean can construct the Transfer Object, populate it

with its attribute values, and pass it by value to the client.

Clients usually require more than one value from an enterprise bean. To reduce the number

of remote calls and to avoid the associated overhead, it is best to use Transfer Objects to

transport the data from the enterprise bean to its client.

When an enterprise bean uses a Transfer Object, the client makes a single remote method

invocation to the enterprise bean to request the Transfer Object instead of numerous remote

method calls to get individual attribute values. The enterprise bean then constructs a new

Transfer Object instance, copies values into the object and returns it to the client. The client

receives the Transfer Object and can then invoke accessor (or getter) methods on the

Transfer Object to get the individual attribute values from the Transfer Object. Or, the

implementation of the Transfer Object may be such that it makes all attributes public.

Because the Transfer Object is passed by value to the client, all calls to the Transfer Object

instance are local calls instead of remote method invocations.

This class diagram that represents the Transfer Object pattern in its simplest form:-

Page 116: J2EE Handout

J2EE

©Copyright 2004, Cognizant Academy, All Rights Reserved 116

The sequence diagram that shows the interactions for the Transfer Object pattern:-

Client

This represents the client of the enterprise bean. The client can be an end-user application,

as in the case of a rich client application that has been designed to directly access the

Page 117: J2EE Handout

J2EE

©Copyright 2004, Cognizant Academy, All Rights Reserved 117

enterprise beans. The client can be Business Delegates (see "Business Delegate" on page

248) or a different BusinessObject.

BusinessObject

The BusinessObject represents a role in this pattern that can be fulfilled by a session bean,

an entity bean, or a Data Access Object (DAO). The BusinessObject is responsible for

creating the Transfer Object and returning it to the client upon request. The BusinessObject

may also receive data from the client in the form of a Transfer Object and use that data to

perform an update.

TransferObject

The TransferObject is an arbitrary serializable Java object referred to as a Transfer Object. A

Transfer Object class may provide a constructor that accepts all the required attributes to

create the Transfer Object. The constructor may accept all entity bean attribute values that

the Transfer Object is designed to hold. Typically, the members in the Transfer Object are

defined as public, thus eliminating the need for get and set methods. If some protection is

necessary, then the members could be defined as protected or private, and methods are

provided to get the values. By offering no methods to set the values, a Transfer Object is

protected from modification after its creation. If only a few members are allowed to be

modified to facilitate updates, then methods to set the values can be provided. Thus, the

Transfer Object creation varies depending on an application's requirements. It is a design

choice as to whether the Transfer Object's attributes are private and accessed via getters and

setters, or all the attributes are made public.

Session Façade

Enterprise beans encapsulate business logic and business data and expose their interfaces,

and thus the complexity of the distributed services, to the client tier.

In a multitiered Java 2 Platform, Enterprise Edition (J2EE) application environment, the

following problems arise:

Tight coupling, which leads to direct dependence between clients and business objects;

Too many method invocations between client and server, leading to network performance

problems;

Lack of a uniform client access strategy, exposing business objects to misuse.

A multitiered J2EE application has numerous server-side objects that are implemented as

enterprise beans. In addition, some other arbitrary objects may provide services, data, or

both. These objects are collectively referred to as business objects, since they encapsulate

business data and business logic.

J2EE applications implement business objects that provide processing services as session

beans. Coarse-grained business objects that represent an object view of persistent storage

and are shared by multiple users are usually implemented as entity beans.

Page 118: J2EE Handout

J2EE

©Copyright 2004, Cognizant Academy, All Rights Reserved 118

Application clients need access to business objects to fulfill their responsibilities and to meet

user requirements. Clients can directly interact with these business objects because they

expose their interfaces. When you expose business objects to the client, the client must

understand and be responsible for the business data object relationships, and must be able to

handle business process flow.

However, direct interaction between the client and the business objects leads to tight coupling

between the two, and such tight coupling makes the client directly dependent on the

implementation of the business objects. Direct dependence means that the client must

represent and implement the complex interactions regarding business object lookups and

creations, and must manage the relationships between the participating business objects as

well as understand the responsibility of transaction demarcation.

As client requirements increase, the complexity of interaction between various business

objects increases. The client grows larger and more complex to fulfill these requirements. The

client becomes very susceptible to changes in the business object layer; in addition, the client

is unnecessarily exposed to the underlying complexity of the system.

Tight coupling between objects also results when objects manage their relationship within

themselves. Often, it is not clear where the relationship is managed. This leads to complex

relationships between business objects and rigidity in the application. Such lack of flexibility

makes the application less manageable when changes are required.

When accessing the enterprise beans, clients interact with remote objects. Network

performance problems may result if the client directly interacts with all the participating

business objects. When invoking enterprise beans, every client invocation is potentially a

remote method call. Each access to the business object is relatively fine-grained. As the

number of participants increases in a scenario, the number of such remote method calls

increases. As the number of remote method calls increases, the chattiness between the client

and the server-side business objects increases. This may result in network performance

degradation for the application, because the high volume of remote method calls increases

the amount of interaction across the network layer.

A problem also arises when a client interacts directly with the business objects. Since the

business objects are directly exposed to the clients, there is no unified strategy for accessing

the business objects. Without such a uniform client access strategy, the business objects are

exposed to clients and may reduce consistent usage.

The following issues are to be noted in relation to this pattern:-

q Provide a simpler interface to the clients by hiding all the complex interactions

between business components.

q Reduce the number of business objects that are exposed to the client across the

service layer over the network.

q Hide from the client the underlying interactions and interdependencies between

business components. This provides better manageability, centralization of

interactions (responsibility), greater flexibility, and greater ability to cope with

changes.

q Provide a uniform coarse-grained service layer to separate business object

implementation from business service abstraction.

Page 119: J2EE Handout

J2EE

©Copyright 2004, Cognizant Academy, All Rights Reserved 119

q Avoid exposing the underlying business objects directly to the client to keep tight

coupling between the two tiers to a minimum.

To solve this, use a session bean as a facade to encapsulate the complexity of interactions

between the business objects participating in a workflow. The Session Facade manages the

business objects, and provides a uniform coarse-grained service access layer to clients.

The Session Facade abstracts the underlying business object interactions and provides a

service layer that exposes only the required interfaces. Thus, it hides from the client's view

the complex interactions between the participants. The Session Facade manages the

interactions between the business data and business service objects that participate in the

workflow, and it encapsulates the business logic associated with the requirements. Thus, the

session bean (representing the Session Facade) manages the relationships between

business objects. The session bean also manages the life cycle of these participants by

creating, locating (looking up), modifying, and deleting them as required by the workflow. In a

complex application, the Session Facade may delegate this lifestyle management to a

separate object. For example, to manage the lifestyle of participant session and entity beans,

the Session Facade may delegate that work to a Service Locator object.

It is important to examine the relationship between business objects. Some relationships

between business objects are transient, which means that the relationship is applicable to

only that interaction or scenario. Other relationships may be more permanent. Transient

relationships are best modeled as workflow in a facade, where the facade manages the

relationships between the business objects. Permanent relationships between two business

objects should be studied to determine which business object (if not both objects) maintains

the relationship.

Sample Code

Implementing the Session Façade

Page 120: J2EE Handout

J2EE

©Copyright 2004, Cognizant Academy, All Rights Reserved 120

Consider a Professional Services Application (PSA), where the workflow related to entity

beans (such as Project, Resource) is encapsulated in ProjectResourceManagerSession,

implemented using the Session Facade pattern. The following example shows the interaction

with Resource and Project entity beans, as well as other business components, like Value List

Handlers and Transfer Object Assemblers.

Implementing Session Facade - Session Bean

package corepatterns.apps.psa.ejb;

import java.util.*;

import java.rmi.RemoteException;

import javax.ejb.*;

import javax.naming.*;

import corepatterns.apps.psa.core.*;

import corepatterns.util.ServiceLocator;

import corepatterns.util.ServiceLocatorException;

// Note: all try/catch details not shown for brevity.

public class ProjectResourceManagerSession

implements SessionBean {

private SessionContext context;

// Remote references for the

// entity Beans encapsulated by this facade

private Resource resourceEntity = null;

private Project projectEntity = null;

...

// default create

public void ejbCreate()

throws CreateException {

}

// create method to create this facade and to

// establish connections to the required entity

// beans

// using primary key values

Page 121: J2EE Handout

J2EE

©Copyright 2004, Cognizant Academy, All Rights Reserved 121

public void ejbCreate(

String resourceId, String projectId, ...)

throws CreateException, ResourceException {

try {

// locate and connect to entity beans

connectToEntities(resourceId, projectId, ...);

} catch(...) {

// Handle exceptions

}

}

// method to connect the session facade to its

// entity beans using the primary key values

private void connectToEntities (

String resourceId, String projectId)

throws ResourceException {

resourceEntity = getResourceEntity(resourceId);

projectEntity = getProjectEntity(projectId);

...

}

// method to reconnect the session facade to a

// different set of entity beans using primary key

// values

public resetEntities(String resourceId,

String projectId, ...)

throws PSAException {

connectToEntities(resourceId, projectId, ...);

}

// private method to get Home for Resource

private ResourceHome getResourceHome()

throws ServiceLocatorException {

return ServiceLocator. getInstance().getHome(

"ResourceEntity", ResourceHome.class);

}

Page 122: J2EE Handout

J2EE

©Copyright 2004, Cognizant Academy, All Rights Reserved 122

// private method to get Home for Project

private ProjectHome getProjectHome()

throws ServiceLocatorException {

return ServiceLocator. getInstance().getHome(

"ProjectEntity", ProjectHome.class);

}

// private method to get Resource entity

private Resource getResourceEntity(

String resourceId) throws ResourceException {

try {

ResourceHome home = getResourceHome();

return (Resource)

home.findByPrimaryKey(resourceId);

} catch(...) {

// Handle exceptions

}

}

// private method to get Project entity

private Project getProjectEntity(String projectId)

throws ProjectException {

// similar to getResourceEntity

...

}

// Method to encapsulate workflow related

// to assigning a resource to a project.

// It deals with Project and Resource Entity beans

public void assignResourceToProject(int numHours)

throws PSAException {

try {

if ((projectEntity == null) ¦¦

(resourceEntity == null)) {

// SessionFacade not connected to entities

throw new PSAException(...);

}

Page 123: J2EE Handout

J2EE

©Copyright 2004, Cognizant Academy, All Rights Reserved 123

// Get Resource data

ResourceTO resourceTO =

resourceEntity.getResourceData();

// Get Project data

ProjectTO projectTO =

projectEntity.getProjectData();

// first add Resource to Project

projectEntity.addResource(resourceTO);

// Create a new Commitment for the Project

CommitmentTO commitment = new

CommitmentTO( ...);

// add the commitment to the Resource

projectEntity.addCommitment(commitment);

} catch(...) {

// Handle exceptions

}

}

// Similarly implement other business methods to

// facilitate various use cases/interactions

public void unassignResourceFromProject()

throws PSAException {

...

}

// Methods working with ResourceEntity

public ResourceTO getResourceData()

throws ResourceException {

...

}

// Update Resource Entity Bean

public void setResourceData(ResourceTO resource)

throws ResourceException {

...

Page 124: J2EE Handout

J2EE

©Copyright 2004, Cognizant Academy, All Rights Reserved 124

}

// Create new Resource Entity bean

public ResourceTO createNewResource(ResourceTO

resource) throws ResourceException {

...

}

// Methods for managing resource's blockout time

public void addBlockoutTime(Collection blockoutTime)

throws RemoteException,BlockoutTimeException {

...

}

public void updateBlockoutTime(

Collection blockoutTime)

throws RemoteException, BlockoutTimeException {

...

}

public Collection getResourceCommitments()

throws RemoteException, ResourceException {

...

}

// Methods working with ProjectEntity

public ProjectTO getProjectData()

throws ProjectException {

...

}

// Update Project Entity Bean

public void setProjectData(ProjectTO project)

throws ProjectException {

...

}

// Create new Project Entity bean

public ProjectTO createNewProject(ProjectTO project)

Page 125: J2EE Handout

J2EE

©Copyright 2004, Cognizant Academy, All Rights Reserved 125

throws ProjectException {

...

}

...

// Other session facade method examples

// This proxies a call to a Transfer Object Assembler

// to obtain a composite Transfer Object.

// See Transfer Object Assembler pattern

public ProjectCTO getProjectDetailsData()

throws PSAException {

try {

ProjectTOAHome projectTOAHome = (ProjectTOAHome)

ServiceLocator.getInstance().getHome(

"ProjectTOA", ProjectTOAHome.class);

// Transfer Object Assembler session bean

ProjectTOA projectTOA =

projectTOAHome.create(...);

return projectTOA.getData(...);

} catch (...) {

// Handle / throw exceptions

}

}

// These method proxies a call to a ValueListHandler

// to get a list of projects. See Value List Handler

// pattern.

public Collection getProjectsList(Date start,

Date end) throws PSAException {

try {

ProjectListHandlerHome projectVLHHome =

(ProjectVLHHome)

ServiceLocator.getInstance().getHome(

"ProjectListHandler",

ProjectVLHHome.class);

// Value List Handler session bean

ProjectListHandler projectListHandler =

Page 126: J2EE Handout

J2EE

©Copyright 2004, Cognizant Academy, All Rights Reserved 126

projectVLHHome.create();

return projectListHandler.getProjects(

start, end);

} catch (...) {

// Handle / throw exceptions

}

}

...

public void ejbActivate() {

...

}

public void ejbPassivate() {

context = null;

}

public void setSessionContext(SessionContext ctx) {

this.context = ctx;

}

public void ejbRemove() {

...

}

}

The remote interface for the Session Facade is listed in the following example

Implementing Session Facade - Remote Interface

package corepatterns.apps.psa.ejb;

import java.rmi.RemoteException;

import javax.ejb.*;

import corepatterns.apps.psa.core.*;

// Note: all try/catch details not shown for brevity.

public interface ProjectResourceManager

Page 127: J2EE Handout

J2EE

©Copyright 2004, Cognizant Academy, All Rights Reserved 127

extends EJBObject {

public resetEntities(String resourceId,

String projectId, ...)

throws RemoteException, ResourceException ;

public void assignResourceToProject(int numHours)

throws RemoteException, ResourceException ;

public void unassignResourceFromProject()

throws RemoteException, ResourceException ;

...

public ResourceTO getResourceData()

throws RemoteException, ResourceException ;

public void setResourceData(ResourceTO resource)

throws RemoteException, ResourceException ;

public ResourceTO createNewResource(ResourceTO resource)

throws ResourceException ;

public void addBlockoutTime(Collection blockoutTime)

throws RemoteException,BlockoutTimeException ;

public void updateBlockoutTime(Collection blockoutTime)

throws RemoteException,BlockoutTimeException ;

public Collection getResourceCommitments()

throws RemoteException, ResourceException;

public ProjectTO getProjectData()

throws RemoteException, ProjectException ;

public void setProjectData(ProjectTO project)

throws RemoteException, ProjectException ;

public ProjectTO createNewProject(ProjectTO project)

Page 128: J2EE Handout

J2EE

©Copyright 2004, Cognizant Academy, All Rights Reserved 128

throws RemoteException, ProjectException ;

...

public ProjectCTO getProjectDetailsData()

throws RemoteException, PSAException ;

public Collection getProjectsList(Date start,

Date end) throws RemoteException, PSAException ;

...

}

The Home interface for the Session Facade is shown in the following example

Implementing Session Facade - Home Interface

package corepatterns.apps.psa.ejb;

import javax.ejb.EJBHome;

import java.rmi.RemoteException;

import corepatterns.apps.psa.core.ResourceException;

import javax.ejb.*;

public interface ProjectResourceManagerHome

extends EJBHome {

public ProjectResourceManager create()

throws RemoteException,CreateException;

public ProjectResourceManager create(String

resourceId, String projectId, ...)

throws RemoteException,CreateException;

}

SUMMARY

After completing this chapter, you have learned:

q Various design patterns like MVC, Factory, Singleton

q Know about Transfer object and Session Facade

Page 129: J2EE Handout

J2EE

©Copyright 2004, Cognizant Academy, All Rights Reserved 129

Chapter7: J2EE Best Practices & Performance Tips

Learning Objective

After completing this chapter, you will be able to:

q Learn the best practices and how to use that while designing any J2EE

architecture

Page 130: J2EE Handout

J2EE

©Copyright 2004, Cognizant Academy, All Rights Reserved 130

Introduction

As J2EE got eveloved best practices also eveloved along with its growth. A top 12 list of the

most important best practices for J2EE application development.These needs to be

considered while desiging any J2EE applications

1. Always use MVC.

Cleanly separate Business Logic (Java beans and EJB components) from Controller Logic

(Servlets/Struts actions) from Presentation (JSP, XML/XSLT). Good layering can cover a

multitude of sins.

This practice is so central to the successful adoption of J2EE that there is no competition for

the #1 slot. Model-View-Controller (MVC) is fundamental to the design of good J2EE

applications. It is simply the division of labor of your programs into the following parts:

Those responsible for business logic (the Model -- often implemented using Enterprise

Java™Beans or plain old Java objects).

Those responsible for presentation of the user interface (the View -- usually implemented with

JSP and tag libraries, but sometimes with XML and XSLT).

Those responsible for application navigation (the Controller -- usually implemented with Java

Servlets or associated classes like Struts controllers).

There are a number of problems that can emerge from not following basic MVC architecture.

The most problems occur from putting too much into the View portion of the architecture.

Practices like using JSP tag libraries to perform database access, or performing application

flow control within a JSP are relatively common in small-scale applications, but these can

cause issues in later development as JSPs become progressively more difficult to maintain

and debug.

Likewise, we often see migration of view layer constructs into business logic. For instance, a

common problem is to push XML parsing technologies used in the construction of views into

the business layer. The business layer should operate on business objects -- not on a

particular data representation tied to the view.

However, just having the proper components does not make your application properly

layered. It is quite common to find applications that have all three of servlets, JSPs, and EJB

components, where the majority of the business logic is done in the servlet layer, or where

application navigation is handled in the JSP. You must be rigorous about code review and

refactoring to ensure that business logic is handled in the Model layer only, that application

navigation is solely the province of the Controller layer, and that your Views are simply

concerned with rendering model objects into appropriate HTML and Javascript.

2. Apply automated unit tests and test harnesses at every layer.

Don't just test your GUI. Layered testing makes debugging and maintenance vastly simpler.

Page 131: J2EE Handout

J2EE

©Copyright 2004, Cognizant Academy, All Rights Reserved 131

There has been quite a shake-up in the methodology world over the past several years as

new, lightweight methods that call themselves Agile (such as SCRUM [Schwaber] and

Extreme Programming [Beck1] in Resources) become more commonplace. One of the

hallmarks of nearly all of these methods is that they advocate the use of automated testing

tools to improve programmer productivity by helping developers spend less time regression

testing, and to help them avoid bugs caused by inadequate regression testing. In fact, a

practice called Test-First Development [Beck2] takes this practice even further by advocating

that unit tests be written prior to the development of the actual code itself. However, before

you can test your code, you need to isolate it into testable fragments. A "big ball of mud" is

hard to test because it does not do a single, easily identifiable function. If each segment of

your code does several things, it is hard to test each bit for correctness.

One of the advantages of the MVC architecture (and the J2EE implementation of MVC) is that

the componentization of the elements make it possible (in fact, relatively easy) to test your

application in pieces. Therefore, you can easily write tests to separately test Entity beans,

Session beans, and JSPs outside of the rest of the code base. There are a number of

frameworks and tools for J2EE testing that make this process easier. For instance, JUnit,

which is an open-source tool developed by junit.org, and Cactus, which is an open source

project of the Apache consortium, are both quite useful for testing J2EE components.

[Hightower] discusses the use of these tools for J2EE in detail.

Despite all of the great information about deeply testing your application, we still see many

projects that believe that if they test the GUI (which may be a Web based GUI or a standalone

Java application), then they have comprehensively tested the entire application. GUI testing is

rarely enough. There are several reasons for this. First, with GUI testing, it is difficult to test

every path through the system. The GUI is only one way of affecting the system. There may

be background jobs, scripts, and various other access points that also need to be tested.

Often, however, they do not have GUIs. Secondly, testing at the GUI level is very coarse

grained. It tests at the macro level of the system how the system behaves. This means that if

problems are found, entire subsystems must be considered, making finding the bugs

identified difficult. Third, GUI testing usually cannot be done well until late in the development

cycle when the GUI is fully defined. This means that latent bugs will not be found

systematically until very late. Fourth, average developers probably do not have access to

automatic GUI testing tools. Thus, when a developer makes a change, there is no easy way

for that developer to retest the affected subsystem. This actually discourages good testing. If

the developer has access to automated code level unit tests, the developer can easily run

them to make sure the changes do not break existing function. Finally, if automated builds are

done, it is fairly easy to add an automated unit testing suite to the automated build process.

By doing this, the system can be rebuilt regularly (often nightly) and regression-tested with

little human intervention.

In addition, we must emphasize that distributed, component based development with EJBs

and Web services makes testing your individual components absolutely necessary. When

there is no "GUI" to test, you must then fall back on lower-level tests. It is best to start that

way, and spare yourself the headache of having to retrofit your process to include those tests

when the time comes to expose part of your application as a distributed component or Web

service.

In summary, by using automated unit tests, defects are found sooner, defects are easier to

find, testing can be made more systematic, and thus, overall quality is improved.

Page 132: J2EE Handout

J2EE

©Copyright 2004, Cognizant Academy, All Rights Reserved 132

3. Develop to the specifications, not the application server.

Know the specifications by heart and deviate from them only after careful consideration. Just

because you can do something doesn't mean you should.

It is very easy to cause yourself grief by trying to play around at the edges of what J2EE

allows you to do. We find developers dig themselves into a hole by trying something that they

think will work "a little better" than what J2EE allows, only to find that it causes serious

problems in performance, or in migration (from vendor to vendor, or more commonly from

version to version) later. In fact, this is such an issue with migrations, that [Beaton] calls this

principle out as the primary best practice for Migration efforts.

There are several places in which not taking the most straightforward approach can definitely

cause problems. A common one today is where developers take over J2EE security through

the use of JAAS modules rather than relying on built-in spec compliant application server

mechanisms for authentication and authorization. Be very wary of going beyond the

authentication mechanisms provided by the J2EE specification. This can be a major source of

security holes and vendor compatibility problems. Likewise, rely on the authorization

mechanisms provided by the servlet and EJB specs, and where you need to go beyond them,

make sure you use the spec's APIs (such as getCallerPrincipal()) as the basis for your

implementation. This way you will be able to leverage the vendor-provided strong security

infrastructure and, where business needs require, support more complex authorization rules.

Other common problems include using persistence mechanisms that are not tied into the

J2EE spec (making transaction management difficult), relying on inappropriate J2SE facilities

like threading or singletons within your J2EE programs, and "rolling your own" solutions for

program-to-program communication instead of staying within supported mechanisms like

JCA, JMS, or Web services. Such design choices cause no end of difficulty when moving

from one J2EE compliant server to another, or even when moving to new versions of the

same server. Using elements outside of J2EE often causes subtle portability problems. The

only time you should ever deviate from a spec is when there is a clear problem that cannot be

addressed within the spec. For instance, scheduling the execution of timed business logic

was a problem prior to the introduction of EJB 2.1. In cases like this, we may recommend

using vendor-provided solutions where available (such as the Scheduler facility in

WebSphere® Application Server Enterprise), or to use third-party tools where these are not

available. In this way, maintenance and migration to later spec versions becomes the problem

of the vendor, and not your own problem.

Finally, be careful about adopting new technologies too early. Overzealously adopting a

technology before it has been integrated into the rest of the J2EE specification, or into a

vendor's product, is often a recipe for disaster. Support is critical -- if your vendor does not

directly support a particular technology proposed in a JSR but not yet accepted into J2EE,

you should probably not pursue it. After all, with rare exceptions, most of us are in the

business of solving business problems, not advancing technology for the sheer fun of it.

4. Plan for using J2EE security from Day One.

Turn on WebSphere security. Lock down all your EJBs and URLs to at least all authenticated

users. Don't even ask -- just do it.

Page 133: J2EE Handout

J2EE

©Copyright 2004, Cognizant Academy, All Rights Reserved 133

It is a continual source of astonishment to us how few customers we work with originally plan

to turn on WebSphere's J2EE security. In our estimate around 50% of the customers we see

initially plan to use this feature. For instance, we have worked with several major financial

institutions (banks, brokerages, and so on) that did not plan on turning security on; luckily this

problem was fixed in review prior to deployment.

Not leveraging J2EE security is a dangerous game. Assuming your application requires

security (almost all do), you are betting that your developers can build a better security

infrastructure than the one you bought from the J2EE vendor. That's not a good bet. Securing

a distributed application is extraordinarily difficult. For example, you need to control access to

EJBs using a network safe encrypted token. In our experience, most home-grown security

infrastructures are not secure; with significant weaknesses that leave production systems

terribly vulnerable. (Refer to chapter 18 of [Barcia] for more.)

Reasons cited for not using J2EE security include: fear of performance degradation, belief

that other security products like Netegrity SiteMinder handle this, or ignorance of the features

and capabilities of WebSphere Application Server security. Do not fall into these traps. In

particular, while products like SiteMinder provide excellent security features, they alone

cannot secure an entire J2EE application. They must work hand in hand with the J2EE

application server to secure all aspects of the system.

Another common reason given for not using J2EE security is that the role-based model does

not provide sufficiently granular access control to meet complex business rules. Though this

is often true, this is not a reason to avoid J2EE security. Instead, leverage the J2EE

authentication model and J2EE roles in conjunction with your specific extended rules. If a

complex business rule is needed to make a security decision, write the code to do it, basing

the decision upon the readily available and trustable J2EE authentication information (the

user's ID and roles).

5. Build what you know.

Iterative development allows you to gradually master all the moving pieces of J2EE. Build

small, vertical slices through your application rather than doing everything at once.

Let's face it, J2EE is big. If a development team is just starting with J2EE, it is far too difficult

to try to learn it all at once. There are simply too many concepts and APIs to master. The key

to success in this environment is to take J2EE on in small, controlled steps.

This approach is best implemented through building small, vertical slices through your

application. Once a team has built its confidence by building a simple domain model and

back-end persistence mechanism (perhaps using JDBC) and thoroughly tested that model,

they can then move on to mastering front-end development with servlets and JSPs that use

that domain model. If a development team finds a need for EJBs, they could likewise start

with simple Session Facades atop Container-Managed persistence EJB components or

JDBC-based Data Access Objects (DAOs) before moving on to more sophisticated constructs

like Message-Driven beans and JMS.

This approach is nothing new, but relatively few teams actually build their skills in this way.

Instead, most teams cave in to schedule pressures by trying to build everything at once --

they attack the View layer, the Model Layer, and the Controller layer in MVC, simultaneously.

Instead, consider some of the new Agile development methods, such as Extreme

Page 134: J2EE Handout

J2EE

©Copyright 2004, Cognizant Academy, All Rights Reserved 134

Programming (XP), that foster this kind of incremental learning and development. There is a

procedure often used in XP called ModelFirst [Wiki] that involves building the domain model

first as a mechanism for organizing and implementing your User Stories. Basically, you build

the domain model as part of the first set of User Stories you implement, and then build a UI

on top of it as a result of implementing later User Stories. This fits very well with letting a team

learn technologies one at a time, as opposed to sending them to a dozen simultaneous

classes (or letting them read a dozen books), which can be overwhelming.

Also, iterative development of each application layer fosters the application of appropriate

patterns and best practices. If you begin with the lower layers of your application and apply

patterns like Data Access Objects and Session Facades, you should not end up with domain

logic in your JSPs and other View objects.

Finally, when you do development in thin vertical slices, it makes it easier to start early in

performance testing your application. Delaying performance testing until the end of an

application development cycle is a sure recipe for disaster, as [Joines] relates.

6. Always use Session Facades whenever you use EJB components.

Never expose Entity beans directly to any client type. Only use Local EJB interfaces for Entity

types.

Using a session facade is one of the best-established best practices for the use of EJB

components. In fact, the general practice is widely advocated for any distributed technology,

including CORBA, EJB, and DCOM. Basically, the lower the distribution "cross-section" of

your application, the less time will be wasted in overhead caused by multiple, repeated

network hops for small pieces of data. The way to accomplish this is to create very large-

grained facade objects that wrap logical subsystems and that can accomplish useful business

functions in a single method call. Not only will this reduce network overhead, but within EJBs,

it also critically reduces the number of database calls by creating a single transaction context

for the entire business function.

EJB local interfaces, introduced as part of the EJB 2.0 specification, provide performance

optimization for co-located EJBs. Local interfaces must be explicitly called by your application,

requiring code changes and preventing the ability to later distribute the EJB without

application changes. Because the Session Facade and the entity EJBs it wraps should be

local to each other, we recommend using local interfaces for the entity beans behind the

Session Facade. However, the implementation of the Session Facade itself, typically a

stateless session bean, should be designed for remote interfaces.

For performance optimization, a local interface can be added to the Session Facade. This

takes advantage of the fact that most of the time, in Web applications at least, your EJB client

and the EJB will be co-located within the same JVM. Alternatively, J2EE application server

configuration optimizations, such as WebSphere "No Local Copies," can be used if the

Session Facade is invoked locally. However, you must be aware these alternatives change

the semantics of the interaction from pass-by-value to pass-by-reference. This can lead to

subtle errors in your code.

To take advantage of these options, you should plan for this possibility from the start.

Page 135: J2EE Handout

J2EE

©Copyright 2004, Cognizant Academy, All Rights Reserved 135

If you use a remote interface (as opposed to a local interface) for your Session Facade, then

you may also be able to expose that same Session Facade as a Web service in a J2EE 1.4

compliant way. (This is because JSR 109, the Web services deployment section of J2EE 1.4,

requires you to use the remote interface of a stateless session bean as the interface between

an EJB Web service and the EJB implementation.) Doing so is often desirable, since it can

increase the number of client types for your business logic.

7. Use stateless session beans instead of stateful session beans.

This makes your system more amenable to failover. Use the HttpSession to store user-

specific state.

Stateful session beans are, in our opinion, an idea whose time has come and gone. If you

think about it, a stateful session bean is exactly the same, architecturally, as a CORBA object

-- a single object instance, tied to a single server, which is dependent upon that server for its

life. If the server goes down, the object values are lost, and any clients of that bean are thus

out of luck.

J2EE application servers providing for stateful session bean failover can workaround some

issues, but stateful solutions are not as scalable as stateless ones. For example, in

WebSphere Application Server, requests for stateless session beans are load-balanced

across all of the members of a cluster where a stateless session bean has been deployed. In

contrast, J2EE application servers cannot load-balance requests to stateful beans. This

means load may be spread disproportionately across the servers in your cluster. In addition,

the use of stateful session beans pushes state to your application server which is undesirable.

It increases system complexity and complicates failure scenarios. One of the key principles of

robust distributed systems is stateless behavior whenever possible.

Therefore, we recommend that a stateless session bean approach be chosen for most

applications. Any user-specific state necessary for processing should either be passed in as

an argument to the EJB methods (and stored outside the EJB through a mechanism like the

HttpSession) or be retrieved as part of the EJB transaction from a persistent back-end store

(for instance, through the use of Entity beans). Where appropriate, this information can be

cached in memory, but beware of the potential challenges that surround keeping the cache

consistent in a distributed environment. Caching works best for read-only data.

In general, you should make sure that you plan for scalability from day one. Examine all the

assumptions in your design and see if they still hold if your application will run on more than

one server. This rule applies not only in application code in the cases outlined above, but also

to situations like MBeans and other administrative interfaces.

Avoiding statefulness is not merely an IBM/WebSphere recommendation based on supposed

limitations of the IBM tool suite; it is a basic J2EE design principle. See [Jewell] for Tyler

Jewell's acerbic opinions on stateful beans, which echo the statements made above.

8. Use container-managed transactions.

Learn how 2-phase commit transactions work in J2EE and rely on them rather than

developing your own transaction management. The container will almost always be better at

transaction optimization.

Page 136: J2EE Handout

J2EE

©Copyright 2004, Cognizant Academy, All Rights Reserved 136

Using container-managed transactions (CMTs) provides two key advantages that are nearly

impossible to obtain without container support: composable units of work, and robust

transactional behavior.

If your application code explicitly begins and ends transactions (perhaps using

javax.jts.UserTransaction, or even native resource transactions), future requirements to

compose modules, perhaps as part of a refactoring, often requires changing the transaction

code. For example, if module A begins a database transaction, updates the database and

then commits the transaction, and module B does the same, consider what happens when

you try to use both from module C. Now, module C, which is performing what is a single

logical action, is actually causing two independent transactions to occur. If module B were to

fail during an operation, module A's work is still committed. This is not the desired behavior. If,

instead, module A and module B both used CMTs, module C can also start a CMT (typically

implicitly via the deployment descriptor) and the work in modules A and B will be implicitly part

of the same unit of work without any need for complex rework.

If your application needs to access multiple resources as part of the same operation, you

need 2-phase commit transactions. For example, if a message is removed from a JMS queue

and then a record is updated in a database based on that message, it is important that both

operations occur -- or that neither occurs. If the message was removed from the queue and

then the system failed without updating the database, this system is inconsistent. Serious

customer and business implications result from inconsistent states.

We occasionally see client applications trying to implement their own solutions. Perhaps the

application code will try to "undo" the queue operation if the database update fails. We do not

recommend this. The implementation is much more complex than you initially think and there

are many corner cases (imagine what happens if the application crashes in the middle of

this). Instead, use 2-phase commit transactions. If you use CMT and access to 2-phase

commit capable resources (like JMS and most databases) in a single CMT, WebSphere will

take care of the dirty work. It will make sure that the transaction is entirely done or entirely not

done, including failure cases such as a system crash, database crash, or whatever. The

implementation maintains transactional state in transaction logs. We cannot emphasize

enough the need to rely on CMT transactions if the application accesses multiple resources.

9. Prefer JSPs as your first choice of presentation technology.

Use XML/XSLT only in cases where you have multiple presentation output types that must be

supported by a single controller and back-end.

There is a common argument that we often hear for why you should choose XML and XSLT

as your presentation technology over JSP. This is that JSP "allows you to mix model and

view" too much, and that XML/XSLT is somehow free from this problem. Unfortunately, this is

not quite true, or at least not as black and white as it may seem. XSL and XPath are, in

reality, programming languages. In fact, XSL is Turing-complete, even though it may not

match most people's definition of a programming language in that it is rules-based and does

not have all of the control facilities that programmers may be used to.

Page 137: J2EE Handout

J2EE

©Copyright 2004, Cognizant Academy, All Rights Reserved 137

The issue is that given this flexibility, developers will take advantage of it. While everyone

agrees that JSP makes it easy for developers to do "model-like" behaviors in the view, in fact,

it is possible to do some of the same kinds of things in XSL. While it is very difficult, if not

impossible, to do things like calling databases from XSL, we have seen some incredibly

complex XSLT stylesheets that perform difficult transformations that still amount to model

code.

However, the most basic reason why people should choose JSP as your first option for

presentation technology is simply because it is the best supported and best-understood J2EE

view technology available. Given the introduction of custom tag libraries, the JSTL, and the

new JSP 2.0 features, it is becoming increasingly easy to build JSPs that do not require any

Java code, and that cleanly separate model and view. There is significant support (including

debugging support) for JSP built into development environments like WebSphere Studio, and

many developers find developing with JSP easier than developing with XSL -- mostly due to

how JSP is procedurally based, as opposed to rules-based. While WebSphere Studio

supports XSL development, the graphical layout tools and other features supporting JSP

(especially when in the context of frameworks like JSF) make it much easier for developers to

work in a WYSIWYG way -- something that is not easily done with XSL.

The final reason to carefully consider using JSP is one of speed. Performance tests done at

IBM comparing the relative speed of XSL and JSP show that in most cases a JSP will be

several times faster at producing the same HTML output as an equivalent XSL transform,

even when compiled XSL is used. While this is often not an issue, in performance-critical

situations it can create problems.

This is not to say that you should never use XSL, however. There are certain cases where the

ability of XSL to take a single representation of a fixed set of data and render it in one of

several different ways based on different stylesheets (see [Fowler]) is the best solution for

rendering your views. However, this kind of requirement is most often the exception rather

than the rule. If you are only ever producing one HTML rendering for each page, then in most

cases, XSL is overkill, and it will cause more problems for your developers than it will solve.

Page 138: J2EE Handout

J2EE

©Copyright 2004, Cognizant Academy, All Rights Reserved 138

10. When using HttpSessions, store only as much state as you need for the current

business transaction and no more.

Enable session persistence.

HttpSessions are great for storing information about application state. The API is easy to use

and understand. Unfortunately, developers often lose sight of the intent of the HttpSession --

to maintain temporary user state. It is not an arbitrary data cache. We have seen far too many

systems that put enormous amounts of data -- megabytes -- for each user's session. Well, if

there are 1000 logged-in users, each with a 1 MB HTTP session, that is one gigabyte or more

of memory in use just for sessions. Keep those HTTP sessions small. If you don't, your

application's performance will suffer. A good rule of thumb is something under 2K-4K. This

isn't a hard rule. 8K is still okay, but obviously slower than 2K. Just keep your eye on it and

prevent the HttpSession from becoming a dumping ground for data that "might" be used.

One common problem is using HttpSessions to cache information that is easily recreated,

should it be necessary. Since sessions are persisted, this is a very expensive decision forcing

unnecessary serialization and writing of the data. Instead, use an in memory hash table to

cache the data and just keep a key to the data in the session. This allows the data to be

recreated should the user fail over to another application server. (See [Brown2] for more.)

Speaking of session persistence, don't forget to enable it. If you do not enable session

persistence, should a server be stopped for any reason (a server failure or ordinary

maintenance), any user that is currently on that application server will lose their session. That

makes for a very unpleasant experience. They have to log in again and redo whatever they

were working on. If, instead, session persistence is enabled, WebSphere will automatically

move the user (and their session) to another application server, transparently. They won't

even know it happened. This works so well, that we have seen production systems that crash

regularly due to nasty bugs in native code (not IBM code!) yet provide adequate service.

11. In WebSphere, turn on dynamic caching and use the WebSphere servlet caching

mechanism.

The performance gains are substantial; the overhead minimal. The programming model is

unaffected.

The merits of caching to improve performance are well understood. Unfortunately, the current

J2EE specification does not include a mechanism for servlet/JSP caching. However,

WebSphere provides support for page and fragment caching through its dynamic cache

function without requiring any application changes. The cache policy is specified declaratively

and configuration is through XML deployment descriptors. Therefore, your application is

unaffected, remaining J2EE specification compliant and portable, while benefiting from the

performance optimizations provided from WebSphere's servlet and JSP caching.

The performance gains from dynamic caching of servlets and JSPs can be substantial,

depending on the application characteristics. Cox and Martin [Cox] showcase performance

benefits up to a multiplier of 10 from applying dynamic caching to an existing RDF (Resource

Description Format) site summary (RSS) servlet. Please recognize that this experiment

involved a simple servlet, and this order of magnitude improvement may not be reflective of a

more complex application mix.

Page 139: J2EE Handout

J2EE

©Copyright 2004, Cognizant Academy, All Rights Reserved 139

For additional performance gains, the WebSphere servlet/JSP results cache is integrated with

the WebSphere plug-in ESI Fragment processor, the IBM HTTP Server Fast Response

Cache Accelerator (FRCA) and Edge Server caching capabilities. For heavy read-based

workloads, significant additional benefits are gained through leveraging these capabilities.

12. Prefer CMP Entity beans as a first-pass solution for O/R mapping due to the

programmer productivity benefits.

Optimize performance through the WebSphere framework (readahead, caching options,

isolation levels, and so on). If necessary, selectively apply patterns like Fast-Lane reader

[Marinescu] to achieve performance goals.

Object/Relational (O/R) mapping is fundamental to building enterprise-scale applications in

Java. Nearly every J2EE application needs some type of O/R mapping. J2EE vendors provide

an O/R mapping mechanism that is portable across vendors, efficient, and well-supported by

standards and tools. This is the CMP (Container-Managed Persistence) portion of the EJB

specification.

Early CMP implementations had a (perhaps) well-deserved reputation for underperforming

and not supporting many SQL constructs. However, as the EJB 2.0 and 2.1 specifications

were developed and adopted by vendors, and tools like IBM WebSphere Studio Application

Developer emerged, these concerns became no longer as valid as they once were.

CMP EJB components are now widely used in many high performing applications.

WebSphere includes optimizations to enhance the performance of EJB components including

life-time in cache and read-ahead capabilities. Both of these optimizations are deployment

options, and do not require application modifications or impact portability.

Life-time in cache caches CMP state data and provides time-based invalidation. The

performance gains from life-time in cache approach Option A caching performance, while still

providing capabilities for your application to scale in a cluster. Read-ahead capabilities are

used in conjunction with container managed relationships. This feature minimizes database

interactions by optionally retrieving associated data in the same query as the parent data.

This provides performance benefits if the associated data is typically going to be accessed

with a subsequent query. [Gunther] provides detailed descriptions and details the

performance improvements possible from these features.

In addition, to fully optimize your EJB components, pay close attention when specifying the

isolation level. Use the lowest isolation level possible while still maintaining integrity of your

data. Lower isolation levels provide optimal performance and reduce the risk of database

deadlocks.

This is by far the most contentious best practice of the lot. Volumes have been written in

praise of CMP EJBs, and condemning them as well. However, the basic problem here is that

database development is hard. You need to have a fundamental knowledge of how queries

and database locks work before beginning to use any persistence solution. If you choose to

use CMP EJBs, be sure you are well-educated in their use through books such as [Brown]

and [Barcia]. There are subtle interactions in locking and contention that are difficult to

understand, but which can be mastered given enough time and effort.

Page 140: J2EE Handout

J2EE

©Copyright 2004, Cognizant Academy, All Rights Reserved 140

J2EE Performance Tips

q Always use Session Facades whenever you use EJB components.

q Use stateless session beans instead of stateful session beans.

q When using HttpSessions, store only as much state as you need for the current

business transaction and no more.

q Prefer CMP Entity beans as a first-pass solution for O/R mapping due to the

programmer productivity benefits.

q Failure to remove an EJB that should have been removed (from the HTTP

session) carries a very high performance price: the EJB will be passivated which

is a very expensive operation.

q Use a dedicated session bean to perform and cache all JNDI lookups in a

minimum number of requests.

q Design coarse-grained EJB remote interfaces to reduce the number of network

calls required.

SUMMARY

After completing this chapter, you have learned:

q The best practices and how to use that while designing any J2EE architecture

Page 141: J2EE Handout

J2EE

©Copyright 2004, Cognizant Academy, All Rights Reserved 141

REFERENCES

WEBSITES

http://www.tutorgig.com/

http://www.java.sun.com/

http://www.enterprisedeveloper.com/developers

BOOKS

q EJB- mastering Enterprise Java Beans By Roman Ed

q Enterprise Java Beans By MONSON-HAEFEL RICHARD

q Enterprise Java Beans By Tom Valesky

q JAVA & XML By BRETT McLAUGHLIN

q JAVA Server Programming By AYERS DANNY ET AL

q JAVA Server Programming J2EE Ed Vol1 & Vol2 By KARL AVEDAL

Page 142: J2EE Handout

J2EE

©Copyright 2004, Cognizant Academy, All Rights Reserved 142

STUDENT NOTES: