Your browser doesn't support the features required by impress.js, so you are presented with a simplified version of this presentation.

For the best experience please use the latest Chrome, Safari or Firefox browser.

Architectural Patterns

Prof. Cesare Pautasso
http://www.pautasso.info
cesare.pautasso@usi.ch
@pautasso

How to Design

Grady Booch

How to Design

Grady Booch

Why patterns?

Patterns help you build on the collective experience of many skilled software engineers

Defining Patterns

Each pattern describes a problem which occurs over and over again in our environment, and then describes the core of the solution to that problem, in such a way that you can use this solution a million times over, without ever doing it the same way twice

Christopher Alexander - A Pattern Language, 1977

Patterns

Goal: practical advice and solutions to concrete design problems

A pattern is a standard solution to common and recurring design problems

Related: related (but different) to Object-Oriented Design Patterns

Hint: apply patterns where they actually solve a problem

Warning: as with all design decisions, all consequences of choosing to use a pattern should be evaluated and fully understood

Design Patterns

Capture the static and dynamic roles and relationships in solutions that occur repeatedly

Douglas C. Schmidt

Architectural Patterns

Express a fundamental structural organization for software systems that provide a set of predefined subsystems, specify their relationships, include the rules and guidelines for organizing the relationships between them

Architectural Styles

General constraints: Usually there is one dominant style for each architecture.

George Fairbanks

Architectural Patterns

Fine-grained constraints: Many patterns are usually combined. The same pattern can be used many times

Layered

  1. State-Logic-Display
  2. Model-View-Controller
  3. Presenter-View

State-Logic-Display

Goal: separate elements with different rate of change

cluster elements that change at the same rate

Pattern: apply the layered style to separate the user interface (display/client), from the business logic (server), from the persistent state (database) of the system

State-Logic-Display

Model-View-Controller

Goal: support many interaction and display modes for the same content

separate content (model) from presentation (output) and interaction (input)

Pattern: model objects are completely ignorant of the UI. When the model changes, the views react. The controller's job is to take the user's input and figure out what to do with it. Controller and view should (mostly) not communicate directly but through the model.

Model-View-Controller

Presenter-View

Goal: keep a consistent look and feel across a complex UI

extract the content from the model to be presented from the rendering into screens/web pages

Pattern: Apply separation of concerns. The presenter extracts and prepares the logical content to be displayed. The view formats the content consistently (possibly using templates).

Synonym: two-step View

Presenter-View

Components

  1. Interoperability
  2. Directory
  3. Dependency Injection

Interoperability

Goal: enable communication between different platforms

map to a standardized intermediate representation and communication style

Pattern: components of different architectural styles running on different platforms are integrated by wrapping them with adapters. These adapters enable interoperability as they implement a mapping to common means of interaction.

Interoperability

Interoperability

Directory

Goal: facilitate location transparency (avoid hard-coding service addresses in clients)

use a directory service to find service endpoints based on abstract descriptions

Pattern: clients lookup services through a directory in order to find out how and where to invoke them

Directory

Directory

Dependency Injection

Goal: facilitate location transparency (avoid hard-coding service addresses in clients)

use a container which updates components with bindings to their dependencies

Pattern: clients expose a mechanism (setter or constructor) so that they can be configured

Dependency Injection

Dependency Injection

Notification

  1. Event Monitor
  2. Observer
  3. Publish/Subscribe
  4. Messaging Bridge
  5. Half Synch-Half Asynch

Event Monitor

Goal: inform clients about events happening at the service

poll and compare state snapshots

Pattern: clients use an event monitor that periodically polls the service, compares its state with the previous one and notifies the clients about changes

Event Monitor

Event Monitor

Observer

Goal: ensure a set of clients gets informed about all state changes of a service as soon as they occur

detect changes and generate events at the service

Pattern: clients register themselves with the service, which will inform them whenever a change occurs

Observer

Observer

Publish/Subscribe

Goal: decouple clients from services generating events

factor out event propagation and subscription management into a separate service

Pattern: clients register with the event service by subscribing to certain event types, which are published to the event service by a set of one or more services.

Publish/Subscribe

Publish/Subscribe

Messaging Bridge

Goal: connect multiple messaging systems

link multiple messaging systems to make messages exchanged on one also available on the others

Pattern: introduce a bridge between the messaging systems, the bridge forwards (and converts) all messages between the buses.

Messaging Bridge

Messaging Bridge

Half-Synch/Half-Asynch

Goal: interconnect synchronous and asynchronous components

Add a layer hiding asynchronous interactions behind a synchronous interface

Pattern: The intermediate layer buffers synchronous requests using queues and maps them to the low-level asynchronous events.

Half-Synch/Half-Asynch

Half-Synch/Half-Asynch

Half-Synch/Half-Asynch

Composition

  1. Scatter/Gather
  2. Canary Call
  3. Master/Slave
  4. Load Balancing
  5. Composition

Scatter/Gather

Goal: send the same message to multiple recipients which will (or may) reply to it

combine the notification of the request with aggregation of replies

Pattern: broadcast a message to all recipients, wait for all (or some) answers and aggregate them into a single message

Scatter/Gather

Scatter/Gather

Canary Call

Goal: avoid crashing all recipients of a poisoned request

use an heuristic to evaluate the request

Pattern: try the potentially dangerous requests on one recipient and scatter the request only if it survives

Canary Call

Canary Call

Canary Call

Master/Slave

Goal: speed up the execution of long running computations

split a large job into smaller independent partitions which can be processed in parallel

Pattern: the master divides the work among a pool of slaves and gathers the results once they arrive.

Synonyms: Master/Worker, Divide-and-Conquer.

Master/Slave

Master/Slave

Load Balancing

Goal: speed up and scale up the execution of multiple requests of many clients

deploy many replicated instances of the server on multiple machines

Pattern: the master assigns the requests among a pool of workers, which answer directly to the clients.

Load Balancing

Load Balancing

Composition

Goal: Improve reuse of existing applications

Build systems out of the composition of existing ones

Pattern: by including compositions as an explicit part of the architecture, it becomes possible to reuse existing services in order to aggregate basic services into value-added ones

Variants: Synchronous, Asynchronous

Synonym: Orchestration

Composition

Composition

Free Advice

The best architectures are full of patterns

Do not use too many unnecessary patterns
(this is an anti-pattern)

More Free Advice

Most software systems cannot be structured according to a single architectural pattern.

Choosing one or more patterns does not give a complete software architecture.
Further refinement is needed.

References

Use a spacebar or arrow keys to navigate