SDA

What is a Pattern?
 What is a Pattern?
• Architectural patterns are recurring design decisions found in
practice.
• They offer a reusable solution to common problems in a specific
context.
• Patterns describe a class of architectures and have known properties.
• Tactics are simpler than patterns and address specific design
concerns.
• Patterns need to be augmented with tactics to meet specific system
requirements.
• An architectural pattern includes a context, problem, and solution.
• The solution is described by element types, interaction mechanisms,
topology, and constraints.
 Layer Pattern
• Context: Complex systems require independent development and
maintenance of modules.
• Problem: Segmentation of software for portability, modifiability, and
reuse with minimal interaction.
• Solution: Divide software into layers, each with cohesive modules and
unidirectional usage.
• Elements: Layers (modules grouped together) and their contents.
• Relations: "Allowed to use" relation between layers with defined
rules and exceptions.
• Constraints: All software allocated to one layer, at least two layers,
and non-circular usage relations.
• Weaknesses: Increased upfront cost and complexity, potential
performance penalty.
 Broker Pattern
• Context: Systems with distributed services across multiple servers.
• Problem: How to structure distributed software for easy interoperability and
dynamic binding between service users and providers.
• Solution: The Broker Pattern introduces an intermediary called a broker to
separate clients (service users) from servers (service providers).
• Solution Overview: Clients query the broker via a service interface, and the broker
forwards the request to the appropriate server for processing.
• Elements:
– Client: Requester of services.
– Server: Provider of services.
– Broker: Intermediary that mediates communication between clients and servers, locating
and forwarding requests.
– Client-side proxy: Intermediary managing communication with the broker on the client
side.
– Server-side proxy: Intermediary managing communication with the broker on the server
side.
 Model-View-Controller Pattern
• Context: User interface software is frequently modified, and multiple views of data
are needed.
• Problem: Separating user interface functionality from application functionality
while remaining responsive to user input and changes in application data.
• Solution: The MVC pattern divides the system functionality into three components:
– Model: Contains the application's data and logic.
– View: Displays a portion of the data and interacts with the user.
– Controller: Mediates between the model and the view, managing state change
notifications.
• Solution Overview: MVC separates the concerns of data (model), presentation
(view), and user interaction (controller).
• Elements:
– Model: Represents application data and may include application logic.
– View: User interface component that displays the model and handles user interaction.
– Controller: Manages interaction between the model and the view, translating user actions
into changes in the model or view.
 Pipe and Filter Pattern
• Context: Systems need to transform streams of data items from input to output.
• Problem: Systems must be divided into reusable, loosely coupled components with
simple interaction mechanisms for flexible combination and parallel execution.
• Solution: The Pipe and Filter Pattern involves successive transformations of data
streams.
• Solution Overview: Data flows through filters that transform it, and pipes connect
the output of one filter to the input of the next.
• Elements:
– Filter: Component that transforms data from input to output.
– Pipe: Connector that conveys data from a filter's output to another filter's input without
altering the data.
• Relations: Filters are attached to pipes, connecting their output to another filter's
input.
• Constraints: Pipes connect filter output ports to filter input ports, and connected
filters must agree on the type of data being passed.
 Client-Server Pattern
• Context: There are shared resources and services that distributed clients need to
access and control.
• Problem: Promoting modifiability and reuse by managing shared resources and
services in a centralized manner while distributing the resources across multiple
servers.
• Solution: The Client-Server Pattern involves clients interacting with servers to request
services.
• Solution Overview: Clients initiate interactions by requesting services from servers,
which provide a set of services.
• Elements:
– Client: Component that invokes services from servers.
• Clients have ports that describe the services they require.
– Server: Component that provides services to clients.
• Servers have ports that describe the services they provide.
– Request/reply connector: Data connector using a request/reply protocol for clients to invoke
services on servers.
• Important Characteristics: Local or remote calls, encryption of data.
 Peer-to-Peer Pattern
• Context: Distributed computational entities that are considered equally important
and provide their own resources need to collaborate to provide a service to a
distributed community of users.
• Problem: Connecting distributed computational entities via a common protocol to
organize and share services with high availability and scalability.
• Solution: The Peer-to-Peer (P2P) Pattern involves components directly interacting as
peers.
• Solution Overview: Peers cooperate and collaborate by requesting and providing
services to each other across a network.
• Elements:
– Peer: Independent component running on a network node. Special peers may provide
routing, indexing, and peer search capabilities.
– Request/reply connector: Connects to the peer network, allows searching for other peers,
and invokes services from other peers. In some cases, the need for a reply is eliminated.
• Relations: Peers are associated with their connectors, and attachments may change
at runtime.
 Service Oriented Architecture Pattern
• Context: Multiple services are offered by service providers and consumed by service consumers.
• Problem: Supporting interoperability of distributed components running on different platforms, written in different implementation
languages, and provided by different organizations across the internet.
• Solution: The Service-Oriented Architecture (SOA) Pattern describes a collection of distributed components that provide and/or consume
services.
• Solution Overview: Computation is achieved by a set of cooperating components that provide and/or consume services over a network.
• Elements:
– Components:
• Service providers: Provide one or more services through published interfaces.
• Service consumers: Invoke services directly or through an intermediary. Service providers can also be service consumers.
– ESB (Enterprise Service Bus): Intermediary element that routes and transforms messages between service providers and
consumers.
– Registry of services: Used by providers to register services and by consumers to discover services at runtime.
– Orchestration server: Coordinates interactions between service consumers and providers based on languages for business
processes and workflows.
• Connectors:
– SOAP connector: Uses the SOAP protocol for synchronous communication between web services over HTTP.
– REST connector: Relies on the basic request/reply operations of the HTTP protocol.
– Asynchronous messaging connector: Uses a messaging system for point-to-point or publish-subscribe asynchronous message
exchanges.
• Relations: Components are connected to connectors based on their respective capabilities.
• Constraints: Service consumers are connected to service providers, and intermediary components like ESB, registry, and orchestration
server may be used.
• Weaknesses: Complexity in building SOA-based systems, lack of control over the evolution of independent services, performance overhead
associated with middleware, potential performance bottlenecks in services, and no performance guarantees provided by services.
 Publish-Subscribe Pattern
