1. Welcome to a necessary evil
4/7/2019
Distributed Systems - Comp 655

2. Distributed Systems - Comp 655
This course is about
What happens when people try to solve problems by getting software on multiple computers to collaborate as as single system.
… which is often complicated and frustrating …
But it can work
We will explore
What can go wrong
What you can do about it
4/7/2019
Distributed Systems - Comp 655

3. Distributed Systems - Comp 655
About us
4/7/2019
Distributed Systems - Comp 655

4. Distributed Systems - Comp 655
Brainstorming – part 1
Brainstorm a few examples of what you would consider to be “distributed systems” (go for some variety)
4/7/2019
Distributed Systems - Comp 655

5. Distributed Systems - Comp 655
Brainstorming – part 2
What benefits might an organization expect from using a distributed system?
4/7/2019
Distributed Systems - Comp 655

6. Distributed Systems - Comp 655
Brainstorming – part 3
What could go wrong in distributed systems?
Some problems may occur with only
2 servers
20 clients
Some more problems may occur with
100 servers
thousands of clients
4/7/2019
Distributed Systems - Comp 655

7. Fowler’s first law of distributed objects
Don’t distribute your objects
4/7/2019
Distributed Systems - Comp 655

8. Eight fallacies of distributed computing
The network is reliable
Latency is zero
Bandwidth is infinite
The network is secure
Topology doesn’t change
There is one administrator
Transport cost is zero
The network is homogeneous
This list appears, in a slightly different order, on p 16 of Tanenbaum & van Steen, Second Edition
A link to a whitepaper-length treatment of the fallacies, by Arnon Rotem-Gal-Oz, is on the 655 resource page
The list originated with Peter Deutsch, who was at Sun at the time
4/7/2019
Distributed Systems - Comp 655

9. Distributed systems also create problems
Complexity
For the people who use the system
For the people who define, design, develop and test the systems
Scalability problems
4/7/2019
Distributed Systems - Comp 655

10. Tools for dealing with the problems
Middleware
Patterns
Well-defined interfaces
Standards
Evil testing
“Well-defined” interfaces include clear definitions of syntax and semantics, plus clear documentation for users and maintainers.
Standards can help, but they also contribute to complexity. Standardization processes tend to make things complicated. Profusion and confusion of competing standards add to complexity in some areas.
4/7/2019
Distributed Systems - Comp 655

11. Distributed Systems - Comp 655
What is “middleware”?
Middleware is reusable software for
Communication
Naming
Persistence
Transactions
Security
You’ll find out where the name “middleware” comes from a little later.
and some fault tolerance, or at least,
some crash resistance
4/7/2019
Distributed Systems - Comp 655

12. Key goals of middleware
Lack of glamour not surprising
Coherence
Scalability
Openness
4/7/2019
Distributed Systems - Comp 655

13. Lectures emphasize middleware and patterns
Good middleware, applied appropriately, can support
System coherence
System scalability
Open systems
There is one area where we do NOT want total coherence in the sense of sticking together, and that is the area of failures and crashes. If everything sticks together no matter what, then if one computer goes down, the whole system goes down with it.
Rather, we’d like the logical, orderly, and consistent relation among the parts of the system to include the idea that when one part goes down, the other parts continue to work without it.
Dictionary definitions of “coherence”:
The state of sticking together
Logical, orderly, consistent relation of parts
4/7/2019
Distributed Systems - Comp 655

14. Project emphasizes interfaces and technologies
Your code will use and implement a set of interfaces
In the last class, we will integrate all teams’ code
4/7/2019
Distributed Systems - Comp 655

15. Distributed Systems - Comp 655
This class is NOT about
Distributed operating systems
Parallel computing
Network architecture
4/7/2019
Distributed Systems - Comp 655

16. Distributed Systems - Comp 655
Remember: we want
System coherence
System scalability
Open systems
4/7/2019
Distributed Systems - Comp 655

17. Distributed Systems - Comp 655
System coherence
One good way to provide logical, orderly, and consistent relations among a system’s parts is to hide various types of inconsistency.
Tanenbaum and van Steen call this “transparency”.
4/7/2019
Distributed Systems - Comp 655

18. Transparency in a Distributed System
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 is replicated
Concurrency
Hide that a resource may be shared by several competitive users
Failure
Hide the failure and recovery of a resource
4/7/2019
Distributed Systems - Comp 655

19. Distributed Systems - Comp 655
Types of Scalability
Data capacity
Busy hour throughput
Daily throughput
Number of authorized users
Number of concurrent users
Geographic dispersion
Number and variety of services
Availability on mobile devices
“Number and variety of services” appears because system openness and extensibility can be thought of as functional scalability
“Availability on mobile devices” appears on this list because it’s a form of downward scaling, specifically, shrinking the client so it can be used on a cell phone, Blackberry, etc
4/7/2019
Distributed Systems - Comp 655

20. Distributed Systems - Comp 655
Exercise: amazon.com
Form small groups (3 or 4 per group)
Imagine you are Jeff Bezos
Your business is a huge distributed system (amazon.com)
What are the three most important types of transparency for you?
What are the three most important types of scalability for you?
4/7/2019
Distributed Systems - Comp 655

21. Distributed Systems - Comp 655
Online resources
Login page
Resource page
My Franklin faculty home page (includes phone numbers)
Did you get CDs?
4/7/2019
Distributed Systems - Comp 655

22. Definition of a Distributed System
A distributed system is:
A collection of independent computers that appears to its users as a single coherent system.
The collection is easy enough to make.
The appearance of coherence is hard.
4/7/2019
Distributed Systems - Comp 655

23. Appearance of coherence
Some approaches:
Build a distributed operating system, develop the application as if it were non-distributed
Expose networking as operating system services, build the application to take advantage of the network-enabled OS it runs on
Build a reusable middleware layer to handle the common aspects of distributed application development
4/7/2019
Distributed Systems - Comp 655

24. Non-distributed application
machine
application
operating system services
kernel
4/7/2019
Distributed Systems - Comp 655

25. Approach 1 machine 1 machine 2 machine 3 Distributed application
Problems?
Distributed operating system services
sameness
hard to
scale
kernel
kernel
kernel
closed
network
4/7/2019
Distributed Systems - Comp 655

26. Approach 2 machine 1 machine 2 machine 3 Distributed application
Problems?
Network OS
Network OS
Network OS
low
trans-
parency
kernel
kernel
kernel
apps hard
to build
network
4/7/2019
Distributed Systems - Comp 655

27. The third way machine 1 machine 2 machine 3 Distributed application
Middleware
Network OS
Network OS
Network OS
It’s called “middleware” because it fits in the middle between the application and the operating system.
kernel
kernel
kernel
network
4/7/2019
Distributed Systems - Comp 655

28. Applications and middleware: who’s in control?
The application can be in control, and call middleware capabilities when needed (traditional layered approach)
The middleware can be in control, and call application capabilities when needed (aka “inversion of control”)
Hybrid: middleware calls application components to process requests, but during processing, application can directly invoke middleware capabilities
Client/server applications usually take the traditional layered approach
GUI frameworks (for example, VB forms or Java Swing) rely heavily on inversion of control
Applications built on enterprise application platforms (for example, Java EE, .Net, LAMP) often take a hybrid approach
4/7/2019
Distributed Systems - Comp 655

29. Distributed Systems - Comp 655
Brainstorm
Advantages of the traditional layered approach
Disadvantages of the traditional layered approach
Advantages of inversion of control
Disadvantages of inversion of control
(ignore hybrids for this exercise)
4/7/2019
Distributed Systems - Comp 655

30. Topic shift: back to assignments and schedule
4/7/2019
Distributed Systems - Comp 655

31. Distributed Systems - Comp 655
The project
DiNo – Distributed Notebook
Schedule
Week 4 Teams formed
Week 8 Design exchange
Week 9 Design paper due
Week 10 Preliminary integration test
Week 12 Talks, integration, pizza
4/7/2019
Distributed Systems - Comp 655

32. Advice about working in Java
Start tomorrow
If you haven’t used Java before
You’ll be able to handle it (if you get started now)
Get an IDE (see the Java development resources page)
Get GlassFish
4/7/2019
Distributed Systems - Comp 655

33. Distributed Systems - Comp 655
Homework
System summary (due week 2)
Communication
Compare approaches (due week 3)
Simple web app
Warm-up for DiNo (due week 5)
Architecture style: RPC/SOAP vs REST
Assess the conflict (due week 7)
4/7/2019
Distributed Systems - Comp 655

34. About that sign-up form
It’s a Perl script
Single-threaded
Running on einstein
Data is in a text file
Error and status messages go to text files
What could go wrong?
4/7/2019
Distributed Systems - Comp 655

35. Communication homework
Due in week 3
Assess applicability of http, smtp and Java RMI
Details
4/7/2019
Distributed Systems - Comp 655