Difference between revisions of "GCore Based Information System"

From Gcube Wiki
Jump to: navigation, search
Line 26: Line 26:
 
* '''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 (''[[ExistClient|ExistLibrary]]'') is part of the gCore Application Framework;
 
* '''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 (''[[ExistClient|ExistLibrary]]'') is part of the gCore Application 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-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 we prefer to have it in the components supporting consumption/query phase because we feel its main role close to such an area.  
+
* '''[[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 we prefer to have it in the components supporting consumption/query phase because we feel its main role close to such an area.  
  
 
The subsystem has been conceived to rely on standards, in particular the WS-ServiceGroup[http://docs.oasis-open.org/wsrf/2004/06/wsrf-WS-ServiceGroup-1.2-draft-02.pdf]  and WS-ResourceProperty  specifications. From a technical point of view it exploits the ''Aggregator Framework'' software framework[http://www.globus.org/toolkit/docs/4.0/info/aggregator/] produced by the Globus Project[http://www.globus.org/]. 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 DIS to be as generic as possible and to be plugged with new aggregator sources at any time.
 
The subsystem has been conceived to rely on standards, in particular the WS-ServiceGroup[http://docs.oasis-open.org/wsrf/2004/06/wsrf-WS-ServiceGroup-1.2-draft-02.pdf]  and WS-ResourceProperty  specifications. From a technical point of view it exploits the ''Aggregator Framework'' software framework[http://www.globus.org/toolkit/docs/4.0/info/aggregator/] produced by the Globus Project[http://www.globus.org/]. 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 DIS to be as generic as possible and to be plugged with new aggregator sources at any time.
  
 
[[Category:Information System]]
 
[[Category:Information System]]

Revision as of 18:07, 24 July 2008

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 Application 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 Application Framework;

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 Application 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 we prefer to have it in the components supporting consumption/query phase because we feel its main role close to such an 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 DIS to be as generic as possible and to be plugged with new aggregator sources at any time.