[TUSCANY-2992] For binding.jms wireFormat.jmsdefault, consider smoothing over elementFormDefault differences

• Type: Improvement
• Status: Open
• Priority: Minor
• Resolution: Unresolved
• Component/s: Java SCA JMS Binding Extension
• Assignee: Unassigned
• Reporter: Scott Kurz
• Created: 27/Apr/09 13:25
• Updated: 27/Apr/09 13:25

Description

So another area where this wF.jmsdefault behavior of unwrapping a single input/output gets tricky is with respect to elementFormDefault, and let me bring up another area to consider.

Consider the wrapped case, either top-down <interface.wsdl> or bottom-up <interface.java> - (the default in the absence of JAX-WS annotations being to treat Java as wrapped.)

While, (according to the JMS binding spec's description of the default WF), we have to read or write the wrapper's single child, the schema-defined element in play is actually the operation-level wrapper element. The wrapper element's schema's elementFormDefault, then, will intersect with whether our child element is NS-qualified or not.

When serializing (request or response), the thing to do seems simple enough: use the elementFormDefault of the wrapper elem definition to decide whether to serialize the child element with a NS ("qualified") or without a NS ("unqualified", the default).

So for:

<wsdl:types>
<schema elementFormDefault="qualified" xmlns:tns="http://test" targetNamespace="http://test" ...>

<element name="myOperation">
<complexType>
<sequence>
<element name="arg1" type="xsd:int"/>
</sequence>
</complexType>
</element>

we serialize:
<tns:arg1>4</tns:arg1>

whereas if we change the schema to elementFormDefault="unqualified" (note this is the default for bottom-up generated schemas as well)

we serialize:
<arg1>4</arg1>

Seems simple enough, but what about deserialization?

One approach would be to require the "other side" to understand the viewpoint of the SCA runtime doing the deserialization and whether or not the SCA runtime expects qualified or unqualified child elements (this is how our code is implemented today).

According to this approach, receiving a JMS payload like:
<tns:arg1>4</tns:arg1>

together with a service described by interface.java method such as:

void myOperation(int x);

would be a user error. The Java, absent JAXB annotations, maps to a schema with elementFormDefault="unqualified", and so we can't handle such a payload.

An alternative approach would be to implement deserialization such that it could smooth over differences in elementFormDefault, i.e. handle either the unexpected presence or absence of a NS by ignoring or adding the NS as necessary. (Even then we could ask: should a NS that's present but incorrect also be smoothed over (ignored)?)

Do we agree this change would be desirable?

I wish I had more sense of how useful in practice this change would be. Not knowing that, at least opening the issue reminds us the issue exists, for later when someone asks why their data is null (as this is what happens in JAXB when you get the elemFormDefault incorrect).