• Context: There are independent producers and consumers of data that need to interact.
• Problem: Creating integration mechanisms to transmit messages among producers and
consumers without them being aware of each other's identity or existence.
• Solution: In the publish-subscribe pattern, components interact via announced messages or
events.
• Solution Overview: Components can subscribe to a set of events and publishers announce
events. The connector infrastructure delivers the events to registered subscribers.
• Elements:
– Components: Any C&C component with at least one publish or subscribe port.
– Publish-Subscribe Connector: Handles the announcement and delivery of events between components.
• Relations: Components are associated with the publish-subscribe connector, specifying which
components announce events and which components receive events.
• Constraints: All components are connected to an event distributor, which can be viewed as a
bus, connector, or component. Publish ports are attached to announce roles, and subscribe
ports are attached to listen roles.
• Weaknesses: Increased latency, potential negative impact on scalability and predictability of
message delivery time, less control over message ordering, and no guaranteed message
delivery.
 Shared-Data Pattern
• Context: Various computational components need to share and manipulate large amounts of data.
• Problem: Storing and manipulating persistent data that is accessed by multiple independent
components.
• Solution: In the shared-data pattern, interaction revolves around the exchange of persistent data
between data accessors and a shared-data store.
• Solution Overview: Communication between data accessors is mediated by a shared data store,
which can be initiated by accessors or the data store itself. The connector type is data reading and
writing.
• Elements:
– Shared-Data Store: Stores the shared data, including considerations such as data types, performance
properties, data distribution, and access permissions.
– Data Accessor Component: Component that accesses and manipulates the shared data.
– Data Reading and Writing Connector: Facilitates the reading and writing of data between accessors and the
data store.
• Relations: Attachment relation determines which data accessors are connected to which data
stores.
• Constraints: Data accessors interact only with the data store(s).
• Weaknesses: The shared-data store may become a performance bottleneck, a single point of
failure, and there may be tight coupling between producers and consumers of data.
 Map-Reduce Pattern
• Context: Businesses need to analyze large volumes of data quickly, often at the petabyte scale.
• Problem: Efficiently performing distributed and parallel sorting and analysis of large data sets.
• Solution: The map-reduce pattern provides a framework for analyzing distributed data in parallel
across multiple processors.
• Solution Overview: The pattern consists of three parts:
– Specialized infrastructure: Allocates software to hardware nodes in a massively parallel computing
environment and handles data sorting.
– Map component: Programmers specify this component to filter and retrieve the data to be combined.
– Reduce component: Programmers specify this component to combine the results of the map.
• Map-Reduce Solution Elements:
– Map: A function with multiple instances deployed across processors to perform data extraction and
transformation.
– Reduce: A function deployed as one or multiple instances across processors to perform the loading of results.
– Infrastructure: The framework responsible for deploying map and reduce instances, managing data transfer,
and recovering from failures.
• Overview of Execution: Parallelization allows for low latency and high availability. The map performs
data extraction and transformation, while the reduce combines the results.
• Weaknesses: Complexity in designing and implementing the map and reduce components, as well as
managing the infrastructure. The pattern may not be suitable for all types of data analysis tasks.
 Multi-Tier Pattern
• Context: In a distributed deployment, there is a need to distribute a system's infrastructure
into distinct subsets.
• Problem: Splitting the system into independent execution structures, consisting of groups
of software and hardware connected by communication media.
• Solution: The execution structures of many systems are organized into logical groupings
called tiers.
• Solution Overview: The system is divided into tiers, which are logical groupings of software
components.
• Elements:
– Tier: A logical grouping of software components that form an execution structure.
• Relations:
– Is part of: Groups components into tiers, indicating the containment relationship.
– Communicates with: Represents how tiers and their components interact with each other.
– Allocated to: Specifies the mapping of tiers to computing platforms.
• Constraints: A software component belongs to exactly one tier.
• Weaknesses: The Multi-Tier Pattern may involve substantial upfront cost and complexity in
designing and implementing the tiers.
 Tactics and Interactions
• Ping/Echo (Fault Detection Tactic):
– Pluses: Detect faults in the system.
– Minuses (Side Effects): Security concerns (preventing ping flood attacks), performance overhead, and
modifiability challenges (integrating ping/echo into the existing architecture).
• Increase Available Resources:
– Pluses: Improves system performance by providing more resources.
– Minuses (Side Effects): Increased cost (additional resources are more expensive) and the need to efficiently
utilize the increased resources.
• Scheduling Policy:
– Pluses: Enables efficient resource utilization.
– Minuses (Side Effects): Modifiability challenges (adding the scheduling policy to the existing architecture and
changing it in the future).
• Use an Intermediary:
– Pluses: Facilitates the addition of the scheduler to the system.
– Minuses (Side Effects): Modifiability challenge (ensuring all communication passes through the
intermediary).
• Restrict Communication Paths:
– Pluses: Addresses the concern of ensuring all communication passes through the intermediary.
– Minuses (Side Effects): Performance concerns (avoiding excessive performance overhead caused by the
intermediary).