Introduction

1.1 Purpose of the System

The main aim of is HUMAN RESOURCE MANAGEMENT SYSTEM is automating the resume processing for organization that is applied by the candidates. With this project organization can add the resume to the database and track the resumed to various rounds and it provides reports on jobs. The objective is to develop customize software package for organization.

The Human Resource Management System is developed using ORACLE as back-end and HTML, JSP as front-end. The operating system being used is the Windows 2000 prof.

The automation of the above mentioned system reduces human dependences and avoids errors in data storage, analysis and retrieval. The time taken for searching candidate details is also drastically reduced due to the automation process, thus reducing the whole cycle time.

This project performs three major roles:

  • Registration
  • Junior level management
  • Senior level management

1.2 Scope Of The System

Human Resource Management System is accessible to the HR Department of the organization “GIT Solutions ”. The functional scope of the system is to provide the user friendly environment in the process of recruitment and it provides search based on particular search criteria to update resume and so scheduled and up to interview rounds. It provides reports based on job positions search.

1.3 Objectives and Success Criteria

Objective:

The main objectives of the Human Resource Management System are as follows:

  • To automate selection process.

  • To facilitate high graphical user interface to the user.
  • To provide better functioning and accurate information in time.
  • To provide data maintenance features.
  • To improve the efficiency and to reduce the overload of work.
  • To generate appropriate and concerned information to the user using dynamic queries.
  • To generate appropriate reports.
  • To provide security.

Success Criteria:

It provides security to the application through login check of the user of this system through this web-based application maintenance of the recruitment process is being done in less time and add efficient manner. The module will be built using Oracle and html and jsp to allow for future enhancement and additions.

1.4 Definitions And Abbreviations

Definitions:

Applicant: An Individuals that is looking for career GIT Solutions

Interview: A meeting between any Executive of GIT Solutions and applicants,

where GIT Solutions determines if the employee's skill set matches

the job that they are trying to fill.

Resume: A document containing the applicant's Personal details, job details

Education, Skills, Past Employment, Reference information.

Test: An exercise to measure quantitatively the aptitude for specified job

requirements.

Posting: Feeding of information of applicant into Application or storing of

application into the database.

Abbreviations:

HRMS: Human Resource Management System

JSP: Java Server Page

JDBC: Java Data Base Connectivity

ODBC: Oracle Data Base Connectivity.

HTML: Hyper Text Markup Language

HTTP: Hyper Text Transper

URL:

1.5 Overview:

The main aim of is HUMAN RESOURCE MANAGEMENT SYSTEM is automating the resume processing for organization that is applied by the candidates. With this project organization can add the resume to the database and track the resumed to various rounds and it provides reports on jobs. The objective is to develop customize software package for organization.

2. CURRENT SYSTEM

No proper dynamic search method is available to immediately access a particular record. Fast retrieval of required data is not possible thus causing delay and unnecessary search of the entire list.

FoxPro under Novel NetWare version is not a graphical user interface based application. User interaction with the system is minimized because of the DOS environment, unlike the windows environment where the user interaction with the system is high.

PROBLEM DEFINITION:

  • Handling of large databases effectively is not possible with the above software.
  • Creating dynamic queries is difficult in FoxPro, So dynamic report generation is not possible.
  • Security feature, which is very important aspect of NFCL, already exists but needs to be enhanced and need to be foolproof.
  • Online reports and graphical representation of reports do not exist.

3. PROPOSED SYSTEM

Keeping in view of growth that has been envisaged, it may not be practical and economical to continue with the current system. To facilitate a more efficient Recruitment System and to increase the responsiveness, it is necessary to have better Recruitment System integrated with the enterprises Information System.

Proposed system is Computerized Recruitment Processing System. A Computer based system is usually needed for the following purposes:

Greater processing speed:

Using computers inherent ability to calculate, sort, retrieve data with greater speed than that of the human doing we can get results in less time.

Better Accuracy and Improved Consistency:

The computer carries out computing steps including arithmetic accurately and consistently from which really human is escaped which yields more fatigue and boredom.

Cost Reduction:

Using computerization we can do the required operations with lower cost than manual process. Hence by computerization we can reduce the cost drastically.

System Objectives:

  • To automate selection process.
  • To facilitate high graphical user interface to the user.
  • To provide better functioning and accurate information in time.
  • To provide data maintenance features.
  • To improve the efficiency and to reduce the overload of work.
  • To generate appropriate and concerned information to the user using dynamic queries.
  • To generate appropriate reports.
  • To provide security.

3.1 Overview:

Proposed HRMS is Computerized System. HRMS mainly deals with the activities taking place in an organization to process the resume details forwarded by the candidates. There are three main modules in this system, they are

  • REGISTRATION

  • JUNIOR LEVEL MANAGEMENT
  • SENIOR LEVEL MANAGEMENT

Registration Module:

In this module, HR Manager can give access rights to some of the employee of the organization by giving UserId and password. Generally in the organization there are five interview rounds.

Namely:

Preliminary Interview

Written Test

Group Discussion

Listening Comprehension

Final Interview

The persons who have access rights to this system, they can define the interview rounds form the above five rounds and their order for recruiting of particular job.

They can Add new Positions for recruiting, Add Departments, Add Marital Status, Add Skill Type, Add Source, Add Languages Add Certifications, Add Rounds, Add Role of the employee who can access this application.

They will send the intimation letter for the written test to the selected applicants.

Junior Level Management Module:

In Junior Level Management the candidates who were called for written test will be conducted the different tests like written, technical, psychological organizational awareness and so on... In this module they generate reports depending on the applicants performance related to test results. Junior Level Management allows the applicant for the next level depending on their performance. After conducting all tests we will mail the intimation letter for the interview to the candidates who were selected in the module. Finally they will assign the applications to the interviewers for interview.

Senior Level Management:

In this module senior level management interacts with the database for getting the details of selected applicants in the previous module. They will go through the applicant details and their Skill-sets reports. Again this management deals with the selected applicants in Jr level management selection process. Here senior level management conducts interview for these selected candidates. With these two modules details they will prepare the final candidates list for appointment and they will send the appointment letters to the selected applicants.

3.2 Functional Requirements:

Functional requirements describe the high level functionality of thee system. It describes the interaction between the system and its environment independent of its implementation. Environment includes the user and any other external system with which the system interacts.

The following are the functional requirements of the HRMS:

  • The hr manger with the userid and password will create the normal user.
  • The user authentication can be created checked based on userid and password.
  • The user can define the job interview rounds.
  • The user can add new list items to database.
  • The application shall support unlimited profile details to be fed.
  • The user can add new resume to the database and can update resumes based on search criteria.
  • The application shall support integrity and check of redundancy of data posting of a profile.
  • The application shall allow for the modification of resumes.
  • The application shall allow intimation to the aspirant about the status of selection.
  • The application shall allow the user to view the details of employee resume from the search results.
  • Resumes can be tracked among the defined job rounds in the interview process and scheduling, updating the interview round for particular applicant.
  • Generating summery report based on the position of the job and changeable to Excel form.
  • Generating the snap short report based on the Name of the applicant from summery Report and changeable to Excel form.

