1. Chapter 17 – Distributed software engineering Chapter 17 Distributed software engineering120/11/2014

2. Distributed systems  Virtually all large computer-based systems are now distributed systems[Tanenbaum and Van Steen (2007)]. “… a collection of independent computers that appears to the user as a single coherent system.”  Information processing is distributed over several computers rather than confined to a single machine.  Distributed software engineering is therefore very important for enterprise computing systems. 20/11/2014Chapter 17 Distributed software engineering2

3. Distributed system characteristics  Resource sharing  Sharing of hardware and software resources such as disks, printers, files, and compilers—that are associated with computers on a network..  Openness  Use of equipment and software from different vendors. they are designed around standard protocols  Concurrency  several processes may operate at the same time on separate computers on the network. These processes may (but need not) communicate with each other during their normal operation. 20/11/2014Chapter 17 Distributed software engineering3

4. Distributed system characteristics  Scalability  The capabilities of the system can be increased by adding new resources to cope with new demands on the system.  The network linking the individual computers in the system may limit the system scalability  Fault tolerance  Since the availability of several computers and the potential for replicating information, distributed systems can be tolerant of some hardware and software failures  A degraded service can be provided when failures occur  Complete loss of service only occurs when there is a network failure. 20/11/2014Chapter 17 Distributed software engineering4

5. Distributed systems Chapter 17 Distributed software engineering520/11/2014

6. Distributed systems issues  Distributed systems are inherently more complex than centralized systems.  This makes them more difficult to design, implement, and test.  It is harder to understand the emergent properties of distributed systems  The reason is the complexity of the interactions between system components and the system infrastructure Chapter 17 Distributed software engineering620/11/2014

7. Distributed systems issues  Complexity arises because different parts of the system are independently managed as is the network.  They cannot be controlled by the owners of systems using the network  There is no single authority in charge of the system so top-down control is impossible.  The network connecting these nodes is a separately managed system  There is an inherent unpredictability in the operation of distributed systems 20/11/2014Chapter 17 Distributed software engineering7

8. Design issues  Transparency To what extent should the distributed system appear to the user as a single system?  When it is useful for users to understand that the system is distributed?  Openness Should a system be designed using standard protocols that support interoperability  Should more specialized protocols be used that restrict the freedom of the designer  Scalability How can the system be constructed so that it is scaleable?  How can the overall system be designed So that its capacity can be increased in response to increasing demands made on the system? Chapter 17 Distributed software engineering820/11/2014

9. Design issues  Security How can usable security policies be defined and implemented?  Quality of service How should the quality of service be specified.  How should the system be implemented to deliver an acceptable quality of service to all users?  Failure management How can system failures be detected,  How can system failures be contained so that they have minimal effects on other components in the system  How can system failures be repaired? 20/11/2014Chapter 17 Distributed software engineering9

10. Transparency  Ideally, users should not be aware that a system is distributed and services should be independent of distribution characteristics.  In practice, this is impossible because parts of the system are independently managed and because of network delays.  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 17 Distributed software engineering1020/11/2014

11. Openness  Open distributed systems are systems that are built according to generally accepted standards.  Components from any supplier can be integrated into the system and can inter-operate with the other system components.  Openness implies that system components can be independently developed in any programming language and, if these conform to standards, they will work with other components.  Web service standards for service-oriented architectures were developed to be open standards. Chapter 17 Distributed software engineering1120/11/2014

12. Scalability  The scalability of a system reflects its ability to deliver a high quality service as demands on the system increase  Size It should be possible to add more resources to a system to cope with increasing numbers of users.  Distribution It should be possible to geographically disperse the components of a system without degrading its performance.  Manageability It should be possible to manage a system as it increases in size, even if parts of the system are located in independent organizations. Chapter 17 Distributed software engineering1220/11/2014

