Transcript Objektorienteret Netværkskommunikation (ITONK1)

Objektorienteret Netværkskommunikation
Presentation 2:
Distributed Systems – A brush up, and
relations to Middleware, Heterogeneity
& Transparency
Agenda
• Motivation: This time, and next time, we will be discussing
the theoretical framework for middleware and distributed
systems. This will help us to categorize the specific
technologies into a taxonomy, and establish a common
vocabulary for the subject
• This time we will discuss
– Definition: What is a Distributed System?
• We need to have the same definition in mind
– Distributed Systems Characteristics
– Examples of Distributed Systems
• We will extract requirements from these
– Distributed System Requirements & Concepts
• We shall use these requirements to point out relevant concepts
– Transparency in Distributed System (levels of)
Slide 2 af 21
Ingeniørhøjskolen i Århus
What is a Distributed System
• Plenum: What is your definition?
Slide 3 af 21
Ingeniørhøjskolen i Århus
What is a Distributed System?
• “You know you have one when the crash of a
computer you’ve never heard of stops you from
getting any work done.” - Leslie Lamport, 1987
Slide 4 af 21
Ingeniørhøjskolen i Århus
What is a Distributed System?
• A collection of (perhaps) heterogeneous nodes
connected by one or more interconnection
networks which provides access to system-side
shared resources and services.
• A collection of independent computers that
appears to its users as a single coherent system.
- Angela Demke Brown
Slide 5 af 21
Ingeniørhøjskolen i Århus
What is a Distributed System?
• A distributed system is a collection of autonomous
hosts (computers) 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)
We will use this definition in ONK
Slide 6 af 21
Ingeniørhøjskolen i Århus
What is a Distributed System?
Component1
Componentn Applikation
API
Middleware
Network Operating System
Platform
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
System appears as one entity to the user
Slide 7 af 21
Ingeniørhøjskolen i Århus
Middleware Examples
- Transaction-oriented - Procedural
-IBM CICS
-Sun ONC
-BEA Tuxedo
-Linux RPCs
- Microsoft
-OSF DCE
Transaction Server
-(SOAP)
- Message-oriented
-Microsoft Message
Queue
- NCR TopEnd
-Sun Tooltalk
- Object-oriented
-OMG CORBA
-Sun Java RMI / EJB
-.NET Remoting
-Microsoft COM
-(SOAP)
Slide 8 af 21
Ingeniørhøjskolen i Århus
Why distributed object technology?
• Exploiting advantages of object technology for new
development (the OO Paradigm)
– Appropriate level of abstraction (“low representational gap”,
polymorphism, decoupling, other OO)
– Extensibility and manageability is optimal
– (termed “openness” in the following)
• Preserving investment by wrapping legacy applications
– Both COBOL, C, C++ and Java is supported “out of the box” by
e.g. CORBA, and there are Visual Basic support as well
– Easy to “wrap” legacy code and integrate with new components
• Resolving
– distribution
– heterogeneity
Slide 9 af 21
Ingeniørhøjskolen i Århus
Common Requirements
• What are we trying to achieve when we construct
a distributed system?
• Certain requirements are common to many
distributed systems (Emmerich, 2000)
–
–
–
–
–
–
Resource Sharing
Openness & Heterogeneity
Concurrency
Scalability
Fault Tolerance
Transparency
Slide 10 af 21
Ingeniørhøjskolen i Århus
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.
Slide 11 af 21
Ingeniørhøjskolen i Århus
Openness & Heterogeneity
• Openness is concerned with extensions and
improvements of distributed systems
– Most projects requires systems to be easily extendible and
maintainable, this means the architecture must be “open”
– OO Paradigm is renowned for its openness as is component
models – you are already experts
– OO middleware thus strives to support openness by birth
• Heterogeneity is about supporting several hardware and
software platforms
– Some middleware strives to support heterogeneity, but not in all
areas
– Differences in data representation of interface types on different
processors (of different vendors) have to be resolved (e.g. UNIX vs
Windows)
– Heterogeneity is a key concept to remember
Slide 12 af 21
Ingeniørhøjskolen i Århus
Openness & Heterogeneity
• The vision – everything works with everything
C
Ada
Java
C++
Web service
CORBA
Mac OS/X
UNIX
Perl
C#
Java
Delphi
.NET Remoting
Java RMI
Windows NT
LINUX
• Reality: highly improbable scenario
Slide 13 af 21
Ingeniørhøjskolen i Århus
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
• This also holds true in non-distributed systems (using
threads & processes), but here we often have more
simulations users
– > greater risk of concurrency problems
Slide 14 af 21
Ingeniørhøjskolen i Århus
Scalability
• Adaption of distributed systems to
– accomodate more users
– respond faster
– Usually done in centralized systems by adding more
and/or faster processors
– May be done by allowing several nodes to run the
same components and share the load
– Load balancing
• Components should not need to be changed
when scale of a system increases
• Design components to be scalable!
Slide 15 af 21
Ingeniørhøjskolen i Århus
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
Slide 16 af 21
Ingeniørhøjskolen i Århus
Transparency in Distributed Systems
• 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 the ANSA project (now part of an ISO standard)
– International Standard on Open Distributed Processing (OPD)
(ISO, 1996).
• These represent various properties that distributed
systems aim at achieving
– … but is only partly implemented (level of transparency)
– We shall use these as a means to measure the characteristics of
the middleware products in question
Slide 17 af 21
Ingeniørhøjskolen i Århus
Distribution Transparency
You need to learn these by heart ;)
Scalability
Transparency
Performance
Transparency
Failure
Transparency
Migration
Transparency
Replication
Transparency
Concurrency
Transparency
Access
Transparency
Location
Transparency
We may measure the characteristics of middleware technologies, on their
support for the different dimensions of transparency as shown above.
Slide 18 af 21
Ingeniørhøjskolen i Århus
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
Example: Distributed Objects
• Makes life easier for the developers
– True when making objects distributed
– There are pitfalls
Slide 19 af 21
Ingeniørhøjskolen i Århus
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
Example: Objects being moved between servers
• Integral part of replication/migration/scal. transparency
Server 1
Server 1
(with object)
Client
Program
(with object)
Hard-coded
Reference
(e.g. IP)
Client
Program
Hard-coded
Reference
(e.g. IP)
Server 2
Server 2
Name
Server
Not easy to move the object to other server
Slide 20 af 21
Ingeniørhøjskolen i Århus
Group Work
• At each table 10 minutes:
–
–
–
–
–
Discuss the remaining ANSA transparencies
What are the purpose of each
When and where are they relevant
How may they be implemented
Would you do the implementation yourself in a project?
Slide 21 af 21
Ingeniørhøjskolen i Århus