This are my initial notes on how PAL works. -- DaveMorris - 27 Apr 2005

InterfaceLayer^?

Interface layer provides external service API.

• Original AstroGrid
• AstroGrid CEA
• ConeSearch
• SIAP
• SkyNode
• SSAP

Input is ADQL query, plus details of where to send results.

AstroGrid interface

This provides as much functionality as possilbe, in particular the asynchronous query handling that we can't provide via SkyNode.

This has been used by some 3rd party teams, but not used at the moment.

Some experiments using this with Taverna and Triana.

As a SOAP service it provides a standard way to integrate with our services using the service WSDL.

CEA interface

Takes 'stuff' from the CEA interface (see Noel) and converts the parameters into the right form for PAL.

Cone Search interface

A servlet implementation that takes RA and DEC.

SIAP interface

A servlet implementation similar to ConeSearch^?, and returns URLs to files that match the query.

Sky Node interface

• An IVOA standard, the implementation not finished yet.
• Attempt using Castor XML Beans got too complicated.
• Attempt to use the ADQL XML direct from the SOAP request is in progres.

SSAP interface

• Similar to SkyNode.
• Not implemented yet.
• Pedro Osuno has done some work in this field.

Data server

DataServer^? layer provides THE common business logic behind the interfaces.

DataServer^? creates a new instance of Querier to handle each request.

Querier

A Querier instance contains

• Account details
• Current status
• The query model
• Where to send the results

Query account

• Account is currently passed as java.xx.Principal
• Not used in implementation.
• Needs lookup for 'get me login name for this ftp server'
• Uses anon for ftp servers if required.

Query status

• Java package with status codes.
• General AstroGrid status codes.
• PAL specific status codes.

Query results

Plugin is responsible for sending results.

• JDBCPlugin uses SQLResults
• SQLResults is a wrapper for RowSet^?
• SQLResults uses TableWriter^?

Query model

QueryModel^? is a Java representation of the ADQL query, containing

• List of scope
• The Condition and Expression tree

QueryModel^? contains ResultSpecification^?, containing

• List of order
• List of expressions
• Target to send results to

Query scope

This represents the FROM part of the ADQL query.

Condition tree

This represents the WHERE caluse as a tree of Condition and Expression objects.

Query sort

This represents the ORDER BY part of the ADQL query.

Output expressions

This represents the SELECT part of the ADQL query.

TableWriter^?

TableWriter^? is an interface.

• VOTableWriter^? to generate VOTable
• HTMLTableWriter^? to generate HTML
• FITSTableWriter^? to generate FITS (inefficient, not streamable)

---

QueryModel^? is passed to a back end plugin for the target database - wrong

• Vendor specific JDBC plugins (PostgreSQL, SQLServer etc)
• FITS file metadata in eXist (MSSL Solar data)
• VizierPlugin^?, acts as a proxy, requesting data from Vizier and handling where to send the results.

Possibly closer would be ....

• Request creates instance of Querier
• Querier contains instance of QueryModel^?
• Querier uses instance of DatabasePlugin^?
• DatabasePlugin^? uses instance of TableWriter^?
• TableWriter^? uses instance of Slinger

---

FITS file plugin handles queries on metadata in eXist database. Returning a VOTABLE of URLs to individual files. URLs point to a servlet which enables client to access the files.

Note - FITS files returned from Solar dataset are not normal FITS files, and require Solar specific client tools. The user has to know that the files need Solar specific client tools, else gibberish occurs.