Presentation is loading. Please wait.

Presentation is loading. Please wait.

The Future of Distributed Systems .

Similar presentations

Presentation on theme: "The Future of Distributed Systems ."— Presentation transcript:

1 The Future of Distributed Systems .
Jim Gray Researcher Microsoft Corp.

2 Outline Global forces Distributed Systems Concepts and terms
Moore’s, Metcalf’s, Bell’s, Bills, Andy’s laws Micro dollars per transaction Cyber-content is key value because distribution costs go to zero Distributed Systems Concepts and terms Key software technologies objects, transactions

3 Metcalf’s Law Network Utility = Users2
How many connections can it make? 1 user: no utility 100,000 users: a few contacts 1 million users: many on Net 1 billion users: everyone on Net That is why the Internet is so “hot” Exponential benefit

4 Moore’s First Law XXX doubles every 18 months 60% increase per year
Micro processor speeds Chip density Magnetic disk density Communications bandwidth WAN bandwidth approaching LAN speeds Exponential growth: The past does not matter 10x here, 10x there, soon you’re talking REAL change PC costs decline faster than any other platform Volume and learning curves PCs will be the building bricks of all future systems 1GB 128MB 1 chip memory size ( 2 MB to 32 MB) 8MB 1MB 128KB 8KB 1970 1980 1990 2000 bits: 1K 4K 16K 64K 256K 1M 4M 16M 64M 256M

5 Bumps In The Moore’s Law Road
1 100 10000 1970 1980 1990 2000 $/MB of DRAM DRAM: 1988: United States anti-dumping rules : ?price flat Magnetic disk: : 10x/decade : 4x/3year! X/decade .01 1 100 10,000 1970 1980 1990 2000 $/MB of DISK

6 Gordon Bell’s Seven Price Tiers
10$: wrist watch computers 100$: pocket/ palm computers 1,000$: portable computers 10,000$: personal computers (desktop) 100,000$: departmental computers (closet) 1,000,000$: site computers (glass house) 10,000,000$: regional computers (glass castle) Super server: costs more than $100,000 “Mainframe”: costs more than $1 million Must be an array of processors, disks, tapes, comm ports

7 Bell’s Evolution Of Computer Classes
Technology enables two evolutionary paths: 1. constant performance, decreasing cost 2. constant price, increasing performance Mainframes (central) Minis (dep’t.) Log price WSs PCs (personals) ?? Time 1.26 = 2x/3 yrs x/decade; 1/1.26 = .8 1.6 = 4x/3 yrs --100x/decade; 1/1.6 = .62

8 Software Economics An engineer costs about $150,000/year
R&D gets [5%…15%] of budget Need [$3 million… $1 million] revenue per engineer Microsoft: $9 billion Profit 24% R&D 16% Tax 13% SG&A 34% Product and Service 13% Intel: $16 billion IBM: $72 billion Oracle: $3 billion Profit 6% Profit 15% R&D 8% R&D 9% Profit R&D 8% Tax 5% 22% Tax 7% SG&A 11% SG&A 22% Tax SG&A 12% P&S 47% P&S 59% P&S 26% 43%

9 Software Economics: Bill’s Law
Fixed_ Cost Price Marginal _Cost = + Units Bill Joy’s law (Sun): don’t write software for less than 100,000 platforms @$10 million engineering expense, $1,000 price Bill Gate’s law: don’t write software for less than 1,000,000 platforms @$10 engineering expense, $100 price Examples: UNIX versus Windows NT: $3,500 versus $500 Oracle versus SQL-Server: $100,000 versus $6,000 No spreadsheet or presentation pack on UNIX/VMS/... Commoditization of base software and hardware

10 Gordon Bell’s Platform Economics
Traditional computers: custom or semi-custom, high-tech and high-touch New computers: high-tech and no-touch 100000 10000 Price (K$) 1000 Volume (K) 100 Application price 10 1 0.1 0.01 Mainframe WS Browser Computer type

11 Grove’s Law The New Computer Industry
Horizontal integration is new structure Each layer picks best from lower layer Desktop (C/S) market 1991: 50% 1995: 75% Function Example Operation AT&T Integration EDS Applications SAP Middleware Oracle Baseware Microsoft Systems Compaq Silicon & Oxide Intel & Seagate

12 Outline Global forces Distributed Systems Concepts and terms
Moore’s, Metcalf’s, Bell’s, Bills, Andy’s laws Micro dollars per transaction Cyber-content is key value because distribution costs go to zero Distributed Systems Concepts and terms Key software technologies objects, transactions

