Upload
others
View
3
Download
0
Embed Size (px)
Citation preview
1
1-1 © Wolfgang Emmerich, 2000
Distributed Systems
1-2 © Wolfgang Emmerich, 2000
Outline
What is a Distributed System? Examples of Distributed Systems Distributed System Requirements Transparency in Distributed System
1-3 © Wolfgang Emmerich, 2000
What is a Distributed System?
2
1-4 © Wolfgang Emmerich, 2000
Hostn-1
Hostn
Host2
Host1
What is a Distributed System?
Middleware Middleware
Middleware Middleware
Network Operating System Network Operating System
Network Operating System Network Operating System
Hardware Hardware
Hardware Hardware
Component1 Componentn Component1 Componentn
Component1 Componentn Component1 Componentn
Network
1-5 © Wolfgang Emmerich, 2000
What is a Distributed System?
A distributed system is a collection of autonomous hosts that that are connected through a computer network. Each host executes components and operates a distribution middleware, which enables the components to coordinate their activities in such a way that users perceive the system as a single, integrated computing facility.
1-6 © Wolfgang Emmerich, 2000
Middleware Examples
Transaction-oriented • IBM CICS • Microsoft Transaction
Server Message-oriented • Microsoft Message
Queue • JMS • Sun Tooltalk
Space-based • JavaSpaces
Procedural • Sun ONC • Linux RPCs • OSF DCE
Object-oriented • OMG CORBA • Java /RMI • Microsoft COM • Enterprise Java Beans • Web services
3
1-7 © Wolfgang Emmerich, 2000
Centralized System Characteristics
One component with non-autonomous parts
Component shared by users all the time All resources accessible Software runs in a single process Single Point of control Single Point of failure
1-8 © Wolfgang Emmerich, 2000
Distributed System Characteristics
Multiple autonomous components Components are not shared by all users Resources may not be accessible Software runs in concurrent processes on
different processors Multiple Points of control Multiple Points of failure
1-9 © Wolfgang Emmerich, 2000
Examples of Distributed Systems
4
1-10 © Wolfgang Emmerich, 2000
Motivation
Case Studies • Hongkong Telecom’s Video-on-demand • UBS IT Services Infrastructure • Boeing’s Aircraft Configuration Management
Used the principles and techniques presented in this course.
Will provide a motivation for this course. Will provide illustrative examples
throughout this course...
1-11 © Wolfgang Emmerich, 2000
Hongkong Telecom Video on demand
Aim: provide subscribers with facilities to download videos from HK TK servers to low-cost Web-TVs.
currently 90,000 users. Built using distributed object-technology.
…
1-12 © Wolfgang Emmerich, 2000
Requirements
Hardware: • Clients: Web-TV • Servers: RISC processor
Operating System Heterogeneity : • Clients: Java OS • Servers: UNIX
Programming Language Heterogeneity: • Clients: Java • Servers: C++
5
1-13 © Wolfgang Emmerich, 2000
Requirements (cont’d)
Communication across Network • How to transmit complex data structures
across the Internet? Scale • Scaling from initially several hundred to
currently 90,000 users Security • Secure Payment • Authentication
1-14 © Wolfgang Emmerich, 2000
Why distributed object technology?
Distributed: • Video clients need to download/show video on
customer’s Web-TV • Multiple servers needs to be operated by
Hongkong Telecom: Object Technology: • Video clients are written in Java: – Web-TV has Java Virtual Machine – portability to e.g. Sony Playstation, Sega-Console...
• Video servers are written in C++: – high performance
1-15 © Wolfgang Emmerich, 2000
Trading Workstation
Authorisation Services
Host Services
Customer Information
Services
Product Database Services
Marketing Services
IT Infrastructure of UBS
6
1-16 © Wolfgang Emmerich, 2000
Requirements
Time to market • Development of new applications with recent
technology • Integration of new applications increasingly
difficult Scalability • Management of 30,000,000 accounts • Management of 10,000,000 customers • Use by 2,000 concurrent users
Reliability
1-17 © Wolfgang Emmerich, 2000
Requirements (cont’d)
Hardware Heterogeneity • Unisys Mainframes • IBM Mainframes • SPARC Servers • PC Workstations
Operating System Heterogeneity • MVS • UNIX • Win-NT
Programming Language Heterogeneity • Cobol • C/C++ • Visual Basic
1-18 © Wolfgang Emmerich, 2000
Why distributed object technology?
Uniform view of all banking services Appropriate level of abstraction Preserving investment by wrapping
legacy applications Exploiting advantages of object
technology for new development Resolving • distribution • heterogeneity
7
1-19 © Wolfgang Emmerich, 2000
Boeing 777 Configuration Mgmnt.
1-20 © Wolfgang Emmerich, 2000
Problems to be solved
Scale • 3,000,000 parts per aircraft • Configuration of every aircraft is different • CAA regulations demand that records are
kept for every single part of aircraft • Aircraft evolve during maintenance • Boeing produce 500 aircraft per year • Configuration database grows by 1.5 billion
parts each year • Projected life of each aircraft 30 years • 45,000 engineers need on-line access to
engineering data
1-21 © Wolfgang Emmerich, 2000
Problems to be solved (cont’d)
COTS Integration • Existing IT infrastructure was no longer
appropriate • Boeing could not afford to build required IT
infrastructure from scratch • Components were purchased from several
different specialized vendors – relational database technology – enterprise resource planning – computer aided project planning
• Components needed to be integrated
8
1-22 © Wolfgang Emmerich, 2000
Problems to be solved (cont’d)
Heterogeneity • 20 Sequent database machines as servers for
the engineering data • 200 UNIX application servers • NT and UNIX workstations for engineers
1-23 © Wolfgang Emmerich, 2000
Why distributed object technology
Object wrapping of COTS
Resolution of distribution at high level of abstraction
Resolution of heterogeneity
Scalability
1-24 © Wolfgang Emmerich, 2000
Distributed System Requirements
9
1-25 © Wolfgang Emmerich, 2000
Requirements
Integration of new, legacy and components off-the-shelf • Legacy components might not need to be re-
engineered • COTS cannot be modified
Heterogeneity of • hardware platforms • operating systems • networks • programming languages
Construction of distributed systems
1-26 © Wolfgang Emmerich, 2000
Common Requirements
What are we trying to achieve when we construct a distributed system?
Certain requirements are common to many distributed systems • Resource Sharing • Openness • Concurrency • Scalability • Fault Tolerance • Transparency
1-27 © Wolfgang Emmerich, 2000
Resource Sharing
Ability to use any hardware, software or data anywhere in the system.
Resource manager controls access, provides naming scheme and controls concurrency.
Resource sharing model (e.g. client/ server or object-based) describing how • resources are provided, • they are used and • provider and user interact with each other.
10
1-28 © Wolfgang Emmerich, 2000
Openness
Openness is concerned with extensions and improvements of distributed systems.
Detailed interfaces of components need to be published.
New components have to be integrated with existing components.
Differences in data representation of interface types on different processors (of different vendors) have to be resolved.
1-29 © Wolfgang Emmerich, 2000
Concurrency
Components in distributed systems are executed in concurrent processes.
Components access and update shared resources (e.g. variables, databases, device drivers).
Integrity of the system may be violated if concurrent updates are not coordinated. • Lost updates • Inconsistent analysis
1-30 © Wolfgang Emmerich, 2000
Scalability
Adaption of distributed systems to • accommodate more users • respond faster (this is the hard one)
Usually done by adding more and/or faster processors.
Components should not need to be changed when scale of a system increases.
Design components to be scalable!
11
1-31 © Wolfgang Emmerich, 2000
Fault Tolerance
Hardware, software and networks fail! Distributed systems must maintain
availability even at low levels of hardware/software/network reliability.
Fault tolerance is achieved by • recovery • redundancy
1-32 © Wolfgang Emmerich, 2000
Transparency in Distributed Systems
1-33 © Wolfgang Emmerich, 2000
Transparency
Distributed systems should be perceived by users and application programmers as a whole rather than as a collection of cooperating components.
Transparency has different dimensions that were identified by ANSA.
These represent various properties that distributed systems should have.
12
1-34 © Wolfgang Emmerich, 2000
Access Transparency
Location Transparency
Concurrency Transparency
Migration Transparency
Performance Transparency
Scalability Transparency
Replication Transparency
Failure Transparency
Distribution Transparency
1-35 © Wolfgang Emmerich, 2000
Access Transparency
Enables local and remote information objects to be accessed using identical operations.
Example: File system operations in NFS. Example: Navigation in the Web. Example: SQL Queries
1-36 © Wolfgang Emmerich, 2000
Location Transparency
Enables information objects to be accessed without knowledge of their location.
Example: File system operations in NFS Example: Pages in the Web Example: Tables in distributed databases
13
1-37 © Wolfgang Emmerich, 2000
Concurrency Transparency
Enables several processes to operate concurrently using shared information objects without interference between them.
Example: NFS Example: Automatic teller machine
network Example: Database management system
1-38 © Wolfgang Emmerich, 2000
Replication Transparency
Enables multiple instances of information objects to be used to increase reliability and performance without knowledge of the replicas by users or application programs
Example: Distributed DBMS Example: Mirroring Web Pages.
1-39 © Wolfgang Emmerich, 2000
Failure Transparency
Enables the concealment of faults Allows users and applications to
complete their tasks despite the failure of other components.
Example: Database Management System
14
1-40 © Wolfgang Emmerich, 2000
Migration Transparency
Allows the movement of information objects within a system without affecting the operations of users or application programs
Example: NFS Example: Web Pages
1-41 © Wolfgang Emmerich, 2000
Performance Transparency
Allows the system to be reconfigured to improve performance as loads vary.
Example: e-commerce Example: Google
1-42 © Wolfgang Emmerich, 2000
Scaling Transparency
Allows the system and applications to expand in scale without change to the system structure or the application algorithms.
Example: World-Wide-Web Example: Distributed Database
15
1-43 © Wolfgang Emmerich, 2000
Key Points
What is a Distributed Systems Adoption of Distributed Systems is driven
by Non-Functional Requirements Distribution needs to be transparent to
users and application designers Transparency has several dimensions Transparency dimensions depend on
each other