Introduction OGC service specifications related to the Event Architecture
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.
Copyright © 2010 Open Geospatial Consortium, Inc.
111 In 2009 in the OWS-6 testbed the first version of the Event Architecture was developed.
It took the experiences of the work on the SAS and the SES as an input but the focus was not on the development of a service specification. The resulting public engineering report
09-032 describes an abstract event architecture including the definition of important terms, an application schema for events and roles and interfaces for the abstract
architecture. This abstract architecture was also mapped to multiple use cases and OGC services to show how it could be applied. In addition related problems and technologies
are described like common messaging patterns, event processing, acknowledgements of events and canceling of events.
This report represents an extension and enhancement of the OWS-6 event architecture work. It defines the actual publish subscribe functionality in much more detail.
Furthermore it lays the foundation to determine which existing publish subscribe technology should be recommended by the OGC for realizing pubsub in OWS. Based on
this report and the predecessor from OWS-6 and the experiences gained from the SES a new service specification is going to be developed that fulfills the requirements
developed in OWS-7 and which is applicable to all OGC domains. This service specification should therefore not be developed within the SWE initiative. Later on a new
sensor specific service can be designed for instance as SWE profile of the common Event Service.
Also the WNS shall be renewed to be compatible with the Event Service. As it does not serve as a notification broker for events but rather as a protocol transducer e.g. from
HTTP to XMPP and a service for a last mile communication it will most likely remain as a separate service specification.
As shown in Figure 38 the SPS does not have a direct influence on the Event Architecture developments. However, it makes use of notification techniques to notify users about task
states. The resulting connection to the Event Architecture is described in the next section as the SPS uses the SWE Service Model SWES specification for notification handling.