TAP information schema

[Doug Tody]

All the second generation data access services will need integration of
Grid capabilities including UWS (SIA V2 in particular, but all of them
ultimately).  Since these are a family of closely related services
it should be done in a consistent matter throughout.  The intention
has always been that UWS will be used for this (e.g., the standard UWS
interactions could be used once a job is running), however how the job
is initiated may need to be tailored to the individual service, since
a service query impliclitly defines the job in terms of what is to be
produced.  While capabilities such as asynchronous execution, VOSpace,
authentication, etc. are needed for the second generation services,
is remains important that basic usage should still be simple.  - Doug


On Fri, 12 Oct 2007, Paul Harrison wrote:

> On 2007-10 -11, at 15:15, Doug Tody wrote:
> 
> > 
> > Ignoring for the moment the metadata query issue, my impression from
> > discussions over the past year or so is that we already have consensus
> > on most of the above issues.  In short:
> > 
> >    - The basic interface should be REST-like (consistent with the
> >      other DAL interfaces unless there is good reason to diverge),
> >      ideally defined in such a way that the logical protocol is
> >      separate from the transport and could be layered upon other
> >      distributed computing platforms in the future, such as SOAP.
> > 
> >    - Async is required for fully-functional services; it probably
> >      should be required for advanced capabilities such as multi-region
> >      queries, complex or large queries, etc. (in other words, require
> >      async to be able to do these things).
> > 
> >    - Sync (when it works) is *much* simpler for both the service
> >      implementation and the client, and is adequate for many simple
> >      queries including small queries of a single table (which can
> >      normally stream) and metadata queries.  We should provide
> >      for this, with an indication of overflow or other failure
> >      condition; async would ultimately be required in this case,
> >      service capabilities permitting of course.  Simple service
> >      implementations should not be required to implement async, but
> >      a "fully compliant" service (as any major data center should
> >      provide) implements async.
> > 
> 
> The solution to this to always follow the UWS REST pattern for TAP - this is
> always asynchronous (i.e. the return of the original http request never
> contains the result) , but is actually relatively simple - if simple is
> defined by being able use a standard web browser to issue the query and
> receive the result.
> 
> It is not consistent with the S*AP protocols, but I thought that everyone is
> agreed that TAP is not "simple" in that we have cone search for that. TAP, I
> thought, was supposed to be the first "second generation" service that
> benefits from all of efforts that the Grid WG have put into designing a simple
> asynchronous pattern.
> 
> >    - If large amounts of data need to be managed, as well as for
> >      full functionality (e.g., workflows where remote delivery of
> >      results is required) VOSpace should be used.
> 
> precisely - VOSpace is the solution to the intermediate storage and possible
> local re-use of data in a TAP service - it is not the solution to the
> synchrony problem as as been suggested elsewhere on this list - that can be
> solved by UWS alone.
> 
> > 
> Dr. Paul Harrison
> JBCA, Manchester University
> http://www.manchester.ac.uk/jodrellbank
> 
>