IS-Manager

From Gcube Wiki
Revision as of 16:34, 24 July 2008 by Federico.defaveri (Talk | contribs) (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...)

(diff) ← Older revision | Latest revision (diff) | Newer revision → (diff)
Jump to: navigation, search

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




DBManager

Manager

Lookup