High Level Design Document Flight Reservation System Overview -------- The Flight Reservation System is designed to ease travel planning and booking by allowing agents to reserve seats on regular airline flights across multiple airlines and multiple hubs. Currently, this system deals only with "non-stop" flight reservation; it does not have the ability to recognize multi-leg solutions. Because this system is intended to be used by many people at once, it has been divided into components that can each execute on a separate machine. This is done for a couple of reasons: - As additional demands are made on the system, hardware resources can easily be added in the form of additional client or server machines without disrupting availability for existing users. - To minimize the deployment overhead of this system, only software concerned with presentation of information is deployed externally, therefore, changes in the search algorithm or datasource need not prompt code delivery to end users. Design ------- The overall design for this system falls under the classification of a multi-tier system Tiers are logical separations: physical deployment may combine two or more tiers onto a single machine. The Client Tier: The code in this tier is responsible for guiding the end user through a criteria selection process that will allow us to identify flights that may suit him/her; for displaying flights that meet those criteria so that the user can review them; and for allowing the user to select a flight to reserve capacity (seats) on. Criteria include: Originating City, City of Destination, Flight Departure Date, Seating Preference (window/aisle/no preference), and number of seats. Flight information includes: Originating City, Originating Airporty, City of Destination, Destination Airport,Flight Departure Date, Aisle Seats, Window Seats, Total Seats, Operating Airline, Inflight Meal (Meal, Snack, None), and Price (in USD). One important note about the client tier is this: the client tier is a "dumb" tier that is only concerned with gathering information from the user and presenting results. All actual business processing occurs on the server. Therefore, one implicit task of the client tier is to connect to a server. In actuality, upon startup, the client reads a configuration file that lists connection information (host,port) for multiple servers. The client connects to the first server, but retains the connection information for the remaining servers in case of server failure or communication problems with the sever. In this scenario, the client can switch to an alternate source of flight information. Important Classes: FRSClient: The application entry point for the client. This class reads the configuration file, creates an instance the ServerProxy with the configuration information, and then creates and displays the main frame. Failure to find the configuration file or connect to the server causes early exit. ServerProxy: This class is responsible for connecting to the server and relaying search requests, search results, and reservation requests to and from the server. Operations are atomic and stateless, so a search can be performed while connected to one server, but capacity requested on another server if the first goes down. FlightCriteriaPanel: This class is responsible for collecting the "flight selection criteria" that the user is interested in, as well as providing the launching point (a "Search" button) for performing searches. The Search button bundles the user input as FlightCriteria object and passes it to the ServerProxy to perform the search. MatchingFlightsPanel: This class is responsible for displaying the 0,1, or more flights that match the user's criteria. The Flight objects are passed in from the ServerProxy, which receives the results of the search request it makes to the server. Flights are displayed in a "table". The "Reserve" button passes the selected Flight back to the ServerProxy to be relayed as a reservation request to the server. FlightCriteria: A data wrapper class for the attributes listed above Flight: A data wrapper class for the attributes listed above The Business Tier: The code in this tier is responsible for identifying flights that meet the user's requirements. The flight data is retrieved from an external source, so the code in this tier is responsible only for the execution of the search and the manipulation of the search results. Business rules dictate, for example, which order flights are returned in based on their operating airline, their cost, and their remaining capacity. The business tier acts as a server to the client/presentation tier (in that it services requests), but as a client to the Data Tier (in that it makes requests for data from that tier). Important Classes: FRSServer: The application entry point for the server. This class begins listening on a socket, and for each client connection request, creates a ClientHandler to communicate with the client, then resumes listening for connection requests. ClientHandler: This class executes in its own thread, and represents an ongoing "conversation" with a client. When a client requests a search, it is the ClientHandler that receives the FlightCriteria, and passes it to the FlightIdentifier. It takes the Flight objects that the FlightIdentifier returns and passes them to the FlightPackager for ordering (and stuff), then returns the list of Flights from FlightPackager to the client. FlightIdentifier: This class takes the FlightCriteria object and transforms it into a SQL statement that is used to retrieve matching flights from the database. It then takes the raw data from the database and creates Flight objects. Note: FlightIdentifier could also be considered part of the Data Access Tier. FlightPackager: This class reads a local configuration file and uses it to order the Flight objects such that flights on preferred airlines are placed in early in the list. Other possible placement factors include: price, originating/destination city. Because the Business Tier may contain multiple copies of its code (i.e. multiple "servers" running), it is difficult to cache flight information. Capacity information would quickly become obsolete as end users connected to other servers reserved capacity (seats) on flights. Distributed caches are a difficult problem, and this possibility (that the client and business tiers might scale beyond the capacity of the Data Access Tier) represents an open concern. The Data Access Tier: We are using a pre-packaged solution for a majority of the data access tier. Oracle's enterprise relational database version 8.17 is being used to store the flight information. Custom code will still be written to retrieve and update flight information stored in Oracle, however. We chose a relational database as the storage/access product of choice for the following reasons: - Relational databases are a mature technology, meaning that ... - They contain sophisticated mechanisms for holding frequently-accessed data in memory instead of on disk; for allowing data to be shared among multiple users in a safe (noncorruptive) manner; and for optimizing the representation of the flight data in secondary storage - They have been well-tested in production environments with large data loads - The technology to use/access relational databases (SQL) is well-known and commonly available among developers - Given our existing relationship with, and investment in, Oracle, it is cost-effective to add the additional licenses required for this system