Testbed-12 Asynchronous Messaging for Aviation

Publication Date: 2017-04-25

Approval Date: 2016-09-13

Posted Date: 2016-08-29

Reference number of this document: OGC 16-017

Reference URL for this document: http://www.opengis.net/doc/PER/t12-E003

Category: Public Engineering Report

Editor: Matthes Rieke, Aleksandar Balaban

Title: Testbed-12 Asynchronous Messaging for Aviation

OGC Engineering Report

COPYRIGHT

WARNING

This document is an OGC Public Engineering Report created as a deliverable of an initiative from the OGC Innovation Program (formerly OGC Interoperability Program). It is not an OGC standard and not an official position of the OGC membership.It is distributed for review and comment. It is subject to change without notice and may not be referred to as an OGC Standard. Further, any OGC Engineering Report should not be referenced as required or mandatory technology in procurements. However, the discussions in this document could very well lead to the definition of an OGC Standard.

LICENSE AGREEMENT

Permission is hereby granted by the Open Geospatial Consortium, ("Licensor"), free of charge and subject to the terms set forth below, to any person obtaining a copy of this Intellectual Property and any associated documentation, to deal in the Intellectual Property without restriction (except as set forth below), including without limitation the rights to implement, use, copy, modify, merge, publish, distribute, and/or sublicense copies of the Intellectual Property, and to permit persons to whom the Intellectual Property is furnished to do so, provided that all copyright notices on the intellectual property are retained intact and that each person to whom the Intellectual Property is furnished agrees to the terms of this Agreement.

If you modify the Intellectual Property, all copies of the modified Intellectual Property must include, in addition to the above copyright notice, a notice that the Intellectual Property includes modifications that have not been approved or adopted by LICENSOR.

THIS LICENSE IS A COPYRIGHT LICENSE ONLY, AND DOES NOT CONVEY ANY RIGHTS UNDER ANY PATENTS THAT MAY BE IN FORCE ANYWHERE IN THE WORLD. THE INTELLECTUAL PROPERTY IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE, AND NONINFRINGEMENT OF THIRD PARTY RIGHTS. THE COPYRIGHT HOLDER OR HOLDERS INCLUDED IN THIS NOTICE DO NOT WARRANT THAT THE FUNCTIONS CONTAINED IN THE INTELLECTUAL PROPERTY WILL MEET YOUR REQUIREMENTS OR THAT THE OPERATION OF THE INTELLECTUAL PROPERTY WILL BE UNINTERRUPTED OR ERROR FREE. ANY USE OF THE INTELLECTUAL PROPERTY SHALL BE MADE ENTIRELY AT THE USER’S OWN RISK. IN NO EVENT SHALL THE COPYRIGHT HOLDER OR ANY CONTRIBUTOR OF INTELLECTUAL PROPERTY RIGHTS TO THE INTELLECTUAL PROPERTY BE LIABLE FOR ANY CLAIM, OR ANY DIRECT, SPECIAL, INDIRECT OR CONSEQUENTIAL DAMAGES, OR ANY DAMAGES WHATSOEVER RESULTING FROM ANY ALLEGED INFRINGEMENT OR ANY LOSS OF USE, DATA OR PROFITS, WHETHER IN AN ACTION OF CONTRACT, NEGLIGENCE OR UNDER ANY OTHER LEGAL THEORY, ARISING OUT OF OR IN CONNECTION WITH THE IMPLEMENTATION, USE, COMMERCIALIZATION OR PERFORMANCE OF THIS INTELLECTUAL PROPERTY.

This license is effective until terminated. You may terminate it at any time by destroying the Intellectual Property together with all copies in any form. The license will also terminate if you fail to comply with any term or condition of this Agreement. Except as provided in the following sentence, no such termination of this license shall require the termination of any third party end-user sublicense to the Intellectual Property which is in force as of the date of notice of such termination. In addition, should the Intellectual Property, or the operation of the Intellectual Property, infringe, or in LICENSOR’s sole opinion be likely to infringe, any patent, copyright, trademark or other right of a third party, you agree that LICENSOR, in its sole discretion, may terminate this license without any compensation or liability to you, your licensees or any other party. You agree upon termination of any kind to destroy or cause to be destroyed the Intellectual Property together with all copies in any form, whether held by you or by any third party.

Except as contained in this notice, the name of LICENSOR or of any other holder of a copyright in all or part of the Intellectual Property shall not be used in advertising or otherwise to promote the sale, use or other dealings in this Intellectual Property without prior written authorization of LICENSOR or such copyright holder. LICENSOR is and shall at all times be the sole entity that may authorize you or any third party to use certification marks, trademarks or other special designations to indicate compliance with any LICENSOR standards or specifications.

This Agreement is governed by the laws of the Commonwealth of Massachusetts. The application to this Agreement of the United Nations Convention on Contracts for the International Sale of Goods is hereby expressly excluded. In the event any provision of this Agreement shall be deemed unenforceable, void or invalid, such provision shall be modified so as to make it valid and enforceable, and as so modified the entire Agreement shall remain in full force and effect. No decision, action or inaction by LICENSOR shall be construed to be a waiver of any rights or remedies available to it.

None of the Intellectual Property or underlying information or technology may be downloaded or otherwise exported or reexported in violation of U.S. export laws and regulations. In addition, you are responsible for complying with any local laws in your jurisdiction which may impact your right to import, export or use the Intellectual Property, and you represent that you have complied with any regulations or registration procedures required by applicable law to make this license enforceable.

Table of Contents

1. Introduction
2. References
3. Terms and definitions
- 3.1. SESAR SWIM-TI and OGC PubSub Taxonomy
4. Conventions
- 4.1. Abbreviated terms
5. Overview
6. Related Technological Standards
7. Current State of Asynchronous Messaging
- 7.1. Federal Aviation Administration
  - 7.1.1. SWIM Architecture
  - 7.1.2. SWIM in Production
- 7.2. Previous OGC Work
8. Requirements
- 8.1. Problem Statements
9. Solutions
- 9.1. Targeted Solutions
- 9.2. Recommendations
  - 9.2.1. OGC PubSub for Asynchronous Messaging
  - 9.2.2. AMQP 1.0 Data Dissemination
10. Architecture
11. Implementations
12. Conclusions
- 12.1. Accomplishments
Appendix A: Asynchronous Messaging Server Capabilities Document
Appendix B: AIXM DNOTAM Document
Appendix C: FIXM Flight Document
Appendix D: Revision History
Appendix E: Bibliography

Abstract

The Asynchronous Messaging for Aviation Engineering Report (ER) focuses on the design of an architecture to create an Publish/Subscribe (PubSub) messaging layer between different Aviation components such as clients, data provider instances and Data Brokers. In order to achieve interoperability among these components, the OGC PubSub 1.0 standard forms the basis of this architecture. The design of this architecture will cover methods for subscribing for specific subsets of data (e.g. Flight Information Exchange Model (FIXM) Flights intersecting a given Airspace), managing such subscriptions as well as publishing data to the Asynchronous Messaging Server. Different delivery methods such as Advanced Message Queuing Protocol (AMQP) 1.0, Java Message Service (JMS) and OASIS WS-Notification are considered. In particular, their harmonization with OGC PubSub 1.0 is evaluated.

