1. Online Stock Trading System
Members of Team 5
Insan Wijaya Tjiam
Shi Lei
Tan Boon Tham
Wu Xue Song
Xu Jun
Zang Yan

2. Contents 1. 2. 3. 4. 5. 6. 7. 8. Introduction Software Architecture
System Overview 3.
Use Case Realization 4.
Fulfillment of Real Time Requirements 5.
External Interfacing 6.
Inter-Process Communication & Synchronization 7.
Design Patterns 8.

3. 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).

4. 1.1 Use Cases

5. 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

6. 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

7. 2. Software Architecture

8. 2.1 Network Diagram

9. 3.1 System Components

10. 3.2 Deployment Diagram

11. 3.3 Data Flow Diagram – Overall System

12. 3.3 Data Flow Diagrams – System Components

13. 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

14. 3.4 Class Diagram - DTO
DTO

15. 3.4 Class Diagram - DAO
DAO

16. 3.4 Class Diagram - EJB
EJB

17. 3.4 Class Diagram - EJB
EJB

18. 3.4 Class Diagram – Web Action

19. 3.4 Class Diagram - JSP
JSP

20. 3.4 Class Diagram - Platform
JMS
Mail API
Serial API

21. 4. Use Case Realization Show one use case here View Stock Information
View Stock History
Force Live Data Retrieval
Periodic Live Data Retrieval
Retrieve Live Stock Info
Setup
Retrieval

22. 4. Use Case Realization - View Stock Info

23. 4. Use Case Realization - View Stock History

24. 4. Use Case Realization - Force Live Data Retrieval

25. 4. Use Case Realization - Periodic Live Data Retrieval

26. 4. Use Case Realization - Retrieve Live Stock Info

27. 4. Use Case Realization - Retrieve Live Stock Info

28. 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
server can handle much more than s 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

29. 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
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.

30. 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) =
ρ^20 = E-8
With a queue of depth 20, there will be almost no data loss, and the response time is less than 1 second

31. 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) =
ρ^20 = E-8
With a queue of depth 20, there will be almost no data loss, and the response time is less than 1 second

32. 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 = E-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
Server
Based on the assumption that it can handle s per second with the size of the notification s, it will be able to support the worst case 2000 notifications at the same time

33. 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 = E-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.

34. 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) =
ρ^20 = E-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.

35. 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.

36. 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 Server
SMTP protocol
Java Mail API
Interface to Banks

37. 6. External Interfacing - TWS

38. 7. Inter-Process Communication & Synchronization
Java Remote Method Invocation
Java Messaging Service
Inter-Process Synchronization
Managed by JEE container
Interface to TWS, using semaphores

39. 7. Inter-Process Communication & Synchronization - RMI

40. 8. Design Patterns MVC model 3-tier model Singleton Factory Method
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 notifications.

41. Thank You !

42. Back-up Slides