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.
 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.
Software Resources
While the model does no longer prescribe the exact structure and semantics of resources, broad classifications remain meaningful. This is particularly the case for software resources, which are the target of most management functions in its core facilities. The system itself provides a number of software resources, and it often manages other types of computational resources (e.g. processors, storage, data) indirectly, through software abstractions that virtualise the resources for management purposes (e.g. data access services, file storage services, job submission services).
All the management functions offered by the system align with a broad classification of software sources which The classification gives scope to the functions and defines a terminology for the design and documentation of the components that implement those functions.
A first distinction between software resources is their role in network interactions:
- services are software resources that accept requests made over the network. In its current version, the system concerns itself with services that use HTTP (at least) as their transport protocol. HTTP services may be WS services, use SOAP over HTTP as a higher-level transport, and WS services are RPC services when SOAP carries requests and responses of service-specific APIs. Some services are stateless, in that their endpoints do not manage any form of state on behalf of clients. Other services are instead stateful, in that their endpoints host a number of service instances, all of which maintain state for a class of clients. HTTP services may also be REST services, in the broad sense of stateless services that use HTTP directly as their application protocol. Typically, services run within a shared runtime controlled by some service container (e.g. a Servlet container or a Restlet container).
- clients are software resources that make requests to services. Clients may operate within a dedicated runtime, i.e. may be pure clients, while others may share a local runtime controlled by some container. In particular, clients may be services in turn.
- libraries are software resources that support the development of clients and/or services. Client libraries support client development and may engage in network interactions on behalf of their clients (e.g. may implement service proxies or façades). Service libraries support service development. Libraries may support the development of both clients and services.
Orthogonally to their role, a second distinction between software resources concerns their relationship to the system:
- managed resource are software resources upon which the system applies some of its management functions. For services, management functions start with publication, discovery, and controlled sharing. For clients, management functions focus on supporting interactions with managed services. The deployment of managed services qualifies the deployment environments as gCube Hosting Nodes (gHNs).
- unmanaged services are software resources that lie outside the purview of the system but can be called, directly or indirectly, by managed services. Intuitively, these are resources accessible by or through the system. Unmanaged clients, i.e. clients of unmanaged services, are of no relevance to the system and its functional scope.
Finally, a third distinction holds between managed resources:
- system resources are managed resources included in system releases. These include (pure) clients and services.
- dependent resources are managed resources that have compile-time dependencies to system resources. System resources normally have inter-dependencies, hence they are typically dependent resources. However, they do not have to be.
- independent resources are managed resources that have no compile-time dependencies to system resources.
The classifications above are informally captured in the following diagram:
A dynamic view of some interactions between resources is provided by the following diagram:
