Difference between revisions of "GCube Infrastructure Enabling Services"
Manuele.simi (Talk | contribs) (→Overall Architecture) |
Manuele.simi (Talk | contribs) (→Overall Architecture) |
||
| Line 4: | Line 4: | ||
The overall architecture of the gCube Infrastructure Enabling Services is depicted in Figure 1. It consists of six cooperating subsystems whose role, functions and relations are briefly described in the rest of this section. | The overall architecture of the gCube Infrastructure Enabling Services is depicted in Figure 1. It consists of six cooperating subsystems whose role, functions and relations are briefly described in the rest of this section. | ||
| − | + | ---- | |
| + | |||
The '''''[[Information System]]''''' represents the “core” of the overall infrastructure since it is the subsystem playing the role of Registry in a gCube based Infrastructure. Because of its role, all resources partaking to a gCube based infrastructure are expected to interact with it (''i'') to ''inform'' the rest of the resources about its presence and its distinguishing features; and (''ii'') to discover the resources they are interested to interact with in order to accomplish its functionality. To facilitate such an interaction and to decouple the ''producer'' and ''consumer'' service logic from the internal organisation of such a subsystem two main components are envisaged, i.e. the [[IS-Publisher]] and the [[IS-Client]] supporting respectively the production/publishing and consumption/discovery phases in the interaction with a registry. This decoupling is fundamental since (''i'') the high work load this component is potentially subject; (''ii'') the robustness and fault-resiliency expected by such a critical component; and (''iii'') the system feature of dynamically deploying new service instances dynamically, will lead to changes in the services implementing the internals of such subsystem. This way such dynamicity is completely transparent to the Information System clients. | The '''''[[Information System]]''''' represents the “core” of the overall infrastructure since it is the subsystem playing the role of Registry in a gCube based Infrastructure. Because of its role, all resources partaking to a gCube based infrastructure are expected to interact with it (''i'') to ''inform'' the rest of the resources about its presence and its distinguishing features; and (''ii'') to discover the resources they are interested to interact with in order to accomplish its functionality. To facilitate such an interaction and to decouple the ''producer'' and ''consumer'' service logic from the internal organisation of such a subsystem two main components are envisaged, i.e. the [[IS-Publisher]] and the [[IS-Client]] supporting respectively the production/publishing and consumption/discovery phases in the interaction with a registry. This decoupling is fundamental since (''i'') the high work load this component is potentially subject; (''ii'') the robustness and fault-resiliency expected by such a critical component; and (''iii'') the system feature of dynamically deploying new service instances dynamically, will lead to changes in the services implementing the internals of such subsystem. This way such dynamicity is completely transparent to the Information System clients. | ||
Revision as of 19:29, 8 June 2010
The gCube Infrastructure Enabling Services is the family of services and related technologies called upon to support the overall operation and management of the rest of constituents of a gCube based e-Infrastructure. The facilities needed to support such kind of e-Infrastructure fall in one of the following classes: resources publishing and discovery, resources controlled sharing support, resources deployment and orchestration, resources selection support and resource workflows definition and operation. Such facilities lead to the identification and organisation of a series of services, software libraries and related technologies described in the following overall architecture.
Overall Architecture
The overall architecture of the gCube Infrastructure Enabling Services is depicted in Figure 1. It consists of six cooperating subsystems whose role, functions and relations are briefly described in the rest of this section.
The Information System represents the “core” of the overall infrastructure since it is the subsystem playing the role of Registry in a gCube based Infrastructure. Because of its role, all resources partaking to a gCube based infrastructure are expected to interact with it (i) to inform the rest of the resources about its presence and its distinguishing features; and (ii) to discover the resources they are interested to interact with in order to accomplish its functionality. To facilitate such an interaction and to decouple the producer and consumer service logic from the internal organisation of such a subsystem two main components are envisaged, i.e. the IS-Publisher and the IS-Client supporting respectively the production/publishing and consumption/discovery phases in the interaction with a registry. This decoupling is fundamental since (i) the high work load this component is potentially subject; (ii) the robustness and fault-resiliency expected by such a critical component; and (iii) the system feature of dynamically deploying new service instances dynamically, will lead to changes in the services implementing the internals of such subsystem. This way such dynamicity is completely transparent to the Information System clients.
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 realising the Virtual Organisation model on which the D4Science Policy domain is based. The main functions this subsystem is called upon are related to authentication and authorisation. Because of this central 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.
The VRE Management represents the subsystem implementing the Virtual Research Environment concept. In particular, this subsystem supports the definition and deployment of such environments 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 monitor the VRE operation. 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. It will also interact with the Resource Broker during the deployment phase as to select the optimal pool of resources to exploit to deliver a VRE. 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).
The Broker and Matchmaker represents the subsystem promoting and supporting the optimal selection and usage of resources during the VRE deployment phase. In particular, it is invoked to select the most appropriate pool of gHNs to be used, among those available in the context of the VRE, during the deployment of the services needed to operate the VRE. Because of this, it interacts with (i) the Information System to be aware of the available gHNs as well as of their distinguishing features (e.g. the number of Running Instances currently hosted by it, the RAM the machine is equipped with) and (ii) with the Virtual Organisation Management to act securely and filter out the gHNs that falls out of the operational context of the VRE. From an architectural point of view it mainly consists of a service implementing the matchmaking algorithm.
The Process Management represents the subsystem managing gCube Compound Services, i.e. complex services obtained by combining existing services, either simple or compound, in workflows delivering advanced functionality. In particular, this subsystem supports both the definition and verification of such compound services as well as their execution in a distributed scenario, i.e. the orchestration of the overall workflow is distributed among the nodes partaking to it during the execution. Because of this, it is requested to interact to both the Information System and the Virtual Organisation Management as to be acquainted of the current status of a gCube based infrastructure it is operating. From an architectural point of view, it mainly consists of (i) a front end supporting the user in defining such a complex workflows of services, starting their execution and monitoring their status and (ii) a distributed engine orchestrating the workflow execution.
The Process Optimisation represents the subsystem promoting and supporting the optimal consumption of resources during Compound Services execution. Because of this it is expected to interact with both the Information System and Virtual Organisation Management to be aware of the current status of a gCube based Infrastructure and with the Process Management Engine to properly influence its behaviour. From an architectural point of view, it mainly consists of services dedicated to dynamically transform the execution plan governing the execution of the workflow.
