DISSERTATION - Architectural Styles and the Design of Network-based Software Architectures
by Roy Thomas Fielding
What is life?
It is the flash of a firefly in the night.
It is the breath of a buffalo in the wintertime.
It is the little shadow which runs across the grass
and loses itself in the sunset.
－Crowfoot’s last words(1890), Blackfoot warrior and orator.
Almost everybody feels at peace with nature: listening to the ocean
waves against the shore, by a still lake, in a field of grass, on a
windblown heath. One day, when we have learned the timeless way
again, we shall feel the same about our towns, and we shall feel as
much at peace in them, as we do today walking by the ocean, or
stretched out in the long grass of a meadow.
Christopher Alexander, The Timeless Way of Building (1979)
CHAPTER 1: Software Architecture
CHAPTER 2: Network-based Application Architectures
CHAPTER 3: Network-based Architectural Styles
CHAPTER 4: Designing the Web Architecture: Problems and Insights
CHAPTER 5: Representation State Transfer (REST)
CHAPTER 6: Experience and Evaluation
Uniform Resource Identifier, URI
INTRODUTION
The complexity of modern software systems have necessitated a greater emphasis on componentized system, where
the implementation is partitioned into independent components that communicate to perform a desired task. 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, and how all of the above can be described using formal and information notations.
At least some of this behavior within the software industry is due to a lack of understanding of why a given set of architectural constrains is useful. In other words, the reasoning behind good software architectures is not apparent to designers when those architectures are selected for reuse.
This dissertation explores a junction on the frontiers of two research disciplines in computer science: software and
**networking. Software research has long been concerned with the categorization of software designs and the development of design methodologies, but has rarely been able to objectively evaluate the impact of various design choices on system behavior. Networking research, in contrast, is focused on the details of generic communication **
**behavior between systems and improving the performance of particular communication techniques, often ignoring the **
fact that changing the interaction style of an application can have more impact on performance than the communication
protocol used for that interaction.
Discuss in Chapter 4. The Web is intended to be an Internet-scale distributed hypermedia system, which means
considerable more than just geographical dispersion. The Internet is about interconnecting information networks
across organizational boundaries. Suppliers of information services must be able to cope with the demands of anarchic
scalability and the independent deployment of software components. Distributed hypermedia provides a uniform means
of accessing services through the embedding of action controls within the presentation of information retrieved form
remote sites. An architecture for the Web must therefore be designed with the context of communicating large-grain
data objects across high-latency networks and multiple trust boundaries.
Chapter 5 introduces and elaborates the Representational State Transfer (REST) architectural style for distributed
hypermedia systems. REST provides a set of architectural constrains that, when applied as a whole, emphasizes
scalability of component interactions, generality of interfaces, independent deployment of components, and
intermediary components to reduce interaction latency, enforce security, and encapsulate legacy system. I describe
the software engineering principles guiding REST and the interaction constraints chosen to retain those principles,
contrasting them to the constraints of other architectural styles.
Like most real-world systems, not all components of the deployed Web architecture obey every constraint in its
architectural design. REST has been used both as a means to define architectural constraints. While mismatches
cannot be avoided in general, it is possible to identify them before they become standardized. Several mismatches
within the modern Web architecture are summarized in Chapter 6, along with analyses of why they arose and how they
deviate from REST.
In summary, this dissertation makes the following contributions to software research within the field of Information and
Computer Science:
a framework for understanding software architecture through architectural styles, including a consistent set of
terminology for describing software architecture;
a classification of architectural styles for network-based application software by the architectural properties
they would induce when applied to the architecture for a distributed hypermedia system;
REST, a novel architectural style for distributed hypermedia systems; and
application and evaluation of the REST architectural style in the design and deployment of the architecture for the
modern World Wide Web.
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.
At the heart of software architecture is the principle of abstraction: kidding some of the details of a system through encapsulation in order to better identify and sustain its properties[117]. A complex system will contain many levels of abstraction, each with its own architecture. An architecture represents an abstraction of system behavior at that level,
such that architectural elements are delineated by the abstract interfaces they provide to other elements at the level [9].
Within each element may be found another architecture, defining the system of sub-elements that implement the behavior represented by the parent’s abstract interface. This recursion of architectures continues down to the most
basic system elements: those that cannot be decomposed into less abstract elements.
In addition to levels of architecture, a software system will often have multiple operational phases, such as start-up,
initialization, normal processing , re-initialization, and shutdown. Each operational phase has its own architecture. For example, a configuration file will be treated as a data element during the start-up phase, but won’t be considered an
architectural element during normal processing, since at that point the information it contained will have already been
distributed throughout the system. It may, in fact, have defined the normal processing, since at that point the information
it contained will have already been distributed throughout the system. It may, in fact, have defined the normal
processing architecture. An overall description of a system architecture must be capable of describing not only the
operational behavior of the system’s architecture during each phase, but also the architecture of transitions between
phases.
Perry and Wolf [105] define processing elements as “transformers of data,” while Shaw et al.[118] describe
components as “the locus of computation and state.” This is further clarified in Shaw and Clements [122]: “A component is a unit of software that performs some function at run-time. Examples include programs, objects, processes, and filters.” This raises an important distinction between software architecture and what is typically referred to as software
structure: the former is an abstraction of the run-time behavior of a software system, whereas the latter is a property of
the static software source code. Although there are advantages to having the modular structure of the source code
match the decomposition of behavior within a running system, there are also advantages to having independent
software components be implemented using parts of the same code (e.g., shared libraried). We separate the view of
software architecture from that of the source code in order to focus on the software’s run-time characteristics independent of a given component’s implementation. Therefore, architectural design and source code structural design,
though closely related, are separate design activities. Unfortunately, some descriptions of software architecture fail to
make this distinction (e.g., [9]).
1.2 Elements
As an illustration, consider what happens to a building if its blueprints and design plans are burned. Does the
building immediately collapse? No, since the properties by which the walls sustain the weight of the roof remain intact.
An architecture has, bu design, a set of properties that allow it to meet or exceed the system requirements. Ignorance of
those properties may lead to later changes which violate the architecture, just as the replacement of a load-bearing wall
with a large window frame may violate the structural stability of a building. Thus, instead of rationale, our definition of
software architecture includes architectural properties. Rationale explicates those properties, and lack of rationale may
result in gradual decay or degradation of the architecture over time, but the rationale itself is not part of the architecture.
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, via
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.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.
A good designer should select a style that matches the needs of the particular problem being solved.
Choosing the right architectural style for a network-based application requires an understanding of the problem
domain and thereby the communication needs of the application, an awareness of the variety of architectural
styles and the particular concerns they address, and the ability to anticipate the sensitivity of each interaction
style to the characteristics of network-based communication.
1.6 Pattern and Pattern Languages
Like software architectural styles, the software patterns research has deviated somewhat from its origin in building
architecture. Indeed, Alexander’s notion of patterns centers not on recurring arrangements of architectural
elements, but rather on the recurring pattern of events - human activity and emotion - that take place within space,
with the understanding that a pattern of events cannot be separated from the space where it occurs.
As an element in the world, each pattern is a relationship between a certain context, a certain system of forces
which repeatedly in that context, and a certain spatial configuration which allows these forces to resolve
themselves.
As an element of language, a pattern is an instruction, which shows how this spatial configuration can be used,
over and over again, to resolve the given system of forces, wherever the context makes it relevant.
The pattern is, in short, at the same time a thing, which happens in the world, and the rule which tells us how to
create that thing, and when we must create it. It is both a process and a thing; both a description of a thing which
is alive, and a description of the process which will generate that thing.
1.7 Views
An architectural viewpoint is often application-specific and varies widely based on the application domain.
we have seen architectural viewpoints that address a variety of issues, including: temporal issues, state and
control approaches, data representation, transaction life cycle, security safeguards, and peak demand and
graceful degradation. No doubt there are many more possible viewpoints.
Three important views in software architecture: processing, data, and connection views.
- A process view emphasized the data flow through the components and some aspects of the connections among
the components with respect to the data. - A data view emphasized the processing flow, with less emphasis on the connectors.
- A connection view emphasizes the relationship between components the state of communication.
1.8 Related Work
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(DSSA)
1.8.4 Architecture Description Languages (ADL)
1.8.5 Formal Architectural Models