Introduction - London South Bank University

Download Report

Transcript Introduction - London South Bank University

ECI-M-811 Distributed Systems and
Internetworking
Coordinator: Dr. Zhanfang Zhao
Office: T409
Tel: 020 7815 6340
Fax: 020 7815 7051
Email: [email protected]
URL:
http://ecce3.sbu.ac.uk/staff/zhaoza/dsi/
Blackboard: http://blackboard.lsbu.ac.uk/
Textbooks
Core reading:
– ‘Distributed Systems: Principles and Paradigms
Tanenbaum AS. Prentice Hall 2002.
Background reading:
– ‘Distributed Systems: Concept and Design’
Coulouris G etc, Addison Wesley, 2001.
Topics
•
•
•
•
•
•
Introduction to DS
Communication in DS
Process in DS
Naming System in DS
Synchronization in DS
New technologies
Outcomes (Distributed System Part)
At the end of this unit the student will be able to:
• Familiar with the concepts of distributed systems
hardware and distributed system facilities.
• Able to appreciate the capabilities and
limitations of applications software running over
local and wide area networks.
• Able to understand, design and implement
simple client-server systems.
• Able to know how the World Wide Web system
works
Introduction to Distributed System
Contents of this lesson:
• Definition of the Distributed System
• The Goals when Building a
Distributed System
• Basic Software Concepts
• The Middleware
• System Architecture & Client-Server
Model
Definition of a Distributed System (1)
A distributed system is:
A collection of independent computers that appears
to its users as a single coherent system. --Tanenbaum
Two aspects of this definition:
• Hardware: The machines are autonomous.
• Software: The user think they are dealing with a single system.
Important characteristics of DS:
• Differences between various computers and the ways in which they communicate
are hidden from users
• Users and applications can interact with a DS in a consistent and uniform way
• Ds should also be easy to extend or scale
• To support heterogeneous computers and networks while offering a single system
view, DS is often organized in certain layers called middleware
Definition of a Distributed System (2)
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.
-----------Wolfgang Emmerich, 2000
Definition of a Distributed System (3)
Component1
Componentn
Middleware
Network Operating System
Hardware
Component1
Componentn
Middleware
Network Operating System
Hardware
Hostn-1
Host2
Component1
Componentn
Middleware
Network Operating System
Hardware
Host1
Network
Component1
Componentn
Middleware
Network Operating System
Hardware
Hostn
Middleware Examples
Transaction-oriented
–
–
–
–
IBM CICS
BEA Tuxedo
IBM Encina
Microsoft Transaction
Server
Message-oriented
– Microsoft Message
Queue
– Sun Tooltalk
Procedural
– Sun ONC
– Linux RPCs
– OSF DCE
Object-oriented
– OMG CORBA
– Sun Java/RMI
– Microsoft COM
.net Remote
– Sun Enterprise Java Beans
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
Goals
•
Four important goals should be met to
make it worth to build a distributed
systems:
1.
2.
3.
4.
Connecting users and resources
Transparency
Openness
Scalability
Transparency in a Distributed System
Transparency
Description
Access
Hide differences in data representation and how a
resource is accessed
Location
Hide where a resource is located
Migration
Hide that a resource may move to another location
Relocation
Hide that a resource may be moved to another
location while in use
Replication
Hide that a resource may be replicated
Concurrency
Hide that a resource may be shared by several
competitive users
Failure
Hide the failure and recovery of a resource
Persistence
Hide whether a (software) resource is in memory or
on disk
Different forms of transparency in a distributed system.
Definition: A DS that is able to present itself to users and applications as if it
were only a single computer system is said to be transparent
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
• These represent various properties that
distributed systems should have.
Distribution Transparency
Scalability
Transparency
Performance
Transparency
Failure
Transparency
Migration
Transparency
Replication
Transparency
Concurrency
Transparency
Access
Transparency
Location
Transparency
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 several processes to operate
concurrently using shared information
objects without interference between
them.
• Example: Automatic teller machine
network
• Example: Database management system
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
• Example: Web Pages
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
algorithms.
• Example: World-Wide-Web
• Example: Distributed Database
Openness
• An open distributed system is a system that offers
services according to standard rules that describe the
syntax and semantics of those services.
• Openness means that the system can easily be extended
and modified.
• To facilitate the openness, the system should have a well
defined and well-documented interfaces. These interface
must declare the services that a component offers. And
these interfaces are often described in an Interface
Define Language (IDL)
• A service is an operation that a component performs on
behalf of a user or another component.
• The interface definition should be complete and neutral.
– Complete means that everything that is necessary to make an
implementation has indeed been specified.
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!
Scalability Problems
Concept
Example
Centralized services
A single server for all users
Centralized data
A single on-line telephone book
Centralized algorithms
Doing routing based on complete information
Examples of scalability limitations.
Software Concepts
System
Description
Main Goal
DOS
Tightly-coupled operating system for multiprocessors and homogeneous
multicomputers
Hide and manage
hardware
resources
NOS
Loosely-coupled operating system for
heterogeneous multicomputers (LAN and
WAN)
Offer local
services to remote
clients
Middleware
Additional layer atop of NOS implementing
general-purpose services
Provide
distribution
transparency
An overview between
• DOS (Distributed Operating Systems)
• NOS (Network Operating Systems)
• Middleware
Uniprocessor Operating Systems
Separating applications from operating
system code through a microkernel.
1.11
Multiprocessor Operating Systems (1)
•An important extension
of MOS is that it supports
multiple processors
having access to a shared
memory. These data in the
shared memory must be
protected against the
concurrent access to
guarantee consistency.
•Two synchronized
primitives are used, one is
semaphore, another is
monitor
monitor Counter {
private:
int count = 0;
public:
int value() { return count;}
void incr () { count = count + 1;}
void decr() { count = count – 1;}
}
A monitor to protect an integer
against concurrent access.
Multiprocessor Operating Systems (2)
monitor Counter {
private:
void decr() {
int count = 0;
if (count ==0) {
int blocked_procs = 0;
blocked_procs = blocked_procs + 1;
condition unblocked;
wait (unblocked);
public:
blocked_procs = blocked_procs – 1;
int value () { return count;}
}
void incr () {
else
if (blocked_procs == 0)
count = count + 1;
else
count = count – 1;
}
}
signal (unblocked);
}
A monitor to protect an integer against concurrent
access, but blocking a process.
Multicomputer Operating Systems (1)
1.14
General structure of a multicomputer operating system
Multicomputer Operating Systems (2)
Alternatives for blocking and buffering in message passing.
1.15
Network Operating System (1)
General structure of a network operating system.
1-19
Network Operating System (2)
Two clients and a server in a network operating system.
File systems is supported by one or more machines called
file servers
1-20
Positioning Middleware
General structure of a distributed system as middleware.
1-22
Middleware and Openness
1.23
In an open middleware-based distributed system, the protocols
used by each middleware layer should be the same, as well
as the interfaces they offer to applications.
System Architecture & Client Server Model
Important styles of architecture for
distributed systems
• Layered architectures
• Object-based architectures
• Data-centered architectures
• Event-based architectures
Architectural Styles (1)
The layered architectural style and …
Architectural Styles (2)
The object-based architectural style.
Architectural Styles (3)
The event-based architectural style ( Publish/Subscribe System)
Architectural Styles (4)
The shared data-space architectural style.
Clients and Servers
1.25
General interaction between a client and a server.
• In the basic client server model, the process in a computing system are
divided into two groups. A server is a process implementing a specific
service, for example database service. A client is a process that
requests a service from a server by sending it a request and
subsequently waiting or the server’s reply
An Example Client and Server (1)
Used for parameters
The header.h file used by the client and server.
An Example Client and Server (2)
A sample server.
An Example Client and Server (3)
1-27 b
A client using the server to copy a file.
Application Layering
For the web applications, the CS applications generally
been organized into three levels:
1-28
Multitiered Architectures (1)
Alternative client-server organizations (a) – (e).
1-29
Multitiered Architectures (2)
An example of a server acting as a client.
1-30
Modern Architectures
An example of horizontal distribution of a Web service.
1-31
Distributed System Paradigms
World Wide Web Architecture Model:
• Traditional Web-based Systems
– Overall organization
– Web Documents
– Programming Languages: HTML, XML &
MIME (Multipurpose Internet Mail
Exchange)
– Multi-tiered Architectures
• Web Services
Traditional Web-Based Systems
Figure 12-1. The overall organization
of a
traditional Web site.
Web Documents
Six top-level MIME types and some common subtypes.
Multitiered Architectures
The principle of using server-side CGI
programs.
Web Services Fundamentals
The principle of a Web service:
•
•
•
WSDL (Web Services Definition Language) is a formal language very much
the same as the interface definition languages of RPC
SOAP ( Simple Object Access Protocol) is essentially a framework in which
much of the communication between two process can be standardized
UDDI ( Universal Description, Discovery and Integration)