Architecture.doc - Google Code

mexicanmorningData Management

Dec 16, 2012 (4 years and 8 months ago)

166 views

University of Victoria

Faculty of Engineering

Spring 2007 SENG 426






Architecture Document

Day Trading Inc.


Version 1.0

Wednesday, March 28, 2007














Group 2

Paul Crawford

Patrick McKnight

Darren Stone

Jim Zhang

Archit
ecture Document

SENG 462 Group 2

Monday, March 18, 2013

1

of
10

1.

Ov
erview


1.1

Purpose


The purpose of this document is to describe the architecture used by Group2 in designing
and prototyping the Day Trading Inc Day Trading System.


1.2

Design Overview


1.2.1

Goals


The goals of the Day Trading prototype are as stated in the requireme
nts:

• Minimum transaction processing times.

• Full support for required features.

• Reliability and maintainability of the system.

• High availability and fault recoverability (i.e. proper use of fault tolerance)

• Minimal costs (development, hardware
, maintenance, etc.)

• Clean design that is easily understandable and maintainable.

• Appropriate security

• A clean web
-
client interface.


In addition to these high level system goals Group2 the goal of delivering the best
prototype system performance
in reference to all competing prototype systems.


1.2.2

Constraints


Group2 has identified the following constraints with the system design and
implementation.

Database server: Due to the limited access to the database server Group2 has identified
this as a con
straint on the design. This server has been identified as a lower performance
computer, and also has limited diagnostic access.



Architecture Document

SENG 462 Group 2

Monday, March 18, 2013

2

of
10



1.2.3

Assumptions


Database server s considered inflexible.

Due to the constraint related to the database server (in terms of the

prototype
implementation) all design decisions have been made to make use of the currently
available database resources. Some speculative statements may be made to suggest
improvements to the system related to changes to the database server, but none hav
e been
implemented.


Architecture Overview


The primary components of the system are the
Web Client
,
Web Server
,
Transaction
Server
,
Database Server
,
Trigger
,
Engine
, and
Quote Server
. As per the requirements, the
system will interface with the single leg
acy quote server and single PostgreSQL database.

The
Web Client

is a standard web browser able to accept cookies, which are used for sto
r-
ing the ID of the user’s session on the transaction server. The
Web Server

is essentially
stateless and is responsib
le for generating the user interface for the user and passing r
e-
quests to the transaction server. The
Transaction Server

manages all aspects of the user’s
session and negotiates transactions with the database server. The
Database Server

s
e
cur
e-
ly commits t
ransactions to the dat
a
base and maintains an audit log.

Figures 1 and 2 provide a simplified and detailed model of the system, respectively, ind
i-
cating the relationships between the primary components in the sy
s
tem.

Archit
ecture Document

SENG 462 Group 2

Monday, March 18, 2013

3

of
10


Figure 1
-

Simplified System Model



Architecture Document

SENG 462 Group 2

Monday, March 18, 2013

4

of
10


2.

Design Approach

3.

Components

2.1.

Transac
tion Server

The
Transaction Server

is responsible for managing all data pertaining to a user's session.
Multiple transaction servers may exist, however, one user session is only associated with a
single
Transaction Server

instance at any given time.
Sess
ions

are opened by the
Web
Server

or
Trigger Engine
, and remain active until either they are closed explicitly by the
client, or after a period of inactivity. A user account can have only one session active at
any given time, and, with the exception of th
e
Trigger Engine
, sessions cannot be shared
between multiple cl
i
ents.


Figure 2
-

System Model


Archit
ecture Document

SENG 462 Group 2

Monday, March 18, 2013

5

of
10

The
Transaction Server

is the only component in the system that communicates directly
with the
Database Server
. When a user logs in to the system a
session

is created on the
Transaction

Server

and all pertinent data relating to the user, including balance and
owned stocks, is read from the database and cached in local
Transaction Server

memory.
From this point, the
Transaction Server

will only send data to the
Database Server

as
transac
tions are executed. The
Transaction Server

keeps track of all pending sell and buy
orders without hitting the dat
a
base.

2.2.

Trigger Engine

The
Trigger Engine

component is responsible for executing all buy and sell triggers in the
system. Each trigger consist
s of a user ID, stock name, price, and buy/sell flag. The
Tri
g-
ger Engine

communicates directly with the
Quote Server

to monitor stock prices. When a
buy or sell is triggered, the
Trigger Engine

passes the purchase order to the
Transaction
Server

for proc
essing. The
Trigger Server

must either attach to an existing session (if the
user is already logged in) or create a new session to execute the transaction. This session
negotiation is performed through the
Transaction Server Manager
.

2.3.

