DEPARTMENT OF COMPUTER ENGINEERING

LAB MANUAL
Sr.
No.
Title of experiment Pae
No.
1. Study report of any two design patterns.
2. Implementation of any two design patterns in
java .
3. Study report for any of the MVC based ramewor!s "#2$$%.
&. Study report on $#'.
(. Implementation of a web appli)ation for a system )overing
representative paper design of the system using navigation* )omponents*
interfa)es* its deployment issue with +M,.
-. .% /evelop dynami) and intera)tive web )lient using #S0*
S)ripting1.pplets1.)tive2 )ontrols.
'% /evelop server side programming with database handling1
servlets1$#'1webservi)e on server side with se)urity aspe)ts )overed.

A!!inment N"m#er$ %&
Title$ Study report of any two design patterns.
Aim$ Study report of any two design patterns.
O#'e(ti)e$ 3o study of /esign 0atterns .
T*eor+$
,*at i! a De!in Pattern-
$a)h pattern des)ribes a problem whi)h o))urs over and over again in our environment*
and then des)ribes the )ore of the solution to that problem* in su)h a way that you )an use
this solution a million times over* without ever doing it the same way twi)e. 4ur
solutions are e5pressed in terms of obje)ts and interfa)es./esign 0attern is general
reusable solution to )ommonly o))urring problems.
In general* a pattern has four essential elements6

