Question? Leave a message!




Distributed Software Engineering

Distributed Software Engineering
Dr.ShaneMatts Profile Pic
Dr.ShaneMatts,United States,Teacher
Published Date:23-07-2017
Website URL
Comment
Chapter 18 Distributed Software Engineering Chapter 18 Distributed Software Engineering Slide 1 Topics covered  Distributed systems characteristics and issues  Models of component interaction  Client–server computing  Architectural patterns for distributed systems  Software as a service Chapter 18 Distributed Software Engineering Slide 2 Distributed systems  Virtually all large computer-based systems are now distributed systems.  Processing is distributed over several computers rather than confined to a single machine.  Appears to the user as a single, coherent system (more or less...). Chapter 18 Distributed Software Engineering Slide 3 Distributed system characteristics / advantages  Resource sharing (hardware and software)  Openness (standard protocols allow equipment and software from different vendors to be combined)  Concurrency (parallel processing to enhance performance)  Scalability (increased throughput by adding new resources up to capacity of network)  Fault tolerance (potential to continue in operation after a fault has occurred) Chapter 18 Distributed Software Engineering Slide 4 Distributed systems issues  Distributed systems are more complex than systems that run on a single processor.  Complexity arises because different parts of the system are independently managed as is the network.  There is generally no single authority in charge of the system so top-down control is impossible. Chapter 18 Distributed Software Engineering Slide 5 Design issues  Transparency: To what extent should the distributed system appear to the user as a single system?  Openness: Should a system be designed using standard protocols that support interoperability?  Scalability: How can the system be constructed so that it is scalable? (cont’d) Chapter 18 Distributed Software Engineering Slide 6 Design issues (cont’d)  Security: How can usable security policies be defined and implemented?  Quality of service: How should the quality of service be specified?  Failure management: How can system failures be detected, contained, and repaired? Chapter 18 Distributed Software Engineering Slide 7 Transparency  Ideally, users should not be aware that a system is distributed and services should be independent of how they are distributed.  In practice, this is impossible because parts of the system are independently managed and because of network delays. (It’s often better to make users aware of distribution so that they can cope with problems.)  To achieve transparency, resources should be abstracted and addressed logically rather than physically. Middleware maps logical to physical resources. Chapter 18 Distributed Software Engineering Slide 8 Openness  Open distributed systems are systems that are built according to generally accepted standards.  Components from any supplier developed in any programming language can be integrated into the system and can inter-operate with one another.  Web service standards for service-oriented architectures were developed to be open standards. Chapter 18 Distributed Software Engineering Slide 9 Scalability  The ability of a system to deliver a high quality service as demands on the system increase... • Size: …by adding more resources to cope with an increasing numbers of users. • Distribution: …by geographically dispersing components without degrading performance. • Manageability: …by effectively managing a system as it increases in size, even if its components are located in independent organizations.  There is a distinction between scaling-up and scaling- out... (cont’d) Chapter 18 Distributed Software Engineering Slide 10 Scaling-up vs. scaling-out  Scaling-up means replacing resources with more powerful ones.  Scaling-out means adding additional resources  Scaling-out is often more cost effective, but usually requires that the system support concurrent processing. Chapter 18 Distributed Software Engineering Slide 11 Security  The number of ways that distributed systems may be attacked is significantly greater than that for centralized systems.  If a part of the system is compromised then the attacker may be able to use this as a “back door” into other parts of the system.  Difficulties can arise when different organizations own parts of the system. Security policies and mechanisms may be incompatible. (cont’d) Chapter 18 Distributed Software Engineering Slide 12 Types of attack to defend against  Interception of communications between parts of the system resulting in a loss of confidentiality.  Interruption of services, e.g., a denial of service attack whereby a node is flooded with spurious service requests so that it cannot deal with valid ones.  Modification of data or services in the system by an attacker.  Fabrication, e.g., of a false password entry that can be used to gain access to a system. Chapter 18 Distributed Software Engineering Slide 13 Quality of service (QoS)  Reflects a system’s ability to deliver services dependably and with a response time and throughput that is acceptable to users.  QoS is particularly critical when a system deals with time-critical data such as audio or video streams (which could become so degraded that it is impossible to understand). Chapter 18 Distributed Software Engineering Slide 14 Failure management  Since failures are inevitable, distributed systems must be designed to be resilient... “You know that you have a distributed system when the crash of a system that you’ve never heard of stops you getting any work done.”  Distributed systems should include mechanisms for discovering failed components, continuing to deliver as many services as possible and, where possible, automatically recovering from failures. Chapter 18 Distributed Software Engineering Slide 15 Topics covered  Distributed systems characteristics and issues  Models of component interaction  Client–server computing  Architectural patterns for distributed systems  Software as a service Chapter 18 Distributed Software Engineering Slide 16 Models of component interaction  There are two types of interaction between components in a distributed system: • Procedural interaction, where one computer calls on a known service offered by another computer and waits for a response. (synchronous) • Message-based interaction, involves the computer sending information about what is required to another computer. There is no necessity to wait for a response. (non-synchronous) Chapter 18 Distributed Software Engineering Slide 17 Procedural interaction between a diner and a waiter via synchronous procedure calls Chapter 18 Distributed Software Engineering Slide 18 Message-based interaction between a waiter and the kitchen via XML starter dish name = “soup” type = “tomato” / dish name = “soup” type = “fish” / dish name = “pigeon salad” / /starter main course dish name = “steak” type = “sirloin” cooking = “medium” / dish name = “steak” type = “fillet” cooking = “rare” / dish name = “sea bass” /main course accompaniment dish name = “french fries” portions = “2” / dish name = “salad” portions = “1” / /accompaniment Chapter 18 Distributed Software Engineering Slide 19 Procedural (synchronous) Interaction  Implemented by Remote Procedure Calls (RPC’s).  One component calls another (via a “stub”) as if it were a local procedure or method.  Middleware intercepts the call and passes it to the remote component which carries out the required computation and returns the result.  A problem is that both components need to be available at the time of the communication and must know how to refer to each other. Chapter 18 Distributed Software Engineering Slide 20