Overview of System Architecture and Data Intensive Systems - Midterm Preparation Guide
This guide outlines key concepts from Lecture 14 on System Architecture and Data Intensive Systems, as part of the Software Engineering course (CS 501, Fall 2000). The midterm exam is scheduled for October 16, from 7:30 to 8:30 p.m. in Hollister B14 (note the change of room). It includes critical topics such as system design, databases, security, and operations. Key examples of data-intensive systems like customer billing and stock brokerage are discussed, including transaction processing and batch updating methodologies. Review course notices for sample questions and further details.
Overview of System Architecture and Data Intensive Systems - Midterm Preparation Guide
E N D
Presentation Transcript
CS 501: Software EngineeringFall 2000 Lecture 14 System Architecture I Data Intensive Systems
Administration Midterm examination, October 16, 7:30 to 8:30 p.m. -- Hollister B14 (note change of room) -- See course notices for sample questions
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: Bill Master file Transaction Data input Each transaction handled as it arrives.
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
Batch Processing: Validation errors Edit & validation Incoming transactions Validated transactions Data input read only Master file
Batch Processing: Master File Update Reports errors Validated transactions in batches Sort by account Bills Master file update 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
Online Inquiry Customer service read only Bills Master file Transactions Data input
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 External services Customer & account database
Real-time Transaction Real-time transactions Products & services database External services Customer & account database
Real-time Transactions & Batch Processing Data input Real-time transactions Batch processing Products & services database External services Customer & account database
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?
Example: Merger of Two Banks Each bank has a database with its customer accounts. The databases are used by staff at many branches and for back-office processing. The requirement is to integrate the two banks so that they appear to the customers to be a single organization and to provide integrated service from all branches.
Merger of Two Banks: Options A B ??? ???
Merger of Two Banks: Architectural Options I. Convert everything to System A. convert databases retrain staff enhance System A (software and hardware) discard System B II. Build an interface between the databases in System A and System B. III. Extend client software so that it can interact with either System A or System B database.
Distributed Computing: General Problem An application that is running on one computer wishes to use data or services provided by another: • Network connection private, public, or virtual private network location of firewalls • Protocols point-to-point, multicast, broadcast message passing, RPC, distributed objects stateful or stateless • Quality of service
Network Choices Public Internet: Ubiquitous -- worldwide Low cost Private network: Security Predictable performance Choice of protocols (e.g., IBM's SNA)
Quality of Network Services Performance Maximum throughput Variations in throughput Real-time media (e.g., audio) Business Suppliers Trouble shooting and maintenance Upgrades
Firewall Private network Public network Firewall A firewall is a computer at the junction of two network segments that: • Inspects every packet that attempts to cross the boundary • Rejects any packet that does not satisfy certain criteria, e.g., an incoming request to open a TCP connection an unknown packet type
