1. HMA May 2006 – Slide 1 Heterogeneous Missions Accessibility Context and Architecture Pier Giorgio Marchetti HMA Project Manager Earth Observation Programme Ground Segment Department ESA / ESRIN pier.giorgio.marchetti@esa.int With contribution from: Y. Coene Spacebel D. Marchionni Datamat F. Sery EADS-Astrium

2. HMA May 2006 – Slide 2 High Level Requirements The GMES ground segment provides the necessary interfaces for requesting and accessing data from national and Eumetsat missions forming part of GMES. The component publishing these interfaces is named Data Access Integration Layer – DAIL [GMES Advisory Council Paper] HMA shall permit to integrate EO products, space data with all kinds of other data and information. [Oxygen objective] Project started in mid 2005 within the ESA GMES Preparatory Activities TODAY the project is executed within the ESA GMES Programme Phase-1 Segment-1

3. HMA May 2006 – Slide 3 HMA - High level objectives Consolidate scenarios and interoperability requirements Define the EO DAIL architecture Define and prototype an interoperable protocol for catalogue, order, mission planning,… Define approach for User Management Define approach for online data access Address interoperability requirements arising from: data quality and formats data policy, SLA, etc. security

4. HMA May 2006 – Slide 4 Industrial Consortium Leading the Prototyping activities In charge of the Catalogue ICD preparation In charge of the Standardisation activities Contributions to the Requirements phase activities (User Management, Processing) Contributions to the Architecture activities EADS Astrium Ltd Prime SpacebelDatamatSpot ImageSciSysSiemensEADS Astrium SAS Leading the Architecture activities Leading the trade-off analyses phase In charge of the Ordering, Mission Planning and ODA ICDs preparation Contribution to Prototyping activities Contributions to the Requirements phase activities Main contributor to the Requirements phase on the subjects of Mission Planning and Ordering Assessment of OGC SWE standards for HMA Leading the collection of data needs & operational requirements from GSE and EC IP projects Leading the Capacity Planning activities Leading the Data Supply Agreements activity Main contributor to the Requirements phase on the subjects of Online Data Access and User Management Leading the definition of the User Management concept for HMA Leading the definition of the Security concept for HMA Leading the Requirements phase activities

5. HMA May 2006 – Slide 5 ESA Project team

6. HMA May 2006 – Slide 6 Partners and GMES contributing missions PartnerMission ASI / Alenia SpazioCosmo-Skymed CNESPleiades, Spot CSA / MDARadarsat 2 DLRTerrasar EUMETSATMeteo Missions EUSCUser ESAERS, ENVISAT, Sentinels

7. HMA May 2006 – Slide 7 Missions interoperation Independent missions do not provide any access nor management of any resources to another mission. Federated missions share access to GS resources, typically catalogue functions. Cooperative missions allow other missions to place orders, i.e. to access to their space resources. Collaborating (or loosely coupled) missions may delegate mission planning functions to a partner, e.g. for optimum scheduling of observations over exclusive right zones. Integrated (or tightly coupled) missions are the highest level of interoperation, typically conceived as a single system

8. HMA May 2006 – Slide 8 Multiple MissionsManagement of Space Resources Management of Ground Segment Resorces Access to Space Resources Access to GS Resources Example(s)Comments - Common or joint IndependentQuick Bird, Radarsat-1 No catalogue FederatedXSpotCatalogue yes, order no CooperativeXXLandsat, Spot (planned) ENVISAT, ERS Catalogue yes, Order yes Loosely coupled -Collaborating XXXALOS, COSMO – Pleiades Cosmo- SAOCOM Catalogue, order, some mission planning Tightly Coupled - Integrated XXXXCosmo- BISSAT Delegation of ROI and Time IntegratedXXXXTandem-XOrbit control Mission classification based on resource access and management

9. HMA May 2006 – Slide 9 Related projects and activities External Requirements and Interfaces ESA studies (sentinels, service architecture, …) GSE projects EC GMES Integrated Projects (e.g. ORCHESTRA, WIN OASIS, GEOLAND, …) INSPIRE EUMETSAT

10. HMA May 2006 – Slide 10 Related projects and activities GSE projects Collocation in December 2005 EC GMES Integrated Projects (e.g. ORCHESTRA, WIN OASIS, GEOLAND, …) Architecture WG established with ORCHESTRA, WIN OASIS INSPIRE Coordinated approach set-up, work-plan on catalogue issues established EUMETSAT Technical co-ordination under definition UN-SDI Technical co-ordination under definition

