Applicationcode

Registry 1

Alignment of R-GMA with developments in the Open Grid Services Architecture (OGSA) is advancing. The existing Servlets and Consumer/Producer instances are being replaced by Web Services and resources respectively. These resources provide lifecycle management (creation using a factory, immediate and delayed destruction) and are modelled on the Web Service Resource Framework. Producers and Consumers become types of resource that support additional functionality to publish and consume data.

ProducerFactoryService

Sensor

Producer API

Application Code

Consumer API

R-GMA is a relational implementation of the Grid Monitoring Architecture (GMA).

Producers: A Producer can publish data to a number of tables. Each table must be declared, at which point the Producer is stored in the Registry as a publisher for that table. A Producer can optionally specify a predicate for a table, in the form of an SQL WHERE clause, which indicates what subset of the table the Producer is responsible for. To publish data, the user issues a standard SQL INSERT statement to the Producer. The detailed descriptions of the tables (column names, types and key information) are held in the Schema.

Example consumer query: SELECT * FROM CPULoad WHERE Facility = ‘CDF’ AND Site = ‘RAL’

An information and monitoring system for static and dynamic information about grid resources, applications, networks …

2005-02-11 19:05:560.5ALICEGLAUK

2005-02-11 19:05:580.4CDFGLAUK

2005-02-11 19:05:570.3CDFRALUK

2005-02-11 19:05:561.6ATLASRALUK

TimestampLoadFacilitySite Country

2005-02-11 19:05:560.9ALICEUCLUK

2005-02-11 19:05:550.6CDFUCLUK

Example producer table ‘CPULoad'

Sensor

Command

Data

RegistryServlet

Consumer Servlet

StreamProducer Servlet

When a user creates a Consumer or Producer, a corresponding instance is created remotely on the server. This handles all the communication with other R-GMA components (Producers, Registry etc.) so the client code can be simple and lightweight. The client API uses HTTP GET/POST to send requests to the servlets; the response is in the form of an XML string, which contains returned data (e.g. a set of tuples) or an error. Typically one server providing Consumer/Producer functionality is deployed per site, but several sites share the same Registry and Schema servers.

PrimaryProducerAPI

Schema API

Registry API

Servlet aware of API during terminationInterval duration Existence of service instances in Registry up to terminationTime

Producer A

Info mastered by Registry 1

Copy of info from Registry 2

Registry 2

Info mastered by Registry 2

Copy of info from Registry 1

Producer B

A peer-to-peer policy for registry replication is used within R-GMA. Each registry is responsible for replicating its local data with other registries. Registry 1 ensures Registry 2 has a copy of all information it masters (and vice versa). A checksum is sent between registries to validate replicated data. A failed checksum forces all replication data to be re-sent. Each registry maintains a list of the locations of other registries. Data that has been replicated is flagged to prevent duplication or re-replication. Deleted data is not sent for replication; lifetime management takes care of this. Any columns relating to time stamps are not replicated.

http://www.r-gma.org/

In the Grid Monitoring Architecture (GMA) from the Global Grid Forum (GGF), Producers register themselves with a Registry and describe the type and structure of information they want to make available to the Grid. Consumers can query the Registry to find out what type of information is available and locate relevant Producers. The Consumer can then contact the Producers directly to obtain the data. By specifying the Consumer-Producer protocol and the interfaces to the Registry one can build inter-operable services.

Producer

Consumer

register

lookup

transferdata Registry

An instance is normally destroyed at the explicit request of the user, but in order to protect itself from an accumulation of redundant instances, R-GMA requires the user to specify a termination interval when it creates the instance. If the servlet doesn't hear from the user for any period exceeding the termination interval, the instance is destroyed. This is the concept of soft-state registration. It puts the onus on the user to keep the resource alive, by making periodic contact with the service. The Registry protects itself in the same way against Producers and Consumers which register then disappear, so a periodic keep-registered message has also to be sent to the Registry, by the Consumer and Producer servlets.

Example producer table declaration: Name: CPULoad Predicate: WHERE Country = ‘UK’

Consumers: A Consumer handles a single query, expressed as an SQL SELECT statement. The details of the query are stored in the Registry so the Consumer can be notified when a relevant new Producer is created.

More than one registry can be deployed to provide fault tolerance and increased performance, but this requires a mechanism to keep the Registries synchronized (as Producers and Consumers only register with one Registry). This mechanism is known as registry replication.

The first stage of this transition is complete with the development of a first version of Web Services. This involved separating the basic R-GMA functionality from the servlet and lifecycle management infrastructures. A modular system is being created that can accommodate new standards as they are developed or different protocols as they are required by plugging in appropriate new modules.

ConsumerFactoryService

RegistryRegistryService

SchemaSchemaService

ConsumerResourceConsumerResourceConsumerResource

ConsumerResourceConsumerResourceProducerResource

Registry servletProducer servlet

RegistryAPI

Producerinstance

Producer registration

Sensor

Producer API

ConsumerAPI

RDBMS

RDBMSDBProducerServlet

Registry API

Registry API

Sensor

PrimaryProducerAPI

SchemaServlet

RDBMS

RDBMS

Server in example deployment