[TAP] sync vs async

Paul Harrison paul.harrison at manchester.ac.uk
Thu Mar 5 04:03:35 PST 2009


Here is my contribution to this debate....

It is clear that implementing an asynchronous UWS style interface is  
more work than a synchronous interface, but it is not an
"order of magnitude harder" - as has been suggested - indeed there are  
already two prototype TAP implementations in existence with the full  
asynchronous interface. It has also been suggested in this list that  
the asynchronous behaviour is all "too complicated" and why do we not  
just do the same simple thing that the rest of the web does - well  
every web page that has an image in it is accessed in an analogously  
"asynchronous" fashion to the TAP protocol if you regard the complete  
page loading as the "unit of work"

I think that everyone agrees that asynchronous behaviour is necessary  
for the cases where the database query response time is greater than  
the typical network timeout or where the  network is unreliable.  
However, there are actually other benefits to the UWS pattern - the  
main one being that the results are not automatically retransmitted to  
the client. This can have a major impact in reducing unnecessary  
network traffic in a "workflow" situation, as the URL of the results  
can be passed to the next service in the chain and thus the data can  
flow direct from service to service instead of having to flow through  
the client. This use case is one of the major arguments for co- 
locating a VOSpace service with the TAP service, and it is certainly  
easier to implement the UWS pattern than a full VOSpace.

As for whether the asynchronous mode should be mandatory or not - I  
say yes because that is the only way to support the more complex use  
cases for the service that will actually make the VO different from  
what we can do with the form based services that already exist for  
every archive today. SkyServer and CASJobs were were way ahead of  
their time in terms of an ambition that seems to have been lost now.

Paul.




More information about the dal mailing list