[TAP] draft 0.42 - errors

[Doug Tody]

On Thu, 30 Apr 2009, Paul Harrison wrote: 
>
> On 2009-04 -29, at 23:02, Doug Tody wrote:
>
>> I have to disagree with this Paul.  As Pat points out, we want to
>> separate the logical service protocol (TAP) from the transport used
>> here (HTTP).  In part this is to permit other transports, such as SOAP,
>> or possibly even local area transports (e.g. a desktop message bus) if
>> we were to use such a service for data access within a single computer.
>
> Pat also points out hat the current way that all the DAL standards are 
> written at the moment does not do this layering - they are all intimately 
> tied to HTTP and as such it would be nice if they followed HTTP conventions.

This is not the case at all.  The logical interface for these services
is merely a set of operations, each with a defined set of parameters,
with a standard and consistent mechanism for status and error returns.
In the case of HTTP as the transport protocol we have a defined
mechanism (REQUEST and VERSION, adopted from OpenGIS) to define the
service operation to be invoked.  The parameters can be extracted
from HTTP and placed in a parameter set.  At that point all we have
is an abstract service operation with an associated parameter set.

The DALServer service framework for example does exactly this,
and except for a thin layer on top, the service implementations are
completely independent of the HTTP transport, with most of the service
interface code shared by all the service types.

See for example the Javadoc pages at
http://webtest.aoc.nrao.edu/ivoa-dal/javadoc/.  If we look at a
particular service implementation such as SIAP, there will be two
methods, SiapServlet and SiapService.  The "Servlet" bit handles the
HTTP interface and is very thin.  The "Service" part is the actual
functional code for the service, and is independent of the transport -
the exact same code can be used regardless of the transport, or with no
transport at all, e.g., for host execution and debugging.  SiapParamSet
contains the parameters for the SIAP QueryData operation and is
completely transport agnostic, merely containing a set of parameters
with associated values.  If any errors occur during execution they
are processed as generic Java exceptions and (in the case of HTTP)
eventually caught up at the Servlet layer, where a generic error
response status return using VOTable is formatted and returned.

The same thing can be done on the client side of course, and has been.

 	- Doug