Difference between revisions of "IS-Manager"
From Gcube Wiki
(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...) |
|||
| Line 3: | Line 3: | ||
==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 sub-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. The master is the interface towards the infrastructure for the IS-Manager. |
| − | ===The | + | ===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 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. | ||
| − | Agent Architecture | + | |
| + | ====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. | 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. | ||
| − | The | + | ===The Master=== |
The Master is a service deployed at the root VO level of the infrastructure. | The Master is a service deployed at the root VO level of the infrastructure. | ||
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 is 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. |
| − | 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. | ||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | Lookup | + | ====Retriever==== |
| + | ====DBManager==== | ||
| + | ====Manager==== | ||
| + | ====Lookup==== | ||
Revision as of 15:38, 24 July 2008
THIS SECTION OF GCUBE DOCUMENTATION IS CURRENTLY UNDER UPDATE.
Contents
IS-MANAGER Architecture
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
- master, which collects and stores data from the agents. The master is the interface towards the infrastructure for the IS-Manager.
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.
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.
The Master
The Master is a service deployed at the root VO level of the infrastructure. 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 is 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.
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.
