Using Advanced Message Queuing Protocol (AMQP)

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.

Service implementations can use the AMQP standard: See https://www.amqp.org/.

See:
- https://reference.swim.aero/technical-infrastructure/guidance-for-pub-sub-push-implementation.html
- https://reference.swim.aero/technical-infrastructure/binding-selection-guidelines.html

v1.0

See
- https://ext.eurocontrol.int/swim_confluence/display/SWIM/FAQ+-+Service+descriptions+v2.0#FAQServicedescriptionsv2.0-HowdoIdefinethelistoftopicsforuseinAMQP1.0?

Questions to address:

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.

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/"
}
}],
...
}]