Introduction

This page highlights how to document the use of standardised implementations in a service description.

The overall approach

There is no need to rewrite the standards. For example, there is no need to document the operations defined by the standard. It is preferable to refer to where they are documented.

Definition

Standardised implementation. An implementation of a system or service that conforms to a standard.

Example standardised implementions

The standardised implementations discussed in this section conform to the SWIM TI YP Specification.

OGC Standards

Service implementations can use the Open Geospatial Consortium (OGC) standards. These include a suite of service standards detailed at https://www.ogc.org/docs/is, including:

Web Feature Service (WFS) for direct fine-grained access to geographic information at the feature and feature property level.
- WFS includes transactional operations that allow changes to be made to a feature instance over WFS.
- OGC Web Feature Service (WFS) Temporality Extension for the AIXM 5 temporality extensions of the WFS 2.0 and FES 2.0 standards.
Web Map Service (WMS) for requesting geo-registered map images from one or more distributed geospatial databases.
Web Coverage Service (WCS) for accessing multi-dimensional coverage data over the Internet.

The standards contain e.g.

defined functionality
defined operations e.g. WFS's GetCapabilities (discovery operation)
characteristics e.g. feature access service

In addition, other standards are of relevance such as:

Filter encoding standard that details a system neutral syntax for expressing projections, selection and sorting clauses collectively called a query expression.

AMQP v1.0

Service implementations can use the Advanced Message Queuing Protocol (AMQP) v1.0 international standard. This is available at https://www.amqp.org/.

It is discussed in connection with the EUROCONTROL SWIM TI Yellow Profile Specification on the SWIM reference website. See:

The issue of topics has been discussed in the FAQ. See:

How do I define the list of topics for use in AMQP1.0?

Services with multiple interfaces

The standards can work together in a single service. It is possible to have two (or more) service interfaces in the same service. For example:

an AMQP 1.0 message may contain a link to data to be accessed via a WFS
a subscription service may be used and notification added to a message queue using AMQP
a notification may embed a link to a URL using a RESTful approach.

Relevant requirements

SWIM-SERV-100 Service categories

The following example shows how to add a service categorisation for a Web Feature Service.

The URL used in the example does not exist yet. It is waiting for the service category page to be updated.

Example of SWIM-SERV-100 using Service Metadata Schema

"serviceCategorisation": {
 "other": [{
  "name": "SERVICE_TYPE",
  "value": "FEATURE_ACCESS_SERVICE",
  "categorisationScheme": {
   "url": "http://reference.swim.aero/information-services/service-categories/CodeServiceType"
  }
 }]
}

SWIM-SERV-120 Service standard reference

There is no need to mention the use of the OGC standards or AMQP 1.0 as part of SWIM-SERV-120 Service standard reference. It allows the link to be made to the service definitions produced by the various ATM communities.

However, a service standard listed as part of SWIM-SERV-120 may include requirements on the use of OGC standards or AMQP 1.0. In that case, any deviations from the service standard should be noted - see the SWIM-SERV-120 Service standard reference page for an example of this.

SWIM-SERV-210 Application message exchange pattern

Guidance on the selection of the application message exchange pattern can be found on the SWIM reference resource pages.

In general:

Web Feature Services use one of the REQUEST-REPLY options that are mention in the CodeApplicationMessageExchangePatternType scheme.
Service that are built around AMQP 1.0 use the PUBLISH-SUBSCRIBE options.

SWIM-SERV-250 SWIM TI Profile and interface bindings

The following example shows how to document the use of WFS as part of the serviceInterfaceBinding. This approach means that the operations do not need to be documented.

Example of SWIM-SERV-250 using Service Metadata Schema

"serviceInterface": [{
 "serviceInterfaceBinding": {
  "name": "SWIM_TI_YP_1_1_WS_LIGHT",
  "description": "The OGC Web Feature Service 2.0 Interface Standard is used in the service implementation. The standardised operations for a Basic WFS are implemented."
 }
}

The following example shows how to document the use of AMQP 1.0 as part of the serviceInterfaceBinding.

Example of SWIM-SERV-250 using Service Metadata Schema

"serviceInterface": [{
 "serviceInterfaceBinding": {
  "name": "SWIM_TI_YP_1_1_AMQP_MESSAGING",
  "description": "AMQP 1.0 is used in the service implementation."
 }
}

SWIM-SERV-270 Service operations

The listing of operations is optional so reference to the OGC standard used can be made in the description of the service interface or in the service interface binding (see above).

SWIM-SERV-280 Service messages

The following example shows how to document the service message for AMQP 1.0. It provides two messages: the first contains the data, the second contains a link to the data.

Example of SWIM-SERV-280 using Service Metadata Schema

"serviceInterface": [{
 "messages": [{
  "name": "AMQP message body",
  "description": "The AMQP message body contains the OPMET data in IWXXM3.0.",
  "schema": {
   "url": "https://schemas.wmo.int/iwxxm/3.0.0/"
  },
  {
  "name": "AMQP message body",
  "description": "Deliver a notification message including a download URL.",
  "schema": {
   "url": "https://myNotificationSchema.json"
  }
 }],
...
}]

SWIM-SERV-310 Filter encoding

The following example shows how to refer to the OGC Filter Encoding Standard.

Example of SWIM-SERV-310 using Service Metadata Schema

"informationDescription": {
 "filtering": {
  "capability": [{
   "name": "OGC Filter Encoding 2.0 Encoding Standard",
   "description": "The service implements the OGC Filter Encoding 2.0 Encoding Standard.",
   "reference": {
    "url": "https://www.ogc.org/standards/filter"
   }
  }]
 }		
}

Adding references

The Service Metadata Schema has a convenience construct, not tied to any requirement, to include relevant references.

The following example shows how to add WFS in the list of references.

Example of references using Service Metadata Schema

"references": {
 "serviceDocument": [{
  "documentType": "SERVICE_SPECIFICATION",
  "title": "OGC Web Feature Service",
  "version": "2.0",
  "description": "Interface Standard for direct fine-grained access to geographic information at the feature and feature property level.",
  "reference": {
	"url": "https://www.ogc.org/docs/is"
  }
 }
 ]
}

The following example shows how to add AMQP 1.0 in the list of references.

Example of references using Service Metadata Schema

"references": {
 "serviceDocument": [{
  "documentType": "PROTOCOL_SPECIFICATION",
  "title": "Advanced Message Queuing Protocol (AMQP)",
  "version": "1.0",
  "description": "The Advanced Message Queuing Protocol (AMQP) is an open internet protocol for business messaging.",
  "reference": {
	"url": "https://www.amqp.org/"
  }
 }
 ]
}

Browser not supported