1. 3he pattern name is a handle we )an use to des)ribe a design problem* its
solutions* and )onse7uen)es in a word or two. 8aming a pattern immediately
in)reases our design vo)abulary. It lets us design at a higher level of
abstra)tion. 9aving a vo)abulary for patterns lets us tal! about them with
our )olleagues* in our do)umentation* and even to ourselves. It ma!es it
easier to thin! about designs and to )ommuni)ate them and their trade:offs
to others. inding good names has been one of the hardest parts of developing
our )atalog.
2. 3he pro#lem des)ribes when to apply the pattern. It e5plains the problem
and its )onte5t. It might des)ribe spe)ifi) design problems su)h as how
to represent algorithms as obje)ts. It might des)ribe )lass or obje)t
stru)tures that are symptomati) of an infle5ible design. Sometimes the
problem will in)lude a list of )onditions that must be met before it ma!es
sense to apply the pattern.
3. 3he !ol"tion des)ribes the elements that ma!e up the design* their
relationships* responsibilities* and )ollaborations. 3he solution doesn;t
des)ribe a parti)ular )on)rete design or implementation* be)ause a pattern
is li!e a template that )an be applied in many different situations. Instead*
the pattern provides an abstra)t des)ription of a design problem and how
a general arrangement of elements ")lasses and obje)ts in our )ase% solves
Page
2
it.
&. 3he (on!e."en(e! are the results and trade:offs of applying the pattern.
3hough )onse7uen)es are often unvoi)ed when we des)ribe design de)isions*
they are )riti)al for evaluating design alternatives and for understanding
the )osts and benefits of applying the pattern. 3he )onse7uen)es for
software often )on)ern spa)e and time trade:offs. 3hey may address language
and implementation issues as well. Sin)e reuse is often a fa)tor in
obje)t:oriented design* the )onse7uen)es of a pattern in)lude its impa)t
on a system;s fle5ibility* e5tensibility* or portability. ,isting these
)onse7uen)es e5pli)itly helps you understand and evaluate them.
Iterator Pattern$
Iterator pattern is very )ommonly used design pattern in #ava and .8et programming
environment.Iterator pattern falls under #e*a)ioral pattern )ategory.
Intent
3his pattern provide a way to a))ess the elements of a )olle)tion obje)t in se7uential
manner without any need to !now its underlying representation.
Al!o /no0n A!
Cursor
Moti)ation
.n aggregate obje)t su)h as a list should give you a way to a))ess its elements
without e5posing its internal stru)ture. Moreover* you might want to traverse the
list in different ways* depending on what you want to a))omplish. 'ut you probably
don;t want to bloat the ,ist interfa)e with operations for different traversals*
even if you )ould anti)ipate the ones you will need. <ou might also need to have
more than one traversal pending on the same list.3he Iterator pattern lets you do all this.
3he !ey idea in this pattern is to ta!ethe responsibility for a))ess and traversal out of the
list obje)t and put it intoan iterator obje)t. 3he Iterator )lass defines an interfa)e for
a))essing the list;selements. .n iterator obje)t is responsible for !eeping tra)! of the
)urrent element=that is* it !nows whi)h elements have been traversed already.
Implementation$
>e;re going to )reate a Iterator interfa)e whi)h narrates navigation method and a
Container interfa)e whi)h retruns the iterator . Con)rete )lasses implementing the
Container interfa)e will be responsible to implement Iterator interfa)e and use it
IteratorPatternDemo* our demo )lass will use NamesRepository* a )on)rete )lass
implementation to print a Names stored as a )olle)tion in NamesRepository.
Step &
Page
3
Create interfa)es.
Iterator.java
publi) interfa)e Iterator ?
publi) boolean has8e5t"%=
publi) 4bje)t ne5t"%=
@
Container.java
publi) interfa)e Container ?
publi) Iterator getIterator"%=
@
Step 1
Create )on)rete )lass implementing the Container interfa)e. 3his )lass has inner )lass
NameIterator implementing the Iterator interfa)e.
NameRepository.java
publi) )lass 8ameAepository implements Container ?
publi) String namesBC D ?EAobertE * E#ohnE *E#ulieE * E,oraE@=
F4verride
publi) Iterator getIterator"% ?
return new 8ameIterator"%=
@
private )lass 8ameIterator implements Iterator ?
int inde5=
F4verride
publi) boolean has8e5t"% ?
if"inde5 G names.length%?
return true=
@
return false=
@
F4verride
publi) 4bje)t ne5t"% ?
if"this.has8e5t"%%?
return namesBinde5HHC=
@
return null=
@
@
@
Step 2
+se the NameRepository to get iterator and print names.
Page
4
IteratorPatternDemo.java
publi) )lass Iterator0attern/emo ?
publi) stati) void main"StringBC args% ?
8ameAepository namesAepository D new 8ameAepository"%=
for"Iterator iter D namesAepository.getIterator"%= iter.has8e5t"%=%?
String name D "String%iter.ne5t"%=
System.out.println"E8ame 6 E H name%=
@
@
@
Step 3
Verify the output.
8ame 6 Aobert
8ame 6 #ohn
8ame 6 #ulie
8ame 6 ,ora
Me4iator Pattern$
Mediator pattern is used to redu)e )ommuni)ation )omple5ity between multiple obje)ts
or )lasses. 3his pattern provides a mediator )lass whi)h normally handles all the
)ommuni)ations between different )lasses and supports easy maintainability of the )ode
by loose )oupling.Mediator pattern falls under #e*a)ioral pattern )ategory.
Intent
/efine an obje)t that en)apsulates how a set of obje)ts intera)t. Mediator promotes
loose )oupling by !eeping obje)ts from referring to ea)h other e5pli)itly* and
it lets you vary their intera)tion independently.
Moti)ation
4bje)t:oriented design en)ourages the distribution of behavior among obje)ts. Su)h
distribution )an result in an obje)t stru)ture with many )onne)tions between
obje)ts= in the worst )ase* every obje)t ends up !nowing about every other.
3hough partitioning a system into many obje)ts generally enhan)es reusability*
proliferating inter)onne)tions tend to redu)e it again. ,ots of inter)onne)tions
ma!e it less li!ely that an obje)t )an wor! without the support of othersIthe system
a)ts as though it were monolithi). Moreover* it )an be diffi)ult to )hange the
system;s behavior in any signifi)ant way* sin)e behavior is distributed among many
obje)ts. .s a result* you may be for)ed to define many sub)lasses to )ustomiJe
the system;s behavior.
Implementation
Page
5
>e;re demonstrating mediator pattern by e5ample of a Chat Aoom where multiple users
)an send message to Chat Aoom and it is the responsibility of Chat Aoom to show the
messages to all users. >e;ve )reated two )lasses ChatRoom and User. User obje)ts will
use ChatRoom method to share their messages.
MediatorPatternDemo* our demo )lass will use User obje)ts to show )ommuni)ation
between them.
Step &
Create mediator )lass.
ChatRoom.java
import java.util./ate=
publi) )lass ChatAoom ?
publi) stati) void showMessage"+ser user* String message%?
System.out.println"new /ate"%.toString"%
H E BE H user.get8ame"% HEC 6 E H message%=
@
@
Step 1
Create user )lass
User.java
publi) )lass +ser ?
private String name=
publi) String get8ame"% ?
return name=
@
publi) void set8ame"String name% ?
this.name D name=
@
publi) +ser"String name%?
this.name D name=
@
publi) void sendMessage"String message%?
ChatAoom.showMessage"this*message%=
@
@
Step 2
+se the User obje)t to show )ommuni)ations between them.
MediatorPatternDemo.java
publi) )lass Mediator0attern/emo ?
Page
6
publi) stati) void main"StringBC args% ?
+ser robert D new +ser"EAobertE%=
+ser john D new +ser"E#ohnE%=
robert.sendMessage"E9iK #ohnKE%=
john.sendMessage"E9elloK AobertKE%=
@
@
Step 3
Verify the output.
3hu #an 31 1-6L(6&- IS3 2L13 BAobertC 6 9iK #ohnK
3hu #an 31 1-6L(6&- IS3 2L13 B#ohnC 6 9ello
Con(l"!ion$
3hus >e have studied two design patterns"Iterator and mediator design pattern%.
Page
7
A!!inment N"m#er$ %1
Title $ Implementation of any two design patterns in java .
Aim6 Implementation of any two design patterns in java .
O#'e(ti)e!$ 3o study implementation of 1% 4bserver 0attern.2%Singleton pattern
T*eor+$
O#!er)er Pattern$
4bserver pattern is used when there is one to many relationship between obje)ts su)h as
if one obje)t is modified* its depenedent obje)ts are to be notified automati)ally. 4bserver
pattern falls under #e*a)ioral pattern )ategory.
Intent
/efine a one:to:many dependen)y between obje)ts so that when one obje)t )hanges
state* all its dependents are notified and updated automati)ally.
Al!o /no0n A!
/ependents* 0ublish:Subs)ribe
Moti)ation
. )ommon side:effe)t of partitioning a system into a )olle)tion of )ooperating
)lasses is the need to maintain )onsisten)y between related obje)ts. <ou don;t
want to a)hieve )onsisten)y by ma!ing the )lasses tightly )oupled* be)ause that
redu)es their reusability.
or e5ample* many graphi)al user interfa)e tool!its separate the presentational
aspe)ts of the user interfa)e from the underlying appli)ation data .Classes defining
appli)ation data and presentations )an be
Aeused independently. 3hey )an wor! together* too. 'oth a spreadsheet obje)t and
bar )hart obje)t )an depi)t information in the same appli)ation data obje)t using
different presentations. 3he spreadsheet and the bar )hart don;t !now about ea)h
other* thereby letting you reuse only the one you need. 'ut they behave as though
they do. >hen the user )hanges the information in the spreadsheet* the bar )hart
refle)ts the )hanges immediately* and vi)e versa.
Page
8
Implementation
4bserver pattern uses three a)tor )lasses. Subje)t* 4bserver and Client. Subje)t* an obje)t
having methods to atta)h and de:atta)h observers to a )lient obje)t. >e;ve )reated )lasses
Subject* Observer abstra)t )lass and )on)rete )lasses e5tending the abstra)t )lass the
Observer.
ObserverPatternDemo* our demo )lass will use Subject and )on)rete )lass obje)ts to
show observer pattern in a)tion.
Step &
Create Subje)t )lass.
Subject.java
import java.util..rray,ist=
import java.util.,ist=
publi) )lass Subje)t ?
private ,istG4bserverM observers
D new .rray,istG4bserverM"%=
private int state=
publi) int getState"% ?
return state=
@
publi) void setState"int state% ?
this.state D state=
notify.ll4bservers"%=
@
publi) void atta)h"4bserver observer%?
observers.add"observer%=
Page
9
@
publi) void notify.ll4bservers"%?
for "4bserver observer 6 observers% ?
observer.update"%=
@
@
@
Step 1
Create 4bserver )lass.
Observer.java
publi) abstra)t )lass 4bserver ?
prote)ted Subje)t subje)t=
publi) abstra)t void update"%=
@
Step 2
Create )on)rete observer )lasses
BinaryObserver.java
publi) )lass 'inary4bserver e5tends 4bserver?
publi) 'inary4bserver"Subje)t subje)t%?
this.subje)t D subje)t=
this.subje)t.atta)h"this%=
@
F4verride
publi) void update"% ?
System.out.println" E'inary String6 E
H Integer.to'inaryString" subje)t.getState"% % %=
@
@
OctaObserver.java
publi) )lass 4)tal4bserver e5tends 4bserver?
publi) 4)tal4bserver"Subje)t subje)t%?
this.subje)t D subje)t=
this.subje)t.atta)h"this%=
@
F4verride
publi) void update"% ?
System.out.println" E4)tal String6 E
H Integer.to4)talString" subje)t.getState"% % %=
@
@
Page
10
!e"aObserver.java
publi) )lass 9e5a4bserver e5tends 4bserver?
publi) 9e5a4bserver"Subje)t subje)t%?
this.subje)t D subje)t=
this.subje)t.atta)h"this%=
@
F4verride
publi) void update"% ?
System.out.println" E9e5 String6 E
H Integer.to9e5String" subje)t.getState"% %.to+pperCase"% %=
@
@
Step 3
+se Subject and )on)rete observer obje)ts.
ObserverPatternDemo.java
publi) )lass 4bserver0attern/emo ?
publi) stati) void main"StringBC args% ?
Subje)t subje)t D new Subje)t"%=
new 9e5a4bserver"subje)t%=
new 4)tal4bserver"subje)t%=
new 'inary4bserver"subje)t%=
System.out.println"Eirst state )hange6 1(E%=
subje)t.setState"1(%=
System.out.println"ESe)ond state )hange6 1LE%=
subje)t.setState"1L%=
@
@
Step 5
Verify the output.
irst state )hange6 1(
9e5 String6
4)tal String6 1N
'inary String6 1111
Se)ond state )hange6 1L
9e5 String6 .
4)tal String6 12
'inary String6 1L1L
16Sinleton Pattern$
Sing leton pattern is one of the simplest desig n patterns in Java. T his type of desig n
pattern comes under
creational pattern as this pattern provides one of the best way to create an object.
Page
11
T his pattern involves a sing le class which is responsible to creates own object while
making sure that only sing le
object g et created. T his class provides a way to access its only object which can be
accessed directly without
need to instantiate the object of the class.
Implementation$
Step 1
Create a Sing leton Class.
SingleObject.java
publi) )lass Single4bje)t ?
11)reate an obje)t of Single4bje)t
private stati) Single4bje)t instan)e D new Single4bje)t"%=
11ma!e the )onstru)tor private so that this )lass )annot be
11instantiated
private Single4bje)t"%?@
11Oet the only obje)t available
publi) stati) Single4bje)t getInstan)e"%?
return instan)e=
@
publi) void showMessage"%?
System.out.println"E9ello >orldKE%=
@
@
Step 2
Get the only object from the sing leton class.
SingletonPatternDemo.java
publi) )lass Singleton0attern/emo ?
publi) stati) void main"StringBC args% ?
11illegal )onstru)t
11Compile 3ime $rror6 3he )onstru)tor Single4bje)t"% is not visible
11Single4bje)t obje)t D new Single4bje)t"%=
11Oet the only obje)t available
Single4bje)t obje)t D Single4bje)t.getInstan)e"%=
11show the message
obje)t.showMessage"%=
@
@
Step 3
Verify the output.
9ello >orldK
Con(l"!ion$
Page
12
3hus >e have implemented two design patterns"4bserver and .dapter design pattern%.
A!!inment N"m#er$ %2
Title$ Study report for any of the MVC based ramewor!s
Aim$ Study report for any of the MVC based ramewor!s
O#'e(ti)e!$
3o study MVC .r)hite)ture.
T*eor+$
Intro4"(tion$
3he ever:evolving #ava programming language and Sun;s #2$$ spe)ifi)ation have
enabled software developers of various dis)iplines to )reate distributed )omputing
appli)ations that were previously possible only with relatively proprietary tools. 3hus*
while some development teams may )hoose to implement new systems in the #ava
platform* others will )reate* enhan)e* and maintain appli)ations using other s!ills and
then integrate them into an e5isting heterogeneous distributed appli)ation. 3his situation
gives rise to an interoperability )hallenge. 9ow )an a new appli)ation intera)t with an old
oneP 3he answer6 web servi)es. >eb servi)es are the new holy grail of programming.
3hey ma!e it possible to share and )oordinate dispersed* heterogeneous )omputing
resour)es.
MVC .r)hite)ture Seperates business logi) from representation of information.
3he MVC design pattern )learly demar)ates the roles of programmers and
designers. In other words* it separates data from business logi). 3his pattern allows
designers to )on)entrate on the display portion of an appli)ation and developers to
)on)entrate on developing the )omponents re7uired to drive the appli)ation;s fun)tions.
MVC is used to separate logi) into 3 distin)t units61C3he Model
2C3he View
3C3he Controller
M7C Ar(*ite(t"re$
.n appli)ation;s data models "the Mode%* presentation )ode "the #ie$%* and
program )ontrol logi) "the Controer% should e5ist as distin)t but inter)ommuni)ating
)omponents. 3he Model )omponent represents and pro)esses appli)ation data. 3he View
Page
13
is the user interfa)e= it refle)ts the Model data and presents it to the user. 3he Controller
maps a)tions performed on the View "for e5ample* pressing a Submit button% to
operations on the Model "for e5ample* retrieving user details%. .fter the Model is
updated* the View is refreshed and the user )an perform more a)tions. 3he MVC pattern
)larifies )ode and fa)ilitates )ode reuse= in addition* in many proje)ts the View is
fre7uently updated* and the MVC pattern insulates the Model and Controller against
those )hanges.
Example$
Aails appli)ations are developed using the Model View Controller "MVC% pattern.
3he easiest way to show how Aails uses MVC is by loo!ing at a simplified e5ample of
the Aails re7uest life)y)le as seen in fig..
Fi"re . M7C in a(tion$ t*e Rail! re."e!t life(+(le
1. <our grandmother fires up her web browser and hits your appli)ation with a
re7uest for some page. 3his re7uest arrives at a Controller* whose job it is to
determine what needs to be done in order to fulfill the re7uest.
2. 3he Controller needs to fet)h some data from the database* so it as!s a Mo4el*
whose job it is to )ommuni)ate with the database* ma!e SQ, )alls to fet)h
re)ords* and to !now if data is valid or not.
3he Model fet)hes data and gives it to the Controller.
3. 3he Controller needs the data in the form of 93M, to give ba)! to the Client "in
this )ase* your grandmotherRs web browser%* so it gives a 7ie0 the data it now
has.
&. 3he View )ombines the data with a template to generate a 93M, page and
returns the page to the Controller.
(. 3he Controller gives the rendered 93M, page ba)! to the Client as a response.
Page
14
Implementation$
>e;re going to )reate a Student obje)t a)ting as a model.Student#ie$ will be a
view )lass whi)h )an print student details on )onsole and StudentControer is the
)ontroller )lass responsible to store data in Student obje)t and update view Student#ie$
a))ordingly.
M#CPatternDemo* our demo )lass will use StudentControer to demonstrate use of
MVC pattern.
Step &
Create Model.
Student.java
publi) )lass Student ?
private String roll8o=
private String name=
publi) String getAoll8o"% ?
return roll8o=
@
publi) void setAoll8o"String roll8o% ?
this.roll8o D roll8o=
@
publi) String get8ame"% ?
return name=
@
publi) void set8ame"String name% ?
this.name D name=
@
@
Step 1
Create View.
Student#ie$.java
publi) )lass StudentView ?
publi) void printStudent/etails"String student8ame* String studentAoll8o%?
System.out.println"EStudent6 E%=
System.out.println"E8ame6 E H student8ame%=
System.out.println"EAoll 8o6 E H studentAoll8o%=
@
@
Page
15
Step 2
Create Controller.
StudentControer.java
publi) )lass StudentController ?
private Student model=
private StudentView view=
publi) StudentController"Student model* StudentView view%?
this.model D model=
this.view D view=
@
publi) void setStudent8ame"String name%?
model.set8ame"name%=
@
publi) String getStudent8ame"%?
return model.get8ame"%=
@
publi) void setStudentAoll8o"String roll8o%?
model.setAoll8o"roll8o%=
@
publi) String getStudentAoll8o"%?
return model.getAoll8o"%=
@
publi) void updateView"%?
view.printStudent/etails"model.get8ame"%* model.getAoll8o"%%=
@
@
Step 3
+se the StudentControer methods to demonstrate MVC design pattern usage.
M#CPatternDemo.java
publi) )lass MVC0attern/emo ?
publi) stati) void main"StringBC args% ?
11fet)h student re)ord based on his roll no from the database
Student model D retriveStudentrom/atabase"%=
11Create a view 6 to write student details on )onsole
StudentView view D new StudentView"%=
StudentController )ontroller D new StudentController"model* view%=
)ontroller.updateView"%=
11update model data
)ontroller.setStudent8ame"E#ohnE%=
)ontroller.updateView"%=
@
private stati) Student retriveStudentrom/atabase"%?
Page
16
Student student D new Student"%=
student.set8ame"EAobertE%=
student.setAoll8o"E1LE%=
return student=
@
@
Step 5
Verify the output.
Student6
8ame6 Aobert
Aoll 8o6 1L
Student6
8ame6 #ulie
Aoll 8o6 1L
Con(l"!ion$
3hus we have studied MVC .r)hite)ture.
Page
17
A!!inment N"m#er$ %3
Title$ Study report on $#'.
Aim$ Study report on $#'.
O#'e(ti)e!$3o study $#'.
T*eor+$
,*+ 0e nee4 Enterpri!e 8a)aBean!-
3he )lient:server model of appli)ation development has enjoyed )onsiderable popularity.
3he )lient appli)ation resides on a lo)al ma)hine and a))esses the data in a data store
su)h as a relational database management system "A/MS%. 3his model wor!s well as
long as the system has only a few users. .s more and more users need a))ess to the
data* these appli)ations donRt s)ale well to meet the demands. 'e)ause the )lient )ontains
the logi)* it must be installed on ea)h ma)hine.Management be)omes in)reasingly
diffi)ult.Oradually the benefits of dividing appli)ations into more than the two tiers of the
)lient:server model be)omes apparent. In a multi:tier appli)ation* only the user interfa)e
stays on lo)al ma)hines while the logi) of the appli)ation runs in the middle tier on a
server. 3he final tier is still the stored data. >hen the logi) of an appli)ation needs
updating* )hanges are made to the software of the middle tier on the server* greatly
simplifying the management of updates. 'ut )reating reliable* se)ure* and easily managed
distributed appli)ations is notoriously diffi)ult. or e5ample* managing transa)tions over
a distributed system is a major tas!. ortunately* using )omponents that follow the $#'
spe)ifi)ation to build distributed systems relieves mu)h of the burden by6
S /ividing the development of a distributed system into spe)ifi) tas!s that are assigned to
spe)ialists.
or e5ample* if the appli)ation is an a))ounting system* the enterprise bean developer
would need to understand a))ounting. 3he system administrator must !now about
monitoring a deployed and running appli)ation. $a)h spe)ialist assumes a parti)ular role.
S Ma!ing $#' server and )ontainer servi)es available to the enterprise bean and
appli)ation developers.
3he $#' server provider and $#' )ontainer provider "who are often the same vendor%
handle many of the more diffi)ult tas!s so the developers donRt have to. or e5ample* the
)ontainer an enterprise bean runs in )an provide transa)tion and se)urity servi)es to the
bean automati)ally.
S Ma!ing enterprise beans portable.
4n)e a bean is written* it )an be deployed on any $#' server that adheres to the
$nterprise #ava'eans standard. $a)h bean is li!ely to in)lude vendor:spe)ifi) elements*
however.
Role! in t*e 4e)elopment of an E8B appli(ation
&.Appli(ation role!
3hose who assume the appli)ation roles write the )ode for the enterprise beans and the
appli)ations that use them. 'oth roles re7uire an understanding of how the business runs*
although at different levels.
3hese are the two appli)ation roles6
Page
18
S 'ean provider
'ean providers "also )alled bean developers% )reate the enterprise beans and write the
logi) of the business methods within them. 3hey also define the remote home or lo)al
home and remote or lo)al interfa)es for the beans and they )reate the beansR deployment
des)riptors. 'ean providers donRt ne)essarily need to !now how their beans will be
assembled and deployed.
S .ppli)ation assembler
.ppli)ation assemblers write the appli)ations that use the enterprise beans. 3hese
appli)ations usually in)lude other )omponents* su)h as O+I )lients* applets* #avaServer
0ages pages "#S0%* and servlets. 3hese )omponents are assembled into a distributed
appli)ation. .ssemblers add assembly instru)tions to the bean deployment des)riptors.
.lthough appli)ation assemblers must be familiar with the methods )ontained within the
enterprise beans so they )an )all them* they donRtneed to !now how those methods are
implemented.
1. Infra!tr"(t"re role!
appli)ations that use them )annot run. .lthough the two infrastru)ture roles are distin)t*
they are almost always assumed by the same vendor. 3ogether they provide system:level
servi)es to the enterprise beans and provide an environment in whi)h to run. 3hese are
the two infrastru)ture roles6
S $#' server provider
$#' server providers are spe)ialists in distributed transa)tion management* distributed
obje)ts* and other low:level servi)es. 3hey provide an appli)ation framewor! in whi)h to
run $#' )ontainers. $#' servi)e providers must provide* at a minimum* a naming servi)e
and a transa)tion servi)e to the beans.
S $#' )ontainer provider
$#' )ontainer providers provide the deployment tools re7uired to deploy enterprise beans
and the runtime support for the beans. . )ontainer provides management servi)es to one
or more beans. 3hey )ommuni)ate for the beans with the $#' server to a))ess the
servi)es the bean needs.
E8B ar(*ite(t"re
Multi:tier distributed appli)ations often )onsist of a )lient that runs on a lo)al ma)hine* a
middle:tier that runs on a server that )ontains the business logi)* and a ba)!end:tier
)onsisting of an enterprise information system "$IS%. .n $IS )an be a relational database
system* an $A0 system* a lega)y appli)ation* or any data store that holds the data that
needs to be a))essed. 3his figure shows a typi)al $#' multi:tier distributed system
with three tiers6 the )lient= the server* the )ontainer* and the beans deployed on them= and
the enterprise information system.
Page
19
'e)ause our interest is how to develop enterprise beans* our fo)us is the middle tier.
T*e E8B !er)er
3he $#' server provides system servi)es to enterprise beans and manages the )ontainers
in whi)h the beans run. It must ma!e available a #8/I:a))essible naming servi)e and a
transa)tion servi)e. re7uently an $#' server provides additional features that distinguish
it from its )ompetitors. 3he 'orland $nterprise Server .ppServer $dition (.L.2 T (.1.5 is
an e5ample of an $#' server.
T*e E8B (ontainer
. )ontainer is a runtime system for one or more enterprise beans. It provides the
)ommuni)ation between the beans and the $#' server. It provides transa)tion* se)urity*
and networ! distribution management. . )ontainer is both )ode and a tool that generates
)ode spe)ifi) for a parti)ular enterprise bean. . )ontainer also provides tools for the
deployment of an enterprise bean* and a means for the )ontainer to monitor and manage
the appli)ation.
3he $#' server and $#' )ontainer together provide the environment for the bean to
run in. 3he )ontainer provides management servi)es to one or more beans. 3he server
provides servi)es to the bean* but the )ontainer intera)ts on behalf of the beans to
obtain those servi)es. .lmost always the $#' server and the $#' )ontainer are made
by the same vendor and are simply two parts of an appli)ation server* su)h as 'orland
$nterprise Server .ppServer $dition (.L.2 T (.1.5.
3he bean developer must )reate these interfa)es and )lasses6
Page
20
1. 3he remote home and1or lo)al home interfa)e for the bean
3he home interfa)e defines the methods a )lient uses to )reate* lo)ate*and destroy
instan)es of an enterprise bean.
2. 3he remote and1or lo)al interfa)e for the bean
3he remote or lo)al interfa)e defines the business methods implemented in the bean.
. )lient a))esses these methods through the
remote interfa)e.
3.3he enterprise bean )lass
3he enterprise bean )lass implements the business logi) for the bean.3he )lient
a))esses these methods through the beanRs remote interfa)e.4n)e the bean is deployed in
the $#' )ontainer* the )lient )alls the )reate"% method defined in the home interfa)e to
instantiate the bean. 3he home interfa)e isnRt implemented in the bean itself* but by the
)ontainer. 4ther methods de)lared in the home interfa)e permit the )lient to lo)ate an
instan)e of a bean and to remove a bean instan)e when it is no longer needed. $#' 2.L
beans also allow the home interfa)e to have business methods )alled ejb9ome methods.
>hen the enterprise bean is instantiated* the )lient )an )all the business methods
within the bean. 3he )lient never )alls a method in the bean instan)e dire)tly* however.
3he methods available to the )lient are defined in the remote or lo)al interfa)e of the
bean* and the remote or lo)al interfa)e is implemented by the )ontainer. >hen the )lient
)alls a method* the )ontainer re)eives the re7uest and delegates it to the bean instan)e.
T+pe! of enterpri!e #ean!
.n enterprise bean )an be a session bean* an entity bean* or a message:driven bean.
Se!!ion #ean!
Session beans )an be either stateful or stateless.
Stateless beans donRt maintain state for a parti)ular )lient. 'e)ause they donRt maintain
)onversational state* stateless beans )an be used to support multiple
)lients.
. stateful session bean e5e)utes on behalf of a single )lient. In a sense* the session bean
represents the )lient in the $#' server. Stateful session beans )an maintain the )lientRs
state* whi)h means they )an retain information for the )lient. 3he )lassi) e5ample where
a session bean might be used is a shopping )art for an individual shopping at an online
store on the web. .s the shopper sele)ts items to put in the U)art*V the session bean retains
a list of the sele)ted items.
Session beans )an be short:lived. +sually when the )lient ends the session*
the bean is removed by the )lient.
Entit+ #ean!
.n entity bean provides an obje)t view of data in a database. +sually the bean represents
a row in a set of relational database tables. .n entity bean usually serves more than one
)lient.
+nli!e session beans* entity beans are )onsidered to be long:lived. 3hey maintain a
persistent state* living as long as the data remains in the database* rather than as long as a
parti)ular )lient needs it. 3he )ontainer )an manage the beanRs persisten)e* or the bean
)an manage it itself. If the persisten)e is bean:managed* the bean developer must write
)ode that in)ludes )alls to the database.
Page
21
Me!!ae94ri)en #ean!
3he $#' 2.L spe)ifi)ation introdu)ed message:driven beans. 3hey behave as a #ava
Message Servi)e "#MS% listener* pro)essing asyn)hronous messages. 3he $#' )ontainer
manages the beanRs entire environment.
Message:driven beans are similar to stateless session beans be)ause they maintain no
)onversational state. +nli!e session and entity beans* )lients donRt a))ess them through
interfa)es. . message:driven bean has no interfa)es* just a bean )lass. . single message:
driven bean )an pro)ess messages from more than one )lient. . message:driven bean is
essentially a blo)! of appli)ation )ode that e5e)utes when a message arrives at a
parti)ular #MS destination.
Remote an4 lo(al a((e!!
.n $#' 2.L )omponent )an be a))essed remotely or lo)ally. Clients that a))ess a remote
bean use the beanRs remote and remote home interfa)es. . remote home is often referred
to as the home interfa)e. . )lient with remote a))ess to a bean )an run on a different
ma)hine and use a different
#ava Virtual Ma)hine "#VM% than the bean itself. In method )alls to a remote bean*
parameters are passed by value* whi)h helps maintain loose )oupling between the )lient
and the bean.
. )lient with lo)al a))ess to a bean must run in the same #VM as the bean it a))esses. .
lo)al )lient wonRt be an e5ternal )lient appli)ation* but rather another enterprise bean or
web )omponent. In method )alls to a lo)al bean* parameters are passed by referen)e*
resulting in a tighter )oupling between the )alling bean or web )omponent and the )alled
bean.
,i!e the remote interfa)e* the lo)al interfa)e provides a))ess to the beanRs business
methods* while its lo)al home interfa)e provides a))ess to the methods that )ontrol the
life )y)le of the bean as well as its finder methods. 4ften entity beans that have a
)ontainer:managed relationship with other entity beans have lo)al a))ess to them.
'e)ause beans with lo)al interfa)es must run in the same #VM* there is no need for
remote )alls. 3herefore* the overhead of serialiJing and transporting obje)ts is redu)ed.
+sually this means greater performan)e.
Con(l"!ion$
3hus >e have studied $#'.
Page
22
A!!inment N"m#er$ %5
Title$ Implementation of +M, diagrams.
Aim$ Implementation of a web appli)ation for a system )overing representative paper
design of the system using navigation* )omponents* interfa)es* its deployment issue with
+M,.
O#'e(ti)e!$
3o study Implementation of +M, diagrams.
T*eor+$
+M, is not a development method by itself= however* it was designed to be
)ompatible with the leading obje)t:oriented software development methods of its time.
Sin)e +M, has evolved* some of these methods have been re)ast to ta!e advantage of the
new notations "for e5ample 4M3%* and new methods have been )reated based on +M,*
su)h as I'M Aational +nified 0ro)ess "A+0%. 4thers in)lude .bstra)tion Method
and /ynami) Systems /evelopment Method.
Mo4elin
It is important to distinguish between the +M, model and the set of diagrams of a
system. . diagram is a partial graphi) representation of a system;s model. 3he model also
)ontains do)umentation that drive the model elements and diagrams "su)h as written use
)ases%.
+M, diagrams represent two different views of a system model
Stati) "or structura % view6 emphasiJes the stati) stru)ture of the system using obje)ts*
attributes* operations and relationships. 3he stru)tural view in)ludes )lass
diagrams and )omposite stru)ture diagrams.
/ynami) "or behaviora % view6 emphasiJes the dynami) behavior of the system by
showing )ollaborations among obje)ts and )hanges to the internal states of obje)ts. 3his
view in)ludes se7uen)e diagrams* a)tivity diagrams and state ma)hine diagrams.
Diaram! o)er)ie0
+M, 2.2 has 1& types of diagrams divided into two )ategories. Seven diagram types
represent structura information* and the other seven represent general types of behavior*
in)luding four that represent different aspe)ts of interactions. 3hese diagrams )an be
)ategoriJed hierar)hi)ally as shown in the following )lass diagram6
Page
23
+M, does not restri)t +M, element types to a )ertain diagram type. In general*
every +M, element may appear on almost all types of diagrams= this fle5ibility has
been partially restri)ted in +M, 2.L. +M, profiles may define additional diagram
types or e5tend e5isting diagrams with additional notations.
In !eeping with the tradition of engineering drawings*
Bcitation neededC
a )omment or note
e5plaining usage* )onstraint* or intent is allowed in a +M, diagram.
Str"(t"re 4iaram!
Stru)ture diagrams emphasiJe the things that must be present in the system being
modeled. Sin)e stru)ture diagrams represent the stru)ture* they are used e5tensively
in do)umenting the software ar)hite)ture of software systems.
Class diagram6 des)ribes the stru)ture of a system by showing the system;s
)lasses* their attributes* and the relationships among the )lasses.
Component diagram6 des)ribes how a software system is split up into )omponents
and shows the dependen)ies among these )omponents.
Composite stru)ture diagram6 des)ribes the internal stru)ture of a )lass and the
)ollaborations that this stru)ture ma!es possible.
/eployment diagram6 des)ribes the hardware used in system implementations and
the e5e)ution environments and artifa)ts deployed on the hardware.
4bje)t diagram6 shows a )omplete or partial view of the stru)ture of a modeled
system at a spe)ifi) time.
0a)!age diagram6 des)ribes how a system is split up into logi)al groupings by
showing the dependen)ies among these groupings.
0rofile diagram6 operates at the metamodel level to show stereotypes as )lasses
with the GGstereotypeMM stereotype* and profiles as pa)!ages with the
GGprofileMM stereotype. 3he e5tension relation "solid line with )losed* filled
arrowhead% indi)ates what metamodel element a given stereotype is e5tending.
Page
24

