Transcript System Architecture

CS 501: Software Engineering
Fall 1999
Lecture 10
System Architecture I
Data Intensive Systems
Administration
Project Interim Report:
Due October 14
Bouncing Ball Diagrams
Example: http://www.cs.cornell.edu/
domain
name
TCP
connection
HTTP get
Client
Servers
System Architecture
The overall design of a system:






Computers and networks (e.g., monolithic, distributed)
Interfaces and protocols (e.g., http, CORBA)
Databases (e.g., relational, distributed)
Security (e.g., smart card authentication, SSL)
Operations (e.g., backup, archiving, audit trails)
Software environments (e.g., languages, source control tools)
Data Intensive Systems
Examples
 Electricity utility customer billing
 Telephone company call recording and billing
 Car rental reservations (e.g., Hertz)
 Stock market brokerage (e.g., Charles Schwab)
 Web sales (e.g., Amazon.com)
Example 1: Electricity Utility Billing
First attempt:
Transactions
Data input
Master file
Each transaction handled as it arrives.
Bills
Criticisms of First Attempt
Where is this first attempt weak?
The requirements have not been specified!!!
Transaction Types








Create account / close account
Meter reading
Payment received
Other credits / debits
Check cleared / check bounced
Account query
Correction of error
etc., etc., etc.,
Typical Requirements
 All payments to be credited on day received
 Customers must be able to query account by telephone
 Cutting off service for non-payment requires
management authorization
 Data input staff should process n transactions per day
per person
 Error rate must be below 0.01%
 System available 99.9% of business hours
Online Inquiry
Customer
service
read only
Transactions
Data input
Master file
Bills
Batch Processing: Validation
errors
Edit &
validation
Incoming
transactions
Data input
read only
Master file
Validated
transactions
Batch Processing: Master File Update
Validated
transactions
in batches
errors
Reports
Sort by
account
Master file
update
Bills
Instructions
Benefits of Batch Updating
 All transactions for an account are processed together
 Backup and recovery have fixed checkpoints
 Better management control of operations
 Efficient use of staff and hardware
Example 2: A Small-town Stockbroker
 Transactions
Received by mail or over telephone
For immediate or later action
 Complex customer inquiries
 Highly competitive market
A Database Architecture
Database(s):
 Customer and account database
 Financial products (e.g., account types, pension plans,
savings schemes)
 External databases (e.g., stock markets, mutual funds,
insurance companies)
Database Architecture
Products &
services database
Customer &
account database
External
services
Real-time Transaction
Real-time
transactions
Products &
services database
Customer &
account database
External
services
Real-time Transactions & Batch
Processing
Real-time
transactions
Products &
services database
Data
input
Batch
processing
Customer &
account database
External
services
Architectural considerations
 Real-time service during scheduled hours + batch
processing overnight
 Combine information from several databases
 Database consistency after any type of failure
two-phase commit
reload from checkpoint + log
detailed audit trail
 How will transaction errors be avoided?
 How will transaction errors be corrected?