3.3 Non-Functional Requirements:

Non-Functional requirements describe user -visible aspects of the system that are not directly related with the functional behavior of the system.

The following are the Nonfunctional requirements of the HRMS:

3.3.1 User Interface and Human Factors:

On the portion of the Application Assessment screen, you have the main menu, where various tabs are shown that form apart of each of the modules.

  • Application Assessment
  • Maintenance of resumes
  • Test Reports
  • Maintains Performance of the applicant in various test and interview levels.
  • Reports

Generates reports depending on their performance in various test and interview levels

  • Click the Application Assessment tab. It shows the following links
  • Personal information Details Screen
  • In this screen User enter the Personal details of the applicants.
  • Educational Details
  • In this screen User enter the Education details of the
  • applicants.
  • Address Details
  • In this screen User enter the Address details of the applicants.
  • Experience Details
  • In this screen User enter the Skills and Experience details of
  • the applicants.
  • Click the Test Assessment tab. It shows the following links
  • Interview Assessment Junior Level Management
  • Interview Assessment Senior Level Management
  • Click the Interview Assessment Junior Level Management tab. It shows the following links
  • Interview Assessment Junior Level Management Screen
  • In this screen User enter the marks of the applicants who
  • wrote the tests in the second module.
  • Interview Assessment Senior Level Management Screen
  • In this screen User enter the marks of the applicants who
  • attended for the interview in the third module.
  • Click the Reports tab in the main menu. It shows the following links
  • Selection list report
  • It contains the following tab links
  • Selection list for Written Test
  • In this Report we will get the applicants list
  • who were selected for the written test.
  • Selection list for Interview
  • In this Report we will get the applicants list
  • who were selected for the Interview.
  • Overall Performance list report
  • In this report we will get the Overall performance in all the
  • test and interview rounds.
  • Intimation list report
  • In this report applicants will be got their status in each
  • round in which they participated. It will shows the
  • following links
  • Call letter for written test
  • In this call letters will be send to the
  • applicants who selected for the written test.
  • Call letter for Interview
  • In this call letters will be send to
  • applicants who selected for the Interview.
  • Call letter for Intimation
  • In this call letters will be send to
  • applicants who selected for the Job.

3.3.2 Documentation

  • In the HRMS the following documentation are provided:
  • Requirement Document
  • System Design Document
  • Database Design Document

3.3.3 Software and Hardware Requirements:

  • Software requirements
  • Operating system ::::: Windows 2000/NT, MS-DOS.
  • Backend ::::: ORACLE 8i
  • Front end ::::: HTML
  • Language ::::: Java, JDBC
  • Web Technologies ::::: Servlets, JSP
  • Web Server ::::: Tomcat 4.1
  • Application Server ::::: Weblogic 7.1
  • Driver ::::: ODBC for oracle.
  • Documentation
  • Tool ::::: Microsoft word 2000
  • Hardware requirements
  • CPU ::::: Pentium IV.
  • Speed ::::: 800 MHz
  • Ram ::::: 1 GB.
  • Hard disk ::::: 20 GB.
  • Monitor ::::: SVGA color monitor.
  • Keyboard ::::: 105 Standard Mouse.
  • Mouse ::::: Logitech

3.3.4 FEASIBILITY STUDY:

All projects are feasible, given unlimited resources and infinite time. But the development of software is plagued by the scarcity of resources and difficult delivery rates. It is both necessary and prudent to evaluate the feasibility of a project at the earliest possible time. Three key considerations are involved in the feasibility analysis.

Economic Feasibility:

This procedure is to determine the benefits and savings that are expected from a candidate system and compare them with costs. If benefits outweigh costs, then the decision is made to design and implement the system. Otherwise, further justification or alterations in proposed system will have to be made if it is to have a chance of being approved. This is an ongoing effort that improves in accuracy at each phase of the system life cycle.

Technical Feasibility:

Technical feasibility centers on the existing computer system (hardware, software, etc.,) and to what extent it can support the proposed addition. If the budget is a serious constraint, then the project is judged not feasible.

Operational Feasibility:

People are inherently resistant to change, and computers have been known to facilitate change. It is understandable that the introduction of a candidate system requires special effort to educate, sell, and train the staff on new ways of conducting business.

FEASIBILITY STUDY IN THIS PROJECT

Technical Feasibility

Human Resource Management System is the project that is designed mainly on Java. The main reason behind choosing the Java environment is that, keeping in mind the needs of the users. The activities that go on in this particular phase are acceptance of applicant's profiles with the help of well designed web based forms and storing the information in the database and retrieving for future use. The usage of JSP facilitates the dynamic page generation. This is the main reason behind the usage of JAVA for the development of this project. Since it is multi platform environment that supports web Browser where as other languages lack these features.

In order to maintain continuously communicate between client and server he/she needs a reliable protocol i.e., is TCP/IP protocol. This protocol frequently transfers messages between client and server. Communication Standards such as HTTP is used .An HTTP is a client/server interaction consists of a single request/reply interchange, it user-friendly environment.

Economic Feasibility

The Human Resource Management System is a system that maintains the information regarding the various applicant details. The entire system is designed to maintain information regarding the applied candidates and those candidates who are recruited. It also maintains information regarding the various tests conducted and the short listed candidates. Once candidates have been selected the left over candidate's information is deleted from the database.

Operational Feasibility

The Human Resource Management System efficiently manages the information coming into the database sends the list of eligible candidates that need to appear for scrutiny very fastly. Also it enables results to be processed in a very time saving and effective manner and short lists the names of all candidates' selected and present details about their performance in a well organized, easily understandable manner. Various reports regarding the selected candidate's performance and pay scale are also generated to provide minute details regarding the entire system.

3.3.5 Performance Characteristics

HRMS was developed as a IAVA web application. It works efficiently; less time it generates web page when it works on Pentium IV Processor with RAM 1 GB.

It works up to ten concurrent users.

3.3.6 Security Issues

Initially HR Manager assign authentication rights to employee of the organization by giving usreid, password.

The authentication of the user is should verify by checking userid, password when ‘Login'.

Only authenticated users of the organization can access the system.

DESCRIPTION OF THE SOFTWARE USED:

HISTORY OF JAVA

Java language was developed by James Gosling and his team at sun Micro systems and released formally in 1995. Its former name is oak. Java Development Kit 1.0 was released in 1996. to popularize java and is freely available on Internet.

Overview of Java

Java is loosely based on C++ syntax, and is meant to be Object-Oriented Structure of java is midway between an interpreted and a compiled language java programs are compiled by the java compiler into Byte Codes which are secure and portable across different platforms. These byte codes are essentially instructions encapsulated in single type, to what is known as a java virtual machine (JVM) which resides in standard browser.

JVM verifies these byte codes when downloaded by the browser for integrity. JVM is available for almost all OS. JVM converts these byte Codes into machine specific instructions at runtime.

