Difference between revisions of "Resource Model (2nd generation)"
From Gcube Wiki
Manuele.simi (Talk | contribs) (Created page with 'The main requirement driving this new edition of the Resource Model is for an extensible notion of resource, particularly for a resource model which is open to modular extensions…') |
Manuele.simi (Talk | contribs) |
||
| Line 1: | Line 1: | ||
| − | The main requirement driving this new edition of the Resource Model is for an extensible notion of resource, particularly for a resource model which is open to modular extensions at runtime by arbitrary third parties (under appropriate security restrictions of course). | + | The main requirement driving this new edition of the Resource Model (named ''ReMo12'') is for an extensible notion of resource, particularly for a resource model which is open to modular extensions at runtime by arbitrary third parties (under appropriate security restrictions of course). |
| + | == Resource Characterizations== | ||
Resources share a minimal set of common properties (such as identifiers and scopes), but no further attempt is made to statically classify their semantics and the information required to describe it. Rather, the semantics of resources is: | Resources share a minimal set of common properties (such as identifiers and scopes), but no further attempt is made to statically classify their semantics and the information required to describe it. Rather, the semantics of resources is: | ||
| − | * | + | * characterized solely by the information that has been bound to them during their lifetime by various parties. This information, which we enumerate in units called ''facets'' |
* namespaced and act as configuration for a class of components that require it in order to carry out a given resource management function within the system. | * namespaced and act as configuration for a class of components that require it in order to carry out a given resource management function within the system. | ||
| + | |||
| + | == Software Resources== | ||
| + | |||
| + | We propose a model for gCube in which software resources are broadly classified with respect to their relationship to the system and their role in networked interactions. This classification defines a terminology for the design and documentation of the system. | ||
| + | We make a first distinction in role between: | ||
| + | * '''services''': resources that accept requests made over the network; | ||
| + | * '''clients''': resources that make requests to services; | ||
| + | |||
| + | A service may act as a client towards other services, while a client that does not act as a service is a pure client. Further, as we do for other types or resources, we distinguish between resources as follows: | ||
| + | * '''managed resources''': resources upon which the system applies some of its management functions. For services, management functions start with publications and controlled sharing. For clients, management functions focus on support for interactions with managed services. The deployment of managed services (static or dynamic) qualifies the target hardware resources | ||
| + | as gCube Hosting Nodes. | ||
| + | * '''unmanaged services''': services that lie outside the purview of the system but can be called, directly or indirectly, by managed services. Intuitively, these are resources made available to infrastructures based on deployments of the system. | ||
| + | Unmanaged clients, i.e. clients of unmanaged services, are of no interest to the system. | ||
| + | |||
| + | Finally, we distinguish between managed resources as follows: | ||
| + | * '''system resources''': resources that are included in system releases. These include (pure) clients and services. | ||
| + | * '''dependent resources''': 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''': resources that have no compile-time dependencies to system resources. | ||
| + | The classification above is informally captured in the following diagram: | ||
| + | |||
| + | [[Image:SoftwareResourceClassification.png|frame|center|Software Resources]] | ||
| + | |||
| + | |||
| + | A dynamic view of some interactions between resources is provided by the following diagram: | ||
| + | |||
| + | [[Image:SoftwareResourceInteractions.png|frame|center|Software Resources Interactions]] | ||
Revision as of 17:30, 27 February 2012
The main requirement driving this new edition of the Resource Model (named ReMo12) is for an extensible notion of resource, particularly for a resource model which is open to modular extensions at runtime by arbitrary third parties (under appropriate security restrictions of course).
Resource Characterizations
Resources share a minimal set of common properties (such as identifiers and scopes), but no further attempt is made to statically classify their semantics and the information required to describe it. Rather, the semantics of resources is:
- characterized solely by the information that has been bound to them during their lifetime by various parties. This information, which we enumerate in units called facets
- namespaced and act as configuration for a class of components that require it in order to carry out a given resource management function within the system.
Software Resources
We propose a model for gCube in which software resources are broadly classified with respect to their relationship to the system and their role in networked interactions. This classification defines a terminology for the design and documentation of the system. We make a first distinction in role between:
- services: resources that accept requests made over the network;
- clients: resources that make requests to services;
A service may act as a client towards other services, while a client that does not act as a service is a pure client. Further, as we do for other types or resources, we distinguish between resources as follows:
- managed resources: resources upon which the system applies some of its management functions. For services, management functions start with publications and controlled sharing. For clients, management functions focus on support for interactions with managed services. The deployment of managed services (static or dynamic) qualifies the target hardware resources
as gCube Hosting Nodes.
- unmanaged services: services that lie outside the purview of the system but can be called, directly or indirectly, by managed services. Intuitively, these are resources made available to infrastructures based on deployments of the system.
Unmanaged clients, i.e. clients of unmanaged services, are of no interest to the system.
Finally, we distinguish between managed resources as follows:
- system resources: resources that are included in system releases. These include (pure) clients and services.
- dependent resources: 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: resources that have no compile-time dependencies to system resources.
The classification above is informally captured in the following diagram:
File:SoftwareResourceClassification.png
Software Resources
A dynamic view of some interactions between resources is provided by the following diagram:
File:SoftwareResourceInteractions.png
Software Resources Interactions
