[TAP] sync vs async
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.
More information about the dal