Home for the UWS Registry Extension?

[Paul Harrison]

> On 2018-08 -27, at 08:28, Markus Demleitner <msdemlei at ari.uni-heidelberg.de> wrote:
> 
>> 
>> Secondly I have to say that "feel" that discovering services in
>> the registry should be easier - the logic of service discovery
> 
> Yeah, so does everyone.  But really, the concept of "A service has a
> couple of capabilities, each of which can have a few interfaces, each
> of which has an access URL and possibly a couple of mirror URLs" is
> about as simple as we'll ever get it.  Each level is in active use
> not (just) for exotic fringe cases but for fairly fundamental
> modelling of our resources.
> 

This is essentially the data model of a service in the registry - however, I think that the problem in the pattern of registering a set of URLs within a “uws" interface that is proposed in this TAP 1.1 use case is making things more complicated - the difference between registering the base address and the individual sync/async endpoints makes them non-equivalent. If each of services are regarded as a “function” with a set of parameters and a result then each of the Interfaces should be thought of as a different way of packaging the parameters and the results - When this model was conceived the two main competitors for packaging were SOAP and form encoded, and the hope was that a query like 

SELECT  intf_type, access_url, security_method_id
FROM rr.capability
NATURAL JOIN rr.interface
WHERE ivoid = 'ivo://datacentre.org/myservice’
and standard_id like 'ivo://ivoa.net/std/aservice%’

would result in a set of access_urls that were equivalent in the sense that for a given set of parameters the same result would be obtained - the intf_type would tell the client how to package/unwrap the parameters/result and security_method_id tells the client what authentication to use/ Any repetitions of intf_type and security_method_id with different access_urls should be transparently equivalent - i.e. it would not matter which access_url was used by the client (the different URLs would have been registered for load balancing, redundancy etc.) 

Unfortunately this simple model was somewhat compromised by the agreements that were eventually reached on the published schema, because to allow for various groups' different world views of how the registries would be used, various asymmetries were introduced, and more flexibility in what the accessURL might mean via the “use” attribute. For instance I had the strong conviction that if the interfaces where equivalent then the parameter declarations for each should be the same (which is the reasoning behind PDL), but the relative demise of SOAP already meant it seemed that there was really only one “interface” type that might be called by programmatic clients, and paramhttp was born. The inclusion of the “WebBrowser” interface type again only further blurs the vision of the simple aspects of the original model.

As an aside it is clear that SOAP was not a good fit for most of the discovery services that we are primarily concerned with as the number of input parameters are relavtively small, but the number of results are typically quite large, so the best fit is actually to package the results in their own format (i.e. VOTable) and in fact the SOAP wrapper just gets in the way compared with the simplicity of a HTTP “blob” return. However, there might be a class of services (e.g. a co-ordinate conversion service) where the set of results is small and actually the RPC style of wrapping might work better (I see attempts to squeeze things into VOTables which seem quite forced to me), and indeed it is good to keep in mind that there might be future protocols for wrapping services in HTTP (e.g. GRPC) that would work well for certain classes of services. 

Given that I believe that it is better to register the base address only for a particular capability type, I am not sure that an interface type of UWS is actually a useful addition at the moment - I think that part of the reasoning behind paramHttp was to be able to register a non-standard service, but then then also using it as part of the search criterial to register/find standard interfaces is causing problems, so something new would be good - however, the “uws” interface does not apply to all VO services, so that would not be a particularly good choice. Furthermore UWS as used in DAL has some slight restrictions on the pattern of use that a “pure” UWS interface need not have - for instance the “Job description language” in the more general UWS definition does not have to be form-encoded, which is implicit in the DAL usage pattern. Thus, using the idea from above that the interface in a registry defined service should define the inputs and the outputs it seems to me that better solution might be to make a “std” (or “dali”) interface type that simply means that the interface which follows the the standard protocol for the service (whatever that might be), as “pure” UWS only actually defines something that happens in the “middle” of the service and actually says nothing concrete about the forms of the inputs and the outputs.

Additionally if the URL endpoints of all the VOSI functions are fixed by convention it does not really seem worth registering these as it further gives the impression that they might be variable - from a server point of view it is easy to make sure that they appear at the correct URL, but if these are allowed not to be at the fixed endpoints then a client always has to consult the registry to discover them, complicating implementation.

In general I think that a 'convention over configuration’ approach would benefit registry operations by reducing the opportunities for confusion and clearly as has been said elsewhere allow for easy use of non-registered services by simply telling a client a single access_url. This works fine also for different security methods if the whole tree is conceptually separate for each security method and each has its own interface definition, rather than as suggested in the TAP 1.1 document that the URLs for each different security method occur below the base URL. There is the other question as to why we are having even to register these different security methods when the rest of the internet seems to get along fine with discovering what is authentication is needed during the initial handshake between client and server….

Paul.


-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 1905 bytes
Desc: not available
URL: <http://mail.ivoa.net/pipermail/grid/attachments/20180905/fd65f9e6/attachment.p7s>