ShoutBox

1.ABSTRACT
2.INTRODUCTION
3.ABOUT ORGANISATION
4.SRS DOCUMENT
5.DESIGN PRINCIPLES & EXPLANATION
6.DESIGN DOCUMENT
6.1 SYSTEM DESIGN
6.2 FEASIBILITY STUDY
7.PROJECT DICTIONARY
7.1 UML DIAGRAMS
7.2 E-R DIAGRAMS
8.FORMS & REPORTS
8.1 I/O SPECIMENS
8.2 I/O SAMPLES
9.TESTING

ShoutBox

9.1 TEST CRITERIA & TEST CASES

9.2 TEST REPORT & ANALYSIS
10.
IMPLEMENTATION & USER
MANUALS
11.

CONCLUSION

12.

BIBLIOGRAPHY

ShoutBox

ShoutBox

ShoutBox is a form of real-time chat communicator

or synchronous conferencing. It is mainly designed
for

group

(many-to-many)

communication

in

discussion forums called channels, but also allows

one-to-one communication and data transfers via
private message. Only team members can enter
their room and the chat can then be automatically
documented in the form of a protocol. It's a fast,
easy and affordable way to host and manage realtime communication. It allows you to organize chatevents,

collaborative

meetings.

System

work

user

can

sessions
open

or

and

online
control
4

ShoutBox

multiples rooms. Moderators can manage users (list,

ban, kickoff), manage blacklist, generate transcripts,
do backup, and apply chatrooms parameters such as
max users, language, filters, performance, ... Server
side

needs

Servlets/JSP.

Client

side

could

be

HTML/CSS/JavaScript, Applets etc. Chatrooms are

easily customizables thanks to skins.
ShoutBox

is

fast,

reliable,

scalable,

fully

customizable and easy to install communication

platform without page flickering. This is not just a
chat for local networks. This chat was designed
initially with the only objective, namely, to have a
pleasure from the talk. Chat80 brings totally new
and superior approach making your communication
in the companies easier and faster than ever.
ShoutBox lets you use your computer to speak to
others

over

the

internet

or

your

local

office

computer network
This application is totally web-based, making it the
thinnest client possible. It's simple to install on the

ShoutBox

server, and needs no client install at all. This

application will let your visitors hold real time
discussions while surfing your site. This application
will turn your entire site into an awesome discussion
boulevard.
Features of this application:

Administration

panel:

Login/Password protected access. Password is

encrypted

in

config.

file.

One

web

page

to

open

room.

One

web

page

to

add/remove/update

moderators.
One

web

page

to

update/close/monitor

page

to

backup

chatrooms.
One

web

chatrooms.

One web page to manage ShoutBox parameters.

Multiple

chatrooms:

ShoutBox supports multiple chatrooms. You can

open, close, update, transcript, backup each

ShoutBox

chatroom. You can also monitor users in each

chatroom.

Blacklist

is

available

for

each

chatroom too.

Chatroom features: Chatroom parameters are:

name,

subject,

messages

and

(allowed

or

max.

users,

not),

private

display

mode

(frames, applet, flash), refresh model (way

clients are synchronized), refresh limit, history,
languages (English, Spanish, Danish, French,
German, Dutch, Portuguese ...), filters (HTML
Filter to prevent from cross scripting attacks
and

URL Filter

hyperlink

in

to convert http://...... into

the

chatroom

content)

and

moderators.

Users management :
Moderator users can list users per chatroom.
They

can

(temporary)

ban

(definitively)

some

users.

Kicked

or

kickoff

users

are

transfered into a blacklist which can be cleared.

Moderators can also track user's session in real

ShoutBox

time. Guest users are identified (nickname) but

not authenticated.

System

management:

System user can modify logs folder, backup

filename,
license

login,

password,

filename

and

users

others

timeout,
advanced

parameters. Chatrooms backup is automatically

done on servlet engine shutdown. Chatrooms
are automatically re-opened on servlet engine
re-start.

Clients:
Basically, ShoutBox provides 4 HTML/JavaScript
skins: Mutlilanguage, classic (simple text skin),
mIRC (mIRC look and feel), j-TV (graphical
skin).

It

also

(Multilanguage,
Comics).

Clients

includes

eXtremeSUN,
could

be

Applet

skins

Manga
FLASH5&6

and
or

Java/Swing Application too.

ShoutBox

ShoutBox

Existing System:
There is no existing system. Here we have
developed this application just to provide chat
rooms to chat different kind of moderators. This
is a system provides all the basic features of a
Chatting System.
Proposed System:
The first step of analysis process involves the
identification of need. The success of a system
depends largely on how accurately a problem is
defined, thoroughly investigated and properly
carried out through the choice of solution.
ShoutBox supports multiple chatrooms. You
can open new chatroom by following "open a
chatroom" link. You can manage a chatroom by
selecting the chatroom in the list box named
"Manage chatroom". You can backup all
chatrooms by following "Backup chatrooms"
link.
You can add/remove/update moderators. A
moderator is defined by an username (login), a
password and an email. Email field is not
mandatory. Links between moderators and
chatrooms could be configured in chatroom
10

ShoutBox

forms. In addition to chatroom's moderation

(kick off, ban, transcript, ...), a moderator can
open
many
new
chatrooms.
However
moderators cannot backup chatrooms, modify
ShoutBox
System
properties,
and
add/remove/update others moderators
Totally you have the control over chat rooms,
users, system properties to chang.
Display Mode : There are four ways to display
chatroom's content (i.e. chatooms clients). It
could be in an HTML/JavaScript page, an Applet,
a Java application or in a Macromedia Flash5
client. So, for HTML/JavaScript clients, you have
to choose between Framed (JSP) or BufferedFramed (JSP) modes. Buffered-Framed one is
optimized to lower flickering effect.

Project Scope and Objectives:

11

ShoutBox

ShoutBox is an application and is used to

create/manager/monitor chatrooms. You can
add/update/remove moderators. You can also
track user's sessions. Finally you can modify
ShoutBox system properties. Lot of effort was
put to make it user friendly.
Optimum utilization of application is
possible. All basic features are provided.
Reduces the user interaction work.
The wastage of time is reduced when
compared with old type chat rooms.
It also helps in optimum distribution of
funds by the management among user groups
for procurement of new equipment.
More
flexible/expendability
it
means
developer can --They can add more languages and support
to ShoutBox through XML resources files
based on multilanguage skin only

They can implement their own client

(HTML/JavaScript,
Applet,
Flash,
Java
Application). They only need API (JavaDoc) to
know how to interact with ShoutBox serverside. HTML/JavaScript skins are also a good
starting point. XML Connector service should
be used for remote clients (Applets, ...).

12

ShoutBox

They can implement additional filters by

extending ShoutBox.Chat. Filter.Filter abstract
class.

They can implement additional Transcript

by extending ShoutBox. Chat.Transcript.Dump
abstract class. Transcript implementation is
declared
in
ShoutBox.xml
(inside
<TRANSCRIPT> tag) and loaded at Runtime.

They can plug listeners by implementing

ShoutBox.Chat.Event.ChatroomListener
or
ShoutBox.Chat.Event.Chatroom
Listener
interfaces.

13

ShoutBox

14

ShoutBox

The ShoutBox is developed with the aim of

design an environment, in which users can enter
required existing chat room other wise he has a
choice of creating his own chat room as per his
interest. There are two users can chat privately
or publicly. Default option is public chat. We can
also set the system properties besides type of
display mode. There are four modes to select:
HTML/JavaScript, applet mode, java application
mode or Flash Media mode.
1.

Introduction
Purpose: The purpose of this
document is to describe all external
requirements for the ShoutBox. It also
describes the interfaces for the system.
1.1

ShoutBox is a JAVA JSP/Servlets chat

application. Here are the three
requirements you need to run it:

15

ShoutBox

Servlet Engine or Application

Server JSP1.0/Servlets2.1 compliant
(or higher).
JVM 1.2.2 or higher.
Browser (Internet Explorer 4.x or
higher, Mozilla 1.x, Netscape 4.x or
higher)
ShoutBox only needs HTTP to
communicate between server-side
(servlet engine) and client-side
(browser).
Scope: This document describes
the requirements of the system. It is
meant for use by the developers, and will
also be the basis for validating the final
system. Any changes made to the
requirements in the future will have to go
through a formal change approval
process. The developer is responsible for
asking for clarifications. When necessary
and will not make any alterations without
the permission of client.
1.2