13 1987: 256 tps Benchmark 14 M$ computer (Tandem) A dozen people
False floor, 2 rooms of machines Admin expert Hardware experts A 32 node processor array Auditor Network expert Simulate 25,600 clients Manager Performance expert OS expert DB expert A 40 GB disk array (80 drives)

14 1988: DB2 + CICS Mainframe 65 tps
IBM 4391 Simulated network of 800 clients 2m$ computer Staff of 6 to do benchmark 2 x 3725 network controllers Refrigerator-sized CPU 16 GB disk farm 4 x 8 x .5GB

15 1997: 10 years later 1 Person and 1 box = 1250 tps
1 Breadbox ~ 5x 1987 machine room 23 GB is hand-held One person does all the work Cost/tps is 1,000x less 1 micro dollar per transaction 4x200 Mhz cpu 1/2 GB DRAM 12 x 4GB disk Hardware expert OS expert Net expert DB expert App expert 3 x7 x 4GB disk arrays

16 What Happened? Moore’s law: Things get 4x better every 3 years (applies to computers, storage, and networks) New Economics: Commodity class price/mips software $/mips k$/year mainframe , minicomputer microcomputer GUI: Human - computer tradeoff optimize for people, not computers mainframe mini micro time price

17 What Happens Next ? Last 10 years: 1000x improvement
Next 10 years: ???? Today: text and image servers are free m$/hit cost 70,000m$/hit advertising revenue Advertising pays for them Content is only “real” expense “You ain’t seen nothing yet!” 1985 2005 1995 performance ?

18 Kinds Of Information Processing
Point-to-point Broadcast Lecture Concert Conversation Money Network Immediate Time- shifted Mail Book Newspaper Database It’s ALL going electronic Immediate is being stored for analysis (so ALL database) Analysis and automatic processing are being added

19 Why Put Everything In Cyberspace?
Point-to-point OR broadcast Low rent - min $/byte Shrinks time - now or later Shrinks space - here or there Automate processing - knowbots Network Immediate OR time-delayed Locate Process Analyze Summarize Database

20 Billions Of Clients Every device will be “intelligent”
Doors, rooms, cars… Computing will be ubiquitous

21 Billions Of Clients Need Millions Of Servers
All clients networked to servers May be nomadic or on-demand Fast clients want faster servers Servers provide Shared Data Control Coordination Communication Clients Mobile clients Fixed clients Servers Server Super server

22 Thesis Many little beat few big
$1 million 1 MM 3 $100 K $10 K Pico Processor Micro Nano 1 MB 10 pico-second ram Mainframe Mini 10 microsecond ram 10 millisecond disc 10 second tape archive 10 nano-second ram 10 MB 1 0 GB 1 TB 1 00 TB 2.5" 1.8" 3.5" 5.25" 1 M SPECmarks, 1TFLOP 106 clocks to bulk ram Event-horizon on chip VM reincarnated Multiprogram cache, On-Chip SMP 9" 14" Smoking, hairy golf ball How to connect the many little parts? How to program the many little parts? Fault tolerance?

23 Future Super Server: 4T Machine
Array of 1,000 4B machines 1 bps processors 1 BB DRAM 10 BB disks 1 Bbps comm lines 1 TB tape robot A few megabucks Challenge: Manageability Programmability Security Availability Scaleability Affordability As easy as a single system CPU 50 GB Disc 5 GB RAM Cyber Brick a 4B machine Future servers are CLUSTERS of processors, discs Distributed database techniques make clusters work

24 The Hardware Is In Place… And then a miracle occurs
? SNAP: scaleable network and platforms Commodity-distributed OS built on: Commodity platforms Commodity network interconnect Enables parallel applications

25 Outline Global forces Distributed Systems Concepts and terms
Moore’s, Metcalf’s, Bell’s, Bills, Andy’s laws Micro dollars per transaction Cyber-content is key value because distribution costs go to zero Distributed Systems Concepts and terms Key software technologies objects, transactions

26 Outline Concepts and Terminology
Why Distributed Distributed data & objects Distributed execution Three tier architectures Transaction concepts

27 What’s a Distributed System?
Centralized: everything in one place stand-alone PC or Mainframe Distributed: some parts remote distributed users distributed execution distributed data

28 Why Distribute? No best organization
Companies constantly swing between Centralized: focus, control, economy Decentralized: adaptive, responsive, competitive Why distribute? reflect organization or application structure empower users / producers improve service (response / availability) distributed load use PC technology (economics)

