MTOM Support on the WSDL Level

To enable MTOM, the slight modification of WSDL file is needed.

<schema targetNamespace="http://pictures.com"
  xmlns:xsd="http://www.w3.org/2001/XMLSchema">
  <element name="Picture">
    <complexType>
      <sequence>
        <element name="Title" type="xsd:string"/>
        <element name="ImageData" type="xsd:base64Binary"/>
      </sequence>
    </complexType>
  </element>
</schema>

...is going to change to:

<schema targetNamespace="http://pictures.com"
  xmlns:xsd="http://www.w3.org/2001/XMLSchema"
  xmlns:xmime="http://www.w3.org/2005/05/xmlmime">
  <element name="Picture">
    <complexType>
      <sequence>
        <element name="Title" type="xsd:string"/>
        <element name="ImageData" type="xsd:base64Binary"
           xmime:expectedContentTypes="application/octet-stream"/>
      </sequence>
    </complexType>
  </element>
</schema>

(Source: http://cxf.apache.org/docs/mtom-attachments-with-jaxb.html)

In other words, only new xml attribute expectedContentTypes from namespace with URI http://www.w3.org/2005/05/xmlmime is set to the value application/octet-stream.

Affected API-M Methods

ingest
getObjectXML
export (response)
modifyDatastreamByValue

There is little discrepancy&nbsp;between _API-M_ WSDL definition of method&nbsp;_modifyDatastreamByValue_ and it's web definition on ([https://wiki.duraspace.org/display/FCR30/API-M#API-M-modifyDatastreamByValue|https://wiki.duraspace.org/display/FCR30/API-M#API-M-modifyDatastreamByValue]). WSDL says attribute&nbsp;_dsContent_ is of type *byte\[\]*, but web says String. I suppose, the *byte\[\]* as the correct type.

Affected API-A Methods

getDatastreamDissemination

Methods marked as <span style="color: #ff0000">red</span> has an input parameter of type *byte\[\]* and <span style="color: #0000ff">blue</span> methods has output value of type *byte\[\]*.

Changes to WSDL

Since API-A and API-M wsdl files both use the include directive inside their <types> element, the changes will be made only to fedora-types.xsd.

Two sides of MTOM

MTOM can be enabled on both the client and the server side. If it is done on the client side, then the SOAP requests with binary data are "MTOMized" and if it is done on the server side, then the responses are. So far, it seems that either client or server (generated by CXF) can handle both MTOM (multipart/related) and non-MTOM (text/xml) SOAP messages in runtime without knowing in advance what type should be received. I am affraid that some old WS client won't be able to provide such a functionality, therefore new set of methods with MTOM support has to be created in order not to break backward compatibility wtih MTOM clients not understanding the MTOM/XOP coding. Another backward compatible solution could be for instance to return MTOMed message if and only if there is some special attribute in HTTP header of SOAP request, however, I haven't found how to change this behaviour of WS programmatically in runtime.

Also there might be some complication with this issue http://stackoverflow.com/questions/2808967/mtom-request-non-mtom-response. I haven't tried it yet, and, hopefully, CXF don't have such problem.