Architectural Styles

Prof. Cesare Pautasso
http://www.pautasso.info
[email protected]
@pautasso

Classical

Neoclassical

Chinese Imperial

Reinassance

Mudejar

Venetian Gothic

Gothic

Gehri (Deconstructivist)

Calatrava (Zoomorphic)

Architecture vs. Art

Grady Booch

Even the best architects copy solutions, styles and patterns that have proven themselves in practice, adapt them to the current context, improve upon their weaknesses, and then assemble them in novel ways with incremental improvements.
The “artistic” part of software architecture is minimal: avoid inventing a new style for every project. Choose the right style instead!
Note: Many software systems use a combination of styles (hybrid/heterogeneous styles).

Which style?

N. Taylor et al.

A software system’s architecture is the set of
principal design decisions made about the system.

One of the first decision: which architectural style(s)?

Architectural Styles

Idiomatic Patterns of System Organization
David Garlan & Mary Shaw
Set of Recurring Useful Design Decisions
Set of Constraints

Architectural Style

N. Taylor et al.

A named collection of architectural decisions that:

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

Why Styles?

Guide the architect with a predefined set of constraints with known benefits and limitations
Consistency: enforcing constraints help to keep the design “clean” (but may limit the freedom of developers to evolve the system)
Improved Communication by shared understanding (like patterns, styles provide a vocabulary to concisely explain an architecture)
Access and reuse expert’s design knowledge
Ensure quality attributes if constraints are followed

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

George Fairbanks, Just Enough Software Architecture: A Risk Driven Approach, M&B 2010
Eberhardt Rechtin, Systems Architecting: Creating and Building Complex Systems, Prentice Hall 1991
Henry Petroski, Small Things Considered: Why There Is No Perfect Design, Vintage 2004
Ian Gordon, Essential Software Architecture, Springer 2004
Christopher Alexander, The Timeless Way of Building, Oxford University Press 1979
Stewart Brand, How Buildings Learn, Penguin 1987
Grady Booch, Handbook of Software Architecture, http://booch.com/architecture/