Software Engineering of
Distributed Systems
University of Colorado
Boulder
ECEN5053
bring up www.cdk4.net before starting Tegrity in class
2
August 28, 2006
University of Colorado ECEN5053 SW Eng of Distributed
Systems Week 1 Intro
Course Logistics








3
Introductions
http://webct.colorado.edu
Format
Calendar – this year, Fall Break is merged into
Thanksgiving week – no classes 11/20-11/24/2006
Final Exam, Monday December 18, 1:30-4 p.m.
Homework – see web site
Contact information – [email protected]
303-492-8369 (CU office), ECEE 1B67
Text web site: www.cdk4.net -- see key pts.
August 28, 2006
University of Colorado ECEN5053 SW Eng of Distributed
Systems Week 1 Intro
Outline







4
Definitions
Software Engineering issues
Purposes
Demands/challenges
Hardware concepts
Software concepts
An example model
August 28, 2006
University of Colorado ECEN5053 SW Eng of Distributed
Systems Week 1 Intro
Definition of a Distributed System


5
A distributed system is a collection of independent
computers that appears to its users as a single
coherent system.
Andrew Tanenbaum
A distributed system is one in which components
located at networked computers communicate and
coordinate their actions only by passing
messages.
Coulouris et al (your text)
 concurrency of components’ execution
 lack of a global clock
 independent failures of components
August 28, 2006
University of Colorado ECEN5053 SW Eng of Distributed
Systems Week 1 Intro
Alternative definition of a distributed system

6
“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
August 28, 2006
University of Colorado ECEN5053 SW Eng of Distributed
Systems Week 1 Intro
Implied characteristics?
“appears to its users as a single coherent system” –
what must be true for that to be true?
7
August 28, 2006
University of Colorado ECEN5053 SW Eng of Distributed
Systems Week 1 Intro
Examples?


8
internet
and what else?
August 28, 2006
University of Colorado ECEN5053 SW Eng of Distributed
Systems Week 1 Intro
Why is this hard?




9
Hardware tends to smaller, faster, more reliable,
cheaper, more predictable to develop and innovate
Concurrent, networked, distributed software has
grown larger, slower, more error-prone, very
expensive and time-consuming to develop, validate,
maintain, enhance
Some low-level sw optimizations are no longer
needed thanks to new hardware
Lifecycle cost continues to rise
August 28, 2006
University of Colorado ECEN5053 SW Eng of Distributed
Systems Week 1 Intro
Software is hard

Inherent complexities
 fundamental domain challenges


Accidental complexities
 Limitations of software tools
 Limitations of development techniques


10
partial failure, distributed deadlock, end-to-end
QoS
non-portable APIs, poor distributed debuggers
Deliberate choices of developers who favor lowlevel languages and tools that don’t scale well
August 28, 2006
University of Colorado ECEN5053 SW Eng of Distributed
Systems Week 1 Intro
Software is hard - 2

11
Inadequate methods and techniques
 Popular software analysis methods and design
techniques have focused largely on
constructing single-process, single-threaded
applications
 Development of high-quality concurrent,
networked, distributed systems with stringent
QoS requirements are left to intuition and
expertise of skilled sw architects and engineers.
 Hard to learn – trial & error, platform-specific
August 28, 2006
University of Colorado ECEN5053 SW Eng of Distributed
Systems Week 1 Intro
Software is hard - 3


Continuous re-invention and re-discovery
 “The software industry has a long history of
recreating in compatible solutions to problems
that are already solved.”
 Dozens of non-standard general-purpose and
real-time o.s.’s managing the same hw resources
 Dozens of incompatible o.s. encapsulation
libraries providing slightly different APIs to
implement essentially the same features and
services
Starting to shift to recognizing value of patterns but
there are fewer available for concurrent, networked,
& distributed systems
12
August 28, 2006
University of Colorado ECEN5053 SW Eng of Distributed
Systems Week 1 Intro
Necessary Developments

Take an historical view
 1945 - 1985
Computers are large & expensive
 Most organizations had only a few
 lacked a way to connect them
 operated independently from one another

By mid-80’s ... powerful microprocessors with
power of a then-contemporary mainframe
 High speed networks!
Result: Easy to combine large numbers of
computers via a high-speed network.


13
August 28, 2006
University of Colorado ECEN5053 SW Eng of Distributed
Systems Week 1 Intro
Purposes -- what problem is solved?


Easily connect users to remote resources
Share resources with remote users in a controlled
way
 Hide the fact that the resources are physically
distributed over a network -- transparency
 Should be an open system


Should be scalable

14
Offers services by standard rules that describe
the syntax and semantics of those services
size, geography, and administration
August 28, 2006
University of Colorado ECEN5053 SW Eng of Distributed
Systems Week 1 Intro
Access and sharing remotely


