0% found this document useful (0 votes)
28 views14 pages

What Is A Pattern?

The document provides definitions and examples of several common architectural patterns, including layer pattern, broker pattern, model-view-controller pattern, pipe and filter pattern, client-server pattern, peer-to-peer pattern, service oriented architecture pattern, and publish-subscribe pattern. Each pattern is described in terms of its context, problem it addresses, proposed solution, key elements, and relationships between elements.

Uploaded by

agumas474
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as PPTX, PDF, TXT or read online on Scribd
0% found this document useful (0 votes)
28 views14 pages

What Is A Pattern?

The document provides definitions and examples of several common architectural patterns, including layer pattern, broker pattern, model-view-controller pattern, pipe and filter pattern, client-server pattern, peer-to-peer pattern, service oriented architecture pattern, and publish-subscribe pattern. Each pattern is described in terms of its context, problem it addresses, proposed solution, key elements, and relationships between elements.

Uploaded by

agumas474
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as PPTX, PDF, TXT or read online on Scribd
You are on page 1/ 14

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

You might also like