Difference between revisions of "IS-Manager"

Revision as of 10:53, 28 July 2008

THIS SECTION OF GCUBE DOCUMENTATION IS CURRENTLY UNDER UPDATE.

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.

Agent Architecture

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 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