Title: IVOA Recommendation: IVOA Support Interfaces
ArXiv ID: 1110.5825
Date: 2023-06-15
Authors: : John Doe, Jane Smith, Michael Johnson
📝 Abstract
This document describes the minimum interface that a (SOAP- or REST-based) web service requires to participate in the IVOA. Note that this is not required of standard VO services developed prior to this specification, although uptake is strongly encouraged on any subsequent revision. All new standard VO services, however, must feature a VOSI-compliant interface. This document has been produced by the Grid and Web Services Working Group. It has been reviewed by IVOA Members and other interested parties, and has been endorsed by the IVOA Executive Committee as an IVOA Recommendation. It is a stable document and may be used as reference material or cited as a normative reference from another document. IVOA's role in making the Recommendation is to draw attention to the specification and to promote its widespread deployment. This enhances the functionality and interoperability inside the Astronomical Community.
💡 Deep Analysis
📄 Full Content
In this architecture, users employ a variety of tools (from the User Layer) to discover and access archives and services--that is, resources--of interest (represented in the Resource Layer). A registry plays a role in discovery by harvesting metadata that describe archives and services and making them searchable from a central service. The VOSI interface provides a means for a service to provide some of this metadata itself; this allows a registry to pull the metadata from the service rather than relying on a human to provide it (e.g. by typing the data into a registration form manually). This mechanism can make it easier to collect highly detailed metadata (e.g. descriptions of columns in a catalog) that might not be practically provided otherwise. As some of this metadata describes the service interface and how it behaves, other applications can use this information for controlling how they use the service. Even when the service is "discovered" through some means other than a registry, an application can still understand how to use the service by querying for this information directly. (See Appendix B for a more detailed description of this use case.) Once a user discovers data and services of interest, she will want to engage them in an analysis process. Success requires that the selected services are actually up and running properly as a down service can cause automated processing to fail completely. Registry and workflow services can assist with this by tracking the availability of services and alerting users about downtime. We envision that VOSI will allow VO projects to better track the overall health of the VO ecosystem.
The standard interface returns metadata without changing the state of the service with which it is associated. This could, in principle, be implemented in any of three ways:
As extra SOAP operations on an existing SOAP endpoint of the service with which it is associated. This would be a ‘SOAP binding’ of VOSI.
As SOAP operations on a separate SOAP endpoint. This would be an alternate form of the SOAP binding.
As web resources with distinct URLs, without using the SOAP protocol. This is the ‘REST binding’ for the standard interface.
This standard requires the REST binding of VOSI even when applied to services that otherwise use SOAP. No details of the SOAP binding are given in this version of the standard.
In the REST binding, the support interfaces shall have distinct URLs in the HTTP scheme and shall be accessible by the GET operation in the HTTP protocol. The response to an HTTP POST, PUT or DELETE to these resources is not defined by this specification. However, if an implementation has no special action to perform for these requests, the normal response would be a HTTP 405 “Method not allowed” status code.
The endpoints and interface types for the support interface shall be defined in the service’s registration using one Capability element for each interface. The values of the standardID attribute for these Capabilitys are given in section 4.
When using the REST binding, any HTTP URLs may be used. The client must find the appropriate URLs from the service’s entry in the VO registry and, in general, should not try and infer the URLs from any other URLs for that service. However, standards for specific services may put extra constraints on the form of the URLs.
There are various classes of metadata that might be returned by a service through its standard interface: those describing its functional capabilities those describing its operational behaviour -availability, reliability, etc. those describing tabular data handled by the service those describing other aspects of the service This section defines how each of these classes is represented. The following typographic convention is used to represent a XML element defined within a particular namespace:
For example, {http://www.ivoa.net/xml/VOResource/v1.0}resource indicates a XML element named resource that is described in the XML schema associated with the ‘http://www.ivoa.net/xml/VOResource/v1.0'
namespace -in this case, this would be VOResource.xsd [12].
‘Capability’ is unfortunately an overloaded term in the VO referring to both a functional aspect of a service and also particular pieces of metadata defined by various XML schema. When referring to an XML element called ‘capability’, it shall be be put in italics. Its parent namespace may also be included (using the syntax described above) if it is ambiguous which XML schema is being referred to.
This interface provides the service metadata in the form of a list of Capability descriptions. Each of these descriptions is an XML element that:
states that the service provides a particular, IVOA-standard function; lists the interfaces for invoking that function; records any details of the implementation of the function that are not defined as default or constant in the standard for that function.
For example, one Capability might describe a cone search function and anot