This report focuses on the interface design required to define an interoperable approach for Aviation using this OGC PubSub 1.0. Specific service level integrations (i.e., Federal Aviation Administration (FAA) System-Wide Information Management (SWIM) and Single European Sky ATM Research Programme (SESAR) SWIM) have been investigated but an implementation has not been fulfilled.

Business Value

Air Traffic Management (ATM) data as well as Flight data changes frequently. In order to achieve an efficient and reliable publication of these changes, a pull-based approach using classical request/response web services is not sufficient.

The design of an asynchronous messaging architecture which is based on the OGC PubSub 1.0 standard and combines industry-established technologies such as AMQP 1.0 and Web Services Notification overcomes this gap and eases integration. By following a standards-based approach, an interoperable solution is available which, besides the Aviation domain, can be easily transferred to other fields that require near-real time, push-based data dissemination.

What does this ER mean for the Working Group and OGC in general

Eventing patterns and asynchronous messaging previously played an important role in OGC Testbed Aviation threads. Architecture patterns similar to the work done in the PubSub WG have been prototypically implemented based on best practices. The PubSub 1.0 standard has been approved by the OGC and an implementation of relevant parts of it will provide a valuable assessment of the design approach of the standard. Besides the implementation, a definition of a profile for aviation could serve as an example on how to integrate OGC PubSub 1.0 into a specific domain.

How does this ER relates to the work of the Working Group

The architecture documented in this ER is one of the first implementations of the OGC PubSub 1.0 standard. Hence, it is of great importance to assess and validate the specification itself, in particular as regards the following aspects:

Extensibility of the PubSub 1.0 specification;
Harmonization of PubSub 1.0 specification, namely the SOAP binding, with AMQP 1.0 as a delivery method;
Integration and backwards compatibility with Harris Data Exchange (DEX) clients supporting the retrieval of data (e.g. AIXM, FIXM) via JMS;
As noted, the ER focuses on the Aviation domain, however a definition of a profile for aviation could serve as an example on how to integrate PubSub into other fields that require near-real time, push-based data dissemination;
Use the OGC Filter Encoding 2.0 language to express subscription filters; and
Plugability of filter languages, e.g. to reference the correct geometry in aviation-specific data formats, via XPath/XQuery, etc.

This ER also contributes to some of the activities in the current scope for the PubSub Standards Working Group (SWG), such as:

Feasibility of adding PubSub capabilities to Web Feature Service (WFS) 2.0 and Web Map Service (WMS) 1.3.0;
Definition of a generic mechanism to reuse service-specific data requests to PubSub-enable the existing Web Services; and
Definition of lexical constants (e.g. "all" to identify all the publications offered by a Publisher).

AMQP is a broadly useful and popular delivery method, and should be considered for standardization in the PubSub SWG. The ER authors are encouraged to bring an AMQP delivery method document to the SWG for consideration and standardization.

Finally, the ER provides useful indications on future lines of work for the PubSub specification, such as:

OGC PubSub 1.0 profile for moving objects;
Specific mechanisms for standardizing delivery methods; and
Analysis on the role of Message Brokers in enterprise production environments (cf. the PubSub Brokering Publisher).

Keywords

ogcdocs, testbed-12, PubSub, Eventing, Aviation, AIXM, AMXM, FIXM, Asynchronous Messaging

1. Introduction

1.1. Scope

Currently, OGC Web Services ^[1] only support synchronous web service request-response query capabilities. This report investigates the means to incorporate asynchronous messaging to OGC Web Services. Asynchronous messaging is a form of message delivery where the provider and consumer can be decoupled (e.g. in time and in terms of knowledge of each other). The recently released OGC Publish/Subscribe specification 1.0 defines a Publish/Subscribe model for OGC Web Services. The work within this testbed applies this specification for the retrieval of aviation data (i.e., AIXM and FIXM) information using geospatial queries and AMQP 1.0 as the underlying messaging protocol. The developed system design, the involved components as well as common workflows are documented.

This report targets the following problem statements.

How to define an OGC compliant web service that allows the management of subscriptions and the corresponding delivery of messages?
What protocols suite best for the dissemination of Aviation data messages from data publishers to client components?
How to define an interoperable solution that meets all requirements in terms of geospatial filtering capabilities, data dissemination and reliability?

In particular, the design and realization of a service architecture based on an implementation of the OGC Publish/Subscribe 1.0 specification (PubSub) in combination with the AMQP 1.0 protocol is illustrated. OGC PubSub 1.0 is a recently published standard which is agnostic of message delivery protocols. This report therefore focuses on the interface design required to define an interoperable approach for Aviation using this standard. Specific service level integrations (i.e. FAA SWIM and SESAR SWIM) have been investigated but an implementation has not been fulfilled. The Future Work section outlines work packages on corresponding efforts.

An in-depth analysis of the existing approaches for asynchronous messaging in Aviation and related available technologies was not the scope of this testbed. In particular, it focused on the prototyping of an OGC based Publish/Subscribe service architecture in correspondence with related message delivery methods and will not provide recommendations beyond this scope.

1.2. Document contributor contact points

All questions regarding this document should be directed to the editor or the contributors:

Table 1. Contacts
Name	Organization
Matthes Rieke (editor, m.rieke@52north.org)	52°North
Aleksandar Balaban (editor, aleksandar.balaban@m-click.aero)	m-click.aero

1.3. Future Work

1.3.1. PubSub-enablement of Data Provision Services

The current architecture uses an OGC PubSub 1.0 standalone publisher for subscription management and data dissemination. OGC PubSub 1.0 also defines an architectural approach that adds Publish/Subscribe capabilities to existing OGC services such as the Web Feature Service. Investigating the feasibility of this approach will be very useful as it may result in a simplified service architecture.

1.3.2. Profile Definition for Geospatial Queries

The current approach developed within this testbed is not fully interoperable with the referenced standards due to the manner in which the geometry part of a message/feature is referenced. The relevant data formats such as AIXM, FIXM and Aerodrome Mapping Exchange Model (AMXM) and their features often contain multiple geometries. It will therefore be of great benefit to define an common approach to define subscriptions with geospatial queries for the Aviation domain. A dedicated profile for OGC PubSub 1.0 could be a reasonable approach. Such a profile would define a solution on how to reference the correct geometry (e.g., via XPath/XQuery or alternatively constant values).

1.3.3. WFS Queries as Subscription Filters

The current architecture only supports filters based on the OGC Filter Encoding 2.0 language. The OGC PubSub SWG has identified the reuse of service-specific data requests as valuable concept for message filtering. Future work could contribute to the SWG by targeting a WFS specific approach. A subscription could be defined using a WFS GetFeature query. A client would then request baseline data from a WFS using a specific query and then simply reuse that query to define a subscription at the Asynchronous Messaging Server. This will ease the integration of the Asynchronous Messaging Server into existing WFS-based architectures.

1.3.4. Integration of FAA SWIM Data Producers

Data producers within FAA SWIM currently provide means for accessing data providing certain business logic (e.g. Stored Queries to access Digital Notice To Airmen (NOTAM) within a 50 miles radius of a specific NAVAID feature). In order to re-use this business logic and to minimize the required systems engineering work dedicated work should be carried out on defining corresponding OGC PubSub 1.0 approaches. The Traffic Flow Management System (TFMS) or the Terminal Flight Data Manager (TFDM) could provide valuable use cases for such integrations.

1.3.5. Network of Messaging Brokers

