WSDL generation with requestSuffix set in DefaultWsdl11Definition

[Alan Stewart]

Hi,
When using root elements in schemas where the request suffix does not end in "Request", the WSDL generation using the DefaultWsdl11Definition is not working as expected. For example, if I have 2 simple schemas, FooRequest and FooResponse, as follows:

<?xml version="1.0" encoding="UTF-8"?>
<xs:schema xmlns:xs="http://www.w3.org/2001/XMLSchema" elementFormDefault="qualified" attributeFormDefault="unqualified" targetNamespace="urn:foo" >
	<xs:element name="FooRequest">
		<xs:complexType>
			<xs:attribute name="bar"/>
		</xs:complexType>
	</xs:element>
</xs:schema>

<?xml version="1.0" encoding="UTF-8"?>
<xs:schema xmlns:xs="http://www.w3.org/2001/XMLSchema" elementFormDefault="qualified" attributeFormDefault="unqualified" targetNamespace="urn:foo">
	<xs:element name="FooResponse">
		<xs:complexType>
			<xs:attribute name="bar"/>
		</xs:complexType>
	</xs:element>
</xs:schema>

and include them in my context bean:

	<bean id="foo" class="org.springframework.ws.wsdl.wsdl11.DefaultWsdl11Definition">
		<property name="schemaCollection">
			<bean class="org.springframework.xml.xsd.commons.CommonsXsdSchemaCollection">
				<property name="xsds">
					<list>
						<value>classpath:xsd/Foo.xsd</value>
						<value>classpath:xsd/FooResponse.xsd</value>
					</list>
				</property>
			</bean>
		</property>
		<property name="portTypeName" value="Foo" />
		<property name="locationUri" value="${core.ws.url}/foo" />
	</bean>

the WSDL that gets generated contains what we expect: a wsdl operation with an input and output as follows:

    <wsdl:operation name="Foo">
      <soap:operation soapAction=""/>
      <wsdl:input name="FooRequest">
        <soap:body use="literal"/>
      </wsdl:input>
      <wsdl:output name="FooResponse">
        <soap:body use="literal"/>
      </wsdl:output>
    </wsdl:operation>

However, if my root element of the request does not end in "Request", ie simply "Foo" instead of "FooRequest", and I specify the requestSuffix of "" in the bean as follows:

 <property name="requestSuffix" value="" />

I don't get the wsdl output at all, in fact I get an wsdl input of FooResponse as well:

  <wsdl:binding name="FooSoap11" type="tns:Foo">
    <soap:binding style="document" transport="http://schemas.xmlsoap.org/soap/http"/>
    <wsdl:operation name="FooResponse">
      <soap:operation soapAction=""/>
      <wsdl:input name="FooResponse">
        <soap:body use="literal"/>
      </wsdl:input>
    </wsdl:operation>
    <wsdl:operation name="Foo">
      <soap:operation soapAction=""/>
      <wsdl:input name="Foo">
        <soap:body use="literal"/>
      </wsdl:input>
    </wsdl:operation>
  </wsdl:binding>

What is the expected behaviour when specifying requestSuffix?
Thanks
Alan

[Alan Stewart]

Further to my last post, a non-empty requestSuffix produces the correct WSDL. So there must be a problem in the way empty or null request suffixes are handled?
Alan

[tunaranch]

I have a gut feeling that what you're seeing is expected behaviour, (to cut a long story short, I've seen the same behaviour seeing schema similar to what you've described) but FWIW, it would be nice if DefaultWsdl11Definition could be taught about empty suffixes.

It doesn't bother me personally, though, because we're using hand written (by someone else ) wsdls.

[Alan Stewart]

Arjen, it is worth raising a JIRA issue on this, or can you confirm empty request suffixes are ignorred or not handled?

[Arjen Poutsma]

Basically, the problem is this:

• We have to differentiate which schema elements are wsdl messages, and which aren't.
• Of all wsdl messages, we have to figure out which are input (request) messages.
• Of all wsdl messages, we have to figure out which are output (response) messages.

The DefaultWsdl11Definition figures this out by suffixes. Or, more specifically, it delegates to a SuffixBasedMessagesProvider and SuffixBasedPortTypesProvider to do so. So if you have some other preferred way of determining what makes an input/output message, you will have to write your own messagesprovider and or porttypesprovider.

Simply put: there is no generic way for Spring-WS to determine what makes up a request and a response, rather than using suffixes.

BTW: I will change the DefaultWsdl11Definition so that it will throw an exception when the given suffix is an empty string, because that it is not the intended usage.

[Alan Stewart]

I did as you say and extended your messages provider and port types provider classes and I have it working now. I realize it's a bit of a hack, but given we have the message schemas dictated to us by an external supplier and I don't want to to hand-code the many wsdls, it's a solution that fits!
Thanks
Alan

[tunaranch]

How about a Messages/PortTypesProvider that can take, say, a Properties or a Map, something like:

doFoo.requestMessage={namespace}Foo
doFoo.responseMessage={namespace}FooResponse
doFoo.faultMessage={namespace}FooFault

It's a bit hacky, but still beats doing wsdl by hand.

[Alan Stewart]

Actually I think your suggestion is better than what I did. The DefaultWsdl11Definition checks for the local part of the Message's QName ending in "Request" or the suppled requestSuffix, and "Response" or the supplied responseSuffix to generate input and output messages respectively. Where as my implementation relies on checking that the message does not end in "Response" or the supplied responseSuffix to generate input messages which is a hack.

Declaratively specifying exactly what to look for will eliminate potential errors
Alan