SANY D2.3.4 Specification of the Sensor Service Architecture V3 Doc.V3.1
Copyright © 2007-2009 SANY Consortium Page 69 of 233
represented by a new event and an event object be distributed which relates to the wrong event, which shall be revoked.
How an application reacts when receiving an event that either supersedes or revokes is up to the application and not defined here.
Whenever an event is detected based upon the information contained in other events then there exists a causal relationship between the detected event and the base events. A base
event caused the detected event maybe multiple other events. From the perspective of the detected event, it was causedBy one or more other events. The set of member events that
caused a complex event is sometimes referred to as the causal vector of that event.
6.4.3 Event-Driven Processing System
6.4.3.1 Overview
Event-driven processing systems are applying the event-based architectural style as described above, i.e. they are centred on an asynchronous “push”-based communication model. They
emphasise the basic idea of sense and respond: Sensors observe the current situation and alert receivers upon specific actions. Using techniques such as Complex Event Processing CEP, it
becomes possible to extract the information value of multiple events and data streams and alertnotify interested parties with minimum delay. Due to the permanent sensing, event-
driven processing systems adapt perfectly to a continuously changing environment. Events get detected when they appear. The influence of pre-planned schedules is minimized.
Any event-driven processing system consists at least of two components, 1 a sensor sensing the event and emitting the notification, and 2 a consumer receiving this notification.
In more complex scenarios, the consumer can act as a sensor itself, emitting new notifications in turn of received ones. Furthermore, any event processing systems supports the following
three features Chandy and Schulte, 2007:
1. Notifications are sent from the producer to a consumer using asynchronous messaging. The emission of notifications is triggered by the producer, not the consumer.
2. Consumers process event notifications as soon as possible to ensure timely end-to-end processes.
3. Notifications don‟t specify the operation that a consumer must perform upon receiving
the notification. As the logic what to do with the notification remains in the consumer, developers can change their response systems without touching the producer. The
logical coupling is minimized.
SANY D2.3.4 Specification of the Sensor Service Architecture V3 Doc.V3.1
Copyright © 2007-2009 SANY Consortium Page 70 of 233
6.4.3.2 Event Processing Role Model
The SensorSA uses a role-based concept to differentiate the various participants involved in the event-driven processing systems
10
. Some of those roles can be implemented as services and will therefore be discussed under the service viewpoint see section 8.
The SensorSA event role concept defines the following roles Figure 6-5:
Figure 6-5: Event Processing Role Model
-
Receivers do receive notifications from a priori known publishers. This simplest type of notification sink does not allow registering additional publishers. It does, however,
support registering itself at new publishers. Example: A component that accepts only incoming notifications from known publishers, e.g. to make data persistent in a
database.
-
Publishers do publish notifications. Publishers dont offer subscription-interfaces. Example: Simple sensor without any interface exposed other than what is necessary to
send notifications.
-
Routers receive events and publish them again, i.e. they forward events from registered Publishers to registered Receivers. Example: A gateway that forwards data
received over a thin wire from a sensor to a bunch of Internet clients. The Router is derived from Receiver and Publisher, i.e. it doesnt provide any interface to register
new publishers, nor does it support subscriptions. Example: A component that receives notifications from a-priori known publishers and publishes them to a-priori known
Receivers.
-
Consumer consumes notifications and provides an interface that allows publishers to register with this Consumer. The Consumer then accepts notifications sent by the
newly registered publisher. Consumers inherit the capability to subscribe with arbitrary Publishers from Receivers. Example: A service that accepts additional
sensors to register themselves as publishers.
10
The concept described herein is based on the OGC Engineering Report OGC 09-032 Everding and Echterhoff Eds., 2009, but varies slightly, as it describes a later stage of discussion.
SANY D2.3.4 Specification of the Sensor Service Architecture V3 Doc.V3.1
Copyright © 2007-2009 SANY Consortium Page 71 of 233
-
Producers do publish data and offer subscription interfaces to clients. Example: Sensor that supports subscription and sends notifications.
-
Broker: A Broker combines the roles of Consumers and Producers. Example: OGC Sensor Alert Service: it consumes data from sensors therefore it is a Consumer and
offers pubsub to clients therefore it is a Producer.
The various roles result on the implementation of interfaces as described in section 6.4.3.3. In concrete implementations, the various components will certainly be called
differently and may provide additional capabilities, as they will be based on specifications and definitions given elsewhere. Nevertheless, the role concept provides a guideline that helps
distinguishing explicit behaviour of components. The following Figure 6-6 illustrates the core capabilities of the various roles.
Figure 6-6: Event Processing Interaction Models
Blue dots represent actors taking on the roles of a publisher or producer, green dots represent consumers or receivers, and purple dots represent router and broker. The first row
differentiates the different capabilities of receivers and consumers in case a publisher intends to send event notifications. The second row reverses the perspective: both receiver and
consumer can subscribe with producers.
Row three and four illustrate the different capabilities of routers and brokers. Whereas the first behaves as a simple forwarder of information, the broker allows publishers to register
and consumers to subscribe to the events its offers.
SANY D2.3.4 Specification of the Sensor Service Architecture V3 Doc.V3.1
Copyright © 2007-2009 SANY Consortium Page 72 of 233
Naturally, all components can be included arbitrary chains. The following figure illustrates a realistic scenario. Here, a wireless sensor is connected to a gateway that forwards
events generated by the sensor to other Internet nodes. Due to the limited capacities of the sensor, it is preconfigured to send all events to a dedicated event sink Internet Gateway. The
Internet Gateway doesn‟t provide any additional capabilities other than forwarding the events to a broker. Such a chain of components is often used to match dedicated security
requirements. An additional router subscribes to the offerings of the broker. This router serves as an intermediate to the client. The router may only act as a protocol transducer, i.e. events
received using Internet protocols might get forwarded using automated phone calls.
Figure 6-7: Event Processing Chain
Principally, brokers and router serve as mediators between event sources and event sinks and don‟t provide any further event processing capabilities. Though, both may
implement further processing capabilities. The OGC Sensor Alert Service see section 8.2.4 is an example of such a broker: Sensors register with the service and publish events or simple
observations. The SAS instance acts as a complex event processor and analyzes all incoming data. Based on its internal settings, the service generates other types of events then it receives.
An example is a blizzard warning services. The service receives data streams and events reporting various weather parameters. Based on the actual constellation of the various
parameters in time and space, it then generates events of type “Blizzard”. The generation of those new event types might be transparent or opaque to subscribers.
6.4.3.3 Event Role Interfaces
