The Design and Implementation of A Distributed Flight Ticket Booking System

CS6400

Jiang Bian

Qifeng Lin

Junjie Zhang

1. Motivation Air transportation has become the most popular and most convenient way for people to travel. Since the wide-spread using of airline, flight selection and flight ticket booking have become very important for the passengers, who need a convenient and fast information system for searching flight information and booking flight tickets. In this project, we plan to design and implement a distributed flight ticket booking system. Distributed database system is essential to flight ticket booking. First, since the airports are located at various cities in the USA, flights and tickets information should be more easily to store and manage in the distributed database system; Second, by focusing most of the query and update operations of flight and ticket information on local database, distributed database system can reduce the size of single database node without too much network traffic; finally, the replication of the flight and ticket information data in distributed database system can enhance the reliability and availability of the flight ticket booking system.

2. Problem Definition and Analysis The goal of the project is implementing a distributed database system with multiple nodes, which stand for multiple airports. All the separate local databases are organized together to form the distributed database system. Like Figure 1 show:

Figure 1 The architecture of the distributed system

Each node stores a part of flight information, ticket information and passenger

information for the whole distributed database system. And there will be some replication of the data between these three airport databases to make the distributed database system more reliable. However, this kind of high level problem definition can not demonstrate clearly enough of the concrete problems, so here we display our considerations during approaching it. 1. Distribution Transparency: This is a desirable feature of a distributed database

system; our system should be totally transparency: users do not need to know the location of data, the fragment of relations and the replication of data, this kind of data distribution issues.

2. Database Schema: Our design of the overall database schema should clearly

represent the data structure of a flight ticket booking system, and also data can efficiently stored.

3. Communication: Communication among the nodes is the foundation of a

distributed database. We will build a communication layer to achieve it. 4. Query Routing and Optimization: Here involves the issues that how to forward

a non-local operation to its target destination and when multiple routes can be chosen, how to achieve lowest communication cost.

5. Data Fragment and Replication: It will be essential to implement effective data

fragment and replication policies to achieve load balancing among the nodes, increased parallelism and enhanced availability. Like we have said before, the data fragment and replication are totally transparent to the users.

In our current work, we have designed and implemented the features regarding the first four points and some parts of the fifth point.

3. Highlights of the System Our main contribution in the project is implementing a totally user-transparent distributed database system with the flexible infrastructure. Based on the infrastructure, we can easily extend multiple applications of distributed database systems and also distribute data to any number of local nodes. The features of our system are shown below: 1. Total transparency: our system is totally transparent to users; users do not need

to know how the data is partitioned and stored. From the perspective of user our system appears like a centralized database system;

2. Scalability: Because of the P2P nature of the organization of agent, there is no

constraint on the scalability of the agent layer. Thus, just by configuring the routing information of the new nodes, you can add arbitrary number of local database nodes to the system; or you can configure the routing information of the whole organization of agents to optimize the routing performance;

3. Routing selection and optimization: through the pre-defined routing table in our

system, we can choose the routes forwarding some non-local operations to its destination; based on the existed routing information, a new node could select the routing and easily join in the organization as 2 illustrates;

4. Independence between GUI interfaces and Agent: our implementation of the

GUI and the agent is fully independent. Different interfaces implementation approaches can be used as long as constructing messages in the format the agent requests; this makes incremental augment to the applications functionality, offering good extendibility.

4. System Design

4.1 Database Design The ER graph of the database is shown below in Figure 2:

Figure 2 ER model

Overall database schema is:

Flight Flight No. Date From To Dep. Time Seat No. Ava. Seat

Airport Name City Addr Tele No.

Passenger SSN Name Tele No. Gender

Book SSN Flight No. Date Type Checkin

4.2 Data Fragment The partition strategy for the relation Flight: The relation Flight is horizontal partitioned. And tuples are distributed into the five airport database, each of which stores the tuples whose departure city is the same to the one its airport database deployed.

The partition strategy for the relation Airport: The relation Airport is horizontal partitioned. Each airport database stores the tuples which contain its own airports information.

The partition strategy for the relation Passenger: The relation Passenger is horizontal partitioned. Each tuple will be stored on the database of a certain airport where he or she has ever booked some flights.

The partition strategy for the relation Book: The relation Book is horizontal partitioned. Each tuple of the book information will be stored in the database of a certain airport which is the same to the departure city of the booked flight.

4.3 Operations on the database 1.Flight Information Retrieval-1

Input: flight number, departure date

Output: all the information about flights with the certain flight number and departure date

2. Flight Information Retrieval -2

