Relationship to the ORCHESTRA Architecture

SANY D2.3.4 Specification of the Sensor Service Architecture V3 Doc.V3.1 Copyright © 2007-2009 SANY Consortium Page 29 of 233

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

The architectural heritage of the SensorSA is the ORCHESTRA Architecture specified in RM- OA, 2007 as an “open architecture that comprises the combined generic and platform- neutral specification of the information and service viewpoint as part of the ORCHESTRA Reference Model ” RM-OA. Consequently, the SensorSA builds upon the components of the ORCHESTRA Architecture which comprise: - Rules and guidance about how to specify information and service models in the context of international standards. In the RM-OA, these rules are formally specified in an ORCHESTRA Meta-model 2 for information and for services. 2 The ORCHESTRA Meta-model is an extension of the ISOOGC-defined General Feature Model. It consists of a set of UML classes stereotyped as MetaClass and associated textual rules that provide guidance on how application schemas and services have to be specified in UML, i.e. on a platform-neutral abstract level. It encompasses two parts: one for the specification of information models in the form of application schemas, and one for the specification of interface and service types. SANY D2.3.4 Specification of the Sensor Service Architecture V3 Doc.V3.1 Copyright © 2007-2009 SANY Consortium Page 30 of 233 - Basic re-usable specification units for information models e.g. pre-defined feature types 3 and service models e.g. re-usable interfaces. - Textual and document templates that guide the specification of services. - A series of textual descriptions and formal specifications of generic services so-called ORCHESTRA Architecture Services or, in short, architecture services that are application- and technology independent. It is the objective of the SANY project to re-use and apply these components in the context of the SensorSA to the extent that they fulfil the requirements of building service networks 4 based on sensor information and higher-level sensor information processing. Thus, there are two cases: 1. The SensorSA contributes to the architectural level in the sense that it specifies new architectural concepts or new architecture services, or it refines existing architecture services. 2. The SensorSA specifies new application-oriented services in the RM-OA categorised as ORCHESTRA Thematic Services or, in short, thematic services that typically require the call of underlying architecture service operations. In this case the SensorSA defines a so-called ORCHESTRA Application Architecture 5 . In both cases, the SensorSA uses the templates and the rules of the RM-OA in order to specify the refined and the new components.

4.3. Requirements of GMES