Difference between revisions of "GCube Infrastructure Enabling Services"
From Gcube Wiki
Manuele.simi (Talk | contribs) |
Luca.frosini (Talk | contribs) (→Overall Architecture) |
||
| (13 intermediate revisions by 3 users not shown) | |||
| Line 1: | Line 1: | ||
| − | 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 facilities | + | 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 == | == Overall Architecture == | ||
| − | The | + | 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 '''''[[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 '''''[[ | + | * 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]]''). |
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 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 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).