Input: from_city, to_city, date Output: all the information about flights with the certain departure city, destination city and departure date

3. Airport Information Retrieval-3

Input: airports name Output: information about the certain airport

4. Booking Flights Input: result of the flight information retrieval

Update: inserting the booking Information into the Booking relation, updating the number of available seats number about flight information and inserting the passengers information into Passenger relation if it has not existed.

5. Booking Information Retrieval-1

Input: passengers ssn number Output: all the booking record about the certain passenger.

6. Passenger Check-in Input: flight number, passengers ssn number

Update: updating the check-in status of the booking information of a passenger from not check-in to check-in.

5. System Implementation Our system is constructed by two main modules, GUI and Agent. GUI is mainly responsible for interaction between users and our system. Agent is responsible for query routing and interaction between our system and database. The Figure 3 showed as follow gives us an overview of the architecture of our system. The goal of the GUI is to receive the requests of the users and send them to the lower agent after translate the requests into some SQL sockets. It must also receive the result of the requests and translate and then reveal them to the passengers with correct and clear meaning. As the key module working in the whole architecture of the distributed database system, Agent works in the scenarios below: The Agent receives a database query request; then the Agent decides the request is the operation on the local database or should forward the request to another Agent for remote operation on other databases;

at the end, the Agent receives the query results either from the local database or another Agent. We will discuss the functions of those two main modules in details in this section.

Input Input Input

SQL Generator

Destination IdentifySQL Statement

SQL Socket: SQL+Type+Destination

GUI

Message Parser

Local ? RouterN Other Agents

Agent

Y

Local Database

Figure 3 Architecture of the system in one node

5.1 The design and implementation of GUI The goal of the GUI is to receive the requests of the users and send them to the lower agent after translate the requests into some SQL sockets. It must also receive the result of the requests and translate and then reveal them to the passengers with correct and clear meaning. In this part, we will introduce our work on the design and implementation of GUI, step by step, from higher level to lower level.

5.1.1 Direct View and Functions of the GUI: The view of GUI is divided into two parts, showed by Figure 4. The left part is the control panel while the right one is display panel. In the control panel, you can do some operations such as searching flights information or booking some flights by specifying some certain attributes such as flight number, departure date, departure city and destination. You can refer to the specific description of all operations discussed in the section 4.3. In the display panel, you will be showed the results of your requests or the status of your operations, like success or error.

Figure 4 A snapshot of GUI

5.1.2 Interaction between GUI and Agent There are two direction behaviors of our system for the interaction between GUI and Agent modules. First, GUI receives the requests of the users and sends them to the lower agent after interpretation. Figure 5 gives us a direct view of this. The GUI will get the Input Attribute from the control panel and send them to SQL Generator and Interpreter after combining them with operation information. Then, after identifying destination, users request will be interpreted into a SQL socket which contains not only the request information but also some routing information created during destination identity. It will be sent to Agent to complete the operations.

Figure 5 GUI generates Request statement

On the other hand, GUI receives the result of the requests from Agent and translates and then reveals them to the users. The Figure 6 gives us a direct view of this.

Figure 6 GUI handles reply

SQL Generator / Interpreter

Request Status

Request Result

Operation Type

SQL Socket

SQL Generator / Interpreter

Input1 Input3 Input2 Input4

Operation Type

Destination Identity

SQL Socket

The GUI will get the requests result from Agent in the form of SQL socket and send them to SQL Generator and Interpreter to parse out the information which is needed by the user. Then, these pieces of information will be showed on the display panel of the GUI to the user who initiates the request. You can refer to the section on message format to understand more about the specific method of interpretation between request or result and SQL socket.

5.2 The design and implementation of Agent As the key module working in the whole architecture of the distributed database system, Agent works in the scenarios below: The Agent receives a database query request; then the Agent decides the request is the operation on the local database or should forward the request to another Agent for remote operation on other databases; at the end, the Agent receives the query results either from the local database or another Agent. To meet the requirements of the scenarios of applications above, the design and implementation of Agent must achieve such function goals: 1. Agent works as a server to listen/accept query request from GUI or other Agents; 2. Agent must have the routing function. In other words, if the Agent decides that the

query request is not a local operation and should be forwarded to another Agent, the Agent must know the next hop of the query request;

3. Agent should have the ability to interact with the local database; 4. Agent should have the ability to deal with the multi requests concurrently. Figure 7 below shows the position of Agent in the whole system and could reflect the function goals mentioned above.

GUI

Agent

Database

GUI

Agent

Database

request

results

request results results

Figure 7 the position of agent in the whole system

To truly fulfill the functions requirements of Agent, we propose such designs and