29 What Should Be Distributed?
Users and User Interface Thin client Processing Trim client Data Fat client Will discuss tradeoffs later Presentation workflow Business Objects Database

30 Transparency in Distributed Systems
Make distributed system as easy to use and manage as a centralized system Give a Single-System Image Location transparency: hide fact that object is remote hide fact that object has moved hide fact that object is partitioned or replicated Name doesn’t change if object is replicated, partitioned or moved.

31 Naming- The basics Names are context dependent: Many naming systems
Objects have Globally Unique Identifier (GUIDs) location(s) = address(es) name(s) addresses can change objects can have many names Names are context dependent: KGB not the same as CIA) Many naming systems UNC: \\node\device\dir\dir\dir\object Internet: LDAP: ldap://ldap.domain.root/o=org,c=US,cn=dir Address guid Jim James

32 Name Servers in Distributed Systems
North Name servers translate names + context to address (+ GUID) Name servers are partitioned (subtrees of name space) Name servers replicate root of name tree Name servers form a hierarchy Distributed data from hell: high read traffic high reliability & availability autonomy root Northern names South root Southern names

33 Autonomy in Distributed Systems
Owner of site (or node, or application, or database) Wants to control it If my part is working , must be able to access & manage it (reorganize, upgrade, add user,…) Autonomy is Essential Difficult to implement. Conflicts with global consistency examples: naming, authentication, admin…

34 Security The Basics Authentication server subject + Authenticator => (Yes + token) | No Security matrix: who can do what to whom Access control list is column of matrix “who” is authenticated ID In a distributed system, “who” and “what” and “whom” are distributed objects subject Object Permissions

35 Security in Distributed Systems
Security domain: nodes with a shared security server. Security domains can have trust relationships: A trusts B: A “believes” B when it says this is Security domains form a hierarchy. Delegation: passing authority to a server when A asks B to do something (e.g. print a file, read a database) B may need A’s authority Autonomy requires: each node is an authenticator each node does own security checks Internet Today: no trust among domains (fire walls, many passwords) trust based on digital signatures

36 Clusters The Ideal Distributed System.
Cluster is distributed system BUT single location manager security policy relatively homogeneous communications is high bandwidth low latency low error rate Clusters use distributed system techniques for load distribution storage execution growth fault tolerance

37 Cluster: Shared What? Shared Disk Cluster Shared Nothing Cluster
Shared Memory Multiprocessor Multiple processors, one memory all devices are local DEC or SGI or Sequent 16x nodes Shared Disk Cluster an array of nodes all shared common disks VAXcluster + Oracle Shared Nothing Cluster each device local to a node ownership may change Tandem, SP2, Wolfpack

38 Outline Concepts and Terminology
Why Distribute Distributed data & objects Partitioned Replicated Distributed execution Three tier architectures Transaction concepts

39 Partitioned Data Break file into disjoint groups
Orders Exploit data access locality Put data near consumer Less network traffic Better response time Better availability Owner controls data autonomy Spread Load data or traffic may exceed single store N.A. S.A. Europe Asia

40 How to Partition Data? How to Partition Problem: to find it must have
by attribute or random or by source or by use Problem: to find it must have Directory (replicated) or Algorithm Encourages attribute-based partitioning N.A. S.A. Europe Asia

41 Replicated Data Place fragment at many sites
Pros: Improves availability Disconnected (mobile) operation Distributes load Reads are cheaper Cons: N times more updates N times more storage Placement strategies: Dynamic: cache on demand Static: place specific Catalog

42 Updating Replicated Data
When a replica is updated, how do changes propagate? Master copy, many slave copies (SQL Server) always know the correct value (master) change propagation can be transactional as soon as possible periodic on demand Symmetric, and anytime (Access) allows mobile (disconnected) updates updates propagated ASAP, periodic, on demand non-serializable colliding updates must be reconciled. hard to know “real” value

43 Replication and Partitioning Compared
1 TPS server 100 Users Base case a 1 TPS system 2 TPS server 200 Users Scaleup to a 2 TPS centralized system Central Scaleup 2x more work Partition Scaleup 2x more work Replication Scaleup 4x more work Partitioning Two 1 TPS systems 1 TPS server 100 Users O tps Two 2 TPS systems 2 TPS server 100 Users 1 tps Replication

