Heterogeneous Missions Accessibility Context and Architecture

May 2006 – Slide 1HMA

Heterogeneous Missions AccessibilityHeterogeneous Missions AccessibilityContext and ArchitectureContext and Architecture

Pier Giorgio Marchetti HMA Project Manager Earth Observation ProgrammeGround Segment DepartmentESA / ESRIN

[email protected]

With contribution from:

Y. Coene Spacebel

D. Marchionni Datamat

F. Sery EADS-Astrium


High Level RequirementsHigh 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


HMA - High level objectivesHMA - 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


Industrial ConsortiumIndustrial 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

Spacebel Datamat Spot Image SciSys Siemens EADS Astrium SAS

• 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

Leading the Requirements phase activities


ESA Project teamESA Project team

E S A P ro je ct T e am

Andrea SimoniniProduct Assurance

Annette TauberProject Controller

Jolyon MartinStandardisation

Prototype

Ludw ig MoellerScenario, Requirements

Sergio VazzanaMission Planning

Pierre PotinCapacity, Agreements, Security

Pier Giorgio MarchettiTechnical Officer

HMA Project Manager

Sergio BenettiContract Officer


Partners and GMES contributing missionsPartners and GMES contributing missions

Partner Mission

ASI / Alenia Spazio Cosmo-Skymed

CNES Pleiades, Spot

CSA / MDA Radarsat 2

DLR Terrasar

EUMETSAT Meteo Missions

EUSC User

ESA ERS, ENVISAT, Sentinels


Missions interoperationMissions 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


Multiple Missions Management of Space Resources

Management of Ground Segment Resorces

Access toSpace Resources

Access to GS Resources

Example(s) Comments -Common or joint

Independent Quick Bird,Radarsat-1

No catalogue

Federated X Spot Catalogue yes, order no

Cooperative X X Landsat,Spot (planned)ENVISAT, ERS

Catalogue yes , Order yes

Loosely coupled -Collaborating

X X X ALOS, COSMO – PleiadesCosmo-SAOCOM

Catalogue, order, some mission planning

Tightly Coupled - Integrated

X X X X Cosmo-BISSAT

Delegation of ROI and Time

Integrated X X X X Tandem-X Orbit control

Mission classification based on resource access and management


Related projects and activitiesRelated 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


Related projects and activitiesRelated 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


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


GMES HMA Architecture – GMES HMA Architecture – Methodology – Tayloring of RM-ODPMethodology – 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.


GMES HMA Architecture –GMES HMA Architecture – MethodologyMethodology

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.


GMES HMA Architecture –GMES HMA Architecture –

Enterprise ViewEnterprise View - Context - Context

EO Data Access integration layer

Static

Geo-spatial

in

situ

COMMERCIAL

SCIScienceCOM

GMES

ScienceCOM

GMES

Service Access Layer

Non European

Mission

Ground Segment

Integration

ESA

MM

Ground Segment

Other European

Mission

Ground Segment

Other European

Mission

Ground Segment

Meteorological

Mission

INSPIRE



Enterprise ViewEnterprise View – Distributed Architecture – Distributed Architecture



Enterprise ViewEnterprise View – High level requirements – 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.



Enterprise ViewEnterprise View – High level requirements – 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.



Information ViewInformation View

HMA will manage the following information:

• Service metadata - Service Discovery.

• User Identity - User Management

• Transaction Tracking data - Monitoring & Control service



Information ViewInformation View

Transaction Tracking data model - Monitoring & Control service

Ordered sequence of service operation

One input for each operation of the service

One or m ore results for each operation of the service

XML Input: it is the XML ASCII string provided as input param eter to the operation of the service

XMLResult: it is the XML ASCII string returned as result from the operation of the service

A workflow instance is created for each invoked operation

W orkflowInstance

OperationInputoperationXMLInput

OperationResultoperationXMLResultstatuslastUpdatedTim e

Organisationnam edescriptionURL

ServiceLifeCycleoperationNam eoperationNum bersynchronousFlagworkflowNam e

Servicenam edescriptiontechnologyfixedDeliveryTim efixedPricestatusserviceId

0..n0..n

0..n0..n

ServiceCategory

0..n0..n

User

userIdpasswordfirstN am elastN am eorganizationem ail

(from U ser M anagem ent)

ServiceRequestrequestIdstatussubStatuspricestartingTim elastUpdatedTim e

0..n0..n

0..n0..n

0..n0..n

0..n0..n

0..n0..n



Information view – NamespacesInformation view – Namespaces

sar.xsd ohr.xsd atm.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



Service view Service view (Work in Progress)(Work in Progress)

HM and GS services:

• Discovery

• Catalogue

• Mission Planning

• Ordering

• Data Access Request

• Monitoring & Control

• User Management


GMES HMA Architecture – GMES HMA Architecture –

Service view Service view (Work in Progress)(Work in Progress)

Relationships between HMA services and GS Services

U ser / O perator(fro m Lo g ica l V ie w )...)

H M A Services

G S Catalogue Service

getR ecords()getR ecordsById()getO ptim isedCoverage()getCatalogueO ptions()

(fro m G S S e rvice s)

<<S e rvice >>

G S D iscovery Service

getCapabilities()getR ecords()describeR ecord()getD om ain()getR ecords ()getR ecordsById()


<<S e rvice >>

G S O rder Service

subm itProductO rder()getO rderStatus()getO rderO ptions()cancelO rder()


<<S e rvice >>

G S M ission Planning Service

subm itAcquisitionO rder()subm itCoverageO rder()getCoverageFeasibilityAnalysis()getCoverageFeasibilityForecast()com pleteCoverageO rder()


<<S e rvice >>

G S U ser M anagem ent Service(fro m G S S e rvice s)

<<S e rvice >>

G S D ata Access R equest(fro m G S S e rvice s)

<<S e rvice >>



Technology viewTechnology 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



Technology viewTechnology 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



Engineering viewEngineering 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.



Engineering view Engineering view (Work in Progress)(Work in Progress)



Engineering viewEngineering view – DAIL Architecture – DAIL Architecture


Identity Mgt- Engineering viewIdentity Mgt- Engineering view

Users

Mission GSk

Policy Management

EODAIL

(local) Policy store

LDAP User Directory Service

ws-securityws-addressing

SOAPHTTP

LDAP User Directory Service

DAIL ServerClient

Identity Server

Federation Server

Policy Enforcement Pointk

Identity Server

WS - order

WS - catalogue

Existing GSk systems



Engineering viewEngineering view – DAIL Architecture – 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


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


Service Partner C

Service Partner B

Service Partner A

Oracle Oracle BPEL PMBPEL PM

“Network of service

partners”

BPEL SolutionBPEL SolutionDesign

Management Console

Engine


Management Console


Management Console


Management Console

HMA prototypeHMA prototype

• http://services.eoportal.org

• [email protected]

• [email protected]

Based on ESA Service Support Environment infratstructure:

Documents

Heterogeneous Missions Accessibility Context and Architecture