Productive messaging systems often feature a network of distributed message broker nodes. In order to route messages to the correct destinations additional metadata is required. The current approach utilizes AMQP 1.0 node links to specify the destination. In a complex brokering environment this is not sufficient. Future work should take these systems into account and extend the developed OGC PubSub 1.0 profile with definitions on necessary metadata (e.g. the to property field of an AMQP 1.0 message).

1.3.6. Moving Object Subscription

In OGC Web Services (OWS) Initiative - Phase 8 a scenario has been developed where a spatial subscription was defined in a dynamic way (see [OGC 11-093r2]). The position on the flight route of a given aircraft was used to determine if a message was relevant (if it intersects the remainder of the route). A prototypical design has been developed but no interoperable approach was specified. Such a use case has been identified as a valuable contribution within this testbed. Therefore work on defining an OGC PubSub 1.0 subscription profile for moving objects will be of great benefit for the Aviation domain (especially FIXM Flight object updates are a perfect match).

1.3.7. Integration of Message Broker Software

A deeper analysis of topic- and queue-based delivery patterns which involve Message Broker Software and accordingly the definition of OGC PubSub 1.0 delivery profiles should be investigated. Such Message Brokers play an important role in the establishment of enterprise production environments and are therefore a crucial aspect of asynchronous messaging architectures.

1.3.8. Definition of an ontology for relevant concepts

A specific need has been identified to define an ontology for the consistent use of asynchronous messaging terminology that lie within the scope of this work. It will help to position the relevant specifications (OGC PubSub 1.0, AMQP, OASIS WS-N) and relate it to existing ontologies (e.g. SESAR SWIM Technical Infrastructure).

1.4. Foreword

Attention is drawn to the possibility that some of the elements of this document may be the subject of patent rights. The Open Geospatial Consortium shall not be held responsible for identifying any or all such patent rights.

Recipients of this document are requested to submit, with their comments, notification of any relevant patent claims or other intellectual property rights of which they may be aware that might be infringed by any implementation of the standard set forth in this document, and to provide supporting documentation.

2. References

The following documents are referenced in this document. For dated references, subsequent amendments to, or revisions of, any of these publications do not apply. For undated references, the latest edition of the normative document referred to applies.

OGC: OGC 09-025r2 OGC® Web Feature Service 2.0 Interface Standard - With Corrigendum (2014)
OGC: OGC 09-026r2 OGC® Filter Encoding 2.0 Encoding Standard - With Corrigendum (2014)
OGC: OGC 11-093r2 OWS-8 Aviation Architecture Engineering Report (2011)
OGC: OGC 15-118 IMIS Profile Recommendations for OGC Web Services Engineering Report (planned 2017)
OGC: OGC 13-131 OGC® Publish/Subscribe Interface Standard 1.0 - Core (2016)
OGC: OGC 13-133 OGC® Publish/Subscribe Interface Standard 1.0 - SOAP Protocol Binding Extension (2016)

3. Terms and definitions

For the purposes of this report, the following terms and definitions apply.

Table 2. Terms and definitions
Publish/Subscribe Model	A concept where senders of messages (= publishers), do not send messages directly to specific receivers (= subscribers), but instead publish messages without knowing possible subscribers. Vice versa, subscribers express interest in (a subset of) messages and only receive messages that are of interest without knowing possible publishers. There exist different definitions of Publish/Subscribe. This report re-uses the definition given in the OGC Publish/Subscribe 1.0 specification (section 6.1 of [OGC 13-131]).
Asynchronous Messaging	Describes a communication pattern in which sending entities can deliver in an asynchronous way. No immediate response from the receiving entity is required to continue processing. Receiving entities can pick up messages directly or at a later point in time. This report uses AMQP 1.0 as the protocol for asynchronous message delivery.

3.1. SESAR SWIM-TI and OGC PubSub Taxonomy

SESAR SWIM-TI (Technical Infrastructure) specification document provides its own, exact specification for messaging/communication taxonomy. It defines a vocabulary based on the available sources and the best practices considering the fact that there is no widely accepted, international standardized communication vocabulary.

The SWIM-TI defines the communication concepts through three different kinds of communication participants decoupling, as well as through further two characteristics: the information persistence and the dissemination (discrete/streaming). Further, it specifies a list of message exchange patterns, which are the combinations of decoupling, statements about communication participants, information flow directions and cardinalities.

3.1.1. General communication characteristics

Decoupling

Decoupling describes the degree of loose coupling between the participants. Decoupling is subdivided into 3 dimensions, as follows.

Time: Time decoupling means that the interacting parties do not have to be actively participating at the same time.
Space: Space decoupling means that the interacting parties do not have to know each other.
Synchronization: Synchronization decoupling means that the interacting parties are not blocked and can do other work.

Persistence/transient

In persistent communication, a message that has been submitted for transmission is stored by the communication middleware as long as it takes to deliver it to the receiver. In contrast, with transient communication, a message is stored by the communication system only as long as the sending and receiving applications are executing.

Discrete/streaming

Discrete/streaming describes if a unit of information exchange does contain all relevant data or the relevant data will be transmitted/received in many atomic communication steps.

3.1.2. Message exchange patterns

The SWIM information distribution is realized via the support to specific Message Exchange Patterns (MEP). MEPs are characterized through 4 groups of attributes:

Conversation direction A conversation is a series of related messages. The Conversation direction describes the sequencing and direction of the flow of messages between the interacting parties.

Cardinality describes the number of participants in the exchange of messages.

Decoupling describes the degree of loose coupling between the participants.

Push/Pull indicates whether a subscriber will receive the data at the initiative of the publisher (Push) or whether the subscriber needs to fetch the data (Pull).

The following table represents SWIM-TI message exchange patterns (MEPs), which are directly supported by OGC PubSub 1.0 standard. Additionally, it explains how OGC PubSub 1.0 requirement classes implement SWIM-TI message exchange patterns.

Table 3. Message Exchange Patterns
MEP	Direction conversation	Cardinality	Time Decoupling		Synchronization Decoupling		Space Decoupling
	Consumer=C Provider=P Subscriber=S Publisher=Pu		C / S	P / Pu	C / S	P / Pu	C / S	P / Pu
Observer Push (OPUSH-MEP)	1 way (Pu → S)	1-many	No	No	Yes	Yes	No	No
Observer Pull (OPULL-MEP)	1 way (Pu → S)	1-many	No	No	Yes	Yes	No	No
Publish/Subscribe Push (PSPUSH-MEP)	1 way (Pu → S)	many-many	Yes	Yes	Yes	Yes	Yes	Yes
Publish/Subscribe Pull (PSPULL-MEP)	1 way (Pu → S) Synchronous R/R	many-many	Yes	Yes	Yes	Yes	Yes	Yes

The following MEPs are removed from the original list because they are irrelevant for the communication paradigm explored in this engineering report:

Synchronous Request/Reply (SRR-MEP)
Synchronous Request/Reply (SRR-MEP)
Asynchronous Fire & Forget (AFF-MEP)
Fully Decoupled Request/Reply (FDRR-MEP)

The OGC PubSub 1.0 core specification is organized into requirement classes. Observer patterns are specified in the "Standalone Publisher" requirement class, while the Publish/Subscribe ones are required in the "Brokering Publisher" requirement class.

