TAP Implementation Issues: Final Comment: TAP and UWS, sync and async

[Guy Rixon]

Tom,

whenever you use UWS in a service definition, you have to say what  
parameters it takes when setting up a job and the work done by that  
job. That's the "application of the UWS pattern" to use the terms from  
the UWS standard.

The UWS specification is supposed to be reusable between applications;  
hence the U in the title. Therefore, it can't specify the application- 
specific parameters.

It's possible to specify a UWS-conforming service for more than one  
application. CEA does this. The modern interface of this kind is  
called UWS-PA ("UWS for parameterized applications") and its fore- 
runner (which is SOAPy) is the Common Execution Connector. In these  
kind of services, the applications are pluggable.

AstroGrid DSA/Catalogue has had a CEC interface for years. It uses a  
generic CEC implementation and passes the requests through to an ADQL- 
query application plugged inside it.

The downside of generalizing a job-control service in this way is  
complication and divergence from the synchronous case. TAP/UWS is  
quite like asynchronous TAP: you do an asynchronous query by POSTing  
the same parameters you could use for a synchronous query. If you try  
to use CEC or UWS-PA to start a TAP query then you have a different  
interface. Because that interface is more general, it's not as simple,  
either to implement in a service or to call from a client.

I think that the current boundary between TAP and UWS is just where we  
need it for the simplest implementations.

Cheers,
Guy

On 6 Nov 2009, at 15:33, Tom McGlynn wrote:

> I'm sure everyone will be happy to see the word 'Final' in the  
> title...
>
> In the past couple of days I've gotten the UWS asynchronous  
> implementation of TAP working (though doubtless still bug-ridden).
>
> When I read and implemented the TAP and UWS standard I had the sense  
> of UWS as being a layer within TAP.  In retrospect I think it would  
> have been better (for my implementation at least), if I had  
> distinguished them more clearly.
>
> Suppose we think of UWS not as an interface layer but as the  
> definition of how to build an asynchronous proxies.  UWS becomes a  
> service definition, not an access protocol.  The proxy accepts and  
> caches input parameters from the users, starts the underlying  
> request when told to, caches the response and sends it back to the  
> user when requested.  [I haven't followed the discussions of UWS  
> earlier in the Grid list, so my apologies if I just discovering what  
> everyone already knows....]
>
> If I think of things this way, then I can implement UWS completely  
> independently of the underlying application. Indeed the binding to  
> the underlying application could be dynamic: I can provide a UWS  
> layer over any number of distinct synchronous applications.    I  
> don't need to know anything about what parameters they use, just  
> some root URL.  The one piece of the  specification that might cause  
> problems is the desire to support multiple outputs as well as a  
> single result.  That's not at issue in TAP, but even this could  
> easily be handled by returning a list of the outputs -- which is  
> what UWS does now anyway.
>
> UWS is not described this way in its standards document: it is shown  
> as a layer within some bigger application, not as a separable  
> entity. Similarly TAP shows the asynchronous interface tightly  
> coupled within the rest of the TAP.
>
> In this new view, the TAP document would say very little about the  
> asynchronous interface.  TAP itself would be synchronous, but if we  
> want asynchronous access to be mandatory then the requirement is  
> that a TAP implementation must specify a corresponding UWS service  
> through which the TAP implementation can be invoked.  We could still  
> have a TAP service that is only available asynchronously: we allow  
> that this TAP service is not directly callable: Only the associated  
> UWS service can access it.  I'm not trying to take sides here in the  
> sync/async wars.
>
> Changes to the UWS document would be rather more subtle, noting that  
> the interface can implemented without reference to the underlying  
> implementation, and perhaps explicitly supporting the kind of  
> dynamic association with the underlying synchronous service  
> mentioned above. Maybe provide a convenience resource to get the  
> output in the single output case (rather than having to parse the  
> output list).
>
> The advantage had we taken this approach before, is that it largely  
> decouples TAP and UWS.  The TAP standard is shorter and simpler.   
> The UWS standard is largely unchanged.  We can change UWS in the  
> future without worrying about any impact on TAP.
>
> This is probably a bridge too far in terms of the TAP standard.  For  
> UWS it's really a change in tone more than content -- hints to the  
> user -- so perhaps it is doable were it to be thought a good idea.   
> Regardless, I do anticipate revising my own implementation to use  
> this approach after the Interop.
>
> 	Tom McGlynn