Resource Model (2nd generation)

Introduction

At its core, the system provides a set of management functions over broad classes of computational resources. Functions include:

• lifetime management
• deployment
• monitoring
• reporting
• security
• and process execution.

Resources include:

• software services
• the hardware on which the services run
• and the data the services produce and consume.

Each management function targets one or more resource classes. Its implementation encompasses one or more components that consume or produce information about resources in the target classes.

The system defines a descriptive resource model that regulates the representation and exchange of this information and, based on the model, offers directory services that allow components to publish it and discover it. 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.

Rationale and Overview

At its inception, the system took a fairly static view over its management functions and equated them with their latest implementations. Resource classes were thus pre-defined and the model of resources within each class was centrally and fully prescribed. It simply collected the information required or produced by all the functions defined over that class. Semantic variations within classes were modelled with hierarchies, insofar as the variations could be anticipated. Classes and subclasses had their own XML bindings, the bindings were defined by schemas, and the schemas were used to validate the publication and discovery of resource descriptions.

Since changing the models had an endemic impact within the system, the schemas evolved to become less strict and a distinguished class of “generic” resources was defined to accommodate descriptions that could not be retrofitted within existing hierarchies. The system evolved within this scheme, occasionally acquiring new management functions and, far more commonly, refining the implementation of existing functions. The catch-all class of generic resources grew beyond initial expectations.

In its latest version, the system takes a more modular and abstract view over its management functions. Functions are described solely by their APIs, and different implementations of the same functions may exist within the system, over time or even concurrently. As different implementations may require different information about resources, the system no longer prescribes concrete resource models for them. Rather, implementations are responsible for defining the resource descriptions that they require or produce, and for binding that information to XML. With this approach, the semantics of a resource is not found within class hierarchies. Rather, it is carried implicitly by the information that, at any point in time, implementation components have independently attached to the resource in order to manage it. Each such piece of information is a resource facet, and the semantics of a resource at any point in time is the collection of its current facets. The system remains responsible for defining the framework in which arbitrary facets may be collated into completed resource descriptions. This framework yields the facet layer of the new resource model of the system.

Of course, consumers often raise overlapping requirements on the information that describes resources. Requirements may converge around resources of a given type, or subtypes thereof. In some cases, they may converge across resource types and along functions. Some requirements may apply indiscriminately to all resources managed by the system. It is undesirable to replicate information required by unrelated consumers within different, independently produced facets. Equally, it is undesirable to create unnecessary dependencies between unrelated publishers and consumers, i.e. expect the latter to access facets defined by the former. Converging modelling requirements are best addressed by sharing information within standard facets. These facets serve as information-oriented interfaces for resources, whereby the resources may be discovered and their models consumed for management purposes. The information that comprises interfaces is public within the system, while the rest remains private to a set of related publishers and consumers.

The facet layer of the new resource model does not address standardisation issues beyond the definition of a small set of common properties shared by all resource descriptions. Rather, it leaves the standardisation of facets to multi-party agreements of varying scope. System-wide agreements define interfaces common to all resources of a given resource type/subtype (type interfaces). Function-wide agreements define interfaces common to all the implementations of a given function (function interfaces).

Collectively, the interfaces identify a higher and evolving layer of the model, the interface layer. The flexibility of the facet layer underneath allows resources to have multiple interfaces, as well as to acquire interfaces over time.

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.