Resource Model (2nd generation)

At its core, the system provides a set of management functions over broad classes of computational resources. Each function targets a specific class of resources, and its implementation requires and/or produces descriptive information about resources in the target class. Independently from individual functions, the system defines an abstract model for this information as well as a concrete XML binding for its serialisation on the wire.

This documents overviews the resource model adopted by the latest version of the system, and the new vision of resource management which underlies its design.

Design Principles

In previous versions, the system took a fairly static view over its resource management functions, often equating them with their latest implementations. As a result, the classes of managed resources and the model of resources within each class was centrally and fully prescribed within the system. Resource in a given class were exactly described by the information required and/or produced by all the functions defined over that class.

Semantic variations within a given class were modelled in hierarchies, insofar as the variations could be anticipated. Each class and subclasses had its own XML binding, and their hierarchies were mirrored in binding schemas used for validating resource publication and discovery.

Since changing the hierarchies would have an endemic impact within the system, a distinguished class of generic resources accommodated all resources that could not be retrofitted within the existing hierarchies. The system evolved within this scheme, occasionally acquiring new management functions and, far more commonly, refining the implementation of existing functions. Each change would reflect on the resource model with the addition of new information. The catch-all class of generic resources grew beyond initial expectations.

In its latest version, the system takes a more abstract view over its management functions. Functions are described solely by their APIs, and different implementations of the same functions may be available in the system, either over time or even concurrently. Different parties may provide implementations.

As the implementations may require and/or produce different information about the target resources, the system no longer prescribes a concrete model of managed resources. Rather, the implementations are responsible for defining the resource information that they require and/or produce, and for binding that information to an XML serialisation.

With this new approach, the concrete semantics of a resource is not found within predefined hierarchies. Instead, it is carried implicitly by the pieces of information that, at any point in time, the implementations have independently attached to the resource in order to manage it. Each such piece of is a resource facet, and the semantics of a resource is the collection of its current facets.

Multi-faceted Resources and their Relationship to Management Functions

The system remains responsible for defining cross-function properties of resources, and for defining the framework in which arbitrary facets may be collated into resource descriptions. This framework is the new resource model of the system.

Resources

All the resources managed by the system are described by the following properties:

• a unique identifier;
• an optional name;
• an optional description;
• one more scopes. Resource scopes are motivated and defined by the scope model of the system;
• zero or more facets, where facets are uniquely named but otherwise vary arbitrarily in structure and content;

The lifetime of resources is intrinsically related to the resource publication function of the system and the local or remote APIs of the components that implement the function. Resource identifiers, names, and descriptions are defined when resources are first published through these APIs. At that time, resources enter implicitly the scope in which publication occurs, and optionally acquire one more facets. Resources may enter other scopes during their lifetime, again implicitly by publication in those scopes.

Also through the publication APIs, resources may explicitly exit scopes and facets may added, changed, or removed. Descriptions may also change, while names and identifiers are immutable once assigned.

Resources serialise as XML documents rooted in a resource element with an id attribute for the resource identifier. name, description, and a list of one or more scope elements nest inside the document root prior to any facet serialisation. All the elements and attributes are namespaced in http://gcube-system.org/namespaces/common/resource, except for facets which may be named in any namespace as long as one such namespace exists.