13. scaling-up and scaling-out  There is a distinction between scaling-up and scaling- out.  Scaling up means replacing resources in the system with more powerful resources.  For example, you may increase the memory in a server from 16 GB to 64 GB.  Scaling out means adding additional resources to the system  an extra web server to work alongside an existing server 20/11/2014Chapter 17 Distributed software engineering13

14. scaling-up and scaling-out  Scaling out is often more cost effective than scaling up  Scaling out means that the system has to be designed so that concurrent processing is possible. Scaling up is more powerful system Scaling out is more system instances. 20/11/2014Chapter 17 Distributed software engineering14

15. Security  When a system is distributed, the number of ways that the system may be attacked is significantly increased, compared to centralized systems.  If a part of the system is successfully attacked then the attacker may be able to use this as a ‘back door’ into other parts of the system.  Difficulties in a distributed system arise because different organizations may own parts of the system.  These organizations may have mutually incompatible security policies and security mechanisms. Chapter 17 Distributed software engineering1520/11/2014

16. The types of attacks  Interception, where communications between parts of the system are intercepted by an attacker  there is a loss of confidentiality.  Interruption, where system services are attacked and cannot be delivered as expected.  Denial of service attacks involve bombarding a node with illegitimate service requests it cannot deal with valid requests. 20/11/2014Chapter 17 Distributed software engineering16

17. The types of attacks  Modification, where data or services in the system are changed by an attacker.  Fabrication, where an attacker generates information that should not exist  then uses this to gain some privileges. an attacker may generate a false password entry and use this to gain access to a system 20/11/2014Chapter 17 Distributed software engineering17

18. The difficulties in a distributed system  Security mechanisms, such as encryption and authentication, are used to enforce the security policy.  Different organizations may own parts of the system.  These organizations may have mutually incompatible security policies and security mechanisms.  Security compromises may have to be made in order to allow the systems to work together. 20/11/2014Chapter 17 Distributed software engineering18

19. Quality of service  The quality of service (QoS) offered by a distributed system reflects the system’s ability to deliver its services dependably and with a response time and throughput that is acceptable to its users.  Quality of service is particularly critical when the system is dealing with time-critical data such as sound or video streams.  In these circumstances, if the quality of service falls below a threshold value then the sound or video may become so degraded that it is impossible to understand. Chapter 17 Distributed software engineering1920/11/2014

20. QoS is not always practicable  It may not be cost effective to design and configure the system to deliver a high QoS under peak load.  This could involve making resources available that are unused for much of the time.  One of the main arguments for ‘cloud computing’ is that it partially addresses this problem.  Using a cloud, it is easy to add resources as demand increases.  The QoS parameters may be mutually contradictory.  İncreased reliability may mean reduced throughput, as checking procedures are introduced to ensure that all system inputs are valid. 20/11/2014Chapter 17 Distributed software engineering20

21. Failure management  In a distributed system, it is inevitable that failures will occur, so the system has to be designed to be resilient to these failures. “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 if a component of the system has failed,  Distributed systems should continue to deliver as many services as possible in spite of that failure and, as far as possible, automatically recover from the failure. Chapter 17 Distributed software engineering2120/11/2014

22. CORBA – Common Object Request Broker Architecture  CORBA is a standard for an object request broker architecture that was developed by the Object Management Group in the 1990s.  It was hoped that this would be widely adopted and that implementations of the standard would be available from competing vendors.  The OMG standards are available from their website 20/11/2014Chapter 17 Distributed software engineering22

23. The structure of a CORBA-based distributed application 20/11/2014Chapter 17 Distributed software engineering23

24. The components of Distributed Application  Application objects that are designed and implemented for this application.  Standard objects that are defined by the OMG for a specific domain.  These domain object standards cover finance/insurance, electronic commerce, healthcare, and a number of other areas.  Fundamental CORBA services that provide basic distributed computing services such as directories, security management, etc. 20/11/2014Chapter 17 Distributed software engineering24

25. The components of Distributed Application  Horizontal CORBA facilities such as user interface facilities, system management facilities, etc.  The term horizontal facilities suggests that these facilities are common to many application domains  the facilities are therefore used in many different applications. 20/11/2014Chapter 17 Distributed software engineering25