From the OGC PubSub 1.0 point of view, the Push/Pull MEPs are dependent on the concrete notification delivery implementation and are not part of the core specification. They are rather specified in so called binding documents. For example, the requirements class SOAP Brokering Publisher from OGC PubSub 1.0 SOAP binding document defines a broker middleware component, which sends notifications (publications) to receivers (subscribers) using push delivery method. This MEP corresponds to PSPUSH-MEP from the table above.

3.1.3. Communication roles

The MEPs identify distinct participants in the communication with distinct roles. The classification of roles in SWIM-TI is as follows.

Common roles:

Service provider: A generic role for providing an ATM specific service that can be consumed; and
Service consumer: A generic role for consuming an ATM specific service that is provided.

Roles similar to those used in OGC PubSub 1.0:

Publisher: A publisher produces information that is potentially of interest for a Publication consumer;
Subscriber: A Subscriber subscribes interest for receiving information by a Publication consumer, negotiates the modalities for delivery of this information and manages the lifecycle of the subscription; and
Publication consumer: A Publication consumer receives information for which the Subscriber has subscribed.

Roles irrelevant for this ER:

Publication mediator: A Publication mediator receives the information produced by a Publisher and forwards that information to all Publication consumers for which the subscriptions match the Publication characteristics;
Subscription handler: A Subscription handler interacts with the Subscriber and maintains the subscriptions;
Registration handler: A Registration handler interacts with the Publisher and maintains the registrations;
Fire & Forget Mediator: A Mediator provides time decoupling between client and server in a Fire & Forget MEP; and
Request Reply Mediator: A Mediator provides time and synchronization decoupling between consumer and provider in a fully decoupled Request/Reply MEP.

Opposite to the detailed role schema defined in SWIM-TI, the OGC PubSub 1.0 distinguishes just a several roles for entities participating in information exchange interactions such as: Sender, Receiver, Subscriber, and Publisher.

3.1.4. OGC PubSub 1.0

The OGC PubSub 1.0 standard specification describes an asynchronous communication system based on individual requirements collected into sets called requirement classes. They extend top level major concepts from the core document gradually adding more details. The top level requirement class is called Basic Publisher. It describes a communication between publishers and subscribers without intermediary middleware components and therefore with temporal decoupling only. This schema corresponds to Observer patterns. A subclass class called Brokered Publisher introduces additional requirements for spatial decoupling and therefore corresponds to the Publish/Subscribe patterns.

The OGC PubSub 1.0 specification describes a communication system with obligatory temporal (Standalone Publisher) and optional spatial and synchronization decoupling.

If a system architecture implements OGC PubSub 1.0 Brokering Publisher requirement class, then it has to implement a message broker, which implies the spatial decoupling. The intermediary (middleware) broker component is defined as the "Brokered Publisher" in the OGC PubSub 1.0 terminology.

Synchronization decoupling is not mandatory. It is frequently provided by standard communication software libraries and application architecture implementation models.

The OGC PubSub 1.0 compatible communication system doesn’t explicitly require message persistence. However, the persistence might be specified as part of binding documents. For example, if data delivery shall be implemented using pull style, it automatically imply persistence for messages. Similar is true for discrete/streaming like data dissemination.The requirements are not included into the core specification and might be specified as part of binding specifications.

The push and pull notification/publication delivery approaches are dependent on a concrete implementation and are not part of the core specification. However, the binding documents target on these approaches. For example, the requirements class "SOAP Brokering Publisher" from the SOAP binding document requires a broker middleware component, which sends notifications (publications) to receivers (subscribers) using push delivery method. This MEP corresponds to PSPUSH-MEP from the table above.

4. Conventions

4.1. Abbreviated terms

AIM Aeronautical Information Management
AIXM Aeronautical Information Exchange Model
AMQP Advanced Message Queuing Protocol
API Application Program Interface
ATM Air Traffic Management
CSW OGC Catalogue Service for the Web
DNOTAM Digital NOTAM
EAD Pan-European AIS Database
FAA Federal Aviation Administration
FES Filter Encoding Specification
FIXM Flight Information Exchange Model
GML Geography Markup Language
GUFI Globally Unique Flight Identifier
HTTP HyperText Transfer Protocol
ISO International Standards Organization
NAS National Airspace System
NEMS NAS Enterprise Messaging Service
NOTAM Notice To Airmen
OASIS Organization for the Advancement of Structured Information Standards
OGC Open Geospatial Consortium
OWS OGC Web Service
PubSub OGC Publish/Subscribe 1.0 Specification
QoS Quality of Service
SAA Special Activity Airspace
SESAR Single European Sky ATM Research Programme
SOA Service-oriented architecture
SOAP Simple Object Access Protocol
SWIM System-Wide Information Management
TCP Transmission Control Protocol
WFS Web Feature Service
WSDL Web Services Description Language
WS-N OASIS Web Services Notification
XML Extensible Markup Language

5. Overview

The Engineering Report starts with an overview on the related technological standards (section Related Technological Standards) in which an overview on the AMQP 1.0 protocol, Java Message Service as well as Web Services Notification is provided.

Subsequently an analysis on the current state of asynchronous messaging as well as Publish/Subscribe approaches in the Aviation domain (section Current State of Asynchronous Messaging) is given. Existing solutions in both the FAA and SESAR SWIM architecture are described as well as previous OGC work on event-driven message dissemination.

Section Requirements provides an overview on the requirements for the system architecture. Following the targeted (and discarded) solutions are presented (section Solutions). Sections Architecture and Implementations describe the architecture design and the corresponding implementation.

Finally, the report concludes with a summary of accomplishments and lessons learned (section Conclusions).

6. Related Technological Standards

The technologies and frameworks described in this section are relevant to the design and implementation of a Publish/Subscribe messaging architecture and a corresponding an asynchronous messaging layer for Aviation. Therefore, a brief overview is outlined to provide the necessary context.

6.1. Advanced Message Queuing Protocol 1.0

AMQP 1.0 [2] is a wire-level protocol that was standardized as by OASIS in 2012. There exists another well-adopted version (0-9-1) that is incompatible with AMQP 1.0 and thus will not be introduced in this document.

As mentioned above, AMQP 1.0 is a wire-level protocol and not an Application Programming Interface (API). Therefore, it is a description of the format of the data that is sent across the network as streams of octets as well as concepts such as reliable delivery of messages. It does not define a set of methods on how to interact with a software entity like an API.

AMQP 1.0 defines a set of message-delivery guarantees (as part of its internal "link protocol"):

at-most-once (a message is delivered once or never);
at-least-once (a message is certain to be delivered, but duplicates could occur); and
exactly-once (a message will always certainly arrive without duplicates).

The structure of an AMQP 1.0 bare message is composed of a set of standard properties (id, user, time of creation, subject, etc.), a non-mandatory set of application-specific properties, and the message body. A bare message is considered as immutable, though it can be annotated with additional information (see Figure 1). In particular, the message header is a well-defined set of delivery-related annotations (time to live (TTL), priority, etc.).

Figure 1. AMQP 1.0 Message Format (source: OASIS AMQP 1.0 Specification)

The AMQP 1.0 specification does not define a message broker architecture, e.g., JMS. Therefore a message broker can define interaction patterns in a custom manner. Still, the specification describes the concept of distributions nodes (e.g. queues and topics) that shall follow certain rules (e.g. expiration of messages after their time-to-live (TTL)).

6.2. OASIS Web Services Notification

