The document provides an overview of architectural patterns in system design, highlighting their importance in determining technology, module interactions, and overall architecture. Key patterns discussed include pipe and filter, layers, shared-data, client-server, publish-subscribe, peer-to-peer, call and return, and blackboard, each with specific use cases and characteristics. Architectural patterns serve as reusable solutions that can significantly influence the performance and scalability of systems.

1. Architectural Patterns
[PART 1]

2. Introduction
Architecture is the system design at the highest
level. All Architectural decisions are made at this
level. For Example decisions about technology to use,
product(s) to use, interfaces, number of modules,
behavior, relationships and interactions of the
modules, scalability and performance.
Changing the architectural decisions will have
significant ripple effects.
Architectural patterns can be an useful aid to
find most suitable architecture for the system.

3. Architectural Patterns
Architectural Patterns • Patterns provide a set of predefined
subsystems, specify their responsibilities and
relationships between them.
• Patterns are reusable and bring well defined
constraints
• Pattern alone or combined can provide
solution for creating architecture for a system

4. Architectural Patterns
Following common patterns will be described in the
subsequent slides.
• Pipe and Filter
• Layers
• Shared-data
• Client-Server
• Publish-subscribe
• Peer-to-peer
• Call and return
• Black Board

5. Pipe and Filter
This pattern can be used to divide system’s task to
different steps. These steps are connected by
dataflow within the system. Output data of one step
can be input data of another step. Each processing
step is implemented by a filter component. Each pipe
implements the data flow between adjacent
processing steps. Filters can be Asynchronous.
Example –
Input
Noise
Detection
(Filter)
Pipe
Noise
Verification
(Filter)
Pipe
Noise
Rectification
(Filter)
output

6. Layers
This pattern can be used for a system that requires
decomposition. System can be decomposed to various
hierarchical level of abstraction. Several operations are on the
same level of abstraction but are largely independent of each
other. Layers communicate between each other using APIs. Each
layer acts as a service provider to above layer.
Example – OSI 7-Layer Model
Each layer is independent of other.
Each lower layer acts as a service
provider to above layer.
Application
Presentation
Session
Transport
Network
Datalink
Physical

7. Shared Data
This pattern can be used for sharing data between components of a
system.
Components are define by two types – Data repositories and Data
accessors.
• Data repositories are permanent storage devices e.g. databases,
files where system stores data. They also take care of
synchronization issues due to concurrent access and provide access
support to data.
• Data accessor components can read and write modified data to it.
Shared data resource can be active agent or passive agent.
Active Agent – any modification to data is informed to all components
Passive Agent – components need to read the data (modified)
whenever they require.
Example – Database oriented systems

8. Client Server
This pattern can be used for communication between two
components Client and Server.
Client - It can only communicate with server and not with other
clients. it can only request to Server and receives reply.
Communication is initiated by a client which sends request and
server responds
Server – It receives the service request from client at a define
port, performs computation and returns the result back to Client
who requested for the service
Connector type is – request/reply, which is asymmetric
Often the client and the server reside on different machines
Example – Distributed systems

9. Peer to Peer
• Peers acts as either clients or servers.
• State and behavior are distributed among peers.
• Peers are independent components, having their own state
and control thread.
• They communicate among themselves using Network
protocols (protocol messages)
• Supports decentralized computing with flow of control and
resources distributed among peers.
• Components use services from each other through methods
• Highly robust in the face of failure of any given node.
• Scalable in terms of access to resources and computing
power.

10. Publish-Subscribe
This pattern can be used in systems where an only send messages to the applications that are
interested in receiving the messages without knowing the identities of the receivers.
The are three variation of the Publish-Subscribe pattern
• List-Based Publish/Subscribe Publish component will maintain a list of subscribers for a subject. When events occur for that subject,
each subscriber on the subscription list is notified.
All interested Subscribe components will register with Publish component for the subject
• Broadcast-Based Publish/Subscribe When an event occurs, Publisher creates a message and broadcasts it to the local area network (LAN).
All Subscriber matches the subject line to a subject that it subscribes to. If the subject does not match, it
ignores the message.
To identify subscribers topic, Publisher sends a broadcast message that asks Subscribers to reply if they
subscribe to a particular topic. Responses are then returned by Subscribers to the Publisher to identify
the Subscribers.
It is an effective method for decoupling producers from consumers.
• Content-Based Publish/Subscribe –
In this case subscriptions are related to specific information content.
Messages are intelligently routed to their final destination based on the content of the message. This
approach overcomes the limitation of a broadcast-based system, where distribution is coupled to a
multicast tree that is based on Transmission Control Protocol (TCP).

11. Call and Return
• Consumer components invoke functionality in Provider
components.
• Consumer components waits until an invoked service
completes and returns results before continuing
• components depend on invoked functionality to get their own
work done
• The correctness of each component may depend on the
correctness of the functionality it invokes
• Inter-process calls or Remote procedure calls in a distributed
set of processes or a network of computers
.

12. Blackboard
This pattern is useful for problems for which no deterministic solution
strategies are known.
Several specialized subsystems assemble their knowledge to build a possibly
partial or approximate solution.
System is divided into 1. Blackboard, 2. A collection of knowledge sources, 3.
Control Component
Blackboard - It is the central data store for solution space and control data. It
provides interface that enables all knowledge sources to read from and write
to it
Knowledge Sources - They are separate, independent subsystems that solve
specific aspects of the overall problem. A solution can only be built by
integrating the results of several knowledge sources
Control Components : It runs a loop to monitor the changes on the
blackboard. It will pick a knowledge source and decide what action to take
next according to a knowledge application strategy
Example - HEARSAY-I1 speech recognition system

13. Thank You
Your suggestions and comments are always welcome.
Please send me your feedback at
a_s_sinha@yahoo.com