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

  • Cobol based Legacy System and an IMS Database accessed through 3270 screens.
  • Credit cards processing service by Transmaster via a secured socket across a dedicated line.
  • A Web Based Frequent Flyer Mileage (FFM) system that tracks mileage earned and used.

    top




    Objective
    The main objectives of the new system are to
  • Provide a Web Interface for booking airfares.
  • Replace Travel Agents' 3270 screens by a GUI.
  • Integrate FFM system with the Travel Agents' Desktop and Web Application.
  • Use the new Transmaster XML/RPC API.
  • All interaction with the customer and the system must be secured with SSL.

    On the performance front, the system must be able to
  • Handle 200,000 airfares bookings per day.
  • Handle 20 Travel Agents and 600 web users concurrently.
  • Keep the response time within 5 seconds for Travel Agents.
  • Ensure that response time doesn't exceed 10 seconds more than 20%
    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:
  • JSP/Servlets for Web Presentation along with elements like GIFs, HTML and JavaScript.
  • EJBs for Business Logic and Transaction Management.
  • JDBC For connection to RDBMS.
  • JavaMail For E-mail notification.
  • JAXP for XML processing.
  • Swing For Desktop Client.
  • I18N API For Internationalization/Localization.
  • Java WebStart for Installation/Auto-Update of Desktop Client.

    The application will be based on MVC Model 2 architectural pattern.

    top




    Assumptions
  • A given Itinerary is composed of Segments. Each Segment represents a flight. The traveler would select a seat on each segment.
    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.
  • Unpaid Itineraries will be persisted.
  • A seat would be counted as reserved only when the Itinerary is paid for.
    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.
  • The overall price of an itinerary is the sum of that of all the included Segments.
    Every segment (source-destination) has a fixed fare for a Service Class (e.g. First, Economy, Business).
  • Service Class would be a part of Search Criteria.
  • The use cases do not indicate when Credit Cards are added to the profile. It is assumed that Create/Update profile use case would include that feature.
  • The Pay For Itinerary doesn't indicate how Mileage is awarded or deducted. It only checks if there is sufficient mileage available for a new reservation. It is assumed that the mileage would be updated in the FFM Database by a separate use case not described here.
  • When an Itinerary is changed and a Segment is deleted, its not clear where the Prepare Itinerary Use Case starts.
    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.
  • The FFM Relational Database Schema is known and can be directly accessed by the new system using a JDBC driver.
  • Travel agents computers are inside the FBN Firewall and tunneling is not required for accessing EJBs.
  • The two SUN 450 can have J2EE WebContainers. If its not the case, the web application can be co-located with the EJB Application as one EAR.

    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:

  • Composite View
  • Front Controller
  • Business Delegate
  • Session Facade
  • Composite Entity
  • Transfer Object
  • Data Access Object

    top

  • SCEA J2EE Enterprise Architecture © 2008. Template by Dicas Blogger.

    TOPO