JBWS-1464 - Adding MTOM support to WSDL To Java - Design

[dlofthouse]

This thread is to discuss the options for adding MTOM support to WSDL To Java.

There are a number of options for how this can be implemented and a number of obstacles to overcome for the more advanced implementations. The main obstacle is that it is not possible to get access to the expectedContentTypes attribute using the xerces schema API.

On the plus side there currently does not apear to be any work required on generating the JAX RPC mapping file, this just requires a variable mapping (which does not contain type information) in the corresponding java-xml-type-mapping. This mapping is already correctly generation.

At the moment I see the following options for how this could be implemented: -

1 - Map all binary types to javax.activation.DataHandler

A global configuration option can be set to switch on MTOM mapping and all types that are based on xs:base64Binary or xs:hexBinary can be mapped to javax.activation.DataHandler.

2 - Global configuration to specify what binary types should be mapped to.

A global configuration option can be added to specify what the binary types should be mapped to. This would assume all binary types can be mapped to the same type.

3 - Allow configuration to map XML types to specific Java types.

This would mean if the schema contains different types based off the binary types then it will be possible for each to be mapped to a different Java type.

This would however not work when the binary types are mapped as follows as it will not be possible to differentiate between them: -

<element name="legacyData"
 xmime:expectedContentTypes="text/xml"
 type="xmime:base64Binary"/>

4 - A more advanced configuration to allow the specific elements to be identified.

 <complexType name='Employee'>
 <sequence>
 <element name="firstname" type="xsd:string"/>
 <element name="lastname" type="xsd:string"/>
 <element name="legacyData" xmime:expectedContentTypes="text/xml"
 type="xmime:base64Binary"/>
 </sequence>
 </complexType>

So for this example the configuration would allow the user to specify that the element legacyData of the type Employee should be mapped to a specific Java type.

5 - Switch on generation of synthetic annotations.

The xerces implementation has a feature that can be enabled to generate a synthetic annotation when a schema component has non-schema attributes. This annotation could then be parsed to extract the expectedContentTypes. This of course would be xerces implementation specific.

An appropriate Java type can then be selected based on the list of content types.

6 - Add a pre-generation step to read mime information from the WSDL

Add a step before generation to read all expectedContentTypes from the schema (Possibly using the synthetic annotations approach), this will store the data in a model - as part of the main generation step this model can be read if a binary type is found to check if mime types have been specified.

[noel.rocher]

1 - Map all binary types to javax.activation.DataHandler

A global configuration option can be set to switch on MTOM mapping and all types that are based on xs:base64Binary or xs:hexBinary can be mapped to javax.activation.DataHandler.

I see base64Binary data that should not be considered as attachment. It's a type that is often used for IDs. For exemple, you can have an operation with an ID as argument and an attachment as a result.

[noel.rocher]

In practice, we should make simple for users to generate a wsdl. What they are used to do today when the wsdl is not trivial :

- write a java interface that is a copy of the SEI but with all attachment params replaced with String params.
- generate the wsdl with wtools from this interface
- make simple changes to wsdl to replace string type by what is required for wstools to detect attachments
- test if client side is correctly generated from this wsdl
- test if the server side is working with this stubs calls

[dlofthouse]

The process of generating the WSDL from the SEI is covered by a separate Jira task: -
http://jira.jboss.com/jira/browse/JBWS-1466

[heiko.braun]

I would favour point (1). This is what i communicated to the users already. It's simple and fits the overall problem the best. There is many cases where

a) you dont know the exact mimetype
b) data is send inlined
c) you need to pass the content type along

DataHandler is the best chioce IMO.

Regarding Noel's considerations:

I see base64Binary data that should not be considered as attachment. It's a type that is often used for IDs. For exemple, you can have an operation with an ID as argument and an attachment as a result.

It's right what you are saying, but in the only (rare) case this becomes a problem is when users types contain base64 types that should be optimized and others that shouldnt at the same time. If this doesnt occur on the same payload then you easily turn off MTOM for that port.

On the otherhand, if you want to meet that rare case a treshold switch should be used to decide at runtime wether or not optimization should be done.

This is a good idea in many cases, because MTOM optimization does pay off only when data reaches several kb.

[noel.rocher]

It's right what you are saying, but in the only (rare) case this becomes a problem is when users types contain base64 types that should be optimized and others that shouldnt at the same time. If this doesnt occur on the same payload then you easily turn off MTOM for that port.

I don't see it as "rare" if you consider that customers are using it as an ID type.

I'm talking about big WS users with a lot of webservices (several hundreds) where using attachment or not is an implementation detail (in fact, it's an optimisation required to have decent response times). What they need is to a natural set of functional operations. It's not a good practice to break this for technical reason.

[jason.greene]

The other problem is that even if the correct type is chosen by tools (say Image), the runtime also needs to know, so JBossXB needs to see the schema annotation as well. JBossXB currently uses xerces as well (although it has an intermediary model) so whatever mechanism would have to be aplied there.

It might make more sense to keep partial support, and assume certain mime types, and encourage people that need more to upgrade to JAX-WS, or use AP 1.0 instead of MTOM (which doesnt have this problem since it's in the WSDL).

-Jason