SOFTWARE ARCHITECTURE-
MODULE - 3
SOFTWARE ARCHITECTURE STYLE
TABLE OF CONTENTS
1.1 Learning Objectives
1.2 Software Architectural Patterns
1.2.1 Layers of abstraction Architectural Pattern,
1.2.2 Call/Return Pattern
1.2.3 Asynchronous Message Communication Pattern,
1.2.4 Synchronous Message Communication Pattern
1.3 Different case studies for implementation of these style
1.4 Summary
1.5 Self-assessment questions
1.6 References
LEARNING OBJECTIVES
After completing this module, the learner will be able to
1. Understand meaning of Software Architectural Patterns
2. Understand the Layers of abstraction Architectural Pattern,
3. Understand the Call/Return Pattern
4. Understand Asynchronous and Synchronous Message Communication Pattern
1
Software Architecture Style:
It's likely that as a software architect, you will frequently encounter the same objectives and
issues. Architectural patterns offer repeatable solutions that handle frequent scenarios, which
facilitates the resolution of these problems.
It comprises of a few essential elements and guidelines for putting them together in a way that
maintains architectural integrity. What establishes an architectural pattern is:
A grouping of different element kinds (such an information store or an algorithmic part).
A set of semantic constraints (e.g., filters in a pipe-and-filter style are pure data transducers—
they incrementally transform their input stream into an output stream, but they do not control
either upstream or downstream elements).
A topological layout of the elements indicating their relationships.
A group of interaction mechanisms (such as blackboard, event-subscriber, and subroutine call)
that control how the elements cooperate within the permitted topology.
So the
Formal Definition:
The architectural pattern is a way to save and reuse the design structures of different software
components and systems. Software developers frequently run across the same issues when
developing code—between projects, within organisations, and throughout their careers. Design
patterns provide engineers with a reusable method to overcome these issues, enabling software
developers to accomplish the same result architecturally for a particular project. This is one
technique to resolve this."
Advantages of Architecture Style:
There are numerous advantages to using architectural patterns in your software designs.
They increase your efficiency.
productivity
Speed
Optimize development costs
2
Improve planning
There are many different types of enterprise architect design patterns you can tap into.
Different architectural Style/Patterns:
Following are the different architectural styles.
• Layers of abstraction Architectural Pattern,
• Call/Return Pattern
• Asynchronous Message Communication Pattern, Synchronous Message Communication
Pattern
• Microservices Pattern
• Client-Server Pattern
• Cloud Architectural Pattern
Layers of abstraction Architectural Pattern:
Among developers, the layered architectural pattern is the most popular. Programmes with
multiple sets of subtasks, each at a distinct degree of abstraction, can benefit from it. A layer in
the programme represents each of these subtasks; it is a unit of modules that generates a
coherent collection of services, and each layer serves the subsequent layer in a unidirectional
manner.
Within the application, each layer plays a distinct role that is interconnected with the roles of
other layers. For example, all UI and browser communication logic would be handled by the
presentation layer, often known as the UL layer, while specific business requirements would be
carried out by the business logic layer.
3
Figure: Various layers in layered architecture.
Within the programme, each layer of the layered architecture pattern has a distinct function and
duty. A business layer, on the other hand, would be in charge of carrying out particular business
rules connected to the request, while a presentation layer would handle all user interface and
browser communication logic. Every architectural layer creates an abstraction around the tasks
required to fulfil a certain business request.
Example:
The presentation layer merely needs to display client data in a specific format on a screen; it
doesn't need to know how to obtain that data or worry about [Link] to this, the business
layer's only job is to retrieve data from the persistence layer, apply business logic to it (such as
calculating values or aggregating data), and then forward that information to the presentation
layer. It need not worry about how to format customer data for screen display or even where the
customer data originates from.
Features:
Part of layered architecture is dividing up the responsibilities of different parts. Only logic
specific to that layer is dealt with by components inside that [Link] instance, elements
belonging to the business layer exclusively handle business logic, while elements in the
presentation layer exclusively deal with presentation logic. Because of the well-defined
4
component interfaces and constrained component scope of this kind of component
classification, it is simple to incorporate roles and responsibility models into your architecture
and to develop, test, govern, and maintain applications using this architecture pattern.
Working of layered architecture:
Take note of how the architecture's layers are all designated as closed in the figure. In the
context of the layered architecture pattern, this idea is crucial. A closed layer requires that
requests pass through the layer immediately below them in order to reach the layer that comes
after them. A request coming from the display layer, for instance, has to pass via the persistence
layer, business layer, and database layer before it can reach the database layer.
Figure: A request flow
layers of isolation:
So why not grant direct access to the persistence layer or database layer from the presentation
layer? In the end, retrieving or saving database information directly from the presentation layer
is far faster than passing through numerous pointless layers. Layers of isolation is a crucial idea
that holds the key to the answer to this dilemma.
According to the notion of layers of isolation, modifications made to one layer of the
5
architecture often have no effect on or influence on elements in other layers:
Changes made to SQL within the persistence layer would affect both the business layer and the
presentation layer if you provide the presentation layer direct access to the persistence layer.
This would result in an extremely tightly connected programme with numerous
interdependencies between components. Changing this kind of building subsequently becomes
exceedingly difficult and costly.
Figure: Data flow between layers
Conclusion:
For most projects, the layered architecture pattern is a smart place to start because it is a strong
general-purpose design. This is especially true if you are unsure of which architecture pattern
will work best for your application.
Call/Return Pattern:
Call and Return Architectures: They are used to build easily scalable and modifiable
programmes. This category contains a wide variety of sub-styles. Below is an explanation of
two of them.
Remote procedure calls Architecture: These components are dispersed among several
computers on a network and utilised to exhibit in a main programme or sub programme
6
architecture.
Main program or Subprogram architectures: A control hierarchy or a multitude of
subprograms comprise the primary programme structure. Numerous subprograms in the main
programme have the ability to call other components.
A system in which clients ask servers for resources, services, or data, and servers respond by
carrying out the requested operations and sending the results back to the clients is described by
the "Call/Return" architectural pattern, also referred to as the "Client/Server" architectural
pattern.
Working:
Client Component: Clients call or send messages to server components to start requests.
Applications, users, and other systems that need access to the server's services might all be
considered clients.
Server Component: Client requests are received by servers, which then process them and return
the information. Depending on the requirements and scalability demands of the system, servers
might be dispersed or centralised.
Communication Protocol: Predefined protocols, like HTTP, TCP/IP, or bespoke protocols, are
used by clients and servers to communicate. These protocols specify the message format, the
guidelines for exchanging information, and the error-handling and security procedures.
Request Handling: In response to incoming requests, servers carry out the specified actions or
make the necessary resource requests. This could entail using databases, processing data,
carrying out business logic, or communicating with other services.
Response Generation: Following the processing of a request, servers provide responses that
include the information or results of the requested operation. Messages or data packets are
typically used to deliver responses back to the customers.
7
Security: Call/Return architectures use data validation, authentication, encryption, and
authorization as security mechanisms to safeguard communication between clients and servers.
In many different kinds of distributed systems, such as web applications, client-server
applications, microservices architectures, and service-oriented architectures (SOA), the
Call/Return architectural pattern is frequently employed. In order to meet corporate needs and
provide services to end users, it offers a flexible and scalable method for building systems with
clients and servers interacting.
Message Communication Pattern:
Messages are an interface via which applications can exchange data with one another. They are
a way to package data payloads and related metadata. The producer is the application that sends
the message, and the consumer is the application that receives it. A range of communication
channels, such as point-to-point requests, message queues, subscription topics, or event buses,
are used by producers and consumers to exchange messages. These transportation channels are
helpful for creating message transmission patterns due to their various properties. When
producers and consumers couple—a process that involves exchanging messages—dependencies
arise.
There are two types of Message Communication Pattern:
Asynchronous Message Communication Pattern:
Synchronous Message Communication Pattern:
Asynchronous Message Communication Pattern:
Asynchronous message communication occurs when a message is sent by the producer
to the customer and moves forward without waiting for a reply.
When a client publishes a message to a queue, and the queue confirms receipt of the message,
the publisher moves forward without waiting for the consumer to receive the message. This is
an example of asynchronous communication over a message queue channel.
8
Figure: Asynchronous message communication
Transport channels like topics, queues, and event buses are used to design asynchronous
communication patterns, which loosely couple producers and consumers. Because loose
coupling establishes an indirection between producer and consumer communication, allowing
them to function independently of one another, it improves an architecture's resilience to failure
and capacity to handle traffic spikes. To allow the web, logic, and data tiers to scale
independently of one another, a message queue can be inserted between them using the example
of a three-tier design. A surge in client traffic to the application causes the web tier to transform
it into extra messages being added to the queue for processing; however, this does not
necessarily affect the logic tier, which may continue to process messages off the queue.
Synchronous Message Communication Pattern:
Synchronous message communication occurs when the sender sends a message to the recipient
and then pauses processing logic until the recipient responds. The process by which an HTTP
client sends a request to an HTTP service, waits for the service to process it, and then uses logic
to interpret the HTTP answer to decide what to do next is an example of synchronous
communication over a point-to-point channel.
Although synchronous communication patterns are easier to set up, they lead to close
relationships between producers and customers.
9
Figure: Synchronous Message Communication
Because traffic surges and failures propagate directly throughout the application, tight coupling
can lead to issues. In a three-tier architecture, for instance, a spike in client traffic experienced
by the application is instantly translated by the web layer as pressure on the logic and data tiers,
which may not be able to handle the unexpected demand. Similarly, the web tier's ability to
respond to client requests is immediately impacted by downstream resource failure in the logic
or data tier.
Case Studies:
In order to demonstrate the significance of software architecture, let's look at two actual case
examples.
Case Study No. 1: Netflix
The massively popular streaming service Netflix has a microservices architecture that is
extremely scalable. Specific tasks, like content distribution, user management, and
recommendation processing, are handled by each microservice. With this strategy, Netflix is
able to offer a flawless streaming experience while meeting the ever-increasing demands of its
users.
Amazon Web Services (AWS) Case Study 2
One of the top cloud service providers in the world, AWS, uses service-oriented architecture, or
SOA, to provide a wide range of cloud services. Customers can use APIs to access and utilise
each independent component of AWS services, which gives them flexibility and scalability
when developing applications.
10
Summary:
Any effective software system is built on its software architecture. Systems can be designed to
be not only functional but also manageable and flexible by architects and developers by
following fundamental principles like modularity, abstraction, scalability, and security.
Although certain architectural styles, such as message communication, layered architecture etc
are available to design the system architecture and have their own advantages, the project's
objectives and requirements should be taken into consideration when selecting an architecture.
The correct tools, effective communication, and documentation are necessary to convert an
architectural idea into a dependable software system.
Self-assessment questions:
I. Long questions:
1. Explain Layers of abstraction Architectural Pattern and explain how it is different from
Call-Return architecture.
2. Discuss Synchronous Message Communication Pattern with suitable example.
II. Short questions:
1. Explain what Software Architecture Style is and enlist different Software Architecture
Style:
2. Distinguish Synchronous and Asynchronous Message Communication Pattern.
3. What advantages are offered by layered architecture?
III. Multiple Choice Questions
1. Architectural styles are used to,
A. Uncovers requirements engineering
B. Defines constraints of the system to be built
C. Architectural style and/or combination of patterns
D. All of the mentioned above
11
2. Amongst which of the following is / are the true for Main program/subprogram
architectures.
A. A classic program structure
B. Decomposes function into a control hierarchy
C. A "main" program invokes a number of program components
D. All of the mentioned above
3. Amongst which of the following is / are the taxonomy of architectural styles,
A. Data-Centered Architectures
B. Data-Flow Architectures
C. Call and Return Architectures
D. Object-oriented Architectures
(Ans: 1. D, 2. D, 3 D)
IV. True and False:
1. In Layered Architectures, the outer layer defines interface operations; inner layer defines
operating system interfacing while intermediate layers provide utility services and
application software functions.
2. Call and return architectures are easily to achieve a program structure which is, Easy to
modify and scale
3. architectures design constitutes a relatively very large model of how the system is
structured
4. Architectural design describes about the, Structure of data and program component.
Ans: 1. True, 2. True, 3. False, 4. True
12
REFERENCES
1. Hassan Gomaa “Software Modeling and Design “ Cambridge University Press
2. Stephen T Albin “ The Art of Software Architecture” Design Methods and Techniques”
WILEY
3. Jones & Bartlett Learning, 2010 Software Architecture and Design Illuminated
4. Martin Fowler, David Rice, Matthew Foemmel, Edward Hieatt, Robert Mee “Patterns of
Enterprise Application Architecture” Addison Wesley
13