Architectural styles and the Design of Network-based Software Architectures

Roy Thomas Fielding

Acknowledgments

The modern Web architecture is still defined more by the work of individual volunteers than by any single company.

Introduction

Software architecture research investigates methods for determining how best to partition a system, how components identify and communicate with each other, how information is communicated, how elements of a system can evolve independently, how all of the above can be described using formal and informal notations.

Design-by-buzzword is a common occurrence.

When given a name, a coordinated set of architectural constraints becomes an architectural style.

Distributed hypermedia provides a uniform means of accessing services through the embedding of action controls within the presentations of information retrieved from remote site.

CHAPTER 1: Software Architecture

1.1 Run-time Abstraction

A software architecture is an abstraction of the run-time elements of a software system during some phase of its operation. A system may be composed of many levels of abstraction and many phases of operation, each with its own software architecture.

an important distinction between software architecture and software structure:

  • the former is an abstraction of the run-time behavior of a software system
  • the latter is a property of the static software source code

1.2 Elements

A software architecture is defined by a configuration of architectural elements–components, connectors, and data–constrained in their relationships in order to achieve a desired set of architectural properties.

1.2.1 Components

A Component is an abstract unit of software instructions and internal state that provides a transformation of data via its interface.

1.2.2 Connectors

A connector is an abstract mechanism that mediates communication, coordination, or cooperation among components.

1.2.3 Data

A datum is an element of information that is transferred from a component, or received by a component, vis a connector.

1.3 Configurations

A configuration is the structure of architectural relationships among components, connectors, and data during a period of system run-time.

1.4 Properties

  • functional properties: achieved by the system
  • non-functional properties(quality attributes):
    • relative ease of evolution
    • reusability of components
    • efficiency
    • dynamic extensibility

1.5 Styles

An architectural style is a coordinated set of architectural constraints that restricts the roles/features of architectural elements and the allowed relationships among those elements within any architecture that conforms to that style.

1.6 Patterns and Pattern Languages

An architectural style, as a coordinated set of constraints, is applied to a design space in order to induce the architectural properties that are desired of the system.

1.7 Views

1.8.1 Design Methodologies

1.8.2 Handbooks for Design, Design Patterns, and Pattern languages

1.8.3 Reference Models and Domain-specific Software Architectures(DDSA)

Reference Models are developed to provide conceptual frameworks for describing architectures and showing how components are related to each other.

DDSA emphasize reuse of components within a common architectural domain, rather than selecting an architectural style that is specific to each system.

1.8.4 Architecture Description Languages(ADL)

An ADL is a language that provides features for the explicit specification and modeling of a software system’s conceptual architecture, including at a minimum: components, component interfaces, connectors, and architectural configurations.

1.8.5 Formal Architectural Models

Architecture styles can be described formally in terms of a small set of mapping from the syntactic domain of architectural descriptions(box-and-line diagrams) to the semantic domain of architectural meaning.

1.9 Summary

This Chapter examined the background for this dissertation.

CHAPTER 2: Network-based Application Architectures

2.1 Scope

2.1.1 Network-based vs. Distributed

Network-based systems are those capable of operation across a network, but not necessarily in a fashion that is transparent to the user.

2.1.2 Application Software vs. Networking Software

Applications represent the “business-aware” functionality of a system.

2.2 Evaluating the Design of Application Architectures

In order to evaluate an architectural design, we need to examine the design rationale behind the constraints it places on a system, and compare the properties derived from those constraints to the target application’s objectives.

2.3 Architectural Properties of Key Interest

2.3.1 Performance

The performance of a network-based application is bound by

  1. the application requirements
  2. the chosen interaction style
  3. the realized architecture
  4. the implementation of each component.
2.3.1.1 Network Performance
  • Throughput
  • Overhead
    • initial setup overhead
    • per-interaction overhead
  • Brandwidth: a measure of the maximum available throughput over a given network link.
    • Usable bandwidth: refers to that portion of bandwidth which is actually available to the application

Styles impact network performance by their influence on the number of interactions per user action and the granularity of data elements.

