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