IS-Registry

From Gcube Wiki
Revision as of 11:21, 15 June 2009 by Manuele.simi (Talk | contribs) (Functions)

Jump to: navigation, search

The IS-Registry is a gCube Service called upon to manage gCube Resources by managing the registration/unregistration of their profiles. Its internals are structures as depicted in Figure 1, i.e. it mainly follows a Factory pattern.

Figure 1. IS-Registry Architecture

Resources and Properties

This Service creates and manage a WS-Resource for each gCube resource that has to be considered part of the e-Infrastructure the IS-Registry is responsible for. Such WS-Resources (ProfileResource) implement the Resource Model described in the Resource Model, in fact each of them consists of four parts:

  • A unique identifier identifying the resource univocally;
  • A type characterising the class the resource belong to, e.g. Running Instance, gHN;
  • A scope identifying the operational scope of such a resource;
  • A profile describing the resource by resource-specific attributes.

In addition to such WS-Resources the service publishes a set of properties about its operational status including the number of resources of a certain type currently registered, the last operation performed including operation type, resource ID and time (RegistryFactoryResource). Such properties are also registered as Topics managed by the IS-Notifier thus making possible for interested clients to subscribe on events representing the changes of status of Infrastructure constituents (e.g. the disappearance of a Running Instance).

Functions

The main functions supported by the Service Factory (RegistryFactory) are:

  • createResource() – which takes as input parameter a message containing a resource profile and a set of registration directives (e.g. VO membership and VRE membership) and returns a string containing the whole profile of the new resource including the automatically assigned ID;
  • updateResource() – which takes as input parameter a message containing the new profile that is supposed to replace an existing one. The key to identify the old profile to be replaced is contained in the profile itself, it is the resource ID. By relying on the internal mapping between IDs and EPRs it identifies the WS-Resource it has to interact with in order to implement such update operation;
  • removeResource() – which takes as input parameter a message mainly containing the resource ID identifying the resource to be removed;
  • updateProfileWithVRE() – which takes as input parameter a message containing the resource ID and the new VRE scopes designed to enrich the resource scope section and returns the new resource profile;
  • removeProfileWithVRE() – which takes as input parameter a message containing the resource ID and the set of VRE scopes to be removed from the resource profile and returns the new resource profile;
  • updateState() – which takes as input parameter a message containing the resource ID and the new state the resource has to be considered in and returns the new resource profile;

The main functions supported by the IS-Registry Service (RegistryService), i.e. the WSRF service managing the WS-Resource instances representing gCube resources, are:

  • update() – which takes as input parameter a message containing the new resource profile and updates its current one;
  • remove() – which deletes the resource by destroying the WS-Resource and its serialisation;
  • getProfileString() – which returns the resource profile represented by its WS-Resource;
  • updateStatus() – which takes as input parameter a message containing the new status the resource must appear to be and accordingly updates the WS-Resource;
  • updateVRE() – which takes as input parameter a message containing the new VRE scopes the managed resource has to be considered in and enriches the WS-Resource accordingly;
  • removeVRE() – which takes as input parameter a message containing the VRE scopes the managed resource has to be removed from and revises the WS-Resource accordingly.

Configuration

An instance of the IS-Registry has to be configured as follows

  1. Since a IS-Registry can act in one and only one scope, its JNDI file ($GLOBUS_LOCATION/etc/org.gcube.informationsystem.registry/jndi-config.xml) must be configure to join only one scope:

Example:

<?xml version="1.0" encoding="UTF-8"?>
<jndiConfig xmlns="http://wsrf.globus.org/jndi/config">

<service name="gcube/informationsystem/registry">
        
                <environment 
                        name="configDir" 
                        value="etc/org.gcube.informationsystem.registry" 
                        type="java.lang.String"
                        override="false" />
                
                <environment 
                        name="securityManagerClass" 
                        value="org.gcube.common.core.security.GCUBESimpleServiceSecurityManager" 
                        type="java.lang.String"
                        override="false" />
                
                <!-- Lifetime for temporary resources, after this period temporary resources are destroyed-->
                <environment
                        name="temporaryResourceLifetimeInMs"
                        value="480000"
                        type="java.lang.Long"
                        override="false" />     
                                
                                        
                         
                <environment 
                        name="startScopes" 
                        value=" /testing/vo1" 
                        type="java.lang.String"
                       override="false" />         
                        
</service>