ShoutBox should run under ANY platform

supporting JSP1.0/ Servlets 2.1(or
higher). This is the scope of our
16

ShoutBox

application
Tested platforms :
Servlet
Engine

WebServer

JVM

OS

SUN Win32
1.2.2_007
Tomcat
Apache
SUN - Solaris
3.2.4
1.3.14
1.3_01
2.7
Tomcat
Apache
SUN - Solaris
3.3.1
1.3.14
1.3_01
2.7
Tomcat
Tomcat
SUN Win32
4.0.3
4.0.3
1.3_02
Tomcat
Apache
SUN - Solaris
4.0.6
1.3.17
1.4.1
2.7
Tomcat
Tomcat
SUN Win32
4.1.18
4.1.18
1.3.0
Tomcat
Tomcat
SUN Win32
5.0.16
5.0.16
1.4.1
SUN Resin 1.2.3 Resin 1.2.3
Win32
1.2.2_007
SUN Resin 2.1.6 Resin 2.1.6
Win32
1.3_02
SUN JRun 3.01 JRun 3.01
Win32
1.2.2_007
SUN JRun 4.0
JRun 4.0
Win32
1.3_02
ServletExec NES-IPlanet SUN Win32
3.1
4.1 SP5 1.2.2_006
SunONE SunONE 7.0 SUN - Win32
Tomcat 3.1 Tomcat 3.1

17

ShoutBox

7.0
Weblogic
5.1 SP9
Weblogic
6.0 SP2
Weblogic
6.1
Weblogic
7.0 SP1

WebLogic
5.1 SP9
WebLogic
6.0 SP2
WebLogic
6.1
Weblogic
7.0 SP1

WTE 3.5.3

WTE 3.5.3

1.3.1
SUN Win32
1.2.2_007
SUN Win32
1.3.0
SUN Win32
1.3.1
BEA Win32
1.3.1
IBM Win32
1.2.2

IBM HTTP
IBM Server
1.2.2
1.3.12
IBM HTTP
WebSphere
Server
IBM - 1.3
4.0.2
1.3.19
WebSphere WebSphere
IBM - 1.3
5.0
5.0
SUN Orion 1.5.2 Orion 1.5.2
1.3.1
WebSphere
3.5.3

Win32

Win32
Win32
Win32

Definition: A ShoutBox can also

treat as a tool for creating an
environment, in which users can chat
with their required users and he is
allowed to create his own chat room.
Administrator has the right of setting the
system properties like Backup file, log
folder, system login, system email,
1.3

18

ShoutBox

timeout,
user
session
id,
default
language, updated password.etc.
1.4
Reference: Not Applicable.
1.5
Developers
Responsibilities
overview: The points that mentioned in
system requirements specification are
An introductory nature describing
mainly the
1.

Purpose

of

requirements
document.
Outlining
the

the

system

specifications
scope

of

the

envisaged application.
Describes the iterations of the
system with its environment without
going into the internals of the system.
Also describes the constraints imposed
on the system. Thus it is out side the
envisaged application. The assumptions
made are also listed. It is supported by
the
2.

UML Diagrams

19

ShoutBox

It also describes the internal

behaviour of the system in response to
the inputs and while generating the
outputs.
3.

This document is also supported with

detailed level UML diagrams, list of
inputs, process explanation and list of
output.
Contains
external
interface
requirements, which includes the user,
hardware and software interfaces.
4.

Deals
with
performance
requirements of the system. Contains
the design constraints composing of
software constraints and hardware
constraints.
5.

2.

General Description

Application
functional
overview:
ShoutBox
you
can
launch
it
and
create/manager/monitor chat rooms. You
20

ShoutBox

can add/update/remove moderators. You

can also track user's sessions. Finally you
can modify ShoutBox system properties.
User characteristics: In our project
user may be an administrator and an
ordinary enduser. Administrator have the
authority to set all the system properties.
Enduser can open a chatroom or can
create a chat room of his own with the
permission of admin. And also he can
choose the pubic or private chat. No need
to have the even minimum knowledge to
operate this system.
2.1

General constraints: The system

should
run
on
Pentium,
under
windowsNT/2000 professional or server
or forward versions of Microsoft operating
systems with minimum 16 MB RAM for
better performance. Actually these filters
can apply on any kind of Mail servers.
2.2

2.3

Assumptions and Dependencies:

It is assumed that the java web
server is Tomcat4.0.6, Tomcat is a
a.

21

ShoutBox

commercial-quality web server solution

based on the Java platform that
supports
the
Servlet
and
JSP
specifications.
b.
It is assumed that application
server is Bea WebLogic. t.
c.
All the details produced by the user
are correct.
d.
Other auxiliary systems like Java
Naming and Directory Interface.
3.

Function Requirements

Functional requirements specify which

outputs should be produced from the given
inputs. They describe the relationship between
the input and output of the system, for each
functional requirement a detailed description
of all data inputs and their source and the
range of valid inputs must be specified.

All the operations to be performed on the

input data to obtain the output should be
specified.

22

ShoutBox

Inputs: Inputs are nothing but

data have to be entered by user or some
properties settled by admin. User has to
feed relevant data only depends on the
operation going to take. To login user has
to give nickname and chatroom as inputs.
3.1

Outputs: Outputs are reflected

immediately. Every text we entered in
text window part is reflect on public main
body of the chat room form.
3.2

4.

External Interface Requirements

User Interface: Here user interface is
developed using JSPs using which we can
design and develop the pages which are
attractive and dynamic. It is also very
easy to navigate from one place to
another place. We put lot of efforts to
make the user interface attractive and
process the data which is fed by the user.
4.1

Software Interfaces: This interface

requirements should specify the inter face
4.2

23

ShoutBox

with other. Software which the system

will use or which will use the system, this
includes the interface with the operating
system and other applications.
The message content and format of each
interface should be given.
4.3 Hardware
Interfaces:
Hardware
interface is very important to the
documentation. If the software is execute
on existing hardware or on the predetermined
hardware,
all
the
characteristics of the hardware, including
memory restrictions, should be specified.
In addition, the current use and load
characteristics of the hardware should be
given.
5.

Performance Requirements

All the requirements relating to the

performance characteristics of the system
must be clearly specified. There are two types
of performance requirements static and
dynamic.

24

ShoutBox

Static Requirements are those that do not

impose
constraint
on
the
execution
characteristics of the system. These include
requirements like the number of terminals to
be supported, and number simultaneous
users to be supported, number of files, and
their sizes that the system has to process.
These are also called capacity of the system.
Dynamic requirements specify constraints on
execution behaviour of the system. These
typically
include
response
time
and
throughput constraints on the system.
The processing speed, respective resource
consumption
throughput
and
efficiency
measure performance. For achieving good
performance few requirements like reducing
code, less use of controls, minimum
involvement of repeated data etc., are to be
followed. Each real-time system, software
what provides required function but does not
conform
to
performance
of
software
requirements
is
acceptable.
These
requirements are used to test run time
performance of software with the context of
an integrated system.

25

ShoutBox

6.

Design constraints
6.1

Software constraints

Operating System
:
Windows2000 Server/
XP.
Reports
: General Reports
Other Applications
:
Tomcat WebServer or
BEA WebLogic
Server
6.2

7.

Hardware Constraints

Pentium Processor
Intel 2.0 GHZ
RAM
Hard Disk
CD/ROM Drive
52 Bit
VDU
Key Board
Standard

:
:
:

256MB
40 GB
:

:
:

VGA
101

Acceptance Criteria

26

ShoutBox

Before accepting the system, the developer

must demonstrate that the system works on
the details of the user email-ids entered in
the corresponding files. The developer will
have to show through test cases that all
conditions are satisfied.

