Download open - SICS

Introduction to Distributed
Programming
Per Brand
Introduction
• Global distributed computing needs an infra structure.
• The Internet provides the first steps towards a global distributed
applications:
– a global namespace (URLs)
– a global communications protocol (TCP/IP).
• Platforms such as Java and CORBA that take advantage of this
infrastructure have become widely-used.
• Distributed programming is still difficult.
• Writing efficient, open, and robust distributed applications remains
much harder than writing centralized applications.
• Making them secure increases the difficulty by another quantum leap.
What are the properties of global
distributed systems?
• A distributed system is set of
processes, linked by a network
• No global information, no global time
• Unpredictable communication delays
• Concurrency and nondeterminism
• Large probability of localized faults
• Easy access by unauthorized users
Additional Properties of the Internet
• A global network that is
partitioned into several
protection domains
(Firewalls)
• Private sub networks with
multiple reassignment of IP
addresses across networks
• Dynamic reassignment of IP
addresses -- ISP’s reuse a
pool of IP addresses among
customers
The issues in distributed programming
Classical problems of
software engineering,
code reuse, maintainability,
etc. are all here
Distribution
Security
Openness
Functionality
Resource Control
Fault tolerance
Scalability
Part of problem
Interaction
Distributed Programming
• Centralized programming
– difficult enough
– research & development for 50 years
– still ongoing
• Distributed programming
– in general much more difficult
– why??
Adding/changing distribution
Distribution
Security E.g. new security
considerations
Openness
Functionality
E.g. RMI -semantics
Resource Control
Fault tolerance
E.g. new kinds of
failure
Scalability
Adding/changing distribution -2
Distribution
Security
Openness
Functionality
Resource Control
Fault tolerance
E.g. recovery changes
Scalability
Adding/changing distribution -3
Distribution
Security
E.g. security in
recovery
Openness
Functionality
E.g. functional operations
on entities mixed with
error-recovery
Resource Control
Fault tolerance
Scalability
E.g. persistence/error
recovery consume
resources
Adding/changing distribution -4
E.g. further
subdivision of tasks
Distribution
Security
Openness
Functionality
Largest problem:
Keeping needing to
come
back here
Resource Control
Fault tolerance
Scalability
Adding/incrementing openness
Example: allow users to share with
their buddies - programs, games,
virtual community
Distribution
Security
E.g. more potential
security problems
Openness
Functionality
Resource Control
E.g. resource use
more unpredictable
Fault tolerance
E.g. more kinds
of failure
Scalability
Adding/incrementing openness - 2
Distribution
E.g. resource control
code mixed with functional
code
Functionality
Security
Openness
Resource Control
Fault tolerance
E.g. resource overuse
new kinds of faults
Scalability E.g. resource control
consumes resources
Levels of Difficulty-1
• Client-Server Applications
– Most Internet Applications still of this type
– Client/server interface very limited and
controlled
• http
• forms
– Little fault-tolerance beyond classical
database transactions on server-side
– In the controlled server environment,
issues of openness, security, and resourcecontrol hardly apply
– Fixed and simple distribution
– Scalability an issue so if you can’t buy a
bigger server then ...
Distribution
Security
Openness
Functionality
Resource
Control
Fault
tolerance
Scalability
Levels of Difficulty - 2
• Client side
– Security (mobile code)
– Resource control
Distribution
Security
Openness
Functionality
• memory/cpu
– Orthogonal aspects from server
side
Resource
Control
Fault
tolerance
Scalability
Levels of Difficulty-3
• Server Clusters
– Distribution and Fault-tolerance within
the cluster
– Fault-tolerance simplified by the fact
that there is no network partitioning
within the cluster
– Distribution simplified by uniformity
of cluster - latencies can almost be
ignored.
– In the controlled server environment,
issues of openness, security, and
resource-control hardly apply.
Distribution
Security
Openness
Functionality
Resource
Control
Fault
tolerance
Scalability
Levels of Difficulty-4
• Multi-tier server architectures
– Fault-tolerance between tiers/clusters,
i.e. distributed transactions
– Latencies important, alternative service
providers
– In the controlled server environment,
issues of openness and resourcecontrol hardly apply.
– Security considerations lesser because
of lack of openness
Distribution
Security
Openness
Functionality
Resource
Control
Fault
tolerance
Scalability
Levels of Difficulty-5
• Virtual Community
– End-users add services to a shared
environment
– Openness with security is essential
– Resource control important - mobile
code
Distribution
Security
Openness
Functionality
Resource
Control
Fault
tolerance
Scalability
Distributed Programming
Platform - DPP
• DPPs
– language/tools/implementation aimed at
providing the developer of distributed
applications what he needs
– general-purpose programming system
– more than just a centralized programming
system
– subsumes a centralized programming system
Groping for DPPs
• RPC
• Java and offshoots
–
–
–
–
–
Original and Pure Java - sharing code across the net
RMI (based on RPC)
Java Enterprise Beans (within a cluster)
Object Voyager
Continually evolving
• often because of shortcomings in previous version (e.g. security manager in Java
1.1 vs 1.2)
•
•
•
•
•
•
Corba (for interoperability too)
Erlang
E-language (system)
Mozart
What is the common element ??
What is missing??
How to answer these Questions
• Present a vision of what DPP should be
– DPP provides 3 basic properties
– The 3 basic properties are not new, only the context analogies with programming languages used
• Examining current tools
– See how they partly fulfill these goals
– Show they fall short.
• Our view - we are the beginning of DPP
development
DPP for distributed global applications
• The DPP abstracts the complexity of
the underlying system of connected
computers
• Provides transparency/hiding (network
and location) as much as possible or as
much as desirable.
• Provides awareness - i.e. models the
aspects of distribution that effect
– performance(e.g. latency)
– reliability (e.g. partial failure)
• Provides control for tuning application
with respect to fundamental tradeoffs in
distributed systems
– e.g. consistency protocol for state
The applications
The DPP runtime
Connected Computers
The Network
Transparent View
Application
The network and
individual computers
are abstracted away
DPP
Machine
Machine
Machine
Communication Medium
Programmer sees a
global computation
space
Awareness View
Fundamental aspects of
distribution presented
to the programmer as
Application
DPP
Machine
DPP
Middleware
Machine
DPP
Machine
Communication Medium
abstractly and
simply as possible
without losing
necessary information
Control View
The necessary control to
to tune performance
available
Application
Litmus test:
DPP
Machine
DPP
Middleware
Machine
DPP
Machine
Communication Medium
It should not be possible
to improve performance
by much by removing the
middleware and
implementing on a lower
level.
Compare: high-level
languages and assembler
The Three Principles in Programming Languages
• Transparency/hiding
– Program constructs hide or make transparent
• memory locations
• actual machine instructions
• hardware architecture
– E.g iteration and recursion in C++
• Awareness
– Programmers have a mental model of performance for logically-equivalent
program constructs
– E.g. Iteration gives better performance by orders of magnitude
• Control
–
–
–
–
So basic that we forget this.
Consider a C++ compiled as it is today that only provided recursion.
Slower by many orders of magnitude (memory consumption increases)
Litmus test fails - the programmer would program in assembler instead
DPP in the broadest sense
• Across the entire network, i.e. not just for server cluster
architecture
– Clients, between clusters, between clusters that cross administrative
boundaries, even devices.
• General-purpose
– For all types of applications
– Compare general-purpose programming languages with domainspecific ones
DPPs and programming languages
• What is the relationship between DPP and programming
languages?
– DPP is not another word for programming language
– A DPP subsumes, extends, and adds a new dimension to
programming languages
• Traditionally programming languages are an
abstraction of a single machine.
• A DPP abstracts over a set of connected machines
– still includes a set of one – still includes basic computation - for functionality
– it is natural to base DPPs on a existing programming language (no
reinventing the wheel)
Extension
• DPPs introduces many more abstractions that are not
needed in centralized programming languages, e.g.
• Failure- shared object may fail due to network partitioning,
crash of other site, etc.
– At the very least new exceptions
– For sophisticated fault-tolerance need to couple error recovery to
object.
• Resource control - imported code
– Execute procedure with specified resource limits
• Scalability - moving computations
New Dimension
• For awareness and control DPPs may need to make
distinctions on program constructs: the programmer may
find these
– new
– artificial
– unnatural and burdensome
• Example - object (shared object)
– Choice of consistency protocol- best choice for performance is
application dependent.
– Three fundamental types as developed in distributed systems
• stationary
• mobile - with token protocol
• mobile - with invalidation protocol
– To fulfill control goals need all 3 kinds.
New Dimension -2
• The burden of the new distinctions is dependent on the
program language base that the middleware is based upon.
• Example - object (shared object)
– Stateful vs. stateless (in pure-object oriented languages) - for
efficiency across the network the platform needs to know that
information is stateless.
• Stateless information can be replicated across the net
• No consistency protocol
• No infrastructure for consistency protocol.
– Synchronous vs. asynchronous
• New dimension latency.
Minimality
• Also a Distributed programming language should
be as similar to a programming language as
possible
– without losing awareness and control.!!
• Minimal extensions, and minimal new
dimensions.
The goal of a DPPseparation of aspects
Distribution
Distribution
Security
Security
Functionality
Openness
Functionality
Resource Control
Openness
Resource
Control
Fault
tolerance
Scalability
Fault tolerance
Scalability