FBN Travel System Re-engineering Project

FBN Travel System

Re-engineering Project

Sun Microsystems
Enterprise Architect For J2EE
Part Two Exam Deliverable

Michael Louis Pastor

SCEA Candidate ID# 1008202 - SUN010028368

mikepastor@earthlink.net

Version 2.1 - July 28, 2005

Table of Contents

System Background
Architecture Overview
System Events
Data Model
Client Tier
Server EJB Tier
Utility Models
Testing and Measurement
Use Case Sequence Diagrams
Glossary

List of Figures

Deployment Component Diagram
Module Package Diagram
Data Model Class Diagram
Client Web Tier Component Diagram
UI Event Class Diagram
Table of User Interface Screens
Session EJB Tier Class Diagram
Entity EJB Tier Class Diagram
Credit Card Utility Model Class Diagram
Award Miles Adapter Model Class Diagram
Prepare Itinerary Sequence Diagram
Price Itinerary Sequence Diagram
Pay For Itinerary Sequence Diagram
Pay For Itinerary With Award Miles Sequence Diagram
Change Itinerary Sequence Diagram (Includes Login/Logout)

1. System Background

Fly By Night Airlines (FBN) is a dynamic regional airline which plans to take their business nationally. As part of this effort, they plan to re-engineer their flight reservation system to service their new national marketplace.

The current regional business is serviced by an IMS Database on a 3270 Cobol based system. They also have a web based Award Miles System that runs within their firewall. Credit card operations are handled externally by the TransMaster service. The new FBN system will utilize the new Internet (Web Service XML-RPC) interface provided by TransMaster.

The purpose of this document is to provide a Design Model, Data Model and Software Architecture Document. We have based this design on the requirements (use case model, domain model, vision & supplementary specifications) provided by the FBN management team and the business analyst. These artifacts form the basis of the "Inception" and "Elaboration" phases of the project.

Currently only in-house travel agents make reservations for customers via 3270 terminals. The new system will be used by the travel agents via a user-friendly desktop application. Customers will be able to make their own reservations via the Internet using a browser. Interfacing with the current Award Miles system will be accomplished internally from the new system.

FBN will be launching a national advertising campaign soon after the new system is online. The current volume of 20,000 reservations a day will increase to over 200,000 in that time period. Our system design is strongly influenced by the sheer size of the business and the need to have the software scale on a very large basis.

The speed of the new system is also critical. Average response time for the travel agent's desktop must be five seconds or less. Response time cannot exceed ten seconds for 80 percent of our web client requests (i.e. 80th percentile at ten seconds). FBN expects that most its web customers will be using dial-up modems. Stress and performance testing will begin early in the development process to insure this quality requirement.

This new system is critical for the success of FBN's new national service plan.

2. Architecture Overview

Architecture can be loosely defined as the organization and structure of the major elements of the system. Our approach is to highlight architecturally significant system requirements and then walk through the system explaining how the requirements will be met. Wherever possible, we describe a quality scenario that can be measured. We will start by looking at the deployment architecture and then move forward into the logical software architecture.

The choice of the J2EE architecture is the first step in building a solid solution. The requirements for the new FBN system dictate a distributed, highly scalable architecture that supports transactions. In this situation, Enterprise Java Beans (EJB) will provide the component architecture. Components provide the very expensive transaction and database concurrency services. Beans can be tuned by the Application Server to optimize and "throttle" user throughput.

The hardware platform for the first release has been chosen. The Sun machines will deliver fine performance.

We will use the Award Miles system as it stands and seamlessly interface to its functions. The local SMTP (Simple Mail Transport Protocol) email server will be used for outgoing mail.

The new Internet interface (XML-RPC) from TransMaster will used to verify/authorize credit. The TransMaster API is in beta and the service level agreement of a maximum 3 second response time will work well. A component will call their web service and be implemented as a "Bridge" pattern. This will allow new credit services to be used in the future without changing the larger reservation system.

The deployment architecture is shown below with a Unified Modeling Language (UML) component diagram. It visually describes the system in terms of the allocation of processes (components) to processing units (nodes) and the overall network configuration.

The logical software architecture describes the system in terms if its conceptual organization in layers, packages, major frameworks and subsystems.

We can see the following layers in the new FBN Travel Reservation System

