ACKNOWLEDGEMENT

From the start to end of this project and writing of this report, I have received
help from the people whom I would like to sincerely thank. First of all, I
would like to thank our major internal guide our college coordinator for all
his help and support and courage he gave us during the making of this project.
His knowledge of the subject was shared and applied in this project. His
advice has proven to be very helpful for us. We sincerely thank his expertise
and wisdom during this project and completion of this project.

Secondly I would like to thank our external guide Mr. Dilip Raval Asst.
General Manager for Department of Information Technology in Air-India
Ltd. He has supported our ideas and concurred on them to be applied. We
thank his guidance and logical knowledge of the company and software.
Without Mr. Raval we wouldn’t have got this project in the first place. We
would like to thank him for his knowledge and practical approach towards the
idea of this project. He provided us with all the information we needed to
make this project a success. We would also want to thank him especially for
his allowance for using his valuable serving time in the making of this
project.

Our most sincere acknowledge Air- India, for its support to the project plan.
We also wish to acknowledge other reference authors and books we referred
to, during this project.

Thanking you,
WAIM team.
 PREFACE

Development of large software systems is an extremely complex activity full

of various opportunities to introduce errors. Software engineering is the
discipline that attempts to provide method to handle this complexity, enabling
us to produce reliable software systems with maximum productivity.

It was felt that it is important and very instructive, not only to learn the
principles of software engineering but also apply them to a software
engineering project so that all aspects of development can be clearly seen on a
project.

Many technological applications may be achieved or implemented when

using the personal computer. The interface design can make users interact
with web server.

We are thankful to teachers and guide for their sincere efforts towards the
completion of this project.
PART

1 INTRODUCTION

1. ORGANIZATION PROFILE:

Air-India is India's national flag carrier. Although air transport was born in
India on February 18, 1911 when Henri Piquet, flying a Humber bi-plane,
carried mail from Allahabad to Naini Junction, some six miles away, the
scheduled services in India, in the real sense, began on October 15, 1932. It
was on this day that J.R.D. Tata, the father of Civil Aviation in India and
founder of Air-India, took off from Drigh Road Airport, Karachi, in a tiny,
light single-engine de Havilland Puss Moth on his flight to Mumbai (then
known as Bombay) via Ahmedabad.

He landed with his precious load of mail on a grass strip at Juhu. At Mumbai,
Neville Vintcent, a former RAF pilot who had come to India from Britain
three years earlier on a barn-storming tour, during which he had surveyed a
number of possible air routes, took over from J.R.D.Tata and flew the Puss
Moth to Chennai (then Madras) via Bellary.

Tata Airlines:

Tata Airlines, as Air-India was then known, consisted of one Puss Moth, one
Leopard Moth, one palm-thatched shed, one whole time pilot assisted by Tata
and Vintcent, one part-time engineer, two apprentice-mechanics and
unlimited optimism.

In 1933, the first full year of its operations, Tata Airlines flew 160,000 miles,
carried 155 passengers and 10.71 tonnes of mail. Tata Airlines was converted
into a Public Company under the name of Air-India in August 1946.

Going Global:

By the beginning of 1947, Air-India turned its attention to the international

scene. Towards the end of the year, an agreement was reached with the
Government of India for the formation of Air-India International Limited to
operate international services.

At Air-India's request, the Government agreed to limit their capital

participation to 49 per cent, subject to an option to acquire, at any time, a
further two per cent from Air-India.

Air-India International, which was registered on March 8, 1948, inaugurated

its international services on June 8, 1948, with a weekly flight from Mumbai
to London via Cairo and Geneva with a Lockheed Constellation aircraft.

Nationalization:

The early '50s saw the financial condition of various airlines operating in
India deteriorate to such an extent that the Government decided to step in and
nationalize the air transport industry and accordingly two autonomous
Corporations were created on August 1, 1953.

Indian Airlines was formed with the merger of eight domestic airlines to
operate domestic services, while Air-India International was established to
operate the overseas services.

The word 'International' was dropped in 1962. Effective March 1, 1994, the
airline has been functioning as Air-India Limited.

From a total of three stations served at the time of nationalization, Air-India's

worldwide network today covers 44 destinations by operating services with
its own aircraft and through code-shared flights.
 2. INTRODUCTION TO PROJECT:

(1) PROJECT PROFILE:-

