[VOSI] Re: TAP 1.0: sync vs async

[Douglas Tody]

On Mon, 20 Jul 2009, Patrick Dowler wrote:

> Current draft:
>
> $base/async?REQUEST=doQuery&...
> $base/sync?REQUEST=doQuery&...
> $base/sync?REQUEST=getAvailability
> $base/sync?REQUEST=getCapabilities
> $base/sync?REQUEST=getTableMetadata
>
> Proposed (e.g.):
>
> $base/async
> $base/sync
> $base/availability
> $base/capabilities
> $base/tableMetadata
>
> As a side effect, this makes REQUEST obsolete since there is only one possible
> value (doQuery). On the surface, this is unlike DAL2 (specifically, SSA 1.0)
> which is syntactically like the sync endpoint of TAP.

What we have with REQUEST/VERSION is an interface pattern which can be
applied consistently in all the DAL2 interfaces to describe services
following the OO model of a service with operations decoupled from the
underlying communications protocol.  It does not matter if a given
service has only a single operation; if we make a special case of a
particular service then the pattern is broken and we no longer have
interface consistency and a simple way to compose service operations.
Other services do have multiple operations, or a new operation might
be added to an existing service interface in a future version.

As I also noted earlier, getCapabilities is not merely needed for
VOSI compliance, it is also needed directly by client applications.
Hence from the client point of view TAP would still have at least
two operations in any case, following the serivce operations model.
All of the DAL interfaces describe getCapabilities and service metadata
and we would like to do this consistently; it is an important part of
the client interface.  Since the VOSI URLs are specified explicitly
when the service is registered there is no problem providing VOSI
compatibility as well.

The proposal to eliminate REQUEST/VERSION would also involve loss
of the explicit version checking and version negotiation capability
provided by VERSION.  In the current DAL2 (basically OpenGIS) interface
we have runtime version checking if VERSION is specified.  Even if
the registry is used to find a particular version of the service
it is useful to have runtime version checking for error detection.

If the service supports multiple versions the one to be used can
also be specified at runtime (including experimental versions not
yet registered, e.g., for testing new versions).  Runtime version
negotiation of a common version is possible at connect time if both
the client and service support multiple versions.  Some of this can be
done via the registry by finding only services with specific versions,
but a requirement has long been that the client should be able to
access all essential functionality by talking directly to the service,
without registry interaction once the service has been located.

The proposed change is not a trivial matter as if this change is
made we can no longer provide a consistent interface among all the
DAL2 services.  SSA is already widely implemented and in the process
the DAL2 service profile based upon REQUEST,VERSION etc. has been
implemented in existing service frameworks based upon this standard.
Other current draft specs (SLAP, SIAV2 at least) and various DAL
documents already in distribution follow this interface pattern.
We are being asked to change all this in a fairly fundamental way
affecting the basic service interface.  More fundamentally, I see
this is as a push away from the whole concept of logical service
operations upon which DAL has been based for the past several years,
towards the more pure REST model currently favored by a few others.

> In the previous discussions, we considered this mainly a stylistic issue and
> it looks a lot like DAL-style vs GWS-style :-) However, as has been discovered
> and pointed out, putting VOSI resources under a service-specific resource
> couples the mandatory-ness and I find that to be a compelling reason to make
> this change. Discussions of required vs optional should not be encumbered in
> this way.

There is no difficulty specifying that support for a sync
getCapabilities (for example) is mandatory.  This need not imply
that more complex functionality such as the data query must also
support /sync (although personally I would find that reasonable).
We have already agreed in earlier GWS/DAL discussions that any fixed
URL can be used to specify the VOSI endpoints hence how we specify
a service interface is up to the service and not specified by VOSI.

> If we were to make this change, it would open up the possibility to make one
> or both of sync and async optional and whose presence/support would be
> described by capabilities. Maybe that would be a change for the future as I
> think it is easy enough to relax restrictions. I certainly can see other types
> of services not wanting to require both and hence having to break with the
> style used in TAP (or SSA) anyway, and if that is the case maybe now is a
> better time than later to at least make it cleanly possible by separating the
> VOSI and service resources.

A possible compromise might be to deal with VOSI differently
than the application specific (service defined) operations such
as doQuery, queryData, etc., retaining REQUEST and VERSION for the
service-specific operations, thereby eliminating the use of /sync for
the VOSI operations.  This would require treating getCapabilities
(VOSI) as a special case but at least it could still be handled
consistently among all the services.  In my view the issue of linking
/sync to a VOSI operation does not justify not providing a consistent
interface pattern and the redirect issue is just not that important
here (we are not going to have to worry about thousands of simultaneous
getCapabilities requests).  But we should try to find a way to resolve
this without abandoning REQUEST,VERSION which would greatly impact
all of DAL2.

 	- Doug