Ongoing discussions within the SWIM communities of interest

Page tree

Ongoing discussions within the SWIM communities of interest

Skip to end of metadata
Go to start of metadata

Task Status

This page is part of the ongoing SWIM communities of interest discussions. The content is working material. It should not be treated as final as it is still subject to review, comment and change.


Definition

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

Introduction

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

Example standardised implementions

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.
  • 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:

Documenting their use

Document what is deployed

Service descriptions describe implemented information services. Therefore, a service description documents the names of services, interfaces and operations as they have been implemented. Considerations on the naming conventions are dealt with as part of Service Design Activities.

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.

Relevant requirements

SWIM-SERV-100 Service categories

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

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-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 including all standardised operations."
 }
}

The best practice could be a link to ... specifications to header/content-type information (e.g. AMQP 1.0 header information to encoding, message-annotation etc.)

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 the 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. That requirement 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.

The following example shows how to document the use of 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 document the use of 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/"
  }
 }
 ]
}

Composite services

The standards can work together in composite services. For example, an AMQP 1.0 message may contain a link to data to be accessed via a WFS.

Is it possible to add some guidance on this. Bring REST into the picture as well.

For example, will AMQP 1.0 and WFS be two interfaces in one service.



  • No labels