Presentation - The pages that are displayed to the travel agents and customers. Our system will use Java Server Pages (JSP) and the Java Swing classes. Other views (mobile phone, etc.) could be added in the future. This layer is the "View" in the Model View Controller (MVC) Pattern.
Workflow - Translation of events, maintaining session and managing page transitions. Events will be dispatched to our Controller Bean (FBNSessionMgrEJB). This layer is the "Controller" in the Model View Controller (MVC) Pattern.
Domain - Business objects represented as Enterprise Java Beans (EJB). For example, the FBNItineraryEJB is an entity bean that represents the customer's flight plan. This layer is the "Model" in the Model View Controller (MVC) Pattern.
Business services - Credit authorization, email, etc. will be encapsulated in components to allow for change in the future.
Foundation services - Logging, database I/O, security.

We begin by dividing the new system into logical modules. We use the provided Domain Model and Use Cases to form our "high level" view of the system. The modules should be highly cohesive (i.e. focused functionality) with low coupling (i.e. independent). This breakdown divides the development effort into manageable development pieces. We can then begin an object oriented analysis to determine the events, objects and their responsibilities. We will describe these modules in this section.

The Scheduled Flight Module is responsible for holding all of the data on scheduled flights. It uses the Aircraft and Seat tables to provide details on the actual flight. All flight search requests will go through the Flight Module. The requirements only call for read-only access, but the module will be engineered to support administration functions (flight, seat and aircraft) in the future.

A unique ID is assigned to each scheduled flight.   It is important to distinguish this unique ID from the flight "name" which is often assigned to regular flights (e.g. Continental Boston-NewYork 110). The same name is used for each flight on a given day. However, we must assign a unique ID to each flight on each day.   Each flight may utilize a different physical aircraft with a different set of available seats.   The Flight Module manages the list of unique flights and the available seats for each of those flights.

The Customer Module will be responsible for managing all of the customer data. Logins and member profile updates will happen in the Customer Module. Any requests to charge credit cards or Award miles will also go through the Customer Module.

The Itinerary Module is responsible for maintaining data on all of the flight reservations made by a customer. A given Itinerary contains a set of Segments. Each Segment represents a flight (direct or a "leg" of a larger journey) for each seat reserved.   The Segment effectively links a customer to a given seat on a given flight.   The existence of a flight/seat in the Segment table removes the seat from the list of available seats for that flight. The overall price of an itinerary is the sum of all the included Segments.   Any pricing requests will go through the Itinerary Module.   To add Segments, the Itinerary Module will call the Flight Module for specific information.

The Controller Module is responsible for managing the command requests sent to it and returning the next screen for display to the user. This module will also manage session state for each customer. Our primary stateful session bean is the FBNSessionMgrEJB. All requests are dispatched through this bean. Events which involve Itinerary changes, will be delegated to the FBNItineraryMgrEJB stateful session bean. This additional controller was added to avoid having the FBNSessionMgrEJB become "bloated" with low cohesion.

The Presentation Module is responsible for interfacing with the user. The requirements call for a desktop GUI application and an Internet browser interface. Screen events (e.g. search flights, select credit card) will be standardized to avoid any coupling of the business logic with the presentation layer. The FBNDispatchAdapter will have implementations for the different presentation layers. It will be the only interface to the FBNSessionMgrEJB controller.

The Utility Module is responsible for managing our interactions with external systems (e.g. TransMaster, Award Miles, email).   Each system will have a component to encapsulate the access logic and allow for flexible growth in the future. The email system will be de-coupled from the main reservation system using a message bean (EmailUtilityEJB) for speed and flexibility.

Here is a package diagram which describes how the high level modules will be separated in the code.

3. System Events

We start our analysis by listing the events that the system can be expected to receive. A good way to do this is with System Sequence Diagrams (SSD). These diagrams allow us to view the system as a "black box".

Here is an SSD for the Prepare Itinerary use case

PrepareItinerary_system_sequence.

The SSD give us a high level view of the expected events. This list of events will allows us to start building objects and assigning responsibilities to them.

All of the events coming from the User Interface (UI) are standardized in Event classes. Each Event implements the Java API W3C UIEvent interface and adds the necessary parameters for the command.

With this design, server code can be unit tested by preparing a "test harness" to feed prepared events directly to the FBNSessionMgr controller. The presentation/client tier code is responsible for building these events with the proper data.

Here we graphically depict the action events that will be sent from the user interfaces.

Event class diagram

4. Data Model

The Data Model for the new system follows the provided Business Domain Model closely. A preliminary data model is presented in this section. It is based only on the written requirements and may have additions when the current IMS database schema is reviewed. We will walk through the data model describing the important relationships.

A customer can have many Itineraries open with us. We maintain basic profile information and credit cards for the Customer. Any credit or Award Miles access is done through the Customer.

