Handout12.docx

**Week\#13 - Distributed Software Engineering** +-----------------------------------------------------------------------+ | **Topics** | +=======================================================================+ | - Distributed systems...

**Week\#13 - Distributed Software Engineering** +-----------------------------------------------------------------------+ | **Topics** | +=======================================================================+ | - Distributed systems | | | | - Middleware | | | | - Client--server computing | | | | - Distributed systems architecture patterns | | | | - Software as a service and service-oriented architecture (SOA) | +-----------------------------------------------------------------------+ **Distributed systems** Distributed systems now make up the majority of large computer-based systems. A collection of separate computers that, to the user, functions as a single, cohesive system. Instead of being limited to a single computer, information processing is spread among a number of them. Distributed software engineering is therefore essential for business computer systems. **Characteristics of distributed systems** - Scalability: Added more resources to increase throughput. - Concurrency: Processing in several threads to improve performance. - Openness: Utilization of hardware and software from several vendors. - Resource sharing: The sharing of computer hardware and software. - Defect tolerance: The capacity to carry on with operations notwithstanding the presence of a problem. **Difficulties with distributed systems** - Systems with many processors are more advanced than those with just one processor. - Complexity grows as a result of the network and other system components being maintained separately. - Because the system is not controlled by a single entity, top-down control is not feasible. **Design challenges** - **Scalability**: What design elements can be used to make the system scalable? - **Failure management**: What steps can be taken to identify, contain, and fix system failures? - **Transparency**: How should the user be able to perceive the dispersed system as one system? - **Security**: What are some practical ways to develop and apply security policies? - **Openness**: Should interoperable standard protocols be used in the design of a system? - **Service quality**: How should service quality be defined? - **Scalability** - Size: A system should have the ability to accommodate growing user populations by adding more resources. - Dispersion: The parts of a system should be able to be geographically separated without the system performing worse. - Adaptability: A system should be able to be managed as it grows, even if some of its components are spread across different organizations. - **Failure management** - **Transparency** - **Security** - **Different attack types** An attack on a distributed system must be defended against in the following ways: - - **Interruption**, in which system services are assaulted and rendered incapable of performing as intended. - **Interception**, when a hacker intercepts communications between system components, causing a loss of confidentiality. - **Denial of service** **attacks** include flooding a node with erroneous service requests in order to prevent it from responding to real ones. - **Modification**, where a hacker changes the system\'s data or services. - **Fabrication**, when a hacker fabricates data that isn\'t supposed to be there and utilizes it to break into a system. - **Openness** - **Service quality** **Interactional models** Two different ways that components of a distributed system interact with one another. - **Procedural interaction**, in which one computer asks another computer for help with a known service and then waits for a response. - **Message-based interaction**, one computer communicates with another by sending the other computer the information that is needed. There is no need to hold off until you hear back. Figure 13.1. Procedures involving a diner and a waiter  Figure 13.2. Iinteractions between the kitchen and a waiter via messages **Remote procedure calls** The method used to implement procedural communication in distributed systems is known as a remote procedure call (RPC). In a RPC, a component addresses another component as if it were a local method or procedure. The middleware of the system picks up this call and routes it to a remote component. This does the necessary computation and sends the output to the called component using middleware. RPCs have the drawback that both the caller and the caller must be available and aware of how to refer to one another at the time of the call. **Passing message** In message-based interactions, one component often creates a message outlining the assistance that is needed from another component. This is transmitted to the receiving component via the system middleware. The receiving component receives the message, processes it, and generates a message with the necessary results for the sending component. The sender and the recipient of the message do not have to be aware of one another in a message-based method. They merely exchange messages with the middleware. **Middleware** Various programming languages and various types of processors may be used to implement the components of a distributed system. Data models, information representations, and communication methods can all vary. Software called middleware can control these many components, ensuring that they can communicate and share information. Support for interactions provided by middleware, which coordinates interactions between various system components. The middleware offers location transparency by removing the need for components to be aware of the precise positions of one another. Providing reusable implementations of common services that may be required by various distributed system components through the use of middleware. By utilizing these common functions, interoperated components can simply provide user services in a consistent manner. Figure 13.3. Distributed systems\' middleware **Client-server computing** Client-server systems are the typical organizational structure of distributed systems that may be accessed via the Internet. The user interacts with an application running on their personal device (such as a mobile or web browser application) in a client-server system. This communicates with an additional program that is running on a different computer (like a web server). Services like web page access are provided by the remote computer for the benefit of outside clients. - **Client/server system layers** - **Presentation**: responsible for informing the user and controlling all user interaction. - **Application processing layer**: responsible for carrying out the application\'s logic and giving users the necessary functionality. - **Data access logic**: controls the data sent to and received from the client such as data checking, searching, indexing etc. - **Data storage**: Holds data.  Figure 13.4. Client-server application architecture in layers **Distributed systems architecture patterns** - **Master-slave architecture**: it is used in real-time systems when specified interaction response times are required. - **A two-tier client server architecture:** it is utilized for straightforward client-server systems and centralized for security. - **Multi-tier client server architecture**: it is utilized when the server must process a large number of transactions. - **Distributed component architecture**: It is used as an implementation paradigm for multi-tier client-server systems or when it\'s necessary to combine resources from several systems and databases. - **Peer-to-peer architecture**: It is used when clients exchange information that is stored locally and the server\'s responsibility is to connect clients. - **Master-slave architectures** Figure 13.5. A master-slave architecture for traffic control system - **Two-tier client server architectures**  Figure 13.6. Functional models for thin client and fat client - **Thin client model** Utilized for converting legacy systems to client-server architectures. With a graphical user interface installed on a client, the legacy system serves as a server within itself. One major disadvantage is the server and network\'s heavy processing load. - **Fat client model** - **Multi-tier client-server architectures** Figure 13.7. A system with three tiers for online banking **Using client-server architectural design principles** --------------------------------------------------------- ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- **Architecture** **Application** Thin clients and a two-tier client server architecture Legacy system applications are employed when it is impracticable to separate application processing from data management. Clients may access programs that require a lot of computation, like compilers, but do few or no application processing and data management. Applications (browsing and querying) that require a lot of data but do not require a lot of processing. The most prevalent instance of using this architecture is when browsing the Web. Fat clients and a two-tier client-server architecture Applications where client-side commercial software (like Microsoft Excel) handles application processing. Applications where the processing of data requires computationally demanding methods (such as data visualization). Applications for mobile devices where internet connectivity is not guaranteed. It is therefore possible to perform some local processing utilizing database information that has been cached. Client-server architecture with many tiers Applications on a large scale with a huge number of users. Applications that are volatile in terms of both the application and the data. Applications that incorporate data from several sources. - **Distributed component architectures** - Scalability and flexibility of the system. - It enables the system designer to put off choosing where and how to deliver services. - The system can be dynamically reconfigured with objects moving across the network as needed. - It has a very flexible system architecture that enables the addition of new resources as needed. - Distributed component architectures have two significant drawbacks: - They require higher design complexity than client-server systems. People find it challenging to envision and comprehend distributed component designs. - The community has never approved standardized middleware for distributed component systems. Different companies have created incompatible middleware, including Microsoft and Sun. - Due of these issues, service-oriented designs are frequently taking the place of distributed component systems. - **Peer-to-peer architectures** **Example of Peer-to-peer systems** - Messaging systems such as Line - Phone systems -- Viber - BitTorrent-based file-sharing systems - Bitcoin-based payment systems - Computer systems in SETI\@home - Databases like the decentralized Freenet  Figure 13.8. A decentralized peer-to-peer system Figure 13.9. A hybrid centralized-p2p architecture **Software as a service** Software as a service (SaaS) includes to the process of hosting a program online and maintaining remote access to it. Software that is installed on a server (or, more typically, a number of servers) can be accessed via a web browser online. On a local computer, it is not configured. The software is belonged and maintained by a software supplier rather than the companies who use it. Users have the alternative of purchasing the software through a yearly, monthly, or usage-based subscription. - **Modifiability**: How is the software set up to meet the unique needs of each organization? - **Multiple tenancy**: How can system resources be used effectively while giving each software user the perception that they are using the system that was installed in their own device? - **Ability to scale**: How can the system be built to grow to accommodate an unexpectedly high number of users? - Workflows and business rules, where each company establishes its own rules for using the data and services. - Database modifications, in which each company specifies how the general service data model is expanded to suit its unique requirements. - Branding, in which users are shown an interface that represents their own organization. - Access control, where service users set up separate user accounts for each member of their staff and specify the resources and features that each user can access. - Multi-tenancy occurs when multiple users simultaneously access the same system, and the architecture of the system is designed to facilitate effective resource sharing and utilization. - Each user must feel as though they are the only ones using the system. - Multi-tenancy entails structuring the system in such a way that the system\'s data and operation are completely segregated from one another. - Create applications with each component built as a straightforward, server-independent stateless service. - Use asynchronous interaction while designing the system to avoid making the program wait for responses to interactions (like read requests). - Control shared resources, like network and database connections, to prevent resource shortages on any one server. - Consider fine-grained locking while designing your database. In other words, avoid locking off entire database records when only a portion of a record is being used. **Summary** - The advantages of distributed systems include their scalability to handle rising demand, their ability to continue serving users even if certain components of the system fail, and their ability to share resources. - Scalability, openness, transparency, security, failure management, and quality of service and are factors to be taken into account while designing distributed systems. - Client-server systems are divided into levels, with the client computer serving as the presentation layer. Servers offer database, application, and data management services. - Client-server systems may have multiple tiers, with the system\'s various layers being dispersed among various machines. - Middleware is needed in distributed component systems to manage component interactions and to enable for the addition and removal of components. - Peer-to-peer architectures lack distinct clients and servers and are decentralized. Multiple systems in various organizations can be used to disperse computations. - Application deployment using thin client server systems, with the client using a web browser to access the services, is known as \"software as a service.\"