\reviewtitle{The Anatomy of the Grid: Enabling Scalable Virtual Organizations}
\reviewlabel{foster01anatomy}
\reviewauthor{Ian Foster, Carl Kesselman, Steven Tuecke}

The authors attempt to formulate a definition for what the Grid is
trying to be and what components it needs to have in order to take
that shape.  In particular they argue that existing technologies do
not support ``virtual organizations'' from being able to flexibly
share one another's resources.  For this reason, a new technology, the
Grid, is necessary.  The Grid's architecture follows an hourglass
form, with broad interface definitions at the top and bottom, and
narrow ones in the middle.  The layered architecture, in order, is:
application, collective, resource, connectivity, and fabric.  Although
the authors occasionally depict the architecture as a stack (and, in
fact, place it next to the OSI stack for comparison), here the
application can in fact make direct calls to the resource and
connectivity layers.  Another real deficit is that they do not
differentiate between global and local perspectives (and seem to
perceive of everything from a one-off global perspective).  For
example, it appears that collectives (collections of resources) are
the same collection of resources from everyone's point of view ---
that my collection is your collection and vice versa.  Similarly they
use the centralized X.509 format instead of the more flexible and
relative SPKI.  This is particularly interesting because they suggest
that sharing relationships between virtual organizations (VOs) ``do
not necessarily involve an explicitly named set of individuals'' but
instead may include ``students.''  This level of indirection is what
SPKI is good at; I'm not sure if it's available in X.509.  They
suggest that several major technology trends (\eg Internet,
enterprise, distributed and p2p computing) all have much to gain from
the Grid, but, strangely, they do not suggest that the Grid could
benefit from them.  In discussing the Grid architecture, the authors
spend a great deal of their time talking about coscheduling, which is
presumably of great import in the type of applications they are
envisioning.

They offer a definition of the goal of the Grid:
``flexible, secure, coordinate resource sharing among dynamic
collections of individuals, institutions, and resources --- what we
refer to as virtual organizations.''

The narrow components of the Grid architecture are the resource and
connectivity protocols.  The components in greater depth are:
\begin{description}
\item[Fabric]
Fabric components implement the local, resource-specific operations
that occur on specific resources (whether physical or logical) as a
result of sharing operations at higher levels.  Here the authors
include ``enquiry'' mechanisms that permit discovery of state and
capabilities and ``resource management'' mechanisms (\eg
General-purpose Architecture for Reservation and Allocation (GARA),
Portable Batch System, and Condor).

\item[Connectivity]
This layer enables the exchange of data between Fabric layer
resources.  It includes communication and authentication.  Globus
includes the Grid Security Infrastructure (GSI), which is mainly
built on the Transport Layer Security (TLS) protocol.  Local policies
can be integrated via the Generic Authorization and Access (GAA)
control interface.

\item[Resource]
``Resource layer protocols are concerned entirely with individual
resources and hence ignore issues of global state and atomic actions
across distributed collections.''  The classes of resource protocols
are (1) information and (2) management.  These appear to be directly
analogous to the Fabric's enquiry and resource management
mechanisms.  The Globus implementations of the resource level
include: Grid Resource Information Protocol (GRIP, based on LDAP),
Grid Resource Access and Management (GRAM, HTTP-based), and GridFTP.

\item[Collective]
These are collections of resources and this layer offers services on
collections.  For example: directory services allow users to query
for resources by name and/or attributes such as type, availability,
or load; co-location and scheduling services, like Condor-G; data replication
\end{description}

The authors offer a nice rebuttal of many confusing points about the
Grid.  One in particular is that even though it is distributed, it
does not need a new computing model --- I bet Jim Waldo would disagree.