The company had obstruction knowing the software details of the computers
in the offices and various departments. They could not say which computer
had which software/hardware installed in it unless they actually opened it.
They might have had some manual procedure to do that but it would take a
lot of time to register the information or even edit the information if the
software for example was changed i.e. if they needed new equipment or if it
was there in the storage or decisions as such.

As we had the project in our hand naming it hadn’t took more than 2 sec.
because “WEB APPLICATION FOR INVENTORY MANAGEMENT”
was most obvious and straight forward name for our project.

Through “WAIM” a valid end-user can acquire knowledge about computers,

S/W, H/W and staff-members of other offices of AIR-INDIA located at
anywhere in the world from anywhere in the world by just interacting with
very few user-friendly web-pages.
(2) ABSTRACT:-

 OVERVIEW:

WAIM is the decided name of the software for AIR-INDIA. The software
deals with the storage of computer configuration and the users it is assigned
to. Since the software only stores the basic computer configuration for
example the software information and the details of it along with the users
that are assigned to the specified computer the name WAIM was derived
where WAIM symbolizes for System Information. This software has been
created as part of partial fulfillment of the requirement for the Degree of
Bachelor of Engineering (Information Technology). The authors for this
project would like to state that though the computer configuration deals also
with software, the project had been broken down into two parts a) Hardware
b) Software.

 PURPOSE:

The purpose of this project evaluation is to assess the various software

methodologies that were used throughout the development of the framework,
the accuracy of the estimations, and the usefulness of the reviews. The
product will be reviewed and evaluated for whether it accomplishes the ideas
presented in the initial overview and for the quality of the product.
 ADVANTAGE:

The main advantage for our project is very common for every Java based
applications: portability, reliability and security. Earlier we had decided to
use AWT control in our applets but after suggestion of our ext. project guide
Mr. Raval we came to know that ease of AWT control comes at cost of less
portability. So, we turned to SWING controls which are cross-platform
controls so it is new aid to portability of our project.

As we had been asked to develop Web App. We were free to (or more
precisely ‘forced to’) make the application more esthetic in look which made
‘end users’ more interested I the project during development time so we had
better feedbacks from actual users.

 APPLICATION:

