Loading...
 
ESA > Join & Share > HMA-T > ERGO TEAM ENGINE
Print

ERGO TEAM ENGINE

TEAM Engine SOAP extension

Compliance & Interoperability Testing & Evaluation (CITE) is an ongoing initiative of the OGC that develops tests for OGC standards, and makes those tests available for online testing on http://cite.opengeospatial.org/.

In the framework of the ERGO project Intecs is updating the TEAM Engine to support the SOAP based HMA catalogue interfaces.

The following functionalities have been added:

  • Support for SOAP (synchronous operations)
  • SOAP parser

 NOTE: this is not the official TEAM Engine release. The approach used in the ERGO project will be discussed at OGC level and the output of this activity could contribute to the development of the official release of the Tool.

The implementation is compliant with the new CTL specification which is now an OGC Best Practice document. The document can be downloaded from

http://portal.opengeospatial.org/files/?artifact_id=33085&version=1

The modified TEAM engine can be downloaded from

https://teamengine.svn.sourceforge.net/svnroot/teamengine/branches/hma

You are strongly encouraged to test it and give us feedback using the forum.

INSTALLATION

To install the new TEAM engine, simply unpack the zip file you downloaded from the above URL. The process creates a "TeamEngine" directory which contains:

  • a subdirectory named "dist", which holds the TEAMEngine2.jar file;
  • a subdirectory named "lib", which holds the library files that the TeamEngine needs to run;
  • a subdirectory named "resources", which holds ctl and schema files used by the TeamEngine at run-time;
  • a DOS batch file "startTeamEngine.bat" to be used to start the TeamEngine.

To run the TeamEngine,  launch a DOS command prompt, navigate to the "TeamEngine" directory, type "startTeamEngine.bat" and press the return key. The output screen will show you the available options. Remind that the parameter:

-source=path_to_the_ctl_file(or directory)

is mandatory. By default, the TeamEngine starts in test mode (if not otherwise specified).

A typical TeamEngine test is launched as follows:

> startTeamEngine.bat -source=C:\...\myCtlFile.xml -logdir=C:\...\myLogDir\  

SOAP Support

Hereafter we report an excerpt of the document

 

 

The <soap-request> element submits a SOAP request to a web service, and returns an XML representation of the response.

Note: the tag does not support the full SOAP specification. Only message based Request-Response Message Exchange Pattern over HTTP is supported.

The request instruction may contain a combination of literal XML elements and/or other CTL or XSL instructions. When any enclosed instructions have been evaluated, the resulting XML shall conform to this encoding.

Element/Attribute                             Usage           Description
                                      Required      The SOAP request instruction

 version="1.1|1.2"                               Required      Define SOAP version to be used.

 charset="utf-8|utf-16">                    Optional       Character set. Default is utf-8.

   l>URLl>                               Required      Web Service end point

  action                 Optional       Action associated with the SOAP

                                                                                 request HTTP header

                                                                                 (SOAPAction in SOAP 1.1).

   *      SOAP header blocks

        mustUnderstand="true|false"     Optional       If "true", the targeted SOAP node must

                                                                                 process each of the blocks according to

                                                                                 its specification.

                                                                                 Default is false.

        relay="true|false"                        OptionalA     SOAP 1.1: Not Applicable

                                                                                 SOAP 1.2: Indicates whether the

                                                                                 blocks targeted at a SOAP

                                                                                 intermediary must be relayed if they

                                                                                 are not processed.

                                                                                 Default is false.
        role="shortname|URI">              Optional       Identifies the role played by the

                                                                                 intended target of the header blocks.

      Header block element                   Required*     SOAP header block element.

                                                                                 Must be namespace-qualified.

                                                                                 May contain any number of attribute,

                                                                                 character, and element children.

  

   XML                       Required      Body of the SOAP Request.

   <parser/>                                         Optional       Parser instruction for handling

                                                                                 the response message. Default is to

                                                                                 return the raw response, with no

                                                                                 validation.
 
Usage Notes:
* May be repeated.
A Only allowed if SOAP version is 1.2.
1.1.3.1       version

This mandatory parameter is used to define the SOAP version to be used. SOAP 1.1 and SOAP 1.2 are supported

1.1.3.2       charset

Optional charset parameter that can take the value of utf-8 or utf-16 (case insensitive). If not provided the default value utf-8 will be used.

1.1.3.3       URL

The required <url> element indicates the web service resource where the request will be submitted.

1.1.3.4       action

SOAP 1.1: SOAP action for the request. It has to be compliant with the end point WSDL description. If not provided an empty SOAPAction will be used.

SOAP 1.2: Optional action parameter to be included in the HTTP header.

1.1.3.5       Header blocks

The <header-blocks> tag contains header blocks to be included in the SOAP Header element. A SOAP header is an extension mechanism that provides a way to pass information in SOAP messages that is not application payload. Such "control" information includes, for example, passing directives or contextual information related to the processing of the message. This allows a SOAP message to be extended in an application-specific manner.

Each header-blocks element may contain attributes that apply to each of the enclosed header blocks.

1.1.3.6       mustUnderstand

If "true", means that the targeted SOAP node must process the block according to the specification of that block. Such a block is colloquially referred to as a mandatory header block. In fact, processing of the SOAP message must not even start until the node has identified all the mandatory header blocks targeted at itself, and "understood" them.

