03:
ILLUSTRATION BY STUDIO TONNE / AGENCYRUSH.COM
may have simple or complex internal
state. Various aspects of this state may
be exposed so that external clients can
engage in “management” operations.
For example, an airline reservation system might give customers the ability to
programmatically create, monitor, and
manage reservations. The same system
might also allow operators to programmatically access information about
current system load and the mapping
of computational resources to different system functions. We are not suggesting these mechanisms provide direct access to the underlying state in its
entirety. Rather, we are assuming the
principles of encapsulation and data
integrity/ownership are maintained. It
is up to a system’s designer to define
the projections to those aspects of the
system’s internal state that they are
willing to expose to the outside world. 5
Such projections can be complex.
For example, in the case of a job management system, the underlying state
associated with even an apparently
simple job may consist of multiple distinct processes on different back-end
computers, entries in various internal tables and catalogs, and activities
within subsystems such as schedulers
and monitors. When designing the allowed interactions with such a system,
we must model the “state of a job” (the
projection of the complex underlying
state that is to be made available to clients) in a manner that is not only easy
for clients to understand and use but
that also makes it possible to maintain
this projection effectively.
It is unwieldy to keep talking about
“modeling a projection of underlying system state,” so we use the shorthand “modeling state.” It is important
to bear in mind, however, the reality
of what could be going on behind the
boundaries of a system with which an
interaction takes place.
We also make a few remarks concerning the difference between architectural styles and implementation
technologies. The evolution of the Web
from an infrastructure that enables
access to resources to a platform for
distributed applications has resulted
in much discussion on the relevant ar-
chitectural approaches and technologies. Terms such as representational
state transfer (REST; 3 an architectural
style) and HTTP (a protocol specification) are often used interchangeably to
indicate an architectural approach in
which a small set of verbs/operations
(PUT, GET, DELETE) with uniform semantics are used to build applications.
Similarly, the popularity of Web services (a set of protocol specifications) 1
has resulted in the use of that term as
a synonym for service orientation (an
architectural style).
We draw a distinction between the
architectural styles and their implementation technologies. Instances of
the former represent a collection of
principles and constraints that provide
guidance when designing and implementing distributed applications. In
contrast, the latter are the mechanisms
or tools used to apply the principles of
an architectural style when building
applications. There is not a one-to-one
mapping between an architectural
style and an implementation technology, even though one set of tools may
