Difference between revisions of "GCube Infrastructure Enabling Services"

From Gcube Wiki
Jump to: navigation, search
(Overall Architecture)
(Overall Architecture)
 
(6 intermediate revisions by 3 users not shown)
Line 16: Line 16:
 
The gCube Infrastructure Enabling Services consist of three cooperating subsystems whose role, functions and relations are the following:
 
The gCube Infrastructure Enabling Services consist of three cooperating subsystems whose role, functions and relations are the following:
  
* The '''''[[Information System]]''''' represents the “core” 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
+
* The '''''[[gCore Based 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;  
 
: (''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.  
 
: (''ii'') discover the resources they are interested to interact with in order to accomplish its functionality.  
  
: Two client libraries, the [[IS-Publisher]] (production/publishing) and the [[IS-Client]] (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  
+
: 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 high workload they could be subject to,
 
:* the robustness and fault-resiliency expected by such a critical component,
 
:* the robustness and fault-resiliency expected by such a critical component,
:* new service IS instances are dynamically deloyed
+
:* new service IS instances are dynamically deployed
  
: This way such dynamicity is completely transparent to the Information System clients.
+
: 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 '''''[[Data e-Infrastructure Policy-oriented Security Facilities]]''''' 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. 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. Architecturally, the subsystem is organized in several modules: [[GCube Security Handler]], [[SOA3 Authentication Module]], [[SOA3 Authorization Module]], and [[SOA3 User Management Module]].
  
* The '''''[[Virtual Organisation Management]]''''' represents 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, some of the components of this subsystem are expected to be ubiquitous in a gCube-based infrastructure as 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.
+
* The '''''[[Resource_Management_Specification|Resource 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 [[gCore Based 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 [[Data e-Infrastructure Policy-oriented Security Facilities]] 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 Gateway]]'' and ''[[gHN Manager]]'').
 
+
 
+
* The '''''[[VRE Management]]''''' is in charge for the ''definition'' and ''deployment'' of such Virtual Research Environments (VREs) by exploiting the resources of a gCube based Infrastructure. Thus, it needs to interact with the [[Information System]] to be acquainted of the resources that are available as well as of their status, to select them appropriately and finally to monitor the VRE operations. Moreover, it is 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 characterised by (i) services implementing the front-end (''[[VRE Modeler]]'') mediating between the users' high level requirements and the subsystem back-end; (ii) services coordinating the deployment and operation of the VRE (''[[Resource Manager]]''); and Services supporting the dynamic deployment (''[[Deployer]]'', ''[[Software Repository]]'' and ''[[gHN Manager]]'').
+

Latest revision as of 13:54, 19 October 2016

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 gCore Based 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 Resource 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 gCore Based 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 Data e-Infrastructure Policy-oriented Security Facilities 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 Gateway and gHN Manager).