|
The following settings are available on the Advanced
tab:
Allow RPC Schema Validation:
When the Allow RPC Schema Validation checkbox is
checked, the filter will make a best attempt to
validate an RPC encoded SOAP message. An RPC encoded message is defined
in the WSDL as having an operation with the following characteristics:
-
The style attribute of the <soap:operation>
element is set to "document".
-
The use attribute of the <soap:body>
element is set to "rpc".
Take a look at Section
3.5 of the WSDL specification, which explains the possible
values for these attributes.
The problem with RPC encoded SOAP messages in terms of schema validation
is that the schema contained within the WSDL file does not necessarily
fully define the format of the SOAP message, unlike with
"document-literal" style messages, for example. With an RPC encoded
operation, the format of the message can be defined by a combination of
the SOAP operation name, WSDL message parts, and schema-defined types.
As a result, the Schema extracted from a WSDL file may not be able to
validate a message.
Another problem with RPC encoded messages is that type information is
included in each element that appears within the SOAP message. In order
for such element definitions to be validated by a schema, the type
declarations must be removed, which is precisely what the
Schema Validation filter does if the checkbox is checked
on this tab. It removes the type declarations and then makes a
best attempt to validate the message.
However, as
explained earlier, if some of the elements in the SOAP message are
actually taken from the WSDL file as opposed to the Schema (for example,
when the SOAP operation name in the WSDL file is used as the wrapper
element beneath the SOAP Body as opposed to a schema-defined type), the
schema will not be able to validate the message.
Inline MTOM Attachments into Message:
MTOM (Message Transmission Optimization Mechanism) provides a way to
send binary data to Web Services within standard SOAP messages. MTOM
leverages the include mechanism defined by XOP (XML Optimized Packaging)
whereby binary data can be send as a MIME attachment (similar to SOAP
with Attachments) to a SOAP message. The binary data can then be
referenced from within the SOAP message using the <xop:Include>
element.
The following SOAP request contains a binary image that has been
base64-encoded so that it can be inserted as the contents of the
<image> element:
|
| | |
|
<?xml version="1.0" encoding="UTF-8"?>
<soap:Envelope xmlns:soap="http://schemas.xmlsoap.org/soap/envelope/">
<soap:Body>
<uploadGraphic xmlns="www.example.org">
<image>/aWKKapGGyQ=</image>
</uploadGraphic>
</soap:Body>
</soap:Envelope>
| |
| | |
|
When this message s converted to an MTOM message by the Enterprise Gateway
(for example, using the Extract
MTOM Content filter)
the base64-encoded content from the <image> element is replaced with
an <xop:Include> element. This contains a reference to a newly
created MIME part that contains the binary content. The following
request shows the resulting MTOM message:
|
| | |
|
POST /services/uploadImages HTTP/1.1
Host: SOAPbox
Content-Type: Multipart/Related;boundary=MIME_boundary;
type="application/xop+xml";
start="<mymessage.xml@example.org>";
start-info="text/xml"
--MIME_boundary
Content-Type: application/xop+xml;
charset=UTF-8;
type="text/xml"
Content-Transfer-Encoding: 8bit
Content-ID: <mymessage.xml@example.org>
<?xml version="1.0" encoding="UTF-8"?>
<soap:Envelope xmlns:soap="http://schemas.xmlsoap.org/soap/envelope/">
<soap:Body>
<uploadGraphic xmlns="www.example.org">
<image>
<xop:Include xmlns:xop='http://www.w3.org/2004/08/xop/include'
href='cid:http://example.org/myimage.gif'/>
</image>
</uploadGraphic>
</soap:Body>
</soap:Envelope>
--MIME_boundary
Content-Type: image/gif
Content-Transfer-Encoding: binary
Content-ID: <http://example.org/myimage.gif>
// binary octets for image
--MIME_boundary
| |
| | |
|
When attempting to validate the MTOM message with an XML Schema, it is
crucial that you are aware of the format of the <image> element.
Will it contain the base64-encoded binary data, or will it contain the
<xop:include> element with a reference to a MIME part.
For example, the XML Schema definition for <image> element might
look like this:
|
| | |
|
<xsd:element name="image" maxOccurs="1" minOccurs="1"
type="xsd:base64Binary"
xmime:expectedContentTypes="*/*"
xsi:schemaLocation="http://www.w3.org/2005/05/xmlmime"
xmlns:xmime="http://www.w3.org/2005/05/xmlmime"/>
| |
| | |
|
In this case, the XML Schema validator will expect the contents of the
<image> element to be base64Binary. However,
if the message has been formatted as an MTOM message, the <image>
element will contain a child element, <xop:Include> that the Schema
know nothing about. This will, of course, cause the schema validator to
report an error and the schema validation will fail.
To resolve this issue, you can check the
Inline MTOM Attachments into Message checkbox on the
Advanced tab. At run-time, the schema validator will
replace the value of the <xop:Include> element with the
base64-encoded contents of the MIME part to which it refers. This means
that the message will now adhere to the definition of the <image>
element in the XML Schema, i.e. the element will contain data of type
base64Binary.
This standard procedure of interpreting XOP messages is described in
Section 3.2 Interpreting XOP Packages of the XML-binary Optimized
Packaging (XOP) specification.
|