The purpose of the information contained on this page is to document the evidence of interoperable implementations required to advance the SOAP 1.2 specifications concerning SOAP message transmission optimization along the W3C's Recommendation track. These specifications are:
The information on this page should not be used to evaluate the implementations outside this context. The information contained on this page is neither suitable nor intended for evaluating the degree to which any of the implementations may or may not conform to the specifications.
Page contents:
| Company/Organisation | Reporting | Implementation Name | Implementation Version | Spec Version/Comment |
|---|---|---|---|---|
| Microsoft | Martin Gudgin | None | None | Endpoint supports CR versions of XOP and MTOM and is located at http://martingudgin-2.dsl.easynet.co.uk/dotnet/mtom/mtomecho.ashx. A description of the endpoint can be found at http://martingudgin-2.dsl.easynet.co.uk/dotnet/mtom/. Contact Martin Gudgin about the endpoint. |
| Canon | Hervé Ruellan | CRF MTOM Implementation | 0.9 | An endpoint is available at http://ws.crf.canon.fr/mtominterop/test. |
| White Mesa | Bob Cunnings | White Mesa Server | 3.0 | Endpoint supports SOAP 1.2, see http://www.whitemesa.net/ for details. |
Table 2 presents the interop traces for each test.
| Test | Description | Interop Traces | Notes |
|---|---|---|---|
| 1a | Send XML, get back MTOM. Single binary part. Limit the number of x:Data elements in the message to 1. | ||
| 1b | Send MTOM, get back XML. Single binary part. Limit the number of x:Data elements in the message to 1. | ||
| 2a | Send XML, get back MTOM. Multiple binary parts. Allow any number of x:Data elements in the message. | ||
| 2b | Send MTOM, get back XML. Multiple binary parts. Allow any number of x:Data elements in the message. | ||
| 3a | Send XML, get back MTOM. Testing xmime:contentType attribute and MIME content-type header. The xmime:contentType header is specified on x:Data elements in an XML message. An MTOM message is returned with the MIME content-type of the binary parts set to the appropriate value. | ||
| 4 | Failure test: Missing MIME part. Send an MTOM message with a xop:Include element that references a non-existent MIME part. A SOAP fault should be returned indicating that the message was in error. | ||
| 5 | Failure test: Use of content-location. Send an MTOM message that references one or more MIME parts by content-location (rather than content-id). A SOAP fault should be returned indicating that the message was in error. | ||
| 6 | Failure test: Use of startinfo parameter that does NOT specify application/soap+xml. Send an MTOM message that uses a startinfo of image/jpeg. A SOAP fault should be returned indicating that the message was in error. | ||
| 7 | Failure test: Use of type parameter on the root part that does NOT specify application/soap+xml. Send an MTOM message that uses a type parameter of image/jpeg for the root part. A SOAP fault should be returned indicating that the message was in error. | ||
| RRSHB 1 |
Request message: node A (client) sends a message to node B (server)
with Resource Representation Header block(s) for the resource
identified by "http://example.org/rrshb/test/data". SOAP Body
consists of the element {http://example.org/rrshb/test}GetResourceRepresentation.
If multiple RRSHB are present in the message they must have different
values for the attribute "xmlmime:contentType".
Response message: node B (server) responds to node A (client) by including all the representations of the resource identified by "http://example.org/rrshb/test/data", in the SOAP Body as the content of the element {http://example.org/rrshb/test}ResourceRepresentation. |
||
| RRSHB 2 | Same as test RRSHB 1 but the request message uses MTOM to optimize all the RRSHB, using xop:Include. | ||
| RRSHB 3 | In this test the SOAP path consists of node A --> node B --> node A. Node B acts as a forwarding intermediary. The message sent from node A to node B is same as in test RRSHB 1, but all the RRSHB headers have the "reinsert" and "relay" attribute with the value of "true". The message sent from node B to node A is same as in test 1, but all the RRSHB headers included in the request message are also present in the response message. | ||
| RRSHB | Demonstrating use of an IRI based identifier for a RRSHB |
Table notes:
David
Fallside, Yves Lafon