technique: 5. Sockets programming techniques are employed to communicate with GUI and

other Agent peers. Especially, the server sockets programming technique is utilized to implement the server function of the Agent;

6. Each Agent should have a routing table to decide the direction of every query request;

7. Because the backend SQL SERVER 2000 as the database system, the JDBC-ODBC bridge is adopted to enable the interact of Agent with database system;

8. Multi threads techniques of JAVA has been used to handle concurrent requests.

5.2.1 The architecture of Agent Figure 8 gives the working flow of Agent, which reflect the architecture of the Agent. It is necessary to notice that the server module does not discriminate that the request comes from a GUI or another Agent. Such design will simplify the architecture of Agent and make the function of server clear. Once the thread gets the encapsulated results, it will send the results back to the socket without considering whether the socket is initiated by a GUI or another Agent.

Figure 8 The architecture of agent

Here I give the description of the server module and thread module based on pseudo JAVA description.

The Server module: public class agent extends Thread { public agent(int port) { listen_socket = new ServerSocket(port); this.start(); } public void run() { try { while(true) { Socket client_socket = listen_socket.accept(); event new_client = new event(client_socket); } } catch(IOException e) { fail(e, "Exception while listening for conncetions from client"); } } public static void main(String[] args) { } } The thread module (named as Event): class event extends Thread { public event(Socket coming_socket) { client = coming_socket; try

{ in= new DataInputStream(client.getInputStream()); out = new PrintStream(client.getOutputStream()); } this.start(); } public void run() { try { while(true) { request = in.readLine(); if (request is local operation) { results = operation in local database; encapsulate the results; send the encapsulated results to out; break; } else { find the next hop; socket = new socket (next hop); forward (request, socket); encapsulated results = receive (socket, results); send the encapsulated results to out; break; } } close (client); } } } The function related with sockets and JDBC-ODBC has works well in the environment. The request can be forwarded correctly to the destination.

5.2.2 The design of the message format

Currently the message format is temporally designed as below: 1. Encapsulated Request:

%destination%operation_type%sql_statement% For example: %atlanta%select%select * from passenger% %seattle%insert%insert.% %seattle%update%update% %seattle%delete%delete..%

2. Encapsulated Reply:

Select reply: %select%ok%*RECORD1**RECORD2**RECORD3**RECORDn*% RECORD: $column1$$column2$$column3$$...........$column n$ %select%error%

Insert reply: %insert%ok%number of inserted items% %insert%error% Update reply: %update%ok%number of updated items% %update%error% Delete reply: %delete%ok%number of deleted items% %delete%error% The key point in the message format design is that how to transfer the ResultSets object in JAVA via sockets programming environment. We design such format and implement in our system. From identifying the information in the message, the application could handle most situations of the database operation, including success and failure.

6. System Test Because of the limitation of the hardware, we deploy five systems in two virtual machines in the VMware station. It is equal to the situation that the these five nodes are deployed in five different machines in the network, because that we use IP&PORT to identify each agent in corresponding system and their communication is based on socket. The testing environment for our system is illustrated in Figure 9.

Figure 9 The testing environment

Here are two scenarios to illustrate the working scenarios with different routing information: 9. In Figure 10, Atlanta could directly reach at the node Seattle. So a request from

Atlanta could reach directly Seattle. 10. In Figure 11, in the case that the network connection between Atlanta and Seattle

is not available, the Atlanta could use other nodes, New York and Cleveland as the router to forward the request to the Seattle destination.

Figure 10 Scenario with a directly reaching routing table

Atlanta

Newyork

Chicago

Cleveland

Seattle

Routing Table- atlanta

Dest Next HopSeattle Newyork

RequestReply

Routing Table- newyork

Dest Next HopSeattle Cleveland

Routing Table- cleveland

Dest Next HopSeattle Seattle

Figure 11 Scenario with an optimized routing table

In the testing phase of the system, our system is easy to configure and run stably in the environment.

7. Future work The current distributed flight ticket booking system is a prototype system. We adopt routing selection and optimization policies as well as basic data fragment and

replication. One of the issues we consider is that when the local nodes number increases, how to dynamically represent the routing related information, such as traffic information and how to optimize routing under this kind of complex scenarios. Another issue is the concurrency control against replicated data in the system. Some simple protocols such as primary copy can be applied to the system. At last, we want to counter systems vulnerability by introducing some failure nodes dealing strategies and communication lost dealing strategies.

Acknowledgement Thanks Prof. Shamkant Navathes insight suggestions about scoping the project, also his helpful comments to our proposal and mid-term report.