Evolutionary Development - Design for Change Component Architecture Independence Generic Infrastructure
4.1.4 Evolutionary Development - Design for Change
The SensorSA shall be designed to evolve, i.e. it shall be possible to develop and deploy the system in an evolutionary way. The SensorSA shall be able to cope with changes of user requirements, system requirements, organisational structures, information flows and information types in the source systems.4.1.5 Component Architecture Independence
The SensorSA shall be designed such that a service network and source systems i.e. existing information systems, sensors and sensor networks are architecturally decoupled. This means that the SensorSA shall not impose any architectural patterns on source systems for the purpose of having them collaborate in a service network, and no source system shall impose architectural patterns on a SensorSA. Note: This architectural principle relies on the RM-OA definition of a source system as being a “container of unstructured, semi-structured or structured data andor a provider of functions in terms of services. The source systems are of a very heterogeneous nature and c ontain information in a variety of types and formats”. In the context of a sensor service network, a source system may also be a sensor or a sensor network to be integrated in a service network. Important here is that a source system is seen as a black box, i.e. no assumptions about its inner structure are made when designing a service network.4.1.6 Generic Infrastructure
The SensorSA services shall be independent of the application domain. This means that the SensorSA services shall be designed in such a flexible and adaptable way that the SensorSA services can be used across different thematic domains and in different organisational contexts, and that the update of integrated components e.g. sensors, applications, systems, ontologies causes little or ideally no changes to the users of the SensorSA services.4.2. Relationship to the ORCHESTRA Architecture
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