Vladimir Dyuzhev, author of MockMotor

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 also 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. The idea of WS-I specifications is 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.

The custom type is, of course, 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>

Test Project

I have created a test SWAREF mock service for this post. The service is included with MockMotor downloadable package and also can be accessed at the Demo Site. You can download the corresponding WSDL and the SoapUI project below.

Download WSDL and SoapUI Project  

Please Share

Was this post useful? Then please share! Tweet This