FEATURES OF JAVA

  • Java is object-oriented language and supports encapsulation, inheritance, polymorphism and dynamic binding, but does not support multiple inheritances. Every thing in java is an object except some primitive data types.
  • Java is portable architecture neutral that is java programs once compiled can be executed on any machine that is enabled.
  • JAVA is distributed in its approach and used for internet programming.
  • Java is robust, secured, high performing and dynamic in nature.
  • Java supports multithreading. There for different parts of the program can be executed at the same time

JAVA AND INTERNET

Java is strongly associated with internet and known as internet programming language. Internet users can use java to create applet programs and run them locally using java enabled browser search as hot java. Applets can be downloaded from remote machine via internet and run it on local machine.

JAVA AND WORLD WIDE WEB

World Wide Web is an open ended information retrieval system designed to be used in the distributed environment. This system contains web pages that provide both information and controls. We can navigate to a new web page in any direction. This is made possible worth HTML java was meant to be used in distributed environment such as internet. So java could be easily incorporated into the web system and is capable of supporting animation graphics, games and other special effect. The web has become more dynamic and interactive with support of java. We can run a java program on remote machine over internet with the support of web

JAVA ENVIRONMENT

Java environment includes a large no. of tools which are part of the system known as java development kit (JDK) and hundreds of classes, methods, and interfaces grouped into packages forms part of java standard library (JSL).

JAVA ARCHITECTURE

Java architecture provides a portable, robust, high performing environment for development. Java provides portability by compiling the byte codes for the java virtual machine which are then interpreted on each platform by the runtime environment java also provides stringent compile and runtime checking and automatic memory management in order to ensure solid code.

JAVA VIRTUAL MACHINE

When we compile the code, java compiler creates machine code (byte code) for a hypothetical machine called java virtual machine (JVM). The JVM will execute the byte code and overcomes the issue of portability. The code is written and compile for one machine and interpreted all other machines. This machine is called java virtual machine.

PARADIGM OF JAVA

  • Dynamic down loading applets(small application programs);
  • Elimination of flatware phenomenon that is providing those features of a product that user needs at a time. The remaining features of a product can remain in the server.
  • Changing economic model of the software
  • Up-to-date software availability
  • Supports network entire computing
  • Supports CORBA & DCOM

ABOUT HTML

HTML (hyper text markup language) is a language used to create hyper text documents that have hyper links embedded in them . it consists of tags embedded in the text of a document with HTML. We can build web pages or web document s. it is basically a formatting language and not a programming language. The browser reading the document interprets mark up tags to help format the document for subsequent display to a reader. HTML is a language for describing structured documents. HTML is a platform independent. WWW (World Wide Web) pages are written using HTML. HTML tags control in part the representation of the WWW page when view with web browser. The browser interprets HTML tags in the web document and displays it. Different browsers show data differently. Examples of browsers used to be web pages include:

  • Netscape
  • Internet Explorer

JAVA SCRIPT

Java script is a general purpose, prototype based, object oriented scripting language developed jointly by sun and Netscape and is meant for the WWW. It is designed to be embedded in diverse applications and systems, with out consuming much memory. Java script borrows most of its syntax from java but also inherits from awk and perl, with some indirect influence from self in its object prototype system.

Java scripts dynamically typed that is programs don't declare variable types, and the type of variable is unrestricted and can change at runtime. Source can be generated at run time and evaluated against an arbitrary scope. Typical implementations compile by translating source into a specified byte code format, to check syntax and source consistency. Note that the availability to generate and interpret programs at runtime implies the presence of a compiler at runtime.

Java script is a high level scripting language that does not depend on or expose particular machine representations or operating system services. It provides automatic storage management, typically using a garbage collector.

FEATURES:

  • Java script is embedded into HTML documents and is executed with in them.
  • Java script is browser dependent
  • JavaScript is an interpreted language that can be interpreted by the browser at run time .
  • Java script is loosely typed language
  • Java script is an object based language.
  • Java script is an Event-Driven language and supports event handlers to specify the functionality of a button.

ADVANTAGES

  • Java script can be used for client side application
  • Java script provides means to contain multiform windows for presentation of the web.
  • Java script provides basic data validation before it is sent to the server. Eg : login and password checking or whether the values entered are correct or whether all fields in a from are filled and reduced network traffic
  • It creates interactive forms and client side lookup tables.

JavaDataBaseConnectivity (JDBC)

It is a java data base connectivity having database as a back-end of java as front end. Database is a collectivity of related data. A data base management system (DBMS) controls the storage or retrieval of data in the database. The main use of this JDBC is the database connectivity.

Using drivers we can get connection to the back-end:

  • Which drive we are going to connect back-end.
  • Create a data source name (dsn).
  • Create a statement for connection.

The package we use here is java. Sql.

Interfaces of jdbc include Driver, Connection, Statement, Prepare Statement, CallableStatement, ResultSet, and ResultSetMetaData.

Classes of JDBC are DriverManages, DriverPropertyInformation, Date, Time, Timestamp, and Type. The driver defined by the class JdbcOdbcDriver in package sun.jdbc.odbc. Class sun.jdbc.odbc.JdbcOdbcDriver represents the jdbc to odbc bridge driver.

Overview of New Features

Result set enhancements

The JDBC 1.0 API provided result sets that had the ability to scroll in a forward directionally. Scrollable result sets allow for more flexibility in the processing of results by providing both forward and backward movement through their contents. In addition, scrollable result sets allow for relative and absolute positioning. For example, its pos-sable to move to the fourth row in a scrollable result set directly, or to move directly to the third row following the current row, provided the row exists. The JDBC API allows result sets to be directly updatable, as well.

Batch updates

The batch update feature allows an application to submit multiple update statements (insert/update/delete) in a single request to the database. This can provide a dramatic increase in performance when a large number of update statements need to be executed.

Advanced data types

Increased support for storing persistent Java programming language objects (Java objects) and a mapping for SQL99 data types such as binary large objects, and structured types, has been added to the JDBC API. An application may also customize the map-ping of SQL99 structured types into Java programming language classes.

RowSets

As its name implies, a rowset encapsulates a set of rows. A rowset may or may not maintain an open database connection. When a rowset is ‘disconnected' from its data source, updates performed on the rowset are propagated to the underlying database using an optimistic concurrency control algorithm. RowSets add support to the JDBC API for the JavaBeans component model. A RowSet object is a bean. A RowSet implementation may be Serializable. Rowsets can be created at design time and used in conjunction with other JavaBeans components in a visual builder tool to construct an application.

JNDI for naming databases

The Java Naming and Directory Interface (JNDI) API can be used in addition to a JDBC technology-based driver manager (JDBC driver manager) to obtain a connection to a database. When an application uses the JNDI API, it specifies a logical name that identifies a particular database instance and JDBC driver for accessing that database. This has the advantage of making the application code independent of a particular JDBC driver and JDBC technology URL.

Connection Pooling

The JDBC API contains ‘hooks' that allow connection pooling to be implemented on top of the JDBC driver layer. This allows for a single connection cache that spans the different JDBC drivers that may be in use. Since creating and destroying database connections is expensive, connection pooling is important for achieving good performance, especially for server applications.

