Rigorous Definition and Use of Concepts and Standards Loosely Coupled Components Technology Independence
4. Enterprise Viewpoint
4.1. Architectural Requirements
The architectural and iterative design approach as described in RM-OA, 2007 is taken as the basis for the specification of the SensorSA. The architectural principles that have guided the specification of the ORCHESTRA Architecture have been adapted and assessed specifically for service networks that include access to sensors and sensor-related information. The result is presented in the following sections.4.1.1 Rigorous Definition and Use of Concepts and Standards
The SensorSA shall make rigorous use of proven concepts and standards in order to decrease dependence on vendor-specific solutions, help ensure the openness of a sensor service network and support the evolutionary development process of the SensorSA. Note: The SensorSA relies on the standard series “OGC Sensor Web Enablement SWE” Botts et al, 2006 as the starting point to refine the access and the management of sensor-related information.4.1.2 Loosely Coupled Components
The components involved in a sensor service network shall be loosely coupled, where loose coupling implies the use of mediation to permit existing components to be interconnected without changes. Note: In this stringency, this architectural principle is restricted to the acquisition, application and user domains of a sensor service network see section 6.1 as its application in the sensor domain may not be possible due to the predominance of proprietary solutions. Furthermore, performance and dependability requirements may necessitate a sensor network with fixed communication relationships and tight coupling of the sensor components.4.1.3 Technology Independence
The SensorSA shall be independent of technologies, their cycles and their changes as far as practically feasible. It must be possible to accommodate changes in technology e.g. lifecycle of middleware technology without changing the SensorSA itself. The SensorSA shall be independent of specific implementation technologies e.g. middleware, programming language, operating system. In general and if possible, the SensorSA shall not be influenced by or deal with limitations of specific implementation technologies. However, the SensorSA shall be explicitly designed such that it may deal with technical limitations of specific implementation technologies in the sensor domain see section 6.1. Note: Limitations of existing sensor networks must be taken into account in the SensorSA. At a minimum the characteristics of the sensor-to-sensor protocols must be considered in the meta-information e.g. dependability, quality of service, performance. This will be assessed in future versions of this document in more detail. SANY D2.3.4 Specification of the Sensor Service Architecture V3 Doc.V3.1 Copyright © 2007-2009 SANY Consortium Page 29 of 2334.1.4 Evolutionary Development - Design for Change
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