The dissemination of near-real time data plays an important role in many application domains. This section provides examples where the OGC PubSub Standard has been integrated into existing architectures in order to provide an interoperable solution for the asynchronous delivery of data.
Sensor web
Sensor Web technologies have been driven by the OGC Sensor Web Enablement (SWE) Working Group since more than a decade. The SOS is a well-established interface standard for providing access to timeseries observation data. As it follows the request/reply MEP, the SOS does not provide access to near-real time data. Still, many application domains of the Sensor Web require access to data in an asynchronous way.
Water infrastructure management highly depends on low latency data processing. In particular, the exceedance of critical thresholds of water gauges play an important role in the prevention of flood scenarios. In the past, error prone polling mechanisms using SOS instances have been installed to achieve this goal.
Another example of a Sensor Web application domain is the management of air quality data. Near real-time processing of air quality data has become an increasingly important mechanism to detect critical air pollution situations (e.g. for large cities, see [2]). Sensor Web technologies and in particular PubSub provide the means to deliver such data in time using asynchronous message delivery. This section describes the approach and design of a Sensor Web service architecture that addresses these requirements.
Technological viewpoint
In order to achieve (near) real-time dissemination of observation data, previous Sensor Web service infrastructures have been based on the orchestration of multiple server nodes and intermediary components. The subscription to as well as the delivery of data of interest was realized by either a dedicated service component or a customized workaround. Bröring et al. [5] describe a complex architecture to achieve this functionality featuring OGC service specifications such as SES and Web Notification Service (WNS). In analogy, Fig. 4 illustrates the design of such an architecture.
The architecture is comprised of four service nodes: a SOS that provides access to time series observation data, a SES that provides the possibility to subscribe for specific data and an intermediary component, the SOS-SES Connector. In addition, the WNS has been used to establish the communication between SES and the client. The dissemination mechanism for real-time observation data could be email delivery, HTTP for machine-to-machine communication or for example an instant messaging protocol such as XMPP (Extensible Messaging and Presence Protocol).
The SOS-SES Connector component introduced a fair amount of instability to the system: to manage the retrieval of time series observation data, the component had to persist its state. In particular, it was required to store the timestamps of single observations in order to not retrieve these multiple times and subsequently produce duplicates. The introduction of such business logic made the system error prone, e.g. in situations where the connector’s state could not be persisted and restored after a planned server maintenance. In general, the involvement of such a high amount of service instances implies multiple drawbacks:
-
1.
More web service components have to be maintained, configured and updated
-
2.
every component introduces a possible point of failure
-
3.
the overall system becomes static and prevents extensibility
-
4.
for each service endpoint, a corresponding client and/or management component has to be provided
Real world applications of this architecture pattern have confirmed the above listed aspects. Therefore, the development of the OGC PubSub specification has been highly anticipated in the Sensor Web community as it provides the capabilities to overcome multiple of these concerns. Figure 5 illustrates a Sensor Web architecture that introduces PubSub as a pivotal component.
The SOS service is extended with the PubSub interface in a modular way. All functionality that has previously been realized by SES, the SOS-SES Connector and the WNS is now bundled within the PubSub interface. The client software only communicates with one service instance that provides both SOS and PubSub interfaces.
A PubSub service instance has to provide a set of Publications (see section “Concepts and technologies”) that form the basis for a subscription. In the Sensor Web domain, it has become a common practice to provide the Observation Offerings of the SOS as the Publications offered by the PubSub interface. Observation Offerings bundle the time series data for a given context that is valid for the use case. For example, in a water infrastructure architecture, all measurements of a certain water gauge station are defined as one Observation Offering. A typical client application consists of a mechanism to display time series data for distinct measurement stations (see Fig. 6), i.e. the offering.
The integration of SOS and PubSub by means of the Observation Offering shows great potential for user applications and provides a close link to an existing concept of the SOS. If the user is interested in real-time data by a certain measurement station, he/she can subscribe for the publication that is the same as the offering. An integration within the user interface could be realized via a few controls within the diagram view, e.g. via a button “auto-update” to enable the real-time update of the diagram with new observation data. For such a web-based solution, the Delivery method would be pre-defined to use WebSockets. The web application would act as both the Subscriber and Receiver following the PubSub terminology.
Aviation and air traffic management
This section describes previous and current service architectures in the domain of Air Traffic Management (ATM). Current ongoing initiatives such as the SESAR Joint Undertaking governed by Eurocontrol [10] and the System Wide Information Management (SWIM) NextGen of the Federal Aviation Administration (FAA) project [6] investigate the possibilities to integrate the asynchronous delivery of ATM data. In this scope, several architectures have been developed (mainly within OGC interoperability experiments) to design a possible SOA featuring publish/subscribe capabilities.
Use cases
Base data such as airspaces or scheduled flights are modeled and encoded using the Air Traffic Information Exchange Model (AIXM) and related technologies (e.g. Flight Information Exchange Model, see [9]). Access to this base data is provided via WFS instances. ATM requires to communicate updates on specific features in a fast and reliable way. For example, the runway of an airport could be closed due to bad weather, or an ad-hoc airspace could be defined to ensure the secure deployment of Search and Rescue activities. This information is highly dynamic and therefore requires an approach beyond the request/reply MEP as provided by classic data services like the OGC WFS.
Technological viewpoint
The OGC has driven the development of SOAs in the Aviation and ATM domain since 2008. From the beginning, the push-based dissemination of data has played a fundamental role in the design of systems and its applications. Figure 7 outlines the high-level architecture for asynchronous data delivery of the OGC Web Services Testbed – Phase 9 (OWS-9). The Event Service (ES) takes the role of a middleware component, which manages subscriptions, as well as the corresponding delivery of ATM data to clients.
The WFS instance had to take care to push updated data to the ES instance which then delivered the data to subscribed client components. This architecture showed drawbacks in terms of flexibility and interoperability. In particular, both the client component and the WFS instance had to communicate with the interfaces of the ES. In addition, the ES had to communicate with the WFS in order to enrich data with supplementary information. This was especially the case for AIXM data as updates to features in general only provided the specific updated properties of the feature and not the full representation. Still, the ES might have had to apply a spatial filter as defined in a subscription and therefore had to resolve relevant information in an additional processing step.
Recently, the OGC designed an advanced architecture which features the PubSub Standard as part of the Testbed-12 interoperability experiment (see [9]). Figure 8 illustrates the newly developed architecture. It acts as the intermediary step towards a single-service architecture where both the request/reply access to data and the asynchronous delivery is managed in a single component.
The Asynchronous Messaging Server is an implementation of the OGC PubSub Brokering Publisher conformance class. It is therefore able to manage subscriptions as well as to act as a data broker between different components of the system architecture. AMQP in its version 1.0 has been used as the delivery method. This allowed the integration of existing data delivery components such as the Harris DEX, which is the current implementation of FAA NAS (National Airspace System) Enterprise Messaging Service.
In contrast to the application within the Sensor Web domain, the definition of PubSub publications has been realized in a broader way. As the system architecture was of a prototypical nature, it was sufficient to defined general publications, i.e. one for AIXM data and FIXM data. In production environments, one possibility for a finer-grained set of publications could be a definition based on geographic regions (e.g. “Airspaces in the San Francisco area”). This would fit to most use cases of ATM as a subscription would likely be defined in the scope of a specific flight and therefore would have a predictable spatial extent.