15
Why share?
 economy
 ease of collaboration -- virtual organizations
 ease of info exchange
 commerce
Connectivity and sharing lead to security issues
 Currently, inadequate protection
August 28, 2006
University of Colorado ECEN5053 SW Eng of Distributed
Systems Week 1 Intro
Transparency Types
Transparency
Access
Description -- Hide:
Location
differences in data representation & how
resource is accessed
where a resource is located
Migration
that a resource may move locations
Relocation
that a resource may be moved while in use
Replication
that a resource is replicated
Concurrency
that a resource may be shared by competitors
Failure
failure and recovery of a resource
Persistence
whether a sw resource is in memory or on disk
16
August 28, 2006
University of Colorado ECEN5053 SW Eng of Distributed
Systems Week 1 Intro
Degree of Transparency



17
Hiding all distribution aspects not always good idea
 Some times desirable to remain fixed
 Messages between processes that are thousands
of miles apart will take hundreds of milliseconds
Trade-off between high degree of transparency and
performance -- why?
The degree of desirable transparency should be
considered in context with other issues such as
performance and cost
August 28, 2006
University of Colorado ECEN5053 SW Eng of Distributed
Systems Week 1 Intro
Openness



Offers services according to standard rules
describing syntax and semantics of the services.
Rules are formalized in protocols
Services generally specified through interfaces
 using Interface Definition Language (IDL)




18
specify syntax only
natural language used to describe semantics
allows arbitrary process that needs an interface
to talk to another process that provides it
proper interfaces are complete and neutral
August 28, 2006
University of Colorado ECEN5053 SW Eng of Distributed
Systems Week 1 Intro
Goals of Openness


Interoperability and portability
 completeness and neutrality are prerequisites
Flexible
 easy to configure the system out of different
components from different developers
 easy to add new components without impact
 easy to replace existing ones without impact
 i.e. extensible
easier said than done
19
August 28, 2006
University of Colorado ECEN5053 SW Eng of Distributed
Systems Week 1 Intro
Flexibility -- Policy and Mechanism




20
System must be organized as a collection of
relatively small and easily replaceable or
adaptable components
Need for change: component does not provide
optimal policy for a specific user or app
Example: differing caching policies
Need to be able to separate policy & mechanism
August 28, 2006
University of Colorado ECEN5053 SW Eng of Distributed
Systems Week 1 Intro
Scability Challenges -- Size

Size
 Limitations of centralized services, data, and
algorithms -- become bottleneck


21
Unlimited processing power and storage cannot
overcome communication limitations
Decentralization introduces some kinds of
uncertainty
August 28, 2006
University of Colorado ECEN5053 SW Eng of Distributed
Systems Week 1 Intro
Scalability Challenges -- Geographic



22
Existing distributed systems designed for LANs are
based on synchronous communication
Communication in WANs is inherently unreliable and
almost always point-to-point
 LANs provide reliable comm based on
broadcasting -- WAN needs special location svces
Centralized components prevent geographic scale
August 28, 2006
University of Colorado ECEN5053 SW Eng of Distributed
Systems Week 1 Intro
Scalability Challenges -Administrative


How to scale across multiple independent
administrative domains
Conflicting policies
 usage (payment)
 management
 security
protect against malice from the new domains
 protect against malice from the distributed
system -- e.g. downloaded programs

23
August 28, 2006
University of Colorado ECEN5053 SW Eng of Distributed
Systems Week 1 Intro
Scaling Techniques

Scalability problems appear as performance ones
 hide communication latencies
avoid waiting for responses as much as possible
 i.e. construct the requestor to use
asynchronous comm as much as possible
 reduce overall communication



distribution -- spreading component parts
across the system, e.g. DNS (see next slide)
replication across the distributed system
increases availability (helps hide latency)
 helps balance the load between components

24
August 28, 2006
University of Colorado ECEN5053 SW Eng of Distributed
Systems Week 1 Intro
Dividing DNS name space into zones
Generic
int
com
edu
Countries
gov
colorado
mil
org
...
Z1
Z2
Z3
cs ece ...
25
August 28, 2006
University of Colorado ECEN5053 SW Eng of Distributed
Systems Week 1 Intro
Outline






26
Definition
Purposes
Demands/challenges
Hardware concepts
Software concepts
An example model
August 28, 2006
University of Colorado ECEN5053 SW Eng of Distributed
Systems Week 1 Intro
Hardware Concepts

Introduction to how distributed systems can be
organized
 how they are interconnected
 how they communicate
Memory
Private
bus-based
Shared
Private
switch-based switch-based
27
August 28, 2006
Interconnection
Shared
bus-based
University of Colorado ECEN5053 SW Eng of Distributed
Systems Week 1 Intro
Shared Memory & Private Memory

