ESA > Join & Share > HMA-S > HMA-S Test Bed

HMA-S Test Bed


HMA-S Test Bed and OGC TEAM Engine


Summary of the Task 8 activities

  • HMA-S Test Bed (SPACEBEL)

Access to testbed here

  • OGC TEAM Engine (INTECS)
The TEAM Engine tool is based on the SAXON tool and uses the SAXON extension to invoke Java
classes and perform the tasks described as CTL tags. The tool was based on HTTP as main
interaction mechanism and has already been extended by INTECS in the framework of the ERGO
project to support SOAP.
When a CTL is loaded and executed the TEAM Engine read in sequence all the tags and executes
the right Java code. The interaction with the back end is typically synchronous and the response is
received within the same HTTP or SOAP exchange. The response received is ten processed via the
next tags that check if the result is the one expected by the test. Generally the OGC specifications
support asynchronous interactions via a polling approach. In this case the TEAM Engine can get the
asynchronous response by invoking several times the HTTP operation and check the results.
The approach described above is typical for specifications essentially based on HTTP and REST. With
the introduction of the SOAP binding it is possible to use more sophisticated approaches to implement
asynchronous communications. Within the DREAM project the CTL language and the TEAM Engine
will updated in order to support the asynchronous operations.
The DREAM update will support the SPS 2.0 uses two asynchronous specifications WS-Addressing
and WS-Notification. Moreover future version of the WPS based on WS- Addressing (already
demonstrated in GENESIS) will be supported.
In the past HMA related project some limitations of the TEAM Engine have been encountered. In
particular in the HMA-FO project has been highlighted that spatial comparison and spatial filtering
verification èerformed with the current version of the TEAM Engine is quiet challenging.
Indeed checking the Spatial filter is well applied is not a trivial task and the CTL language does not
provide support for this kind of checks.
To check validity of spatial filtering, solution would be :
  • Perform a GetRecordById to obtain an EOProduct
  • Extract Box as RefBox
  • Perform a GetRecords where Id = X & Box intersect RefBox. This search should return only
  • one result
  • Calculate Box outside RefBox as outsideBox
  • Perform GetRecords where Id = X & Box intersect outsideBox. This search should return no
  • results.
The procedure reported above is only an example of more sophisticated checks that can be performed
on the EO product and they are not easily implementable via the CTL language.
In order to support these additional checks we foresee two possible solutions:
  • Extend the CTL language in order to support spatial comparisons. Implement a set of java functions that perform the checks and then integrate them in the CTL scripts via the native extension mechanism. These functions will then be made available at the
  • OGC community as source code that can be adapted for other specifications
CTL extension:
  • PRO: It is included in the original language and follows a more clear process
  • CONS: Past experience have shown that the adoption at OGC is not straightforward and can require a lot of time and effort. The CTL tags have to be generic (not specific for the EO world). This may result in a more complex. CTL development approach. The performances of the test execution are not optimized.
Java functions
  • PRO: The Java functions are tailored for the EO world and are more efficient. The source code provided to the community can then be easily extended for other specifications.
  • CONS: It is not included in the original CTL documentation and may have less visibility.

In HMA-S the java function approach will be followed

<HMA Task 7>                               <Return to the HMA-S Project Page>                             <HMA-S Tqsk 2>

Contributors to this page: Patrick Jacques

Page last modified on Friday 11 of July 2014 17:02:34 CEST by Patrick Jacques.