More on JAXWS and WSIT MTOM interoperability ...

In my previous blog I talked about the latest MTOM work I am doing in JAXWS 2.0.1 EA. As you already know that JAXWS 2.0.1 EA with WSIT jars enable WS-* supports, such as WS-Addressing, WS-Reliable Messaging, WS-Security etc.

So what that extra interoperability MTOM feature in JAXWS 2.0.1 EA will bring in when used with or without WSIT?

• MTOM enabled client/endpoint always sends MTOM encoded message

In JAXWS 2.0 FCS, when MTOM is enabled the MTOM encoding takes place only when the message has binary data and its size is greater  than the MTOM threshold value. The fact that WCF MTOM enabled client/endpoint expects the message to always be MTOM encoded whether the message has binary data or not, this requires JAXWS 2.0 FCS client/endpoints to always set their threshold value to set to 0 in-order to interoperate with WCF.

In JAXWS 2.0.1 EA, as part of re-architecting the MTOM encoding we found that to keep the previous behavior we need to process the message completely. This required buffering the entire message and the cost saved was only encoding/decoding of Content-Type as per MTOM spec. The buffering is expensive so we decided not do it in JAXWS 2.0.1 EA.  Now if MTOM is enabled, the MTOM encoding of Content-Type always takes place irrespective of the binary size or MTOM threshold value.  This makes MTOM interop

• MTOM policy assertion in the published WSDL

  JAXWS 2.0 FCS MTOM enabled service has no way to say in the published WSDL (WSDL 1.1) that MTOM is enabled. For this to work and interoperate correctly with a WCF client, developer has to use WCF defined mechanism to enable MTOM explicitly. This was a pain and not intuitive as the described service has no direct way to tell that it expects/sends MTOM messages.

  JAXWS 2.0.1 EA with WSIT inserts appropriate MTOM policy assertion in the published WSDL for an MTOM enabled endpoint. This allows a WCF client to automatically interoperate with the endpoint.

  The MTOM policy assertion in the published WSDL would appear as:

  <wsp:Policy wsu:Id="BasicHttpBinding_IMtomTest_policy">
    <wsp:ExactlyOne>
        <wsp:All>
            <wsoma:OptimizedMimeSerialization xmlns:wsoma="http://schemas.xmlsoap.org/ws/2004/09/policy/optimizedmimeserialization" />
        </wsp:All>
    </wsp:ExactlyOne>
</wsp:Policy>

• MTOM policy assertion aware JAXWS 2.0.1 EA

  WCF endpoints publish MTOM endpoint WSDL with MTOM policy assertion, so if you're writing a JAXWS 2.0.1 EA client, run wsimport on the WCF endpoint's WSDL and write your application against the generated Service Endpoint Interface class and you're good to go.

• Secure MTOM

MTOM feature is architected in such a way that message processing layers are agnostic of it. for example security Pipe doesn't need to be aware of MTOM. This allows a Secure MTOM endpoint to interoperate well with  WCF Secure MTOM client/endpoint. I would write more on it in my next or latter blogs.

Checkout jaxws and wsit projects and stay tuned...