Components of The Fly By Nights Reservations System

Schemas

Design choice made and reasons to support the same.

There are 4 basic components in the Fly By Nights reservations Applications as : Swing Client which the end user interacts with. Data Client which does communication with the local/remote DataBase Server. RMI Server  located locally or remotely server DBMS system which supports the schema layout,public interface to access, modify,add,lock etc. the DataBase.    There is also the DataBase Conversion tool that converts the Ascii flat file into a binary format to be used by the  DBMS

A waterfall paradigm approach was adopted while working out the design and specifications.

The front end should support the following 4 basic features (more features would have been incorporated, but that is within the scope of this project):

• Booking of Tickets
• Inquiry on flight schedules
• Inquiries on Flight reservations
• Cancellation of Reservations

Booking of Tickets:

The first step in Booking a ticket is to enter the traveler's requirements.
He could enter a day,date,origin airport,destination airport,flight number, carrier name or any combination of this fields. In addition if "any" is specified in the "origin airport" and/or the "destination airport"  fields, it shall be interpreted as a wildcard to bring up the flights that operate in between all the possible routes.
The available number of seats is displayed for all dates within the next week.

The flight details gets displayed on the Flights Details table. Which is a dynamically changing table based on the number of rows that were retrieved by the query.
On a particular date, the number of available seats may be less than 0 indicating wait list number.
Once a flight is chosen for booking, the details of the passengers are entered. At one point of time, more than one tickets can be booked on the chosen flight.
The details of a passengers are also entered using a table which is a dynamically growing table in itself.

Once the Booking is done, the user is notified of the ReservationKey number(s) assigned to the reservations just done. This key is the primary key of the Reservation and can be use for query and cancellation purposes.

Inquiry on Flights Schedules

The option provides for inquiry into the flights schedules master. It displays information about the various schedules of the flights operating between different routes.

The first step is to enter the query criteria.
The user can enter a Flight number,carrier,Day,Origin airport,Destination Airport or any combination of this fields.
All flights that match the criteria exactly are displayed on the flights schedules table.

The option is an inquiry only screen.

Inquiries on Flight reservations

The option provides for inquiry into the reservations information.
The main purpose of this option will be to check the status of a reservation like change of a reservation which was initially in the wait List.

The first step is to enter the query criteria.
The user can enter the ReservationKey of the ticket and directly access the information about the reservation.
The Reservationkey is the key for a reservation.
Else, the user can also enter the passengers lastName,firstName or ContactNo. But this may result fetching more than reservation details.

Cancellation of Reservations

A reservation can be canceled using this option.
Once a reservation is canceled all tickets in the wait list on the same flight and date, on which the just canceled ticket belong, are move forward and the status of the available is also updated on the record corresponding to the flight and date.

The first step in canceling a reservation is to pull up the reservation to be canceled. This can be achieved by a procedure similar to the above reservations inquiry. The flight to be canceled is chosen and the Cancel button is chosen to be deleted.

The status record of that flight number and date is also updated, as mentioned above.

Return To Top

The Data Client provides routines for each of the following:

• Inquiry of Flight schedules
• Find Flights that meets the travelers' requirements.
• Booking Tickets
• Inquiry of Reservations details
• Cancellation of Reservations
• Checking the status ( more specifically the number of available seats) of a flight on a particular date. This routine is used for debugging purposes mainly.

The remote instances are used to call the appropriate methods from the remote server to accomplish the task of query,booking or cancellation.

Whenever there was a remote exception from the remote object, a ClientException is thrown with the message of the remote object nested. This helps in knowing the actual error that occurred while the method was invoked.

Return to Top

The remote object represents the Server of the DBMS. It implements the DbServer  interface. The interface extends the java.rmi.Remote class. It provides the template of a DataBase server and provides the methods to access,modify,add,delete,lock,search etc. the DataBase the server embeds.

Important
The SeverImpl class encapsulates 3 different instances of the Data class.
In the parlance of RDBMS, this 3 objects are 3 tables to represent :

• Flights Schedules between various routes
• Flights Reservations
• Flights seats availability on a particular date and also the current booking number.

• FltNo : Flights Schedule
• Date:FltNo : Flight Status
• Date:FltNo:BkgNo : Tickets Reservations

The Key for a reservation is "Date:FltNo:BkgNo". The Date of travel and the flight number is a necessary part of the Reservation Key. The BkgNo is the count of  the booking done on the flight on a particular date. This is not same as the Seat number that was available/allocated at the time of booking the ticket. This is because if there was a cancellation of a reservation then the seat number has to be reused and for that we need to maintain a dynamic list of canceled seat number. Another problem is, when a ticket in the wait List is to be enhanced due to a cancellation, it will result in changing a key component of that ticket in the wait list.

The Status field of the reservation states whether a ticket is "OK" or in wait List. If the value of the Status field is a negative number then the ticket is in wait List and the negative value indicate the number of overBooked tickets before its reservation.

Depending on what the argument is in the "-Djava.rmi.server.hostname" option of "java" while starting the server, the Server will be started remotely or locally.

Return To Top

The Data class provides the basic database services. It uses two other support classes: DataInfo and FieldInfo

It provides the following methods:

• add
• close
• delete
• finalize
• find
• findCriteria
• getFieldInfo
• getRecord
• getRecordCount
• invariant
• lock
• modify
• releaseLocks
• releaseLocks(java.lang.String ClientId)
• unLock

