[glue-wg] intros for 7.1 through 7.5

[Maarten.Litmaath at cern.ch]

Hi all,
below is my attempt at intros for 7.1 through 7.5.

There are 2 "FIXME" instances in the text that pertain to this question:
how can we publish an access protocol that has a fixed endpoint?

For example, a dCache instance might have a fixed gsidcap or gsiftp
server for legacy clients that cannot deal with the SRM.

I suppose we discussed this before the public comment phase,
but I do not recall the outcome, so I went with the content of
the "pc_r2" draft currently published on the GLUE web site:
the access protocol would have to be published as an Interface.

Comments?
Thanks,
	Maarten

----------------------------------------------------------------------
7.1 StorageService

A StorageService represents a grid-enabled storage system, most often
hosted by a single site, but possibly distributed over multiple sites.
A StorageService makes StorageShares of given properties available to
selected UserDomains, typically (not necessarily) through one or more
explicitly identified StorageEndpoints.  Data can be stored in or
retrieved from StorageShares through one or more
StorageAccessProtocols.  A StorageShare is a composition of chunks
from one or more DataStores.  StorageShares may overlap.  A DataStore
represents a physical device that can hold data (e.g. a disk or a tape
robot).  Each DataStore is managed by a StorageManager, an instance of
a particular product identified by the ProductName and ProductVersion.
StorageServiceCapacity objects summarize capacity-related information
for which details may be available associated to StorageShares and
DataStores.

7.2 StorageServiceCapacity

A StorageServiceCapacity summarizes capacity-related information for
all the StorageShares and DataStores of a given homogeneous type.
The summaries may be compared to the sums of the relevant
StorageShareCapacity attributes for the StorageShares of the given
type.  Capacities of overlapping StorageShares must only be counted
once.  An inconsistency between a summary value and the corresponding
sum of relevant attributes can occur if part of the capacity is not
explicitly published, or if the attributes concerned could not all be
exactly determined or recorded at the same time.  The summaries may
also be compared to the sums of the relevant attributes of the
DataStores of the given type, where inconsistencies may arise due to
similar causes.

7.3 StorageAccessProtocol

A StorageAccessProtocol describes a protocol that can be used to store
data in or retrieve data from StorageShares.  The "file" protocol
indicates that for ComputingServices given by ToComputingService
objects the StorageShares are available through POSIX I/O.  The mount
point details are given by corresponding ToStorageService objects
published by those ComputingServices.  Most protocols require a
negotiation between the client and a StorageEndpoint.  For example,
a StorageEndpoint implementing a version of the SRM protocol can be
asked for a data transfer URL corresponding to a desired access
protocol.  An access protocol that does not require prior negotiation
can be published as the Interface in a StorageEndpoint supporting that
protocol [FIXME].

7.4 StorageEndpoint

A StorageEndpoint represents a service that can be contacted by
clients to manage StorageShares and to store or retrieve data.  The
StorageEndpoint typically implements a control protocol given by the
Interface, which allows for the manipulation of StorageShares and the
properties of their data content.  Access to StorageShares for storing
or retrieving data often has to be negotiated through the given
control protocol.  The available access protocols can be published in
StorageAccessProtocol objects.  The StorageEndpoint Interface may also
indicate itself an access protocol that does not require prior
negotiation [FIXME].  The StorageEndpoint may be able to serve only a
subset of the StorageShares within the StorageService, in which case
that subset can be indicated through explicit associations with those
StorageShares.

7.5 StorageShare

A StorageShare is a composition of chunks from one or more DataStores.
StorageShares that overlap have the same SharingID, which in that case
must neither be empty nor the string "dedicated".  A DataStore
represents a physical device that can hold data (e.g. a disk or a tape
robot).  A StorageShare need not be composed of homogeneous devices.
The AccessLatency gives the maximum latency category for a file stored
in the StorageShare to be made available for reading.  For example, if
the StorageShare comprises both disk and tape, and data may need to be
recalled from tape, the published AccessLatency is "nearline".  The
RetentionPolicy indicates the probability of the StorageShare losing
data.  For example, "custodial" represents a very low probability,
while "replica" indicates that the StorageShare is not suitable for
keeping the only copy of precious data, but can be used for keeping
a replica of such data.  The ExpirationMode indicates what happens to
data whose lifetime has expired, if ever.  The Identifier allows the
StorageShare to be given a tag that is meaningful for the
UserDomain(s) served by the StorageShare.  For example, for version
2.2 of the SRM control protocol a StorageShare would represent a Space
and the Identifier the corresponding SpaceTokenUserDescription.
Capacity-related information is made available through
StorageShareCapacity objects.  A StorageShare need not be available
through StorageEndpoints not explicitly listed.
----------------------------------------------------------------------