Be*a)io"r 4iaram!
'ehavior diagrams emphasiJe what must happen in the system being modeled. Sin)e
behavior diagrams illustrate the behavior of a system* they are used e5tensively to
des)ribe the fun)tionality of software systems.
.)tivity diagram6 des)ribes the business and operational step:by:step wor!flows
of )omponents in a system. .n a)tivity diagram shows the overall flow of )ontrol.
+M, state ma)hine diagram6 des)ribes the states and state transitions of the
system.
+se )ase diagram6 des)ribes the fun)tionality provided by a system in terms of
a)tors* their goals represented as use )ases* and any dependen)ies among those
use )ases.
Intera(tion 4iaram!
Intera)tion diagrams* a subset of behaviour diagrams* emphasiJe the flow of )ontrol
and data among the things in the system being modeled6
Communi)ation diagram6 shows the intera)tions between obje)ts or parts in terms
of se7uen)ed messages. 3hey represent a )ombination of information ta!en from
Class* Se7uen)e* and +se Case /iagrams des)ribing both the stati) stru)ture and
dynami) behavior of a system.
Intera)tion overview diagram6 provides an overview in whi)h the nodes represent
)ommuni)ation diagrams.
Se7uen)e diagram6 shows how obje)ts )ommuni)ate with ea)h other in terms of a
se7uen)e of messages. .lso indi)ates the lifespans of obje)ts relative to those
messages.
3iming diagrams6 a spe)ifi) type of intera)tion diagram where the fo)us is on
timing )onstraints.
Con(l"!ion$
3hus we have implemented +M, /iagrams.
Page
25
A!!inment N"m#er$ %:
Title$ /evelop a appli)ation using )lient side and server side te)hnology.
Aim$ .%/evelop dynami) and intera)tive web )lient using #S0*
S)ripting1.pplets1.)tive2 )ontrols.
'%/evelop server side programming with database handling1
servlets1$#'1webservi)e on server side with se)urity aspe)ts )overed.
O#'e(ti)e!$3o study of Server Side programming and to develop dynami) and
intera)tive web )lient.
T*eor+$
A6De)elop 4+nami( an4 intera(ti)e 0e# (lient "!in 8SP;
S(riptin<Applet!<A(ti)e= (ontrol!.
#ava Server 0ages or #S0 for short is Sun;s solution for developing dynami) web sites.
#S0 provide e5)ellent server side s)ripting support for )reating database driven web
appli)ations. #S0 enable the developers to dire)tly insert java )ode into jsp file* this
ma!es the development pro)ess very simple and its maintenan)e also be)omes very
easy. #S0 pages are effi)ient* it loads into the web servers memory on re)eiving the
re7uest very first time and the subse7uent )alls are served within a very short period of
time.
In today;s environment most web sites servers dynami) pages based on user re7uest.
/atabase is very )onvenient way to store the data of users and other things. #/'C
provide e5)ellent database )onne)tivity in heterogeneous database environment. +sing
#S0 and #/'C its very easy to develop database driven web appli)ation.
#ava is !nown for its )hara)teristi) of Ewrite on)e* run anywhere.E #S0 pages are
platform independent. <our port your .jsp pages to any platform.
#avaServer 0ages
#avaServer 0ages "#S0% te)hnology is the #ava platform te)hnology for delivering
dynami) )ontent to web )lients in a portable* se)ure and well:defined way. 3he
#avaServer 0ages spe)ifi)ation e5tends the #ava Servlet .0I to provide web appli)ation
developers with a robust framewor! for )reating dynami) web )ontent on the server
using 93M,* and 2M, templates* and #ava )ode* whi)h is se)ure* fast* and
independent of server platforms. #S0 has been built on top of the Servlet .0I and
utiliJes Servlet semanti)s. #S0 has be)ome the preferred re7uest handler and response
me)hanism. .lthough #S0 te)hnology is going to be a powerful su))essor to basi)
Servlets* they have an evolutionary relationship and )an be used in a )ooperative and
)omplementary manner.
Servlets are powerful and sometimes they are a bit )umbersome when it )omes to
generating )omple5 93M,. Most servlets )ontain a little )ode that handles appli)ation
Page
26
logi) and a lot more )ode that handles output formatting. 3his )an ma!e it diffi)ult to
separate and reuse portions of the )ode when a different output format is needed. or
these reasons* web appli)ation developers turn towards #S0 as their preferred servlet
environment.
8a)a Ser)er Pae! 9 An O)er)ie0
3he #ava Server 0ages 1.2 spe)ifi)ation provides web developers with a framewor! to
build appli)ations )ontaining dynami) web )ontent su)h as 93M,* /93M,* 293M,
and 2M,. . #S0 page is a te5t based do)ument )ontaining stati) 93M, and dynami)
a)tions whi)h des)ribe how to pro)ess a response to the )lient in a more powerful and
fle5ible manner. Most of a #S0 file is plain 93M, but it also has* interspersed with it*
spe)ial #S0 tags.
3here are many #S0 tags su)h as6
#S0 dire)tive denoted by GWF*
2. s)riplets indi)ated by GW ... WM tags and
dire)tive in)ludes the )ontents of the file sample.html in the response at that point.
3o pro)ess a #S0 file* we need a #S0 engine that )an be )onne)ted with a web server or
)an be a))ommodated inside a web server. irstly when a web browser see!s a #S0 file
through an +A, from the web server* the web server re)ogniJes the .jsp file e5tension
in the +A, re7uested by the browser and understands that the re7uested resour)e is a
#avaServer 0age. 3hen the web server passes the re7uest to the #S0 engine. 3he #S0
page is then translated into a #ava )lass* whi)h is then )ompiled into a servlet.
3his translation and )ompilation phase o))urs only when the #S0 file is re7uested for
the first time* or if it undergoes any )hanges to the e5tent of getting retranslated and
re)ompiled. or ea)h additional re7uest of the #S0 page thereafter* the re7uest dire)tly
goes to the servlet byte )ode* whi)h is already in memory. 3hus when a re7uest )omes
for a servlet* an init"% method is )alled when the Servlet is first loaded into the virtual
ma)hine* to perform any global initialiJation that every re7uest of the servlet will need.
3hen the individual re7uests are sent to a servi)e"% method* where the response is put
together. 3he servlet )reates a new thread to run servi)e"% method for ea)h re7uest. 3he
re7uest from the browser is )onverted into a #ava obje)t of type 9ttpServletAe7uest*
whi)h is passed to the Servlet along with an 9ttpServletAesponse obje)t that is used to
send the response ba)! to the browser. 3he servlet )ode performs the operations
spe)ified by the #S0 elements in the .jsp file.
3he Components of #S0s
#S0 synta5 is almost similar to 2M, synta5. 3he following general rules are appli)able
to all #S0 tags.
1. 3ags have either a start tag with optional attributes* an optional body* and a mat)hing
end tag or they have an empty tag possibly with attributes.
Page
27
2. .ttribute values in the tag always appear 7uoted. 3he spe)ial strings Xapos= and E
)an be used if 7uotes are a part of the attribute value itself.
.ny whitespa)e within the body te5t of a do)ument is not signifi)ant* but is preserved*
whi)h means that any whitespa)e in the #S0 being translated is read and preserved
during translation into a servlet.
3he )hara)ter Y )an be used as an es)ape )hara)ter in a tag* for instan)e* to use the W
)hara)ter* YW )an be used.
#ava Server 0ages are te5t files that )ombine standard 93M, and new s)ripting tags.
#S0s loo! li!e 93M,* but they get )ompiled into #ava servlets the first time they are
invo!ed. 3he resulting servlet is a )ombination of 93M, from the #S0 file and
embedded dynami) )ontent spe)ified by the new tags. $verything in a #S0 page )an be
divided into two )ategories6
1. $lements that are pro)essed on the server
2. 3emplate data or everything other than elements* that the engine pro)essing the #S0
engines.
$lement data or that part of the #S0 whi)h is pro)essed on the server* )an be )lassified
into the following )ategories6
&. Dire(ti)e!
1. S(riptin element!
2. Stan4ar4 a(tion!
#S0 dire)tives serve as messages to the #S0 )ontainer from the #S0. 3hey are used to
set global values su)h as )lass de)laration* methods to be implemented* output )ontent
type* et). 3hey do not produ)e any output to the )lient. .ll dire)tives have s)ope of the
entire #S0 file. 3hat is* a dire)tive affe)ts the whole #S0 file* and only that #S0 file.
/ire)tives are )hara)teriJed by the F )hara)ter within the tag and the general synta5
is6
3he three dire)tives are page* in)lude and taglib.
S)ripting elements are used to in)lude s)ripting )ode "#ava )ode% within the #S0. 3hey
allow to de)lare variables and methods* in)lude arbitrary s)ripting )ode and evaluate
an e5pression. 3he three types of s)ripting element are6 /e)laration* S)riptlets and
$5pressions.
. de)laration is a blo)! of #ava )ode in a #S0 that is used to define )lass:wide variables
and methods in the generated )lass file. /e)larations are initialiJed when the #S0 page
is initialiJed and have )lass s)ope. .nything defined in a de)laration is available
throughout the #S0* to other de)larations* e5pressions or )ode.
. s)riptlet )onsists of one or more valid #ava statements. . s)riptlet is a blo)! of #ava
)ode that is e5e)uted at re7uest:pro)essing time. . s)riptlet is en)losed between EGWE
and EWME. >hat the s)riptlet a)tually does depends on the )ode* and it )an produ)e
output into the output stream to the )lient. Multiple s)riptlets are )ombined in the
)ompiled )lass in the order in whi)h they appear in the #S0. S)riptlets li!e any other
Page
28
#ava )ode blo)! or method* )an modify obje)ts inside them as a result of method
invo)ations.
.n e5pression is a shorthand notation for a s)riptlet that outputs a value in the response
stream ba)! to the )lient. >hen the e5pression is evaluated* the result is )onverted to a
string and displayed* .n e5pression is en)losed within GWD and WM EGWDE and EWME.
If any part of e5pression is an obje)t* the )onversion is done using the toString"%
method of the obje)t.
Standard a)tions are spe)ifi) tags that affe)t the runtime behavior of the #S0 and affe)t
the response sent ba)! to the )lient. 3he #S0 spe)ifi)ation lists some standard a)tion
types to be provided by all )ontainers* irrespe)tive of the implementation. Standard
a)tions provide page authors with some basi) fun)tionality to e5ploit= the vendor is
free to provide other a)tions to enhan)e behavior.
Synta5 of #S0 dire)tives is6
GWFdire)tive attributeDEvalueE WM
>here dire)tive may be6
1. page6 page is used to provide the information about it.
$5ample6 GWFpage languageDEjavaE WM

