Skip to main content

More on JAXWS and WSIT MTOM interoperability ...

Posted by vivekp on May 18, 2006 at 8:18 AM PDT


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...

Related Topics >>