1 / 30

gCube Information System motivations, architecture, and interfaces

D4Science-EGEE Meeting 1 December 2008 CERN. gCube Information System motivations, architecture, and interfaces. Pasquale Pagano CNR-ISTI pasquale.pagano@isti.cnr.it. www.d4science.org. Session objectives. To present the resources managed by the gCube IS the way it works

kumiko
Download Presentation

gCube Information System motivations, architecture, and interfaces

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. D4Science-EGEE Meeting1 December 2008 CERN gCube Information System motivations, architecture, and interfaces Pasquale Pagano CNR-ISTI pasquale.pagano@isti.cnr.it www.d4science.org

  2. Session objectives • To present • the resources managed by the gCube IS • the way it works • the monitoring interfaces • the Infrastructure Viewer (TreeMap technology)

  3. gCube IS • The Information System (IS) supports the publishing, discovery and monitoring of the set of resources forming a gCube-based infrastructure. • It acts as the registry of the infrastructure.

  4. gCube Resources: definition • gCube resources are: • gCube Hosting Node (gHN) • gHN is a computer machine connected to the network, available in the infrastructure and running the gCore service container. • Service • Service is a software system tarball. It is composed by a set of related Packages (installable units of software). • RunningInstance (RI) • RunningInstance is a deployed and activated service that delivers functionalities. • gLite resource • gLiteResource represents the resources provided by the underlying grid infrastructure that can be monitored and used by the gCube services: Site, CE, SE

  5. gCube Resources: definition [cont.] • gCube resources are: • Collection • Collections are the basic data structure used to organize information objects by exploiting shared commonalities. • Metadata Collection • Metadata Collections are collections that contains metadata objects sharing the same schema and language. • Index • A systematically arranged data structure containing enough information for each item to be found.

  6. Resources: registration • Resources are dynamically added through the registration process • Who registers what • gHN ←gHN Manager + Resource Manager (human) • Service ← Resource Manager (human) • RunningInstance ← self-registered through gCore • gLiteResource ← gLiteBridge service • Collection, Metadata Collection, and Indexes ← gCube services

  7. Resources : profile ans status • For each resource, two kinds of information are published: • the profile, characterizing the resource; • the status, characterizing the operational status of the resource, e.g. indicators of the size of the resource currently managed. • The resource profile is initially supplied at registration time and then updated if needed. • The resource status is exposed as WS-ResourceProperties document by the producers • Any information published in the IS can be queried through xPath and xQuery expressions • Information are collected by the IS exploiting the Aggregator Framework and the WS-ServiceGroup specification

  8. gCube IS publishing: technologies overview • The Aggregator Framework is a software framework that: • (i) collect information from grid resources using pluggable aggregation sources (Aggregator Sources), • (ii) deliver collected information to pluggable sinks (Aggregator Sinks), • (iii) manage creation and destruction of individual aggregation registrations. • The gCube IS architecture has been designed to take advantage of this framework

  9. Profiles publication schema

  10. Publish/retrieve schema

  11. gCube IS Architecture

  12. Resources and Scope • gCube resources are shared within one or more scopes • outside of which, they can neither be discovered nor used • RIs operate in different scopes at different time • clients must specify a scope when contacting RIs • any state which the RI may create must retain the scope of the call which triggered its creation. • Resources, ws-resources, and calls are all explicitly and transparently scoped • as in no other infrastructure we are aware of! • a major element of innovation associated with gCube

  13. Modeling scope • 3 levels of scope • infrastructure (global scope) • virtual organization (community scope) • virtual research environment (application scope) • hierarchically related • VOs exist only above VREs and only below Infrastructures • resources above may be shared below (implicitly or explicitly) • as assets to share or managers for sharing

  14. Ground law • R1: a resource in the scope of a VO is also in the scope of the VREs below • a resource in /a/b is also in /a/b/c but not necessarily in /a or /a/d • intuition: community resources are immediately available to all community applications. • typically, VO-level resources are for VRE management • e.g. gHNs, Core Services RIs • note: • Converse is not true: • resources may be dedicated to applications and not be shared across communities • It does not extend to infrastructure: • global resources are not community resources until explicitly joined to them • typically, are for VO management • extra resource-specific rules widen, narrow, complement ground law

  15. gCube IS Monitoring http://dlib18.isti.cnr.it/monitoring/

  16. gCube IS –Infrastructure Viewer http://dlib18.isti.cnr.it/iv Address bar Control Panel Tree Map Widget Legend Comment Area

  17. IV Views • GHN View represents Sites and gHNs characterized by the Ris the gHNs are running • Services View represents Class of Services, Services, and Running Instances • Data View represents Collections, Metadata Collections, and Indexes

  18. IV, scopes, and metrics • IV Views are available for different scopes. The scope is identified by selecting the Infrastructure and the VO. • Specific metrics are available per View. Data View GHN View Services View

  19. gCube IV base technology: GWT • gCube IV exploits Google Web Toolkit (GWT). • The AJAX front-end is completely written in Java which GWT then cross-compiles into optimized JavaScript that automatically works across all major browsers. • It exploits GWT RPC. • gCube IV client defines an interface that specifies the remote methods it needs to call. When a user issues a remote call from the browser, GWT RPC automatically • serializes the arguments, • invokes the proper method on the server, • then deserializes the return value for the client code.

  20. gCube IV base technology: GWT [cont.] • All gCube IV rendering logic is moved to the client. • The server-side code that gets invoked from the client is designed to fetch the data from remote services. The gCube IV client initiates an asynchronous call to request the data immediately before it begins constructing the widgets. While the server-side code is fetching the required data, the browser is rendering the user interface code. When the client finally receives the data from the server, the UI has been constructed and laid out, and the data is ready to be displayed.

  21. gCube IV Implementationhttp://dlib18.isti.cnr.it/iv/doc TreeMap widget and controllers Data View specific GHN View specific Services View specific Server side

  22. gCube IV Client Implementation • A Region defines position and dimension of the area. • The set of Regions (areas) contained in another area is implemented as a RegionsContainer. • To each RegionsContainer is associated a Level that characterises the macro area in terms of content (title, border, tooltip) and style. • A view specific implementation of the StyleFunction, TitleFunction, ToolTipFunctioninterfaces is included in the functions package of each View. TreeMap Region org.gcube.portlets.admin.infrastructureviewer.client.treemap.widget.data RegionsContainer

  23. gCube IV Client Implementation [cont.] GHN View • The overall area is a Region • The overall area contains Region<Site> grouped in a RegionsContainer<Site> • Each Region<Site> represents a Site resource • Each Region<Site> contains Region<GHN> grouped in the RegionsContainer<GHN> • Each Region<GHN> represents a GHN resource Region RegionsContainer

  24. gCube IV Client Implementation [cont.] • The implementation of the TreeMap area is done by the TreemapWidget class that defines the Region and RegionsContainer for the overall TreeMap area. The TreemapControl class provides the TreemapWidget the data to be visualized. The TreemapWidget offers a listener to catch users click on the area. It is used to report detailed information about the region. org.gcube.portlets.admin.infrastructureviewer.client.treemap.widget

  25. gCube IV Client Implementation [cont.] • The DataLoader interface provides the information needed to visualize the TreeMap independently by the selected View. • It defines a loadData method that specifies the dimension of the area and the AsyncCallback<ViewData<?>>. • The ViewData<?> contains the data utilized by the TreemapWidget and by the addressbar. • The DataLoader interface is implemented through the DataViewDataLoader, GHNViewDataLoader, and ServicesViewDataLoader classes (control package).

  26. gCube IV Server Implementation • The gCube resources are fetched by issuing xQueries (ASL package) to the IS, enriched by resolving references, transformed in objects, and cached. MapGenerator MapGenerator DataSourceCache MapGenerator IS TreemapGenerator DataSource RegionsContainer to be passed to the AsyncCallback gCube Resources View specific objects

  27. gCube IV Server Implementation [cont.] • Each MapGenerator (View package) builds on a tree representing the resources of the view: • Sites->GHNs • Service Classes -> Service -> RI • Collections -> Metadata Collections-> Indices • It divides the area of the treemap in squares, one for each level of the tree it is examining, recursively. • This operation is performed by exploiting the TreeMapGenerator that is trained specifying the selected algorithm and the list of (resource, weight) to be displayed. • The weight is determined as function of the selected view metric.

  28. gCube IV Server Implementation [cont.] • For each View it is defined a datasource interface (datasource package) that models the specific data of the view: • GHNViewISDataSource, • ServicesViewISDataSource, • DataViewISDataSource • The data are represented by CacheData<T> (commons package) that contains additional information as well (e.g. exceptions). • For each interface there are two implementations: • GHNViewISDataSourceCached, • GHNViewISDataSourceNoCache, • ServicesViewISDataSourceCached, • ServicesViewISDataSourceNoCache, • DataViewISDataSourceCached, • DataViewISDataSourceNoCache

  29. gCube IV Server Implementation [cont.] • Caching mechanism • DataSource (common package): a generic data provider of type <T> with a unique method getData: GHNViewISDataSourceNoCache, ServicesViewISDataSourceNoCache, DataViewISDataSourceNoCache are implementation of DataSource • DataRepository (common package), repository of data of type <T> with a unique method setData • CacheUpdater (common package), a runnable class that periodically updates the DataRepository by refreshing the DataSources for each scope • CachedDataSource (common package), a generic cached data provider of type <T> with a unique method getData: GHNViewISDataSourceCached, ServicesViewISDataSourceCached, DataViewISDataSourceCached are implementation of CachedDataSource

  30. Questions? • For further information: • federico.defaveri@isti.cnr.it

More Related