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.
Introduction
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:
- https://reference.swim.aero/technical-infrastructure/guidance-for-pub-sub-push-implementation.html
- https://reference.swim.aero/technical-infrastructure/binding-selection-guidelines.html
The issue of topics has been discussed in the FAQ. See:
Documenting its use
The overall approach
SWIM-SERV-120 Service standard reference
Name for WFS or AMQP could be harmonised (e.g. Web Feature Service 2.0, OGC Filter Encoding 2.0).
SWIM-SERV-140 Service functions
The functionality name could be somehow harmonised for AMQP services or a general term, because it delivers always data.
SWIM-SERV-240 Service interfaces
Name and description could be harmonised e.g. AMQP Notification, AMQP Subscription WFS Request, REST Request.
SWIM-SERV-250 SWIM TI Profile and interface bindings
The best practice could be a link to an existing standard (e.g. OGC WFS 2.0, OGC WCS 2.0.1) or specifications to header/content-type information (e.g. AMQP header information to encoding, message-annotation etc.)
SWIM-SERV-270 Service operations
A harmonised entry for AMQP delivery or reference to the WFS operations e.g. WFS getFeature. Consider a controlled vocabulary of verbs for names.
SWIM-SERV-280 Service messages
An example for an AMQP1.0 message payload can be given, e.g.
"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/"
}
}],
...
}]