What they decided on is an application that could give them real time replica
of what the situation was like currently. Suppose any office is looked up for
a computer configuration it is holding. The total number of computers it has
and along with it what configuration the machines hold and the users that are
using those specific computers can be achieved the office could be
monitored in an excellent way. However to create that application would
take immense knowledge of the office topology
`
PART

2 SAD
3. PROJECT PLANNING:

This section of the document describes the scope of the project. WAIM as
the name of the software goes is custom software made for the AIR-INDIA
company by the specifications they have given us. The code cannot be
published in this document due to contractual basis. However, we have been
given the liberty to explain the workings of the software. WAIM has been
made for I.T. Dept., AIR-INDIA Ltd. Air India wanted us to make an
application that can be accessed from any part of the earth. They believed that
information was the key to the smooth running of the organization. Everyone
needs to know what configuration the PCs are running on. The software
installed on a specific pc. The computers assigned to specific users etc. In
order to keep a track of all this they wanted a one eye view of it. When we
approached the company they told us about the needs of the organization and
we accepted it as a project. The former details of the same project were
handed to us.

The examiner kindly take into account that the information given to us was
strictly referential and none of it has been directly used in the creation of this
software. The administrator will enter and delete information and the viewer
can watch the list and search a pc according to his/her choice of query. The
end users are defined into two types a).Administrator b).Viewer. An
administrator is a trusted employee of the company that can access the
hardware database and add more information to it. The same employee can
 also edit and delete some specific information. The software has security
plans for the company. No viewer is allowed to edit or delete or add any
information to the database software. He can only view the information
already stored in the database. The viewer can search for any information on
the server related to the software specifications.

The administrator is taken to be the trusted employee of the company who has
the right to add information, edit information and even delete information.
The administrator can very well grant rights to other fellow employee
depending on their conduct. But that does not come under the domain of the
software rules. The matter is left on the company to decide.

(1)SCOPE:-

 Constraints:

When we had been assigned the project, we thought project has perfect size
for the 8th semester project. So, the most common constraint for the
projects- ‘TIME’ was not a major problem for us except in early stage of the
project when we had to give time for settle-in down at Mumbai but we were
able to finish it quickly and set focus back to the project.

As we had made our web-app in JSP and JAVA, unlike the other standalone
projects or web-apps developed through Microsoft technology such as
ActiveX control etc, we can not directly read the file of end-user[‘s computer
to acquire information about end-user and his/her computer, we have to ask
the end-user to provide them for us. Though the ease of work at cost of
security are never desirable and eventually we felt that JSP, java and SQL
Server were good choice for our application.

The portability and security of JAVA does not come free but it comes at cost
of “speed”. But, we have tried to speed up our application by concentrating
on making efficient servelets and extensive use of applets.
 Reliability:

All the java applications have inherent reliability and security. But, during
the project we learned that strengths of java (or any technology) you are
using will be without of any help if your code is not neat, efficient and
most importantly without any bugs. Our project had been gone through
extensive testing and we had worked very hard to elicit the bugs of our
project to make it very reliable and secure.

(2)SOFTWARE PROCESS MODEL:-

A typical process model covers the whole of the life cycle and clearly
defines each phase and the tasks and activities to be performed within that
phase as well as those activities that are continuous throughout the life cycle.
 The phases of the software life cycle:-

• User Requirements definition;

• Software Requirements definition;
• Architectural Design;
• Detailed Design and construction;
• Delivery to the user;
• Operations;
 The most important activities are:

• Project management: planning, resource allocation, tracking,

deadlines;
• Verification and Validation: reduce software defects and make sure
that it does what the user wants;
• Software Configuration Management: handle the actual code,
variants, versions and so on;
• Maintenance: fixing bugs, coping with changes at the boundary of
the system, adding new functionality.
Software Process Maturity:

The quality of a process can be measured in terms of maturity against a

recognized framework. The higher the level of maturity the higher the
quality of the organization's process. The reference is the Capability
Maturity Model (CMM).

The maturity framework consists of five levels:

1: The initial level is where most organizations begin. A level one process is
usually ad hoc, few processes are defined and success depends more on individual
effort than team work;

2: The repeatable level: basic project management processes are implemented to

follow cost, schedule and functionality. The process is sufficiently defined to be
able to repeat earlier successes on projects with similar applications;
3: The defined level: the processes for both management and engineering are
documented, standardized and integrated into a standard organizational software
process

4: The managed level requires that detailed measures are taken of the process and
product, and that process and product are quantitatively understood and controlled.

5: The optimizing level: continuous process improvement is in place, using

quantitative feedback.

The most difficult step is to move from level one to level two because of all
the management procedures and activities that have to be put in place. At
higher levels of maturity the project management has a better visibility on the
software process, and can take corrective actions. This visibility enables to
take corrective action sooner when something goes wrong. The difference in
maturity levels is also characterized by the ability to accurately estimate and
schedule product delivery and the capability of the process to meet those
estimates. As an organization moves up the maturity levels, estimates become
more accurate and the time required to produce a system is shorter.

(3) PROJECT TEAM:-

Our team consists of two members named AAAAAA, BBBBB, CCCCC

and DDDDD. We are students of final year XXXXXX. We had met Mr.
Dilip Raval, Asst. General Manager, I.T. Dept., AI. and asked about
industrial project training. We made him agree with us to allot a project.

(4) PROJECT SCHEDULE:-

 in t r o

In v e s t ig a t io n
14% 9%
13% R e q . D e t.
11%
R eq.
13% s p e c if ic a t io n
16% S y s . D e s ig n
9%
15%
D e v . S ys .

T e s t in g

Planned time :- Im p le m
4 persons e n Days
* AA t in g * BB hours

4. SYSTEM ANALYSIS:
(1) FEASIBILITY STUDY:-
(A) Technical Feasibility

As far as technology consults, we had to confirm about web

application for web server and application server. We have gone
through JSP, SQL Server and Tomcat Server. It made the project to be
completed within technical limits.

(B) Economical Feasibility

We have implemented web application for existing web server of AI.

So, amount of buying server system was out of consideration. It
limited us to expected low value.

(C) Schedule Feasibility

We had been given 60 days for completing project. As we are 2

persons, it seems to be completed. Though, it took 75 days.
(D) Operational Feasibility

We had been given development of web application. The task was

made of building interface, passing queries to server and responding
users.
(2) SYSTEM REQ. ENGG.:-

(A)Requirement Analysis

- Fact finding

We had been very fortunate to have external guide like Mr. Raval
who had given very broad and clear view of what they want from
us, which was really helpful to us during requirement analysis and
determination.

We had been advised to have talked with some of the senior staff
members who are actual of our application to make our picture clear
about the final system.

Instead of requesting them to fill out the entries of our

questionnaires by then selves we opted to ask those questions face
to face for several reasons. First, we were developing the project to
have industrial experience only. Second, until the project completed,
we have no idea which employees were going to use our application
if any.

- Other details of analysis:

At the starting of project we had been introduced to their current

manual process (by calling other offices, through mail etc) and the
difficulties of that system. Although they had not decided the
language or the nature of the system (standalone or web-app) but
they had a good functional view of system. As we noticed that
single system available to every branch will be more helpful
rather then making replica to every branch because, it will
eliminate many problems like violation of integration due to
replication. And our application does not deserve a complex
implementation like distributed system. Now the most suitable
 implementation was a centralized web application. After deciding
the nature of system (web-app) the selection of tools and
technology were easy. Our choice for technology was JSP. And
we have used JAVA components (applets, beans and servelets)
extensively. And as backend we have chosen SQ-Server. A
whole section is devoted to discuss these tools and technology in
great details.

(B) Project Definition

As we had the project in our hand naming it hadn’t took more than 2
sec. because “WEB APPLICATION FOR INVENTORY
MANAGEMENT” was most obvious and straight forward name for
our project.

Through “WAIM” a valid end-user can acquire knowledge about

computers, S/W, H/W and staff-members of other offices of AIR-
INDIA located at anywhere in the world from anywhere in the world
by just interacting with very few user-friendly web-pages.

(C) Requirement Specification:

- Functional Requirements:

- Non-functional Requirements:
 5. SYSTEM DESIGN:

(1) DESIGN PRINCIPLES:-

Most of the components like servelets, beans and applets of our applications
are made in Java which strictly follows OOP concepts. Dynamically
creations of web-pages on the request of individual users are made possible
through JSP technology follows object based approach (a functional approach
which uses corresponding object to invoke its method).

So, we had used Object Oriented conventions right from design phase. We
have tried to follow most common design practices so the diagrams can be
easily understandable.

(2) USE CASE DIAGRAM:-

(3) ACTIVITY DIAGRAM:-

(4) SEQUENCE DIAGRAM:-

(5) CLASS DIAGRAM:-

(6) STATE TRANSITION DIAGRAM:-

(7) COMPONENT DIAGRAM:-

(8) DEPLOYMENT DIAGRAM:-

(9) DATABASE DESIGN:-

(A) E-R Diagram

(B) Data Dictionary

PART

3 IMPLEMENTATION
6. PROGRAMMING FUNDAMENTALS:
7. SCREEN LAYOUTS:
 8. SOFTWARE TESTING:

(1) TESTING STRATEGY:-

Why rapid testing?

Most testing classes try to teach you how to test thoroughly. The problem is that
almost none of us are given the time and resources to properly execute a thorough
test process from beginning to end. Rapid testing is a way to scale thorough testing
methods to fit an arbitrarily compressed schedule. Rapid testing doesn't mean "not
thorough", it means "as thorough as is reasonable, given the constraints on your
time." A good rapid tester is a skilled practitioner who can test productively under
a wider variety of conditions than conventionally trained (or untrained) testers.
The other reason to study rapid testing is respect. Historically, testers have had
trouble gaining the respect of developers and other people on a software project.
After all, from the outside, the testing activity doesn't look like much. Most of the
value of testing comes from how testers think, but even excellent testers struggle to
articulate or justify their ideas about how to test. Rapid testing is a personal
discipline, teachable and learnable, that allows you to think and talk about testing
with confidence. By contrast, a conventionally trained tester generally is limited to
complaining about how the requirements aren't fully documented, or about how
some other condition necessary for arbitrarily thorough testing has not been met.
That behavior rarely inspires respect.

The rapid testing techniques are indispensable when you are asked to test
something on short notice, off the top of your head, early in the development
process, or when you're in the process of developing test cases and procedures for
future use. These techniques are also useful even when you're called upon to test
more thoroughly, and given the time and resources to do so.

How does rapid testing work?

Instead of explicit algorithms and instructions, I emphasize skill and heuristics.

A core skill is the ability to think critically. Thus, we discuss and practice the art of
being skeptical and of separating observations from inferences. This is a thread that
runs throughout the class. I will listen to you report bugs and challenge you to
explain the relationship between your conjecture that something is amiss and the
observations you made. A good tester thinks like a scientist or a detective.

Rapid test design is an organized process, driven by a set of concise heuristics

(think of them as guidelines) designed to assure that you don't forget to test
anything important. For new testers, the heuristics provide basic guidance. For
experienced testers, the heuristics help you organize and access your experience, so
that even under pressure, you perform like an expert and feel like one, too. With
practice, you get better and better at testing rapidly while still being fully
accountable for your work.

Another element I emphasize is exploratory testing, which is the opposite of pre-

scripted testing. There are often good reasons to pre-script tests, but there are also
many situations where defining and recording tests in advance of executing would
take far too long and find far too few bugs. In exploratory testing, the tester designs
and executes tests at the same time.
Where did the rapid testing ideas come from?

From 1987 to 1995, I worked mostly alone to develop a systematic heuristic-based

test methodology that applied to commercial mass-market software projects.
Traditional test methodology didn't work well for market-driven test project.
Starting in 1995, I began to collaborate with other thinkers and writers in the field,
who helped find and fix errors in my work, and helped extend it beyond the scope
of market-driven projects. What began, for me, as my own vision of testing merged
with other ideas to become a community vision..

The ideas in my class are drawn not only from experience, but are also grounded in
epistemology, cognitive psychology, decision theory, and other fields. Testing is a
far more interesting field than most people realize. We're at the crossroads of many
other traditions.

The original motivation for all this was my personal quest to be a truly expert
software tester. It is an ongoing journey, and this class represents the best I have to
show for it, at any given moment. My goal with the class is to propel each student
forward on his or her own quest for expertise and self-confidence.

The project duration was too long. The estimated lines of coding were
approximately 1400. As the project grew longer the coding also increased. This
made it difficult for us to trace bugs in the code even more. The testing was not
fully accurate as the results were expected at first because of these bugs. In the
course of the project there was hardware failure. Tremendous data was lost during
the project. So this affected the testing process. Once the code was finished and
everything was done, the testing began. The testing took longer than the code
writing procedure because every application needs to be bug free. Every time a
desired result was not attained it was due to a bug in the code. To search the code
and then correct it was a tedious job.

Since the project code contained good naming conventions and the use of
comments was wide. It was easier to figure out where the problem was and it could
be corrected as fast as it could be done. The testing process was done on stand
alone computers and the connectivity of the software to the SQL database was
tested. The front end (interface) did give some problems at first to get connected to
the database, because the code in the interface forms was restricted to the testing
machines name. However, it was confirmed and corrected and the smooth running
of the project was underway.
(2) SAMPLE TEST CASES:-

PART

4 TOOLS & TECH.

(1) TECHNOLOGY:

JSP:
JAVA:
Servelets:
Applets:
Java beans:

(2) TOOLS:
(1) Net Bean 3.6 – IDE:

(2)Bean Builder:

(3) Microsoft FrontPage:

PART

5 APPENDIX
1. PROJECT TRACKING:

In t r o
14% 11% In v e s t ig a t io n
11% R e q . D e t.
11%
R e q . s p e c ific a t io n
in t r o
11%
16% S ys. D ev.
10%
16% T e s tin g
Im p le m e n ta t io n
 2. USER MANUAL:

 As discussed earlier our app. was web-application it is not possible to

provide a printed copy of ‘user manual’ to every potential user of our system and
nowadays surfing web is so common that it is not needed.

 We have tried our best to stick with a common layout while making web-
app so user can feel comfortable with our app. from its first use.
 3. FUTURE ENHANCEMENT:

 Make application more user-friendly and enhance look and feels of web-
pages.

 Optimization of database operations.

 The functionality of inventory management can be easily applied to other

things then S/W. H/W, employee and computers.
 4. GLOSSARY:

JAVA:-
Abstract Window Toolkit (AWT)
A collection of graphical user interface (GUI) components that were
implemented using native-platform versions of the components. These
components provide that subset of functionality which is common to all
native platforms. Largely supplanted by the Project Swing component set.

API:
Application Programming Interface. The specification of how a programmer
writing an application accesses the behavior and state of classes and objects.

Applet:

A component that typically executes in a Web browser, but can execute in a

variety of other applications or devices that support the applet programming
model.

Bean:

A reusable software component that conforms to certain design and naming

conventions. The conventions enable beans to be easily combined to create
an application using tools that understand the conventions.

CORBA:
Common Object Request Broker Architecture. A language independent,
distributed object model specified by the Object Management Group
(OMG).

Core class:
 A public class (or interface) that is a standard member of the Java Platform.
The intent is that the core classes for the Java platform, at minimum, are
available on all operating systems where the Java platform runs. A program
written entirely in the Java programming language relies only on core
classes, meaning it can run anywhere.

Core packages:

It contains required set of APIs in a Java platform edition which must be

supported in any and all compatible implementations.

Embedded Java Technology:

The availability of Java 2 Platform, Micro Edition technology under a

restrictive license agreement that allows a licensee to leverage certain Java
technologies to create and deploy a closed-box application that exposes no
APIs.

GUI:

“Graphical User Interface” refers to the techniques involved in using

graphics, along with a keyboard and a mouse, to provide an easy-to-use
interface to some program.

IDL:

Interface Definition Language. APIs written in the Java programming language

that provides standards-based interoperability and connectivity with CORBA
(Common Object Request Broker Architecture).

IIOP:

“Internet Inter-ORB Protocol” is a protocol used for communication between

CORBA object request brokers.
Interface:

A Java keyword used to define a collection of method definitions and

constants. It can later be implemented by classes that define this interface
with the "implements" keyword.

JAR:

JAR (Java Archive) is a platform-independent file format that aggregates

many files into one. Multiple applets written in the Java programming
language, and their requisite components (.class files, images, sounds and
other resource files) can be bundled in a JAR file and subsequently
downloaded to a browser in a single HTTP transaction. It also supports file
compression and digital signatures.

Java 2 SDK, Standard Edition:

The Software Development Kit (SDK) is development environment for

building applications, applets, and components using the Java programming
language. This SDK provides a reference implementation of the J2SE
platform.

Java APIs for Integrated Networks (JAIN):

It enables the rapid development of Next Generation telecom products and

services on the Java platform.

Java Card API:

An ISO 7816-4 compliant application environment focused on smart cards.

Java Compatibility Kit (JCK):

A test suite, a set of tools, and other requirements used to certify a Java
platform implementation conformant both to the applicable Java platform
specifications and to Java Software reference implementations.

Java Database Connectivity (JDBC):

It is an industry standard for database-independent connectivity between the

Java platform and a wide range of databases. The JDBC provides a call-level
API for SQL-based database access.

Java Development Kit (JDK):

It is a software development environment for writing applets and

applications in the java programming language. Technically, the JDK is the
correct name for all versions of the Java platform from 1.0 to 1.1.x.

Java Foundation Classes (JFC):

It is an extension that adds graphical user interface class libraries to the

Abstract Windowing Toolkit (AWT).

Java Interface Definition Language (IDL):

It is a set of Java APIs that provide CORBA (Common Object Request

Broker Architecture) interoperability and connectivity capabilities for the
J2EE platform. These capabilities enable J2EE applications to invoke
operations on remote network services using the OMG IDL and IIOP.

Java Remote Method Invocation (RMI):

It is a distributed object model for Java program to Java program, in which

the methods of remote objects written in the Java programming language can
be invoked from other Java virtual machines, possibly on different hosts.
Java Runtime Environment (JRE):

It is a subset of the Java Development Kit (JDK) for end-users and

developers who want to redistribute the runtime environment alone. The
Java runtime environment consists of the Java virtual machine, the Java core
classes, and supporting files.

Java virtual machine:

It is a software "execution engine" that safely and compatibly executes the
byte codes in Java class files on a microprocessor (whether in a computer or
in another electronic device).

JavaBeans:

It is a portable, platform-independent reusable component model. A

component that conforms to this model is called a bean.

Just-in-time (JIT) Compiler:

It is a compiler that converts all of the bytecode into native machine code
just as a Java program is run. This results in run-time speed improvements
over code that is interpreted by a Java virtual machine.

Multithreaded:

Describes a program that is designed to have parts of its code execute

concurrently

ORB:

Object Request Broker. It is a library that enables CORBA objects to locate

and communicate with one another.
OTS:

Object Transaction Service. A definition of the interfaces that permit

CORBA objects to participate in transactions

Package:

It is a group of type. Packages are declared with the package keyword.

POA:

“Portable Object Adapter” is a CORBA standard for building server-side

applications that are portable across heterogeneous ORBs.

SOAP:

The Simple Object Access Protocol (SOAP) uses a combination of XML-

based data structuring and the Hyper Text Transfer Protocol (HTTP) to
define a standardized method for invoking methods in objects distributed in
diverse operating environments across the Internet.

SQL:

“Structured Query Language” is the standardized relational database

language for defining database objects and manipulating data.

Thread:
It is the basic unit of program execution. A process can have several threads
running concurrently, each performing a different job, such as waiting for
events or performing a time-consuming job that the program doesn't need to
complete before going on. When a thread has finished its job, the thread is
suspended or destroyed
Web server:

It is software that provides services to access the Internet, an intranet, or an

extranet. A Web server hosts Web sites, provides support for HTTP and
other protocols, and executes server-side programs (such as CGI scripts or
servlets) that perform certain functions.

SQL:-

Access control list (ACL):

A list associated with a file that contains information about which users or
groups have permission to access or modify the file.

Backward compatibility mode:

It is a Mode in which a SQL Server 7.0 application or database functions as

it did in SQL Server 6.x.

COM:

The extension reserved by MS-DOS for a type of executable binary

(program) file limited to a single 64-KB segment.

Data Access Object (DAO):

Connectivity tool designed for desktop access to data and based on the
Microsoft Jet database engine technology.

Distributed COM (DCOM):

It is the version of Microsoft's Component Object Model (COM)
specification that stipulates how components communicate over Windows-
based networks. It permits the distribution of different components for a
single application across two or more networked computers and allows an
 application to run distributed across a network so that the distribution of
components is not apparent to the user.

Global temporary table:

Temporary table that is visible to all sessions.

Group:

It is a Security administrative unit within the Windows NT operating system

that contains Windows NT user accounts or other groups. Privileges can be
specified for the group, and each member will have those privileges.

Inter-query parallelism:

It is an ability to assign different queries to different processors.

Intra-query parallelism:

It is an ability to break a single query into multiple subtasks and execute

them on multiple processors in an SMP computer.

Loose consistency:
Latent guaranteed consistency.

Major entity:

Semantic entity normally used in English Query to correspond to an entire

table.

Non-SQL Command Providers:

 It is a provider who supports the Command object and its mandatory
interfaces but does not support a SQL standard dialect recognized by SQL
Server.

Nonclustered indexes:

B-trees formed out of 8-KB index pages.

Nonleaf level:

It is an upper part of an index B-tree structure.

Nonrelational data:

Data not stored in relational databases, for example, audio and video clips
and e-mail messages.

Open Database Connectivity (ODBC):

A C/C++ API designed to target different sources from the same source code
by substituting different drivers.

Page:

It is the fundamental unit of data storage in SQL Server, consisting of 8 KB.

Query cost:

Estimated elapsed time, in seconds, required to execute a query on a specific

hardware configuration.
Query execution:

Major phase in query processing consisting of executing the plan chosen

during query optimization.

Query governor:

It is a SQL Server 7.0 feature that prevents a query from running if its query
cost is greater than an administrator-specified upper cost limit.

Query optimization:

Major phase in query processing consisting of choosing the fastest execution

plan.

Query processor:

Major SQL Server component that accepts, selects, and then executes the
plan chosen for executing the syntax.

Referential integrity:

It is the way in which an RDBMS manages relationships between tables.

5. BIBLIOGRAPHY:
 The Complete Reference Java 2, Fifth Edition, By Hurbert Schildt, Tata
McGraw-Hill Edition

 SAMS “Teach Yourself JSP”, By Jose Annunziato and Stepheny Fesler

Kaminaris, Techmedia Publication.

 ‘Complete Reference – SQL’ by James R. Groff and Paul N. Weinberg.

 JSP 2.0: The Complete Reference (Complete Reference S.), Philip Hanna,
Osborne McGraw-Hill.

 Core Servlets and JavaServer Pages. Sun Press. The alltime best-selling servlet
and JSP book.

 More Servlets and JavaServer Pages. Sun Press. New book that covers filters,
life-cycle listeners, TagLibraryValidator, JSTL, Web application security, and
other new topics.

 Pure JSP: Java Server Pages by James Goodwill (Sams, 2000)

 JavaServer Pages by Larne Pekowsky (Addison-Wesley, 2000)

 Instant JavaServer Pages by Paul Tremblett (Osborne McGraw-Hill, 2000)