[BEEHIVE-746] WSDL generated for headers inconsistent with JSR 181 spec

• Type: Bug
• Status: Closed
• Priority: Major
• Resolution: Fixed
• Affects Version/s: V1Beta
• Fix Version/s: v1m1
• Component/s: Web Services (181)
• Environment: Beehive SVN 170442
• Assignee: daryoush mehrtash
• Reporter: Jeremiah Johnson
• Created: 17/May/05 18:46
• Updated: 19/May/05 03:42
• Resolved: 19/May/05 03:42

Description

There is an example in the JSR 181 spec in section 5.4.1.3 and another in section 9.1.1 showing an annotated Web service and the expected resulting WSDL. In both cases, a specific message element represents the header field and a specific message element represents the other parameters. The WSM implementation takes a different route and maps all parameters, header or body, into the header message entry in the WSDL. Is that clear?

Here is the WSM version of the binding operation from the 5.4.1.3 example:
<wsdl:operation name="SecurePing">
<wsdlsoap:operation soapAction=""/>
<wsdl:input name="SecurePingRequest">
<wsdlsoap:body namespace="http://www.openuri.org/jsr181/WebParamExample" parts="Ping" use="literal"/>
<wsdlsoap:header message="impl:SecurePingRequest" namespace="http://www.openuri.org/jsr181/WebParamExample" part="SecHeader" use="literal"/>
</wsdl:input>
</wsdl:operation>

And then the message element:
<wsdl:message name="SecurePingRequest">
<wsdl:part name="SecHeader" type="impl:SecurityHeader"/>
<wsdl:part name="Ping" type="impl:PingDocument"/>
</wsdl:message>

Here is the spec version of the binding operation:
<operation name="SecurePing">
<soap:operation soapAction="http://openuri.org/SecurePing"/>
<input>
<soap:body parts="Ping" use="literal"/>
<soap:header message="SecurePingHeaders" part="SecHeader"use="literal"/>
</input>
</operation>

And the message elements:
<message name="SecurePing">
<part name="Ping" type="tns:Ping"/>
</message>
<message name="SecurePingHeaders">
<part name="SecHeader" element="tns:SecurityHeader"/>
</message>

I get the impression that the non-spec route was explicitly chosen, so the reasoning must be documented somewhere so that it may be validated; otherwise, the handling of headers needs to be changed.

Here is the wording from the spec about WebParam.header (section 7.2):
Parameters annotated with the @WebParam.header attribute map to SOAP headers instead of elements in the SOAP body. Header parameters may appear as parts in the operation's input message, output message, or both depending on the value of the @WebParam.mode attribute. Header parameters are included as soap:header elements in the appropriate wsdl:input and wsdl:output sections of the binding operation.