Distributed Systems. Outline. What is a Distributed System?

(1)

1-1 © Wolfgang Emmerich, 2000

Distributed Systems

Outline

■What is a Distributed System?

■Examples of Distributed Systems

■_{Distributed System Requirements} ■Transparency in Distributed System

(2)

1-4 © Wolfgang Emmerich, 2000 Hostn-1 Hostn Host2 Host1

What is a Distributed System?

Middleware Middleware

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

Middleware Examples

■Transaction-oriented • IBM CICS • BEA Tuxedo • IBM Encina • Microsoft Transaction Server ■Message-oriented • Microsoft Message Queue • NCR TopEnd • Sun Tooltalk ■Procedural • Sun ONC • Linux RPCs • OSF DCE ■Object-oriented • OMG CORBA • Sun Java/RMI • Microsoft COM • Sun Enterprise Java

(3)

Centralised 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}

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

(4)

Motivation

■Case Studies

• Hongkong Telecom’s Video-on-demand

• UBS IT Services Infrastructure

• Boeing’s Aircraft Configuration Management

• Managing of Football Association

■Used the principles and techniques presented in this course.

■Will provide a motivation for this course.

■_{Will provide illustrative examples}

throughout this course...

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

(5)

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)

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

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

(7)

Boeing 777 Configuration Mgmnt.

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

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

(8)

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

Why distributed object technology

■Object wrapping of COTS

■Resolution of distribution at high level of abstraction

■Resolution of heterogeneity

■Scalability

Management of Football Association

■Managing soccer leagues, national team, clubs, player transfer

■Imaginary system

■Common example that can be twisted for didactic purposes

(9)

Requirements

■Autonomy of clubs

• Every club operates its own administration,

training/game scheduling.

■Need for integration in order to

• register players with the football association.

• book players for national team games.

• agree to schedule of league games.

■Heterogeneity

• different machines

• different programming languages

Distributed System Requirements

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

(10)

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-29 © 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.

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.

(11)

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

Scalability

■Adaption of distributed systems to

• accomodate 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!}

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

(12)

Transparency in Distributed Systems

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.

1-36 © Wolfgang Emmerich, 2000 Access Transparency Location Transparency Concurrency Transparency Migration Transparency Performance Transparency Scalability Transparency Replication Transparency Failure Transparency

Distribution Transparency

(13)

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

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

Concurrency Transparency

■Enables serveral processes to operate concurrently using shared information objects without interference between them.

■Example: NFS

■Example: Automatic teller machine network

(14)

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.

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

Migration Transparency

■Allows the movement of information objects within a system without affecting the operations of users or application programs

■Example: NFS

(15)

Performance Transparency

■Allows the system to be reconfigured to improve performance as loads vary.

■Example: Distributed make.

Scaling Transparency

■Allows the system and applications to expand in scale without change to the system structure or the application algortithms.

■Example: World-Wide-Web

■Example: Distributed Database

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