GCube Infrastructure Enabling Services

The gCube Infrastructure Enabling Services collectively form the lower layer of the gCube framework whose role is to glue together and support the overall operation and management of the rest of constituents of a gCube based e-Infrastructure. The following classes of facilities are offered by the enabling services to the rest of the gCube infrastructure actors:

→ resources publishing and discovery

→ resources controlled sharing support

→ resources deployment and orchestration

→ resources selection support

→ and resource workflows definition and operation.

These facilities are globally delivered by a set of services, software libraries and related technologies described in the following.

Overall Architecture

The gCube Infrastructure Enabling Services consist of three cooperating subsystems whose role, functions and relations are the following:

• The Information System represents the binding point of the infrastructure playing the role of a Registry in a gCube-based Infrastructure. All actors partaking to a gCube based infrastructure are expected to interact with it in order to

(i) inform the rest of the resources about its presence and its distinguishing features;

(ii) discover the resources they are interested to interact with in order to accomplish its functionality.

Two client libraries, one for production/publishing and one for discovery/consumption are distributed as part of this subsystem to facilitate such interactions and to decouple the producer and consumer service logic from the internal organization and deployment of the IS services. This decoupling is fundamental because the IS services can be replicated and distributed across multiple VOs depending on

• the high workload they could be subject to,
• the robustness and fault-resiliency expected by such a critical component,
• new service IS instances are dynamically deployed

The gCore legacy clients are the IS-Publisher and the IS-Client, while the new clients belonging to the Featherweight Stack are respectively the Registry-Publisher and the Ic-client.

This way such dynamism is completely transparent to the Information System clients.

• The Virtual Organisation Management is the subsystem securing the sharing and reuse of the constituents a gCube based Infrastructure, i.e. all the managed resources. The subsystem implements a security framework realizing the Virtual Organization model on which the GCube Security Model is based. The main functions of this subsystem are related to authentication and authorization. Because of this role, the components of this subsystem are expected to be ubiquitous in a gCube-based infrastructure to facilitate the exploitation of these features. VO Management is also in charge to provide mechanisms to achieve a production level interoperability with identified external infrastructures. Architecturally, the subsystem is organized in some local libraries available on each gHN and an instance of Argus.

• The VRE Management is in charge for the definition and deployment of Virtual Research Environments (VREs) and Virtual Organisation (VOs) by exploiting the resources of a gCube-based Infrastructure. Thus, it interacts with the Information System to be acquainted of the resources that are available as well as of their state, to select them appropriately and finally to monitor the VRE operations. Moreover, it is also requested to interact with the Virtual Organisation Management to both act securely and create the security context supporting each Virtual Research Environment. The main achievement is the deployment phase where the optimal pool of resources is identified and deployed in order to create a VRE compliant with its definition. From an architectural point of view it is characterized by (i) services implementing the front-end (VRE Modeler) mediating between the users' high level requirements and the other back-end services; (ii) services coordinating the deployment and operation of the VRE (Resource Manager); (iii) a service (Resource Broker)) in charge of identifying the optimal allocation of to-be-created service's instances; and (iv)Services supporting the dynamic deployment (Deployer, Software Repository and gHN Manager).