Chapter 8. Sending Binary Data Using SOAP with Attachments

download PDF


SOAP attachments provide a mechanism for sending binary data as part of a SOAP message. Using SOAP with attachments requires that you define your SOAP messages as MIME multipart messages.


SOAP messages generally do not carry binary data. However, the W3C SOAP 1.1 specification allows for using MIME multipart/related messages to send binary data in SOAP messages. This technique is called using SOAP with attachments. SOAP attachments are defined in the W3C’s SOAP Messages with Attachments Note.


The WSDL extensions used to define the MIME multipart/related messages are defined in the namespace

In the discussion that follows, it is assumed that this namespace is prefixed with mime. The entry in the WSDL definitions element to set this up is shown in Example 8.1, “MIME Namespace Specification in a Contract”.

Example 8.1. MIME Namespace Specification in a Contract


Changing the message binding

In a default SOAP binding, the first child element of the input, output, and fault elements is a soap:body element describing the body of the SOAP message representing the data. When using SOAP with attachments, the soap:body element is replaced with a mime:multipartRelated element.


WSDL does not support using mime:multipartRelated for fault messages.

The mime:multipartRelated element tells Apache CXF that the message body is a multipart message that potentially contains binary data. The contents of the element define the parts of the message and their contents. mime:multipartRelated elements contain one or more mime:part elements that describe the individual parts of the message.

The first mime:part element must contain the soap:body element that would normally appear in a default SOAP binding. The remaining mime:part elements define the attachments that are being sent in the message.

Describing a MIME multipart message

MIME multipart messages are described using a mime:multipartRelated element that contains a number of mime:part elements. To fully describe a MIME multipart message you must do the following:

  1. Inside the input or output message you are sending as a MIME multipart message, add a mime:mulipartRelated element as the first child element of the enclosing message.
  2. Add a mime:part child element to the mime:multipartRelated element and set its name attribute to a unique string.
  3. Add a soap:body element as the child of the mime:part element and set its attributes appropriately.


    If the contract had a default SOAP binding, you can copy the soap:body element from the corresponding message from the default binding into the MIME multipart message.

  4. Add another mime:part child element to the mime:multipartReleated element and set its name attribute to a unique string.
  5. Add a mime:content child element to the mime:part element to describe the contents of this part of the message.

    To fully describe the contents of a MIME message part the mime:content element has the following attributes:

    Table 8.1. mime:content Attributes
    AttributeDescription +


    Specifies the name of the WSDL message part, from the parent message definition, that is used as the content of this part of the MIME multipart message being placed on the wire.



    The MIME type of the data in this message part. MIME types are defined as a type and a subtype using the syntax type/subtype.


    There are a number of predefined MIME types such as image/jpeg and text/plain. The MIME types are maintained by the Internet Assigned Numbers Authority (IANA) and described in detail in Multipurpose Internet Mail Extensions (MIME) Part One: Format of Internet Message Bodies and Multipurpose Internet Mail Extensions (MIME) Part Two: Media Types.


  6. For each additional MIME part, repeat steps [i303819] and [i303821].


Example 8.2, “Contract using SOAP with Attachments” shows a WSDL fragment defining a service that stores X-rays in JPEG format. The image data, xRay, is stored as an xsd:base64binary and is packed into the MIME multipart message’s second part, imageData. The remaining two parts of the input message, patientName and patientNumber, are sent in the first part of the MIME multipart image as part of the SOAP body.

Example 8.2. Contract using SOAP with Attachments

<?xml version="1.0" encoding="UTF-8"?>
<definitions name="XrayStorage"

  <message name="storRequest">
    <part name="patientName" type="xsd:string"/>
    <part name="patientNumber" type="xsd:int"/>
    <part name="xRay" type="xsd:base64Binary"/>
  <message name="storResponse">
    <part name="success" type="xsd:boolean"/>

  <portType name="xRayStorage">
    <operation name="store">
      <input message="tns:storRequest" name="storRequest"/>
      <output message="tns:storResponse" name="storResponse"/>

  <binding name="xRayStorageBinding" type="tns:xRayStorage">
    <soap:binding style="document" transport=""/>
      <operation name="store">
      <soap:operation soapAction="" style="document"/>
      <input name="storRequest">
          <mime:part name="bodyPart">
            <soap:body use="literal"/>
          <mime:part name="imageData">
            <mime:content part="xRay" type="image/jpeg"/>
      <output name="storResponse">
        <soap:body use="literal"/>

  <service name="xRayStorageService">
    <port binding="tns:xRayStorageBinding" name="xRayStoragePort">
      <soap:address location="http://localhost:9000"/>
Red Hat logoGithubRedditYoutubeTwitter


Try, buy, & sell


About Red Hat Documentation

We help Red Hat users innovate and achieve their goals with our products and services with content they can trust.

Making open source more inclusive

Red Hat is committed to replacing problematic language in our code, documentation, and web properties. For more details, see the Red Hat Blog.

About Red Hat

We deliver hardened solutions that make it easier for enterprises to work across platforms and environments, from the core datacenter to the network edge.

© 2024 Red Hat, Inc.