Software Management Functions

From Gcube Wiki
Jump to: navigation, search

While the Resource Model no longer prescribes 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. 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:

Software Resources

A dynamic view of some interactions between resources is provided by the following diagram:

Software Resource Interactions