104 Copyright © 2011 Open Geospatial Consortium,
Inc. All Rights Reserved.
Whenever an OGC Web Service supports KVP encoded requests via HTTP GET andor plain XML encoded requests via HTTP POST, the use of the well known
GetCapabilities request can be used for bootstrapping because all the required information is contained in the Capabilities document. For each network endpoint
indicated by a URL, the use of either the HTTP GET or POST method is given, in addition to other parameters as defined by OWS Common
However, if SOAP is required then the Capabilities document does not carry enough information. The use of SOAP may involve a particular format to include
security related metadata into the headers. Different OASIS standards such as WS-Policy or WS-SecurityPolicy exist that allow encoding constraints to indicate
what the service expects in terms of security metadata when a clients tries to execute it. Other information, such as the required use of HTTP headers such as
SOAPAction, cannot be specified in the Capabilities document. Therefore, the bootstrapping of an OWS that requires SOAP should be done by a WSDL
document that describes in more detail the requirements to get going with the service.
In terms of publish-find-bind, it is up to the service provider to publish the appropriate bootstrapping mechanism in a registry or catalogue. For HTTP GET
and POST OWS this should be the Capabilities document and for SOAP OWS it should be the WSDL document. Both can be provided via a simple online
document and do not require the client to perform an additional service request. This relaxes the opportunities for bootstrapping a protected OWS. Access to the
Capabilities or the WSDL document can always be unprotected. In case that the service is protected and the user does not have the required rights, he will find out
after the first service execution attempt.
In the end, the group agreed to not use SOAP during the testbed for WFS interactions as the additional features that it could have supported were not required there. The WFS
service that initially only supported SOAP was enhanced to also support KVP and XML based operation invocations.
10.2.3 SOAP Version
When talking about SOAP and support for it by a given web service, it is important to acknowledge that there are two versions of SOAP: 1.1 and 1.2. Communities may require
support for SOAP 1.1 or 1.2 or both or any one of them while allowing the other. There may be different reasons for doing so, such as backwards compatibility or integration
with existing systems. Therefore, OWS standards should be SOAP version agnostic even though usually more options are not favorable for achieving interoperability.
The Sensor Web Enablement 2.0 standards are written in a SOAP version agnostic way. They rely on OWS Common 1.1, which does not specify any requirement regarding
SOAP. In addition, they do not have any requirement that prevents a SWE service from using a particular SOAP version. Other OWS standards used in the OWS-8 Aviation
thread are not SOAP version agnostic:
WCS 2.0 builds upon OWS Common 2.0, which requires SOAP 1.2.
Copyright © 2011 Open Geospatial Consortium,
Inc. All Rights Reserved.
105
WFS 2.0 builds on OWS Common 1.1 which - as said before - does not define SOAP in any way, but the WFS 2.0 specification itself requires SOAP 1.1.
Apparently some harmonization is needed. Until that is achieved, aviation clients may need to support both versions of SOAP in a SOAP based service environment.
10.2.4 Security
The use of SOAP - as a particular format for XML messages exchanged with a network endpoint - provides hooks for enabling metadata with the actual information exchanged
in an interoperable way. One useful way is to use these hooks for including message based security metadata to cope with Integrity, Confidentiality and potentially
Authenticity for the XML encoded information enclosed by the SOAP message tags.
This is important in architectures where there is no direct connection between the service itself and the client that executes the service, because lower ISOOSI stack security
measures such as SSL or TLS only provide a secure communication channel between two machines and not between the actual applications running on it.
Therefore, in a workflow or a real message based system such as an Enterprise Service Bus e.g. SWIM it is important to provide a method that enables securing the exchanged
information the message from one application to another end-to-end. This is achieved by explicitly encrypting a message before it is delivered via the network to the recipient.
However, in an architecture where a Web Browser or a desktop client executes one or multiple services according to the transparent chaining pattern OGC Topic 12, the use
of SOAP does not seem to bring any advantages compared to using an HTTPS HTTP + SSLTLS connection, because the difference between point-to-point and end-to-end is
not meaningful here. It actually tends to be more complex for application and service developers, because the use of secured SOAP messages requires to encrypt and decrypt
each individual requestresponse inside the application compared to simply using the security features that are already provided and automatically handled by the transport
protocol HTTPS.
As encryption based security was not required in OWS-8, the use of SOAP was not necessary. This was also beneficial for the access control use cases, as the PEP did not
need to perform addition processing to unwrap the actual request contained in a SOAP message.
10.2.5 Message Size
Implementers reported a doubling of size of exchanged web service messages when SOAP was used - for example for GetCapabilities requests. Some observations regarding
the statement are listed in the following:
A very basic GetCapabilities request encoded in XML can be very small. The same can be true for other OWS operations. In these cases simply wrapping the
request with a SOAP envelope and body element indeed represents overhead that
