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

[Tom McGlynn]

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