SANY D2.3.4 Specification of the Sensor Service Architecture V3 Doc.V3.1
Copyright © 2007-2009 SANY Consortium Page 62 of 233
The third type of event occurs when some state has changed in the sensor or service network configuration e.g. addition of a new sensor or sensor service instance or some
unforeseen behaviour has been detected. The latter situation usually results in an exception on the software level. If deemed essential by the software engineer, such exceptions may be
escalated to other components in the form of events.
In the context of the SensorSA, all event types are handled equally. The event type is transparent to the receiver of an event notification. It is created by the event observer and
published or transferred to notification consumers. Still, the SensorSA addresses a very heterogeneous environment with sensors and
services provided by a number of institutions and organisations. The event-based architectural style of the SensorSA defined below takes these aspects into account.
6.4. Event-based Architectural Style
SensorSA defines different architectural styles that could be applied to the Sensor Web. The goal is to harmonize the various styles in order to facilitate a successful integration of
different approaches in a single application. In the following, we define the Event-based Architectural Style. It is based on the existence of events that get communicated between
various components within the Sensor Web.
Note: The SensorSA Event-based Architectural Style was developed in close cooperation with the Sensor Web Enablement Team of OGC to ensure a sustainable solution
beyond the lifetime of the project SANY. The goal was to develop a general Event-based architectural style to be applied to Sensor Web applications. The results of this activity are
published as OGC Engineering Report Everding and Echterhoff Eds., 2009. With over 150 pages in length, this report goes beyond the scope of the SensorSA core document. Thus, we
make do with an excerpt of the main findings at this stage and refer to the publicly available OGC report.
6.4.1 Event Definition
The ISO 19100 series of standards, which are, as leading standards in the geospatial IT domain, of overall importance to the SensorSA, provide two definitions of the term “event”.
Common to both definitions is the refe rence to an “action”. It is therefore in line with the
rather philosophic definitions such as the one provided by the Oxford English Dictionary, which defines an event as “something that happens or is thought of as happening”. In terms of
our application domain, this leads to the rather problematic situation that the event is equated with the action itself, thus the event becomes an abstract, non-computable thing:
-
ISO 19136: An event is “an action that occurs at an instant or over an interval of time.”
-
ISO 19108: An event is “an action that occurs in an instant, an instant being a zero-
dimensional geometric primitive representing position in time” Common to both terms is the reference to an action that occurs. The relation to a time
instant versus a time interval manifests the crucial difference. According to ISO 19108, only
SANY D2.3.4 Specification of the Sensor Service Architecture V3 Doc.V3.1
Copyright © 2007-2009 SANY Consortium Page 63 of 233
those actions qualify as events, that postulate changes, e.g. “it started raining at 20:00hrs CET”. Observations like “it rains” or “it rained from 2AM to 4PM” don‟t qualify as events
c onsequently. The definition in ISO 19136 is more relaxed. Here, both “it started raining at
20:00hrs CET” as well as “it rained from 2AM to 4PM” do qualify as events, only “it rains” does not. The latter would be called a “state” in ISO 19136.
In SensorSA, we adopt the definition of Luckham and Schulte Eds. 2008 and combine it with the definition of ISO 19136 in order to be consistent with ISO TC 211
nomenclature. Thus the term event is defined as follows:
-
An event is anything that happens or is contemplated as happening at an instant or over an interval of time.
This definition emphasizes the fact that an event has a strong temporal aspect and may represent anything that happens in the real world but can as well be simulated or happen in
software. The term happening encompasses action, occurrence and situation of interest, state change
etc. which all represent something that happens. To ensure better alignment with the domain of interest, i.e. information and
communication technologies, we introduce further the term event object:
-
An event object represents, encodes, or records an event, generally for the purpose of computer processing,
Thus, not the happening itself, but a record that signifies the happening is considered to be an event object. The happening of interest is sometimes referred to as action or activity.
This action remains an action until something observes it and generates an event object that reifies it. We emphasise that event processing literature often does not distinguish between an
activity that takes place and an object that represents that activity for the purpose of computer
processing. This causes an overloading of the word “event”, which takes both meanings. An event can be generated at any time during an observation. Given the sensor model as
described in 5.2, an event can be produced at any stage during the observation process, i.e. from or after the first observation of an environmental property throughout all processing
steps until the final observation is delivered as output of the sensor or sensing system. The event time will be assigned by the observation provider and equals the sampling time of the
observation. The event model, which will be described in the next section, will elaborate the temporal aspects of events.
6.4.2 Event Model