The OASIS Web Services Notification (WS-N, [3]) family of standards defines a set of web services and their interaction following the Publish/Subscribe pattern and asynchronous messaging (for a definition of these terms see Terms and definitions). WS-N uses the HTTP protocol and SOAP 1.2 as the message layer protocol.

WS-N defines a set of roles for components of a distributed service architecture and message protocol. In particular, these roles are Publishers, Notification Producers, Notification Consumers and Notification Brokers which are briefly described as follows:

a Publisher is responsible for formatting a Notification and disseminating it to a NotificationProducer;
a Notification Consumer must provide an interface for receiving NotificationMessages;
a Notification Producer must provide an interface for subscribing to a subset of messages and must be capable to deliver these subsets of NotificationMessages to the subscribing Notification Consumer; and
a Notification Broker combines the tasks of a Notification Producer and a Notification Consumer and acts as an intermediary distributor.

6.3. Java Message Service

The JMS specifies an API for message exchange between two or more clients. JMS is developed under the Java Community Process ^[2] and is integrated within the Java Enterprise Edition (Java EE).The JMS API implements the Publish/Subscribe pattern and supports both 1-to-1 (queues) and 1-to-n (topic) delivery. As JMS is an API, it is not ensured that different implementors of this API interoperate seamlessly. For example, if a client software wants to interact with a JMS provider, it has to ensure that it includes provider-specific components into the software. This is most often limited to runtime components, therefore the business logic of the client software does not need to be adjusted.

Figure 2. JMS Architecture (source: [1])

JMS defines a set of concepts and roles (see Figure 2) that interact with each other through the API. A Producer publishes messages to Destinations (queues or topics). A Consumer listens on these to receive messages on the other end.

7. Current State of Asynchronous Messaging

Asynchronous messaging (see Terms and definitions) has been implemented in several ways in the Aviation domain. These approaches are often specific to a system (e.g. SWIM and SESAR) and are not designed to be interoperable. This section describes previous efforts of the OGC on an interoperable Publish/Subscribe architecture supporting asynchronous messaging.

7.1. Federal Aviation Administration

In 2007, the FAA established the SWIM Program to implement a set of Information Technology principles in the National Airspace System (NAS) and provide users with relevant and commonly understandable information [5]. The following sections provide an overview of the FAA SWIM platform.

7.1.1. SWIM Architecture

SWIM enables the sharing of information between diverse systems enabling the Next Generation Air Transportation System (NextGen) to deliver the right information to the right place at the right time. To achieve this, SWIM provides the IT Service Oriented Architecture (SOA) enterprise infrastructure necessary for NAS systems to share and reuse information and increase interoperability [6]. SWIM’s approach allows software applications in the NAS to interact with one another through information services that can be accessed without knowledge of an application’s underlying platform implementation. This simplifies interface requirements to existing NAS systems and ensures new systems can be built with minimum technology (hardware, software, and data definition) constraints. SWIM also enables the transition to net-centric NAS operations, and from tactical conflict management to strategic, trajectory-based operations.

At the heart of the SWIM architecture is the NAS Enterprise Messaging System (NEMS). NEMS provides some of the core services under the SWIM program including messaging, service management, service-level security, and mediation services. NEMS provides both asynchronous publish/subscribe and request/reply platforms. For asynchronous publish/subscribe transactions, NEMS uses the ActiveMQ 1.0 protocol as well as JMS. Figure 3 illustrates the JMS flow through NEMS.

Figure 3. NEMS JMS Message Flow

7.1.2. SWIM in Production

The FAA uses SWIM in its production environment [7]. The following list gives some examples of what type of systems use SWIM.

Flight and Flow Data Systems
- Time Based Flow Management System (TBMS): Includes Time Based Metering capability and trajectory modeler, to enhance efficiency and optimize demand and capacity.
- Traffic Flow Management System (TFMS): Data exchange system for supporting the management and monitoring of national air traffic flow. TFMS processes all available data sources such as flight plan messages, flight plan amendment messages, and departure and arrival messages.
- SWIM Terminal Data Distribution Systems (STDDS): Publishes Terminal data to NAS and non-NAS consumers.
- SWIM Flight Data Publication Services (SFDPS): Provides flight data and updates to clients for files and active flight plans.
Aeronautical Data
- Digital NOTAM Service: Publishes NOTAMS in AIXM 5.1.
- Aeronautical Information Management for the Federal NOTAM System (AIM FNS): System-to-system interface that enables end systems to receive digital NOTAMs from FNS.
- Aeronautical Information Management for Special Activity Airspace (AIM SAA): Provides Airport reference and configuration data, definitions and schedule information for Special Activity Airspace (SAA).
Weather Data
- Integrated Terminal Weather System (ITWS) Data Publication: Provides specialized weather products in the terminal area.

7.2. Previous OGC Work

Within the OGC, several approaches have been designed to implement asynchronous messaging patterns. In the following, relevant concepts are outlined.

7.2.1. Event Service

The OGC Event Service has been used from OGC Testbeds 6 to 10 to implement a Publish/Subscribe architecture. It is based on the Sensor Event Service Discussion Paper (OGC 08-133). The design of the service is heavily based on the OASIS WS-N standards and is extensible in terms of filtering capabilities.

A client can define a subscription using the OGC Filter Encoding 2.0 specification [OGC 09-026r2] which is also used by the OGC Web Feature Service 2.0 [OGC 09-025r2] as the primary filtering language. One drawback of the Event Service is the fact that it it requires clients to implement the WS-N Consumer role in order to receive messages asynchronously. It does not allow the definition of alternative dissemination methods (e.g. AMQP 1.0).

The latest state of the Event Service concept has been described in an additional Discussion Paper (OGC 11-088r1).

7.2.2. Web Event Processing Service

Within the OGC IMIS IoT Pilot an event processing architecture which relies on a OGC Web Processing Service (WPS) server has been implemented. Central element is the WPS for Event Processing (Web Event Processing Service, WEPS) which controls the overall workflow (see Figure 4).

Figure 4. Web Event Processing Service (source: [OGC 15-118])

Main tasks of this WEPS are:

Handling and managing client event subscriptions through WPS Execute requests; and
Controlling the event processing module which performs the analysis and pattern matching of incoming sensor data streams against the event pattern rules contained in the event subscriptions.

7.2.3. OGC PubSub 1.0

The OGC Publish/Subscribe Interface Standard 1.0 [OGC 13-131] is a recently released specification that introduces the Publish/Subscribe pattern to the OGC web services world.

Publish/Subscribe 1.0 is an interface specification that supports the core components and concepts of the Publish/Subscribe message exchange pattern with OGC Web Services. The Publish/Subscribe pattern complements the Request/Reply pattern specified by many existing OGC Web Services. This specification may be used either in concert with, or independently of, existing OGC Web Services to publish data of interest to interested Subscribers.

— OGC ® Publish/Subscribe Interface Standard 1.0 - Core

The main concepts of OGC PubSub 1.0 are:

Publications: an implementing service provides information on the data it makes available for subscribing;
Delivery Methods: the technological solution on how messages are transported to subscribers; and
Filtering Capabilities: definition of the way a subscriber can subset data of a publication.

The following role entities are defined:

Publisher: an entity that offers publications to subscribers;
Receiver: an entity that receives messages from senders;
Sender: an entity that sends messages to receivers;
Subscriber: an entity that creates a subscription at a publisher; and
Subscription: an expression of interest in (a subset of) a publication offered by a publisher.

