CH - 11

Distributed
Software
Engineering

1
Topics
◦ Distributed systems
◦ Middleware
◦ Client–server computing
◦ Distributed systems architecture patterns
◦ Software as a service and service-oriented architecture (SOA)

2
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.

3
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.

4
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.

5
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?

6
Scalability
A system's capacity to provide a high-quality service as demands on it rise is
measured by its 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.
Scaling-out and scaling-up are independent concepts. Scaling out creates
additional system instances while scaling up creates a more powerful system.

7
Failure management
Because errors are bound to happen in distributed systems, the system must be
built to be resilient to them. You can tell you have a distributed system when
you are unable to complete any work because of the failure of a system you
have never heard of.
Distributed systems must include procedures for determining when a system
component has failed, should keep providing as many services as they can in
spite of the failure, and should, to the extent possible, automatically recover
from the failure

8
Transparency
Ideally, services should be independent of distribution features. In a distributed
system, consumers shouldn't be aware of it.. Due to network latency and the
autonomous management of several system components, this is actually not
possible.
It is frequently preferable to inform users about distribution so they can deal
with issues. Resources should be abstracted and dealt with conceptually rather
than physically in order to achieve transparency. Logical and physical resources
are mapped via middleware.

9
Security
Compared to centralized systems, the number of methods that a distributed
system can be attacked is substantially greater. The attacker could be able to
exploit a successful attack on one component of the system as a "back door"
onto other components.
A distributed system faces challenges because various organizations may own
various components of the system. These companies might use security
measures and policies that are incompatible with one another.

10
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.

11
Openness
Open distributed systems are those that are created in accordance with
acknowledged industry standards. Any supplier's components may be
incorporated into the system and may interact with other system components.
System components can be freely written in any programming language,
according to openness and will interact with other components if they adhere to
standards. Web service standards were created as open standards for service-
oriented architectures.

12
Service quality
A distributed system's capacity to reliably deliver its services with a response
time and throughput that are acceptable to its customers is indicated by the
quality of service it offers. When the system is handling time-sensitive data, like
sound or video streams, quality of service is especially important.
If the level of service drops below a certain point in certain conditions, the
sound or video may deteriorate to the point where it is hard to interpret.

13
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.

14
Procedures involving a diner and a waiter

15
Interactions between the kitchen and a waiter via messages

16
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.

17
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.

18
 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.
19
Distributed systems' middleware

20
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.

21
 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.

22
Distributed systems
architecture patterns
Common techniques for structuring a distributed system's architecture:-
◦ 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.

23
Master-slave architectures
Master-slave architectures are widely used in real-time systems, where there
may be various processors for obtaining data from the system's environment,
data processing and computing, application processing, and controller
management.
The 'master' process, which frequently control over the 'slave' processes,
manages computation, coordination, and communication.
"Slave" processes are devoted to particular tasks, such collecting data from a
variety of sensors.

24
Master-slave architectures

25
Two-tier client server
architectures
A single logical server and a variable number of clients that access to
the server are how the system is implemented in a two-tier client
server architecture. The thin-client approach, in which the data
storage, data access logic, and application processing are all
implemented on a server while the presentation layer is processed
on the client. A fat-client architecture, in which some or all
application processing is processed on the client. The server
implements data storage and data access logic functions.

26
Two-tier client server
architectures

27
Two-tier client server
architectures
◦ 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

Because the application processing is carried out locally, more processing is
transferred to the client. Most appropriate for new C/S systems if the client
system's capabilities are understood in advance. More difficult to manage,
especially when compared to a thin client paradigm. All clients must have the
most recent versions of the application installed.

28
Multi-tier client-server
architectures
In a "multi-tier client-server" architecture, the presentation,
application processing, data access logic and data store layers of the
system are independent processes that may run on various
processors. This prevents issues with system management if a fat-
client paradigm is employed as well as scalability and performance
issues in the case of a thin-client two-tier model.

29
Multi-tier client-server
architectures

30
Using client-server architectural design principles

Architecture Application
Thin clients and a two- Legacy system applications are employed when it is impracticable to separate
tier client server application processing from data management. Clients may access programs that
architecture 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 Applications where client-side commercial software (like Microsoft Excel) handles
client-server architecture 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 Applications on a large scale with a huge number of users. Applications that are
with many tiers volatile in terms of both the application and the data. Applications that incorporate
data from several sources.

31
Distributed component
architectures
Clients and servers are not separate in a distributed component
design. Every distributable entity is a component that both offers and
receives services from other components. A middleware system is
used for component communication.

32
Distributed component
architectures
A distributed component architecture's advantages

◦ 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.

33
Distributed component
architectures
Distributed component architecture's drawbacks

◦ 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.

34
Peer-to-peer architectures
Peer to peer (P2P) systems are decentralized systems in which any
network node may perform computations. The whole system is built
to benefit from the processing power and storage of many
networked computers. P2P networks have traditionally been used
mostly by individuals, although corporate applications are growing.
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

35
Peer-to-peer architectures

A decentralized peer-to-peer system

A hybrid centralized-p2p architecture

36
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.

37
Software as a service (SaaS)
and service-oriented
architecture (SOA)
The provision of functionality on a remote server with client access
via a web browser is known as "software as a service." Throughout
an interaction session, the server keeps track of the user's
information and state. Transactions, like changing a document, are
frequently lengthy transactions.
A software system can be organized using a service-oriented
architecture as a collection of independent, stateless services. These
could be disseminated and offered by many suppliers. Transactions
are often brief operations in which a service is called, performs some
activity, and then returns a result.

38
SaaS implementation factors
◦ 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?

39
SaaS implementation factors
Modifiability
◦ 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.

40
SaaS implementation factors
Multi-tenancy
◦ 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.

41
SaaS implementation factors
Ability to scale
◦ 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.

42
 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."

43
## Exercise Questions

What Exactly Are Distributed Systems?

Please provide some examples of distributed systems.

Is cloud computing a service provided by distributed systems?

44