IVOA, Kyoto May Data Access Layer Thoughts on ADQL/DAL Integration Doug Tody (NRAO) International V IRTUAL O BSERVATORY

IVOA, Kyoto May Architecture Any DAL Service –Interfaces GET WS –Query Parameter based (GET) Syntactical (ADQL) –Query Response VOTable, based on interface-defined data model –AccessData (Staging) Relies upon GWS asynchronous services infrastructure SOAP request/response, messaging, stateful service –GetData URL-based

IVOA, Kyoto May Role of ADQL/SkyNode Alternative query interface –ADQL document substituted for GET GET parameter interface still supported –Query response is the same in both cases –AccessData is unaffected –GetData is unaffected –Virtual data product is unchanged

IVOA, Kyoto May Implementation Strategy Approach –SkyNode with virtual tables for query front-end –Rest of service is largely unaffected Data Collection Metadata –Preload into RDBMS tables –Metadata conforms to standard data model –Each DAL service class (SIA, SSA, etc.) includes a data model and standard dataset metadata –Will probably require some additional metadata to support execution planning

IVOA, Kyoto May Implementation Strategy Query processing –High level Deals with ADQL extensions, virtual tables –Low level Conventional RDBMS query Query against preloaded tables describing data collection –Construct getData access reference Tells how to construct virtual data product May cache specification somewhere and return reference Or build full specification into access reference –Build query response VOTable

IVOA, Kyoto May Implementation Strategy Data access –Back end is independent of query interface –Use data access framework to construct virtual data product Defines standard interface for per-collection pluggable data access component Component provided by data provider when data collection is published Does the actual data access, subsetting, mediation etc. –Return data directly or via VOStore –Optional AccessData method Can be used to asynchronously stage data

IVOA, Kyoto May Implementation Strategy Primary Interfaces –Client query This is the standard SkyNode / ADQL interface –Data collection This interface defines, for a class of data, the database tables required to support query processing. This will combine information from the DAL object data model (image, spectrum, etc.) with metadata required for data generation. –Virtual data generation This is the interface between the query processor and the “back end” which generates a virtual data product. This is essentially the getData method in a DAL interface.

IVOA, Kyoto May Implementation Strategy Some Issues –Define core subset of functionality required for ADQL (and STC) Any implementation would provide this core Ok to have server-specific extensions Something like JVOQL could be done either by adding extensions or via an optional add-on interface –Multi-language support is important for client side where query is built Client needs to construct query (ADQL-S or ADQL-X) Parse VOTable response (already well supported)

IVOA, Kyoto May Implementation Strategy Some Issues –DBMS support Be careful about using object-database features Good set of DBMS for testing would include MySQL, PostgreSQL, Oracle, MS SQL-Server