Difference between revisions of "GCore Based Information System"

Revision as of 22:18, 7 January 2009

Information System

The Information System (IS) plays a central role in a gCube-based Infrastructure by implementing the features supporting the publishing, discovery and ‘real-time’ monitoring of the set of resources forming a gCube-based infrastructure. It acts as the registry of the infrastructure, i.e. all the resources are registered there and every service partaking to the infrastructure must refer to it to dynamically discover the rest of Infrastructure constituents. For each resource, two kinds of information will be published:

• the profile, statically characterising the resource, e.g. its type;
• the status, characterising the operational status of the resource, e.g. indicators of the size of the resource currently managed .

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

The functions requested to an information system fall in one of the following three phases: production/publishing, collection/storage, consumption/query. Similarly, the components forming this subsystem (presented in Figure 1) contribute to implement it with respect to one of these three functions.

Figure 1. Information System Reference Architecture

The components supporting the production/publishing phase are:

• IS-Registry – this Service supports the publishing/un-publishing of gCube resources; a gCube resource is advertised through its profile, i.e. the resource profile represents the existence of a resource;
• IS-gLiteBridge – this Service supports the publishing/un-publishing of resources gathered from a gLite based infrastructure; a gCube-based infrastructure include resources forming a gLite-based infrastructure;
• IS-Publisher – this Library supports services in publishing/un-publishing groups of resource properties as well as registering/un-registering groups of topics. Actually, this library is an interface other Services will rely on. Because of this fundamental role in supporting Services operation in a gCube-based infrastructure, a reference implementation of such an interface (gCubePublisher) is part of the gCore Framework;
• IS-Notification – this Library provides a Publish/Subcribe notification mechanism for Topics produced and consumed by services.

The components supporting the collection/storage phase are:

• IS-IC – this Service aggregates the information published in the IS; form a logical point of view it is a global registry but, because of the expected quality of service, it has been designed to support a federation model, i.e. chains of IS-IC can be configured to collectively implement the global registry function;

The components supporting the consumption/query phase are:

• IS-Client – this Library supports Services in retrieving information published in the IS; it supports the discovery of both profiles and properties. Actually, this library is an interface Services will rely on. Because of this fundamental role in supporting Services operation in a gCube-based infrastructure, a reference implementation of such an interface (ExistLibrary) is part of the gCore Framework;
• 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-Manager – this Service supports other Services and clients in observing, checking, or keeping a continuous record of the status of the resources forming the infrastructure. Because of this role, it can also be classified as a component supporting the collection/storage phase but it is preferable to have it in the components supporting consumption/query phase because it is considered closer to this area.

The subsystem has been conceived to rely on standards, in particular the WS-ServiceGroup[1] and WS-ResourceProperty specifications. From a technical point of view it exploits the Aggregator Framework software framework[2] produced by the Globus Project[3]. The Aggregator Framework is a software framework that collects data from aggregator sources and sends data to aggregator sinks. It also allows implementing pluggable and customized sources and sinks and connecting them together following the WS-ServiceGroup specification. These capabilities have been exploited in the IS by implementing some gCube services as aggregator sinks (e.g. the IS-IC) and allowing any gCube service to become an aggregator source (through the gCubePublisher); The IS-Registry is another example of aggregator source. The data exchanged within the IS connections are always WS-ResourceProperty documents. This allows the IS to be as generic as possible and to be plugged with new aggregator sources at any time.

Another principle has been followed during the design of the IS: program to an interface, not an implementation by meaning that we tried to maintain the IS consumers and producers as much as possible decoupled from its implementation. Concretely, this reflects on mechanisms to dynamically load the IS-Client, IS-Notifier and IS-Publisher at runtime and exposing only their abstract interface. Then, once their clients depend on interfaces only, they are decoupled from the implementation.