44 Outline Concepts and Terminology
Why Distribute Distributed data & objects Partitioned Replicated Distributed execution remote procedure call queues Three tier architectures Transaction concepts

45 Distributed Execution Threads and Messages
Thread is Execution unit (software analog of cpu+memory) Threads execute at a node Threads communicate via Shared memory (local) Messages (local and remote) shared memory messages

46 Peer-to-Peer or Client-Server
Peer-to-Peer is symmetric: Either side can send Client-server client sends requests server sends responses simple subset of peer-to-peer request response

47 Connection-less or Connected
request contains client id client context work request client authenticated on each message only a single response message e.g. HTTP, NFS v1 Connected (sessions) open - request/reply - close client authenticated once Messages arrive in order Can send many replies (e.g. FTP) Server has client context (context sensitive) e.g. Winsock and ODBC HTTP adding connections

48 Remote Procedure Call: The key to transparency
Object may be local or remote Methods on object work wherever it is. Local invocation y = pObj->f(x); f() x val y = val; return val;

49 Remote Procedure Call: The key to transparency
Remote invocation marshal un x proxy y = pObj->f(x); Obj Local? x un marshal pObj->f(x) x stub val y = val; f() return val; Obj Local? x val f() return val; val

50 Object Request Broker (ORB) Orchestrates RPC
Registers Servers Manages pools of servers Connects clients to servers Does Naming, request-level authorization, Provides transaction coordination (new feature) Old names: Transaction Processing Monitor, Web server, NetWare Transaction Object-Request Broker

51 History and Alphabet Soup
DCE RPC GUIDs IDL Kerberos DNS COM Microsoft DCOM based on OSF-DCE Technology DCOM and ActiveX extend it 1985 Solaris International UNIX OSF DCE Foundation (OSF) Open software NT X/Open 1990 Management Group (OMG) Object CORBA ODBC XA / TX 1995 Open Group

52 ActiveX and COM COM is Microsoft model, engine inside OLE ALL Microsoft software is based on COM (ActiveX) CORBA + OpenDoc is equivalent Heated debate over which is best Both share same key goals: Encapsulation: hide implementation Polymorphism: generic operations key to GUI and reuse Versioning: allow upgrades Transparency: local/remote Security: invocation can be remote Shrink-wrap: minimal inheritance Automation: easy COM now managed by the Open Group

53 Linking And Embedding Objects are data modules; transactions are execution modules
Link: pointer to object somewhere else Think URL in Internet Embed: bytes are here Objects may be active; can callback to subscribers

54 Bottom Line Re ORBs Object-Request Broker
Microsoft Promises Cairo distributed objects, secure, transparent, fast invocation Netscape promises the CORBA Both will deliver Customers can pick the best one Transaction Object-Request Broker

55 Using RPC for Transparency Partition Transparency
Send updates to correct partition send to correct partition x y = pfile->write(x); part Local? x un marshal pObj->write(x) x x val write() return val; val

56 Using RPC for Transparency Replication Transparency
Send updates to EACH node Send to each replica x y = pfile->write(x); x val

57 Outline Concepts and Terminology
Why Distributed Distributed data & objects Distributed execution remote procedure call queues Three tier architectures what why Transaction concepts

58 Client/Server Interactions All can be done with RPC
Request-Response response may be many messages Conversational server keeps client context Dispatcher three-tier: complex operation at server Queued de-couples client from server allows disconnected operation C S S C S S S C S

59 Queued Request/Response
Time-decouples client and server Three Transactions Almost real time, ASAP processing Communicate at each other’s convenience Allows mobile (disconnected) operation Disk queues survive client & server failures Submit Perform Response Client Server

60 Why Queued Processing? Prioritize requests ambulance dispatcher favors high-priority calls Manage Workflows Deferred processing in mobile apps Interface heterogeneous systems EDI, MOM: Message-Oriented-Middleware DAD: Direct Access to Data Order Build Ship Invoice Pay

61 Work Distribution Spectrum
Fat Thin Presentation and plug-ins Workflow manages session & invokes objects Business objects Database Presentation workflow Business Objects Database

62 Transaction Processing Evolution to Three Tier Intelligence migrated to clients
Mainframe cards Mainframe Batch processing (centralized) Dumb terminals & Remote Job Entry Intelligent terminals database backends Workflow Systems Object Request Brokers Application Generators green screen 3270 Server TP Monitor ORB Active

