We recently found an issue with MTOM handling in OpenESB 2.2. Where MTOM encoded response was not been send to client as response. I am writing this blog to give the problem in general we might face when we work with MTOM in OpenESB httpbc and a workaround.

What is MTOM: (Message Transmission Optimization Mechanism)

MTOM is the W3C Message Transmission Optimization Mechanism, a method of efficiently sending binary data to and from Web services.

Normally when we send the SOAP response from the web service, where base64 attachment is there in response. SOAP response will include the base64 string as inline. As follows

<S:Envelope xmlns:S="http://schemas.xmlsoap.org/soap/envelope/">
  <S:Body>
    <ns2:downloadImageResponse xmlns:ns2="http://ws.mkyong.com/">
      <return>fsf33089f!ksfof......</return>
    </ns2:downloadImageResponse>
  </S:Body>
</S:Envelope>

Above response is good for small attachment, where payload is less, but some time base64 is not the perfect way for responding larger binary data.

With MTOM, the above response will look like :

<S:Envelope xmlns:S="http://schemas.xmlsoap.org/soap/envelope/">
  <S:Body>
    <ns2:downloadImageResponse xmlns:ns2="http://ws.mkyong.com/">
      <return>
        <xop:Include xmlns:xop="http://www.w3.org/2004/08/xop/include" href="cid:012eb00e-9460-407c-b622-1be987fdb2cf@example.jaxws.sun.com">
        </xop:Include>
      </return>
    </ns2:downloadImageResponse>
  </S:Body>
</S:Envelope>
//Binary content
--uuid:c73c9ce8-6e02-40ce-9f68-064e18843428Content-Id: <012eb00e-9460-407c-b622-1be987fdb2cf@example.jaxws.sun.com>
Content-Type: image/png
Content-Transfer-Encoding: binary

As you can see it will have xop XML-Binary Optimized Packaging (XOP) technique : which is more appropriate standard for web service response with attachment.

For more detail you can read it online specification and examples, there are lot of material present there in detail.

Using MTOM in OpenESB

There could be two scenario while uisng MTOM in Composite Application

1. ExternalClient ————–>htttpbc————>bpel( or any JBI Component)
2. bpel( or any JBI Component)———>httpbc———–>ExternalWebservice

The first scenario works fine where httpbc is provisioning the service, However the second scenarion in which  an user want to use MTOM while making an Outgoing CALL (invoking external web service ) httpbc———>ExternalWebservice , then it does not work , i.e the data is not sent as an attachment ( rather gets inlined)  though the wsdl policy specifies the mtom policy. This is due to a limitation in the jax-ws dispatch API which is used the httpbc to invoke an webservice external to the composite application , The solution is that case is to use Soap With Attachment

There is an excellent workaround for this problem, where you don’t need to modify metro version of glassfish. You can achieve this MTOM encoded response using SOAP Handler and configure your Composite Application to use the SOAP Handler. This can be done in following simple steps.

Step-1 :  Write a SOAPHandler that can read the inline base64 content, convert it into binary data and Attach this binary as multipart attachment, which reference from xop:include node in SOAP body of response.  (PFA RequestHandler Project)

Step-2 : Configure the OpenESB to use above Request Handler

Right Click on CASA editor SOAP binding -> Properties

Click on JAX-WS Notification

Click on ADD and Select the Request Handler Compiled Jar path, OpenESB automatically detect the SOAP Handler in add in List. As shown below

We have logged a bug in OpenESB to be correct in future version.

Now I hope, this problem is solved properly.

Cheers,

Param