Return To Top

The DataBase binary file has a header block followed by the data records.
The header block contains the following in sequence:

• an integer denoting the length of the header
• an integer denoting the number of fields in the schema
• an integer denoting the current number of data records
• pairs of the form (fieldname,fieldlength). There are as many such pairs are there are number of fields. The field name is written as UTF string and the fieldlength is written as an integer.
• The hexadecimal value "0XC0C0BABE" as the magic number that separates the header from the Data Records

Please see the Specifications for the Data Conversion tool.

Return To Top

The Schemas of the Data objects can be changed at any time without modifying any of the code, except that the Available field wherever mentioned is expected to be the last field by the DataClient class.

The Following are the Schema details of the data objects corresponding to Flights Schedules,Flight Reservations,Flight Status:

Flights Schedules
 

Name of Field	Length(in Bytes)	Description	Key
FltNo	5	Flight Number	Primary
OriginAirpt	3	Originating Airport of the Flight	X
DestAirpt	3	Destination Airport of the Flight	X
Carrier	15	The Flight Carrier	X
Price	8(double)	The Fare	X
Day	3(Sun to Mon)	The Day on which it Flies	X
Time	5(like 19:55)	The Time of flight	X
Duration	6(like 10h40m)	The duration of the flight	X
Available	4(an integer)	The maximum number of seats in the Flight	X

Flights Reservation
 

Name of Field	Length(in Bytes)	Description	Key
ReserKey	21	Date:FltNo:BkgNo	Primary
Date	10(mm/dd/yyyy)	The Date of travel	X
FltNo	5	The flight number of  the reservations	X
LastName	15	lastName of traveler	X
FirstName	15	FirstName of traveler	X
Sex	1	Sex of the traveler	X
ContactNo	12	The phone number	X
OriginAirpt	3	The originating airport	X
DestAirpt	3	The destination airport	X
Carrier	15	The flight carrier	X
Price	8	Price of ticket	X
Day	3	Day of travel	X
Time	5	Starting time of journey	X
Duration	6	Duration of journey	X
Status	4	OK or wait List number	X

As it is seen, the reservations information stores all of the flights details which would have been obtained from the flights schedule. There are 2 main reasons for this:

• Reduce remote calls to obtain the flights details
• Data represents a DBMS system and does not directly enforce relationship between the different Data objects.

• Implementation of the lock,unlock,releaseLocks methods
• Choice of RMI over Socket datagram/TCP-IP
• Thread Concurrency

•   Implementation of the lock,unlock,releaseLocks methods

As per the Sun certification instructions, the lock method must be implemented as:

public void lock(int recNum) throws IOException.

But this method has been implemented as:

public void lock(int recNum, String clientID) throws DatabaseException.

Reasons:

The clientID is required to know the identity of the client who has requested to place the lock.
This clientID is stored as the value of the key( which is recNum) for an entry in the DbLockTable.
When another client tries to unlock the record it is not allowed as it is not the owner of the lock.     The clientID is passed on to the server by the DataClient. It is a globally unique ID obtained as the      concatenation of the "hostname" where the client is running plus the string representation of the call      to "java.rmi.server.UID" which returns a unique ID for each client running in the same machine.

The lock method is a method of the Data class which represents a DataBase object. Hence any exception condition must be notified by the customized  DatabaseException.

    Implementation

The Thread asking for a lock blocks itself if it could not obtain the lock, by calling the        java.lang.Object.wait() method The Thread execution the unlock calls the java.lang.Object.notifyAll() to  notify all waiting threads to give a  try.

releaseLocks() and releaseLocks(String clientID)

This two are new additions.

releaseLocks() is called whenever the Data object is garbaged collected (by calling from the     finalize() method of the ServerImpl remote server and also whenever the server is "unreferenced".
The intended use of releaseLocks(String clienID) is to release all the locks placed by a client whenever the server knows that the connection with the clientID is lost or terminated.

• Choice of RMI over Socket datagram/TCP-IP

        1. RMI is the cutting edge technology on distributed objects computing
        2. RMI allows for HTTP connection if firewall is present without much extra programming
        3. Serialization and Deserialization of objects is done by RMI and need no writing of objects
            to stream and reconverting it. It is just same as calling a method of a class, which happens to
            reside in a local or remote location.

• Thread Concurrency

If a client wants to invoke a transaction like booking a ticket which requires exclusive access to records the lock and unlock are used in pair as the boundary of such a transaction. The possible steps for booking a ticket  will be:

               * Get the Flight Status record of a particular flight on a particular date.
               * Reduce the number of available by the number of tickets to book.
               * Modify the status record with  the new value of the Available
               * Make entries for the reservations

As each methods of the Data Class which do the above 4 steps are atomic, there would not be any   corruption of data. But if a lock was not placed after step 1 above, then another client could book  tickets on  the seats we are about to book in step 2. This would result to duplicate reservation key. Hence the correct solution is to place a lock before doing the booking and releasing the same so that another waiting client can have access. The corrected steps would like the following:

               * Lock the Status record for the flight on a particular date
               * Get the Flight Status record of a particular flight on a particular date.
               * Reduce the number of available by the number of tickets to book.
               * Modify the status record with  the new value of the Available
               * Release the lock on the status record
               * Make entries for the reservations

Return To Top