FlyByNight Inc.
FlyByNight Travel System Re-write
Software Architecture Document
Version <0.4>
FlyByNight Inc. Travel System Re-write
Version:
<0.4>
Software Architecture Document
Date: <3/3/2016>
J:\USERS\MKANPA\TECH\ARCHITECT\FlyByNight Software Architecture.doc
Revision History
Date
11/04/02
Version
0.1
Description
Created initial draft of the Architecture
document.
Author
kanpa
Documented Understanding of Nonfunctional requirements in section 3.4
11/22/02
0.2
Updated logical view - added class diagram
kanpa
Documented understanding of Business
Architecture and Enterprise Architecture
and the scope of our Reservation
Application architecture based on J2EE in
connection with the above two.
Added reference to Semantic Analysis
Pattern based Online Reservation System
domain.
12/02/02
0.3
Updated Implementation view - added
Component and Deployment Diagrams
kanpa
Added assumptions section 3.6.
01/02/03
Confidential
0.4
Updated Use-case view - added Sequence
Diagrams and descriptions
FlyByNight Inc., 2002
kanpa
Page 2 of 25
FlyByNight Inc. Travel System Re-write
Version:
<0.4>
Software Architecture Document
Date: <3/3/2016>
J:\USERS\MKANPA\TECH\ARCHITECT\FlyByNight Software Architecture.doc
Table of Contents
1.
2.
Introduction
5
1.1
1.2
1.3
Purpose
Scope
Definitions, Acronyms and Abbreviations
1.3.1 Java 2 Platform, Enterprise Edition Glossary, http://java.sun.com/j2ee/glossary.html
1.3.2 Travel Industry Dictionary, http://www.hometravelagency.com/dictionary/index.html
1.3.3 Architecture Characteristics
1.4
References
1.4.1 SCEA Project assignment deliverable, index.html
1.4.2 FBN Business Domain Model, Business Domain Model.html
1.4.3 FBN Use-Case Model, Use Case Diagram.html
1.4.4 Interview with FBN CEO and CIO, instructions.html
1.4.5 Core J2EE Pattern Catalog
1.4.6 Java Blue Prints Enterprise Guidelines
1.4.7 EAI Architecture Patterns
1.4.8 Patterns for e-business
1.4.9 Applying Traditional Design Patterns to EJB Applications
1.4.10 Building Java Technology based business frameworks
1.4.11 Pattern – Oriented Software Architecture, Frank Buschmann et el.,
1.4.12 An Object Oriented Analysis Model for Flight Reservations
1.5
Overview
5
5
5
5
5
5
6
6
6
6
6
6
6
6
6
6
6
6
6
6
Architectural Goals and Constraints
7
2.1
2.2
2.3
2.4
2.5
2.6
2.7
Business Architecture
Enterprise Architecture
Non functional requirements
2.3.1 Technology requirements
2.3.2 Security requirements
2.3.3 Integration requirements
2.3.4 Performance requirements
2.3.5 Scalability requirements
2.3.6 Transaction requirements
2.3.7 UI requirements
2.3.8 Deployment requirements
Assumptions
2.4.1 Object Management Policy
2.4.2 Reuse Management
2.4.3 Technical team expertise
2.4.4 Budget
2.4.5 Miscellaneous technical assumptions
Constraints
Objectives
Software requirements
2.7.1 Operating System
2.7.2 Java Virtual Machine
2.7.3 J2EE Compliant Application Server
2.7.4 Web Server
2.7.5 Database Server
2.7.6 Email Server
Confidential
FlyByNight Inc., 2002
7
8
8
8
8
9
9
9
9
9
9
9
9
10
10
10
10
10
10
10
10
10
10
11
11
11
Page 3 of 25
FlyByNight Inc. Travel System Re-write
Version:
<0.4>
Software Architecture Document
Date: <3/3/2016>
J:\USERS\MKANPA\TECH\ARCHITECT\FlyByNight Software Architecture.doc
3.
4.
Use-Case View
11
3.1
11
12
13
14
15
16
17
18
Use-Case Realizations
3.1.1 Generic interaction model
3.1.2 Prepare Itinerary
3.1.3 Change Itinerary
3.1.4 Price Itinerary
3.1.5 Pay for Itinerary
3.1.6 Pay for Itinerary – Customer Selects Award Travel
3.1.7 Notify Frequent Flyer System
Logical View
18
4.1
4.2
4.3
18
19
20
20
21
21
Overview
Architecture analysis and design mechanisms
Architecturally Significant Design Packages
4.3.1 Architectural Layers
4.3.2 Architectural Patterns
4.3.3 Design Patterns
5.
Deployment View
22
6.
Implementation View
22
7.
Quality
23
7.1
7.2
7.3
7.4
7.5
7.6
24
24
24
24
24
25
8.
Modularity
Re-usability
Extensibility
Performance
Manageability
Security
Conclusion
Confidential
25
FlyByNight Inc., 2002
Page 4 of 25
FlyByNight Inc. Travel System Re-write
Version:
<0.4>
Software Architecture Document
Date: <3/3/2016>
J:\USERS\MKANPA\TECH\ARCHITECT\FlyByNight Software Architecture.doc
Software Architecture Document
1. Introduction
1.1 Purpose
This document provides a comprehensive architectural overview of the system, using a number of different
architectural views to depict different aspects of the system. It is intended to capture and convey the
significant architectural decisions, which have been made on the system.
It is also intended that this software architecture document will be representative of a common high-level
abstraction of the system that most of the system’s stakeholders can use as a basis for creating mutual
understanding, forming consensus and communicating with each other.
This software architecture document serves as a supporting documentation to assist examiners in evaluating
the necessary artifacts (Class diagram, Component Diagram and Sequence Diagrams) submitted as part of
the Sun Certified Enterprise Architect for Java 2 Platform, Enterprise Edition.
1.2 Scope
This software architecture document applies to FlyByNight Travel System Re-write project. The scope of
this document is limited to meeting the given functional requirements provided in the form of Use Cases
and satisfying the non-functional requirements captured during an interview with CEO and CIO of FBN.
The information captured from the interview is consolidated and documented in a separate section titled
non-functional requirements. See section 2.4.
Though the importance of business architecture is appreciated, the scope of this document is to capture
information relevant to software architecture only. A recommendation to evolve the business architecture
is briefly outlined in this document and the details shall be maintained separately using FlyByNight
Business Architecture Document 1
This document will be baselined and kept under version control once reviewed and the documented
assumptions are validated. Embracing on an iterative approach with an inherent assumption that no system
ever built is complete, as the software architecture evolves, this document will be updated.
It is expected that the audience of this document will have basic understanding of the online flight
reservation problem domain, software engineering, UML modeling, and java language concepts.
1.3 Definitions, Acronyms and Abbreviations
1.3.1 Java 2 Platform, Enterprise Edition Glossary, http://java.sun.com/j2ee/glossary.html
1.3.2 Travel Industry Dictionary, http://www.hometravelagency.com/dictionary/index.html
1.3.3 Architecture Characteristics
Modularity: Allows application functionality to be developed somewhat independently and localizes the
impact of design and implementation changes
Reusability: Leverages the domain knowledge and prior effort of experienced developers to avoid
recreating and revalidating common solutions to recurring application requirements and software design
challenges.
Extensibility: Allows for the easy addition of new functionalities
1
As of this writing, it is assumed that a business architecture document for FlyByNight Travel System doesn’t exist.
Confidential
FlyByNight Inc., 2002
Page 5 of 25
FlyByNight Inc. Travel System Re-write
Version:
<0.4>
Software Architecture Document
Date: <3/3/2016>
J:\USERS\MKANPA\TECH\ARCHITECT\FlyByNight Software Architecture.doc
Portability: Allows applications to run on machines of different operating systems.
Inversion of control: Allows the framework (rather than developers) to determine which set of applicationspecific methods to invoke in response to external events.
Consistence: Proves essential to a large-scale application to keep multiple ways of viewing and
manipulating the same data.
Scalability: Improves the capability to increase functionality loads over time.
1.4 References
1.4.1 SCEA Project assignment deliverable, index.html
1.4.2 FBN Business Domain Model, Business Domain Model.html
1.4.3 FBN Use-Case Model, Use Case Diagram.html
1.4.4 Interview with FBN CEO and CIO, instructions.html
1.4.5 Core J2EE Pattern Catalog
http://java.sun.com/blueprints/corej2eepatterns/Patterns/index.html
1.4.6 Java Blue Prints Enterprise Guidelines
http://java.sun.com/blueprints/guidelines/designing_enterprise_applications_2e/index.html
1.4.7 EAI Architecture Patterns
http://www.eaijournal.com/PDF/Lutz.pdf
1.4.8 Patterns for e-business
http://www-106.ibm.com/developerworks/patterns/index.html
1.4.9 Applying Traditional Design Patterns to EJB Applications
http://java.sun.com/javaone/javaone2001/pdfs/829.pdf
1.4.10 Building Java Technology based business frameworks
http://servlet.java.sun.com/javaone/javaone2000/pdfs/TS-518.pdf
1.4.11 Pattern – Oriented Software Architecture, Frank Buschmann et el.,
1.4.12 An Object Oriented Analysis Model for Flight Reservations
http://www.cs.wcupa.edu/~zjiang/flight.doc
1.5 Overview
This software architecture document is organized under following headings.
Confidential