Figure 5. PubSub Workflow (source: OGC 13-131)

A common subscription workflow is illustrated in Figure 5. It shows how the above mentioned entities interact with each other. Within this testbed the following components have been mapped to OGC PubSub 1.0 entities.

Table 4. PubSub Mapping to Aviation components
OGC PubSub 1.0 Entity	Aviation Architecture Component
Subscriber	Aviation Client
Publisher	Asynchronous Messaging Server (using WFS as the backend)
Sender	Asynchronous Messaging Server
Receiver	Aviation Client

Currently only the SOAP Protocol Binding Extension [OGC 13-133] as a protocol-specific realization of OGC PubSub 1.0 is available. Therefore, this binding extensions has been implemented during the testbed.

8. Requirements

Currently, OGC Web Services only support synchronous web service request-response query capabilities. This report is required to define means to incorporate Publish/Subscribe messaging patterns for the retrieval of aviation data (i.e. AIXM and FIXM) information using geospatial queries through an AMQP 1.0 interface. The report shall demonstrate the capability using the recommended approach.

8.1. Problem Statements

Following the above requirements, these problem statements have been identified.

How to define an OGC compliant web service that allows the management of subscriptions and the corresponding delivery of messages?
What protocols suite best for the dissemination of Aviation data messages from data publishers to client components?
How to define an interoperable solution that meets all requirements in terms of geospatial filtering capabilities, data dissemination and reliability?

9. Solutions

The following sections provide an overview of the approaches that have been discussed and implemented during this testbed. The different aspects of the Publish/Subscribe architecture, such as subscription management, publication methods, message delivery, and service orchestration are outlined. Finally, recommendations for the architectural and technological approaches are described.

9.1. Targeted Solutions

9.1.1. Service Architecture

In the analysis and requirements phase of the testbed, it has been identified that OGC PubSub 1.0 (see section OGC PubSub 1.0) and its SOAP binding extension provide a good foundation for the service-based management of subscription and dissemination of corresponding data. The specification defines means to subset data streams (using a filtering language) as well as to disseminate the resulting data streams to a client using a delivery channel of his preference. As OGC PubSub 1.0 has recently been released and fulfills all requirements, this approach has been implemented.
Alternatives such as the OGC Event Service (see section Event Service) have been discussed. The Event Service has been used in previous testbeds' Aviation threads and also provides capabilities to manage subscriptions and subset data streams. The dissemination of data is achieved via HTTP POST requests. The usage of the Event Service has been discarded in favor to a OGC PubSub 1.0 service due to its lack of flexible support of different data dissemination methods.

9.1.2. Data Publication

In order to implement a Publish/Subscribe approach, a data provider (e.g. Web Feature Services, Harris Data Exchange) has to publish (updates to) data in near-real time. To achieve this, several approaches have been discussed.

One approach is to set up a component that regularly queries a Web Feature Service using the same request and compare the response. If a change is observed, the component pushes the change to the Asynchronous Messaging Server. Such intermediary component would be the Publisher within the Publish/Subscribe approach. This approach has been discarded due to the high amount of business logic that would be required to identify updates to data sets. In particular, the underlying Aviation data models such as AIXM 5.1 have complex logic for dynamic features and updates to these.
Alternatively, a WFS could implement a simple push mechanism whenever its data changes (see section Architecture). The WFS would then be the Publisher. This approach has been implemented within the testbed due to successful application in previous testbed and the straightforward realization (see section Patterns for Publishing Data).
OGC PubSub 1.0 defines an architectural approach where existing data provision services can add the OGC PubSub 1.0 interface as an extension to the native service interface. This way, the service would both the Publisher and the Asynchronous Messaging Server. This approach has been discarded as the efforts for adding such functionality to existing Web Feature Services would have exceeded the time frame of the testbed.

9.1.3. Data Dissemination

For the dissemination of data between the data publishers (e.g. Web Feature Services, Harris Data Exchange), the Asynchronous Messaging Server and clients several approaches have been discussed.

OASIS Web Services Notifications (WS-N, see section OASIS Web Services Notification) has been successfully applied in previous testbeds and provides means to ensure reliable message transportation. A client that wants to receive data has to implement the WS-N Consumer role which accepts HTTP POST requests carrying the payload. This approach has been discarded as it has been proved working in previous testbeds already.
AMQP 1.0 (see section Advanced Message Queuing Protocol 1.0) is a modern wire-level protocol designed for asynchronous message exchange. It has built-in support for reliable message delivery, message expiration as well as encryption and authentication. Within this testbed the message delivery using AMQP 1.0 has been chosen and implemented.

9.2. Recommendations

This report focuses on a solution which is based on OGC PubSub 1.0. The architecture and workflow described in the following sections describe the client and server components that implement against the interfaces defined by OGC PubSub 1.0. To accommodate the existing architectures (e.g. FAA SWIM’s "Content Based Router") some dedicated efforts have been made to illustrates the advantages of interoperability (see FAA-specific AMQP 1.0 Profile for OGC PubSub 1.0).

9.2.1. OGC PubSub for Asynchronous Messaging

The central component for this testbeds messaging architecture is a service that implements OGC PubSub 1.0, i.e., its SOAP binding. It provides the means to manage subscriptions, evaluate these against message streams and asynchronously disseminate the messages to clients. Section Workflows and Use Cases describes the design and common workflows.

9.2.2. AMQP 1.0 Data Dissemination

To achieve asynchronous and reliable message delivery the AMQP 1.0 protocol is used (see section AMQP 1.0 Profile for OGC PubSub 1.0). The use of Message Broker software is discussed in section Message Broker Software and has been integrated into the asynchronous messaging architecture (see section Implementations).

10. Architecture

This section provides an overview on both the overall service architecture of the Testbed-12 Aviation thread as well the parts related to the Publish/Subscribe pattern and asynchronous messaging.

10.1. General Testbed Architecture

The overall service architecture for Aviation within Testbed-12 consists of several components that can be separated into three layers.

Data Provider Layer: This layer provides access to aeronautical data (AIXM, FIXM, AMXM) using OGC Web Feature Service 2.0 (WFS) as well as OGC Web Map Service 1.3.0 (WMS) instances.
Broker Layer: The Data Broker service and the Asynch Messaging Server build the broker layer. They act as gateway services to the underlying data providers.
Client Layer: The Aviation Client accesses the aeronautical data by communicating with the services of the broker layer.

An OGC Catalogue Service for the Web (CSW) service allows the client to discover relevant services and is orthogonal to the above three layers. Figure 6 illustrates the Aviation components and their interaction.

Figure 6. Aviation Service Architecture

10.2. OGC Publish/Subscribe Architecture

This document focuses on the requirements and service architecture for the asynchronous messaging parts of the overall architecture. The Asynchronous Messaging Server forms the basis of this system. It implements the OGC PubSub 1.0 specification (manifestation of the its Publisher and Sender entities), allowing clients to subscribe for data using advanced filtering (e.g. spatial queries) as well as data producers to provide access to data in an event-drive fashion.

Figure 7 outlines the components and the interfaces for interaction. For message delivery the AMQP 1.0 wire-level message protocol is used. It provides an interoperable and platform-independent way to disseminate messages.

Figure 7. Publish/Subscribe and Asynchronous Messaging Architecture

