Studies and Tasks Undertaken in VOTech

Web presence

VOTech uses its Internet presence for a number of activities:

• Provide a public introduction to the project and its progress (http://eurovotech.org/)
• Plan and monitor progress in the various stages and publish interim findings and reports (http://wiki.eurovotech.org/bin/view/VOTech/)
• Discussion of various issues and plans (http://forum.eurovotech.org/)

These services are hosted and maintained at the IoA Edinburgh.

Reports

Client-side User Interface report

See: this link.

Wrapping heterogeneous data

[CDS]

Investigations

Provide access to SIAP, SSAP, ConeSearch, OpenSkyQuery etc

A number of early studies were undertaken to evaluate how these protocols might best be supported from within the astroGrid infrastructure. The DSA, CEA and JES componnets were all considered. This has resulted in recent work on the following:

• DSA: This component is now a family of componanets rather than a monolith. Thus we are working on DSA/Catalogue, DSA/SIAP, DSA/SSAP etc
• The AR is now capable of access these and other IVOA compliant services. Existing astroGrid components will be refactored over time to use the AR. Once this is complete, it will be possible to call all IVOA compliant services from within any AstroGrid component.

See: AR below.

Prototypes

VizieR ADQL-SkyNode

[CDS]

Mediation tools

[CDS]

Intelligent Agents

- Prototype - Build a pure database system - VOEvent - Investigate wrappers - Network prototype - First cut infrastructure libraries - Agent with workflow core - Recommendation report

VOTechBroker

The VOTechBroker (VOTB) acts as a bridge for submitting parameter sweep computations from the Virtual Observatory to the Grid, and other distributed resources. It provides a number of features, including:

• Flexibility: Most existing projects provide interaction with a given Grid middleware only, for example Globus. In some cases interaction is tied to a particular version of Globus. Our approach is to utilise whatever middleware a site already has installed. For example if Globus or Condor are not available we can still execute the client's algorithm. We do not require system administrators to install additional software.
• Transparency: A standards based job description language abstracts clients from the syntax of underlying grid middleware. Conversion between this abstract language and middleware specific syntax is performed by drivers that plug in to the submission framework.
• Ease of use: Details of parameter sweep job submissions are hidden from the client. Issues such as location of resources, staging of application binaries and data, the monitoring (and restarting) of jobs, the staging of results are taken care of by the broker.
• Distribution: The broker does not assume a shared file system between resources. It is the responsibility of the information service to detect which endpoints have shared file systems and optimise file staging appropriately.
• Integration: The VOTechBroker provides a SOAP interface so that a diverse range of clients can submit jobs and monitor progress. Current clients include, CEA wrapped 'thin-clients' for integration with the AstroGrid Workflow, Java (Web start) applications and Web forms.

See this link

Security

Components are being develped following the emerging IVOA architecture. These stand as reference implementations to validate the IVOA architecture and allow EuroVO to implement SSO in advance of IVOA’s final standard.

The AstroGrid components are as follows.

• Community services, including MyProxy, user management and the attribute service.
• Facilities in the Astro Client Runtime (ACR) to obtain and store credentials for use of a client application.
• Java classes to obtain credentials from a MyProxy service.
• “Security facade” of Java classes to:
  • sign outgoing SOAP requests;
  • check signatures on incoming SOAP requests;
  • handle authorization decisions based on attributes;
  • participate in credential delegation

See this link

Astro Runtime

The Astro Runtime is a programming interface for any client code that wants to access Virtual Observatory services. It's facilities are exposed via a range of technologies - HTTP / XML-RPC / Java-RMI, making it easily accessible from almost all programming and scripting languages. It hides the complexities of the VO - security, configuration, service resolution - and lets developers get on with the interesting stuff.

The runtime simplifies access to

• IVOA standard services : Registries, Siap, SSAP
• All AstroGrid services : MySpace, Workflow, CEA
• Other popular protocols: NVO Cone-search
• Useful one-off services - CDS Simbad, etc

It also provides GUI components - simple dialogues that can be reused by client applications to perform common tasks (myspace microbrowser, registry browser, etc). Other benefits of the runtime include single sign-on, single-configuration, and single cache service responses - making implementation of client-side applications simpler.

See this link

PLASTIC

PLASTIC is a protocol for communication between client-side astronomy applications. It is very simple for application developers to adopt and is easily extended. Through PLASTIC applications can do tasks such as instruct each other to load VOTables, highlight a subset of rows or load an image of a particular area of sky. Although such operations are quite simple, they enable powerful collaborations between tools. The philosophy is that the astronomer should have a suite of interoperating tools at his disposal, each of which does one thing well and which can be composed according to need

See this link

Workflow

Develop Use Cases and a prototype for generic workflow requirements

[CDS]

Workbench

Standards

VO WS Profile

[CDS]

UWS (w/ ESO)

An interface for controlling long-running activities ('jobs') via an asynchronous SOAP service. The interface follows the WS-ResourceFramework (draft) standard of OASIS and includes ideas from AstroGrid's Common Execution Architecture. If implemented in full, the interface defines a universal worker service.

See: here and here.

VO Data Storage (w/ ESO)

Overview

There is a strong desire within the Virtual Observatory to have a distibuted storage mechanism, that will allow users to easily refer to a piece of data without necessarily needing to concern themselves with the physical location. The task of defining this system has been given to the IVOA Grid and Web Services WG This conceptual storeage space is called VOSpace. It is envisaged that the VOSpace will manage references to the physical location of data. A primary design goal of VOSpace should be to allow easy integration of existing systems such as SRB or NGAS which have similar goals, but differing levels of abstraction and implementation

There are two primary use cases

1. A certain dataset is needed for anaysis - for efficiency reasons it would be best if the data could reside "close" in network terms to the compute resource on which the analysis will be performed. In the ideal case this will involve the data being located on the anaysis computer's hard disks. With potentially many analyses being performed on the same data at many locations, it is more efficient if the data are gradually replicated onto these locations
2. A user would like easily to publish and share his own data.

See this link

Prototypes

• VOStore interface to NGAS created
• 1::Many FileManager-FileStore support prototyped at ADASS, Oct 2005