Architectural Goals and Constraints

Use-Case View

Logical View

Deployment View

Implementation View

Conclusion
FlyByNight Inc., 2002
Page 6 of 25
FlyByNight Inc. Travel System Re-write
Version:
<0.4>
Software Architecture Document
Date: <3/3/2016>
J:\USERS\MKANPA\TECH\ARCHITECT\FlyByNight Software Architecture.doc
2. Architectural Goals and Constraints
Before we proceed with the architectural goals, it will be useful to document what we don’t intend to do
here. For the purpose of Sun Certified Enterprise Architect project assignment, we do not intend to come
up with a sophisticated business architecture or an enterprise architecture. Our goals are to define FBN
Travel system architecture that will adequately meet the given functional as well as non-functional
requirements. It is assumed that this travel system re-write project is the first attempt to adopt Object
oriented development methodology and hence no reusable artifacts exist currently in FBN.
It is believed that through iterative and incremental approach, as we gain better understanding of the over
all business requirements, sophisticated enterprise architecture can be evolved. Hence, it is important that
the current architecture is flexible and extensible.
We briefly outline here to further clarify what we mean by business architecture or enterprise architecture.
2.1 Business Architecture
This section is kept here as the business architecture has significant impact on the software architecture. To
compare it in terms of the Object Management Group (OMG) Model Driven Architecture (MDA), the
business architecture represents Platform Independent Model (PIM) while the software architecture
represents Platform Specific Model (PSM).
Though we are presented with a Business Object Model for the purpose of FBN Travel System rewrite, it is
viewed as a simple and concise model defined adequate enough for the purpose of understanding the given
Use Cases. The Use Cases themselves are not complete to sufficiently automate the real life Travel system
business processes but detailed enough to start defining architecture (Architectural analysis). It is assumed
that they will further be enhanced in future iterations.
The key to building successful business architecture is through Business Modeling. Business modeling is
the practice of abstracting and representing a business for better understanding and communication. An
abstract model could represent many different businesses but is specific to none. Through successive
refinements, the model is transformed into an accurate representation of a specific target business. Use of
semantic analysis patterns is one good way to build such an abstraction and represent a given business.
They emphasize the functional aspects of the application model.
For example, from the given business object model and use-cases, we will consider (assume or elaborate)
the following requirements for the flight reservation system.
 Customers make reservations for specific seats in specific flights.
 A flight is defined by a number and a date, and determines a route from an origin airport to a