Database Server

The
Database Server

provides an interface through which the
Transaction Server

can read
and write to the database. It provides atomic methods for buying stock, selling stock, and
adding funds to an account. These methods return a
Receipt

and confirmation numb
er
upon successful completion.

To commit a transaction, the
Transaction Server

sends a
Purchase Order

object to the
D
a-
tabase Server

for processing, along with a unique confirmation number. Upon a succes
s-
ful commit, the
Database Server

will return a
Receip
t

object containing a copy of the
Pu
r-
chase

Order

and the confirmation number, which is returned to the user. If the
Database
Server

fails to commit the transaction due to a timeout or other error, the
Transaction

Server

will issue a cancel command the
Dat
abase Server
, indicating that the transaction
associated with the given confirmation number is no longer valid. If the transaction was
written to the d
a
tabase, the
Database Server

will undo the transaction.

The
Database Server

maintains a fixed pool of da
tabase connections and worker threads.
Transactions are queued as they are received, and passed along to worker threads as they
become available.

2.4.

Transaction Server Manager (Load Balancing and Fail
-
over)

The
Transaction Server Manager

(TSM) is responsible

for balancing sessions between mu
l-
tiple
Transaction Servers
. The TSM knows about all active sessions and users in the sy
s-
tem, as well as which sessions belong to which
Transaction Server

instances. When a
Web
Server

initiates a connection to a
Transacti
on Server
, it first contacts the TSM to find out
which
Transaction Server

owns the session, and then connects to the correct
Transa
c
tion
Server
. The TSM also periodically polls each
Transaction Server

to measure load and ver
i-
fy the health of the server.
It may use this information to periodically re
-
balance the load
by r
e
voking sessions from one server and transferring them to another.

Architecture Document

SENG 462 Group 2

Monday, March 18, 2013

6

of
10

2.5.

Web Server

The
Web Server

is responsible for construction the user interface for HTTP clients. The
Web Server

is complet
ely stateless, except for the session ID which is stored in a cookie on
the user's browser. This allows simple load balancing b
e
tween multiple
Web Servers
.

Commands are issued by the client using standard HTTP POST commands. The
Web
Server

will return d
ata in one of two formats based on a flag specified by the client. By d
e-
fault, the
Web Server

outputs a standard HTML user interface to allow the system to be
used from a web browser. For the automated test client, the
Web Server

will return sp
e-
cially fo
rmatted XML data instead of a standard user interface. This allows to the test cl
i-
ent to read the status of all commands issued to the
Web Server
.

2.6.

Caching Quote Server

The
Caching Quote Server

(CQS) provides an interface to the legacy quote server. The
C
QS caches all quotes for one minute. Data returned from the CQS includes all data pr
o-
vided by the legacy quote server, including, stock symbol, price, time stamp, security key,
and user name. As well, the quote includes a time
-
to
-
live parameter that indi
cates how
long the quote is valid for. A quote will be valid for one minute or less, depending on
how long it has been cached.

Archit
ecture Document

SENG 462 Group 2

Monday, March 18, 2013

7

of
10

3.

Data Structures

Figure 3 describes the basic data structures that are used throughout to pass data between
difference component
s of the
system.

UserInfo

contains the basic i
n-
formation about the user and
session, and provides enough
information to allow the
Web
Server

to render the basic user
interface, including balance,
pending transactions, and cu
r-
rently owned stocks.

StockRec
ord

is used for r
e-
cording a stock purchase.

PurchaseOrder

is used for r
e-
cording pending transactions
as well as executing transa
c-
tions.

Receipt

is generated by the
Database Server

upon succes
s-
ful transaction, and is ult
i-
mat
e
ly returned to the user for
thei
r own record kee
p
ing.

Quote

encapsulates all data
returned from the legacy quote
server, as well as the amount
of time for which the quote is
valid.

Figure 3
-

Data Structures



Architecture Document

SENG 462 Group 2

Monday, March 18, 2013

8

of
10

4.

Technology

The system will use JBoss to facilitate the load balancing, fail over, communication, and
confi
guration of the distributed system. All components of the system prototype will be
implemented as Enterprise Java Beans. The Web Server is implemented as a Java Servlet
and will use JSP to render the user interface for the web clients. The Database Serv
er will
communicate with the PostgreSQL dat
a
base using JDBC.

The prototype may utilise RMI
-
IIOP for communication between components, which is
CORBA compatible and would allow certian components of the system to be re
-
implemented natively in C or C++ to p
rovide further performance i
m
provements.

The prototype will be developed and hosted on i386 Linux machines, exception for the d
a-
tabase server which is hosted on a single legacy Solaris box.