Temporality and Uniqueness Digital NOTAM

54 Copyright © 2011 Open Geospatial Consortium, Inc. All Rights Reserved. or updated due to informational errors. This was one of the encoding recommendations of the OWS-7 Aviation Architecture Engineering Report OGC 10-079 and has also been documented as a recommendation in the OWS-8 Report on Digital NOTAM Event Specification OGC 11-092.

9.1.1.2 Spatial Extent

Similar to the previous testbeds the geometries of AIXM features are – besides their actual spatial extent – encoded using the gml:boundedBy element. As most of AIXM features have a specific or potentially no geometry at all, the workaround as established in OWS-6 and OWS-7 has been used in this testbed as well. Here, bounding boxes have been created by the service provider explicitly and included in the DNOTAM. The bounding box was then used for spatial filtering. The WFS data stores are responsible for computing the relevant geometry for every feature to enable spatial filtering of digital NOTAMs using the Event Service. There are several issues e.g. collections of or multiple geometries per feature; as discussed in OGC 10-079 which have not been addressed during this testbed. For most cases spatial filtering is performed using the computed bounding box e.g. of an Airspace or special geometry forms such as DirectPositions e.g. aixm:ElevatedPoint for a Navaid of an AIXM feature.

9.2 Web Service Notification and SOAP

For transmission of Events the WS-N communication patterns are used. This results from the fact that the Event Service – acting as an intermediary component for data filtering see section 7.4 – is based on the OASIS Web Services Notification WS-N standards family. SOAP version 1.2 was applied as the protocol binding for the involved WS-N components. Within this testbed version SOAP 1.2 has been used in combination with WSDL 1.1 descriptions of the Event Services to enable SOAP bootstrapping see section 10.2.2. WS-N defines a set of roles for components of a distributed service architecture and message protocol. In particular, these roles are Publishers, NotificationProducers, NotificationConsumers and NotificationBrokers which are briefly described in the following: - A Publisher is responsible for formatting a Notification and disseminating it to a NotificationProducer - A NotificationConsumer must provide an interface for receiving NotificationMessages - A NotificationProducer must provide an interface for subscribing to a subset of messages and must be capable to deliver these subsets of NotificationMessages to the subscribing NotificationConsumer - A NotificationBroker combines the tasks of a NotificationProducer and a NotificationConsumer and acts as an intermediary distributor. The message protocol defines a NotificationMessage carrying the contents of an event such as a DNOTAM in a dedicated message element. Examples of requestresponse communication as well as push-based communication are presented in the following section. Copyright © 2011 Open Geospatial Consortium, Inc. All Rights Reserved. 55 A NotificationMessage can also define a topic for its contents. The Event Architecture makes use of these topics for grouping similar events as recommended in the OWS-7 Aviation Architecture Engineering Report OGC 10-079. The following topics also called channels were used in the testbed: dNOTAM-Events AircraftPositionUpdates. Thus, a NotificationConsumer can easily subscribe for a subset of similar events disseminated on the same channel.

9.3 Eventing Components and Dataflow

This section describes the components involved in the event architecture and their roles in detail. In general, the architecture can be separated into three tiers as done in chapter 5. The Event Architecture only uses the Event Services for processing and disseminating DNOTAM data. Their role can be summarized as an information broker within the general OWS-8 Aviation Architecture. Figure 20 – Components involved in OWS-8 Eventing Figure 20 depicts the components used in the eventing parts of OWS-8 based on the corresponding figure in chapter 5. Figure 21 gives a high-level overview on the interaction patterns between the components.