Definition and Subscription of Events
10.11.1 Definition and Subscription of Events
Initially, two scenarios must be differentiated, as illustrated in Figure 10-31 and Figure 10-32. Figure 10-31 illustrates the simplest scenario. Sensors define events and advertise them to an SAS instance. Those event-types will then be advertised by the SAS. Clients can subscribe to those events exclusively. As an example, the sensor triggers events if the temperature exceeds 10 °C. The clients can subscribe to “temperature exceeds 10°C” exclusively. Other commonly used examples of predefined events are “battery low” or “observation failure”. . Figure 10-31: Clients subscribe to sensor-defined event types Figure 10- 13 illustrates the second scenario. Sensors don‟t define event-types, but advertise observation data to the SAS. SAS will advertise these data to clients. Clients are now free to define their own events based on the observation data. As an example, a sensor offers SANY D2.3.4 Specification of the Sensor Service Architecture V3 Doc.V3.1 Copyright © 2007-2009 SANY Consortium Page 220 of 233 temperature observations at a certain location in degree Celsius. The client may define an event as an observation with a result greater than 20°Celsius. Figure 10-32: Clients define events based on observation offerings by sensors or SAS respectively The next scenario, illustrated in Figure 10-33, describes a combination of the two base types described above. Here, a single sensor or any number of sensors push data to the SAS instance. Independently of the type of incoming data either observation results or event notifications, the SAS instance may define and advertise new event-types. Clients can then register those event-types. The SAS will process all incoming data to detect the type of event it advertises. An example would be an SAS that advertises “storm warning” events. The “storm warnings” are detected based on data coming from a number of meteorological sensors. Figure 10-33: SAS defines event types based on various incoming data sets. Clients subscribe to those events10.11.2 Generation and Dispatching of Alerts
Parts
» Specification of the Sensor Service Architecture (SensorSA)
» Executive Summary Specification of the Sensor Service Architecture (SensorSA)
» Intended Audience Abbreviations and acronyms
» General Remark Terms and Definitions
» Architectural Framework Specification of the Sensor Service Architecture (SensorSA)
» Relationship to the ORCHESTRA Architecture
» Requirements of GMES Enterprise Viewpoint
» Requirements of GEOSS Enterprise Viewpoint
» Requirements of Sensor Networks
» Overview Sensor Network User Requirements
» Data and Information User Requirements
» Data Quality Security User Requirements
» Processing and Fusion User Requirements
» Decision Support User Management
» Complex form of a Sensor Sensor System
» Overview Enterprise Viewpoint of a Sensor
» Engineering Viewpoint of a Sensor
» Service Viewpoint of a Sensor
» Information Viewpoint of a Sensor
» Overview Functional Domains Major Concepts of the Sensor Service Architecture
» Overview RequestReply Interaction Model
» Event-based Interaction Model Models of Interaction
» Event Definition Event-based Architectural Style
» Event Properties Event Model
» Event Verbosity Levels Event Model
» Form of Events Roles in Event Relationships
» Overview Event Processing Role Model
» Event Role Interfaces Event-Driven Processing System
» Resources Resources and their Identification
» URN Namespace for SANY Resources
» Naming principles Resources and their Identification
» Resource and Catalogue Types
» Sensor Planning Information Service Planning Functions
» Introduction Data and Service Integration Interpretation
» Discovery Monitoring Authentication and Authorisation
» The measurement process Uncertainty
» Access Control Service Architecture
» t Conceptual Building blocks for “Plug-and-Measure”
» Overview Information Model for Observations Measurements OM
» Information Model of the Sensor Observation Service
» Model for Subject Related Information Profiles and Identities
» SAML Security Assertion Markup Language
» XACML eXtensible Access Control Markup Language
» Event Information Model Information Viewpoint
» Resource representation Resource name
» Resource link Uniform Interface
» Introduction Relationship between Resources, Services and Features
» Overview Meta-information Schema for Discovery
» Meta-information Sections Related to Observation Discovery
» Overview Services of the OGC Sensor Web Enablement
» Sensor Observation Service Services of the OGC Sensor Web Enablement
» Web Notification Service Services of the OGC Sensor Web Enablement
» Overview Profile Management Service
» Policy Enforcement Service Access Control Services
» Overview Services of the Mediation, Processing and Application Domain
» Interfaces of WS-Base Notification Specification
» Properties of a Service Platform
» Specification of the SensorSA W3C Web Services Platform
» Specification of the SensorSA OGC Web Services Platform
» Specification of the SensorSA RESTful Web Services Platform
» Introduction Query Models Resource Discovery Policy
» Discovery of Observations Typical resource discovery policies
» Discovery of Procedures Typical resource discovery policies
» Event-based Harvesting Resource Discovery Policy
» Overview Policies for Sensor and Service Monitoring
» Policies for Sensor Planning
» “Non intrusive” at service level
» Delegate Anonymous Service Chain
» Patterns for Access Control in a Multi-Protocol Environment Usage of SAML
» Attachment of quality information
» Data flow optimization Providing alternative views to data
» Data pre-processing Multi-level sensor data storage
» Processing Chain Service Processing Chains .1 Introduction
» Approach Combining Earth Observation and In-situ data .1 Introduction
» Integration of Mobile Sensors
» Definition and Subscription of Events
» Sensor Plug In Plug-and-measure Support
» Sensor recognition and connection establishment Sensor Adapters
Show more