JBWS-1260 - such a part must refer to an element named after

[dlofthouse]

From the JAX-RPC specification, in the list of three requirements that need to be met for a message to be unwrapped: -

such a part must refer to an element named after the operation

How inportant is this requirement when deciding about unwrapping? This line does not indicate if it refers to the input or output messages? Unless they are different namespaces or the same element is referenced it is not possible for both to be named after the operation.

Or is it sufficient for the name of the element to contain or start with the name of the operation?

[jason.greene]

I would follow the JAX-WS convention, which is that only the input element needs to match the operation.

[thomas.diesler]

This also relates to

http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4000809#4000809

Is request message element to operation name equivalents a general requirement for doc/lit? Does the BP say anything about it?

[dlofthouse]

BP only mentions a naming requirement for the wrappers for RPC, for document it just says that each operation must have a unique signature so that they can be identified.

It is the JAX-RPC spec and JAX-WS spec that specified requirements that must be met for an operation to be considered a wrapped operation.

From JAX-RPC 6.4.1: -

In order to qualify as using the ?wrapper? style, an operation must fulfill the following
conditions:
? its input and output messages (if present) must contain exactly one part;
? such a part must refer to an element named after the operation;
? such an element (a wrapper) must be of a complex type defined using the
xsd:sequence compositor and containing only elements declarations.

From JAX-WS 2.3.1.2 this is refined slightly: -

A WSDL operation qualifies for wrapper style mapping only if the following criteria are met:
(i) The operation?s input and output messages (if present) each contain only a single part
(ii) The input message part refers to a global element declaration whose localname is equal to the operation
name
(iii) The output message part refers to a global element declaration
(iv) The elements referred to by the input and output message parts (henceforth referred to as wrapper
elements) are both complex types defined using the xsd:sequence compositor
(v) The wrapper elements only contain child elements, they must not contain other structures such as
wildcards (element or attribute), xsd:choice, substitution groups (element references are not permitted)
or attributes; furthermore, they must not be nillable.

[thomas.diesler]

In that case a wsdl like this

 <types>
 <schema ...>
 <complexType name="paraListType">
 <sequence>
 <element name="username" type="string" nillable="true"/>
 <element name="password" type="string" nillable="true"/>
 <element name="operationName" type="string" nillable="true"/>
 <element name="inputXML" type="string" nillable="true"/>
 </sequence>
 </complexType>
 <complexType name="responseType">
 <sequence>
 <element name="result" type="string" nillable="true"/>
 </sequence>
 </complexType>
 <element name="paraList2" type="tns:paraListType"/>
 <element name="responseXML" type="tns:responseType"/>
 </schema>
 </types>
 <message name="attachRequest">
 <part name="parameters" element="ns2:paraList2"/>
 <part name="attachmentContents" type="xsd:string"/>
 </message>
 <message name="attachResponse">
 <part name="result" element="ns2:responseXML"/>
 </message>
 <portType name="TransmulatorInterface">
 <operation name="invokeAttach">
 <input message="tns:attachRequest"/>
 <output message="tns:attachResponse"/>
 </operation>
 </portType>

should work and the generated java method name should be paraList2 instead of invokeAttach.

AFAICS the requriment pertains only the the java realm and not to the abstract contract in wsdl.

[dlofthouse]

I am not sure if that is the case, this requirement is described within chapter 2 of the JAX-RPC specification and the purpose of this chapter is to describe how to generate the service endpoint interface from the WSDL.

Also the terminology used is WSDL terminology, they are saying the element must be named after the operation not that the parameter must be named after the method. When refering to java methods and parameters they do refer to them as methods and parameters.

So I am interpreting it as: -

When you are generating a SEI from a WSDL
If the operation meets these requirements you can treat it as wrapped an unwrap it.

Having said that this check was one of the last checks I added just to be complete with the list of requirements in the spec so there shouldn't be a problem if it is removed.

Looking at your WSDL your message 'attachRequest' contains two message parts so based on the first requirement for a message to contain only a single part this should also be rejected so I am surprised you are not seeing that - I will have a look and see what happened to that check.

[dlofthouse]

I can't reproduce the error you are seeing if my WSDL contains messages with 2 parts, instead I get the following error reported: -

[junit] org.jboss.ws.WSException: Only Request-Only and Request-Response MEPs are allowed
[junit] at org.jboss.ws.metadata.wsdl.WSDLUtils.getWsdl11Input(WSDLUtils.java:885)
[junit] at org.jboss.ws.tools.WSDLToJava.appendMethods(WSDLToJava.java:287)
[junit] at org.jboss.ws.tools.WSDLToJava.createSEIFile(WSDLToJava.java:588)
[junit] at org.jboss.ws.tools.WSDLToJava.createSEI(WSDLToJava.java:618)
[junit] at org.jboss.ws.tools.WSDLToJava.generateSEI(WSDLToJava.java:187)
[junit] at org.jboss.ws.tools.helpers.ToolsHelper.handleWSDLToJavaGeneration(ToolsHelper.java:304)
[junit] at org.jboss.ws.tools.WSTools.process(WSTools.java:138)

I think this check was part of some refactoring that happened on trunk.

[jason.greene]

In that case a wsdl like this

should work and the generated java method name should be paraList2 instead of invokeAttach.

Thats incorrect. The generated java method name (unless customized) always matches the operation name, it never matches the element name. Also it does not adhere to the wrapped convention so it must be treated as a bare parameter style service.

Also, this WSDL violates BP 1.0 because it uses "type" on the part definition for a document/literal web service. It must be element.

<part name="attachmentContents" type="xsd:string"/>

[jason.greene]

In that case a wsdl like this
AFAICS the requriment pertains only the the java realm and not to the abstract contract in wsdl.

This is not in the BP since it only governs existing specifications namely WSDL 1.1, which does not have a mechanism to express this convention.

The whole reason for the wrapped convention, is to fix the RPC style in WSDL 1.1 by overlaying the RPC requirements on top of a document/literal service. (This is the source of the operation name match requirement). So the intention is that a server component using the wrapped convention would provide hints to any client so that it would use this style as well. However since a WSDL extension was not introduced, the service still works with any thing that understands document/literal (since it is just a convention). So, by design, the wrapped convention is more restrictive than a normal document/literal bare service.

The problem was fully addressed in WSDL 2.0, where the wrapped convention became the new RPC style. So, in WSDL 2.0, all of these rules and restrictions you see are officially part of the spec.

[jason.greene]

I am not sure if that is the case, this at your WSDL your message 'attachRequest' contains two message parts so based on the first requirement for a message to contain only a single part this should also be rejected so I am surprised you are not seeing that - I will have a look and see what happened to that check.

The rule is that it must contain only one part that is bound to body of the message. The service can still contain additional parts if the extra parts are bound to an attachment or a header.

[jason.greene]

Also, this WSDL violates BP 1.0 because it uses "type" on the part definition for a document/literal web service. It must be element.

<part name="attachmentContents" type="xsd:string"/>

Note, this comment is wrong, the AP 1.0 spec allows type or element. BP 1.0 only governs the standard SOAP binding not the MIME binding.