An Itinerary will have many Segments. Each Segment represents a reserved seat on the customer's Itinerary (e.g. two people traveling will each have a Segment for each flight/leg in the Itinerary). Cost and payment information will be maintained in the Itinerary.

The Segment table provides the intersection where a specific seat on a specific flight is linked to a customer's itinerary. Each Scheduled Flight is assigned a set of Seats (based on aircraft) upon creation. This 'total' set is reduced by the 'reserved' seats in the Segment table to provide the list of 'available' seats.

The ScheduledFlight table is a read-only source of all FBN's scheduled flights. Each ScheduledFlight has many Seats depending on the aircraft type. The aircraft type and cabin seat layout is contained in the Aircraft table.

Here the data model is depicted graphically as a UML class implementation diagram.

FBN Database Model

5. Client Tier

The client presentation tier is handled by Java Server Pages (JSP) and a Swing based desktop application. Although the supplemental requirements state that the travel agents will access the system via a graphical user interface "application", there is no reason why the browser interface could not also be used for this purpose. Nonetheless, we include the desktop client interface as part of this design document. The value added is the rich GUI interface we could provide to the Travel Agents.

All communications with the clients are encrypted with SSL for security. HTTPS is used for web clients and TCP/IP with SSL for the application clients. Since the desktop application clients are always behind the corporate firewall, using SSL for them could be considered optional at management's discretion.

All actions from the user front end are packaged as standard events (extends UIEvent). The FBNDispatchAdapter interface is the "translator" which packages events in a standard way. It is responsible for dispatching all events to the application controller (FBNSessionMgr) and forwarding any returned data to the client.

The FBNDispatchAdapter looks up the FBNSessionMgr bean through the FBNServiceLocator. The Service Locator pattern is used whenever an EJB handle is needed in the system.

The JSP server side processed display logic provides the best way to deliver simple HTML to the client. The pages will be setup as "panels" which fit inside a small set of composite template JSPs. All interaction between the browser and the dispatch servlet will be handled through these template JSP pages. The template pages make good use of the Composite View pattern.

The desktop application will use the Java Swing classes to provide a rich, user-friendly interface for the Travel Agents. The application will communicate with the server via TCP/IP sockets over SSL. Standard Swing libraries will be used to implement the template/panel composite design.

The templates populate the panels based on data in the returned request scope bean. All data is produced at the Business Tier and transmitted to the Client Tier via simple Java Beans (Transfer/Value Object pattern). FBNDispatchAdapter will serialize the returned Java Beans and transmit them to the Swing client when necessary.

Standard Tag libraries (e.g. JSTL) will be used to encapsulate web display logic as Helper objects. This will allow the presentation development staff to work on the pages independent from the server technical staff. We could also include a lightweight Macromedia Flash SWF presentation on some pages for marketing appeal.

The FBNDispatchServlet is the focus of all HTTP requests made by the JSP pages. The FBNDispatchSocketServlet will be launched at startup (via web.xml) and "listen" for TCP/IP connections from desktop applications.

An Adapter pattern is used to separate the UI from the controller. This maintains the Model View Controller (MVC) design which allows the system to use multiple "View" interfaces. A concrete implementation for each UI interface ( FBNDispatchAdapterWebImp, FBNDispatchAdapterSocketImp ) is created to assemble the parameters and build a corresponding standard input event (see Section 3 - System Events). FBNDispatchTarget.dispatchEvent() then sends that event directly to the application controller (FBNSessionMgrEJB).

Here we look at the design of the FBN Dispatch Adapter. The dispatch adapter factory singleton will return the correct adapter implementation based on a passed argument. Each presentation type will enter the system through a different servlet. The implementations are the only access to the SessionMgr controller bean.

Each user interface screen is based upon a composite template. The Composite pattern is very useful in keeping the presentation layer modular and flexible. The template page uses information in the request/environment to determine which functional panel pages to populate. This gives us a steady format for many pages. Style sheets and standard Swing classes will be used to provide a consistent and flexible user interface format.

Here is a sample component diagram for the composite JSP screens.

Here is a preliminary list of the necessary FBN screens at a functional level. The web based implementation will use Java Server Pages. The desktop version will use the Java Swing classes. Engaging a graphic artist to design the final screens is a good idea. We would begin implementation with basic "wire frames".

FBN Screen name	Description

WelcomeCompositeTemplate	The basic template format for users who have just arrived at our site or opened the application.
CustomerCompositeTemplate	The basic template format for operations on a users profile or other data.
LoggedInCompositeTemplate	The basic template format for existing users who have logged into their account.