destination airport. Equipment (or plane) is assigned to flights.
 A route is a way followed by a flight from its origin airport to its destination airport. A route may have
several flights that share the same origin and destination airports.
 A span is the way to get from a start airport to a termination airport using one flight. The start (or
termination) airport is called origin (or destination) airport of this span.
 For each flight there are several connecting flights (different flights that leave from an intermediate
stop closely after its arrival)
 A segment (reservation segment) is a portion of an itinerary representing a reservation to travel on an
airline flight. Each segment includes origin, destination, flight information and seat information.
 An itinerary includes a one-way route or a two-way route (round-trip). By a round-trip itinerary, a
passenger can go to an airport and come back using the same route. A passenger may use different
route to come back from the destination to which he/she arrived. For each route, he/she needs a set of
one-way itinerary. Such a round-trip is a special case of one-way trip where its source and destination
are the same.
Given the above requirements, we could apply such semantic analysis patterns as Travel Ticket pattern,
Confidential
FlyByNight Inc., 2002
Page 7 of 25
FlyByNight Inc. Travel System Re-write
Version:
<0.4>
Software Architecture Document
Date: <3/3/2016>
J:\USERS\MKANPA\TECH\ARCHITECT\FlyByNight Software Architecture.doc
Assignment pattern, Collection pattern, Connection pattern, Routing pattern, Role object pattern etc.,
For example, the assignment (Assignment pattern) of (reservation) segment to Seat, Flight and Span is
same as assignment to Faculty, Student and Staff in a University department information system. Another
example is that the Connection pattern is used to show connecting flights, connecting spans and connecting
airports. This Connection pattern is similar to a type of relationship in a class; managers and employees.
In order to stay focused on J2EE Architecture, herewith we just make recommendation and provide
guidance to come up with a solid Business Architecture, but we do not intend to do the same here. It is
planned that in the current iteration of flight reservation system development, we will focus on laying out
the foundation for J2EE based application architecture. For more details on Semantic analysis patterns for
the flight reservation domain, a reference model can be found from the references section (Refer 1.4.12).
2.2 Enterprise Architecture
The Enterprise architecture lays out foundation for the entire IT infrastructure in an enterprise. It defines
reusable assets that will be utilized by systems development across the enterprise. By its nature, it is
important for these reusable assets to be at a high level of abstraction. These reusable assets could be
combinations of guidelines, patterns, frameworks, and libraries.
The following lists some examples of the frameworks, enterprise architecture could typically include:
 Error Facility,
 Config Facility,
 Log Facility,
 Audit Log Facility,
 Security Facility,
 Authentication Facility,
 Help Facility, and
 Email Facility etc.,
Note that besides the available Java APIs to code such functionality, the advantage of building frameworks
on top of it (an additional layer) would be to provide a simplified façade interface for each of the
mechanism and enforce consistency among team members in availing such common infrastructure
facilities.
Again, detailing each of the frameworks would require a separate class and sequence diagrams. Building
such sophisticated enterprise architecture will have major impact on the project cost (time and resources).
Also, it is not advisible to over-engineer before such requirements are identified and the cost is estimated.
It may be possible that the organization’s object management policy would permit the use of open source
frameworks.
For the reasons stated above, we wouldn’t be making an attempt to detail the above listed framework
components. We will limit the scope of the current iteration (refers to the SCEA project assignment) to
define J2EE based application architecture to meet the given functional and non-functional requirements.
2.3 Non functional requirements
This section lists the non-functional requirements gathered from various sources. The architecture should ensure
that these requirements are met.
2.3.1 Technology requirements
System must be built using J2EE technology.
2.3.2 Security requirements
All communication between web client and the server must be secured using SSL.
Confidential
FlyByNight Inc., 2002
Page 8 of 25
FlyByNight Inc. Travel System Re-write
Version:
<0.4>
Software Architecture Document
Date: <3/3/2016>
J:\USERS\MKANPA\TECH\ARCHITECT\FlyByNight Software Architecture.doc
2.3.3 Integration requirements
Travel system should be integrated with Frequent Flyer legacy system and TransMaster credit card
processing system.
2.3.3.1 Frequent Flyer implementation details
 Perl
 CGI
 HTML
 Oracle DB
2.3.3.2 TransMaster credit card processing system implementation details
 Currently supports COBOL interface
 Currently communication is via a secured socket across a dedicated line.
 The next release of the product will be web enabled.
 New release will have an interface that will use XML-RPC over HTTPS
 New release will eliminate the cost of dedicated line by using Internet to communicate.
 New Travel system should be designed for the new release of the TransMaster system.
