Transcript 4. Use Case Realization

Online Stock Trading System
Members of Team 5
Insan Wijaya Tjiam
Shi Lei
Tan Boon Tham
Wu Xue Song
Xu Jun
Zang Yan
LOGO
Contents
1.
Introduction
2.
Software Architecture
3.
System Overview
4.
Use Case Realization
5.
Fulfillment of Real Time Requirements
6.
External Interfacing
7.
Inter-Process Communication & Synchronization
8.
Design Patterns
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 here
View 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