MainSearchPanel	The panel for entering basic search criteria.
SearchResultsPanel	The panel for presenting initial flight lists.
PricedFlightWithAltPanel	The panel for presenting priced flights with alternatives.
SelectSegmentSeatPanel	The panel for presenting available flight seats.
PricedItineraryConfirmPanel	The panel for presenting a priced summary of the pending transaction.
PayPricedItineraryPanel	Request payment and present payment options.
PayCreditCardPanel	Present available credit cards,
PayAwardMilesPanel	Present available Award Miles
PayStatusPanel	Present status of credit or award miles debit transaction.
DisplayItinerariesPanel	The panel for presenting the customer's existing itineraries list.
DisplayItinerarySegmentPanel	The panel for presenting all of the Segments in an Itinerary.

LoggedInHeaderPanel	The panel for displaying the standard banner and link buttons for a logged in user.
LoggedInLeftNavPanel	The left navigation for logged in users. Links to existing Itineraries, Profile, logoff, etc. are included.
FooterCopyrightPanel	Standard footer with copyright notices.
FBNErrorPage	The panel for presenting a serious system error (a.k.a. "Please try again later" page)

6. Server EJB Tier

The design of the server components is at the heart of a good system. These components allow us to scale and tune the application in very sophisticated ways. They also provide data concurrency for a large scale system. Synchronizing the data and providing transaction safety would be enough, however the components also provide us with user session management. The components of choice in the J2EE Architecture are Enterprise Java Beans.

We will try to walk through a "day in the life" of the FBN server components to explain the design and considerations.

The day begins when the FBNDispatchAdapter sends a packaged user event to the FBNSessionMgrEJB bean (i.e. dispatchEvent() ). The FBNSessionMgrEJB is a stateful session Enterprise Java Bean (EJB). It keeps our client session state and acts as a Facade for our other EJBs. It will challenge users who want to book a reservation without being logged in and implement the profile/membership security.

FBNSessionMgr exposes a "coarse grained" interface and all of the smaller, "fine grained" business requests will be efficiently delegated to other beans. It uses a Command pattern modularize the actions and make maintenance easier. The Service Locator pattern is used whenever an EJB handle is needed in the system.

To avoid having a "bloated controller" with low cohesion, a second controller is included in the design. This is the FBNItineraryMgrEJB bean. All new Itineraries are created by this stateful bean. It keeps the customer's "flight list in progress" through his/her session. This controller always has a primary itinerary that it is working on.

The AwardMilesAdaperEJB bean is our interface to the Award Miles System. It is implemented as a stateless session bean to encapsulate the task and business logic. The bean is covered in more detail in section 6 Utility Models.

The CreditCardUtilityEJB bean will allow us interface to TransMaster. The Bridge pattern used by this bean will allow the business to better adapt to changing business requirements (i.e. the interface) and new credit processing services (i.e. the implementation). This bean is also covered in more detail in section 6 Utility Models.

At the end of the day, we have scheduled an itinerary and processed the payment. The last step is to send the customer a receipt email.

Email must be sent to our customers at the completion of every payment transaction. We want the email service to be de-coupled from the new reservation system. If the corporate SMTP server is down we cannot wait on the sale or miss a confirmation email. We also would like the email request process to be as fast as possible because it is part of the Pay For Itinerary use case. This use case utilizes all of the beans and can contain a three second delay from the credit card processing service.

To this end, we are making the email utility a Message Driven Bean. The point-to-point design will connect the application (via a message queue) to a bean which will consume and process the email requests. The bean will provide us with encapsulated access to the javax.mail.Session object and will connect to a local FBN SMTP (Simple Mail Transport Protocol) server.

Here we graphically depict the session and message beans used in the system.

Since we are deploying the beans to a single application server (Sun E10000), we have the opportunity to utilize local interfaces with our beans. This will dramatically speed up response time but will take away location independence from our EJB deployment. All of the beans will include local interfaces to allow for this performance improvement feature to possibly be implemented in the future. The CMPSegmentEJB will utilize the local interface in a container managed relationship (see below for more details).

Here we depict the interfaces using the CustomerEJB as an example.

The entity beans are shown here. They all utilize container managed persistence (CMP). We choose to delegate the persistence tasks to the container for speed, efficiency and flexibility. Where the beans have to access the database directly (e.g. seats from a ScheduledFlight bean), a Data Access Object (DAO) layer will be implemented.