2.3.4 Performance requirements
Travel agents should have the fastest system possible. Response time should never exceed 5 seconds. Web
users will use 28.8K modem. Web users response time can’t exceed 10 seconds more than 20% of the
time. In other words 80% of the time, the system should not exceed 10 seconds response time.
2.3.5 Scalability requirements
The current system facilitates 35 concurrent travel agents. In the new system initially it is anticipated that
20 travel agents and 200 web users will be using concurrently. The maximum of 600 concurrent web users
are expected.
2.3.6 Transaction requirements
Currently the number of airfares being booked is 20,000 per day and it is expected to grow 10 times
(around 200,000) within the first month of going national.
2.3.7 UI requirements
Travel Agent UI will have to be the Java Application Client while web users UI will have to be Web client.
2.3.8 Deployment requirements
The following hardware will be used for deployment.
Software Component
Application Server
Oracle DB Server
Web Servers
Frequent Flyer system
Hardware
Sun E10000 Server
Sun E6500 Server
2 450s
E5500
2.4 Assumptions
It is important to define an architecture that will match organization's culture and expectations. From that
perspective it is necessary to understand about the organization's object management policy, Reuse management,
current development standards, team expertise, budget etc., Herewith we list the assumptions made on these
aspects.
2.4.1 Object Management Policy
It is not clear if the FBN organization’s object management policy would allow the use of open source
frameworks. Hence none of the open source framework is used in the current iteration of the architecture,
though a recommendation will be made to consider such frameworks.
Confidential
FlyByNight Inc., 2002
Page 9 of 25
FlyByNight Inc. Travel System Re-write
Version:
<0.4>
Software Architecture Document
Date: <3/3/2016>
J:\USERS\MKANPA\TECH\ARCHITECT\FlyByNight Software Architecture.doc
2.4.2 Reuse Management
It is derived assumption that Travel System re-write is FBN’s first development project based on the Object
oriented methodology.
2.4.3 Technical team expertise
As it is FBN’s first object oriented development project and also as there is a design constraint that the
system must be built using J2EE, it is assumed that the organization will either hire skilled resources or
train existing resources in object oriented methodology, Java and J2EE technologies.
2.4.4 Budget
We have made an implicit assumption that sufficient budget is available.
2.4.5 Miscellaneous technical assumptions
2.4.5.1 Persistence
A confirmed decision is not made for the relational database server selection. It could be Oracle, Sybase or
Informix, which will replace the IMS database. There is an E6500 server to host the Oracle database,
which is assumed to be the one used by Frequent Flyer system.
2.4.5.2 Java application client deployment requirements
There is no mentioning about the client deployment requirements as well as client desktop requirements. A
recommendation will be made to utilize Java Web Start Architecture to deploy Java client application
because of its ease of use in distributing client application bundles and automatic version checking and
update features.
2.4.5.3 Authentication and User data store
The choice of user data store implementation mechanism is not identified. The user data store can either be
implemented using RDBMS or LDAP compliant directory Server. Most J2EE servers support integration
with both implementation mechanisms to authenticate users. In order to achieve good return on investments
made in relational database server and to keep expenses lower, initial rollover could be made using
RDBMS. But based on the expected number of airfares booking which are 200,000 per day in the first
month of going national, the total number of users are anticipated to be in a higher range over a year period
and if user lookup (authentication) appears to be a bottleneck, it is recommended to migrate to LDAP
compliant directory server as these servers are optimized for read or lookup operations.
2.5 Constraints
Business analyst is no longer available.
2.6 Objectives
The evolving component technologies and standards make it possible for the businesses to open up doors to
interact effectively within the organization (EAI), with external business entities involved in the workflow
(B2B), or to reach customers over the Internet (B2C). The nature of FBN business demands to adopt these
component technologies in order to improve its business process and compete in the market to remain the
leader in its business domain.
2.7 Software requirements
2.7.1 Operating System
2.7.2 Java Virtual Machine
2.7.3 J2EE Compliant Application Server
J2EE compliant application server provides the infrastructure services necessary to build and deploy
enterprise systems such as load balancing, clustering, object pooling, connection pooling, caching,
persistence services, transaction management, security management, session management etc., The J2EE
compliant application server plays vital role in FBN architecture to meet many of its non-functional
Confidential
FlyByNight Inc., 2002
Page 10 of 25
FlyByNight Inc. Travel System Re-write
Version:
<0.4>
Software Architecture Document
Date: <3/3/2016>
J:\USERS\MKANPA\TECH\ARCHITECT\FlyByNight Software Architecture.doc
requirements. Most importantly the above listed infrastructure services help in improving system
performance and scalability.
2.7.4 Web Server
2.7.5 Database Server
2.7.6 Email Server
3. Use-Case View
In this section, we will list and detail the use-case realizations for the purpose of Architecture illustration.
Currently (Architectural design), only alternate flows that has architecture significance is illustrated using
sequence diagrams. It is assumed that later during detailed design, the designer will complete the model for
all flows, as necessary.
1.
Generic interaction model
Illustrates a typical sequence of interactions between significant classes to process user request.
2.
Prepare Itinerary
To illustrate how presentation tier components are interacting each other to handle view
management and view navigation.
3.
Change Itinerary
To illustrate how business tier components interact together to service client requests.
4.
View Mileage Account
To illustrate how synchronous architecture is applied to communicate and retrieve data from
another enterprise application.
5.
Notify Frequent Flyer System
To illustrate how asynchronous architecture is applied to notify business events to another
enterprise application.
6.
Pay for Itinerary
To illustrate how B2B architecture is applied to communicate with credit services.
3.1 Use-Case Realizations
This section illustrates how the software actually works by giving a few selected use-case (or scenario)
realizations, and explains how the various design model elements contribute to their functionality.
Confidential
FlyByNight Inc., 2002
Page 11 of 25
FlyByNight Inc. Travel System Re-write
Version:
<0.4>
Software Architecture Document
Date: <3/3/2016>
J:\USERS\MKANPA\TECH\ARCHITECT\FlyByNight Software Architecture.doc
3.1.1 Generic interaction model
3.1.1.1 Diagram
Figure 1:Generic interaction model (Zoom at 350%)
3.1.1.2 Description
The above sequence diagram shows generic sequence of interactions between key classes in order to process user
request. For subsequent sequence diagrams, the following assumption are made in order to avoid cluttering the
diagram and focus on the specific importance of the functionality.
Assumption: The sequence diagrams shown here depict interaction between architecturally significant classes. It is
assumed that in later iterations the use-cases will be detailed with necessary business rules and during the detailed
design the designers will elaborate and model more detailed sequence diagrams.
Confidential
FlyByNight Inc., 2002
Page 12 of 25
FlyByNight Inc. Travel System Re-write
Version:
<0.4>
Software Architecture Document
Date: <3/3/2016>
J:\USERS\MKANPA\TECH\ARCHITECT\FlyByNight Software Architecture.doc
3.1.2 Prepare Itinerary
3.1.2.1 Diagram
Figure 2: Prepare Itinerary (Zoom at 450%)
3.1.2.2 Description
The above sequence diagram for Prepare Itinerary illustrates how presentation tier components are interacting each
other to handle view management and view navigation.








