Testbed-12 — Catalog Services for Aviation

This engineering report is concerned with two topics regarding the use of registry services:

In this report a registry is construed to be a type of catalog that offers additional capabilities supporting lifecycle governance. While the CSW-ebRIM profile does offer registry functionality, those aspects are not in scope.

All questions regarding this document should be directed to the editor or the contributors:

No future work is contemplated for this document, but change requests against other OGC specifications may arise from it.

Attention is drawn to the possibility that some of the elements of this document may be the subject of patent rights. The Open Geospatial Consortium shall not be held responsible for identifying any or all such patent rights.

Recipients of this document are requested to submit, with their comments, notification of any relevant patent claims or other intellectual property rights of which they may be aware that might be infringed by any implementation of the standard set forth in this document, and to provide supporting documentation.

The following typographical conventions are used in this document:

Catalog (and registry) services play an essential "matchmaker" role in a service-oriented architecture, enabling resource producers and consumers to interact without possessing prior knowledge about service capabilities and endpoints. Clients may search a catalog for resources of interest, and then use the results to obtain the resource from some provider by employing the appropriate protocol or "binding" (see figure below, Role of catalog services).

Within the aviation domain, the catalog role is primarily fulfilled by a SWIM-compliant registry. Existing SWIM registries developed by the FAA and Eurocontrol are based on the Drupal content management system and incorporate concepts from the Service Description Conceptual Model [2] (SDCM). However, they do not currently support spatial queries and cannot readily accommodate OGC service descriptions.

Section 4.5 in Appendix B of the RFQ is concerned with advancing the use of catalog services in the aviation domain. Several functional requirements are presented:

The prospects for improving the interoperability of SWIM registries by adopting existing standards were explored; this work should help to guide the future development of these implementations. Two main recommendations arise that reflect varying degrees of conformance and development effort.

A CSW-ebRIM registry can process the service requests summarized below, most of which are common to all CSW-based catalog services.

A basic read-only implementation supports only search and retrieval operations; this constitutes the lowest level of conformance. The component used in this testbed is fully capable and allows authorized users to submit harvest and transaction requests. Anonymous users may search and retrieve registry content.

The registry service implements a web service API based on the OGC CSW-ebRIM profile. The API is used by other software components to programmatically search and update registry content. As indicated in the following figure, some of the client components may be web applications that present a graphical interface to human users; however, these applications make use of the same underlying API.

The CSW-ebRIM profile marries the CSW catalog interface to the OASIS ebXML registry information model [4]. The extensibility of the underlying model is what makes a CSW-ebRIM registry so broadly useful. The main extension points are presented in the following figure (Extension points in ebRIM).

The highlighted extension points apply to several types of registry objects:

Application-specific extensions are bundled within an extension package (EP) to promote interoperability and reuse. An extension package is itself a registry object (rim:RegistryPackage) that can be imported and enabled in any CSW-ebRIM service. The 'Basic' package [5] is common to all implementations and provides general support for describing geographic services and data sets.

Metadata harvesting exemplifies a convenient pull-style of publication whereby resources are retrieved and ingested in accord with predefined mapping rules. The OGC catalogue specification [6] defines a Harvest request for this purpose. A representation of an XML request entity is shown below. The required Source and ResourceType elements are absolute URIs that identify the target resource and its type, respectively.

The participants in this effort have implemented a specialized CSW-ebRIM harvester for WFS 2.0 services. The source must refer to a WFS service description (an OGC capabilities document). The corresponding resource type is "http://www.opengis.net/def/serviceType/ogc/wfs/2.0", which is the service type identifier assigned by the OGC Naming Authority (OGCNA). The ebRIM mapping rules are summarized in the figure below (Output of WFS v2 harvester).

The root registry object is a Service; it includes a ServiceBinding for the GetCapabilities request and is classified using the geographic services taxonomy defined in ISO 19119. There is an associated ExtrinsicObject (of type "urn:ogc:def:ebRIM-ObjectType:OGC:Dataset") for each feature type listed in the capabilities document; it is linked to a service using the "OperatesOn" association. Each Dataset object has a slot that contains a gml:Envelope representing the approximate spatial extent of the feature data.

