Software Engineering of Distributed Systems

1. Software Engineering of Distributed Systems University of Colorado Boulder ECEN5053 bring up www.cdk4.net before starting Tegrity in class

2. University of Colorado ECEN5053 SW Eng of Distributed Systems Week 1 Intro

3. Course Logistics • 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 – dameron@colorado.edu 303-492-8369 (CU office), ECEE 1B67 • Text web site: www.cdk4.net -- see key pts. University of Colorado ECEN5053 SW Eng of Distributed Systems Week 1 Intro

4. Outline • Definitions • Software Engineering issues • Purposes • Demands/challenges • Hardware concepts • Software concepts • An example model University of Colorado ECEN5053 SW Eng of Distributed Systems Week 1 Intro

5. Definition of a Distributed System • 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 University of Colorado ECEN5053 SW Eng of Distributed Systems Week 1 Intro

6. Alternative definition of 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 University of Colorado ECEN5053 SW Eng of Distributed Systems Week 1 Intro

7. Implied characteristics? “appears to its users as a single coherent system” – what must be true for that to be true? University of Colorado ECEN5053 SW Eng of Distributed Systems Week 1 Intro

8. Examples? • internet • and what else? University of Colorado ECEN5053 SW Eng of Distributed Systems Week 1 Intro

9. Why is this hard? • 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 University of Colorado ECEN5053 SW Eng of Distributed Systems Week 1 Intro

10. Software is hard • Inherent complexities • fundamental domain challenges • partial failure, distributed deadlock, end-to-end QoS • Accidental complexities • Limitations of software tools • Limitations of development techniques • non-portable APIs, poor distributed debuggers • Deliberate choices of developers who favor low-level languages and tools that don’t scale well University of Colorado ECEN5053 SW Eng of Distributed Systems Week 1 Intro

11. Software is hard - 2 • 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 University of Colorado ECEN5053 SW Eng of Distributed Systems Week 1 Intro

12. 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 University of Colorado ECEN5053 SW Eng of Distributed Systems Week 1 Intro

13. 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. University of Colorado ECEN5053 SW Eng of Distributed Systems Week 1 Intro

14. 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 • Offers services by standard rules that describe the syntax and semantics of those services • Should be scalable • size, geography, and administration University of Colorado ECEN5053 SW Eng of Distributed Systems Week 1 Intro

15. Access and sharing remotely • Why share? • economy • ease of collaboration -- virtual organizations • ease of info exchange • commerce • Connectivity and sharing lead to security issues • Currently, inadequate protection University of Colorado ECEN5053 SW Eng of Distributed Systems Week 1 Intro

16. Transparency Types University of Colorado ECEN5053 SW Eng of Distributed Systems Week 1 Intro

17. Degree of Transparency • 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 University of Colorado ECEN5053 SW Eng of Distributed Systems Week 1 Intro

18. Openness • Offers services according to standard rules describing syntax and semantics of the services. • Rules are formalized in protocols • Services generally specified throughinterfaces • using Interface Definition Language (IDL) • 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 University of Colorado ECEN5053 SW Eng of Distributed Systems Week 1 Intro

19. 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 University of Colorado ECEN5053 SW Eng of Distributed Systems Week 1 Intro

20. Flexibility -- Policy and Mechanism • 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 University of Colorado ECEN5053 SW Eng of Distributed Systems Week 1 Intro

21. Scability Challenges -- Size • Size • Limitations of centralizedservices, data, and algorithms -- become bottleneck • Unlimited processing power and storage cannot overcome communication limitations • Decentralization introduces some kinds of uncertainty University of Colorado ECEN5053 SW Eng of Distributed Systems Week 1 Intro

22. Scalability Challenges -- Geographic • 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 University of Colorado ECEN5053 SW Eng of Distributed Systems Week 1 Intro

23. 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 University of Colorado ECEN5053 SW Eng of Distributed Systems Week 1 Intro

24. 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 University of Colorado ECEN5053 SW Eng of Distributed Systems Week 1 Intro

25. Dividing DNS name space into zones Generic Countries int com edu gov mil org ... Z1 colorado Z2 cs ece ... Z3 University of Colorado ECEN5053 SW Eng of Distributed Systems Week 1 Intro

26. Outline • Definition • Purposes • Demands/challenges • Hardware concepts • Software concepts • An example model University of Colorado ECEN5053 SW Eng of Distributed Systems Week 1 Intro

27. Hardware Concepts • Introduction to how distributed systems can be organized • how they are interconnected • how they communicate Memory Interconnection University of Colorado ECEN5053 SW Eng of Distributed Systems Week 1 Intro

28. 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 University of Colorado ECEN5053 SW Eng of Distributed Systems Week 1 Intro

29. Bus-based & Switch-based • 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 University of Colorado ECEN5053 SW Eng of Distributed Systems Week 1 Intro

30. 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 • Limited scalability University of Colorado ECEN5053 SW Eng of Distributed Systems Week 1 Intro

31. 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, bus-based network) • 5. Private memory, switch-based network (massively parallel processors, clusters of workstations) • 6. and ... University of Colorado ECEN5053 SW Eng of Distributed Systems Week 1 Intro

32. Performance impacts - heterogeneous multicomputer systems • 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) University of Colorado ECEN5053 SW Eng of Distributed Systems Week 1 Intro

33. Software Concepts • 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 University of Colorado ECEN5053 SW Eng of Distributed Systems Week 1 Intro

34. 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: scalabilityandopenness of network o.s. andtransparency and ease of use of distributed o.s. • Additional layer called middleware University of Colorado ECEN5053 SW Eng of Distributed Systems Week 1 Intro

35. Various middleware models (paradigms) • 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 University of Colorado ECEN5053 SW Eng of Distributed Systems Week 1 Intro

36. Sample Paradigms University of Colorado ECEN5053 SW Eng of Distributed Systems Week 1 Intro

37. Each paradigm must address these issues: • Communication • Processes & synchronization • Processes & process interaction • Naming • Consistency and replication • Fault tolerance • Security University of Colorado ECEN5053 SW Eng of Distributed Systems Week 1 Intro

38. Software Engineering of Distributed Systems • 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 University of Colorado ECEN5053 SW Eng of Distributed Systems Week 1 Intro