When the container initializes the front controller servlet, a Command Dispatcher is instantiated during
which display commands are constructed and action code to display command mapping is maintained.
JSP View strategy is chosen to implement view pages.
A view page forwards user requests to front controller
Servlet Front strategy is chosen to implement Front controller
The Front controller works with a Command Dispatcher to complete view management and navigation.
Command Dispatcher and associated Display commands demonstrate the use of Service-to-Worker pattern
as described in the J2EE patterns catalog.
Display Commands gather data required by the view, decides the next view page to be rendered to the user
and returns the next view name
The Command Dispatcher forward to the next view.
Confidential
FlyByNight Inc., 2002
Page 13 of 25
FlyByNight Inc. Travel System Re-write
Version:
<0.4>
Software Architecture Document
Date: <3/3/2016>
J:\USERS\MKANPA\TECH\ARCHITECT\FlyByNight Software Architecture.doc
3.1.3 Change Itinerary
3.1.3.1 Diagram
Figure 3: Change Itinerary (Zoom at 400%)
3.1.3.2 Description
The above sequence diagram for Change Itinerary illustrates how business tier components interact together To
Whom It May Concern: service client requests.










Both client tier and presentation tier classes re-use the business tier logic.
In order to reduce coupling and hide the underlying implementation details of the business service,
OnlineReservationDelegate is used. It follows the Business Delegate pattern as described in the J2EE
Patterns Catalog.
From Client tier, the View Handler (Mediator) classes will use the OnlineReservationDelegate class.
From Presentation tier, the Display Command (Helper) classes will use the OnlineReservationDelegate
class.
The OnlineReservationDelegate intercept service level exceptions and generate user-friendlier application
level exceptions.
The OnlineReservationDelegate uses ServiceLocator (application of Service Locator pattern as described in
the J2EE Patterns Catalog) to hide the details of business service lookup code.
The ServiceLocator will improve performance by providing Caching Facility.
The OnlineReservationDelegate will then invoke services on OnlineReservationFacade, which applies the
Session Facade pattern as described in J2EE Patterns catalog.
The OnlineReservationFacade is implemented using Stateless Session Façade strategy.
Business object as Session Bean strategy is used to provide business service and wrap Data access logic.
Confidential
FlyByNight Inc., 2002
Page 14 of 25
FlyByNight Inc. Travel System Re-write
Version:
<0.4>
Software Architecture Document
Date: <3/3/2016>
J:\USERS\MKANPA\TECH\ARCHITECT\FlyByNight Software Architecture.doc
For example Online Reservation Façade will interact with such classes as ItineraryController,
FlightSelectionController, CustomerController etc.,
3.1.4 Price Itinerary
3.1.4.1 Diagram
Figure 4: Price Itinerary (Zoom at 500%)
3.1.4.2 Description
This sequence diagram illustrates
 The use of Pricing strategy class to calculate the price of an itinerary
Confidential
FlyByNight Inc., 2002
Page 15 of 25
FlyByNight Inc. Travel System Re-write
Version:
<0.4>
Software Architecture Document
Date: <3/3/2016>
J:\USERS\MKANPA\TECH\ARCHITECT\FlyByNight Software Architecture.doc


