Overview RequestReply Interaction Model
6.3. Models of Interaction
6.3.1 Overview
The SensorSA uses the taxonomy proposed in MuehlFiegePietzuch, 2006 in order to characterise the interaction models between the service components in a sensor service network. The taxonomy is based upon the way interdependencies between the service components are established see Figure 6-3. Figure 6-3: Taxonomy of Interaction Models MuehlFiegePietzuch, 2006 It is expressed by two attributes: the initiator attribute, which describes whether the consumer or the provider initiates an interaction, and the addressee attributes, which describes whether the addressee of the interaction is known i.e. directly addressed or unknown i.e. indirectly addressed.The SensorSA currently supports the following interaction models: - requestreply interaction model see section 6.3.2 - event-based interaction model see section 6.3.3 Note: These are interaction models between the logical service components without making assumptions about the underlying infrastructural means e.g. communication protocols to implement these interaction models. Furthermore, both interaction models may be applied to implement the two logical interface types that are distinguished in the service viewpoint of the sensor model see section 5.5: the information and the management interface.6.3.2 RequestReply Interaction Model
In the requestreply interaction model the initiator is the consumer also called client that requests data or functionality from the provider also called server. The initiator either expects data to be returned or it relies on a specific task to be done. The consumer knows the provider in the sense that it may directly address the provider. The address may have been acquired through pre-knowledge configuration or by means of resource discovery see section 10.2. The requestreply interaction model is applied in most of the services and interfaces specified in the Service Viewpoint in section 7. Note: In cases where the addresses of the providers are not known, MuehlFiegePietzuch, 2006 talk about the anonymous requestreply interaction model. This SANY D2.3.4 Specification of the Sensor Service Architecture V3 Doc.V3.1 Copyright © 2007-2009 SANY Consortium Page 61 of 233 interaction model may be applied in the sensor domain of the SensorSA functional domains see Figure 6-1 and implemented by broadcast or multicast communication protocols in sensor networks. However, these communication protocols are conceptually out of the scope of the SensorSA., because, as explained in section 2.1, the SensorSA specification is independent of the specifics of a particular service platform.6.3.3 Event-based Interaction Model
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