General description
The ASM Service is designed to support data exchange between ASM Support Systems and External Users both within and across FAB boundaries.
ASM Support System - External User
In this configuration the ASM Support Systems can each act as a client to each other, though the relationship does not need to be bidirectional. This allows each ASM Support System privilege to distribute general information from the other system to its users. It also allows each ASM Support System to request and modify bookings in the other system and engage in coordination with the other system directly. It is the responsibility of the system providing the services to restrict the data shared with all or each client as appropriate. Equally, it is the responsibility of the client system to ensure booking, creation and editing is granted for the appropriate individual users.
In the case when the External User is an ATC system, the ASM system acts as the provider while the ATC system acts as the consumer. However, the consumer can notify that it has received activation data.
Obtaining up to date data
The interfaces defined within this document are supported by both a Synchronous Request/Reply mechanism and a Publish/Subscribe Push mechanism.
-
Publish/Subscribe Push
The Publish/Subscribe Push mechanism allows a client to subscribe to a topic and receive messages published on that topic. The Publish/Subscribe mechanism is supported by two procedures:
- subscription management: the client creates a new subscription and, in general, a corresponding message queue is allocated to collect messages related to the requested subscription topic. (see SubscriptionManagement interface)
- message consumption: the client consumes the messages from the message queue for the subscription topic. (see Publication interface)
The Publish/Subscribe mechanism is implemented using AMQP to support coordination between ASM Support Systems and External User to exchange the near real-time updates of their ASM data.
-
Request/Reply
The Synchronous Request/Reply mechanism allows a client to request and to receive ASM data. It is used to retrieve the current ASM data of the other system either on the initial connection between ASM Support Systems and External Users or to re-establish synchronisation potentially after one has experienced downtime or due to network failures.
This Request/Reply mechanism may also be implemented by clients that are interested in a small subset of the ASM service where the data is subject to change infrequently or when using latest data is not crucial.
As two ASM Support Systems may not be fully synchronised all of the time, Request/Reply mechanism is implemented to re-establish synchronisation by exchanging the latest snapshot of the available ASM data. The systems are synchronised again and they can continue to be updated by using the Publish/Subscribe mechanism.
-
Filtering
To avoid unnecessary processing of irrelevant messages on the client side some message filtering functionalities have to be implemented by both Request/Reply and Publish/Subscribe mechanisms through a combination of the following filter criteria for each ASM Service Interface:
- Activity,
- Airspace,
- Airspace Name,
- Airspace Feature Type,
- Change Period,
- Geometry,
- Interested Interval,
- Mission.
When using the Publish/Subscribe mechanism, the External User has to set the required message filtering criteria when creating the subscription so that the messages for each type of subscriptions can be filtered before they are published to the message queues allocated to that External User.
The Request/Reply mechanism requires the External Users to set the required message filtering criteria when generating the request.
To allow ASM data requests to be aligned with subscriptions a single abstract Filter definition is available for use by both mechanisms, in that the SubscriptionCreationRequest message is an extension to the basic FilteredRequest message as shown in the diagram below. Consequently, the same Filters can be used when requesting ASM data and subscribing for ASM data to ensure the same data is retrieved via both mechanisms. Specific filter implementations that have been deemed necessary for the services to be usable are defined in the specification document. The available filters may be extended beyond those specified in any implementation of this service. This allows for custom filtering to be defined by a provider of this service while still conforming to the interfaces defined in the specification document. It has to be noted that only the filters defined in the specification document are to be relied upon in order to create an implementation independent client.
The FilteredRequest is used throughout the service interfaces and is extended to form the SubscriptionCreationRequest. The FilteredRequest defines a series of Filters which will be applied using the logical OR operator. Filters may be combined with a logical “AND” using the “AndFilter”.
In the specification document, each service interface defines in detail the Filters it accepts.
ASM-INTF-FIL-010: All ASM service interfaces specified in this document shall implement a filtering functionality both for Synchronous Request/Reply and Publish/Subscribe Push application message exchange patterns.