The AstroGrid Engine Room

The tools you run on your PC (VO Desktop, Topcat, etc) are just the tip of the iceberg. They rely on a engine working on their behalf, spread all over the world. If you want to know a little more about what goes on under the hood, read on ....

The Client Side Background Software

First is the Astro Runtime (AR) background software, which also runs on your PC, but handles calls to VO services. It is automatically started by VO Desktop, but once it is running, other applications can also use it to access VO services. For example, this is how Topcat can load files from the user's VOSpace account; and most of the AstroGrid Python routines run through the AR. In other words, the AR acts an Application Programming Interface (API) for the VO. Also running on your PC is the PLASTIC Hub. This is a very simple piece of software that allows VO tools to pass messages and files between each other within your own PC environment, routed through the Hub. Any "PLASTIC enabled" application will either start up a PLASTIC Hub, or detect one that's already running. An increasing number of European tools are PLASTIC enabled, and an equivalent protocol called SAMP is currently being developed by the IVOA, so this application interoperability will soon be global.

The Server Side Infrastructure

The next layer down in the iceberg is Community. This is both a standard, defining how you identify yourself, and carry this identity around the internet, and also a piece of software running on a server. The idea is that local institutions will each run a Community service. Users log in to this and so get access to their VOSpace, and can also get access to proprietary data. Today there are only a handful of Communities, but we expect Community services to grow rapidly. Next there is the Resource Registry, the yellow pages of the VO. Again, it is both a standard, defining how you express what a Resource contains, and a piece of software running on a server, that allows applications like VO Desktop to query its contents. AstroGrid runs several registries, and there are several more around the world. They "harvest" from each other so we all stay up to date. However AstroGrid maintains more detail in its registries than most other projects. Finally, among the core set of AstroGrid services, there is VOSpace. Once again, this both a standard defining how remote storage is addressed, and a piece of software running on a server that mediates your access to your storage. AstroGrid had been running a prototype for some years called MySpace, but VOSpace is now an international standard, so global distributed storage will become increasingly transparent. Finally there is the concept of Workflow. This means simply the automation of a sequence of tasks, and is what we provide through AstroGrid Python scripting, which uses the Astro Runtime. However, we intend in the future to also provide a remote Job Execution Service (JES) so that complex workflows can be submitted and continue to run when the user is disconnected.

World-wide services

Of course, the applications, and the AstroGrid infrastructure services like Community, VOSpace and Registry, are of no use without VO content, and in particular Data Services and Remote Applications. Data Services need to follow standard IVOA protocols (like the Simple Image Access Protocol (SIAP) to be capable of being consumed by applications like VODesktop. The AstroGrid Data Set Access (DSA) component is a piece of software with plugins that translate between VO protocols and a variety of native data formats and databases, so that data centres can expose their data in the correct manner. We are working with Euro-VO colleagues at ESAC who are developing a toolkit for publishing resources in the standard registry format, which together with DSA should soon make a way for ordinary users to publish their data. In an analogous manner, the AstroGrid Common Execution Architecture provides a way to "wrap" any application which can be expressed in terms of input and output parameters and files, and provides a working interface by which users can submit jobs. For example SExtractor could be running on a server in Manchester; if you locate this resource, the "Task Runner" in VODesktop allows you to fill in the required parameters including the URL of an input image file; the application runs, and the output object catalogue can be saved in your VOSpace. An updated version of CEA is currently being standardised within the IVOA under the name Universal Worker Service.