The assumption made that the system shall allow the actor to save an itinerary once it is priced and the
price is verified. The saved itineraries can later be paid.
The seat assignment logic. When new itinerary is saved, the seats for each of the reservation segment is
assigned. When a changed itinerary is saved, the seats for each new reservation segment is assigned, while
the seats for each replaced segment is unassigned. Assigned seats not necessarily mean confirmed seats, I
t is only upon payment of the itinerary the seats will be reserved (or occupied) by the passenger.
3.1.5 Pay for Itinerary
3.1.5.1 Diagram
Figure 5: Pay for Itinerary
3.1.5.2 Description
The above sequence diagram Pay for Itinerary illustrates how B2B architecture is applied to communicate with
credit services.
 Upon receiving request to pay for itinerary, the ItineraryController checks if the itinerary is new or
modified, if so saves the itinerary. (For save operation, check the sequence described in the Price Itinerary
sequence diagram after Pricing the itinerary)
 It then gets an implementation of ICreditCardServices,, which is TransMasterServices and issue request to
authorize credit card.
 The TransMasterServices uses Integration Adapter pattern (See References section for link to EAI
Architectural patterns)
 The TransMasterServices creates AuthorizeTxMessage class.
 The AuthorizeTxMessage converts the CreditCardVO into B2BEvent and vice versa.
 The B2BEvent class encapsulates the RPC-XML message format.
 The B2BEvent is now sent using HTTPSAdapter (protocol handler) to the TransMaster system.
 Upon receiving the response (pseudo-synchronous request/reply interaction model), it validates if the credit
card is authorized. A PaymentAckMessage will be used to convert the RPC-XML response to the
Confidential
FlyByNight Inc., 2002
Page 16 of 25
FlyByNight Inc. Travel System Re-write
Version:
<0.4>
Software Architecture Document
Date: <3/3/2016>
J:\USERS\MKANPA\TECH\ARCHITECT\FlyByNight Software Architecture.doc


PmtAckVO
If authorized, it marks the itinerary as paid and confirm seats for all the reservation segments for that
itinerary.
An email notification is sent either on successful or unsuccessful authorization of credit card.
3.1.6 Pay for Itinerary – Customer Selects Award Travel
3.1.6.1 Diagram
Figure 6: Pay for Itinerary: Customer Selects Award Travel
3.1.6.2 Description
The above sequence diagram illustrates the EAI architecture used as part of the alternate flow ‘Customer Selects
Award Travel’ in the Pay for Itinerary use-case. For EAI, the façade uses FrequentFlyerServices integration adapter
to retrieve customer’s mileage account information from frequent flyer system.
Confidential
FlyByNight Inc., 2002
Page 17 of 25
FlyByNight Inc. Travel System Re-write
Version:
<0.4>
Software Architecture Document
Date: <3/3/2016>
J:\USERS\MKANPA\TECH\ARCHITECT\FlyByNight Software Architecture.doc
3.1.7 Notify Frequent Flyer System
3.1.7.1 Diagram
Figure 7: Notify Frequent Flyer system
3.1.7.2 Description
The above sequence diagram illustrates the EAI approach using asynchronous fire and forget update style pattern.
 The ReservationEvent, which is an EAIEvent is instantiated
 The Reservation Event is published to JMS Queue
 Asynchronously, the ReservationEventListener, a Message Driven Bean, is notified of this event.
 The handling of this event is delegated to ReservationEventHandler.
 Based on the event code, it uses MileageAccountDAO to update the account.
4. Logical View
4.1 Overview
This subsection describes the overall decomposition of the design model in terms of layers.
Confidential
FlyByNight Inc., 2002
Page 18 of 25
FlyByNight Inc. Travel System Re-write
Version:
<0.4>
Software Architecture Document
Date: <3/3/2016>
J:\USERS\MKANPA\TECH\ARCHITECT\FlyByNight Software Architecture.doc
Figure 8: Class diagram showing key participating classes in the FBN architecture (Zoom at 400%)
4.2 Architecture analysis and design mechanisms
By doing Architectural Analysis, Architectural Design from the given requirements, the following analysis
mechanisms and design mechanisms are identified.
Analysis Mechanism
GUI application client
GUI application client deployment
Web client application
Workflow process logic
Integration/ Messaging
E-Mail Service
Connection Pooling
Persistence
Transaction management
Secure Server systems
Transport Security
Authentication, Authorization
Confidential
Design Mechanism
Java Swing APIs
Java Web Start Architecture.
JSP, Servlets, HTML, Javascript
EJB Session Bean
J2EE container's JMS Provider will be utilized.
Messaging will be accomplished using JMS APIs
and Message Driven Beans.
JavaMail API will be used to send e-mail
notification
J2EE container's connection pool feature will be
utilized.
RDBMS data store will be used. Access to RDBMS
will be done using JDBC API.
J2EE container's transaction services will be
utilized.
The DMZ (Demiliterized Zone) configuration will
be setup.
Will be accomplished using SSL enabled server
 RDBMS realm will be created to define
users and groups
FlyByNight Inc., 2002
Page 19 of 25
FlyByNight Inc. Travel System Re-write
Version:
<0.4>
Software Architecture Document
Date: <3/3/2016>
J:\USERS\MKANPA\TECH\ARCHITECT\FlyByNight Software Architecture.doc

Authentication via GUI application client
Caching
Scalability
J2EE container will be utilized to delegate
the authentication service request.
 Roles will be defined in web, ejb
deployment descriptors.
 Login view page will be defined in web
deployment descriptor.
 Security constraints will be defined in web,
