General description
The ASMtoASM Service is designed to support data exchange directly between any two ASM Support Systems both within and across FAB boundaries. Such an exchange is shown above between ASM Support System 1 and ASM Support System 2 and between ASM Support System 2 and ASM Support System 3. Additionally, the interface can be used by any client of an ASM Support System to exchange data. This is again shown above with the ASM Service Client making requests of ASM Support System 1 and ASM Support System 3. The ASM support systems both connect to each other acting as both a client and a server to the other, whereas the clients only connect directly to their own ASM support system. Data flow between the client and server is bidirectional.
ASM Support System - ASM Support System
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 create and edit 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.
External ASM User - ASM Support System
In this configuration an External User is authenticated itself as a specific user of the ASM Support System resulting in a series of privileges to view and create data in the same way as a standard user of the ASM Support System.
This configuration is applicable for external client tools of the ASM Support System that belong to the same state as opposed to the above ASM Support System – ASM Support System relationship which supports users from different states. Here the focus is on the option of the service to be used by any ASM Service Client that is not a client to the ASM Support System, e.g. a mission management system could be a client to the ASM Support System. In this context, the presumption is that both ASM and MMS are belonging to the same state.
It is anticipated that, for example, the creation of mission data within the ASM Support System may not generally be available to another ASM Support System but a privileged user may be allowed to access the functionality through this interface. This differentiation in privileges is the responsibility of the ASM Support System providing the service and not managed directly through the service interfaces.
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 may be implemented using AMQP to support coordination between two ASM Support Systems 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 two established ASM Support Systems 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 ASMtoASM 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 may be implemented by both Request/Reply and Publish/Subscribe mechanisms through a combination of the following filter criteria for each ASMtoASM Service Interface:
o Activity,
o Airspace,
o Change Period,
o Geometry,
o Interested Interval,
o 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 this 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 this document. It has to be noted that only the filters defined in the 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 ASMtoASM service interfaces specified in this document shall implement a filtering functionality both for Synchronous Request/Reply and Publish/Subscribe Push application message exchange patterns.