Understanding a header means that the node must be prepared to do whatever is described in the specification of that block. (Keep in mind that the specifications of header blocks are not a part of the SOAP specifications.)

1.1.3.7       relay

SOAP 1.1: Not Applicable

SOAP 1.2: Indicates whether a header block targeted at a SOAP intermediary must be relayed if it is not processed.

Note that if a header block is processed, the SOAP processing rules require that it be removed from the outbound message. (It may, however, be reinserted, either unchanged or with its contents altered, if the processing of other header blocks determines that the header block be retained in the forwarded message.) The default behavior for an unprocessed header block targeted at a role played by a SOAP intermediary is that it must be removed before the message is relayed.

1.1.3.8       role

Identifies the role played by the intended target of that header block. A SOAP node is required to process a header block if it assumes the role identified by this attribute. How a SOAP node assumes a particular role is not a part of the SOAP specifications.

In SOAP 1.1 it will be used to fill the actor attribute: The SOAP actor global attribute can be used to indicate the recipient of a header element. The value of the SOAP actor attribute is a URI. The special URI "http://schemas.xmlsoap.org/soap/actor/next"indicates that the header element is intended for the very first SOAP application that processes the message.

The value may be set to a URI value, or to one of the short names in the list below:

Ver
Short-name
URI
1.1
next
http://schemas.xmlsoap.org/soap/actor/next
1.2
next
http://www.w3.org/2003/05/soap-envelope/role/next
1.2
none
http://www.w3.org/2003/05/soap-envelope/role/none
1.2
ultimateReceiver
http://www.w3.org/2003/05/soap-envelope/role/ultimateReceiver
 
1.1.3.9       Header Block Element

Header blocks represent a logical grouping of data which can individually be targeted at SOAP nodes that might be encountered in the path of a message from a sender to an ultimate receiver.

Each element contains one or more header block elements to be included in the SOAP Header. The name of the header block is not fixed, but it must be namespace-qualified. It may contain any number of attribute, character, and element children.

 
1.1.3.10   Body

The <body> element contains the data to be included in the SOAP body. The element should contain XML compliant with the web service interface.

1.1.3.11   Parser

A parser may be used to check the content of the result message. If present, the name of this element should correspond to the name attribute of a parser element. Parsers may contain various required or optional attributes or elements, depending on the parser implementation.

The soap-request element returns an XML representation of the SOAP message response or a SOAP fault element in case of errors.

Example 1: OGC Catalog Service SOAP request
>
    l>http://mycompany.com/wrsl>
    GetCapabilities
   
       
         xmlns:csw="http://www.opengis.net/cat/csw/2.0.2"
         service="CSW"/>
   
 
Example 2: Travel Service example

This example is borrowed from example 3 in section 2.2.1 of W3C’s SOAP Version 1.2 Part 0: Primer.

 
>
   l>http://travelcompany.example.org/servicel>
   "next"mustUnderstand="true">
      
       xmlns:m="http://travelcompany.example.org/reservation">
         
            uuid:093a2da1-q345-739r-ba5d-pqff98fe8j7d
         
         2001-11-29T13:36:50.000-05:00
      

      lns:n="http://mycompany.example.com/employees">

         Ã…ke Jógvan Øyvind

      
   header-blocks>
  
      
      xmlns:p="http://travelcompany.example.org/reservation/travel">
         
            LGA
         
         
            EWR
         
      
  
 

SOAPParser is a parser that parses data as SOAP messages and validates it. Only the SOAP structure is validated. To validate the SOAP body content an XMLValidatingParser can be used as child of a SOAPParser (with the return attribute set to content).

Element/Attribute                                Usage           Description

                             Required      The parser element

 return="content|envelope">                 Optional       Envelope indicates return complete

                                                                                    SOAP message including SOAP

                                                                                    evelope. Content indicates just

                                                                                    return SOAP body. Default is

                                                                                    envelope.
       <parser/>                                        Optional       Parser instruction for carrying out

                                                                                    further processing

 
1.1.3        Results

The SOAPParser validates the content of the SOAP message (SOAP 1.1 or 1.2 according to the response content namespace). Any validation errors and warnings are presented to the user. If there are no errors or warnings, the parser returns the XML. If the SOAP structure message cannot be validated no content is returned.

In the next example the complete SOAP message is returned

 xmlns:xi="http://www.w3.org/2001/XInclude"
 xmlns:parsers="http://www.occamlab.com/te/parsers">
    l>http://ebrr.pisa.intecs.it/ebrr/webservice?wsdll>
    GetCapabilities
   
.. ..
   
   
   

In the next example the content of the SOAP message is returned

 xmlns:xi="http://www.w3.org/2001/XInclude"
 xmlns:parsers="http://www.occamlab.com/te/parsers">
    l>http://ebrr.pisa.intecs.it/ebrr/webservice?wsdll>
    GetCapabilities
   
.. ..
   
   
   

In the next example the content of the SOAP message validated and returned if no errors are detected

lns="http://www.occamlab.com/ctl"
xmlns:parsers="http://www.occamlab.com/te/parsers"
version="1.1" charset="UTF-8">
    l>http://ebrr.pisa.intecs.it/ebrr/webservice?wsdll>
    GetRecord
   
.. ..
   
   
         
                 

                        http://www.example.com/example.xsd

                 
           
        

 

 

 


Contributors to this page:

Maria Rosaria Barone .

Page last modified on Monday 13 of July 2009 14:35:42 CEST by .

Category: HMA-T