SUN CERTIFIED ENTERPRISE ARCHITECT
SCEA EXAMS 310-051, 310-300A, 310-061
_
FBN Booking System
Background
Objective
Architecture Overview
Class Diagram
Component Diagram
Deployment Diagram
Prepare Itinerary Sequence Diagram
Price Itinerary Sequence Diagram
Pay For Itinerary Sequence Diagram
Change Itinerary Sequence Diagram
Assumptions
State Management
Authentication/Authorization
Persistence
Localization/Internationalization
J2EE Design Patterns
Q&A
Background
FlyByNight, Inc. (FBN) is a regional commuter airline and uses its own travel agents for booking all airfares.
The current system comprises of
top
Objective
The main objectives of the new system are to
On the performance front, the system must be able to
of the time for web users.
top
Architecture Overview
The proposed architecture is based on J2EE. J2EE provides a stack of technologies which cover the gamut of enterprise applications like this. The J2EE platform provides all the services e.g. security, transactions and lifecycle management which simplify development of multi tier, component based and scalable systems.
The new application will be based on J2EE Platform and make use of the following APIs:
The application will be based on MVC Model 2 architectural pattern.
top
Assumptions
e.g. Going from LAX to SEA via SFO has two segments: LAX-SFO by Flight#F1 and SFO-SEA by Flight#F2. Traveler needs a reservation on both of these segments.
An unpaid itinerary can still have the seat number, but it would be available for others to book. When that happens, the unpaid itinerary cannot be confirmed without selecting a new available seat. In such cases where Itinerary has become invalid, the Prepare Itinerary Use Case is initiated.
Every segment (source-destination) has a fixed fare for a Service Class (e.g. First, Economy, Business).
Its assumed that it would begin at alternative flights view for that source-destination airports and if already Confirmed the itinerary status would change to Unconfirmed.
top
State Management
For the web application, session would be kept as HTTPSession, maintained in the webserver.
Desktop Client would maintain its own state and would access stateless EJB Services.
Desktop Client would also benefit from local cache of frequently used data which would help achieve its performance targets.
The other alternatives of session state being using Stateful Session Beans and Database are not recommended.
The majority of users are projected to be using the Web Application, so leveraging the cluster of two WebServers justifies the choice.
top
Authentication/Authorization
There are two kinds of users of the application - Travel Agents using the Desktop Client and Customers who use the web interface.
The Desktop application would be a J2EE Application Client, and the J2EE Client container would authenticate the travel agents.
Web Users will be authenticated by the container using a FORM login mechanism.
The J2EE platform does not standardize a mechanism to add users dynamically to applications. So there is an obvious tradeoff.
Container Managed Security is easier to implement and maintain but would require a container specific code to access the user directory of the server. As this will only be a small piece of code and can be developed in a pluggable way so that when the need arises, can be replaced without much impact to the application, the architecture proposes the use of Container Managed Security.
top
Persistence
The new application will make use of CMP Entity Beans. All Entity Beans will expose local interfaces
and there relationships will be managed by Container (CMR EJB 2.1).
Entity Beans would follow the Composite Entity Pattern.
The new application will also use DAOs for searches and integration with FFM.
top
Localization/Internationalization
Its common industry practice to show local times for Flights. As the airports could very well lie in different time zones, I18N APIs would be used for this translation.
top
J2EE Patterns in Use
The new architecture makes use of a number of design patterns including:
top