63 Web Evolution to Three Tier Intelligence migrated to clients (like TP)
Server WAIS Character-mode clients, smart servers GUI Browsers - Web file servers GUI Plugins - Web dispatchers - CGI Smart clients - Web dispatcher (ORB) pools of app servers (ISAPI, Viper) workflow scripts at client & server archie ghopher green screen Mosaic NS & IE Active

64 PC Evolution to Three Tier Intelligence migrated to server
Stand-alone PC (centralized) PC + File & print server message per I/O PC + Database server message per SQL statement PC + App server message per transaction ActiveX Client, ORB ActiveX server, Xscript IO request reply disk I/O SQL Statement Transaction

65 The Pattern: Three Tier Computing
Presentation Clients do presentation, gather input Clients do some workflow (Xscript) Clients send high-level requests to ORB (Object Request Broker) ORB dispatches workflows and business objects -- proxies for client, orchestrate flows & queues Server-side workflow scripts call on distributed business objects to execute task workflow Business Objects Database

66 The Three Tiers DCOM (oleDB, ODBC,...) Object server Pool HTTP+ DCOM
Web Client HTML VB or Java Script Engine Virt Machine VBscritpt JavaScrpt VB Java plug-ins Internet ORB HTTP+ DCOM Object server Pool Middleware TP Monitor Web Server... DCOM (oleDB, ODBC,...) Object & Data server. LU6.2 IBM Legacy Gateways

67 Why Did Everyone Go To Three-Tier?
Manageability Business rules must be with data Middleware operations tools Performance (scaleability) Server resources are precious ORB dispatches requests to server pools Technology & Physics Put UI processing near user Put shared data processing near shared data Presentation workflow Business Objects Database

68 Why Put Business Objects at Server?
Customer comes to store with list Gives list to clerk Clerk gets goods, makes invoice Customer pays clerk, gets goods Easy to manage Clerks controls access Encapsulation MOM’s Business Objects DAD’sRaw Data Customer comes to store Takes what he wants Fills out invoice Leaves money for goods Easy to build No clerks

69 What Middleware Does ORB, TP Monitor, Workflow Mgr, Web Server
Registers transaction programs workflow and business objects (DLLs) Pre-allocates server pools Provides server execution environment Dynamically checks authority (request-level security) Does parameter binding Dispatches requests to servers parameter binding load balancing Provides Queues Operator interface

70 Server Side Objects Easy Server-Side Execution
A Server ORB gives simple execution environment Object gets start invoke shutdown Everything else is automatic Drag & Drop Business Objects Network Receiver Queue Management Connections Context Security Configuration Thread Pool Service logic Synchronization Shared Data

71 A new programming paradigm
Develop object on the desktop Better yet: download them from the Net Script work flows as method invocations All on desktop Then, move work flows and objects to server(s) Gives desktop development three-tier deployment Software Cyberbricks

72 Why Server Pools? Server resources are precious. Clients have 100x more power than server. Pre-allocate everything on server preallocate memory pre-open files pre-allocate threads pre-open and authenticate clients Keep high duty-cycle on objects (re-use them) Pool threads, not one per client Classic example: TPC-C benchmark 2 processes everything pre-allocated N clients x N Servers x F files = N x N x F file opens!!! Pool of DBC links HTTP IE 7,000 clients IIS SQL

73 Classic Three-Tier Example TPC-C
7,000 Web clients Transaction Processing Performance Council (TPC): standard performance benchmarks 5 transaction types order entry , payment , status (oltp) delivery (mini-batch) restock (mini-DSS) Metrics: Throughput, Price/Performance Shows best practices: everyone three tier 2 processes at server everything pre-allocated HTTP IIS = Web Pool of DBC links ODBC SQL

74 Classic Mistakes Thread per terminal fix: DB server thread pools fix: server pools Process per request (CGI) fix: ISAPI & NSAPI DLLs fix: connection pools Many messages per operation fix: stored procedures fix: server-side objects File open per request fix: cache hot files

75 Outline Laws & micro$/transaction Distributed Systems
Why Distributed Distributed data & objects Distributed execution Three tier architectures why: manageability & performance what: server side workflows & objects Transaction concepts Why transactions? Using transactions

76 Thesis Transactions are key to structuring distributed applications
ACID properties ease exception handling Atomic: all or nothing Consistent: state transformation Isolated: no concurrency anomalies Durable: committed transaction effects persist 2

77 What Is A Transaction? Success! Failure! Programmer’s view:
Bracket a collection of actions A simple failure model Only two outcomes: Begin() action Commit() Begin() action Rollback() Begin() action Rollback() Fail ! Success! Failure! 3

