Presentation is loading. Please wait.

Presentation is loading. Please wait.

CS 501: Software Engineering Fall 2000 Lecture 14 System Architecture I Data Intensive Systems.

Similar presentations


Presentation on theme: "CS 501: Software Engineering Fall 2000 Lecture 14 System Architecture I Data Intensive Systems."— Presentation transcript:

1 CS 501: Software Engineering Fall 2000 Lecture 14 System Architecture I Data Intensive Systems

2 2 Administration Midterm examination, October 16, 7:30 to 8:30 p.m. -- Hollister B14 (note change of room) -- See course notices for sample questions

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

4 4 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)

5 5 Example 1: Electricity Utility Billing First attempt: Data input Master file Transaction Bill Each transaction handled as it arrives.

6 6 Criticisms of First Attempt Where is this first attempt weak? The requirements have not been specified!!!

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

8 8 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

9 9 Batch Processing: Validation Data input Master file Edit & validation read only errors Validated transactions Incoming transactions

10 10 Batch Processing: Master File Update Master file update Bills Validated transactions in batches Sort by account errors Reports Instructions

11 11 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

12 12 Online Inquiry Data input Master file Transactions Bills read only Customer service

13 13 Example 2: A Small-town Stockbroker Transactions Received by mail or over telephone For immediate or later action Complex customer inquiries Highly competitive market

14 14 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)

15 15 Database Architecture Customer & account database Products & services database External services

16 16 Real-time Transaction Customer & account database Products & services database External services Real-time transactions

17 17 Real-time Transactions & Batch Processing Customer & account database Products & services database External services Real-time transactions Batch processing Data input

18 18 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?

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

20 20 Merger of Two Banks: Options ??? A B

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

22 22 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

23 23 Network Choices Public Internet: Ubiquitous -- worldwide Low cost Private network: Security Predictable performance Choice of protocols (e.g., IBM's SNA)

24 24 Quality of Network Services Performance Maximum throughput Variations in throughput Real-time media (e.g., audio) Business Suppliers Trouble shooting and maintenance Upgrades

25 25 Firewall Public network Private 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


Download ppt "CS 501: Software Engineering Fall 2000 Lecture 14 System Architecture I Data Intensive Systems."

Similar presentations


Ads by Google