SERVLETS
Introduction to web applications:
HTTP is used by the browsers to communicate with
the web servers. In place of browser we can develop
our own programs using Socket API to communicate
with a web server.
According to HTTP the user agent/http client/browser
sends a request for a resource and gets back
response. According to the protocol the web
server/http server sends the response with a status
code. Most of the web servers are configured not to
list the contents of a directory. Almost every web
server provides an option of defining a list of files as
welcome files.
TOMCAT:
Tomcat_home is a directory in which TOMCAT is
installed. Ex:
C:\Tomcat\Tomcat5.0 (most it look like C:\ jakartatomcat-5.0.19/jakartatomcat27

ShoutBox

5.0.19 when you extracted zip file to C drive)

Starting and Stopping Tomcat :
To start Tomcat run Tomcat_Home\bin\startup.bat
To stop Tomcat run Tomcat_Home\bin\shutdown.bat
Tomcat requires the location in which java is installed
for this we need to add set JAVA_HOME=path
where
jdk
is
installed
and
add
set
CATALINA_HOME=..
in
both
startup.bat
and
shutdown.bat. If you are not installed the tomcat, for
accessing Admin and Manager we need to add
<role rolename="manager"/>
<role rolename="admin"/>
<user username=uname" password=pwd
roles="admin,manager,tomcat"/>
to Tomcat_Home\conf\tomcat-users.xml
Tomcat is configured to listen at port no 8080. We
can change the port no using configuration files.
(Tomcat_Home\conf\server.xml
file
change
<Connector port="8080 >).
Request and Response formats:
Request format:
Initial request line
header1
header2
header3
.
.
.
Body (optional)
28

ShoutBox

Most of the browsers either implements http 1.0 or

1.1 protocol. According to http, initial request line
contains
Request method
Requested resource
Protocol version
Header is split into (1) Header name (2) Header
value
Ex: User-Agent : MSIE
Response Format:
Initial response line
header1
header2
header3
.
.
Body
In the response the server sets several heads like
Server ----- Name of the server
Content length ----- Length of the content
MIME is standard format in which different types of
contents can be placed standard format used by email clients
Status Codes:
1xx Informational message only
2xx Success of some find
3xx Redirects the client to another URL
4xx Error on clients part
5xx Error on servers part
Standard Request Methods:
GET Used to request a resource
29

ShoutBox

HEAD Used to request only header part

POST Used to send the data from client to server
ex: when we will fill the form the browser may send
the data
OPTIONS Used to identify the options supported by
the browser
PUT Used by the clients to ask the server to store
the content on it
DELETE Used to ask the server to delete a file
Diff Btw Get and Post :
In our programs most of the time we will use GET or
POST methods. In HTML forms we can specify the
method as POST or GET When we use GET method
the browser appends the form data to the URL but
when we use POST method the data will not
appended to the URL. Data will be placed as part of
request body. In order to upload files from browser
to web server we can use <INPUT Type= file> for
these types of forms we need to use POST instead of
GET.
Web-Containers:
Java soft has released Servlet and JSP specifications
publicly. There are so many vendors who has
provided the implementation of these specifications.
All these products are known as web containers.
A web application developer develops a web
application using different resources like html pages,
image files, servlets, jsp pages, ..

30

ShoutBox

Configuring web applications:

Java soft has defined a standard approach for
configuring web applications. Once the web
application is configured we can deploy it on any of
the available web containers.
Steps:
Create WEB_APP_ROOT directory
Under WEB_APP_ROOT create WEB-INF
Create classes and lib directories under WEB-INF
( place java classes in classes directory and .jar files
in lib directory)
Create web.xml and place it under WEB-INF
Create a WAR (Web Application Archive) file using
java tool for this move to WEB_APP_ROOT dir and
use jar cvf webapp.war . Above command places all
files in webapp.war We use content paths to identify
the
web
applications.
Ex:
http://localhost:8080/myweebapp1/index.html
By
default index.html is consider as a welcomefile.
According to our application we can configure a
different set of welcome files. Ex:
<welcome-file-list>
<welcome-file>index.jsp</welcome-file>
<welcome-file>index.html</welcome-file>
<welcome-file>index.htm</welcome-file>
</welcome-file-list>
The web containers will not be sending the
information about WEB_INF directory to the user
agent. Even though we can place all the files under
the root it is not recommended. It is not
recommended to use the absolute paths of the
resource in a web application. We have to use
31

ShoutBox

relative paths. Managing web applications in web

containers:
Most of the vendors provide the tools to manage the
web applications. We can use these tools to upload
our war files to the server and deploy them. Ex: In
Tomcat
Use the URL http://localhost:8080
Choose Tomcat Manager (by using uname and pwd
given in config file)
Choose the war file to be uploaded choose install In
Tomcat
Login to Tomcat server using admin uname and
pwd
Choose War File to deploy upload the war files
Select the war file place it on server, configure and
deploy it Today most of the websites generates the
content dynamically (when a request is send the web
server, the content is generated)
First generation web servers are designed to serve
the static content. Later on the web servers provided
an option of extending its capability using CGI A CGI
program or script is the one that runs external to a
web server. Earlier most of the programmers have
used CGI programs to generate content dynamically.
The main problems with this approach are
Server has to spend some time in starting a new
process
As web server gets too many requests the server
has to create more no of processes and this reduces
the performance.

32

ShoutBox

As scripting languages are easier than programming

languages most of the web developers has started
writing web applications using scripting languages.
To run the perl scripts we require a program called
perl interpreter. Even it is easy to develop perl
scripts we need an interpreter to run them. Later on
most of the web server vendors started supporting
different scripting languages directly.
Java soft designed an alternative for CGI programs
as well as script getting executed in a web server
called as a Servlet. In servlets the request send by
the browser and the response send by the server will
be represented as objects. While compiling the java
servlets we need to set the classpath point to a jar
file that contains javax.servlet and javax.servlet.http
packages (in most cases the jar file will be
servlet.jar or servlet-api.jar or .).
Every container vendor supplies the jar files that
contain
javax.servlet
and
javax.servlet.http
packages.Deploying servlets:
After developing the servlet classes to deploy the
servlets,

Copy
the
servlet
classes
under
WEB_APP_ROOT/WEB-INF/classes
Modify web.xml by adding the information about
the servlet element as
<servlet>
<servlet-name>servlet1</servlet-name>
<servlet-class>class of servlet</servlet-class>
33

ShoutBox

</servlet>
<!-- mapping our servlet -->
<servlet-mapping>
<servlet-name>servlet1</servlet-name>
<url-pattern>/serv1</url-pattern>
</servlet-mapping>
We can use any url pattern like * or *.do or *.xyz
etc ex:
<url-pattern>/*</url-pattern>
To get the name of the user agent we can use
stringbuffer = request.getHeader(USER_AGENT);
We can get the list of all headers using
Java.util.Enumuration
list
=
request.getHeaderNames
To invoke a servlet from our applications
( standalone java apps/applets/ servlet/ejb )
Establish a socket connection with web server
Send http request to the server
Read the response
Servlets are initially designed to extend any type of
server (web server/ ftp server / smtp ) but almost
all the companies has implemented this technology
to extend http servers.
In object oriented projects to eliminate redundancy
we will be using class hierarchy as,

34

ShoutBox

In above ex, code specific to web server in http

server class, code specific to ftp server in ftp server
class and code that is common to all the servers is
implemented in server class. Servlet class hierarchy:

A servlet is an object that provides the

implementation of javax.servlet.Servlet interface.
Web container must provide one ServletConfig object
to a servlet. ServletContext is also called as
application object. javax.servlet.Servlet has the
following methods
init called by the web container after our servlet
object is created.
service called when the client sends the request.
destroy called before our servlet object is
removed.
A servlet life cycle has 3 stages, (a) servlet is
created (b) servlet will provide the service (c) servlet
will be destroyed.

35

ShoutBox

getServletInfo() must return a string describing the

purpose of our servlet. getServletConfig() method
must return the servlet config associated with the
servlet. It is the responsibility of servlet containers to
create the servlet objects and destroy.
<load-on-startup>10</load-on-startup> where 10 is
the priority.
If we use it, the web container will be created our
servlet object when our application is deployed.A
servlet object is created
At the startup if we use load-on-startup
When the initial request is send and the servlet is
not yet available or
Whenever it is required.
Servlet object will be destroyed
When the web application is undeployed
Whenever the server wants to remove.
The GenericServlet implemented as part of
javax.servlet package provides the implementation
of init method and getServletConfig method that fits
almost all the servlets. javax.servlet.http.HttpServlet
provides the implementation of service method. We
can implement a servlet as a sub class of
36

ShoutBox

GenericServlet. service method of GenericServlet

takes ServletRequest and ServletResponce as
parameters.

HttpServletRequest
and
HttpServletResponce
contains methods specific to http and same as with
ftp. If we create a servlet as subclass of
GenericServlet we may need to write common code
like converting the reference of type ServletRequest,
ServletResponce
to
HttpServletRequest
and
HttpServletResponce.
This can be eliminated by creating our servlet as a
subclass of javax.servlet.http.HttpServlet. Inside the
servlet containers our servlets are pointing by using
reference of type javax.servlet.Servlet.
Whenever a method is called on an object the JVM
will start searching for the method from the class
based on which the object is created. If it is not
available then the method will be searched in the
super class. The containers always calls the methods
exposed by Servlet interface.
init(ServletConfig) {
init() }
37

ShoutBox

service(ServletRequest, ServletResponce) {
service(HttpServletRequest,HttpServletResponce) }
service(HttpServletRequest,HttpServletResponce) {
doXXX() }
The
implementation
of
doXXX
methods
of
HttpServlet sends an error to the user agent. To
report an error from our servlets we can use
response.SendError(status code)
Before we start development of any solution we need
to understand the business requirements and
functional
specifications.
We
can
use
request.getParameter to get values sumbitted using
a form. Instead of using System.out for debugging
its better to use log method. The data will be stored
in a destination like in a log file or as database. To
know the location of log file we need to read the
documentation of the container.
Typical sequence of steps we carry out in a servlet to
process the form
Read the input parameters
Validate the input
Process the input
Generate the view.
Instead of hard coding we can place the information
as servlet initialization parameters or context
parameters.
If multiple servlets uses the same set of parameters
instead of placing them as servlet initialization
parameters we can use context parameters.
<context-param>
38

ShoutBox

<param-name>name1</param-name>
<param-value>value1</param-value>
</context-param>
getInitparameter() available in ServletContext will be
getting the initialization parameters configured as
context parameters.
ServletContext scon = getServletContext();
url = scon.getInitParameter(dburl)
1st line gets the reference of servlet context
2nd line gets context parameter.
We can add any no of context parameters in web.xml
file. The web container is responsible for reading
context parameters from web.xml and places them
in ServletContext. For every servlet the container is
responsible for creating ServletConfig and stores the
init parameters in this object.
public class init extends HttpServlet {
public void doGet() {
HttpServletRequest req;
HttpServletResponce res;
out.getInitParameters(name);
}
public void init(ServletConfig config) throws
ServletException{
System.out.println(ServletConfig.getInitParameter(
name);
}
Above code in doGet() will be failing to get the initial
parameters. To avoid this failure we need to add
super.init(config) if init method is overridden.
39

ShoutBox

Methods like getInitParameter, getServletConfig,

getServletContext, log available in GenericServlet
will fail if we write code with calling super.init().
Instead of overriding init(ServletConfig) we can
override init() We can store the strings as resource
bundles instead of hard coding the strings in source
code. Its very common to submit the information
using multiple forms ex: user registration form can
be split-up into multiple forms.

In above ex information is gathered from the user

using 3 different forms. Once the user fills the 1st
page he gets the 2nd page after it is filled he gets
3rd page. Once the 3rd page filled, information will
be saved in database. If the protocol is designed to
remember what is done earlier by the client then it is
called as stateful protocol otherwise it is called as
stateless protocol.
** Http 1.0 as well as Http 1.1 is stateless protocols.
If we have application with multiple forms the web
server will be able to give the information submitted
in the current form, it will not be able to give us the
info submitted earlier.A web application can use
following techniques to remember the state of the
client.
Hidden Fields
40

ShoutBox

Cookies
Sessions using cookies
Sessions using URL rewriting.
We can use <input type= hidden name=n1
value=v1> as part of our html forms. Browser will
not be developing the info about the hidden fields. If
there are too many no of forms more amount of N/W
traffic will be generated if we use hidden fields.
Cookie is a piece of info set by the server on the
client using http. We can use response.setCookie() to
set a cookie on a browser, to get the cookies we can
use request.getCookie()
Steps to set cookie:
Create a cookie object cookie c1 = new
cookie(name, value)
Add the cookie response.addCookie(name)
Cookies are mainly used to serve personalized
content according to user requirement.
Problems:
If used heavily this generate more N/W traffic
There are some limitations in some browsers in
maximum no of cookies per domain.
It is not advisable to store sensitive info using
cookie. When we execute response.addCookie(), it
adds set-cookie header to the response. Browser
sends back the cookie as part of request header as,
cookies
name1=value1&name2=value2
Most of the browsers provide an option of allowing or
denying the cookies. Most of web application
developers display a message saying that their web
application works properly if the cookies are allowed.
41

ShoutBox

The cookie class provides the methods setMaxAge,

setDomain, setPath In most of he cases we may
not use these methods. We can store any java object
using session.setAttribute(key, java object) ,
request.setAttribute,
ServletContext.setAttribute( key, jo)
We can retrieve the objects by using
session.getAttribute(key)
request.getAttribute(key)
ServletContext.getAttribute(key)
To remove the java object we can use
xxx.removeAttribute(key)
The web containers can create the session objects on
behalf of a client. For accessing the session object
we use, request.getSession(true/false). For every
session object that is created a session id will be
generated.
request.getSession(true)
creates
a
session object if it is not already exists. We can
remove
the
session
objects
by
using
session.invalidate(). As the server cant detect the
closure of browser, the server deletes the session
object after inactivatetimeout which can be
configured in web.xml or we can use
session.setMaxInactiveInterval(int)
session.setAttribute(key1,value1);
session.setAttribute(key1,value2);
session.getAttribute(key1);
session.getAttribute(key2);
When 1st stmt executed value1 will be stored using
key1 and when 2nd stmt executed value1 is removed
and value2 is stored in key1. 3rd stmt gets value2
and 4th line gets null. A web application based on
42

ShoutBox

session using cookie to carry session id may failed (if

user doesnt accept cookies). To overcome this we
can use sessions maintain using URL rewriting
technique.
To use URL rewriting in our servlets, we need to use
response.encodeURL(string)
instead
of directly
writing the URL. When we use response.encodeURL,
the URL will rewritten as, /xyz/abc +session id This
technique places a bit of burden on server (server
has to spend some time in writing URLs with session
id).
To upload the files we have to use post method. In
the form we can use any no of inputs. For files the
input type must be specified as file. There are so
many file uploading components available in the
market one such component is javazoom file upload
component. You can see details at
http://www.javazoom.net/jzservlets/uploadbean/upl
oadbean.html
To deals with upload files
Create a newreq object using the class javazoom
To get the list of the files we can use getFiles()
uses a list of files in a hash table.
To store the files:
Create uploadBean
Set the folder
Set override policy
Execute store method with newreq as parameter.
To read the parameter submitted as part of the form
we can use newreq.getParameter() .Ex: book store
43

ShoutBox

provided by java soft We can consider deploying a

web application, un-deploying a web application,
creating a session, adding an attribute, removing an
attribute from ServletContext, HttpSession as
events. We can write the code by implementing the
listeners
interface
provided
as
part
of
javax.servlet.http package.
Names of the listener interface,
ServletContextListener, HttpSessionListener,
ServletContextAttributeListener and
HttpSessionAttributeListener ContextInitialized is
called when the application is deployed.
ContextDestroyed is called when the application is
undeployed.
We can implement the above listeners and configure
them as listeners in web.xml file as,
<listener><listener-class> Class Name</listenerclass> </listener>
SessionListener interface has (a) sessionCreated
called when the session is
created (b) sessionDestroyed called when session
is destroyed.
Whenever we need to add an object as soon as the
session object is created.
We can write the code in sessionCreated of
HttpSessionListener.
Along with the cookie we can pass a comment
indicating the purpose of the
cookei using cookie.setComment() Netscape 4.75
(old versions) stores the cookies in cookies.txt file
and IE uses multiple files. When we specify the age

44

ShoutBox

of the cookie the browser stores the info about the

cookie in a file,
1) Name of the cookie
2) Value of the cookie
3) Path of cookie
4) Domain of the cookie and
5) Expire time of the cookie.
In most of the applications the parameters will not
setting the path explicitly using setPath() In such
case path of the cookie will be set to the path of
resource. It is very rare to use setDomain() on a
cookie. By default domain value will be set to the
domain name where the cookie is set ex:
http://localhost or www.yahoo.com A servlet running
at www.domain1.com cant set a cookie specifying
the
domain
name
of
the
cookie
as
www.domain2.com. If the cookies are set by
hotmail.com the browser will send back to
hotmail.com only. This is why the browser stores the
domain of a cookie. While sending back the cookies,
browser will check whether the path of requested
resource is matching with the path of the cookie or
not. If we are running 2 web applications in same
server one servlet in application1 can set a cookie
that can be reuse by servlet in application2. We can
remove the cookie that is set earlier by setting its
MaxAge to 0; if we have not used setMaxAge -1 will
be used as default. If MaxAge is -1 the browser will
not storing the cookie in file, cookie will held in
memory and its get deleted when the browser is
closed. We need to pass the no of seconds the cookie
has to live. Ex: setMaxAge(600) cookie will live 10
45

ShoutBox

min. We can assign multiple names like a.com,

b.com, www.a.com to the same machine. On the
global internet the N/W administrators will be
configuring the DNS servers with this mapping. We
can place the mapping between the name and IP
address
in
C:/winnt/system32/drivers/etc
(in
2000/NT)
C:/windows/system32/drivers/etc (in win Xp).
Ex: 102.54.94.97 xyz.com
abc.com
Http 1.1 supports virtual hosting hosting the web
site with different domain names on a single sever.
This is supported by using the Host header.
According to Http 1.1 Host header is mandatory.
Using this header the web server will be able to
identify the resource that has to be served. It is very
common to refer images, applets, activex controls in
a webpage. In older Http protocol the browsers used
to establish a connection, sends the request, get the
response, and disconnect the connection. If we have
a html file with 10 images embedded inside it. The
browser has to repeat the same steps for 11 times.
This may reduce the performance of browser as
establishing a connection is time consuming process.
Browsers can send connection keep alive header
asking the web browser to keep the connection alive.
The server may or may not keep the connection
alive.
Most of the web administrators either disable keep
alive request or disable persistent connection or set
the connection timeout to a small value. If we expect
too many concurrent users then to improve the
46

ShoutBox

performance of web server. We use small value for

no of connections that are kept alive or we can total
disable persistent connection.
**Irrespective of the type of connection http is
stateless.

The above web application uses Front Controller

design pattern In this design pattern we use one
servlet to act as a controller sitting in front of other
resources. In this design pattern all the requests will
be first handled by FC then it dispatches the request
to the appropriate resource. The servlet engine
internally uses RequestDispatcher to dispatch the
request to the appropriate servlet or jsp. We can use
ServletContext.getRequestDispatcher() to get the
request dispatcher.There are two methods (a)
forward (b) include Its very common to develop a
web application with more Servlets processing the
same request.
** We can use both include and forward to dispatch
the request to other servlets. When we use include
the outputs generated by both the servlets will be
sent to the client when forward is used the output
generated by 1st servlet will be discarded and only
2nd servlet output will be send to the client.

47

ShoutBox

Difference between Request Forward and

Redirect :
When we forward method only one request will be
send by the browser and it is processed by two
servlets/jsps. But when we SendRedirect method two
requests will be send by the browser.

JSP
Most of the web developers deploying web
applications
using servlets mixes the presentation logic and
business logic. Separation of business logic from
presentation logic helps us in simplifying the
development of application( web authors can
48

ShoutBox

concentrates on developing the presentation logic

and other developers in the team who has good
knowledge of java can concentrate on business logic
in (1)Java Beans (2)EJB and (3)Tag Handlers)
Java Server Page is designed to simplify the process
of developing a web application on the top of servlet
technology. Writing and configuring the application
using
JSP
is
easy
Javax.servlet.jsp
and
javax.servlet.jsp.tagext contains the interfaces to
support JSP technology and Tag libraries. When we
send a request to JSP file if there is no servlet
representing the JSP file the web container runs JSP
compiler that generates the servlet code. Whenever
we modify the JSP file the servlet will be
regenerated. Some of the web containers provide an
option of pre-compiling of JSP. We can place our JSP
files directly under WEB_APP_ROOT or any other sub
directory except WEB-INF.We need not add an entry
in web.xml file for most of JSPs. When we need to
pass initialization parameters to JSPs then we have
to make an entry in web.xml as,
<servlet>
<servlet-name>servlet1</servlet-name>
<jsp-file>one.jsp</jsp-file>
</servlet>
<!-- mapping our servlet -->
<servlet-mapping>
<servlet-name>servlet1</servlet-name>
<url-pattern>/jsp1</url-pattern>
</servlet-mapping>

49

ShoutBox

If there are any errors in JSP file the jsp compiler

fails to compile the java source code. We can check
the log files for more information on session for
failure.ASP allows us to mix html with a scripting
language like jscript, vb script JSP also allows us to
mix html with java language (scriptlet) or scripting
languages. Most of the web containers support only
java language code be mixed with html. Resin
supports jscript as part of JSP. In JSP files we can
use Page directives like Language, Import, Include
These directives very much similar to preprocessor
directives we use in C programs.
It is very common to have the same header and
footer for multiple web pages, to simplify the
development of such applications we develop
header.jsp responsible for generating only the
header portion and footer.jsp to generate the footer.
In all other JSP pages we write the code as,
Page1.jsp : Page2.jsp:
Include header.jsp Include header.jsp
Content1 Content1
Include footer.jsp Include footer.jsp
Ex: www.oracle.com (same header and footer for all
pages)
When we send the request for page1.jsp the JSP
compiler internally generates Page1.jsp by merging
header.jsp, footer.jsp with Page1 and this JSP page
will be converted as a servlet. According to JSP
specification the container need not regenerates the
servlet whenever there is a change in the files that
are included using include directive. Tomcat
50

ShoutBox

regenerates the servlet even if there is a change in

the included file. When we used Info directive JSP
compiler generates getServletInfo method. Language
directive can be used to specify the language that is
used as part of our JSP. Ex:Page Directive:
<%@ page
[ language="java" ]
[ extends="package.class" ]
[ import= "{ package.class | package.* }, ..." ]
[ session="true|false" ]
[ buffer="none|8kb|sizekb" ]
[ au0toFlush="true|false" ]
[ isThreadSafe="true|false" ]
[ info="text" ]
[ errorPage="relativeURL" ]
[ contentType="mimeType [
;charset=characterSet ]" |
"text/html ; charset=ISO-8859-1" ]
[ isErrorPage="true|false" ]
%>
For more information on JSP page directives see the
URL
http://www.developer.com/java/other/article.php/62
6391
Whenever we use an object in System.out.println
internally toString() will be executed. Ex: Date d =
new Date();
System.out.println(d);
System.out.println(d.toString());
If we need to use a class in a package other than the
default package we can use import package or fully

51

ShoutBox

qualified name of the class in our code In our JSP

pages to import the classes we can use
<%@ page import = java.util.Date %>
<%@ page import = java.io.* %> (or)
<%@ page import = java.util.Date, java.io.* %>
We can include the java code directly as part of JSP
files ,
<% Java Code %> called as scriptlet. When the JSP
compiler compiles the JSP file it copies the scriptlet
as it is in jspService method. Html content
<%= new java.util.Date() %>
<% int i=10; out.println(i=,+i); %>
In above code we have declared a variable i and
used in print stmt but we are using a variable out
without declaring it but it is perfectly valid in JSP
scriptlets.
Implicit Variables:
JSP compiler generates JSP code with a set of
variable like (i) out ii) request iii) response iv)
pageContext v) session vi) application vii) config and
viii) page. All the variables can be used in the
scriptlets without declaring them. These variables
are called as well known variable or implicit
variables. For more info on implicit variable see the
following link
http://javaboutique.internet.com/tutorials/JSP/part1
1/page07.html
page refers to this current object and pageContext
is an object (javax.servlet.jsp.pageContext) that is
created for every JSP page and it provides access to
the other objects like out, session . We have
methods like forward and include performing
52

ShoutBox

operations like RequestDispatcher.forward and

RequestDispatcher.include In JSP pages we can use
declarative statements to define the variables or
implement the methods as,
<%! int i; %>
We can write our own methods, static variables and
instance variables in declarative statement as,
<%! Static int x =10;
int add (int a, int b) { return a+b; }
%>
It is highly recommend to use tag libraries instead of
using scriptlets and declarative statement.
In java we use try catch blocks to separate out the
actual code that performs the action and code the
code that deals with error. In JSP we can provide the
implementation of code that handles the error in a
separate page. This JSP page is known as error
page. For supporting the above concept JSP provides
isErrorPage and errorPage directives.

When an exception is thrown while executing one.jsp

file the container will start executing errpage.jsp. We
can access the exception variable without declaring it
in error pages. Instead of sending the data byte by
byte to the browser the web container collects the
data in a buffer. If the size of the buffer is enough to
accommodate the whole o/p of JSP page the o/p is
collected and send at once to the browser. This
reduces the amount of Network traffic. If the jsp
53

ShoutBox

generates more amount of data than the size of the

buffer the container frees the buffer once it is filled
(this is done if autoFlush is set to true)
<%@ page buffer="1kb"%>
<%@ page autoFlush="false"%> ( default is true)
When we encounter JSP buffer overflow exception we
can solve it either by increasing the size of the buffer
or by setting the value of autoFlush to true. In JSP
pages we can use action tags like include, forward,
useBean, setProperty, getProperty, param these
tags are supported by all the web containers. See url
http://javaboutique.internet.com/tutorials/JSP/part1
1/page08.html
<jsp:include page=page2.html" flush="true" /> It
includes the content of page2 (it may be of type
jsp/html/img .) in the o/p sent to the client
(internally
it
uses
requestDispatcher.include)
similarly we can use jsp:forward tag to forward the
request from one page to other page. This is
equivalent to requestDispatcher.forward. If the data
is already committed before the execution of
jsp:forward then forward will be failed. We can solve
the problem by increasing the buffer. There will be
no difference in the o/p produced by using
jsp:include and include directive. When we use
include directive the contents will merge together by
jsp compiler and generates a single servlet but when
we use action tag include two servlets will be
generated and in first servlet code similar to
requestDispatcher.include will be added.

54

ShoutBox

There may be slight benefit in terms of performance

using include directive. When we use jsp:include a
change in main file and change in sub file causes
regeneration of the servlets. According to jsp
specification the container need not regenerates the
servlet if there is a change in included file when we
use include directive We can write the functions as
part of declarations and in these function we cant
access implicit variables. Implicit variables are local
to jspService and can be accessed from the
scriptlets. We can provide the implementation of
jspInit and jspDestory which are equivalent to init()
and destroy() methods in the servlets. As part of JSP
files we can use jsp expression as,
<%= Java Expression %>
ex: Current time: <%= new java.util.Date() %> In
jsp 2.0 we have support for EL Expression
Language
Tomcat as well as other web containers internally
creates the threads and access the service method
from the threads. A servlet container creates
multiple threads and accesses the service method
from these threads concurrently as shown below
same point of time it sends the response.

55

ShoutBox

Since the servlets are accessing from multiple

threads the code in Servlets must be ThreadSafe.
Code will be thread safe if it can be executed
concurrently from multiple threads. All the objects
we will use from our servlets using instance variables
must be thread safe. Not every java class is thread
safe ex: AWT, JFC classes If our servlet uses only
locals variables we can claim that our servlet is
thread safe. We can develop a servlet by
implementing single thread model. This is a marker
interface or tagged interface. From servlets 2.4 this
interface is deprecated and it is not recommended.
By implementing this interface we are telling the web
container that my service method cant executed
concurrently from multiple threads. Most of the web
container vendors creates multiple servlet objects
based on same class if the servlet implements single
thread model. In this case more amount of memory
space is required.
Java Beans:
We can assemble a computer or fan very easily by
choosing different components manufactured by
different vendors. We can take a screw from
company one and use it to fit the Mother board to
cabinet as they are manufactured according to a
standard. Observing to this point to simplify the
process of developing software, different software
companies has proposed different component
technologies. Ex: java soft java bean component
tech, EJB component tech, Microsoft COM, BONOBO
56

ShoutBox

component model. Java Bean and EJB are two

different specifications from java soft. EJB can be
used to implement business logic on the server side.
Most of the developers uses to assume Java Bean
components are for developing GUI components and
they can be used only on the client side but we can
develop any kind of software using Java Bean
standard (GUI/ non GUI). Java Bean can be used
either on the client side or on the server side. AWT,
JFC components are implemented according to Java
Bean standard. According to Java Bean standard a
Bean component can support a set of properties, set
of events, any number of additional methods. A
property can be read-write or it can be just read only
property. For read write property we need to provide
setXXX and getXXX methods (isXXX if the property is
Boolean )
To support the following properties (i) uname (ii)
email (iii) age according to Java bean standard we
need to write the code as,
public class UserBean {String uname;
String email;
int age;
public void setUsername( String value ) {uname =
value; }
public void setEmail( String value ) { email =
value; }
public void setAge( int value ) { age = value; }
public String getUsername() { return uname; }
public String getEmail() { return email; }
public int getAge() { return age; }
}
57

ShoutBox

Java Beans like JButton supports the events by

providing the methods with
naming
patterns
(i)
addXXXListener
(ii)
removeXXXListener
Apart from developing Java bean class we can also
provide BeanInfo class.
In this class we can provide (i) Information about
properties (ii) Information
about the events and (iii) Information about the icon
that represents our
bean.
According to JSP model1 we can develop the
application as,

According to above model the presentation logic has

to be implemented in JSP page and the business
logic has to be implemented as part of Java bean
This model help us in separating the presentation
and business logic. For a large scale projects instead
of using model1 it is better to use model2 (MVC).
Stuts frame work is based on model 2.

58

ShoutBox

59

ShoutBox

60

ShoutBox

DESIGN PRINCIPLES & METHODOLOGY

To produce the design for large module can

be extremely complex task. The design
principles are used to provide effective handling
the complexity of the design process, it will not
reduce to the effort needed for design but can
also reduce the scope of introducing errors
during design.
For solving the large problems, the problem
is divided into smaller pieces, using the timetested principle of divide and conquer. This
system problem divides into smaller pieces, so
that each piece can be conquered separately. For
software design, the problem is to divide into
manageable small pieces that can be solved
separately. This divide principle is used to
reduce the cost of the entire problem that
means the cost of solving the entire problem is
more than the sum of the cost of solving all the
pieces.
When partitioning is high, then also arises a
problem due to the cost of partitioning. In this
61

ShoutBox

situation to know the judgement about when to

stop partitioning.
In design, the most important quality
criteria are simplicity and understandability. In
this each the part is easily related to the
application and that each piece can be modified
separately. Proper partitioning will make the
system to maintain by making the designer to
understand problem partitioning also aids design
verification.
Abstraction is essential for problem
partitioning and is used for existing components
as well as components that are being designed,
abstracting of existing component plays an
important role in the maintenance phase. ding
design process of the system.
In the functional abstraction, the main four
modules to taking the details and computing for
further actions. In data abstraction it provides
some services.
The system is a collection of modules
means

components.

The

highest-level
62

ShoutBox

component corresponds to the total system. For

design this system, first following the top-down
approach to divide the problem in modules. In
top-down design methods often result in some
form of stepwise refinement after divide the
main

modules,

the

bottom-up

approach

is

allowed to designing the most basic or primitive

components to higher-level components. The
bottom-up method operations starting from very
bottom.
In this system, the system is main module,
because it consists of discrete components such
that each component supports a well-defined
abstraction and if a change to the component
has minimal impact on other components. The
modules are highly coupled and coupling is
reduced
in
the
system.
Because
the
relationships among elements in different
modules is minimized.

63

ShoutBox

64

ShoutBox

65

ShoutBox

66

ShoutBox

System design is the process of applying various

techniques and principles for the purpose of
definition a system in sufficient detail to permit
its physical realization.
Software design is the kernel of the software
engineering
process.
Once
the
software
requirements have been analyzed and specified,
the design is the first activity. The flow of
information during this process is as follows.
Information domain details

Function specification
Desig
n

Behavioral specification

Code

Other requirement modules

Program

Test

Procedural design
67

ShoutBox

Software design is the process through which

requirements
are
translated
into
a
representation of software.

Primary

design

is

concerned

with

the

transformation of requirements into data and

software architecture.
Detailed design focuses on refinements to the
architectural representations that lead
detailed data structure and algorithmic

to

representation for software. In the present

project report only preliminary design is given
more emphasis.

68

ShoutBox

System design is the bridge between system &

requirements
analysis
and
system
implementation.
Some
of
the
essential
fundamental concepts involved in the design of
as applications are
Abstraction
Modularity
Verification
Abstraction is used to construct solutions to
problems without having to take account of the
intricate details of the various component subprograms. Abstraction allows system designer to
make step-wise refinements by which attach
stage of the design unnecessary details
annunciate
with
representation
or
implementation may be hidden from the
surrounding environment.
Modularity is concerned with decomposing of
main module into well-defined, manageable
units with well-defined interfaces among the
units. This enhances design clarity, which in turn
eases implementation, debugging, testing, and
documentation maintaining of the software
product. Modularity viewed in this senses vital

69

ShoutBox

tool in the
projects.

construction

of

large

software

Verification is fundamental concept in software

design. A design is verification. It can be
demonstrated that the design will result in an
implementation, which satisfied the customers
requirements.
Some of the important factors of quality that are
to be considered in the design of application are:
The software should behave strictly
according to the original specification of
satisfying customers requirements and should
function smoothly under normal and possible
abnormal conditions. This product is highly
reliable, can handle any number of mails to
filter.
The design of the system must be
such a way that any new additions to the
information functional and behavioral domain
may be done easily and should be adapted to
new specifications. We provided this extensibility
to this product. you can add any number of
filters to your product in the future.
70

ShoutBox

System design is the process of developing

specification for the candidate system that
meets the criteria established during the phase
of system analysis. Major step in the design is
the preparation of input forms and design of
output reports in a form acceptable to the user.
These steps in turn lead to a successful
implementation of the system.
6.2 FEASIBILITY STUDY
FEASIBILITY REPORT: Feasibility study is
the high level capsule version of the entire
requirement analysis process.The objective
of feasibility study is to determine whether
the proposed system can be
developed
with available resources.
There are three steps to be followed for
determining
the
feasibility
study
of
proposed system.
Technical Feasibility
Operational Feasibility
Economical Feasibility
Technical Feasibility: It is concerned with
hardware and software feasibility. In
this
71

ShoutBox

study,one has to test whether the proposed

system can be developed using existing
technology or not. If new technology is
required ,what is the likely hood that it
can be developed ?The organization for
which the system to be developed is not
having a software application for employee
communication .Since this company is using
the softwares like Apache Tomcat which is an
open source, the company need not purchase
new softwares or hardware for run this
application As per our client requirements
the system to be developed should have
speed response because of fast and easy
communication, programming
productivity,
reliability, security, scalability, integration and
availability. To meet these requirements I as
a developer I can choose jsp as a right
choice because of its features platform
independence, modularity and reusability.
Operational
Feasibility:
Operational
feasibility determines whether the proposed
system satisfied the user objectives and
can
be
fitted
in
to
current
system
operation. The proposed system ShoutBox
can be justified as operationally feasible
basing on the following.
The

methods

presentation

are

of

processing

completely

acceptable

and
by
72

ShoutBox

the clients because they meet all the user

and client requirements.
The

clients

have

been

involved

during

the preparation of requirement analysis and

design process.
The
user

system

will

certainly

objectives

and

it

will

satisfy
also

the

enhance

their capability.
The

system

current

operation

documentation

can

is

and

be best
requires

needed

to

fitted
little
make

into
bit
our

employees aware of using this application. With

the help of

this system the employee can

communicate with another employee and the

administrator can monitor the departments.
The

proposed

system

is

completely

user

friendly.
Economical Feasibility: This includes an
evaluation of all incremental costs and
73

ShoutBox

benefits expected if proposed system is

implemented. costs-benefit analysis which is
to be
performed
during
economical
feasibility
delineates costs
for
project
development
and
weighs
them
against
benefits of system. In this the proposed
system replaces
the manual process of
employee communication increases the phone
cost or decreases the productivity by wasting
his time by physically moving and contacting
another employee. This application benefits the
organization in increasing the productivity
indirectly by providing virtual communication.
So developing this system is economically
feasible to organization.

Architectural overview of the project:

you can create/manager/monitor chatrooms.
You can add/update/remove moderators. You
can also track user's sessions. Finally you can
modify ShoutBox system properties.
AUTHENTICATION
Administration GUI is login/password
protected.
When you access
74

ShoutBox

http://yourserver.com/admin/index.jsp you get

the screen below.
- Default SYSTEM login is : system and default
password is : password.
You could change both in System properties.
- Default MODERATOR login is : moderator and
default password is : password.
You could change both in Moderators
properties.
You could also add and remove moderators.

75

ShoutBox

MODERATORS

ShoutBox provides moderation feature. You

can add/remove/update moder-ators. A moderator
is defined by an username (login), a password and
an email. Email field is not mandatory. Links
between moderators and chatrooms could be
configured in chatroom forms. In addition to
chatroom's moderation(kick off, ban,transcript,...),
a moderator can open many new chat rooms.
However moderators cannot backup chatrooms,
modify ShoutBox System properties, and
add/remove/update others moderators.
Note:Moderators information are persisted in
ShoutBoxusers.xml file. All pass words are
encrypted, they can't be reversed.

76

ShoutBox

CHATROOMS
ShoutBox supports multiple chatrooms. You
can open new chatroom by following "open a
chatroom" link. You can manage a chatroom by
selecting the chatroom in the list box named
"Manage chatroom". You can backup all
chatrooms by following "Backup chatrooms" link.
See the screen below to locate these features.
Note that you can logout the administration

77

ShoutBox

through the "Logout" link. System properties page

is available through "Manage ShoutBox" link

OPEN A CHATROOM
You need severals parameters (basics and
advanced) to open a new chatroom :
Name : The name of the chatroom.
Subject : The subject of the chatroom.
78

ShoutBox

Max. users. : Maximum users for the chatroom.

No more users allowed to enter in the chatroom
once this limit is reached.
Display Mode : There are four ways to display
chatroom's content (i.e. chatooms clients). It could
be in an HTML/JavaScript page, an Applet, a Java
application or in a Macromedia Flash5 client. So,
for HTML/JavaScript clients, you have to choose
between Framed (JSP) or Buffered-Framed
(JSP) modes. Buffered-Framed one is optimized
to lower flickering effect.
Note that "Framed" means that HTML/JavaScript
clients need frames.
History : It's the number of lines, from the
chatroom's content, that will be displayed on
clients. It's a "window" on the chatroom's content
starting from the most recent message. The more
history value is high, the more you need bandwith.
One page is around 5 KB with history=40.
Refresh model : ShoutBox uses a PULL system to
keep all clients synchonized. It means that each
client asks for the chatroom's content periodically.
ShoutBox provide three model of "time-period" to
refresh clients :
+ Time-Constant => Period is constant (in
seconds).
+ RoomLoad => The more chatroom is loaded, the
more its clients are "refreshed".
+ Action-Tracker => The more an user chats, the
more it is "refreshed".
Refresh limit : This parameter is linked to refresh
79

ShoutBox

model above. Refresh period can't be longer than

this value. The more this value is low the more
refresh period is fast.
Private message : This parameter allows system
user to enable/disable private message feature for
the chatroom.
Language : This parameter allows system user to
select a language for the chatroom. It will work
only if the skin support multilanguage feature. If
you want to add more languages then see API &
Extension section.
Filters : This parameter applies filters to the
chatroom's content.
+ HTML filter escapes "<" and ">" characters to
prevent from HTML tags send by users. These tags
could mess up the chatroom (i.e. : javascript tag,
images ...).
+ URL Converter filter transforms - on the fly user's messages including http://..., ftp://...,
mailto:..., news://.. into hyperlinks. It could be
useful for users. Note that links are always opened
in a new browser's window.
Much more filters to come ...
Finally, you can select moderators for the
chatroom to open. Multiple moderators are
allowed. A moderator can list/kickoff/ban
chatroom's users. He can also generate transcripts
and update chatroom's parameters.

80

ShoutBox

MANAGE A CHATROOM
Once the chatroom is opened you can update
some parameters : Subject, History, Refresh
Model, Refresh Limit, Private Messages,
Language, Filters and Moderators. The update
occurs in real time, as soon as you click on
"Update" button.
You can generate a transcript (text file dump) of
the chatroom through the Transcript form. Fill in a
transcript filename and click on "Generate". The
81

ShoutBox

text file will be stored in logs folder.

You can clear the chatroom content through
"Clear" link.
You can close the chatroom through "Close" link.
The whole chatroom will be lost.
You can join the chatroom by following "Join" link.
You will be logged as SYSTEM or MODERATOR user
so filters don't applies. That's the only way for
moderators and system user to join a chatroom.

82

ShoutBox

USERS
You can list users through "Users" link. You will
learn about Name, IP Address, User Agent
(Netscape, Internet Explorer,...) and last
accessed time (in seconds) of any logged user.
You can also kickoff or ban any user. "kickoff"
means that the user will be kicked off the
chatroom for a few seconds only. He could join the
chatroom again. "ban" means that user's IP
Address will be banned. He couldn't join the
83

ShoutBox

chatroom with the same IP.

All banned users (IP) move to Blacklist. You
can clear the whole blacklist or only some IP
address. You can also manually add an IP address
to the blacklist. Note that only SYSTEM and
MODERATOR users knows about users' IP.
ShoutBox identifies guest users (nickname).
Moreover It does provide authentication
(login/password) through Add-Ons tools.

SYSTEM PROPERTIES
You can modify ShoutBox system properties
(ShoutBox.xml) through the administration GUI
below. Once saved, modifications will be taken into
account on the next login.
Backup file : Backup filename of ShoutBox.
Chatrooms' dump will be stored there.
Log folder : Log folder of ShoutBox. Log files will
be stored there.
System login : SYSTEM login. Default is system.
You should modify it.
System email : SYSTEM email.
TimeOut : User's session timeout in seconds.
(e.g. if an user closes its browser then he will
84

ShoutBox

leave the chatroom automatically after the

TimeOut period).
USERSESSIONID : Name of an internal variable
for session management. Do not modify it except
if you have a conflict with others WebApp in your
servlet engine.
Default Language : Default language for
chatrooms.
License file : License filename. You have to
modify it if you purchase a license to use.
Update password : You should modify SYSTEM
password. Default is password. You have to select
the checkbox and fill in password forms twice
before submiting. Note this password is stored as
its MD5 value (i.e. encrypted).

85

ShoutBox

Input design is the process of converting useroriginated

information
to
computer-based
format. The goal of designing input data is to
make data entry as easier and error free as
possible. An input format should be easy to
understand.

86

ShoutBox

In this product inputs are nothing but forms fed

with data. Using the JSP pages provides highlevel graphical user interface.

Output reflects image of the organization. The

output design involves designing forms layout,
making lists, making well designed reports etc.,
and reports are main outputs of the proposed
system. We can also consider the response for
our inputs is nothing but outputs. Here if we set
some properties the affect of that setting can be
immediately seen are nothing but outputs for
our system. How the system is working
according to our setting or properties set by us
is the main issue we have to monitor. Those are
our system results. Suppose a user create a new
chat room. Then creating a new chat room is our
required output.

UML Diagrams

87

ShoutBox

88

ShoutBox

89

ShoutBox

90

ShoutBox

91

ShoutBox

Testing is one of the most important phases in

the software development activity. In software
development life cycle (SDLC), the main aim of
testing process is the quality; the developed
software is tested against attaining the required
functionality and performance.

92

ShoutBox

During the testing process the software is

worked with some particular test cases and the
output of the test cases are analyzed whether
the software is working according to the
expectations or not.
The success of the testing process in
determining the errors is mostly depends upon
the test case criteria, for testing any software
we need to have a description of the expected
behaviour of the system and method of
determining whether the observed behaviour
confirmed to the expected behaviour.
Since the errors in the
software can be injured at any stage. So, we
have to carry out the testing process at different
levels during the development. The basic levels
of testing are Unit, Integration, System and
Acceptance Testing.
The Unit Testing is carried out on coding. Here
different modules are tested against the
specifications produced during design for the
modules. In case of integration testing different
tested modules are combined into sub systems
and tested in case of the system testing the full
93

ShoutBox

software is tested and in the next level of testing

the system is tested with user requirement
document prepared during SRS.
There are two basic approaches for testing. They
are
In Functional Testing test cases
are decided solely on the basis of requirements
of the program or module and the internals of
the program or modules are not considered for
selection of test cases. This is also called Black
Box Testing

In Structural Testing test cases

are generated on actual code of the program or
module to be tested. This is called White Box
Testing.
A number of activities
must be performed for testing software. Testing
starts with test plan. Test plan identifies all
testing related activities that need to be
performed along with the schedule and guide
lines for testing. The plan also specifies the
94

ShoutBox

levels of testing that need to be done, by

identifying the different testing units. For each
unit specified in the plan first the test cases and
reports are produced. These reports are
analyzed.
Test plan is a general document for
entire project, which defines the scope,
approach to be taken and the personal
responsible for different activities of testing. The
inputs for forming test plane are
Project plan
Requirements document
System design
Although there is one test
plan for entire project test cases have to be
specified separately for each test case. Test case
specification gives for each item to be tested. All
test cases and outputs expected for those test
cases.
The steps to be performed
for executing the test cases are specified in
separate document called test procedure
specification. This document specify any specify
requirements that exist for setting the test
95

ShoutBox

environment and describes the methods and

formats for reporting the results of testing.
Unit testing mainly focused first in the
smallest and low level modules, proceeding one
at a time. Bottom-up testing was performed on
each module. As developing a driver program,
that tests modules by developed or used. But for
the purpose of testing, modules themselves
were used as stubs, to print verification of the
actions performed. After the lower level modules
were tested, the modules that in the next higher
level those make use of the lower modules were
tested.
Each module was tested against required
functionally and test cases were developed to
test the boundary values.
Integration testing is a
systematic technique for constructing the
program structure, while at the same time
conducting tests to uncover errors associated
with interfacing. As the system consists of the
number of modules the interface to be tested
were between the edges of the two modules.
The software tested under this was incremental
bottom-up approach.
96

ShoutBox

Bottom-up approach integration strategy was

implemented with the following steps.
Low level modules were combined into
clusters that perform specific software sub
functions.
The clusters were then tested.
System testing is a series of different
tests whose primary purpose is to fully exercise
the computer-based system. It also tests to find
discrepancies between the system and its
original objective, current specifications.

97

ShoutBox

98

ShoutBox

99

ShoutBox

ShoutBox can be considered as a tool, which

creates an environment that allows users to chat
each other in their required chat rooms. Lots of
efforts were put to make it work perfectly and
efficiently. The developed system is tested with
real data and the users are satisfied with the
performance of the system and reports.
This

project

is

developed

using

JSPs/Java

Servlets and web Server. By using this tool we

can make easy the work of navigating, creating
a chat room, allowing publicly or privately. By
this lot of work load will be reduced to the
administrator, who is creating/updating/deleting
users or chat rooms. This tool is very useful for
Administrating

deportment

of

SAPARNA

InfoTech Limited. It provides extendibility also.

So you can add your own features in future very
simply without disturbing the existing code. This
tool reduces the manual

work and saves the

100

ShoutBox

time

as

well

as

manpower. The

time

for

processing and producing reports is considerably

reduced. All the features are implemented and
developed as per the requirements.

101

ShoutBox

102

ShoutBox

Basic Java Concepts

: Thinking in JAVA
( Bruce Eckel )

Java Mail API

: Wrox Publications

Volume I and II
An Integrated Approach to
Software Engineering : Pankaj Jalote
103

ShoutBox

Introduction to System
Analysis and Design

: I.T.Hawryszkiewycz

For UML diagrams

: UML in 24 Hours

Book
Some preferred websites

www.bruceeckel.com
www.sun.com/j2ee/mailapi
www.sun.com/j2se

104