TAP information schema

[Guy Rixon]

On Thu, 11 Oct 2007, Patrick Dowler wrote:

>
> I also agree 100% with this -- need both sync and async and the output of the
> async should go to a VOSpace...
>
> Can one just specify that the output is to some combination of a service type
> (soap, rest, etc) and a service endpoint (URL) that makes ? Would that
> include VOSpace and other (unknown) interfaces? The reason I am asking is
> that for VOSpace 1.x the destination is a SOAP web service but there was lots
> of talk about VOSpace 2.0 being REST (eg more vanilla http).

In CEA v1, the remote endpoints for data flows are just URLs. If the service
sees an ivo:// URL then it looks it up in the registry; typically this is an
AstroGrid-MySpace service. if it sees http:// or gsiftp:// instead then it
knows how to deal with those. There's no type information alongside these
URLs.

Similarly, a service presented with a vos:// URL knows it's dealing with
VOSpace, but it has to go to the registry (or to its cache of registry
information) to find out which version.

The pattern is that a data URL is either for a data stream or for a service
that is a generator of data streams, and the only supported cases of the
latter are MySpace and VOSpace. We can't exchaneg data with an arbitrary SOAPm
or REST service unless we know its protocol.

> Also, is either of sync or async an optional capability? My feeling is that at
> a minimum sync is required and async is optional, but anyone with a decent
> sized database is going to implement async.
>
> Further, I think a TAP service should have the option of refusing to execute a
> query in sync mode and telling the caller that async must be used. We would
> need to specify exactly how the service makes this known, but in the general
> case a service may decide after seeing the query itself so I think this is a
> sort of result or error message (actually more like an http redirect) that
> clients will have to deal with.

The asynchronicity or lack thereof would have to be described in the TAP
capability. I suspect that it's going to be a separate Interface element to
the synchronous functions. It may by (as Paul Harrison has already suggested)
that we need a formal sub-type of Interface called UWS.

> pat
>
> On 2007-10-11 04:27, Alex Szalay wrote:
> > My 2 cents on Sync/Async:
> >
> > we desperately need this feature to build the next generation scalable
> > services. Not to have this is simply not an option in my opinion
> >
> > I think that most of the hard work that went into VOSpace was with this
> > feature in mind, so I would strongly recommend that the default proposal is
> > to use VOSpace for async messaging
> >
> > We still may want to retain the ability to do sync returns, especially for
> > small requests (like metadata). It would increase the responsiveness of our
> > services if for such requests we could expect an immediate response.
>
>
> --
>
> Patrick Dowler
> Tel/Tél: (250) 363-6914                  | fax/télécopieur: (250) 363-0045
> Canadian Astronomy Data Centre   | Centre canadien de donnees astronomiques
> National Research Council Canada | Conseil national de recherches Canada
> Government of Canada                  | Gouvernement du Canada
> 5071 West Saanich Road               | 5071, chemin West Saanich
> Victoria, BC                                  | Victoria (C.-B.)
>
>

Guy Rixon 				        gtr at ast.cam.ac.uk
Institute of Astronomy   	                Tel: +44-1223-337542
Madingley Road, Cambridge, UK, CB3 0HA		Fax: +44-1223-337523