‘Airline Mobile Reservation Development’ PDF Quick download link is given at the bottom of this article. You can see the PDF demo, size of the PDF, page numbers, and direct download Free PDF of ‘Flight Booking Process: Structure, Steps, And Key Systems’ using the download button.
Airline Reservation System Project Documentation PDF Free Download
Airline Reservation
Introduction
In modern-day society, airlines are some of the most complicated and most frequently used systems globally.
Airline systems seamlessly incorporate a wide variety of features including flight schedules, passenger reservations, and airport arrival coordination.
An individual airline’s direct distribution works within its own reservation system, as well as pushing out information to the global distribution network (GDS).
Travel agencies and other indirect distribution channels access the same GDS.
In addition, a secondary direct distribution channel is available for consumers who use the internet or mobile applications to make their own reservations.
Objective
The main objective of our project is to deploy a flight reservation system in a distributed computing environment with a focus on fulfilling consumer requests.
We chose to simplify the booking process by removing flight scheduling and transaction processing from our system.
By focusing on reservations alone, our reservation system aims to provide a reliable, distributed
reservation system that can handle multiple asynchronous requests from clients.
More specifically, we designed our flight reservation system as a client-server application.
As stated before, we will be assuming that other portions of the system (i.e. timing at airports, delays, etc.) are managed by other connected systems.
In other words, the goal of our system is to enable clients to request a reservation for seat(s) on a specified flight.
When running the client-side version of the program, the client will be asked to provide a unique client identifier.
After this, the client makes requests for seat(s) to the server.
Client requests can come in one of two forms.
The client can either request a number of seats on a flight (i.e. 5 tickets to flight 543) or request specific seat(s) on a flight (i.e. seat 39A and seat 39B on flight 543).
Architecture
Our system consists of three main components – the client, the local cluster, and the remote cluster.
We decided to focus on the reliability of the system in case of faults, so we implemented each component in such a way that even in the case of large failures, this system is able to run with limited bandwidth.
Below you can see the scheme of our system.
Every request from our clients comes to a load balancer which directs a request to one of the local cluster services.
The load balancer is the only service that does not have a backup. However, the load balancer can be easily changed if the situation requires it.
The local cluster service is responsible for the initial checking of the request.
It checks that the request is valid, authorization is complete, and all fields are completed.
This service is designed to be lightweight and able to perform a huge amount of requests per second.
After validation is done, the service pushes the request into Kafka to send it to the remote service.
Apache Kafka is a distributed message processing system.
It uses the publish/subscribe approach to process messages from a producer to multiple consumers.
It is widely used in the enterprise world.
It is also fault tolerant and, because of that, Kafka internally consists of multiple Kafka brokers and optionally Zookeeper to manage them.
Outside of the local cluster, the remote cluster is located in Amazon Web Service’s (AWS) cloud servers.
We use multiple remote cluster services to consume messages from Kafka, process them, and store information into the Hadoop File System (HFS) for further usage.
IV. Approach
The user client is built entirely in Python using the Tkinter module to build a GUI.
When the application is opened, the user is asked to input a unique identifier, the clientID, as shown below.
In the main interface, the flight name is an alphanumeric flight that is present in the main database.
Each name is provided in the comma-separated format of first name followed by last
name.
The seat field is optional and can be used to request specific seats on a particular flight if
desired.
Once the results are verified, the client’s clientID, requested flight name, reservation names, and desired seats are formatted into a JSON style string which is packaged into a HTTPS POST request to one of our local cluster nodes with a sixty second timeout.
If the request fails, the HTTPS response code is displayed to the user. If the request succeeds, a message box opens, informing the user that the reservation was successful.
To implement the local server side services we have used the Go programming language. Go provides great frameworks for creating small microservices and deploying them.
In addition, Go also offers a simple interface to execute work in parallel, which is essential for
our system.
Every service is provided with a separate yaml configuration file to have an ability to
scale the system linearly.
The remote cluster has the following return codes which indicate whether an operation is successful or not: 200 for completed requests, 409 when seat is taken, 400 if bad request and 500 in case of internal errors.
| Author | – |
| Language | English |
| No. of Pages | 6 |
| PDF Size | 3 MB |
| Category | Project Report |
| Source/Credits | ics.uci.edu |
Airline Reservation System Project Documentation PDF Free Download