2.3.1.2 User-perceived Performance
  • latency
  • completion time

optimizing latency will often have the side-effect of degrading completion time, and vice versa.

2.3.1.3 Network Efficiency

the most efficient architectural styles for a network-based application are those that can effectively minimize use of the network:

  • reuse of prior interactions(caching)
  • reduction of the frequency of network interactions in relation to user actions(replicated data and disconnected operation)
  • remove the need for some interactions by moving the processing of data closer to the source of the data(mobile code)

2.3.2 Scalability

Scalability can be improved by simplifying components, by

  • distributing services across many components (decentralizing the interactions)
  • controlling interactions and configurations as a result of monitoring

Scalability is also impacted by the frequency of interactions, whether

  • the load on a component is distributed evenly over time or occurs in peaks
  • an interaction requires guaranteed delivery or a best-effort
  • a request involves synchronous or asychronous handling
  • the environment is controlled or anarchic (i.e., can you trust the other components?)

2.3.3 Simplicity

Applying the principle of generality to architectural elements also improves simplicity, since it decreases variation within an architecture. Generality of connectors leads to middleware.

2.3.4 Modifiability

Modifiability can be further broken down into evolvability, extensibility, customizability, configurability, and reusability.

dynamic modifiability: the modification is made to a deployed application without stopping and restarting the entire system.

2.3.4.1 Evolvability

dynamic evolution

2.3.4.2 Extensibility

Extensibility is induced within an architectural style by reducing the coupling between components, as exemplified by event-based integration.

2.3.4.3 Customizability

Customizability is a property induced by the remote evaluation and code-on-demand styles.

2.3.4.4 Configurability
2.3.4.5 Resuability

2.3.5 Visibility

Visibility can enable improved performance via shared caching of interactions, scalability through layered service, reliability through reflective monitoring, and security by allowing the interactions to be inspected by mediators (e.g., network firewalls).

2.3.6 Portability

move code along with the data to be processed, such as the virtual machine and mobile agent styles, and those that constrain the data elements to a set of standardized formats.

2.3.7 Reliability

2.4 Summary

CHAPTER 3: Network-based Architectural Styles

3.1 Classification Methodology

3.1.1 Selection of Architectural Styles for Classification

3.1.2 Style-induced Architectural Properties

3.1.3 Visualization

3.2 Data-flow Styles

3.2.1 Pipe and Filter (PF)

PF: referred to as a one-way data flow network.

The constraint is that a filter must be completely independent of other filters (zero coupling): it must not share state, control thread, or identity with the other filters on its upstream and downstream interfaces.

3.2.2 Uniform Pipe and Filter (UPF)

The uniform pipe and filter style adds the constraint that all filters must have the same interface.

3.3 Replication Styles

3.3.1 Replicated Repository (RR)

3.3.2 Cache ($)

This form of replication is most often found in cases where the potential data set far exceeds the capacity of any one client, as in the WWW, or where complete access to the repository is unnecessary.

The cache style becomes network-based when it is combined with a client-stateless-server style.

3.4 Hierarchical Styles

3.4.1 Client-Server (CS)

The basic form of clinet-server does not constrain how application state is partitioned between client and server components. It is often referred to by the mechanisms used for the connector implementation, such as remote procedure call or message-oriented middleware.

3.4.2 Layered System (LS) and Layered-Client-Server (LCS)

A layered System is organized hierarchically, each layer providing services to the layer above it and using services of the layer below it.

Examples:

  • the processing of layered communication protocols: TCP/IP and OSI protocol stack
  • hardware interface libraries

The primary disadvantage of layered system is that they add overhead and latency to the processing of data, reducing user-perceived performance.

Layered-client-server add proxy and gateway components to the client-server style. These additional mediator components can be added in multiple layers to add features like load balancing and security checking to the system.

LCS is also a solution to managing identity in a large scale distributed system, where complete knowledge of all servers would be prohibitively expensive. Instead, servers are organized in layers such that rarely used services are handled by intermediaries rather than directly by each client.

3.4.3 Client-Stateless-Server (CSS)

