Distributed Software Engineering: Concepts, Issues, and Architectural Patterns, Mitschriften von Computer Vision

These notes describe about the Distributed Applications and what are the types of distributed applications are. About how we can scale in or scale out

Art: Mitschriften

2020/2021

Hochgeladen am 19.06.2022

mohammad-afwan
mohammad-afwan 🇩🇪

5 dokumente

1 / 4

Toggle sidebar

Diese Seite wird in der Vorschau nicht angezeigt

Lass dir nichts Wichtiges entgehen!

bg1
Exercise 2
Task 1
Distributed Software Engineering
The objective of this chapter is to introduce distributed systems
Key issues that must be considered when designing and implementing distributed software
systems
Most computer-based systems are now distributed systems. A distributed system is one
involving several computers rather than a single application running on a single machine
Tanenbaum and Van Steen (Tanenbaum and Van Steen 2007) define a distributed system to
be “a collection of independent computers that appears to the user as a single coherent
system.”
When you are designing a distributed system, there are specific issues that have to be taken
into account simply because the system is distributed. These issues arise because different
parts of the system are running on independently managed computers and because the
characteristics of the network, such as latency and reliability, may have to be considered in
your design.
Five benefits of developing systems as distributed systems:
Resource sharing
Openness
Concurrency
Scalability
Fault tolerance
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 because of the complexity of the interactions between
system components and system infrastructure.
Response time depends on the overall load on the system, its architecture, and the network
load.
The most important developments that have affected distributed software systems in the
past few years are service-oriented systems and the advent of cloud computing, delivering
infrastructure, platforms, and software as a service.
Distributed systems
There is no single authority in charge of the entire distributed system. The network
connecting these nodes is also a separately managed system. It is a complex system and
cannot be controlled by the owners of systems using the network.
Some of the most important design issues that must be considered in distributed systems
engineering are:
Transparency
Openness
Scalability
Security
Quality of service
Failure management
In an ideal world, the fact that a system is distributed would be transparent to users. Users
would see the system as a single system whose behavior is not affected by the way that the
system is distributed.
In practice, this is impossible to achieve because there is no central control over the system
as a whole
pf3
pf4

Unvollständige Textvorschau

Nur auf Docsity: Lade Distributed Software Engineering: Concepts, Issues, and Architectural Patterns und mehr Mitschriften als PDF für Computer Vision herunter!

Exercise 2

Task 1

❖ Distributed Software Engineering

➢ The objective of this chapter is to introduce distributed systems ➢ Key issues that must be considered when designing and implementing distributed software systems ➢ Most computer-based systems are now distributed systems. A distributed system is one involving several computers rather than a single application running on a single machine ➢ Tanenbaum and Van Steen (Tanenbaum and Van Steen 2007) define a distributed system to be “a collection of independent computers that appears to the user as a single coherent system.” ➢ When you are designing a distributed system, there are specific issues that have to be taken into account simply because the system is distributed. These issues arise because different parts of the system are running on independently managed computers and because the characteristics of the network, such as latency and reliability, may have to be considered in your design. ➢ Five benefits of developing systems as distributed systems: ▪ Resource sharing ▪ Openness ▪ Concurrency ▪ Scalability ▪ Fault tolerance ➢ 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 because of the complexity of the interactions between system components and system infrastructure. ➢ Response time depends on the overall load on the system, its architecture, and the network load. ➢ The most important developments that have affected distributed software systems in the past few years are service-oriented systems and the advent of cloud computing, delivering infrastructure, platforms, and software as a service.

❖ Distributed systems

➢ There is no single authority in charge of the entire distributed system. The network connecting these nodes is also a separately managed system. It is a complex system and cannot be controlled by the owners of systems using the network. ➢ Some of the most important design issues that must be considered in distributed systems engineering are: ▪ Transparency ▪ Openness ▪ Scalability ▪ Security ▪ Quality of service ▪ Failure management ➢ In an ideal world, the fact that a system is distributed would be transparent to users. Users would see the system as a single system whose behavior is not affected by the way that the system is distributed. ➢ In practice, this is impossible to achieve because there is no central control over the system as a whole

➢ The CORBA standard (Pope 1997), developed in the 1990s, was intended to be the universal standard for open distributed systems, However, the CORBA standard never achieved a critical mass of adopters. Rather, many companies preferred to develop systems using proprietary standards for components from companies such as Sun (now Oracle) and Microsoft. ➢ The scalability of a system reflects its ability to deliver high-quality service as demands on the system increase. The three dimensions of scalability are size, distribution, and manageability. ➢ Changing the size of a system may involve either scaling up or 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 more resources to the system (e.g., an extra web server to work alongside an existing server). ➢ Scaling out is often more cost-effective than scaling up, especially now that cloud computing makes it easy to add or remove servers from a system. ➢ A distributed system must defend itself against the following types of attack: ▪ Interception ▪ Interruption ▪ Modification ▪ Fabrication ➢ In a distributed system, it is inevitable that failures will occur, so the system has to be designed to be resilient to these failures.

❖ Models of interaction

➢ Two fundamental types of interaction may take place between the computers in a distributed computing system: procedural interaction and message-based interaction. ➢ Procedural interaction involves one computer calling on a known service offered by some other computer and waiting for that service to be delivered. ➢ Message-based interaction involves the “sending” computer defining information about what is required in a message, which is then sent to another computer. Messages usually transmit more information in a single interaction than a procedure call to another machine. ➢ Procedural communication in a distributed system is usually implemented using remote procedure calls (RPCs). ➢ Using that name, a component can call on the services offered by another component as if it was a local procedure or method. ➢ Remote procedure calls require a “stub” for the called procedure to be accessible on the computer that is initiating the call. This stub defines the interface of the remote procedure. The stub is called, and it translates the procedure parameters into a standard representation for transmission to the remote procedure.

❖ Middleware

➢ The components in a distributed system may be implemented in different programming languages and may execute on different types of processors. Models of data, information representation, and protocols for communication may all be different. ➢ A distributed system therefore requires software that can manage these diverse parts and ensure that they can communicate and exchange data. ➢ In a distributed system, middleware provides two distinct types of support: ▪ Interaction support ▪ The provision of common services

❖ Architectural patterns for distributed systems

➢ Designers of distributed systems must organize their system designs to find a balance between performance, dependability, security, and manageability of the system.

Task 3 ❖ Using an example of a remote procedure call, explain how middleware coordinates the interaction of applications in a distributed system. What are the roles of ‘stub’ and ‘skeleton’? ➢ In a remote procedure call, an executing component on one computer (A) calls a procedure or method, which is part of a component that is executing on a different computer (B). The role of the middleware is to coordinate this interaction. There are several steps involved in this: ▪ 1. The provision of a stub procedure with the same interface as the called component. Calling this stub procedure initiates a call to the system middleware. ▪ 2. The middleware running on computer A accepts the call and discovers the location of the called component. ▪ 3. It translates the parameters into a standard format and sends these to computer B along with a request to call the required component. ▪ 4. The middleware on computer B converts the parameters into the appropriate format for the language of the called component and then calls that component. ▪ 5. After execution, the called component returns the result to the middleware on computer B which then translates this into the middleware standard format. ▪ 6. The result is transmitted to the middleware on computer A, which then translates that into the appropriate language format and returns it to the original calling component. ➢ Remote procedure calls require a “stub” for the called procedure to be accessible on the computer that is initiating the call. This stub defines the interface of the remote procedure. The stub is called, and it translates the procedure parameters into a standard representation for transmission to the remote procedure. A server skeleton, the stub on the server side, is responsible for deconversion of parameters passed by the client and conversion of the results after the execution of the function.