Copyright © 2010 Open Geospatial Consortium, Inc.
109 reroute the aircraft or divert to an alternative airport. The according use case is illustrated
in the following figure.
Figure 37: Monitoring flights and detecting relevant aeronautical and weather events
– use case of the OWS-7 Aviation thread
More detailed information about the aviation event architecture can be found in OGC document 10-079.
12 Standards and specifications related to the Event Architecture
12.1 Service models
12.1.1 Introduction
In this section the relations between different service specifications and binding technologies that influence the event architecture or are influenced by the event
architecture are introduced. The goal is to describe the connections between different specifications and to give an overview of the timeline.
12.1.2 OGC service specifications related to the Event Architecture
Here, the timeline and connection between those OGC service specifications is shown that influence the Event Architecture. These services either are designed as a kind of
Event Service like the SAS or SES or they have primarily a different scope but make use of eventing technologies for specific purposes like the SPS. Figure 38 gives an overview
of the timeline and the relations between the Sensor Alert Service SAS, the Sensor Event Service SES, the planned Event Service, the Event Architecture, the Web
Notification Service WNS and the Sensor Planning Service SPS.
110
Copyright © 2010 Open Geospatial Consortium, Inc.
Figure 38: Overview and timeline of the relevant service specifications
The general aim of the Event Architecture work is to develop the theoretical background for an Event Service specification that is applicable in all OGC domains. This includes
for instance requirement analysis, definition of terms, general architecture design but also investigation of possible realization technologies. The latter is discussed in the next
section.
In the way towards an Event Service, the first steps were made in the Sensor Web Enablement SWE initiative with the definition of the SAS and WNS specifications. The
development on these specifications went on until 2007 and resulted in two Best Practices specifications 06-028r3 for the SAS and 06-095 for the WNS. These
specifications were prepared for voting but never entered the voting phase and thus, no SAS or WNS standard was released. One reason for this was the request to make stronger
use of existing standards for instance for the encoding of SAS alerts but also for the service binding.
This led to the development of the SES specification, still within the SWE initiative. Like the SAS, the Sensor Event Service was designed as a broker between notification
producers e.g. sensors and notification consumers e.g. client applications or other services. In contrast to the SAS it reused the Web Services Notification WS-N
standards from OASIS for the definition of the service binding. Necessary OGC and SWE operations like GetCapabilities or DescribeSensor were added on top. Also the
filtering capabilities were redesigned and largely enhanced, allowing to use the OGC Filter Encoding to define the events one is interested in as well as the Event Pattern
Markup Language EML, Discussion Paper 08-132 to perform complex event processing. This service specification was released as an OGC Discussion Paper in 2008
08-133.