Two different architectural solutions have been developed within this testbed. A basic AMQP 1.0 message delivery method and an advanced FAA-specific AMQP 1.0 method that addresses system-specific requirements.

10.3. Workflows and Use Cases

The two different approaches (basic AMQP 1.0, FAA-specific) follow different workflow patterns. The following sections provide an overview on the developed workflows and the participating software components.

10.3.1. Standalone Publisher

Figure 8 illustrates a common service-oriented setup based on OGC WFS data provisioning services. An OGC PubSub 1.0 Standalone Publisher ("PubSub Asynch Server" in the figure) acts as the brokering component (Publisher and Sender entities) in between the data provisioning and the client layer.

Figure 8. Standalone Publisher Workflow

The PubSub Async Server evaluates incoming data based on the subscriptions registered by a client. In the above sequence diagram two WFS services send data updates to the PubSub Async Server via simple HTTP POST Requests. This emulates a PubSub-enabled WFS instance. OGC PubSub 1.0 defines two design patterns: the Standalone Publisher and PubSub-enabled OGC services (see section OGC PubSub 1.0). Due to some restrictions it was not possible during this testbed to develop a PubSub-enabled WFS, thus the emulation using HTTP POST has been established.

10.4. Harris Data Exchange Integration

DEX is a software component that is already in production within the FAA SWIM architecture. It allows the management of subscriptions and the retrieval of data (e.g. AIXM, FIXM) via JMS (see section Java Message Service). It does not support complex filtering (e.g. spatial or content-wise).

To benefit from the complex filtering capability of the PubSub Async Server, an integration pattern has been developed that provides both backwards compatibility for DEX clients and access to complex filtering in an interoperable way.

Figure 9. Harris DEX Workflow

Figure 9 and Figure 7 illustrate the architecture and workflow of this integration pattern. A DEX client simply interacts with the existing DEX subscription management interface. The DEX is then responsible for converting subscriptions into an OGC PubSub 1.0 conforming structure.

As the DEX uses content-based routing (see section Harris Data Exchange) to deliver messages to the corresponding user, the PubSub Async Server includes the relevant information in the AMQP 1.0 message header. The details of this approach are outlined in section FAA-specific AMQP 1.0 Profile for OGC PubSub 1.0.

10.5. Subscribe Patterns

This section provides an overview on the developed patterns for subscribing to asynchronously disseminated messages. The OGC PubSub 1.0 Core Specification and its SOAP binding extension form the basis of the design. In addition, a profile for OGC Filter Encoding 2.0 is presented, which ensures interoperability between clients and service implementations.

10.5.1. OGC PubSub 1.0

The general subscription workflow involves methods for:

creating a subscription;
removing a subscription; and
renewing a subscription (updating the termination time).

The following Listing outlines the common structure of a Subscribe request against a OGC PubSub 1.0 service that implements the SOAP binding extension.

Creating A Subscription

Subscription using AMQP 1.0 Delivery

<?xml version="1.0" encoding="UTF-8"?>
<env:Envelope xmlns:env="http://www.w3.org/2003/05/soap-envelope"
  xmlns:fes="http://www.opengis.net/fes/2.0"
  xmlns:gml="http://www.opengis.net/gml/3.2"
        xmlns:pubsub="http://www.opengis.net/pubsub/1.0"
  xmlns:wsa="http://www.w3.org/2005/08/addressing"
        xmlns:wsn="http://docs.oasis-open.org/wsn/b-2">
   <env:Header>
      <wsa:Action>http://docs.oasis-open.org/wsn/bw-2/NotificationProducer/SubscribeRequest</wsa:Action>
   </env:Header>
   <env:Body>
      <wsn:Subscribe>
         <wsn:ConsumerReference>
           <wsa:Address>http://a.url</wsa:Address>
         </wsn:ConsumerReference>
         <wsn:Filter>
            <wsn:MessageContent Dialect="http://www.opengis.net/fes/2.0">
              ...
            </wsn:MessageContent>
         </wsn:Filter>
         <wsn:InitialTerminationTime>2016-08-18T16:30:00Z</wsn:InitialTerminationTime>
         <pubsub:PublicationIdentifier>AIXM</pubsub:PublicationIdentifier>
         <pubsub:DeliveryMethod>
            <pubsub:Identifier>http://a.delivery.method</pubsub:Identifier>
         </pubsub:DeliveryMethod>
      </wsn:Subscribe>
   </env:Body>
</env:Envelope>

The element wsn:ConsumerReference is used to define the endpoint to where matching messages shall be delivered. This depends on the delivery method chosen for the given subscription: for example a WS-N consumer would provide the WS-N Consumer endpoint that accepts HTTP POST requests, an AMQP 1.0 capable client would specify the node link URL for a topic or a queue.

A Subscriber can use the optional element wsn:Filter/wsn:MessageContent to define filter criteria which subset the stream of data of the targeted Publication. See section Support for Geospatial Queries for details.

The element pubsub:PublicationIdentifier references a valid Publication identifier as discovered in the services Capabilities document (see following section).

The response from the server is structured as follows:

Subscription Response

<?xml version="1.0" encoding="UTF-8"?>
<soap12:Envelope
    xmlns:soap12="http://www.w3.org/2003/05/soap-envelope"
    xmlns:wsn="http://docs.oasis-open.org/wsn/b-2"
    xmlns:add="http://www.w3.org/2005/08/addressing"
    xmlns:pubsub="http://www.opengis.net/pubsub/1.0">
    <soap12:Body>
        <wsn:SubscribeResponse>
            <wsn:SubscriptionReference>
                <add:Address>http://ows.dev.52north.org:8080/subverse-webapp/service</add:Address>
                <add:ReferenceParameters>
                    <wsn:ConsumerReference>
                        <add:Address>http://message.endpoint.url</add:Address>
                    </wsn:ConsumerReference>
                    <pubsub:SubscriptionIdentifier>9d864279-7972-4002-bc7a-b9db9d351a5a</pubsub:SubscriptionIdentifier>
                </add:ReferenceParameters>
            </wsn:SubscriptionReference>
            <wsn:CurrentTime>2016-07-11T09:24:44.206Z</wsn:CurrentTime>
            <wsn:TerminationTime>2016-07-11T09:30:00.000Z</wsn:TerminationTime>
        </wsn:SubscribeResponse>
    </soap12:Body>
</soap12:Envelope>

The wsn:ConsumerReference element carries the information for the AMQP 1.0 node where the client can receive the data. The identifier for later management purposes is provided in the pubsub:SubscriptionIdentifier element.

Removing A Subscription

Unsubscribing a previously created subscription can be achieved by sending the following request:

Removing a Subscription

<?xml version="1.0" encoding="UTF-8"?>
<soap:Envelope xmlns:soap="http://www.w3.org/2003/05/soap-envelope"
    xmlns:wsa="http://www.w3.org/2005/08/addressing"
    xmlns:wsnt="http://docs.oasis-open.org/wsn/b-2"
 xmlns:pubsub="http://www.opengis.net/pubsub/1.0">
    <soap:Body>
        <wsnt:Unsubscribe>
          <pubsub:SubscriptionIdentifier>9d864279-7972-4002-bc7a-b9db9d351a5a</pubsub:SubscriptionIdentifier>
        </wsnt:Unsubscribe>
    </soap:Body>
</soap:Envelope>

