MTOM/XOP considerations

[heiko.braun]

When looking at our current MTOM/XOP implementation i see it tightly coupled to our SOAP object model (saaj and SOAPContentElement). The specs refer to an 'Outbound' and 'Inbound' message representation, aka the optimized (XOP package) and the original SOAP message. From my point of view XOP processing could be regarded as some (optional) pre- and post processing of the SOAP message and thus it shouldn't be coupled to the internal object model.

This would mean that internally a binary would still be represented as a xsd:base64Binary type and thus the binding layer and our internal model remain untouched.

Still we could think if xsd:base64Binary should use DataHandler instances as the preferred structure between the binding layer and an endpoint.

Once we move to JAXB 2.0 we can still think about further enhancements.

Would this be a feasible approch to complete our MTOM impl. or do i miss something here?

[heiko.braun]

Jason says:

Hello,

Should a JAX-WS handler ever see the XOP infoset? The spec does not clarify this, and the RI seems to have contradicting behavior (outbound messages are prevented from being xop encoded if there is a handler, inbound messages are left as is).

Since the XOP specification mentions that conceptual form is an XML infoset with base64 elements, it seems that the correct behavior is that a handler should not see the XOP infoset. This is especially important when using encryption and/or signature processing.

If it is clarified and decided that JAX-WS handlers should see the conceptual XML infoset, then this raises two other questions:

1. Should attachments still be visible as AttachmentPart(s) on SOAPMessage?
- It would be more efficient to leave them, however this introduces
a consistency problem. For example, technically a handler has the
ability to update either the base64 value or the attachment itself.
2. Should XOP processing still be done, but this time after handlers are processed?

[heiko.braun]

From the specs (http://www.w3.org/TR/xop10/):

However, at the conceptual level, this binary data can be thought of as being base64-encoded in the XML Document. As this conceptual form might be needed during some processing of the XML Document (e.g., for signing the XML document), it is necessary to have a one to one correspondence between XML Infosets and XOP Packages. Therefore, the conceptual representation of such binary data is as if it were base64-encoded, using the canonical lexical form of XML Schema base64Binary datatype (see [XML Schema Part 2: Datatypes Second Edition] 3.2.16 base64Binary). In the reverse direction, XOP is capable of optimizing only base64-encoded Infoset data that is in the canonical lexical form.

[heiko.braun]

Looking at the above statement I'd say a handler should see the conceptual level, that is the base64 representation without an actual attachment visible at the message level. It's arguable though if a handler needs mutable access to that data.

[jason.greene]

The question was sent to the JAX-WS list, since this is a deficiency of the spec.