Requirements of GEOSS Enterprise Viewpoint

SANY D2.3.4 Specification of the Sensor Service Architecture V3 Doc.V3.1 Copyright © 2007-2009 SANY Consortium Page 36 of 233 - A SOA represents business functionality as implementation- and vendor neutral and standards-based shared services. - Existing legacy systems can be extended with service interfaces, and in that way become part of a SOA. - By means of the inherent service discovery and access flexibility see above, a SOA enables GMESINSPIRE service providers to be more agile and to respond more quickly to changing business needs and evolving requirements. - A set of common generic services can provide standard, domain-independent functionality for discovery, search, navigation, data access, authorisation etc. which only needs to be implemented once. - Sharing of services — no need to ―re-invent the wheel‖ - Loose coupling — ability to update applications with minimal effect on services that invoke them - Location transparency — ability to re-host applications with minimal effect on services that invoke them GMES applications built on top of a joint, adopted infrastructure will be interoperable and much easier to integrate into multi-purpose, cross-application operations. ” As a consequence, the SensorSA shall adopt a service-oriented architecture based on open standards in order to contribute to an emerging GMES infrastructure which demands flexibility, stability, and durability while preventing vendor lock-in. There are a number of projects, both concluded and ongoing, that are providing major contributions in terms of architectures suitable for the GMES infrastructure, for example the FP6 Integrated Projects OASIS, ORCHESTRA, and WIN on the EC side and HMA on the ESA side. All of these projects use the ISO RM-ODP methodology which is also adopted by the OGC Reference Model OGC 03-040.

4.4. Requirements of GEOSS

The purpose of the Global Earth Observation System of Systems GEOSS is to build on and add value to existing earth observation systems to achieve comprehensive, coordinated, and sustained observations of the whole planet. It is a “system of systems” that will facilitate the sharing of observations and derived products obtained by the cooperating earth observation systems for the benefit of a broad range of user communities around the globe. GEOSS is being developed by the Group on Earth Observations GEO which includes 73 Governments and the European Commission. In addition, 51 intergovernmental, international, and regional organizations with a mandate in Earth observation or related issues have been recognized as participating organizations status: June 2008, source: http:earthobservations.orgabout_geo.shtml. GEO has established a GEOSS 10-Year Implementation Plan GEOSS 1000R, 2005 that was adopted at the 3 rd Earth Observation Summit in Brussels in February 2005. SANY D2.3.4 Specification of the Sensor Service Architecture V3 Doc.V3.1 Copyright © 2007-2009 SANY Consortium Page 37 of 233 GEOSS addresses the requirements of users in the following nine societal benefit areas as briefly summarised below: - Disasters: Reducing loss of life and property from natural and human-induced disasters - Health: Understanding environmental factors affecting human health and well-being - Energy: Improving management of energy resources - Climate: Understanding, assessing, predicting, mitigating, and adapting to climate variability and change. - Water: Improving water resource management through better understanding of the water cycle - Weather: Improving weather information, forecasting, and warning - Ecosystems: Improving the management and protection of terrestrial, coastal, and marine ecosystems - Agriculture: Supporting sustainable agriculture and combating desertification - Biodiversity: Understanding, monitoring, and conserving biodiversity GEOSS is a federated system which is assembled from components contributed by GEO members and participating organisations. These components are basically used to acquire observations, to process observation data into products, and to exchangedisseminate these observations and products. One of the key aspects of GEOSS is therefore the interoperability between the various and numerous components which should be based on open international standards. The architecture of GEOSS is being defined under the supervision of the Architecture and Data Committee ADC which has provided high level strategic and tactical guidelines for the implementation of GEOSS. One of the tasks on the first two-year work plan of the ADC was to conduct a GEOSS Architecture Implementation Pilot to test and validate architectural aspects of GEOSS. The first phase of the AIP has been successfully conducted in 2007 with 75 registered services. A second phase is currently in progress and should be completed by end of May 2009. The Architecture Implementation Pilot specification adopts the structure of the RM- ODP viewpoints. The computational viewpoint proposes a service-oriented architecture SOA approach in which componentsservices interact through well defined interfaces based on open standards. The services are further organized into three tiers: a lower tier providing access to various types of data, a middle tier providing business processes acting on these data, and a top tier providing user interfaces for users consuming the data. The engineering viewpoint further identifies component types consistent with the enterprise and computational viewpoints as shown in Figure 4-4. SANY D2.3.4 Specification of the Sensor Service Architecture V3 Doc.V3.1 Copyright © 2007-2009 SANY Consortium Page 38 of 233 Figure 4-4: GEOSS Architecture – Engineering Viewpoint GEOSS AIP CFP, 2008 The results of the Architecture Implementation Pilot Phase 1 are documented in the GEOSS Core Architecture Implementation Report GEOSS CAIR, 2007 that was issued in November 2007. The Core Architecture is composed of the following components: GEO Web Portal, GEOSS Registries, and GEOSS Clearinghouse. As highlighted in this report and illustrated in Figure 4-5, the GEOSS interoperability process follows a publish-find-bind pattern supported by several registries where components, services, and standards are registered. The role of the Standards and Interoperability Forum SIF is to facilitate the establishment of interoperability arrangements standards or special. The GEOSS Core Architecture Implementation Report provides a list of candidate interoperability arrangement standards for services and encodings. Most of these services and encodings refer to OGC specifications including some SWE services. Other services and encodings refer to OASIS specifications such as UDDI, WS-Notification, and BPEL. The above services are also listed in section 4.2 of Annex B of the Call for Participation document GEOSS AIP CFR, 2008 for the Phase 2 Architecture Implementation Pilot that was issued in June 2008. SANY D2.3.4 Specification of the Sensor Service Architecture V3 Doc.V3.1 Copyright © 2007-2009 SANY Consortium Page 39 of 233 GEOSS Compo nent and Service Registries GEO Portal Standards and Interoperability Forum Users GEOSS Standards and Interoperability R egistry Standards Special Arrangements Components Registry Services Registry GEOSS Clearinghouse Community Catalogs GEOSS Contributor Compo nents Services Figure 4-5: GEOSS Interoperability Process from GEOSS CAIR, 2007 The architectural requirements of GEOSS are in many ways similar to the architectural requirements encountered in GMES and INSPIRE e.g. system of systems. As a matter of fact, as documented in The First 100 Steps to GEOSS document GEOSS 100S, 2007, both GMES and INSPIRE are expected to provide important EU contributions to GEOSS. The document also highlights the contribution that some FP6 and FP7 EU projects, including ORCHESTRA and SANY, could make in support of building GEOSS.

4.5. Requirements of Sensor Networks