Result Set Enhancements

This chapter discusses the new functionality that has been added to result sets. The goal of the enhancements is to add two new basic capabilities to result sets: scrolling and updatability. Several methods have also been added to enable a JDBC driver to deliver improved performance when processing results. A variety of examples are included to illustrate the new features.

Scrolling

A result set created by executing a statement may support the ability to move backward (last-to-first) through its contents, as well as forward (first-to-last). Result sets that support this capability are called scrollable result sets. Result sets that are scrollable also support relative and absolute positioning. Absolute positioning is the ability to move directly to a row by specifying its absolute position in the result set, while relative positioning gives the ability to move to a row by specifying a position that is relative to the current row. The definition of absolute and relative positioning in the JDBC API is modeled on the X/Open SQL CLI specification.

Result Set types

The JDBC 1.0 API provided one result set type—forward-only. The JDBC 2.1 core API provides three result set types: forward-only, scroll-insensitive, and scroll-sensitive. As their names suggest, the new result set types support scrolling, but they differ in their ability to make changes visible while they are open.A scroll-insensitive result set is generally not sensitive to changes that are made while it is open. A scroll-insensitive result set provides a static view of the underlying data it contains. The membership, order, and column values of rows in a scroll-insensitive resultset are typically fixed when the result set is created. On the other hand, a scroll-sensitive result set is sensitive to changes that are made while it is open, and provides a ‘dynamic' view of the underlying data. For example, when using a scroll-sensitive result set, changes in the underlying column values of rows are visible. The membership and ordering of rows in the result set may be fixed—this is implementation defined.

Concurrency types

An application may choose from two different concurrency types for a result set: read-only and updatable. A result set that uses read-only concurrency does not allow updates of its contents. This can increase the overall level of concurrency between transactions, since any number of read-only locks may be held on a data item simultaneously. A result set that is updatable allows updates and may use database write locks to mediate access to the same data item by different transactions. Since only a single write lock may be held at a time on a data item, this can reduce concurrency. Alternatively, an optimistic concurrency control scheme may be used if it is thought that conflicting accesses to data will be rare. Optimistic concurrency control implementations typically compare rows either by value or by a version number to determine if an update conflict

Performance

Two performance hints may be given to a JDBC 2.1 technology-enabled driver to make access to result set data more efficient. Specifically, the number of rows to be fetched from the database each time more rows are needed can be specified, and a direction for processing the rows—forward, reverse, or unknown—can be given as well. These values can be changed for an individual result set at any time. A JDBC driver may ignore a performance hint if it chooses.

Creating a result set

The example below illustrates creation of a result set that is forward-only and uses read-only concurrency. No performance hints are given by the example, so the driver is free to do whatever it thinks will result in the best performance. The transaction isolation level for the connection is not specified, so the default transaction isolation level of the underlying database is used for the result set that is created. Note that this code is just written using the JDBC 1.0 API, and that it produces the same type of result set that would have been produced by the JDBC 1.0 API.

Connection con =

DriverManager.getConnection ("jdbc:odbc:dsnName",

”username”,”password”);

Statement stmt = con.createStatement();

