It's really an interoperability problem with .NET clients. .NET requires that the soap header definition appear in the WSDL, otherwise you are forced to modify the generated proxies to allow them to pass the soap header. Forcing clients of the API to have to modify the proxies is not viable.
One of the advantages of the header is that you can pass information to the service that does not clutter up the method signature; otherwise you might as well just pass it as a regular parameter. Ideally, wsdl2java would interpret the WSDL by allowing the header information to be set once on the service, and then unwrap the parameters so that you would have the intended method signature. I do believe the way it is generating the header information in the WSDL is a bug, since it is set to be wrapped document-literal, yet it generates messages with 2 parts. How it decides to represent the header in the proxies, either as a parameter or a way to set the header on the service is certainly a design choice, but not unwrapping the rest of the parameters certainly results in a proxy that does not honor the intent of the service author. Does Axis 1.4 support WS-Policy? I did not see any reference to it in the docs or samples. -----Original Message----- From: Anne Thomas Manes [mailto:[EMAIL PROTECTED] Sent: Thursday, July 20, 2006 5:07 PM To: [email protected] Subject: Re: Generating soap:header info in the WSDL If you specify the header in the WSDL, then you intend the application to supply the header (hence the inclusion of the AuthenticationHeader parameter in the interface). If you don't intend the application to supply the header, then you should not include the header in the WSDL. Your security policies should be specified using WS-Policy. Anne On 7/19/06, Brian Fitzpatrick <[EMAIL PROTECTED]> wrote: > > > > > So, I figured out how to configure Axis to generate soap:header information > in the WSDL file, but it breaks the wrapped document-literal spec. > > > > Configuring Axis to send a parameter in the header, by setting <parameter > inHeader="true"> in the WSDD file creates WSDL that does not comply with the > wrapped document-literal spec. > > > > It generates a wsdl:message that contains 2 parts instead of the 1 required > by the spec. > > > > <wsdl:message name="TestParametersRequest"> > > <wsdl:part element="impl:AuthenticationHeader" > name="AuthenticationHeader"/> > > <wsdl:part element="impl:TestParameters" name="parameters"/> > > </wsdl:message> > > > > As a result, when trying to create an Axis client using WSDL2Java, it fails > to unwrap the TestParameters type (the code will only unwrap if it contains > only one part and meets other criteria). Thus a service operation defined > as: > > > > public void testParameters(String stringParam, int integerParam, Boolean > booleanParam ) > > > > becomes > > > > public void testParameters(AuthenticationHeader header, > TestParameters parameters ) > > > > in the generated Axis client proxies. > > > > It seems like the WSDL generation for headers is incorrect. It should be > generated like .NET generates them, using 2 wsdl:message's: one for the > parameters and one for the header. Then the header is referenced in the > wsdl:binding. > > > > If Axis is going to generate the soap:header information in this way in the > WSDL, then at least the Axis client proxies should be able to recognize this > pattern and unwrap the parameters. Currently, the .NET 2.0 proxies (against > the Axis generated WSDL) do correctly recognize the header and create method > signatures that match the parameters, not a wrapped object containing the > parameters. > > > > > > ________________________________ > > > From: Brian Fitzpatrick > Sent: Wednesday, July 12, 2006 8:19 AM > To: [email protected] > Subject: Generating soap:header info in the WSDL > > > > Does Axis 1.4 support generating the WSDL for a soap header? I can't find a > configuration or samples where it is done. > > > > We have a web service deployed under .NET and Axis. In .NET you can add a > directive to the source code and it will create the wsdl that includes the > soap header info. It creates the binding shown below and also the message > and parts required. > > > > If this is not supported, any suggestions on how to accomplish this > (handlers?, sample code?). > > > > Thanks. > > > > <wsdl:operation name="TestParameters"> > > <soap:operation soapAction="urn:Test/TestParameters" > style="document"/> > > <wsdl:input> > > <soap:body use="literal"/> > > <soap:header > message="tns:TestParametersAuthenticationHeader" > part="AuthenticationHeader" use="literal"/> > > </wsdl:input> > > <wsdl:output> > > <soap:body use="literal"/> > > </wsdl:output> > > </wsdl:operation> > > > > --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
