Difference between revisions of "IS-Manager"

From Gcube Wiki
Jump to: navigation, search
(New page: Image:Alert_icon2.gif ''THIS SECTION OF GCUBE DOCUMENTATION IS CURRENTLY UNDER UPDATE.'' ==IS-MANAGER Architecture== The IS-Manager is designed as two software components to render it...)
 
 
(8 intermediate revisions by 2 users not shown)
Line 1: Line 1:
[[Image:Alert_icon2.gif]] ''THIS SECTION OF GCUBE DOCUMENTATION IS CURRENTLY UNDER UPDATE.''
 
 
 
==IS-MANAGER Architecture==
 
==IS-MANAGER Architecture==
 
The IS-Manager is designed as two software components to render it more scalable.  
 
The IS-Manager is designed as two software components to render it more scalable.  
agents, which operate at the sub-VO level by retrieving data, buffering it, and sending it to the master
+
*agents, which operate at the VO level by retrieving data, buffering it, and sending it to the master
master, which collects and stores data from the agents. The master is the interface towards the infrastructure for the IS-Manager.
+
*master, which collects and stores data from the agents by operating at Infrastructure level. The master is the interface towards the infrastructure for the IS-Manager.
  
===The agent===
+
===The Agent===
An agent is a service deployed in each sub-VO from which, through the IS-Registry, it retrieves all profiles and their updates. This data, after being processed, is buffered and transmitted to the Retriever component that is a module of the Master service. For the kind of interaction the agent has with the IS-Registry, it is compulsory to co-deploy the agent service with the IS-Registry service.
+
An Agent is a service deployed in each VO from which, through the IS-Registry, it retrieves all profiles and their updates. This data, after being processed, is buffered and transmitted to the Retriever component that is a module of the Master service. For the kind of interaction the Agent has with the IS-Registry, it is compulsory to co-deploy the Agent service with the IS-Registry service.
Agent Architecture
+
 
Retrieving data from IS-Registry is not performed by a subscription to the IS-Notifier. Rather, it exploits the gCore Event Framework that allows to make the system more scalable. The agent is notified directly by the IS-Registry and for each notification the type of operation (CREATE, UPDATE, REMOVE) and the updated or new profile represented by a GCUBEREsource object are transmitted to the Retriever.
+
====Agent Architecture====
 +
Retrieving data from IS-Registry is not performed by a subscription to the IS-Notifier. Rather, it exploits the gCore Event Framework that allows to make the system more scalable. The Agent is notified directly by the IS-Registry and for each notification the type of operation (CREATE, UPDATE, REMOVE) and the updated or new profile represented by a GCUBEREsource object are transmitted to the Retriever.
 
The profile processing performed by the Agent is computed according to the following rules:
 
The profile processing performed by the Agent is computed according to the following rules:
If the profile is new, it is serialized into XML with internal procedures;
+
*If the profile is new, it is serialized into XML with internal procedures;
If the profile is an update, the difference between the new profile and the old one that has been cached by the agent is calculated. The difference is represented using XML.
+
*If the profile is an update, the difference between the new profile and the old one that has been cached by the agent is calculated. The difference is represented using XML.
If the profile has been removed, only the ID is transmitted.
+
*If the profile has been removed, only the ID is transmitted.
 
The XML produced by this processing is buffered and, at regular times or when a certain number of processed profiles has been reached, all processed profiles are transmitted to the Retriever.
 
The XML produced by this processing is buffered and, at regular times or when a certain number of processed profiles has been reached, all processed profiles are transmitted to the Retriever.
 +
[[Image:agent_architecture.png|frame|center|Agent Architecture]]
  
The master
+
 
The Master is a service deployed at the root VO level of the infrastructure.
+
===The Master===
 +
The Master is a service deployed at the Infrastructure level.
 
The Master is organized into the following modules:
 
The Master is organized into the following modules:
the Retriever, that collects all the information received from each Agent;
+
*the Retriever, that collects all the information received from each Agent;
the relational database, where all the information is stored;
+
*the relational database, where all the information are stored;
the DBManager, that manages the interaction with the database;
+
*the DBManager, that manages the interaction with the database;
the Manager, that reacts to profile modifications, e.g. the alteration of a service state;
+
*the Manager, that reacts to profile modifications, e.g. the alteration of a service state;
the Lookup, that provides an interface to consume the data stored in the IS-Manager.  
+
*the Lookup, that provides an interface to consume the data stored in the IS-Manager.
 +
[[Image:master_architecture.png|frame|center|Master Architecture]]
  
Data storing
+
====Data storing====
 
All the procedures for data storing are hidden by a DAO (Data Access Object) pattern.
 
All the procedures for data storing are hidden by a DAO (Data Access Object) pattern.
 
All data is stored into a relational database.
 
All data is stored into a relational database.
Retriever
 
 
 
 
 
 
  
 +
====Retriever====
 +
[[Image:retriever_architecture.png|frame|center|Retriever Architecture]]
  
DBManager
+
====DBManager====
 +
====Manager====
 +
====Lookup====
  
Manager
 
  
Lookup
+
[[Category:Information System]]

Latest revision as of 12:46, 9 December 2010

IS-MANAGER Architecture

The IS-Manager is designed as two software components to render it more scalable.

  • agents, which operate at the VO level by retrieving data, buffering it, and sending it to the master
  • master, which collects and stores data from the agents by operating at Infrastructure level. The master is the interface towards the infrastructure for the IS-Manager.

The Agent

An Agent is a service deployed in each VO from which, through the IS-Registry, it retrieves all profiles and their updates. This data, after being processed, is buffered and transmitted to the Retriever component that is a module of the Master service. For the kind of interaction the Agent has with the IS-Registry, it is compulsory to co-deploy the Agent service with the IS-Registry service.

Agent Architecture

Retrieving data from IS-Registry is not performed by a subscription to the IS-Notifier. Rather, it exploits the gCore Event Framework that allows to make the system more scalable. The Agent is notified directly by the IS-Registry and for each notification the type of operation (CREATE, UPDATE, REMOVE) and the updated or new profile represented by a GCUBEREsource object are transmitted to the Retriever. The profile processing performed by the Agent is computed according to the following rules:

  • If the profile is new, it is serialized into XML with internal procedures;
  • If the profile is an update, the difference between the new profile and the old one that has been cached by the agent is calculated. The difference is represented using XML.
  • If the profile has been removed, only the ID is transmitted.

The XML produced by this processing is buffered and, at regular times or when a certain number of processed profiles has been reached, all processed profiles are transmitted to the Retriever.

Agent Architecture


The Master

The Master is a service deployed at the Infrastructure level. The Master is organized into the following modules:

  • the Retriever, that collects all the information received from each Agent;
  • the relational database, where all the information are stored;
  • the DBManager, that manages the interaction with the database;
  • the Manager, that reacts to profile modifications, e.g. the alteration of a service state;
  • the Lookup, that provides an interface to consume the data stored in the IS-Manager.
Master Architecture

Data storing

All the procedures for data storing are hidden by a DAO (Data Access Object) pattern. All data is stored into a relational database.

Retriever

Retriever Architecture

DBManager

Manager

Lookup