LOGO
Online Stock Trading System
Members of Team 5Insan Wijaya Tjiam
Shi Lei
Tan Boon Tham
Wu Xue Song
Xu Jun
Zang Yan
Contents
Introduction1.
Software Architecture2.
System Overview3.
Use Case Realization4.
Fulfillment of Real Time Requirements5.
External Interfacing6.
Inter-Process Communication & Synchronization7.
Design Patterns8.
1. Introduction
The Stock Trading System is a real time web application which allow investors to do transaction of Stock in Singapore
This system will be a Java based web application Trading are done through an electronic broker
“Interactive Brokers”, who provides APIs via which can write custom applications to link with their TWS (Trader Workstation Software).
1.1 Use Cases
2. Software Architecture
The Online Stock Trading (OST) system is a J2EE Web based system: 3-tier enterprise system Presentation tier using Struts framework Business tier using EJB 3.0 Data tier using Hibernate
2. Software Architecture
Selection of platform Enterprise Java was selected to build this web-based distributed system
due to its comprehensive services Normal Java system has some limitations on meeting strict real time
constraints• Java doesn't support true priority in thread. This is because Java tried to avoid
use of platform native APIs (e.g. Windows), which are needed for such support.• Due to the lack of priority, there is no support for priority inheritance.• Effect of garbage collection affects the determinism of the system response
Java Community has developed the Real-Time Specification for Java (RTSJ). This specification has addressed the above issues with new JVM
Unfortunately, we cannot use RTSJ• There are no implementation for RTSJ on JEE so far• The current RTSJ approach on memory management doesn't fit in into the JEE
context since it doesn't allow class unloading Given the distributed nature of the system topology, the bottle neck for the
real time performance of the system is unlikely the JVM For our application, the real time requirement is much softer (between soft
real time and firm real time). • We don't really need priority based scheduling• Workaround for Garbage Collection - Instead of waiting for low memory threshold
to be hit to start calling garbage collector, the system nodes will force a garbage collection process periodically
2. Software Architecture
2.1 Network Diagram
3.1 System Components
3.2 Deployment Diagram
3.3 Data Flow Diagram – Overall System
3.3 Data Flow Diagrams – System Components
3.4 Class Diagrams
Data Transfer Objects Data Access Objects Enterprise Java Beans Struts Web Actions Java Servlet Pages Java Platform Objects
Java Messaging Service Java Mail API Java Communications API
3.4 Class Diagram - DTO
DTO
3.4 Class Diagram - DAO
DAO
3.4 Class Diagram - EJB
EJB
3.4 Class Diagram - EJB
EJB
3.4 Class Diagram – Web Action
Web Action
3.4 Class Diagram - JSP
JSP
3.4 Class Diagram - Platform
JMS
Mail API
Serial API
4. Use Case Realization
Show one use case hereView Stock Information
View Stock Info View Stock History Force Live Data Retrieval Periodic Live Data Retrieval Retrieve Live Stock Info
• Setup
• Retrieval
4. Use Case Realization - View Stock Info
4. Use Case Realization - View Stock History
4. Use Case Realization - Force Live Data Retrieval
4. Use Case Realization - Periodic Live Data Retrieval
4. Use Case Realization - Retrieve Live Stock Info
4. Use Case Realization - Retrieve Live Stock Info
5. Fulfillment of Real Time Requirements
Real Time Requirements Summary 200 concurrent users 5-sec response time
Assumptions Typical web user issues less than 4 requests per second Typically there will be less than 10 database access per
user per second Price trigger notification text can be fit into one standard
SMS with max 160 byte data TWS platform has worst case response time of 1 second Email server can handle much more than 2000 emails per
second Database server can support 500 concurrent users, and
can handle 5000 operations per second. It has worst case response time of 1 second
5. Fulfillment of Real Time Requirements
Time budget Web tier - 1 second Business tier - 1 second Data tier - 1 second Queuing for TWS - 1 second TWS response time - 1 second GSM Modem Manager - 1 second Email Server - 1 second
With the above allocation, any transaction for the use cases will not involve more than 5 items above, and hence will not exceed the 5 second response time limit.
5. Fulfillment of Real Time Requirements
Web Tier Maximum 4 requests per second per user, 200 concurrent
users will generate 800 requests The web server farm entry point can handle 2000 requests
per second With 10 boxes in the farm, each supporting 200 requests
per second, the total is 2000 request per second ρ = 800/2000 = 0.4 L = 1/2000/(1-0.4) = 0.00083 ρ^20 = 1.0995E-8 With a queue of depth 20, there will be almost no data
loss, and the response time is less than 1 second
5. Fulfillment of Real Time Requirements
Business Tier Maximum 4 requests per second per user passed from
web tier, 200 concurrent users will generate 800 requests The application server farm entry point can handle 2000
requests per second With 10 boxes in the farm, each supporting 200 requests
per second, the total is 2000 request per second ρ = 800/2000 = 0.4 L = 1/2000/(1-0.4) = 0.00083 ρ^20 = 1.0995E-8 With a queue of depth 20, there will be almost no data
loss, and the response time is less than 1 second
5. Fulfillment of Real Time Requirements
Data Tier With maximum 10 database access per second per user
passed from web tier, 200 concurrent users will generate 2000 access
The database server can handle 5000 access per second ρ = 2000/5000 = 0.4 ρ^20 = 1.0995E-8 With a queue of depth 20, there will be almost no data loss Database server worst case response time is assumed to
be 1 second Email Server
Based on the assumption that it can handle 2000 emails per second with the size of the notification emails, it will be able to support the worst case 2000 notifications at the same time
5. Fulfillment of Real Time Requirements
GSM Modem Time required for Telco to deliver the SMS is out of our control
and is not considered as part of the time budget, so only queuing delay is considered.
Each modem can exceed transmitting speed of 100Kb per second. With 4 modems in the pool, the total process rate is 400Kb per second.
The entry point can handle even more data at 1Mb per second With maximum 10 price triggers per user, 200 concurrent user
will generate 2000 triggers. At worst case scenario, all of these trigger are met, and the total data to transmit per second is 160byte*10*200 = 320Kb
ρ = 2000/2500 = 0.8 L = 1/2500/(1-0.8) = 0.002 ρ^64 = 6.2771E-7 With a buffer of 10Mb (64 SMS messages with size 160b) for
each modem, there will be almost no data loss, and the response time is less than 1 second.
5. Fulfillment of Real Time Requirements
Queuing for TWS Based on TWS specification, each connection can transmit
50 messages per second With 10 connections in the socket pool, total amount of
messages per second is 500 With 200 concurrent users, assuming every user
issued requests to TWS, there will be 200 messages to be sent
ρ = 200/500 = 0.4 L = 1/500/(1-0.4) = 0.00333 ρ^20 = 1.0995E-8 With a queue of depth at least 20 for the 2 Message Driven
Beans managing the interface to TWS, there will be almost no data loss, and the queuing time is less than 1 second.
5. Fulfillment of Real Time Requirements
Periodic Timers Periodic live stock data retrieval timer Periodic price trigger checking timer
These 2 periodic timers are implemented as EJB timers. Started by the context listener at web server starting time
Based on the update sequence of the TWS platform and the amount of tasks to perform at each time out, the period of these 2 periodic timers are set as 1 minute,
This time timer value could be fine tuned later on based on system load.
6. External Interfacing
Interface to TWS Platform Interface defined by TWS Via sockets and callbacks
Interface to GSM Modem Physical connection – RS232 AT commands over Java serial port API
Interface to Email Server SMTP protocol Java Mail API
Interface to Banks
6. External Interfacing - TWS
TWS
7. Inter-Process Communication & Synchronization
Inter-Process Communication Java Remote Method Invocation Java Messaging Service
Inter-Process Synchronization Managed by JEE container Interface to TWS, using semaphores
7. Inter-Process Communication & Synchronization - RMI
RMI
8. Design Patterns
MVC model The system adopted a Model View Controller model. The model is the data
access layer, the view is the presentation layer and the controller is the business layer.
3-tier model The system used a standard 3-tier JEE structure: Web-tier, Business-tier
and Data-tier. Singleton
A few components in the system are modeled as singleton, such as DAO Factory, Socket Pool and SMS Dispatcher.
Factory Method The factory method pattern is used to get instance of the DAOs. This
pattern can be upgraded to Abstract Factory if more than one database implementations are preferred.
Facade A few EJBs acts as facade to the data tier. The same bean manages an
aspect of a usecase, and is the entry point of all related DAO access. Strategy
The notification for price triggers can make use of the strategy pattern to support both SMS and email notifications.
LOGO
Back-up Slides