Garlan & Shaw: An Introduction to Software Architecture 5
One of these is based on the theory of abstract data types. But this is not the
only way to organize a software system.
Many other organizations have developed informally over time, and are
now part of the vocabulary of software system designers. For example, typical
descriptions of software architectures include synopses such as (italics ours):
•“Camelot is based on the client-server model and uses remote procedure
calls both locally and remotely to provide communication among
applications and servers.”[8]
•“Abstraction layering and system decomposition provide the appearance
of system uniformity to clients, yet allow Helix to accommodate a
diversity of autonomous devices. The architecture encourages a client-
server model for the structuring of applications.”[9]
•“We have chosen a distributed, object-oriented approach to managing
information.” [10]
•“The easiest way to make the canonical sequential compiler into a
concurrent compiler is to pipeline the execution of the compiler phases
over a number of processors. . . . A more effective way [is to] split the
source code into many segments, which are concurrently processed
through the various phases of compilation [by multiple compiler
processes] before a final, merging pass recombines the object code into a
single program.”[11]
Other software architectures are carefully documented and often widely
disseminated. Examples include the International Standard Organization's
Open Systems Interconnection Reference Model (a layered network
architecture) [12], the NIST/ECMA Reference Model (a generic software
engineering environment architecture based on layered communication
substrates) [13, 14], and the X Window System (a distributed windowed user
interface architecture based on event triggering and callbacks) [15].
We are still far from having a well-accepted taxonomy of such architectural
paradigms, let alone a fully-developed theory of software architecture. But we
can now clearly identify a number of architectural patterns, or styles, that
currently form the basic repertoire of a software architect.
3. Common Architectural Styles
We now examine some of these representative, broadly-used architectural
styles. Our purpose is to illustrate the rich space of architectural choices, and
indicate what are some of the tradeoffs in choosing one style over another.
To make sense of the differences between styles, it helps to have a common
framework from which to view them. The framework we will adopt is to treat
an architecture of a specific system as a collection of computational