11. HMA May 2006 – Slide 11 The approach to describe the architecture follows the RM-ODP model (Reference Model of Open Distributed Processing (ISO/IEC 10746- 1:1998)). RM-ODP model analyses the systems through 5 different views: The enterprise viewpoint: A viewpoint on the system and its environment that focuses on the purpose, scope and policies for the system. The information viewpoint: A viewpoint on the system and its environment that focuses on the semantics of the information and information processing performed. The computational viewpoint: A viewpoint on the system and its environment that enables distribution through functional decomposition of the system into objects which interact at interfaces. The engineering viewpoint: A viewpoint on the system and its environment that focuses on the mechanisms and functions required to support distributed interaction between objects in the system. The technology viewpoint: A viewpoint on the system and its environment that focuses on the choice of technology in that system. GMES HMA Architecture – Methodology – RM-ODP Model

12. HMA May 2006 – Slide 12 GMES HMA Architecture – Methodology – Tayloring of RM-ODP The RM-ODP approach focuses on distributed processing systems, while the GMES HMA is a loosely coupled network of services Need for tayloring, as for ORCHESTRA project. The HMA definition of is: The enterprise viewpoint: same as RM-ODP. The information viewpoint: Specifies the modelling of all categories of information the GMES HMA Architecture deals with including their thematic, spatial, temporal characteristics as well as their meta-data. The service viewpoint: This is the view that correspond to the computation view point. It specifies the GMES HMA services that support the syntactical and semantic interoperability between GSs, clients, EO DAIL. The engineering viewpoint: Specifies the mapping of the GMES HMA service specifications and information models to the chosen service and information infrastructure. The technology viewpoint: Specifies the technological choices of the service infrastructure and the operational issues of the infrastructure.

13. HMA May 2006 – Slide 13 GMES HMA Architecture – Methodology Design driven also by the Simple Service Architecture concept defined in the OpenGIS Service Architecture, section 7.6: Message-operations. The HMA Services operations will be modelled as messages. A message operation shall consist of a request and response. Requests and responses contain parameters as the payload, which is transferred in uniform manner independent of content. Separation of control and data. A client accessing a HMA service may not want the full results of the service. A client should have the option of receiving just the status of an operation and separately the data should be accessible through a separate operation. Synchronous versus Asynchronous Service Depending on the expected response time services will be defined either synchronous (i.e. service response is real time -e.g. catalogue service) or asynchronous ( e.g. order) Known service type. All service instances are of specific service types and the client knows the type prior to runtime. This hypothesis makes the interaction between the different HMA elements (clients, EO DAIL, Ground Segments) simpler because it is avoided the completely dynamic discovery and invocation of service operations. Adequate hardware. HMA services are software implementations running on hardware hosts. This assumption means that the hardware assignment is transparent to user.

14. HMA May 2006 – Slide 14 GMES HMA Architecture – Enterprise View - Context

15. HMA May 2006 – Slide 15 GMES HMA Architecture – Enterprise View – Distributed Architecture

16. HMA May 2006 – Slide 16 GMES HMA Architecture – Enterprise View – High level requirements HL_GEN_505: The overall HMA architecture, including the DAIL one, shall be driven to minimise the cost and impact on partners ground segments. HL_GEN_506: The DAIL architecture shall be independent of a particular partners ground segment. HL_GEN_507: The HMA architecture shall permit integration and reuse by additional partners in the future. HL_GEN_509: It shall be possible to add missions without changing the HMA architecture. HL_GEN_510: The HMA shall permit the support of INSPIRE implementing rules.

17. HMA May 2006 – Slide 17 GMES HMA Architecture – Enterprise View – High level requirements HL_GEN_511: The HMA architecture shall allow the use of partners proprietary GUI clients that are compliant to HMA interface specifications for the user access to HMA provided functionality/ services. HL_GEN_512: The HMA shall allow the traceability of all transactions which are handled through the DAIL. HL_GEN_513: The HMA architecture shall permit the partner to choose whether the user registration and the management of user privileges and or policies are managed either on the DAIL or at the partners ground segment or both. HL_GEN_500: The Access to the services from the missions participating in GMES will be ruled by Data Access Agreements to be signed between ESA and the mission owner. HL_GEN_501: The Data Access Agreements will define the Service Level Agreements to be supported for the specific mission/data access.

18. HMA May 2006 – Slide 18 GMES HMA Architecture – Information View HMA will manage the following information: Service metadata - Service Discovery. User Identity - User Management Transaction Tracking data - Monitoring & Control service

19. HMA May 2006 – Slide 19 GMES HMA Architecture – Information View Transaction Tracking data model - Monitoring & Control service

20. HMA May 2006 – Slide 20 GMES HMA Architecture – Information view – Namespaces sar.xsdohr.xsdatm.xsd hma.xsd smXML - gmd (ISO 19139) Catalogue metadata specific to EO space mission type gml Namespaces for radar missions Namespaces for optical missions Namespaces for atmospheric missions Generic catalogue metadata Catalogue metadata specific to EO space missions

21. HMA May 2006 – Slide 21 GMES HMA Architecture – Service view (Work in Progress) HM and GS services: Discovery Catalogue Mission Planning Ordering Data Access Request Monitoring & Control User Management

22. HMA May 2006 – Slide 22 GMES HMA Architecture – Service view (Work in Progress) Relationships between HMA services and GS Services

23. HMA May 2006 – Slide 23 GMES HMA Architecture – Technology view Pull IT standards (W3C/OASIS) e.g. XML/SOAP/WSDL. Push EO specific profile within OGC Propose adoption within the INSPIRE Implementing Rules ISO adoption / standardisation of specifications - long term goal

24. HMA May 2006 – Slide 24 GMES HMA Architecture – Technology view Selected technologies & protocols: Service Oriented Architecture (SOA) XML Schema Message-based SOAP (Simple Object Access Protocol) over HTTP or HTTPS for secure communication WSDL (Web Services Description Language) Business Process Execution Language (BPEL) UDDI service registry Ws-addressing Security/Identity management Security Assertion Markup Language (SAML) Lightweight Directory Access Protocol (LDAP) WS-Security WS-Policy Inspire Open Geospatial Consortium GML,WMS, WFS,WCS OGC CSW2.0 Application Profile ISO19115/19119

25. HMA May 2006 – Slide 25 GMES HMA Architecture – Engineering view HMA Services allocation (EO DAIL vs GS) criteria: When the responsibility for follow-on actions is with the GS Owner, then the service shall be provided by the GS owner The splitting of complex service request, the combination of results, the tracking of the transaction is allocated to EO DAIL; Complex coordination functions are allocated to ESA MM Ground Segment (either current or future); If support needed by GS Owner (station, processing, etc.) then the service shall be provided by the ESA MM GS The level of performance and/or reliability provided by the different components (e.g. EO DAIL, GS Owner, ESA MM GS) may be used as criterion to allocate service execution responsibility.

26. HMA May 2006 – Slide 26 GMES HMA Architecture – Engineering view (Work in Progress)

27. HMA May 2006 – Slide 27 GMES HMA Architecture – Engineering view – DAIL Architecture

28. HMA May 2006 – Slide 28 Identity Mgt- Engineering view Users Mission GS k Policy Management EODAIL (local) Policy store LDAP User Directory Service ws-security ws-addressing SOAP HTTP LDAP User Directory Service DAIL Server Client Identity Server Federation Server Policy Enforcement Point k Identity Server WS - order WS - catalogue Existing GS k systems

29. HMA May 2006 – Slide 29 GMES HMA Architecture – Engineering view – DAIL Architecture HTTP Server: listen to incoming SOAP over HTTP calls. Servlet Engine: hosts the execution of Servlets SOAP Engine: de-seriale the SOAP request message in a structured java class and serialize the answer in a properly formatted SOAP message. Application Layer: contains ad-hoc software implementing the EO DAIL services RDBMS: database management system needed to store the data supporting the Application Layer. Workflow Engine: in charge of executing predefined workflows upon triggering from the Application Layer. LDAP: in charge of storing the user identity information

30. HMA May 2006 – Slide 30 Planning 2006-2007 HMA SRR 2 March 2006 HMA Standards Workshop 27- 28 April 2006 HMA PDR 6-7 June 2006 HMA CDR 5-6 September 2006 HMA AR 28-29 November 2006 HMA FP 27-28 February 2007 OGC Meetings 6-9 March 2006 26-29 June 2006 CEOS WGISS Architecture info 11 May 2006 GI Workshop 21 June 2006

31. HMA May 2006 – Slide 31 HMA prototype http://services.eoportal.org Jolyon.Martin@esa.int yves.coene@spacebel.be Based on ESA Service Support Environment infratstructure: