Question? Leave a message!




Distributed Software Engineering

Distributed Software Engineering
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 computerbased 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 topdown 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 interoperate with one another.  Web service standards for serviceoriented 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 scalingup and scaling out... (cont’d) Chapter 18 Distributed Software Engineering Slide 10 Scalingup vs. scalingout  Scalingup means replacing resources with more powerful ones.  Scalingout means adding additional resources  Scalingout 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 timecritical 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) • Messagebased interaction, involves the computer sending information about what is required to another computer. There is no necessity to wait for a response. (nonsynchronous) 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 Messagebased 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 Messagebased (asynchronous) Interaction  Normally involves one component creating a message that details the services required of another.  Message is sent via middleware to the receiving component which parses the message, carries out the computations, and (possibly) creates a return message with the required results.  Messages are queued until the receiver is available. Components need NOT refer to each other; middle ware ensures that messages are passed to the appropriate component. Chapter 18 Distributed Software Engineering Slide 21 Middleware  The components in a distributed system may be implemented in different programming languages and may execute on different processors.  Models of data, information representation, and protocols for communication may all be different.  Middleware is software that can manage these diverse components, and ensure that they can communicate and exchange data.  Examples include: CORBA, DCOM, .NET Chapter 18 Distributed Software Engineering Slide 22 Middleware in a distributed system Chapter 18 Distributed Software Engineering Slide 23 Types of middleware support  Interaction support: coordinates interactions between different components in the system. • Provides location transparency whereby it isn’t necessary for components to know the physical locations of other components.  Common services: provides services that may be required by different components regardless of their functionality (i.e., security, notification, transaction management, etc.). • Supports interoperability and service consistency. Chapter 18 Distributed Software Engineering Slide 24 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 25 Clientserver computing  Distributed systems that are accessed over the Internet are often organized as clientserver (C/S) systems.  The user interacts with a program running on a local computer (e.g., a web browser or phonebased application) which interacts with another program running on a remote computer (e.g., a web server).  The remote computer provides services, such as access to web pages, which are available to clients. Chapter 18 Distributed Software Engineering Slide 26 Processes in a clientserver system c3 c2 c4 c12 c11 Server process c1 s1 s4 c10 c5 Client process s2 s3 c9 c6 c8 c7 Chapter 18 Distributed Software Engineering Slide 27 Mapping of client and server processes to networked computers c1 c2 c3, c4 CC1 CC2 CC3 Network Server s3, s4 s1, s2 computer SC1 SC2 Client computer c5, c6, c7 c8, c9 c10, c11, c12 CC4 CC5 CC6 Chapter 18 Distributed Software Engineering Slide 28 Layered architectural model for clientserver applications Chapter 18 Distributed Software Engineering Slide 29 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 30 Distributed system architectural patterns  Masterslave: used in realtime systems for which guaranteed interaction response times are required.  Twotier clientserver: used for simple clientserver systems, and where the system is centralized for security reasons.  Multitier clientserver: used when there is a high volume of transactions to be processed by the server.  Distributed component: used when resources from different systems and databases need to be combined, or as an implementation model for multitier clientserver systems.  Peertopeer: used when clients exchange locally stored information and the role of the server is to introduce clients to each other. Chapter 18 Distributed Software Engineering Slide 31 Distributed system architectural patterns  Masterslave: used in realtime systems for which guaranteed interaction response times are required.  Twotier clientserver: used for simple clientserver systems, and where the system is centralized for security reasons.  Multitier clientserver: used when there is a high volume of transactions to be processed by the server.  Distributed component: used when resources from different systems and databases need to be combined, or as an implementation model for multitier clientserver systems.  Peertopeer: used when clients exchange locally stored information and the role of the server is to introduce clients to each other. Chapter 18 Distributed Software Engineering Slide 32 Masterslave architectures  Commonly used in realtime systems with separate processors associated with data acquisition, data processing, and computation and actuator management.  A “Master” process is usually responsible for computation, coordination, and communications; it controls the “slave” processes.  “Slave” processes are dedicated to specific actions, e.g., the acquisition of data from an array of sensors. Chapter 18 Distributed Software Engineering Slide 33 A traffic management system with a masterslave architecture Control room Traffic flow Traffic light control Sensor processor processor processor processor Light Coordination Sensor Display control and Display control process process Process process Slave Slave Master Traffic lights Traffic flow sensors Operator consoles and cameras Chapter 18 Distributed Software Engineering Slide 34 Distributed system architectural patterns  Masterslave: used in realtime systems for which guaranteed interaction response times are required.  Twotier clientserver: used for simple clientserver systems, and where the system is centralized for security reasons.  Multitier clientserver: used when there is a high volume of transactions to be processed by the server.  Distributed component: used when resources from different systems and databases need to be combined, or as an implementation model for multitier clientserver systems.  Peertopeer: used when clients exchange locally stored information and the role of the server is to introduce clients to each other. Chapter 18 Distributed Software Engineering Slide 35 Twotier C/S architecture  System is implemented as a single logical server plus some number of clients that use that server. • Thinclient model: presentation layer is implemented on the client; all other layers (data management, application processing and database) are on the server. • Fatclient model: some or all application processing is implemented on the client; data management and database functions are on the server. Chapter 18 Distributed Software Engineering Slide 36 Thin and fatC/S architectures Chapter 18 Distributed Software Engineering Slide 37 Thinclient model  Often used when centralized legacy systems evolve to a C/S architecture; a graphical interface is implemented on clients and the legacy system acts as a server.  Disadvantage: places a heavy processing load on both the server and the network. Chapter 18 Distributed Software Engineering Slide 38 Fatclient model  More processing is delegated to the client.  Most suitable for new C/S systems where client capabilities are known in advance.  System management is more complex. When application functionality changes, updates are required on each client. Chapter 18 Distributed Software Engineering Slide 39 A fatclient C/S architecture for an ATM system ATM ATM Account server Tele Customer processing account ATM monitor database ATM transaction manager Chapter 18 Distributed Software Engineering Slide 40 Distributed system architectural patterns  Masterslave: used in realtime systems for which guaranteed interaction response times are required.  Twotier clientserver: used for simple clientserver systems, and where the system is centralized for security reasons.  Multitier clientserver: used when there is a high volume of transactions to be processed by the server.  Distributed component: used when resources from different systems and databases need to be combined, or as an implementation model for multitier clientserver systems.  Peertopeer: used when clients exchange locally stored information and the role of the server is to introduce clients to each other. Chapter 18 Distributed Software Engineering Slide 41 Multitier C/S architecture  Each layer may execute on a separate processor.  Allows for: • better performance and scalability than the thinclient, approach, and is • simpler to manage than a fatclient approach. (Why) Chapter 18 Distributed Software Engineering Slide 42 Threetier architecture for an internet banking system Client HTTP interaction Database server Web server SQL query Customer Client Account service SQL account provision database Client Tier 2: Tier 3: Database Application processing processing Client and data management Tier 1: Presentation Chapter 18 Distributed Software Engineering Slide 43 Use of C/S architectural patterns Architecture Applications Twotier client–server Legacy system applications that are used when architecture with thin clients separating application processing and data management is impractical. Clients may access these as services, as discussed in Section 18.4. Computationally intensive applications such as compilers with little or no data management. Dataintensive applications (browsing and querying) with nonintensive application processing. Browsing the Web is the most common example of a situation where this architecture is used. (cont’d) Chapter 18 Distributed Software Engineering Slide 44 Use of C/S architectural patterns Architecture Applications Twotier clientserver Applications where application processing is provided architecture with fat clients by offtheshelf software (e.g., Microsoft Excel) on the client. Applications where computationally intensive processing of data (e.g., data visualization) is required. Mobile applications where internet connectivity cannot be guaranteed. Some local processing using cached information from the database is therefore possible. Chapter 18 Distributed Software Engineering Slide 45 Use of C/S architectural patterns Architecture Applications Multitier client–server Largescale applications with hundreds or thousands of architecture clients. Applications where both the data and the application are volatile. Applications where data from multiple sources are integrated. Chapter 18 Distributed Software Engineering Slide 46 Distributed system architectural patterns  Masterslave: used in realtime systems for which guaranteed interaction response times are required.  Twotier clientserver: used for simple clientserver systems, and where the system is centralized for security reasons.  Multitier clientserver: used when there is a high volume of transactions to be processed by the server.  Distributed component: used when resources from different systems and databases need to be combined, or as an implementation model for multitier clientserver systems.  Peertopeer: used when clients exchange locally stored information and the role of the server is to introduce clients to each other. Chapter 18 Distributed Software Engineering Slide 47 Distributed component architectures  System is designed as a set of services, without attempting to allocate these services to layers in the system.  Each service (or group of related services) is implemented as a separate component or object.  Components communicate via middleware using remote procedure or method calls. Chapter 18 Distributed Software Engineering Slide 48 Generic distributed component architecture Chapter 18 Distributed Software Engineering Slide 49 A distributed component architecture of a DATA MINING SYSTEM Chapter 18 Distributed Software Engineering Slide 50 Advantages of distributed component architectures  Allows developers to delay decisions on where and how services should be provided. (Service providing components may execute on any network node.)  Very open architecture – new resources can be added as required.  System is dynamically reconfigurable – components can migrate across the network as required. (Thus improving performance.)  Therefore: flexible and scalable. Chapter 18 Distributed Software Engineering Slide 51 Disadvantages of distributed component architectures  Less intuitive/natural than C/S: more difficult to visualize, understand, and design.  Competing middleware standards: vendors, such as Microsoft and Sun, have developed different, incompatible middleware systems. As a result, serviceoriented architectures (SOA’s) are replacing distributed component architectures in many situations. Chapter 18 Distributed Software Engineering Slide 52 Distributed system architectural patterns  Masterslave: used in realtime systems for which guaranteed interaction response times are required.  Twotier clientserver: used for simple clientserver systems, and where the system is centralized for security reasons.  Multitier clientserver: used when there is a high volume of transactions to be processed by the server.  Distributed component: used when resources from different systems and databases need to be combined, or as an implementation model for multitier clientserver systems.  Peertopeer: used when clients exchange locally stored information and the role of the server is to introduce clients to each other. Chapter 18 Distributed Software Engineering Slide 53 Peertopeer (p2p) architectures  Decentralized systems utilize the power and storage of a large number of networked computers running the same application.  Computations may therefore be carried out by any node in the network.  Most systems have been personal in nature (e.g., file sharing on PCs), but the number of business and scientific applications is increasing. (Foldinghome, SETIhome, VOIP, etc.) Chapter 18 Distributed Software Engineering Slide 54 Appropriate uses of p2p 1. Computationally intensive applications where processing can be efficiently distributed among a large number of networked computers that need not communicate with one another. (E.g., Foldinghome) 2. Applications where processing involves a large number of networked computers exchanging data that need not be centrally stored or managed. (E.g., file sharing) Chapter 18 Distributed Software Engineering Slide 55 A decentralized p2p architecture Chapter 18 Distributed Software Engineering Slide 56 A “semicentralized” p2p architecture Chapter 18 Distributed Software Engineering Slide 57 P2p problems  The major concerns that have inhibited p2p use are security and trust.  When p2p nodes interact with one another, any resources could potentially be accessed.  Problems may also occur if peers deliberately behave in a malicious way. Chapter 18 Distributed Software Engineering Slide 58 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 59 Software as a Service (SaaS)  Involves hosting software remotely on servers (“the cloud”) with access provided over the Internet via web browsers.  The server maintains user data and state during a trans action session.  Applications are owned and managed by a software pro vider rather than users.  Users may pay for access according to the amount of use, or through an annual or monthly subscription.  If free, users are exposed to advertisements which fund the software service. Chapter 18 Distributed Software Engineering Slide 60 Differences between SaaS and “Service oriented architecture” (SOA)  SOA (Chap. 19) is an implementation technology for structuring a system as a set of separate, stateless services.  Services may be owned and managed by multiple providers and may be distributed.  Existing services may be composed and configured to create new composite services and applications.  The basis for service composition is often a workflow. Chapter 18 Distributed Software Engineering Slide 61 Differences between SaaS and “Service oriented architecture” (SOA) (cont’d)  Example SOA for a “Vacation Package” workflow: Chapter 18 Distributed Software Engineering Slide 62 Differences between SaaS and “Service oriented architecture” (SOA) (cont’d)  Individual SOA transactions are typically “brief,” whereby a service is called, does something, and returns a result.  SaaS transactions, in contrast, are usually “long,” e.g., editing a document. (This is a very simplistic generalization – it is not a reliable discriminator) Chapter 18 Distributed Software Engineering Slide 63 Differences between SaaS and “Service oriented architecture” (SOA) (cont’d)  In summary: • SaaS is simply a general software delivery method whereby a software system is hosted remotely on a provider’s server (a “cloud”) – e.g., webbased email. • SOA is a specific implementation strategy for designing and building software products through the composition of existing capabilities and services. • Thus, delivering tax capabilities over the web is SaaS, while enabling a tax application to integrate with IRS services for tax form checking and efiling is SOA. Chapter 18 Distributed Software Engineering Slide 64 Implementation considerations for SaaS  Service configuration: How do you configure the software for the specific requirements of different users/organizations  Multitenancy: How do you give users the impression that they are working with their own copy of the system while, at the same time, making efficient use of system resources  Scalability: How do you design the system so that it can be scaled to accommodate an unpredictably large number of users Chapter 18 Distributed Software Engineering Slide 65 Implementation considerations for SaaS  Service configuration: How do you configure the software for the specific requirements of different users/organizations  Multitenancy: How do you give users the impression that they are working with their own copy of the system while, at the same time, making efficient use of system resources  Scalability: How do you design the system so that it can be scaled to accommodate an unpredictably large number of users Chapter 18 Distributed Software Engineering Slide 66 SaaS service configuration may support:  Branding: users can be presented with an interface that reflects their own organization.  Business rules and workflows: rules that govern the use of the service and its data can be organization specific.  Database extensions: each organization can define extensions to the generic service data model that meet its specific needs.  Access control: organizations can create individual accounts for their staff and define the resources and functions that are accessible to each of them. Chapter 18 Distributed Software Engineering Slide 67 Configuration of a software system offered as a service configurations for different organizations Chapter 18 Distributed Software Engineering Slide 68 Implementation considerations for SaaS  Service configuration: How do you configure the software for the specific requirements of different users/organizations  Multitenancy: How do you give users the impression that they are working with their own copy of the system while, at the same time, making efficient use of system resources  Scalability: How do you design the system so that it can be scaled to accommodate an unpredictably large number of users Chapter 18 Distributed Software Engineering Slide 69 Multitenancy  Multitenancy involves defining a system architecture that: 1. allows many different users to access and efficiently share system resources, and 2. gives each of those users the impression that he is the sole user of the system.  This requires designing the system so that there is an absolute separation between the system functionality and the user data and state . Chapter 18 Distributed Software Engineering Slide 70 Tenant identifiers in a multitenant database Chapter 18 Distributed Software Engineering Slide 71 Implementation considerations for SaaS  Service configuration: How do you configure the software for the specific requirements of different users/organizations  Multitenancy: How do you give users the impression that they are working with their own copy of the system while, at the same time, making efficient use of system resources  Scalability: How do you design the system so that it can be scaled to accommodate an unpredictably large number of users Chapter 18 Distributed Software Engineering Slide 72 General guidelines for achieving scalability  Develop applications where components are implemented as simple, stateless services that can run on any server.  Design the system using messagebased (non synchronous) interaction so that the application does not have to wait for the result of an inter action (such as a read request). (cont’d) Chapter 18 Distributed Software Engineering Slide 73 General guidelines for achieving scalability (cont’d)  Manage resources such as network and database connections as a pool so that no single server is likely to run out of resources.  Design your database to allow finegrain locking. That is, do not lock out whole records when only part of a record is in use. Chapter 18 Distributed Software Engineering Slide 74 Key points  Important benefits of distributed systems: they can be scaled to cope with increasing demand, they can continue to provide user services if parts of the system fail, and they enable resources to be shared.  Issues to be considered in the design of dis tributed systems: transparency, openness, scalability, security, quality of service and failure management. (cont’d) Chapter 18 Distributed Software Engineering Slide 75 Key points (cont’d)  Clientserver systems are structured into layers, with the presentation layer implemented on a client computer. Servers provide data management, application, and database services.  Clientserver systems may have several tiers, with different layers of the system distributed to different computers. (cont’d) Chapter 18 Distributed Software Engineering Slide 76 Key points (cont’d)  Architectural patterns for distributed systems include: masterslave architectures, twotier and multitier C/S architectures, distributed component architectures, and peertopeer architectures.  Distributed component systems are designed as a set of services, without attempting to allocate these services to layers. Middleware handles component communication. (cont’d) Chapter 18 Distributed Software Engineering Slide 77 Key points (cont’d)  Peertopeer architectures support decentralized systems that utilize the power and storage of a large number of networked computers running the same application.  Software as a service (SaaS) is a way of deploying applications as thinclient C/S systems where the software is hosted remotely on servers (“the cloud”) and the client is a web browser. Chapter 18 Distributed Software Engineering Slide 78 Chapter 18 Distributed Software Engineering Chapter 18 Distributed Software Engineering Slide 79