Download ConsortiumPresentation_wTemplate

AstroGrid
AstroGrid increases scientific research possibilities.
The registry is a hidden service from the users; it is used by all
other components for resource discovery.
Registry conforms to a set of IVOA schemas containing
information on various areas, such as Service, Table data,
Application data, Data Collections.
The registry is an essential component in Astrogrid. Helps
components discover where other services are, what tables and
column data can be queried on in data sets, what parameters
applications rely on.
<dd-mmm-yyyy>
<<title>>
1
AstroGrid framework:
A PPARC funded project
Community
Portal
The virtual data repository
Tool to sequence applications
Workflow
Registry
Myspace
working on a data set •Data discovery and resource directory,
Integrated applications for data manipulation
DataAccess
CEA
Access to the Data
•Auxiliary applications for portability of heterogeneous data.
AstroGrid Registry
The registry is a set of web service interface
methods conforming to the IVOA standard for
Query and Harvesting interfaces,
Astrogrid registry versions supports 0.9 and
0.10.
registry uses eXist database for the xml and
indexes the xml for querying using Xquery
Now replaced with eXist with exception
handling using the apache-commons-http
<dd-mmm-yyyy>
<<title>>
3
Features
The registry supports search in ADQL.
The version of Resources for querying is identified by
the VR namespace (or defaults if not present).
The registry server provides a variety of properties
that normally do not require changing. But the
flexibility allows to support other versions of IVOA
schemas.
Updates access the VR namespace and store it in the
appropriate collection (table).
Registry web service infrastructure uses Axis
message-style back-end.
<dd-mmm-yyyy>
<<title>>
4
Features contd.
Axis simply gives the XML DOM doc to the
service to figure out what to do. Binding or
generation of java objects anywhere is
avoided.
Validates the XML incoming, but depending
on how the properties are set, it will try to
store the XML.
Using a XML database allows storing any
extensions to the Registry Resource schemas
(CEA XML).
<dd-mmm-yyyy>
<<title>>
5
Current Astrogird registries
Astrogrid

Cambridge - publishing registry

Cambridge - full registry 0.9 only at the moment

Hydra - full registry 0.9 and 0.10 data.
Others
<dd-mmm-yyyy>

STSCI – full registry recently 0.10

Caltech – full registry 0.10

NCSA – Publishing registry 0.10

Heasac – Publishing registry 0.10

Vizier – Publishing registry 0.9 and 0.10

JVO and CanadaVO may be coming soon.
<<title>>
6
Problematic Areas
Invalid data and namespaces became a big
problem for the portal.
eXist database as its own server works well.
A few inconsistant problems have recently
shown up with the webapp version under
tomcat with large amounts of data.
<dd-mmm-yyyy>
<<title>>
7
Next Step
1) Security – Authenticate and Authorize updates of data.
2) Curration – Making sure our data is appropriately described.
3) Fall Over Protection – discover if a registry is down and
switch to another registry.
4) Re-factoring
5) Explore other interfaces into eXist; ex: Soap service vs REST
style
6) Query processing: return sub-elements to Resource query
7.) Xforms – Maybe another look at this at a later date.
<dd-mmm-yyyy>
<<title>>
8