26. Four major elements of CORBA standards  An object model for application objects where a CORBA object is an encapsulation of state with a well-defined, language-neutral interface described in an IDL (Interface Definition Language).  An object request broker (ORB) that manages requests for object services.  The ORB locates the object providing the service,  The ORB prepares it for the request  The ORB sends the service request  The ORB returns the results to the requester. 20/11/2014Chapter 17 Distributed software engineering26

27. Four major elements of CORBA standards  A set of object services that are general services likely to be required by many distributed applications.  Examples of services are directory services, transaction services and persistence services.  A set of common components built on top of these basic services that may be required by applications  These may be vertical domain-specific components or horizontal, general-purpose components that are used by many applications. 20/11/2014Chapter 17 Distributed software engineering27

28. Models of interaction  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.  Message-based interaction, involves the sending computer sending information about what is required to another computer. There is no necessity to wait for a response. Chapter 17 Distributed software engineering2820/11/2014

29. Procedural interaction between a diner and a waiter Chapter 17 Distributed software engineering2920/11/2014 Synchronous ordering process as a series of calls

30. Message-based interaction between a waiter and the kitchen Chapter 17 Distributed software engineering30 20/11/2014 Hypothetical XML message that defines an order made by the table of three people

31.  The waiter takes the order as a series of interactions, with each interaction defining part of the order.  However, the waiter has a single interaction with the kitchen where the message defines the complete order. 20/11/2014Chapter 17 Distributed software engineering31

32. Remote procedure calls (RPC)  Procedural communication in a distributed system is implemented using remote procedure calls (RPC).  In a remote procedure call, one component calls another component as if it was a local procedure or method.  The middleware in the system intercepts this call and passes it to a remote component.  This carries out the required computation  via the middleware, returns the result to the calling component.  A problem with RPCs is that the caller and the callee need to be available at the time of the communication, and they must know how to refer to each other. Chapter 17 Distributed software engineering3220/11/2014

33. The Steps: Remote procedure calls (RPC)  RPCs require a ‘stub’ for the called procedure to be accessible on the computer that is initiating the call.  The stub is called and it translates the procedure parameters into a standard representation for transmission to the remote procedure.  Through the middleware, it then sends the request for execution to the remote procedure.  The remote procedure uses library functions to convert the parameters into the required format, carries out the computation,  And it communicates the results via the ‘stub’ that is representing the caller. Chapter 17 Distributed software engineering33

34. remote method invocations (RMI)  In Java, remote method invocations (RMI) are comparable with, though not identical to, RPCs.  The RMI framework handles the invocation of remote methods in a Java program. 20/11/2014Chapter 17 Distributed software engineering34

35. Message passing  Message-based interaction normally involves one component creating a message that details the services required from another component.  Through the system middleware, this is sent to the receiving component.  The receiver parses the message, carries out the computations and creates a message for the sending component with the required results.  In a message-based approach, it is not necessary for the sender and receiver of the message to be aware of each other.  They simple communicate with the middleware. Chapter 17 Distributed software engineering3520/11/2014

36. Middleware  The components in a distributed system may be implemented in different programming languages and may execute on completely different types of processor.  Models of data, information representation and protocols for communication may all be different.  Middleware is software that can manage these diverse parts, and ensure that they can communicate and exchange data. Chapter 17 Distributed software engineering3620/11/2014

37. Middleware in a distributed system Chapter 17 Distributed software engineering3720/11/2014

38. Middleware support  Interaction support, where the middleware coordinates interactions between different components in the system  The middleware provides location transparency in that it isn’t necessary for components to know the physical locations of other components.  The provision of common services, where the middleware provides reusable implementations of services that may be required by several components in the distributed system.  By using these common services, components can easily inter- operate and provide user services in a consistent way. Chapter 17 Distributed software engineering3820/11/2014