ResultSet rs = stmt.executeQuery("SELECT emp_no, salary FROM

employees");

The next example creates a scrollable result set that is updatable and sensitive to updates. Rows of data are requested to be fetched twenty-five at-a-time from the database.

Connection con = DriverManager.getConnection(“jdbc:odbc:dsnName",

”username”,”password”);

Statement stmt = con.createStatement(ResultSet.TYPE_SCROLL_SENSITIVE,

ResultSet.CONCUR_UPDATABLE);

stmt.setFetchSize(25);

ResultSet rs = stmt.executeQuery("SELECT emp_no,salary FROM

employees");

The example below creates a result set with the same attributes as the previous example,

however, a prepared statement is used to produce the result set.

PreparedStatement pstmt = con.prepareStatement("SELECT emp_no, salary FROM employees where emp_no = ?",

ResultSet.TYPE_SCROLL_SENSITIVE,

ResultSet.CONCUR_UPDATABLE);

pstmt.setFetchSize(25);

pstmt.setString(1, "100010");

ResultSet rs = pstmt.executeQuery();

The method DatabaseMetaData.supportsResultSetType() can be called to see which result set types are supported by a JDBC driver. However, an application may still ask a JDBC driver to create a Statement, PreparedStatement,or CallableStatement object using a result set type that the driver does not support. In this case, the driver should issue an SQLWarning on the Connection that produces the statement and choose an alternative value for the result set type of the statement according to the following rules:

  1. If an application asks for a scrollable result set type the driver should use a scrollable type that it supports, even if this differs from the exact type requested by the application.
  2. If the application asks for a scrollable result set type and the driver does not support scrolling, then the driver should use a forward-only result set type.

Similarly, the method DatabaseMetaData.supportsResultSetConcurrency() can be called to determine which concurrency types are supported by a driver. If an appli-cation asks a JDBC driver for a concurrency type that it does not support then the driver should issue an SQLWarning on the Connection that produces the statement and choose the alternative concurrency type. The choice of result set type should be made first if an application specifies both an unsupported result set type and an unsupported concurrency type.

In some instances, a JDBC driver may need to choose an alternate result set type or con-currency type for a ResultSet at statement execution time. For example, a SELECT statement that contains a join over multiple tables may not produce a ResultSet that is updatable. The JDBC driver should issue an SQLWarning in this case on the Statement, PreparedStatement,orCallableStatement that produces the ResultSet and

choose an appropriate result set type or concurrency type as described above. An appli-cation may determine the actual result set type and concurrency type of a ResultSet by calling the ResultSet.getType() and getConcurrency() methods, respectively.

Updates

A result set is updatable if its concurrency type is CONCUR_UPDATABLE. Rows in an Updatable result set may be updated, inserted, and deleted. The example below updates the first row of a result set. The ResultSet.updateXXX() methods are used to modify the value of an individual column in the current row, but do not update the underlying

database. When the ResultSet.updateRow() method is called the database is updated. Columns may be specified by name or number.

rs.first();

rs.updateString(1, "100020");

rs.updateFloat(“salary”, 10000.0f);

rs.updateRow();

The updates that an application makes must be discarded by a JDBC driver if the appli-cationmoves the cursor from the current row before calling updateRow(). In addition, an application can call the ResultSet.cancelRowUpdates() method to explicitly cancel the updates that have been made to a row. The cancelRowUpdates() method must be called after calling updateXXX() and before calling updateRow(), otherwise

it has no effect. The following example illustrates deleting a row. The fifth row in the result set is deleted from the database.

rs.absolute(5);

rs.deleteRow();

The example below shows how a new row may be inserted into a result set. The JDBC API defines the concept of an insert row that is associated with each result set and is used as a staging area for creating the contents of a new row before it is inserted into the result set itself. The ResultSet.moveToInsertRow() method is used to position the result set's cursor on the insert row. The ResultSet.updateXXX()and ResultSet.getXXX() methods are used to update and retrieve individual column values from the insert row. The contents of the insert row is undefined immediately after calling ResultSet.moveToInsertRow(). In other words, the value returned by calling a ResultSet.getXXX() method is undefined after moveToInsertRow() is called until the value is set by calling ResultSet.updateXXX(). Calling ResultSet.updateXXX() while on the insert row does not update the underlying database or the result set.

Once all of the column values are set in the insert row, ResultSet.insertRow() is called to update the result set and the database simulta-neously. If a column is not given a value by calling updateXXX() while on the insert row, or a column is missing from the result set, then that column must allow a null value. Otherwise, calling insertRow() throws an SQLException.

rs.moveToInsertRow();

rs.updateString(1, "100050");

rs.updateFloat(2, 1000000.0f);

rs.insertRow();

rs.first();

A result set remembers the current cursor position “in the result set” while its cursor is temporarily positioned on the insert row. To leave the insert row, any of the usual cursor positioning methods may be called, including the special method Result-Set.moveToCurrentRow() which returns the cursor to the row which was the current row before ResultSet.moveToInsertRow() was called. In the example above,

ResultSet.first() is called to leave the insert row and move to the first row of the resultset. Due to differences in database implementations, the JDBC API does not specify an ex-act set of SQL queries which must yield an updatable result set for JDBC drivers that support updatability. Developers can, however, generally expect queries which meet the following criteria to produce an updatable result set:

  1. The query references only a single table in the database.
  2. The query does not contain any join operations.
  3. The query selects the primary key of the table it references.In addition, an SQL query should also satisfy the conditions listed below if inserts are to be performed.
  4. The query selects all of the non-nullable columns in the underlying table.
  5. The query selects all columns that don't have a default value.

DATABASE MODELS

JDBC and accessing the database through applets and JDBC API via an intermediate server resulted server resulted in a new type of database model which is different from the client-server model. Based on number of intermediate server through the request should go it is named as single tire, two tire and multi tire architecture

In a single tier the server and client are the same in the sense that a client program that needs information (client) and the source of this type of architecture is also possible in java, in case flat files are used to store the data. However this is useful only in case of small applications. The advantage with this is the simplicity and portability of the application developed.

In two tier architecture the database resides in one machine and client in different machine they are connected through the network. In this type of architecture a database management takes control of the database and provides access to clients in a network. This software bundle is also called as the server. Software in different machines, requesting for information are called as the clients.

Three Tier and N-Tier

In the three-tier architecture, any number of servers can access the database that resides on server, which in turn server clients in a network. For example, you want to access the database using java applets, the applet running in some other machine, can send request only to the server from which it is down loaded. For this reason we will need to have a intermediate server which will accept the requests from applets and them to the actual database server. This intermediate server acts as a two-way communication channel also. This is the information or data from the database is passed on to the applet that is requesting it. This can be extended to make n tiers of servers, each server carrying to specific type of request from clients, however in practice only 3 tiers architecture is popular.

JDBC Driver Types:

The JDBC drivers that we are aware of at this time fit into one of four categories:

  1. JDBC-ODBC BRIDGE PLUS ODBC DRIVER The java soft bridge product provides JDBC access via ODBC drivers. Note that ODBC binary code end in many cases database client code must be loaded on each client machine that uses this driver. As a result, this kind of driver is most appropriate on a corporate network where client installations are not major problem, or for application server code written in java in a 3-tier architecture.
  2. NATIVE API PARTLY-JAVA DRIVER This kind of driver converts JDBC calls into calls on the client API for oracle Sybase, Informix, DB2, or other DBMS. Note that, like the bridge driver, this style of driver requires that some binary code be loaded on each client machine.
  3. JDBC-NET ALL-JAVA DRIVER This driver translates JDBC calls into a DBMS independent net protocol, which is then translated, to a DBMS protocol by a server. This net server middle-ware is able to connect its all java clients to many different databases. The Specific protocol used depends on the vendor. In general, this is most flexible JDBC alternative. It is likely that all vendors of this solution will provide products suitable for intranet use. In order for these products to also support Internet access, they must handle the additional requirements for security, access through firewalls, etc that the web imposes. Several vendors are adding JDBC drivers to their existing database middleware products.
  4. NATIVE PROTOCOL ALL-JAVA DRIVER This kind of driver converts JDBC calls into the network protocol used by DBMS directory. This allows a direct call from the client machine to the DBMS server that is practical solution for intranet access. Since many of these protocols are proprietary, the database vendors themselves will be the primary source. Several database vendors have these in progress. Eventually, we expect that driver categories 3 and 4 will be the preferred way to access databases from JDBC. Driver categories one and two are interim solutions where direct all java drivers are not yet available. Category 4 is in some sense the ideal; however, there are many cases where category 3 may be preferable: eg: -where a thin DBMS-independent client is desired, or if a DBMS -independent protocol is standardized and implemented directly by many DBMS vendors.

Introduction to Servlets

Servlets provide a Java(TM)-based solution used to address the problems currently associated with doing server-side programming, including inextensible scripting solutions, platform-specific APIs, and incomplete interfaces. Servlets are objects that conform to a specific interface that can be plugged into a Java-based server. Servlets are to the server-side what applets are to the client-side -- object bytecodes that can be dynamically loaded off the net. They differ from applets in that they are faceless objects (without graphics or a GUI component). They serve as platform-independent, dynamically-loadable, pluggable helper bytecode objects on the server side that can be used to dynamically extend server-side functionality.

What is a Servlet?

Servlets are modules that extend request/response-oriented servers, such as Java-enabled web servers. For example, a servlet might be responsible for taking data in an HTML order-entry form and applying the business logic used to update a company's order database.

Servlets are to servers what applets are to browsers. Unlike applets, however, servlets have no graphical user interface. Servlets can be embedded in many different servers because the servlet API, which you use to write servlets, assumes nothing about the server's environment or protocol. Servlets have become most widely used within HTTP servers; many web servers support the Servlet API.

Use Servlets instead of CGI Scripts!

Servlets are an effective replacement for CGI scripts. They provide a way to generate dynamic documents that is both easier to write and faster to run. Servlets also address the problem of doing server-side programming with platform-specific APIs: they are developed with the Java Servlet API, a standard Java extension. So use servlets to handle HTTP client requests. For example, have servlets process data POSTed over HTTPS using an HTML form, including purchase order or credit card data. A servlet like this could be part of an order-entry and processing system, working with product and inventory databases, and perhaps an on-line payment system.

Other Uses for Servlets

Here are a few more of the many applications for servlets:

  • Allowing collaboration between people. A servlet can handle multiple requests concurrently, and can synchronize requests. This allows servlets to support systems such as on-line conferencing.
  • Forwarding requests. Servlets can forward requests to other servers and servlets. Thus servlets can be used to balance load among several servers that mirror the same content, and to partition a single logical service over several servers, according to task type or organizational boundaries.

Architecture of the Servlet Package

The javax.servlet package provides interfaces and classes for writing servlets. The architecture of the package is described below.

The Servlet Interface

The central abstraction in the Servlet API is the Servlet interface. All servlets implement this interface, either directly or, more commonly, by extending a class that implements it such as HttpServlet.

The Servlet interface declares, but does not implement, methods that manage the servlet and its communications with clients. Servlet writers provide some or all of these methods when developing a servlet.

Client Interaction

When a servlet accepts a call from a client, it receives two objects:

  • A ServletRequest, which encapsulates the communication from the client to the server.
  • A ServletResponse, which encapsulates the communication from the servlet back to the client.

ServletRequest and ServletResponse are interfaces defined by the javax.servlet package.

The ServletRequest

The ServletRequest interface allows the servlet access to:

  • Information such as the names of the parameters passed in by the client, the protocol (scheme) being used by the client, and the names of the remote host that made the request and the server that received it.
  • The input stream, ServletInputStream. Servlets use the input stream to get data from clients that use application protocols such as the HTTP POST and PUT methods.Interfaces that extend ServletRequest interface allow the servlet to retrieve more protocol-specific data. For example, the HttpServletRequest interface contains methods for accessing HTTP-specific header information.

The ServletResponse Interface

The ServletResponse interface gives the servlet methods for replying to the client. It:

  • Allows the servlet to set the content length and MIME type of the reply.
  • Provides an output stream, ServletOutputStream, and a Writer through which the servlet can send the reply data.

Interfaces that extend the ServletResponse interface give the servlet more protocol-specific capabilities. For example, the HttpServletResponse interface contains methods that allow the servlet to manipulate HTTP-specific header information.

Additional Capabilities of HTTP Servlets

The classes and interfaces described above make up a basic Servlet. HTTP servlets have some additional objects that provide session-tracking capabilities. The servlet writer can use these APIs to maintain state between the servlet and the client that persists across multiple connections during some time period. HTTP servlets also have objects that provide cookies. The servlet writer uses the cookie API to save data with the client and to retrieve this data.

Servlet Lifecycle

Each servlet has the same life cycle:

  1. A server loads and initializes the servlet.
  2. The servlet handles zero or more client requests.
  3. The server removes the servlet.

Initializing a Servlet

When a server loads a servlet, the server runs the servlet's init method. Initialization completes before client requests are handled and before the servlet is destroyed.

Even though most servlets are run in multi-threaded servers, servlets have no concurrency issues during servlet initialization. The server calls the init method once, when the server loads the servlet, and will not call the init method again unless the server is reloading the servlet. The server can not reload a servlet until after the server has destroyed the servlet by calling the destroy method.

The init Method

The init method provided by the HttpServlet class initializes the servlet and logs the initialization. To do initialization specific to your servlet, override the init() method following these rules:

  • If an initialization error occurs that renders the servlet incapable of handling client requests, throw an UnavailableException.An example of this type of error is the inability to establish a required network connection.
  • Do not call the System.exit method

Initialization Parameters

The second version of the init method calls the getInitParameter method. This method takes the parameter name as an argument and returns a String representation of the parameter's value.

The specification of initialization parameters is server-specific. In the Java Web Server, the parameters are specified with a servlet is added then configured in the Administration Tool. For an explanation of the Administration screen where this setup is performed, see the Administration Tool: Adding Servlets online help document.

If, for some reason, you need to get the parameter names, use the getParameterNames method.
Destroying a Servlet

Servlets run until the server are destroys them, for example at the request of a system administrator. When a server destroys a servlet, the server runs the servlet's destroy method. The method is run once; the server will not run that servlet again until after the server reloads and reinitializes the servlet.

When the destroy method runs, another thread might be running a service request. The Handling Service Threads at Servlet Termination section shows you how to provide a clean shutdown when there could be long-running threads still running service requests.
Using the Destroy Method

The destroy method provided by the HttpServlet class destroys the servlet and logs the destruction. To destroy any resources specific to your servlet, override the destroy method. The destroy method should undo any initialization work and synchronize persistent state with the current in-memory state.

Handling Service Threads at Servlet Termination

All of a servlet's service methods should be complete when a servlet is removed. The server tries to ensure this by calling the destroy method only after all service requests have returned, or after a server-specific grace period, whichever comes first. If your servlet has operations that take a long time to run (that is, operations that may run longer than the server's grace period), the operations could still be running when destroy is called. You must make sure that any threads still handling client requests complete; the remainder of this section describes a technique for doing this.

If your servlet has potentially long-running service requests, use the following techniques to:

  • Keep track of how many threads are currently running the service method.
  • Provide a clean shutdown by having the destroy method notify long-running threads of the shutdown and wait for them to complete
  • Have the long-running methods poll periodically to check for

shutdown and, if necessary, stop working, clean up and return.
Tracking Service Requests

To track service requests, include a field in your servlet class that counts the number of service methods that are running. The field should have access methods to increment, decrement, and return its value.

Servlet-client Interaction

Handling HTTP Clients

An HTTP Servlet handles client requests through its service method. The service method supports standard HTTP client requests by dispatching each request to a method designed to handle that request. For example, the service method calls the doGet method shown earlier in the simple example servlet.

Requests and Responses

Methods in the HttpServlet class that handle client requests take two arguments:

  • An HttpServletRequest object, which encapsulates the data from the client
  • An HttpServletResponse object, which encapsulates the response to the client

HttpServletRequest Objects

An HttpServletRequest object provides access to HTTP header data, such as any cookies found in the request and the HTTP method with which the request was made. The HttpServletRequest object also allows you to obtain the arguments that the client sent as part of the request.

To access client data:

  • The getParameter method returns the value of a named parameter. If your parameter could have more than one value, use getParameterValues instead. The getParameterValues method returns an array of values for the named parameter. (The method getParameterNames provides the names of the parameters.)
  • For HTTP GET requests, the getQueryString method returns a String of raw data from the client. You must parse this data yourself to obtain the parameters and values.
  • For HTTP POST, PUT, and DELETE requests,

If you expect text data, the getReader method returns a

BufferedReader for you to use to read the raw data.
If you expect binary data, the getInputStream method returns a

ServletInputStream for you to use to read the raw data
Note: Use either a getParameter[Values] method or one of the methods that allow you to parse the data yourself. They can not be used together in a single request.

HttpServletResponse Objects

An HttpServletResponse object provides two ways of returning data to the user:

  • The getWriter method returns a Writer
  • The getOutputStream method returns a ServletOutputStream
  • Use the getWriter method to return text data to the user, and the getOutputStream method for binary data. Closing the Writer or ServletOutputStream after you send the response allows the server to know when the response is complete.

    HTTP Header Data

    You must set HTTP header data before you access the Writer or OutputStream. The HttpServletResponse class provides methods to access the header data. For example, the setContentType method sets the content type. (This header is often the only one manually set.)

    Handling GET and POST Requests

    The methods to which the service method delegates HTTP requests include,

    • doGet, for handling GET, conditional GET, and HEAD requests
    • doPost, for handling POST requests
    • doPut, for handling PUT requests
    • doDelete, for handling DELETE requests

    By default, these methods return a BAD_REQUEST (400) error. Your servlet should override the method or methods designed to handle the HTTP interactions that it supports. This section shows you how to implement methods that handle the most common HTTP requests: GET and POST.

    The HttpServlet's service method also calls the doOptions method when the servlet receives an OPTIONS request, and doTrace when the servlet receives a TRACE request. The default implementation of doOptions automatically determines what HTTP options are supported and returns that information. The default implementation of doTrace causes a response with a message containing all of the headers sent in the trace request. These methods are not typically overridden.

    About Session Tracking

    Session T tracking is a flexible, lightweight mechanism that enables stateful programming on the web. Its general implementation serves as a basis for more sophisticated state models, such as persistent user profiles or multi-user sessions.

    A session is a series of requests from the same user that occur during a time period. This transaction model for sessions has many benefits over the single-hit model. It can maintain state and user identity across multiple page requests. It can also construct a complex overview of user behavior that goes beyond reporting of user hits.

    Server-Side Session Objects and Users

    Session tracking gives servlets and other server-side applications the ability to keep state information about a user as the user moves through the site. Server-side applications can use this facility to create more stateful user experiences and to track who's doing what on the site.

    Java Web Server maintains user state by creating a Session object for each user on the site. These Session objects are stored and maintained on the server. When a user first makes a request to a site, the user is assigned a new Session object and a unique session ID. The session ID matches the user with the Session object in subsequent requests. The Session object is then passed as part of the request to the servlets that handle the request. Servlets can add information to Session objects or read information from them.

    Session Endurance

    After the user has been idle for more than a certain period of time (30 minutes by default), the user's session becomes invalid, and the corresponding Session object is destroyed.

    A session is a set of requests originating from the same browser, going to the same server, bounded by a period of time. Loosely speaking, a session corresponds to a single sitting of a single anonymous user (anonymous because no explicit login or authentication is required to participate in session tracking).

    Handling Non-Cookie Browsers (URL Rewriting)

    The Session Tracker uses a session ID to match users with Session objects on the server side. The session ID is a string that is sent as a cookie to the browser when the user first accesses the server. On subsequent requests, the browser sends the session ID back as a cookie, and the server uses this cookie to find the session associated with that request.

    There are situations, however, where cookies will not work. Some browsers, for example, do not support cookies. Other browsers allow the user to disable cookie support. In such cases, the Session Tracker must resort to a second method, URL rewriting, to track the user's session.

    URL rewriting involves finding all links that will be written back to the browser, and rewriting them to include the session ID..

    MultipleServlets

    URL conversions are required only if the servlet supports session tracking for browsers that do not support cookies or browsers that reject cookies. The consequences of not doing these conversions is that the user's session will be lost if the user's browser does not support cookies and the user clicks on an un-rewritten URL. Note that this can have consequences for other servlets. If one servlet does not follow these conventions, then a user's session could potentially be lost for all servlets.

    Using Session Tracking with the Page Compiler

    Page compilation is a feature of the Java Web Server that allows HTML pages containing Java code to be compiled and run as servlets. Page compilation also simplifies the task of supporting session tracking. To that end, if URL rewriting is enabled, page compilation automatically adds the encodeUrl call to links in the HTML page.

    Additional APIs

    In addition to the Session object, there are a few more classes that may interest the servlet developer.

    Description

    Class

    HttpSessionContext

    The HttpSessionContext is the object that contains all existing and valid sessions. The HttpSessionContext can be obtained by calling getSessionContext() on the Session object. The HttpSessionContext lets you find other Session objects by their IDs and list the IDs of all valid sessions.

    HttpSessionBindingListener

    HttpSessionBindingListener is an interface that can be implemented by objects placed into a Session. When the Session object is invalidated, its contained values are also removed from the system. Some of these values may be active objects that require cleanup operations when their session is invalidated. If a value in a Session object implements HttpSessionBindingListener, then the value is notified when the Session is invalidated, thereby giving the object a chance to perform any necessary cleanup operations.

    Session Swapping and Persistence

    An Internet site must be prepared to support many valid sessions. A large site, for example, might have hundreds, or even thousands, of simultaneously valid sessions. Because each session can contain arbitrary data objects placed there by the application servlets, the memory requirements for the entire system can grow prohibitively large.

    To alleviate some of these problems, the session tracking system places a limit on the number of Session objects that can exist in memory. This limit is set in the session.maxresidents property. When the number of simultaneous sessions exceeds this number, the Session Tracker swaps the least recently-used sessions out to files on disk. Those sessions are not lost: they will be reloaded into memory if further requests come in for those sessions. This system allows for more sessions to remain valid than could exist in memory. Session invalidation is not affected by session swapping. If a session goes unused for longer than the normal invalidation time, the session is invalidated, whether it is in memory or on disk. Session invalidation is set in the session.invalidationinterval property.

    Sessions are written to and read from disk using Java serialization. For this reason, only serializable objects put into the Session object will be written to disk. Any objects put into the Session object that are not serializable will remain in memory, even if the rest of the Session object has been written to disk. This does not affect session tracking, but does reduce the memory savings that the Session Tracker gets from swapping a session to disk. For this reason, the servlet developer should try to put only serializable objects into the Session object. Serializable objects are those that implement either java.io.Serializable or java.io.Externalizable.

    The session-swapping mechanism is also used to implement session persistence, if the session persistence feature is enabled. When the server is shut down, sessions still in memory are written to the disk as specified in the session.swapdirectory property. When the server starts again, ssions that were written to disk will once again become valid. This allows the server to be restarted without losing existing sessions. Only serializable data elements in the session will survive this shutdown/restart operation.

    Note: Session persistence is intended for preserving sessions across server restarts. It is not meant to be used as a general long-term session persistence mechanism.

    Customizing Session Tracking

    Session-tracking interfaces are in the javax.servlet.http package.

    Properties

    You can customize properties in the Session Tracker. The properties are kept in the server.properties files at:
    <server_root>/properties/server/javawebserver/server.properties
    where <server_root> is the directory into which you installed the Java Web Server product.

    Note: These property settings are applied to all sessions, and cannot be tuned for individual sessions.

    Parameter

    Description

    Default

    session.invalidationinterval

    Time interval when Java Web Server checks for sessions that have gone unused long enough to be invalidated. Value is an integer, specifying the interval in milliseconds.

    10000
    (10 seconds)

    session.swapinterval

    Time interval when Java Web Server checks if too many sessions are in memory, causing the overflow of sessions to be swapped to disk. Value is an integer, specifying the interval in milliseconds.

    10000
    (10 seconds)

    session.persistence

    Boolean value specifying if Java Web Server keeps session data persistent. If true, sessions are swapped to disk when Java Web Server shuts down and are revalidated from disk when it restarts. If false, Java Web Server removes session swap files every time it starts.

    True

    session.swapdirectory

    Name of directory that the Java Web Server uses to swap out session data. No other data should be kept in this directory.

    sessionSwap

    session.maxresidents

    Number of sessions allowed to remain in memory at once. If the number of sessions exceeds this number, sessions will be swapped out to disk on a least recently used basis to reduce the number of resident sessions.

    1024

    session.invalidationtime

    Amount of time a session is allowed to go unused before it is invalidated. Value is specified in milliseconds.

    1800000
    (30 minutes)

    enable.sessions

    Boolean value specifying whether Session Tracking is active. If false, then the Java Web Server performs no function for extracting or inserting session IDs into requests.

    true

    enable.cookies

    Boolean value indicating whether Java Web Server uses cookies as a vehicle for carrying session ID. If true, session IDs arriving as cookies are recognized and the Java Web Server tries to use cookies as a means for sending the session ID.

    true

    enable.urlrewriting

    Boolean value indicating whether Java Web Server uses rewritten URLs as a vehicle to carry the session ID. If true, then session IDs arriving in the URL are recognized, and the Java Web Server rewrites URLs if necessary to send the session ID.

    False

    enable.protocolswitchrewriting

    Boolean value indicating whether the session ID is added to URLs when the URL dictates a switch from "http" to "https" or vice-versa.

    False

    session.cookie.name

    Name of the cookie used to carry the session ID, if cookies are in use.

    Jwssessionid

    session.cookie.comment

    Comment of the cookie used to carry the session ID, if cookies are in use.

    Java Web Server Session Tracking Cookie

    session.cookie.domain

    If present, this defines the value of the domain field that is sent for session cookies.

    null

    session.cookie.maxage

    If present, this defines the value of the maximum age of the cookie.

    -1

    session.cookie.path

    If present, this defines the value of the path field that will be sent for session cookies.

    "/"

    session.cookie.secure

    If true, then session cookies will include the secure field.

    false

    Java Server Pages Technology

    JavaServer Pages technology lets you put snippets of servlet code directly into a text-based document. A JSP page is a text-based document that contains two types of text: static template data, which can be expressed in any text-based format such as HTML, WML, and XML, and JSP elements, which determine how the page constructs dynamic content.

    ORACLE

    INTRODUCTION:

    Oracle is a relational database management system, which organizes data in the form of tables. Oracle is one of many database servers based on RDBMS model, which manages a seer of data that attends three specific things-data structures, data integrity and data manipulation. With oracle cooperative server technology we can realize the benefits of open, relational systems for all the applications. Oracle makes efficient use of all systems resources, on all hardware architecture; to deliver unmatched performance, price performance and scalability. Any DBMS to be called as RDBMS has to satisfy Dr.E.F.Codd's rules.

    DISTINCT FEATURES OF ORACLE:

    4.ORACLE IS PORTABLE:

    The Oracle RDBMS is available on wide range o f platforms ranging from PCs to super computers and as a multi user loadable module for Novel NetWare, if you develop application on system you can run the same application on other systems without any modifications.

    5.ORACLE IS COMPATIBLE:

    Oracle commands can be used for communicating with IBM DB2 mainframe RDBMS that is different from Oracle, that is Oracle compatible with DB2. Oracle RDBMS is a high performance fault tolerant DBMS, which is specially designed for online transaction processing and for handling large database applications.

    6.MULTITHREADED SERVER ARCHITECTURE:

    Oracle adaptable multithreaded server architecture delivers scalable high performance for very large number of users on all hardware architecture including symmetric multiprocessors (sumps) and loosely coupled multiprocessors. Performance is achieved by eliminating CPU, I/O, memory and operating system bottlenecks and by optimizing the Oracle DBMS server code to eliminate all internal bottlenecks.

    FEATURES OF ORACLE:

    Most popular RDBMS in the market because of its ease of use

    7.Client/server architecture.

    8.Data independence.

    9.Ensuring data integrity and data security.

    10.Managing data concurrency.

    11.Parallel processing support for speed up data entry and online transaction processing used for applications.

    12.DB procedures, functions and packages.

    Dr.E.F.CODD's RULES

    These rules are used for valuating a product to be called as relational database management systems. Out of 12 rules, a RDBMS product

    hould satisfy at least 8 rules +rule called rule 0 that must be satisfied.

    RULE 0: FOUNDATION RULE:

    For any system that is to be advertised as, or claimed to be relational DBMS. That system should manage database with in it self, with out using an external language.

    RULE 1.INFORMATION RULE

    All information in relational database is represented at logical level in only one way as values in tables.

    RULE 2.GUARANTEED ACCESS:

    Each and every data in a relational database is guaranteed to be logically accessibility by using to a combination of table name, primary key value and column name

    RULE 3.SYSTEMATIC TREATMENT OF NULL VALUES

    Null values are supported for representing missing information and inapplicable information. They must be handled in systematic way, independent of data types.

    RULE 4 DYNAMIC ONLINE CATALOG BASED RELATION MODEL:

    The database description is represented at the logical level in the same way as ordinary data so that authorized users can apply the same relational language to its interrogation as they do to the regular data.

    RULE 5: COMPRHENSIVE DATA SUB LANGUAGE

    A relational system may support several languages and various models of terminal use. However there must be one language whose statement can express all of the following:

    Data Definitions, View Definitions, Data Manipulations, Integrity, Constraints, Authorization and transaction boundaries.

    RULE 6.VIEW UPDATING

    Any view that is theoretical can be updatable if changes can be made to the tables that effect the desired changes in the view.

    RULE 7.HIGH LEVEL UPDATE, INSERT and DELETE

    The capability of handling a base relational or derived relational as a single operand applies not only retrieval of data also to its insertion, updating, and deletion.

    RULE 8.PHYSICAL DATA INDEPENDENCE

    Application program and terminal activities remain logically unimpaired whenever any changes are made in either storage representation or access method.

    RULE 9.LOGICAL DATA INDEPENDENCE

    Application programs and terminal activities remain logically unimpaired whenever any changes are made in either storage representation or access methods.

    RULE 10: INTEGRITY INDEPENDENCE:

    Integrity constraints specific to particular database must be definable in the relational data stored in the catalog, not in application program.

    RULE 11: DISTRIBUTED INDEPENDENCE:

    Whether or not a system support database distribution, it must have a data sub-language that can support distributed databases without changing the application program.

    RULE 12: NON SUB-VERSION:

    If a relational system has low level language, that low language cannot use to subversion or by pass the integrity rules and constraints expressed in the higher level relational language.

    ORACLE SUPPORTS THE FOLLOWING CODD'S RULES:

    Rule 1: Information Rule (Representation of information)-YES.

    Rule 2: Guaranteed Access-YES.

    Rule 3: Systematic treatment of Null values-YES.

    Rule 4: Dynamic on-line catalog-based Relational Model-YES.

    Rule 5: Comprehensive data sub language-YES.

    Rule 6: View Updating-PARTIAL.

    Rule 7: High-level Update, Insert and Delete-YES.

    Rule 8: Physical data Independence-PARTIAL.

    Rule 9: Logical data Independence-PARTIAL.

    Rule 10: Integrity Independence-PARTIAL.

    Rule 11: Distributed Independence-YES.

    Rule 12: Non-subversion-YES.