The client has to provide the previously received identifier in the pubsub:SubscriptionIdentifier element.

The response from the server is a simple acknowledgment:

Unsubscribe Response

<?xml version="1.0" encoding="UTF-8"?>
<soap:Envelope
    xmlns:soap="http://www.w3.org/2003/05/soap-envelope"
    xmlns:wsn="http://docs.oasis-open.org/wsn/b-2"
    xmlns:pubsub="http://www.opengis.net/pubsub/1.0">
    <soap:Body>
        <wsn:UnsubscribeResponse>
            <pubsub:SubscriptionIdentifier>9d864279-7972-4002-bc7a-b9db9d351a5a</pubsub:SubscriptionIdentifier>
        </wsn:UnsubscribeResponse>
    </soap:Body>
</soap:Envelope>

Publications

The PubSub specification requires that an implementing service provides a set of publications that it supports. In general, these publications are a concept to group similar message into one data stream. A client can then decide if it wants to subscribe to the whole stream of a publication or a subset of it by defining a filter.

The following publications have been defined for this testbed.

Table 5. Testbed-12 Aviation Publications
identifier	abstract
AIXM	Provides AIXM 5.1 data for OGC Testbed-12
FIXM	Provides FIXM 3.0.1 data for OGC Testbed-12
all	Provides all data (root publication)

The available Publications of a service are discoverable via the services Capabilities document. An exemplary document is appended as an Annex (see Asynchronous Messaging Server Capabilities Document) to this report.

10.5.2. Support for Geospatial Queries

To enable geospatial filtering within a subscription, a client has to provide a wsn:Filter/wsn:MessageContent (see above). To streamline the way how spatial queries are implemented across all Aviation services, the Asynchronous Messaging Server also uses the OGC Filter Encoding 2.0 Specification. Similar to WFS services, the PubSub service describes via the Capabilities document which spatial operations it supports.

Filter Encoding 2.0

The following Listing shows an exemplary bounding box filter. It uses the input/geometry value to refer to the geometry of a feature. It is currently the responsibility of the Asynchronous Messaging Server to decide how to resolve the geometry of a feature. This approach limits the interoperability and a future work item addressing this issue is documented in section Future Work.

FES 2.0 Filter for Bounding Box

<fes:Filter xmlns:fes="http://www.opengis.net/fes/2.0"
   xmlns:gml="http://www.opengis.net/gml/3.2">
 <fes:ValueReference>input/geometry</fes:ValueReference>
  <fes:BBOX>
     <gml:Envelope srsName="urn:ogc:def:crs:EPSG::4326">
        <gml:lowerCorner>-33 52</gml:lowerCorner>
        <gml:upperCorner>-32 53</gml:upperCorner>
     </gml:Envelope>
  </fes:BBOX>
</fes:Filter>

supported operators (comparison, spatial, …)
queryables (e.g. for AIXM/AMXM geometries
- XPath, XQuery?

WFS Queries as Subscription Filters

The OGC PubSub SWG has identified the reuse of service-specific data requests as valuable concept for message filtering. A subscription could be defined using a WFS GetFeature query, following an analogue approach in the common request/response pattern. This support WFS Queries has been identified as out of scope for this testbed. Thus, a possible future work item has been identified and documented accordingly (see section Future Work).

10.6. AMQP 1.0 Profile for OGC PubSub 1.0

In order to achieve interoperability for AMQP 1.0 message transportation in combination with OGC PubSub 1.0, a dedicated profile is required. The current standard provides means to extend a service at the required locations. In order to interoperable interact with an OGC PubSub 1.0 service the following extensions are required:

Extend the capabilities DeliveryCapabilities section with an AMQP 1.0 definition;
Extend the Subscribe request with additional required parameters - or describe how to use the existing once; and
Extend the SubscribeResponse with required information on where the AMQP 1.0 messages are delivery - or describe how to use the existing once.

This approach uses AMQP 1.0 node links in order to deliver messages to users. When working with complex brokering architectures (e.g. networks of messages brokers), additional metadata (i.e. the to properties field of an AMQP 1.0 message) is required. An implementation of this was out of scope within this testbed, and is considered for a future work item (see Future Work) has been documented.

10.6.1. Definitions

The profile itself requires a unique identifier. Proposal:

http://www.opengis.net/extension/PubSubAMQP/1.0/amqp10deliveryMethod

A PubSub DeliveryMethod requires and unique identifier and an abstract. Proposal:

Table 6. AMQP 1.0 Profile definitions
identifier	abstract
https://docs.oasis-open.org/amqp/core/v1.0	Advanced Message Queuing Protocol 1.0

An exemplary encoding (following the OGC PubSub 1.0 SOAP Binding) would be:

AMQP 1.0 Profile definitions XML encoding

<pubsub:DeliveryMethod>
    <ows:Abstract>Advanced Message Queuing Protocol 1.0</ows:Abstract>
    <pubsub:Identifier>https://docs.oasis-open.org/amqp/core/v1.0</pubsub:Identifier>
</pubsub:DeliveryMethod>

10.6.2. Exemplary Workflow

The following use cases illustrate possible interaction workflows between client, server and AMQP 1.0 brokers.

Use case 1: Usage of the default AMQP 1.0 broker provided by the PubSub service

The client retrieves the Capabilities via web service request.
Within the capabilities, the client identifies the existence of the AMQP 1.0 delivery method.
The client executes a Subscribe request by providing the AMQP 1.0 delivery method unique identifier and the default broker (as provided by the capabilities).
The server provides a SubscribeResponse with a dynamically created AMQP 1.0 node link that is unique among subscriptions (1-to-1 delivery).
The client connects to the provided AMQP 1.0 node link.
Once the server receives data that matches the subscription it sends this data to the AMQP 1.0 node.
The subscription terminates (e.g. via an Unsubscribe request, or by end of life) - no more data is send to the AMQP 1.0 node.

For step 3, additional information on the default AMQP 1.0 broker has to be provided by the capabilities. Proposal:

DeliveryMethod XML encoding extensions

<pubsub:DeliveryMethod>
    <ows:Abstract>Advanced Message Queuing Protocol 1.0</ows:Abstract>
    <pubsub:Identifier>https://docs.oasis-open.org/amqp/core/v1.0</pubsub:Identifier>
    <pubsub:Extension>
        <amqp:defaultHost>amqp://a.valid.amqp.node.link</amqp:defaultHost>
    </pubsub:Extension>
</pubsub:DeliveryMethod>

This requires a formal definition (e.g. by XML Schema). Proposal:

Namespace: http://www.opengis.net/pubsub/1.0/amqp/v1.0 Elements:

Table 7. DeliveryMethods extension fields
name	example values
defaultHost	ows.dev.52north.org, amqp://myserver.com, amqps://myserver.com

The client shall provide the defaultBroker within the Subscribe request, e.g.:

Use case 1 Subscribe Request

<?xml version="1.0" encoding="UTF-8"?>
<env:Envelope xmlns:env="http://www.w3.org/2003/05/soap-envelope" xmlns:fes="http://www.opengis.net/fes/2.0" xmlns:gml="http://www.opengis.net/gml/3.2" xmlns:pubsub="http://www.opengis.net/pubsub/1.0" xmlns:wsa="http://www.w3.org/2005/08/addressing" xmlns:wsn="http://docs.oasis-open.org/wsn/b-2" xm