Difference between revisions of "GCore Based Information System"

Revision as of 21:48, 25 June 2011

Information System

The gCube Information System (shortly, IS) delivers a crucial service in a gCube Infrastructure: it delivers functionalities for publishing, discovering and monitoring the set of resources forming the infrastructure. It acts as the registry of the infrastructure, i.e. all the resources are registered in the IS and every service partaking in the infrastructure must refer to it to dynamically discover the other infrastructure constituents. Moreover, the approach provided by the IS is of great support for the dynamic deployment capabilities of gCube.

In this context, a resource can be:

• a gCube resource, supporting the deployment and operation of a gCube infrastructure;
• an instance state, characterizing the operational state of an instance of a gCube service
• a generic resource, any XML well-formed document (a text that follows all the syntactic rules labelled as well-formedness rules in the XML specification)

Because of its central role, key requirements in terms of quality of service for such a subsystem are performance, scalability, freshness and availability. Moreover, facilities supporting the interaction with such subsystem have been included in the gCore Framework.

Reference Architecture

Architecturally, the IS is composed by a group of services and libraries enhancing the experience of potential clients. The central role is played by the InformationCollector (IC) service, in charge of collecting information about the infrastructure (or a subset) and responding to those that call for discovering. There are two ways to feed the IC, depending on the nature of the information published. If the information is a gCube Resource profile, a request for publication must be sent to the Registry service. This service is devoted to validate and filter profiles in order to decide whether a resource is accepted or not as part of the infrastructure (other gCube services are in charge of regulating the access to the accepted resources). On the other hand, if the information to publish is an instance state or a generic resource, it does not need to pass through the Registry service's acceptance procedure and can be directly sent to the IC.

The third service belonging the IS is the Notifier, offering a mechanism for subscription/notification on events related to gCube Resource's lifetime. By relying on the WS-Notification and in cooperation with the Registry service, this service sends notifications to subscribed consumers about events happening in the Registry service (such as the registration of a new resource).

All of the three services have a related client library abstracting over the details of the services' interface:

• IS-Client: for interacting with the IC service for discovering
• IS-Publisher: for interacting with the IC and Registry services for publication
• IS-Notification: for becoming a consumer of gCube's notification events sent by the Notifier

Finally, the last service is the gLiteBridge. Its role is to foster the interoperability with gLite-based infrastructures by publishing in the IS computing elements, storage elements and sites harvested from their information systems (mainly BDII).

Figure 1 presents the components of the Information System and their main interactions:

Figure 1. Information System Architecture and Main Interactions

They globally deliver the following functionalities with respect to the information handled:

• production and publication
• collection and storage
• discovery and consumption

The components belonging the production and publication phase are:

• IS-Registry – this Service supports the publishing/un-publishing of profiles describing gCube resources;
• IS-gLiteBridge – this Service supports the publishing/un-publishing of resources gathered from a gLite based infrastructure that gCube services may access to;
• IS-Publisher – this Library supports services in publishing/un-publishing information in the Information Collector service. It's the gateway for any information going to the IS;
• IS-Notification – this Library provides a publication/subscription/notification mechanism for Topics produced and consumed by services.

The component supporting the collection and storage phase is:

• IS-InformationCollector – this Service collects and makes available information related to the actual state of a gCube infrastructure and/or of an assigned subset of it;

The components supporting the discovery and consumption phase are:

• IS-Client – this Library supports services in discovering information published in the IS;
• IS-Notifier – this Service supports other services in subscribing/unsubscribing to topics produced by the various Services; this service decouples the actual producer of the topic from the actual consumer allowing for producers re-location;
• IS-Sweeper (coming soon) – this Executor plugin keep updated the GHN and RI profiles when the related GHN dies or have communication problems;

Design Notes

The IS has been conceived to rely on standards, most noticeably:

• WS-Notifications
• WS-ServiceGroup 1.2
• WS-ResourceProperty 1.2
• Web Services Data Access and Integration – The XML Realization (WS-DAIX) Specification, Version 1.0
• XQuery 1.0

Early versions mostly exploited WS-ServiceGroup and WS-ResourceProperty specifications. Starting from version 2.0 (released in Feb 2011), the IS is designed around the WS-DAIX specification for publishing. WS-Notifications is at the heart of the functionalities delivered by the IS-Notifier service. Finally, the queries accepted by the IS has to be compliant with the XQuery language.

Worthy to mention, during the design of the IS, the following principle has been widely adopted: program to an interface, not an implementation. This means that we tried to maintain the IS consumers and producers as much as possible decoupled from its implementation. More concretely, a gCube service has to know only the IS-Client, IS-Notifier and IS-Publisher interfaces and that's all. It does not need to care about their implementation (mechanisms to dynamically load the IS-Client, IS-Notifier and IS-Publisher at runtime have been put in place) nor the actual IS deployment scenario (completely abstracted by the IS client libraries).