Vladimir Dyuzhev
MockMotor Creator

SOAP Attachments with SWAREF

SWAREF is just SWA with a reference in the payload.

What is SWAREF

Previously I described SOAP with Attachments (SWA) and how to use it in MockMotor, and how MTOM/XOP came to replace it.

However, there was another, less successful attempt to create a better SWA: SWAREF. It is very similar to XOP. However, it is not as flexible.

SWAREF was introduced for WS-I (Interoperability) Attachment Profile. WS-I specifications are to define a set of features that each implementation can safely follow to make sure it can talk to all other implementations.

SWAREF is based on SWA but adds a special element type {http://ws-i.org/profiles/basic/1.1/xsd}swaRef. The element that contains (refers to) the attachment must have this type in the WSDL.

Of course, the custom type is less convenient than the standard xsd:base64Binary that XOP uses.

A SWAREF-enabled WSDL must contain an element with swaRef type, like below:

...
<element name="claimForm" type="wsi:swaRef" xmlns:wsi="http://ws-i.org/profiles/basic/1.1/xsd"/>
...

and then the on-the-wire message would look like this:

MIME-Version: 1.0
Content-Type: Multipart/Related; boundary=----=_Part_5_32550604.1118953563502; type=text/xml
Content-Length: 1193

------=_Part_5_32550604.1118953563502
Content-Type: text/xml; charset=utf-8

<soapenv:Envelope xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/">
    <soapenv:Body>
        <claimForm>cid:b0a597fd-5ef7-4f0c-9d85-6666239f1d25@example.jaxws.sun.com</claimForm>
    </soapenv:Body>
</soapenv:Envelope>

------=_Part_5_32550604.1118953563502
Content-Type: application/pdf
Content-ID: <b0a597fd-5ef7-4f0c-9d85-6666239f1d25@example.jaxws.sun.com>

%PDF-1.7
1308 0 obj
<</Linearized 1/L 643967/O 1314/E 57853/N 5/T 643378/H [ 753 544]>>
...
------=_Part_5_32550604.1118953563502--

As you can see, the message packaging is the same as in SWA (that’s why it is SWA-REF), with the header having text/xml content type.

The attachment element contains a cid: reference to the attachment, just like XOP does.

However, with SWAREF, the parsing code must have access to the WSDL to understand that the claimForm is, in fact, a reference. With XOP, such access is not required because the element name (xop:Include) itself broadcasts its purpose.

How to Generate a SWAREF Response

In MockMotor, creating a SWAREF response is trivial.

1 Configure the attachments in Response Attachments sections.
2 Use MIME/SWA attachment style.
3 In the response body, generate the proper cid: reference for each attachment.

You can generate cid:s for default Content-IDs that MockMotor sets: Content-ID-1, Content-ID-2, and so on.

<soapenv:Envelope xmlns:urn="urn:ClaimSchema" xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/">
   <soapenv:Header/>
   <soapenv:Body>
      <urn:ClaimResponse>
         <Status>SUCCESS</Status>
         <ClaimForm>cid:Content-ID-1</ClaimForm>
      </urn:ClaimResponse>
   </soapenv:Body>
</soapenv:Envelope>

The mock response is configured as below: