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