ERGO TEAM ENGINE
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.
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\
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.
version="1.1|1.2" Required Define SOAP version to be used.
request HTTP header
(SOAPAction in SOAP 1.1).
process each of the blocks according to
its specification.
Default is false.
SOAP 1.2: Indicates whether the
blocks targeted at a SOAP
intermediary must be relayed if they
are not processed.
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
This mandatory parameter is used to define the SOAP version to be used. SOAP 1.1 and SOAP 1.2 are supported
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.
The required <url> element indicates the web service resource where the request will be submitted.
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.
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.
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.)
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.
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
|
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
The <body> element contains the data to be included in the SOAP body. The element should contain XML compliant with the web service interface.
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.
This example is borrowed from example 3 in section 2.2.1 of W3C’s SOAP Version 1.2 Part 0: Primer.
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).
SOAP message including SOAP
return SOAP body. Default is
further processing
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
In the next example the content of the SOAP message is returned
In the next example the content of the SOAP message validated and returned if no errors are detected
