Databases Reference
In-Depth Information
Another minor issue with document/literal is that it doesn't contain the operation
name in the SOAP message, which can make dispatching of messages difficult in
some scenarios and can also make debugging complicated when monitoring SOAP
traffic, particularly when multiple operations contain the same parameters.
Use Document (literal) wrapped
Document Wrapped is a particular style or use of Document/literal that
addresses these issues. With this approach, the request and response parameters
for an operation are 'wrapped' within a single request and response element.
The request wrapper must have the same name as the corresponding operation,
while the name of the response wrapper is derived by appending 'Response' to the
operation name.
This ensures that the SOAP body only contains a single nested element whose name
matches that of the operation.
These wrapping elements must be defined as elements, not complex types. While
WSDL allows either, the use of
complexTypes
is not WS-I compliant.
This approach ensures that you have WS-I compliant messages.
A document wrapped web service looks very similar to a RPC/literal
style, as they both produce a SOAP message containing a single nested
element matching the name of the operation within the
soap:Body
.
Building your abstract WSDL document
Once we have standardized on the document wrapped pattern, we can define the
abstract part of our WSDL contract at this stage, without having to worry about the
actual binding.
WSDL namespace
As with our schema definitions, we need to define a namespace for our business
service. Here we would recommend defining a different namespace for each
service. This should also be different from the namespaces used within your
canonical model.