78 Why Bother: Atomicity? ? ? ? RPC semantics: At most once: try one time
At least once: keep trying ’till acknowledged Exactly once: keep trying ’till acknowledged and server discards duplicate requests ? ? ? 4

79 Why Bother: Atomicity? Example: insert record in file
At most once: time-out means “maybe” At least once: retry may get “duplicate” error or retry may do second insert Exactly once: you do not have to worry What if operation involves Insert several records? Send several messages? Want ALL or NOTHING for group of actions 5

80 Why Bother: Durability
Once a transaction commits, want effects to survive failures Fault tolerance: old master-new master won’t work: Can’t do daily dumps: would lose recent work Want “continuous” dumps Redo “lost” transactions in case of failure Resend unacknowledged messages 9

81 Why ACID For Client/Server And Distributed
ACID is important for centralized systems Failures in centralized systems are simpler In distributed systems: More and more-independent failures ACID is harder to implement That makes it even MORE IMPORTANT Simple failure model Simple repair model 11

82 ACID Generalizations Taxonomy of actions
Unprotected: not undone or redone Temp files Transactional: can be undone before commit Database and message operations Real: cannot be undone Drill a hole in a piece of metal, print a check Nested transactions: subtransactions Work flow: long-lived transactions 10

83 Programming & Transactions The Application View
You Start (e.g. in TransactSQL): Begin [Distributed] Transaction <name> Perform actions Optional Save Transaction <name> Commit or Rollback You Inherit a XID Caller passes you a transaction You return or Rollback. You can Begin / Commit sub-trans. You can use save points Begin Begin RollBack Commit XID RollBack Return Return

84 Nested Transactions Going Beyond Flat Transactions
Need transactions within transactions Sub-transactions commit only if root does Only root commit is durable. Subtransactions may rollback if so, all its subtransactions rollback Parallel version of nested transactions T12 T121 T122 T123 T1 T11 T13 T112 T114 T131 T132 T133 T111 T113

85 Workflow: A Sequence of Transactions
Application transactions are multi-step order, build, ship & invoice, reconcile Each step is an ACID unit Workflow is a script describing steps Workflow systems Instantiate the scripts Drive the scripts Allow query against scripts Examples Manufacturing Work In Process (WIP) Queued processing Loan application & approval, Hospital admissions… Presentation workflow Business Objects Database

86 Workflow Scripts Workflow scripts are programs (could use VBScript or JavaScript) If step fails, compensation action handles error Events, messages, time, other steps cause step. Workflow controller drives flows fork Source join branch case loop Compensation Action Step

87 Workflow and ACID Workflow is not Atomic or Isolated
Results of a step visible to all Workflow is Consistent and Durable Each flow may take hours, weeks, months Workflow controller keeps flows moving maintains context (state) for each flow provides a query and operator interface e.g.: “what is the status of Job # 72149?”

88 ACID Objects Using ACID DBs The easy way to build transactional objects
Application uses transactional objects (objects have ACID properties) If object built on top of ACID objects, then object is ACID. Example: New, EnQueue, DeQueue on top of SQL SQL provides ACID SQL dim c as Customer dim CM as CustomerMgr ... set C = CM.get(CustID) C.credit_limit = 1000 CM.update(C, CustID) .. Business Object: Customer Business Object Mgr: CustomerMgr SQL Persistent Programming languages automate this.

89 ACID Objects From Bare Metal The Hard Way to Build Transactional Objects
Object Class is a Resource Manager (RM) Provides ACID objects from persistent storage Provides Undo (on rollback) Provides Redo (on restart or media failure) Provides Isolation for concurrent ops Microsoft SQL Server, IBM DB2, Oracle,… are Resource managers. Many more coming. Any masochist can build one

90 Outline Why Distributed Distributed data & objects
Distributed execution Three tier architectures Transaction concepts Why transactions? Using transactions programming workflow

91 References Essential Client/Server Survival Guide 2nd ed.
Orfali, Harkey & Edwards, J. Wiley, 1996 Client/Server Programming with Java and CORBA Orfali, Harkey, J Wiley, 1997 Principles of Transaction Processing Bernstein & Newcomer, Morgan Kaufmann, 1997 Transaction Processing Concepts and Techniques Gray & Reuter, Morgan Kaufmann, 1993 30


Download ppt "The Future of Distributed Systems ."

Similar presentations

Ads by Google