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