Difference between revisions of "IS-Registry"

From Gcube Wiki
Jump to: navigation, search
(Design)
Line 1: Line 1:
 
  
 
== Role ==
 
== Role ==
Line 29: Line 28:
 
=== Factory ===
 
=== Factory ===
  
The Factory port-type is practically a wrapper around the <code>ResourceRegistration</code> port-type to provide backwards compatibility to previous IS-Publisher and testers implementation.  
+
The Factory port-type is practically a wrapper around the <code>ResourceRegistration</code> port-type to provide backwards compatibility to previous IS-Publisher and testers implementation. Therefore, it exposes the following operations:
However, it is also in charge of creation the singleton FactoryResource. This resource is used to expose Topics ....
+
 
+
== Interface ==
+
 
+
[TBP]
+
 
+
* 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).
+
  
=== Operations ===
+
* <code>createResource</code> – 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;
[TBU]
+
* <code>updateResource</code> – 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;
The main operations supported by the Service Factory (RegistryFactory) are:
+
* <code>removeResource</code> – which takes as input parameters a message containing the resource ID identifying the resource to be removed and its type;
  
* '''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;
+
The <code>Factory</code> is also in charge of creating the singleton FactoryResource. This resource exposes a set of WS-ResourceProperties registered as Topics in the [[IS-Notifier]], 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).  
* '''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 containing the resource ID identifying the resource to be removed;
+
  
 
== Sample Usage ==  
 
== Sample Usage ==  

Revision as of 16:41, 8 April 2011

Role

The IS-Registry is the gateway to entering in a gCube infrastructure for gCube resources by means of registering/unregistering their profiles.

The IS-Registry performs three fundamental tasks:

  • decide if accept or not a new resource
  • validate a resource before its registration
  • execute post-deletion actions to keep consistent the IS content


Design

The design of the service is distributed across two port-types: the ResourceRegistration and the Factory.

Figure 1. IS-Registry Architecture

ResourceRegistration

The ResourceRegistration port-type manages the registration/update/removal of GCUBE Resources. It is directly contacted only by the IS-Publisher in order to perform such operations.

It exposes three operations:

  • ...
  • ...
  • ...

Factory

The Factory port-type is practically a wrapper around the ResourceRegistration port-type to provide backwards compatibility to previous IS-Publisher and testers implementation. Therefore, it exposes the following operations:

  • 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 parameters a message containing the resource ID identifying the resource to be removed and its type;

The Factory is also in charge of creating the singleton FactoryResource. This resource exposes a set of WS-ResourceProperties registered as Topics in the IS-Notifier, 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).

Sample Usage

[TBP]