2. in)lude6 in)lude is used to in)lude a file in the #S0 page.
$5ample6 GWF in)lude fileDE1header.jspE WM

3. taglib6 taglib is used to use the )ustom tags in the #S0 pages ")ustom tags allows
us to defined our own tags%.
$5ample6 GWF taglib uriDEtlds1taglib.tldE prefi5DEmytagE WM

and attribute may be6
1. languageDEjavaE
3his tells the server that the page is using the java language. Current #S0
spe)ifi)ation supports only java language.
$5ample6 GWFpage languageDEjavaE WM

2. e5tendsDEmypa)!age.my)lassE
3his attribute is used when we want to e5tend any )lass. >e )an use )omma"*% to
import more than one pa)!ages.
$5ample6 GWFpage languageDEjavaE importDEjava.s7l.Z*mypa)!age.my)lassE
WM

Page
29
3. sessionDEtrueE
>hen this value is true session data is available to the #S0 page otherwise not. 'y
default this value is true.
$5ample6 GWFpage languageDEjavaE sessionDEtrueE WM

&. error0ageDEerror.jspE
error0age is used to handle the un:handled e5)eptions in the page.
$5ample6 GWFpage languageDEjavaE sessionDEtrueE error0ageDEerror.jspE WM

(. )ontent3ypeDEte5t1html=)harsetDIS4:[[(\:1E
+se this attribute to set the mime type and )hara)ter set of the #S0.
$5ample6 GWFpage languageDEjavaE sessionDEtrueE
)ontent3ypeDEte5t1html=)harsetDIS4:[[(\:1E WM
De)elopin fir!t 8SP
#ava Server 0ages are save with .jsp e5tension. ollowing )ode whi)h generates a simple
html page.
$5e)ute the e5ample.
GhtmlM
GheadMGtitleM/.3$G1titleM
G1headM
GbodyM
GWjava.util./ate dateDnew java.util./ate"%=WM
Current /ate is6GWDdateWM
G1bodyM
B6De)elop !er)er !i4e prorammin 0it* 4ata#a!e *an4lin< !er)let!<E8B<0e#!er)i(e on
!er)er !i4e 0it* !e("rit+ a!pe(t! (o)ere4.
,*at are Ser)let!-
#ava Servlets are programs that run on a >eb or .ppli)ation server and a)t as a middle
layer between a re7uest )oming from a >eb browser or other 9330 )lient and databases or
appli)ations on the 9330 server.
+sing Servlets* you )an )olle)t input from users through web page forms* present re)ords from
a database or another sour)e* and )reate web pages dynami)ally.
#ava Servlets often serve the same purpose as programs implemented using the Common
Oateway Interfa)e "COI%. 'ut Servlets offer several advantages in )omparison with the COI.
Page
30
0erforman)e is signifi)antly better.
Servlets e5e)ute within the address spa)e of a >eb server. It is not ne)essary to )reate
a separate pro)ess to handle ea)h )lient re7uest.
Servlets are platform:independent be)ause they are written in #ava.
#ava se)urity manager on the server enfor)es a set of restri)tions to prote)t the
resour)es on a server ma)hine. So servlets are trusted.
3he full fun)tionality of the #ava )lass libraries is available to a servlet. It )an
)ommuni)ate with applets* databases* or other software via the so)!ets and AMI
me)hanisms that you have seen already.
Ser)let! Ar(*ite(t"re$
ollowing diagram shows the position of Servelts in a >eb .ppli)ation.
Ser)let! Ta!>!$
Servlets perform the following major tas!s6
Aead the e5pli)it data sent by the )lients "browsers%. 3his in)ludes an 93M,
form on a >eb page or it )ould also )ome from an applet or a )ustom 9330
)lient program.
Aead the impli)it 9330 re7uest data sent by the )lients "browsers%. 3his
in)ludes )oo!ies* media types and )ompression s)hemes the browser
understands* and so forth.
0ro)ess the data and generate the results. 3his pro)ess may re7uire tal!ing to a
database* e5e)uting an AMI or C4A'. )all* invo!ing a >eb servi)e* or
)omputing the response dire)tly.
Send the e5pli)it data "i.e.* the do)ument% to the )lients "browsers%. 3his
do)ument )an be sent in a variety of formats* in)luding te5t "93M, or 2M,%*
binary "OI images%* $5)el* et).
Page
31
Send the impli)it 9330 response to the )lients "browsers%. 3his in)ludes telling
the browsers or other )lients what type of do)ument is being returned "e.g.*
93M,%* setting )oo!ies and )a)hing parameters* and other su)h tas!s.
Ser)let! Pa(>ae!$
Servlets )an be )reated using the 'a)ax.!er)let and 'a)ax.!er)let.*ttp pa)!ages.
Life C+(le $
. servlet life )y)le )an be defined as the entire pro)ess from its )reation till the
destru)tion. 3he following are the paths followed by a servlet
3he servlet is initialiJed by )alling the init ?6 method.
3he servlet )alls !er)i(e?6 method to pro)ess a )lient;s re7uest.
3he servlet is terminated by )alling the 4e!tro+?6 method.
inally* servlet is garbage )olle)ted by the garbage )olle)tor of the #VM.
T*e init?6 met*o4 $
3he init method is designed to be )alled only on)e. It is )alled when the servlet
is first )reated* and not )alled again for ea)h user re7uest.
3he init method definition loo!s li!e this6
p"#li( )oi4 init?6t*ro0!Ser)letEx(eption@
<< InitialiAation (o4e...
B
T*e !er)i(e?6 met*o4 $
3he servi)e"% method is the main method to perform the a)tual tas!. 3he servlet
)ontainer "i.e. web server% )alls the servi)e"% method to handle re7uests )oming from the
)lient" browsers% and to write the formatted response ba)! to the )lient.
3he servi)e"% method is the main method to perform the a)tual tas!. 3he servlet )ontainer
"i.e. web server% )alls the servi)e"% method to handle re7uests )oming from the
)lient" browsers% and to write the formatted response ba)! to the )lient.
9ere is the signature of this method6
p"#li( )oi4 !er)i(e?Ser)letRe."e!t re."e!t;
Ser)letRe!pon!e re!pon!e6
t*ro0!Ser)letEx(eption;IOEx(eption@
B
3he servi)e "% method is )alled by the )ontainer and servi)e method invo!es
doOe* do0ost* do0ut* do/elete* et). methods as appropriate. So you have nothing to do
with servi)e"% method but you override either doOet"% or do0ost"% depending on what
type of re7uest you re)eive from the )lient.
3he doOet"% and do0ost"% are most fre7uently used methods with in ea)h servi)e re7uest.
T*e 4oGet?6 Met*o4$
Page
32
. O$3 re7uest results from a normal re7uest for a +A, or from an 93M, form
that has no M$394/ spe)ified and it should be handled by doOet"% method.
p"#li( )oi4 4oGet?CttpSer)letRe."e!t re."e!t;
CttpSer)letRe!pon!e re!pon!e6
t*ro0!Ser)letEx(eption;IOEx(eption@
<< Ser)let (o4e
B
T*e 4oPo!t?6 Met*o4$
. 04S3 re7uest results from an 93M, form that spe)ifi)ally lists 04S3 as the
M$394/ and it should be handled by do0ost"% method.
p"#li( )oi4 4oPo!t?CttpSer)letRe."e!t re."e!t;
CttpSer)letRe!pon!e re!pon!e6
t*ro0!Ser)letEx(eption;IOEx(eption@
<< Ser)let (o4e
B
T*e 4e!tro+?6 met*o4 $
3he destroy"% method is )alled only on)e at the end of the life )y)le of a servlet.
3his method gives your servlet a )han)e to )lose database )onne)tions* halt ba)!ground
threads* write )oo!ie lists or hit )ounts to dis!* and perform other su)h )leanup a)tivities.
.fter the destroy"% method is )alled* the servlet obje)t is mar!ed for garbage )olle)tion.
3he destroy method definition loo!s li!e this6
p"#li( )oi4 4e!tro+?6@
<< FinaliAation (o4e...
B
Ar(*ite(t"re Diram$
3he following figure depi)ts a typi)al servlet life:)y)le s)enario.
irst the 9330 re7uests )oming to the server are delegated to the servlet
)ontainer.
3he servlet )ontainer loads the servlet before invo!ing the servi)e"% method.
3hen the servlet )ontainer handles multiple re7uests by spawning multiple
threads* ea)h thread e5e)uting the servi)e"% method of a single instan)e of the
servlet.
Page
33
Con(l"!ion$
3hus we have studied development of /ynami) web appli)ation.
Page
34