The ItineraryEJB and the SegmentEJB are joined with a container managed relationship (CMR). An Itinerary is always made of up of segments, so it makes sense to combine these objects. Since CMR requires a local EJB interface, the two beans must be co-located on the same machine.

Seats are "booked" by adding a Segment for that customer/itinerary and flight/seat combination. Each flight aggregates a collection of the "total" seats available (ScheduledFlightSeat) for the particular aircraft. The EJBSessionMgr bean will compare the "total" seat list to the "booked" seat list to provide a list of "available" flight seats.

Transaction locking will be used sparingly on the system. A Seat becomes reserved once a corresponding Segment is added to the database. The bean method for adding a new Segment will use the "RequiresNew" transaction attribute. Beyond that scope, we will use a "first-come first-served" algorithm for booking a seat . If a seat is reserved by another customer, before the first customer confirms his flight itinerary summary, then an alternate use case flow ("Re-enter seat choice") will be presented. The simplicity will buy us freedom from monitoring open transactions (i.e. the client never returns). Deleting a Segment automatically returns the Seat to the "available" state.

7. Utility Models

Accepting credit cards and processing them through a service is a fundamental part of FBN's business. To this end, we build the credit card utility with a Bridge pattern. This design will allow flexibility in the interface and the implementation. Credit operations will change over time and the system will adapt by altering the CreditCard interface/API. FBN may also want the flexibility of using other credit services in the future. This is achieved by providing a new CreditCardService implementation class.

The TransMaster Specification for its new web based product provides details on the XML format needed for communication. They are using a web service (XML request/ XML response over HTTP) to achieve hardware transparency and a flexible implementation. Our system will use a utility (HttpsSocketCall) to post out our request to TransMaster and receive their reply. The utility provides SSL (via Java Security Extensions/JSSE) encryption for all communications and will support SOAP.

The XML request will be assembled with the Java API for XML Processing (JAXP) and a SAX (Simple API for XML) parser will quickly fetch the TransMaster response code.

We use a direct socket call on this web service for speed and efficiency. Each connection will be made on a thread and time out if necessary. TransMaster's service level agreement states three second response time. We must achieve ten second response time for 80 percent of our client requests (i.e. 80th percentile at ten seconds). Processing a credit card must be fast and flexible for the future.

The Fly By Night Award Miles system is a fine web based utility for the business. We will provide an Adapter to get and post data to the Award Miles screens. The reading and writing of HTTP screens is sometimes called "screen scraping". Unless we can directly connect to the Award Miles Oracle database, we have few other interface options. The basic functionality of Debit and Fetch Award Miles can be accessed with this method.

8. Testing and Measurement

The Fly By Night Travel Reservation System will be developed in a series of iterations. Stress and performance testing will be included at each iteration to ensure performance expectations. At a minimum, the S&P tests will simulate the expected maximum usage of 620 (20 desktops and 600 web users) users entering 200,000 reservations over the course of a day.

Response time from the desktop applications (within the corporate firewall) will average no more than 5 seconds. Eighty percent of responses to the web Internet clients will not exceed ten seconds (i.e. 80th percentile at ten seconds). A standard tool such as LoadRunner should be used to execute the tests.

A "Test Harness" will be built to send predefined UI events to the SessionMgrEJB controller. This will allow the server code to be developed without coupling the presentation layer. Presentation layer objects will also code to the predefined UI Events. The end result of the submit should be a properly formatted event object.

9. Use Case Sequence Diagrams

Prepare Itinerary

(Use Case Text)

Price Itinerary

(Use Case Text)

Pay Itinerary

(Use Case Text)

Pay Itinerary With Award Miles

Change Itinerary

(Use Case Text)

10. Glossary

Customer - Any person who registers a profile (i.e. becomes a member) with FBN. Customers must be registered and logged in before they can purchase Itineraries.
Itinerary - A reserved travel plan for one or more people on FBN's scheduled flights. A customer can have many Itineraries.
Scheduled Flight - A planned flight for which FBN is selling reserved seats. Each scheduled flight is pre-populated with its total set of seats at creation time. The total set of seats depends on the aircraft type.
Segment - A flight or leg of a flight on a customer's itinerary. A Segment connects a customer itinerary with an actual flight and reserved seat. Entering the Segment in the database effectively reserves the seat.
Seat - Actual seat on a scheduled flight. The seat is reserved if there is a Segment which references it.
Aircraft - Any plane or other airborne vehicle ( turbojet, helicopter, etc.) which has a reservable seat.