Finally, the service is linked to a ServiceProfile object (another type of ExtrinsicObject) that provides information about the general characteristics of the service. In particular, a copy of the OGC capabilities document is available from the registry as a repository item. However, if the service is a protected resource that is not publicly accessible then no ServiceProfile is created. Information about applicable access constraints will need to be obtained from the service provider.

If credentials are required to harvest a protected resource they must be conveyed to the registry in some manner. However, no OGC catalog specification allows for this. The solution adopted here was to exploit the generic syntax for URIs [7], which defines a userinfo field in the authority component in accord with these syntax rules:

In this testbed access to some service capabilities documents was restricted using the "basic" authentication scheme. The user information consists of a user name and password in the format "user:password"; this data is inserted into the Source element of the Harvest request entity as indicated below:

This technique is only appropriate if the harvest request is submitted to the registry over a secure connection using TLS. The message payload is then kept private.

A CSW-ebRIM registry offers a stored query capability whereby predefined queries can be published and invoked by user agents that are permitted to do so. Such a facility provides a simpler means of searching the registry, since detailed knowledge of the underlying information model is not required; this is in contrast to building an ad hoc query with multiple filter criteria. Furthermore, a stored query can be invoked by simply submitting a GET request to the GetRecords endpoint. A stored query may accept parameters that act as filter criteria or affect the presentation of the search results. The parameters are included in the query component of the target URI in the usual manner.

The Basic EP defines several stored queries that are publicly accessible. For example, the findServices query accepts a serviceType parameter that identifies a service type in the ISO 19119 geographic services taxonomy. The GET request in the following listing returns a list of all OGC WFS 2.0 services.

Anyone may invoke a publicly accessible stored query (showStoredQueries returns a list of these). A registered user may define a stored query and choose to label it as private, in which case it may only be invoked by the owner.

The OGC filter grammar [9] allows a wide variety of queries to be expressed, including ones that involve multiple registry object types that are interrelated in some manner. Examples of some common requests are listed below; these are all GetRecords requests that contain compound filter predicates.

The following listing is a request to find data sets by area of interest. The BBOX predicate specifies a GML envelope that defines a bounding box. The relevant registry object property is a slot having the name "http://purl.org/dc/terms/spatial"; such a slot (defined in the "Basic" package) may be used to express a spatial extent using a GML geometry representation.

A more complicated query is shown below. It seeks to find WFS services that offer data in some area of interest. Note that several PropertyIsEqualTo predicates serve to filter for Service objects related to the matching Dataset objects by the "OperatesOn" association.

Service descriptions are harvested in the form of service capabilities documents presented by all OGC services. A WFS advertises the spatial extent of available feature types as indicated in the following listing. The ows:WGS84BoundingBox element specifies a bounding box in the WGS 84 coordinate reference system (with non-standard axis order longitude, latitude).

In this instance the spatial extent covers almost the entire surface of the planet; it nearly coincides with the valid area for the coordinate reference system. If feature data are not in fact available throughout such a large area, a client may be (mis)lead into searching for data where none exist. That is, a catalog search may produce a "false positive" that will yield nothing when querying a data access service. When confronted with such a default setting that is unlikely to be correct, a "dynamic" catalog might periodically query the data service in order to automatically refresh the corresponding registry item(s). This is an option that was considered during the testbed but was not implemented.

The concept of a SWIM Common Registry (SCR) is driven by the desire to share service-related information among SWIM communities that implement registries according to their needs and local requirements. Relevant information assets include:

The common information model is SDCM, a high-level view of which is shown below. The three top-level elements of a service description are broken down into their constituent parts in a platform-independent manner. That is, the model is agnostic with respect to particular technology choices.

A common interface will enable interworking within and between SWIM communities. Work in this area is ongoing, but it is worth considering whether existing interfaces might be adopted in whole or in part.

The integration of OGC® catalog functionality into SWIM registries is not an "all or nothing" proposition. Several options are explored that entail varying degrees of effort: