Heterogeneous Missions Accessibility Context and Architecture

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. 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 - 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. Prime EADS Astrium Ltd Leading the Requirements phase activities Spacebel Datamat Spot Image SciSys Siemens EADS Astrium SAS • 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 • Leading the Architecture activities • Leading the trade-off analyses phase • In charge of the Ordering, Mission Planning and ODA ICD’s 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 Industrial Consortium

5. ESA Project team

6. Partners and GMES contributing missions

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. Mission classification based on resource access and management

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. 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. GMES HMA Architecture –Methodology – RM-ODP Model • 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.

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. 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. GMES HMA Architecture –Enterprise View - Context

15. GMES HMA Architecture –Enterprise View – Distributed Architecture

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 partner’s 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. 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. 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. GMES HMA Architecture –Information View • Transaction Tracking datamodel - Monitoring & Control service

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

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. GMES HMA Architecture – Service view (Work in Progress) • Relationships between HMA services and GS Services

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. 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. 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. GMES HMA Architecture –Engineering view (Work in Progress)

27. GMES HMA Architecture –Engineering view – DAIL Architecture

28. Identity Mgt- Engineering view EODAIL Mission GSk Users (local) Policy store DAIL Server Client Policy Management Identity Server Policy Enforcement Pointk Federation Server Identity Server LDAP User Directory Service ws-securityws-addressingSOAP HTTP LDAP User Directory Service Existing GSksystems WS - order WS - catalogue

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 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 Planning 2006-2007

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