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 Styles

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

Classical

Neoclassical

Chinese Imperial

Reinassance

Mudejar

Venetian Gothic

Gothic

Gehri (Deconstructivist)

Calatrava (Zoomorphic)

Architecture vs. Art

Grady Booch

Which style?

N. Taylor et al.

Architectural Styles

Architectural Style

N. Taylor et al.

A named collection of architectural decisions that:

  1. are applicable in a development context
  2. constrain architectural design decisions specific to the system within that context
  3. elicit beneficial qualities in each resulting system (more elegant, effective, efficient, dependable, evolvable, scalable, etc.)

Why Styles?

Architectural Style Catalog

Monolithic

System organized as a single element

Lack of structure

No Constraints

Synonym: Blob, Big Ball of Mud

Initial State of formless architectures

Final State of completely eroded architectures

Qualities: Poor Extensibility,
Poor Maintainability,
(Maybe) Good Performance

Layered

Elements of each layer communicate only with the ones in the layers above and below

Information Hiding: Layers hide the ones below them

Incremental Construction: Avoid circular dependencies

Interactions may potentially traverse all layers

Layers can be replaced without affecting others

Qualities: Poor performance,
Good Evolvability

Examples: Hardware/OS/Apps, Network Protocol Stacks, Web/App/Database

Component Based

Components have well defined interfaces that hide their implementation

Components communicate via connectors linking their matching interfaces

Components need to be compatible (with each other and with the overall framework)

Qualities: Independent Component Development, Promote Reusability, Trusted Components

Implied Decision:
To Buy or To Make a component?

Service Oriented

Distributed components have well defined (standard) interfaces and communicate via specific connectors (pub/sub message bus) linking their interfaces.

Components may belong to and are operated by different organizations

Multiple providers compete to deliver "Software as a Service" in a "Service-Oriented Architecture"

Qualities: Loose Coupling, Reusability, Availability, Security/Trust

Examples: Web Service APIs, Cloud Computing

Plugin

The architecture defines explicit extension points so that the system can be customized or even dynamically composed out of plugins.

Static (deployment/installation) vs. Dynamic (without restarting the system)

Mechanism: Plug in and plug out

Recursive: Plugins get extended by other plugins

Ecosystem: the system becomes a platform where alternative plugins compete

Qualities: Dynamic Extensibility, High Customizability, Lower Security

Examples: Browser Extensions, Eclipse, Photoshop

Pipe and Filter

Filters process data streaming through a pipeline

Pipes connect pairs of filters, one writing into it and the other reading from it

Pipes may buffer data and transport it across the network (distributed pipeline)

Pipelines do not have to be linear

Pipes may transport raw bits, structured data, audio/video

Filters may be stateless or stateful (but never share state)

Qualities: Composability, Reconfigurability, Reusability

Examples: Unix Shell, Compilers, Graphics Rendering

Blackboard

Elements share, post, update data written on the blackboard in order to collectively solve a problem.

Asynchronous interactions between processing units mediated by the blackboard

Blackboard: central repository managing concurrent access to the state of a computation

Qualities: Loose Coupling, Implicit Data Flow, Opportunistic Control Flow, Reliability

Examples: Databases, Tuple Space, Expert System

Event-Driven

Elements communicate by producing events and reacting to events produced by other elements

Asynchronous interactions

Messages: events that carry data

Signals: events that transfer control

Qualities: Loose Coupling

Examples: Sensor Monitoring, Complex Event Processing

Publish/Subscribe

Event Driven system where elements are coupled by subscriptions and receive notifications when some interesting event happens.

Roles: publishers and subscribers

Subscription Models: Queues/Topics or Content

Message delivery: Push or Pull

Qualities: Loose Coupling, (Limited) Scalability

Examples: email, Financial News Tickers, Twitter, RSS Feeds

Client/Server

One or more clients send requests to the server, which processes them before sending them back a response.

Client = Active, Server = Passive

Layering: 2-Tier, 3-Tier, N-Tier

Clients are closer to the user, Servers are closer to the data

Qualities: Scalability, Security, Availability

Examples: Web Browsers/Servers, Databases, File Servers, SVN, X

Peer to Peer (P2P)

There is no central server as all elements can both act as client and as server and send one another requests and response messages.

Variants: symmetric peers or asymmetric (peers and super peers)

Churn: peers may join and leave the system at any time

Qualities: Scalability, Dependability (No single point of failure)

Examples: File Sharing, Communication, Distributed Hash Tables, Bitcoin

Data Centric

The system stores and manages its persistent state using some kind of database (layered)

A database is used to share state among multiple elements (blackboard)

ACID Transactions: Atomicity, Consistency, Isolation, Durability

BASE Transactions: Basically Available, Soft state, Eventual consistency

Qualities: Persistence, Consistency

Examples: Relational Databases, Key-Value Stores, XML Databases, Graph Databases

Virtual Machine

Layered system where the virtual machine layer completely hides the real execution environment to ensure the portability of the layers above.

Synonym: Virtualization, Hypervisor

Software packaging and delivery mechanism: VM images, virtual appliances

Qualities: Portability, Dynamic Migration, Security (Sandboxing, Isolation)

Examples: JavaVM, VirtualBox, Xen, Infrastructure-as-a-Service Clouds

Rule Based

Layered system where events are handled by following rules which can be dynamically triggered from external elements or from the rules themselves.

Large knowledge bases with many rules become difficult to understand, predict and maintain

Qualities: Evolvability

Examples: Expert Systems, Prolog, Automated Reasoners, Business Rule Engines

Mobile Code

Code (sometime also its execution state) migrates across execution nodes.

Variants: Remote Evaluation (push), Code on Demand (pull)

Movement can be determined from within the code (agent) or triggered by its environment (fault tolerance, load balancing, consolidation)

Qualities: Security

Example: JavaScript, Flash, Java Applets, Viruses, Mobile Agents, Botnets

REST

Every element publishes its resources using global identifiers. Resources have the same uniform interface.

Representations of resources are transferred between elements

Hypermedia links are used for decentralized resource discovery by referral

Interactions are stateless, Resources are stateful

Qualities: Loose Coupling, Scalability, Interoperability

Examples: HTTP, World Wide Web, RESTful Web APIs

Hybrid Style: Layered + Client/Server + Code on Demand.

Rails

Convenient structure to rapidly implement REST elements

Patterns: Model-View-Controller, object-relational mappings, active record, persistent storage

Scaffolding to generate working skeletons

Convention over Configuration

Qualities: Time to Market

Examples: Ruby on Rails, Grails (JVM), RailwayJS

Layered Styles

Data and Data Flow

From Events to Services

Summary

References

Use a spacebar or arrow keys to navigate