Multiprocessors (not multicomputers)
 Single physical address space shared by all CPUs
CPU A writes 37 to address 1000
 CPU B then reads from address 1000 and gets 37
 e.g., multiple processors on a board with shared
memory


Multicomputers
 Every machine has its own private memory
CPU A writes 37 to its address 1000
 CPU B reads from its address 1000 and gets
whatever happens to be there; not affected by the
other write
 e.g., PCs connected by a network

28
August 28, 2006
University of Colorado ECEN5053 SW Eng of Distributed
Systems Week 1 Intro
Bus-based & Switch-based


29
Bus architecture of the interconnection network
 single network, backplane, bus, cable or other
medium that connects all the machines
 e.g., cable television
Switched architecture
 Msgs move along wires with an explicit
switching decision made at each step to route
the message along one of the outgoing wires.
 e.g., worldwide public telephone system
August 28, 2006
University of Colorado ECEN5053 SW Eng of Distributed
Systems Week 1 Intro
Performance Impacts--bus, shared memory

Bus-based multiprocessor, shared memory
 Coherent memory
 Bus contention
 If cache memory for each CPU has a high hit
rate, bus traffic drops dramatically
but introduces serious problem -- what is it?
 Caching and memory coherence is an issue for
distributed systems


30
Limited scalability
August 28, 2006
University of Colorado ECEN5053 SW Eng of Distributed
Systems Week 1 Intro
Performance impacts -





1. Switched, shared memory
2. Not quite shared memory
3. Homogeneous multicomputers, each with own
memory
4. Processors connected thru shared multiaccess
network such as Fast Ethernet (private memory, busbased network)
5. Private memory, switch-based network (massively
parallel processors, clusters of workstations)
6. and ...
31
August 28, 2006
University of Colorado ECEN5053 SW Eng of Distributed
Systems Week 1 Intro
Performance impacts heterogeneous multicomputer systems





32
Most distributed systems are these
Computers are heterogeneous w.r.t. processor type,
memory size, I/O bandwidth, etc.
Interconnection networks can be heterogeneous, too
Many large-scale heterogeneous multicomputers lack a
global system view
 cannot assume same performance or services are
available everywhere
THEREFORE sophisticated software is needed
 shield application developers from what is going on at
hardware level (transparency)
August 28, 2006
University of Colorado ECEN5053 SW Eng of Distributed
Systems Week 1 Intro
Software Concepts

33
Distributed systems software
 Acts as resource manager(s) for the
underlying hardware
 Hide intricacies and heterogeneity of
underlying hardware
 The issues that this software faces are the
core of distributed systems principles we will
study this semester
August 28, 2006
University of Colorado ECEN5053 SW Eng of Distributed
Systems Week 1 Intro
When is a distributed system
not a distributed system?



Distributed operating system:
 Not intended to handle a collection of independent
computers
Network operating system:
 Does not provide a view of a single coherent
system
“true” distributed system
 Goal: scalability and openness of network o.s. and
transparency and ease of use of distributed o.s.
 Additional layer called middleware
34
August 28, 2006
University of Colorado ECEN5053 SW Eng of Distributed
Systems Week 1 Intro
Various middleware models (paradigms)


35
A particular paradigm is a set of decisions about
how to describe distribution and communication
 Distributed file systems
 Remote procedure calls
 Distributed objects
 Distributed documents
See table
August 28, 2006
University of Colorado ECEN5053 SW Eng of Distributed
Systems Week 1 Intro
Sample Paradigms
Paradigm
Distributed
file system
Distribution
Communication
Dist. xparency supp’d
for traditional files
Remote
proc calls
Network xparency allows
process to call procedure
on remote machine
meth. invocation: interface
implementation on process’
mach. translates invoc into
msg sent to remote object;
reply msg --> return value
Distributed
objects
Distributed
documents
36
Info org’d as docs;
each doc somewhere
in the world
University of Colorado ECEN5053 SW Eng of Distributed
August 28, 2006
Systems Week 1 Intro
Each paradigm must address these issues:







37
Communication
Processes & synchronization
Processes & process interaction
Naming
Consistency and replication
Fault tolerance
Security
August 28, 2006
University of Colorado ECEN5053 SW Eng of Distributed
Systems Week 1 Intro
Software Engineering of Distributed Systems





38
Requirements specification of these issues in
distributed systems -- how to recognize
Architecture patterns – respected proven solutions
Design -- how to choose and represent
Implementation
Testing -- static and dynamic
August 28, 2006
University of Colorado ECEN5053 SW Eng of Distributed
Systems Week 1 Intro
Descargar

Software Engineering of Distributed Systems