ejb deployment descriptors.
JAAS Framework. A JAAS based authentication
module will be implemented to authenticate users.
Custom Caching Facility to cache flight search
results and improve performance.
J2EE container's clustering, load balancing
capabilities will be utilized. Also having session
beans to implement workflow proessing and using
container's object pooling features will help to
improve scalability.
4.3 Architecturally Significant Design Packages
4.3.1 Architectural Layers2
This architectural pattern describes a proven approach to structuring software. This pattern promotes development
of software that is easy to extend and maintain.
Tier
Client Tier
Presentation Tier
Business Tier
Integration Tier
List of Classes shown in the class diagram
UI Application, View Handler, View. The concrete
view handlers and view components are omitted in the
class diagram intentionally for the purpose of brevity.
OnlineReservationServlet, CommandDispatcher,
DisplayCommand. The concrete Display commands and
JSPs are omitted in the class diagram intentionally for
the purpose of brevity.
OnlineReservationDelegate, OnlineReservationFacade,
ItineraryController, CustomerController,
FlightSelectionController, Flight, Itinerary, Customer
DAOs, Profile, CreditCard, Payment, Route, Span,
Segment, Equipment, Seat. The value objects are not
shown in the class diagram in order to avoid cluttering.
TransMasterServices, FrequentFlyerServices,
ReservationEventListener, MileageAccountDAO,
EAIEvent, B2BEvent
4.3.1.1 The Client Layer
This layer is responsible to represent all types of clients accessing the system or application. A client can be a web
browser, a Java or other application, a Java Applet, a WAP phone, a network application, or any other pervasive
devices.
4.3.1.2 The Presentation Layer
The Presentation Layer encapsulates the presentation logic required to service the clients that access the system.
2
Busch Mann et al.
Confidential
FlyByNight Inc., 2002
Page 20 of 25
FlyByNight Inc. Travel System Re-write
Version:
<0.4>
Software Architecture Document
Date: <3/3/2016>
J:\USERS\MKANPA\TECH\ARCHITECT\FlyByNight Software Architecture.doc
This layer will contain the web components such as Servlets and JSPs.
4.3.1.3 The Business Layer
This layer contains the business data and business logic. All business processing for the application is centralized
into this layer.
4.3.1.4 The Integration Layer
This layer is responsible for communicating with external resources and systems such as data stores and legacy
applications. The business objects in the Business Layer will access data or services that reside in the Resource
Layer using the components in this layer. The components in this layer can use JDBC, J2EE Connector technology,
or some proprietary middleware to work with the Resource Layer.
4.3.2 Architectural Patterns
Architecture comprises frameworks, patterns, standards, guidelines, and libraries. Hence, in this section we will
document the architectural patterns used to build FBN travel system.
4.3.2.1 Layered Architecture
Layered architecture refers to partitioning the system into a number of layers by placing them on top of one another
such that services of layer n+1 consist mostly of the services provided by layer n or a combination of sub layers.
Within the same layer, all components work at the same level of abstraction or the same functionality.
4.3.2.2 MVC Architecture
MVC stands for Model-View-Controller. The responsibilities of each are described below.
Model
 Encapsulates application state
 Notifies view of state changes
 Responds to state queries
 Generates B2B events
View
 Forwards user requests to control
 Allows control to choose next view
 Query application state
 Renders GUI
Control
 One for each functionality
 Updates application model
 Determines next view
 Defines B2C application behavior
4.3.3 Design Patterns
The current iteration of FBN architecture uses the following design patterns. These patterns help to verify and
validate if the defined architecture meet the given non-functional requirements. Please refer to 1.4.5 in the
References section, the Core J2EE Patterns for details on each of the pattern listed below. In future iterations, a
separate Design guidelines document will be compiled to include information on how the use of these patterns help
to meet the quality attributes of defined architecture such as modularity, re-usability, extensibility, interoperability,
consistency,



Front Controller
View Helper
Service-to-Worker
Confidential
FlyByNight Inc., 2002
Page 21 of 25
FlyByNight Inc. Travel System Re-write
Version:
<0.4>
Software Architecture Document
Date: <3/3/2016>
J:\USERS\MKANPA\TECH\ARCHITECT\FlyByNight Software Architecture.doc









Business Delegate
Service Locator
Command
Controller
Coarse Grained Entity
Value object
Integration Adapter
DAO
Factory Method
5. Deployment View
The following diagram shows a proposed deployment model for the FBN travel system. The nodes such as
Firewalls, Load balancer, proxy server(s) are assumed to be currently existing.. This deployment model utilizes the
DMZ setup to protect system from potential attackers. The web clients (Internet users) will use HTTPS protocol and
the application clients (Intranet users) will use RMI-IIOP protocol to communicate with FBN travel system.
Figure 9: FBN Travel System Deployment model (Zoom to 200%)
6. Implementation View
This section describes the overall structure of the implementation model, the decomposition of the software
into layers and subsystems in the implementation model, and any architecturally significant components.
Confidential
FlyByNight Inc., 2002
Page 22 of 25
FlyByNight Inc. Travel System Re-write
Version:
<0.4>
Software Architecture Document
Date: <3/3/2016>
J:\USERS\MKANPA\TECH\ARCHITECT\FlyByNight Software Architecture.doc
Figure 10: FBN Travel System Component Diagram
7. Quality
In this section, we will validate how the use of selected patterns for the FBN architecture helps to meet the various
quality attributes associated with the architecture. Only select examples are listed here, documentation on complete
architecture validation is beyond the scope of this document.
Confidential
FlyByNight Inc., 2002
Page 23 of 25
FlyByNight Inc. Travel System Re-write
Version:
<0.4>
Software Architecture Document
Date: <3/3/2016>
J:\USERS\MKANPA\TECH\ARCHITECT\FlyByNight Software Architecture.doc
7.1 Modularity
Allows application functionality to be developed somewhat independently and localizes the impact of design and
implementation changes

