Globally unique identifiers, their use and implementation are still an unresolved topic. The implementaton of objects that are identifiable and resolvable in a global sense must, given an open world, reflect the standards and best practices being used by the community as a whole. Consequently this area of the CDM is likely to change to reflect this.
The service layer implements a number of services designed to serve
as the basis of a LSID Resolution Service. This includes implementations
of LSIDAuthorityService
,
LSIDMetadataService
, and
LSIDDataService
. Note that these are
service-layer implementations - the http-specific components can be found
in the cdmlib-remote package.
In addition to implementations of the three core LSID Resolution
services, the service layer holds the
LSIDRegistry
, the component that maps LSID
authority + namespace combinations onto CDM classes. The implementation
assumes that a given authority and namespace will map onto a single CDM
base class, but that authorities may use different namespaces for the same
class of objects. In addition, the
LSIDRegistry
provides a way of controlling
which authority + namespace combinations a CDM application will respond
to. For example, it is possible that an application will store objects
with identifiers published by another (foreign) authority, but doesn't
wish to serve metadata about these objects. By only registering specific
authority + namespace combinations in the
LSIDRegistry
, a CDM store can resolve some
combinations but not others.
The three most common methods used are the
getAuthorityWSDL
and
getAvailableServices
methods that return a
javax.xml.transform.Source
within an
ExpiringResponse
object suitable for
rendering in a response to a client, and
getMetadata
, that returns an
IIdentifiableEntity
within a
MetadataResponse
. If the
authority+namespace is not resolved, or if the object cannot be resolved,
or if the client requests metadata in an unavailable format, an exception
is thrown.