The client-stateless-server style derives from client-server with the additional constraint that no session state is allowed on the server component. Session state is kept entirely on the client.

3.4.4 Client-Cache-Stateless-Server (C$SS)

Example: Sun Microsystems’ NFS

3.4.5 Layered-Client-Cache-Stateless-Server(LC$SS)

Example: the Internet domain name system (DNS)

3.4.6 Remote Session (RS)

The remote session style is a variant of client-server that attempts to minimize the complexity, or maximize the reuse, of the client components rather the server component. Each client initiates a session on the server and then invokes a series of services on the server, finally exiting the session. Application state is kept entirely on the server. This style is typically used when it is desired to access a remote service using a generic client (e.g., TELNET) or via an interface that mimics a generic client (e.g., FTP).

3.4.7 Remote Data Access (RDA)

The remote data access style is a variant of client-server that spread the application state across both client and server.

The advantages of RDA are that a large data set can be iteratively reduced on the server side without transmitting it across the network, improving efficiency, and visibility is improved by using a standard query language.

3.5 Mobile Code Styles

In all of the mobile code styles, a data element is dynamically transformed into a component.

3.5.1 Virtual Machine (VM)

3.5.2 Remote Evaluation (REV)

The remote evaluation style assumes that the provide code will be executed in a sheltered environment, such that it won’t impact other clients of the same server aside from the resources being used.

3.5.3 Code on Demand (COD)

In the code-on-demand style, a client component has access to a set of resources, but not the know-how on how to process them. It sends a request to a remote server for the code representing that know-how, receives that code, and executes it locally.

3.5.4 Layered-Code-on-Demand-Client-Cache-Stateless-Server (LCODC$SS)

LCODC$SS: the addition of code-on-demand to the layered-client-cache-stateless-server style.

Example: HotJava Web browser[java.sun.com], which allows applets and protocol extensions to be downloaded as typed media.

3.5.5 Mobile Agent (MA)

3.6 Peer-to-Peer Styles

3.6.1 Event-based Integration (EBI)

3.6.2 C2

3.6.3 Distributed Object

3.6.4 Brokered Distributed Object

3.7 Limitations

3.8.1 Classification Of Architectural Styles and Patterns

3.8.2 Distributed Systems and Programming Paradigms

3.8.3 Middleware

These services are called middleware because they act as a layer above the OS and networking software and below industry-specific applications.

3.9 Summary

CHAPTER 4: Designing the Web Architecture: Problems and Insights

4.1 WWW Application Domain Requirements

Web’s major goal was to be a shared information space through which people and machines could communicate.

4.1.1 Low Entry-barrier

Since information within large databases is often much easier to access via a search interface rather than browsing, the Web also incorporated the ability to perform simple queries by providing user-entered data to a service and rendering the result as hypermedia.

4.1.2 Extensibility

A system intending to be as long-lived as the Web must be prepared for change.

4.1.3 Distributed Hypermedia

The Web architecture must be designed for large-grain data transfer.

4.1.4 Internet-scale

Suppliers of information services must be able to cope with the demands of anarchic scalability and the independent deployment of software components.

4.1.4.1 Anarchic Scalability

Anarchic scalability refers to the need for architectural elemtns to continue operating when they are subjected to an unanticipated load, or when given malformed or maliciously constructed data, since they may be communicating with elements outside their organizational control.

This requires that the architecture be capable of communicating authentication data and authorization controls.

4.1.4.2 Independent Deployment

4.2 Problem

4.3 Approach

That is, over the past six years I have been constructing models, adding constraints to the architectural style, and testing their affect on the Web’s protocol standards via experimental extensions to client and server software.

4.4 Summary

The challenge is to develop a method for designing improvements to an architecture such that the improvements can be evaluated prior to their deployment.

CHAPTER 5: Representational State Transfer(REST)

REST is a hybrid style derived from several of the network-based architectural styles described in Chapter 3 and combined with additional constraints that define a uniform connector interface.

5.1 Deriving REST

CHAPTER 6: Experience and Evaluation