The use of Service-to-worker and View Helper patterns improves modularity or provides improved role
separation by separating the formatting logic from the application business logic and reduces dependencies
on the same resources among individuals fulfilling different roles.
7.2 Re-usability
Leverages the domain knowledge and prior effort of experienced developers to avoid recreating and revalidating
common solutions to recurring application requirements and software design challenges.


The use of Front Controller improves reusability by promoting cleaner application partitioning. Code that
is common among components is moved into the front controller and reused for each request.
With the use of Display Command (View Helper) pattern, business logic that is factored out of JSP into
commands may be reused across numerous JSPs. The code is not duplicated in many different JSPs, and
thus is easier to maintain and debug.
7.3 Extensibility
Allows for the easy addition of new functionalities.
 For example, when new presentation tier functionality is required we can quickly create a new display
command, appropriate JSP view page and easily plug-in by registering it with the Command Dispatcher
without much impact to the existing functionality.
7.4 Performance
Performance can be measured in terms of response time for a given screen transaction per user or in transaction
throughput, which is the number of transactions in a given time period, usually one second.
Though performance can be improved at various levels such as operating system, network, java virtual machine,
application server etc., in this section we will list how the use of selected design patterns for FBN architecture could
contribute to performance improvements.
 The use of business delegate provides caching services (and better performance) to the presentation tier for
common service requests.
 The use of Session Façade improves performance by reducing network overhead between the client and the
server because all interactions are routed via the Session Façade in a coarse grained manner.
 The use of Value Object pattern improves performance by transferring the values from the business tier to
the client/presentation in one remote method call. The value object acts as a data carrier and reduces the
number of remote network methods calls required to obtain the attribute values.
 The Service Locator can cache the initial context objects and references to the factory objects to eliminate
unnecessary JNDI activity that occurs when obtaining the initial context and the other objects. This
improves the application performance.
7.5 Manageability
Manageability is the ability to manage the system to ensure the continued health of a system with respect to
scalability, reliability, availability, performance and security.
 The use of business delegate pattern reduces coupling between the presentation tier and business tier by
hiding all the business tier implementation details. It is easier to manage changes because they are
centralized in one place.
 The use of Session Façade decouples the underlying business objects and system from clients, thus
reducing the tight coupling between the two tiers and the client’s dependency on the business objects.
Inter business objects are abstracted into a workflow in a façade. This provides better manageability,
greater flexibility to cope with changes.
 Because all data access operations are delegated to the data access object, the separate data access layer can
Confidential
FlyByNight Inc., 2002
Page 24 of 25
FlyByNight Inc. Travel System Re-write
Version:
<0.4>
Software Architecture Document
Date: <3/3/2016>
J:\USERS\MKANPA\TECH\ARCHITECT\FlyByNight Software Architecture.doc
be viewed as the layer that can isolate the rest of the application from data access implementation. This
centralization makes the application easier to maintain and manage.
7.6 Security
Security is the ability to ensure that the system can’t be compromised. Security includes not only issues of
confidentiality and integrity, but also relates to Denial-of-Service (Dos) attacks that impact availability.
 The FBN travel system deployment will utilize the DMZ setup to protect from potential attackers.
 In order to utilize the J2EE Container's authentication and authorization services, a RDBMS realm will be
created in which the users and groups are defined.
 As per the pre-conditions stated in the use-cases, any view pages participating in the use-cases Change
Itinerary, Price Itinerary, Pay for Itinerary will be configured as a ‘protected resource’ in web deployment
descriptor.
 A login view page (JSP) and authentication error page (JSP) will be created and configured using web
deployment descriptor. Whenever a protected resource is accessed, if the user is not logged in, it will
present the configured login view page to the user.
 Two roles will be defined for the actors ‘Travel Agent’ and ‘Customer’.
 All customer interaction will be secured using SSL and accessing the application URL using HTTP
protocol will be prevented.
 As shown in the use-case model diagram, users belonging to both travel agent and customer roles will be
permitted to access all of the business functionality. Access to web resources will be granted to Customer
role (using web deployment descriptor) and access to EJB resources will be granted to both Customer and
Travel Agent roles (using EJB deployment descriptor – declarative security).
 In addition to declarative security, we will require programmatic security to allow users belonging to travel
agent be able to access any customer’s reservation, while users belonging to customer role can only access
their own profile and itineraries.
 The application client (client tier) during its startup will register itself with Security Facility 3 framework.
This Security Facility checks to see if it is protected application and if so check if the user is authenticated
to use this application. If not authenticated, the Authentication Facility framework will be used to
authenticate the user using JAAS based implementation of authentication module.
8. Conclusion
The document defined the FBN architecture to meet given requirements for Sun Certified Enterprise Architect
project assignment. More importantly as the architecture is defined using best software engineering practices with
the use of architectural patterns and design patterns, it can be easily understood and validated. The architecture is
represented using use-case view, logical view, deployment view and implementation view to show how the defined
architecture is used to realize (or design/implement) the given functional requirements.
3
For the purpose of brevity, the Security Facility and Authentication Facility framework is mentioned, but not detailed in this
document.
Confidential
FlyByNight Inc., 2002
Page 25 of 25