-
July 15, 1999
Software Architectural Styles for Network-based Applications
Roy T. FieldingUniversity of California, Irvine
Phase II Survey Paper
Draft 1.1
-of nica-rk e in failure
a-. style rties
op-ing tional
are
A software architecture determines how system components are
identified and allocated, how the components interact to form a
system, the amount and granularity communication needed for
interaction, and the interface protocols used for commution. For a
network-based application, system performance is dominated by
netwocommunication. Therefore, selection of the appropriate
architectural style(s) for usdesigning the software architecture
can make the difference between success andin the deployment of a
network-based application.
Software architectural styles have been characterized by their
control-flow and datflow patterns, allocation of functionality
across components, and component typesUnfortunately, none of these
characterizations are useful for understanding how a influences the
set of architectural properties, or qualities, of a system. These
propeinclude, among others, user-perceived performance, network
efficiency, simplicity, modifiability, scalability, and
portability. We use these style-induced architectural prerties to
classify styles for network-based applications with the goal of
understandwhy certain styles are better than others for some
applications, thus providing addiguidance for software engineers
faced with the task of architectural design.
Keywords
software architecture, software architectural style,
network-based application, softwdesign, software design patterns,
pattern languages
1
-
t for
which
es ts are les ri-
lines ization been ior. on ation tion that
s of of the for kson, e
ility to ased
and tion 3 y efines n of 5,
as of va-
gree-archi-arch ering
1 Introduction
Excuse me ... did you say ‘knives’?
— City Gent #1 (Michael Palin), The Architects Sketch [Python,
1970]
As predicted by Perry and Wolf [1992], software architecture has
been a focal poinsoftware engineering research in the 1990s. The
complexity of modern software systems have necessitated a greater
emphasis on componentized systems withinthe details of an
implementation can be hidden.
Architecture is found at multiple levels within software
systems. This paper examinthe highest level of software
architecture, where the interactions among componencapable of being
realized in network communication. We limit our discussion to
styfor network-based application architectures in order to reduce
the dimensions of vaance within the classification. In addition,
focusing on a particular type of software allows us to identify the
advantages of one style over another.
This survey is intended to explore a gap on the frontier between
two research discipin computer science. Software research has long
been concerned with the categorof software designs and the
development of design methodologies, but has rarely able to
objectively evaluate the impact of various design choices on system
behavNetworking research, in contrast, is focused on the details of
generic communicatibehavior between systems and improving the
performance of particular communictechniques, often ignoring the
fact that changing the interaction style of an applicacan have more
impact on performance than the communication protocols used
forinteraction.
Some architectural styles are often portrayed as “silver bullet”
solutions for all formsoftware. However, a good designer should
select a style that matches the needs particular problem being
solved [Shaw, 1995]. Choosing the right architectural stylea
network-based application requires an understanding of the problem
domain [Jac1994] and thereby the communication needs of the
application, an awareness of thvariety of architectural styles and
the particular concerns they address, and the abanticipate the
sensitivity of each interaction style to the characteristics of
network-bcommunication [Waldo et al., 1994].
Section 2 examines the various definitions of architecture and
architectural styles defines those terms which will be used
throughout the remainder of this paper. Secdescribes what is
intended by network-based application architectures, and
therebdefines the scope of this survey. Section 4 describes the
survey methodology and dthe style-induced architectural properties
used for style comparison. A classificatiosoftware architectural
styles for network-based applications is presented in
Sectionfollowed in Section 6 by a discussion of related work within
the larger research aresoftware architecture and distributed
systems. Finally, I conclude with some obsertions on the relevance
of this work to software engineering research and practice.
2 Context within Software Architecture Research
In spite of the interest in software architecture as a field of
research, there is little ament among researchers as to what
exactly should be included in the definition of tecture. Also, some
aspects of architectural design have been ignored by the
reselabeled software architecture. This section examines how
current software engine
2 Software Architectural Styles for Network-based
Applications
-
those
itec-ft-
lation-le e
f ion nded
Does tain ties ance as the ties of
ed, re i-
e. An
stem o-cture nts of ora-
ture mic
it a sis of to do
research defines software architecture and architectural styles,
and then redefinesterms for our own usage with respect to
network-based application architectures.
2.1 Software Architecture
A comprehensive examination of the scope and intellectual basis
for software archture can be found in Perry and Wolf [1992]. They
present a model that defines a soware architecture as a set of
architectural elements that have a particular form, explicated by a
set of rationale. Architectural elements include processing, data,
andconnecting elements. Form is defined by the properties of the
elements and the reships among the elements — that is, the
constraints on the elements. The rationaprovides the underlying
basis for the architecture by capturing the motivation for thchoice
of architectural style, the choice of elements, and the form.
Although rationale is an important aspect of software
architecture research, and oarchitectural description in
particular, including rationale as part of the architectureitself
is questionable. At first glance, this would seem to imply that the
documentatof system requirements would be part of the architecture.
However, I think the interelationship between rationale and
architecture is more subtle. As an illustration, consider what
happens to a building if its blueprints and design plans are
burned. the building immediately collapse? No, since the properties
by which the walls susthe weight of the roof remain intact. An
architecture has, by design, a set of properthat allow it to meet,
or perhaps exceed, the system requirements. However, ignorof those
properties may lead to later changes which violate the
architecture, such replacement of a load-bearing wall with a large
window frame. In summary, properare an aspect of the architecture,
a rationale explicates those properties, and lackrationale may
result in gradual decay or degradation of the architecture over
time.
A key feature of the model in Perry and Wolf [1992] is their
distinction between thevarious element types. Processing elements
are those that perform transformations ondata, data elements are
those that contain the information that is used and transformand
connecting elements are the glue that holds the different pieces of
the architectutogether. Interestingly, the notion of data elements
is missing from most other defintions of software architecture.
Garlan and Shaw [1993] describe software architecture vaguely as
system structurarchitecture of a specific system is a collection of
computational components together with a description of the
interactions between these components—the connectors. This
definition is expanded upon in Shaw et al. [1995]: The architecture
of a software sydefines that system in terms of components and of
interactions among those compnents. In addition to specifying the
structure and topology of the system, the architeshows the intended
correspondence between the system requirements and elemethe
constructed system (what Perry and Wolf [1992] called rationale).
Further elabtion of this definition can be found in Shaw and Garlan
[1996].
What is surprising about the Shaw et al. [1995] definition is
that it isn’t defining thesoftware’s architecture; rather, it is
defining a description of the software’s architecas if that were
the architecture. In the process, software architecture as a whole
isreduced to what is commonly found in most informal architecture
diagrams: boxes(components) and lines (connectors). Data elements,
along with many of the dynaaspects of real software architectures,
are ignored.
Naturally, there is one benefit of conflating the architecture
with its description, albecynical one: formal analysis of the
description can then be equated to formal analythe architecture.
The bulk of published work in software architecture research
has
Software Architectural Styles for Network-based Applications
3
-
n
f s of rious the le
fini-
the stin-
his is hat es, what time re
s to
n cus de by t a
will ystem they y be archi-decom-
tem r data em
hitec-start-
with formal architectural descriptions and the notations or
languages for descriptio(Section 6.7 contains a summary this
related work).
Abowd et al. [1995] define architectural description as
supporting the description osystems in terms of three basic
syntactic classes: components, which are the locucomputation;
connectors, which define the interactions between components;
andconfigurations, which are collections of interacting components
and connectors. Vastyle-specific concrete notations may be used to
represent these visually, facilitatedescription of legal
computations and interactions, and constrain the set of
desirabsystems.
Strictly speaking, one might think of a configuration as being
equivalent to a set ofspecific constraints on component
interaction, and thus already covered by the detions of software
architecture above. For example, Perry and Wolf [1992] include
topology in their definition of architectural form relationships.
However, separating active topology from more general constraints
allows an architect to more easily diguish the active configuration
from the potential domain of all legal configurations. Additional
rationale for distinguishing configurations within architectural
descriptionlanguages is presented in Medvidovic and Taylor
[1997].
Perry and Wolf [1992] define processing elements as
“transformers of data,” whileShaw et al. [1995] describe components
as “the locus of computation and state.” Tfurther clarified in Shaw
and Clements [1997]: “A component is a unit of software tperforms
some function at run-time. Examples include programs, objects,
processand filters.” This raises an important distinction between
software architecture and is typically referred to as software
structure: the former is an abstraction of the run-behavior of a
software system, whereas the latter is a property of the static
softwasource code. Although there are advantages to having the
modular structure of thesource code match the decomposition of
behavior within a running system, the twoshould be considered
separate design activities. Unfortunately, some research failmake
this distinction (e.g., [Bass et al, 1998]).
Boasson [1995] criticizes current software architecture research
for its emphasis ocomponent structures and architecture development
tools, suggesting that more foshould be placed on data-centric
architectural modeling. Similar comments are maJackson [1994]. As
will become clear in Section 5, the nature of the data
elementswithin a network-based application architecture will often
determine whether or nogiven architectural style is appropriate.
This is further evident in the comparison ofmobile code design
paradigms in Fuggetta et al. [1998].
All of the references that define software architecture
recognize that a given systemhave many layers of architecture. Each
architecture represents an abstraction of sbehavior at that level,
such that elements are delineated by the abstract interfacesprovide
to other elements at that level [Bass et al., 1998]. Within each
element mafound another architecture, defining the system of
subelements that implement thebehavior represented by the parent
element’s abstract interface. This recursion of tectures continues
down to the most basic system elements: those that cannot be posed
into less abstract elements.
Perry and Wolf [1992] hint at another source for multiple
architectures within a syswhen they mention that connecting
elements may, at times, be either processing oelements, or both.
Although it isn’t explicitly mentioned elsewhere, a software
systwill often have multiple operational phases, such as start-up,
initialization, normal processing, reinitialization, and shutdown.
Each operational phase has its own arcture. For example, a
configuration file will be treated as a data element during the
4 Software Architectural Styles for Network-based
Applications
-
that l ly the chitec-
r of
ay its nnec-
tion , ith far as
ter-men-
t.
ordi-ples tocols,
or
at is
re mpo- of
is to t of
n be the ego-en-
up phase, but won’t be considered an element during normal
processing, since at point the information it contained will have
already been distributed throughout thesystem. It may, in fact,
have defined the normal processing architecture. An
overaldescription of a system architecture must therefore be
capable of describing not onoperational behavior of the system
architecture during each phase, but also the arture of transitions
between phases.
Selecting from the above, the following terms will be used
throughout the remaindethis paper:
software architecture. A software architecture is an abstraction
of the run-time behavior of a software system during some phase of
its operation. A system mconsist of many levels of abstraction and
many phases of operation, each withown software architecture. A
software architecture consists of components, cotors, data, a
configuration, and a set of architectural properties.
component. A component is an abstract unit of software that
provides a transformaof data via its interface. Example
transformations include loading into memoryperforming some
calculation, translating to a different format, encapsulation
wother data, etc. The behavior of each component is part of the
architecture insothat behavior can be observed or discerned from
the point of view of another component [Bass et al., 1998]. In
other words, a component is defined by its inface and the services
it provides to other components, rather than by its impletation
behind the interface. Parnas [1971] would define this as the set of
assumptions that other architectural elements can make about the
componen
connector. A connector is an abstract mechanism that mediates
communication, conation, or cooperation among components [Shaw and
Clements, 1997]. Examinclude shared representations, remote
procedure calls, message-passing proand data streams.
datum. A datum is an element of information that is transferred
from a component,received by a component, via a connector. Examples
include files, messages, marshalled parameters, and serialized
objects, but not including information thpermanently resident or
hidden within a component.
configuration. A configuration is the structure of architectural
relationships among components, connectors, and data during some
period of system run-time.
architectural properties. The set of architectural properties of
a software architectuincludes those properties that derive from the
selection and arrangement of conents, connectors, and data within
the system. Examples include relative easeevolution, reusability of
components, efficiency, dynamic extensibility, and the functional
properties achieved by the system. The goal of architectural design
create an architecture with a set of architectural properties that
form a supersethe system requirements.
2.2 Architectural Styles
Since an architecture embodies both functional and
non-functional properties, it cadifficult to directly compare
architectures for different types of systems, or for evensame type
of system set in different environments. Styles are a mechanism for
catrizing architectures and for defining their common
characteristics [Di Nitto and Ros
Software Architectural Styles for Network-based Applications
5
-
d by s aw,
nci-
and
e the
ts.
aints hitec-f trac-5]
ret a
n-rchi-
id .
-ern t. A
age is Kerth
h-mpo-
cast as they
ase of d set
ng a .
blum, 1999]. An architectural style characterizes a family of
systems that are relateshared structural and semantic properties
[Monroe et al., 1997]. Architectural styleprovide an abstraction
for the interactions of the components in an architecture [Sh1990].
Each style captures the essence of a pattern of interaction by
ignoring the idental details of the rest of the architecture.
Perry and Wolf [1992] define architectural style as an
abstraction of element typesformal aspects from various specific
architectures, perhaps concentrating on only certain aspects of an
architecture. An architectural style encapsulates important
deci-sions about the architectural elements and emphasizes
important constraints on thelements and their relationships. This
definition allows for styles that focus only onconnectors of an
architecture, or on specific aspects of the component
interfaces.
In contrast, Garlan and Shaw [1993], Garlan et al. [1994], and
Shaw and Clements[1997] all define style in terms of a pattern of
interactions among typed componenSpecifically, an architectural
style determines the vocabulary of components and connectors that
can be used in instances of that style, together with a set of
constron how they can be combined [Garlan and Shaw, 1993]. This
restricted view of arctural styles is a direct result of their
definition of software architecture — thinking oarchitecture as a
formal description, rather than as a running system, leads to
abstions based only in the shared patterns of box and line
diagrams. Abowd et al. [199define this explicitly as viewing the
collection of conventions that are used to interpclass of
architectural descriptions as defining an architectural style.
New architectures can be defined as instances of specific styles
[Di Nitto and Roseblum, 1999]. Since architectural styles may
address different aspects of software atecture, a given
architecture may be composed of multiple styles. Likewise, a
hybrstyle can be formed by combining multiple basic styles into a
single coherent style
2.3 Architectural Patterns and Pattern Languages
Each pattern describes a problem that 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.
[Alexander et al., 1977]
In parallel with the software engineering research in
architectural styles, the objectoriented programming community has
been exploring the use of patterns and pattlanguages to describe
recurring abstractions in object-based software developmenpattern
is defined as an important and recurring system construct. A
pattern langua system of patterns organized in a structure that
guides the patterns’ application [and Cunningham, 1997].
The design space of patterns includes implementation concerns
specific to the tecniques of object-oriented programming, such as
class inheritance and interface cosition, as well as the
higher-level design issues addressed by architectural styles [Gamma
et al., 1995]. In some cases, architectural style descriptions have
been rearchitectural patterns [Shaw, 1996]. However, the primary
benefit of patterns is thatdescribe relatively complex protocols of
interactions between objects as a single abstraction [Monroe et
al., 1997]. In general, a pattern, or pattern language in the
cmultiple integrated patterns, can be thought of as a recipe for
implementing a desireof interactions among objects. In other words,
a pattern defines a process for solviproblem by following a path of
design and implementation choices [Coplien, 1997]
6 Software Architectural Styles for Network-based
Applications
-
tyles ure ews
ctions essing ation-
es ion of ture
or is
f t that be a of ppli-
ork-entral-
ashion of the
iable cost
tures ssing sm
2.4 Architectural Views
An architectural viewpoint is often application-specific and
varies widely based on the application domain. ... we have seen
architectural viewpoints thataddress 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. [Kerth and Cunningham, 1997]
In addition to the many architectures within a system, and the
many architectural sfrom which the architectures are composed, it
is also possible to view an architectfrom many different
perspectives. Perry and Wolf [1992] describe three important viin
software architecture: processing, data, and connection views. A
process view emphasizes the data flow through the components and
some aspects of the conneamong the components with respect to the
data. A data view emphasizes the procflow, with less emphasis on
the connectors. A connection view emphasizes the relship between
components and the state of communication.
Multiple architectural views are common within case studies of
specific architectur[Bass et al., 1998]. One architectural design
methodology is based on the productdifferent views. The 4+1 View
Model organizes a description of a software architecusing five
concurrent views, each of which addresses a specific set of
concerns [Kruchten, 1995].
3 Network-based Application Architectures
A survey of architectural styles cannot cover every type of
software in existence, nthere an incentive for doing so. The
primary value of a survey such as this one is toprovide design
guidance during the creation of an architecture for a specific type
oproblem. Restricting the scope of the survey reduces the
variability of styles to a secan be reasonably compared against a
system’s requirements. Ideally, there wouldsurvey available for
each particular problem, but that is impractical given the
rangesoftware applications. This survey restricts itself to the
domain of network-based acation architectures.
3.1 Network-based vs. Distributed
Tanenbaum et al. [1985] make a distinction between distributed
systems and netwbased systems: a distributed system is one that
looks to its users like an ordinary cized system, but runs on
multiple, independent CPUs. In contrast, network-based systems are
those capable of operation across a network, but not necessarily in
a fthat is transparent to the user. In some cases it is desirable
for the user to be awaredifference between an action that requires
a network request and one that is satisfon their local system,
particularly when network usage implies an extra transaction[Waldo
et al., 1994].
The primary distinction between network-based architectures and
software architecin general is that communication between
components is restricted to message pa[Andrews, 1991], or the
equivalent of message passing if a more efficient mechanican be
selected at run-time based on the location of components.
Software Architectural Styles for Network-based Applications
7
-
lica- s re”
ich le, a g ard luate of tential per
ad, cific of a .
or the nd. ral
this en
s
tails ed (or
ing ed s s). It
hen-rmed The tified
3.2 Application Software vs. Networking Software
Another restriction on the scope of this survey is that we limit
our discussion to apption architectures, excluding the operating
system, networking software, and somearchitectural styles that
would only use a network for system support (e.g., procescontrol
styles [Garlan and Shaw, 1993]). Applications represent the
“business-awafunctionality of a system [Umar, 1997].
Application software architecture is an abstraction level of an
overall system, in whthe goals of a user action are representable
as architectural properties. For examphypermedia application must
be concerned with the location of information pages,performing
requests, and rendering data streams. This is in contrast to a
networkinabstraction, where the goal is to move bits from one
location to another without regto why those bits are being moved.
It is only at the application level that we can evadesign
trade-offs based on the number of interactions per user action, the
locationapplication state, the effective throughput of all data
streams (as opposed to the pothroughput of a single data stream),
the extent of communication being performeduser action, etc.
Architectural styles, however, do not generally include
application knowledge. Instewe focus on the architectural
properties that a style induces on a system. The speneeds of a
network-based application can then be matched against the
propertiesgiven style in order to determine the style’s suitability
for use within an architecture
4 Classification Methodology
The purpose of building software is not to create a specific
topology of interactionsuse a particular component type — it is to
create a system that meets or exceeds application needs. The style
must conform to those needs, not the other way arouTherefore, in
order to provide useful design guidance, a classification of
architectustyles should be based on the architectural properties
induced by those styles.
4.1 Visualization
I use a table of style versus architectural properties as the
primary visualization forclassification. The table values indicate
the relative influence that the style for a givrow has on a
column’s property. Minus (−−−−) symbols accumulate for negative
influenceand plus (++++) symbols for positive, with plus-minus
(±±±±) indicating that it depends on some aspect of the problem
domain. Although this is a gross simplification of the depresented
in each section, it does indicate the degree to which a style has
addressignored) an architectural property.
An alternative visualization would be a property-based
derivation graph for classifyarchitectural styles. The styles would
be classified according to how they are derivfrom other styles,
with the arcs between styles illustrated by architectural
propertiegained or lost. The starting point of the graph would be
the null style (no constraintis possible to derive such a graph
directly from the descriptions in Section 5.
4.2 Selection of Architectural Styles for Classification
The set of architectural styles included in the classification
is by no means compresive of all possible network-based application
styles. Indeed, a new style can be fomerely by adding a new
architectural constraint to any one of the styles surveyed. goal is
to describe a representative sample of styles, particularly those
already iden
8 Software Architectural Styles for Network-based
Applications
-
rac-ased a rtunis--on are ions
ugh
cture al., , ] to
tion to a er-s nts
y only vey. ral one
use
ture iffer-n.
ture, not ires annot effi- the
ster data.
within the software architecture literature, and provide a
framework by which otherstyles can be added to the classification
as they are developed.
I have intentionally excluded styles that do not enhance the
communication or intetion properties when combined with one of the
surveyed styles to form a network-bapplication. For example, the
blackboard architectural style [Nii, 1986] consists of central
repository and a set of components (knowledge sources) that operate
oppotically upon the repository. A blackboard architecture can be
extended to a networkbased system by distributing the components,
but the properties of such an extensientirely based on the
interaction style chosen to support the distribution — notificatvia
event-based integration, polling a la client-server, or replication
of the repository. Thus, there would be no added value from
including it in the classification even thothe hybrid style is
network-capable.
4.3 Style-induced Architectural Properties
As described in Section 2.1, the set of architectural properties
of a software architeincludes both functional properties and the
equivalent of quality attributes [Bass et1998]. A quality attribute
can be induced by the constraints of an architectural styleusually
motivated by applying a software engineering principle [Ghezzi et
al., 1991an aspect of the architectural elements. For example, the
uniform pipe-and-filter style obtains the qualities of reusability
of components and configurability of the applicaby applying
generality to its component interfaces — constraining the
componentssingle interface type. Hence, the architectural
constraint is “uniform component intface,” motivated by the
generality principle, in order to obtain two desirable qualitiethat
will become the architectural properties of reusable and
configurable componewhen that style is instantiated within an
architecture.
This section describes the architectural properties used to
differentiate and classifarchitectural styles in this survey. This
is not a comprehensive list; I have included those properties that
are clearly influenced by the restricted set of styles in this
surAll of the architectural properties are relative in the sense
that adding an architectuconstraint may improve or reduce a given
property, or even simultaneously improveaspect of the property and
reduce some other aspect of the property. Likewise, improving one
property may lead to the reduction of another.
4.3.1 Performance
One of the main reasons to focus on styles for network-based
applications is becacomponent interactions can be the dominant
factor in determining user-perceived performance and network
efficiency. Since the architectural style influences the naof those
interactions, selection of an appropriate architectural style can
make the dence between success and failure in the deployment of a
network-based applicatio
The performance of a network-based application is bound first by
the application requirements, then by the chosen interaction style,
followed by the realized architecand finally by the implementation
of each component. In other words, software canavoid the basic cost
of achieving the application needs; e.g., if the application
requthat data be located on system A and processed on system B,
then the software cavoid moving that data from A to B. Likewise, an
architecture cannot be any more cient than its interaction style
allows; e.g., the cost of multiple interactions to movedata from A
to B cannot be any less than that of a single interaction from A to
B. Finally, regardless of the quality of an architecture, no
interaction can take place fathan a component implementation can
produce data and its recipient can consume
Software Architectural Styles for Network-based Applications
9
-
nents. , a
per ongly
that the ut of
ct on infor-mple-
se. ction: n; 2) ed to inter-r and
esent tyle.
ion en an ion is t can
eived
sen-
tion so, ), or er to
ution -
Network Performance. Network performance measures are used to
describe someattributes of communication. Throughput is the rate at
which information, including both application data and
communication overhead, is transferred between compoOverhead can be
separated into initial setup overhead and per-interaction
overheaddistinction which is useful for identifying connectors that
can share setup overheadacross multiple interactions
(amortization). Bandwidth is 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 interactionsuser action and the granularity of data
elements. A style that encourages small, strtyped interactions will
be efficient in an application involving small data transfers among
known components, but will cause excessive overhead within
applications involve large data transfers or negotiated interfaces.
Likewise, a style that involvescoordination of multiple components
arranged to filter a large data stream will be oplace in an
application that requires many small control messages.
User-perceived Performance. User-perceived performance differs
from network performance in that the performance of an action is
measured in terms of its impathe user in front of an application
rather than the rate at which the network moves mation. The primary
measures for user-perceived performance are latency and cotion
time.
Latency is the time period between initial stimulus and the
first indication of a responLatency occurs at several points in the
processing of a network-based application a1) the time needed for
the application to recognize the event that initiated the actiothe
time required to setup the interactions between components; 3) the
time requirtransmit each interaction to the components; 4) the time
required to process each action on those components; and, 5) the
time required to complete sufficient transfeprocessing of the
result of the interactions before the application is able to begin
rendering a usable result. It is important to note that, although
only (3) and (5) repractual network communication, all five points
can be impacted by the architectural sFurthermore, multiple
interactions are additive to latency unless they take place
inparallel.
Completion is the amount of time taken to complete an
application action. Complettime is dependent upon all of the
aforementioned measures. The difference betweaction’s completion
time and its latency represents the degree to which the
applicatincrementally processing the data being received. For
example, a Web browser tharender a large image while it is being
received provides significantly better user-perceived performance
than one that waits until the entire image is completely recprior
to rendering, even though both experience the same network
performance.
Network Efficiency. An interesting observation about
network-based applications isthat the best application performance
is obtained by not using the network. This estially means that the
most efficient architectural styles for a network-based applicaare
those that can effectively minimize use of the network when it is
possible to dothrough reuse of prior interactions (caching),
reduction of the frequency of networkinteractions in relation to
user actions (replicated data and disconnected operationby removing
the need for some interactions by moving the processing of data
closthe source of the data (mobile code).
The impact of the various performance issues is often related to
the scope of distribfor the application. The benefits of a style
under local conditions may become draw
10 Software Architectural Styles for Network-based
Applications
-
med a rk re a
o- can po-a-ation ts.
ction us or
., can
e nts. lly h n to al
ity, ads
archi-
ere the tches iety lica-t be ded
ion f d by l
backs when faced with global conditions. Thus, the properties of
a style must be frain relation to the interaction distance: within
a single process, across processes onsingle host, inside a
local-area network (LAN), or spread across a wide-area netwo(WAN).
Additional concerns become evident when interactions across a WAN,
whesingle organization is involved, are compared to interactions
across the Internet, involving multiple trust boundaries.
4.3.2 Scalability
Scalability refers to the ability of the architecture to support
large numbers of compnents, or interactions among components,
within an active configuration. Scalabilitybe improved by
simplifying components, by distributing services across many
comnents (decentralizing the interactions), and by controlling
interactions and configurtions as a result of monitoring. Styles
influence these factors by determining the locof application state,
the extent of distribution, and the coupling between componen
Scalability is also impacted by the frequency of interactions,
whether the load on acomponent will be distributed evenly over time
or occur in peaks, whether an interarequires guaranteed delivery or
a best-effort, whether a request involves synchronoasynchronous
handling, and whether the environment is controlled or anarchic
(i.eyou trust the other components?).
4.3.3 Simplicity
The primary means by which architectural styles induce
simplicity is by applying thprinciple of separation of concerns to
the allocation of functionality within componeIf functionality can
be allocated such that the individual components are substantialess
complex, then they will be easier to understand and implement.
Likewise, sucseparation eases the task of reasoning about the
overall architecture. I have choselump the qualities of complexity,
understandability, and verifiability under the generproperty of
simplicity, since they go hand-in-hand for a network-based
system.
Applying the principle of generality to architectural elements
also improves simplicsince it decreases the variability within an
architecture. Generality of connectors leto middleware (Section
6.3).
4.3.4 Modifiability
Modifiability is about the ease with which a change can be made
to an application tecture. Modifiability can be further broken down
into evolvability, extensibility, customizability, configurability,
and reusability, as described below. A particular concern of
network-based systems is dynamic modifiability [Oreizy et al.,
1998], whthe modification is made to a deployed application without
stopping and restarting entire system. Even if it were possible to
build a software system that perfectly mathe requirements of its
users, those requirements will change over time just as socchanges
over time. Because the components participating in a network-based
apption may be distributed across multiple organizational
boundaries, the system musprepared for gradual and fragmented
change, where old and new implementationscoexist, without
preventing the new implementations from making use of their
extencapabilities.
Evolvability. Evolvability represents the degree to which a
component implementatcan be changed without negatively impacting
other components. Static evolution ocomponents generally depends on
how well the architectural abstraction is enforcethe
implementation, and thus is not something unique to any particular
architectura
Software Architectural Styles for Network-based Applications
11
-
ques
d to d mpli-
one t also and
d by
it -e pipe-les
s, tions. tion er-pes
a-lity n ared c-
tors
ing
les ssed, data
style. Dynamic evolution, however, can be influenced by the
style if it includes constraints on the maintenance and location of
application state. The same techniused to recover from partial
failure conditions in a distributed system [Waldo et al.,1994] can
be used to support dynamic evolution.
Extensibility. Extensibility is defined as the ability to add
functionality to a system [Pountain et al., 1995]. Dynamic
extensibility implies that functionality can be addea deployed
system without impacting the rest of the system. Extensibility is
inducewithin an architectural style by reducing the coupling
between components, as exefied by event-based integration (Section
5.5).
Customizability. Customizability is a specialization of
extensibility in that it refers tomodifying a component at
run-time, specifically so that the component can then perform an
unusual service. A component is customizable if it can be extended
byclient of that component’s services without adversely impacting
other clients of thacomponent [Fuggetta et al., 1998]. Styles that
support dynamic customization mayimprove simplicity and
scalability, since service components can be reduced in
sizecomplexity by directly implementing only the most frequent
services and allowing infrequent services to be defined by the
client. Customizability is a property inducethe remote evaluation
(Section 5.3.2) and code-on-demand (Section 5.3.3) styles.
Configurability. Configurability is related to both
extensibility and reusability in that refers to post-deployment
modification of components, or configurations of components, such
that they are capable of using a new service or data element type.
Thand-filter (Section 5.1) and code-on-demand (Section 5.3.3)
styles are two exampthat induce configurability of configurations
and components, respectively.
Reusability. Reusability is a property of an application
architecture if its componentconnectors, or data elements can be
reused, without modification, in other applicaThe primary
mechanisms for inducing reusability within architectural styles is
reducof coupling (knowledge of identity) between components and
constraining the genality of component interfaces. The uniform
pipe-and-filter style exemplifies these tyof constraints.
4.3.5 Visibility
Styles can also influence the visibility of interactions within
a network-based appliction by restricting interfaces via generality
or providing access to monitoring. Visibiin this case refers to the
ability of a component to monitor or mediate the interactiobetween
two other components. Visibility can enable improved performance
via shcaching of interactions, scalability through layered
services, reliability through refletive monitoring, and security by
allowing the interactions to be inspected by media(e.g., network
firewalls). Mobile code is an example where the lack of visibility
maylead to security concerns.
This usage of visibility differs from that in Ghezzi et al.
[1991], where they are referrto visibility into the development
process rather than the product.
4.3.6 Portability
Software is portable if it can run in different environments
[Ghezzi et al., 1991]. Stythat induce portability include those
that move code along with the data to be procesuch as the virtual
machine and mobile agent styles, and those that constrain the
elements to a set of standardized formats.
12 Software Architectural Styles for Network-based
Applications
-
res- reli-
g,
s and the
is one-
trol
yle
nd
r style e
). agree s can (exten- ead-
pe-
ny the
e ica-
4.3.7 Reliability
Reliability, within the perspective of application
architectures, can be viewed as thedegree to which an architecture
is susceptible to failure at the system level in the pence of
partial failures within components, connectors, or data. Styles can
improveability by avoiding single points of failure, enabling
redundancy, allowing monitorinor reducing the scope of failure to a
recoverable action.
5 Architectural Styles for Network-based Applications
5.1 Pipe and Filter (PF)
In a pipe and filter style, each component (filter) reads
streams of data on its inputproduces streams of data on its
outputs, usually while applying a transformation toinput streams
and computing incrementally so that output begins before the input
completely consumed [Garlan and Shaw, 1993]. This style is also
referred to as a way data flow network [Andrews, 1991]. The
constraint is that a filter must be completely independent of other
filters (zero coupling): it must not share state, conthread, or
identity with the other filters on its upstream and downstream
interfaces[Garlan and Shaw, 1993].
Abowd et al. [1995] provide an extensive formal description of
the pipe and filter stusing the Z language. The Khoros software
development environment for image processing [Rasure and Young,
1992] provides a good example of using the pipe afilter style to
build applications.
Garlan and Shaw [1993] describe the advantageous properties of
the pipe and filteas follows. First, PF allows the designer to
understand the overall input/output of thsystem as a simple
composition of the behaviors of the individual filters
(simplicitySecond, PF supports reuse: any two filters can be hooked
together, provided they on the data that is being transmitted
between them (reusability). Third, PF systembe easily maintained
and enhanced: new filters can be added to existing systems
sibility) and old filters can be replaced by improved ones
(evolvability). Fourth, theypermit certain kinds of specialized
analysis (verifiability), such as throughput and dlock analysis.
Finally, they naturally support concurrent execution
(user-perceived performance).
Disadvantages of the PF style include: propagation delay is
added through long pilines, batch sequential processing occurs if a
filter cannot incrementally process itsinputs, and no interactivity
is allowed. A filter cannot interact with its environment because
it cannot know that any particular output stream shares a
controller with aparticular input stream. These properties decrease
user-perceived performance if problem being addressed does not fit
the pattern of a data flow stream.
One aspect of PF styles that is rarely mentioned is that there
is an implied “invisiblhand” that arranges the configuration of
filters in order to establish the overall appl
Style Derivation Net
Per
form
.
UP
Per
form
.
Effi
cien
cy
Sca
labi
lity
Sim
plic
ity
Evo
lvab
ility
Ext
ensi
bilit
y
Cus
tom
iz.
Con
figur
.
Reu
sabi
lity
Vis
ibili
ty
Por
tabi
lity
Rel
iabi
lity
PF ±±±± ++++ ++++ ++++ ++++ ++++
UPF PF −−−− ±±±± ++++++++ ++++ ++++ ++++++++ ++++++++ ++++
Software Architectural Styles for Network-based Applications
13
-
he and id-re, even
me racters he
f the
s for for rmed, s the are
ing s from until made
er e ce
f
tion. A network of filters is typically arranged just prior to
each activation, allowing tapplication to specify the configuration
of filter components based on the task at hand the nature of the
data streams (configurability). This controller function is
consered a separate operational phase of the system, and hence a
separate architectuthough one cannot exist without the other.
5.1.1 Uniform Pipe and Filter (UPF)
The uniform pipe and filter style adds the constraint that all
filters must have the sainterface. The primary example of this
style is found in the Unix operating system,where filter processes
have an interface consisting of one input data stream of cha(stdin)
and two output data streams of characters (stdout and stderr).
Restricting tinterface allows independently developed filters to be
arranged at will to form new applications. It also simplifies the
task of understanding how a given filter works.
A disadvantage of the uniform interface is that it may reduce
network performance idata needs to be converted to or from its
natural format.
5.2 Client-Server (CS)
The client-server style is the most frequently encountered of
the architectural stylenetwork-based applications. A server
component, offering a set of services, listensrequests upon those
services. A client component, desiring that a service be perfosends
a request to the server via a connector. The server either rejects
or performrequest and sends a response back to the client. A
variety of client-server systemssurveyed by Sinha [1992] and Umar
[1997].
Andrews [1991] describes client-server components as follows: A
client is a triggerprocess; a server is a reactive process. Clients
make requests that trigger reactionservers. Thus, a client
initiates activity at times of its choosing; it often then delays
its request has been serviced. On the other hand, a server waits
for requests to beand then reacts to them. A server is usually a
non-terminating process and often provides service to more than one
client.
Separation of concerns is the principle behind the client-server
constraints. A propseparation of functionality should simplify the
server component in order to improvscalability. This simplification
usually takes the form of moving all of the user
interfafunctionality into the client component. The separation also
allows the two types ocomponents to evolve independently, provided
that the interface doesn’t change.
Style Derivation Net
Per
form
.
UP
Per
form
.
Effi
cien
cy
Sca
labi
lity
Sim
plic
ity
Evo
lvab
ility
Ext
ensi
bilit
y
Cus
tom
iz.
Con
figur
.
Reu
sabi
lity
Vis
ibili
ty
Por
tabi
lity
Rel
iabi
lity
CS ++++ ++++ ++++
LS −−−− ++++ ++++ ++++ ++++
LCS CS+LS −−−− ++++++++ ++++ ++++++++ ++++ ++++
CSS CS −−−− ++++++++ ++++ ++++ ++++ ++++
C$SS CSS+$ −−−− ++++ ++++ ++++++++ ++++ ++++ ++++ ++++
LC$SS LCS+C$SS −−−− ±±±± ++++ ++++++++++++ ++++++++ ++++++++
++++ ++++ ++++ ++++
RS CS ++++ −−−− ++++ ++++ −−−−
RDA CS ++++ −−−− −−−− ++++ −−−−
14 Software Architectural Styles for Network-based
Applications
-
ed ed for 984]
ayer h is r.
from -
P and ary essing
le. A aking
st its ner-
ers to
red,
re s are ther
raint server t take
the
-gle
, llows
on.
ance ests,
The basic form of client-server does not constrain how
application state is partitionbetween client and server components.
It is often referred to by the mechanisms usthe connector
implementation, such as remote procedure call [Birrell and Nelson,
1or message-oriented middleware [Umar, 1997].
5.2.1 Layered System (LS) and Layered-Client-Server (LCS)
A layered system is organized hierarchically, each layer
providing services to the labove it and using services of the layer
below it [Garlan and Shaw, 1993]. Althouglayered system is
considered a “pure” style, its use within network-based
systemslimited to its combination with the client-server style to
provide layered-client-serve
Layered systems reduce coupling across multiple layers by hiding
the inner layersall except the adjacent outer layer, thus improving
evolvability and reusability. Examples include the processing of
layered communication protocols, such as the TCP/IOSI protocol
stacks [Zimmerman, 1980], and hardware interface libraries. The
primdisadvantage of layered systems is that they add overhead and
latency to the procof data, reducing user-perceived performance
[Clark and Tennenhouse, 1990].
Layered-client-server adds proxy and gateway components to the
client-server styproxy [Shapiro, 1986] acts as a shared server for
one or more client components, trequests and forwarding them, with
possible translation, to server components. A gateway component
appears to be a normal server to clients or proxies that
requeservices, but is in fact forwarding those requests, with
possible translation, to its “inlayer” servers. These additional
mediator components can be added in multiple layadd features like
load balancing and security checking to the system.
Architectures based on layered-client-server are referred to as
two-tiered, three-tieor multi-tiered architectures in the
information systems literature [Umar, 1997].
LCS is also a solution to managing identity in a large scale
distributed system, whecomplete knowledge of all servers would be
prohibitively expensive. Instead, serverorganized in layers such
that rarely used services are handled by intermediaries rathan
directly by each client [Andrews, 1991].
5.2.2 Client-Stateless-Server (CSS)
The client-stateless-server style derives from client-server
with the additional constof no session state allowed on the server
component. Each request from client to must contain all of the
information necessary to understand the request, and cannoadvantage
of any stored context on the server. Application state is kept
entirely onclient.
These constraints improve the properties of visibility,
reliability, and scalability. Visibility is improved because a
monitoring system does not have to look beyond a sinrequest datum
in order to determine the full nature of the request. Reliability
is improved because it eases the task of recovering from partial
failures [Waldo et al.1994]. Scalability is improved because not
having to store state between requests athe server component to
quickly free resources and further simplifies implementati
The disadvantage of client-stateless-server is that it may
decrease network performby increasing the repetitive data
(per-interaction overhead) sent in a series of requsince that data
cannot be left on the server in a shared context.
Software Architectural Styles for Network-based Applications
15
-
cache client hable,
erver. S
ally or rfor-
rver po-
name
CS e,
.
ervices rver. neric
in the when
lability ns,
s the a stan-nd ake
piece cture-
ced on hat erver
k-
5.2.3 Client-Cache-Stateless-Server (C$SS)
The client-cache-stateless-server style derives from the
client-stateless-server andstyles via the addition of cache
components. A cache acts as a mediator between and server in which
the responses to prior requests can, if they are considered cacbe
reused in response to later requests that are equivalent and likely
to result in a response identical to that in the cache if the
request were to be forwarded to the sAn example system that makes
effective use of this style is Sun Microsystems’ NF[Sandberg et
al., 1985].
The advantage of adding cache components is that they have the
potential to particompletely eliminate some interactions, improving
efficiency and user-perceived pemance.
5.2.4 Layered-Client-Cache-Stateless-Server (LC$SS)
The layered-client-cache-stateless-server style derives from
both layered-client-seand client-cache-stateless-server through the
addition of proxy and/or gateway comnents. Two examples of systems
that use an LC$SS style are the Internet domain system (DNS) and
the World Wide Web’s HTTP [Fielding et al., 1999].
The advantages and disadvantages of LC$SS are just a combination
of those for Land C$SS. However, note that we don’t count the
contributions of the CS style twicsince the benefits are not
additive if they come from the same ancestral derivation
5.2.5 Remote Session (RS)
The remote session style is a variant of client-server that
attempts to minimize thecomplexity, or maximize the reuse, of the
client components rather than the servercomponent. Each client
initiates a session on server and then invokes a series of son the
server, finally exiting the session. Application state is kept
entirely on the seThis style is typically used when it is desired
to access a remote service using a geclient (e.g., TELNET) or via
an interface that mimics a generic client (e.g., FTP).
The advantages of the remote session style are that it is easier
to centrally maintainterface at the server, reducing concerns about
inconsistencies in deployed clientsfunctionality is extended, and
improves efficiency if the interactions make use of extended
session context on the server. The disadvantages are that it
reduces scaof the server, due to the stored application state, and
reduces visibility of interactiosince a monitor would have to know
the complete state of the server.
5.2.6 Remote Data Access (RDA)
The remote data access style [Umar, 1997] is a variant of
client-server that spreadapplication state across both client and
server. A client sends a database query indard format, such as SQL,
to a remote server. The server allocates a workspace aperforms the
query, which may result in a very large data set. The client can
then mfurther operations upon the result set (such as table joins)
or retrieve the result oneat a time. The client must know about the
data structure of the service to build strudependent queries.
The advantage of remote data access is that a large data set can
be iteratively reduthe server side without transmitting it across
the network, improving efficiency, andvisibility is improved by
using a standard query language. The disadvantages are tthe client
needs to understand the same database manipulation concepts as the
simplementation (lacking simplicity) and storing application
context on the server decreases scalability. Reliability also
suffers, since partial failure can leave the wor
16 Software Architectural Styles for Network-based
Applications
-
n be tion
en rehen-hi-
el. In idered
mity
a data ity is ral
ter, rably tyle, rver
ral ary plat- d ted in
space in an unknown state. Transaction mechanisms (e.g.,
two-phase commit) caused to fix the reliability problem, though at
a cost of added complexity and interacoverhead.
5.3 Mobile Code
Mobile code styles use mobility in order to dynamically change
the distance betwethe processing and source of data or destination
of results. These styles are compsively examined in Fuggetta et al.
[1998]. A site abstraction is introduced at the arctectural level,
as part of the active configuration, in order to take into account
the location of the different components. Introducing the concept
of location makes it possible to model the cost of an interaction
between components at the design levparticular, an interaction
between components that share the same location is consto have
negligible cost when compared to an interaction involving
communication through the network. By changing its location, a
component may improve the proxiand quality of its interaction,
reducing interaction costs and thereby improving effi-ciency and
user-perceived performance.
In all of the mobile code styles, a data element is dynamically
transformed into a component. Fuggetta et al. [1998] use an
analysis that compares the code’s size aselement to the savings in
normal data transfer in order to determine whether mobildesirable
for a given action. This would be impossible to model from an
architectustandpoint if the definition of software architecture
excludes data elements.
5.3.1 Virtual Machine (VM)
Underlying all of the mobile code styles is the notion of a
virtual machine, or interprestyle [Garlan and Shaw, 1993]. The code
must be executed in some fashion, prefewithin a controlled
environment to satisfy security and reliability concerns, which
isexactly what the virtual machine style provides. It is not, in
itself, a network-based sbut it is commonly used as such when
combined with a component in the client-sestyle (REV and COD
styles).
Scripting languages are the most common use of virtual machines,
including genepurpose languages like Perl and task-specific
languages like PostScript. The primbenefits are the separation
between instruction and implementation on a particularform
(portability) and ease of extensibility. Visibility is reduced
because it is hard toknow what an executable will do simply by
looking at the code. Simplicity is reducedue to the need to manage
the evaluation environment, but that may be compensasome cases as a
result of simplifying the static functionality.
Style Derivation Net
Per
form
.
UP
Per
form
.
Effi
cien
cy
Sca
labi
lity
Sim
plic
ity
Evo
lvab
ility
Ext
ensi
bilit
y
Cus
tom
iz.
Con
figur
.
Reu
sabi
lity
Vis
ibili
ty
Por
tabi
lity
Rel
iabi
lity
VM ±±±± ++++ −−−− ++++
REV CS+VM ++++ −−−− ±±±± ++++ ++++ −−−− ++++ −−−−
COD CS+VM ++++ ++++ ++++ ±±±± ++++ ++++ −−−−
LCODC$SS LC$SS+COD −−−− ++++++++ ++++++++ ++++4444++++
+±+±+±+±++++ ++++++++ ++++ ++++ ++++ ±±±± ++++ ++++
MA REV+COD ++++ ++++++++ ±±±± ++++++++ ++++ ++++ −−−− ++++
Software Architectural Styles for Network-based Applications
17
-
r and a ppen
erver avail-
e eval-ment, being
mpo-
erver y is mpen-ility viron-t the ty.
ploy-
s to a t to a ecutes
ed -lient’s ns.
hat ction-t
ignifi-ple st
n of e. with ee, .
for ther
5.3.2 Remote Evaluation (REV)
In the remote evaluation style [Fuggetta et al., 1998], derived
from the client-servevirtual machine styles, a client component has
the know-how necessary to performservice, but lacks the resources
(CPU cycles, data source, etc.) required, which hato be located at
a remote site. Consequently, the client sends the know-how to a
scomponent at the remote site, which in turn executes the code
using the resourcesable there. The results of that execution are
then sent back to the client. The remotuation style assumes that
the provided code will be executed in a sheltered environsuch that
it won’t impact other clients of the same server aside from the
resources used.
The advantages of remote evaluation include the ability to
customize the server conent’s services, which provides for improved
extensibility and customizability, and better efficiency when the
code can adapt its actions to the environment inside the s(as
opposed to the client making a series of interactions to do the
same). Simplicitreduced due to the need to manage the evaluation
environment, but that may be cosated in some cases as a result of
simplifying the static server functionality. Scalabis reduced; this
can be improved with the server’s management of the execution
enment (killing long-running or resource-intensive code when
resources are tight), bumanagement function itself leads to
difficulties regarding partial failure and reliabiliThe most
significant limitation, however, is the lack of visibility due to
the client sending code instead of standardized queries. Lack of
visibility leads to obvious dement problems if the server cannot
trust the clients.
5.3.3 Code on Demand (COD)
In the code-on-demand style [Fuggetta et al., 1998], a client
component has accesset of resources, but not the know-how on how to
process them. It sends a requesremote server for the code
representing that know-how, receives that code, and exit
locally.
The advantages of code-on-demand include the ability to add
features to a deployclient, which provides for improved
extensibility and configurability, and better userperceived
performance and efficiency when the code can adapt its actions to
the cenvironment and interact with the user locally rather than
through remote interactioSimplicity is reduced due to the need to
manage the evaluation environment, but tmay be compensated in some
cases as a result of simplifying the client’s static funality.
Scalability of the server is improved, since it can off-load work
to the client thawould otherwise have consumed its resources. Like
remote evaluation, the most scant limitation is the lack of
visibility due to the server sending code instead of simdata. Lack
of visibility leads to obvious deployment problems if the client
cannot truthe servers.
5.3.4 Layered-Code-on-Demand-Client-Cache-Stateless-Server
(LCODC$SS)
As an example of how some architectures are complementary,
consider the additiocode-on-demand to the
layered-client-cache-stateless-server style discussed abovSince the
code can be treated as just another data element, this does not
interferethe advantages of the LC$SS style. An example is the World
Wide Web [Berners-L1996], where applets and protocol extensions can
be downloaded as typed media
The advantages and disadvantages of LCODC$SS are just a
combination of thoseCOD and LC$SS. We could go further and discuss
the combination of COD with oCS styles, but this survey is not
intended to be exhaustive (nor exhausting).
18 Software Architectural Styles for Network-based
Applications
-
nt is data lua-
for the hen
at a
essi-he at and
the ary
ce
tency
lt of lica-city of the et-
lity of also
rms
and, rage,
5.3.5 Mobile Agent (MA)
In the mobile agent style [Fuggetta et al., 1998], an entire
computational componemoved to a remote site, along with its state,
the code it needs, and possibly some required to perform the task.
This can be considered a derivation of the remote evation and
code-on-demand styles, since the mobility works both ways.
The primary advantage of the mobile agent style, beyond those
already describedREV and COD, is that there is greater dynamism in
the selection of when to movecode. An application can be in the
midst of processing information at one location wit decides to move
to another location, presumably in order to reduce the
distancebetween it and the next set of data it wishes to process.
In addition, the reliability problem of partial failure is reduced
because the application state is in one locationtime [Fuggetta et
al., 1998].
5.4 Replication
5.4.1 Replicated Repository (RR)
Systems based on the replicated repository style [Andrews, 1991]
improve the accbility of data and scalability of services by having
more than one process provide tsame service. These decentralized
servers interact to provide clients the illusion ththere is just
one, centralized service. Distributed filesystems, such as XMS
[FridrichOlder, 1985], and remote versioning systems, like CVS
[www.cyclic.com], are the primary examples.
Improved user-perceived performance is the primary advantage,
both by reducing latency of normal requests and enabling
disconnected operation in the face of primserver failure or
intentional roaming off the network. Simplicity remains neutral,
sinthe complexity of replication is offset by the savings of
allowing network-unaware components to operate transparently on
locally replicated data. Maintaining consisis the primary
concern.
5.4.2 Cache ($)
A variant of replicated repository is found in the cache style:
replication of the resuan individual request such that it may be
reused by later requests. This form of reption is most often found
in cases where the potential data set far exceeds the capaany one
client, as in the WWW [Berners-Lee, 1996], or where complete access
to repository is unnecessary. Lazy replication occurs if data is
replicated upon a not-ycached response for a request, thus relying
on locality of reference and commonainterest to propagate useful
items into the cache for later reuse. Active replication
ispossible, via pre-fetching of cachable entries based on
anticipated requests.
Caching provides slightly less improvement than the replicated
repository style in teof user-perceived performance, since more
requests will miss the cache and only recently accessed data will
be available for disconnected operation. On the other hcaching is
much easier to implement, doesn’t require as much processing and
sto
Style Derivation Net
Per
form
.
UP
Per
form
.
Effi
cien
cy
Sca
labi
lity
Sim
plic
ity
Evo
lvab
ility
Ext
ensi
bilit
y
Cus
tom
iz.
Con
figur
.
Reu
sabi
lity
Vis
ibili
ty
Por
tabi
lity
Rel
iabi
lity
RR ++++++++ ++++ ++++
$ RR ++++ ++++ ++++ ++++
Software Architectural Styles for Network-based Applications
19
-
che yle.
stem the can egister vokes odel-tion 90],
the eneral ts to ,
that invo-a-rove
isten with t as a ca-nd
re not is no
ilding e-
e le,
and is more efficient because data is transmitted only when it
is requested. The castyle becomes network-based when it is combined
with a client-stateless-server st
5.5 Event-based Integration (EBI)
The event-based integration style, also known as the implicit
invocation or event systyle, reduces coupling between components by
removing the need for identity onconnector interface. Instead of
invoking another component directly, a component announce (or
broadcast) one or more events. Other components in a system can
rinterest in that type of event and, when the event is announced,
the system itself inall of the registered components [Garlan and
Shaw, 1993]. Examples include the MView-Controller paradigm in
Smalltalk-80 [Krasner and Pope, 1988] and the integramechanisms of
many software engineering environments, including Field [Reiss,
19SoftBench [Cagan, 1990], and Polylith [Purtilo, 1994].
The event-based integration style provides strong support for
extensibility through ease of adding new components that listen for
events, for reuse by encouraging a gevent interface and integration
mechanism, and for evolution by allowing componenbe replaced
without affecting the interfaces of other components [Garlan and
Shaw1993]. However, like pipe-and-filter systems, there needs to be
an “invisible hand” places components on the event interface. Most
EBI systems also include explicit cation as a complementary form of
interaction [Garlan and Shaw, 1993]. For applictions that are
dominated by data monitoring, rather than data retrieval, EBI can
impefficiency by removing the need for polling interactions.
The basic form of EBI system consists of one event bus to which
all components lfor events of interest to them. Of course, this
immediately leads to scalability issuesregard to the number of
notifications, event storms as other components broadcasresult of
events caused by that notification, and a single point of failure
in the notifition delivery system. This can be ameliorated though
the use of layered systems afiltering of events, at the cost of
simplicity.
Other disadvantages of EBI systems are that it can be hard to
anticipate what will happen in response to an action (poor
understandability) and event notifications asuitable for exchanging
large granularity data [Garlan and Shaw, 1993]. Also, theresupport
for recovery from partial failure.
Sullivan and Notkin [1992] provide a survey of implicit
invocation research and describe its application to improving the
evolution quality of software tool suites. Barrett et al. [1996]
present a survey of event-based integration mechanisms by bua
framework for comparison and then seeing how some systems fit
within that framwork. Rosenblum and Wolf [1997] investigate a
design framework for Internet-scalevent notification. All are
concerned with the scope and requirements of an EBI styrather than
providing solutions for network-based systems.
Style Derivation Net
Per
form
.
UP
Per
form
.
Effi
cien
cy
Sca
labi
lity
Sim
plic
ity
Evo
lvab
ility
Ext
ensi
bilit
y
Cus
tom
iz.
Con
figur
.
Reu
sabi
lity
Vis
ibili
ty
Por
tabi
lity
Rel
iabi
lity
EBI ++++ ++++ − − − − −−−− ±±±± ++++ ++++ ++++ ++++ −−−−
−−−−
C2 EBI+LCS ++++ ++++ ++++ ++++++++ ++++ ++++ ++++++++ ±±±± ++++
±±±±
DO CS+CS −−−− ++++ ++++ ++++ ++++ −−−− −−−−
BDO DO+LCS −−−− −−−− ++++++++ ++++ ++++ ++++++++ −−−− ++++
20 Software Architectural Styles for Network-based
Applications
-
euse ce. It nous , are f with
m
ot say plete ering. l-
e
g as ata, a thread on, er oca-ed
ade
tions is
ely to of
er jects ject ation ment, 991].
ce, data r
5.6 Other Hybrid Styles
5.6.1 C2
The C2 architectural style [Taylor et al., 1996] is directed at
supporting large grain rand flexible composition of system
components by enforcing substrate independendoes so by combining
event-based integration with layered-client-server.
Asynchronotification messages going down, and asynchronous request
messages going upthe sole means of intercomponent communication.
This enforces loose coupling odependency on higher layers (service
requests may be ignored) and zero couplinglower levels (no
knowledge of notification usage), improving control over the
systewithout losing most of the advantages of EBI.
Notifications are announcements of a state change within a
component. C2 does nwhat should be included with a notification: a
flag, a delta of state change, or a comstate representation are all
possibilities. A connector’s primary responsibility is therouting
and broadcasting of messages; its secondary responsibility is
message filtThe introduction of layered filtering of messages
solves the EBI problems with scaability, while improving
evolvability and reusability as well. Heavyweight connectorsthat
include monitoring capabilities can be used to improve visibility
and reduce threliability problems of partial failure.
5.6.2 Distributed Objects
The distributed objects style organizes a system as a set of
components interactinpeers. An object is an entity that
encapsulates some private state information or dset of associated
operations or procedures that manipulate the data, and possibly of
control so that collectively they can be considered a single unit
[Chin and Chans1991]. In general, an object’s state is completely
hidden and protected from all othobjects. The only way it can be
examined or modified is by making a request or invtion on one of
the object’s publicly accessible operations. This creates a
well-defininterface for each object, enabling the specification of
an object’s operations to be mpublic while at the same time keeping
the implementation of its operations and therepresentation of its
state information private, which in turn improves evolvability.
An operation may invoke other operations, possibly on other
objects. These operamay in turn make invocations on others, and so
on. A chain of related invocations referred to as an action [Chin
and Chanson, 1991]. State is distributed among the objects. This
can be advantageous in terms of keeping the state where it is most
likbe up-to-date, but has the disadvantage in that it is difficult
to obtain an overall viewsystem activity (poor visibility).
In order for one object to interact with another, it must know
the identity of that othobject. When the identity of an object
changes, it is necessary to modify all other obthat explicitly
invoke it [Garlan and Shaw, 1993]. There must be some controller
obthat is responsible for maintaining the system state in order to
complete the applicrequirements. Central issues for distributed
object systems include: object manageobject interaction management,
and resource management [Chin and Chanson, 1
Object systems are designed to isolate the data being processed.
As a consequenstreaming is not supported in general. However, this
does provide better support foobject mobility when combined with
the mobile agent style.
Software Architectural Styles for Network-based Applications
21
-
use ased rib-er t that
vel
ards vel-
appli-are rn.
are ctural nts for and
ssifi-
aw nts ifica-y the ed in ; how t type ears n. It
valu-t the t
style s with ela-chi-s can
tterns
5.6.3 Brokered Distributed Objects
In order to reduce the impact of identity, modern distributed
object systems typicallyone or more intermediary styles to
facilitate communication. This includes event-bintegration and
brokered client/server [Buschmann et al., 1996]. The brokered
distuted object style introduces name resolver components whose
purpose is to answclient object requests for general service names
with the specific name of an objecwill satisfy the request.
Although improving reusability and evolvability, the extra leof
indirection requires additional network interactions, reducing
efficiency.
Brokered distributed object systems are currently dominated by
the industrial standdevelopment of CORBA within the OMG [1997] and
the international standards deopment of Open Distributed Processing
(ODP) within ISO/IEC [1995].
In spite of all the interest associated with distributed
objects, they fare poorly whencompared to most other network-based
architectural styles. They are best used forcations that involve
the remote invocation of encapsulated services, such as
hardwdevices, where the efficiency and frequency of network
interactions is less a conce
6 Related Work
I include here only those areas of research that describe,
define, or embody softwarchitectural styles. Other areas for
software architectural research include architeanalysis techniques,
architecture recovery and reengineering, tools and
environmearchitectural design, architecture refinement from
specification to implementation, case studies of deployed software
architectures [Garlan and Perry, 1995].
6.1 Classification of Architectural Styles and Patterns
The area of research most directly related to this survey is the
identification and clacation of architectural styles and
architecture-level patterns.
Shaw [1990] describes a few architectural styles, later expanded
in Garlan and Sh[1993]. A preliminary classification of these
styles is presented in Shaw and Cleme[1997] and repeated in Bass et
al. [1998], in which a two-dimensional, tabular classtion strategy
is used with control and data issues as the primary axes, organized
bfollowing categories of features: which kinds of components and
connectors are usthe style; how control is shared, allocated, and
transferred among the componentsdata is communicated through the
system; how data and control interact; and, whaof reasoning is
compatible with the style. The primary purpose of the taxonomy
appto be simply to identify style characteristics, rather than to
assist in their comparisoconcludes with a small set of “rules of
thumb” as a form of design guidance
Unlike this survey, the Shaw and Clements [1997] classification
does not assist in eating designs in a way that is useful to an
application designer. The problem is thapurpose of building
software is not to build a specific shape, topology or
componentype, so organizing the classification in that fashion does
not help a designer find athat corresponds to their needs. It also
mixes the essential differences among styleother issues which have
only incidental significance, and obscures the derivation
rtionships among styles. Furthermore, it does not focus on any
particular type of artecture, such as network-based applications.
Finally, it does not describe how stylebe combined, nor the effect
of their combination.
Buschmann and Meunier [1995] describe a classification scheme
that organizes paaccording to granularity of abstraction,
functionality, and structural principles. The
22 Software Architectural Styles for Network-based
Applications
-
me-n s and nd
s, t al.
the n
age s in a mu-
soft-
r, the
task,
ode bile e-
stan- stry-
f inte-
the al e use
helf the
into struc-
granularity of abstraction separates patterns into three
categories: architectural fraworks (templates for architectures),
design patterns, and idioms. Their classificatioaddresses some of
the same issues as this survey, such as separation of
concernstructural principles that lead to architectural properties,
but only covers two of thearchitectural styles described here.
Their classification is considerably expanded inBuschmann et al.
[1996] with more extensive discussion of architectural patterns
atheir relation to software architecture.
Zimmer [1995] organizes design patterns using a graph based on
their relationshipmaking it easier to understand the overall
structure of the patterns in the Gamma e[1995] catalog. However,
the patterns classified are not architectural patterns,
andclassification is based exclusively on derivation or uses
relationships rather than oarchitectural properties.
6.2 Distributed Systems and Programming Paradigms
Andrews [1991] surveys how processes in a distributed program
interact via messpassing. He defines concurrent programs,
distributed programs, kinds of processedistributed program
(filters, clients, servers, peers), interaction paradigms, and
comnication channels. Interaction paradigms represent the
communication aspects of ware architectural styles. He describes
paradigms for one-way data flow through networks of filters
(pipe-and-filter), client-server, heartbeat, probe/echo,
broadcast,token passing, replicated servers, and replicated workers
with bag of tasks. Howevepresentation is from the perspective of
multiple processes cooperating on a singlerather than general
network-based architectural styles.
Fuggetta et al. [1998] provide a thorough examination and
classification of mobile cparadigms. This survey builds upon their
work to the extent that I compare the mocode styles with other
network-capable styles, and place them within a single framwork and
set of architectural definitions.
6.3 Middleware
Bernstein [1996] defines middleware as a distributed system
service that includes dard programming interfaces and protocols.
These services are called middlewarebecause they act as a layer
above the OS and networking software and below induspecific
applications. Umar [1997] presents an extensive treatment of the
subject.
Architecture research regarding middleware focuses on the
problems and effects ograting components with off-the-shelf
middleware. Di Nitto and Rosenblum [1999] describe how the usage of
middleware and predefined components can influence architecture of
a system being developed and, conversely, how specific
architecturchoices can constrain the selection of middleware.
Dashofy et al. [1999] discuss thof middleware with the C2
style.
Garlan et al. [1995] point out some of the architectural
assumptions within off-the-scomponents, examining the authors’
problems with reusing subsystems in creatingAesop tool for
architectural design [Garlan et al., 1994]. They classify the
problemsfour main categories of assumptions that can contribute to
architectural mismatch:nature of components, nature of connectors,
global architectural structure, and contion process.
Software Architectural Styles for Network-based Applications
23
-
e -ign the
on ns
struc-es are of
olo-ture does olo-t
eads trol cture.
nd citing 994]
ety g a
archi-
s are e than
frame-s or lica-
6.4 Handbooks for Design, Design Patterns, and Pattern
Languages
Shaw [1990] advocates the development of architectural handbooks
along the samlines as traditional engineering disciplines. As
discussed in Section 2.3, the objectoriented programming community
has taken the lead in producing catalogs of despatterns, as
exemplified by the books on design patterns [Gamma et al., 1995]
andessays edited by Coplien and Schmidt [1995].
Patterns tend to be more problem-oriented than architectural
styles. Shaw [1996] presents more detail on eight example
architectural patterns, including informationthe kinds of problems
best suited to each architecture, but doesn’t draw comparisobetween
the architectural patterns.
Tepfenhart and Cusick [1997] use a two dimensional map to
differentiate among domain taxonomies, domain models, architectural
styles, frameworks, kits, designpatterns, and applications. In the
topology, design patterns are predefined design tures used as
building blocks for a software architecture, whereas architectural
stylsets of operational characteristics that identify an
architectural family independentapplication domain. However, they
fail to define architecture itself.
6.5 Design Methodologies
Most early research on software architecture was concentrated on
design methodgies. For example, object-oriented design [Booch,
1986] advocates a way to strucproblems that leads naturally to an
object-based architecture (or, more accurately,not lead naturally
to any other form of architecture). One of the first design
methodgies to emphasize design at the architectural level is
Jackson System Developmen[Cameron, 1986]. JSD intentionally
structures the analysis of a problem so that it lto a style of
architecture that combines pipe-and-filter (data flow) and process
conconstraints. These design methodologies tend to produce only one
style of archite
There has been some initial work at investigating methodologies
for the analysis adevelopment of architectures. Kazman et al. have
described design methods for elithe architectural aspects of a
design through scenario-based analysis with SAAM [1and
architectural trade-off analysis via ATAM [1999]. Shaw [1995]
compares a variof box-and-arrow designs for an automobile cruise
control system, each done usindifferent design methodology and
encompassing several architectural styles.
6.6 Reference Models and Domain-specific Software Architectures
(DSSA)
Reference models are developed to provide conceptual frameworks
for describing tectures and showing how components are related to
each other [Shaw, 1990].
The Object Management Architecture (OMA), developed by the OMG
[1995] as a reference model for brokered distributed object
architectures, specifies how objectdefined and created, how client
applications invoke objects, and how objects can bshared and
reused. The emphasis is on management of distributed objects,
ratherefficient application interaction.
Hayes-Roth et al. [1995] define domain-specific software
architecture (DSSA) as comprising: a) a reference architecture,
which describes a general computational work for a significant
domain of applications, b) a component library, which
containreusable chunks of domain expertise, and c) an application
configuration method fselecting and configuring components within
the architecture to meet particular apption requirements. Tracz
[1995] provides a general overview of DSSA.
24 Software Architectural Styles for Network-based
Applications
-
ing tyle
e
f
n for inter-lows res
archi-and itec-r
99].
s with
s of x- in rties of
o d by y i-
el, it ose
e or the
m for
DSSA projects have been successful at transferring architectural
decisions to runnsystems by restricting the software development
space to a specific architectural sthat matches the domain
requirements [Medvidovic et al., 1999]. Examples includeADAGE
[Batory et al., 1995] for avionics, AIS [Hayes-Roth et al., 1995]
for adaptivintelligent systems, and MetaH [Vestal, 1996] for
missile guidance, navigation, andcontrol systems.
6.7 Architecture Description Languages (ADL)
Most of the recent published work regarding software
architectures is in the area oarchitecture description languages
(ADL). An ADL is, according to Medvidovic andTaylor