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

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.

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

3.4 Class Diagram - JSP JSP

3.4 Class Diagram - Platform JMS Mail API Serial API

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

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

7. Inter-Process Communication & Synchronization 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

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 email notifications.

Thank You !

Back-up Slides