Difference between revisions of "Resource Model (2nd generation)"

Revision as of 22:35, 5 June 2012

Introduction

At its core, gCube provides a set of management functions over broad classes of computational resources. Functions include lifetime management, monitoring, sharing, reporting, deployment, security, and process execution. Resources include software components, the hardware on which those components run, and the data sources they produce and consume.

Each management function targets one or more resource classes. For example, deployment and process execution are concerned with software and hardware, security is concerned with software and data sources, and reporting applies to all resources. The implementation of the function is distributed across one or more system components, which are themselves primary examples of managed software resources. A single component may contribute to the implementation of multiple functions.

System components consume or produce information about resources in the target classes. gCube defines a descriptive model that regulates the representation and exchange of this information. Based on this resource model, it includes directory services that allow components to publish and discover resource descriptions (cf. Figure 1).

Figure 1: A model governs the description of resource descriptions produced and consumed by components that implements management functions defined over classes of related resources. The components rely on directory services to publish and discover resource descriptions.

First Generation

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. Quite simply, it 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 and the bindings were defined by schemas. 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 introduced to accommodate resource 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.

Second Generation

Starting from this version of the resource model, 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.

Facet Layer

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. It is instead carried implicitly by the information that, at any point in time, implementation components have independently attached to the resource in order to manage it (cf. Figure 2). Each such piece of information is a resource facet and, at ay point in time, the semantics of a resource 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 constitutes the facet layer of the new resource model.

Figure 2: Producers and consumers in the implementations of given management functions add and use only relevant facets in resource descriptions.

Interface Layer

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.

Figure 3

Resource Descriptions

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

a unique identifier;

the identifier of a resource allows system components to unambiguously separate it from other resources and to resolve references to the resource included in the description of other resources. Accordingly, the model requires its uniqueness and immutability but does not otherwise mandate a concrete syntax for it. Implementations will ensure that resource identifiers can be embedded in URIs (through escaping of characters forbidden by RFC 2396) and will offer guarantees for their immutability and global uniqueness.

an optional name;

the name of a resource serves solely for reporting purposes. The model does not mandate a syntax for it and allows it to change over time.

an optional description;

the description of a resource serves solely for reporting purposes. The model does not mandate a syntax for it and allows it to change over time.

one or more scopes;

the scopes of a resource limit access to the resource and visibility of its description to clients that operate in one of the scopes. The syntax of scopes is defined outside the model, as it is the responsibility for enforcing scopes. Scopes may added to or removed from resources over time

one or more facets;

facets are uniquely named but the model does not constrain a-priori their structure and content. Constraints on particular facets are introduced in the interface layer of the model. Facets may be added to or removed from resources over time.

XML Binding

Resources serialize as XML documents rooted in a resource element with at least an id attribute for the resource identifier, name, description, and a list of one or more scope elements nest inside the document root in that order and before facet serializations. All have simple, non-empty content and the content of name can be qualified with an arbitrary namespace. All the elements and attributes are defined in the namespace http://gcube-system.org/namespaces/common/resource, except for facets which may be named in any namespace, as long as one such namespace exists. Facets may be simple or complex elements, though they cannot mix elements and text nor include XML structures other than elements.

Formally, XML serializations of resources must validate against the following XML Schema:

<schema xmlns="http://www.w3.org/2001/XMLSchema" targetNamespace="http://gcube-system.org/namespaces/common/resource"
 xmlns:tns="http://gcube-system.org/namespaces/common/resource" elementFormDefault="qualified">
 
<element name="resource" type="tns:defaultResource" />
<complexType name="defaultResource">!
 <sequence>
    <element name="name" type="tns:nonemptyname" minOccurs="0" />
    <element name="description" type="tns:nonempty" minOccurs="0" />
    <element name="scope" type="tns:nonempty" maxOccurs="unbounded"/>
    <any processContents="lax" namespace="##other" maxOccurs="unbounded" />
 </sequence>
 <attribute name="id" type="string" />
 <anyAttribute processContents="lax"/>
</complexType>
 
<simpleType name="nonempty">
 <restriction base="string">
   <minLength value="1" />
   <pattern value=".*[^\s].*" />
 </restriction>
</simpleType>
 
<simpleType name="nonemptyname">
 <restriction base="QName">
   <minLength value="1" />
   <pattern value=".*[^\s].*" />
 </restriction>
</simpleType>
</schema>

Note that the schema lacks the expressiveness to capture all the constraints defined by the model (unique naming and content model enforcement for facets).

Type Interfaces

The model defines a number of type interfaces that standardize the properties common to broad classes of managed resources.